Question

我们既有火花工作，也可以在当前hadoop集群中随机运行配置单元查询

我看到同一个配置单元表具有不同的分区模式，如下所示：

即如果表按日期划分，则

hdfs dfs -ls /data/hive/warehouse/db_name/table_name/part_date=2019-12-01/

给出结果

/data/hive/warehouse/db_name/table_name/part_date=2019-12-01/part-00001
....
/data/hive/warehouse/db_name/table_name/part_date=2019-12-01/part-06669
/data/hive/warehouse/db_name/table_name/part_date=2019-12-01/part-06670

但是如果找到不同分区日期的数据

hdfs dfs -ls /data/hive/warehouse/db_name/table_name/part_date=2020-01-01/

列出名称不同的文件

/data/hive/warehouse/db_name/table_name/part_date=2020-01-01/000007_0
/data/hive/warehouse/db_name/table_name/part_date=2020-01-01/000008_0
....
/data/hive/warehouse/db_name/table_name/part_date=2020-01-01/000010_0

我所能区分的不仅是在一个分区中，数据文件带有part-前缀，而另一个分区则类似于00000n_0，而且{{1} }文件，但每个文件都很小。

我还发现part-文件上的聚合比part-文件慢很多

文件模式差异的可能原因是什么？将配置从一种更改为另一种可能是什么？

Answer 1

当Spark Streaming在Hive中写入数据时，它会在Hive中创建许多名为part-的小文件，并且这些文件不断增加。在Hive表上查询时，这将导致性能问题。由于分区中没有大量小文件，因此Hive需要太多时间才能得出结果。

当Spark作业在Hive中写入数据时，它看起来像-

/data/hive/warehouse/db_name/table_name/part_date=2019-12-01/part-00001
....
/data/hive/warehouse/db_name/table_name/part_date=2019-12-01/part-06669
/data/hive/warehouse/db_name/table_name/part_date=2019-12-01/part-06670

但是这里不同的文件模式是由于分区文件上的压缩逻辑将小文件压缩为大文件所致。 00000n_0中的n是化简器的数量。

样本压缩脚本，它将小文件压缩为分区内的大文件，例如表欠样本数据库-

set hive.exec.dynamic.partition=true;
set hive.exec.dynamic.partition.mode=nonstrict;
set hive.exec.reducers.bytes.per.reducer=268435456; --256MB reducer size.

CREATE TABLE example_tmp
     STORED AS parquet
        LOCATION '/user/hive/warehouse/sample.db/example_tmp'
AS
  SELECT * FROM example

INSERT OVERWRITE table sample.example PARTITION (part_date) select * from sample.example_tmp;

DROP TABLE IF EXISTS sample.example_tmp PURGE;

上面的脚本会将小文件压缩为分区中的某个大文件。文件名将为00000n_0

文件模式差异的可能原因是什么？将配置从一种更改为另一种可能是什么？

可能有人使用Hive在分区上运行压缩逻辑。或者可能是使用Hive重新加载分区数据。这不是问题，数据保持不变。

是什么导致蜂巢表分区中的不同模式？

1 个答案: