一、 AnalyticDB MySQL介紹

首先介紹下 ADB 產(chǎn)品架構(gòu)， ADB湖倉版產(chǎn)品架構(gòu)包含自研和開源兩部分。ADB湖倉版在數(shù)據(jù)全鏈路的「采存算管用」5 大方面都進行了全面升級和建設(shè)。

在「采集」方面，我們推出了數(shù)據(jù)管道 APS 功能，可以一鍵低成本接入數(shù)據(jù)庫、日志、大數(shù)據(jù)中的數(shù)據(jù)，解決數(shù)據(jù)入湖倉的問題。

在「存儲」方面，我們除了內(nèi)置Hudi /Delta格式的外表數(shù)據(jù)湖格式能力，也對內(nèi)部存儲進行了升級改造。通過只存一份數(shù)據(jù)，同時滿足離線、在線 2 類場景。

在「計算」方面，我們對自研的 XIHE BSP SQL 引擎進行容錯性、運維能力等方面的提升，同時引入開源 Spark 引擎滿足更復(fù)雜的離線處理場景和機器學(xué)習(xí)場景。

在「管理」方面，我們推出了統(tǒng)一的元數(shù)據(jù)管理服務(wù)，統(tǒng)一湖倉元數(shù)據(jù)及權(quán)限，讓湖倉數(shù)據(jù)的流通更順暢。

在「應(yīng)用」方面，除了通過SQL方式的BI分析應(yīng)用外，還支持基于 Spark 的 AI 應(yīng)用。

我們希望通過在做深自研的同時，也充分擁抱開源技術(shù)，來滿足不同客戶的不同業(yè)務(wù)場景，幫助客戶實現(xiàn)降本增效。

擁抱開源不僅僅只是簡單集成Spark/Hudi/Delta等開源引擎，還包括湖倉庫表元數(shù)據(jù)管理，以便多引擎共享，為此ADB 提供了統(tǒng)一元數(shù)據(jù)服務(wù)管理湖倉庫表元數(shù)據(jù)，湖倉中的元數(shù)據(jù)/權(quán)限可互通，不同引擎可自由訪問湖倉數(shù)據(jù)而無需重復(fù)創(chuàng)建元數(shù)據(jù)。對于湖倉數(shù)據(jù)，為屏蔽底層數(shù)據(jù)存儲格式的差異，便于第三方引擎集成，ADB 提供了面向內(nèi)存列存格式 Arrow的Lakehouse API服務(wù)，提供統(tǒng)一的讀寫能力，滿足業(yè)務(wù)對倉存儲有大吞吐的訴求，對于倉存儲已經(jīng)通過 Arrow 格式完成 Spark 引擎對接。

可以看到在ADB擁抱開源技術(shù)方面，Spark扮演著非常重要的角色，而在引入Spark引擎后ADB團隊基于Spark引擎也做了非常多的優(yōu)化，讓其更符合云原生的場景。

二、AnalyticDB MySQL Serverless Spark核心優(yōu)化 

接下來分享ADB Spark的核心優(yōu)化，下圖是ADB Spark整體架構(gòu)。

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

為讓客戶更便捷使用ADB Spark，享受云上Serverless Spark帶來的彈性、性價比優(yōu)勢，低門檻被集成能力是關(guān)鍵的一環(huán)，因此ADB Spark基于阿里云OpenAPI規(guī)范開發(fā)了30個API來管理Spark作業(yè)，覆蓋全生命周期管理，包括提交作業(yè)、停止作業(yè)、獲取作業(yè)狀態(tài)、獲取作業(yè)日志等。

基于OpenAPI能力支持了阿里云DMS、Dataworks調(diào)度系統(tǒng)，同時為了滿足客戶自建調(diào)度系統(tǒng)如自建Airflow場景，ADB Spark也支持Airflow調(diào)度并且將此特性貢獻到了Airflow官方開源倉庫，便于社區(qū)用戶更方便使用ADB Spark。

Spark典型ETL作業(yè)會先訪問OSS、RDS、ES、Kafka等數(shù)據(jù)源，分析計算后寫出。數(shù)據(jù)源訪問是第一步，不同于傳統(tǒng)線下機房的部署形態(tài)，ADB Spark提供Serverless形態(tài)部署在ADB平臺VPC內(nèi)，和用戶數(shù)據(jù)源所在的VPC不在同一個VPC內(nèi)，網(wǎng)絡(luò)是相互隔離的，因此需要打通平臺VPC和用戶VPC的網(wǎng)絡(luò)。ADB Spark使用ENI彈性網(wǎng)卡技術(shù)打通不同VPC之間的網(wǎng)絡(luò)，用戶只需要配置交換機和安全組，ADB Spark會自動創(chuàng)建托管的彈性網(wǎng)卡來打通Driver/Executor到數(shù)據(jù)源的網(wǎng)絡(luò)，彈性網(wǎng)卡的生命周期與作業(yè)生命周期對應(yīng)，彈性網(wǎng)卡在作業(yè)提交后被創(chuàng)建，停止后被釋放。

