一、 AnalyticDB MySQL介绍

首先介绍下 ADB 产品架构， ADB湖仓版产品架构包含自研和开源两部分。ADB湖仓版在数据全链路的「采存算管用」5 大方面都进行了全面升级和建设。

我们推出了数据管道 APS 功能，可以一键低成本接入数据库、日志、大数据中的数据，解决数据入湖仓的问题。

我们除了内置Hudi /Delta格式的外表数据湖格式能力，也对内部存储进行了升级改造。通过只存一份数据，同时满足离线、在线 2 类场景。

我们对自研的 XIHE BSP SQL 引擎进行容错性、运维能力等方面的提升，同时引入开源 Spark 引擎满足更复杂的离线处理场景和机器学习场景。

我们推出了统一的元数据管理服务，统一湖仓元数据及权限，让湖仓数据的流通更顺畅。

除了通过SQL方式的BI分析应用外，还支持基于 Spark 的 AI 应用。

我们希望通过在做深自研的同时，也充分拥抱开源技术，来满足不同客户的不同业务场景，帮助客户实现降本增效。

拥抱开源不仅仅只是简单集成Spark/Hudi/Delta等开源引擎，还包括湖仓库表元数据管理，以便多引擎共享，为此ADB 提供了统一元数据服务管理湖仓库表元数据，湖仓中的元数据/权限可互通，不同引擎可自由访问湖仓数据而无需重复创建元数据。对于湖仓数据，为屏蔽底层数据存储格式的差异，便于第三方引擎集成，ADB 提供了面向内存列存格式 Arrow的Lakehouse API服务，提供统一的读写能力，满足业务对仓存储有大吞吐的诉求，对于仓存储已经通过 Arrow 格式完成 Spark 引擎对接。

可以看到在ADB拥抱开源技术方面，Spark扮演着非常重要的角色，而在引入Spark引擎后ADB团队基于Spark引擎也做了非常多的优化，让其更符合云原生的场景。

二、AnalyticDB MySQL Serverless Spark核心优化

接下来分享ADBSpark的核心优化，下图是ADBSpark整体架构。

为让客户更便捷使用ADB Spark，享受云上Serverless Spark带来的弹性、性价比优势，低门槛被集成能力是关键的一环，因此ADB Spark基于阿里云OpenAPI规范开发了30个API来管理Spark作业，覆盖全生命周期管理，包括提交作业、停止作业、获取作业状态、获取作业日志等。

基于OpenAPI能力支持了阿里云DMS、Dataworks调度系统，同时为了满足客户自建调度系统如自建Airflow场景，ADB Spark也支持Airflow调度并且将此特性贡献到了Airflow官方开源仓库，便于社区用户更方便使用ADB Spark。

Spark典型ETL作业会先访问OSS、RDS、ES、Kafka等数据源，分析计算后写出。数据源访问是第一步，不同于传统线下机房的部署形态，ADB Spark提供Serverless形态部署在ADB平台VPC内，和用户数据源所在的VPC不在同一个VPC内，网络是相互隔离的，因此需要打通平台VPC和用户VPC的网络。ADB Spark使用ENI弹性网卡技术打通不同VPC之间的网络，用户只需要配置交换机和安全组，ADB Spark会自动创建托管的弹性网卡来打通Driver/Executor到数据源的网络，弹性网卡的生命周期与作业生命周期对应，弹性网卡在作业提交后被创建，停止后被释放。

Spark UI是分析Spark作业的一种非常重要的工具，该服务对于开发者至关重要，开发人员依赖UI服务进行作业调试、调优，以及生产作业的问题排查。好的UI服务可以很好地加速研发效率。而开源Spark社区的HistoryServer提供对Spark历史作业的UI和日志服务，但在实际应用中遇到诸多痛点，典型如下：

Eventlog空间开销大： HistoryServer依赖Spark引擎将运行中的Event信息全部记录到存储系统中，然后后台回放并绘出UI页面。对于复杂作业和长作业Eventlog量较大，可以达到百GB甚至TB级别。

复杂作业和长作业不支持： 复杂作业或者长作业的Eventlog很大，HistoryServer会解析失败，甚至OOM。再加上空间开销大的原因，用户一般都只能关闭Eventlog

Replay效率差，延迟高： HistoryServer采用后台Replay Eventlog的方式还原Spark UI，相当于把Spark引擎的事件全部重放一遍，开销大并且延迟高。特别是作业较多或者较复杂的情况下，延迟可达分钟甚至十分钟级别。

由于开源HistoryServer方案存在诸多痛点问题，ADBSpark自研了一套多租户UI服务来满足云上场景，该UI服务有如下特点

高效渲染： 作业运行时，Spark Driver 实时流式采集 Spark Event Meta 到OSS，保存作业结束时的页面元信息。为了加速复杂作业 UI 渲染速度，ADB Spark 优化反序列算法并采用 Rotation 算法自动过滤非必要事件，GB 级 Event 渲染提升 47%

UIServer水平扩展 UIServer主要负责解析历史UIMeta和提供stderr和stdout日志服务，轻量化无状态，可以实现水平扩展，满足万级客户在线

多租户： Spark UI URL采用加密token作为参数，token代表用户身份、应用ID、UI过期时间等，并据此实现多租户服务化

本地日志自动滚动： 对于长作业而言，stderr 或者 stdout 日志随时间增加累积，最终可能打爆磁盘，引起稳定性问题。ADB Spark安全容器内置后台进程，实现日志滚动，保存最有价值的最近一段时间的日志

当作业运行出现异常情况时，对作业进行快速诊断调优的能力非常重要，开源Spark用户通过Spark UI查看各Task执行情况以及配合日志分析一些诸如长尾Task，Join计划不合理等问题，然后调整代码逻辑重新提交作业进行调试，整个分析步骤非常耗费时间和精力，调优效率低下并且很多时候效果不佳。为解决此类问题， ADB Spark针对作业提供了诊断和调优服务，运行作业时便可在控制台查看作业是否有异常诊断结果，为更方便客户处理异常作业，ADB Spark除了输出异常作业诊断根因外，还会给出调优建议，包括多表Join后数据膨胀、资源利用率过载、过低等调优建议，让客户以更合理的配置完成作业，解决盲目调优的难题。

除了提供易于数据工程师开发调试作业的调度系统/控制台外，ADB Spark还提供了方便数据分析师使用的Notebook，借助Notebook和底层Spark强大的分布式能力，方便数据分析师进行数据分析，洞察数据价值。Notebook服务完全免费，用户通过ADB控制台便可开箱使用Notebook，Notebook当前支持SQL/Python/Scala语言来满足不同工程师需求。

在生态建设方面，为降低用户使用湖格式门槛，ADB Spark内置了Hudi/Delta湖格式，开箱即用且完全兼容开源语法，同时ADB Spark也支持客户自定义开发的私有格式。除了内置支持湖存储外，ADB Spark还支持直接访问内部仓存储格式，通过Lakehouse API（SDK方式）对接内部仓存储，显著提高访问仓的吞吐。

ADB Spark基于Spark CatalogPlugin机制构建了统一的Catalog管理不同的表格式Catalog，如支持Hudi表的HoodieCatalog、Delta表的DeltaCatalog以及ADB内表的ADBCatalog，基于统一Catalog屏蔽Hudi/Delta开源社区中繁琐的catalog和extension等参数配置，开箱即用，在保持易用性的同时，也兼容Hudi/Delta开源社区标准用法以及支持客户自定义Catalog管理其他表格式。

对于访问仓存储，通过传统JDBC协议访问效率低，无法支撑机器学习、数据挖掘等大吞吐访问场景。为让一份数据同时支持离线和在线场景，ADB Spark支持通过Lakehouse API（SDK协议）对接仓存储，以Arrow格式进行数据交换，相比传统JDBC方式，访问效率提升6x，客户可以借助Spark和仓存储构建Zero-ETL解决方案。

如客户有对内表进行挖掘分析的诉求，但受限于JDBC吞吐能力，需要先将数据以Parquet格式导出至OSS，然后使用Spark进行分析挖掘，引入ETL操作，数据一致性差、时效性低

而通过LakehouseAPI（SDK协议）方式吞吐高，满足分析挖掘需求，无需ETL，数据一致性好、时效性高

为满足客户对于安全方面的诉求，ADB Spark团队联合达摩院团队面向隐私计算领域携手打造的全密态密云原生大数据计算引擎，让可信安全的一站式数据交换迈上了平台化的新阶梯，满足对安全有诉求的场景，全自研的TEE引擎也通过了信通院最高级别的安全认证。客户通过简单配置即可开启全密态计算，使用成本极低。

访问OSS数据源是Spark数据湖分析中非常典型的一类场景，开源hadoop-oss也支持直接访问OSS，但开源方案使用AK/SK明文方式访问，而明文AK/SK配置泄露可能导致发生信息安全风险。为规避此类安全风险，ADB Spark基于阿里云RAM系统自研了RAM&STS方案，该方案可以满足企业安全以及精细化访问控制要求，ADB Spark基于RAM系统实现对OSS的访问控制，用户只需快速一键授权即可授权子账号/跨账号访问权限，免AK/SK访问OSS数据，规避账密泄露风险。

Spark Driver/Executor会周期性的请求元数据服务中心刷新STS Token避免Token过期，元数据服务中心会将请求代理给RAM系统生成新的Token返回，后续Driver/Executor使用新的新的凭证访问OSS文件，避免访问凭证过期影响作业稳定性。

除了对OSS易用性进行改造外，ADB Spark结合OSS对象存储的特点对OSS写性能也进行了深度优化。

