关于大数据:OPPO大数据离线计算平台架构演进

1 前言

OPPO 的大数据离线计算倒退，经验了哪些阶段？在生产中遇到哪些经典的大数据问题？咱们是怎么解决的，从中有哪些架构上的降级演进？将来的 OPPO 离线平台有哪些方向布局？明天会给大家一一揭秘。

2 OPPO 大数据离线计算倒退历史

2.1 大数据行业倒退阶段

一家公司的技术倒退，离不开整个行业的倒退背景。咱们简短回归一下大数据行业的倒退，通过谷歌的 BigData 搜寻热度咱们大略分一下大数据的近十几年的过程。

下面的热度曲线来看，大数据倒退大略能够分成三个阶段：
成长期 （2009-2015），这段期间次要代表是 Hadoop1.0 以及相干生态的疾速成长；
巅峰期 （2015-2018），这段期间次要代表是 Hadoop2.0 以及 Spark 迅速成为大数据基础架构和计算引擎的行业事实根底底座；
成熟期（2018-now），这段时间次要代表是 Spark、Flink 等计算引擎以及 OLAP 引擎的凋敝；

从这个热度曲线看，有一个小疑难，近两年大数据热度迅速降落，那么什么技术在近几年成为热度最大的技术？

2.2 OPPO 大数据倒退阶段

OPPO 大数据起步比整个行业稍晚，咱们先看一下倒退时间轴：

2013 年，大数据巅峰期之初，OPPO 开始搭建大数据集群和团队，应用 Hadoop 0.20 版本（Hadoop1.0）。
2015 年，应用 CDH 服务，集群初具规模。
2018 年，自建集群，曾经达到中等规模，应用 Hive 作为计算引擎。
2020 年，开始大规模从 Hive 向 Spark 计算引擎迁徙 SQL 作业。
2021 年，从大数据资源层和计算层降级革新。

OPPO 的大数据倒退能够总结成两个阶段：
发展期 ：2013-2018 年，OPPO 大数据从无到有，缓缓成长，计算节点规模从 0 扩大到中等规模；
繁荣期：2018- 当初，三年大数据疾速倒退，技术上从 hadoop1.0 降级到 hadoop2.0，计算引擎由 hive 降级到 spark；自研技术以及架构降级解决集群规模收缩后常见问题；

3 大数据计算畛域常见问题

大数据畛域有很多经典的问题，咱们这里选取了生产环境遇到五种典型的问题来阐明；咱们将围绕这五种问题开展，介绍 OPPO 大数据离线计算的架构演进。

3.1 Shuffle 问题

Shuffle 是大数据计算的要害一环，shuffle 对工作的性能和稳定性都产生重要的影响。有以下几点因素，导致 shuffle 性能变慢和稳定性变差：

spill&merge：屡次磁盘 io；map 在写 shuffle 数据的过程中，会将内存的数据依照肯定大小刷到磁盘，最初做 sort 和 merge，会产生屡次磁盘 io.

磁盘随机读：每个 reduce 只读取每个 map 输入的局部数据，导致在 map 端磁盘随机读。

过多的 RPC 连贯：假如有 M 个 map，N 个 reduce，shuffle 过程要建设 MxN 个 RPC 连贯（思考多个 map 可能在同一台机器，这个 MxN 是最大连接数）。

Shuffle 问题不仅会影响工作的性能和稳定性，同时在大数据工作上云的过程中，shuffle 数据的承接也成为上云的妨碍。云上资源的动静回收，须要期待上游读取上游的 shuffle 数据之后能力平安的开释资源，否则会导致 shuffle 失败。

3.2 小文件问题

小文件问题简直是大数据平台必须面对的问题，小文件次要有两点危害：

1. 小文件过多对 HDFS 存储的 NameNode 节点产生比拟大的压力。
2. 小文件过多，会对上游工作并发度产生影响，每个小文件生成一个 map 工作读数据，造成过多的工作生成，同时会有过多的碎片读。

小文件问题产生的起因有哪些？

1. 工作数据量小同时写入的并发又比拟大，比拟典型的场景是动静分区。
2. 数据歪斜，数据总量可能比拟大，然而有数据歪斜，只有局部文件比拟大，其余的文件都比拟小。

3.3 多集群资源协调问题

随着业务倒退，集群迅速扩张，单个集群的规模越来越大，同时，集群数量也扩大到多个。面对多集群的环境如何做好资源协调是咱们面临的一个挑战。

首先看下多集群的优劣势：
劣势：各个集群资源隔离，危险隔离，局部业务独享资源。
劣势：资源隔离，造成资源孤岛，失去大集群劣势，资源利用率不平均。

例如，比照咱们线上集群 vcore 资源应用状况：

