HiveSQL优化

最新推荐文章于 2023-01-10 23:57:30 发布

一直青蛙

最新推荐文章于 2023-01-10 23:57:30 发布

阅读量565

点赞数 5

分类专栏： BigData 文章标签： hive hadoop sql hivesql优化 mapreduce

本文链接：https://blog.csdn.net/weixin_37944880/article/details/86682851

版权

Hadoop应该是当前最流行的大数据处理工具了（没有之一的那种），单独写MapReduce任务的应该不多了，主要还是用的Hive SQL，所以如何让HQL跑的又快又稳是非常重要的。

首先，说SQL之前，可以在Hive表上做文章，比如：

1.加分区

这个应该是最常用的了，把数据分别存到各个partition，查的时候指定好分区字段或者范围，hive只会扫对应分区的数据，最简单，也最有效；

2.加桶

与加分区类似，是对表或分区的进一步划分，本人用的不多，稍稍展开下；

通过对指定列进行哈希计算来实现，通过哈希值将一个列名下的数据切分为一组桶，并使每个桶对应于该列名下的一个存储文件。

demo:

create table bucketed_user(
    id int,
    name string
)
clustered by (id) into 4 buckets

作用：

a.高效采样，数据是hash过的，从一个桶取跟从所有数据取几乎一毛一样

b.获得更好的查询处理效率，比如，join时候知道key对应到哪个桶，就能直接取

3.优化表结构

可以采用增量表或者拉链表（高大上一点叫极限存储）；

增量表，优点不用多说，毕竟省存储资源约等于省钱；缺点是历史信息追溯不到，但是依旧好用到飞起，毕竟很多时候过去并不重要，从关系型数据库同步的话，比较关键的是增量字段要加索引；

拉链表，弥补了增量表最大的不足，并且继承了增量表的优点，但是依旧有缺陷，频繁更新的表不适用；另外，对于表的使用者，尤其是非开发人员，存在一些理解上的弊端，这个的话，可以建视图的方式隐藏掉复杂逻辑，对外保持原来的使用模式；

以上其实都是可以单独展开写成一篇的，无奈被标题所囚禁，尊重一手写标题时候的自己，单纯的从SQL运行的角度，继续研究；

说白了，就是HQL跑的贼慢，要怎么办；

首先，类似关系型数据库，可以用 explain 查看sql执行计划，将整个执行为多个Stage；不过，自己实际用的不多，HQL执行计划异常情况也不像Oracle那样频繁，以后再完善相关内容(…)；

HQL本质上是MapReduce任务，一般map task从数据源获取数据，再经过shuffle操作到reduce端由reduce task进行操作，最终产出数据，这里各个阶段，各个步骤都是有可能拖慢整个任务的；

通过Hadoop UI界面，可以清楚的看到，各个阶段，各种task的运行状况，只要任务没有立马挂掉，就可以看到那些任务跑的快，哪些拖了个长长的尾巴，

关注