开篇
近年来大家都逐渐意识到数据驱动的洞察力的重要性，因为这种方式可以增强战略决策并提高投资回报率，为了安全存档大数据同时也将焦点落在构建数据湖和数据仓库上。顺势，大数据可用于支持各种数据工程、数据科学、业务分析和运营分析计划，并通过提高运营效率、降低运营成本、制定业务战略来帮助企业受益。然而，人类日常消费和生成的数据呈指数级增长，因此就需要在大数据平台中采用结构良好的容量治理方法。
介绍
容量治理和可扩展性工程是相互关联的学科，因为它需要全面了解计算、存储容量需求、基础设施供应及其相互关系，从而制定出大数据平台可扩展性策略。除此之外，技术风险的解决和安全合规性也是容量治理需要考虑的重要方面。
与其他应用程序类似，大数据应用程序会对客户个人身份信息 (PII) 数据进行操作，并影响公司的关键业务和战略决策。同样，大数据应用程序必须始终遵循最新的数据安全和服务可靠性标准。所有 IT 硬件和软件组件都必须定期更新并使用最新的安全补丁，并对错误进行及时修复。无论部署哪种基础设施，都必须不断扫描大数据平台的每个组件，从而保证组件能够被快速识别，同时解决组件潜在的技术问题或安全风险。
上图是大数据平台容量治理框架的功能架构。图中最右边的部分代表技术用户的基础设施或供应流。图表的最左侧部分代表需求为主以及按照通常的商业模式为主的流派，这个流派的代表是业务用户，他们的关注点是解决业务问题而不会深入了解解决方案的技术细节。图中时间点部分代表大数据框架，这部分会使用工具和技术根据需求（左边的部分）管理供应（右边的部分）。
为了保持文章简短，我们将把技术架构排除在讨论范围之外，因为已经有存在成熟的微服务等工具能够解决特定的领域问题。在开始之前，需要提出一个显而易见的问题——围绕这个问题构建解决方案是否值得？市场上是否有相应的工具能够解决容量和合规性的问题。随着时间的推移，在使用大量监控、APM 和分析工具之后，我们发现如果需要构建治理平台就需要整合多种工具，因为每种工具都对应解决不同特定领域的问题。以上结论的前提是不重新造轮子，而使用成熟的工具。
例如，在 YARN 上运行的 Spark 应用程序监控、日志分析和性能管理的工具与用于部署在 Kubernetes 容器中实现相同功能的工具是完全不同的。虽然它们实现了相同的功能但是运行的平台不同。同样，将适用于在本地 VMware 中监控、APM 和自动扩展的工具应用于共有云中的虚拟机中却毫无违和感，因为公共云也需要本地监控工具和自动缩放 API。能够移植的原因是功能相同，环境也相同，公有云是由无数个VMware组合而成。
数据科学或 AI 产业化项目不一定是指 MapReduce/spark/大数据，还有一部分项目包括：系统接口、常规软件或微服务应用。只需要对DevOps 工具和底层部署平台进行选择就好。
对于金融机构而言，确保大数据平台的持续合规性和高可用性极为重要。需要全面了解计算存储资源（供应）、4 V（容量、速度、品种、准确性）、工作负载的性质（处理过程）、SLA 和数据敏感性要求（需求/BAU）。只有考虑上述因素之后才能构建一个适合特定业务场景的可扩展解决方案，同时确保大数据平台的高可用性和容量冗余。
交付方式：
遵循成熟度矩阵，从数据收集和探索，到识别趋势和执行分析，通过分析来支持智能运营。这里将分为 7 个阶段实现这一目标：
1、全面盘点
建立全面的跨平台清单，其中虚拟机基础架构级别的清单可以从本地监控工具中轻松获得。需要注意的是，容器化平台和不同公有云中的 API以及监控模式是存在差异的。除此之外，仅 VM 级别的清单是不够的。由于平台使用了多个内部的、供应商支持的和开源的中间件，而这些中间件由不同组件组成，所以需要对这些中间件创建清单。我们必须实现发布者、观察者和订阅者来为这些中间件执行角色标记，然后再将这些中间件部署到虚拟机、容器化（Kubernetes/Openshift）或公有云平台中。
2. 基础设施利用率、消费趋势以及分析
当了解跨混合云基础架构部署的角色之后，就需要使用基础架构利用率并将数据分类为更细的颗粒度，并且对其定义指标。
此外，监控数据必须解决这两个问题：
时间点事件管理需要快速识别、通知和解决 CPU、RAM 和网络容量问题。事件管理仪表板的采样频率需要接近实时。
时间序列数据是容量矩阵的聚合，其中聚合数据的标记从 5 分钟的采样汇总到每小时、每天、每周和每月的采样汇总。通过这样的组件采样频率，提升长期容量利用率和服务运行状况分析的能力。
上面说的数据是技术/基础设施利用率数据，然后将多租户占用率数据叠加到这些数据之上，得出每个数据集、工作、项目/计划和业务单位的租户占用率的累积信息。
3. 需求分析与预测
如果从基础设施利用率中获得租户的入住率数据，就能够确定存储、计算和项目规模级别的增长趋势。基于单个数据集/租户的相对增长，就可以确定最高占用者、增长最快的数据集/租户、顶级（计算）浪费和非关键噪声邻居。
4、性能优化
确定最浪费的资源，在确保适当冗余并提高服务可靠性的前提下，与业务部门合作对资源进行优化减少浪费。在每个时间点，都有由作业程序调度到集群上的数千个作业，每个队列包含数百个提交的作业，这些作业服务于每日、每周、每月或临时计划。在这些作业的执行过程中需要识别和调整最大的 CPU 和 RAM 浪费，并将非关键作业安排到非关键或非高峰时间段运行。
5. 高可用性、容量冗余和可扩展性
识别关键业务工作负载并为其运行提供冗余容量，并将非关键的负载调整到非高峰时间，这种负载调整的行为被认为是站点可靠性团队的关键性能指标之一。除了确保中间件的高可用性之外，识别站点可靠性问题，并确保平台组件的单独和集体扩展性，从而应对高峰时段的流量激增，要做到以上描述必须监控和观察一段时间内的运营数据才能实现。
对于每个中间件组件，worker 和 master 级别的高可用性是一项基本要求，尤其是对于业务关键型为 1 类的应用更是这样。对于内部应用，需要对每个组件级别收集彻底、一致的代码分析、单元集成性能测试结果、依赖许可以及漏洞扫描数据等相关信息。对于托管服务，在公有云中需要与各自的云基础设施提供商建立服务水平协议。外部软件提供商需要确保相同的软件支持、修补和事件管理支持 SLA。
6. 自动扩展、自我修复、成本优化
在成熟的最后阶段，容量治理框架将变得更具侵入性，我们的决策引擎不仅可以为 SRE 团队生成时间表、每周每月的计划，还可以在无需人工干预的情况下自动修复或清理一些服务（取决于环境的关键性、服务水平协议和变化的影响范围）。最后，必须对上面捕获的数据和分析进行管理，以确定适合每个中间件组件的性能最高、成本最优的基础架构。
这些数据还可以用于创建自动扩展策略、自我修复（特别是针对非 HA 组件）、性能和成本优化报告以及推荐模型。
7. 技术风险和持续合规
事实证明，采购和设置一个高性能的安全兼容的系统是不够的，有必要确保每个组件无论部署在什么样的平台上都保持兼容性，组件不会受到持续的威胁和漏洞的影响。
技术风险和合规性是金融行业服务交付的极其重要的方面之一，因为服务中断可能导致金钱损失和监管处罚， Cat1 这类型的应用就是个典型的例子。一旦将项目交付到生产环境，成本就不会止步于此，所以要三思而后行。
- 更换报废硬件。支持软件类需要持续更新。终止支持许可证应及时更新。
- 部署到不同平台的各种组件公开了各种 TCP 和其他端口，必须统一扫描这些端口以获取必要的网络区域隔离、传输 (SSL) 和静态（加密）标准。
- 每个中间件子组件/微服务必须准时扫描关键漏洞（例如最近的 log4j 漏洞）。服务器需要及时打上最新的操作系统和安全补丁。
- 服务器需要定期重启以确认中间件层的灾难恢复、高可用性、检测和消除单点故障以及应用需要重启的补丁。
- 对于云 EC2 实例，需要关注刷新 AMI、凭证和加密密钥以及 SSL 证书需要更换。
- 需要扫描并确保容量冗余，以应对月度租户增长和动态需求高峰时期的每小时利用率。
1.需求/BAU 流
将业务需求从各个维度进行分析，最终形成技术架构，该架构结合了大数据工具集和部署基础设施以及针对用例的解决方案。
制定用户案例需要的工具类型和数据容量根据系统的数据性质以及数据抽取、计算和报告要求来确定。例如，流式作业需要处理连续的占用内存较小的流数据（以及适当的计算和网络带宽来处理流式工作负载）。另一方面，对历史数据的 Batch/ETL 抽取需要考虑大量的内存应用和网络流量激增的情况。除此之外，数据分析和报告生成的工作对负载的要求需要考虑CPU 和 内存瞬间爆发力，具体取决于数据集的大小和查询的复杂性。
需求规模模块：
需求规模模块将数据容量的工作负载需求（可预测和不可预测）进行简化，化简之后只需要考虑基础设施数据容量的供应和可用性问题。该模块形成了反馈闭环，该闭环将容量增长和管理需求的利益相关者涵盖其中。
业务需求、技术需求与运营可扩展性：
对于业务用户而言，功能需求是将数据集传输或批量抽取到数据湖中，并应用于数据工程。又或者利用这些数据生成战略报告，再或者在数据集上训练推荐模型仓库。
在更广泛的意义上，我们将需求分为两类——1.结构化容量需求，2.动态容量需求。让我们看看这些。
1a 结构化容量需求：
结构化容量需求是预测容量大小和作业计划的需求，以便提供必要的最低保证容量或保持适当的冗余的工作负载，从而应对高峰时段的流量激增。这些工作负载包括流式作业，它可以预测来自源系统的流式负载。同样，一旦最终部署模型 API，也可以预先为模型 API 预先设置容量。
1b 动态容量需求：
动态容量请求由探索阶段的作业组成，因为容量大小无法预先预测，以及作业的执行没有固定的时间表。这包括数据工程师构建其摄取或计算作业的非生产开发环境，以及数据科学家在将模型发布用于生产之前直接训练其模型的实验环境。这些工作负载在办公时间处于活动状态，因此需要在使用高峰时段进行容量冗余从而面对激增的流量，同时在非高峰时段回收容量，达到节约成本的目的。
度量单位与比例单位：
在考虑整个平台的可扩展性时，我们需要考虑三个重要因素：
伸缩单位：例如，在 Openshift 中，可以定义容器的可伸缩性，在 VPC 中它将是 VMWare，在 Aws 中它将是EKS 集群、ec2 实例、 s3 存储桶。
度量单位：在伸缩单位最接近度量单位的情况下可以使用度量单位。例如，在 EMR 中，伸缩单位是 ec2 实例，但由于这是一个多租户集群，因此度量单位仍然是 spark 作业使用的 CPU 小时数或内存小时数，
销售/购买单位：是可以放置价格标签的实体。由于大数据平台本身就是一个资源管理器，也是一个资源的混合体。如果为团队构建单独的集群，虽然可以对整个集群进行扩展，但仍然需要回答每个作业所消耗的资源，这里就可以通过销售/购买单位来衡量。
需求分析循环（正向容量计划）：
在构建数据科学/数据工程项目时，必须理解用例、选择工具和考虑容量规划。 尽管对源系统的四个 V 有很好的理解，但只能估计目标数据集的实际足迹。除此之外，随着按计划或在集群上临时运行的连续抽取和计算作业——需要根据增长的综合趋势来预测容量，包括不断增长的 T1、T2 和 T3 数据集将来所需的容量，以及每个类别所需要抽取和计算的数据集容量。
2. 处理/中间件流
位于图表的中心的是各种大数据中间件，这个流最接近大数据主题专家和 SRE 领袖们。该图根据功能对组件进行了分类。
最大的部分是分布式计算层，包括Hadoop/spark 框架（如 Cloudera CDH/CDP、Databricks、Kubernetes 上的 Spark 等）、查询引擎（如 Presto/Impala）和流引擎（Kafka） 。下面来逐一介绍这些组件：
2a 2b 2c 基本服务（监控和日志聚合、数据治理、数据安全）：
有一些工具可以为平台中的工作负载提供跨环境、跨集群的基本服务。这包括日志聚合、数据发现/数据治理和数据安全等功能。工具可以跨环境工作，以确保大数据平台的可持续、安全和可靠的运行。
2e 分析/数据科学工作负载：
它的使用模式和容量要求与运营集群的数据抽取或计算作业有所不同。数据科学家可能需要将一组特定的大型数据集导入到分布式处理引擎中进行模型训练。这一过程会一直持续到模型被训练出来，当然需要花费比较长的时间。模型的训练不需要遵循任何时间表，尽管集群上的负载在正常办公时间很高，但是在非高峰时间是处于空闲的状态，完全可以用来进行模型的训练。
此外，分析/数据科学的工作负载对集群的数据安全性和访问控制要求比较高，因为模型训练的过程有可能会直接访问客户的生产数据。因此必须建立严格的标记化、数据存储、检索和数据泄漏预防机制，以避免任何数据泄露或个人身份信息 (PII) 数据被盗。
2f 开发人员/非产品工作负载：
对于操作环境的数据抽取和计算作业而言，数据要么是合成数据，要么是经过查杀的。通常，开发人员环境是共享租赁的，容量相比生产环境会更小一些，支持 SLA 的强度也较低。本质上，大数据解决方案依赖于实际生产数据的四个 V，因此作业的实际足迹和性能只能在生产区进行验证。通常会为生产环境的作业性能调整提供单独的 QA 环境。该环境用于验证来自业务逻辑、数据治理、数据安全和视图集成测试的作业。
2g 运维/ETL/批处理工作负载：
运维工作负载是指需要满足有保证的服务水平协议 (SLA) 的抽取或计算作业。这些服务的任何中断都可能影响公司的正常业务 (BAU) 运营或战略业务决策。需要了解作业的整体计算、存储、数据安全和时间敏感性，并确保有足够的容量和冗余，以防止对其 SLA 产生任何影响。
2h分布式查询处理/可视化层工作负载
许多业务报告不需要对底层数据集进行任何修改，而只需要在内存中处理大型数据集。有几个用于大数据的分布式查询处理引擎（如 Trino/Apache Presto、Apache Impala、Apache Drill 甚至 SparkSQL）可用于报告或可视化工具（如 superset、tableau、Qlikview 或构建的自定义仪表板），并且提供 SQL 接口展示到可视化/图表库上。
关于存储虚拟化的说明：
许多组织希望利用对象存储来实现更廉价的数据归档。然而，就 CAP 定理而言，S3 牺牲了一致性以确保其他两个。同时，考虑到公有云 s3——将大量的大数据计算负载直接放到网络通道上，会造成系统的可靠性不一致。各种工具提供存储虚拟化，实际上是通过仲裁层为最终用户提供查询接口，因此很难建立模式（因为不知道用户何时使用接口进行查询）。除非用户的查询操作在办公时间，那么可以提升容量在这一时段的利用率，又或者通过可以隔离和分配容量为用户提供预定查询的服务。同时，容量需求可以通过项目级隔离和相应的容量冗余来处理。
2i 流式工作负载、 处理工作负载
新建项目常常会通过流式数据抽取将运营和业务的数据导入到数据仓库中。Apache Kafka、Apache Storm、Spark Streaming 和 AWS Kinesis 是常用的数据抽取工具。Kafka 平台自带一套高可用性、多租户和容量治理功能的工具集。根据源系统的网络和性质，大多数情况下，流式作业的 CPU/RAM 占用率不会出现激增的情况，因为流式引擎有效解决了复制和弹性的问题（水平扩展）。
2j持久层、存储遍历和占用
数据集（保存到存储层）的最终大小可能取决于源系统的性质和大小、压缩类型、复制要求、标记化和加密以及抽取/计算作业的性质。因此，需要通过遍历持久层的方式去识别数据集的实际大小，然后将其与计算作业、租户和源系统产生关联。
编写的存储遍历模块就是建立这种关联，通过元数据和多租户结构连接它们的大小，然后得出数据集增长的趋势。最终，才能预测数据集增长的性质和大小，从而使我们能够根据要求确保存储层冗余。
YARN（或 Future Spark-on-Kubernetes）调度程序的容量治理：
本质上，大数据框架中计算工作负载的容量管理利用了 YARN 容量调度程序。Spark 社区正在努力将相同的功能引入 Kubernetes 上的 Spark。基本上对于一个特定的队列，我们有一个最小的保证容量，即使集群负载很重，我们也会保证队列的容量，其他作业将被抢先提供给队列。另一方面，需要设置最大容量，因为即使在集群正常负载的情况下，也可能无法分配资源的限制。
最小保证容量和最大限制之间的差异来自公共池。在高峰时段，如果非关键作业具有较高的 Max Limit 值，则可能会影响具有合理最小值和最大值的关键作业。例如，Apache Hadoop 2.4.1 — Hadoop Map Reduce Next Generation-2.4.1 — 容量调度程序。
例如，上面是操作集群中的 YARN 队列之一。红线表示最小保证容量为 100 个 vCore。而最大值被限制在 270 个 vCore 左右。最小保证容量和最大限制之间的差异来自公共池，如果此时Yarn处于负载状态，则可以抢占该区域中的作业。现在，队列可能在一天内包含数千个运行的作业，如何识别最大的浪费并进行优化需要通过单独的文章来描述。
基本上，我们想要做的是让 VM Infrastructure 成本更接近队列分配的成本。一旦 CPU 或 RAM 被分配给一个作业，从 YARN 的角度来看，它被认为是被占用/使用的。
但我们的目标是采购更接近队列中使用/分配的内容，并设置合理的冗余来处理激增的工作负载。在应用该分配方式的同时，我们也通过不断地衡量的方式使利用率更接近分配的内容。在这个过程中，避免了分配不足（避免意外涌入集群）和过度分配（避免浪费）的情况发生。此外，我们希望避免在高峰时段安排非关键作业，以避免对具有更高 SLA 的时间关键作业产生影响。对于容量和进度优化，需要有不同的策略。
SRE 日历和合规，每日、每周、每月花名册
每个生产变更请求都需要我们的 L1 支持和站点可靠性工程（SRE）团队为我们的开发和 DevOps 团队做好准备。SRE 团队必须清楚地了解通知 BAU 团队的停机时间或服务中断时间，尤其是在生产环境中。
另一方面，合规热图提供了关键技术风险可交付成果的综合视图。
SRE 日历提供了为 SRE 团队安排上述技术风险行动项目的地方。它还允许开发团队在软件发布、升级和补丁期间通过 L1 支持和 SRE 团队预订和协调 BAU 停机时间。
3. 供应/基础设施流
该分类的灵感来自 Mirco Hering 的DevOps for the Modern Enterprise。根据 DevOps 与相应平台的交互方式，基础设施供应主要分为三个流。这三个基础架构域在我们实现高可用性、供应/部署自动化和自动扩展的方式上会有所不同。实施基础设施运营和管理技术风险以及合规的模式也存在不同。
3a本地基础设施
虽然一些组织希望将基础设施维护工作交给公共云提供商来负责，并希望他们提供具有竞争力的价格。但随着市场上可用的 IT 基础设施越来越便宜，但能源效率却在不断升高；将客户数据进行迁移、存储和检索到公共云的成本如滚雪球般越来越多，同时还存在公司客户数据遭到破坏或 PII 数据被盗的风险——许多组织更愿意在虚拟私有云本身中构建具有成本效益的功能。
3b容器化（云原生）基础设施
根据 Gartner 的这项研究——到 2021 年，全球 98% 的基础设施将部署到容器中。使用 Kubernetes/Openshift 等容器编排器将我们的应用程序部署到容器中，从而可以提供更深层次的操作系统级别隔离、高效配置管理、自动扩展等高级功能、高可用性、可维护性和自愈能力。
甚至 Spark 社区也在努力将 Spark 引入 Kubernetes。尽管动态资源分配和队列管理仍在进行中，但一些组织已设法在生产中使用它。
3c公有云（IAAS / PAAS / SAAS）
公有云易于配置或扩展，同样也会存在浪费。如果不对用例使用最合适的解决方案，很容易浪费资源。对于每个公有云，最好使用托管服务。例如，虽然可以设置 Argo 管道来启动 vanilla Kubernetes 集群，但为了更好的集成，首选 EKS。同样，与自行部署的 Jupyterhub 和 Hadoop + Spark 部署相比，Sagemaker + EMR 将是首选组合。无论如何，我们仅将公有云用于 IAAS 或 PAAS，或者将业务工作负载重新设计为公有云产品的本地托管服务——有必要开发一个全面的资产清单并将消费数据叠加在上面其中。
基础设施供应反馈回路
随着越来越多的计算和抽取作业加入，并在集群应用中不断增长，必须通过容量反馈来确保容量冗余。除了入住率和增长分析外，还应将其传达给业务用户。通过上面的需求规模模块图中描述的各种前向和后向反馈工作揭示需求和供应的相互作用关系，并且进行分析。
结论
在构建容量治理框架的同时，保持站点可靠性、高可用性和合规性，需要在虚拟私有云 (VPC) 中的各种基础设施产品中实施 DevOps 和站点可靠性工程 (SRE)，并且将这些原则和经验进行结合，应用到容器化、公有云平台以及大数据产品的工作中。同时需要充分考虑业务用户的观点、平台的多租户结构和照旧业务 (BAU)的 服务水平协议 (SLA)、数据安全以及正常运行时间要求。随着时间的推移构建的容量治理框架能够提供洞察力，增强 SRE 团队的能力，并能够通过容量优化节省数百万美元的基础设施成本。
译者介绍
崔皓，51CTO社区编辑，资深架构师，拥有18年的软件开发和架构经验，10年分布式架构经验。曾任惠普技术专家。乐于分享，撰写了很多热门技术文章，阅读量超过60万。《分布式架构原理与实践》作者。
原文标题：Capacity and Compliance in Hybrid Cloud, Multi-Tenant Big Data Platforms，作者：Amit Thakur
链接：https://dzone.com/articles/capacity-compliance-hybrid-cloud-multi-tenant-platforms