基於EMR的新一代資料湖儲存加速技術詳解

語言: CN / TW / HK

時間 2022-10-08 18:01:33 阿里雲大資料AI技術

主題:

摘要：本文整理自阿里雲開源大資料平臺數據湖儲存團隊孫大鵬在7月17日阿里雲資料湖技術專場交流會的分享。本篇內容主要分為兩個部分：

背景介紹

JindoData 資料湖儲存解決方案

背景介紹

大資料行業蓬勃發展，主要源自於通訊技術的發展，全球資料規模，預計2025年將增長到163ZB，相當於全球60億人，平均每人27TB資料。資料量爆發式增長，使得企業擁有了更多資料資源。更多資料意味著需要更大的儲存。此外，資料本身極具價值，因此要挖掘資料價值並進行充分利用，以此反向推動業務的發展和改造。

幻燈片5.PNG

大資料技術的發展趨勢是雲化、輕量化、服務化。資料湖、與雲融合、實時計算已經成為大資料領域的關鍵詞。存算分離概念在雲端計算早期已被提出。儲存與計算耦合的自建平臺會造成額外成本，且受限於本地網路頻寬。有了雲端計算以後，網路頻寬得到了很大緩解。可以按量收費，提供服務化、容器化的能力，更好地做運維開發。

業界儲存架構演進

幻燈片6.PNG

早期的大資料基於 HDFS 構建數倉。 HDFS 是非常好的分散式儲存選型，單叢集可穩定支撐到 4-6 億檔案規模，資料量可達 100 PB 。但是 HDFS 運維成本比較高，儲存作為基礎元件，一旦儲存出現問題，則意味著整個業務被中斷。此外，達到4-6億檔案規模，100PB資料量後，再進行擴充套件則會出現問題。

因此，社群提出了 HDFS Federation 方案。將 HDFS 叢集進行擴充套件，並將業務進行拆分，大業務可以獨立使用一組 NameNode，可突破單組 NameNode JVM 的限制，實現了HDFS 元資料和容量的橫向擴充套件。此外，社群開發了 NS Router 元件，幫助更好地使用 HDFS 元資料。

隨著 HDFS 的擴充套件，其運維成本也成倍增加。業界開始選擇利用物件儲存的高可用、高吞吐，基於雲上物件儲存構建資料湖。每個雲廠商都會從設計到運維上投入大量人力、物力保證物件儲存可靠、穩定、高效。

從存算一體到雲原生資料湖

幻燈片7.PNG

開源大資料平臺經歷了幾次大的演進。

第一代開源大資料平臺EMR，為更好地將 Hadoop 搬到雲上提供了基礎運維。線上下使用物理機，在雲上使用 ECS 本地盤機型，即可實現與物理機近似的儲存能力和成本。其特點為將線下 IDC 叢集搬上雲，可以通過雲簡化叢集部署和擴容，但不解決 HDFS 的上線、運維等問題。

第二代開源大資料平臺EMR 將 OSS 和 S3 物件儲存作為 storage connector 引入叢集。當儲存叢集達到一定規模後，溫資料、冷資料可以轉存到 OSS 或 S3 物件儲存，進一步降低儲存成本。

第三代開源大資料平臺的特點為本地叢集基本不保留任何元資料，而是保留在雲上。DLF使用 Table 替代了 Hive Metastore 元資料方案，表的元資料通過雲服務託管，利用 OSS 做儲存，使叢集基本實現無狀態。因此，使用者只需建立好叢集即可使用資源，體驗極佳。且可以對接更多儲存引擎，互相之間能夠實現隔離，比如離線、線上可以利用雲上元資料和儲存實現叢集分離。

資料湖儲存演進之路

幻燈片8.PNG

資料湖儲存的演進主要也分為三個階段：

資料湖1.0：存算分離架構，冷熱分層，以Hadoop生態為主。
資料湖2.0：以物件儲存為中心，統一儲存承載生產業務、大規模、高效能。
資料湖3.0：以物件儲存為中心，構建企業資料湖全相容、多協議、統一元資料。

JindoData 資料湖儲存解決方案

幻燈片9.PNG

經過不斷演化，最終實現了 JindoData 資料湖儲存解決方案。JindoData 是儲存加速專案。JindoFS 儲存系統構建在 OSS 之上，提供了檔案元資料功能和目錄功能，可以和 NameNode 進行比對，解決了物件儲存在模擬檔案系統時的操作比如 rename 等問題。Jindo FSx 是儲存加速系統，負責解決頻寬問題。客戶端或計算叢集側有儲存資源，如果都通過網路，則延時、效率與 HDFS 存在差距，經過不斷地放大後，使用者會逐漸感受到效能差距。因此需要 Jindo FSx 儲存加速系統來解決頻寬和延時問題。

