年度回顾 | 云原生数据湖分析DLA：新型基础设施再发力，数据湖谱

 

概  述

2020年黑天鹅事件不断出现，疫情给人们的生活也带来了改变。在后疫情时代，伴随着云原生技术的发展，企业寻求更加敏捷、更加灵活的数据分析方案，数据湖刚好满足这核心诉求。有不少同学问笔者，Hadoop与数据湖有啥区别？笔者认为，其一：数据湖分析支持的数据格式包括非结构化与半结构化。虽然HDFS可以存图片，但是一般还是有视频&图片的专门服务器，原因存储计算不分离情况下，大数据硬件存图片不经济；其二：数据湖往往跟云结合更加紧密，因为存储计算分离以后，存储与计算可以单独发展。计算可以跟业务系统错峰调度，再结合不同公司计算任务的差异，可以增强弹性能力。其三：数据湖的技术与数据仓库进一步融合，如Hudi支持数据实时写入、事务与更新。

 

阿里云云原生数据湖分析DLA，在这样的背景下诞生，历经两年的发展，充分结合云、Presto、Spark、Hudi等优势，构建出了新一代的大数据方案。目前DLA已经服务了数千客户，不少公司的核心数仓也是基于DLA；DLA也集成在友盟、CDN、DBS（数据库备份）、IOT、QuickBI等产品中，间接服务了数万客户；

 

我们也重视开源与商业合作，目前，DLA是Apache PrestoDB基金会的代表；与Alluxio达成战略合作，共同构建缓存系统；团队有数位Apache的Committer，一起参与贡献开源社区。

 

本文主要概括地讲述下阿里云云原生数据湖分析（简称DLA）为了应变分析之大变局，在2020年主要实现的一些事情。

 

云原生数据湖分析的基本架构如下： 

DLA分为 DLA Meta、DLA Lakehouse、DLA Presto、DLA Spark 四大模块。在20年我们重写了元数据模块，增加了元数据与数据源之间的同步模块，针对OSS可以发现元数据，简化用户的配置管理；在数据管理Lakehouse方向上支持了RDS MySQL实时同步到Hudi，目前正在产品化中；新增了DLA Serverless Spark模块，支持按照Job计费，重写了接入层，实现了多租户的UI，并且针对OSS做Rename等内核性能优化；DLA Presto改进了扫描版的稳定性，增强内核性能，实现了CU版本的产品形态，并且保持扫描量版本与CU版本统一架构。接下来分模块讲述：

 

二
DLA Meta

对比开源的Hive元数据，DLA Meta是兼容Hive meta的，支持云上15+种数据数据源（OSS、HDFS、DB、DW）的统一视图，引入多租户、元数据发现等能力。DLA Meta追求边际成本为0，免费提供使用的。

 

• 企业级权限管理：支持多账号的权限与隔离，可以简单的GRANT&REVOKE对子账号赋予权限，Meta会托管OSS与DB赋予的权限，DLA Presto与DLA Spark通过内部的API拿到相应的权限，访问OSS与DB数据库；
• 开放访问：通过OpenAPI可以直接拿到Meta的信息，客户自建的Spark集群也可以使用DLA Meta；
• 扩展性强：MetaServer是无状态的服务，可以扩展多个集群；在元数据存储采取的是多库存储，可以无限扩展；
• 元数据发现：支持OSS 数仓模式发现，SLS投递到OSS数据发现，OTS元数据自动同步。支持客户一键发现元数据，这些元数据也会自动维护。典型的场景是：用户的APP可以不断往OSS写新的Partition，元数据发现服务会自动同步Partition。

 

三
 DLA Lakehouse

数据湖有着巨大的低成本、扩展性的优势。但是在数据组织与维护方面，天然比数仓有着不足。不少客户通过代码维护一套数仓体系：基本流程为准备数据，再通过Spark&Hive清洗，构建离线的数据仓库。DLA目前在基于Apache Hudi实现DLA Lakehouse，主要目标是提供高效的湖仓，基本的架构图如下图所示：

