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

—2023— B站基于Iceberg构建秒级响应湖仓一体平台的技术实践 李锐—哔哩哔哩—资深开发工程师 背景查询加速智能优化现状 背景 Hive数仓的痛点 •查询性能达不到交互式分析的要求 •出仓链路复杂 •数据冗余 •时效性不好 我们的目标 互联互通 查询高效 使用便捷 湖仓一体架构 Flink 实时ETL 数据优化 Spark 离线ETL Alluxio SDK 实时ETL 交互式分析 Trino IcebergonHDFS Magnus IcebergonHDFS Iceberg表结构 文件级别的元数据管理 开放格式，完善的tablespec定义 查询加速 排序 •Iceberg表在文件级别记录每个列的MinMax统计信息 •可用于planfile时的文件过滤 •数据经过排序后有更好的过滤效果 InterleaveOrder Z-ORDERHilbertCurve 聚集性更好 基于BoundaryIndex的Z-ORDER计算 索引 •多维排序字段越多效果越差 •对于基数较高的字段，文件级别的索引有较好的过滤效果 索引 •BloomFilter •占用空间小 •存在falsepositive、只支持等值查询 •Bitmap •占用空间大 •支持等值和范围查询、精准匹配行号，可进一步skip数据 索引 •BloomRF •分段单调有序哈希函数，支持等值和范围查询 •存在falsepositive •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文件的生成与管理 聚合值的处理 •由于是文件级的聚合，所以查询时还需要对每个文件的聚合结果进行globalmerge •对于可直接累加的聚合值（如MIN、MAX、COUNT），直接存储聚合值 •对于不可直接累加的聚合值（如AVG、COUNT_DISTINCT），存储binary类型的中间结果 查询改写 •判断聚合计算是否符合cube定义 •改写逻辑计划 •TableScan切换到cube模式 仅有部分文件生成Cube •没生成Cube的数据现场计算 •与Cube数据union后再做globalmerge •仅适用于少量文件没有Cube的情况 Star-TreeIndex •参考ApachePinot的实现 •Cube定义选取最细粒度的维度字段 •可响应不同维度组合的查询 •Cube数据量随纬度数量增长 Cube定义 维度字段：Dim1、Dim2、Dim3聚合值：Count Cube数据按照维度字段排序 分层创建star-tree，生成starrecord 根据splitthreshold判断是否创建子节点 Star-TreeIndex 智能优化 目标 •小文件过多？ •数据怎么排序？ •提前预计算？ •常用过滤字段？ •常用聚合维度和统计项？ •我需要一个Iceberg表 大数据专家 自动化 智能化 Magnus服务 •后台优化 Magnus服务 •Iceberg表详情展示 Magnus服务 •智能推荐 Magnus服务 •智能推荐 现状 主要场景 •BI报表 •指标服务 •A/BTest •人群圈选 •日志 落地情况 •Iceberg表 •总量5PB •日增75TB •Trino查询 •20万/天 •P95响应时间5s •过滤数据量（估算）500TB/天，占比100%~200% 感谢您的观看 李锐—哔哩哔哩—资深开发工程师