Hadoop生态系统基本介绍PPT学习课件.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,#,Hadoop,发展历程及各组件介绍,1,第一章,课程简介,2,课程介绍,Hadoop,发展历程,Hadoop,各组件介绍,3,第二章,Hadoop,发展历程,4,Why Hadoop,？,Hadoop,简史,Hadoop,核心组件,Hadoop,生态系统,总结,Hadoop,解决的问题,5,我们处在一个海量数据的时代,我们正产生着比以往任何时候都多的数据,-,金融交易数据,-,网络数据,-,服务器日志,-,分析数据,-,电子邮件和短信,-,各类多媒体数据,6,我们处在一个海量数据的时代,我们产生数据的速度比以往任何时候都快,-,各类自动化数据,-,无处不在的互联网,-,用户自发生成的内容,例如,-,纽约证交所每天产生的交易数据多达,1TB,-Twitter,每天处理,3.4,亿条信息,-Facebook,每天有,27,亿条评论,7,淘宝双,11,当天的营业额？,8,淘宝双,11,全记录,9,数据就是价值,这些数据可用于许多有价值的应用,-,营销分析,-,产品推荐,-,需求预测,-,欺诈检测,-,更多、更多,我们必须处理它以提取其价值,10,数据处理的可扩展性受限,我们如何处理所有这些信息,有两个问题需要面对,-,大数据的存储,HDFS,-,大数据的分析,MapReduce,11,Why Hadoop,？,Hadoop,简史,Hadoop,版本,Hadoop,解决的问题,12,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,13,早期,Hadoop,Hadoop,后来从,Apache Nutch,被分离出来,-,第一次进入,Lucene,的一个子项目，称为,hadoop,-,后来成为顶级,Apache,项目,雅虎,!,领导早期的许多,Hadoop,开发,-,其他很多公司也接踵而至,2006 2008 2008,Hadoop sub-project,1000-node Yahoo!cluster,Top-level Apache project,14,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,个节点,15,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,个节点上）,16,Why Hadoop,？,Hadoop,简史,Hadoop,版本,Hadoop,解决的问题,17,Hadoop,版本,0.20 hadoop2.0 hadoop2.3,19,HDP,版本,Web UI,23,Hadoop,生态系统,24,HDFS,特性,高性能,容错,相对简单的集中管理,-,主从架构,优化了,MapReduce,处理,-,数据本地处理,可扩展性,25,经典,HDFS,架构,HDFS,的架构最近有所改进,-,更有弹性,-,更好的可扩展性,这些变化只是在最近的版本中可用,-,如,Cloudera,的,CDH4,-,目前版本,CDH5,许多人仍然运行在生产之前的版本,-,我们将首先讨论早期架构,-,然后我们将讨论它是如何改变的,26,传统的,HDFS,架构概述,在“经典”,HDFS,有三个守护进程,NameNode(,主节点,),Secondary NameNode(,主节点,),DataNode(,从节点,),NameNode,DataNode,DataNode,DataNode,DataNode,DataNode,DataNode,Secondary,NameNode,27,基于,QJM,的,HDFS HA,架构概述,在,HA,模式的,HDFS,有如下的守护进程,Active NameNode(,主,),standby NameNode(,主,),DataNode(,从,),JournalNode,（奇数个）,ZKFC,（主备）,28,写文件流程,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,29,读文件流程,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,30,Hadoop,生态系统,31,如何理解,mapreduce,过程？,Map,-Reduce在,Map,和,Reduce,之间是,shuffle,和,sort,阶段,-,从,Mapper,向,Reducer,发送数据,33,MapReduce,是什么？,(contd),数据处理的过程跟,Unix,的管道比较类似,cat/my/log|grep.html|sort|uniq c/my/outfile,Map,Shuffle and sort,Reduce,34,MapReduce v1,架构概述,35,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,36,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),37,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),38,MapReduce:,简单的例子,(contd),Output from the Reducer,written to HDFS:,(aardvark,1),(cat,1),(mat,1),(on,2),(sat,2),(sofa,1),(the,4),39,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,不能用，容易造成资源利用不足。,40,MRv2,系统架构,(contd),41,Hadoop,生态系统之,Hive,42,Hive,hive.apache.org/,建立在,Hadoop,基础上的数据仓库架构，它为数据仓库的管理提供了许多功能，包括：数据,ETL,（抽取、转换和加载）工具、数据存储管理和大型数据集的查询和分析能力,Hive,是MapReduce,的一个高度抽象实现,-最初由Facebook,的,一个团队创建-避免写,Java MapReduce,代码-在HDFS中的数据被非常类似于SQL的语言查询,-称为HiveQL,Hive,解释,器把,HiveQL,转,成MapReduce,任务,-表,对应,存储在HDFS,上的一个,目录,-,Hive Metastore,包含如何将文件映射到一个表结构的信息,43,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;,44,Hadoop,生态系统之,zookeeper,45,Zookeeper,简介,在分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。,Zookeeper,的目的就在于此。,46,Zookeeper,角色,47,Zookeeper,同步流程,选完,leader,以后，,zk,就进入状态同步过程。,1.leader,等待,server,连接；,2.Follower,连接,leader,，将最大的,zxid,发送给,leader,；,3.Leader,根据,follower,的,zxid,确定同步点；,4.,完成同步后通知,follower,已经成为,uptodate,状态；,5.Follower,收到,uptodate,消息后，又可以重新接受,client,的请求进行服务了。,48,Hadoop,生态系统之,Flume,49,Flume,人们很容易将现有文件添加到HDFS,-hadoop fs put logfile.txt/tmp,但是,如果,想要将数据创建在,HDFS,上,-例如,把,服务器,日志输出到,HDFS,我们,可以,用,Flume,实现,Flume,是一个分布式、可靠、和高可用的海量日志聚合的系统，支持在系统中定制各类数据发送方，用于收集数据；同时，,Flume,提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。,50,Flume,架构,51,Kafka,分布式消息系统,Kafka,是,Linkedin,于,2010,年,12,月份开源的消息系统，它主要用于处理活跃的流式数据。,活跃的流式数据在,web,网站应用中非常常见，这些数据包括网站的,pv,、用户访问了什么内容，搜索了什么内容等。这些数据通常以日志的形式记录下来，然后每隔一段时间进行一次统计处理。,Kafka,相对其他消息系统，像,activemq,、,rabbitmq,在性能方面有很大的优势。,52,Kafka,架构,53,Hadoop,生态系统之,Hbase,54,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作为对应。,55,HBase,的体系架构,HDFS,：每个文件由多个,Block,组成，分散在多个,DataNode,上,RegionServer,是,Hbase,集群的物理节点,RegionServer,包含多个,Region,，一个表由多个,Region,组成,Hmaster,负责,Region,在,RegionServer,间的,Balance,Zookeeper,集群存储索引表所在位置并负责主从节点的通信,每个,Region,包含多个,Store,，一个列族对应一个,Store,Store,中包含一个或多个,StoreFile,，写数据时首先写入,MemeStore,，后续,Flush,到,StoreFile,WriteAheadLog,，主要用于写恢复,56,Client,：,HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信，对于管理类操作，Client与HMaster进行RPC；对于数据读写类操作，Client与HRegionServer进行RPC,ZookeeperZookeeper 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 工作流程,57,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,根据负载情况随机均匀分布,58,Q&A,？,59,谢谢！,60,