為什麼要建構資料湖
大資料時代早期，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/每月 我們可以看到使用 JindoFS 加速方案建構資料湖，要節省 25% 的存儲成本。同時 OSS 是按量計費，即計算存儲分離，當計算和存儲比例存在差異時，比如存儲資源高速增長，計算資源增加較小時，成本優勢會更加明顯。
對 OSS 資料進行緩存加速，需要額外使用計算節點上部分磁盤空間，帶來一定成本。這部分成本，一般取決于熱資料或者要緩存資料的大小，跟要存儲的資料總量關系不大。增加這部分成本，可以換取計算效率的提升和計算資源的節省，整體效果可以根據實際場景進行評估。
JindoFS 生态
資料湖是開放的，需要對接各種計算引擎。目前 JindoFS 已經明确支援 Spark、Flink、Hive、MapReduce、Presto 和 Impala 元件。同時，JindoFS 為了支援更好地使用資料湖，還提供 JindoTable 對結構化資料進行優化和查詢加速；提供 JindoDistCp 來支援 HDFS 離線資料往 OSS 遷移；支援 JindoFuse 友善資料湖上加速機器學習訓練。
更多資料湖技術相關的文章請點選：
阿裡雲重磅釋出雲原生資料湖體系。資料湖建構·Data Lake Formation是阿裡巴巴資料湖團隊帶來的最新一站式入湖解決方案，了解更多資訊請加入産品釘釘交流群