基於以上兩大核心繫統，我們對上層提供了 HDFS API 和 POSIX API ，兩個 API 基本可以滿足大資料平臺上對儲存的使用需求，Flink 、Hadoop 、Spark 等大資料相關元件可以直接通過相關 API 方便地接入。比如當前新興的 AI 訓練可以將中間結果、TFRecord等通過 POSIX API 存到物件儲存系統裡。

JindoSDK 生態工具解決了和生態對接問題，比如與計算對接、本地 POSIX 掛載。JindoDistCP 解決從 OSS 和 HDFS 之間的資料遷移，JindoTable 能夠以表粒度做遷移，JindoShell 能夠幫助我們更好地使用物件儲存。

底層資料來源可以對接 HDFS、物件儲存、NAS以及阿里雲OSS。

幻燈片10.PNG

JindoSDK：超級資料湖SDK

幻燈片12.PNG

JindoSDK 是對接生態的重要 SDK，上層可以對接各種引擎，下層對接各種儲存。通常，很多元件和儲存都是基於煙囪式開發，導致 SDK 能力規格存在很大偏差。因此我們重點打造了 Native Core 層，使用 C++ 語言開發，對上層抽象出了 ObjectStore API 、DataStream API 和 FileSystem API。通過 Cython 對接 Python SDK，通過 JNI 對接 Hadoop SDK，通過 C SDK 對接 Jindo Fuse，使上層所有計算引擎都可以使用相同的一套原生 SDK。因此，SDK 層面改進後，上層全鏈路都可以享受 SDK 改進帶來的收益，比如檔案系統元資料操作優化、IO 路徑的讀寫優化、安全、靈活的 STS 配置策略等。

ObjectStore是物件儲存的介面，OSS、S3 都可以歸結到 ObjectStore 內部API。上圖左下角為 Jindo Native SDK 和 OSS Java SDK 的效能對比，可以看到 Jindo SDK 效能平均提升 2.2 倍。

幻燈片13.PNG

Hadoop SDK 訪問 OSS ，效能也可以得到全面提升。幾個 SDK 廣泛應用在 EMR 生產叢集，其穩定性等效能都已經過阿里雲上的產品驗證。

JindoFS：構建在OSS上的高效能儲存系統

幻燈片15.PNG

JindoFS 重點解決了超大規模 HDFS 儲存叢集的挑戰，比如單組 NameNode 架構存在容量限制，如果想突破容量限制，必須投入極高的運維成本，需要運維十多個服務包括NameNode、ZKFC 、ZK、JN；同時，元資料運維重啟時間可高達幾個小時，引數調優、JVM GC、全域性鎖等問題也存在挑戰。除此之外，DataNode 做節點上下線、叢集節點替換、HDFS 內部 balancer 等都需要解決。

幻燈片16.PNG

早期，受限於當時的技術，使用 QJM 架構來解決上述痛點。而隨著 Raft 在業界廣泛推廣和使用，JindoFS 選擇基於 Raft 架構建元資料，內部只需三個 NamespaceService 節點，避免了 HDFS 大量服務部署。

運維成本上，實現了分鐘級重啟。通過C++語言開發，效能非常好。基於 OSS 儲存，可以大大簡化頂層設計，服務也更高效，且本地 block 可以用作快取。

幻燈片17.PNG

半托管的 JindoFS 通過這套元資料可以解決 HDFS 的運維複雜度以及 OSS 介面的損耗，滿足使用者“對系統穩定可靠、運維簡單、節省成本；物件儲存資料湖和 HDFS 相比效能只好不差”的需求。

幻燈片18.PNG

隨著 JindoFS 半托管的深入使用，我們發現即使運維簡單，但因為需要為使用者在半托管上部署一套服務，也會給使用者帶來一定的運維成本。因此我們實現了基於雲原生容器化和儲存服務化的JindoFS資料湖3.0架構，

資料層面， OSS 服務可以提供兩層 API ，分別是物件 API 和目錄 API，通過兩套 API 組合使用，可以基本滿足所有高效能元資料和儲存需求。客戶實際部署時，可以將 SDK 以及 JindoFSx加速等元件部署線上下、容器或 ECS 裡，使容器上的元件也可以更好地使用雲上服務。

幻燈片19.PNG

JindoFS 使用了物件儲存作為底層儲存，因此可以實現冷熱分層，可以根據物件檔案生命週期的不同，選擇標準型、低頻型、歸檔型和冷歸檔型四種模式，最大程度地節省成本。歸檔型別適合長期儲存但可能很長時間不讀的資料，低頻適合讀得比較少的資料。

JindoFSx：高效能/價效比的儲存加速系統

