JindoFS：雲原生的大數據計算存儲分離方案

JindoFS：雲原生的大數據計算存儲分離方案

JindoFS 以前

在 JindoFS 以前，雲上客戶主要使用 HDFS 和 OSS/S3 做爲大數據存儲。HDFS 是 Hadoop 原生的存儲系統，10 年來，HDFS 已經成爲大數據生態的存儲標準，可是咱們也能夠看到 HDFS 雖然不斷優化，可是 JVM 的瓶頸也始終沒法突破，社區後來從新設計了 OZone。OSS/S3 做爲雲上對象存儲的表明，也在大數據生態進行了適配，可是因爲對象存儲設計上的特色，元數據相關操做沒法達到 HDFS 同樣的效率；對象存儲給客戶的帶寬不斷增長，可是也是有限的，一些時候較難徹底知足用戶大數據使用上的需求。

Jindo 的由來

EMR Jindo 是阿里雲基於 Apache Spark / Apache Hadoop 在雲上定製的分佈式計算和存儲引擎。Jindo 原是內部的研發代號，取自筋斗(雲)的諧音，EMR Jindo 在開源基礎上作了大量優化和擴展，深度集成和鏈接了衆多阿里雲基礎服務。阿里雲 EMR (E-MapReduce) 在 TPC 官方提交的 TPCDS 成績，也是使用 Jindo 提交的。

http://www.tpc.org/tpcds/results/tpcds_perf_results.asp?resulttype=all

JindoFS

EMR Jindo 有計算和存儲兩大部分，存儲的部分叫 JindoFS。JindoFS 是阿里雲針對雲上存儲定製的自研大數據存儲服務，徹底兼容 Hadoop 文件系統接口，給客戶帶來更加靈活、高效的計算存儲方案，目前已驗證支持阿里雲 EMR 中全部的計算服務和引擎：Spark、Flink、Hive、MapReduce、Presto、Impala 等。Jindo FS 有兩種使用模式，塊存儲模式和緩存模式。下面咱們來分析下，JindoFS 是如何來解決大數據上的存儲問題的。

塊存儲模式

計算和存儲分離是業界的趨勢，OSS 這樣的雲上存儲能力是無限大的，成本上很是有優點，如何利用 OSS 提供的無限存儲能力，同時又高效地操做文件系統的元數據。JindoFS 塊存儲模式提供了一套完整的雲原生解決方案。

JindoFS 的塊存儲模式，在元數據上使用 JindoNameService 服務管理 Jindo 文件系統元數據，元數據操做的性能和體驗上能夠對標 HDFS NameNode。同時，JindoStorageService 保障了數據能夠始終有一份存在 OSS 上，即便數據節點被釋放，數據也能夠隨時從 OSS 上拉取，成本上也能夠作到更加靈活。

JindoFS 的塊存儲模式，也支持多種存儲策略，好比，本地存兩份，OSS上存一份；本地存兩份，OSS上不存儲；本地不存，OSS上存一份等等。用戶能夠充分利用不一樣的存儲策略根據業務或者數據冷熱進行使用。

塊存儲使用了全新的 jfs:// 格式，原始 HDFS/OSS 數據經過 distcp 方式便可完成數據導入，同時，JindoFS 提供了 SDK，在 EMR 集羣外部，用戶也能夠讀寫 Jindo FS。

緩存模式

緩存模式，正如「緩存」自己的含義，經過緩存的方式，在本地集羣基於 JindoFS 的存儲能力構建了一個分佈式緩存服務，遠端的數據能夠保存在本地集羣，使遠端數據變成「本地化」。簡單地描述 JindoFS 緩存模式解決的問題
就是「OSS / 遠端HDFS 已經有了大量數據，每次讀數據的時候網絡帶寬常常被打滿，Jindo FS 就能夠經過緩存模式優化網絡帶寬的限制。」

「原來的文件路徑是 oss://bucket1/file1 或 hdfs://namenode/file2，不想改做業的路徑能夠嗎？」。是的，不須要修改。EMR 對 OSS 進行了適配（後續會支持遠端 HDFS 的場景），能夠經過配置的方式使用緩存模式。緩存對於上層的做業作到了徹底無感。

可是緩存模式也不是萬能的，爲了保證多端數據一致性，rename 這種操做必定要同步刷新到遠端的 OSS / HDFS，特別是 OSS 的Rename 操做比較耗時，緩存模式對 rename這種文件元數據操做暫時不能優化。

總結

在 2019 年的雲棲大會上，EMR Jindo 的技術存儲分離方案獲得很大的關注，後續咱們也會在雲棲社區和釘釘羣分享更多的 Jindo 技術乾貨，歡迎有興趣的同窗加入 《Apache Spark技術交流社區》進行交流和技術分享。

 

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。