Hadoop上小文件存储处理-Java-优质IT资源分享社区

admin
管理员
管理员
  • UID1
  • 粉丝26
  • 关注4
  • 发帖数581
  • 社区居民
  • 忠实会员
  • 原创写手
阅读:143回复:0

 Hadoop上小文件存储处理

楼主#
更多 发布于:2016-05-20 18:49

Hadoop上小文件存储处理

原文衔接 译者:小村长

Hadoop–小文件存储处理

本篇文章项目是Cloudera论坛中无意中看到的,尽管原文写于2009年,但是当时开来Hadoop的小文件存储计划并没有极好的解决计划,所以感受作者写的极好,也很具体,于是就抽空翻译了。本次翻译首要针对对Hadoop感兴趣和作业中运用到Hadoop的开发人员供给有价值的中文资料,期望能够对我们的作业和学习有所协助。

由于我英语水平有限,有些翻译虽能了解其大意,但是却无法极好的表达出来,所以有些当地翻译的不是极好。一起也由于才能才智有限,翻译过程中不免呈现自个的片面或许客观原因致使与原文档有差异。在此,我仍是主张有才能的童鞋能够自个去原文看看,一起假如我们发现十分好的对于Hadoop小文件处理的文件,也主张我们提出来与我们一同分享。

小文件疑问

February 2, 2009

By Tom White

32 Comments

Categories: General Hadoop

在Hadoop中小文件是一个大疑问 — 或许说, 最少, 他们在用户的评论区域是对比抢手的论题.

在这篇文章中我将直面这个疑问, 并提出一些常见的解决计划.

在HDFS中的小文件疑问

这儿评论的小文件指的是那些在HDFS中小于HDFS块巨细(默许是64M)的文件.

假如你存储了很多这种小文件, 或许你有很多这种小文件 (假如你并没有运用Hadoop), 这儿评论的疑问是Hadoop不能处理很多的这种文件.

每一个文件, 目录和块在HDFS中代表一个目标存储在namenode的内存中, 它们每一个占用150

字节, 依据经历. 所以1000万个文件,每一个运用一个块, 将大概需求3GB的内存. 远远超越当时的硬件处理水平. 当然10亿个文件直接无法处理.

此外, HDFS是没有才能去有效地拜访小文件:它首要是专为串行流式拜访的大文件规划的.

阅览小文件一般会致使从一个DataNode到DataNode检索每个小文件, 一切的这些拜访数据功率都是很低下的.

在MapReduce中小文件疑问

Map使命每次能处理一个块的输入 (运用的是默许的FileInputFormat).

假如文件十分小而且还很多, 致使每次Map使命发生十分小的输入, 一起这儿需求很多的map使命, 这么增加了很多额定的开支. 对比一个1GB 文件分红16

64MB 块, 10,000 或许 100KB 文件. 10,000文件每个文件运用一个map使命, 这个使命比一个持平的大文件要慢10或许上百倍.

这儿有一些特征能够减轻额定的开支:多个使命运用一个JVM, 然后防止了一些JVM启动开支

(看mapred.job.reuse.jvm.num.tasks特点), 和MultiFileInputSplit能够运转多个以上的切割使命.

小文件怎样发生的?

这儿最少有两个场景

这些文件是一个更大的逻辑文件.

由于HDFS近来才支撑追加,一个十分通用的保存无界文件(例如日志文件)的形式是写在HDFS块.

有的文件一向对比小. 幻想一个大的图像库. 每一个文件是一个不一样的文件,

没有天然的办法把它们组合成一个更大的文件.

这两者需求不一样的解决计划. 对于第一个实例, 文件是有一个个记载组成, 这个疑问能够经过调用

HDFS’ssync()办法来防止 (这个是追加, 深化了解能够看 this discussion) 每一个如此频繁地写大文件.

别的,你能够经过写一个程序来把小文件衔接在一起 (查看 Nathan Marz’s post 东西能够完成这种功用).

对于第二种状况,经过一些方法来对文件进行分组操作. Hadoop供给了几种计划.

HAR files

