一、 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核心優化 

接下來分享ADB Spark的核心優化，下圖是ADB Spark整體架構。

• 最上層是面向用戶的使用入口，包括ADB SQL/Jar控制臺、ADB作業調度控制臺，以及阿里云DMS、Dataworks調度系統，以及貼合開源Spark用戶使用習慣的SparkSubmit腳本方式。
• 支持控制臺和調度系統提交Spark作業的是OpenAPI模塊，該模塊提供了規范的API能力，對下對接管控服務，對上支持各類系統集成ADB Spark服務。
• Spark管控服務負責管理Spark作業，該服務以多租形態部署，負責Spark作業資源校驗，元數據管理，狀態管理，安全校驗等方面。
• 下一層由Driver和多個Executor組成的Spark集群，該集群歸屬于ADB實例的資源組，不同資源組之間的資源相互隔離，互不影響，Driver、Executor都會通過統一元數據服務請求庫表元信息，通過統一管控底座申請彈性資源。
• 最底層是ADB Spark支持的各類數據源，大體分為兩類，一類是OSS/MaxCompute等通過AnyTunnel/STS Token進行授權訪問的數據源，另一類是用戶VPC下如ADB/RDS/HBase等需要通過ENI彈性網卡技術打通不同VPC網絡才能訪問的數據源。

為讓客戶更便捷使用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方案存在諸多痛點問題，ADB Spark自研了一套多租戶UI服務來滿足云上場景，該UI服務有如下特點

高效渲染：作業運行時，Spark Driver 實時流式采集 Spark Event Meta 到OSS，保存作業結束時的頁面元信息。為了加速復雜作業 UI 渲染速度，ADB Spark 優化反序列算法并采用 Rotation 算法自動過濾非必要事件，GB 級 Event 渲染提升 47%

UIServer水平擴展：UIServer主要負責解析歷史UI Meta和提供 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操作，數據一致性差、時效性低

而通過Lakehouse API（SDK協議）方式吞吐高，滿足分析挖掘需求，無需ETL，數據一致性好、時效性高

為滿足客戶對于安全方面的訴求，ADB Spark團隊聯合達摩院團隊面向隱私計算領域攜手打造的全密態密云原生大數據計算引擎，讓可信安全的一站式數據交換邁上了平臺化的新階梯，滿足對安全有訴求的場景，全自研的TEE引擎也通過了信通院最高級別的安全認證。客戶通過簡單配置即可開啟全密態計算，使用成本極低。

訪問OSS數據源是Spark數據湖分析中非常典型的一類場景，開源hadoop-oss也支持直接訪問OSS，但開源方案使用AK/SK明文方式訪問，而明文AK/SK配置泄露可能導致發生信息安全風險。為規避此類安全風險，ADB Spark基于阿里云RAM系統自研了RAM&STS方案，該方案可以滿足企業安全以及精細化訪問控制要求，ADB Spark基于RAM系統實現對OSS的訪問控制，用戶只需快速一鍵授權 https://help.aliyun.com/document_detail/455073.html即可授權子賬號/跨賬號訪問權限，免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方式有如下優勢：

• 寫入文件不需要多次拷貝。不需要昂貴的 Rename 操作，寫入文件不需要copy&delete。另外相比于Rename，OSS 的 completeMultipartUpload 接口非常輕量。
• 出現數據不一致幾率更小。雖然如果一次要寫入多個文件，此時進行completeMultipartUpload仍然不是原子性操作，但是相比于原先的rename會copy數據，時間窗口縮短很多，出現數據不一致的幾率會小很多，可以滿足絕大部分場景
• Rename中的文件元信息相關操作不再需要。經過統計，算法1中一個文件的元數據操作可以從13次下降到6次，算法2則可以從8次下降到4次。

OSS Multipart Upload中控制用戶可見性的接口是CompleteMultipartUpload和abortMultipartUpload,這種接口的語義類似于commit/abort。Hadoop FileSystem標準接口沒有提供commit/abort這樣的語義，因此我們引入了一套獨立的Semi-Transaction層提供類似語義，大致流程如下：

setupJob。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接口，讓所有文件對用戶可見。

該事務層有如下特點：

• 通用性強：不依賴任何計算引擎的接口，可以比較方便移植到另外其他計算引擎，通過適配可以將它所提供的實現給Presto或者其它計算引擎使用
• 擴展性好：可以在Transaction的語義下添加更多的實現。例如對于分區合并的這種場景，可以加入MVCC的特性，在合并數據的同時不影響線上對數據的使用

除了對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也在進一步支持中。

以上分享了ADB Spark相較于開源Spark在各方面的增強，各個維度總結表格如下，整體而言ADB Spark相較開源版本性能提升2.7x，成本比自建下降29%

三、基于AnalyticDB MySQL湖倉版的最佳實踐

