如何用好雲原生資料湖？

阿里技術發表於2020-10-27

如何用好雲原生資料湖？

阿里妹導讀：資料湖可以很好地幫助企業應對當前資料場景越來越多、資料結構越來越複雜、資料處理需求越來越多樣化的問題。阿里雲從2018年起就開始佈局資料湖，推出了雲原生資料湖分析Data Lake Analytics（DLA），從資料湖管理（幫助客戶高效管理構建資料湖），Serverless Spark（提供高價效比的大規模計算），Serverless SQL（提供高價效比的線上互動式分析）三個方面幫助客戶挖掘資料價值。本文分享相關技術挑戰及解決方案。


一  資料湖的機遇與挑戰

資料湖可以很好地幫助企業應對當前資料場景越來越多、資料結構越來越複雜、資料處理的需求越來越多樣化的問題。Gartner 2020年釋出的報告顯示目前已經有39%的使用者在使用資料湖，34%的使用者考慮在1年內使用資料湖。

從2018年起，阿里雲就開始佈局資料湖，推出了雲原生資料湖分析Data Lake Analytics（簡稱：DLA）產品，結合物件儲存OSS一起，從彈性擴充套件、按需付費、服務化等方面打造有競爭力的產品。透過採用儲存計算分離模式，儲存和計算完全按需付費，使用者只需要為實際產生價值的計算買單；DLA深度定製雲原生彈效能力，實現作業級彈性，一分鐘可彈300個節點。雲原生資料湖分析DLA從成本、彈性、交付能力方面相對傳統資料分析方案，獲得了較大的提升。
如何用好雲原生資料湖？
在雲上也已經有數千家企業使用資料湖服務滿足資料應用，如友盟+ 的U-DOP資料開放平臺根據友盟+多年沉澱的大資料領域經驗，形成了以APP、WEB、小程式、廣告營銷、社會化分享和推送為基礎的多端主題資料的採集和處理能力，為客戶形成規範化的多端資料資產。尤其是利用了資料湖的彈效能力，應對了雙十一峰值期間DAU暴漲的業務變化，例如，透過實施分析搜尋關鍵詞的變化，改變首頁廣告推薦資訊，對活躍使用者和下單使用者分不同渠道的分析梳理，及時調整優惠策略，以吸引更多的客戶新購及復購等。

資料庫與大資料一體化趨勢在加強，傳統的資料庫使用者與DBA，也可以使用及維護大資料系統，一體化解決大資料的問題。具體在DLA體現在資料庫的資料無縫與大資料結合，比如DLA提供的一鍵入湖建倉的功能；DLA Serverless SQL相容MySQL協議及部分語法。

DLA Serverless產品形態，開發者只需要使用平臺介面即可，如使用DLA SQL的JDBC介面提交SQL，使用DLA Spark的OpenAPI提交Spark作業。開發者只需要關注業務邏輯本身，不需要關心平臺的複雜邏輯。原來使用開源元件遇到的很多痛點都可以迎刃而解：

入門門檻高

Hadoop生態往往需要多個元件同時使用，比如Yarn、HDFS、Spark、Hive、Kerberos、Zookeeper等等。開發者需要了解所有元件，因為開發過程中這些元件往往都會接觸到。

開發維護困難

開發者在開發過程中會遇到各個元件帶來的使用問題，開發者需要了解所有這些元件以應對這些問題。這些加重了開發者的使用負擔。

穩定性難以保障

開源元件本身都必須經過細緻的調參並加上合適的硬體資源配置，才能良好執行，並且需要修復不少BUG，出現問題沒有兜底。

缺乏適應雲的效能最佳化

雲上的OSS、PolarDB等元件都是雲原生的元件，開源元件對這部分的改造適應不足，沒有充分挖掘出更高的效能。

DLA從資料湖管理（幫助客戶高效管理構建資料湖），Serverless Spark（提供高價效比的大規模計算），Serverless SQL（提供高價效比的線上互動式分析）三個方面幫助客戶挖掘資料價值。整體架構如下所示。接下來，本文將從這三個方面，分別講述相關技術挑戰以及解決方案。