Spark UI是分析Spark作業(yè)的一種非常重要的工具，該服務(wù)對于開發(fā)者至關(guān)重要，開發(fā)人員依賴UI服務(wù)進行作業(yè)調(diào)試、調(diào)優(yōu)，以及生產(chǎn)作業(yè)的問題排查。好的UI服務(wù)可以很好地加速研發(fā)效率。而開源Spark社區(qū)的HistoryServer提供對Spark歷史作業(yè)的UI和日志服務(wù)，但在實際應(yīng)用中遇到諸多痛點，典型如下：

Eventlog空間開銷大：HistoryServer依賴Spark引擎將運行中的Event信息全部記錄到存儲系統(tǒng)中，然后后臺回放并繪出UI頁面。對于復(fù)雜作業(yè)和長作業(yè)Eventlog量較大，可以達到百GB甚至TB級別。

復(fù)雜作業(yè)和長作業(yè)不支持：復(fù)雜作業(yè)或者長作業(yè)的Eventlog很大，HistoryServer會解析失敗，甚至OOM。再加上空間開銷大的原因，用戶一般都只能關(guān)閉Eventlog

Replay效率差，延遲高：HistoryServer采用后臺Replay Eventlog的方式還原Spark UI，相當(dāng)于把Spark引擎的事件全部重放一遍，開銷大并且延遲高。特別是作業(yè)較多或者較復(fù)雜的情況下，延遲可達分鐘甚至十分鐘級別。

由于開源HistoryServer方案存在諸多痛點問題，ADB Spark自研了一套多租戶UI服務(wù)來滿足云上場景，該UI服務(wù)有如下特點

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

UIServer水平擴展：UIServer主要負(fù)責(zé)解析歷史UI Meta和提供 stderr 和 stdout 日志服務(wù)，輕量化無狀態(tài)，可以實現(xiàn)水平擴展，滿足萬級客戶在線

多租戶：Spark UI URL采用加密token作為參數(shù)，token代表用戶身份、應(yīng)用ID、UI過期時間等，并據(jù)此實現(xiàn)多租戶服務(wù)化

本地日志自動滾動：對于長作業(yè)而言，stderr 或者 stdout 日志隨時間增加累積，最終可能打爆磁盤，引起穩(wěn)定性問題。ADB Spark安全容器內(nèi)置后臺進程，實現(xiàn)日志滾動，保存最有價值的最近一段時間的日志

當(dāng)作業(yè)運行出現(xiàn)異常情況時，對作業(yè)進行快速診斷調(diào)優(yōu)的能力非常重要，開源Spark用戶通過Spark UI查看各Task執(zhí)行情況以及配合日志分析一些諸如長尾Task，Join計劃不合理等問題，然后調(diào)整代碼邏輯重新提交作業(yè)進行調(diào)試，整個分析步驟非常耗費時間和精力，調(diào)優(yōu)效率低下并且很多時候效果不佳。為解決此類問題， ADB Spark針對作業(yè)提供了診斷和調(diào)優(yōu)服務(wù)，運行作業(yè)時便可在控制臺查看作業(yè)是否有異常診斷結(jié)果，為更方便客戶處理異常作業(yè)，ADB Spark除了輸出異常作業(yè)診斷根因外，還會給出調(diào)優(yōu)建議，包括多表Join后數(shù)據(jù)膨脹、資源利用率過載、過低等調(diào)優(yōu)建議，讓客戶以更合理的配置完成作業(yè)，解決盲目調(diào)優(yōu)的難題。

除了提供易于數(shù)據(jù)工程師開發(fā)調(diào)試作業(yè)的調(diào)度系統(tǒng)/控制臺外，ADB Spark還提供了方便數(shù)據(jù)分析師使用的Notebook，借助Notebook和底層Spark強大的分布式能力，方便數(shù)據(jù)分析師進行數(shù)據(jù)分析，洞察數(shù)據(jù)價值。Notebook服務(wù)完全免費，用戶通過ADB控制臺便可開箱使用Notebook，Notebook當(dāng)前支持SQL/Python/Scala語言來滿足不同工程師需求。

