其实Hadoop不是解决大数据问题的唯一方案

Hadoop通常被认定是能够帮助你解决所有问题的唯一方案。 当人们提到“大数据”或是“数据分析”等相关问题的时候，会听到脱口而出的回答：Hadoop！实际上Hadoop被设计和建造出来，是用来解决一系列特 定问题的。对某些问题来说，Hadoop至多算是一个不好的选择。对另一些问题来说，选择Hadoop甚至会是一个错误。对于数据转换的操作，或者更广泛 意义上的抽取－转换－装载的操作（译者注：Extraction Transformation Load，ETL，数据仓库中对数据从初始状态到可用状态处理过程的经典定义）， 使用Hadoop系统能够得到很多好处， 但是如果你的问题是下面5类之中的一个的话，Hadoop可能会是一不合适的解决方案。

1.对于大数据的渴望

很多人相信他们拥有正真“大”的数据， 但通常情况并非如此。 当考虑数据容量和理解大多数人对“大数据”处理的想法的时候， 我们应当参考这篇研究论文， 没有人会因为买了一个集群的服务器而被辞退， 它告诉了我们一些有趣的事实。 Hadoop是被设计成用来处理在TB或PB级别的数据的， 而世界上大多数的计算任务处理的是100GB以下的输入数据。（Microsoft和Yahoo在这个数据统计上的中位数是14GB，而90% Facebook的任务处理的是100GB以下的数据）。对于这样的情况来说， 纵向扩展的解决方案就会在性能上胜过横向扩展（scale-out）的解决方案。

所以你需要问自己：

• 我是否有超过几个TB的数据？
• 我是否有稳定、海量的输入数据？
• 我有多少数据要操作和处理？

2.你在队列中

当你在Hadoop系统中提交计算任务的时候， 最小的延迟时间是1分钟 。 这意味系统对于客户的商品购买信息要花1分钟的时间才能响应并提供相关商品推荐。这要求系统有非常忠实和耐心的客户， 盯着电脑屏幕超过60秒钟等待结果的出现。 一种好的方案是将库存中的每一件商品都做一个预先的相关商品的计算， 放在Hadoop上。 然后提供一个网站，或者是移动应用来访问预先存储的结果，达到1秒或以下的即时响应。 Hadoop是一个非常好的做预先计算的大数据引擎。 当然，随着需要返回的数据越来越复杂，完全的预先计算会变得越来越没有效率。

所以你需要问自己：

• 用户期望的系统响应时间大概在什么范围？
• 哪些计算任务是可以通过批处理的方式来运行的？

3.你的问题会在多少时间内得到响应

对于要求实时响应查询的问题来说，Hadoop并不是一个好的解决方案。Hadoop的计算任务要在map和reduce上花费时间， 并且在shuffle阶段还要花时间。 这些过程都不是可以在限定时间内可以完成的， 所以Hadoop并不适合用于开发有实时性需求的应用。一个实际的例子是，在期货或股票市场的程序化交易系统（Program Trading）中用到的成交量加权平均价格（Volume-weighted average price，VWAP）的计算，通常是实时的。这要求交易系统在限定时间内将结果给到用户，使得他们能够进行交易。

对数据分析人员来说， 他们实际上非常想使用SQL这样的查询语言的。Hadoop系统并不能很好地支持对存储在Hadoop上的数据的随即访问 。即便你使用了HIVE来帮助将你的类似SQL的查询转换成特定MapReduce计算任务的时候， 数据的随机访问也不是Hadoop的强项。Google的Dremel系统（和它的扩展， BigQuery系统）被设计成能够在几秒中之内返回海量的数据。启示SQL还能够很好地支持数据表之间的各种join操作。 另外一些支持实时响应的技术方案包括，从Berkley 加州分校（University of California， Berkeley）的AmpLab诞生的Shark项目， 以及Horntoworks领导的Stinger项目等。

所以你需要问自己：

• 你的用户和分析人员期望的数据访问的交互性和实时性要求是怎样的？
• 你的用户希望要能够访问TB级别的数据吗，还是只需要访问其中的一部分数据？

我们应该认识到， Hadoop是在批处理的模式下工作的。 这意味着当有新的数据被添加进来的时候， 数据处理的计算任务需要在整个数据集合上重新运行一遍。所以，随着数据的增长，数据分析的时间也会随之增加。 在实际情况下，小块新数据的增加、单一种类的数据更改或者微量数据的更新都会实时地发生。通常， 商业程序都需要根据这些事件进行决策。 然而，不论这些数据多么迅速地被输入到Hadoop系统，在Hadoop处理这些数据的时候，仍然是通过批处理的方式。Hadoop 2.0的MapReduce框架YARN承诺将解决这个问题。 Twitter使用的Storm平台是另一个可行的、流行的备选方案。将Storm和例如Kafka这样的分布式消息系统结合在一起，可以支持流数据处理 和汇总的各种需求。痛苦的是，目前Storm并不支持负载平衡，但是Yahoo的S4版本中会提供。

