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