从资源应用状况看，集群 2 的资源利用率显著低于集群 1，这就造成集群之间负载不平均，资源利用率低下，资源节约。

3.4 元数据扩大问题

因为历史起因，元数据在集群搭建初期选取单个 MySQL 实例存储。随着业务数据快速增长的同时，元数据也在飞快增长。这种单点的元数据存储，曾经成为整个大数据系统的稳定性和性能的最大的隐患。同时，在过来的一年，咱们的集群因为元数据服务问题，已经呈现两次比拟大的故障。在此背景下，对元数据的扩大，成为紧急且重要的事项。

问题来了，抉择什么样的扩大计划？
调研业界的几种计划，包含：

1. 应用 TiDB 等分布式数据库；
2. 从新布局元数据的散布，拆分到不同的 MySQL；
3. 应用 Waggle-Dance 作为元数据的路由层；
   在选型的过程中，咱们思考尽可能对用户影响最小，做到对用户通明，平滑扩大；

3.5 计算对立入口

在咱们将 sql 工作从 hive 迁徙到 spark 引擎的同时，咱们遇到的首要问题是：SparkSQL 工作能不能像 HiveSQL 一样很不便的通过 beeline 或者 jdbc 提交？原生的 spark 是通过 spark 自带的 submit 脚本提交工作，这种形式显然不适宜大规模生产利用。

所以，咱们提出对立计算入口的指标。

不仅对立 SparkSQL 工作提交，同时 jar 包工作也要对立起来。

以上五个问题是咱们在生产环境一直的碰壁，一直的摸索，总结进去的典型的问题。当然，大数据计算畛域还有更多的典型问题，限于文章篇幅，这里仅针对这五个问题探讨。

4 OPPO 离线计算平台解决之道

针对后面提到的五个问题，咱们介绍一下 OPPO 的解决方案，同时也是咱们的离线计算平台的架构演进历程。

4.1 OPPO Remote Shuffle Service

为了解决 shuffle 的性能和稳定性问题，同时，为大数据工作上云做铺垫，咱们自研了 OPPO Remote Shuffle Service（ORS2）。

4.1.1 ORS2 在大数据平台整体架构

有了 ORS2，不仅将 spark 工作的 shuffle 过程从本地磁盘解耦，同时承接了云上资源的大数据计算工作的 shuffle 数据。

从 ShuffleService 自身来说，独立进去一个 service 角色，负责整合计算工作的 shuffle 数据。同时，ShuffleService 自身能够部署到云上资源，动静扩缩容，将 shuffle 资源化。整体架构上看，ShuffleService 分成两层，下面 Service 层，次要有 ShuffleMaster 和 ShuffleWorker 两种角色。

ShuffleMaster 负责 ShuffleWorker 的治理，监控，调配。ShuffleWorker 将本身的相干信息上报给 ShuffleMaster，master 对 worker 的衰弱做治理；提供 worker 加黑放黑、punish 等治理操作。调配策略可定制，比方：Random 策略、Roundrobin 策略、LoadBalance 策略。

ShuffleWorker 负责会集数据，将雷同分区的数据写入到一个文件，Reduce 读分区数据的过程变成程序读，防止了随机读以及 MxN 次的 RPC 通信。

在存储层，咱们的 ShuffleService 能够灵便选取不同的分布式存储文件系统，分区文件的治理以及稳定性保障交由分布式文件系统保障。目前反对 HDFS、CFS、Alluxio 三种分布式文件系统接口。能够依据不同的需要应用不同的存储介质，例如，小工作作业或者对性能要求比拟高的作业，能够思考应用内存 shuffle；对于稳定性要求比拟高，作业重要性也比拟高的作业，能够选取 ssd；对性能要求不高的低级别作业，能够选取 SATA 存储；在性能和老本之间寻求最佳的均衡。

4.1.2 ORS2 的外围架构

从 ShuffleService 的外围架构来看，分为三个阶段：

ShuffleWriter：
Map 工作应用 ShuffleWriter 实现数据的汇集和发送，采纳多线程异步发送；应用堆外内存，内存治理对立交由 spark 原生内存管理系统，防止额定内存开销，升高 OOM 危险。为了进步发送数据的稳定性，咱们设计了两头切换目标 ShuffleWorker 的共，当正在发送的 ShuffleWorker 呈现故障，Writer 端能够立刻切换目标 Worker，持续发送数据。

ShuffleWorker：
Shuffle 负责将数据会集，同时将数据落到分布式文件系统中。ShuffleWorker 的性能和稳定性，咱们做了很多设计，包含流量管制，定制的线程模型，音讯解析定制，checksum 机制等。

ShuffleReader：
ShuffleReader 间接从分布式文件系统读取数据，不通过 ShuffleWorker。为匹配不同的存储系统读数据的个性，Reader 端咱们做了 Pipeline read 优化。
通过以上的多种优化，咱们应用线上大作业测试，ShuffleService 可能减速 30% 左右。

