[概览]开源大数据技术漫谈

开源大数据技术漫谈
http://sanwen8.cn/p/150ZTVb.html
简单把上述大数据技术做一个总结,大数据可以从流程上分为输入(Delivery)、处理(Processing)、存储(Storage)和查询(Querying)四个步骤,分别有对应的开源技术,而这些技术方案之间往往又是相互渗透的。看下图:

Paste_Image.png

大数据开源要从Hadoop说起。2003年Google发布了GFS的论文,2004年发布了MapReduce的论文。Yahoo的工程师们以这个设计思路开发了名为Nutch的搜索项目,并在2006年把它开源了。从此,Hadoop横空出世,开启了大数据开源的时代。

来看看Hadoop的内部构造,我们可以简单地把Hadoop分为数据存储和数据处理两大部分。待处理的数据以文件为单位被保存在HDFS(分布式文件系统)上,然后交由MapReduce进行数据处理。

HDFS(分布式文件系统)在Hadoop中负责数据的存储,其特点是可以运行在廉价的硬件上,提供了高度容错的大吞吐量的数据访问。而MapReduce是一种并行计算的方案,极大地方便了编程人员在不会分布式并行编程的情况下,将自己的程序运行在分布式系统上。

随着基于Hadoop的开发越来越多,其先天的局限性也逐步暴露出来。Hadoop原来是为搜索设计的解决方案,它的存储是基于文件系统的,包括原始输入和中间计算结果都要保存为磁盘上。而我们都知道磁盘IO是系统性能的瓶颈之一。这也造成了基于Hadoop的大数据方案在一些对实时性要求比较高的场景下不太适用。

仔细分析实时性场景,我们会发现有两种不同的实时性需求:一种是实时数据处理,另一种是实时数据查询。不同场景对数据的输入、计算、存储和查询有不同的要求,也就产生了不同的开源大数据解决方案。

第一种实时数据处理场景要求输入数据是实时的流数据,数据的分析处理要在规定时间内完成。比如要分析每年春运的人员流动数据,输入数据是海量的汽车、火车、航班旅客信息,对输出结果的时效有极高的要求,如果数据分析速度太慢,就失去了实时监控和预测的意义。

实时数据输入解决方案让输入数据以流的方式实时地进入大数据系统,而不必先存储到HDFS文件系统中,从而避免了由于磁盘IO造成的性能损失。Apache Kafka, RabbitMQ,Apache Flume等是当前比较流行的开源方案,其中Apache Kafka越来越引人注目,这主要归功于其恐怖的性能指标。Kafka目前用于LinkedIn,它每天处理超过100亿消息,持续负载平均每秒172,000消息。目前,无论从内部和外部的使用数据的应用程序大量使用多订阅者支持。每个消息发布出来后,基本上会有5.5个消息消费者使用,这导致的结果是每一天将有550亿的消息发送给实时消费者。

随着大数据中计算越来越复杂,往往一个处理过程会分解成很多小的计算任务,这些计算任务的中间结果需要保存在文件中做为下一个任务的输入。这样在计算过程中就会引入多次磁盘读写,降低了整体的计算速度。基于流处理的开源方案解决了这个问题,通过把中间计算结果保存在内存中,大大减少了磁盘读写带来的性能损失。这类方案有代表性的有Spark,STORM,samza,其中Spark发展得最好。

第二种实时数据查询场景类似于早期的商业智能解决方案,它对数据处理速度和输入数据的实时性要求不高,但对数据查询的响应速度要求极高。对这种业务需求的基本解决思路是数据的预处理和查询优化。所谓预处理就是把所有可能的查询条件组合都事先计算好,这样当实际查询发生时不必再进行计算,而可以直接使用已经算好的结果。这就引入了第二个问题,如何快速匹配查询结果。目前主流的开源查询方案包括SQL-on-Hadoop,基于Key-Value存储的cassandra,Apache HBASE,和基于列存储的Druid等。其中Druid是最近开始崭露头角的一个新项目,它采用了列存储技术,将查询速度提高到次秒级,提供了以交互方式访问数据的能力。

简单把上述大数据技术做一个总结,大数据可以从流程上分为输入(Delivery)、处理(Processing)、存储(Storage)和查询(Querying)四个步骤,分别有对应的开源技术,而这些技术方案之间往往又是相互渗透的。看下图:


大数据技术在国内的互联网企业中已经大量应用,淘宝、百度都是其中的佼佼者。特别是淘宝,由于马云在很早就把数据提到全公司的战略高度上,无论在人才上,技术实力上还是应用的深度广度上,淘宝的大数据都是走在前列的。从目前公开的资料看,淘宝的大数据平台主要还是建立在Hadoop之上的,但也在不断加入新的技术,如STORM等。淘宝不仅自己使用开源软件,自己也为开源做出贡献,比如开源系统timetunnel就是淘宝参考kafka产品的一个数据库日志采集收取发布中间件。而RocketMQ是另一个淘宝开源的消息中间件,定位于非日志的可靠消息传输,在阿里集团被广泛应用在订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发等场景。

从Hadoop开源到今天已经过了10年,开源大数据技术的发展是被不断扩大的业务需求推动的。未来的10年,随着越来越多的大数据应用的出现,新的需求又会对大数据技术提供新的挑战,推动大数据向新的领域扩展。而人工智能技术可以说是最令人激动的大数据发展方向了。目前,Google和微软都在人工智能上押了重注,同时也是开源社区中重要的领导者,比如微软的MicrosoftCognitive Services和Google的TensorFlow。 相信开源大数据技术的未来会越来越精彩。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,640评论 6 507
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,254评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,011评论 0 355
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,755评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,774评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,610评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,352评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,257评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,717评论 1 315
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,894评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,021评论 1 350
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,735评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,354评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,936评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,054评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,224评论 3 371
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,974评论 2 355

推荐阅读更多精彩内容