在生態(tài)建設(shè)方面，為降低用戶使用湖格式門檻，ADB Spark內(nèi)置了Hudi/Delta湖格式，開箱即用且完全兼容開源語法，同時ADB Spark也支持客戶自定義開發(fā)的私有格式。除了內(nèi)置支持湖存儲外，ADB Spark還支持直接訪問內(nèi)部倉存儲格式，通過Lakehouse API（SDK方式）對接內(nèi)部倉存儲，顯著提高訪問倉的吞吐。

ADB Spark基于Spark CatalogPlugin機制構(gòu)建了統(tǒng)一的Catalog管理不同的表格式Catalog，如支持Hudi表的HoodieCatalog、Delta表的DeltaCatalog以及ADB內(nèi)表的ADBCatalog，基于統(tǒng)一Catalog屏蔽Hudi/Delta開源社區(qū)中繁瑣的catalog和extension等參數(shù)配置，開箱即用，在保持易用性的同時，也兼容Hudi/Delta開源社區(qū)標(biāo)準(zhǔn)用法以及支持客戶自定義Catalog管理其他表格式。

對于訪問倉存儲，通過傳統(tǒng)JDBC協(xié)議訪問效率低，無法支撐機器學(xué)習(xí)、數(shù)據(jù)挖掘等大吞吐訪問場景。為讓一份數(shù)據(jù)同時支持離線和在線場景，ADB Spark支持通過Lakehouse API（SDK協(xié)議）對接倉存儲，以Arrow格式進行數(shù)據(jù)交換，相比傳統(tǒng)JDBC方式，訪問效率提升6x，客戶可以借助Spark和倉存儲構(gòu)建Zero-ETL解決方案。

如客戶有對內(nèi)表進行挖掘分析的訴求，但受限于JDBC吞吐能力，需要先將數(shù)據(jù)以Parquet格式導(dǎo)出至OSS，然后使用Spark進行分析挖掘，引入ETL操作，數(shù)據(jù)一致性差、時效性低

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

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

訪問OSS數(shù)據(jù)源是Spark數(shù)據(jù)湖分析中非常典型的一類場景，開源hadoop-oss也支持直接訪問OSS，但開源方案使用AK/SK明文方式訪問，而明文AK/SK配置泄露可能導(dǎo)致發(fā)生信息安全風(fēng)險。為規(guī)避此類安全風(fēng)險，ADB Spark基于阿里云RAM系統(tǒng)自研了RAM&STS方案，該方案可以滿足企業(yè)安全以及精細(xì)化訪問控制要求，ADB Spark基于RAM系統(tǒng)實現(xiàn)對OSS的訪問控制，用戶只需快速一鍵授權(quán) https://help.aliyun.com/document_detail/455073.html即可授權(quán)子賬號/跨賬號訪問權(quán)限，免AK/SK訪問OSS數(shù)據(jù)，規(guī)避賬密泄露風(fēng)險。

Spark Driver/Executor會周期性的請求元數(shù)據(jù)服務(wù)中心刷新STS Token避免Token過期，元數(shù)據(jù)服務(wù)中心會將請求代理給RAM系統(tǒng)生成新的Token返回，后續(xù)Driver/Executor使用新的新的憑證訪問OSS文件，避免訪問憑證過期影響作業(yè)穩(wěn)定性。

除了對OSS易用性進行改造外，ADB Spark結(jié)合OSS對象存儲的特點對OSS寫性能也進行了深度優(yōu)化。

阿里云OSS支持Multipart Upload功能，原理是把一個文件切分成多個數(shù)據(jù)片并發(fā)上傳，上傳完成后調(diào)用Multipart Upload完成接口將這些數(shù)據(jù)片合并成原來的文件，以此來提高文件寫入OSS的吞吐。由于Multipart Upload可以控制文件對用戶可見的時機，所以可以利用它代替rename操作來優(yōu)化寫OSS時的性能，利用Multipart Upload方式有如下優(yōu)勢：

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

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

setupJob。Driver開啟一個GlobalTransaction,GlobalTransaction在初始化的時候會在OSS上新建一個隱藏的屬于這個GlobalTransaction的工作目錄，用來存放本job的文件元數(shù)據(jù)。

