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导致两边不一致，当然，该命令是主要用于集群间拷贝的。

适用场景：大量文件或大文件的拷贝。

最近在弄一个信令数据汇聚的事情，主要目的是把FTP上的信令数据汇聚到HDFS上去存储。 逻辑是这样的：把FTP服务器上的文件下载到一台主机上，然后SCP到另外一台主机上的Spooling Directory Source所监控的目录下面去，sink是hdfs（这里解释一下，由于网络环境的因素，另一台不能访问到内网的FTP服务器，所以只能这样中转一下）。 嗯，想法不错，逻辑上看上去也应该没啥问题，于是就开始吭哧吭哧写脚本了。FTP上每个信令数据的每个文件的大小差不多都有300M左右。SCP到远端服务器也没出现问题，可就是agent老是会挂掉，报这个异常： 2014-11-26 12:30:16,942 ERROR org.apache.flume.source.SpoolDirectorySource: FATAL: Spool Directory source source1: { spoolDir: /var/log/apache/flumeSpool }: Uncaught exception in SpoolDirectorySource thread. Restart or reconfigure Flume to continue processing. java.nio.charset.MalformedInputException: Input length = 1 at java.nio.charset.CoderResult.throwException(CoderResult.java:277) at org.apache.flume.serialization.ResettableFileInputStream.readChar(ResettableFileInputStream.java:195) at org.apache.flume.serialization.LineDeserializer.readLine(LineDeserializer.java:134) at org.apache.flume.serialization.LineDeserializer.readEvent(LineDeserializer.java:72) at org.apache.flume.serialization.LineDeserializer.readEvents(LineDeserializer.java:91) at org.apache.flume.client.avro.ReliableSpoolingFileEventReader.readEvents(ReliableSpoolingFileEventReader.java:241) at org.apache.flume.source.SpoolDirectorySource$SpoolDirectoryRunnable.run(SpoolDirectorySource.java:224) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) 然后让我重启agent才会把Spooling Directory Source所监控的目录下面的文件抽取到HDFS上去，感觉很莫名，网上搜索了一下这个错误的原因，很多都是说可能传输的文件字符集的原因，不以为然，因为我反复测试了一下，如果是字符集的原因，那么为什么我重启一下agent又可以成功的抽取数据了。 于是我想了想是不是由于同时读写导致的问题，因为我SCP文件过去，文件较大，需要一定的时间，而flume监测到有文件马上就开始逐行读取文件转化成EVENT发送到HDFS上去，这中间肯定存在同时读写一个文件了，然后就产生的这个异常问题？ 目前仅仅是猜测，于是我修改了Spooling Directory Source的配置，加了这么一个配置： tier1.sources.source1.ignorePattern = ^(.)*\\.tmp$ 就是忽略监控目录下面的.tmp文件。然后我修改了scp的逻辑，拷贝到另一台主机上时，先命名为:原文件名.tmp（由于是.tmp文件，agent不会采集此类文件）,等SCP执行成功之后，在mv这个.tmp文件，去掉.tmp后缀，这样agent又会抽取这个文件的数据了，通过这么一处理，就巧妙的避免了同时读写一个文件的问题。 脚本调整好之后，重新运行脚本，惊喜的发现成功了，这次agent没有挂掉，大功告成了。 总结：使用Spooling Directory Source的时候，一定要避免同时读写一个文件的情况。采用上面提到的方法就可以巧妙的避开这个问题。

在这篇文章中，我们将讨论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资源不专用于MapReduce，我们可以将它用于其他应用程序。

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。

小伙伴们想了解更多的大数据相关技术可以点击文章末尾“了解更多”查看

了解更多

---