经过研究一些不太常用的替代计划来处理MapReduce功能问题以及挑选处理计划时要考虑的因素。

处理MapReduce功能问题

以下处理计划来缓解MapReduce功能问题：

  • 更改吸取进程/距离
  • 批处理文件兼并
  • 序列文件
  • HBase
  • S3DistCp（假如运用Amazon EMR）
  • 运用CombineFileInputFormat
  • Hive装备
  • 运用Hadoop的附加功能

现已讨论过更改吸取进程，批处理文件兼并和序列文件。

Hbase

假如要生成很多小文件，将数据作为文件存储在HDFS中或许不是最佳处理计划。相反，您能够考虑运用HBase列存储。运用HBase能够将吸取进程从生成许多小型HDFS文件更改为将单个记载写入HBase表。假如您的数据拜访形式根据明确界说的随机拜访查找，则HBase或许是您的最佳挑选。它在架构上针对高速数据记载插入，大容量，单个记载查找和根据流的分析进行了调整。可是，假如您的数据拜访形式倾向于完好文件/表扫描，那么HBase或许不是最佳的。

能够创立映射到HBase数据的Hive表; 可是，此规划中的查询功能会有所不同。当挑选单行或一系列行时，HBase上的Hive会闪烁，但假如您的查询倾向于全表扫描，则HBase的效率十分低。大多数分析查询，尤其是那些运用group by的查询，都需求进行全表扫描。

HBase供给了将数据流式传输到Hadoop并使其可实时处理的最佳才能。可是，平衡HBase与其他集群进程的需求或许具有挑战性，而且需求高级体系管理。此外，HBase功能在很大程度上取决于数据拜访形式，在挑选HBase处理小文件问题之前，应细心考虑这些形式。

S3DistCp

此处理计划仅适用于Amazon EMR的用户。Amazon EMR集群的生命周期很短，将数据保存在Amazon S3中。即便运用Amazon S3，处理很多小文件依然会导致发动不必要的map使命，从而降低功能。

S3DistCp是亚马逊供给的一种实用程序，用于将数据从S3分发复制到暂时HDFS甚至其他S3存储桶。该实用程序供给了经过运用groupBy和targetSize选项将文件连接在一起的功能。当您在S3中存储了数千个要运用Amazon EMR处理的小文件时，这十分有用。S3DistCp经过连接许多小文件并使它们出现在更快，时间短的HDFS存储中，一箭双雕。据报道，运用这种机制能够提高15倍的功能。

出于一切实际目的，S3DistCp执行与提到的批处理文件兼并方法相同的使命。假如运用Amazon EMR，请注意您有一个预先构建的东西来完结此使命。

运用CombineFileInputFormat

CombineFileInputFormat是Hadoop供给的抽象类，它在MapReduce读取时兼并小文件。兼并的文件不会持久保存到磁盘。相反，该进程读取多个文件并“动态”兼并它们以供单个map使命运用。您能够获得不为每个文件发动一个map使命的好处，而且不需求将多个文件兼并到一个持久文件中作为预备步骤的一部分。这处理了MapReduce作业发动太多map使命的问题; 可是，因为作业仍在读取多个小文件，因而随机磁盘IO依然存在问题。此外，CombineFileInputFormat的大多数实现都不考虑数据局部性，而且通常会经过网络从各种数据节点提取数据。

为了实现这一点，有必要在Java中为不同的文件类型扩展CombineFileInputFormat。这需求很多的开发专业知识来开发您的自界说输入格式类。可是，一旦编写，您能够装备最大分割巨细，它将兼并文件，直到满足此巨细。

请注意，因为兼并数据不会在HDFS中保留，因而CombineFileInputFormat不会缓解NameNode内存问题。

Hive装备

假如您注意到Hive经过“create table as”或“insert overwrite”语句在Hadoop集群中创立小文件，则能够调整一些Hive特定装备设置以进行缓解。运用时，这些设置会告诉Hive将创立的任何小文件兼并到较大的文件中。可是，有一个赏罚。Hive将发动一个额外的MapReduce作业后查询，以执行兼并。此外，在Hive向用户指示查询已完结处理而不是异步产生之前完结兼并。

应该注意，这些设置仅适用于由Hive创立的文件。例如，假如运用其他东西（如Sqoop）在Hive外部创立文件，则运用hdfs fs -mv命令将其复制到Hive表中，Hive将不会兼并文件。因而，当摄入Hadoop的文件很小时，此处理计划不起作用。此处理计划仅主张在以Hive为中心的体系结构中，其间insert overwrite和create table as语句中的小功能损失是可接受的。

要运用的设置是：

[外链图片转存失败,源站或许有防盗链机制,主张将图片保存下来直接上传(img-VebLTa1P-1669338671217)(qingbooks.oss-cn-beijing.aliyuncs.com/projects/ha…)]

运用Hadoop的附加功能

附加或许是可用的，但Hadoop生态体系中的主要东西都不支撑它：Flume，Sqoop，Pig，Hive，Spark和Java MapReduce。MapReduce强制执行一条规矩，即MapReduce作业的输出方位在执行之前不得存在。因为这个规矩，MapReduce显然不或许经过其输出附加到预先存在的文件。因为Sqoop，Pig和Hive都运用了MapReduce，因而这些东西也不或许支撑追加。Flume不支撑追加很大程度上是因为它假定经过一段时间（无论是秒，字节，事件数或不活动秒），Flume将封闭文件而不再翻开它。Flume社区认为这足够，而不是要求追加支撑。

假如你真的有必要在Hadoop中运用appends，你有必要编写自己的体系来执行吸取并附加到现有文件。此外，假如您的任何群集内处理需求附加到现有文件，您将无法运用Spark或MapReduce。因而，运用HDFS附加功能十分复杂，只能由技术最精深的安排运用。假如没有重要的工程团队和支撑许诺，则不主张运用此选项。

挑选处理计划

挑选运用小文件的最佳处理计划取决于各种问题。或许有必要根据拜访形式和数据要求运用这些处理计划的组合。应该考虑的问题包含：

  • 数据流中的哪一点是生成的小文件？是在吸取时还是经过群集内处理创立小文件？
  • 生成小文件的东西是什么？更改东西装备能够减少小文件的数量吗？
  • 您的安排有多少技术技术？您是否有才能维护输入格式或编写自己的吸取引擎？
  • 生成小文件的频率是多少？为了创立大文件，能够多久兼并一次小文件？
  • 这些小文件需求哪种数据拜访？这些文件是否需求经过Hive拜访？
  • 能够在集群内部运转流程以减轻小文件的管理周期类型？
  • MapReduce流程可接受的延迟级别是多少？