杨关锁-StarRocks x Iceberg 云原生湖仓分析技术揭秘与最佳实.pdf

《杨关锁-StarRocks x Iceberg 云原生湖仓分析技术揭秘与最佳实.pdf》由会员分享，可在线阅读，更多相关《杨关锁-StarRocks x Iceberg 云原生湖仓分析技术揭秘与最佳实.pdf（33页珍藏版）》请在三个皮匠报告上搜索。

1、StarRocks x Iceberg：云原生湖仓分析技术揭秘与最佳实践演讲人：杨关锁 镜舟科技研发工程师StarRocks Lakehouse架构介绍01StarRocks x Iceberg 极致性能揭秘02StarRocks x Iceberg最佳实践03近期规划04目 录CONTENTSStarRocks Lakehouse架构介绍什么是LakehouseLakehouse兼具数据湖、数据仓库优势一种新的架构范式，而非简单湖仓组合业务价值开放统一的数据存储，Single source of truth基于一份数据，支持多样化的 Workload，服务企业 AI、BI 的数据应用AIBI

2、BatchStreamingAnalyticsData lake如何构建LakehouseSTORAGEObject Storage 作为统一存储底座开放的数据存储格式CATALOG数据以 Catalog 形式向上层提供统一的数据访问控制、数据治理ENGINES计算引擎解决各个场景的需求CATALOGIcebergPaimonHiveHudiData lakeObject StorageSparkFlinkStarRocksSTORAGEENGINES基于StarRocks构建Lakehouse直接查询物化视图透明加速Lakehouse对比项Data PipelineETL 作业同步数据无须维

3、护 ETL 作业Data Reliablity两份数据，口径不一致Single source of truthData Freshness等待数据同步时间数据入湖后即可查询Data Storage Cost冗余数据存储存储一份数据分层架构LakehouseLakehouse架构对比StarRocks x Iceberg 极致性能揭秘StarRocks查询Iceberg基本流程FEBEslice itdata filesscan rangesBEBEHDFS/OSS/S3ParquetORCCSVHMS/Glue1.Get metadata(tables,partions,files.)2.Sl

4、ice files into scan ranges3.Select BE for each scan range4.Assign scan ranges to BE5.Read data from remote storageFetch and parse metadata is slowFile reader is not efficientExecution plan is not optimalRemote IO is slowWhy its not fast enough?Iceberg Metadata Cache性能痛点元数据文件解析慢访问效率低Metadata Cache缓存解

5、析后的元数据支持后台增量刷新Iceberg Distributed Metadata Plan性能痛点Plan阶段耗时过长，特别是元数据文件解析速度慢对FE节点的CPU和内存依赖过重当表的元数据很大时，Iceberg Job Planing耗时显著增加Distributed Metadata PlanIceberg Job Planing性能提升数倍FE节点的内存和CPU开销显著降低Iceberg Job PlaningHow metadata cache and distributed metadata plan works?BEMetaData Managermanifest fileIn

6、-memory deserialized manifest cacheLocal manifest file cache1.检查目标manifest文件是否存在2.检查目标manifest文件是否存在BEBE3.2.执行distributed manifest plan job3.1.直接从远端获取并解析manifest文件4.从远端获取并解析manifest文件 FE检查本地meta cache确定是否触发distributed manifest plan job主要环节统计信息收集统计信息为CBO优化器提供成本的计算参考优化器基于统计信息尽可能选择最优执行计划ParserRelationT