Hadoop Archives (HAR

文件)被引进到HDFS在0.18.0版别中为了减轻寄存很多文件在namenode内存中的疑问. HAR 文件的作业原理是在HDFS中树立一个分层的文件体系.

一个 HAR文件创立经过运用hadoop archive指令,他经过运转一个MapReduce使命把HDFS中的小文件进行打包.

对于客户端运用HAR文件体系没有改动: 一切的初始文件是可见的和可拜访的 (经过运用 har:// URL). 但是,

在HDFS上的文件数量并没有减少.

在HDFS上读文件比HAR上面功率要高一些,

事实上,也许会对比慢由于每个HAR文件拜访需求两个索引文件的读取以及数据文件的读取(见下图). 尽管HAR文件能够作为MapReduce的输入文件 ,

HAR并没有允许在进行Map操作的时分把一切的文件当着一个块来操作. 它应该是供给一个输入的格局能够在HARs进步改善的当地, 实际上它并没有. 请注意

MultiFileInputSplit, 即便在 HADOOP-4565 经过挑选本地文件切割来进步, 将也需求查询每一个小的文件.

经过与SequenceFile文件功能对比是很风趣的, 所以说.如今HARs最常运用的是来处理文档.

Sequence Files

一般答复对于“小文件疑问” 是: 运用SequenceFile.

SequenceFile文件的规划思维是运用文件名作为key文件内容作为值. 这在实践中极好. 回到10,000 100KB 文件疑问,

你能够写一个程序把他们放到一个单独的SequenceFile文件里边, 而且你能够经过串流的形势对其进行拜访(直接或许经过MapReduce)

在SequenceFile文件上进行操作. 更神奇的当地是. SequenceFiles文件能够被可拆分, 所以MapReduce能够打破成块,每一块独立操作.

它们也支撑紧缩, 不像HARs. 块紧缩是大多数状况下最好的挑选, 由于紧缩了几个记载块(相当于每个记载).

它能够将现有的数据转化成为SequenceFiles.

但是,彻底有也许在并行创立一系列sequencefiles. (Stuart Sierra 现已写了一篇很有用的对于 post

变换tar文件到SequenceFile文件 — 这种东西是很有利的,

看到更多的人会极好).最好的规划在写入数据的时分直接写入到SequenceFiles文件里边, 假如也许,而不是写小文件作为中心步骤.

不像HAR文件,

SequenceFile文件无法罗列出一切的keys,简略的阅览需求获取经过全部文件. (MapFiles文件很像一个现已对key进行排序的

SequenceFiles 文件, 维护有些索引, 所以他们不能罗列一切它们的keys — 如图所示.)

SequenceFile文件相当于Java的中心. TFile文件被规划成跨渠道的,

是一个能够代替的 SequenceFile, 但它没有供给.

HBase

假如你发生了很多小文件, 但是, 依据拜访形式, 不一样类型的存储也许更合适. HBase

存储数据经过MapFiles (索引SequenceFiles), 是一个极好的挑选假如你需求MapReduce流剖析一起也需求随机拜访查看.

假如推迟是一个疑问, 但是这儿有很多其他的挑选 — 看Richard Jones’ 出色的survey of key-value stores.

[font=Tahoma  ][font=Tahoma  ]

优质IT资源分享社区为你提供此文。

本站有大量优质Java教程视频,资料等资源,包含java基础教程,高级进阶教程等等,教程视频资源涵盖传智播客,极客学院,达内,北大青鸟,猎豹网校等等IT职业培训机构的培训教学视频,价值巨大。欢迎点击下方链接查看。

java教程视频

优质IT资源分享社区(www.itziyuan.top)
一个免费,自由,开放,共享,平等,互助的优质IT资源分享网站。
专注免费分享各大IT培训机构最新培训教学视频,为你的IT学习助力!

!!!回帖受限制请看点击这里!!!
!!!资源失效请在此版块发帖说明!!!

[PS:按 CTRL+D收藏本站网址~]

——“优质IT资源分享社区”管理员专用签名~

本版相似帖子

游客