视频访谈： Hadoop全方位解读

观看视频有问题？

我是Boris Lublinsky，来自InfoQ SOA社区编辑，我现在和Ted Dunning讨论关于Hadoop的一切，他是MapR技术公司的首席应用架构师。Ted在许多年前就已经开始做Hadoop，所以第一个问题，你为什么要加入开源，以及为什么选择了Hadoop呢？

其实早在1975年我就在做开源，那时在Colorado州有一个小组非常活跃地为那时的新微机电脑革命编写软件。当时我们很自然地会在彼此之间分享代码，并把代码分发出去。这就是起因，但从那以后开源就在走下坡路了。我一直在参与开源，自从那时以来，几乎没有间断。

在过去的两周里，我参加了两次会议，一次是在纽约举行的Hadoop World，另一次是在旧金山举行的QCon，似乎大家都在到处谈论Hadoop。你认为是什么造就了现在的Hadoop革命呢？

Hadoop是一场真正的革命；在这个意义上讲，它没有什么规则，过去有一些技术看起来有革命的潜力，但只有Hadoop真正做到了，它真正地引导了新的做事方法。因此很多人在谈论它，尽管还没有很多人已经在做，但我们正见证一些真正的变化。我认为这种变化体现在人们所看到的情况上的不同。我看到的情况是某些成本分析曲线，正在随着数据增长从平方级或指数级变为线性形状，现在我们最终能实现改变线性形状的系数，使用Hadoop技术把成本曲线变为线性也改变了社会的本质行为，改变了采纳解决方案的方式，改变了基本经济学。大多数技术没有真正地以这种方式改变情况，Hadoop在这种方式上是一门新的技术。

有一种有趣的现象，到目前为止，IT产业的增长是通过加入越来越多的抽象概念层达到的 ，而Hadoop要试图打破这些层，把你带回到裸机，尝试着从裸机上压榨出更多价值。你对此如何看呢？

是的，这种模式我们已经看到过很多次。早在80年代中期左右，有一场仿真革命；在那之前的70年代，发生了第一次虚拟机革命，你可以使你的架构仿真在运行于裸机上的仿真机中。在每一层都仿真模拟之后，抽象概念的好处变得很清楚，但是随后抽象概念的成本也变得很清晰，然后人们再找到更有效的方式；看起来每次抽象概念都会崩溃，最终回到裸机上。我不是说Hadoop还没有接近裸机，你也许也知道有一些实现已经达到令人兴奋地接近裸机的程度了，我所知道的我们的实现是其中之一。我想这又在驱动着历史重演，不过你说得对，通过共享大型集群，我们避免只知道自己的做事方式，而忽略其他可能已经很流行的方案。

这也很可能意味着Hadoop开始对企业架构从整体上产生深远的影响。你认为通过引入Hadoop，企业架构在哪些方面在发生改变呢？

确实有些事正在发生变化。直到不久前，Hadoop对创业公司以及那些想找到一种能持续工作的软件的人来说是一个杰出的工具。企业里还没有深化这样的意识：Hadoop在处理新型问题上速度很快，因此Hadoop的优势足够大，值得冒险尝试。我前面描述的情况的变化，接着又带来了经济最大值的转折点变化；我们现在因为Hadoop而处在风口浪尖的变革时代，企业有必要采用Hadoop，而且必定会有越来越多的企业采用。对于灾难恢复有严格需求的银行以及类似企业，这些需求开始由Hadoop社区得到解决。

理解。但是我想我的问题更多是关于Hadoop如何影响企业架构？如何改变企业架构？如何适应企业现有架构，或者你认为它是一种完全不同的东西，与其他企业系统相隔离。

