别老扯什么Hadoop了，你的数据根本不够大

17顶
6踩

2013-09-18 11:39 by 副主编 WnouM 评论(14) 有32498人浏览

hadoop 大数据 sql

本文原名“Don't use Hadoop when your data isn't that big ”，出自有着多年从业经验的数据科学家Chris Stucchio，纽约大学柯朗研究所博士后，搞过高频交易平台，当过创业公司的CTO，更习惯称自己为统计学者。对了，他现在自己创业，提供数据分析、推荐优化咨询服务，他的邮件是：stucchio@gmail.com 。

“你有多少大数据和Hadoop的经验？”他们问我。我一直在用Hadoop，但很少处理几TB以上的任务。我基本上只是一个大数据新手——知道概念，写过代码，但是没有大规模经验。

接下来他们会问：“你能用Hadoop做简单的group by和sum操作吗？”我当然会，但我会说需要看看具体文件格式。

他们给我一个U盘，里面有所有的数据，600MB，对，他们所有的数据。不知道为什么，我用pandas.read_csv（Pandas是一种Python数据分析库）而不是Hadoop完成了这个任务后，他们显得很不满意。

Hadoop其实是挺局限的。它无非是运行某个通用的计算，用SQL伪代码表示就是： SELECT G(...) FROM table GROUP BY F(...) 你只能改变G和F操作，除非要在中间步骤做性能优化（这可不怎么好玩！）。其他一切都是死的。

（关于MapReduce，之前作者写过一篇“41个词讲清楚MapReduce”，可以参考。）

Hadoop里，所有计算都必须按照一个map、一个group by、一个aggregate或者这种计算序列来写。这和穿上紧身衣一样，多憋得慌啊。许多计算用其他模型其实更适合。忍受紧身衣的唯一原因就是，可以扩展到极大极大的数据集。可你的数据集实际上很可能根本远远够不上那个数量级。

可是呢，因为Hadoop和大数据是热词，世界有一半的人都想穿上紧身衣，即使他们根本不需要。

可我的数据有好几百MB呢！Excel都装不下

对Excel很大可不是什么大数据。有很多好工具——我喜欢用的是基于Numpy的Pandas。它可以将几百MB数据以高效的向量化格式加载到内存，在我已经3年的老笔记本上，一眨眼的功夫，Numpy就能完成1亿次浮点计算。Matlab和R也是很棒的工具。

数百MB数据一般用一个简单的Python脚本逐行读取文件、处理，然后写到了一个文件就行了。

可我的数据有10G呢！

我刚买了一台笔记本电脑。16G内存花了141.98美元，256GB SSD多收200美元。另外，如果在Pandas里加载一个10GB的csv文件，实际在内存里并没有那么大——你可以将 “17284932583” 这样的数值串存为4位或者8位整数，“284572452.2435723”存为8位双精度。

最差情况下，你还可以不同时将所有数据都一次加载到内存里。

可我的数据有100GB/500GB/1TB！

一个2T的硬盘才94.99美元，4T是169.99。买一块，加到桌面电脑或者服务器上，然后装上PostgreSQL。

Hadoop的适用范围远小于SQL和Python脚本

从计算的表达能力来说，Hadoop比SQL差多了。Hadoop里能写的计算，在SQL或者简单的Python脚本都可以更轻松地写出来。

SQL是直观的查询语言，没有太多抽象，业务分析师和程序员都很常用。SQL查询往往非常简单，而且一般也很快——只要数据库正确地做了索引，要花几秒钟的查询都不太多见。

Hadoop没有任何索引的概念，它只知道全表扫描。而且Hadoop抽象层次太多了——我之前的项目尽在应付Java内存错误、内存碎片和集群竞用了，实际的数据分析工作反而没了时间。