如何用好雲原生資料湖？


二  如何管理與構建資料湖？

資料湖中資料難以管理主要體現在兩個方面：

  1. 已經在資料湖儲存OSS上面的資料如何高效的構建後設資料。

  2. 非OSS資料如何高效的入湖建倉。

資料湖管理相關的主要功能包括後設資料管理、後設資料發現、資料庫入湖建倉、實時資料入湖。接下來重點介紹“海量檔案後設資料自動構建技術”和“入湖建倉資料管理技術”兩個關鍵技術。

1  海量檔案後設資料自動構建技術

當以OSS作為資料湖儲存，儲存的資料檔案具有以下幾個特性：

  • 格式豐富：包括CSV、Text、JSON、Parquet、Orc、Avro、hudi、Delta Lake等格式，其中CSV、Text又包含多種自定義的分隔符等。

  • 檔案數在百萬級別：OSS的擴充套件性及價效比較好，使用者儲存在OSS的檔案會是百萬級別。

  • 檔案動態上傳：儲存在OSS上面資料檔案具有動態持續上傳的特性，新的檔案如何快速增量修改後設資料。

為了高效的為OSS上面的海量資料構建後設資料，阿里雲DLA提出並實現了“海量檔案後設資料自動構建技術”。具體技術如下圖所示，核心解決了：萬表萬分割槽識別、增量感知更新後設資料兩個問題。

如何用好雲原生資料湖？

萬表萬分割槽識別

使用者OSS上面的檔案數量會到百萬級別，這些檔案不僅格式不同，比如JSON、CSV、Text等，而且同一種格式由於業務屬性不同具體的Schema欄位也不一樣。該技術透過檔案Schema識別器搭配檔案分類器支援自動生成萬表萬分割槽。其中檔案Schema識別器比如針對JSON單檔案識別到0.15s、CSV單檔案識別0.2s，搭配可插拔的智慧取樣策略及分散式策略，百萬檔案的Schema識別可以到分鐘級別。檔案分類器透過樹的結構進行聚合、剪枝、壓縮，百萬級別檔案的分類識別需要290ms左右。

增量感知更新

戶會往OSS上面持續不斷的上傳檔案，後設資料自動構建既要把屬於已經建立表的檔案Schema變化更新到已有的表，同時對獨立新增的檔案建立新的表。這裡一方面“檔案Schema識別器”透過獲取OSS上面檔案的增加、刪除變化對變化的檔案進行識別，同時“檔案分類器”對新增的檔案Schema和已經建立的表進行對別生成變化策略，目前支援增加分割槽、增加欄位、欄位不更改、不感知檔案刪除4種策略，後續可以持續新增新的策略。

2  入湖建倉資料組織技術

把DataBase及訊息日誌服務的資料統一儲存到資料湖儲存OSS進行管理，能夠滿足計算加速、構建數倉歸檔、冷熱分離等業務需求。DLA的入湖建倉資料組織技術包括三種資料組織管理模式：映象模式、分割槽模式、增量模式，三種模式能夠搭配友好支援這些業務場景。

如何用好雲原生資料湖？
映象模式

每次全量同步源庫一個Database下面所有表的資料到資料湖儲存OSS之上，同步期間可以做到源庫負載增加控制在10%以內。這裡主要使用了全域性統一資料分片排程演算法。保持資料湖的資料和源庫一致。

分割槽模式

面對歸檔場景支援按天全量及增量同步源庫資料到資料湖，並以時間分割槽的方式進行組織，方便歸檔管理。這種模式能夠做到小時級別的時間延遲。

增量模式

這種模式透過行列混存技術、commitlog及index管理技術，可以做到T+10min的資料入湖。其中透過delta的增量檔案及非同步compaction技術解決了小檔案問題；透過delta增量檔案及索引技術可以支援Database場景更新、刪除日誌的增量實時寫入；透過commitlog的方式記錄分割槽檔案的對映，解決百萬分割槽在傳統Catalog管理模式效能慢的問題。

