关于大数据:联通数据编排技术在联通的应用

7次阅读

共计 8938 个字符，预计需要花费 23 分钟才能阅读完成。

欢送来到【微直播间】，2min 纵览大咖观点，本期分享的题目是数据编排技术在联通的利用。本次分享内容将围绕四个方面讲述 Alluxio 数据编排技术在联通的利用，次要围绕缓存减速、存算拆散、混合负载以及轻量级剖析四个不同的应用场景进行分享：

摘要
01. 在缓存减速方面的利用
为了减速 Spark 计算，引入了 Alluxio 来减速数据的读写性能，进步数据写入的稳定性，以及接管 Spark Cache 后晋升 Spark 作业的稳定性。这是咱们一开始采纳的架构，数据编排在咱们的整个架构中的定位是缓存减速层。

* 减速迭代计算：减速上游 SQL 读取数据速度，晋升数据写⼊稳定性；* Spark Job 间共享数据，替换 Spark cache；* 内存多正本显著提⾼热数据访问速度；* 调整数据分布策略实现负载平衡；* Alluxio 带来性能与稳定性晋升；

02. 在存算拆散方面的利用

* 利⽤其余业务资源满⾜计算扩容需要；* 实现存储独⽴扩容，数据冷热拆散；

03. 在混合负载畛域的利用

* 利⽤ Alluxio Client Cache 实现缓存隔离；* 利⽤ Alluxio Fuse 买通 ETL 与 AI 训练 / 推理；

04. 轻量级剖析相干摸索
Presto + Alluxio 实现轻量级数据分析

* 1) 在⽤户集群搭建 Alluxio + Presto 两套零碎满⾜数据分析需要，运维复杂度绝对较低，纯 SQL 交互⽤户体验好；* 2) Alluxio mount 平台 HDFS ⽤于公有数据共享，Alluxio SDS mount 平台 Hive ⽤于私有数据拜访及性能减速；* 3) 基于 Presto Iceberg connector 的 hadoop catalog mode，采⽤只写缓存的⽅式在本地实现 ETL，最终数据长久化⾄平台 HDFS；* 4) Alluxio 使⽤ 3 正本策略保障缓存数据的可⽤性，可挂载独⽴存储集群长久化存储需⻓期保留的剖析数据。

以上仅为大咖演讲概览，残缺内容【点击观看】：

附件：大咖分享文字版残缺内容可见下文

首先介绍 Alluxio 作为分布式缓存减速大数据计算的应用场景。咱们事业部存在多个数据处理与数据分析业务，这些业务散布在不同的平台。应用 GreenPlum 数据库的数据处理业务基于批处理存储过程实现数据加工，对计算工夫有严格的要求，有明确的 deadline。这些业务遇到的次要问题是 GreenPlum 集群规模达到几十台时遇到扩容瓶颈，进一步扩大给业务运维工程师带来很大挑战；还有一部分业务基于 hive 运行 T + 1 批处理作业，遇到的次要问题是内存、CPU 等资源耗费比拟大，并行度不高，跑的速度比较慢；还有一些传统统计业务是跑在 Oracle 上，Oracle 单机跑的成果不是特地好，并且 Oracle 比拟贵，一台小型机可能就要两千多万，业务方冀望能有其余数据分析平台代替 Oracle。

过后，咱们的课题是基于 Spark、Hadoop 这个开源体系，去做一个对立的计算平台，把上述三个引擎承接的业务全副接过来。咱们间接用 Spark + HDFS 遇到了一些问题：

首先，它的性能是没有方法满足 GreenPlum 承载的生产业务，因为 GreenPlum 是 MPP 数据库，等同体量下它会比 Spark 要快很多；

其次，GreenPlum 承载的业务中存在伴生的交互式查问的场景，同样性能也是没有方法去满足的。

接着，对于一些批处理的业务来说，Spark + HDFS 比拟欠缺稳定性，批处理的业务每一次工作周期会有几千、几万个 SQL 去做迭代计算，工作如果常常失败的话，没有方法很好地在那之前保障去实现。

所以，为了减速 Spark 计算，咱们引入了 Alluxio 来减速数据的读写性能，进步数据写入的稳定性，以及接管 Spark Cache 后晋升 Spark 作业的稳定性。这是咱们一开始采纳的架构，数据编排在咱们的整个架构中的定位是缓存减速层。

具体看一下应用案例，如果拿减速迭代计算来说，咱们会把 Sink 间接写到 Alluxio 上，而后下一个 SQL 的 Source 去读这个 Sink，把 Source 和 Sink 之间的串联交给 Alluxio 的缓存去做，这样能够比较显著晋升整个 pipeline 的稳定性。因为不须要再和磁盘交互，能够极大升高磁盘压力。而通过内存，pipeline 的稳定性失去了比拟好的改善，通过间接读取内存会进步整个 pipeline 的运行速度。

第二个应用案例，是咱们通过 Alluxio 去共享整个 Job 之间的数据，而防止应用 Spark Cache。通过 Spark Cache 形式会对整个 Executor JVM 造成比拟大的压力。性能测试结果表明在数据量达到肯定规模的状况下，Spark Cache 的性能是要比 Alluxio 差一些。而且 Alluxio 随着 Spark 两头数据的增大，它对性能的影响是能够预测的，是线性而不是指数性上涨的。所以说，咱们抉择用 Alluxio 做两头数据的共享层。

为了加强数据读取的性能，能够显示的为每个门路去配置正本浮动范畴。而且 Alluxio 还反对了数据预加载的性能 –distributedLoad. 这个在 2021 年的时候，社区也是花了很多的精力在下面，目前是做的非常欠缺的工具了。咱们能够在执行一些固定工作之前，提前先把数据加载到内存。这样能够进步整个 pipeline 的运行速度。此外，Alluxio 还反对一些内存操作工具，比方 pin 和 free，这样的话能不便咱们更好地去治理内存。就是依照咱们既定的一个 pipeline 能够使整个内存布局失去最好的优化。

接下来是跟 Alluxio 数据编排 Policy 无关的例子。比方咱们一个 Spark 工作去读一个数据，它可能会在每个 worker 上都拉起一些正本，比方重复使用的一些数据。这种状况可能会迅速把缓存占满。对于这种状况，Alluxio 能够提供一个叫确定性哈希的策略。这个策略能够使咱们在固定的某几个 worker 下来读。这样能够把整个集群的正本数加起来，能更无效地去应用空间。

除此之外，针对大量场景，它还反对一些跟负载平衡相干的策略。比方最高可控策略，它会抉择整个集群内空间残余量最大的一个 worker 去读。这样能够使所有 worker 的应用比拟平衡。然而，它也有一些问题，当大量 Alluxio Client 在 Spark Executor 这边如果大量去挤兑一个 Alluxio Worker 的话，那么可能会导致这个 worker 的使用量霎时打满，呈现性能降级的状况。

针对这种状况，咱们能够去抉择一个轮循策略，在若干有残余量的 work 之间去轮循应用，这样能够比拟好地去实现集群的负载平衡。

从总的应用成果来看，Alluxio 还带来了比拟大的性能与稳定性的晋升。这里是一个比拟典型的 Spark Task 统计，Alluxio 对整个 GC 的工夫优化，还有整个工作总耗时的优化的收益是比较显著的。它最大的长处是能够显著升高每批次 Job 的重算概率，从而使整个过程更加稳固，更加可预测。

最终成果是咱们从之前 GreenPlum 迁徙过去的外围业务的规模曾经有靠近 70 倍的增长，并且承接的用户数相比之前进步了 100%，业务总体提速了 26 个小时。交互式查问业务目前日常数据曾经达到 60TB，如应用 Spark 单表 2.5tb 数据，查问耗时也是分钟级别。原先 Oracle 业务迁徙到 Spark 后能够做用户级的计算，这对于他们来讲是具备很大的价值。

接下来是咱们针对集群持续倒退的特点，做了在存算拆散方面的一些建设。存算拆散的背景大略是什么样的？

这次要是跟整个集群的倒退有肯定的关系。首先在咱们这边的平台建设是跟着业务走。随着业务快速增长，会呈现资源碎片化的状况。如图所示，第一年新建一个机房，咱们占用了一部分机架，其余业务或部门也会占用一些机架。到第二年的时候，第一年的机房就满了，第二年新建的机房大家能够各自去申请一些。这就导致整个机器不具备连续性，可能会跨机房，甚至可能会跨楼，有时候甚至还会跨数据中心。与之随同的就是业务快速增长，基本上处于逐年倍增的状况，而且资源申请周期十分长，至多须要一年的工夫能力交付，最初导致的状况就是集群出现碎片化。

更为蹩脚的是在业务增长过程中，其实它的资源需要是不均衡的，次要是存储与计算之间的不均衡。

首先，一个客观事实是历史数据的存储需要是逐年递增的。之前业务只须要保留 1 至 2 个月的数据。然而当初因为一些历史的趋势剖析或是各方面测算，一些次要业务的数据须要保留 12 至 24 个月。业务数据每个周期之间的环比涨幅大略是 10%，涨幅大时甚至有 5～10 倍的状况，次要是跟业务逻辑变动相干。

其次，存储规模的涨幅大略是计算规模涨幅的 5 到 6 倍，这也是存储计算倒退不均衡的状况。

咱们应用了存算拆散的技术来解决这些问题。首先解决计算资源的问题。咱们向其余的业务租借了一个现有的集群，利用该集群闲暇的夜间实现数据加工作业。咱们在下面部署了一套 Spark，以及 Alluxio 和咱们集群的 HDFS 形成一套存算拆散的数据分析系统。为什么不在该集群部署 Hadoop？起因是租借的业务集群曾经搭建了一套 Hadoop，咱们不被容许二次搭建 Hadoop，也不容许去应用他们的 Hadoop。所以，咱们就用该业务集群的 Alluxio 去挂载咱们平台的 HDFS。挂载 HDFS 之后就跟咱们本人平台放弃一样的命名空间，这样看起来都是一样的，基本上做到用户无感知。

更具体的如此图所示，就是对于 2 个 Alluxio 来说，看到的 Path 都是一样的，都是映射到 HDFS 的一个 Path，所以用户认为这两个 Path 都是一样的。咱们在读写不同 Path 的时候，会让不同的 Alluxio 别离执行读写操作。比方近程 Alluxio 对 Path1 是只读的，它会去写 Path2，本地 Alluxio 会写 Path1，但只会去读 Path2，这样就防止了两个 Alluxio 相互之间抵触。

在具体落实计划上，咱们还应用了一些本人的设计，来防止存算拆散会遇到的一些问题。

首先，咱们在近程业务集群这块，是基于 RocksDB+Raft HA 的形式来解决没有本地 HDFS 时 Alluxio HA 元数据操作性能的问题。因为咱们的 HDFS 在咱们的集群，两头有肯定的网络耗费。如果咱们间接还是采纳原来的 zookeeper ha，首先咱们须要在他们的集群搭一套 zookeeper ha，以及把元数据放在咱们本人集群的 HDFS 上，跨网络元数据交互可能会带来很多的不确定性。比方带宽打满了，或者是因为其余网络稳定的因素，会导致 Alluxio 自身的性能抖动，甚至可能呈现因为数据写入或者读取超时导致整个 Alluxio 挂掉的状况。所以，咱们抉择了 Alluxio 2.x 之后一直去建设去欠缺的 RocksDB+Raft HA 的形式来解决这个问题。

其次，咱们在业务集群这边因为要满足所有两头数据的存储，晋升整个计算性能，所以咱们应用 HDD 作为存储介质。Spark 作业的两头过程数据间接存储在缓存磁盘里，不会与 UFS 有任何交互，所以对于用户来说，这种模式的性能是不受影响的。

第三，最终后果还能够长久化至集群。因为最终后果的数量也不是特地大，所以它的耗时还是能够承受的。最初对于用户来说，他可能须要跨集群部署工作，咱们是在租借的业务集群之内搭建了一个 Dolphin Scheduler Worker，通过 Dolphin 的调度策略，帮忙用户把他的特定工作起在这个 Worker 下面。通过 Worker 的抉择来管制它提交到不同的集群。对于用户来说只是配置上做了变更，作业提交入口以及治理入口都是雷同的，解决了跨集群作业管理的问题。

实现计算混合部署之后，咱们又接到了大量的数据存储需要。然而咱们的集群短时间内没有方法扩容了，所以咱们申请了一批大容量存储，而后把大容量存储 mount 到 Alluxio，将历史数据自动化降级到大容量存储上，查问的时候就经由 Alluxio 通明拜访。咱们会把前 2 个月至前 12 个月的历史数据降级到大容量存储上，本地集群只保留最近几个月会频繁参加计算的数据。对于用户来说，拜访的门路跟之前还是一样的，咱们通过 mount 形式屏蔽了历史数据分层治理的差异性。对于咱们的益处是单位服务器的存储容量显著进步了，大容量存储能够独立扩容，对于咱们来说缓解了很大的存储压力。以下是咱们做完存算拆散当前的实际效果。

首先，某外围用户租借算力占平台调配算力的 82%，这个是比拟大的晋升。承接新业务应用租借算力占比达到 50%，Alluxio 治理 ETL 过程数据达到 148TB，算是十分宏大的数字了。因为 Alluxio 其实作为缓存来讲并不会去治理特地大量的数据。治理 100 至 200TB 这个数据量，咱们跟社区一起做了很多工作，包含 worker 启动超时等优化，以满足两头数据存储的需要。独自扩容的大容量存储给咱们带来的益处是单台服务器的存储容量晋升 5 倍，计算集群采纳的计算型服务器存储容量比拟小，大容量存储单台机器就能存储 90TB 数据，服务器台数雷同的状况下，容量晋升比拟显著，所以历史数据存储显著升高，扩容老本是升高了 83%。

当集群向后持续倒退的时候，咱们引入了更多的计算引擎来适配更多的业务场景以失去更好的成果。其中比拟典型的场景是咱们在一个平台上同时提供 Spark 和 Presto，Spark 次要用于 ETL，Presto 提供即席查问服务。它们共用 Alluxio 时会遇到一些问题：首先，Alluxio System Cache 不反对 Quota，没有方法隔离 Spark 跟 Presto 之间的用量，因为 Spark ETL 作业写入的数据较大，数据间接写入 Alluxio 作为 pipeline 下一个节点的读取减速。这种状况下内存冲刷比拟频繁，会一次性占用较多的内存。这样 Presto 刚实现数据加载，想查数据的时候发现缓存中没有了，Presto 查问的缓存利用率不是特地高。

第二个状况是一些用户应用 TensorFlow 做自然语言解决或者工夫序列剖析的 AI 计算。在 AI 计算之前，用户首先基于 Spark 做分布式 ETL，而后想把 ETL 后果间接拿给 TensorFlow 应用，在这种状况下，用户很难把分布式的数据和本地数据分割到一起。第三方框架比方 TensorFlow on Spark 个别都会封装一些规范模型。用户应用的模型不是支流模型，但实际效果较好，这种状况没有方法套用现用的第三方框架，间接将 Spark DataFrame 转换成 TensorFlow 的数据模型间接应用。这样 TensorFlow 还是一种读取本地文件的模式，就是不是很好的能把 Spark 与 TensorFlow 联动起来。

针对应用案例方才讲到的一些问题，咱们做了一些改良。首先，Presto 这边咱们放弃了应用 Alluxio System Cache，而是应用 Alluxio Local Cache 缓存数据，这样跟 Spark 应用的 Alluxio System Cache 进行隔离。咱们会为每个 Presto Worker 去开拓一个独立的缓存。这个缓存是放在 Ramdisk 下面，官网举荐放到 SSD 里边也是能够的。缓存不占用 Presto Worker 的 JVM 空间，不会对 GC 造成额外负担。除此之外，因为咱们有一些磁盘场景，所以跟社区一起欠缺了基于 RockDB 的缓存实现。以上是咱们在缓存隔离上做的一些设计。

在 AI 这边，咱们利用 Alluxio Fuse 买通了 ETL 与 AI 训练和推理。Alluxio Fuse 首先做了本地文件跟分布式系统挂载，这样就能够把分布式文件映射到本地文件。而后用户能够间接应用读写本地文件的形式操作一个分布式系统中的文件，与笔记本上开发的读写本地代码的逻辑完全相同。这样就胜利地买通了 Spark ETL 跟 TensorFlow 的计算。Alluxio 目前是提供两种 Fuse 挂载模式，首先提供为每个 Worker 创立一个 Fuse 的挂载目录。这种形式能够更好地进步数据拜访性能，咱们目前应用的是这种模式。还有一种是独自起一个 Fuse 过程，这样就不须要在本地区部署 Alluxio 集群，这种形式有助于灵便部署。大家能够依照本人须要去抉择不同的部署模式。

目前应用的成果，Presto 因为引入了 Cache，查问性能晋升了 50% 左右，相比 OS Cache 更加稳固。如果咱们都用 OS Cache 性能是最快的，但因为集群撑持的是数据密集型的负载，所以 OS Cache 不是特地稳固，容易被刷下去。相比没有 Cache 减速时，它的查问性能有不错的晋升。大数据 AI 集成方面，用户能够用 TensorFlow 去训练推理的代码不须要做任何改变，就能够跟 Spark ETL 做集成，目前首批业务是实现了 60 万用户的接入，整个过程基于 Dolphin Scheduler 实现大数据 +AI 全流程自动化调度，用户的运维复杂度非常低。这里帮 Alluxio 的邱璐做个广告，她目前是 Alluxio Fuse 的负责人。Alluxio Fuse 曾经在微软、Boss 直聘、哔哩哔哩、陌陌等公司的生产训练中实现了部署。

现状一，目前联通在鼎力推动数字化转型，之前很多跟数据分析没有关系的业务，如一些传统业务，也想做数据分析。利用之前积淀的数据，想做预测或者是起因定位。指标用户更多是业务工程师，更喜爱关系型数据库以及 SQL。

