StarRocks x Iceberg:探索Lakehouse架构极致查询性能

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 王云霏
2.
3. 目录
4. WHY LAKEHOUSE ?
5. 核心优势 BI、 Reports AI、 ML 核心优势 1. 数据质量 1. 统一入湖 2. 查询性能 2. 开放访问 3. 事务支持 问题与挑战 问题与挑战 1. 数据类型多样化 1. 复杂的ETL链路, 2. 成本与扩展性 2. 降低时效性 3. 高级数据分析(AI) 3. 数据一致性,冗余存储
6.
7. Lakehouse的业务价值 One data, all analytics 1. 开放统一的数据存储, Single source of truth Batch Stream 2. 一份数据,多样化的Workload, 服务企业AI、BI的数据应用 3. 原生存算分离,弹性计算实现 极高性价比 Metadata、Caching、Index data Analytics
8. HOW LAKEHOUSE ?
9. Storage Object Storage 作为统一存储底座 开放的数据存储格式 Catalog 数据以 Catalog 形式向上层提供 统一的数据访问控制、数据治理 Engine 计算引擎解决各个场景的需求 追求性价比
10. BI、Report AI、ML 数据工程师 无需维护复杂 ETL Pipeline 数据分析师 实时高效的在数据湖上进行探索分析 数据科学家 直接访问开放数据,构建 AI 应用 企业经营/管理者 简单高效的数据分析驱动企业经营决策
11. 架构简单,性能强悍 StarRocks BE StarRocks BE StarRocks BE
12. 1. 无需维护额外的 ETL pipeline, 小红书 2. 存储成本下降 50% 3. 查询性能提升3倍,P90 延时降到10s量级 离线/近实时场景 微信 实时场景 数据直接入Iceberg,时效性10分 钟级,查询响应亚秒级 数据入StarRocks,将冷至 Iceberg,数据新鲜度秒级
13. HOW ABOUT LAKEHOUSE ?
14. CBO优化器 千军易得,良将难求 向量化执行引擎 将士用命,以一当三 CBO 优化器 向量化 引擎 MPP执行框架 韩信点兵,多多益善 MPP执行框架
15. metadata解析开销大 冷数据IO访问开销大 字符串处理开销大 极高并发 缺少统计信息 Cache不够smart 文件解析开销大 极低延迟
16. 痛点:元数据解析开销大 元数据规模较大时: ⚫ Plan阶段耗时过长, ⚫ 对FE节点的CPU和内存依赖过重 ⚫ Iceberg Job Planing耗时显著增加 Distributed MetaData Plan ⚫ 消除FE性能瓶颈 ⚫ 元数据解析性能提升n倍
17. 痛点:Data Lake统计信息不足导致plan严重恶化 查询触发统计信息收集 Optimizer get table statistics ConnectorTableCacheSt ats invalid outdated collectStatistics cache add pending task PendingTaskQue ue RunningTask Queue
18. 痛点:冷数据IO访问开销大 ●数据copy开销 ●网络客户端收发开销 针对AWS客户端进行优化,可以支持所有S3兼容的对象存储 ●zero-copy ●poco client poco ●poco 连接池 default network bandwidth improvement:13% + 11% poco default cpu usage
19. 痛点:Cache很好,但是不够smart ⚫ 手动预热 ⚫ 周期预热 ●访问频次不高,但是延迟敏感
20. 痛点:Cache很好,但是不够smart ● 磁盘已达瓶颈,远端访问也许更快 ⚫ IO自适应 adaptive io Executor OSS/Hdfs busy insert into blackhole() select * from lineitem; Local Cache 353GB->188G远端访问,38s 优化前 88s
21. 痛点:Cache很好,但是不够smart ● 弹性场景,cache miss引起的性能抖动 Cache Sharing Queries • 无需额外硬件成本,节点间缓存共享 • 降低增删节点时延时抖动 • 请求自适应,改善集群资源瓶颈 Origin Nodes New Nodes BE cache read cache cache BE cache BE read cache BE cache BE cache S3/HDFS
22. 痛点:字符串执行效率低 ●难以向量化 ●内存占用高 ●传递开销大 数据分析场景的字符串~80%是低基数字符串 低基数优化 select sum(lo_revenue) from lineorder_flat group by c_city; “shanghai”, 200 “beijing”, 100 “shenzhen”, 100 beijing 1 shanghai 2 shenzhen 3 2, 200 “beijing”, 200 1, 100 3, 100 1, 200 HashMap<string, result> HashMap<int, result>
23. 低基数优化 ●开箱即用,轻量采样 improvement:2~5x ① Query ●自动重试,用户无感 LowCard DictManager ●自动增强,错误自限 Trigger Sample Check Version Try LowCardOpt Rewrite Plan Execution return result ③ Supplement Dict Encounter Error
24. 痛点:文件解析开销大 ●数据量大 Native Parquet Reader Index: select * from table where c1 = ‘xxx’ or c2 > ‘yyy’; ⚫ RowGroup Statistics ⚫ PageIndex ⚫ Bloom Filter ⚫ 析取谓词 or ⚫ 合取谓词 and
25. 痛点:文件解析开销大 ●数据量大 Native Parquet Reader 延迟物化: 高效谓词优先 Filter下推至Decoder select * from table where name = ‘wangwu’ and district = ‘haidian’;
26. 痛点:文件解析开销大 Native Parquet Reader 向量化: ⚫ 精细的SIMD调优 ●数据量大
27. 痛点:部分场景并发特别高,延迟要求特别低,能否通过Lakehouse满足需求? 物化视图 ●自动查询改写 ●全生命周期管理 User ⚫ 基于物化视图查询改写透明加速 ⚫ 支持Aggregate, Join, Union等查询 query ⚫ 构建外表物化视图,简化数据处理流程 rewrite query to query mv instead query result Materialize it!!! orders product s Materialized View
28. 物化视图 ●预计算 fact ●增量计算 ●re-distribution shuffle join dimension P1 P2 T1 Pn T2 Distributed by join key Distributed by join key MV2 MV1 P1 P2 Pn MV colocate join
29. StarRocks速度快,加速度也很快 StarRocks tpcds性能达到databricks photon 2倍 StarRocks vs Photon 35000 30000 25000 20000 15000 10000 5000 0 Photon StarRocks 4*m7gd4x, warmup,1concurrency, 1TB tpcds parquet, iceberg vs delta lake
30. StarRocks速度快,加速度也很快 3.5版本相比3.3版本ssbflat性能提升50%+ StarRocks 3.5 vs 3.3 90,000 80,000 70,000 60,000 50,000 40,000 30,000 20,000 10,000 0 Q01 Q02 Q03 Q04 Q05 Q06 Q07 3.3 3.5 8*i3en2x, no-cache,10concurrency, 1TB ssbflat parquet Q08 Q09 Q10 Q11 Q12 Q13
31. WHAT WILL BE?
32. 更快 持续优化查询性能,Query On Lake简化业务流程,提供极致性价比 1. cache zero-copy & decompressed cache 2. 完善cache内存自适应调整 3. 持续优化基础算子 更全能 服务更多场景,降低运维成本 1. Iceberg data maintain, 完善DDL、DML和写Iceberg的能力 2. 完善StarRocks Iceberg Rest Catalog鉴权体系 3. StarRocks服务于AI Agent和LLM Post-Training的SQL engine
33.
34. 大模型正在重新定义软件 Large Language Model Is Redefining The Software

首页 - Wiki
Copyright © 2011-2025 iteam. Current version is 2.147.0. UTC+08:00, 2025-10-28 23:06
浙ICP备14020137号-1 $访客地图$