总结Hadoop集群技术近年来对大数据处理的推动
infoq & 02-23 09:47:47 & 作者：查礼
这篇文章主要介绍了总结Hadoop集群技术近年来对大数据处理的推动,随着数据量的日益庞大,越来越多的人开始对Hadoop的性能产生怀疑,那么忧郁是否要在网站中采用Hadoop的朋友可以阅读一下文中的经验总结,需要的朋友可以参考下
什么是大数据？麦肯锡公司的报告《大数据：创新、竞争和生产力的下一个前沿领域》中给出的大数据定义是：大数据指的是规模超过现有数据库工具获取、存储、管理和分析能力的数据集，并同时强调并不是超过某个特定数量级的数据集才是大数据。
国际数据公司（IDC）用四个维度的特征来定义大数据，即数据集的规模（Volume）、数据流动的速度（Velocity）、数据类型的多少（Variety）和数据价值的大小（Value）。
亚马逊的大数据科学家John Rauser的定义比较直接：&超过单台计算机处理能力的数据量则为大数据&。
最后我们来看看维基百科上的大数据定义：&Big data is the term for a collection of data sets so large and complex that it becomes difficult to process using on-hand database management tools or traditional data processing applications. &翻译成中文的意思是：大数据指的是数据规模庞大和复杂到难以通过现有的数据库管理工具或者传统的数据处理应用程序进行处理的数据集合。
上述大数据的概念中无一例外都突出了&大&字。从表面上看，数据规模的增长的确为处理数据带来了很大的问题。具体来说，在同样时间内获取与以前相同价值的数据变得不可为了。换言之，本质问题是数据的价值密度变低了，数据交换速率变慢了，所以催生了很多新型数据处理技术和工具，如Google的GFS和MapReduce，Apache Hadoop生态系统，美国伯克利大学AMPLab的Spark等；出现了对时间敏感程度不同的计算模式，如批式计算模式、交互式计算模式、流计算模式、实时计算模式等。计算模式的差异只是决定获取价值的技术不同，取决于上层业务需求的不同。实际上，所谓大数据问题的本质应是数据的资产化和服务化，而挖掘数据的内在价值是研究大数据的最终目标。
2. 大数据技术源起Google
Google在搜索引擎上所获得的巨大成功，很大程度上是由于采用了先进的大数据管理和处理技术，是针对搜索引擎所面临的日益膨胀的海量数据存储问题以及在此之上的海量数据处理问题而设计的。
Google提出了一整套基于分布式并行集群方式的基础架构技术，利用软件的能力来处理集群中经常发生的节点失效问题。Google使用的大数据平台主要包括五个相互独立又紧密结合在一起的系统：分布式资源管理系统Borg，Google文件系统（GFS），针对Google应用程序的特点提出的MapReduce 编程模式，分布式的锁机制Chubby以及大规模分布式数据库BigTable。
Borg是这五个系统中最为神秘的一个，直到2015年Google才在EuroSys 2015上发表了题为&Large-scale cluster management at Google with Borg&的论文。称Google内部不仅像计算型的应用，比如MapReduce、Pregel等运行在Borg上，存储类的应用，比如GFS，BigTable和Megastore等也运行在上面，真正做到了批处理作业和长周期服务的混合部署和资源动态调度。得益于此项技术，可以使平均资源利用率达到30%~75%以上，大大高于业界平均水平的6%~12%。
GFS是一个大型的分布式文件系统，它为Google云计算提供海量存储，并且与Chubby、MapReduce和BigTable等技术结合得十分紧密，处于系统的底层。它的设计受到Google特殊的应用负载和技术环境的影响。相对于传统的分布式文件系统，为了达到成本、可靠性和性能的最佳平衡，GFS从多个方面进行了简化。
MapReduce是处理海量数据的并行编程模式，用于大规模数据集的并行运算。MapReduce通过&Map（映射）&和&Reduce（化简）&这样两个简单的概念来参加运算。用户只需要提供自己的Map 函数以及Reduce 函数就可以在集群上进行大规模的分布式数据处理。这一编程环境能够使程序设计人员编写大规模的并行应用程序时不用考虑集群的可靠性、可扩展性等问题。应用程序编写人员只需要将精力放在应用程序本身，关于集群的处理问题则交由平台来完成。与传统的分布式程序设计相比，MapReduce封装了并行处理、容错处理、本地化计算、负载均衡等细节，具有简单而强大的接口。正是由于MapReduce具有函数式编程语言和矢量编程语言的共性，使得这种编程模式特别适合于非结构化和结构化的海量数据的搜索、挖掘、分析等应用。
Chubby是提供粗粒度锁服务的一个文件系统，它基于松耦合分布式文件系统，解决了分布式系统的一致性问题。这种锁只是一个建议性的锁而不是强制性的锁。通过使用Chubby的锁服务，用户可以确保数据操作过程中的一致性。GFS使用Chubby来选取一个GFS主服务器，BigTable使用Chubby指定一个主服务器并发现、控制与其相关的子表服务器。
大规模分布式数据库BigTable是基于GFS和Chubby开发的分布式存储系统。很多应用程序对于数据的组织是非常有规则的。一般来说，数据库对于处理格式化的数据还是非常方便的。但是由于关系数据库要求很强的一致性，很难将其扩展到很大的规模。为了处理Google内部大量的格式化以及半格式化数据，Google构建了弱一致性要求的大规模数据库系统BigTable。BigTablede在很多方面和数据库类似，但它并不是真正意义上的数据库。Google包括Web索引、卫星图像数据等在内的很多海量结构化和半结构化数据都是存储在BigTable中的。
3. Hadoop开启了大数据时代的大门
Google的技术虽好但不开源。如果没有Doug Cutting和他的Hadoop开源软件，我们就看不到如今大数据技术和应用的飞速发展。Doug Cutting主导的Apache Nutch项目是Hadoop软件的源头，该项目始于2002年，是Apache Lucene 的子项目之一。当时的系统架构尚无法扩展到存储并处理拥有数十亿网页的网络化数据。Google在2003年于SOSP上公开了描述其分布式文件系统的论文&The Google File System&，为Nutch提供了及时的帮助。2004年，Nutch的分布式文件系统(NDFS)开始开发。同年，Google在OSDI上发表了题为&MapReduce: Simplified Data Processing on Large Clusters&的论文，受到启发的Doug Cutting等人开始实现MapReduce计算框架并与NDFS（Nutch Distributed File System）结合起来，共同支持Nutch的主要算法。至2006年，它逐渐成为一套完整而独立的软件，已经到Yahoo!工作的Doug Cutting将这套大数据处理软件命名为Hadoop。2008年初，Hadoop成为Apache的顶级项目，除Yahoo!之外在众多互联网企业中得到应用。
早期的Hadoop，包括Hadoop v1以及更早之前的版本，主要由两个核心组件构成：HDFS和MapReduce，其中HDFS是Google GFS的开源版本，MapReduce计算框架实现了由Google工程师提出的MapReduce编程模型。还有一些围绕在Hadoop周围的开源项目，为完善大数据处理的全生命周期提供了必要的配套和补充。这些软件常用的有ZooKeeper、Hive、Pig、HBase、Storm、Kafka、Flume、Sqoop、Oozie、Mahout等。2012年5月，Hadoop v2的alpha版本发布，其中最重要的变化是在Hadoop核心组件中增加了YARN（Yet Another Resource Negotiator）。YARN的出现是为了把计算框架与资源管理彻底分离开，解决Hadoop v1由此带来的扩展性差、单点故障和不能同时支持多种计算框架的问题。YARN对标的恰好就是Google的Borg系统。至此，Hadoop方才能够与Google的大数据平台比肩。
一个好的、有生命力的开源生态系统要有一个核心，这个核心要是差异化和非平凡的，还要有广泛的应用和活跃的社区。Hadoop恰好具备这三个特征，以Hadoop为核心的大数据开源生态系统逐渐形成，Hadoop也成为自Linux以来最成功的开源软件，没有之一。受人民大学信息学院院长杜小勇老师的委托，我在CNCC 2015上组织了一个名为&大数据开源生态系统&的论坛。论坛邀请了来自互联网企业、硬件厂商、系统集成商以及学术界的同行分享在大数据开源方面的工作和体会。在最后的Panel环节，讨论了为什么要做开源和怎么做开源这两个问题。回答是比较分散的，有开源是唯一选择的，有拉通产业链的，有认为开源是新业态新商业模式的，有认为开源促进技术进步的。总之，在产业链不同的环节上的机构做开源的动机和目标自然是不同的，但只有这样，产业链中不同角色都能够在生态系统中找到自己的位置，这样的生态系统才是健壮的有生命力的，不是吗？
4. Hadoop的发展历史和应用之路
大数据领域第一个吃螃蟹的是互联网行业。这是因为大数据概念和技术都来源于互联网企业的老大哥Google的原因。以Hadoop投入实际应用来看：
从2006年到2008年是Hadoop的诞生阶段。只有国外少数几个互联网巨头在尝试，国内互联网行业在学习这项新技术。2006年，Yahoo!构建100节点规模的Hadoop机群用于Webmap业务。2007年，Yahoo!构建1000节点规模的Hadoop机群。2008年，Yahoo!的Hadoop机群扩展到2000节点规模，Facebook贡献Hive项目到开源社区。
从2008年到2010年是Hadoop的少年阶段。在互联网行业已经开始投入实际应用，应用集中在网页存储检索，日志处理和用户行为分析等方面。2009年，Yahoo!使用4000节点的机群运行Hadoop，支持广告系统和Web搜索的研究；Facebook使用600节点的机群运行 Hadoop，存储内部日志数据，支持其上的数据分析和机器学习；百度用Hadoop处理每周200TB的数据，进行搜索日志分析和网页数据挖掘工作。2010年，Facebook的Hadoop机群扩展到1000节点；百度用Hadoop每天可处理1PB的数据；中国移动通信研究院基于Hadoop开发了&大云&（BigCloud）系统，不但用于相关数据分析，还对外提供服务；淘宝的Hadoop系统达到千台规模，用于存储并处理电子商务的交易相关数据。
从2010年到2015年是Hadoop的青年阶段。在互联网行业无不将Hadoop作为大数据计算的标准配置，且应用形式趋于多样化；企业计算领域开始实践基于Hadoop的大数据应用；在追求大数据处理能力的同时，也开始思考系统适配性和效率问题。互联网行业出现了大量数据分析类应用，比如支付宝的交易数据离线分析系统等；用Hadoop与生态系统中的其他软件一起构成更为复杂的应用系统，比如腾讯的广点通精准广告投放系统，电信运营商的基于用户画像的精准营销系统等。除互联网行业外，出现了网络通讯大数据、金融大数据、交通旅游大数据、工业制造大数据、医疗健康大数据、社会治理大数据、教育大数据等，大数据理念和技术已经融入各行各业。Hadoop源于互联网行业，在应用于企业计算时，需要进行适配，原因在于互联网应用和企业计算应用在需求、服务、研发和运维体系方面有本质的不同。互联网应用业务逻辑简单、服务于海量用户、非固定使用人群、系统的用户体验至上、持续交付、能够快速响应的专业运维；而企业计算应用业务逻辑复杂、有限数量用户、固定使用人群、系统更强调稳定可靠、版本交付、层级式的技术支持。一时间市面上出现了很多面向企业用户的Hadoop发行版，以易部署、好配置，以及使用和管理方便为切入点，吸引着企业用户的眼球。
5.大数据技术的发展趋势
系统架构的专业化。从当今IT技术的发展角度看，提出系统结构上的解决方案是&应用驱动的大数据架构与技术&。也就是说根据具体类型应用的需求，在系统架构和关键技术上进行创新。为了降低成本并获得更好的能效，大数据应用系统越来越趋向扁平化、专用化的系统架构和数据处理技术，逐渐摆脱了传统的通用技术体系。比如并行数据库更鲜明的分化为面向事务处理的OLTP类数据库和面向分析的OLAP类数据库等。传统的应用服务器、数据库服务器和存储服务器这样的典型三层架构受到极大的冲击。应用开发人员更深入的理解计算机系统结构，&程序& = &算法& + &数据结构&将逐渐演变成&程序& = &算法& + &数据结构& + &系统结构&。
大数据生态系统范围扩大。克隆了Google的GFS和MapReduce的Apache Hadoop自2008年以来逐渐为互联网企业接纳，并成为大数据处理领域的事实标准。但2013年出现的Spark作为一匹黑马可以说终结了这一神话，大数据技术不再一家独大。由于应用不同导致Hadoop一套软件系统不可能满足所有需求，在全面兼容Hadoop的基础上，Spark通过更多的利用内存处理大幅提高系统性能。此外，Scribe、Flume、Kafka、Storm、Drill、Impala、TEZ/Stinger、Presto、Spark/Spark SQL等的出现并不是取代Hadoop，而是扩大了大数据技术生态环境，促使生态环境向良性和完整发展。今后在非易失存储层次、网络通信层次、易失存储层次和计算框架层次还会出现更多、更好和更专用化的软件系统。
系统整体效能更为用户重视。在全球互联网企业的努力下，Hadoop已经可以处理百PB级的数据，在不考虑时间维度的前提下，价值密度低的数据可以处理了。在解决了传统关系型数据库技术无法处理如此量级的数据之后，业界正在向系统能效要价值。能效问题一方面体现在系统性能上。互联网服务强调用户体验，原本做不到实时的应用在向实时化靠拢，比如前端系统及业务日志从产生到收集入库的延迟从1到2天时间进化到10秒以内。传统企业无法忍受关系数据库动辄几十分钟的查询分析性能，纷纷求助于性价比更好的技术和产品。这些需求使大数据交互式查询分析、流式计算、内存计算成为业界研发和应用的新方向。能效问题的另一方面体现在系统功耗和成本上。中科院计算所陈云霁研究员领导研究的专用神经网络处理器技术，可大幅加速机器学习负载，与通用芯片和GPU相比，计算速度提高几十倍，功耗只有十分之一，整体能效提高450倍。百度云存储万台定制ARM服务器可节电约25%，存储密度提升70%，每瓦特计算能力提升34倍（用GPU取代CPU计算），每GB存储成本降低50%。
个性化服务的需求愈发强烈。个性化对应于互联网服务的长尾部分，这部分需求在传统的系统设计中因为复杂性原因是被舍弃的，但正是这部分体现出个性化服务的需求。个性化服务，即系统能够提供满足不同个体需求的差异化服务，比如个性化推荐，广告精准投放等。就拿个性化推荐技术来说，目前已经开始从简单的商品推荐走向复杂的内容推荐。根据用户的特性与偏好，推荐内容的特征，以及当时的上下文数据（客户端设备类型、用户所处时空数据等），向特定用户提供个性化的内容推荐服务，内容包括商品（包括电商和零售）、广告、新闻和资讯等。在移动设备和移动互联网飞速发展的时代，个性化推荐将成为用户获取信息最直接的渠道之一。
价值挖掘的理论和技术亟待发展。对数据进行浅层分析的理论和技术，主要体现在分布式系统和关系型数据库理论的结合与再创新，目前已经有较大幅度进展。但是，从数据中抽取隐含的信息或者知识，也就是价值挖掘，这方面的理论和技术还比较缺乏。一是缺乏成熟的数据挖掘建模方法和工具，经验对于挖掘出有价值信息的影响甚大，原始数据与隐含信息之间存在技术缺失，所以&啤酒+尿布&的案例并不是天天都能产生的。二是机器学习和深度学习技术面临应用问题。与大数据相结合，已经在诸如语音识别、图像识别、广告推荐和风险控制等场景中得以初步应用，但这方面的技术和软件工具成熟度不高，还有很大提升空间。此外，机器学习和深度学习的应用场景还不够广泛，这既是机遇也是挑战。
Hadoop开源软件自2006年起至今已经走过十个年头，这对于任何软件来说生命周期不可谓不长。但是，Hadoop也在经历来自其他开源黑马的冲击。Spark在早期发展阶段通过全面兼容Hadoop而借力于后者成熟的生态系统。时至今日，Spark正在挑战Hadoop的权威，因为Spark已经将发展目标定位在取代Hadoop。Hadoop老矣，尚能饭否？ Hadoop的近100位Committer在积极的为Hadoop谋划未来，让我们拭目以待吧！我们已经步入数据化全覆盖的时代，社会生活、各行各业都在因数据而发生巨变。近年来，大数据已成为国家层面的基础性战略资源，正日益对全球生产、流通、分配、消费活动以及经济运行机制、社会生活方式和国家治理能力产生重要影响。推动大数据发展已成为国际社会的行动共识。
大家感兴趣的内容
12345678910
最近更新的内容测试环境：
192.168.217.130 master master.hadoop
192.168.217.131 node1 node1.hadoop
192.168.217.132 node2 node2.hadoop
一、设置master服务器时间
查看本地时间和时区
[root@master ~]# date
Mon Feb 27 09:54:09 CST 2017
[root@master ~]# tzselect
&[root@master ~]# cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
修改时间（date -s 00:00:00或者网络同步：apt- ntpdate cn.pool.ntp.org）
写入硬盘时间（hwclock -w）
二、在master服务器上检查时间服务是否安装
[root@node1 ~]# rpm -q ntp
ntp-4.2.4p8-2.el6.x86_64
如果没有安装，用yum安装
[root@node1 ~]#&yum install ntp
按上面的安装方式在内网每台服务器上都安装好NTP软件包。
完成后，都需要配置NTP服务为自启动
[root@master ~]# chkconfig ntpd on
[root@master ~]# chkconfig --list ntpd
ntpd & & & & & 0:off1:off2:on3:on4:on5:on6:off
三、在master上更改相关配置文件
[root@master ~]# vim /etc/ntp.conf&
进行如下修改：
第一处新增，意思是从IP地址192.168.217.1-192.168.217.254，默认网关255.255.255.0的服务器都可以使用我们的NTP服务器来同步时间
第二处新增，指明互联网和局域网中作为NTP服务器的IP
第三处是修改，将原有注释去掉，是当服务器与公用的时间服务器失去联系时以本地时间为客户端提供时间服务
配置文件修改完成，保存退出，启动服务。
[root@master ~]# &service ntpd start
启动后，一般需要5-10分钟左右的时候才能与外部时间服务器开始同步时间。可以通过命令查询NTPD服务情况。
查看服务连接和监听
[root@master ~]# netstat -tlunp | grep ntp &
udp & & & &0 & & &0 192.168.217.130:123 & & & & 0.0.0.0:* & & & & & & & & & & & & & & & 4990/ntpd & & & & &&
udp & & & &0 & & &0 127.0.0.1:123 & & & & & & & 0.0.0.0:* & & & & & & & & & & & & & & & 4990/ntpd & & & & &&
udp & & & &0 & & &0 0.0.0.0:123 & & & & & & & & 0.0.0.0:* & & & & & & & & & & & & & & & 4990/ntpd & & & & &&
udp & & & &0 & & &0 fe80::20c:29ff:fee7:123 & & :::* & & & & & & & & & & & & & & & & & &4990/ntpd & & & & &&
udp & & & &0 & & &0 ::1:123 & & & & & & & & & & :::* & & & & & & & & & & & & & & & & & &4990/ntpd & & & & &&
udp & & & &0 & & &0 :::123 & & & & & & & & & & &:::* & & & & & & & & & & & & & & & & & &4990/ntpd&
重新启动服务
[root@master ~]# service ntpd restart
可设置crontab每天和NTP服务器同步一次（以和互联网时间同步为例）
[root@master ~]# crontab -l
10 23 * * * root (/usr/sbin/ntpdate cn.pool.ntp.org && /sbin/hwclock -w) && /var/log/ntpdate.log
四、&将其他节点的时间与master进行同步
在其他每一个节点运行命令
[root@node1 ~]# ntpdate master
27 Feb 10:10:15 ntpdate[32724]: adjust time server 192.168.217.130 offset -0.170230 sec
[root@node2 ~]# ntpdate master
27 Feb 10:10:23 ntpdate[30874]: adjust time server 192.168.217.130 offset -0.149563 sec
这时候发现节点间的时间同步了，但ntpdate只在开机运行，我们若要设置为1小时同步一次
[root@node1 ~]# crontab -l
* */1 * * * /usr/sbin/ntpdate master
阅读(...) 评论()hadoop是干什么用的?_百度知道
hadoop是干什么用的?
学习hadoop要有什么 语言基础啊?java c 还是php啊
我有更好的答案
hadoop是什么？hadoop是一个平台，是一个适合大数据的分布式存储和计算的平台。什么是分布式存储？这就是后边我们要讲的hadoop核心之一HDFS；什么是分布式计算？这是我们后边要讲的hadoop另外一个重要的核心MapReduce。hadoop的优点一：低成本hadoop本身是运行在普通PC服务器组成的集群中进行大数据的分发及处理工作的，这些服务器集群是可以支持数千个节点的。hadoop优点二：高效性这也是hadoop的核心竞争优势所在，接受到客户的数据请求后，hadoop可以在数据所在的集群节点上并发处理。hadoop优点三：可靠性通过分布式存储，hadoop可以自动存储多份副本，当数据处理请求失败后，会自动重新部署计算任务。hadoop优点四：扩展性hadoop的分布式存储和分布式计算是在集群节点完成的，这也决定了hadoop可以扩展至更多的集群节点。hadoop安装方式|hadoop部署方式hadoop安装方式只有三种：本地安装；伪分布安装；集群安装。后期我们会专题进行讲解。
和 linux系统命令基础，得到最终结果。就是mapreduce 算法：将每个机器上的计算结果合并起来 再在一台机器上计算。hadoop是运行的系统要求是 linux，处理大数据的框架。只要思想是 分组合并 思想分组：比如 有一个大型数据，并且在奴隶主机上进行计算。合并。hadoop 用 java写的分布式 ，那么他就会将这个数据按照算法分成多份，每份存储在
奴隶主机上要有java语言基础
主要用来 存储数据?那和我现在用的网站mysql 还有 Oracle 有啥区别啊.不都是存数据么
区别很大，hadoop采用分布式存储。能够处理海量数据。
为您推荐：
其他类似问题
您可能关注的内容
hadoop的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。8,105被浏览753,366分享邀请回答slideshare.net/davidengfer/intro-to-the-hadoop-stack-javamug）用MapReduce统计一个文本文件中单词出现的频率的示例WordCount请参见：，如果对MapReduce不恨熟悉，通过该示例对MapReduce进行一些了解对理解下文有帮助。在MapReduce中，Shuffle是一个非常重要的过程，正是有了看不见的Shuffle过程，才可以使在MapReduce之上写数据处理的开发者完全感知不到分布式和并发的存在。（图片来源： Hadoop Definitive Guide By Tom White）广义的Shuffle是指图中在Map和Reuce之间的一系列过程。Hadoop的局限和不足但是，MapRecue存在以下局限，使用起来比较困难。抽象层次低，需要手工编写代码来完成，使用上难以上手。只提供两个操作，Map和Reduce，表达力欠缺。一个Job只有Map和Reduce两个阶段（Phase），复杂的计算需要大量的Job完成，Job之间的依赖关系是由开发者自己管理的。处理逻辑隐藏在代码细节中，没有整体逻辑中间结果也放在HDFS文件系统中ReduceTask需要等待所有MapTask都完成后才可以开始时延高，只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够对于迭代式数据处理性能比较差比如说，用MapReduce实现两个表的Join都是一个很有技巧性的过程，如下图所示：（图片来源：）因此，在Hadoop推出之后，出现了很多相关的技术对其中的局限进行改进，如Pig，Cascading，JAQL，OOzie，Tez，Spark等。Apache PigApache Pig也是Hadoop框架中的一部分，Pig提供类SQL语言（Pig Latin）通过MapReduce来处理大规模半结构化数据。而Pig Latin是更高级的过程语言，通过将MapReduce中的设计模式抽象为操作，如Filter，GroupBy，Join，OrderBy，由这些操作组成有向无环图（DAG）。例如如下程序：visits
= load ‘/data/visits’ as (user, url, time);
= group visits by url;
visitCounts
= foreach gVisits generate url, count(visits);
= load ‘/data/urlInfo’ as (url, category, pRank);
visitCounts
= join visitCounts by url, urlInfo by url;
gCategories = group visitCounts by category;
topUrls = foreach gCategories generate top(visitCounts,10);
store topUrls into ‘/data/topUrls’;
描述了数据处理的整个过程。而Pig Latin又是通过编译为MapReduce，在Hadoop集群上执行的。上述程序被编译成MapReduce时，会产生如下图所示的Map和Reduce：（图片来源：）Apache Pig解决了MapReduce存在的大量手写代码，语义隐藏，提供操作种类少的问题。类似的项目还有Cascading，JAQL等。Apache TezApache Tez，Tez是HortonWorks的Stinger Initiative的的一部分。作为执行引擎，Tez也提供了有向无环图（DAG），DAG由顶点（Vertex）和边（Edge）组成，Edge是对数据的移动的抽象，提供了One-To-One，BroadCast，和Scatter-Gather三种类型，只有Scatter-Gather才需要进行Shuffle。以如下SQL为例：SELECT a.state, COUNT(*),
AVERAGE(c.price)
JOIN b ON (a.id = b.id)
JOIN c ON (a.itemId = c.itemId)
GROUP BY a.state
（图片来源：）途中蓝色方块表示Map，绿色方块表示Reduce，云状表示写屏障（write barrier，一种内核机制，可以理解为持久的写），Tez的优化主要体现在：去除了连续两个作业之间的写屏障去除了每个工作流中多余的Map阶段（Stage）通过提供DAG语义和操作，提供了整体的逻辑，通过减少不必要的操作，Tez提升了数据处理的执行性能。Apache SparkApache Spark是一个新兴的大数据处理的引擎，主要特点是提供了一个集群的分布式内存抽象，以支持需要工作集的应用。这个抽象就是RDD（Resilient Distributed Dataset），RDD就是一个不可变的带分区的记录集合，RDD也是Spark中的编程模型。Spark提供了RDD上的两类操作，转换和动作。转换是用来定义一个新的RDD，包括map, flatMap, filter, union, sample, join, groupByKey, cogroup, ReduceByKey, cros, sortByKey, mapValues等，动作是返回一个结果，包括collect, reduce, count, save, lookupKey。Spark的API非常简单易用，Spark的WordCount的示例如下所示：val spark = new SparkContext(master, appName, [sparkHome], [jars])
val file = spark.textFile("hdfs://...")
val counts = file.flatMap(line =& line.split(" "))
.map(word =& (word, 1))
.reduceByKey(_ + _)
counts.saveAsTextFile("hdfs://...")
其中的file是根据HDFS上的文件创建的RDD，后面的flatMap，map，reduceByKe都创建出一个新的RDD，一个简短的程序就能够执行很多个转换和动作。在Spark中，所有RDD的转换都是是惰性求值的。RDD的转换操作会生成新的RDD，新的RDD的数据依赖于原来的RDD的数据，每个RDD又包含多个分区。那么一段程序实际上就构造了一个由相互依赖的多个RDD组成的有向无环图（DAG）。并通过在RDD上执行动作将这个有向无环图作为一个Job提交给Spark执行。例如，上面的WordCount程序就会生成如下的DAGscala& counts.toDebugString
res0: String =
MapPartitionsRDD[7] at reduceByKey at &console&:14 (1 partitions)
ShuffledRDD[6] at reduceByKey at &console&:14 (1 partitions)
MapPartitionsRDD[5] at reduceByKey at &console&:14 (1 partitions)
MappedRDD[4] at map at &console&:14 (1 partitions)
FlatMappedRDD[3] at flatMap at &console&:14 (1 partitions)
MappedRDD[1] at textFile at &console&:12 (1 partitions)
HadoopRDD[0] at textFile at &console&:12 (1 partitions)
Spark对于有向无环图Job进行调度，确定阶段（Stage），分区（Partition），流水线（Pipeline），任务（Task）和缓存（Cache），进行优化，并在Spark集群上运行Job。RDD之间的依赖分为宽依赖（依赖多个分区）和窄依赖（只依赖一个分区），在确定阶段时，需要根据宽依赖划分阶段。根据分区划分任务。（图片来源：）Spark支持故障恢复的方式也不同，提供两种方式，Linage，通过数据的血缘关系，再执行一遍前面的处理，Checkpoint，将数据集存储到持久存储中。Spark为迭代式数据处理提供更好的支持。每次迭代的数据可以保存在内存中，而不是写入文件。Spark的性能相比Hadoop有很大提升，2014年10月，Spark完成了一个Daytona Gray类别的Sort Benchmark测试，排序完全是在磁盘上进行的，与Hadoop之前的测试的对比结果如表格所示：（表格来源： ）从表格中可以看出排序100TB的数据（1万亿条数据），Spark只用了Hadoop所用1/10的计算资源，耗时只有Hadoop的1/3。Spark的优势不仅体现在性能提升上的，Spark框架为批处理（Spark Core），交互式（Spark SQL），流式（Spark Streaming），机器学习（MLlib），图计算（GraphX）提供一个统一的数据处理平台，这相对于使用Hadoop有很大优势。（图片来源：）按照Databricks的连城的说法是One Stack To Rule Them All特别是在有些情况下，你需要进行一些ETL工作，然后训练一个机器学习的模型，最后进行一些查询，如果是使用Spark，你可以在一段程序中将这三部分的逻辑完成形成一个大的有向无环图（DAG），而且Spark会对大的有向无环图进行整体优化。例如下面的程序：val points = sqlContext.sql(
“SELECT latitude, longitude FROM historic_tweets”)
val model = KMeans.train(points, 10)
sc.twitterStream(...)
.map(t =& (model.closestCenter(t.location), 1))
.reduceByWindow(“5s”, _ + _)
（示例来源：）这段程序的第一行是用Spark SQL 查寻出了一些点，第二行是用MLlib中的K-means算法使用这些点训练了一个模型，第三行是用Spark Streaming处理流中的消息，使用了训练好的模型。Lambda ArchitectureLambda Architecture是一个大数据处理平台的参考模型，如下图所示：（图片来源： ）其中包含3层，Batch Layer，Speed Layer和Serving Layer，由于Batch Layer和Speed Layer的数据处理逻辑是一致的，如果用Hadoop作为Batch Layer，而用Storm作为Speed Layer，你需要维护两份使用不同技术的代码。而Spark可以作为Lambda Architecture一体化的解决方案,大致如下：Batch Layer，HDFS+Spark Core，将实时的增量数据追加到HDFS中，使用Spark Core批量处理全量数据，生成全量数据的视图。，Speed Layer，Spark Streaming来处理实时的增量数据，以较低的时延生成实时数据的视图。Serving Layer，HDFS+Spark SQL（也许还有BlinkDB），存储Batch Layer和Speed Layer输出的视图，提供低时延的即席查询功能，将批量数据的视图与实时数据的视图合并。总结如果说，MapReduce是公认的分布式数据处理的低层次抽象，类似逻辑门电路中的与门，或门和非门，那么Spark的RDD就是分布式大数据处理的高层次抽象，类似逻辑电路中的编码器或译码器等。RDD就是一个分布式的数据集合（Collection），对这个集合的任何操作都可以像函数式编程中操作内存中的集合一样直观、简便，但集合操作的实现确是在后台分解成一系列Task发送到几十台上百台服务器组成的集群上完成的。最近新推出的大数据处理框架Apache Flink也使用数据集（Data Set）和其上的操作作为编程模型的。由RDD组成的有向无环图（DAG）的执行是调度程序将其生成物理计划并进行优化，然后在Spark集群上执行的。Spark还提供了一个类似于MapReduce的执行引擎，该引擎更多地使用内存，而不是磁盘，得到了更好的执行性能。那么Spark解决了Hadoop的哪些问题呢？抽象层次低，需要手工编写代码来完成，使用上难以上手。=&基于RDD的抽象，实数据处理逻辑的代码非常简短。。只提供两个操作，Map和Reduce，表达力欠缺。=&提供很多转换和动作，很多基本操作如Join，GroupBy已经在RDD转换和动作中实现。一个Job只有Map和Reduce两个阶段（Phase），复杂的计算需要大量的Job完成，Job之间的依赖关系是由开发者自己管理的。=&一个Job可以包含RDD的多个转换操作，在调度时可以生成多个阶段（Stage），而且如果多个map操作的RDD的分区不变，是可以放在同一个Task中进行。处理逻辑隐藏在代码细节中，没有整体逻辑=&在Scala中，通过匿名函数和高阶函数，RDD的转换支持流式API，可以提供处理逻辑的整体视图。代码不包含具体操作的实现细节，逻辑更清晰。中间结果也放在HDFS文件系统中=&中间结果放在内存中，内存放不下了会写入本地磁盘，而不是HDFS。ReduceTask需要等待所有MapTask都完成后才可以开始=& 分区相同的转换构成流水线放在一个Task中运行，分区不同的转换需要Shuffle，被划分到不同的Stage中，需要等待前面的Stage完成后才可以开始。时延高，只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够=&通过将流拆成小的batch提供Discretized Stream处理流数据。对于迭代式数据处理性能比较差=&通过在内存中缓存数据，提高迭代式计算的性能。因此，Hadoop MapReduce会被新一代的大数据处理平台替代是技术发展的趋势，而在新一代的大数据处理平台中，Spark目前得到了最广泛的认可和支持，从参加Spark Summit 2014的厂商的各种基于Spark平台进行的开发就可以看出一二。2.9K89 条评论分享收藏感谢收起slideshare.net/Hadoop_Summit/w-235phall1pandey这是Hadoop峰会上Tez的材料，第九页开始有描述Hive on Tez和传统MR Hive的区别，这些区别应该也适用于MR Hive和Spark SQL，也很清楚的体现了为何MR模型很笨重。相比Tez，Spark加入了更多内存Cache操作，但据了解它也是可以不Cache直接处理的，只是效率就会下降。再说Programming Interface，Tez的Interface更像MapReduce，但是允许你定义各种Edge来连接不同逻辑节点。Spark则利用了Functional Programming的理念，API十分简洁，相比MR和Tez简单到令人发指。我不清楚Spark如果要表现复杂的DAG会不会也变得很麻烦，但是至少wordcount的例子看起来是这样的，大家可以比较感受下：处理大规模数据而言，他们都需要更多proven cases。至少Hadoop MapReduce是被证明可行的。作为Data Pipeline引擎来说，MapReduce每个步骤都会存盘，而Spark和Tez可以直接网络发送到下一个步骤，速度上是相差很多的，但是存盘的好处是允许继续在失败的数据上继续跑，所以直观上说MapReduce作为pipeline引擎更稳健。但理论上来说，如果选择在每个完成的小步骤上加CheckPoint，那Tez和Spark完全能和现在的MapReduce达到一样的稳健。总结来说，即便现在不成熟，但是并没有什么阻碍他们代替现有的MapReduce Batch Process。对Tez而言，似乎商业上宣传不如Spark成功。Databricks头顶Berkley的光环，商业宣传又十分老道，阵营增长极快。光就系统设计理念，没有太大的优劣，但是商业上可能会拉开差距。Cloudera也加入了Spark阵营，以及很多其他大小公司，可以预见的是，Spark会成熟的很快，相比Tez。但Tez对于Hortonworks来说是赢取白富美的关键，相信为了幸福他们也必须努力打磨推广tez。所以就算现在各家试用会有种种问题，但是毕竟现在也就出现了2个看起来有戏的“次世代”平台，那慢慢试用，不断观望，逐步替换，会是大多数公司的策略。56320 条评论分享收藏感谢收起