A. 请问hadoop的hdfs文件系统和本地windows文件系统或linux文件系统是什么关系啊，谢谢
hdfs的数据来实际上是存储在本地文件系统源中的。在配置hadoop时你需要配置hdfs的存储文件夹，如果你的用户名为root，文件夹位置是/root/tmp。那么你的hdfs的数据存储在/root/tmp/dfs/data/current中。其中block是块文件，也就是数据文件，.meta是元数据。hadoop是java写的，因此hadoop存储的数据的方式使用的也是java的方式。
B. spark和hadoop的区别
直接比较Hadoop和Spark有难度，因为它们处理的许多任务都一样，但是在一些方面又并不相互重叠。
比如说，Spark没有文件管理功能，因而必须依赖Hadoop分布式文件系统(HDFS)或另外某种解决方案。
Hadoop框架的主要模块包括如下：
Hadoop Common
Hadoop分布式文件系统(HDFS)
Hadoop YARN
Hadoop MapRece
虽然上述四个模块构成了Hadoop的核心，不过还有其他几个模块。这些模块包括：Ambari、Avro、Cassandra、Hive、 Pig、Oozie、Flume和Sqoop，它们进一步增强和扩展了Hadoop的功能。
Spark确实速度很快(最多比Hadoop MapRece快100倍)。Spark还可以执行批量处理，然而它真正擅长的是处理流工作负载、交互式查询和机器学习。
相比MapRece基于磁盘的批量处理引擎，Spark赖以成名之处是其数据实时处理功能。Spark与Hadoop及其模块兼容。实际上，在Hadoop的项目页面上，Spark就被列为是一个模块。
Spark有自己的页面，因为虽然它可以通过YARN(另一种资源协调者)在Hadoop集群中运行，但是它也有一种独立模式。它可以作为 Hadoop模块来运行，也可以作为独立解决方案来运行。
MapRece和Spark的主要区别在于，MapRece使用持久存储，而Spark使用弹性分布式数据集(RDDS)。
性能
Spark之所以如此快速，原因在于它在内存中处理一切数据。没错，它还可以使用磁盘来处理未全部装入到内存中的数据。
Spark的内存处理为来自多个来源的数据提供了近乎实时分析的功能：营销活动、机器学习、物联网传感器、日志监控、安全分析和社交媒体网站。另 外，MapRece使用批量处理，其实从来就不是为惊人的速度设计的。它的初衷是不断收集来自网站的信息，不需要这些数据具有实时性或近乎实时性。
易用性
支持Scala(原生语言)、Java、Python和Spark SQL。Spark SQL非常类似于SQL 92，所以几乎不需要经历一番学习，马上可以上手。
Spark还有一种交互模式，那样开发人员和用户都可以获得查询和其他操作的即时反馈。MapRece没有交互模式，不过有了Hive和Pig等附加模块，采用者使用MapRece来得容易一点。
成本
“Spark已证明在数据多达PB的情况下也轻松自如。它被用于在数量只有十分之一的机器上，对100TB数据进行排序的速度比Hadoop MapRece快3倍。”这一成绩让Spark成为2014年Daytona GraySort基准。
兼容性
MapRece和Spark相互兼容;MapRece通过JDBC和ODC兼容诸多数据源、文件格式和商业智能工具，Spark具有与MapRece同样的兼容性。
数据处理
MapRece是一种批量处理引擎。MapRece以顺序步骤来操作，先从集群读取数据，然后对数据执行操作，将结果写回到集群，从集群读 取更新后的数据，执行下一个数据操作，将那些结果写回到结果，依次类推。Spark执行类似的操作，不过是在内存中一步执行。它从集群读取数据后，对数据 执行操作，然后写回到集群。
Spark还包括自己的图形计算库GraphX。GraphX让用户可以查看与图形和集合同样的数据。用户还可以使用弹性分布式数据集(RDD)，改变和联合图形，容错部分作了讨论。
容错
至于容错，MapRece和Spark从两个不同的方向来解决问题。MapRece使用TaskTracker节点，它为 JobTracker节点提供了心跳(heartbeat)。如果没有心跳，那么JobTracker节点重新调度所有将执行的操作和正在进行的操作，交 给另一个TaskTracker节点。这种方法在提供容错性方面很有效，可是会大大延长某些操作(即便只有一个故障)的完成时间。
Spark使用弹性分布式数据集(RDD)，它们是容错集合，里面的数据元素可执行并行操作。RDD可以引用外部存储系统中的数据集，比如共享式文件系统、HDFS、HBase，或者提供Hadoop InputFormat的任何数据源。Spark可以用Hadoop支持的任何存储源创建RDD，包括本地文件系统，或前面所列的其中一种文件系统。
RDD拥有五个主要属性：
分区列表
计算每个分片的函数
依赖其他RDD的项目列表
面向键值RDD的分区程序(比如说RDD是散列分区)，这是可选属性
计算每个分片的首选位置的列表(比如HDFS文件的数据块位置)，这是可选属性
RDD可能具有持久性，以便将数据集缓存在内存中。这样一来，以后的操作大大加快，最多达10倍。Spark的缓存具有容错性，原因在于如果RDD的任何分区丢失，就会使用原始转换，自动重新计算。
可扩展性
按照定义，MapRece和Spark都可以使用HDFS来扩展。那么，Hadoop集群能变得多大呢?
据称雅虎有一套42000个节点组成的Hadoop集群，可以说扩展无极限。最大的已知Spark集群是8000个节点，不过随着大数据增多，预计集群规模也会随之变大，以便继续满足吞吐量方面的预期。
安全
Hadoop支持Kerberos身份验证，这管理起来有麻烦。然而，第三方厂商让企业组织能够充分利用活动目录Kerberos和LDAP用于身份验证。同样那些第三方厂商还为传输中数据和静态数据提供数据加密。
Hadoop分布式文件系统支持访问控制列表(ACL)和传统的文件权限模式。Hadoop为任务提交中的用户控制提供了服务级授权(Service Level Authorization)，这确保客户拥有正确的权限。
Spark的安全性弱一点，目前只支持通过共享密钥(密码验证)的身份验证。Spark在安全方面带来的好处是，如果你在HDFS上运行Spark，它可以使用HDFS ACL和文件级权限。此外，Spark可以在YARN上运行，因而能够使用Kerberos身份验证。
总结
Spark与MapRece是一种相互共生的关系。Hadoop提供了Spark所没有的功能特性，比如分布式文件系统，而Spark 为需要它的那些数据集提供了实时内存处理。完美的大数据场景正是设计人员当初预想的那样：让Hadoop和Spark在同一个团队里面协同运行。
然后看这篇文章：Link
注：对下面这一段持保留意见：
此外我们这里还要讲到的是一个关于spark的重要误区—“spark是基于内存的技术”。它不是基于内存的技术；spark是一个管道式的执行引擎，而且在shuffle的过程中会将数据写入磁盘(比如说，如果我们想针对某个字段做聚合操作)、如果内存不够的话也一样会内存溢出(但是内存可以调整)。因此，spark之所以比MapRece快主要是因为它是管道式处理方式而不是有些人说的“基于内存的优化”。当然，spark在内存中做了缓存来提高性能，但这不是spark真正工作快的原因。
现在，我们再来完整比对一下：
1. MapRece可以被Spark Core替换？是的，它会随着时间的推移被替代，而且这种替代是合理的。但是spark目前还不是特别成熟能完全替代MapRece。此外，也没有人会完全放弃MapRece,除非所有依赖MapRece的工具都有可替代方案。比如说，想要在pig上运行的脚本能在spark上执行还是有些工作要做的。
（注：Pig是一种数据流语言，用来快速轻松的处理巨大的数据，雅虎推出的，现在正在走下坡路。Pig可以非常方便的处理HDFS和HBase的数据，和Hive一样,Pig可以非常高效的处理其需要做的，通过直接操作Pig查询可以节省大量的劳动和时间。当你想在你的数据上做一些转换，并且不想编写MapRece jobs就可以用Pig.）
2. Hive可以被Spark SQL替换？是的，这又是对的。但是我们需要理解的是Spark SQL对于spark本身来说还是比较年轻的，大概要年轻1.5倍。相对于比较成熟的Hive来说它只能算是玩具了吧，我将在一年半到两年之内再回头来看Spark SQL.。如果我们还记得的话，两到三年前Impala就号称要终结Hive,但是截止到目前两种技术也还是共存状态，Impala并没有终结Hive。在这里对于Spark SQL来说也是一样的。
3. Storm可以被Spark Streaming替换？是的，可以替换。只不过平心而论storm并不是Hadoop生态系统中的一员，因为它是完全独立的工具。他们的计算模型并不太形同，所以我不认为storm会消失，反而仍会作为一个商业产品。
4. Mahout可以被MLib替换？公平的讲，Machout已经失去了市场，而且从过去的几年来看它正在快速失去市场。对于这个工具，我们可以说这里是Spark真正可以替换Hadoop生态系统中的地方。 (注：同意！Spark的ML非常好用！要好好学！)
因此，总的来说，这篇文章的结论是：
1.不要被大数据供应商的包装所愚弄。他们大量推进的是市场而不是最终的真理。Hadoop最开始是被设计为可扩展的框架，而且其中很多部分是可替换的：可以将HDFS替换为Tachyon（现在新的名字是Alluxio），可以将YARN替换为Mesos，可以将MapRece替换为Tez并且在Tez之上可以运行Hive。这将会是Hadoop技术栈的可选方案或者完全替代方案？倘若我们放弃的MR（MapRece）而使用Tez,那么它还会是Hadoop吗？
2. Spark不能为我们提供完整的技术栈。它允许我们将它的功能集成到我们的Hadoop集群中并且从中获益，而不用完全脱离我们老的集群方案。
3. Spark还不够成熟。我认为在过三到四年我们就不会再叫“Hadoop栈”而是叫它“大数据栈”或者类似的称呼。因为在大数据栈中我们有很广泛的选择可以选出不同的开源产品来组合在一起形成一个单独的技术栈使用。
C. hadoop是分布式文件系统吗
是的Hadoop分布式文件系统(HDFS)是一种被设计成适合运行在通用硬件上的分布式文件系统。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。它能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。要理解HDFS的内部工作原理，首先要理解什么是分布式文件系统。1.分布式文件系统 多台计算机联网协同工作(有时也称为一个集群)就像单台系统一样解决某种问题，这样的系统我们称之为分布式系统。 分布式文件系统是分布式系统的一个子集，它们解决的问题就是数据存储。换句话说，它们是横跨在多台计算机上的存储系统。存储在分布式文件系统上的数据自动分布在不同的节点上。 分布式文件系统在大数据时代有着广泛的应用前景，它们为存储和处理来自网络和其它地方的超大规模数据提供所需的扩展能力。2.分离元数据和数据：NameNode和DataNode 存储到文件系统中的每个文件都有相关联的元数据。元数据包括了文件名、i节点(inode)数、数据块位置等，而数据则是文件的实际内容。 在传统的文件系统里，因为文件系统不会跨越多台机器，元数据和数据存储在同一台机器上。 为了构建一个分布式文件系统，让客户端在这种系统中使用简单，并且不需要知道其他客户端的活动，那么元数据需要在客户端以外维护。HDFS的设计理念是拿出一台或多台机器来保存元数据，并让剩下的机器来保存文件的内容。 NameNode和DataNode是HDFS的两个主要组件。其中，元数据存储在NameNode上，而数据存储在DataNode的集群上。NameNode不仅要管理存储在HDFS上内容的元数据，而且要记录一些事情，比如哪些节点是集群的一部分，某个文件有几份副本等。它还要决定当集群的节点宕机或者数据副本丢失的时候系统需要做什么。 存储在HDFS上的每份数据片有多份副本(replica)保存在不同的服务器上。在本质上，NameNode是HDFS的Master(主服务器)，DataNode是Slave(从服务器)。
D. hadoop-hdfs safemode安全模式
当hdfs启动的时候，会从fsimage当中加载文件系统状态信息，然后会等到datanode报告块的存储情况，防止namenode过早地对块进行复制。在等待datanode报告的这一段时间内，namenode会进入safemode，此时只是只读模式，当datanode报告完之后，会自动退出safemode模式。 可以通过shell来人工打开 hdfs dfsadmin -safemode enter ,打开后，会在namenode的前端页面中看到，此时进入了安全模式。如果这时候在进行写操作，则会报错，提醒进入了写模式。eg： $: bin/hadoop fs -touch /foodir/newfile.txt touch: Cannot create file/foodir/newfile.txt. Name node is in safe mode. 也可以通过shell退出该模式 hdfs dfsadmin -safemode leave 。
E. Hadoop分布式文件系统HDFS和OpenStack对象存储系统Swift有何不同
最近在Quora上有人提到一个问题，有关Hadoop分布式文件系统和OpenStack对象存储的不同。问题原文如下：“HDFS （Hadoop分布式文件系统）和OpenStack对象存储（OpenStack Object Storage）似乎都有着相似的目的：实现冗余、快速、联网的存储。什么样的技术特性让这两种系统因而不一样？这两种存储系统最终趋于融合是否大有意义？”问题提出之后，很快有OpenStack的开发者进行了回复。本文在此摘抄了前两名回复进行翻译，以供各位参考。排名第一的答案来自RackSpace的OpenStack Swift开发者Chuck Their：虽然HDFS与Openstack对象存储（Swift）之间有着一些相似之处，但是这两种系统的总体设计却大不一样。1. HDFS使用了中央系统来维护文件元数据（Namenode，名称节点），而在Swift中，元数据呈分布式，跨集群复制。使用一种中央元数据系统对HDFS来说无异于单一故障点，因而扩展到规模非常大的环境显得更困难。2. Swift在设计时考虑到了多租户架构，而HDFS没有多租户架构这个概念。3. HDFS针对更庞大的文件作了优化（这是处理数据时通常会出现的情况），Swift被设计成了可以存储任何大小的文件。4. 在HDFS中，文件写入一次，而且每次只能有一个文件写入；而在Swift中，文件可以写入多次；在并发操作环境下，以最近一次操作为准。5. HDFS用Java来编写，而Swift用Python来编写。另外，HDFS被设计成了可以存储数量中等的大文件，以支持数据处理，而Swift被设计成了一种比较通用的存储解决方案，能够可靠地存储数量非常多的大小不一的文件。排名第二的答案来自Joshua McKenty，他是美国宇航局Nebula云计算项目的首席架构师，是OpenStack Nova软件的早期开发者之一，目前是OpenStack项目监管委员会的成员，还是Piston.cc这家基于OpenStack的公司的创始人。Chuck刚才详细介绍了两者的技术差异，但是没有讨论两者可想而知的融合，OpenStack设计峰会上抛出了融合这个话题。简而言之，HDFS被设计成可以使用Hadoop，跨存储环境里面的对象实现MapRece处理。对于许多OpenStack公司（包括我自己的公司）来说，支持Swift里面的处理是路线图上面的一个目标，不过不是每个人都认为MapRece是解决之道。我们已讨论过为HDFS编写包装器，这将支持OpenStack内部存储应用编程接口（API），并且让用户可以针对该数据来执行Hadoop查询。还有一个办法就是在Swift里面使用HDFS。但是这些方法似乎没有一个是理想的。OpenStack社区方面也在开展研究开发方面的一些工作，认真研究其他替代性的MapRece框架（Riak和CouchDB等）。最后，现在有别的一些存储项目，目前“隶属于”OpenStack社区（SheepDog和HC2）。充分利用数据局部性，并且让对象存储变得“更智能”，这是预计会取得进步的一个领域。
F. hadoop全家桶系列1-zookeeper
启动ZK服务: sh bin/zkServer.sh start 查看ZK服务状态: sh bin/zkServer.sh status 停止ZK服务: sh bin/zkServer.sh stop 重启ZK服务: sh bin/zkServer.sh restart 显示根目录下、文件： ls / 使用 ls 命令来查看当前 ZooKeeper 中所包含的内容 显示根目录下、文件： ls2 / 查看当前节点数据并能看到更新次数等数据 创建文件，并设置初始内容： create /zk "test" 创建一个新的 znode节点“ zk ”以及与它关联的字符串 获取文件内容： get /zk 确认 znode 是否包含我们所创建的字符串 修改文件内容： set /zk "zkbak" 对 zk 所关联的字符串进行设置 删除文件： delete /zk 将刚才创建的 znode 删除 退出客户端： quit 帮助命令： help 执行hdfs zkfc -formatZK 初始化HA的zookeeper信息 hadoop namenode -format 在nn1上执行hadoop-daemon.sh start namenode 在nn2上执行hadoop namenode -bootstrapStandby 同步 在nn2上执行 hadoop-daemon.sh start namenode 在nn1和nn2分别启动hadoop-daemon.sh start zkfc,这时两个一个变成active,一个变成standby hdfs haadmin -getServiceState 可查看HA状态 注意HA不能切换是因为nn1和nn2的没有安装fuser 在nn1和nn2上执行yum -y install psmisc 改变文件副本数 setrep hadoop fs -setrep -R -w 2 /test.txt -R 递归改变目录下所有文件的副本数。 -w 等待副本数调整完毕后返回。可理解为加了这个参数就是阻塞式的了。 hadoop dfsadmin 例如：hadoop dfsadmin -report dfsadmin命令详解 -report：查看文件系统的基本信息和统计信息。 -safemode <enter | leave | get | wait>：安全模式命令。安全模式是NameNode的一种状态，在这种状态下，NameNode不接受对名字空间的更改（只读）；不复制或删除块。NameNode在启动时自动进入安全模式，当配置块的最小百分数满足最小副本数的条件时，会自动离开安全模式。enter是进入，leave是离开。
G. 如何查看hadoop hdfs文件系统
使用插件——Hadoop-Eclipse-Plugin此方法需要借助Eclipse，插件的安装及使用请参考博文。借助Eclipse只能进行简单的HDFS操作，如查看，删除，上传，下载。以下是操作界面：
H. hadoop分布式文件系统具有怎样的特性
硬件错误硬件错误是常态而不是异常。HDFS可能由成百上千的服务器所构成，每个服务器上存储着文件系统的部分数据。我们面对的现实是构成系统的组件数目是巨大的，而且任一组件都有可能失效，这意味着总是有一部分HDFS的组件是不工作的。因此错误检测和快速、自动的恢复是HDFS最核心的架构目标。流式数据访问运行在HDFS上的应用和普通的应用不同，需要流式访问它们的数据集。HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。POSIX标准设置的很多硬性约束对HDFS应用系统不是必需的。为了提高数据的吞吐量，在一些关键方面对POSIX的语义做了一些修改。大规模数据集运行在HDFS上的应用具有很大的数据集。HDFS上的一个典型文件大小一般都在G字节至T字节。因此，HDFS被调节以支持大文件存储。它应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。简单的一致性模型HDFS应用需要一个“一次写入多次读取”的文件访问模型。一个文件经过创建、写入和关闭之后就不需要改变。这一假设简化了数据一致性问题，并且使高吞吐量的数据访问成为可能。Map/Rece应用或者网络爬虫应用都非常适合这个模型。目前还有计划在将来扩充这个模型，使之支持文件的附加写操作。“移动计算比移动数据更划算”一个应用请求的计算，离它操作的数据越近就越高效，在数据达到海量级别的时候更是如此。因为这样就能降低网络阻塞的影响，提高系统数据的吞吐量。将计算移动到数据附近，比之将数据移动到应用所在显然更好。HDFS为应用提供了将它们自己移动到数据附近的接口。异构软硬件平台间的可移植性HDFS在设计的时候就考虑到平台的可移植性。这种特性方便了HDFS作为大规模数据应用平台的推广。
I. Hadoop分布式文件系统HDFS和OpenStack对象存储系统Swift有何不同
1.HDFS使用集中式单一节点架构(NameNode)来维护文件系统元数据，而在Swift中，元数据分布在整个集群中并拥有多个副本。注意：集中式元数据存储使HDFS存在性能、单点故障和扩展性问题，因此规模越大就性能越低，就越容易不可用，就越难扩展甚至不能扩展，所幸的是HDFS2使用NameNodeHA和HDFSFederation解决了这三个问题。2.Swift在设计时考虑到了多租户架构，而HDFS没有多租户架构这个概念。3.HDFS针对大文件作了优化(HDFS关注吞吐量，常用于批量数据处理)，而Swift被设计成可以存储任意大小的文件。4.在HDFS中，文件只能写入一次（部分版本可以使用Append操作在文件的末尾添加数据，但不支持在文件的任意位置进行修改），而在Swift中，文件可以写入多次。5.HDFS用Java来编写，而Swift用Python来编写。
J. Hadoop分布式文件系统（HDFS）会不会被淘汰
首先我们应该更具体的理解这样一个现象，为什么流行的技术框架会被淘汰。谈到淘汰，常见两种情况： 第一：应用模式被淘汰了，例如：BB机，功能机，最终被智能机淘汰，胶卷被数码相机淘汰，即便诺基亚的功能机做得再完美，也会被淘汰。软件方面例如：终端的字处理，邮件收发等应用软件被视窗应用软件淘汰。 第二：技术升级，新技术弥补了老技术的缺陷，并且引入了更多有优势的功能。例如：Springframework的横空出世，配合Hibernate，在具有同样功效的情况下，解决了EJB的部署复杂，体态臃肿，计算效率低，用灵活性，面向程序员的友好性，淘汰了曾经企业级经典的EJB。 那么对于Hadoop分布式文件系统（HDFS），我们要讨论它的淘汰可能性，淘汰时间，首先我们就要看它为什么要被淘汰的因素。从模式上，分布式文件系统是大数据存储技术极为重要的一个领域，我们还看不到分布式文件系统有被淘汰的任何理由，那么我就再看技术升级是否有淘汰它的可能性。 谈技术升级，首先要看HDFS的缺点，然后再看这种缺点的解决办法，是否会带来新的技术框架，然后让HDFS埋进历史的垃圾堆。 HDFS为集中式协调架构，namenode若是单节点，部署并不复杂，但是namenode作为单节点无法可靠的运行在生产环境，必须对namenode实现双机HA，那么部署复杂度就变得极高，这时候需要在namenode，datanode的基础上再引入namenode active，namenode standby的概念，需要引入QJM的元数据共享存储并基于Paxos做一致性协调，另外需要引入ZKFC和ZooKeeper，解决主备选举，健康探测，主备切换等操作。 因此HDFS的部署复杂度完全是因为namenode HA导致的。这是集中式管理的分布式架构一个原生问题，如果在这个地方进行优化的话，那么就是简化QJM，ZKFC，ZooKeeper的多组服务，用一组服务来代替，但是namenode和datanode的分布式数据块的读写，复制，恢复机制，目前看非常成熟，高效，这是核心问题，并不是缺点，不需要更具颠覆性的优化。 由于namenode在内存中记录了所有数据块（block 默认128M）的信息，索引了数据块与datanode的关系，并且构建了文件系统树，因此可想而知namenode的元数据内存区是大量占用内存，这是没有上限的。对于较大型数据存储项目，例如上百个datanode节点和上千万个数据块的容量来说，元数据在namenode的内存大概能控制在32G以内，这是还没问题的，但是对于构建海量数据中心的超大型项目，这个问题就好像达摩克斯之剑，首先堆内存超过临界范围导致的内存寻址性能问题不说，一旦namenode内存超限到单机内存可承载的物理上最大承受范围，整个hdfs数据平台将面临停止服务。 这个问题的本质还是Google设计GFS时候采用粗放的实用主义，先把元数据都交给主节点在内存中节制，超大问题以后再解决。目前Google的GFS2设计上，已经将元数据在内存中迁移至了BigTable上，那么问题就来了：“BigTable基于GFS，而GFS2的元数据基于BigTable”？有点鸡生蛋还是蛋生鸡的自相矛盾。是的，看似矛盾实质上是架构的嵌套复用，可以这么去解读：GFS2是基于<基于GFS的BigTable的元数据存储>的下一代GFS架构。用BigTable的k-v存储模型放GFS2的元数据，虽然没有内存高效，但是够用，而且可以无限存储，用BigTable专门存储元数据形成的k-v记录最终保存成GFS数据块，因此在GFS的元数据内存中只需少量的内存占用，就能支撑天量的真正应用于数据块存储的GFS2元数据。 基于GFS2的设计思想，我相信下一代HDFS应该也是这样的方案去解决元数据的内存瓶颈问题，也就是基于<基于HDFS的HBase的元数据存储>的下一代HDFS架构。那么HDFS的元数据瓶颈问题将被彻底解决，很难看到比这更具优势的替代性技术框架了。 如下图所示： 副本数默认为3最大的问题就是占空间，这几乎是所有传统分布式文件系统（DFS）的通病。因此HDFS集群的默认空间利用率只有33.3%，这么低的利用率显然不符合一些场景，例如长期的冷数据备份，那么有没有更好的方式呢？是有的，目前比较成熟的方案就是纠删码技术，类似raid5，raid6，HDFS 3.0版本以后支持这种模式，叫做Erasure Coding(EC)方案。 HDFS是怎么通过EC方案解决磁盘利用率的问题呢？我们先聊点比较硬的原理，说说EC方案之一的条形布局： 首先数据文件写的时候会向N个节点的块(Block)依次写入，N个Block会被切成多组条(stripe 1… stripe n)，如果分布式环境有五个存储节点(DataNode)，那么就把stripe切成3个单元(cell)，然后再根据这3个cell计算出2个校验cell，然后这5个cell（3个data+2个parity）分别写入5个Block中。数据条就这么依次轮巡的方式，将校验块的位置轮换存储在不同Block上，直至写满，这样校验块的分布可以更均匀。 其次再说取数据，取数据每次只从3个DataNode中各取出1个cell，如果这3个cell都是数据cell，那么就成功拿到一组数据条stripe，如果有一个cell是校验cell，那么就能通过校验cell和另外2个数据cell计算出第3个数据cell，完成数据条stripe的组合。这种情况下，即便是5个datanode节点有2个datanode宕机了，另外3个datanode也能通过校验码计算完成剩余2个节点的数据，这就是利用纠删码技术实现数据冗余的原理。 通过这种方式，我们就比传统2副本50%，3副本33.3%的多副本模式要省空间，EC中2+1可以达到66.7%的磁盘利用率，例子是3+2可以达到60%的磁盘利用率 但是其问题是特别消耗CPU计算，上面那种读取情况，五分之三的读取数据条时间都要进行校验码计算。因此可以利用Intel CPU推出的ISA-L底层函数库专门用于提升校纠删码算法的编解码性能。通常情况下，纠删码用于冷数据的冗余，也就是不经常访问，但又必须联机存储以备查询的数据。除了磁盘利用率，多副本方式用空间换效率的方式肯定是最好，没什么问题。
