新一代海量数据架构分析:NoHadoop

标签: Google 互联网 外文翻译 旧文存档 服务器架构 | 发表时间:2012-03-30 03:59 | 作者:谋万世全局者
出处:http://www.ha97.com

在经历了长达25年的统治地位后,关系型数据库正面临越来越火的“NoSQL”挑战,而挑战者是以Hadoop为代表的分布式计算开源架构。可以看到,越来越多的消息表明,不管NoSQL是被解释为“No SQL”还是“Not Only SQL”,如果你面临海量数据的挑战,那么你最应该选的海量数据架构是Hadoop。

但是Hadoop就能代表一切吗?答案显然是否定的,Hadoop的MapReduce在性能上的确是有局限性的:比如MapReduce没有索引,只有靠强大的运算能力来处理;此外,MapReduce本身存在一些lower-level实现的问题, 特别是skew和数据交换等等。

因此有些人开始回到关系型数据库上,因为相比较Hadoop的处理能力,一些SQL架构依然呈现数量级的优势。

也许,我们现在正处于一个新的“NoHadoop”时代,因为越来越多的企业开始认识到,海量数据处理仅有Hadoop是不够的。在他们看来,简单的批处理工具比如MapReduce和Hadoop恐怕并不足以应付将来更大的数据结构。诚然,大多数的比较复杂的海量数据处理我们也许能够用Hadoop就足以对付——也许更多的是一个无奈选择。它们可能涉及更复杂的连接,比如ACID需求、实时要求、超级计算的算法、图形计算、互动分析或者连续增量的需求等等。

事实上,Hadoop之所以受到越来越多的人欢迎,原因在于它对于海量数据的处理方式,而且,最重要的是,它是免费的。

但是随着对海量数据处理的应用程序性能需求不断增加,我们会发现,在很多领域,我们需要除了Hadoop以外的更多的海量数据处理方式。

那么,我们应该怎样看待下一代分布式计算架构呢?或者说,“NoHadoop”的架构应该是怎样的呢?从性能上而言,下一代的架构需要在MapReduce/Hadoop的基础上有10——10000倍的性能提高。

在每一种应用下,都有新一代的数据架构,可以提供所需的规模和效能。在未来的几年内,这些架构中的某些也许会成为主流。

1、SQL:数据库已经有了25年的发展历史。大量的创新正在围绕数据库技术,比如VoltDB、Clustrix等等(也许下一代产品不应该再称为数据库),但当你需要处理复杂的连接,或需要ACID需求时,数据库依然是你最好的选择。

应用场景:复杂的业务查询、在线交易处理。

2、Cloudscale:在海量数据上的实时分析,它打破了自由批量处理的限制。比如,当你打算分析一台百万次的服务器中发生的事件流,你需要一个真正的实时数据流体系结构。而Cloudscale架构提供的这种实时数据分析能力,比Hadoop的批处理系统快了近10000倍。

应用场景:商业算法,欺诈检测,手机广告、位置服务、市场情报。

3、MPI和BSP:相当多的超级计算机应用中,需要在海量数据上建立复杂的算法,为了实现规模效应,需要对处理器的直接访问调用以提高计算的速度。在并行计算中,MPI和BSP这些工具是进行高性能计算的必要。

应用场景:建模与仿真系统,流体动力学。

4、Pregel:当你需要分析一个复杂的社交网,或者是要分析网络的时候,面对的不是数据的问题,而是一个很大的图形。我们面临的现状是,大规模的动态图形正成为一些应用的关键。Google的Pregel结构采用了BSP模型,以便能够进行规模化、高效的图形计算。

应用场景:算法,算法的结构图,地理位置图,网络优化等

5、Dremel:这是一个需要与网络进行大规模交互的数据集。Google的Dremel的设计原理在于支持几秒内万亿行命令的执行,并提供即时查询。而它的查询执行并没有采用MapReduce 的功能。自从2006年以来Dremel诞生以来,已经有了成千上万的用户。

应用场景:数据搜索、客户支持、数据中心监控。

6、Percolator (Caffeine) :如果需要对庞大的数据增量进行不断更新,你会发现,Percolator是一种很好的实现方式,这也是Google在新的索引系统上采用的架构,Google的即时搜索引擎Instant不能没有它。“由于索引内容可以逐步增加,采用以Percolator的Google Caffeine系统检索速度将百倍于之前采用Hadoop的分布式数据处理方式。”

应用场景:实时搜索

原文链接:http://www.sys-con.com/node/1573226

作者简介:Bill McColl:Cloudscale创始人和首席执行官,牛津大学计算科学系主任,负责并行计算研究中心。

CSDN编译