阿里云OSS支持Multipart Upload功能，原理是把一个文件切分成多个数据片并发上传，上传完成后调用Multipart Upload完成接口将这些数据片合并成原来的文件，以此来提高文件写入OSS的吞吐。由于Multipart Upload可以控制文件对用户可见的时机，所以可以利用它代替rename操作来优化写 OSS时的性能，利用Multipart Upload方式有如下优势：

OSS Multipart Upload中控制用户可见性的接口是CompleteMultipartUpload和abortMultipartUpload,这种接口的语义类似于commit/ab ort。Hadoop FileSystem标准接口没有提供commit/abort这样的语义，因此我们引入了一套独立的Semi-Transaction层提供类似语义，大致流程如下：

Driver开启一个GlobalTransaction,GlobalTransaction在初始化的时候会在OSS上新建一个隐藏的属于这个GlobalTransaction的工作目录，用来存放本job的文件元数据。

setupTask。 Executor使用Driver序列化过来的GlobalTransaction生成LocalTransaction。并监听文件的写入完成状态。Executor写文件。文件的元数据信息会被LocalTransaction监听到，并储存到本地的RocksDB里面，OSS远程调用比较耗时，我们把元数据存储到本地RocksDB上等到后续一次提交能够减少远程调用耗时。

commitTask。 当Executor调用LocalTransaction commit操作时，LocalTransaction会上传这个Task它所相关的元数据到OSS对应的工作目录中去，不再监听文件完成状态。

commitJob。 Driver会调用GlobalTransaction的commit操作，全局事务会读取工作目录中的所有元数据中的待提交文件列表，调用OSS completeMultipartUpload接口，让所有文件对用户可见。

该事务层有如下特点：

除了对OSS访问进行深度优化外，ADB Spark还引入了Native Engine来加速CPU计算。Spark 1.6 版本以来引入了诸如钨丝计划、向量化 Parquet Reader 等一系列优化后，整体的计算性能有两倍左右的提升。

但在 3.0 版本，整体计算性能的提升有所减缓，很难达到倍数提升。随着磁盘/网络带宽技术的不断发展，CPU计算能力成为新的瓶颈，而Spark 基于 JVM 体系只能利用到一些比较基础的 CPU 指令集，虽然有 JIT 的加持，但相比目前市面上很多的 Native 向量化计算引擎而言，性能差距较大。

因此考虑如何将具有高性能计算能力的 Native 向量引擎引用到 Spark 里来，从而提升 Spark 的计算性能，突破 CPU 瓶颈，向量引擎包括闭源的Databricks Photon引擎，开源社区的Gluten + Velox/Clickhouse引擎等，都可以更好的实现CPU加速，开源Gluten + Velox方案性能平均提升2x，单查询性能最高提升8x。

向量引擎整体思路是在不破坏Spark兼容性的同时，将执行计划算子尽可能地卸载到Native Engine执行来加速spark作业性能，阿里云ADB团队与英特尔 Gluten团队展开了深度合作，在ADB Spark中支持了Native Engine的落地上线，客户无需修改任何代码便可开启Native优化，在内部测试中相较于开源的Spark，Native Engine有1.3x到2.8x倍的性能提升。

除针对CPU瓶颈作业进行优化外，ADB Spark也针对重IO作业进行了优化，构建了分布式缓存服务LakeCache。LakeCache利用高性能Local SSD实现可线性扩展的高效Cache服务，为计算引擎提供10倍以上IO加速。通过多租户实现低成本Cache，每计算单元(ACU)成本增加3%，TPCH E2E性能提升2.7倍。通过分布式、大容量Cache共享服务，实现Cache命中率接近100%，基于Native Engine的LakeCache Client也在进一步支持中。

以上分享了ADBSpark相较于开源Spark在各方面的增强，各个维度总结表格如下，整体而言ADBSpark相较开源版本性能提升2.7x，成本比自建下降29%

三、基于AnalyticDB MySQL湖仓版的最佳实践

接下来分享几个基于ADB MySQL的最佳客户实践。

1、第一个案例

这个案例是利用ADB湖仓一体能力，借助ADB Spark弹性能力加速湖上数据写入湖仓中。

基于ADB湖仓一体架构收益如下：

2、第二个案例

这个案例是基于ADB Spark + ADB Hudi + OSS构建低成本LakeHouse。整体数据流如下：

基于ADB平台构建Lakehouse方案收益如下：

这个案例是从CDH迁移到ADB Spark实现降本增效的案例，客户调度系统和元数据中心都采用自建方案，存储使用OSS，计算采用自建 CDH Spark集群，但面临自建CDH节点扩缩容周期长，天维度扩/缩容，无法处理突发的业务高峰等问题。因此需要将计算上云切换为全托管弹性方式。

阿里云AnalyticDBMySQL升级为湖仓一体架构，支持高吞吐离线处理和高性能在线分析，可无缝替换CDH/TDH/Databricks/Presto/Spark/Hive等。试用活动（5000ACU时+100GB存储）正在火热申请中，申请链接：。