你好，很抱歉发了这么长的短信，
我们使用hive1.2.0，表按日期划分，按客户id划分，也按客户id排序(我知道，不应该按同一件事分类，但这样做是有意义的）。
在测试性能时，我们使用了已经存在的表，所以每个分区有128个文件（表有128个bucket）。性能影响很大。
但我注意到，在实时环境中，所有插入都会创建额外的128个文件。我希望看到配置单元插入到已经存在的文件中。如果我们每小时填充一次表，我们就可以得到24 x 128个文件，所有文件都已排序。但这已经不是真正的排序了-它是按文件排序的。我相信它仍然很重要，但它的表现会受到影响。table每天排100米左右。由于一些后续/延迟的条目，实际插入到一个分区的次数可能会超过24个，可能是30-40个。
我们目前正在考虑每周做一次压实作业，但这确实令人沮丧：）。最初，这是一个spark管道，然后需要从“spark staging table”插入配置单元，因为spark无法写入这样的表，现在我们正在研究压缩作业的可能性。。。
有什么意见/建议吗？
提前谢谢！
1条答案
按热度按时间zbdgwd5y1#
我不明白你到底想问什么。
但根据你的问题。
在customer id上创建排序的bucket是个好主意，它肯定会提供性能优化，主要是在smb和bucked连接等连接中，您会看到很大的改进。
众所周知，如果插入到bucked表中，配置单元将使用复制创建新的bucket，它将不会编辑或更新现有bucket，而是使用新值创建新bucket。
如果您正处于应用程序的设计阶段，我建议您基于techincal partition再创建一个partition子句，它可以是您的运行id。例如，如果您每小时运行一次进程，那么您可以基于hour创建新分区，也可以是您可以生成的任何唯一id
所以你的结构会像
无法编辑现有的bucket。
其他解决方法是与主表一起创建一个临时表，它将保存您1天左右的数据，并使用新数据加入此表，然后插入覆盖主表，这样您的buckets将保存所有排序的customer\u id，并且在我们将覆盖的数据插入现有表时不会有文件副本