JindoFSx 快取加速系統部署在 worker 上。很多物件儲存遠端有一定的網路開銷，而如果全走網路請求，會導致延時增加。IO 越短，GPU 機器成本也可以發揮到最大。JindoFSx 可以在內部進行分層，能夠對本地儲存資源進行管理。通過 JindoSDK 對上層對接了各種 ETL、互動式分析、實時計算、機器學習等元件，底層可以對接不同資料來源。比如阿里雲上可能要訪問其他雲的物件儲存，頻寬效能上可能無法滿足高效能查詢的需求。但部署 JindoFSx 以後，對資料進行快取、預熱即可基本滿足儲存需求。

幻燈片22.PNG

JindoFSx 實現了分散式快取架構，包括 Namespace、Storage，上層有一套 NameSpaceService 服務做檔案元資料層面的加速，通過檔案系統介面暴露給 JindoSDK，供上層應用使用，以此解決 IO 密集、頻寬受限、遠端資料訪問的問題。

生態工具和場景

幻燈片24.PNG

上圖為資料湖儲存對接計算引擎的大圖，通過 OSS 可以方便地對接各種服務和儲存。

幻燈片25.PNG

我們在資料流層面做了非同步資料預讀、複用，使得讀取 Parquet/ORC 格式時可以實現高效定址，利用快取使資料讀取更高效。

幻燈片26.PNG

物件儲存上的 rename 操作比較重，因此我們設計了JindoCommitter，基於物件儲存系統的 Multiple Upload，結合 OSS 檔案系統層面的定製支援，可以實現在保證資料一致性前提下無需 rename 操作的 Job Committer。在 OSS 上執行作業時，只要加上Jindocommitter ，即可同時保證 Hadoop V1 版本的事務性和 Hadoop V2 版本的高效能。

幻燈片27.PNG

目錄 rename 的優化提供了針對 EMR 優化字首重新命名介面，目錄 rename 降低到毫秒級並保證原子性。另外，我們支援了 fast copy，對比大部分物件儲存對於 object 的copy 操作需要將資料進行真實拷貝， fast copy只需在內部做一次索引轉換，避免了資料真實拷貝。

幻燈片28.PNG

很多資料湖引擎是基於檔案系統原子 rename 特性設計的，即物件如果已經存在，則不能被二次覆蓋。對於這個重要特性，我們在 OSS 上做了重點支援。首先，OSS 是一個強一致性儲存，比如向 bucket 裡寫入 object，如果沒有強一致的保證，在 list 時可能無法獲取到最新的物件。其次，物件儲存的 rename是 Key 覆蓋， Key 級別物件不會檢查檔案是否存在。而資料湖場景下，原子 rename 特性，我們實現了兩種方案：在 SDK 層面基於 OTS 構建原子 Rename 的能力。同時進行深度優化後，已經可以實現 OSS 原生原子性 rename 支援，不依賴任何外部服務，可以在檔案做 copy 時進行強一致的檢測。

幻燈片29.PNG

物件儲存是不支援 Flush 的，而像 Flink、Flume 這類引擎對 Flush 的依賴是比較重的，我們在物件儲存上也做了深度優化，雖然不能保證完整的 Flush 語義，即資料 Flush 以後立刻可見，但是可以保證 Flush 以後資料不丟，對於 Flume 層面來說已經完全滿足實際使用需求。 Flink 裡使用了 MPU 介面，實現了 recoverable writer 的可恢復寫入。

幻燈片30.PNG

資料湖生態的 JindoTable 是專門為結構化資料設計一套工具集，可以幫助降低儲存成本和維護成本。

幻燈片31.PNG

JindoTable 可以以表維度做資料冷熱轉換。比如表存在 OSS 或 HDFS 上，可以通過JindoTable 操作 Hive MetaStore 等的資料，可以按照 DB 級別、表級別、字首級別做生命週期轉換，可以很方便地進行冷熱資料統計，並按特點進行資料分層操作。

幻燈片32.PNG

Hadoop 原生 DistCP 在物件儲存和 HDFS 同步資料會存在一些問題，比如拷貝策略、儲存型別、資料校驗等支援。JindoDistCP 重點解決這類問題：JindoDistCP 上實現了異構 checksum 比對，HDFS 和物件儲存的 checksum 演算法是不同的，傳統的做法無法將HDFS 和物件直接做 checksum 比對，在 JindoDistCP 裡進行了透明的 checksum 轉換，保證了寫入和傳輸過程中的資料準確性。

此外，我們對 JindoDistCP 的核心也進行了重新優化，實現了動態拷貝，類似搶佔式拷貝的方式，大檔案和小檔案可以快速同時並行，頻寬利用率大幅提高。