相关 [量数 架构 分析] 推荐:

新一代海量数据架构分析:NoHadoop

- - 服务器运维与网站架构|Linux运维|互联网研究
在经历了长达25年的统治地位后,关系型数据库正面临越来越火的“NoSQL”挑战,而挑战者是以Hadoop为代表的分布式计算开源架构. 可以看到,越来越多的消息表明,不管NoSQL是被解释为“No SQL”还是“Not Only SQL”,如果你面临海量数据的挑战,那么你最应该选的海量数据架构是Hadoop.

GFS架构分析

- zou - NOSQL Notes
Google文件系统(Google File System,GFS)是构建在廉价的服务器之上的大型分布式系统. 它将服务器故障视为正常现象,通过软件的方式自动容错,在保证系统可靠性和可用性的同时,大大减少了系统的成本. GFS是Google云存储的基石,其它存储系统,如Google Bigtable,Google Megastore,Google Percolator均直接或者间接地构建在GFS之上.

Instagram 架构分析笔记

- Yousri - DBA Notes
Instagram 团队上个月才迎来第 7 名员工,是的,7个人的团队. 作为 iPhone 上最火爆的图片类工具,instagram 用户数量已经超过 1400 万,图片数量超过 1.5 亿张. 不得不说,这真他妈是个业界奇迹. 几天前,只有三个人的 Instagram 工程师团队发布了一篇文章:What Powers Instagram: Hundreds of Instances, Dozens of Technologies,披露了 Instagram 架构的一些信息,足够勾起大多数人的好奇心.

Android 系统架构分析

- - CSDN博客移动开发推荐文章
Android:开源的 Linux + Google 的封闭软件 + 私有的基带 + 运营商锁定 = 开放的 Android 手机. iPhone:开源的 BSD + 苹果的闭源软件 + 私有的基带 + 运营商锁定 = 封闭的苹果 iPhone. 一个平庸的应用商店,开发者依靠广告赚钱,商店并非独此一家,用户找不到好软件.

twitter系统架构分析

- - 企业架构 - ITeye博客
twitter系统架构分析. (一)twitter的核心业务. twitter的核心业务,在于following和be followed:. (1)following-关注. 进入个人主页,会看到你follow的人发表的留言(不超过140个字),这是following的过程;. (2)followed-被关注.

大型门户网站架构分析

- - 网站架构_搜搜博客搜索
   大型门户网站架构分析.   千万人同时访问的网站,一般是有很多个数据库同时工作,说明白一点就是数据库集群和并发控制,这样的网站实时性也是相对的. 这些网站都有一些共同的特点:数据量大,在线人数多,并发请求多,pageview高,响应速度快. 总结了一下各个大网站的架构,主要提高效率及稳定性的几个地方包括:.

Hadoop Metrics体系架构分析

- - 非技术 - ITeye博客
原文: http://blog.csdn.net/chenpingbupt/article/details/7957396. 本文基于Hadoop 0.20.XX版本分析,和现在的Metrics2稍有不同. Hadoop Metrics用来统计集群运行数据,比如接口调用次数,响应时间,队列长度等等,现阶段(0.19版本)支持为数不多的几个层级的数据,分别是dfs,jvm,rpc,mepred等.

Feed消息队列架构分析

- - Tim[后端技术]
最近一两年,大部分系统的数据流由基于日志的离线处理方式转变成实时的流式处理方式,并逐渐形成几种通用的使用方式,以下介绍微博的消息队列体系. 当前的主要消息队列分成如图3部分. 1、feed信息流主流程处理,图中中间的流程,通过相关MQ worker将数据写入cache、Redis及MySQL,以便用户浏览信息流.

数据分析平台系统架构

- - 企业架构 - ITeye博客
      大数据技术是近几年发展比较繁荣的技术方向,出了很多优秀的开源项目,也有越来越多的公司投入大量人力在其中. 认识到数据的重要性,数据分析平台系统也成为数据平台重点建设的项目,数据分析被广泛应用到电商、金融、教育、医疗领域. 开源的OLAP数据分析引擎:. 1.2 wedata系统架构图. 已有 0 人发表留言,猛击->> 这里<<-参与讨论.

淘宝海量数据产品的技术架构 - Mainz

- - 博客园_Mainz's Blog
淘宝海量数据产品的技术架构是什么,又是如何应对双十一的海量访问的. 按照数据的流向来划分,我们把淘宝数据产品的技术架构分为五层(如图1所示),分别是数据源、计算层、存储层、查询层和产品层. 位于架构顶端的是我们的数据来源层,这里有淘宝主站的用户、店铺、商品和交易等数据库,还有用户的浏览、搜索等行为日志等.