所以你需要问自己：

• 我的数据的生命周期是多长？
• 我的业务需要多迅速地从输入数据中获得价值？
• 对我的业务来说响应实时的数据变化和更新有多重要？

实时性的广告应用和收集传感器的监控应用都要求对流数据的实时处理。 Hadoop以及之上的工具并不是解决这类问题的唯一选择。 在最近的Indy 500车赛中，迈凯轮车队在他们的ATLAS系统中使用了SAP的HANA内存数据库产品来进行数据分析，并结合Matlab来进行各种模拟，对比赛中实 时得到的赛车遥测数据进行分析和计算。很多数据分析人员认为，Hadoop的未来在于能够支持实时性和交互性的操作。

4.我才和我的社交网络分手

当数据能够被分解为键值对，又不用担心丢失上下文或者某些数据之间隐性关系的时候，Hadoop，特别是MapReduce框架，是最好的选择。但 是图这样的数据结构中包含着各种隐性的关系， 如图的边、子树 、节点之间的父子关系、权重等，而且这些关系并非都能在图中一个结点上表示。这样的特性就要求处理图的算法要在每一次的迭代计算中加入当前图的完整或部分 的信息。 这样的算法基本上用MapReduce的框架是不可能实现的，即便能够实现也会是一种很迂回的解决方案。 另外一个问题是如何制定将数据切分到不同结点上的策略。如果你要处理的数据的主要数据结构是图或者是网络， 那么你最好选择使用面向图的数据库，比如NeoJ或者Dex。或者你可以去研究一下最新的Google Pregel 或者Apache Giraph项目。

所以你需要问自己：

• 我的数据的底层结构是否和数据本身一样重要？
• 我希望从数据的结构中得到的启发和见解，是否和数据本身一样重要， 甚至更重要？

5.MapReduce的模具

很多的计算任务、工作及算法从本质上来说就是不适合使用MapReduce框架的。 上一章中已经谈到了其中一类的问题。另一类的问题是，某些计算任务需要上一步计算的结果来进行当前一步的计算。一个数学上的例子就是斐波那契数列的计算。 某些机器学习的算法，如梯度和最大期望等，也不是很适合使用MapReduce的模式。很多研究人员已经对实现这些算法中需要的特定优化和策略（全局状 态，计算时将数据结构传入进行引用等）给出了建议，但是如果用Hadoop来实现具体算法的话，还是会变得很复杂而且不易被理解。

所以你需要问自己：

• 我的业务是否对特定的算法或者领域相关的流程有非常高的要求？
• 技术团队是否有足够的能力和资源来分析算法是否可以使用MapReduce框架？

除此之外，需要考虑另外一些情况， 比如，数据总量并不大，或者数据集虽然很大，但主要是由上亿的小文件组成，而且不能拼接（如，许多图形文件需要以不同的形状被输入进来）。正如我们之前说 到的，对于那些不适合使用MapReduce分割、合并原则的计算任务，如果用Hadoop来实现他们的话，会让Hadoop的使用变得大费周折。

现在我们已经分析了在哪些情况下Hadoop不合适，让我们看一下在哪些情况下使用Hadoop是正确的选择。

你需要问自己，你的组织是否，

• 想要从一堆文本格式的日志文件中抽取信息？
• 想要将大多数是非结构化或者半结构化的数据转换为有用的、结构化的格式？
• 有没有计算任务是每天晚上在整个数据集合上运行的？（比如说信用卡公司在晚上处理所有白天的交易记录）
• 从一次数据处理中获取的结论和下一次计划要处理的结论是一致的（不像股票市场的价格，每一天都在变化）？

如果以上答案都为“是”，那么你就应该深入研究Hadoop。

以上所谈到的几类问题代表了相当大部分能够用Hadoop来解决的商业问题（尽管很多行业报告的结论是将这些类别的Hadoop系统部署到生产环境 中并不是一件容易的事情）。对于某些计算任务，Hadoop的计算模型是非常合适的。 比如说， 你需要处理海量的非结构化或半结构化的数据，然后将内容进行汇总或者将相关计算结果转换成结构化的数据， 并且将结果提供给其他组件或系统使用。如果收集的数据可以很容易地被转换位一个ID以及和它对应的内容（用Hadoop的术语来说就是键值对，key- value pair），那么你就可以使用这种简单的关联来进行不同种类的汇总计算。