1-5 李呈祥-哔哩哔哩OLAP平台引擎演进实践.pdf

《1-5 李呈祥-哔哩哔哩OLAP平台引擎演进实践.pdf》由会员分享，可在线阅读，更多相关《1-5 李呈祥-哔哩哔哩OLAP平台引擎演进实践.pdf（24页珍藏版）》请在三个皮匠报告上搜索。

1、哔哩哔哩OLAP平台引擎演进实践演讲人：李呈祥01OLAP平台介绍03湖仓一体02ClickHouse04总结目录|两年前的OLAP场景状态|1.业务分散自建2.没有统一OLAP平台建设3.缺乏完善的接入工具和标准4.多种OLAP引擎并存，维护使用成本高阶段一：数据服务引擎收敛到ClickHouse|Why ClickHouse？|1.性能强大2.功能丰富3.支持各种场景4.业界大规模使用，社区活跃，稳定可靠。典型的使用场景：1.用户行为分析2.人群圈选3.Up主/稿件分析案例一：用户行为分析平台|用户行为分析平台的业务特点：1.数据量超大，超千亿条数据/天。2.大量天/周/月级别的分组UV统

2、计/留存/漏斗/路径/用户分群分析等。3.数据业务来源较多，公共属性字段和业务私有属性字段并存。64节点ClickHouse集群5PB数据量P90 4s响应案例一：用户行为分析平台|ClickHouse BulkLoad：1.将写入资源消耗移出ClickHouse，为查询提供稳定的资源保证。2.Spark任务可scale-out扩展，不受clickhouse节点限制。问题一：超大规模数据写入导致的CK集群稳定性问题。案例一：用户行为分析平台|主要的性能优化手段：1.统一的UserID字典映射，从String映射为bigint2.By UserID分shard存储，将分布式Count Disti

3、nct转化为Local Count Distinct。3.通过数据聚合物化，将UV/漏斗/人群分组等操作转化为RoaringBitMap的交并差计算。问题二：如何达到交互式的查询性能。B站基于ClickHouse的海量用户行为分析应用实践阶段二：文本检索迁移到ClickHouse|ES部分场景的迁移|文本检索搜索排序案例二：日志平台|基于ElasticSearch日志平台的相关问题：1.写吞吐量上有着明显的瓶颈，分词耗CPU且难以解决热点问题。2.由于压缩率不高的原因，ES的存储成本较高，对内存有着较高的要求3.数据分析能力较弱，入一份数据进大数据平台代价又太大。案例二：日志平台|日志平台从E

4、lasticSearch迁移到ClickHouse的收益写入性能提升10倍存储成本降低至1/3结构化字段查询性能提升2倍P90 3s案例二：日志平台|ClickHouse内核层面主要的增强MapV2隐式列B站基于Clickhouse的下一代日志体系建设实践ClickHouse使用情况|业务场景涵盖：1.用户行为分析2.人群圈选3.广告DMP4.电商交易分析5.OGV内容分析6.日志/Trace分析千万查询/天超万亿条写入/天P90 200ms读写访问模式涵盖：1.多维分析2.文本检索3.中低频点查4.时序数据5.CDC更新6.灵活Schema阶段三：湖仓一体降本增效|OLAP降本增效方向 湖仓

5、一体|什么是湖仓一体？1.开放的查询引擎（Spark/Presto/Trino）2.开放的存储格式（Iceberg）3.统一的存储和元数据管理（HDFS/HMS）4.高阶数仓引擎的能力（data clustering/索引/预计算/实时/upsert）湖仓一体的架构|数据接入：Spark（离线），Flink（实时）数据管理：Magnus/Spark 数据缓存：Alluxio 查询引擎：Trino异步的数据组织优化。基于策略的数据组织优化任务调度湖仓一体适用场景|离线分析OLAP引擎湖仓一体收益：1.更好的查询性能。2.ACID。3.数据近实时可见。收益：1.无需数据同步冗余。2.计算存储分离。

6、3.工具链完备。场景：1.BI报表。2.近实时分析。3.数仓分析层建模。场景：1.历史数据低频访问。2.低成本数据副本。3.低频秒级数据服务。湖仓一体的增强|Data Clustering 文件间和文件内排序 Z-Order数据排序Index BloomFilter BitMap TokenBloomFilter TokenBitMap预计算 Min/Max/Count/Avg CountDistinct/Approximate Count Distinct TopN湖仓一体