Hive 外部表最佳分区大小答案

【问题标题】：Hive external table optimal partition sizeHive 外部表最佳分区大小
【发布时间】：2016-10-01 05:34:04
【问题描述】：

外部表分区的最佳大小是多少？我计划按年/月/日对表进行分区，我们每天会获得大约 2GB 的数据。

【问题讨论】：

你想“优化”什么？你有很多小节点，几个小节点，几个大节点吗？使用本地磁盘、网络驱动器或 S3 对象存储？您是否可以控制传入文件的大小（即 Flume 中的 1000 个小文件，或单个 FTP 文件）？您是否可以控制文件格式（CSV、AVRO、Parquet）？您是否可以控制文件压缩（无、Snappy、GZip）？您的默认容器大小（以 MB 为单位）是多少？你使用 TEZ 还是 MapReduce？你更喜欢一些长期运行的 Mapper 还是很多短命的 Mapper？你必须减少很多吗？
另一方面，如果您不知道自己在做什么，只是想要一个没有任何意义的幻数，那么普遍接受的有意义数是 42 参见。 en.wikipedia.org/wiki/…
@SamsonScharfrichter 我的意思是目录分区指向的最佳大小。我会尝试制作 64 到 128 MB 之间的文件

【解决方案1】：

最佳的表分区是与您的表使用场景相匹配的。应根据以下因素选择分区：

即使对于一个文件来说，2Gb 也不算多，不过这又取决于您的使用场景。避免不必要的复杂和冗余分区，例如（年、月、日）——在这种情况下，日期足以进行分区修剪。

【讨论】：

【解决方案2】：

Hive 分区定义将存储在 Metastore 中，因此过多的分区将占用 Metastore 中的大量空间。

分区将作为目录存储在 HDFS 中，因此许多分区键会产生分层目录，从而使其扫描速度变慢。

您的查询将作为 MapReduce 作业执行，因此创建太小的分区是没有用的。

视情况而定，考虑如何查询您的数据。对于您的情况，我更喜欢一个定义为 'yyyymmdd' 的键，因此我们将获得 365 个分区/年，表目录中只有一个级别和 2G 数据/分区，这对于 MapReduce 工作来说非常好。

为了回答的完整性，如果您使用 Hive here。

有用的博客here。

【讨论】：

【解决方案3】：

Hive 分区在数据稀疏的情况下最为有效。稀疏是指数据在内部具有可见的分区，例如按年、月或日。

在您的情况下，按日期进行分区没有多大意义，因为每天都会有 2 Gb 的数据，而且不会太大而无法处理。按周或按月分区更有意义，因为它会优化查询时间并且不会创建太多的小分区文件。

【讨论】：