云计算

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

         [ CIO时代网 转载 ] 暂无评论

      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级别的数据吗,还是只需要访问其中的一部分数据?

     

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

    提示:支持键盘“← →”键翻页
    本文导航
    • 第1页:对于大数据的渴望

    周关注排行榜

    产品品牌

    文章推荐

    互动沙龙

    相关内容 网友评论 返回首页
    专家咨询