是的，目前它肯定是独立的，但是尽管如此，仍然对其有深远的影响。我认为将来会更多地集成在一起，我觉得Doug Cutting去年夏天在柏林时引用过一句话说得很好，引用的那个人的名字我不记得了，他说，人们是因为Hadoop才拥有大数据，而不是因为大数据才有Hadoop。经常有项目因为采用了类似Hadoop的工具而打破了某些障碍，一旦这在几个月之内发生，他们就会完全越过当初计划的范围，因为一旦这些能力成为可能，在整个组织内有巨大的需求来使用这些能力，因此Hadoop就存在了，仅仅单纯地在组织中存在也能突然导致大量的数据出现。因为人们丢弃这些数据时想着也许有一天我们能分析它，当突然有一个线索你也许可以分析时，他们开始保存那些数据，开始在很多情况下成为Hadoop狂热者，因为他们能以一种前所未有的方式来看事情。

T这很可能是Hadoop的一个方面，因为许多人在谈论Hadoop，关于他们的分析、离线处理、时钟处理以及类似的事情。但是把真正的企业赖以生存的数据迁移到Hadoop如何呢？这是我的问题的第一部分。第二部分，在InfoQ会议期间，有很多交流是关于现有企业系统的性能和扩展性，大家都承认，从性能这一角度来考虑，最昂贵的是数据访问。Hadoop把它上下颠倒了，它不是把数据推向应用，而是把应用移向数据。你认为这个会对如何设计应用产生影响吗？

绝对会。但是我认为在工作中有更深层次的原因。我认为正在发生的情况是，应用增长一般来说足够了，就像Michael Steinberger说的“一套规模不再适合所有场景”。因此我们看到面向特定应用场景的专业软件开始出现了。在数据库领域，比如Vault DB是专门用来做事务处理，它在很多方面做了折中，因此能够在事务这一特定领域做得很专业，可以完成之前不可能的任务。Hadoop也成为其所在领域内的专门工具，它专注于核心问题的横向扩展，核心问题包括核心搜索引擎、核心数据库等，也有大量非核心的边缘应用需要类似Hadoop的框架，因此在某种意义上来说，Hadoop的出现所带来的改变影响并导致了架构的根本性变化，这也是最近几年发生的Hadoop所带来的专业化的影响。

当人们在谈论Hadoop时，大多数是指HDFS和MapReduce，但是在Hadoop World和QCon会议上，我们听到了很多关于HBase的演讲，HBase似乎成了新的宠儿，特别是今年，因为直到0.90版本它还是不稳定，现在大家都认为它足够稳定，可以在企业中使用。那么在你看来，大多数人是继续选择HDFS呢，还是HBase已经显示出在实现相同功能时，提供了更简单的API有优势呢？

HDFS除了用来执行MapReduce程序之外，对其他应用来说都不可接受。它对MapReduce来说很合适，但它不具有也没有打算具有解决状态更新之类的问题，以及用来展示统计计数之类的应用、用户信息更新或者消息系统。在那种场景下，数据都相对较小，小于100万字节，一般来说小于这个大小的场景下才需要做更新。因此HBase提供了这种更新操作，无论HBase这个面向列的K-V存储的NOSQL数据库是否具有较小的应答，它们都解决了某一特定问题，这种问题是一种折中，因为关系型SQL数据库在扩展时无法解决这个问题。

但是它们从问题的不同方面来入手，用不同的方法来解决问题。HBase在写吞吐量上做得很成功。因此我们过去经常有些需求中要求的在一次写的过程中，要尽可能地减少读取磁盘的次数，这已经在数据库中实现了。许多HBase应用已经能达到1万次写只需要一次磁盘读操作，这已经开辟一个新的领域。但这只是个开始，仍然有很长的路要走，HBase和Hadoop都不是很轻易就能运行起来的，必须要有相应的专家，这方面做得还不够友好。其他的竞争对手，尤其是MongoDB，在可扩展基础上以损失性能为代价，解决了易用性的问题。因此我们需要组合不同系统的优点，MongoDB“开箱即用”的优点，HBase的写吞吐量和存储数据高性能扫描的优点，也许还有其他系统的各种优点。

HBase很让人兴奋，我今年已经尝试使用过很多次，每次我都发现它是个值得拥有的软件。现在我们开始找到HBase推动企业应用的着手点，但是这并不意味着一切都做完了，也不是说HBase今后几年就不会变了。我们能看到最近加入了协处理器技术，今后也会看到有意思的文本应用、分析应用，今后几年的HBase将会成为一款杰出的新事物。

