hadoophdfsftp
❶ 大数据Hadoop2.x与Hadoop3.x相比较有哪些变化
在这篇文章中，我们将讨论Hadoop 2.x与Hadoop 3.x之间的比较。 Hadoop3版本中添加了哪些新功能，Hadoop3中兼容的Hadoop 2程序，Hadoop 2和Hadoop 3有什么区别？ 我们希望Hadoop 2和Hadoop 3之间的这个功能的区别将帮助回答上述问题。
Hadoop 2.x与Hadoop 3.x之间的功能比较
本节将讲述Hadoop 2.x与Hadoop 3.x之间的22个差异。 现在让我们逐一讨论
1.License
adoop 2.x - Apache 2.0，开源
Hadoop 3.x - Apache 2.0，开源
2.支持的最低java版本
Hadoop 2.x - java的最低支持版本是java 7
Hadoop 3.x - java的最低支持版本是java 8
3.容错
Hadoop 2.x - 可以通过复制（浪费空间）来处理容错。
Hadoop 3.x - 可以通过Erasure编码处理容错。
4.数据平衡
Hadoop 2.x - 对于数据，平衡使用HDFS平衡器。
Hadoop 3.x - 对于数据，平衡使用Intra-data节点平衡器，该平衡器通过HDFS磁盘平衡器CLI调用。
5.存储Scheme
Hadoop 2.x - 使用3X副本Scheme
Hadoop 3.x - 支持HDFS中的擦除编码。
6.存储开销
Hadoop 2.x - HDFS在存储空间中有200％的开销。
Hadoop 3.x - 存储开销仅为50％。
7.存储开销示例
Hadoop 2.x - 如果有6个块，那么由于副本方案（Scheme），将有18个块占用空间。
Hadoop 3.x - 如果有6个块，那么将有9个块空间，6块block，3块用于奇偶校验。
8.YARN时间线服务
Hadoop 2.x - 使用具有可伸缩性问题的旧时间轴服务。
Hadoop 3.x - 改进时间线服务v2并提高时间线服务的可扩展性和可靠性。
9.默认端口范围
Hadoop 2.x - 在Hadoop 2.0中，一些默认端口是linux临时端口范围。所以在启动时，他们将无法绑定。
Hadoop 3.x - 但是在Hadoop 3.0中，这些端口已经移出了短暂的范围。
10.工具
Hadoop 2.x - 使用Hive，pig，Tez，Hama，Giraph和其他Hadoop工具。
Hadoop 3.x - 可以使用Hive，pig，Tez，Hama，Giraph和其他Hadoop工具。
11.兼容的文件系统
Hadoop 2.x - HDFS（默认FS），ftp文件系统：它将所有数据存储在可远程访问的FTP服务器上。 Amazon S3（简单存储服务）文件系统Windows Azure存储Blob（WASB）文件系统。
Hadoop 3.x - 它支持所有前面以及Microsoft Azure Data Lake文件系统。
12.Datanode资源
Hadoop 2.x - Datanode资源不专用于MapRece，我们可以将它用于其他应用程序。
Hadoop 3.x - 此处数据节点资源也可用于其他应用程序。
13.MR API兼容性
Hadoop 2.x - 与Hadoop 1.x程序兼容的MR API，可在Hadoop 2.X上执行
Hadoop 3.x - 此处，MR API与运行Hadoop 1.x程序兼容，以便在Hadoop 3.X上执行
14.支持Microsoft Windows
Hadoop 2.x - 它可以部署在Windows上。
Hadoop 3.x - 它也支持Microsoft Windows。
15.插槽/容器
Hadoop 2.x - Hadoop 1适用于插槽的概念，但Hadoop 2.X适用于容器的概念。通过容器，我们可以运行通用任务。
Hadoop 3.x - 它也适用于容器的概念。
16.单点故障
Hadoop 2.x - 具有SPOF的功能，因此只要Namenode失败，它就会自动恢复。
Hadoop 3.x - 具有SPOF的功能，因此只要Namenode失败，它就会自动恢复，无需人工干预就可以克服它。
17.HDFS联盟
Hadoop 2.x - 在Hadoop 1.0中，只有一个NameNode来管理所有Namespace，但在Hadoop 2.0中，多个NameNode用于多个Namespace。
Hadoop 3.x - Hadoop 3.x还有多个名称空间用于多个名称空间。
18.可扩展性
Hadoop 2.x - 我们可以扩展到每个群集10,000个节点。
Hadoop 3.x - 更好的可扩展性。 我们可以为每个群集扩展超过10,000个节点。
19.更快地访问数据
Hadoop 2.x - 由于数据节点缓存，我们可以快速访问数据。
Hadoop 3.x - 这里也通过Datanode缓存我们可以快速访问数据。
20.HDFS快照
Hadoop 2.x - Hadoop 2增加了对快照的支持。 它为用户错误提供灾难恢复和保护。
Hadoop 3.x - Hadoop 2也支持快照功能。
21.平台
Hadoop 2.x - 可以作为各种数据分析的平台，可以运行事件处理，流媒体和实时操作。
Hadoop 3.x - 这里也可以在YARN的顶部运行事件处理，流媒体和实时操作。
22.群集资源管理
Hadoop 2.x - 对于群集资源管理，它使用YARN。 它提高了可扩展性，高可用性，多租户。
Hadoop 3.x - 对于集群，资源管理使用具有所有功能的YARN。
小伙伴们想了解更多的大数据相关技术可以点击文章末尾“了解更多”查看
了解更多
❷ 4、Hadoop-HDFS部署步骤（1.X）
· 依赖软件ssh、jdk
· 环境的配置
Java_Home
免密钥
· 时间同步
· hosts、hostname
· /opt/sxt/
· 配置文件新修改
Java_Home
· 角色在哪里启动
部署参考步骤（请点击此处）
（1）设置ssh免密钥
ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
此时可检验是否设置成功，尝试免密登录本机，如下
（2）安装jdk
首先利用xftp将安装包导入，再解压安装
解压后，java所在目录位置如下 /usr/java
配置环境变量，打开 vi /etc/profile 追加下面两行
保存退出后，是设置系统配置，linux下使用source /etc/profile保存配置后，新的环境变量只能在一个终端里面有效。
（3）hadoop部署
利用xftp将hadoop-2.6.5.tar.gz包上传，解压安装
新建目录存放hadoop
配置hadoop环境变量，增加如下两行
进入如下目录修改hadoop-env.sh等配置文件，首先修改hadoop-env.sh文件，改后如下
其次、修改mapred-env.sh，/usr/java/jdk1.8.0_261-amd64
修改yarn-env.sh
其次修改etc/hadoop下的core-site.xml和hdfs-site.xml,使主节点位置可知
```
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://node01:9000</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/var/sxt/hadoop/local</value>
</property>
</configuration>
```
```
<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.namenode.secondary.http-address</name>
<value>node01:50090</value>
</property>
</configuration>
```
配置slaves文件，使DataNode可知，修改如下，如以后还有namenode，可添加
随后格式化 hdfs namenode -format 显示successfully则配置成功
启动，如报错，在查看下方日志文件排错
访问node01：50070 如下所示，成功！
计划：node01 ： NameNode
node02 ： SecondaryNode DataNode
node03 node04 ： DataNode
（1）安装jdk，配置环境变量，设置ssh免密钥（将node01d1ssh的id_dsa.pub写到其他三个节点）
此时查看node02中.ssh下目录
或者直接将node01的authorized_keys追加到node02的.ssh下，如下所示，此时node01可以免密登录node02
之后node03和node04依次执行图3-1和图3-2的命令。校准四个系统时间
修改node01的core-site.xml
进入node01的sxt目录将hadoop-2.6.5拷贝到node02（03、04都要执行相同步骤）的同目录下（node02下的opt/sxt）
经过以上步骤配置完成，再从node01进行格式化
hdfs namenode -format
❸ ftp提取文件到hdfs
实际场景中，我们经常需要通过ftp协议把不同数据源的文件统一汇入到hdfs数据中心，经过实践，有以下的三种方法，分别列出其优缺点及适用场景。
1、 先把文件ftp到本地，然后用命令hdfsdfs –put [local_path] [hdfs_path]
优点：文件在本地可以进行本地化的一系列操作后，再放回hdfs中
缺点：文件传输经过两层，并且从源服务器到本地提取是单机串行，比较消耗时间。
适用于文件放入hfds前需要预处理的情景，如：.zip压缩文件不被hadoop支持的，所以我们可以先在本地转压缩方式然后再放入hdfs中。
2、 hdfs dfs –cp [ftp://username:password@hostname/ftp_path] [hdfs:///hdfs_path]
优点：简单，提取速度快
缺点：CLI执行不会显示进度
适用场景：适用于小文件的ftp拷贝。
3、 hadoop distcp [ftp://username:password@hostname/ftp_path] [hdfs:///hdfs_path]
优点：简单，能显示拷贝进度，并且是分布式提取的，数据比较快。
缺点： 如果拷贝的文件是不断有其他程序写入，会报错，因为该命令最后要对数据进行checksum导致两边不一致，当然，该命令是主要用于集群间拷贝的。
适用场景：大量文件或大文件的拷贝。
❹ Hadoop系列之HDFS架构
本篇文章翻译了Hadoop系列下的 HDFS Architecture ，原文最初经过笔者翻译后大概有6000字，之后笔者对内容进行了精简化压缩，从而使笔者自己和其他读者们阅读本文时能够更加高效快速的完成对Hadoop的学习或复习。本文主要介绍了Hadoop的整体架构，包括但不限于节点概念、命名空间、数据容错机制、数据管理方式、简单的脚本命令和垃圾回收概念。
PS：笔者新手一枚，如果看出哪里存在问题，欢迎下方留言！
Hadoop Distributed File System（HDFS）是高容错、高吞吐量、用于处理海量数据的分布式文件系统。
HDFS一般由成百上千的机器组成，每个机器存储整个数据集的一部分数据，机器故障的快速发现与恢复是HDFS的核心目标。
HDFS对接口的核心目标是高吞吐量而非低延迟。
HDFS支持海量数据集合，一个集群一般能够支持千万以上数量级的文件。
HDFS应用需要对文件写一次读多次的接口模型，文件变更只支持尾部添加和截断。
HDFS的海量数据与一致性接口特点，使得迁移计算以适应文件内容要比迁移数据从而支持计算更加高效。
HDFS支持跨平台使用。
HDFS使用主从架构。一个HDFS集群由一个NameNode、一个主服务器（用于管理系统命名空间和控制客户端文件接口）、大量的DataNode（一般一个节点一个，用于管理该节点数据存储）。HDFS对外暴露了文件系统命名空间并允许在文件中存储用户数据。一个文件被分成一个或多个块，这些块存储在一组DataNode中。NameNode执行文件系统命名空间的打开关闭重命名等命令并记录着块和DataNode之间的映射。DataNode用于处理客户端的读写请求和块的相关操作。NameNode和DataNode一般运行在GNU/Linux操作系统上，HDFS使用Java语言开发的，因此NameNode和DataNode可以运行在任何支持Java的机器上，再加上Java语言的高度可移植性，使得HDFS可以发布在各种各样的机器上。一个HDFS集群中运行一个NameNode，其他机器每个运行一个（也可以多个，非常少见）DataNode。NameNode简化了系统的架构，只用于存储所有HDFS元数据，用户数据不会进入该节点。下图为HDFS架构图：
HDFS支持传统的分层文件管理，用户或者应用能够在目录下创建目录或者文件。文件系统命名空间和其他文件系统是相似的，支持创建、删除、移动和重命名文件。HDFS支持用户数量限制和访问权限控制，不支持软硬链接，用户可以自己实现软硬链接。NameNode控制该命名空间，命名空间任何变动几乎都要记录到NameNode中。应用可以在HDFS中对文件声明复制次数，这个次数叫做复制系数，会被记录到NameNode中。
HDFS将每个文件存储为一个或多个块，并为文件设置了块的大小和复制系数从而支持文件容错。一个文件所有的块（除了最后一个块）大小相同，后来支持了可变长度的块。复制系数在创建文件时赋值，后续可以更改。文件在任何时候只能有一个writer。NameNode负责块复制，它周期性收到每个数据节点的心跳和块报告，心跳表示数据节点的正常运作，块报告包含了这个DataNode的所有块。
副本存储方案对于HDFS的稳定性和性能至关重要。为了提升数据可靠性、灵活性和充分利用网络带宽，HDFS引入了机架感知的副本存储策略，该策略只是副本存储策略的第一步，为后续优化打下基础。大型HDFS集群一般运行于横跨许多支架的计算机集群中，一般情况下同一支架中两个节点数据传输快于不同支架。一种简单的方法是将副本存放在单独的机架上，从而防止丢失数据并提高带宽，但是增加了数据写入的负担。一般情况下，复制系数是3，HDFS存储策略是将第一份副本存储到本地机器或者同一机架下一个随机DataNode，另外两份副本存储到同一个远程机架的不同DataNode。NameNode不允许同一DataNode存储相同副本多次。在机架感知的策略基础上，后续支持了 存储类型和机架感知相结合的策略 ，简单来说就是在机架感知基础上判断DataNode是否支持该类型的文件，不支持则寻找下一个。
HDFS读取数据使用就近原则，首先寻找相同机架上是否存在副本，其次本地数据中心，最后远程数据中心。
启动时，NameNode进入安全模式，该模式下不会发生数据块复制，NameNode接收来自DataNode的心跳和块报告，每个块都有一个最小副本数量n，数据块在NameNode接受到该块n次后，认为这个数据块完成安全复制。当完成安全复制的数据块比例达到一个可配的百分比值并再过30s后，NameNode退出安全模式，最后判断是否仍然存在未达到最小复制次数的数据块，并对这些块进行复制操作。
NameNode使用名为EditLog的事务日志持续记录文件系统元数据的每一次改动（如创建文件、改变复制系数），使用名为FsImage的文件存储全部的文件系统命名空间（包括块到文件的映射关系和文件系统的相关属性），EditLog和FsImage都存储在NameNode本地文件系统中。NameNode在内存中保存着元数据和块映射的快照，当NameNode启动后或者某个配置项达到阈值时，会从磁盘中读取EditLog和FsImage，通过EditLog新的记录更新内存中的FsImage，再讲新版本的FsImage刷新到磁盘中，然后截断EditLog中已经处理的记录，这个过程就是一个检查点。检查点的目的是确保文件系统通过在内存中使用元数据的快照从而持续的观察元数据的变更并将快照信息存储到磁盘FsImage中。检查点通过下面两个配置参数出发，时间周期（dfs.namenode.checkpoint.period）和文件系统事务数量（dfs.namenode.checkpoint.txns），二者同时配置时，满足任意一个条件就会触发检查点。
所有的HDFS网络协议都是基于TCP/IP的，客户端建立一个到NameNode机器的可配置的TCP端口，用于二者之间的交互。DataNode使用DataNode协议和NameNode交互，RPC包装了客户端协议和DataNode协议，通过设计，NameNode不会发起RPC，只负责响应来自客户端或者DataNode的RPC请求。
HDFS的核心目标是即使在失败或者错误情况下依然能够保证数据可靠性，三种常见失败情况包括NameNode故障、DataNode故障和network partitions。
网络分区可能会导致部分DataNode市区和NameNode的连接，NameNode通过心跳包判断并将失去连接的DataNode标记为挂掉状态，于是所有注册到挂掉DataNode的数据都不可用了，可能会导致部分数据块的复制数量低于了原本配置的复制系数。NameNode不断地追踪哪些需要复制的块并在必要时候进行复制，触发条件包含多种情况：DataNode不可用、复制乱码、硬件磁盘故障或者认为增大负值系数。为了避免DataNode的状态不稳定导致的复制风暴，标记DataNode挂掉的超时时间设置比较长（默认10min），用户可以设置更短的时间间隔来标记DataNode为陈旧状态从而避免在对读写性能要求高的请求上使用这些陈旧节点。
HDFS架构兼容数据各种重新平衡方案，一种方案可以在某个DataNode的空闲空间小于某个阈值时将数据移动到另一个DataNode上；在某个特殊文件突然有高的读取需求时，一种方式是积极创建额外副本并且平衡集群中的其他数据。这些类型的平衡方案暂时还未实现（不太清楚现有方案是什么...）。
存储设备、网络或者软件的问题都可能导致从DataNode获取的数据发生乱码，HDFS客户端实现了对文件内容的校验，客户端在创建文件时，会计算文件中每个块的校验值并存储到命名空间，当客户端取回数据后会使用校验值对每个块进行校验，如果存在问题，客户端就会去另一个DataNode获取这个块的副本。
FsImage和EditLog是HDFS的核心数据结构，他们的错误会导致整个HDFS挂掉，因此，NameNode应该支持时刻维持FsImage和EditLog的多分复制文件，它们的任何改变所有文件应该同步更新。另一个选择是使用 shared storage on NFS 或者 distributed edit log 支持多个NameNode，官方推荐 distributed edit log 。
快照能够存储某一特殊时刻的数据副本，从而支持HDFS在发生错误时会滚到上一个稳定版本。
HDFS的应用场景是大的数据集下，且数据只需要写一次但是要读取一到多次并且支持流速读取数据。一般情况下一个块大小为128MB，因此一个文件被切割成128MB的大块，且每个快可能分布在不同的DataNode。
当客户端在复制系数是3的条件下写数据时，NameNode通过目标选择算法收到副本要写入的DataNode的集合，第1个DataNode开始一部分一部分的获取数据，把每个部分存储到本地并转发给第2个DataNode，第2个DataNode同样的把每个部分存储到本地并转发给第3个DataNode，第3个DataNode将数据存储到本地，这就是管道复制。
HDFS提供了多种访问方式，比如 FileSystem Java API 、 C language wrapper for this Java API 和 REST API ，而且还支持浏览器直接浏览。通过使用 NFS gateway ，客户端可以在本地文件系统上安装HDFS。
HDFS使用目录和文件的方式管理数据，并提供了叫做 FS shell 的命令行接口，下面有一些简单的命令：
DFSAdmin命令集合用于管理HDFS集群，这些命令只有集群管理员可以使用，下面有一些简单的命令：
正常的HDFS安装都会配置一个web服务，通过可配的TCP端口对外暴露命名空间，从而使得用户可以通过web浏览器查看文件内容。
如果垃圾回收配置打开，通过FS shell移除的文件不会立刻删除，而是会移动到一个垃圾文件专用的目录（/user/<username>/.Trash），类似回收站，只要文件还存在于那个目录下，则随时可以被回复。绝大多数最近删除的文件都被移动到了垃圾目录（/user/<username>/.Trash/Current），并且HDFS每个一段时间在这个目录下创建一个检查点用于删除已经过期的旧的检查点，详情见 expunge command of FS shell 。在垃圾目录中的文件过期后，NameNode会删除这个文件，文件删除会引起这个文件的所有块的空间空闲，需要注意的是在文件被删除之后和HDFS的可用空间变多之间会有一些时间延迟（个人认为是垃圾回收机制占用的时间）。下面是一些简单的理解删除文件的例子：
当文件复制系数减小时，NameNode会选择多余的需要删除的副本，在收到心跳包时将删除信息发送给DataNode。和上面一样，这个删除操作也是需要一些时间后，才能在集群上展现空闲空间的增加。
HDFS Architecture
❺ 如何hadoop distcp ftp目录中部分文件
hadoop中有一个叫做distcp（分布式复制）的有用程序，能从hadoop的文件系统并行复制大量数据。
distcp一般用于在两个HDFS集群中传输数据。如果集群在hadoop的同一版本上运行，就适合使用hdfs方案：
% hadoop distcp hdfs://namenode1/foo hdfs://namenode2/bar
这将从第一个集群中复制/foo目录（和它的内容）到第二个集群中的/bar目录下，所以第二个集群会有/bar/foo目录结构。如果/bar不存在，则会新建一个。可以指定多个源路径，并且所有的都会被复制到目标路径。源路径必须是绝对路径。
默认情况下，distcp会跳过目标路径已经有的文件，但可以通过提供的-overwrite选项进行覆盖，也可以用-update选项来选择只更新那些修改过的文件。第一个集群的子树/foo下的一个文件与第二个集群的改变进行同步。
% hadoop distcp -update hdfs://namenode1/foo hdfs://namenode2/bar/foo
distcp是作为一个MapRece作业执行的，复制工作由集群中并行运行的map来完成。这里没有recer。每个文件都由一个单一的map进行复制，并且distcp通过将文件分成大致相等的文件来为每个map数量大致相同的数据。
map的数量确定：
通过让每一个map复制数量合理的数据以最小化任务建立所涉及的开销，是一个很好的想法，所以每个map的副本至少为256MB。例如，1GB的文件被分成4个map任务。如果数据很大，为限制带宽和集群的使用而限制映射的数据就变得很有必要。map默认的最大数量是每个集群节点（tasktracker）有20个。例如，复制1000GB的文件到一个100个节点的集群，会分配2000个map（每个节点20个map），所以平均每个会复制512MB。通过对distcp指定-m参数，会减少映射的分配数量。例如，-m 1000会分配1000个map，平均每个复制1GB。
如果想在两个运行着不同版本HDFS的集群上利用distcp，使用hdfs协议是会失败的，因为RPC系统是不兼容的。想要弥补这种情况，可以使用基于HTTP的HFTP文件系统从源中进行读取。这个作业必须运行在目标集群上，使得HDFS RPC版本是兼容的。使用HFTP重复前面的例子：% hadoop distcp hftp://namenode1:50070/foo hdfs://namenode2/bar
注意，需要在URI源中指定名称节点的Web端口。这是由dfs.http.address的属性决定的，默认值为50070。
保持HDFS集群的平衡
向HDFS复制数据时，考虑集群的平衡相当重要。文件块在集群中均匀地分布时，HDFS能达到最佳工作状态。回顾前面1000 GB数据的例子，通过指定-m选项为1，即由一个单一的map执行复制工作，它的意思是，不考虑速度变慢和未充分利用集群资源，每个块的第一个副本会存储在运行map的节点上(直到磁盘被填满)。第二和第三个副本分散在集群中，但这一个节点并不会平衡。通过让map的数量多于集群中节点的数量，我们便可避免这个问题。鉴于此，最好首先就用默认的每个节点20个map这个默认设置来运行distcp。
然而，这也并不总能阻止一个集群变得不平衡。也许想限制map的数量以便一些节点可以被其他作业使用。若是这样，可以使用balancer工具继续改善集群中块的分布。
❻ hadoop上传问题
是不是hdfs空间满了，还有是不是上传的 文件路径 都是相同的啊，如果是相同的，就是在对同一文件进行put
http://www.linuxidc.com/Linux/2012-02/54888.htm
在数据上传的客户端hadoop- site.xml里修改配置参数 dfs.socket.timeout（默认十分钟），之后重新运行大批量的数据上传操作，问题不再重现：）
❼ hadoop2 VS hadoop3 功能对比
1.目的
在这篇文章中，我们将讨论Hadoop 2.x与Hadoop 3.x之间的比较。 Hadoop3版本中添加了哪些新功能，Hadoop3中兼容的Hadoop 2程序，Hadoop 2和Hadoop 3有什么区别？ 我们希望Hadoop 2和Hadoop 3之间的这个功能的区别将帮助回答上述问题。
2.1License
Hadoop 2.x - Apache 2.0，开源
Hadoop 3.x - Apache 2.0，开源
2.2支持的最低Java版本
Hadoop 2.x - java的最低支持版本是java 7
Hadoop 3.x - java的最低支持版本是java 8
2.3容错
Hadoop 2.x - 可以通过复制（浪费空间）来处理容错。
Hadoop 3.x - 可以通过Erasure编码处理容错。
2.4数据平衡
Hadoop 2.x - 对于数据，平衡使用HDFS平衡器。
Hadoop 3.x - 对于数据，平衡使用Intra-data节点平衡器，该平衡器通过HDFS磁盘平衡器CLI调用。
2.5存储Scheme
Hadoop 2.x - 使用3X副本Scheme
Hadoop 3.x - 支持HDFS中的擦除编码。
2.6存储开销
Hadoop 2.x - HDFS在存储空间中有200％的开销。
Hadoop 3.x - 存储开销仅为50％。
2.7存储开销示例
Hadoop 2.x - 如果有6个块，那么由于副本方案（Scheme），将有18个块占用空间。
Hadoop 3.x - 如果有6个块，那么将有9个块占用6块空间，3个用于奇偶校验。
2.8YARN时间线服务
Hadoop 2.x - 使用具有可伸缩性问题的旧时间轴服务。
Hadoop 3.x - 改进时间线服务v2并提高时间线服务的可扩展性和可靠性。
2.9默认端口范围
Hadoop 2.x - 在Hadoop 2.0中，一些默认端口是Linux临时端口范围。所以在启动时，他们将无法绑定。
Hadoop 3.x - 但是在Hadoop 3.0中，这些端口已经移出了短暂的范围。
2.10工具
Hadoop 2.x - 使用Hive，pig，Tez，Hama，Giraph和其他Hadoop工具。
Hadoop 3.x - 可以使用Hive，pig，Tez，Hama，Giraph和其他Hadoop工具。
2.11兼容的文件系统
Hadoop 2.x - HDFS（默认FS），FTP文件系统：它将所有数据存储在可远程访问的FTP服务器上。 Amazon S3（简单存储服务）文件系统Windows Azure存储Blob（WASB）文件系统。
Hadoop 3.x - 它支持所有前面以及Microsoft Azure Data Lake文件系统。
2.12Datanode资源
Hadoop 2.x - Datanode资源不专用于MapRece，我们可以将它用于其他应用程序。
Hadoop 3.x - 此处数据节点资源也可用于其他应用程序。
2.13MR API兼容性
Hadoop 2.x - 与Hadoop 1.x程序兼容的MR API，可在Hadoop 2.X上执行
Hadoop 3.x - 此处，MR API与运行Hadoop 1.x程序兼容，以便在Hadoop 3.X上执行
2.14支持Microsoft Windows
Hadoop 2.x - 它可以部署在Windows上。
Hadoop 3.x - 它也支持Microsoft Windows。
2.15插槽/容器
Hadoop 2.x - Hadoop 1适用于插槽的概念，但Hadoop 2.X适用于容器的概念。通过容器，我们可以运行通用任务。
Hadoop 3.x - 它也适用于容器的概念。
2.16单点故障
Hadoop 2.x - 具有SPOF的功能，因此只要Namenode失败，它就会自动恢复。
Hadoop 3.x - 具有SPOF的功能，因此只要Namenode失败，它就会自动恢复，无需人工干预就可以克服它。
2.17HDFS联盟
Hadoop 2.x - 在Hadoop 1.0中，只有一个NameNode来管理所有Namespace，但在Hadoop 2.0中，多个NameNode用于多个Namespace。
Hadoop 3.x - Hadoop 3.x还有多个名称空间用于多个名称空间。
2.18可扩展性
Hadoop 2.x - 我们可以扩展到每个群集10,000个节点。
Hadoop 3.x - 更好的可扩展性。 我们可以为每个群集扩展超过10,000个节点。
2.19更快地访问数据
Hadoop 2.x - 由于数据节点缓存，我们可以快速访问数据。
Hadoop 3.x - 这里也通过Datanode缓存我们可以快速访问数据。
2.20HDFS快照
Hadoop 2.x - Hadoop 2增加了对快照的支持。 它为用户错误提供灾难恢复和保护。
Hadoop 3.x - Hadoop 2也支持快照功能。
2.21平台
Hadoop 2.x - 可以作为各种数据分析的平台，可以运行事件处理，流媒体和实时操作。
Hadoop 3.x - 这里也可以在YARN的顶部运行事件处理，流媒体和实时操作。
2.22群集资源管理
Hadoop 2.x - 对于群集资源管理，它使用YARN。 它提高了可扩展性，高可用性，多租户。
Hadoop 3.x - 对于集群，资源管理使用具有所有功能的YARN。
3.结论
正如我们已经讨论了Hadoop 2.x与Hadoop 3.x之间的22个重要差异，现在我们可以看到Hadoop 2和Hadoop 3哪个更好。
❽ Hadoop（一) HDFS概念及原理总结
HDFS的文件读取原理，主要包括以下几个步骤：
1、首先调用FileSystem对象的open方法，其实获取的是一个DistributedFileSystem的实例。
2、DistributedFileSystem通过RPC(远程过程调用)获得文件的第一批block的locations，同一block按照重复数会返回多个locations，这些locations按照hadoop拓扑结构排序，距离客户端近的排在前面。
3、前两步会返回一个FSDataInputStream对象，该对象会被封装成 DFSInputStream对象，DFSInputStream可以方便的管理datanode和namenode数据流。客户端调用read方法，DFSInputStream就会找出离客户端最近的datanode并连接datanode。
4、数据从datanode源源不断的流向客户端。
5、如果第一个block块的数据读完了，就会关闭指向第一个block块的datanode连接，接着读取下一个block块。这些操作对客户端来说是透明的，从客户端的角度来看只是读一个持续不断的流。
6、如果第一批block都读完了，DFSInputStream就会去namenode拿下一批blocks的location，然后继续读，如果所有的block块都读完，这时就会关闭掉所有的流。
HDFS的文件写入原理，主要包括以下几个步骤：
1、客户端通过调用 DistributedFileSystem 的create方法，创建一个新的文件。
2、DistributedFileSystem 通过 RPC（远程过程调用）调用 NameNode，去创建一个没有blocks关联的新文件。创建前，NameNode 会做各种校验，比如文件是否存在，客户端有无权限去创建等。如果校验通过，NameNode 就会记录下新文件，否则就会抛出IO异常。
3、前两步结束后会返回 FSDataOutputStream 的对象，和读文件的时候相似，FSDataOutputStream 被封装成 DFSOutputStream，DFSOutputStream 可以协调 NameNode和 DataNode。客户端开始写数据到DFSOutputStream,DFSOutputStream会把数据切成一个个小packet，然后排成队列 data queue。
4、DataStreamer 会去处理接受 data queue，它先问询 NameNode 这个新的 block 最适合存储的在哪几个DataNode里，比如重复数是3，那么就找到3个最适合的 DataNode，把它们排成一个 pipeline。DataStreamer 把 packet 按队列输出到管道的第一个 DataNode 中，第一个 DataNode又把 packet 输出到第二个 DataNode 中，以此类推。
5、DFSOutputStream 还有一个队列叫 ack queue，也是由 packet 组成，等待DataNode的收到响应，当pipeline中的所有DataNode都表示已经收到的时候，这时akc queue才会把对应的packet包移除掉。
6、客户端完成写数据后，调用close方法关闭写入流。
7、DataStreamer 把剩余的包都刷到 pipeline 里，然后等待 ack 信息，收到最后一个 ack 后，通知 DataNode 把文件标示为已完成。
❾ 数据库与hadoop与分布式文件系统的区别和联系
数据库与hadoop与分布式文件系统的区别和联系
1. 用向外扩展代替向上扩展
扩展商用关系型数据库的代价是非常昂贵的。它们的设计更容易向上扩展。要运行一个更大
的数据库，就需要买一个更大的机器。事实上，往往会看到服务器厂商在市场上将其昂贵的高端机
标称为“数据库级的服务器”。不过有时可能需要处理更大的数据集，却找不到一个足够大的机器。
更重要的是，高端的机器对于许多应用并不经济。例如，性能4倍于标准PC的机器，其成本将大大
超过将同样的4台PC放在一个集群中。Hadoop的设计就是为了能够在商用PC集群上实现向外扩展
的架构。添加更多的资源，对于Hadoop集群就是增加更多的机器。一个Hadoop集群的标配是十至
数百台计算机。事实上，如果不是为了开发目的，没有理由在单个服务器上运行Hadoop。
2. 用键/值对代替关系表
关系数据库的一个基本原则是让数据按某种模式存放在具有关系型数据结构的表中。虽然关
系模型具有大量形式化的属性，但是许多当前的应用所处理的数据类型并不能很好地适合这个模
型。文本、图片和XML文件是最典型的例子。此外，大型数据集往往是非结构化或半结构化的。
Hadoop使用键/值对作为基本数据单元，可足够灵活地处理较少结构化的数据类型。在hadoop中，
数据的来源可以有任何形式，但最终会转化为键/值对以供处理。
3. 用函数式编程（MapRece）代替声明式查询（SQL ）
SQL 从根本上说是一个高级声明式语言。查询数据的手段是，声明想要的查询结果并让数据库引擎
判定如何获取数据。在MapRece中，实际的数据处理步骤是由你指定的，它很类似于SQL
引擎的一个执行计划。SQL 使用查询语句，而MapRece则使用脚本和代码。利用MapRece可
以用比SQL 查询更为一般化的数据处理方式。例如，你可以建立复杂的数据统计模型，或者改变
图像数据的格式。而SQL 就不能很好地适应这些任务。
4.
分布式文件系统（dfs）和分布式数据库都支持存入，取出和删除。但是分布式文件系统比较暴力，
可以当做key/value的存取。分布式数据库涉及精炼的数据，传统的分布式关系型数据库会定义数据元
组的schema，存入取出删除的粒度较小。
分布式文件系统现在比较出名的有GFS（未开源），HDFS（Hadoop distributed file system）。
分布式数据库现在出名的有Hbase，oceanbase。其中Hbase是基于HDFS，而oceanbase是自己内部
实现的分布式文件系统，在此也可以说分布式数据库以分布式文件系统做基础存储。
共享文件与分布式文件系统的区别
分布式文件系统(Distributed File System，DFS)
如果局域网中有多台服务器，并且共享文件夹也分布在不同的服务器上，这就不利于管理员的管理和用户的访问。而使用分布式文件系统,系统管理员就可以把不同服务器上的共享文件夹组织在一起，构建成一个目录树。这在用户看来，所有共享文件仅存储在一个地点，只需访问一个共享的DFS根目录，就能够访问分布在网络上的文件或文件夹，而不必知道这些文件的实际物理位置。
ftp server和分布式文件系统的区别
换个思路，使用mount --bind把目录加载过来就可以了 先将数据盘挂载 mount /dev/sdb1 /mnt/d 在ftp目录下建一个文件夹data mount --bind /mnt/d data
FTP server和分布式文件系统的区别, 分布式文件系统和分布式数据库有什么不同
分布式文件系统（dfs）和分布式数据库都支持存入，取出和删除。但是分布式文件系统比较暴力，可以当做key/value的存取。分布式数据库涉及精炼的数据，传统的分布式关系型数据库会定义数据元组的schema，存入取出删除的粒度较小。
分布式文件系统现在比较出名的有GFS（未开源），HDFS（Hadoop distributed file system）。分布式数据库现在出名的有Hbase，oceanbase。其中Hbase是基于HDFS，而oceanbase是自己内部实现的分布式文件系统，在此也可以说分布式数据库以分布式文件系统做基础存储。
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(从服务器)。
文件系统与数据库系统的区别和联系
其区别在于：
(1)
文件系统用文件将数据长期保存在外存上，数
据库系统用数据库统一存储数据。
(2)
文件系统中的程序和数据有一
定的联系，数据库系统中的程序和数据分离。
(3)
文件系统用操作系
统中的存取方法对数据进行管理，数据库系统用
DBMS
统一管理和控
制数据。
(4)
文件系统实现以文件为单位的数据共享，数据库系统实
现以记录和字段为单位的数据共享。
其联系在于：
(1)
均为数据组织的管理技术。
(2)
均由数据管理软
件管理数据，程序与数据之间用存取方法进行转换。
(3)
数据库系统
是在文件系统的基础上发展而来的。
数据库系统和文件系统的区别与联系
文件系统和数据库系统之间的区别：
（1） 文件系统用文件将数据长期保存在外存上，数据库系统用数据库统一存储数据；
（2） 文件系统中的程序和数据有一定的联系，数据库系统中的程序和数据分离；
（3） 文件系统用操作系统中的存取方法对数据进行管理，数据库系统用DBMS统一管理和控制数据；
（4） 文件系统实现以文件为单位的数据共享，数据库系统实现以记录和字段为单位的数据共享。
文件系统和数据库系统之间的联系：
（1） 均为数据组织的管理技术；
（2） 均由数据管理软件管理数据，程序与数据之间用存取方法进行转换；
（3） 数据库系统是在文件系统的基础上发展而来的。
什么是Hadoop分布式文件系统
分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。
Hadoop是Apache软件基金会所研发的开放源码并行运算编程工具和分散式档案系统，与MapRece和Google档案系统的概念类似。
HDFS（Hadoop 分布式文件系统）是其中的一部分。