setupTask。Executor使用Driver序列化過來的GlobalTransaction生成LocalTransaction。并監(jiān)聽文件的寫入完成狀態(tài)。
Executor寫文件。文件的元數(shù)據(jù)信息會被LocalTransaction監(jiān)聽到，并儲存到本地的RocksDB里面，OSS遠程調(diào)用比較耗時，我們把元數(shù)據(jù)存儲到本地RocksDB上等到后續(xù)一次提交能夠減少遠程調(diào)用耗時。

commitTask。當(dāng)Executor調(diào)用LocalTransaction commit操作時，LocalTransaction會上傳這個Task它所相關(guān)的元數(shù)據(jù)到OSS對應(yīng)的工作目錄中去，不再監(jiān)聽文件完成狀態(tài)。

commitJob。Driver會調(diào)用GlobalTransaction的commit操作，全局事務(wù)會讀取工作目錄中的所有元數(shù)據(jù)中的待提交文件列表，調(diào)用OSS completeMultipartUpload接口，讓所有文件對用戶可見。

該事務(wù)層有如下特點：

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

除了對OSS訪問進行深度優(yōu)化外，ADB Spark還引入了Native Engine來加速CPU計算。Spark 1.6 版本以來引入了諸如鎢絲計劃、向量化 Parquet Reader 等一系列優(yōu)化后，整體的計算性能有兩倍左右的提升。

但在 3.0 版本以后，整體計算性能的提升有所減緩，很難達到倍數(shù)提升。隨著磁盤/網(wǎng)絡(luò)帶寬技術(shù)的不斷發(fā)展，CPU計算能力成為新的瓶頸，而Spark 基于 JVM 體系只能利用到一些比較基礎(chǔ)的 CPU 指令集，雖然有 JIT 的加持，但相比目前市面上很多的 Native 向量化計算引擎而言，性能差距較大。

因此考慮如何將具有高性能計算能力的 Native 向量引擎引用到 Spark 里來，從而提升 Spark 的計算性能，突破 CPU 瓶頸，向量引擎包括閉源的Databricks Photon引擎，開源社區(qū)的Gluten + Velox/Clickhouse引擎等，都可以更好的實現(xiàn)CPU加速，開源Gluten + Velox方案性能平均提升2x，單查詢性能最高提升8x。

向量引擎整體思路是在不破壞Spark兼容性的同時，將執(zhí)行計劃算子盡可能地卸載到Native Engine執(zhí)行來加速spark作業(yè)性能，阿里云ADB團隊與英特爾 Gluten團隊展開了深度合作，在ADB Spark中支持了Native Engine的落地上線，客戶無需修改任何代碼便可開啟Native優(yōu)化，在內(nèi)部測試中相較于開源的Spark，Native Engine有1.3x到2.8x倍的性能提升。

除針對CPU瓶頸作業(yè)進行優(yōu)化外，ADB Spark也針對重IO作業(yè)進行了優(yōu)化，構(gòu)建了分布式緩存服務(wù)LakeCache。LakeCache利用高性能Local SSD實現(xiàn)可線性擴展的高效Cache服務(wù)，為計算引擎提供10倍以上IO加速。通過多租戶實現(xiàn)低成本Cache，每計算單元(ACU)成本增加3%，TPCH E2E性能提升2.7倍。通過分布式、大容量Cache共享服務(wù)，實現(xiàn)Cache命中率接近100%，基于Native Engine的LakeCache Client也在進一步支持中。

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

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

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

1、第一個案例

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

整體數(shù)據(jù)流如下：

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

基于ADB湖倉一體架構(gòu)收益如下：

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

2、第二個案例

這個案例是基于ADB Spark + ADB Hudi + OSS構(gòu)建低成本LakeHouse。整體數(shù)據(jù)流如下：

• 客戶通過平臺自研數(shù)據(jù)采集模塊從門戶網(wǎng)站采集信息至RDS，日增百萬條記錄
• RDS數(shù)據(jù)通過數(shù)據(jù)增量抽取以parquet格式寫入OSS
• 通過 Spark 對 parquet表進行清洗并寫入Hudi表，清洗邏輯涉及分詞、分句、實體關(guān)鍵詞的抽?。ㄜ囆停?、統(tǒng)計等。
• 通過 Spark 對Hudi表進行清洗聚合后再寫入Hudi表
• 根據(jù)業(yè)務(wù)訴求生成Parquet離線文件供數(shù)據(jù)分析師下載使用或?qū)?shù)據(jù)導(dǎo)入倉進行在線分析

基于ADB平臺構(gòu)建Lakehouse方案收益如下：

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

3、第三個案例

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

使用ADB Spark方案收益如下：

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

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