Hadoop是Apache的未注册商标，事实上没有人直接使用Apache的发行版，市场上有些其他的Hadoop发行版，包括Cloudera、HortonWorks、Amazon的EMR ，当然也包括您最喜爱的MapR发行版。您认为是什么导致了这么多的发行版，以及这些发行版市场是如何形成的？

我想我应该向Apache致敬，我以Apache成员的身份来回答这个问题。我想对大多数最终用户来说，Apache的各种软件的原始发行版并不适合他们。要想作为一个成品，还需要打包、修补、文档和支持，以及更多的包装，然后再系上绸缎之类的事。社区正在打造这种能力，但是并不是所有的都是你需要的。我认为可以通过这么多公司的存在来做识别，这些公司都试图生产具有可比性的软件，甚至像DataStax公司的类似Hadoop的Brisk软件，他们都想将软件的优点使用在他们自己的产品里，因此这些软件需要包装、需要有用户界面，可以据此来识别，虽然这些不是消费者的需求，但这些公司是很专业的消费者。不过对于应该包装成什么样仍然有很多不一致的意见。我们有蓝球，或者红球，或者三个粉色的球吗？我们在我们的产品上放了很多球，因为我们总想着需要更多的球和闪耀的东西；HortonWorks公司说：我们应该很纯粹，做透明的包装。

关于哪个是最好的选择之类的决定是由客户说了算，而不是我们，但是我认为在社区里有那些不同的意见是非常非常健康的一种情况。Hadoop核心部分的技术仍然在那儿，至今为止它在所有发行版里占据了很大部分，但是如果仅仅因为在不同的地方下载而说他们都不是真正的Hadoop是不对的，他们的比特位还不都完全一样呢，总会有需要改变的地方。

不仅是这些小公司，也许我不该这么叫他们，但相对于IBM、Oracle来说，他们确实是小角色，大公司也即将拥有他们自己的Hadoop发行版，甚至Microsoft也声称明年Hadoop将作为SQL server的一部分。

这说明在你的产品里加入Hadoop已经变得非常流行，除此之外我不确定还能说明其他什么问题。对于这些大公司的发行会产生什么实际影响，我们仍然拭目以待。我们当然认为一个大公司，比如EMC，卖给我们的都是最好的产品，当然，我更愿意称这种产品为创新，我一般不使用创新这个词。像Microsoft包装Hadoop后创新发行，是否能获得成功仍需要再看，但是我认为这更加说明了Hadoop是多么地让人兴奋，它是一场大的变革，值得人们把精力投入到这上面来。

另一个问题是关于MapReduce，它也是Hadoop系统的核心；现在真正理解把某个问题改为使用MapReduce意味着什么的人越来越少了。不幸的是，大家都以word count这个示例作为入门，大家读完之后认为这就是MapReduce的全部。你对于想理解MapReduce范例的人有什么建议，以及对于这个问题是否有什么解决方案？

解决方案很多，而且我认为正在不停地涌现新的答案，不仅MapReduce，像BSP相关的解决方案，比如Apache的Giraffe，或者某些BSP的商业发行版也不断出现。不会是只有一个计算框架，只会越来越多。因此整个形势在好转之前还会变得更糟。我认为学习MapReduce最好的方式是根据你的实际情况找到一些简单的问题，然后使用这个工具来解决这些问题。开始时最好使用隐藏细节的工具，除非你是喜欢深究具体实现的人。如果有可工作的Hadoop集群，可以先使用Pig或Hive，以这种方式做试验，你会发现除了算法范例的限制之外还有些框架的限制，以及一些每人都必须要通过的简单障碍。

你会逐渐体会到不要把静态变量放到map函数里，诸如此类；很奇怪的是，大多数人的问题都相似。我还是认为首先需要开始尝试去做，试着编写这样的程序，看看你会在哪里遇到问题。当然，像word count这样的聚合功能很适合作为入门教程，不过我们有很多其他的更有意思的示例。其次，有一些专业化的社区，比如Mahout做数据挖掘，有些也许对这类问题比较感兴趣，或者分布式数据，或者推荐系统。这样就能以自己比较感兴趣的问题来开始学习。

这同时又会带给我们另一类问题：我知道您是Mahout的贡献者、代码提交者，您写了一本令人赞叹的Mahout的书，您建议大家如何看待机器学习呢？是否应该先做一些简单的处理数据的工作，然后开始深入，并使用Hadoop来解决问题？

机器学习是一类非常有意思的问题，它往往是我们想或不想使用某个特殊技术的分界点。Mahout是为了实现数据挖掘的可扩展，它不是Hadoop数据挖掘，它也不是任何特殊的技术，它是为了扩展的机器学习。欢迎大家通过邮件组的方式加入这个社区。如果你遇到问题时，首先需要确定问题的类型，如果你能确定一个问题及其数据源，那么你就成功了一半，这样能促使最终找到答案。在Mahout社区，我们经常提醒大家，开始时只需要找到最简单的可能的实现即可，也许是Mahout，也许会是其他工具。

是读Mahout还是Mahoot？我经常混淆。

没关系，你可以按照任意你喜欢的方式来叫它。我说Mahout是因为我喜欢盘子，在希伯来语里他有一个pan的音，这个希伯来单词的意思是真理或本质，因此我喜欢它。而且我有很多朋友来自印度南部，他们也倾向于这个发音。我知道很多人都说“Mahout”，哪一种读法可以。我想说的是，数据挖掘的任何问题，我认为首先都应该从最简单的技术开始，从最简单的实现开始，这一点非常重要。许多之前看起来好像很大的问题，按照现在对大的定义来看，也是相对较小。而在某种意义上来说，小问题在最近也变为大问题。因此对于看起来似乎比较大、比较显著的问题，要使用简单的技术，只要可以完成就好。所以你需要意识到的很重要的一件事是以简单开始，然后只采用那些可扩展的技术，他们更不活跃，某种意义上来说甚至是笨重的、更难的，相比较于快速和简单的解释性工具（跟MapReduce相反的工具）来说不够敏捷。通常从多个工具里做选择是比较好的做法，决定哪个是解决你现在的问题比较合适的工具。所以我经常以小数据和简单的方案为开始，然后再确定我真正需要的是什么。

这个听起来很有趣。你对于想使用Hadoop的人有什么建议？

Just do it（只管去做）！但是，当然，这也是件比较难的事；听起来容易做起来难。我建议的只管去做的最好办法是跟社区保持联系，最好的办法往往是亲自去做。如果你住在大城市附近，一般来说都会有月度的大数据或者Hadoop的聚会小组，也会有专业化的活动，比如月度数据挖掘小组聚会。如果你能参加其中一个，并跟大家交流，那么你会开始了解到大家在谈论什么、如何工作，你能明白如何去自己实现这些。Amazon对公众完全免费的开放了大数据资源，他们有大量的基因数据、美国的数据中心、Apache的归档的很多年的Email的样本数据集，你可以在这上面做各种实验；我一般很讨厌被推荐任何商业服务，但是Amazon允许在他们的EMR产品中使用MapReduce和Hadoop，因此你可以非常方便地在公共可用数据集上编写执行小的EMR程序。

之后如果你想的话，也可以在云服务的小型集群上跑一个Hadoop集群，只需要花几美元就可以在合理的时间内在大量硬件资源上执行任务，比如10小时、2小时，直到你学会为止。你也可以在回收的硬件资源上来跑任务，我就是以这种方式来开始学习的。我们那时在工作上有10台不太稳定的机器，没有人使用，对我来说正好可以用来做实验。如果你不想在EC2上花钱的话，一般来说都能找到这种资源。这些就是如何实现“Just do it（只管去做）”的简单说明：找人、找邮件组、在真实数据上试验；大家会给你以指引，我也很高兴来帮助大家。

非常感谢Ted，最后一个问题：MapR会与你的服务一起发布是吗？

是这样的，一个完整的发布版，坦率地说，我不会说不，如果你使用过免费版再来问我一个问题，我也会回答！