三  雲原生資料湖平臺需打通雲基礎設施

DLA整體是一個多租戶的架構，分Region部署，每個Region的使用者共享一套控制邏輯。虛擬叢集VC是邏輯的隔離單元。平臺支援 Serverless Spark、Serverless SQL等引擎，打造雲原生服務。

如何用好雲原生資料湖？

如上圖所示，平臺主要面臨的挑戰有：資源高效供給、安全防護、訪問資料來源的頻寬保障。

1  資源高效供給

雲原生平臺基於阿里雲的底座ECS&ACK&ECI，與阿里雲IAAS資源大池打通，本Region跨可用區資源排程，保障資源的供給。支援1分鐘彈300個節點，單客戶在大Region 5w計算節點資源的保障。

2  安全防護

使用者可以寫任意的程式碼平臺內執行，可能是故意惡性的攻擊行為，如果沒有任何保護，則平臺面臨安全危險。在安全方面，我們透過如下技術保障安全性：

  • 一次金鑰：每個Job任務都會去TokenServer申請臨時的Token，Job失效Token會過期，如果存在攻擊行為，則平臺會直接讓Token過期，則訪問Meta等服務會被拒絕。

  • 預防DDOS&注入攻擊：所有的訪問平臺服務的請求，都會對接到安全防護中心，安全防護中心檢測有任何攻擊或者注入行為，直接關閉網路埠。

  • 計算容器隔離：計算節點間採用阿里雲自研的安全容器，容器本身可以實現VM相同的安全隔離級別。

  • 安全白名單：使用者互相之間的網路是完全隔離的。

  • ENI虛擬網路卡：打通VPC需要配置自己賬號下的安全組和虛擬交換機（VSwitch），配置之後結算節點容器會分配使用者VPC對應VSwitch網段的的IP，並掛載使用者的安全組。

3  高吞吐網路頻寬

  • 訪問OSS服務是透過高吞吐的頻寬服務。
  • 使用ENI技術訪問自持VPC，跟在自持VPC內ECS上部署計算引擎訪問自持VPC內資料一樣，頻寬同樣是VPC內網頻寬。

四  Serverless Spark服務的技術挑戰


Apache Spark是目前社群最為流行的開源引擎，不但具備流、SQL、機器學習以及圖等計算能力，也可以連線豐富的資料來源。但是，面對資料湖場景，傳統叢集版Spark方案，除了面臨前面提到的資料管理困難、運維成本、計算資源彈效能力不足、企業級能力弱等問題外，還面臨訪問OSS的效能不佳、複雜作業難以除錯等問題。

藉助於第二章節提到的資料湖管理機制，可以很好地解決資料管理難題。藉助於第三章節提到的多租戶安全平臺，DLA Spark實現了全新的雲原生Serverless產品形態，很好地解決了彈性問題、運維成本問題以及企業級需求問題。本章節對Spark訪問OSS的效能最佳化以多租戶UI服務做進一步展開。

1  Spark訪問OSS最佳化

社群版本的問題

開源版Spark訪問OSS資料預設採用Hadoop FileFormat介面直接對接OSSFileSystem實現。該方法在實踐中發現存在效能差，一致性難以保證等問題。

（1）Spark訪問OSS效能差

核心原因在於OSS KV模型跟HDFS檔案樹模型的差異。FileFormat演算法最初設計是基於HDFS檔案系統，然而物件儲存如OSS，為了解決擴充套件性，本質上採用的是KV模型。KV模型相對於HDFS檔案系統差異較大，比如RenameDirectory介面，在HDFS中只是指標操作，但在KV中，需要將所有子檔案和目錄的KV執行Rename，效能開銷很大，並且保證不了原子性。Hadoop FileOutputFormat在寫入資料的時候先寫到臨時目錄，最後寫入最終目錄，臨時目錄到最終目錄的過程中需要做檔案樹合併，合併過程中有大量Rename操作。

