Doris基于Hive表的全局字典设计与实现

本次分享的主要内容包括:
•Doris为什么需要全局字典
•什么是全局字典
•全局字典的实现
•总结与未来规划

展开查看详情

1.Doris基于Hive表的全局字典设计与实现 王博

2.主要内容 • 为什么需要全局字典 • 什么是全局字典 • 全局字典的实现 • 总结与未来规划

3.为什么需要全局字典 • 业务需要OLAP引擎能够⽀持精确去重的预计算 • 与⾦钱,业绩相关的⽐较重要的数据难以容忍近似计算 • 当前Doris的BITMAP列仅⽀持对于整型的精确去重计数

4.什么是全局字典 全局字典的数据结构 • 其实就是⼀个⽐较⼤的MAP • KEY保存了原始值,VALUE保存了编码后的整型值 • 原始值转成整型值之后就可以使⽤Doris的BITMAP列进⾏存储

5.什么是全局字典 全局字典的构建与使⽤流程 性能瓶颈点 • 抽取去重值 • 对去重值进⾏编码,构建全局字典 • 读取全局字典,使⽤全局字典对原始值进⾏编码

6.全局字典的技术实现 业界⽬前主要有两种全局字典的实现 • 基于Trie树的全局字典的实现(美团贡献给Kylin社区) • 基于Hive表的全局字典的实现(滴滴贡献给Kylin社区)

7.全局字典的技术实现:基于Trie树的全局字典 Trie树⽅案 • Kylin引擎⽀持 • 在美团内部有⼤规模落地的经验

8.全局字典的技术实现:基于Trie树的全局字典 Trie树的基本设计 • Trie树的结构在写⼊时就完成了去重和排序的⼯作 • 读取数据时,数据在Trie树中的位置就是对应的编码值

9.全局字典的技术实现:基于Trie树的全局字典 对Trie树进⾏分⽚ • 为了避免Trie树的内存使⽤过⾼,在单棵树节点⼤于⼀定阈值时,会对节点做分裂操作 • 每⼀个分⽚都是位于HDFS的⼀个⽂件 • 通过对分⽚⽂件进⾏缓存从⽽提升访问效率

10.全局字典的技术实现:基于Trie树的全局字典 Trie树总结与分析 优点 • 资源⾮常节约 • 单节点构建 • 编码阶段只需要对原始数据做⼀次MapReduce操作 • 在⼤部分场景下性能表现良好 局限性 • 字典的分⽚缓存命中率下降时,访问HDFS容易成为性能瓶颈,例如: • 字典很⼤,⽐如⼏⼗GB百GB的情况,输⼊数据相对离散 • 有多列⾼基数去重列 • ⽬前的字典是单个Reducer构建,在字典基数较⼤时存在以下问题 • 查询字典时容易把HDFS单节点⽹络带宽打满 • 单节点构建效率较低

11.全局字典的技术实现:基于Hive表的全局字典 基于SparkSQL+Hive表的字典基本思路 字典表 主要包含两个字段,⼀个字段是KEY,保存了去重列的原始值; 另⼀个字段是VALUE,保存了去重字段编码后的值 原始Hive表,要编码的原始Hive表,schema由业务指定 去重值表,保存了去重列的去重值的表

12.全局字典的技术实现:基于Hive表的全局字典 构建流程:抽取去重值

13.全局字典的技术实现:基于Hive表的全局字典 构建流程:构建全局字典

14.全局字典的技术实现:基于Hive表的全局字典 构建流程:对原始值进⾏编码 • 当去重列数据倾斜时容易出现性能瓶颈

15.全局字典的技术实现:基于Hive表的全局字典 性能瓶颈分析:字典构建阶段 SparkSQL窗⼜函数(row_number)容易成为性能瓶颈 • 该函数单机执⾏,可⽤内存有限 • 单次输⼊⾏数在亿级别时容易内存溢出 • 解决办法 • 对输⼊值进⾏分⽚,并⾏编码

16.全局字典的技术实现:基于Hive表的全局字典 性能瓶颈分析:编码阶段 当去重列发⽣数据倾斜时,编码阶段耗时很长 • ⼀些优化⽅法 • 使⽤MAP JOIN(已实现) • 如果倾斜列空值较多,那么就只对⾮空值进⾏编码(已实现) • ⽆法MAP JOIN且倾斜的值不是空值的情况,通过添加随机前缀的⽅式解 决(理论情况,⽬前线上还未遇到)

17.两种⽅案对⽐分析 基于Hive表的⽅方案 基于Trie树的⽅方案 字典构建 多节点并⾏行行构建 单节点构建 通过⼀一次shuffle完成单列列的构建 对原始值进⾏行行编码 不不需要shuffle 有⼏几个去重列列就需要shuffle⼏几次 即使增加资源,性能提升也⽐比较 弹性 增加资源可以提升性能 有限 整个流程shuffle次数较多 资源使⽤用 资源相对节省 资源开销⼤大 ⾼高基数,多去重列列时缓存容易易成 性能瓶颈 数据倾斜 为瓶颈

18.两种⽅案对⽐分析 为什么选择了基于Hive表的⽅案? • 现阶段除了数据倾斜时容易出现性能瓶颈之外,整个⽅案没有明显的短板 • 未来可以考虑从Spark引擎层的⾓度解决数据倾斜的问题 • 可以解决Trie树的短板问题 • ⽅案实现⽐较简单适合快速落地 • 弹性较好 • 增加资源的情况下提升并⾏度的情况下,可以明显提升构建性能

19.未来规划 基于Hive表的⽅案在线上环境的持续优化 • ⽬前基于Hive表的⽅案已经作为Hive2Doris流程的默认⽅案 • 未来优化⽅向 • 考虑从Spark的层⾯解决数据倾斜的问题,例如引⼊SparkAQE的特性 • Trie树⽅案与Hive表⽅案融合调研 • 对Trie树进⾏分桶改造并进⾏分布式构建 • 增加Trie转Hive表的接⼜,使得Trie树也可以参与Shuffle,从⽽解决Trie树的性能瓶颈问题

20.END Q&A

Apache DolphinScheduler(原EasyScheduler)是一个分布式工作流任务调度系统,主要解决错综复杂的依赖关系,而不能直观监控任务健康状态等问题。同类作品有oozie、Azkaban等,欢迎对比,哈哈