混合云、多租户大数据平台的容量和合规性思考

2022年05月13日 阅读数:5
这篇文章主要向大家介绍混合云、多租户大数据平台的容量和合规性思考,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

混合云、多租户大数据平台的容量和合规性思考_数据

PART 01 安全

开篇   性能优化

近年来你们都逐渐意识到数据驱动的洞察力的重要性,由于这种方式能够加强战略决策并提升投资回报率,为了安全存档大数据同时也将焦点落在构建数据湖和数据仓库上。顺势,大数据可用于支持各类数据工程、数据科学、业务分析和运营分析计划,并经过提升运营效率、下降运营成本、制定业务战略来帮助企业受益。然而,人类平常消费和生成的数据呈指数级增加,所以就须要在大数据平台中采用结构良好的容量治理方法。服务器

PART 02 网络

介绍    架构

容量治理和可扩展性工程是相互关联的学科,由于它须要全面了解计算、存储容量需求、基础设施供应及其相互关系,从而制定出大数据平台可扩展性策略。除此以外,技术风险的解决和安全合规性也是容量治理须要考虑的重要方面。框架

与其余应用程序相似,大数据应用程序会对客户我的身份信息 (PII) 数据进行操做,并影响公司的关键业务和战略决策。一样,大数据应用程序必须始终遵循最新的数据安全和服务可靠性标准。全部 IT 硬件和软件组件都必须按期更新并使用最新的安全补丁,并对错误进行及时修复。不管部署哪一种基础设施,都必须不断扫描大数据平台的每一个组件,从而保证组件可以被快速识别,同时解决组件潜在的技术问题或安全风险。运维

混合云、多租户大数据平台的容量和合规性思考_数据_02

上图是大数据平台容量治理框架的功能架构。图中最右边的部分表明技术用户的基础设施或供应流。图表的最左侧部分表明需求为主以及按照一般的商业模式为主的流派,这个流派的表明是业务用户,他们的关注点是解决业务问题而不会深刻了解解决方案的技术细节。图中时间点部分表明大数据框架,这部分会使用工具和技术根据需求(左边的部分)管理供应(右边的部分)。分布式

为了保持文章简短,咱们将把技术架构排除在讨论范围以外,由于已经有存在成熟的微服务等工具可以解决特定的领域问题。在开始以前,须要提出一个显而易见的问题——围绕这个问题构建解决方案是否值得?市场上是否有相应的工具可以解决容量和合规性的问题。随着时间的推移,在使用大量监控、APM 和分析工具以后,咱们发现若是须要构建治理平台就须要整合多种工具,由于每种工具都对应解决不一样特定领域的问题。以上结论的前提是不从新造轮子,而使用成熟的工具。ide

例如,在 YARN 上运行的 Spark 应用程序监控、日志分析和性能管理的工具与用于部署在 Kubernetes 容器中实现相同功能的工具是彻底不一样的。虽然它们实现了相同的功能可是运行的平台不一样。一样,将适用于在本地 VMware 中监控、APM 和自动扩展的工具应用于共有云中的虚拟机中却毫无违和感,由于公共云也须要本地监控工具和自动缩放 API。可以移植的缘由是功能相同,环境也相同,公有云是由无数个VMware组合而成。微服务

数据科学或 AI 产业化项目不必定是指 MapReduce/spark/大数据,还有一部分项目包括:系统接口、常规软件或微服务应用。只须要对DevOps 工具和底层部署平台进行选择就好。

对于金融机构而言,确保大数据平台的持续合规性和高可用性极为重要。须要全面了解计算存储资源(供应)、4 V(容量、速度、品种、准确性)、工做负载的性质(处理过程)、SLA 和数据敏感性要求(需求/BAU)。只有考虑上述因素以后才能构建一个适合特定业务场景的可扩展解决方案,同时确保大数据平台的高可用性和容量冗余。

PART 03 

交付方式 

遵循成熟度矩阵,从数据收集和探索,到识别趋势和执行分析,经过分析来支持智能运营。这里将分为 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 证书须要更换。
  • 须要扫描并确保容量冗余,以应对月度租户增加和动态需求高峰时期的每小时利用率。

PART 04 

需求/BAU 流

将业务需求从各个维度进行分析,最终造成技术架构,该架构结合了大数据工具集和部署基础设施以及针对用例的解决方案。

