為什么要構建數據湖

大數據時代早期，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 方便數據湖上加速機器學習訓練。

?

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的基于JindoFS+OSS构建高效数据湖的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。