不要用Hadoop——你的数据没有那么大

Posted 2021-04-13 Python程序员

Python部落(python.freelycode.com)组织翻译，禁止转载，欢迎转发。

他们问我：“你在大数据和Hadoop领域有多少经验？”我告诉他们我一直在用Hadoop，但是很少用在仅有几个TB数据量的工作上。实际上，我是一个大数据新手——我知道相关概念，我写相关代码，但是从没有大规模的去做这些事情。

接下来他们问我：“你能使用Hadoop做一个简单的分组和相加吗？”我当然能，仅告诉他们我需要看一些数据文件格式的示例。

他们给我一个装有他们数据的600MBflash存储（这不是一个采样，而是所有的数据）。不知道什么原因，当我的解决方案使用pandas.read_csv时候，他们好像不太满意。

Hadoop是有限制的，它允许你运行一个通用计算，我将使用伪代码描述一下这个通用计算。

Scala风格的伪代码：

collection.flatMap( (k,v) => F(k,v) ).groupBy( _._1 ).map( _.reduce( (k,v) => G(k,v) ) )

SQL风格的伪代码

SELECT G(...) FROM table GROUP BY F(...)

或者，就像几年前解释的一样：

• 目标：计算图书馆中书的数量。

• Map：你数一下奇数排的书架，我数偶数排的书架（人越多，这个部分进行的就越快）。

• Reduce：我们凑到一起，将每个人得到的数字加起来。你被允许动的唯一东西是F(k,y)和G(k,y),当然除了中间步骤的一些性能优化（通常不是有趣的那种！），别的东西都是固定死的。

它强制你使用map，group by和aggregate的术语来写每一个运算，或者是一系列这样的运算。以这种方式运行一个运算是严格约束的，很多计算更适合用于一些别的模型。使用这种严格约束的运算来做这些事情是有原因的，你可以将你的运算扩展到十分巨大的数据集合上去。但是，多数情况下，你的数据是一个规模很小的那种。

但是因为“Hadoop”和“Big Data”是时髦词，半个世界的人就想穿上这件”约束衣”，即使他们并不需要这么做。

但是我的数据是上百兆！Excel不能加载

对Excel太“大”的数据并不是“大数据”。有很多杰出工具来处理这种情况——我最钟爱建立在Numpy上的Pandas。你可以用一种高效的矢量化格式将几百兆数据加载进内存。在我用了3年的笔记本上，眨眼间numpy将100000000个浮点数乘到一起。Matlab和R也是这种任务的的杰出工具。

数百兆数据也可用简单的python脚本处理，该脚本逐行读取数据，处理，并且写到另一个文件中。

但是我的数据是10GB！

我刚买了个新笔记本。16GB的RAM花了$141.98，额外加了一个$200的SSD（容量256gb，联想预装）。别的就是你加载一个10GB的csv文件到Pandas中，通常这与内存比起来是不大的一部分——结果是使用4个或8个字节整数存储数字字符串“17284932583”，或者用8字节的double存储"284572452.2435723"。

更糟糕的情况，你可能并没有将你所有的东西同时加载进ram中。

但是，我的数据是100GB/500GB/1TB！

一个2T的硬盘花销是$94.99，4T的是$169.99。买一个加到台式机或者服务器上，接着在机器上安装Postgres。

Hadoop<< SQL, Python脚本

用计算机的术语表述，Hadoop比SQL是比更低级的。没有一个你能使用Hadoop写的计算，而不能使用SQL或者一个扫描文件的Python脚本来更容易的完成。

SQL是一个简单直接的查询语言，它有最少的抽象并且在商业分析和编程中被广泛使用。使用SQL查询是极其简便的，也很快——如果你的数据库已经有了合适的索引（index），多级查询也是不在话下。

Hadoop压根就没有index的概念，它只有整表扫描。Hadoop满是漏洞的抽象——在我的工作中，我花了很多时间来处理java内存错误，文件分片和集群间竞争，这些时间比我花在我想要执行的最直接的分析上的时间要多得多。

如果你的数据没有像SQL表一样结构化（例如，纯文本，json块，二进制块），通常是写一个小的python或ruby<脚本来处理你的每一个数据行。存数据到文件中，处理每一个文件，并且继续。在有些情况下SQL并不适用，从一个编程的角度来讲，Hadoop有更少的麻烦。但是相比于写一个简单Python脚本来读取数据数据，处理和写数据到磁盘来说，Hadoop没有任何优势。

使编码更加困难的是，Hadoop几乎总是比这个更简便的替代者慢。通过审慎的使用index，SQL查询可以非常的快——执行一个join，PostgreSQL仅仅是简单地查看一下index（如果有的话）并且查找它需要的key。Hadoop需要扫描整张表，接着是对整张表进行排序。通过将任务分发到多台机器上，排序可以更快，但是另一方面，你依然需要将数据流分发到多台机器上去。在处理二进制数据情形中，为了找到和处理数据，Hadoop要求在namenode上不断的游走。简单的python脚本仅需要在文件系统上游走。

但是我的数据多于5TB！

你的生活完了——你陷入了Hadoop中。你没有别的选择（拥有很多磁盘的大服务器可能依然可以完成任务），别的选择可能会更加昂贵。

使用Hadoop的唯一优势是便于规模扩展。如果你有一个包含数T数据的单表，Hadoop可能是一个运行全表扫描的好选择。如果你没有这么一张表，远离<Hadoop。这并不值得你用Hadoop去折腾，如果使用传统的方法，你将省时省力。

P.S． Hadoop是一个好工具

并不是故意憎恨Hadoop，我通常使用Hadoop来工作，都没有很好的掌握别的工具（小技巧：我推荐使用Scalding而不是Hive或者Pig。Scading使用Scala，这是一个得体的编程语言，使这些链化的Hadoop任务十分简便，而不需要隐藏底层上是一个mapreduce的事实）。Hadoop是一个好的工具，它在某些特定场景上进行了权衡。我在这里想说的是三思而后行，不要将运行在“云”上的“Hadoop”仅仅是去处理你“企业级”规模的500mb“大” 数据。

如果你开始学习Hadoop时需要帮助，O’Reilly有一个合适的（或者说有点过时的）介绍，在amazon上只有$32。

本文还有一个俄文版本。

英文原文：https://www.chrisstucchio.com/blog/2013/hadoop_hatred.html
译者：pyBean

了解野狗，请点击阅读原文