现状二，不同的业务之间同时须要拜访平台经营的私有数据，以及拜访、治理业务公有数据。这些公有数据的业务口径由业务方制订，并依照本人的凋谢策略向其余业务方提供。因而共享公有数据须要数据提供方受权，私有数据只须要平台受权就能够。

现状三，服务器资源增量目前低于业务的需求量，因为数据分析需要上涨很厉害，而且不可预测，很多需要不在总体规划里。与此同时，业务自有服务器在闲暇时间段负载比拟低，个别次要是白天比较忙。这样的话，他们的现有资源其实是可能去撑持新增的一些数据分析业务的。

所以，思考到平台在扩容的时候是没有方法跟上业务的倒退脚步的。为了能尽快满足业务数字化建设需要，咱们打算为这些业务做私有化部署，基于 Spark 做私有化部署的时候，咱们遇到一些问题。

首先，如果依照咱们本人规范的模式为每个用户去独立部署一个 Spark on Yarn 的话，治理复杂度就太高了。咱们可能会管很多个集群的 Spark on Yarn，这样的治理老本是无奈撑持的。另外，局部用户服务器曾经部署了 HBase on Hadoop，这些集群不容许咱们部署 Hadoop 也不容许咱们在下面部署 Hbase，而且不能应用已有的 Hadoop。这样就给 Spark 体系减少了很多难度。并且，业务用户心愿应用这种纯 SQL 剖析数据，如果是这样，咱们会须要增加相似于 Kyuubi 的工具，咱们须要为了满足一个需要增加很多组件，这样的话多个集群的治理复杂度会十分高。还有一种形式就是咱们不采纳 on Yarn 的形式，采纳 Spark Standalone 模式，其实部署起来绝对还好，只应用 Spark + Alluxio 还不错。

但这种形式的问题是，如果咱们采纳 Spark per job 作业模式，它的并发度是无限的。如果咱们给一个通用值，它并发度是一个查问起一个 job，并发度是比拟低的，可能同时只能并发几个。而且 Spark 配置复杂度偏高，对于 SQL 用户来说不是很敌对，还须要配置内存大小，executor 数目，或者 Dynamic allocate 限度参数。如果不采纳 Spark per job 采纳单 Session 的模式，又没有方法在多任务间做优先级隔离，无奈对一个业务的多个 SQL 进行编排。

咱们的思路是心愿应用 Presto+Alluxio 做一个轻量级的数据分析，基于 Presto Iceberg native connector，间接去操作存储在 Alluxio 下面的 Hadoop catelog 表，只须要加 Presto + Alluxio 两个组件，咱们就能够实现整个 ETL 的过程。咱们用了两套 mount 零碎：第一套是比拟传统的 Alluxio 间接去 mount 平台的 HDFS；第二套是 Alluxio structure data service（结构化数据服务）mount hive 表，对于用户集群来说，他看到的 hive 表跟平台这边的 hive 表是一样的。Mount 的益处是能够将数据通明地映射到 Alluxio 命名空间之内，通过 Hive Table load 提前把数据加载至 Alluxio 缓存中，减少数据读取性能。所有的两头过程只须要 Presto 以 must cashe 的形式写入 Alluxio 本地，加工完之后，就能够把这个数据最初的后果数据写回平台的 hive。整个架构比较简单的，只须要两个组件，每台机只有起两个过程，没有额定的累赘。

而且用户能够通过 JDBC 或者是 Command line 两种模式拜访 Presto，并且用户能够通过选择性的 persist Iceberg Hadoop table 来受权给其余集群用户拜访两头数据。通过 Alluxio 的对立命名空间设计，用户看到的 hive table、Iceberg table 是完全一致的，实现了多个集群之间的通明治理。

在这个轻量级数据分析栈内，咱们只须要在用户集群搭建两个组件就能够满足需要。因为用户基于 Presto 以纯 SQL 的形式实现数据分析，体验比拟好。目前咱们用户喜爱用 JDBC 的形式去连贯，所以临时不须要提供更多可视化工具。如果须要，只有在咱们现有的可视化工具里配置链接就行。Alluxio mount 平台 HDFS 用于私有化数据共享，SDS mount 平台 Hive 用于共有数据拜访及性能加，基于 Presto Iceberg connector 的 hadoop catalog mode 这种模式，能够采纳只写缓存的形式在本地实现 ETL。Alluxio 全副应用的挂载磁盘的形式来保障缓存空间足够包容数据分析两头数据，最终数据长久化至平台 HDFS。Alluxio 在写入的时候会应用三正本的策略，保障缓存数据的可用性。