如何优化hive查询过程

在过去几年中，主要受到围绕Stinger计划的Hive社区创新的推动，Hive查询时间得到了显着改善，使Hive能够以速度和规模支持批量和交互式工作负载。 但是，许多使用者仍然不熟悉以最快速度运行Hive查询的基本技术和最佳实践。本文中，将重点介绍一些常使用的简单技术，以提高HIVE查询的性能。

技术#1：使用TEZ
Hive可以使用Apache Tez执行引擎而不是Map-reduce引擎。不会详细介绍这里提到的使用Tez的许多好处; 相反，提出一个简单的建议：如果在您的环境中默认情况下没有打开它，请在Hive查询的开头使用Tez设置为“true”
set hive.execution.engine=tez;

技术#2：使用ORCFILE
Hive支持ORCfile，这是一种新的表存储格式，通过谓词下推，压缩等技术实现极佳的速度提升。
对每个HIVE表使用ORCFile应该是一个明智的选择，对于获得HIVE查询的快速响应时间非常有益。
作为一个例子，考虑两个大表A和B（存储为文本文件，这里没有指定一些列），以及一个简单的查询 :
SELECT A.customerID, A.name, A.age, A.address join
B.role, B.department, B.salary
ON A.customerID=B.customerID;

此查询可能需要很长时间才能执行，因为表A和B都存储为TEXT。将这些表转换为ORCFile格式通常会显着缩短查询时间：

CREATE TABLE A_ORC (
customerID int, name string, age int, address string
) STORED AS ORC tblproperties (“orc.compress" = “SNAPPY”);

INSERT INTO TABLE A_ORC SELECT * FROM A;

ORC支持压缩存储（使用ZLIB或如上所示使用SNAPPY），但也支持未压缩存储。将基表转换为ORC通常是取决于所在团队获取数据的职责，由于其他优先级，可能需要一些时间来更改完整的获取数据过程。ORCFile的好处是如此明显，以至于推荐如上所示的自助式方法 - 将A转换为A_ORC，将B转换为B_ORC并以此方式进行连接，以便立即从更快的查询中受益，而不依赖于其他团队。
技术#3：VECTORIZATION
矢量化查询执行通过一次批量执行1024行而不是每行一行来提高扫描，聚合，过滤器和连接等操作的性能。
这个功能在Hive 0.13中引入，显着缩短了查询执行时间，并且可以通过两个参数设置轻松启用：
set hive.vectorized.execution.enabled = true;
set hive.vectorized.execution.reduce.enabled = true;

技术#4：查询优化
在提交最终执行之前，Hive会优化每个查询的逻辑和物理执行计划。这些优化不是基于查询的成本 - 也就是说，直到运行时。
最近添加到Hive，基于成本的优化，基于查询成本执行进一步优化，从而导致可能不同的决策：如何订购联接，执行哪种类型的联接，并行度等。
要使用基于成本的优化（也称为CBO），请在查询开头设置以下参数
set hive.cbo.enable=true;
set hive.compute.query.using.stats=true;
set hive.stats.fetch.column.stats=true;
set hive.stats.fetch.partition.stats=true;

然后，通过运行Hive的“analyze”命令为CBO准备数据，以收集我们想要使用CBO的表的各种统计信息。
例如，在tweet数据表中，希望收集有关该表的统计信息以及大约2列：“sender”和“topic”：
analyze table tweets compute statistics;
analyze table tweets compute statistics for columns sender, topic;

使用HIVE 0.14（在HDP 2.2上），analyze命令的工作速度要快得多，而且您不需要指定每一列，因此只需如下：
analyze table tweets compute statistics for columns;

现在使用此表执行查询应该会导致不同的执行计划由于成本计算和Hive创建的不同执行计划而更快。
技术#5：编写良好的SQL
SQL是一种强大的声明性语言。与其他声明性语言一样，编写SQL语句的方法不止一种。尽管每个语句的功能都相同，但它可能具有截然不同的性能特征
CREATE TABLE clicks (
timestamp date, sessionID string, url string, source_ip string
) STORED as ORC tblproperties (“orc.compress” = “SNAPPY”);

每条记录代表一次点击事件，希望找到每个sessionID的最新网址。
有人使用如下方式：
SELECT clicks.* FROM
clicks inner join
( select sessionID, max(timestamp) as max_ts from clicks
group by sessionID
) latest
ON clicks.sessionID = latest.sessionID AND clicks.timestamp = latest.max_ts;

在上面的查询中，构建一个子查询来收集每个会话中最新事件的时间戳，然后使用内部联接来过滤掉其余的事件。
虽然查询是一个合理的解决方案 - 从功能的角度来看 - 事实证明，有一种更好的方法来重写这个查询，如下所示
SELECT * FROM
( SELECT *,
RANK() over (partition by sessionID,order by timestamp desc) as rank
FROM clicks
) ranked_clicks
WHERE ranked_clicks.rank=1;

在这里，使用Hive的OLAP功能（OVER和RANK）来实现相同的功能，但没有使用表连接。
显然，删除不必要的连接几乎总能带来更好的性能，而且当使用大数据时，这比以往任何时候都更重要。在很多情况下查询不是最优的 - 所以仔细查看每个查询并考虑重写是否可以使它更好更快。
更多内容信息 https://blue-shadow.top

作者：NEO_X
链接：https://www.jianshu.com/p/91f793a1bdb3
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。