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.