4.2 OPPO 小文件解决方案

小文件问题的解决，咱们心愿对用户是通明的，不须要用户染指，引擎侧通过批改配置即可解决。在理解了 Spark 写入文件的机制后，咱们自研了通明的解决小文件计划。

Spark 工作在最初写入数据的过程，目前有三种 Commit 形式：
（V1，V2，S3 commit），咱们以 V1 版本的 Commit 形式介绍一下咱们的小文件解决方案。

Spark 的 V1 版本 Commit，分为两个阶段，Task 侧的 commit 和 Driver 侧的 commit。Task 侧的 commit，负责将该 Task 自身产生的文件挪到 Task 级的长期目录；Driver 侧的 commit 将整所有的 Task commit 的长期目录挪到最终的目录，最初创立_SUCCESS 文件，标记作业运行胜利。

咱们实现了本人的 CommitProtocol，在 Driver commit 阶段的前段退出合并小文件的操作，扫描：

${output.dir.root}_temporary/${appAttempt}/ 目录上面的小文件，而后生成对应的合并小文件作业。合并完小文件，再调用原来的 commit，将合并后的文件挪到 ${output.dir.root}/ 目录下。

这种形式奇妙的防止显性的提交额定的作业对后果数据合并，同时，在 Driver commit 移动后果文件的时候移动的文件数成数量级的升高，缩小文件移动的工夫耗费。目前，咱们曾经在国内和海内环境全副上线小文件合并。

4.3 OPPO Yarn Router- 多集群资源协调

后面咱们提到多集群的次要的毛病是导致资源孤岛，集群的负载不平衡，整体资源利用率低。上面咱们形象出简略的示意图：

从示意图上看，右边代表 pending 作业，左边代表集群资源状况；长度代表资源量多少，色彩代表资源负载，越深代表负载越高。很显著能够看进去，目前的各个集群资源负载不平衡，同时 pending 作业状况也跟集群的资源应用比成比例，比方 Y1 集群的资源负载很高，然而 pending 作业也很高，Y3 集群资源很闲暇，然而这个集群没有作业 pending。

这种问题，咱们如何解决？

咱们引入了社区的 Yarn Router 性能，用户提交的工作到 router，router 再调配到各个 yarn 集群，实现联邦调度。

社区版本的 Router 策略比拟繁多，只能通过简略的比例调配路由到不同的集群。这种形式只能简略实现路由作业的性能，对集群的资源应用和作业运行状况没有感知，所以，做进去的决策仍然会导致集群负载不平均，例如：

为了彻底解决负载平衡的问题，咱们自研了智能路由策略。

ResourceManager 实时向 router 上报本身集群的资源和作业运行状况，给出资源开释量的预测，router 依据各个集群上报的信息，产生全局的视图。依据全局视图，router 做出更正当的路由决策。

总体上看，有了一个全局视线的 Router 角色，多集群场景下，充分发挥多集群的劣势，同时防止多集群的有余。将来，咱们打算赋予 Router 更多的能力，不仅用来解决作业 pending，晋升资源利用率。还将从作业运行效率方面做更多的工作，让作业和计算、存储资源做更好的匹配，让计算更有价值。

4.4 元数据扩大利器——Waggle Dance

Waggle Dance 为 Hive MetaStore 提供路由代理，是 Apache 开源我的项目。Waggle Dance 齐全兼容 HiveMetaStore 原生接口，无缝接入现有零碎，实现对用户通明降级，这也是咱们抉择该技术计划的次要起因。

Waggle Dance 的工作原理是将现有的 Hive 数据库依照库名别离路由到不同组的 Metastore，每一组 Metastore 对应独立的 MySQL DB 实例，实现从物理上隔离元数据。

下面的示意图，右边是原始的 HiveMetastore 架构，从架构图自身来看，整体架构存在显著的单点问题，同时数据交换流程不够柔美。应用 Waggle Dance 降级后，整体架构更加清晰，更加柔美。Waggle Dance 作为元数据交换的“总线”，将下层计算引擎的申请依照库名路由到对应的 Metastore。

咱们在做线上切分元数据实际操作过程中，总体 Metastore 停机工夫在 10 分钟以内。咱们对 Waggle Dance 做了定制优化，加了数据缓存层，晋升路由效率；同时，将 Waggle Dance 与咱们的外部管理系统整合，提供界面话的元数据管理服务。

4.5 计算对立入口——Olivia

为了解决 Spark 工作提交入口的问题，咱们还是将眼光投向了开源社区，发现 Livy 能够很好的解决 SparkSQL 的工作提交。

