我使用aws emr运行配置单元查询，在运行配置单元版本0.13.1时出现性能问题。
新版本的hive运行10行数据大约需要5分钟。但230804行的同一个脚本需要2天时间，并且仍在运行。我应该如何分析和解决问题？
样本数据：
表1：
hive> describe foo;
OK
orderno string
Time taken: 0.101 seconds, Fetched: 1 row(s)表1的示例数据：
hive>select * from foo;
OK
1826203307
1826207803
1826179498
1826179657表2：
hive> describe de_geo_ip_logs;
OK
id bigint
startorderno bigint
endorderno bigint
itemcode int
Time taken: 0.047 seconds, Fetched: 4 row(s)表2的样本数据：
hive> select * from bar;
127698025 417880320 417880575 306
127698025 3038626048 3038626303 584
127698025 3038626304 3038626431 269
127698025 3038626560 3038626815 163我的问题：
SELECT b.itemcode
FROM foo a, bar b
WHERE a.orderno BETWEEN b.startorderno AND b.endorderno;
1条答案
按热度按时间5ssjco0h1#
在您的配置单元日志输出的最顶部，它声明“警告：阶段'stage-1 mapred'中的shuffle join[4][tables a，b]是一个叉积。”
编辑：“叉积”或笛卡尔积是无条件的联接，它返回“b”表中的每一行以及“a”表中的每一行。因此，如果以‘a’是5行，而‘b’是10行为例，就得到了乘积，或者，5乘以10=50行。对于一个或其他表，将有许多行完全为“null”。
现在，如果您有一个20000行的表'a'并将其联接到另一个500000行的表'b'，您将要求sql引擎返回1000000000行的数据集'a，b'，然后对1000万行执行between操作。
因此，如果去掉“b”行的数量，您会看到比“a”有更多的好处—在您的示例中，如果您可以过滤ip_logs表，表2，因为我猜测它的行数比您的order number表的行数多，它将减少执行时间。结束编辑
通过不指定联接的条件，可以强制执行引擎处理笛卡尔积。它必须一遍又一遍地扫描整个a表。有10行，就不会有问题了。使用20k，您将遇到几十个map/reduce波。
尝试此查询：
但我很难搞清楚你的模特会允许加入哪个栏目。也许这个表达式的数据模型可以改进？可能是我看不清样品。
无论哪种方式，都需要在where子句之前过滤比较的数量。我在hive中完成这项工作的其他方法是使用较小的数据集创建一个视图，并连接/匹配视图而不是原始表。