一、 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存储）正在炽热放开中，放开链接：。