接下來分享幾個基于ADB MySQL的最佳客戶實踐。

1、第一個案例

這個案例是利用ADB湖倉一體能力，借助ADB Spark彈性能力加速湖上數據寫入湖倉中。

整體數據流如下：

• 使用ADB APS入湖服務消費SLS數據并以每秒4G/s速率寫入OSS Hudi表
• 根據不同的業務場景，通過Spark彈性作業將湖中數據寫入倉中加速查詢或者進行ETL寫入新CSV表供客戶下載分析

基于ADB湖倉一體架構收益如下：

• 通過新發布的高速數據通道，湖倉一體存儲，統一元數據服務，Spark/Xihe離在線混合引擎核心技術，支撐雙11數據庫自治服務（DAS），總寫入吞吐達到8GB/s，存儲總量達到20PB+。 
• ADB內建數據通道支持SLS/Kafka等數據源高吞吐低延遲入湖入倉，通過橫向擴容，負載均衡，熱點打散，保障面對大促，提供平時2倍以上的吞吐能力。
• 通過統一的元數據服務打通湖倉邊界，并提供統一的存儲API接口，離線和在線計算引擎均可直接訪問湖和倉的數據，一套體系同時支撐了SQL模板趨勢分析離線場景和數據導出，日志查詢在線場景，為DAS業務持續發展提供豐富想象力。

2、第二個案例

這個案例是基于ADB Spark + ADB Hudi + OSS構建低成本LakeHouse。整體數據流如下：

• 客戶通過平臺自研數據采集模塊從門戶網站采集信息至RDS，日增百萬條記錄
• RDS數據通過數據增量抽取以parquet格式寫入OSS
• 通過 Spark 對 parquet表進行清洗并寫入Hudi表，清洗邏輯涉及分詞、分句、實體關鍵詞的抽取（車型）、統計等。
• 通過 Spark 對Hudi表進行清洗聚合后再寫入Hudi表
• 根據業務訴求生成Parquet離線文件供數據分析師下載使用或將數據導入倉進行在線分析

基于ADB平臺構建Lakehouse方案收益如下：

• 計算耗時：下降3倍。使用傳統自建Hadoop集群的方式，對于小公司，由于成本原因，集群的固定資源一般是不夠大的，這會導致計算任務耗時很長，尤其是任務多了之后只能串行處理不能并行化，導致時間會更長。使用可靈活彈性升級的ADB數據湖分析平臺后，我們可以并行化啟動多個任務流，每個任務流根據我們預計的完成時間分配合理的計算資源ACU數量，可以做到不增加總成本的基礎上，讓計算時間顯著縮短。目前我們每天的計算任務可以控制在30分鐘內完成，一周的計算任務可以控制在3小時內完成。最快的一次，我們需要重算歷史一年的數據，通過指定使用更多的ACU數量，在1天之內就全部計算完成。同時引入Hudi后作業耗時從10min下降到3min。
• 計算費用：下降30%~50%。ADB數據湖分析的整體費用由兩部分構成：OSS存儲和接口費+ADB Spark按量計算費用。OSS存儲和接口費，按照數據量10TB左右估算，每個月費用應該在2000元以內；ADB Spark按量計算費用是按ACU數量*計算時長收費，100核400G的集群算1個小時大概35元，性價比非常高。ADB Spark + OSS組合方案中 Spark 計算 + OSS存儲成本每個月5000左右，一年約6萬，搭建傳統集群50個CU 估計1年成本9萬多，整體成本下降30%，如果業務數據量大，計算復雜，計算頻率不是很高，整體成本下降更高，使用ADB Spark數據湖分析性價比非常高

3、第三個案例

這個案例是從CDH遷移到ADB Spark實現降本增效的案例，客戶調度系統和元數據中心都采用自建方案，存儲使用OSS，計算采用自建 CDH Spark集群，但面臨自建CDH節點擴縮容周期長，天維度擴/縮容，無法處理突發的業務高峰等問題。因此需要將計算上云切換為全托管彈性方式。

使用ADB Spark方案收益如下：

• 云資源調整量只要在界面修改最大資源就可以獲得足夠的資源滿足業務運算需求，非常靈活，且按量付費成本更低，降本20%
• 業務增長不需要添加機器，也沒有機器需要運維，至少減少80%降低了運維成本
• 使用標準的開源技術，在業務發展后，若自建機房更低成本，該放方案輕松進行下云操作，不會Vendor lock-in，因為元數據、調度都自主研發可控

阿里云AnalyticDBMySQL升級為湖倉一體架構，支持高吞吐離線處理和高性能在線分析，可無縫替換CDH/TDH/Databricks/Presto/Spark/Hive等。試用活動（5000ACU時+100GB存儲）正在火熱申請中，申請鏈接：https://free.aliyun.com/?searchKey=AnalyticDB%20MySQL。