基於JindoFS+OSS構建高效數據湖

爲何要構建數據湖

大數據時代早期，Apache HDFS 是構建具備海量存儲能力數據倉庫的首選方案。隨着雲計算、大數據、AI 等技術的發展，全部雲廠商都在不斷完善自家的對象存儲，來更好地適配 Apache Hadoop/Spark 大數據以及各類 AI 生態。因爲對象存儲有海量、安全、低成本、高可靠、易集成等優點，各類 IoT 設備、網站數據都把各類形式的原始文件存儲在對象存儲上，利用對象存儲加強和拓展大數據 AI 也成爲了業界共識，Apache Hadoop 社區也推出了原生的對象存儲「Ozone」。從 HDFS 到對象存儲，從數據倉庫到數據湖，把全部的數據都放在一個統一的存儲中，也能夠更加高效地進行分析和處理。

對於雲上的客戶來講，如何構建本身的數據湖，早期的技術選型很是重要，隨着數據量的不斷增長，後續進行架構升級和數據遷移的成本也會增長。在雲上使用 HDFS 構建大規模存儲系統，已經暴露出來很多問題。HDFS 是 Hadoop 原生的存儲系統，通過 10 年來的發展，HDFS 已經成爲大數據生態的存儲標準，但咱們也看到 HDFS 雖然不斷優化，可是 NameNode 單點瓶頸，JVM 瓶頸仍然影響着集羣的擴展，從 1 PB到 100+ PB，須要不斷的進行調優、集羣拆分來，HDFS 能夠支持到 EB 級別，可是投入很高的運維成本，來解決慢啓動，心跳風暴，節點擴容、節點遷移，數據平衡等問題。

雲原生的大數據存儲方案，基於阿里雲 OSS 構建數據湖是最合適的選擇。OSS 是阿里雲上的對象存儲服務，有着高性能、無限容量、高安全、高可用、低成本等優點，JindoFS 針對大數據生態對 OSS 進行了適配，緩存加速，甚至提供專門的文件元數據服務，知足上雲客戶的各類分析計算需求。所以在阿里雲上，JindoFS + OSS 成爲客戶採起數據湖架構遷移上雲的最佳實踐。

JindoFS 介紹

Jindo 是阿里雲基於 Apache Spark / Apache Hadoop 在雲上定製的分佈式計算和存儲引擎。Jindo 原是阿里雲 開源大數據團隊的內部研發代號，取自筋斗(雲)的諧音，Jindo 在開源基礎上作了大量優化和擴展，深度集成和鏈接了衆多阿里雲基礎服務。

JindoFS 是阿里雲針對雲上存儲自研的大數據緩存加速服務，JindoFS 的設計理念是雲原生：彈性、高效、穩定和低成本。JindoFS 徹底兼容 Hadoop 文件系統接口，給客戶帶來更加靈活、高效的數據湖加速方案，徹底兼容阿里雲 EMR 中全部的計算服務和引擎：Spark、Flink、Hive、MapReduce、Presto、Impala 等。JindoFS 有兩種使用模式，塊存儲模式(BLOCK)和緩存模式(CACHE)。下面咱們介紹下如何在 EMR 中配置和使用 JindoFS 以及不一樣模式對應的場景。

JindoFS 架構

JindoFS 主要包含兩個服務組件：元數據服務(NamespaceService) 和存儲服務 (StorageService)：

• NamespaceService 主要負責元數據管理以及管理 StorageService。
• StorageService 主要負責管理節點的本地數據和 OSS 上的緩存數據。

下圖是 JindoFS 架構圖：元數據服務 NamespaceService 部署在獨立的節點，對於生產環境推薦部署三臺(Raft)來實現服務高可用；存儲服務 StorageService 部署在集羣的計算節點，管理節點上的閒置存儲資源（本地盤/SSD/內存等），爲JindoFS 提供分佈式緩存能力。

JindoFS 元數據服務

JindoFS 的元數據服務叫 JindoNamespaceService，內部基於 K-V 結構存儲元數據，相對於傳統的內存結構有着操做高效，易管理，易恢復等優點。

