我有一个hdfs文件，有5000万条记录，原始文件大小是50gb。
我正在尝试将其加载到配置单元表中，并在加载时使用下面的为所有行创建唯一id。我使用的是hive 1.1.0-cdh5.16.1。
作为id的行（按事件\u id、用户\u id、时间戳排序）
在执行时，我看到在reduce步骤中，分配了40个reducer。39个reducer的平均时间大约是2分钟，而最后一个reducer大约需要25分钟，这显然让我相信大多数数据都是在一个reducer中处理的。
我怀疑order by子句是这种行为的原因，并尝试了以下方法，
行号（）over（）作为id
然而，我看到了同样的行为。
考虑到map reduce范例，我觉得如果不指定partition by子句，则必须在一个reducer（未分发）中处理数据，以便查看所有行并附加正确的行号。对于任何没有partition by子句或partition by on skewed column的窗口函数，都可能是这样。
现在，我的问题是，当我们必须避免按子句划分时，如何绕过这个问题并优化窗口函数？
3条答案
按热度按时间yvfmudvl1#
而不是试着点
sort by或者cluster byvhmi4jdf2#
您可以使用uuid：
在系统/工作流中生成的uuid在其他一些系统中也是唯一的，因为uuid是全局唯一的。uuid工作完全分布式和快速。
在hive3.x中还有一个代理键函数，您可以在ddl中使用它
xeufq47z3#
@leftjoin的建议非常有效（非常感谢！）对于这个用例。它不涉及减少步骤和工作完成不到3分钟。我测试过，它确实是产生唯一的id。将检查底层代码，因为它是非常有趣的，它能够产生唯一的id，即使有500+Map器。
因为我使用的是Hive1.1，所以无法尝试代理密钥
不幸的是，@strick的建议没有奏效，但是谢谢分享。使用cluster by没有生成唯一的id。所有行都被标记为1，因为我的cluster by子句具有自然密钥。按行为排序在结果和性能上与按行为排序相似（完成需要32分钟）。也许数据是通过一个减速机导入的，这意味着在这种情况下，sort by相当于order by(但我不确定）
仍然在寻找窗口函数的解决方案，它可能没有partitionby子句，但应该是分布式的