B站基于Iceberg构建秒级响应湖仓一体平台的技术实践

B站基于Iceberg构建秒级响应湖仓一体平台的技术实践 李锐—哔哩哔哩—资深开发工程师 智能优化 现状 背景 背景 Hive数仓的痛点 •查询性能达不到交互式分析的要求•出仓链路复杂•数据冗余•时效性不好 我们的目标 查询高效 使用便捷 湖仓一体架构 Iceberg表结构 Ø文件级别的元数据管理Ø开放格式，完善的tablespec定义 查询加速 排序 •Iceberg表在文件级别记录每个列的MinMax统计信息•可用于planfile时的文件过滤•数据经过排序后有更好的过滤效果 InterleaveOrder HilbertCurve聚集性更好 基于Boundary Index的Z-ORDER计算 索引 •多维排序字段越多效果越差 •对于基数较高的字段，文件级别的索引有较好的过滤效果 索引 •BloomFilter •占用空间小 •存在false positive、只支持等值查询 •Bitmap •占用空间大 •支持等值和范围查询、精准匹配行号，可进一步skip数据 索引 •BloomRF •分段单调有序哈希函数，支持等值和范围查询•存在false positive •TokenBloomFilter、NgramBloomFilter •分词后构造BloomFilter索引•用于日志场景 •TokenBitmap、NgramBitmap•分词后构造Bitmap索引•用于日志场景 预计算 •Cube/AggIndex，针对聚合计算•支持单表和星型模型•定义维度字段、聚合值•支持Count、Min、Max、Sum、Avg、Count_Distinct、Percentile、TopN等聚合函数•文件级别聚合 预计算 •维度字段（关联列）：d_year，p_brand，s_region•聚合值：sum(lo_revenue) Cube文件的生成与管理 聚合值的处理 •由于是文件级的聚合，所以查询时还需要对每个文件的聚合结果进行global merge•对于可直接累加的聚合值（如MIN、MAX、COUNT），直接存储聚合值•对于不可直接累加的聚合值（如AVG、COUNT_DISTINCT），存储binary类型的中间结果 查询改写 •判断聚合计算是否符合cube定义•改写逻辑计划•TableScan切换到cube模式 仅有部分文件生成Cube •没生成Cube的数据现场计算•与Cube数据union后再做globalmerge•仅适用于少量文件没有Cube的情况 Star-TreeIndex •参考ApachePinot的实现•Cube定义选取最细粒度的维度字段•可响应不同维度组合的查询•Cube数据量随纬度数量增长 Star-TreeIndex Cube定义维度字段：Dim1、Dim2、Dim3聚合值：Count Cube数据按照维度字段排序分层创建star-tree，生成starrecord根据split threshold判断是否创建子节点 智能优化 目标 Magnus服务 •后台优化 Magnus服务 •Iceberg表详情展示 Magnus服务 •智能推荐 Magnus服务 •智能推荐 现状 主要场景 •BI报表•指标服务•A/B Test•人群圈选•日志 落地情况 •Iceberg表•总量5PB•日增75TB •Trino查询 •P95响应时间5s 感谢您的观看 李锐—哔哩哔哩—资深开发工程师