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

《高性能、云原生湖仓体存储架构探秘.pdf》由会员分享，可在线阅读，更多相关《高性能、云原生湖仓体存储架构探秘.pdf（22页珍藏版）》请在三个皮匠报告上搜索。

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 T