• 高效元數據操做。JindoFS NamespaceService 基於內存 + 磁盤管理和存儲元數據，可是性能上比使用內存的 HDFS NameNode 還要好，一方面是 JindoFS 使用 C++ 開發，沒有 GC 等問題，響應更快；另外一方面是因爲 Namespace Service 內部有更好的設計，好比文件元數據上更細粒度的鎖，更高效的數據塊副本管理機制。
• 秒級啓動。有大規模 HDFS 集羣維護經驗的同窗比較清楚，當 HDFS 元數據存儲量過億之後，NameNode 啓動初始化要先加載 Fsimage ，再合併 edit log，而後等待所有 DataNode 上報 Block，這一系列流程完成要花費一個小時甚至更長的時間， 因爲 NameNode 是雙機高可用（Active/Standby），若是 standby 節點重啓時 active 節點出現異常 ，或兩臺 NameNode 節點同時出現故障，HDFS 將出現停服一小時以上的損失。JindoFS 的元數據服務基於 Raft 實現高可用，支持 2N+1 的部署方式，容許同時掛掉 N 臺；元數據服務 (NamespaceService) 在元數據內部存儲上進行了設計和優化，進程啓動後便可提供服務，能夠作到了快速響應。因爲 NamespaceService 近實時寫入 OTS 的特色，元數據節點更換，甚至集羣總體遷移也很是容易。
• 低資源消耗。HDFS NameNode 採用內存形式來存儲文件元數據。在必定規模下，這種作法性能上是比較不錯的，可是這樣的作法也使 HDFS 元數據的規模受限於節點的內存，通過推算，1億文件 HDFS 文件大約須要分配 60 GB Java Heap 給 NameNode，因此一臺 256 GB的機器最多能夠管理 4 億左右的元數據，同時還須要不斷調優 JVM GC。JindoFS 的元數據採用 Rocksdb 存儲元數據，能夠輕鬆支持到 10 億規模，對於節點的內存需求也很是小，資源開銷不到 NameNode 的十分之一。

JindoFS 緩存服務

JindoFS 的數據緩存服務叫 JindoStorageService，本地 StorageService 主要提供高性能緩存加速，因此運維上能夠基於這樣的設定大大簡化。

• 彈性運維。HDFS 使用 DataNode 在存儲節點上來管理節點存儲，所有數據塊都存儲在節點的磁盤上，依靠 DataNode 按期檢查和心跳把存儲狀態上報給 NameNode，NameNode 經過彙總和計算，動態地保證文件的數據塊達到設定的副本數（通常 3 副本）。對於大規模集羣（節點 1000+），常常須要進行集羣節點擴容，節點遷移，節點下線，節點數據平衡這樣的操做，大量的數據塊的副本計算增長了 NameNode 負載，同時，節點相關操做要等待 NameNode 內部的副本調度完成才能進行，一般一個存儲節點的下線須要小時級別的等待才能完成。JindoFS 使用 StorageService 來管理節點上的存儲，因爲 JindoFS 保證了數據在 OSS 上有一副本，因此本地的副本主要用來進行緩存加速。對於節點遷移、節點下線等場景，JindoFS 無需複雜副本計算，經過快速的「標記」便可完成下線。
• 高性能存儲。StorageService 採用 C++ 語言開發，在對接最新高性能存儲硬件上也有着自然優點。StorageService 的存儲後端不只能夠同時對接SSD、本磁盤、OSS 知足 Hadoop/Spark 大數據框架各類海量、高性能的存儲訪問需求，能夠對接內存、AEP 這樣的高性能設備知足 AI/機器學習的低延時、高吞吐的存儲使用需求。

JindoFS 適用場景

JindoFS 的元數據存儲在 Master 節點的 NamespaceService （高可用部署）上，性能和體驗上對標 HDFS；Core節點的 StorageService 將一份數據塊存儲在 OSS 上，本地數據塊能夠隨着節點資源進行快速的彈性伸縮。多集羣之間也能夠相互打通。

爲了支持數據湖多種使用場景，一套 JindoFS 部署同時提供兩種 OSS 使用方式，存儲模式（Block）和緩存模式（Cache）。

