Hadoop生态系统基本介绍.pptx

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,#,Hadoop,发展历程及各组件介绍,第一章,课程简介,课程介绍,Hadoop,发展历程,Hadoop,各组件介绍,第二章,Hadoop,发展历程,Why,Hadoop,？,Hadoop,简史,Hadoop,核心,组件,Hadoop,生态系统,总结,Hadoop,解决的问题,我们处在一个海量数据的时代,我们正产生着比以往任何时候都多的数据,-,金融交易数据,-,网络数据,-,服务器日志,-,分析数据,-,电子邮件和短信,-,各类多媒体数据,我们处在一个海量数据的时代,我们产生数据的速度比以往任何时候都快,-,各类自动化数据,-,无处不在的互联网,-,用户自发生成的内容,例如,-,纽约证交所每天产生的交易数据多达,1TB,-Twitter,每天处理,3.4,亿条信息,-Facebook,每天有,27,亿条评论,淘宝双,11,当天的营业额？,淘宝双,11,全记录,数据就是价值,这些数据可用于许多有价值的应用,-,营销分析,-,产品推荐,-,需求预测,-,欺诈检测,-,更多、更多,我们必须处理它以提取其价值,数据处理的可扩展性受限,我们如何处理所有这些信息,有两个问题需要面对,-,大数据的,存储,HDFS,-,大数据的,分析,MapReduce,Why,Hadoop,？,Hadoop,简史,Hadoop版本,Hadoop,解决的问题,Hadoop,的史前,Hadoop,最,开始用来提高,Apache Nutch,的可扩展性,-Nutch,是一个开源的,Web,搜索引擎项目,两篇谷歌论文对这项成果有重大影响,-The Google File System(,存储,),-Mapreduce(,处理,),2002 2003 2004 2005,Nutch created,Google Filesystem paper,MapReduce paper,Nutch re-architecture,早期,Hadoop,Hadoop,后来,从,Apache Nutch,被分离出来,-,第一次,进入,Lucene,的,一个子,项目，称为,hadoop,-,后来成为顶级,Apache,项目,雅虎,!,领导早期的,许多,Hadoop,开发,-,其他很多公司也接踵而至,2006,2008,2008,Hadoop sub-project,1000-node Yahoo!cluster,Top-level Apache project,Hadoop,大事记,2004,年,Doug Cutting MikeCafarella,实现了,HDFS,和,MapReduce,的初版,2005,年,12,月,Nutch,移植到新框架，,Hadoop,在,20,个节点上稳定运行,2006,年,1,月,Doug Cutting,加入雅虎,2006,年,2,月,Apache Hadoop,项目正式启动，支持,MapReduce,和,HDFS,独立发展,2006,年,2,月,雅虎的网格计算团队采用,Hadoop,2006,年,4,月,在,188,个节点上（每节点,10GB,）运行排序测试机需要,47.9,个小时,2006,年,5,月,雅虎建立了一个,300,个节点的,Hadoop,研究集群,2006,年,5,月,在,500,个节点上运行排序测试集需要,42,个小时（硬件配置比,4,月份更好）,2006,年,11,月,研究集群增加到,600,个节点,Hadoop,大事记,2006,年,12,月,排序测试记在,20个节点上运行,1.8,个小时，,100,个节点上运行,3.3,个小时，,500,个节点上运行,5.2,个小时，,900,个节点上运行,7.8,个小时,2007,年,1,月,研究集群增加到,900,个节点,2007,年,4,月,研究集群增加到两个集群,1000,个节点,2008,年,4,月,在,900,个节点上运行,1TB,的排序测试集仅需要,209,秒，成为全球最快,2008,年,10,月,研究集群每天状态,10TB,的数据,2009,年,3,月,17,个集群共,24000,个节点,2009,年,4,月,在每分钟排序中胜出，,59,秒内排序,500GB,（,1400,个节点上）和,173,分钟,内排序,100TB,的数据（在,3400,个节点上）,Why,Hadoop,？,Hadoop,简史,Hadoop,版本,Hadoop,解决的问题,Hadoop,版本,http,:/,0.20 hadoop2.0 hadoop2.3,HDP,版本,http,:/Web UI,Hadoop,生态系统,HDFS,特性,高性能,容错,相对简单的集中管理,-,主从架构,优化了,MapReduce,处理,-,数据本地处理,可扩展性,经典,HDFS,架构,HDFS,的架构最近有所改进,-,更有弹性,-,更好的可,扩展性,这些,变化只是在最近的版本中可用,-,如,Cloudera,的,CDH4,-,目前版本,CDH5,许多,人仍然运行在生产之前的版本,-,我们将首先讨论早期架构,-,然后我们将讨论它是如何改变的,传统的,HDFS,架构概述,在“经典”,HDFS,有三个守护进程,NameNode(,主节点,),Secondary NameNode(,主节点,),DataNode(,从节点,),NameNode,DataNode,DataNode,DataNode,DataNode,DataNode,DataNode,Secondary,NameNode,基于,QJM,的,HDFS HA,架构概述,在,HA,模式的,HDFS,有如下的守护,进程,Active NameNode,(,主,),standby,NameNode(,主,),DataNode(,从,),JournalNode,（奇数个）,ZKFC,（主备）,写文件流程,HDFS client,Distributed FileSystem,FSData OutputStream,NameNode,DataNode,DataNode,DataNode,1:create,2:create,3:write,7:complete,6:close,5,4,5:ack,packet,4:write packet,4,5,Client node,namenode,datanode,datanode,datanode,Client JVM,Pipeline of datanodes,读文件流程,HDFS client,Distributed FileSystem,FSData InputStream,NameNode,DataNode,DataNode,DataNode,1:open,2:get block location,3:read,6:close,4:read,5:read,datanode,datanode,datanode,namenode,client,Hadoop,生态系统,如何理解,mapreduce,过程？,http,:/Map,-Reduce,在,Map,和,Reduce,之间是,shuffle,和,sort,阶段,-,从,Mapper,向,Reducer,发送数据,MapReduce,是什么？,(contd),数据处理的过程跟,Unix,的管道比较类似,cat/my/log|grep.html|sort|uniq c/my/outfile,Map,Shuffle and sort,Reduce,MapReduce v1,架构,概述,MapReduce,：流程图,map,map,=Barrier=:Aggregates intermediate values by output key,reduce,reduce,reduce,Data store 1,Data store n,(Key,1,Values),(Key,2,Values),(Key,3,Values),(Key,1,Values),(Key,2,Values),(Key,3,Values),Key,1,Intermediate Values,Key,2,Intermediate Values,Key,3,Intermediate Values,Final key1 values,Final key2 values,Final key3 values,Input key value pairs,Input key value pairs,MapReduce:,简单的例子,(contd),Sample input to the Mapper:,the,cat sat on the mat,the,aardvark sat on the sofa,Intermediate data produced:,(,the,1,),(,cat,1,),(,sat,1,),(,on,1,),(,the,1),(,mat,1,),(,the,1,),(,aardvark,1,),(,sat,1),(,on,1,),(,the,1,),(,sofa,1),MapReduce:,简单的例子,(contd),Input to the Reducer,(,aardvark,1),(,cat,1),(,mat,1),(,on,1,1),(,sat,1,1),(,sofa,1),(,the,1,1,1,1),MapReduce:,简单的例子,(contd),Output from the,Reducer,written,to HDFS:,(,aardvark,1),(,cat,1),(,mat,1),(,on,2),(,sat,2),(,sofa,1),(,the,4),MapReduce,2 YARN,经典,MapReduce,架构的问题,JobTracker,是集群事务的集中处理点，存在单点故障,JobTracker,需要完成的任务太多，既要维护,job,的状态又要维护,job,的,task,的状态，造成过多的资源消耗,在,taskTracker,端，用,map/reduce task,作为资源的表示过于简单，没有考虑到,CPU,、内存等资源情况，当把两个需要消耗大内存的,task,调度到一起，很容易出现,OOM,把资源强制划分为,map/reduce slot,当只有,map task,时，,reduce slot,不能用；当只有,reduce task,时，,map slot,不能用，容易造成资源利用不足。,MRv2,系统架构,(contd),Hadoop,生态系统之,Hive,Hive,hive.apache.org,/,建立,在,Hadoop,基础上的数据仓库架构，它为数据仓库的管理提供了许多功能，包括：数据ETL,（抽取、转换和加载）工具、数据存储管理和大型数据集的查询和分析能力,Hive,是MapReduce,的一个高度抽象实现,-最初由Facebook,的,一个团队创建-避免写,Java MapReduce,代码-在HDFS中的数据被非常类似于SQL的语言查询,-称为HiveQL,Hive,解释,器把,HiveQL,转,成MapReduce,任务,-表,对应,存储在HDFS,上的一个,目录,-,Hive Metastore,包含如何将文件映射到一个表结构的信息,Hive(contd),Example Hive query:,SELECT,stock.product,SUM(orders.purchases),FROM stock INNER JOIN orders,ON(stock.id=orders.stock_id),WHERE orders.quarter=Q1,GROUP BY stock.product;,Hadoop,生态系统之,zookeeper,Zookeeper,简介,在,分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。,Zookeeper,的目的就在于此,。,Zookeeper,角色,Zookeeper,同步流程,选完,leader,以后，zk,就进入状态同步过程。,1.leader,等待,server,连接；,2.Follower,连接,leader,，将最大的,zxid,发送给,leader,；,3.Leader,根据,follower,的,zxid,确定同步点；,4.,完成同步后通知,follower,已经成为,uptodate,状态；,5.Follower,收到,uptodate,消息后，又可以重新接受,client,的请求进行服务了。,Hadoop,生态系统之,Flume,Flume,人们,很容易将现有文件添加到HDFS,-hadoop fs put logfile.txt/tmp,但是,如果,想要将数据创建在,HDFS,上,-,例如,把,服务器,日志输出到,HDFS,我们,可以,用,Flume,实现,Flume,是一个分布式、可靠、和高可用的海量日志聚合的系统，支持在系统中定制各类数据发送方，用于收集数据；同时，,Flume,提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。,Flume,架构,Kafka,分布式,消息系统,Kafka,是,Linkedin,于,2010,年,12,月份开源的消息系统，它主要用于处理活跃的流式数据,。,活跃,的流式数据在,web,网站应用中非常常见，这些数据包括网站的,pv,、用户访问了什么内容，搜索了什么内容等。这些数据通常以日志的形式记录下来，然后每隔一段时间进行一次统计处理。,Kafka,相对其他消息系统，像,activemq,、,rabbitmq,在性能方面有很大的优势。,Kafka,架构,Hadoop,生态系统之,Hbase,HBase 简介,HBASE-Hadoop Database 是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可以在廉价PC Server上搭建起大规模结构化存储集群。,HBase 是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable利用 Chubby作为协同服务，HBase利用Zookeeper作为对应。,HBase,的体系架构,HDFS,：每个文件由多个,Block,组成，分散在多个,DataNode,上,RegionServer,是,Hbase,集群的物理节点,RegionServer,包含多个,Region,，一个表由多个,Region,组成,Hmaster,负责,Region,在,RegionServer,间的,Balance,Zookeeper,集群存储索引表所在位置并负责主从节点的通信,每个,Region,包含多个,Store,，一个列族对应一个,Store,Store,中包含一个或多个,StoreFile,，写数据时首先写入,MemeStore,，后续,Flush,到,StoreFile,WriteAheadLog,，主要用于写恢复,Client,：,HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信，对于管理类操作，Client与HMaster进行RPC；对于数据读写类操作，Client与HRegionServer进行RPC,Zookeeper,Zookeeper Quorum中除了存储了-ROOT-表的地址和HMaster的地址，HRegionServer也会把自己以Ephemeral方式注册到Zookeeper中，使得HMaster可以随时感知到各个HRegionServer的健康状态。此外，Zookeeper也避免了HMaster的单点问题，见下文描述,H,m,aster,：,HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行，HMaster在功能上主要负责Table和Region的管理工作：,1.,管理用户对Table的增、删、改、查操作,2.管理HRegionServer的负载均衡，调整Region分布,3.在Region Split后，负责新Region的分配,4.在HRegionServer停机后，负责失效HRegionServer 上的Regions迁移,HBase 工作流程,Hbase,的存储结构,RowKey,时间戳,列族,1,列族,2,列,A,列,B,列,C,13910000001,T1,201212,1,aaa,13910000002,T1,201212,2,bbb,13910000003,T2,201212,2,ccc,13910000004,T1,201212,4,ddd,13910000005,T1,201212,34,bba,13910000006,T2,201212,54,aa,13910000007,T3,201212,34,cs,13910000008,T1,201212,21,ddf,13910000009,T3,201212,1,sdsx,Region1,Region2,Region3,RegionServer1,RegionServer2,根据负载情况随机均匀分布,Q&A,？,谢谢！,