欢送来到【微直播间】，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正本策略保障缓存数据的可⽤性，可挂载独⽴存储集群长久化存储需⻓期保留的剖析数据。

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

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

01. 在缓存减速方面的利用

首先介绍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后能够做用户级的计算，这对于他们来讲是具备很大的价值。

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

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

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

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

首先，一个客观事实是历史数据的存储需要是逐年递增的。之前业务只须要保留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%。

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

当集群向后持续倒退的时候，咱们引入了更多的计算引擎来适配更多的业务场景以失去更好的成果。其中比拟典型的场景是咱们在一个平台上同时提供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直聘、哔哩哔哩、陌陌等公司的生产训练中实现了部署。

04. 轻量级剖析相干摸索

现状一，目前联通在鼎力推动数字化转型，之前很多跟数据分析没有关系的业务，如一些传统业务，也想做数据分析。利用之前积淀的数据，想做预测或者是起因定位。指标用户更多是业务工程师，更喜爱关系型数据库以及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在写入的时候会应用三正本的策略，保障缓存数据的可用性。

分享嘉宾

张策 联通软件研究院 大数据工程师
嘉宾介绍：毕业于北京交通大学，2018年退出联通软件研究院，次要负责大数据平台的建设与保护，同时在Alluxio社区负责PMC Member。

想要获取更多乏味有料的【流动信息】【技术文章】【大咖观点】，请关注【Alluxio智库】：