阿里妹导读：数据湖可以很好地帮助企业应对当前数据场景越来越多、数据结构越来越复杂、数据处理需求越来越多样化的成绩。阿里云从2018年起就开始布局数据湖，推出了云原生数据湖分析Data Lake Analytics（DLA），从数据湖管理（帮助客户高效管理建立数据湖），Serverless Spark（提供高性价比的大规模估计），Serverless SQL（提供高性价比的在线交互式分析）三个方面帮助客户挖掘数据价值。本文分享相关手艺挑战及解决方案。
一 数据湖的机遇与挑战
数据湖可以很好地帮助企业应对当前数据场景越来越多、数据结构越来越复杂、数据处理的需求越来越多样化的成绩。Gartner 2020年发布的报告显示目前已经有39%的用户在利用数据湖，34%的用户考虑在1年内利用数据湖。从2018年起，阿里云就开始布局数据湖，推出了云原生数据湖分析Data Lake Analytics（简称：DLA）产品，结合对象保存OSS一起，从弹性扩展、按需付费、效劳化等方面打造有竞争力的产品。通过采用保存估计分离模式，保存和估计完全按需付费，用户只需要为实际产生价值的估计买单；DLA深度定制云原生弹机能力，实现功课级弹性，一分钟可弹300个节点。云原生数据湖分析DLA从成本、弹性、交付能力方面相对传统数据分析方案，获得了较大的提升。
在云上也已经有数千家企业利用数据湖效劳满足数据应用，如友盟+ 的U-DOP数据开放平台根据友盟+多年沉淀的大数据领域经验，形成了以APP、WEB、小程序、广告营销、社会化分享和推送为基础的多端主题数据的采集和处理能力，为客户形成规范化的多端数据资产。尤其是利用了数据湖的弹机能力，应对了双十一峰值期间DAU暴涨的业务变化，例如，通过实施分析搜索关键词的变化，改变首页广告推荐信息，对活跃用户和下单用户分不同渠道的分析梳理，及时调整优惠策略，以吸引更多的客户新购及复购等。数据库与大数据一体化趋势在加强，传统的数据库利用者与DBA，也可以利用及维护大数据系统，一体化解决大数据的成绩。具体在DLA体现在数据库的数据无缝与大数据结合，比如DLA提供的一键入湖建仓的功能；DLA Serverless SQL兼容MySQL协议及部分语法。DLA Serverless产品形态，开发者只需要利用平台接口即可，如利用DLA SQL的JDBC接口提交SQL，利用DLA Spark的OpenAPI提交Spark功课。开发者只需要关注业务逻辑本身，不需要关心平台的复杂逻辑。原来利用开源组件遇到的很多痛点都可以迎刃而解：入门门槛高Hadoop生态往往需要多个组件同时利用，比如Yarn、HDFS、Spark、Hive、Kerberos、Zookeeper等等。开发者需要了解所有组件，因为开发过程中这些组件往往都会接触到。开发维护困难开发者在开发过程中会遇到各个组件带来的利用成绩，开发者需要了解所有这些组件以应对这些成绩。这些加重了开发者的利用负担。稳定性难以保障开源组件本身都必须经过细致的调参并加上合适的硬件资材配置，才能良好运行，并且需要修复不少BUG，出现成绩没有兜底。缺乏适应云的机能优化云上的OSS、PolarDB等组件都是云原生的组件，开源组件对这部分的改造适应不足，没有充分挖掘出更高的机能。DLA从数据湖管理（帮助客户高效管理建立数据湖），Serverless Spark（提供高性价比的大规模估计），Serverless SQL（提供高性价比的在线交互式分析）三个方面帮助客户挖掘数据价值。整体架构如下所示。接下来，本文将从这三个方面，分别讲述相关手艺挑战以及解决方案。
二 如何管理与建立数据湖？
数据湖中数据难以管理主要体现在两个方面：
已经在数据湖保存OSS上面的数据如何高效的建立元数据。
非OSS数据如何高效的入湖建仓。
数据湖管理相关的主要功能包括元数据管理、元数据发现、数据库入湖建仓、实时数据入湖。接下来重点介绍“海量文献元数据自动建立手艺”和“入湖建仓数据管理手艺”两个关键手艺。
1 海量文献元数据自动建立手艺
当以OSS作为数据湖保存，保存的数据文献具有以下几个特性：
格式丰富：包括CSV、Text、JSON、Parquet、Orc、Avro、hudi、Delta Lake等格式，其中CSV、Text又包含多种自定义的分隔符等。
文献数在百万级别：OSS的扩展性及性价比较好，用户保存在OSS的文献会是百万级别。
文献动态上传：保存在OSS上面数据文献具有动态持续上传的特性，新的文献如何快速增量修改元数据。
为了高效的为OSS上面的海量数据建立元数据，阿里云DLA提出并实现了“海量文献元数据自动建立手艺”。具体手艺如下图所示，核心解决了：万表万分区识别、增量感知更新元数据两个成绩。
万表万分区识别用户OSS上面的文献数量会到百万级别，这些文献不仅格式不同，比如JSON、CSV、Text等，而且同一种格式由于业务属性不同具体的Schema字段也不一样。该手艺通过文献Schema识别器搭配文献分类器支撑自动生成万表万分区。其中文献Schema识别器比如针对JSON单文献识别到0.15s、CSV单文献识别0.2s，搭配可插拔的智能采样策略及分布式策略，百万文献的Schema识别可以到分钟级别。文献分类器通过树的结构进行聚合、剪枝、压缩，百万级别文献的分类识别需要290ms左右。增量感知更新户会往OSS上面持续不断的上传文献，元数据自动建立既要把属于已经创建表的文献Schema变化更新到已有的表，同时对独立新增的文献创建新的表。这里一方面“文献Schema识别器”通过获取OSS上面文献的增加、删除变化对变化的文献进行识别，同时“文献分类器”对新增的文献Schema和已经创建的表进行对别生成变化策略，目前支撑增加分区、增加字段、字段不更改、不感知文献删除4种策略，后续可以持续添加新的策略。
2 入湖建仓数据组织手艺
把DataBase及消息日志效劳的数据统一保存到数据湖保存OSS进行管理，能够满足估计加速、建立数仓归档、冷热分离等业务需求。DLA的入湖建仓数据组织手艺包括三种数据组织管理模式：镜像模式、分区模式、增量模式，三种模式能够搭配友好支撑这些业务场景。
镜像模式每次全量同步源库一个Database下面所有表的数据到数据湖保存OSS之上，同步期间可以做到源库负载增加控制在10%以内。这里主要利用了全局统一数据分片调度算法。保持数据湖的数据和源库一致。分区模式面对归档场景支撑按天全量及增量同步源库数据到数据湖，并以时间分区的方式进行组织，方便归档管理。这种模式能够做到小时级别的时间延迟。增量模式这种模式通过行列混存手艺、commitlog及index管理手艺，可以做到T+10min的数据入湖。其中通过delta的增量文献及异步compaction手艺解决了小文献成绩；通过delta增量文献及索引手艺可以支撑Database场景更新、删除日志的增量实时写入；通过commitlog的方式记录分区文献的映射，解决百万分区在传统Catalog管理模式机能慢的成绩。
三 云原生数据湖平台需打通云基础设施
DLA整体是一个多租户的架构，分Region部署，每个Region的用户共享一套控制逻辑。虚拟集群VC是逻辑的隔断单元。平台支撑 Serverless Spark、Serverless SQL等引擎，打造云原生效劳。
如上图所示，平台主要面临的挑战有：资材高效供给、安全防护、造访数据源的带宽保障。
1 资材高效供给
云原生平台基于阿里云的底座ECS&ACK&ECI，与阿里云IAAS资材大池打通，本Region跨可用区资材调度，保障资材的供给。支撑1分钟弹300个节点，单客户在大Region 5w估计节点资材的保障。
2 安全防护
用户可以写任意的代码平台内运行，可能是故意恶性的攻击行为，如果没有任何保护，则平台面临安全危险。在安全方面，我们通过如下手艺保障安全性：
一次密钥：每个Job任务都会去TokenServer申请临时的Token，Job失效Token会过期，如果存在攻击行为，则平台会直接让Token过期，则造访Meta等效劳会被拒绝。
预防DDOS&注入攻击：所有的造访平台效劳的请求，都会对接到安全防护中心，安全防护中心检测有任何攻击或者注入行为，直接关闭网络端口。
估计容器隔断：估计节点间采用阿里云自研的安全容器，容器本身可以实现VM相同的安全隔断级别。
安全白名单：用户互相之间的网络是完全隔断的。
ENI虚拟网卡：打通VPC需要配置自己账号下的安全组和虚拟交换机（VSwitch），配置之后结算节点容器会分配用户VPC对应VSwitch网段的的IP，并挂载用户的安全组。
3 高吞吐网络带宽
造访OSS效劳是通过高吞吐的带宽效劳。利用ENI手艺造访自持VPC，跟在自持VPC内ECS上部署估计引擎造访自持VPC内数据一样，带宽同样是VPC内网带宽。
四 Serverless Spark效劳的手艺挑战
Apache Spark是目前社区最为流行的开源引擎，不但具备流、SQL、机器学习以及图等估计能力，也可以连接丰富的数据源。但是，面对数据湖场景，传统集群版Spark方案，除了面临前面提到的数据管理困难、运维成本、估计资材弹机能力不足、企业级能力弱等成绩外，还面临造访OSS的机能不佳、复杂功课难以调试等成绩。借助于第二章节提到的数据湖管理机制，可以很好地解决数据管理难题。借助于第三章节提到的多租户安全平台，DLA Spark实现了全新的云原生Serverless产品形态，很好地解决了弹性成绩、运维成本成绩以及企业级需求成绩。本章节对Spark造访OSS的机能优化以多租户UI效劳做进一步展开。
1 Spark造访OSS优化
社区版本的成绩
开源版Spark造访OSS数据默认采用Hadoop FileFormat接口直接对接OSSFileSystem实现。该方法在实践中发现存在机能差，一致性难以保证等成绩。（1）Spark造访OSS机能差核心原因在于OSS KV模型跟HDFS文献树模型的差异。FileFormat算法最初设计是基于HDFS文献系统，然而对象保存如OSS，为了解决扩展性，本质上采用的是KV模型。KV模型相对于HDFS文献系统差异较大，比如RenameDirectory接口，在HDFS中只是指针操作，但在KV中，需要将所有子文献和目录的KV执行Rename，机能开销很大，并且保证不了原子性。Hadoop FileOutputFormat在写入数据的时候先写到临时目录，最后写入最终目录，临时目录到最终目录的过程中需要做文献树合并，合并过程中有大量Rename操作。（2）一致性难保证FileFormat v1算法中，合并文献树操作全部在AppMaster单点执行，效率非常低，尤其是动态分区场景。为了解决AppMaster单点，社区提供了算法2，其核心思路是将合并过程并行到Task中执行，在机能上会有一定的提高，但是，如果Job执行失败，部分成功的Task会将数据写入最终数据目录，导致脏数据成绩。
Spark OSS造访优化
（1）基于MultipartUpload的FileOutputFormat实现针对Spark造访OSS的特点，我们全新实现了Hadoop FileOutputFormat接口，如上图所示。算法的改进重点在优化合并操作，合并的核心是解决文献何时可见的成绩。OSS提供MultipartUpload接口，也就是断点续传功能，文献可以分片上传，上传没有结束，分片文献是不可见的。借助该特性，我们可以让Task直接将数据写入到最终目录，只有功课成功才让文献最终可见，该方法不用先写入临时目录，也就大大减少了元数据的操作。对于执行失败的Task写入的临时分片，我们在功课结束时，执行Abort操作，就可以将其删除，这也就降低了空间占用。针对Spark典型ETL Benchmark Terasort，在1TB输入数据量的情况下，DLA FileOutputFormat执行时间缩短62%，机能提升163%。而针对动态分区场景，社区算法1运行失败，算法2可以执行成功，DLA FileOutputFormat算法相比算法2机能还要进一步提升124%。（2）OSS元数据CacheSpark读取OSS的过程中，在ResolveRelation阶段，Spark会遍历OSS的目录，解析表结构和分区结构，以及解析Schema，该过程中同样会有大量元数据操作，并且同一个OSS 对象的元数据会被造访多次。针对该成绩，我们实现了对OSS元数据的缓存，第一次造访到的OSS对象元数据就会被缓存到本地，后续如果造访该对象直接读取本地缓存。这种方式可以最大限度降低对OSS元数据的造访。Cache机制可以让ResolveRelation有1倍左右的机能提升，针对典型的Spark查问场景，该机制整体可以提升60%的机能。
2 多租户UI效劳
UI效劳对于开发者来说至关重要，开发人员依赖UI效劳进行功课调试，以及生产功课的成绩排查。好的UI效劳可以很好地加速研发效率。
HistoryServer的痛点
Spark社区提供HistoryServer提供对Spark历史功课的UI和日志效劳，在实际应用中遇到诸多痛点，典型如下：（1）Eventlog空间开销大HistoryServer依赖Spark引擎将运行中的Event信息全部记录到FileSystem中，然后后台回放并绘出UI页面。对于复杂功课和长功课Eventlog量较大，可以达到百GB甚至TB级别。（2）复杂功课和长功课不支撑复杂功课或者长功课的Eventlog很大，HistoryServer会解析失败，甚至OOM。再加上空间开销大的原因，用户一般都只能关闭Eventlog。（3）Replay效率差，延迟高HistoryServer采用后台Replay Eventlog的方式还原Spark UI，相当于把Spark引擎的事件全部重放一遍，开销大，会有延迟。特别是功课较多或者较复杂的情况下，延迟可达分钟甚至十分钟级别。
DLA多租户SparkUI
SparkUI效劳是DLA平台自研的多租户UI效劳，针对社区方案做了深度优化：（1）去EventlogDLA Spark去掉了Eventlog依赖，在功课结束的时候，Spark Driver只是dump UI的Meta到OSS，保存功课结束前的页面元信息。这部分信息只是相对于Eventlog来说，会大大减少，即使非常复杂的功课也只有MB级别。UiServer读取OSS上的UI Meta，将其反序列化出来即可展示SparkUI页面。（2）UIServer水平扩展UIServer主要负责解析历史UI Meta和提供Stderr和Stdout日志效劳，是轻量化，无状态的，可以实现水平扩展，进而支撑万级别客户同时在线效劳。UIServer URL采用加密token作为参数，token代表的用户身份，功课id，UIServer据此实现多租户效劳化。（3）本地日志自动滚动对于长功课而言，Stderr或者Stdout信息会随着时间增加累积，最终甚至可能打爆磁盘。DLA Spark安全容器内置后台进程，实现日志滚动，保存最有价值的最近一段时间的日志。
五 Serverless SQL效劳的手艺挑战
DLA Serverless SQL是基于目前托管于Linux基金会之下的PrestoDB打造的云原生数据湖引擎，Alibaba同时也是Presto基金会成员之一，一直在贡献优化Presto。PrestoDB引擎本身具有优秀的特性：
全内存估计带来的极致速度。
支撑完整SQL语义带来的强大表达力。
易用的插件机制使得我们可以对任何数据源进行关联查问。
强大的社区使得我们利用之后没有后顾之忧。
不过社区PrestoDB是单租户的一个引擎，它假定你是在一个公司内部利用，因此算力隔断、高可用等等方面没有过多投入，这使得要直接利用它来作为云原生效劳的引擎存在几个成绩：
一个用户如果提交大量大查问将可能占用集群所有资材，导致其它用户无法利用。
单Coordinator使得整个效劳的可用性无法得到保证。
我们做了一系列的优化、改造使得它可以云原生的形态效劳所有的用户，今天着重介绍多租户隔断手艺以及多Coordinator两个主要的特性。首先我们看一下DLA Serverless SQL的整体架构：
我们在核心的PrestoDB集群周边建设了诸如接入层、统一元数据等等效劳来使得用户可以用得稳定、用得便利，下面我们将在多租户隔断手艺和多Coordinator手艺的介绍中详细剖析。
1 多租户隔断手艺
PrestoDB原生是有资材组的支撑，它可以支撑在不同资材组间做一定程度的CPU、内存的限制，但是它有一些成绩使得我们无法基于它来实现估计力的隔断：
全局调度层面：即使一个租户利用了过多的估计力资材也不会及时被惩罚，只有新查问会被Block。
Worker调度层面：所有租户的Split是在同一个队列里面进行调度，一个租户如果有过多Split会影响其它租户。
我们的估计力多租户方案如下：
我们在集群中引入了一个ResourceManager的模块用于从所有的Coordinator收集所有租户的资材利用信息，ResourceManager把收集到的资材利用信息跟我们预设的估计力的阈值进行对比，估计出哪些租户应该被惩罚，然后把这个惩罚信息通知到所有的Worker。Worker在进行调度的时候会参照ResourceManager通知过来的惩罚信息决定哪些租户的查问得到调度，哪些租户的查问不进行调度。这样不同的租户之间算力就会得到隔断，我们测试了如果有一个租户过量利用资材，它会在最长1.3秒之内得到惩罚，从而释放资材给其它租户，而社区默认版本的“惩罚”要等到租户所有的查问执行完成才会到来。只有元数据和估计力得到隔断，我们才能放心用一个集群来效劳我们所有的用户。
2 Multi-Coordinator手艺
社区版本的Presto里面，Coordinator是一个单点，它会带来两个方面的成绩：
可用性隐患: 一旦Coordinator宕机、整个集群将不可用达5到10分钟。
无法实现无缝升级，升级过程中影响所有用户的查问利用。
我们采取了如下的架构方案：
首先我们在Presto的Coordinator之上放置了一个新的FrontNode模块，让用户连接到这个模块，而不是直接连接到我们底层的Coordinator，这样我们底层到底有多少个Coordinator，现在哪个Coordinator在给用户提供效劳都对用户完全透明，这样架构上就比较灵活，从而方便我们在底层对Coordinator进行扩展。FrontNode在接收到用户的查问之后会把请求按照Round Robin的方式发送给底层的多个Coordinator，这样多个Coordinator就可以分担压力，但是整个集群还是有一些全局的事情要有单个Coordinator来做，比如Presto的Worker状态监控、OOM Killer等等，因此我们引入了一个Zookeeper来做Coordinator选主的事情，选主之后主Coordinator的职责会跟社区的Presto类似：做全局的Worker状态监控、OOM Killer以及执行分配给它的查问；从Coordinator的职责则比较轻量级: 只负责执行分配给它的查问。如果其中一个Coordinator因为任何成绩宕机，Zookeeper会在秒级发现这个成绩并重新选主，用户受到影响的查问只要重试即可。而且我们正在做的一个尝试是做查问的自动重试，对于确定是系统原因造成的失败我们做自动重试，这样一个Coordinator对用户的影响将会很小。而有了多Coordinator的架构，我们要实现无缝升级就非常简单了，我们在升级的时候只要主动把某个Coordinator/Worker从集群中摘除，进行升级，升级完成再加入集群，客户可以毫不感知，因为在升级过程中始终有一个正常工作的集群在给用户提供效劳, 比如我们在升级从Coordinator的时候，整个集群情况如下：
通过诸如多租户隔断手艺、多Coordinator架构等等优化，我们基于PrestoDB打造了可以效劳所有的用户的阿里云云原生数据湖Serverless SQL引擎。
六 云原生数据湖端到端最佳实践
如上图方案所示，DLA提供了端到端的方案，面对OSS数据开放性带来的管理及入湖困难，DLA数据湖管理，帮助您一站式建立安全数据湖。
提供统一开放的Meta效劳对OSS数据进行管理，支撑库表权限。
利用元数据爬取功能，可以一键创建OSS上的元数据信息，轻松自动识别CSV/JSON/Parquet等格式，建立好库表信息，方便后续估计引擎利用。
一键将RDS/PolarDB/MongoDB等数据库的数据同步到OSS保存当中，搭建冷热数据分层的业务架构，对多源海量数据进行数据洞察分析。
支撑流式建立Hudi格式，满足T+10分钟的延迟要求，极大提升分析的端到端的延迟。
Serverless化SQL分析，帮助您即开即用数据湖。用户无需购买任何资材，即可运行标准的SQL语法查问数据。
支撑对数据湖保存OSS Cache加速，提升10倍的机能。
支撑RDS、PolarDB、ADB、MongoDB数据十种数据源的分析。
对比传统的Presto、Impala方案提升10x的性价比提升。
Serverless化Spark估计，帮助您自主玩转数据湖。用户无需购买任何资材，即可利用云原生的Spark效劳，支撑OSS 数PB的数据清洗、机器学习、用户可编程，玩转数据湖。
每分钟可弹出500个节点参与估计。
对比传统的自建Spark方案提升3x的性价比提升。
由于DLA涉及较多的手艺点，本文讲述了部分手艺细节，更多欢迎关注云原生数据湖分析DLA：https://www.aliyun.com/product/datalakeanalytics