• 緩存模式。對於已經存在於 OSS 上的數據，可使用緩存模式訪問，正如「緩存」自己的含義，經過緩存的方式，在本地集羣基於 JindoFS 的存儲能力構建了一個分佈式緩存服務，把遠端數據緩存在本地集羣，使遠端數據「本地化」。使用上也沿用原來的路徑訪問，如 oss://bucket1/file1 ，這種模式全量的文件都在 OSS 上面，能夠作到集羣級別的彈性使用。
• 存儲模式。存儲模式（Block）適用於高性能數據處理場景，元數據存儲在 NamespaceService （支持高可用部署）上，性能和體驗上對標 HDFS；StorageService 將一份數據塊存儲在 OSS 上，本地數據塊能夠隨着節點資源能夠進行快速的彈性伸縮。基於 JindoFS Block 模式這樣的特性，能夠用做構建高性能數倉的核心存儲，多個計算集羣能夠訪問 JindoFS 主集羣的數據。

JindoFS 方案優點

基於JindoFS + OSS 來構建數據湖相比於其餘數據湖方案同時具備性能和成本優點。

• 性能上，JindoFS 針對一些經常使用的場景和 Benchmark 進行了對比測試，如 DFSIO、NNbench、TPCDS、Spark、Presto 等，經過測試咱們能夠看到性能上，Block模式徹底領先於 HDFS，Cache模式徹底領先於 Hadoop 社區的 OSS SDK 實現，因爲篇幅的緣由，後續咱們會發布詳細的測試報告。
• 成本上。成本是也是用戶上雲的重要考量，JindoFS 的成本優點主要體如今運維成本和存儲成本兩方面。運維成本指的是集羣平常維護，節點上下線、遷移等。如前面分析，當 HDFS 集羣增加到必定規模時，好比 10PB+，除了對 HDFS 進行專家級別調優外，還須要業務上的拆分規劃，避免達到 HDFS 元數據上的瓶頸。同時，隨着集羣數據不斷增加，一些節點和磁盤也會出現故障，須要進行節點下線和數據平衡，也給大集羣的運維帶來必定的複雜度。JindoFS 可使用 OSS + OTS 的存儲模式，OSS 上保留原始文件和數據塊備份，對節點和磁盤出現的問題能夠更好兼容；元數據（NamespaceService）採用 C++ 開發加上工程打磨，相比 NameNode + JVM 在容量上和性能上也更有優點。

下面咱們重點來看存儲成本。存儲成本指的是存放數據後產生的存儲費用，使用 OSS 是按量付費的，相比基於本地盤建立的 HDFS 集羣有更好的成本優點，下面來計算和對比一下兩者成本：

基於 HDFS + 本地盤方案構建大數據存儲：

因爲本地盤機型爲總體價格，須要以下進行換算，預估存儲成本以下：

（參考連接：https://www.aliyun.com/price/product#/ecs/detail ）

考慮到實際使用 HDFS 會有3副本以及必定的預留空間，咱們以 HDFS 3 副本、 80% 使用率進行成本計算：

基於 JindoFS 加速方案構建數據湖：

OSS 數據存儲（標準型單價）=  0.12元/GB/每個月

（參考連接：https://www.aliyun.com/price/product#/oss/detail ）

咱們能夠看到使用 JindoFS 加速方案構建數據湖，要節省 25% 的存儲成本。同時 OSS 是按量計費，即計算存儲分離，當計算和存儲比例存在差別時，好比存儲資源高速增加，計算資源增長較小時，成本優點會更加明顯。

對 OSS 數據進行緩存加速，須要額外使用計算節點上部分磁盤空間，帶來必定成本。這部分紅本，通常取決於熱數據或者要緩存數據的大小，跟要存儲的數據總量關係不大。增長這部分紅本，能夠換取計算效率的提高和計算資源的節省，總體效果能夠根據實際場景進行評估。

JindoFS 生態

數據湖是開放的，須要對接各類計算引擎。目前 JindoFS 已經明確支持 Spark、Flink、Hive、MapReduce、Presto 和 Impala 組件。同時，JindoFS 爲了支持更好地使用數據湖，還提供 JindoTable 對結構化數據進行優化和查詢加速；提供 JindoDistCp 來支持 HDFS 離線數據往 OSS 遷移；支持 JindoFuse 方便數據湖上加速機器學習訓練。

原文連接本文爲阿里雲原創內容，未經容許不得轉載。