万字详解大数据平台异地多机房架构实践
发布时间：2022-08-25 11:56:40 所属栏目：大数据 来源：互联网
导读：01 背景 随着B站业务的高速发展，业务数据的生产速度变得越来越快，离线集群规模快速膨胀，既有机房内的机位急剧消耗，在可预见的不久的将来会达到机房容量上限，阻塞业务的发展。因此，如何解决单机房容量瓶颈成为了我们亟待解决的问题。 目前，针对机房容
|
01 背景 随着B站业务的高速发展，业务数据的生产速度变得越来越快，离线集群规模快速膨胀，既有机房内的机位急剧消耗，在可预见的不久的将来会达到机房容量上限，阻塞业务的发展。因此，如何解决单机房容量瓶颈成为了我们亟待解决的问题。 目前，针对机房容量问题的解决方案业界主要有以下两种： 1） 集群整体搬迁至更高容量的机房（scale up） 。该方案是一种纵向扩容方案，即将现有集群搬迁至容量更大的机房，从而提供集群扩展的空间。现实中，集群迁移一般不能影响业务的发展，即保证不停机，因此，迁移过程中需要两个规模相近的集群做全量迁移，或者需要一个具有一定规模的过渡集群，分批次迁移；对于大规模（tens of thousands）集群来说，迁移的经济成本巨大；另外，迁移后的新机房会有再次达到容量上限的风险。 2） 多机房方案（scale out） ，即一个机房容量有限，扩展为多个机房，同时对既有架构进行一定的改造，保证用户视角仍像是一个机房。此举可依据业务需要，采用灵活的方式增量扩容，从而一定程度上避免容量冗余问题。然而，该方案会存在跨机房数据交互，而机房间网络带宽一般也存在瓶颈；同时，网络的抖动或断网可能造成跨机房业务出现异常。因此，该方案需要考虑/解决网络带宽不足及网络抖动/断网问题带来的影响，技术成本较集群整体搬迁方案要高。 就我们目前自建机房的情况来看，中短期暂无清退既有机房（全部搬迁至新机房）的计划，从长期来看也会存在多个机房；另外，比起方案2的技术成本，我们更难接受方案1的经济成本和容量风险。因此，方案2是我们解决机房容量问题首选方案。 02 多机房方案 2.1 面临的问题 上文提到多机房方案面临带宽等网络问题，多机房方案的设计受其制约。 带宽瓶颈 离线场景主要是批处理场景，是对海量历史数据进行离线分析/处理的场景，该场景对延迟不敏感，但由于其处理数据量巨大对网络带宽等资源消耗较大；另外，生产场景中作业数量一般较多且执行时间不受控，若两个机房的主机只是简单叠加在一起做为一个集群来用，可能会存在大量的跨机房互访，产生大量的随机流量打满有限的跨机房带宽, 此时除离线自身受影响外, 还可能对其它跨机房业务造成影响 。因此，如何防止跨机房随机流量打满跨机房带宽是多机房方案要解决的一个重要问题。 网络抖动&连通性 跨城网络会受供应商服务质量影响（或施工影响）造成抖动（或断网）, 与机房内CLOS架构的网络质量相比会低很多。若两个机房的主机当做为一个集群来用，如图1 HDFS示例，当网络抖动时，不但会导致跨机房读写延迟增加，还会影响DN的IBR等过程，造成服务性能和稳定性下降；当网络出现严重问题造成断网时，会导致异地机房数据不可用，还会导致异地机房DN失联，造成大量Block低于预期副本数，触发NN大量补副本等问题。因此，如何降低网络抖动及网络连通性问题带来的影响是多机房方案要解决的另外一个不可忽视的问题。 2.2 设计选型 如上所述，多机房的主要矛盾是跨机房网络带宽不足、稳定性差与离线海量数据处理任务高效产出之间的矛盾，解决该主要矛盾面临的核心问题是如何减少跨机房带宽的消耗，以及如何降低网络稳定性问题带来的影响。 经调研，单元化架构是为解决多地多中心问题演进而来的部署架构，其中，单元是指一个能完成所有业务操作的自包含集合，在这个集合中包含了业务所需的所有服务，以及分配给这个单元的数据 [1-2] 。按照单元化的思路，在多机房场景中，每个机房可以作为一个单元，每个单元内提供作业执行所需要的全部服务以及数据，保证作业在单元内完成，从而解决上述多机房面临的核心问题；单元化拆分后任何一个单元的故障只会影响局部，不会造成整体瘫痪；在选定采用单元化思想来设计了多机房方案之后， 多机房方案的核心问题就限定在了如何决定作业与数据放置，以及如何让作业访问距离近的数据，来降低跨机房带宽的消耗及网络稳定性问题带来的影响。 带着上面的核心问题，我们调研了业界大厂的多机房解决方案 [3-7] 。这些方案在计算层面为防止Shuffle等中间结果数据造成跨机房流量，每个机房均独立部署了计算集群，在该层面均符合单元化思想；但在存储存面存在分歧，如图2所示，依据数据和异地机房的数据副本是否属于同一组NameSpace (NS)，大体可以分为多机房单集群方案和多机房多集群方案。 [3-5] 采用了多机房单集群方案，该方案中采用Block级的数据副本，数据和数据副本同属于一组NS，无数据一致性问题，但因NS只能在其中一个机房，无法有效应对网络连通性问题，且Namenode异地副本管理（BlockPlacementPolicy）和相关工具（Mover, Balancer等）改造成本较大，另外该方案可扩展性也受单集群规模制约。 [6-7] 采用了多机房多集群方案，整体符合单元化思想。其中 [6] 应用于云梯迁机房场景，它首先在同机房中通过Fast Copy将文件元数据分离到两个NS，然后再通过同NS内DN到DN的跨机房Copy将数据复制到远程机房，该方案在一定程度上可以有效应对跨机房网络风险，但因存在两次copy时效性上难以保障，另外也存在异地的数据节点，因此本质上也存在多机房单集群方案改造成本和扩展性问题；[7] 阿里Yugong（Yugong: Geo-Distributed Data and Job Placement at Scale）基于MetaStore针对分区表场景，通过调整作业放置和数据放置来降低跨机房带宽的消耗；如图3所示，计算A、B存在跨机房访问行为，通过调整（互换）计算A、B的放置位置可以有效减少跨机房访问流量；计算C、D同时跨机房消费同一份数据3, 若通过数据复制的方式将数据3复制到机房2， 让C、D依赖数据3在机房2中的副本，则可以减少一次跨机房消费数据流量。但对于我们采用开源大数据架构的场景来说，需要改造（分属于多个子部门的）多种计算框架来适配其基于MetaStore的数据副本管理和数据路由，改造实施成本较大；另外，其基于MetaStore的设计只能解决表（SQL）场景的多机房问题，也不能覆盖我们对非表场景提供多机房支持的需求；不过，该方案中通过“作业放置-数据复制”来解决带宽瓶颈问题的思路非常值得我们借鉴。 综上，我们参考Yugong“作业放置-数据复制”的思路，采用有限的单元化思想设计多机房方案；如图4所示，每个机房部署一套独立的完整的集群（YARN&HDFS），为作业在一个机房内执行提供最基本的服务保障，从而在跨机房网络出现异常时，降低影响范围；同时，通过合理的作业放置和有计划的数据复制，消除跨机房随机访问流量及跨机房数据重复消费等问题，来达到降低带宽消耗的目的；另外，我们结合内部的基础设施情况，以及满足表和非表两种场景的需求，我们选择了基于扩展HDFS Router（RBF）多挂载点来实现数据副本管理和数据路由功能，并通过Client IP感知自动将数据请求路由至较近的机房；还有为解决数据复制带来的一致性问题引入了Version服务等，图中涉及组件将在实现部分进行介绍。 2.3 总体流程 图5展示了以Hive作业为例的在上述设计思路下的总体流程，图中绿色模块为我们新增或改造组件。首先，通过周期性的分析作业间依赖关系及依赖的数据大小，确定作业放置位置信息并进行持久化（DataManager用于管理作业放置信息等），B站的作业调度平台（Archer和Airflow）提交作业时，先获取作业的放置机房信息，并检查预期放置机房的数据副本是否Ready，若Ready则提交作业，否则，阻塞提交，等待数据复制服务完成复制数据；其次，作业调度提交后，拉起Hive/Spark Driver生成可执行计划，向预期DC的Yarn集群提交Job，等待拉起Job，同时我们在Yarn层面也做了改造，基于Yarn Federation架构，实现了基于app tag和队列的机房调度策略，这个在下文也会介绍; 最后，被拉起的作业请求HDFS数据，HDFS Router依据Client IP所属的DC信息，自动将请求路由到距离Client较近的数据复本所在机房的NS, 并将结果返回Client。 多机房核心流程包括作业放置、数据复制、数据路由、版本控制、数据限流、跨机房流量分析等几个阶段，上述Job提交流程并未完全涵盖，下文实现部分我们将对所有阶段进行详细说明。 03 多机房方案实现 下面章节会对多机房核心环节进行介绍， 包括作业放置、数据复制、数据路由，以及为保障数据副本一致性引入的数据版本服务和带宽控制的限流服务，并引入事后的跨机房流量分析工具，用以发现预期外的跨机房行为指导调整。 3.1 作业放置 a. 依赖分析 大数据离线场景，作业数量多，作业之间依赖复杂。比如，大数据离线报表处理业务，从数据采集，清洗，到各个层级的报表的汇总运算，到最后数据导出到外部业务系统，一个完整的业务流程，可能涉及到成百上千个相互交叉依赖关联的作业。就作业放置来说，对复杂作业依赖的管理和分析工作至关重要， 而如我们自研的调度平台Archer等DAG工作流类调度系统，自身具有较强的作业依赖管理能力，因此，我们仅需要聚焦作业依赖分析以确定要迁移的业务。 我们依据作业间依赖关系及需要处理的数据大小，基于社区发现（Community Detection）探索了一种考虑跨机房带宽代价的作业关系链划分模型。该模型首先依据调度系统管理的作业间的依赖关系构建DAG图， 然后从DAG图中圈出相对高内聚（相对比较闭环）的业务子单元，最后结合相互依赖的子单元间的数据量选择出的可以迁移的子单元；如图6所示的简单DAG, 我们假定图中正方形代表计算，圆形代表数据，圆的大小代表数据大小，则我们以虚线作为划分边界将DAG分成两个子单元，分别调度到两个机房，则可满足数据传输代价小的目标。当然，整个过程除了考虑跨机房数据访问代价外，还需要考虑机房计算和存储资源是否可以满足需求。 （编辑：肇庆站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