此模块已经有不少客户使用，目前还缺乏产品化，是以方案提供。在接入层已经支持RDS MySQL通过DTS实时写数据到Lakehouse中，接入层全量&增量模块均是直接调用DLA Serverless Spark服务。

 

• 实时写入：支持 MySQL数据延期10分钟直接写入到OSS的，写入后，可以支持DLA Serverless Presto与DLA Serverless Spark访问。
• 自动合并小文件：支持小文件的自动合并，接入层对接的是DLA Serverless Spark服务，目前也正在研发弹性的Compaction机制。
• 支持多库多表：相对于社区支持单库单表，我们可以一次性把RDS MySQL实例内所有的库与表实时同步到OSS上，并一条链路支持超过5000+张表的同步。

 

目前Lakehouse发展比较快，内核模块Hudi我们也在跟社区保持紧密的合作，DLA也在加紧产品化中，提供在产品界面点按钮就可以使用的体验，并且不断优化数据源到链路到格式的性能。

 

四
DLA Serverless Presto

DLA Serverless Presto是基于Apache PrestoDB研发的，主要是做联邦交互式查询与轻量级ETL，2020年改造后架构如下：

• 提供独享集群：在扫描量情况下，客户不好评估成本，需要财务固定成本；一些如Cache、访问Hive、UDF等在扫描量无法实现；DLA推出了Presto独享集群版本。独享版本的资源是独享的，财务成本基本固定的（独享集群也可以按时弹性），比较适合大客户使用。扫描量版本比较实现查询频率比较低的客户使用。在独享集群版本中，我们核心提供了 如下能力：

DataCache：与Alluxio合作共同推出了DLA Presto的DataCache，具体机制参考：

https://developer.aliyun.com/article/781291，在IO密集类型中，查询性能可最高提升10倍；
分时弹性：扫描量是按照Query计费的，在独享集群下，也是可以弹性的。分时弹性就是用户可以设置时间段来付费；
特有的数据源：如支持Hive等数据源、Cassandra等数据源；
更快的性能提升：目前也在实现如Query Result Cache、Fragment Result cache、针对性算子下沉；

 

• 支持更多的连接器：过去一年我们新增支持了Hive、HDFS、KUDU、OTS ParallelScan、Cassandra、ElasticSearch、ADB PG、Oracle、Druid等；
• 稳定性改进：接入层打通底层ACK弹性调度、DLA网络管控、SLB管控等链路，实现被动宕机时从之前3分钟到3秒内快速恢复，主动业务发布时只中断1次连接、并在1s左右迅速实现连接切换等能力；Multi-Master实现Coordinator和Worker的优雅关闭，关闭时会等待所有SQL执行完，同时又不接受新SQL，使得我们在升级的时候从之前的用户SQL全挂，到现在用户的SQL可以不被影响，做到客户无感升级；算力租户隔离可以实时控制每个用户的算力，算力过度使用时会实时惩罚的机制，解决了大SQL会导致整个集群过载的问题；
• 易用性：SQL诊断界面，我们也在不断改进，也是接下来的重点改进方向。

 

未来，我们将充分与社区结合互补，不断提升性能，支持更多的功能，提供更加方便的诊断工具，做到云上的第一的联邦交互式查询引擎。

 

五
DLA Serverless Spark

Spark是最流行的大数据计算引擎，DLA支持Spark主要是为在湖上做大规模的ETL，并支持流计算、机器学习；比传统自建Spark有着300%的性价比提升，从ECS自建Spark或者Hive批处理迁移到DLA Spark可以节约50%的成本。DLA Spark架构如下图所示：