Livy 是一个提交 Spark 工作的 REST 服务，能够通过多种路径向 Livy 提交作业，比方咱们罕用的是 beeline 提交 sql 工作，还有其余的比方网络接口提交；

工作提交到 Livy 后，Livy 向 Yarn 集群提交工作，Livy client 生成 Spark Context，拉起 Driver。Livy 能够同时治理多个 Spark Context，反对 batch 和 interactive 两种提交模式，性能根本相似 HiveServer。

Livy 能满足咱们的需要吗？咱们先看 Livy 自身有哪些问题。

咱们总结的 Livy 次要有三个缺点：

不足高可用：Livy Server 过程重启或者服务掉线，下面治理的 Spark Context session 将会失控，导致工作失败。

不足负载平衡：Livy Server 的任务分配是一个随机过程，随机选取 zk 命名空间的一个 Livy Server，这种随机过程会导致一组 Livy Server 负载不平衡。

对 spark submit 作业反对有余：对于 spark submit 提交的 jar 包工作，目前反对的不欠缺。

针对下面的几个问题，咱们基于 Livy 自研了 Olivia，是一种高可用、负载平衡、同时反对 spark submit jar 包工作以及 python 脚本的计算对立入口。

Olivia 应用域名提交作业，用户不必感知具体是哪台 Server 反对作业提交和治理。后盾应用一致性 Hash 实现负载平衡，如果有 Server 高低线，也会主动实现负载平衡。对于故障转移，咱们应用 zk 存储 spark session 信息，某个 server 呈现问题，对应治理的 session 会主动转移到其余的 server 治理。对于 Spark submit 工作的反对，咱们新增一个 Olivia client 角色，该 client 会主动将 jar 包以及 python 脚本上传到集群，不便 Olivia Server 提交作业。

4.6 总揽

后面介绍了咱们对五种问题的解决方案，串联起来就是咱们明天的主题：大数据离线计算平台的演进。

在这一章的最初，咱们从整顿看一下目前的离线计算架构视图。

由上到下，咱们能够形象出六层，别离是：

Job Submit：这层次要是咱们的离线作业调度 Oflow，实现工作的定时调度，dag 治理，作业运行治理；外围性能就是实现了工作的提交。

Job Control：这层次要有 HiveServer、Livy、Olivia 这些工作管制组件，负责工作向集群提交和管控。

Compute Engine：引擎层次要应用 Spark 和 MR。

Shuffle Service：这层是为 Spark 引擎提供 shuffle 服务，后续 Shuffle Service 也将承接 Flink 引擎的 shuffle 数据。

MetaData Control：Waggle Dance 和 MetaStore 以及底层的 MySQL 造成咱们的元数据管制层，应用了 Waggle Dance 是咱们的元数据管理更灵便。

Resource Control：资源管制层，就是咱们的计算资源，次要由 Yarn Router 来管制各个集群的作业路由，各个 Yarn 集群实现资源的治理和作业运行。咱们不仅在 Router 上有自研的策略，咱们在 RM 资源调度上也摸索了更多的调度模式，比方：动静标签、资源限售、更智能的抢占调度。

5 OPPO 离线计算平台倒退瞻望

技术的倒退演进始终在进行，OPPO 的离线计算将来是什么样子，这也是咱们始终在考虑的命题。咱们思考从纵向和横向两个方向都要兼顾。

5.1 横向考虑

横向上，思考与其余资源和计算模式买通交融。

咱们正在与弹性计算团队单干，将大数据与云上资源买通，利用线上服务和大数据计算两种模式的错峰个性，充分利用公司现有资源，实现在离线混合调度。

同时，咱们跟实时计算团队单干，摸索更适宜实时计算的调度模式。

5.2 纵向考虑

纵向上，咱们思考如何将现有架构做的更深刻，更精细化。

大 HBO 概念：咱们在摸索一种大 HBO 概念的架构降级，从 Oflow 到 yarn 调度，再到 spark 引擎以及 OLAP 引擎的 HBO 优化。外围是提供更快、更主动、老本更低的计算。

Shuffle 的持续演进，思考后续 Shuffle 的演进，与引擎作业调度更加交融，提供 spark 批计算的 Pipeline 计算模式。同时，思考在 Shuffle Service 退出 Shuffle Sorter 角色，将 sort 过程挪到 Shuffle Service 层，将 spark sort 算子并行化，减速 sort 操作。

最初，感激大家的关注，欢送大家多多交换大数据计算的技术思考。

作者简介

David OPPO 高级数据平台工程师

次要负责 OPPO 大数据离线计算方向架构设计开发，曾在国内一线大厂参加自研大数据计算引擎开发。对大数据平台建设有比拟丰盛的教训。

获取更多精彩内容，请扫码关注 [OPPO 数智技术] 公众号