（2）一致性難保證

FileFormat v1演算法中，合併檔案樹操作全部在AppMaster單點執行，效率非常低，尤其是動態分割槽場景。為了解決AppMaster單點，社群提供了演算法2，其核心思路是將合併過程並行到Task中執行，在效能上會有一定的提高，但是，如果Job執行失敗，部分成功的Task會將資料寫入最終資料目錄，導致髒資料問題。

Spark OSS訪問最佳化

如何用好雲原生資料湖？

（1）基於MultipartUpload的FileOutputFormat實現

針對Spark訪問OSS的特點，我們全新實現了Hadoop FileOutputFormat介面，如上圖所示。演算法的改進重點在最佳化合並操作，合併的核心是解決檔案何時可見的問題。OSS提供MultipartUpload介面，也就是斷點續傳功能，檔案可以分片上傳，上傳沒有結束，分片檔案是不可見的。藉助該特性，我們可以讓Task直接將資料寫入到最終目錄，只有作業成功才讓檔案最終可見，該方法不用先寫入臨時目錄，也就大大減少了後設資料的操作。對於執行失敗的Task寫入的臨時分片，我們在作業結束時，執行Abort操作，就可以將其刪除，這也就降低了空間佔用。

針對Spark典型ETL Benchmark Terasort，在1TB輸入資料量的情況下，DLA FileOutputFormat執行時間縮短62%，效能提升163%。而針對動態分割槽場景，社群演算法1執行失敗，演算法2可以執行成功，DLA FileOutputFormat演算法相比演算法2效能還要進一步提升124%。

（2）OSS後設資料Cache

Spark讀取OSS的過程中，在ResolveRelation階段，Spark會遍歷OSS的目錄，解析表結構和分割槽結構，以及解析Schema，該過程中同樣會有大量後設資料操作，並且同一個OSS 物件的後設資料會被訪問多次。針對該問題，我們實現了對OSS後設資料的快取，第一次訪問到的OSS物件後設資料就會被快取到本地，後續如果訪問該物件直接讀取本地快取。這種方式可以最大限度降低對OSS後設資料的訪問。Cache機制可以讓ResolveRelation有1倍左右的效能提升，針對典型的Spark查詢場景，該機制整體可以提升60%的效能。

2  多租戶UI服務


UI服務對於開發者來說至關重要，開發人員依賴UI服務進行作業除錯，以及生產作業的問題排查。好的UI服務可以很好地加速研發效率。

HistoryServer的痛點

Spark社群提供HistoryServer提供對Spark歷史作業的UI和日誌服務，在實際應用中遇到諸多痛點，典型如下：

（1）Eventlog空間開銷大

HistoryServer依賴Spark引擎將執行中的Event資訊全部記錄到FileSystem中，然後後臺回放並繪出UI頁面。對於複雜作業和長作業Eventlog量較大，可以達到百GB甚至TB級別。

（2）複雜作業和長作業不支援

複雜作業或者長作業的Eventlog很大，HistoryServer會解析失敗，甚至OOM。再加上空間開銷大的原因，使用者一般都只能關閉Eventlog。

（3）Replay效率差，延遲高

HistoryServer採用後臺Replay Eventlog的方式還原Spark UI，相當於把Spark引擎的事件全部重放一遍，開銷大，會有延遲。特別是作業較多或者較複雜的情況下，延遲可達分鐘甚至十分鐘級別。

DLA多租戶SparkUI

如何用好雲原生資料湖？
SparkUI服務是DLA平臺自研的多租戶UI服務，針對社群方案做了深度最佳化：

（1）去Eventlog

DLA Spark去掉了Eventlog依賴，在作業結束的時候，Spark Driver只是dump UI的Meta到OSS，儲存作業結束前的頁面元資訊。這部分資訊只是相對於Eventlog來說，會大大減少，即使非常複雜的作業也只有MB級別。UiServer讀取OSS上的UI Meta，將其反序列化出來即可展示SparkUI頁面。