• 完全支持开源的Spark语法，独享的运行环境：DLA Serverless Spark完全兼容开源的Spark语法，支持Python专享的运行环境，支持开源的算法框架；
• 弹性，每Job每计费：传统的Spark都需要用户事先购买好集群，DLA支持无需购买任何的计算资源即可开箱使用Spark，兼容开源Spark所有的语法；
• 重写Serverless Spark接入层，保障Job的稳定性：对比Livy接入层，Livy存在较多的稳定性问题，比如：不能互相扩展，有单点问题，无法在DLA多租户环境应用；为此，DLA Spark组完全重写了Spark的接入层，力求保障长job的稳定性，深度结合云原生的环境。
• 实现多租户的UI服务：DLA Serverless Spark运行完成后，其UI数据会存放在用户OSS空间，DLA提供多租户SparkUI服务，开源查询正在运行中及运行完成的Spark信息，此服务完全免费。
• 多数据源，针对OSS数据源优化： 目前DLA Serverless Spark支持对接Kafka、LogHub等数据源，直接对接HDFS、HBase、OTS、PolarDB、ADB等几乎所有的数据源的分析与回写。并针对OSS数据源支持MetaCache与Rename等优化，在小文件较多的情况，比开源版本提升50%的性能。

 

目前DLA Serverless Spark一直追求更加弹性的服务，跟开源使用体验尽量一致，接入层的服务会更加稳定性。PS：得益于先进的云原生架构，目前UI服务与接入层服务是免费的，用户只需要为实际的资源消耗付费。

 

六
数据平台的演进

DLA致力于帮助客户构建低成本、简单易用、弹性的数据平台，比传统Hadoop至少节约50%的成本。具体到大数据架构，业内大数据架构有Lambda、Kappa等，目前在大公司应用基本是混合体，大数据与业务是比较强相关，随着公司规模大小不一，适用的场景不近相同，且又随着业务的发展需要不同的大数据架构，目前还不存在包打天下的银弹（不过每个组件都想扩展场景，替换其它组件的地盘），如果规模不小的公司只有一个肯定会有损耗或者不是最佳的方案架构。一般随着公司规模发展，有如下趋势（此图挑选业内比较流行的组件）：

方案四，摊开细节一点如下，再结合阿里云OLAP团队的组件：

上图中分为七块，也是目前业内主流的数据处理模式：

 

• 数据源：一般是数据产生的系统，比如事务性的数据会直接存入MySQL，物联网一般直接写入到HBase/Lindorm系统之中；
• 实时数据处理：可以直接对接数据源，如DB CDC或者Kafka，经过流ETL后，写入到数据仓库或者数据湖之中；
• 离线数据湖：存离线的数据，比如CSV\JSON上传的数据，或者离线数仓的数据；
• 专题数据仓库：针对高并发的场景加速，一般为业务团队直接持有；
• 联邦交互式分析：可以跨数据源查询，包括数据仓库、数据湖、数据库的数据；
• 数据应用：数据的应用，如BI、营销系统等；
• 数据开发平台：如计算引擎的调度，数据血缘等。

 

特别注明的是，Lakehouse（Hudi）会把实时数据与离线数据湖结合起来，并且会融合部分数据仓库的能力。在实际的实践中，Lakehouse也是作为数据湖的一部分，解决数据高效入湖，且支持高效分析。

 

七
鸣谢与展望2021年

DLA感谢广大客户的信任，目前已经服务数千客户。在2021年，DLA会聚焦在数据湖场景下，从DLA Meta、DLA Lakehouse、DLA Serverless Spark、DLA Serverless Presto方向发力，提供更加实惠，稳定性，弹性，高性能的数据湖服务。DLA Lakehouse会不断优化支持Kafka、Loghub、DB CDC的实时入湖；DLA Presto主打通用格式的交互式查询，会在多数据源算子下沉，Cache等方向发力；DLA  Spark会完全兼容开源Spark的语法与体验，并且在弹性层面不断突破。

 

文章转自公众号：阿里云数据库