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

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