高性能、云原生湖仓体存储架构探秘

湖仓一体存储架构的演进与JuiceFS实践

大数据存储系统的演进

• HDFS：起源于GFS，2006年发布，采用独立元数据存储（NameNode）和树形结构，支持多副本数据存储，数据分块不可修改，存算耦合架构，适合存储大文件（约2亿文件数）。
• 对象存储：2006年发布S3，以海量非结构化数据存储为目标，支持万亿级文件数，大小文件均适合，低廉存储成本（支持EC），高可靠持久性（11个9），基于HTTP协议的RESTful API，KV结构元数据，数据不支持修改，最终一致性。

不同类型存储系统比较

HDFS vs. 对象存储

• HDFS的阿喀琉斯之踵——NameNode：
  • 存储瓶颈：单一命名空间下NameNode性能瓶颈。
  • 联邦架构：1.0（ViewFs+多集群），2.0（Router-based Federation，RBF）。
  • 高可用架构：Quorum Journal Manager（QJM）。
• 对象存储的阿喀琉斯之踵——元数据：
  • 元数据操作性能及一致性问题。
  • 重命名操作步骤：递归拷贝数据、更新索引、删除原路径数据，一致性保证挑战。
  • 元数据性能及API限制：List性能差（HudiMetadataTable），API QPS限制（IcebergObjectStorageLocationProvider）。

探索湖仓一体架构未来的存储选型

目标

• 扩展性好
• 高可用
• 高性能
• 弹性伸缩
• 存算分离
• 海量小文件管理
• 云原生
• 多种类型API

技术关键点

• 扩展性好
• 高可用
• 数据可靠
• 高性能
• 弹性伸缩
• 存算分离
• 海量小文件管理
• 云原生
• 多种类型API

JuiceFS

• 强一致性分布式文件系统
• 插件式元数据引擎
• 使用对象存储作为数据存储
• 元数据引擎可横向扩展
• 小文件友好的元数据设计
• 本地多级缓存
• 多种类型客户端
• 完全兼容POSIX
• 完全兼容HDFS API

湖仓一体架构在JuiceFS上的实践

元数据性能比较

• 使用NNBench（多线程测试）进行性能测试，3台阿里云4核16G虚拟机，CDH 5，HDFS 2.6环境，HDFS使用3个JournalNode高可用配置，OSS使用内网接口访问。

数据查询性能比较

• 左图：3台计算节点（4核CPU、16G内存、200G x 2硬盘），100GB TPC-DS数据集，Spark SQL基准测试。
• 右图：5台计算节点（8核CPU、32G内存、5500G x 4硬盘），PrestoSQL 3.3，1TB TPC-DS数据集，JuiceFS启用缓存并充分预热。