Question

INSERT OVERWRITE TABLE result
SELECT /*+ STREAMTABLE(product) */
i.IMAGE_ID, 
p.PRODUCT_NO,
p.STORE_NO,
p.PRODUCT_CAT_NO,
p.CAPTION,
p.PRODUCT_DESC,
p.IMAGE1_ID,
p.IMAGE2_ID, 
s.STORE_ID, 
s.STORE_NAME, 
p.CREATE_DATE, 
CASE WHEN custImg.IMAGE_ID is NULL THEN 0 ELSE 1 END, 
CASE WHEN custImg1.IMAGE_ID is NULL THEN 0 ELSE 1 END, 
CASE WHEN custImg2.IMAGE_ID is NULL THEN 0 ELSE 1 END
FROM image i  
JOIN PRODUCT p ON i.IMAGE_ID = p.IMAGE1_ID
JOIN PRODUCT_CAT pcat ON p.PRODUCT_CAT_NO = pcat.PRODUCT_CAT_NO
JOIN STORE s ON p.STORE_NO = s.STORE_NO
JOIN STOCK_INFO si ON si.STOCK_INFO_ID = pcat.STOCK_INFO_ID 
LEFT OUTER JOIN CUSTOMIZABLE_IMAGE custImg ON i.IMAGE_ID = custImg.IMAGE_ID 
LEFT OUTER JOIN CUSTOMIZABLE_IMAGE custImg1 ON p.IMAGE1_ID = custImg1.IMAGE_ID 
LEFT OUTER JOIN CUSTOMIZABLE_IMAGE custImg2 ON p.IMAGE2_ID = custImg2.IMAGE_ID;

我有一个连接查询，我正在加入大表，我正在尝试优化此配置单元查询。以下是关于表格的一些事实

图像表有60米行，产品表有1b行， product_cat有1000行，商店有1米行， stock_info有100行， customizable_image有200万行。

产品可以有一个或两个图像（image1和image2），产品级别信息仅存储在产品表中。我尝试将产品的连接移动到底部，但我不能，因为所有其他后续连接都需要产品表中的数据。

这是我到目前为止所尝试的，我给出了一个提示，以便将产品表作为最大的产品表 2.我将表（在创建表中）分成256个桶（在image_id上），然后进行连接 - 没有给我任何显着的性能提升 3.将输入格式从textfile（gzip文件）更改为序列文件，这样它就可以拆分，因此如果hive想要运行更多的映射器，可以运行更多的映射器

以下是来自hive控制台的一些关键日志。我在aws中运行了这个配置单元查询。任何人都可以帮我理解这里的主要瓶颈吗？此作业仅处理实际数据的子集。

Stage-14 is selected by condition resolver.
Launching Job 1 out of 11
Number of reduce tasks not specified. Estimated from input data size: 22
In order to change the average load for a reducer (in bytes):
  set hive.exec.reducers.bytes.per.reducer=<number>
In order to limit the maximum number of reducers:
  set hive.exec.reducers.max=<number>
In order to set a constant number of reducers:
  set mapred.reduce.tasks=<number>
