所以你需要问自己：
我的数据的生命周期是多长？
我的业务需要多迅速地从输入数据中获得价值？
对我的业务来说响应实时的数据变化和更新有多重要？
实时性的广告应用和收集传感器的监控应用都要求对流数据的实时处理。 Hadoop以及之上的工具并不是解决这类问题的唯一选择。 在最近的Indy 500车赛中，迈凯轮车队在他们的ATLAS系统中使用了SAP的HANA内存数据库产品来进行数据分析，并结合Matlab来进行各种模拟，对比赛中实 时得到的赛车遥测数据进行分析和计算。很多数据分析人员认为，Hadoop的未来在于能够支持实时性和交互性的操作。
（译者注：YARN是Hadoop2.0采用的新不同于MapReduce的资源管理和任务处理的框架，它号称能够支持比MapReduce更广的编程模型， 同时实现对实时查询和计算的任务的支持，详见http：//hortonworks.com/Hadoop/yarn/ 。Storm是由Twitter主导的开源项目， 是一种分布式数据处理系统，其主要特点是能够很好地支持实时性要求高的流数据处理，详见http：//storm-project.net 。淘宝和阿里巴巴都在使用Storm。Simple Scalable Streaming System， S4 是由Yahoo创建的另外一个实时流数据处理的分布式系统，详见http：//incubator.apache.org/s4/ 。这里有一篇网页引用了很多比较Yahoo S4和Storm的文章，http：//blog.softwareabstractions.com/the_software_abstractions/2013/06/links-comparing-yahoo-s4-and-storm-for-continuous-stream-processing-aka-real-time-big-data.html 。Kafka是Apache 的一个开源项目，http：//kafka.apache.org/。HANA是 SAP推出的商业产品，是可一个支持横向扩展的内存数据库解决方案，可以支持实时的大数据分析和计算。详见 http：//www.sap.com/HANA。 Matlab是Mathworks公司开发的一个用于科学计算的开发类产品， www.mathworks.com/products/matlab. McLaren 车队是著名的英国F1车队， 它是F1方程式比赛中一支非常成功的队伍。同时他们也参加美国著名的Indy 500赛车比赛。他们使用大数据平台处理赛车数据来提高赛车成绩的故事可以看这篇文章，http：//blogs.gartner.com/doug-laney/the-indy-500-big-race-bigger-data/ ）
4.我才和我的社交网络分手
当数据能够被分解为键值对，又不用担心丢失上下文或者某些数据之间隐性关系的时候，Hadoop，特别是MapReduce框架，是最好的选择。但 是图这样的数据结构中包含着各种隐性的关系， 如图的边、子树 、节点之间的父子关系、权重等，而且这些关系并非都能在图中一个结点上表示。这样的特性就要求处理图的算法要在每一次的迭代计算中加入当前图的完整或部分 的信息。 这样的算法基本上用MapReduce的框架是不可能实现的，即便能够实现也会是一种很迂回的解决方案。 另外一个问题是如何制定将数据切分到不同结点上的策略。如果你要处理的数据的主要数据结构是图或者是网络， 那么你最好选择使用面向图的数据库，比如NeoJ或者Dex。或者你可以去研究一下最新的Google Pregel 或者Apache Giraph项目。
所以你需要问自己：
我的数据的底层结构是否和数据本身一样重要？
我希望从数据的结构中得到的启发和见解，是否和数据本身一样重要， 甚至更重要？
（译者注：NeoJ 拥有商业和GPL双许可证模式，详见http：//www.neo4j.org/，Dex是商业产品，详见http：//www.sparsity-technologies.com/dex 。Apache Giraph 项目http：//giraph.apache.org 是根据Google Pregel论文http：//dl.acm.org/citation.cfm？id=1807184， http：//kowshik.github.io/JPregel/pregel_paper.pdf 的开源实现 ，是用来分析社交网络这样可以被抽象为图或网络数据结构的大数据处理平台。 ）
5.MapReduce的模具
很多的计算任务、工作及算法从本质上来说就是不适合使用MapReduce框架的。 上一章中已经谈到了其中一类的问题。另一类的问题是，某些计算任务需要上一步计算的结果来进行当前一步的计算。一个数学上的例子就是斐波那契数列的计算。 某些机器学习的算法，如梯度和最大期望等，也不是很适合使用MapReduce的模式。很多研究人员已经对实现这些算法中需要的特定优化和策略（全局状 态，计算时将数据结构传入进行引用等）给出了建议，但是如果用Hadoop来实现具体算法的话，还是会变得很复杂而且不易被理解。
所以你需要问自己：
我的业务是否对特定的算法或者领域相关的流程有非常高的要求？
技术团队是否有足够的能力和资源来分析算法是否可以使用MapReduce框架？
（译者注：梯度方法， gradient method通常用于数学优化计算中，详见http：//zh.wikipedia.org/wiki/%E6%A2%AF%E5%BA%A6%E4%B8%8B%E9%99%8D%E6%B3%95。最大期望算法maximization expectation algorithm ，通常用于概率模型及相应的机器学习算法中， http：//zh.wikipedia.org/zh-cn/%E6%9C%80%E5%A4%A7%E6%9C%9F%E6%9C%9B%E7%AE%97%E6%B3%95 ）
除此之外，需要考虑另外一些情况， 比如，数据总量并不大，或者数据集虽然很大，但主要是由上亿的小文件组成，而且不能拼接（如，许多图形文件需要以不同的形状被输入进来）。正如我们之前说 到的，对于那些不适合使用MapReduce分割、合并原则的计算任务，如果用Hadoop来实现他们的话，会让Hadoop的使用变得大费周折。
现在我们已经分析了在哪些情况下Hadoop不合适，让我们看一下在哪些情况下使用Hadoop是正确的选择。
你需要问自己，你的组织是否，
想要从一堆文本格式的日志文件中抽取信息？
想要将大多数是非结构化或者半结构化的数据转换为有用的、结构化的格式？
有没有计算任务是每天晚上在整个数据集合上运行的？（比如说信用卡公司在晚上处理所有白天的交易记录）
从一次数据处理中获取的结论和下一次计划要处理的结论是一致的（不像股票市场的价格，每一天都在变化）？
如果以上答案都为“是”，那么你就应该深入研究Hadoop。
以上所谈到的几类问题代表了相当大部分能够用Hadoop来解决的商业问题（尽管很多行业报告的结论是将这些类别的Hadoop系统部署到生产环境 中并不是一件容易的事情）。对于某些计算任务，Hadoop的计算模型是非常合适的。 比如说， 你需要处理海量的非结构化或半结构化的数据，然后将内容进行汇总或者将相关计算结果转换成结构化的数据， 并且将结果提供给其他组件或系统使用。如果收集的数据可以很容易地被转换位一个ID以及和它对应的内容（用Hadoop的术语来说就是键值对，key- value pair），那么你就可以使用这种简单的关联来进行不同种类的汇总计算。
总的来说， 关键是要认清你拥有的各种资源，并且理解想要解决的问题的本质。 结合本文提到的一些观点和你自己的理解和认识， 你就能够选择最适合你的工具。 在某些情况下， 最终的解决方案很有可能是Hadoop。
