用Hadoop，仍是不用Hadoop？

本文由 伯乐在线 - Lex Lian 翻译。
英文出处：Anand Krishnaswamy。欢迎加入翻译小组。

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）的解决方案。

 

（译者注：纵向扩展scale-up一般是指在一台机器上增长或更换内存、CPU、硬盘或网络设备等硬件来实现系统总体性能的提高, 横向扩展（scale-out）指的是经过在集群中增长机器来提高集群系统总体性能的提高。论文中比较了对Hadoop系统进行各类纵向扩展和横向扩展以后， 在性能指标上进行评测的试验。结论是在某些状况下在一台机器上的纵向扩展会比在Hadoop集群中增长机器获得更高的系统性能，并且性价比会更好。这个结论打破了大多数人对Hadoop系统的简单认识， 那就是必定要用若干廉价的机器组成集群才能到达最好的总体性能。 ）

 

因此你须要问本身：

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

 

2.你在队列中

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

 

因此你须要问本身：

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

 

（译者注：原做者应该是用了B2C电子商务网站上经典的商品推荐功能做为用例，描述如何用Hadoop实现这个功能。）

 

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

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

（译者注：Hadoop的MapReduce中的shuffle过程指的是将多个map任务的结果分配给一个或多个reduc任务是的数据洗牌和分配的操做，这篇blog解释的比较详细，http://langyu.iteye.com/blog/992916 。 这里的用例是在投资银行的程序交易中，如何计算股票或期货交易的基准价格。 这样的计算我以为每次对数据的查询响应时间应该是在100ms如下的，详见http://baike.baidu.com/view/1280239.htm，http://baike.baidu.com/view/945603.htm。关于这个例子，相信投行的xdjm们应该有更多的发言权。）

 

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

 

因此你须要问本身：

• 你的用户和分析人员指望的数据访问的交互性和实时性要求是怎样的？
• 你的用户但愿要可以访问TB级别的数据吗，仍是只须要访问其中的一部分数据？

 

（译者注：Apache Hive 是Hadoop生态系统中的一个开源项目，其主要目的是在Hadoop系统上提供接近ANSI SQL的数据操做，以方便熟悉SQL语言的数据分析人员对Hadoop上的数据进行查询。Dremel 系统是Google开发的支持大数据的实时查询系统，它利用了精心设计的列式存储结构和大规模并行查询的机制， 在测试中可以到达在3秒内在分析和查询1PB数据的性能（英文论文，中文翻译 ）。 BigQuery是Google基于Dremel开发出的开放给开发人员的SaaS服务，能够对大量数据进行操做  。Berkeley Data Analytics Stack, BDAS 是AmpLab提供的基于Hadoop的大数据平台， 包含多个开源项目， 详见https://amplab.cs.berkeley.edu/software/。Spark项目是BDAS中的一个项目， 它使用Scala语言开发，提供了相似于SQL的数据操做接口，彻底兼容Hive。其主要的特色是利用底层的Spark将查询翻译为具体的计算任务。Spark会经过大量使用Hadoop集群中结点上内存的方式来进行数据缓存和在内存中进行实时计算， 达到加速查询和计算的目的。详见http://shark.cs.berkeley.edu/。Hortonworks是目前几家专一于提供基于Hadoop的大数据系统和应用的公司之一， Stinger是用来  Horontoworks提出的为了提高Hive查询性能的一系列在基于Hadoop的项目和改进的总称，其主要方法是优化Hive的文件存储格式以及针对Hive的查询请求进行分析优化。）

 

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

因此你须要问本身：

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

 

实时性的广告应用和收集传感器的监控应用都要求对流数据的实时处理。 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是正确的选择。

你须要问本身，你的组织是否，

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

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

 

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

总的来讲， 关键是要认清你拥有的各类资源，而且理解想要解决的问题的本质。 结合本文提到的一些观点和你本身的理解和认识， 你就可以选择最适合你的工具。 在某些状况下， 最终的解决方案颇有多是Hadoop。