Hive数据倾斜案例阐述

一、离线数据的主要挑战：“数据倾斜”

首先介绍 “数据倾斜” 的概念。

“倾斜”应该来自于统计学里的的偏态分布，数据处理中的倾斜和此相关。

对于分布式数据处理来说，我们希望数据平均分布到每个处理节点，但是实际上由于业务数据本身的问题或者分布算法的问题，每个节点分配到的数据量很可能并不是我们预想的那样。

也就是说，只有待分到最多数据的节点处理完数据，整个数据处理任务才能完成，时分布式的意义就大打折扣 ，想想那个卡死的 99% 。

实际上，即使每个节点分配到的数据量大致相同，数据仍可能倾斜，比如考虑统计词频的极端问题，如果某个节点分配到的词都是一个词，那么显此节点需要的耗时将很长，即使其数据量和其他节点的数据量相同。

Hive 的优化正是采用各种措施和方法对上述场景的倾斜问题进行优化和处理。

二、Hive 的优化

其实在实际 Hive SQL 开发的过程中， Hive SQL 性能的问题上实际只有一小部分和数据倾相关。

很多时候， Hive SQL 运行得慢是由开发人员对于使用的数据了解不够以及一些不良的使用习惯引起的。

开发人员 要确定以下几点：

• 「需要计算的指标真的需要从数据仓库的公共明细层来自行汇总么?」 是不是数据公共层团队开发的公共汇总层已经可以满足自己的需求?对于大众的、 KPI 相关的指标等通常设计良好的数据仓库公共层肯定已经包含了，直接使用即可。
• 「真的需要扫描这么多分区么?」 比如对于销售明细事务表来说，扫描一年的分区和扫描一周的分区所带来的计算、 IO 开销完全是两个量级，所耗费的时间肯定也是不同的。作为开发人员，我们需要仔细考虑业务的需求，尽量不要浪费计算和存储资源!
• 「尽量不要使用 select * from your_table 这样的方式，用到哪些列就指定哪些列。」 如 select coll, col2 from your_table ，另外， where 条件中也尽量添加过滤条件，以去掉无关的数据行，从而减少整个 MapReduce 任务中需要处理、分发的数据量
• 「输入文件不要是大量的小文件。」 Hive 的默认 Input Split 是 128MB (可配置)，小文件可先合并成大文件。

在保证了上述几点之后，有的时候发现 Hive SQL 还是要运行很长时间，甚至运行不出来， 这时就需要真正的 Hive 优化技术了!

（编辑：甘孜站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!