Iceberg 湖仓一体在 B 站的实践 - 李锐

背景

• 湖仓一体的必要性：传统数据出仓链路复杂且维护麻烦，存在数据冗余、口径不一致问题，未出仓数据查询性能无法满足交互式分析需求，Hive数仓实时性差（仅天级或小时级分区）。
• 数据湖到湖仓一体的演化：从数据湖逐步发展为湖仓一体架构。
• 选择Iceberg的原因：支持文件级别元数据管理、基于Snapshot的事务支持、开放格式及良好的存储格式抽象和定义。
• 湖仓一体的目标：实现无限容量、开放格式、流批读写高效、数据优化、索引加速，接近分布式数仓性能，并降低使用门槛。

查询加速

• 优化思路：通过多维分析常见模式（关联→过滤→聚合→排序）和大宽表或星型模型，尽可能过滤掉不需要的数据。
• 数据排序组织：Iceberg记录每个列的Min/Max统计信息，过滤效果依赖于过滤字段的值在文件中的聚集效果。
  • Linear Order：仅对第一个排序字段有较好聚集效果。
  • Interleave Order：Z-ORDER通过映射不同数据类型为正整数参与计算，基于Boundary Index的Z-ORDER（Hilbert曲线）聚集性更好，但排序字段越多聚集性越差（一般不超过4个）。
• 索引：判断文件数据是否满足过滤条件，每个索引针对一个字段，一张表可定义多个索引。
  • Bloomfilter索引：计算简单、占用空间小，但存在False Positive，适用于等值过滤。
  • Bitmap索引：适用于等值和范围过滤，无False Positive，但占用空间大、加载开销大。
• SSB测试：1TB大宽表模式下的性能表现。
• 星型模型优化：通过维表字段对事实表进行过滤，关联列定义在事实表上，是一种虚拟列，可通过关联维表得到，Join Key需满足PK-FK或UNIQUE约束。
  • 关联列：使用与普通列相似，数据不保存到事实表，可基于关联列做排序和索引，查询引擎负责将过滤条件下推到事实表。
• 测试结果：星型模型预计算（Cube/AggIndex）在事实表上定义维度字段和聚合值，文件级聚合，查询时需对聚合结果进行global merge。

智能化服务

• Magnus服务：提供智能化分析能力。
• 需求：通过自动化服务提升查询效率和用户体验。

总结与展望

• 总结：排序和索引功能已在B站落地，支持10万查询/天，P95响应时间约5秒，平均扫描数据量80 million。
• 未来工作：推进预计算落地及增强，自动生成Cube文件，支持部分数据生成Cube时的查询响应，智能化创建索引和Cube，增强UPSERT能力打造近实时湖仓。