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

高性能、云原生湖仓一体存储架构探秘 怵雷➃넞僅⨴Juicedata䪮助⚁㹻 湖仓一体存储架构的演进 目录 不同类型存储系统比较 探索湖仓一体架构未来的存储选型 湖仓一体架构在JuiceFS上的实践 01 湖仓一体存储架构的演进 大数据存储系统的演进 HDFS •起源于GFS（Google FileSystem），2006年正式发布•独⽴元数据存储（NameNode），树形结构元数据•多副本数据存储（DataNode）•数据分块存储（Block），不可修改•存算耦合架构（HDFS + YARN）•适合存储⼤⽂件，2亿左右的⽂件数 对象存储 •S3于2006年发布•以存储海量⾮结构化数据为⽬标•能⽀撑万亿级⽂件数，⼤⼩⽂件均适合•低廉的存储成本（⽀持EC），可靠的数据持久性（11个9）•基于HTTP协议的RESTful API•KV结构的元数据设计•数据不⽀持修改•最终⼀致性 02 不同类型存储系统比较 HDFS vs.对象存储 HDFS的阿喀琉斯之踵——NameNode •单⼀命名空间下的NameNode存储瓶颈•联邦架构1.0：ViewFs+多集群•联邦架构2.0：Router-basedFederation（RBF） HDFS的阿喀琉斯之踵——NameNode •NameNode的单点问题•⾼可⽤架构：Quorum JournalManager（QJM） 对象存储的阿喀琉斯之踵——元数据 •元数据操作的性能以及⼀致性问题 如何实现重命名？mv/foo/bar 对象存储的阿喀琉斯之踵——元数据 •步骤1：递归拷⻉数据•步骤2：更新索引•步骤3：删除原路径中的数据•⼀致性如何保证？ 对象存储元数据性能及API限制 •List性能差：HudiMetadataTable•APIQPS限制：IcebergObjectStorageLocationProvider 03 探索湖仓一体架构未来的存储选型 目标 •扩展性好 •⾼可⽤ •⾼性能 •弹性伸缩 •存算分离 •海量⼩⽂件管理 •云原⽣ •多种类型API 技术关键点 •扩展性好•⾼可⽤•数据可靠•⾼性能•弹性伸缩•存算分离•海量⼩⽂件管理•云原⽣•多种类型API •不存在扩展瓶颈•不存在单点，⾃动故障切换•冗余机制保证数据可靠性•针对⽂件系统设计的独⽴元数据•数据存储组件容易横向伸缩•缓存加速，分布式缓存，缓存亲和性•元数据存储结构优化•充分利⽤云上资源•针对不同API实现不同客户端 JuiceFS •强⼀致性分布式⽂件系统•插件式元数据引擎•使⽤对象存储作为数据存储•元数据引擎可横向扩展•⼩⽂件友好的元数据设计•本地多级缓存•多种类型客户端•完全兼容POSIX•完全兼容HDFS API 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硬盘，PrestoSQL334，使⽤1TBTPC-DS数据集。以上测试中JuiceFS启⽤了缓存，并使数据充分预热。 感 谢 您 的 观 看 https://github.com/juicedata/juicefs