如何用好云原生數(shù)據(jù)湖？
????數(shù)據(jù)湖可以很好地幫助企業(yè)應(yīng)對(duì)當(dāng)前數(shù)據(jù)場(chǎng)景越來(lái)越多、數(shù)據(jù)結(jié)構(gòu)越來(lái)越復(fù)雜、數(shù)據(jù)處理需求越來(lái)越多樣化的問(wèn)題。阿里云從2018年起就開(kāi)始布局?jǐn)?shù)據(jù)湖，推出了云原生數(shù)據(jù)湖分析Data Lake Analytics(DLA)，從數(shù)據(jù)湖管理(幫助客戶高效管理構(gòu)建數(shù)據(jù)湖)，Serverless Spark(提供高性價(jià)比的大規(guī)模計(jì)算)，Serverless SQL(提供高性價(jià)比的在線交互式分析)三個(gè)方面幫助客戶挖掘數(shù)據(jù)價(jià)值。本文分享相關(guān)技術(shù)挑戰(zhàn)及解決方案。
一 數(shù)據(jù)湖的機(jī)遇與挑戰(zhàn)
數(shù)據(jù)湖可以很好地幫助企業(yè)應(yīng)對(duì)當(dāng)前數(shù)據(jù)場(chǎng)景越來(lái)越多、數(shù)據(jù)結(jié)構(gòu)越來(lái)越復(fù)雜、數(shù)據(jù)處理的需求越來(lái)越多樣化的問(wèn)題。Gartner 2020年發(fā)布的報(bào)告顯示目前已經(jīng)有39%的用戶在使用數(shù)據(jù)湖，34%的用戶考慮在1年內(nèi)使用數(shù)據(jù)湖。
從2018年起，阿里云就開(kāi)始布局?jǐn)?shù)據(jù)湖，推出了云原生數(shù)據(jù)湖分析Data Lake Analytics(簡(jiǎn)稱(chēng)：DLA)產(chǎn)品，結(jié)合對(duì)象存儲(chǔ)OSS一起，從彈性擴(kuò)展、按需付費(fèi)、服務(wù)化等方面打造有競(jìng)爭(zhēng)力的產(chǎn)品。通過(guò)采用存儲(chǔ)計(jì)算分離模式，存儲(chǔ)和計(jì)算完全按需付費(fèi)，用戶只需要為實(shí)際產(chǎn)生價(jià)值的計(jì)算買(mǎi)單;DLA深度定制云原生彈性能力，實(shí)現(xiàn)作業(yè)級(jí)彈性，一分鐘可彈300個(gè)節(jié)點(diǎn)。云原生數(shù)據(jù)湖分析DLA從成本、彈性、交付能力方面相對(duì)傳統(tǒng)數(shù)據(jù)分析方案，獲得了較大的提升。
?? 
在云上也已經(jīng)有數(shù)千家企業(yè)使用數(shù)據(jù)湖服務(wù)滿足數(shù)據(jù)應(yīng)用，如友盟+ 的U-DOP數(shù)據(jù)開(kāi)放平臺(tái)根據(jù)友盟+多年沉淀的大數(shù)據(jù)領(lǐng)域經(jīng)驗(yàn)，形成了以APP、WEB、小程序、廣告營(yíng)銷(xiāo)、社會(huì)化分享和推送為基礎(chǔ)的多端主題數(shù)據(jù)的采集和處理能力，為客戶形成規(guī)范化的多端數(shù)據(jù)資產(chǎn)。尤其是利用了數(shù)據(jù)湖的彈性能力，應(yīng)對(duì)了雙十一峰值期間DAU暴漲的業(yè)務(wù)變化，例如，通過(guò)實(shí)施分析搜索關(guān)鍵詞的變化，改變首頁(yè)廣告推薦信息，對(duì)活躍用戶和下單用戶分不同渠道的分析梳理，及時(shí)調(diào)整優(yōu)惠策略，以吸引更多的客戶新購(gòu)及復(fù)購(gòu)等。
數(shù)據(jù)庫(kù)與大數(shù)據(jù)一體化趨勢(shì)在加強(qiáng)，傳統(tǒng)的數(shù)據(jù)庫(kù)使用者與DBA，也可以使用及維護(hù)大數(shù)據(jù)系統(tǒng)，一體化解決大數(shù)據(jù)的問(wèn)題。具體在DLA體現(xiàn)在數(shù)據(jù)庫(kù)的數(shù)據(jù)無(wú)縫與大數(shù)據(jù)結(jié)合，比如DLA提供的一鍵入湖建倉(cāng)的功能;DLA Serverless SQL兼容MySQL協(xié)議及部分語(yǔ)法。
DLA Serverless產(chǎn)品形態(tài)，開(kāi)發(fā)者只需要使用平臺(tái)接口即可，如使用DLA SQL的JDBC接口提交SQL，使用DLA Spark的OpenAPI提交Spark作業(yè)。開(kāi)發(fā)者只需要關(guān)注業(yè)務(wù)邏輯本身，不需要關(guān)心平臺(tái)的復(fù)雜邏輯。原來(lái)使用開(kāi)源組件遇到的很多痛點(diǎn)都可以迎刃而解：
入門(mén)門(mén)檻高
Hadoop生態(tài)往往需要多個(gè)組件同時(shí)使用，比如Yarn、HDFS、Spark、Hive、Kerberos、Zookeeper等等。開(kāi)發(fā)者需要了解所有組件，因?yàn)殚_(kāi)發(fā)過(guò)程中這些組件往往都會(huì)接觸到。
開(kāi)發(fā)維護(hù)困難
開(kāi)發(fā)者在開(kāi)發(fā)過(guò)程中會(huì)遇到各個(gè)組件帶來(lái)的使用問(wèn)題，開(kāi)發(fā)者需要了解所有這些組件以應(yīng)對(duì)這些問(wèn)題。這些加重了開(kāi)發(fā)者的使用負(fù)擔(dān)。
穩(wěn)定性難以保障
開(kāi)源組件本身都必須經(jīng)過(guò)細(xì)致的調(diào)參并加上合適的硬件資源配置，才能良好運(yùn)行，并且需要修復(fù)不少BUG，出現(xiàn)問(wèn)題沒(méi)有兜底。
缺乏適應(yīng)云的性能優(yōu)化
云上的OSS、PolarDB等組件都是云原生的組件，開(kāi)源組件對(duì)這部分的改造適應(yīng)不足，沒(méi)有充分挖掘出更高的性能。
DLA從數(shù)據(jù)湖管理(幫助客戶高效管理構(gòu)建數(shù)據(jù)湖)，Serverless Spark(提供高性價(jià)比的大規(guī)模計(jì)算)，Serverless SQL(提供高性價(jià)比的在線交互式分析)三個(gè)方面幫助客戶挖掘數(shù)據(jù)價(jià)值。整體架構(gòu)如下所示。接下來(lái)，本文將從這三個(gè)方面，分別講述相關(guān)技術(shù)挑戰(zhàn)以及解決方案。
?? 
二 如何管理與構(gòu)建數(shù)據(jù)湖?
數(shù)據(jù)湖中數(shù)據(jù)難以管理主要體現(xiàn)在兩個(gè)方面：
已經(jīng)在數(shù)據(jù)湖存儲(chǔ)OSS上面的數(shù)據(jù)如何高效的構(gòu)建元數(shù)據(jù)。
非OSS數(shù)據(jù)如何高效的入湖建倉(cāng)。
數(shù)據(jù)湖管理相關(guān)的主要功能包括元數(shù)據(jù)管理、元數(shù)據(jù)發(fā)現(xiàn)、數(shù)據(jù)庫(kù)入湖建倉(cāng)、實(shí)時(shí)數(shù)據(jù)入湖。接下來(lái)重點(diǎn)介紹“海量文件元數(shù)據(jù)自動(dòng)構(gòu)建技術(shù)”和“入湖建倉(cāng)數(shù)據(jù)管理技術(shù)”兩個(gè)關(guān)鍵技術(shù)。
1 海量文件元數(shù)據(jù)自動(dòng)構(gòu)建技術(shù)
當(dāng)以O(shè)SS作為數(shù)據(jù)湖存儲(chǔ)，存儲(chǔ)的數(shù)據(jù)文件具有以下幾個(gè)特性：
- 格式豐富：包括CSV、Text、JSON、Parquet、Orc、Avro、hudi、Delta Lake等格式，其中CSV、Text又包含多種自定義的分隔符等。
- 文件數(shù)在百萬(wàn)級(jí)別：OSS的擴(kuò)展性及性價(jià)比較好，用戶存儲(chǔ)在OSS的文件會(huì)是百萬(wàn)級(jí)別。
- 文件動(dòng)態(tài)上傳：存儲(chǔ)在OSS上面數(shù)據(jù)文件具有動(dòng)態(tài)持續(xù)上傳的特性，新的文件如何快速增量修改元數(shù)據(jù)。
為了高效的為OSS上面的海量數(shù)據(jù)構(gòu)建元數(shù)據(jù)，阿里云DLA提出并實(shí)現(xiàn)了“海量文件元數(shù)據(jù)自動(dòng)構(gòu)建技術(shù)”。具體技術(shù)如下圖所示，核心解決了：萬(wàn)表萬(wàn)分區(qū)識(shí)別、增量感知更新元數(shù)據(jù)兩個(gè)問(wèn)題。
?? 
萬(wàn)表萬(wàn)分區(qū)識(shí)別
用戶OSS上面的文件數(shù)量會(huì)到百萬(wàn)級(jí)別，這些文件不僅格式不同，比如JSON、CSV、Text等，而且同一種格式由于業(yè)務(wù)屬性不同具體的Schema字段也不一樣。該技術(shù)通過(guò)文件Schema識(shí)別器搭配文件分類(lèi)器支持自動(dòng)生成萬(wàn)表萬(wàn)分區(qū)。其中文件Schema識(shí)別器比如針對(duì)JSON單文件識(shí)別到0.15s、CSV單文件識(shí)別0.2s，搭配可插拔的智能采樣策略及分布式策略，百萬(wàn)文件的Schema識(shí)別可以到分鐘級(jí)別。文件分類(lèi)器通過(guò)樹(shù)的結(jié)構(gòu)進(jìn)行聚合、剪枝、壓縮，百萬(wàn)級(jí)別文件的分類(lèi)識(shí)別需要290ms左右。
增量感知更新
戶會(huì)往OSS上面持續(xù)不斷的上傳文件，元數(shù)據(jù)自動(dòng)構(gòu)建既要把屬于已經(jīng)創(chuàng)建表的文件Schema變化更新到已有的表，同時(shí)對(duì)獨(dú)立新增的文件創(chuàng)建新的表。這里一方面“文件Schema識(shí)別器”通過(guò)獲取OSS上面文件的增加、刪除變化對(duì)變化的文件進(jìn)行識(shí)別，同時(shí)“文件分類(lèi)器”對(duì)新增的文件Schema和已經(jīng)創(chuàng)建的表進(jìn)行對(duì)別生成變化策略，目前支持增加分區(qū)、增加字段、字段不更改、不感知文件刪除4種策略，后續(xù)可以持續(xù)添加新的策略。
2 入湖建倉(cāng)數(shù)據(jù)組織技術(shù)
把DataBase及消息日志服務(wù)的數(shù)據(jù)統(tǒng)一存儲(chǔ)到數(shù)據(jù)湖存儲(chǔ)OSS進(jìn)行管理，能夠滿足計(jì)算加速、構(gòu)建數(shù)倉(cāng)歸檔、冷熱分離等業(yè)務(wù)需求。DLA的入湖建倉(cāng)數(shù)據(jù)組織技術(shù)包括三種數(shù)據(jù)組織管理模式：鏡像模式、分區(qū)模式、增量模式，三種模式能夠搭配友好支持這些業(yè)務(wù)場(chǎng)景。
?? 
鏡像模式
每次全量同步源庫(kù)一個(gè)Database下面所有表的數(shù)據(jù)到數(shù)據(jù)湖存儲(chǔ)OSS之上，同步期間可以做到源庫(kù)負(fù)載增加控制在10%以內(nèi)。這里主要使用了全局統(tǒng)一數(shù)據(jù)分片調(diào)度算法。保持?jǐn)?shù)據(jù)湖的數(shù)據(jù)和源庫(kù)一致。
分區(qū)模式
面對(duì)歸檔場(chǎng)景支持按天全量及增量同步源庫(kù)數(shù)據(jù)到數(shù)據(jù)湖，并以時(shí)間分區(qū)的方式進(jìn)行組織，方便歸檔管理。這種模式能夠做到小時(shí)級(jí)別的時(shí)間延遲。
增量模式
這種模式通過(guò)行列混存技術(shù)、commitlog及index管理技術(shù)，可以做到T+10min的數(shù)據(jù)入湖。其中通過(guò)delta的增量文件及異步compaction技術(shù)解決了小文件問(wèn)題;通過(guò)delta增量文件及索引技術(shù)可以支持Database場(chǎng)景更新、刪除日志的增量實(shí)時(shí)寫(xiě)入;通過(guò)commitlog的方式記錄分區(qū)文件的映射，解決百萬(wàn)分區(qū)在傳統(tǒng)Catalog管理模式性能慢的問(wèn)題。
三 云原生數(shù)據(jù)湖平臺(tái)需打通云基礎(chǔ)設(shè)施
DLA整體是一個(gè)多租戶的架構(gòu)，分Region部署，每個(gè)Region的用戶共享一套控制邏輯。虛擬集群VC是邏輯的隔離單元。平臺(tái)支持 Serverless Spark、Serverless SQL等引擎，打造云原生服務(wù)。
?? 
如上圖所示，平臺(tái)主要面臨的挑戰(zhàn)有：資源高效供給、安全防護(hù)、訪問(wèn)數(shù)據(jù)源的帶寬保障。
1 資源高效供給
云原生平臺(tái)基于阿里云的底座ECS&ACK&ECI，與阿里云IAAS資源大池打通，本Region跨可用區(qū)資源調(diào)度，保障資源的供給。支持1分鐘彈300個(gè)節(jié)點(diǎn)，單客戶在大Region 5w計(jì)算節(jié)點(diǎn)資源的保障。
2 安全防護(hù)
用戶可以寫(xiě)任意的代碼平臺(tái)內(nèi)運(yùn)行，可能是故意惡性的攻擊行為，如果沒(méi)有任何保護(hù)，則平臺(tái)面臨安全危險(xiǎn)。在安全方面，我們通過(guò)如下技術(shù)保障安全性：
- 一次密鑰：每個(gè)Job任務(wù)都會(huì)去TokenServer申請(qǐng)臨時(shí)的Token，Job失效Token會(huì)過(guò)期，如果存在攻擊行為，則平臺(tái)會(huì)直接讓Token過(guò)期，則訪問(wèn)Meta等服務(wù)會(huì)被拒絕。
- 預(yù)防DDOS&注入攻擊：所有的訪問(wèn)平臺(tái)服務(wù)的請(qǐng)求，都會(huì)對(duì)接到安全防護(hù)中心，安全防護(hù)中心檢測(cè)有任何攻擊或者注入行為，直接關(guān)閉網(wǎng)絡(luò)端口。
- 計(jì)算容器隔離：計(jì)算節(jié)點(diǎn)間采用阿里云自研的安全容器，容器本身可以實(shí)現(xiàn)VM相同的安全隔離級(jí)別。
- 安全白名單：用戶互相之間的網(wǎng)絡(luò)是完全隔離的。
- ENI虛擬網(wǎng)卡：打通VPC需要配置自己賬號(hào)下的安全組和虛擬交換機(jī)(VSwitch)，配置之后結(jié)算節(jié)點(diǎn)容器會(huì)分配用戶VPC對(duì)應(yīng)VSwitch網(wǎng)段的的IP，并掛載用戶的安全組。
3 高吞吐網(wǎng)絡(luò)帶寬
訪問(wèn)OSS服務(wù)是通過(guò)高吞吐的帶寬服務(wù)。
使用ENI技術(shù)訪問(wèn)自持VPC，跟在自持VPC內(nèi)ECS上部署計(jì)算引擎訪問(wèn)自持VPC內(nèi)數(shù)據(jù)一樣，帶寬同樣是VPC內(nèi)網(wǎng)帶寬。
四 Serverless Spark服務(wù)的技術(shù)挑戰(zhàn)
Apache Spark是目前社區(qū)最為流行的開(kāi)源引擎，不但具備流、SQL、機(jī)器學(xué)習(xí)以及圖等計(jì)算能力，也可以連接豐富的數(shù)據(jù)源。但是，面對(duì)數(shù)據(jù)湖場(chǎng)景，傳統(tǒng)集群版Spark方案，除了面臨前面提到的數(shù)據(jù)管理困難、運(yùn)維成本、計(jì)算資源彈性能力不足、企業(yè)級(jí)能力弱等問(wèn)題外，還面臨訪問(wèn)OSS的性能不佳、復(fù)雜作業(yè)難以調(diào)試等問(wèn)題。
借助于第二章節(jié)提到的數(shù)據(jù)湖管理機(jī)制，可以很好地解決數(shù)據(jù)管理難題。借助于第三章節(jié)提到的多租戶安全平臺(tái)，DLA Spark實(shí)現(xiàn)了全新的云原生Serverless產(chǎn)品形態(tài)，很好地解決了彈性問(wèn)題、運(yùn)維成本問(wèn)題以及企業(yè)級(jí)需求問(wèn)題。本章節(jié)對(duì)Spark訪問(wèn)OSS的性能優(yōu)化以多租戶UI服務(wù)做進(jìn)一步展開(kāi)。
1 Spark訪問(wèn)OSS優(yōu)化
社區(qū)版本的問(wèn)題
開(kāi)源版Spark訪問(wèn)OSS數(shù)據(jù)默認(rèn)采用Hadoop FileFormat接口直接對(duì)接OSSFileSystem實(shí)現(xiàn)。該方法在實(shí)踐中發(fā)現(xiàn)存在性能差，一致性難以保證等問(wèn)題。
(1)Spark訪問(wèn)OSS性能差
核心原因在于OSS KV模型跟HDFS文件樹(shù)模型的差異。FileFormat算法最初設(shè)計(jì)是基于HDFS文件系統(tǒng)，然而對(duì)象存儲(chǔ)如OSS，為了解決擴(kuò)展性，本質(zhì)上采用的是KV模型。KV模型相對(duì)于HDFS文件系統(tǒng)差異較大，比如RenameDirectory接口，在HDFS中只是指針操作，但在KV中，需要將所有子文件和目錄的KV執(zhí)行Rename，性能開(kāi)銷(xiāo)很大，并且保證不了原子性。Hadoop FileOutputFormat在寫(xiě)入數(shù)據(jù)的時(shí)候先寫(xiě)到臨時(shí)目錄，最后寫(xiě)入最終目錄，臨時(shí)目錄到最終目錄的過(guò)程中需要做文件樹(shù)合并，合并過(guò)程中有大量Rename操作。
(2)一致性難保證
FileFormat v1算法中，合并文件樹(shù)操作全部在AppMaster單點(diǎn)執(zhí)行，效率非常低，尤其是動(dòng)態(tài)分區(qū)場(chǎng)景。為了解決AppMaster單點(diǎn)，社區(qū)提供了算法2，其核心思路是將合并過(guò)程并行到Task中執(zhí)行，在性能上會(huì)有一定的提高，但是，如果Job執(zhí)行失敗，部分成功的Task會(huì)將數(shù)據(jù)寫(xiě)入最終數(shù)據(jù)目錄，導(dǎo)致臟數(shù)據(jù)問(wèn)題。
Spark OSS訪問(wèn)優(yōu)化
?? 
(1)基于MultipartUpload的FileOutputFormat實(shí)現(xiàn)
針對(duì)Spark訪問(wèn)OSS的特點(diǎn)，我們?nèi)聦?shí)現(xiàn)了Hadoop FileOutputFormat接口，如上圖所示。算法的改進(jìn)重點(diǎn)在優(yōu)化合并操作，合并的核心是解決文件何時(shí)可見(jiàn)的問(wèn)題。OSS提供MultipartUpload接口，也就是斷點(diǎn)續(xù)傳功能，文件可以分片上傳，上傳沒(méi)有結(jié)束，分片文件是不可見(jiàn)的。借助該特性，我們可以讓Task直接將數(shù)據(jù)寫(xiě)入到最終目錄，只有作業(yè)成功才讓文件最終可見(jiàn)，該方法不用先寫(xiě)入臨時(shí)目錄，也就大大減少了元數(shù)據(jù)的操作。對(duì)于執(zhí)行失敗的Task寫(xiě)入的臨時(shí)分片，我們?cè)谧鳂I(yè)結(jié)束時(shí)，執(zhí)行Abort操作，就可以將其刪除，這也就降低了空間占用。
針對(duì)Spark典型ETL Benchmark Terasort，在1TB輸入數(shù)據(jù)量的情況下，DLA FileOutputFormat執(zhí)行時(shí)間縮短62%，性能提升163%。而針對(duì)動(dòng)態(tài)分區(qū)場(chǎng)景，社區(qū)算法1運(yùn)行失敗，算法2可以執(zhí)行成功，DLA FileOutputFormat算法相比算法2性能還要進(jìn)一步提升124%。
(2)OSS元數(shù)據(jù)Cache
Spark讀取OSS的過(guò)程中，在ResolveRelation階段，Spark會(huì)遍歷OSS的目錄，解析表結(jié)構(gòu)和分區(qū)結(jié)構(gòu)，以及解析Schema，該過(guò)程中同樣會(huì)有大量元數(shù)據(jù)操作，并且同一個(gè)OSS 對(duì)象的元數(shù)據(jù)會(huì)被訪問(wèn)多次。針對(duì)該問(wèn)題，我們實(shí)現(xiàn)了對(duì)OSS元數(shù)據(jù)的緩存，第一次訪問(wèn)到的OSS對(duì)象元數(shù)據(jù)就會(huì)被緩存到本地，后續(xù)如果訪問(wèn)該對(duì)象直接讀取本地緩存。這種方式可以最大限度降低對(duì)OSS元數(shù)據(jù)的訪問(wèn)。Cache機(jī)制可以讓ResolveRelation有1倍左右的性能提升，針對(duì)典型的Spark查詢場(chǎng)景，該機(jī)制整體可以提升60%的性能。
2 多租戶UI服務(wù)
UI服務(wù)對(duì)于開(kāi)發(fā)者來(lái)說(shuō)至關(guān)重要，開(kāi)發(fā)人員依賴UI服務(wù)進(jìn)行作業(yè)調(diào)試，以及生產(chǎn)作業(yè)的問(wèn)題排查。好的UI服務(wù)可以很好地加速研發(fā)效率。
HistoryServer的痛點(diǎn)
Spark社區(qū)提供HistoryServer提供對(duì)Spark歷史作業(yè)的UI和日志服務(wù)，在實(shí)際應(yīng)用中遇到諸多痛點(diǎn)，典型如下：
(1)Eventlog空間開(kāi)銷(xiāo)大
HistoryServer依賴Spark引擎將運(yùn)行中的Event信息全部記錄到FileSystem中，然后后臺(tái)回放并繪出UI頁(yè)面。對(duì)于復(fù)雜作業(yè)和長(zhǎng)作業(yè)Eventlog量較大，可以達(dá)到百GB甚至TB級(jí)別。
(2)復(fù)雜作業(yè)和長(zhǎng)作業(yè)不支持
復(fù)雜作業(yè)或者長(zhǎng)作業(yè)的Eventlog很大，HistoryServer會(huì)解析失敗，甚至OOM。再加上空間開(kāi)銷(xiāo)大的原因，用戶一般都只能關(guān)閉Eventlog。
(3)Replay效率差，延遲高
HistoryServer采用后臺(tái)Replay Eventlog的方式還原Spark UI，相當(dāng)于把Spark引擎的事件全部重放一遍，開(kāi)銷(xiāo)大，會(huì)有延遲。特別是作業(yè)較多或者較復(fù)雜的情況下，延遲可達(dá)分鐘甚至十分鐘級(jí)別。
DLA多租戶SparkUI
?? 
SparkUI服務(wù)是DLA平臺(tái)自研的多租戶UI服務(wù)，針對(duì)社區(qū)方案做了深度優(yōu)化：
(1)去Eventlog
DLA Spark去掉了Eventlog依賴，在作業(yè)結(jié)束的時(shí)候，Spark Driver只是dump UI的Meta到OSS，保存作業(yè)結(jié)束前的頁(yè)面元信息。這部分信息只是相對(duì)于Eventlog來(lái)說(shuō)，會(huì)大大減少，即使非常復(fù)雜的作業(yè)也只有MB級(jí)別。UiServer讀取OSS上的UI Meta，將其反序列化出來(lái)即可展示SparkUI頁(yè)面。
(2)UIServer水平擴(kuò)展
UIServer主要負(fù)責(zé)解析歷史UI Meta和提供Stderr和Stdout日志服務(wù)，是輕量化，無(wú)狀態(tài)的，可以實(shí)現(xiàn)水平擴(kuò)展，進(jìn)而支持萬(wàn)級(jí)別客戶同時(shí)在線服務(wù)。UIServer URL采用加密token作為參數(shù)，token代表的用戶身份，作業(yè)id，UIServer據(jù)此實(shí)現(xiàn)多租戶服務(wù)化。
(3)本地日志自動(dòng)滾動(dòng)
對(duì)于長(zhǎng)作業(yè)而言，Stderr或者Stdout信息會(huì)隨著時(shí)間增加累積，最終甚至可能打爆磁盤(pán)。DLA Spark安全容器內(nèi)置后臺(tái)進(jìn)程，實(shí)現(xiàn)日志滾動(dòng)，保存最有價(jià)值的最近一段時(shí)間的日志。
五 Serverless SQL服務(wù)的技術(shù)挑戰(zhàn)
DLA Serverless SQL是基于目前托管于Linux基金會(huì)之下的PrestoDB打造的云原生數(shù)據(jù)湖引擎，Alibaba同時(shí)也是Presto基金會(huì)成員之一，一直在貢獻(xiàn)優(yōu)化Presto。PrestoDB引擎本身具有優(yōu)秀的特性：
- 全內(nèi)存計(jì)算帶來(lái)的極致速度。
- 支持完整SQL語(yǔ)義帶來(lái)的強(qiáng)大表達(dá)力。
- 易用的插件機(jī)制使得我們可以對(duì)任何數(shù)據(jù)源進(jìn)行關(guān)聯(lián)查詢。
- 強(qiáng)大的社區(qū)使得我們使用之后沒(méi)有后顧之憂。
不過(guò)社區(qū)PrestoDB是單租戶的一個(gè)引擎，它假定你是在一個(gè)公司內(nèi)部使用，因此算力隔離、高可用等等方面沒(méi)有過(guò)多投入，這使得要直接使用它來(lái)作為云原生服務(wù)的引擎存在幾個(gè)問(wèn)題：
- 一個(gè)用戶如果提交大量大查詢將可能占用集群所有資源，導(dǎo)致其它用戶無(wú)法使用。
- 單Coordinator使得整個(gè)服務(wù)的可用性無(wú)法得到保證。
我們做了一系列的優(yōu)化、改造使得它可以云原生的形態(tài)服務(wù)所有的用戶，今天著重介紹多租戶隔離技術(shù)以及多Coordinator兩個(gè)主要的特性。
首先我們看一下DLA Serverless SQL的整體架構(gòu)：
?? 
我們?cè)诤诵牡腜restoDB集群周邊建設(shè)了諸如接入層、統(tǒng)一元數(shù)據(jù)等等服務(wù)來(lái)使得用戶可以用得穩(wěn)定、用得便利，下面我們將在多租戶隔離技術(shù)和多Coordinator技術(shù)的介紹中詳細(xì)剖析。
1 多租戶隔離技術(shù)
PrestoDB原生是有資源組的支持，它可以支持在不同資源組間做一定程度的CPU、內(nèi)存的限制，但是它有一些問(wèn)題使得我們無(wú)法基于它來(lái)實(shí)現(xiàn)計(jì)算力的隔離：
- 全局調(diào)度層面：即使一個(gè)租戶使用了過(guò)多的計(jì)算力資源也不會(huì)及時(shí)被懲罰，只有新查詢會(huì)被Block。
- Worker調(diào)度層面：所有租戶的Split是在同一個(gè)隊(duì)列里面進(jìn)行調(diào)度，一個(gè)租戶如果有過(guò)多Split會(huì)影響其它租戶。
我們的計(jì)算力多租戶方案如下：
?? 
我們?cè)诩褐幸肓艘粋€(gè)ResourceManager的模塊用于從所有的Coordinator收集所有租戶的資源使用信息，ResourceManager把收集到的資源使用信息跟我們預(yù)設(shè)的計(jì)算力的閾值進(jìn)行對(duì)比，計(jì)算出哪些租戶應(yīng)該被懲罰，然后把這個(gè)懲罰信息通知到所有的Worker。Worker在進(jìn)行調(diào)度的時(shí)候會(huì)參照ResourceManager通知過(guò)來(lái)的懲罰信息決定哪些租戶的查詢得到調(diào)度，哪些租戶的查詢不進(jìn)行調(diào)度。這樣不同的租戶之間算力就會(huì)得到隔離，我們測(cè)試了如果有一個(gè)租戶過(guò)量使用資源，它會(huì)在最長(zhǎng)1.3秒之內(nèi)得到懲罰，從而釋放資源給其它租戶，而社區(qū)默認(rèn)版本的“懲罰”要等到租戶所有的查詢執(zhí)行完成才會(huì)到來(lái)。只有元數(shù)據(jù)和計(jì)算力得到隔離，我們才能放心用一個(gè)集群來(lái)服務(wù)我們所有的用戶。
2 Multi-Coordinator技術(shù)
社區(qū)版本的Presto里面，Coordinator是一個(gè)單點(diǎn)，它會(huì)帶來(lái)兩個(gè)方面的問(wèn)題：
- 可用性隱患: 一旦Coordinator宕機(jī)、整個(gè)集群將不可用達(dá)5到10分鐘。
- 無(wú)法實(shí)現(xiàn)無(wú)縫升級(jí)，升級(jí)過(guò)程中影響所有用戶的查詢使用。
我們采取了如下的架構(gòu)方案：
?? 
首先我們?cè)赑resto的Coordinator之上放置了一個(gè)新的FrontNode模塊，讓用戶連接到這個(gè)模塊，而不是直接連接到我們底層的Coordinator，這樣我們底層到底有多少個(gè)Coordinator，現(xiàn)在哪個(gè)Coordinator在給用戶提供服務(wù)都對(duì)用戶完全透明，這樣架構(gòu)上就比較靈活，從而方便我們?cè)诘讓訉?duì)Coordinator進(jìn)行擴(kuò)展。
FrontNode在接收到用戶的查詢之后會(huì)把請(qǐng)求按照Round Robin的方式發(fā)送給底層的多個(gè)Coordinator，這樣多個(gè)Coordinator就可以分擔(dān)壓力，但是整個(gè)集群還是有一些全局的事情要有單個(gè)Coordinator來(lái)做，比如Presto的Worker狀態(tài)監(jiān)控、OOM Killer等等，因此我們引入了一個(gè)Zookeeper來(lái)做Coordinator選主的事情，選主之后主Coordinator的職責(zé)會(huì)跟社區(qū)的Presto類(lèi)似：做全局的Worker狀態(tài)監(jiān)控、OOM Killer以及執(zhí)行分配給它的查詢;從Coordinator的職責(zé)則比較輕量級(jí): 只負(fù)責(zé)執(zhí)行分配給它的查詢。
如果其中一個(gè)Coordinator因?yàn)槿魏螁?wèn)題宕機(jī)，Zookeeper會(huì)在秒級(jí)發(fā)現(xiàn)這個(gè)問(wèn)題并重新選主，用戶受到影響的查詢只要重試即可。而且我們正在做的一個(gè)嘗試是做查詢的自動(dòng)重試，對(duì)于確定是系統(tǒng)原因造成的失敗我們做自動(dòng)重試，這樣一個(gè)Coordinator對(duì)用戶的影響將會(huì)很小。
而有了多Coordinator的架構(gòu)，我們要實(shí)現(xiàn)無(wú)縫升級(jí)就非常簡(jiǎn)單了，我們?cè)谏?jí)的時(shí)候只要主動(dòng)把某個(gè)Coordinator/Worker從集群中摘除，進(jìn)行升級(jí)，升級(jí)完成再加入集群，客戶可以毫不感知，因?yàn)樵谏?jí)過(guò)程中始終有一個(gè)正常工作的集群在給用戶提供服務(wù), 比如我們?cè)谏?jí)從Coordinator的時(shí)候，整個(gè)集群情況如下：
?? 
通過(guò)諸如多租戶隔離技術(shù)、多Coordinator架構(gòu)等等優(yōu)化，我們基于PrestoDB打造了可以服務(wù)所有的用戶的阿里云云原生數(shù)據(jù)湖Serverless SQL引擎。
六 云原生數(shù)據(jù)湖端到端最佳實(shí)踐
?? 
如上圖方案所示，DLA提供了端到端的方案，面對(duì)OSS數(shù)據(jù)開(kāi)放性帶來(lái)的管理及入湖困難，DLA數(shù)據(jù)湖管理，幫助您一站式構(gòu)建安全數(shù)據(jù)湖。
- 提供統(tǒng)一開(kāi)放的Meta服務(wù)對(duì)OSS數(shù)據(jù)進(jìn)行管理，支持庫(kù)表權(quán)限。
- 利用元數(shù)據(jù)爬取功能，可以一鍵創(chuàng)建OSS上的元數(shù)據(jù)信息，輕松自動(dòng)識(shí)別CSV/JSON/Parquet等格式，建立好庫(kù)表信息，方便后續(xù)計(jì)算引擎使用。
- 一鍵將RDS/PolarDB/MongoDB等數(shù)據(jù)庫(kù)的數(shù)據(jù)同步到OSS存儲(chǔ)當(dāng)中，搭建冷熱數(shù)據(jù)分層的業(yè)務(wù)架構(gòu)，對(duì)多源海量數(shù)據(jù)進(jìn)行數(shù)據(jù)洞察分析。
- 支持流式構(gòu)建Hudi格式，滿足T+10分鐘的延遲要求，極大提升分析的端到端的延遲。
- Serverless化SQL分析，幫助您即開(kāi)即用數(shù)據(jù)湖。用戶無(wú)需購(gòu)買(mǎi)任何資源，即可運(yùn)行標(biāo)準(zhǔn)的SQL語(yǔ)法查詢數(shù)據(jù)。
- 支持對(duì)數(shù)據(jù)湖存儲(chǔ)OSS Cache加速，提升10倍的性能。
- 支持RDS、PolarDB、ADB、MongoDB數(shù)據(jù)十種數(shù)據(jù)源的分析。
- 對(duì)比傳統(tǒng)的Presto、Impala方案提升10x的性價(jià)比提升。
- Serverless化Spark計(jì)算，幫助您自主玩轉(zhuǎn)數(shù)據(jù)湖。用戶無(wú)需購(gòu)買(mǎi)任何資源，即可使用云原生的Spark服務(wù)，支持OSS 數(shù)PB的數(shù)據(jù)清洗、機(jī)器學(xué)習(xí)、用戶可編程，玩轉(zhuǎn)數(shù)據(jù)湖。
- 每分鐘可彈出500個(gè)節(jié)點(diǎn)參與計(jì)算。
- 對(duì)比傳統(tǒng)的自建Spark方案提升3x的性價(jià)比提升。
由于DLA涉及較多的技術(shù)點(diǎn)，本文講述了部分技術(shù)細(xì)節(jié)，更多歡迎關(guān)注云原生數(shù)據(jù)湖分析DLA：https://www.aliyun.com/product/datalakeanalytics
【本文為51CTO專(zhuān)欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