Kill Command = /home/hadoop/bin/hadoop job  -kill job_201403242034_0001
Hadoop job information for Stage-14: number of mappers: 341; number of reducers: 22
2014-03-24 20:55:05,709 Stage-14 map = 0%,  reduce = 0%
.
2014-03-24 23:26:32,064 Stage-14 map = 100%,  reduce = 100%, Cumulative CPU 34198.12 sec
MapReduce Total cumulative CPU time: 0 days 9 hours 29 minutes 58 seconds 120 msec
.
2014-03-25 00:33:39,702 Stage-30 map = 100%,  reduce = 100%, Cumulative CPU 20879.69 sec
MapReduce Total cumulative CPU time: 0 days 5 hours 47 minutes 59 seconds 690 msec
.
2014-03-26 04:15:25,809 Stage-14 map = 100%,  reduce = 100%, Cumulative CPU 3903.4 sec
MapReduce Total cumulative CPU time: 0 days 1 hours 5 minutes 3 seconds 400 msec
.
2014-03-26 04:25:05,892 Stage-30 map = 100%,  reduce = 100%, Cumulative CPU 2707.34 sec
MapReduce Total cumulative CPU time: 45 minutes 7 seconds 340 msec
.
2014-03-26 04:45:56,465 Stage-2 map = 100%,  reduce = 100%, Cumulative CPU 3901.99 sec
MapReduce Total cumulative CPU time: 0 days 1 hours 5 minutes 1 seconds 990 msec
.
2014-03-26 04:54:56,061 Stage-26 map = 100%,  reduce = 100%, Cumulative CPU 2388.71 sec
MapReduce Total cumulative CPU time: 39 minutes 48 seconds 710 msec
.
2014-03-26 05:12:35,541 Stage-4 map = 100%,  reduce = 100%, Cumulative CPU 3792.5 sec
MapReduce Total cumulative CPU time: 0 days 1 hours 3 minutes 12 seconds 500 msec
.
2014-03-26 05:34:21,967 Stage-5 map = 100%,  reduce = 100%, Cumulative CPU 4432.22 sec
MapReduce Total cumulative CPU time: 0 days 1 hours 13 minutes 52 seconds 220 msec
.
2014-03-26 05:54:43,928 Stage-21 map = 100%,  reduce = 100%, Cumulative CPU 6052.96 sec
MapReduce Total cumulative CPU time: 0 days 1 hours 40 minutes 52 seconds 960 msec

MapReduce Jobs Launched: 

Job 0: Map: 59  Reduce: 18   Cumulative CPU: 3903.4 sec     HDFS Read: 37387 HDFS Write: 12658668325 SUCCESS
Job 1: Map: 48              Cumulative CPU: 2707.34 sec   HDFS Read: 12658908810 HDFS Write: 9321506973 SUCCESS
Job 2: Map: 29  Reduce: 10   Cumulative CPU: 3901.99 sec   HDFS Read: 9321641955 HDFS Write: 11079251576 SUCCESS
Job 3: Map: 42              Cumulative CPU: 2388.71 sec   HDFS Read: 11079470178 HDFS Write: 10932264824 SUCCESS
Job 4: Map: 42  Reduce: 12   Cumulative CPU: 3792.5 sec     HDFS Read: 10932405443 HDFS Write: 11812454443 SUCCESS
Job 5: Map: 45  Reduce: 13   Cumulative CPU: 4432.22 sec   HDFS Read: 11812679475 HDFS Write: 11815458945 SUCCESS
Job 6: Map: 42              Cumulative CPU: 6052.96 sec   HDFS Read: 11815691155 HDFS Write: 0 SUCCESS
Total MapReduce CPU Time Spent: 0 days 7 hours 32 minutes 59 seconds 120 msec
OK

在Hive中查询仍然需要超过5个小时，而在RDBMS中只需要5个小时。我需要一些帮助来优化这个查询，以便它执行得更快。有趣的是，当我使用4个大型核心实例运行任务时，与使用3个大型实例核心实例的运行相比，所花费的时间仅增加了10分钟。但当我用3个核心运行任务时，需要花费1小时10分钟。

这让我想到了一个问题，“Hive甚至是这种复杂连接的正确选择”吗？

Answer 1

我怀疑瓶颈只是在对产品表进行排序，因为它看起来比其他产品更大。我认为与Hive连接超过一定大小的表变得站不住脚，只是因为它们需要排序。

有一些优化排序的参数，比如io.sort.mb，您可以尝试设置，以便在内存中进行更多排序，而不是溢出到磁盘，重新读取和重新排序。查看溢出记录的数量，看看它是否比您的输入大得多。有多种方法可以优化排序。它也可能有助于将您的查询分解为多个子查询，因此它不必一次排序。

对于stock_info和product_cat表，您可以将它们保存在内存中，因为它们非常小（请查看Brickhouse中的'distributed_map'UDF（https://github.com/klout/brickhouse/blob/master/src/main/java/brickhouse/udf/dcache/DistributedMapUDF.java）。对于自定义映像，您可以使用一个布隆过滤器，如果有一些误报不是一个真正的大问题。

要完全删除连接，也许您可以将图像信息存储在像HBase这样的keystone数据库中，以进行查找。 Brickhouse还为HBase提供了UDF，如hbase_get和base_cached_get。

优化用于多表连接的配置单元查询

1 个答案: