高性能、云原生湖倉體存儲架構探秘.pdf

1、高性能、云原生湖倉一體存儲架構探秘?Juicedata?2023目錄湖倉一體存儲架構的演進不同類型存儲系統比較探索湖倉一體架構未來的存儲選型湖倉一體架構在 JuiceFS 上的實踐01湖倉一體存儲架構的演進大數據存儲系統的演進HDFS?云原、性能存儲系統機房時代云計算時代HDFS 起源于 GFS（Google File System），2006 年正式發布 獨元數據存儲（NameNode），樹形結構元數據 多副本數據存儲（DataNode）數據分塊存儲（Block），不可修改 存算耦合架構（HDFS+YARN）適合存儲件，2 億左右的件數對象存儲 S3 于 2006 年發布 以存儲海量結構化數

2、據為標 能撐萬億級件數，件均適合 低廉的存儲成本（持 EC），可靠的數據持久性（11 個 9）基于 HTTP 協議的 RESTful API KV 結構的元數據設計 數據不持修改 最終致性02不同類型存儲系統比較HDFS vs.對象存儲HDFS對象存儲存儲規模（單 namespace）億級 萬億級致性 強致性部分強致性容量管理動 彈性原重命名 持不持List 性能 低隨機寫不持不持緩存加速不持不持運維復雜度 低HDFS API 兼容性-部分兼容Hadoop 態權限管理兼容性-不兼容POSIX 兼容性不持部分兼容（需第三組件）HDFS 的阿喀琉斯之踵NameNode 單命名空間下的 NameNo

3、de存儲瓶頸 聯邦架構 1.0：ViewFs+多集群 聯邦架構 2.0：Router-based Federation（RBF）https:/hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs-rbf/HDFSRouterFederation.htmlHDFS 的阿喀琉斯之踵NameNode NameNode 的單點問題 可架構：Quorum Journal Manager（QJM）https:/ 元數據操作的性能以及致性問題如何實現重命名？mv/foo/bar對象存儲的阿喀琉斯之踵元數據 步驟 1：遞歸拷數據 步驟 2：

4、更新索引 步驟 3：刪除原路徑中的數據 致性如何保證？對象存儲元數據性能及 API 限制 List 性能差：Hudi Metadata Table API QPS 限制：Iceberg ObjectStorageLocationProvider件數對象存儲 List P50 延遲10050ms1K131ms10K1062ms100K9932mshttps:/hudi.apache.org/docs/metadatahttps:/iceberg.incubator.apache.org/docs/latest/aws/#object-store-file-layout03探索湖倉一體架構未來的存

5、儲選型目標 擴展性好 可 性能 彈性伸縮 存算分離 海量件管理 云原 多種類型 API技術關鍵點 擴展性好 可 數據可靠 性能 彈性伸縮 存算分離 海量件管理 云原 多種類型 API 不存在擴展瓶頸 不存在單點，動故障切換 冗余機制保證數據可靠性 針對件系統設計的獨元數據 數據存儲組件容易橫向伸縮 緩存加速，分布式緩存，緩存親和性 元數據存儲結構優化 充分利云上資源 針對不同 API 實現不同客戶端JuiceFS 強致性分布式件系統 插件式元數據引擎 使對象存儲作為數據存儲 元數據引擎可橫向擴展 件友好的元數據設計 本地多級緩存 多種類型客戶端 完全兼容 POSIX 完全兼容 HDFS API

6、04湖倉一體架構在 JuiceFS 上的實踐湖倉一體架構元數據性能比較使 Hadoop 中專于壓測件系統元數據性能的組件 NNBench，將其單線程測試測試任務改成多線程，便于增加并發壓。使 3 臺阿云 4 核 16G 的虛擬機，CDH 5，HDFS 2.6 作為測試環境。HDFS 使 3 個 JournalNode 的可配置，使內 IP。OSS 使內接訪問。數據查詢性能比較左圖：使阿云 3 臺計算節點 4 核 CPU、16G 內存、200G x 2 硬盤，使 100GB TPC-DS 數據集，通過 Spark SQL 進基準測試。右圖：使阿云 5 臺計算節點 8 核 CPU、32G 內存、5500G x 4 硬盤，PrestoSQL 334，使 1TB TPC-DS 數據集。以上測試中 JuiceFS 啟了緩存，并使數據充分預熱。感謝您的觀看https:/