（2）UIServer水平擴充套件

UIServer主要負責解析歷史UI Meta和提供Stderr和Stdout日誌服務，是輕量化，無狀態的，可以實現水平擴充套件，進而支援萬級別客戶同時線上服務。UIServer URL採用加密token作為引數，token代表的使用者身份，作業id，UIServer據此實現多租戶服務化。

（3）本地日誌自動滾動

對於長作業而言，Stderr或者Stdout資訊會隨著時間增加累積，最終甚至可能打爆磁碟。DLA Spark安全容器內建後臺程式，實現日誌滾動，儲存最有價值的最近一段時間的日誌。

五  Serverless SQL服務的技術挑戰

DLA Serverless SQL是基於目前託管於Linux基金會之下的PrestoDB打造的雲原生資料湖引擎，Alibaba同時也是Presto基金會成員之一，一直在貢獻最佳化Presto。PrestoDB引擎本身具有優秀的特性：

  • 全記憶體計算帶來的極致速度。

  • 支援完整SQL語義帶來的強大表達力。

  • 易用的外掛機制使得我們可以對任何資料來源進行關聯查詢。

  • 強大的社群使得我們使用之後沒有後顧之憂。

不過社群PrestoDB是單租戶的一個引擎，它假定你是在一個公司內部使用，因此算力隔離、高可用等等方面沒有過多投入，這使得要直接使用它來作為雲原生服務的引擎存在幾個問題：

  • 一個使用者如果提交大量大查詢將可能佔用叢集所有資源，導致其它使用者無法使用。

  • 單Coordinator使得整個服務的可用性無法得到保證。


我們做了一系列的最佳化、改造使得它可以雲原生的形態服務所有的使用者，今天著重介紹多租戶隔離技術以及多Coordinator兩個主要的特性。

首先我們看一下DLA Serverless SQL的整體架構：

如何用好雲原生資料湖？
我們在核心的PrestoDB叢集周邊建設了諸如接入層、統一後設資料等等服務來使得使用者可以用得穩定、用得便利，下面我們將在多租戶隔離技術和多Coordinator技術的介紹中詳細剖析。

1  多租戶隔離技術

PrestoDB原生是有資源組的支援，它可以支援在不同資源組間做一定程度的CPU、記憶體的限制，但是它有一些問題使得我們無法基於它來實現計算力的隔離：

  • 全域性排程層面：即使一個租戶使用了過多的計算力資源也不會及時被懲罰，只有新查詢會被Block。

  • Worker排程層面：所有租戶的Split是在同一個佇列裡面進行排程，一個租戶如果有過多Split會影響其它租戶。

我們的計算力多租戶方案如下：
如何用好雲原生資料湖？
我們在叢集中引入了一個ResourceManager的模組用於從所有的Coordinator收集所有租戶的資源使用資訊，ResourceManager把收集到的資源使用資訊跟我們預設的計算力的閾值進行對比，計算出哪些租戶應該被懲罰，然後把這個懲罰資訊通知到所有的Worker。Worker在進行排程的時候會參照ResourceManager通知過來的懲罰資訊決定哪些租戶的查詢得到排程，哪些租戶的查詢不進行排程。這樣不同的租戶之間算力就會得到隔離，我們測試瞭如果有一個租戶過量使用資源，它會在最長1.3秒之內得到懲罰，從而釋放資源給其它租戶，而社群預設版本的“懲罰”要等到租戶所有的查詢執行完成才會到來。只有後設資料和計算力得到隔離，我們才能放心用一個叢集來服務我們所有的使用者。

2  Multi-Coordinator技術


社群版本的Presto裡面，Coordinator是一個單點，它會帶來兩個方面的問題：

  • 可用性隱患: 一旦Coordinator當機、整個叢集將不可用達5到10分鐘。

  • 無法實現無縫升級，升級過程中影響所有使用者的查詢使用。

