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 小文件问题
小文件问题简直是大数据平台必须面对的问题，小文件次要有两点危害：
- 小文件过多对HDFS存储的NameNode节点产生比拟大的压力。
- 小文件过多，会对上游工作并发度产生影响，每个小文件生成一个map工作读数据，造成过多的工作生成，同时会有过多的碎片读。
小文件问题产生的起因有哪些？
- 工作数据量小同时写入的并发又比拟大，比拟典型的场景是动静分区。
- 数据歪斜，数据总量可能比拟大，然而有数据歪斜，只有局部文件比拟大，其余的文件都比拟小。
3.3 多集群资源协调问题
随着业务倒退，集群迅速扩张，单个集群的规模越来越大，同时，集群数量也扩大到多个。面对多集群的环境如何做好资源协调是咱们面临的一个挑战。
首先看下多集群的优劣势：
劣势：各个集群资源隔离，危险隔离，局部业务独享资源。
劣势：资源隔离，造成资源孤岛，失去大集群劣势，资源利用率不平均。
例如，比照咱们线上集群 vcore资源应用状况：
从资源应用状况看，集群2的资源利用率显著低于集群1，这就造成集群之间负载不平均，资源利用率低下，资源节约。
3.4 元数据扩大问题
因为历史起因，元数据在集群搭建初期选取单个MySQL实例存储。随着业务数据快速增长的同时，元数据也在飞快增长。这种单点的元数据存储，曾经成为整个大数据系统的稳定性和性能的最大的隐患。同时，在过来的一年，咱们的集群因为元数据服务问题，已经呈现两次比拟大的故障。在此背景下，对元数据的扩大，成为紧急且重要的事项。
问题来了，抉择什么样的扩大计划？
调研业界的几种计划，包含：
- 应用TiDB等分布式数据库；
- 从新布局元数据的散布，拆分到不同的MySQL；
- 应用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数智技术]公众号