Hive中优化部分

        

说一说常见的 SQL 优化

RBO优化：基于规则优化的优化器，优化规则都已经预先定义好了，只需要将SQL往这些规则上套即可，例如谓词下推，列裁剪，常量折叠等。

谓词下推的目的就是通过将一些过滤条件尽可能的在最底层执行可以减少每一层的交互的数据量，从而提升性能；

SELECT COUNT(1)
FROM A
JOIN B
ON A.id = B.id
WHERE A.a > 10 AND B.b < 100;
//优化
SELECT COUNT(1)
FROM (SELECT * FROM A WHERE a > 10) A1
JOIN (SELECT * FROM B WHERE b < 100) B1
ON A1.id = B1.id;

列裁剪也叫投影下推，表示扫描数据源的时候，只读取那些与查询相关的字段

SELECT
t1.id, 1 + 2 + t1.value AS v
FROM t1, t2
WHERE
t1.id = t2.id AND
t2.id < 1000;
//优化
我们发现整个查询中只用到了表 t1 的 id 和 value 字段，表 t2 的 id 字段，那么我们可以将投影下推到表，先查出 t2的 id 字段，然后再完成联结查询。这样可以去掉 t2 表的多余字段，极大地节省了 I / O 开销。
SELECT
t1.id, 1 + 2 + t1.value AS v
FROM t1, (SELECT t2.id FROM t2) t2
WHERE
t1.id = t2.id AND
t2.id < 1000

常量折叠也叫表达式折叠，表示将表达式提前计算出结果，然后使用结果对表达式进行替换。

SELECT
e.empno,
e.ename,
e.sal,
d.deptno,
d.dname
FROM
emp AS e
INNER JOIN dept AS d ON e.deptno = d.deptno
AND d.deptno = 5 + 5;

CBO优化：基于代价的优化，他需要计算所有可能执行计划的代价，并挑选出代价最小的执行计划，

Join优化：

小表JOIN大表Map Join，

Map Join顾名思义，就是在Map阶段进行表之间的连接，而不需要进入到Reduce阶段才进行连接，这样就节省了在Shuffle阶段时要进行大量数据传输，（就是在Map阶段将小表读入到内存，顺序扫描大表完成join）.

大表JOIN大表的Reduce Join,

Bucket Map Join(中型表和大表Join)

Sort Merge Bucket Join(大表和大表Join)

Reduce Join：

Map端的主要工作：为来自不同表或文件的数据，进行打标签以区别不同源的记录，然后用JOIN字段作为Key，其余部分数据和新加的标志作为Value，最后进行输出。

Reduce端的主要工作：在Reduce端以JOIN字段作为Key完成分组，接下来只需要在每一个分组中，将那些来源与不同Map端的文件的记录进行合并即可。

应用场景：大表（相较于 Map Join 小表的数据更大） JOIN 大表。 实现原理：将两张表的数据在 Shuffle 阶段利用 Shuffle 的分组将数据按照 JOIN 字段进行合并。 具体使用：Hive 会自动判断是否满足 Map Join，如果不满足 Map Join，则会自动执行 Reduce Join。

分区/分桶：

分区中开启严格模式，主要是为了禁止某些查询（这些查询可能会造成意想不到的坏结果），目前主要禁止三种类型的查询： 分区表查询时，必须在 WHERE 语句后指定分区字段，否则不允许执行。因为在查询分区表时，如果不指定分区查询，会进行全表扫描。而分区表通常有非常大的数据量，全表扫描非常消耗资源。 ORDER BY 查询必须带有 LIMIT 语句，否则不允许执行。因为 ORDER BY 会进行全局排序，这个过程会将处理的结果分配到一个 Reduce 中进行处理，处理时间长且影响性能。 笛卡尔积查询（多使用 JOIN 和 ON 语句查询）。数据量非常大时，笛卡尔积查询会出现不可控的情况，因此严格模式下也不允许执行。

分桶：

提高 JOIN 查询效率：获得更高的查询处理效率。桶为表加上了额外的结构，Hive 在处理某些查询的时能利用这个结构。具体而言，连接两个在（包含连接列的）相同列上划分了桶的表，可以使用 Map 端连接 （Map-side Join）高效的实现。比如 JOIN 操作。对于 JOIN 操作两个表有一个相同的列，如果对这两个表都进行了桶操作。那么将保存相同列值的桶进行 JOIN 操作就可以，可以大大较少 JOIN 的数据量。