Iceberg 湖仓一体在 B 站的实践

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. Iceberg 湖仓一体在 B 站的实践 李锐
2.
3. 目录 • • • • 背景 查询加速 智能化服务 总结与展望
4. 背景
5. 为什么需要湖仓一体
6. 为什么需要湖仓一体 • • • • 数据出仓链路复杂,维护麻烦 数据冗余,口径不一致 未出仓数据查询性能达不到交互式分析的要求 Hive数仓实时性不好,只能做到天级或小时级分区
7. 数据湖到湖仓一体的演化
8. 数据湖到湖仓一体的演化
9. 为什么选择Iceberg • • • 文件级别的元数据管理 基于Snapshot的事务支持 开放格式,良好的存储格式抽象和定义
10. 湖仓一体的目标 灵活 •无限容量 •开放格式 •流批读写 高效 便捷 •数据优化 •索引加速 •接近分布式 数仓的性能 •自动优化 •智能分析 •降低使用门 槛
11. 查询加速
12. 优化思路 • • • 多维分析的常见模式:关联  过滤  聚合  排序 大宽表或者星型模型 如何尽可能过滤掉不需要的数据
13. 数据排序组织 • • Iceberg记录每个列的Min/Max统计信息 过滤效果取决于过滤字段的值在文件中的聚集效果 如何对过滤字段进行聚集? DataFile统计信息 ColumnSizes col1: …, col2: …, … ValueCounts col1: …, col2: …, … LowerBounds col1: …, col2: …, … UpperBounds col1: …, col2: …, …
14. Linear Order的问题 • 仅对第一个排序字段有较好的聚集效果 SSB Benchmark
15. Interleave Order • Z-ORDER 如何把不同数据类型映射成正整数参与计算?
16. 基于Boundary Index的Z-ORDER计算 • • • • 映射值需要保序 映射值的分布需要统一 对参与计算的字段划分boundary 根据boundary index计算z-value
17. 基于Boundary Index的Z-ORDER计算
18. Hilbert曲线 Z-ORDER Hilbert Curve 聚集性更好
19. 过滤效果 Z-ORDER 排序字段越多,聚集性越差,一般不超过4个 Hilbert Curve
20. 索引 • • • 判断一个文件中的数据是否满足某个过滤条件 对于高基数过滤字段,无需排序也能实现较好的过滤效果 每个索引针对一个字段,一张表可以定义多个索引
21. Bloomfilter索引 • • • • 计算简单 占用空间小 存在False Positive 只适用于等值过滤条件
22. Bitmap索引 • • • 适用于等值和范围过滤条件 不存在False Positive 占用空间大,加载索引的开销较大
23. SSB测试 • 1TB,大宽表模式
24. 星型模型 • • • 大多过滤条件在维表上 维表上的过滤条件有较高的Selectivity 但是过滤后的join key取值范围较大
25. 星型模型 能否通过维表字段 对事实表进行过滤?
26. 关联列 • • • • 定义在事实表上 是一种虚拟列 通过关联维表得到 Join Key需满足PK-FK或UNIQUE约束
27. 关联列 • • • 使用与普通列相似:name、type、id 关联列的数据不会保存到事实表中 可以基于关联列做排序和索引
28. 关联列 • 查询引擎负责将关联列的过滤条件下推到事实表中
29. 测试结果
30. 星型模型预计算 • • • • 多维分析的常见模式:关联  过滤  聚合  排序 Cube/AggIndex,定义在事实表上 定义维度字段、聚合值 文件级别聚合
31. 星型模型预计算 • • 维度字段(关联列):d_year,p_brand,s_region 聚合值:sum(lo_revenue)
32. Cube文件的生成与管理
33. 聚合值的处理 • • • 由于是文件级的聚合,所以查询时还需要对每个文件的聚合结 果进行global merge 对于可直接累加的聚合值(如MIN、MAX、COUNT),直接 存储聚合值 对于不可直接累加的聚合值(如AVG、 COUNT_DISTINCT),存储binary类型的中间结果
34. 查询改写 • • • 判断聚合计算是否符合cube定义 改写逻辑计划 事实表切换到cube模式
35. 测试结果
36. 智能化服务
37. 为什么需要智能化服务
38. Magnus服务
39. 总结与展望
40. 总结 • • • • • 排序和索引功能已在B站落地 更好的用数取数体验 10w查询/天 P95响应时间: ~5s 平均扫描数据量:80 million
41. 未来工作 • • • • • 推进预计算的落地以及增强 自动根据聚合效果判断是否生成cube文件 支持在只有部分数据生成cube文件时响应查询 智能化分析常用过滤字段、查询模式,自动创建索引、cube等 增强UPSERT能力,打造近实时湖仓
42.
43.

ホーム - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-15 14:40
浙ICP备14020137号-1 $お客様$