我們採取瞭如下的架構方案：
如何用好雲原生資料湖？
首先我們在Presto的Coordinator之上放置了一個新的FrontNode模組，讓使用者連線到這個模組，而不是直接連線到我們底層的Coordinator，這樣我們底層到底有多少個Coordinator，現在哪個Coordinator在給使用者提供服務都對使用者完全透明，這樣架構上就比較靈活，從而方便我們在底層對Coordinator進行擴充套件。

FrontNode在接收到使用者的查詢之後會把請求按照Round Robin的方式傳送給底層的多個Coordinator，這樣多個Coordinator就可以分擔壓力，但是整個叢集還是有一些全域性的事情要有單個Coordinator來做，比如Presto的Worker狀態監控、OOM Killer等等，因此我們引入了一個Zookeeper來做Coordinator選主的事情，選主之後主Coordinator的職責會跟社群的Presto類似：做全域性的Worker狀態監控、OOM Killer以及執行分配給它的查詢；從Coordinator的職責則比較輕量級: 只負責執行分配給它的查詢。

如果其中一個Coordinator因為任何問題當機，Zookeeper會在秒級發現這個問題並重新選主，使用者受到影響的查詢只要重試即可。而且我們正在做的一個嘗試是做查詢的自動重試，對於確定是系統原因造成的失敗我們做自動重試，這樣一個Coordinator對使用者的影響將會很小。

而有了多Coordinator的架構，我們要實現無縫升級就非常簡單了，我們在升級的時候只要主動把某個Coordinator/Worker從叢集中摘除，進行升級，升級完成再加入叢集，客戶可以毫不感知，因為在升級過程中始終有一個正常工作的叢集在給使用者提供服務, 比如我們在升級從Coordinator的時候，整個叢集情況如下：
如何用好雲原生資料湖？
透過諸如多租戶隔離技術、多Coordinator架構等等最佳化，我們基於PrestoDB打造了可以服務所有的使用者的阿里云云原生資料湖Serverless SQL引擎。

六  雲原生資料湖端到端最佳實踐

如何用好雲原生資料湖？
如上圖方案所示，DLA提供了端到端的方案，面對OSS資料開放性帶來的管理及入湖困難，DLA資料湖管理，幫助您一站式構建安全資料湖。

  • 提供統一開放的Meta服務對OSS資料進行管理，支援庫表許可權。

  • 利用後設資料爬取功能，可以一鍵建立OSS上的後設資料資訊，輕鬆自動識別CSV/JSON/Parquet等格式，建立好庫表資訊，方便後續計算引擎使用。

  • 一鍵將RDS/PolarDB/MongoDB等資料庫的資料同步到OSS儲存當中，搭建冷熱資料分層的業務架構，對多源海量資料進行資料洞察分析。

  • 支援流式構建Hudi格式，滿足T+10分鐘的延遲要求，極大提升分析的端到端的延遲。

  • Serverless化SQL分析，幫助您即開即用資料湖。使用者無需購買任何資源，即可執行標準的SQL語法查詢資料。

  • 支援對資料湖儲存OSS  Cache加速，提升10倍的效能。

  • 支援RDS、PolarDB、ADB、MongoDB資料十種資料來源的分析。

  • 對比傳統的Presto、Impala方案提升10x的價效比提升。

  • Serverless化Spark計算，幫助您自主玩轉資料湖。使用者無需購買任何資源，即可使用雲原生的Spark服務，支援OSS 數PB的資料清洗、機器學習、使用者可程式設計，玩轉資料湖。

  • 每分鐘可彈出500個節點參與計算。

  • 對比傳統的自建Spark方案提升3x的價效比提升。

由於DLA涉及較多的技術點，本文講述了部分技術細節，更多歡迎關注雲原生資料湖分析DLA：
https://www.aliyun.com/product/datalakeanalytics

相關文章