Apache Kylin4 在有赞的应用

1. 数智 · 同行第三届大数据技术沙龙

2. Apache Kylin4 在有赞的应用郑生俊有赞｜数据开发工程师

3.

4. Contents 01 有赞 OLAP 介绍 02 Kylin4 的大幅度性能提升 03 有赞 Kylin4 性能优化 04 参与开源社区

5. 01 有赞 OLAP 介绍有赞 OLAP 的发展历程、遇到的挑战

6. • 技术栈简单 • 学习成本低 • 实时 • 查询灵活预计算 +MySQL 缺点 • 灵活性差 • 开发效率低下 • 性能不足早期 • 聚合度高 • RT 最低 • 支持精确去重 Druid 缺点 • 不支持精确去重 • 聚合度不够高 • 不支持明细 OLAP • 故障 T+1 恢复 2018 Kylin ClickHouse • 实时 / 离线 • 查询非常灵活 now

7. 600w 存量商家 100 亿 + 构建数据年 GMV 1073 亿 300+Cube

8. B 端场景 ( 稳定性、 RT 要求严格)：故障快速恢复单店千万会会、数十万商品复杂查询性能

9. 部门 A 组织架构灵活变动部门 B 客户、部门、员工变动明细好友、粉丝关系变动部门 D 部门 C 部门 - 员工 - 客户拉链表拉链表明细员工 2 员工 1 微信、粉丝建联、失联客户客户部门 A 员工 1 部门 C 员工 1 千万级别粉丝、会员支持上卷、下钻部门 B 员工 1 数仓宽表 KYLIN 树状结构打平趋势、比例分析

10. 能不能支持精确去重？能不能放宽查询时间范围到三年？ RT 控制在两秒以内， QPS 不低与 XXX ！ 1. 通过全局字典编码减小 BitMap 2. 改写查询，利用多个时间聚合维度进行预计算天聚合数据季度聚合表月聚合表天聚合表

11. 02 Kylin4 大幅度性能提升 Kylin4 在有赞 OLAP 场景下的性能提升

12. 1. 平均构建时间从 48min 降低到 10.5min 2. 构建时间降低 78% 优化点： 1. 去掉了维度字典的编码 2. 去掉了 HBase File 生成步骤 3. 全部转换为 Spark 进行构建 4. 基于 Cuboid 的构建划分提升构建并行度

13. 单店数十万商品， 10X 精确去重指标的排序分析 27s -> 2s Kylin2 Kylin4 并发取决于 Region 和 Shard 并发可以与数据无关无法针对单个查询设置（不同数据量的商家、并发相同）灵活设置单个查询并发充分利用 Spark 分布式优势

14.  从 Calcite 的单点执行到基于 Spark 的完全分布式执行  充分利用并行化、向量化、 code gen 等技术  自动调整 Spark 参数优化查询效率  基于 Parquet 的列存替换 HBase 的行存 Sort SortDF Agg AggDF Project ProjectDF Filter Cube 分布式 HBase & Coprocessor FilterDF CuboidDF 基于 Spark DF 完全分布式

15. 03 我们做的优化 Kylin4 在有赞 OLAP 场景下的性能提升

16. 动态消除 Cuboid 分区维度 Cube 有三个 Segment ，分区字段为 p: [20200101-2020201), [20200201-2020301), [20200301-2020307) SQL: Select count(a) from test where p >= 20200101 and p <= 20200306 group by a Aggregate Aggregate Scan 65rows 优化后 Scan 8rows Filter TableScan Cuboid: (a, p) Segments: 20200101~20200201 20200201~20200301 20200301~20200307 Union Filter1 Filter2 TableScan TableScan Cuboid: (a) Segments: 20200101~20200201 20200201~20200301 Cuboid: (a, p) Segments: 20200301~20200307 • 自动消除分区维度选择不同 cuboid ，减少了数十倍的数据读取和计算量。 • 更加高效地支持跨月、跨年的查询

17. 在 Kylin4 中， SQL 首先经过了 Calcite 的解析、优化、代码生成，然后再根据 Calcite 转换为 Spark DataFrame 。在部分场景中， Calcite 的 SQL 解析会消耗 150ms 左右。解决方案：在 Kylin4 中支持 PreparedStatementCache 缓存 Calcite 执行计划，降低该步骤的时间消耗。 SQL Calcite Spark DF Spark Logical Plan Spark Physical Plan

18. P0 Input RDD 背景：在一些流量分析的场景或者大宽表的场景中，部分精确去重的度量列存在大量空值，导致构建任务运行数小时无法完成 repartition by dictionary column Hive P1 B2 P2 B3 RDD 通过优化后：构建时间从 5h 无法完成，缩短到 38min P0 Input RDD Hive repartition by dictionary column B1 P1 编码全局字典编码 + 倾斜字典 + 倾斜字典 + 倾斜字典 P2 RDD 分桶后的字典 B1 B2 B3 编码全局字典分桶后的字典

19. 04 参与开源社区 Kylin4 在有赞 OLAP 场景下的性能提升

20. 查询： • 基于动态规划的实现的复杂条件下的分区裁剪和分区。避免查询进行全表扫描； • 基于动态规划的实现分区条件消除。在月跨度的查询下减少数十倍数据量 • 支持缓存 calcite 执行计划构建： • 在字典编码阶段检测并避免数据倾斜导致的构建问题使用 Spark 构建时缓存上一层的数据，同时支持控制缓存的 Parent Dataset 数量语法扩展 : • 支持分页查询 ……

21. 团队角度提高项目的开发效率，降低研发成本提升线上服务的稳定性提升团队技术影响力避免重复的研发资源投入高效沟通、远程协作、文档记录更多的用通过线上真实场景打磨产品个人角度从业界大咖学习方案讨论、 Code Review 规范编码、提高工程质量文档规范提升技术影响力程序员缺少行业认证更多的最佳实践和技术方案 Apache Committer/PMC 业界认可开源项目更加强大的生命力，更多的从业经历者 JetBrains 全家桶其他 apache 邮箱、个人网站

22. 1. 对项目有基本的了解 2. 对于复杂的项目，从某个模块出发 3. 订阅项目的开发者邮件组 4. 充分了解 Git 的各种功能 5. 从 Typo 做起，作为熟悉社区工作方式、 PR 流程、建联的途径

23. 解决问题了解当前业务痛点扩大应用场景业务的正向反馈深入原理与代码解决问题获得更多帮助获得重视贡献社区加强融入

24. 后续计划 1. 关注，适当参与 Native Engine ：社区在计划 Rust/C++ 的引擎改写，提升查询性能 2. OLAP 是一个千亿的市场，营销分析是一个万亿的市场：继续提升有赞 OLAP 性能

25. Any advice ？ 1. 在真实的业务场景中才能解决问题 2. 技术只有解决实际问题才有价值 3. 在某个技术方向上持续投入

26.