为啥要使用Hadoop

Posted 2023-04-27

参考技术A 感觉现在各个公司使用Hadoop的方式都不一样，主要我觉得有两种吧。
第一种是long running cluster形式，比如Yahoo，不要小看这个好像已经没什么存在感的公司，Yahoo可是Hadoop的元老之一。这种就是建立一个Data Center，然后有几个上千Node的Hadoop Cluster一直在运行。比较早期进入Big Data领域的公司一般都在使用或者使用过这种方式。
另一种是只使用MapReduce类型。毕竟现在是Cloud时代，比如AWS的Elastic MapReduce。这种是把数据存在别的更便宜的地方，比如s3，自己的data center， sql database等等，需要分析数据的时候开启一个Hadoop Cluster，Hive/Pig/Spark/Presto/Java分析完了就关掉。不用自己做Admin的工作，方便简洁。
所以个人如果要学Hadoop的话我也建议第二种，AWS有免费试用时间（但是EMR并不免费，所以不要建了几千个Node一个月后发现破产了），可以在这上面学习。最重要的是你可以尝试各种不同的配置对于任务的影响，比如不同的版本，不同的container size，memory大小等等，这对于学习Spark非常有帮助。
总的来说Hadoop适合应用于大数据存储和大数据分析的应用，适合于服务器几千台到几万台的集群运行，支持PB级的存储容量。Hadoop典型应用有：搜索、日志处理、推荐系统、数据分析、视频图像分析、数据保存等。 参考技术B 数据日志是每天从生产数据库导出到数据服务器，再通过一个Python脚本分析这些日志并存入mysql当中，这种方式在数据量小的情况下还没什么事，数据量一大，所需时间是几何增长。有段时间每天光apache log解压之后就有几十个G，虽然通过很多手段比如减少查询，减少单条数据插入，使用LOAD将数据导入数据库，但所需时间还是要很久。为了减少每天log分析的时间以及数据的稳定性，决定搭建一个Hadoop系统，使用hadoop map/reduce来并行的处理log。想要了解更多请关注大讲台官网。

为啥 hadoop 不能拆分一个大文本文件，然后使用 gzip 压缩拆分？

【中文标题】为啥 hadoop 不能拆分一个大文本文件，然后使用 gzip 压缩拆分？

【英文标题】：Why can't hadoop split up a large text file and then compress the splits using gzip?为什么 hadoop 不能拆分一个大文本文件，然后使用 gzip 压缩拆分？

【发布时间】：2011-06-28 18:20:46

【问题描述】：

我最近一直在研究 hadoop 和 HDFS。当您将文件加载到 HDFS 中时，它通常会将文件拆分为 64MB 的块并将这些块分布在您的集群中。除非它不能对 gzip 文件执行此操作，因为 gzip 文件无法拆分。我完全理解为什么会这样（我不需要任何人解释为什么不能拆分 gzip 文件）。但是为什么 HDFS 不能将纯文本文件作为输入并像平常一样拆分它，然后分别使用 gzip 压缩每个拆分？当访问任何拆分时，它只是在运行中解压缩。

在我的场景中，每个拆分都是完全独立压缩的。拆分之间没有依赖关系，因此您不需要整个原始文件来解压缩任何拆分。这就是此补丁所采用的方法：https://issues.apache.org/jira/browse/HADOOP-7076，请注意，这不是我想要的。

这看起来很基本......我错过了什么？为什么不能这样做？或者如果可以做到，hadoop 开发人员为什么不看这条路呢？考虑到我发现了很多关于人们想要在 HDFS 中拆分 gzip 文件的讨论，这似乎很奇怪。

【问题讨论】：

我只是想为这个问题添加评论。我正在考虑的将与 git 对其对象存储中的对象所做的完全一样。每个单独的 blob、提交和树对象在保存到磁盘之前都经过 zlib 压缩。这与实际对象是什么无关，并且在 git 管道“之上”工作的任何工具都不需要了解有关压缩格式的任何信息。

【参考方案1】：

原因很简单，就是“关注点分离”的设计原则。

如果你按照你的建议去做，那么 HDFS 必须知道文件的实际位和字节的含义。还必须使 HDFS 能够对其进行推理（即提取、解压缩等）。 一般来说，您不希望在软件中混合这种职责。

因此，理解位含义的“唯一”部分是必须能够读取它的应用程序：这通常使用 Hadoop 的 MapReduce 部分编写。

正如 HADOOP-7076 的 Javadoc 中所述（我写了那个东西；））：

永远记得有 替代方法：

解压原始 gzip 文件，将其拆分成小块并 在提供之前重新压缩碎片 他们到 Hadoop。 例如： Splitting gzipped logfiles without storing the ungzipped splits on disk 解压缩原始 gzip 文件并使用不同的压缩文件进行压缩 可拆分编解码器。例如 BZip2Codec 或根本不压缩。

HTH

【讨论】：

Hadoop 不必知道这些位的含义，就像它对可拆分的 bzip2 一样。我只是在谈论拆分完成后如何存储数据。因此，将文件拆分为 67108864 字节的块（对这些位和字节一无所知），然后在存储之前压缩每个块。我想我更多地将其视为一种存储后端格式，而不是实际的文件格式。这样，绝对可以使用任何压缩算法。

另外，bzip2 直到 0.21 才真正可拆分，这并不稳定。谁知道什么时候会发布 0.22。

HDFS 级别的 64M 块仅与这些文件如何放置在集群的数据节点上有关。此外，如果您的 gzipped 文件更大，这将对这些 GZipped 文件的作业性能产生负面影响。

HDFS 也不知道文件的位和字节是什么意思。对于 HDFS，HDFS 块和 HDFS 文件之间没有太大区别。有些文件只位于一个块中..

【参考方案2】：

HDFS 的范围有限，仅作为分布式文件系统服务，不执行诸如压缩数据之类的繁重操作。数据压缩的实际过程委托给分布式执行框架，如 Map-Reduce、Spark、Tez 等。因此，数据/文件的压缩是执行框架的关注点，而不是文件系统的关注点。

此外，Sequence-file、Parquet 等容器文件格式的存在使 HDFS 无需按照问题的建议自动压缩数据块。

总结一下，由于设计理念的原因，任何数据压缩都必须由执行引擎完成，而不是由文件系统服务完成。

【讨论】：

我想实现我的想法，你可以简单地使用一个支持透明压缩的文件系统，用于数据节点用于存储块的所有卷。

您的意思是基于硬件的压缩？...不包括此功能可能是 HDFS 实施者有意识的决定。他们将来可能会包括它..

不是硬件压缩。许多像 zfs 这样的文件系统可以进行透明压缩。