如果你的数据结构不是SQL表的形式（比如纯文本、JSON、二进制），一般写一小段Python或者Ruby脚本按行处理更直接。保存在多个文件里，逐个处理即可。SQL不适用的情况下，从编程来说Hadoop也没那么糟糕，但相比Python脚本仍然没有什么优势。

除了难以编程，Hadoop还一般总是比其他技术方案要慢。只要索引用得好，SQL查询非常快。比如要计算join，PostgreSQL只需查看索引（如果有），然后查询所需的每个键。而Hadoop呢，必须做全表扫描，然后重排整个表。排序通过多台机器之间分片可以加速，但也带来了跨多机数据流处理的开销。如果要处理二进制文件，Hadoop必须反复访问namenode。而简单的Python脚本只要反复访问文件系统即可。

可我的数据超过了5TB！

你的命可真苦——只能苦逼地折腾Hadoop了，没有太多其他选择（可能还能用许多硬盘容量的高富帅机器来扛），而且其他选择往往贵得要命（脑海中浮现出IOE等等字样……）。

用Hadoop唯一的好处是扩展。如果你的数据是一个数TB的单表，那么全表扫描是Hadoop的强项。此外的话，请关爱生命，尽量远离Hadoop。它带来的烦恼根本不值，用传统方法既省时又省力。

Via CSDN极客头条

来自: CSDN极客头条

分享到：

17
顶

6
踩

评论共 14 条请登录后发表评论

14 楼 psfu 2013-09-24 16:05

cywhoyi 写道

现在不说big data，都不好意思出门！其实程序员也有文艺范儿，自认为在海量方面在中国还是比较需要的，人口基数太大了，有木有？

也许吧，但是一张 1TB 的表就相当于 10亿人每人10K的数据！！

13 楼 Azurer 2013-09-23 22:55

这就跟当年沃森断定计算机不会超过XX台一样, 社会始终在进步的~~

12 楼 cywhoyi 2013-09-23 11:24

现在不说big data，都不好意思出门！其实程序员也有文艺范儿，自认为在海量方面在中国还是比较需要的，人口基数太大了，有木有？

11 楼 haibo 2013-09-22 20:06

自从被EJB朦过之后，就很少再尝试什么框架,很简单，一方面是自己的业务与目标框架不符合，另一方面是框架过于束缚，不可否认他们都很优秀，但与现实都相差太远，只有借鉴的作用

10 楼 psfu 2013-09-22 15:49

bitray 写道

dohkoos 写道

IT界的不良风气之一：过分追求新技术。

合适的才是最好的

主要是互联网行业的不良风气,号称规模大,数据多,必须新技术解决问题

5TB 的表才是Hadoop 的优势啊

9 楼 bitray 2013-09-22 14:51

dohkoos 写道

IT界的不良风气之一：过分追求新技术。

合适的才是最好的

主要是互联网行业的不良风气,号称规模大,数据多,必须新技术解决问题

8 楼 psfu 2013-09-22 10:31

赞同啊，，

7 楼 ai2ming 2013-09-21 18:38

说的不错，数据量较小的时候，普通的数据库足够应付了。

6 楼 peihexian 2013-09-20 11:49

翻译的很好，赞！

5 楼 kuchaguangjie 2013-09-19 11:56

找个能解决问题的方案, 而不是听起来很酷的方案,

4 楼 dohkoos 2013-09-18 19:08

IT界的不良风气之一：过分追求新技术。

合适的才是最好的

3 楼 hanjiangit 2013-09-18 17:58

zhangzhenjj 写道

单单数据量大不能称作大数据，还得考究这个数据集的维度，上了维度才跟这个“大”沾上了边

哪方面的维度？

2 楼 zhangzhenjj 2013-09-18 12:48

单单数据量大不能称作大数据，还得考究这个数据集的维度，上了维度才跟这个“大”沾上了边

1 楼 tongyitaiwan 2013-09-18 11:45

狗腿啊啊啊啊

发表评论

您还没有登录,请您登录后再发表评论

17顶6踩