- 使用 hint 来改写执行计划
select a.*, b.*
from fctOrders a
inner join employees b on a.employee_id = b.employee_id
显然 fctOrder 表的记录要比 employees 多上好几个数量级。将 fctOrders 放在第一位导致第一遍 map 跑批的数据量增大。因此当尽量用小表在 join 的左边。
有了 hint, 就不必在意 join 两表的顺序了:
select /*+ STREAMTABLE(a) */ a.*,b.*
from fctOrders a
inner join employees b on a.employee_id = b.employee_id
- 使用配置来改写执行计划
set hive.auto.convert.join =true ;
select a.*, b.*
from fctOrders a
inner join employees b on a.employee_id = b.employee_id
同样是将 join 的两表进行位置互换,这一次是使用配置。
所有的配置需要固化下来,都可以放在 $HOME/.hiverc 文件中
- 使用 partition
针对大数据量的事实表做分区,比如按月做分区,那么查询每个月的基本数据量时,只需扫描单个分区即可,而不必要扫描整张大表。假设极限情况下,所有其他月的数据并不够多,而只是其中一个月的数据量很大,那么只有对这个月的数据进行有效分区之后,才能真正达到高效。
分区本质上还是分而治之,但如果分区数据并不是分布在每台集群中的服务器上,仅仅是存储在其中一台服务器上,分区也没有太大意义,在这种情况下就变成了单实例的数据库。除非分区在分布式集群中,也是均摊到各个集群节点服务器上。
3.1 如何去验证分区的数据,其实是分布在不同服务器上呢? namenode 查询,hdfs -ls.
3.2 如何对一张没有实现分区的表,做分区?一开始就没有实现分区的表,是不能直接在其上做分区的,必须新建同样结构的分区表,然后将数据导入
3.3 动态分区表如何实现?
- 使用 sequencefile 存储格式
当hdfs上的文件小于一个hdfs block的时候,被称作小文件。处理小文件并不是 hadoop 的专长,同样也不是 hive 的专长。
碰到这类问题,就需要将小文件统统归档到一个大文件里面去,比如 sequencefile.
比如 /user/hive/warehouse/logs 下面很多 10MB 的 log 文件,我们可以用 text file 来将整个目录下的文件都从逻辑上归档到一张表 temp_table 中去,再创建一张 sequenfile 表,将 temp_table中的数据装载到 sequencefile 中。
为什么不把这些数据重新插入一整张新表中去呢,这样依然可以满足大表的存储需求。
sequencefile 除了可以压缩功能,肯定还有其他特性吸引采用它,而不是其他文件存储格式。
- 使用 ORCfile 存储:
官方说明,predicate-push-down, compression 等技术使得 ORCfile 在 join 两张大表的时候,更能体现性能的优势。
来自 hortonworks 官方的说明, 对每张表都采用 ORCfile 格式存储,已经是个不争的技巧。
和 4 中的 sequencefile 格式比较,应该做一些例子来进行更严格的求证。
- 使用 Apache Tez 执行引擎
Tez 是基于 YARN 的一个计算引擎。配置 Tez 对于 Hive 有益的地方在于有效利用 YARN 带来的比 MapReduce 1 优异的性能。其中之一就是有效利用每台节点服务器的内存,防止浪费,也有效防止因数据得不到充足的内存而故障造成的任务延迟。
在最终的结果生成时,有效利用并行输出也是提高整体 HQL 的一环。
SET hive.tez.auto.reducer.parallelism=true;
- 使用 vectorization 技术
set hive.vectorized.execution.enabled=true ;
set hive.vectorized.execution.reduce.enabled=true;
在计算类似 scan, filter, aggregation 的时候, vectorization 技术以设置批处理的增量大小为 1024 行单次来达到比单条记录单次获得更高的效率。
是否 1024 行单次为固定的增量大小,是否可以设置更大的量?
- cost based query optimization
成本优化器:传统的数据库,成本优化器做出最优化的执行计划是依据统计信息来计算的。Hive 的成本优化器也一样。
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 ;
以上开启了 cost based optimization.
下面的命令重新计算了统计信息:
analyze table tweets compute statistics;
analyze table tweents compute statistics for columns sender, topic;
analyze table tweens compute statistics for columns ;
- 语句级别的调优
比如: row_number 可以解决 Hive 级别的 Join 导致的网络传输速度慢的问题,但在 sql server 中就不能这么用了。
select tmp.*
from (select a, row_number()over(partition by category order by orderDate desc) as rnk
from fctOrder
) tmp
where rnk = 1
select a.*
from fctOrder a
inner join (select category,max(orderDate) as maxDate from fctOrder
group by category ) tmp on a.category = tmp.category
and a.orderDate = tmp.maxDate
这类应用在 sql server 和 Hive 中各自的效率是不一样的。
8.1 避免使用 SELECT COUNT(Distinct field) FROM tblTable
使用
SELECT COUNT(1) AS TotalCount
FROM (
SELECT Distinct field
FROM tblTable
)Tmp
这里最重要的思想便是将所有的计算拆成利用多个 reducer 进行计算的模式,而不是将全部的计算都压到一个 reducer.
8.2 慎重考虑用于分组的笛卡尔运算:
good:SELECT GROUP BY userId, gender
bad: SELECT GROUP BY gender,userId
userId 在前面,可利用多个 reducer 进行分组运算,而 gender 则之多会应用 3 个 reduer. 一是男,二是女,三未知。
8.3 Each-Top-N 的求解
每组前 N 个的应用场景,在数据分析领域常用。在 SQL 中一般用窗口函数 Rank()Over(Partition By)来计算。
而 Hive 中为了更好的发挥分布式运算,需要利用多个 reducer 来处理。
SELECT *,Rank()Over(Partition BY)
FROM tblTable
Distribute By FieldA
Sort By FieldA, MetricA DESC
这需要验证,Hive 中支持的 Window Function 有哪些要求。
- 使用 predicate pushdown (PPD) 在存储级别执行过滤
SET hive.optimize.ppd=true ;
SET hive.optimize.ppd.storage=true ;