【问题标题】:Compaction in Impala TablesImpala 表中的压缩
【发布时间】:2020-06-29 20:58:04
【问题描述】:

我想了解 Impala 表中的压缩,但找不到要研究的材料。 有哪些不同的技术,我可以在哪里找到相关材料进行研究。

【问题讨论】:

    标签: cloudera impala


    【解决方案1】:

    compaction 的主要技术是避免使用small file problem,这取决于您的用例。

    例如,您可能有一个将小文件写入HDFS 的进程,并且您希望像Impala table 一样查询这些文件。您可以为这些小文件设置一个staging table,并使用INSERT INTO TABLE base_table SELECT .....FROM stg_table 加载base table 以将小文件压缩成更大的文件。

    另一个用例是partitioning。 使用分区时的一个主要风险是创建的分区会导致您遇到小文件问题。 发生这种情况时,对表进行分区实际上会降低查询性能 (与使用分区时的目标相反)因为它会导致创建太多小文件。 使用dynamic partitioning 时更有可能发生这种情况,但它仍然可以 发生在 static partitioning 上——例如,如果您向销售表添加了一个新分区 每天包含前一天的销售额, 而且每天的数据也不是特别大。

    在选择分区时,您希望在太多分区之间取得平衡 (导致小文件问题)和太少的分区(提供性能的好处很少)。 分区列或列应具有合理数量的值 对于分区 - 但您应该认为合理的内容很难量化。

    使用dynamic partitioning 特别危险,因为如果你不小心, 在具有太多不同值的列上进行分区很容易。 想象一个用例,您经常在其中查找属于 您将在查询中指定的时间范围。 您可能认为在与时间相关的列上进行分区是个好主意。 但是TIMESTAMP 列的时间可以达到纳秒,所以每一行都可以有一个唯一的值; 对于分区列来说,这将是一个糟糕的选择!甚至到分钟或小时都可以创造 分区太多,具体取决于数据的性质; 按较大的时间单位(如日、月甚至年)进行分区可能是更好的选择。

    上面的阅读只是问题的介绍,用例更多,总的主题是性能和调优。

    您可以从 Cloudera 文档开始。您可以点击此链接:

    Tuning Impala for Performance

    希望这会有所帮助。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2018-07-01
      • 1970-01-01
      • 2016-06-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-10-06
      • 2013-08-04
      相关资源
      最近更新 更多