制定用户案例须要的工具类型和数据容量根据系统的数据性质以及数据抽取、计算和报告要求来肯定。例如,流式做业须要处理连续的占用内存较小的流数据(以及适当的计算和网络带宽来处理流式工做负载)。另外一方面,对历史数据的 Batch/ETL 抽取须要考虑大量的内存应用和网络流量激增的状况。除此以外,数据分析和报告生成的工做对负载的要求须要考虑CPU 和 内存瞬间爆发力,具体取决于数据集的大小和查询的复杂性。混合云、多租户大数据平台的容量和合规性思考_数据_03

需求规模模块:

需求规模模块将数据容量的工做负载需求(可预测和不可预测)进行简化,化简以后只须要考虑基础设施数据容量的供应和可用性问题。该模块造成了反馈闭环,该闭环将容量增加和管理需求的利益相关者涵盖其中。业务需求、技术需求与运营可扩展性:对于业务用户而言,功能需求是将数据集传输或批量抽取到数据湖中,并应用于数据工程。又或者利用这些数据生成战略报告,再或者在数据集上训练推荐模型仓库。在更普遍的意义上,咱们将需求分为两类:结构化容量需求、动态容量需求。让咱们看看这些。

(1)结构化容量需求

结构化容量需求是预测容量大小和做业计划的需求,以便提供必要的最低保证容量或保持适当的冗余的工做负载,从而应对高峰时段的流量激增。这些工做负载包括流式做业,它能够预测来自源系统的流式负载。一样,一旦最终部署模型 API,也能够预先为模型 API 预先设置容量。

(2)动态容量需求

动态容量请求由探索阶段的做业组成,由于容量大小没法预先预测,以及做业的执行没有固定的时间表。这包括数据工程师构建其摄取或计算做业的非生产开发环境,以及数据科学家在将模型发布用于生产以前直接训练其模型的实验环境。

这些工做负载在办公时间处于活动状态,所以须要在使用高峰时段进行容量冗余从而面对激增的流量,同时在非高峰时段回收容量,达到节约成本的目的。(3)度量单位与比例单位在考虑整个平台的可扩展性时,咱们须要考虑三个重要因素:

  • 伸缩单位:例如,在 Openshift 中,能够定义容器的可伸缩性,在 VPC 中它将是 VMWare,在 Aws 中它将是EKS 集群、ec2 实例、 s3 存储桶。
  • 度量单位:在伸缩单位最接近度量单位的状况下可使用度量单位。例如,在 EMR 中,伸缩单位是 ec2 实例,但因为这是一个多租户集群,所以度量单位仍然是 spark 做业使用的 CPU 小时数或内存小时数,
  • 销售/购买单位:是能够放置价格标签的实体。因为大数据平台自己就是一个资源管理器,也是一个资源的混合体。若是为团队构建单独的集群,虽然能够对整个集群进行扩展,但仍然须要回答每一个做业所消耗的资源,这里就能够经过销售/购买单位来衡量。
  • 需求分析循环(正向容量计划):在构建数据科学/数据工程项目时,必须理解用例、选择工具和考虑容量规划。 尽管对源系统的四个 V 有很好的理解,但只能估计目标数据集的实际足迹。除此以外,随着按计划或在集群上临时运行的连续抽取和计算做业——须要根据增加的综合趋势来预测容量,包括不断增加的 T一、T2 和 T3 数据集未来所需的容量,以及每一个类别所须要抽取和计算的数据集容量。​

PART 05 

处理/中间件流

位于图表的中心的是各类大数据中间件,这个流最接近大数据主题专家和 SRE 领袖们。该图根据功能对组件进行了分类。

最大的部分是分布式计算层,包括Hadoop/spark 框架(如 Cloudera CDH/CDP、Databricks、Kubernetes 上的 Spark 等)、查询引擎(如 Presto/Impala)和流引擎(Kafka) 。下面来逐一介绍这些组件:

(1)基本服务(监控和日志聚合、数据治理、数据安全)

有一些工具能够为平台中的工做负载提供跨环境、跨集群的基本服务。这包括日志聚合、数据发现/数据治理和数据安全等功能。工具能够跨环境工做,以确保大数据平台的可持续、安全和可靠的运行。

(2)分析/数据科学工做负载

它的使用模式和容量要求与运营集群的数据抽取或计算做业有所不一样。数据科学家可能须要将一组特定的大型数据集导入到分布式处理引擎中进行模型训练。这一过程会一直持续到模型被训练出来,固然须要花费比较长的时间。模型的训练不须要遵循任什么时候间表,尽管集群上的负载在正常办公时间很高,可是在非高峰时间是处于空闲的状态,彻底能够用来进行模型的训练。此外,分析/数据科学的工做负载对集群的数据安全性和访问控制要求比较高,由于模型训练的过程有可能会直接访问客户的生产数据。所以必须创建严格的标记化、数据存储、检索和数据泄漏预防机制,以免任何数据泄露或我的身份信息 (PII) 数据被盗。

(3)开发人员/非产品工做负载

对于操做环境的数据抽取和计算做业而言,数据要么是合成数据,要么是通过查杀的。一般,开发人员环境是共享租赁的,容量相比生产环境会更小一些,支持 SLA 的强度也较低。本质上,大数据解决方案依赖于实际生产数据的四个 V,所以做业的实际足迹和性能只能在生产区进行验证。一般会为生产环境的做业性能调整提供单独的 QA 环境。该环境用于验证来自业务逻辑、数据治理、数据安全和视图集成测试的做业。

(4)运维/ETL/批处理工做负载

运维工做负载是指须要知足有保证的服务水平协议 (SLA) 的抽取或计算做业。这些服务的任何中断均可能影响公司的正常业务 (BAU) 运营或战略业务决策。须要了解做业的总体计算、存储、数据安全和时间敏感性,并确保有足够的容量和冗余,以防止对其 SLA 产生任何影响。

(5)分布式查询处理/可视化层工做负载

许多业务报告不须要对底层数据集进行任何修改,而只须要在内存中处理大型数据集。有几个用于大数据的分布式查询处理引擎(如 Trino/Apache Presto、Apache Impala、Apache Drill 甚至 SparkSQL)可用于报告或可视化工具(如 superset、tableau、Qlikview 或构建的自定义仪表板),而且提供 SQL 接口展现到可视化/图表库上。

  • 关于存储虚拟化的说明

许多组织但愿利用对象存储来实现更廉价的数据归档。然而,就 CAP 定理而言,S3 牺牲了一致性以确保其余两个。同时,考虑到公有云 s3——将大量的大数据计算负载直接放到网络通道上,会形成系统的可靠性不一致。各类工具提供存储虚拟化,其实是经过仲裁层为最终用户提供查询接口,所以很难创建模式(由于不知道用户什么时候使用接口进行查询)。除非用户的查询操做在办公时间,那么能够提高容量在这一时段的利用率,又或者经过能够隔离和分配容量为用户提供预约查询的服务。同时,容量需求能够经过项目级隔离和相应的容量冗余来处理。

(6)流式工做负载、 处理工做负载

新建项目经常会经过流式数据抽取将运营和业务的数据导入到数据仓库中。Apache Kafka、Apache Storm、Spark Streaming 和 AWS Kinesis 是经常使用的数据抽取工具。Kafka 平台自带一套高可用性、多租户和容量治理功能的工具集。根据源系统的网络和性质,大多数状况下,流式做业的 CPU/RAM 占用率不会出现激增的状况,由于流式引擎有效解决了复制和弹性的问题(水平扩展)。

(7)持久层、存储遍历和占用

数据集(保存到存储层)的最终大小可能取决于源系统的性质和大小、压缩类型、复制要求、标记化和加密以及抽取/计算做业的性质。所以,须要经过遍历持久层的方式去识别数据集的实际大小,而后将其与计算做业、租户和源系统产生关联。编写的存储遍历模块就是创建这种关联,经过元数据和多租户结构链接它们的大小,而后得出数据集增加的趋势。最终,才能预测数据集增加的性质和大小,从而使咱们可以根据要求确保存储层冗余。

YARN(或 Future Spark-on-Kubernetes)调度程序的容量治理

本质上,大数据框架中计算工做负载的容量管理利用了 YARN 容量调度程序。

Spark 社区正在努力将相同的功能引入 Kubernetes 上的 Spark。基本上对于一个特定的队列,咱们有一个最小的保证容量,即便集群负载很重,咱们也会保证队列的容量,其余做业将被抢先提供给队列。另外一方面,须要设置最大容量,由于即便在集群正常负载的状况下,也可能没法分配资源的限制。最小保证容量和最大限制之间的差别来自公共池。在高峰时段,若是非关键做业具备较高的 Max Limit 值,则可能会影响具备合理最小值和最大值的关键做业。例如,Apache Hadoop 2.4.1 — Hadoop Map Reduce Next Generation-2.4.1 — 容量调度程序。混合云、多租户大数据平台的容量和合规性思考_数据集_04

例如,上面是操做集群中的 YARN 队列之一。红线表示最小保证容量为 100 个 vCore。而最大值被限制在 270 个 vCore 左右。最小保证容量和最大限制之间的差别来自公共池,若是此时Yarn处于负载状态,则能够抢占该区域中的做业。如今,队列可能在一天内包含数千个运行的做业,如何识别最大的浪费并进行优化须要经过单独的文章来描述。基本上,咱们想要作的是让 VM Infrastructure 成本更接近队列分配的成本。一旦 CPU 或 RAM 被分配给一个做业,从 YARN 的角度来看,它被认为是被占用/使用的。但咱们的目标是采购更接近队列中使用/分配的内容,并设置合理的冗余来处理激增的工做负载。在应用该分配方式的同时,咱们也经过不断地衡量的方式使利用率更接近分配的内容。在这个过程当中,避免了分配不足(避免意外涌入集群)和过分分配(避免浪费)的状况发生。此外,咱们但愿避免在高峰时段安排非关键做业,以免对具备更高 SLA 的时间关键做业产生影响。对于容量和进度优化,须要有不一样的策略。

SRE 日历和合规,每日、每周、每个月花名册

每一个生产变动请求都须要咱们的 L1 支持和站点可靠性工程(SRE)团队为咱们的开发和 DevOps 团队作好准备。SRE 团队必须清楚地了解通知 BAU 团队的停机时间或服务中断时间,尤为是在生产环境中。另外一方面,合规热图提供了关键技术风险可交付成果的综合视图。SRE 日历提供了为 SRE 团队安排上述技术风险行动项目的地方。它还容许开发团队在软件发布、升级和补丁期间经过 L1 支持和 SRE 团队预订和协调 BAU 停机时间。

PART 06 

供应/基础设施流

该分类的灵感来自 Mirco Hering 的DevOps for the Modern Enterprise。根据 DevOps 与相应平台的交互方式,基础设施供应主要分为三个流。这三个基础架构域在咱们实现高可用性、供应/部署自动化和自动扩展的方式上会有所不一样。实施基础设施运营和管理技术风险以及合规的模式也存在不一样。

(1)本地基础设施

虽然一些组织但愿将基础设施维护工做交给公共云提供商来负责,并但愿他们提供具备竞争力的价格。但随着市场上可用的 IT 基础设施愈来愈便宜,但能源效率却在不断升高;将客户数据进行迁移、存储和检索到公共云的成本如滚雪球般愈来愈多,同时还存在公司客户数据遭到破坏或 PII 数据被盗的风险——许多组织更愿意在虚拟私有云自己中构建具备成本效益的功能。

(2)容器化(云原生)基础设施

根据 Gartner 的这项研究——到 2021 年,全球 98% 的基础设施将部署到容器中。使用 Kubernetes/Openshift 等容器编排器将咱们的应用程序部署到容器中,从而能够提供更深层次的操做系统级别隔离、高效配置管理、自动扩展等高级功能、高可用性、可维护性和自愈能力。甚至 Spark 社区也在努力将 Spark 引入 Kubernetes。尽管动态资源分配和队列管理仍在进行中,但一些组织已设法在生产中使用它。

(3)公有云(IAAS / PAAS / SAAS)

公有云易于配置或扩展,一样也会存在浪费。若是不对用例使用最合适的解决方案,很容易浪费资源。对于每一个公有云,最好使用托管服务。例如,虽然能够设置 Argo 管道来启动 vanilla Kubernetes 集群,但为了更好的集成,首选 EKS。一样,与自行部署的 Jupyterhub 和 Hadoop + Spark 部署相比,Sagemaker + EMR 将是首选组合。不管如何,咱们仅将公有云用于 IAAS 或 PAAS,或者将业务工做负载从新设计为公有云产品的本地托管服务——有必要开发一个全面的资产清单并将消费数据叠加在上面其中。

基础设施供应反馈回路

随着愈来愈多的计算和抽取做业加入,并在集群应用中不断增加,必须经过容量反馈来确保容量冗余。除了入住率和增加分析外,还应将其传达给业务用户。经过上面的需求规模模块图中描述的各类前向和后向反馈工做揭示需求和供应的相互做用关系,而且进行分析。

PART 07 

结论    

在构建容量治理框架的同时,保持站点可靠性、高可用性和合规性,须要在虚拟私有云 (VPC) 中的各类基础设施产品中实施 DevOps 和站点可靠性工程 (SRE),而且将这些原则和经验进行结合,应用到容器化、公有云平台以及大数据产品的工做中。同时须要充分考虑业务用户的观点、平台的多租户结构和照旧业务 (BAU)的 服务水平协议 (SLA)、数据安全以及正常运行时间要求。随着时间的推移构建的容量治理框架可以提供洞察力,加强 SRE 团队的能力,并可以经过容量优化节省数百万美圆的基础设施成本。