目录
大数据概述
Hadoop大数据开发平台
资源管理YARN
分布式文件系统HDFS
非关系型数据库NOSQL
分布式数据库HBASE
批处理和MapReduce
数据仓库查询分析和Hive
基于内存计算的Spark
流计算和Flink
图计算和PREGEL
Hadoop常用命令总结
大数据概述
大数据的4V:大量化、快速化、多样化、价值密度低。
大数据对思维方式的影响:颠覆了传统的思维方式——全样而非抽样、效率而非精确、相关而非因果
大数据对科学研究的影响:实验、理论、计算、数据
三次信息化浪潮
第一次——1980——个人计算机为标志——解决信息处理——Intel、AMD、IBM
第二次——1995——互联 ——信息传输——雅虎、谷歌
第三次——2010——物联 、云计算和大数据——信息爆炸——亚马逊、美团
信息科技为大数据提供的技术
- 存储设备容量增加、成本降低
- CPU性能提升
- 络带宽增加、终端数目增加
数据变革阶段
大数据发展三个阶段
萌芽期(第一):20世纪90年代至21世纪初——随着数据挖掘理论和数据库技术的逐步成熟,一批商业智能工具和知识管理技术开始被应用。如数据仓库、专家系统、知识管理系统等。
成熟期(第二):21世纪第一个十年——Web2.0应用迅速发展,非结构化数据大量产生,传统处理方法难以应对,带动了大数据技术的快速突破,大数据解决方案逐渐走向成熟,GFS和MapReduce等大数据技术受到追捧,Hadoop平台开始崭露头角。
大规模应用期(第三):2010年以后——大数据应用渗透各行各业,数据驱动决策,信息 会智能化程度大幅提高。
Hadoop大数据开发平台
谷歌2004年“三驾马车”处理海量数据问题:GFS分布式文件系统、MapReduce大数据分布式计算框架、NoSQL数据库系统BigTable
大数据两个核心技术:分布式存储、分布式处理
分布式存储
- 文件系统:HDFS
- NoSQL:HBase、MongoDB
- 消息系统:Kafka
分布式处理
- 批处理计算:MapReduce、Spark
- 流计算:Storm,Flink
- 图计算:Pregel
- 查询分析计算:Hive、Impala
Hadoop:是一个能够对大量数据进行分布式处理的软件框架,并且是以一种可靠、高效、可伸缩的方式进行处理的,
Hadoop特性:高扩展、高效性、高可靠、高容错、成本低。
Hadoop生态:
- Zookeeper:分布式协调服务
- Hbase:分布式数据库
- Ambari:安装部署工具
- Oozie:作业流调度系统
- MapReduce:离线计算
- Tez:DAG计算
- Spark:内存计算
- yean:资源调度管理
- HDFS:分布式存储系统
- Sqoop:数据库TEL工具
- Flume:日志收集
Hadoop三种安装模式
单机模式:一台机器上运行。(真正单机)
伪分布式模式:一台机器上模拟一个小集群,依赖SSH,需要初始化文件系统,本地的input文件夹和HDFS的input文件夹都在同一台机器上,并不需要通过 络传输数据。(单机装多机)
完全分布式模式:存储采用分布式文件系统HDFS,而且HDFS的名称结点和数据结点位于不同机器上。(真正多机)
伪分布式安装
- Hadoop进程可以分离的多个Java进程来运行
- 单结点,既作为NameNode也作为DataNode
- Hadoop配置文件位于/uhadoop/etc/hadoop/中,伪分布式需要修改配置文件core-site.xml和hdfs-site.xml
- Hadoop的配置文件是xml格式,每个配置以声明property的name和value来实现
伪分布式安装是在一个单机上模拟一个分布式的环境,启动Hadoop时,HDFS和yarn都将启动。其中HDFS包括Namenode、Datanode、SecondaryNamenode。Yarn包括Resourcemanager、Nodemanager。伪分布式具备Hadoop的主要功能。
伪分布式用途:常用于调试程序
Hadoop的版本
Hadoop2.0三大主要部分:HDFS、MapReduce、yarn。其中HDFS包括NN Federation和HA;MapReduce运行于Yean之上。
1.0到2.0版本差异:
资源管理YARN
yarn——2.0的资源调度框架
MapReduce1.0既是一个计算框架,也是一个资源管理调度框架。到了Hadoop2.0后,其资源调度功能被分离形成Yarn,而被剥离了资源调度功能的MapReduce1.0变为2.0,只拥有计算功能。
总结:Yarn是纯粹的资源调度框架,MR2.0是纯粹的计算框架。
yarn的调度策略
- 先进先出——队列
- 容器——多队列——资源使用量小、优先级高的先执行;最大化吞吐量和利用率
- 公平——多队列——公平调度算法,支持资源抢占,确保平均而言所有作业获得等量的资源
yarn的目标就是实现一个集群多个框架。即在一个集群上部署一个统一的资源调度框架yean,在yean之上可以部署其他各种计算框架。
yarn好处
- yarn为这些计算框架提供统一的资源调度管理服务,并且能够根据各种计算框架的负载需求,调整各自占用的资源,实现集群资源共享和资源弹性收缩。
- 其可以实现一个集群上的不同应用负载混搭,有效提高了集群的利用率
- 不同计算框架可以共享底层存储,避免了数据集跨集群移动
分布式文件系统HDFS
分布式文件系统
分布式文件系统指通过 络实现文件在多台主机上进行分布式存储的文件系统,一般采用“客户机/服务器”(CS)模式,客户端以特定的通信协议通过 络与服务器建立连接,提出文件访问请求,如GFS和HDFS。
注:分布式文件系统是大集合,HDFS是子集。
HDFS目标
- 兼容廉价的硬件设备
- 流数据读写
- 大数据集
- 简单的文件模型
- 强大的跨平台兼容性
HDFS局限性
- 不适合低延迟数据访问
- 无法高效存储大量小文件
- 不支持多用户写入及任意修改文件
HDFS存储的好处
- 加快数据传输速度
- 很容易检查数据错误
- 保证数据可靠性
HDFS构造
块(HDFS的核心概念):HDFS默认一个块64MB,一个文件被分成多个块,以块作为存储单位。
名称结点(NameNode):负责管理分布式文件系统的命名空间,用两个文件保存了两个核心的数据结构(FSImage和EditLog)。
数据结点(DataNode):负责数据的存储和读取,会根据客户端或者是名称结点的调度来进行数据的存储和检索,并且向名称结点定期发送自己所存储的块的列表
第二名称结点(SecondaryNamenode):用来保存名称结点对HDFS元数据信息的备份,并减少名称结点重启的时间。
注:一个机架上可以放一个名称节点、多个数据节点。
拓展: 块的默认大小是64MB,但是也可以128MB。HDFS中的块比一般普通文件系统的块大很多。之所以设计成一块一块是因为HDFS是面向大规模数据存储,且降低分布式节点的寻址开销。但是块不是越大越好,如果块过大会导致MapReduce才执行一两个任务,这样牺牲了其并行度,发挥不了分布式并行处理的效果。 名称节点也叫主节点。它是整个HDFS集群的管家,可以理解为是数据库中的数据目录。而数据节点才是存储真实数据即元数据。 FSImage用于保存系统文件树(如文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块等)。EditLog用于记录对数据进行的操作。 名称节点若出错则根据第二名称结点备份。 名称节点管家会定期检查数据节点是否坏掉,如坏掉则标志位宕机,然后将坏掉的数据节点中的数据迁移到另外一个数据节点上。这种做法有时也可以解决负载均衡问题。 总结:HDFS用块存文件内容,名称结点做管家只有通知功能不具备亲自上手功能,数据节点相当于工人真正在干活,管家中的FSImage用于存储信息在块的位置,EditLog记录操作,EditLog做记录肯定不断变大,第二名称结点则作为备份工人和垃圾回收工人,定期处理不断变大的EditLog。 |
HDFS如何减轻中心结点的负担/strong>
当客户端需要访问一个文件时,首先把文件名发送给名称结点,名称结点根据文件名找到对应的数据块(一个文件可能包括多个数据块),再根据每个数据块信息找到实际存储各个数据库的数据节点的位置,并把数据节点位置发送给客户端,最后客户端直接访问这些数据节点获取数据,在整个访问过程中,名称节点并不参与数据的传输。名称节点启动成功并进入正常运行状态以后,HDFS的更新操作都会被写入到EditLog,而不是直接写入FSImage。第二名称结点可以完成EditLog与FSImage的合并操作,减小EditLog文件大小,缩短名称结点重启时间。
HDFS对于冗余数据的保存
HDFS默认的冗余复制因子是3。其中,有两份副本放在同一个机架的不同机器上面,第三个副本放在不同机架的机器上面,这样既可以保证机架发送异常时的数据恢复,也可以提高数据读写性能。一般而言,如果是在集群内发起写操作请求,则把第一个副本放置在发起写操作请求的数据结点上,实现就近写数据。如果是来自集群外部的写操作请求,则从集群内部挑选一台磁盘不太慢,CPU不太忙的数据结点作为第一个副本的存放地。
非关系型数据库NOSQL
关系数据库和NoSQL(非关系数据库)的比较
关系数据库
- 优势:以完善的关系代数理论作为基础,有严格的标准,支持ACID四大特性,借助索引机制可以实现高效的查询,技术成熟,有专业公司的技术支持。
- 劣势:可扩展性差,无法较好支持海量数据存储,数据规模过于死板,无法较好支持Web2.0应用,事务机制影响了系统的整体性能等。
NoSQL数据库
- 优势:可以支持超大规模的数据存储,灵活的数据模型可以很好地支持Web2.0应用,具有强大的横向扩展能力等。
- 劣势:缺乏数据理论支持,复杂查询性能不高,大都不能实现事务强一致性,很难实现数据完整性,技术尚不成熟,缺乏专业团队的技术支持,维护较困难等。
两者各有优缺点,彼此无法替代。
关系数据库应用场景:电信银行等领域的关键业务系统,需要保证强事务一致性。
NOSQL数据库应用场景:互联 企业、传统企业的非关键业务。
采用混合架构
- 亚马逊公司使用不同类型的数据库来支撑它的电子商务应用。
- 对于购物篮这种临时性数据,采用键值存储会更加高效
- 当前的产品和订单信息则适合存储在关系数据库中
- 大量的历史订单信息则适合保存在类似MongoDB这类文档数据库中。
NoSQL四大类型
文档数据库:以文档为数据库的最小单位,对文档以某种标准化格式封装,每个文档可能具有完全不同的结构,具有基于文档内容的索引和查询能力。如mongoDB。
图数据库:使用图作为数据模型来存储数据,可以高效地存储不同顶点之间的关系,专门用于处理具有高度相互关联关系的数据,可以高效地处理实体之间的关系。如InfiniteGraph。
键值数据库:使用键定位值,值对数据库而言是透明不可见的,不能对值进行索引和查询,只能通过键进行查询。如Redis。
列族数据库:采用列族数据模型,数据库由多个行构成,每行数据包含多个列族,不同的行可以具有不同数量的列族,属于同一列族的数据会被存放在一起。如HBase。
拓展:MongoDB MongoDB简介 MongoDB是由C++语言编写的,是一个基于分布式文件存储的开源数据库系统,在高负载的情况下,添加更多的节点,可以保证服务器性能。MongoDB旨在为WEB应用提供可扩展的高性能数据存储解决方案。 MongoDB特点
|
NoSQL的三大基石
三大基石:CAP、BASE、最终一致性
CAP:CAP指的是Consistency一致性、Availability可用性、Partition Tolerance分区容错率。CA最简单的做法是把所有的事务放在同一台机器上,但这种做法会严重影响系统的可扩展性。CP当出现 络分区的情况时,受影响的服务需要等待数据一致,因此在等待期间就无法对外提供服务。AP允许系统返回不一致的数据。
BASE:并非表示“基础”。而是指Basically Available、Soft state、Eventual consistency。其中Basically Available表示基本可用(一个分布式系统的一部分发生问题变得不可用时,其他部分仍然可以使用,允许分区失败的情形出现)。Soft state表示软状态(和一致性相反,状态可以有一段时间不同步,具有一定的滞后性)。Eventual consistency表示最终一致性(后续的访问操作可能暂时读不到更新后的数据,但最终必须能读到)。
拓展:事务的ACID四大特性 Atomicity原子性:事务必须是不可再分的,要么全执行,要么不执行。 Consistency一致性(硬状态):所有的数据都应该在事务执行前后保持一致。 Isolation隔离性:事务之间互不影响 Durability持久性:事务完成之后对系统的影响是持久性的,即使发生故障。 |
最终一致性
根据更新数据后各进程访问到数据的时间和方式的不同,可以区分为以下几种:
- 因果一致性:如果进程A通知进程B它已经更新了一个数据项,那么进程B的后续访问将获得A写入的最新值。
- “读己之所写”一致性:当进程A自己执行一个更新操作后,它自己总是可以访问自己更新过的值,不会看到旧值。
- 单调读一致性:如果进程已经看到过数据对象的某个值,那么任何后续访问,都不会返回在那个值之前的旧值。
- 会话一致性:它会把访问存储系统的这些进程放到会话的上下文进程当中,这时只要这些会话存储,系统就可以保证读己之所写一致性。
- 单调写一致性:系统需要保证来自同一个进程的写操作按顺序执行。
分布式数据库HBASE
Hbase简介
HBase是一个高可靠、高性能(可以支持PB级别的数据)、面向列、可伸缩的分布式数据库,是谷歌BigTable的开源实现,主要用来存储非结构化和半结构化的松散数据。HBase的目标是处理非常庞大的表,可以通过水平扩展的方式,利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表,其运行在HDFS或Alluxio(读音:/a’la’so/)之上。
拓展:BigTable 其架构于GFS之上,使用MapReduce作为数据处理,使用Chubby作为协同管理服务。 而HBase架构于HDFS之上,使用Hadoop MapReduce作为数据处理,使用Zookeeper作为协同管理服务。 |
Hbase和传统关系数据库的对比分析
HBase的出现原因:虽然已经有了HDFS和MapReduce,但是Hadoop主要解决大规模数据离线批量数据,没法满足大数据实时处理。
关系数据库:多种数据类型,使用传统的关系数据模型,非常多的数据操作,支持多表连接,基于行存储,可以构建多个索引提高查询效率,更新操作会覆盖旧值,很难实现横线扩展和纵向扩展。
HBase:只有字符串类型,有多种操作,但是要避免多表连接(表中数据过多,若多表连接时间复杂度很高),基于列存储,只有行键索引,更新时生成新版本保留旧版本,可以轻易在集群中增加或者减少硬件数量来实现性能的压缩。
Hbase数据模型
表:Hbase采用表来组织数据,表由行和列组成,列划分为若干个列族。
行:每个Hbase表由若干行组成,每个行有一个行键。
列族:一个Hbase表被分组成许多列族的集合,它是基本的访问控制单元。
列限定符(列):列族里的数据通过列来定位。
单元格:在Hbase表中,通过行、列族和列限定符确定一个单元格,单元格存储的数据类型被视为字节数组byte[]。
时间戳:每个单元格都保存着同一份数据的多个版本,这些版本用时间戳进行索引。
总结:一言蔽之,行键确定行,列族确定大概方位,列确定具体列的位置,上面三者所确定的具体位置即为单元格,单元格可以多版本,确定版本可以用时间戳。
批处理和MapReduce
分布式并行编程
批处理计算:解决针对大规模数据的批量处理需求,MapReduce是最具有代表性和影响力的大数据批处理技术,用于大规模数据集的并行运算。
MR设计理念:计算向数据靠拢而非数据向计算靠拢(要完成一次数据分析时,选择一个计算节点,把运行数据分析的程序放到计算节点上运行,然后把它涉及的数据,全部从各个不同节点上面拉过来,传输到计算发生的地方)。
传统并行计算框架:使用共享内存并行计算模型,容错性差;使用刀片服务器、高速 、SAN、价格贵、扩展性差;编程难度高;适用于实时细粒度计算,属于计算密集型。
MR:使用非共享式并行计算模型,容错性好;普通PC机即可并行,扩展性好;编程简单;适用于非实时批处理计算,属于数据密集型。
扩展:MapReduce策略 其采用分而治之的策略,将非常大的数据集切分为非常多的独立的小分片,然后为每一个分片单独地启动一个map任务,最终通过多个map任务,并行地在多个机器上去处理。 |
Split
MR基本处理单位为Split。Split是为逻辑概念,只记录数据元信息,划分数据为多少个Split由用户自己决定。
扩展:MapReduce架构 MR采用Master/slave架构。MR中带有一个Master服务器和多个slave服务器,Master服务器带有一个作业跟踪器JobTracker,用于负责整个作业的调度和处理以及失败和恢复,而slave服务器带有负责具体任务执行的组件TaskTracker,TaskTracker主要负责接收JobTracker给它发的作业处理指令完成具体的任务处理。 如上,用户可以通过Client用户端提交用户编写的应用程序(也可以查看当前提交作业的运行状态),而后用户端提交作业给作业跟踪器,作业跟踪器指明作业的分配后,将作业交给TaskTracker去落实这个分配计划,而作业跟踪器则监督其是否落实。 |
Map和Reduce
MapReduce的任务被抽象为两个函数:Map和Reduce。其中Map的功能是将一个键值对输出分为一堆的键值对输出。至于要分为多少由用户决定,这是一个分片split的过程。而Reduce是一个汇总的过程,Map将一个任务分成多个子任务进行处理后,Reduce将结果进行简单求和。
如:输入<行 ,”a,b,c”>则map后输出<”a”,1><”b”,1><”c”,1>。
如:输入<”a”,<1,1,1>>则Reduce后输出<”a”,3>
任务的数量
Map任务的数量
Hadoop为每个split创建一个Map任务,split的多少决定了Map任务的数目。大多数情况下,理想的分片大小是一个HDFS块。
Reduce的数量
- 最优的Reduce任务个数取决于急群中可用的reduce任务槽(Slot)的数目
- 通常设置比reduce任务槽数目小一些的Reduce任务个数(这样可以预留一些系统资源处理可能发生的错误)
注:MapReduce过程中用户无法参与,也无法从一台机器中发送消息给另一台。
拓展:MapReduce的执行过程 从HDFS中读取数据-》加载到InputFormat中-》用户指定Split大小进行逻辑分割-》转换为RR数据集-》进行Map,此时变为<key,value>-》进行Shuffle-》进行Reduce,此时变为<key,value>-》通过outputFormat输出结果-》写入HDFS |
Shuffle过程
Shuffle就是指将Map后的数据进行分区、排序、合并、归并的过程,中文叫做洗牌。
从图中可以看出,Shuffle分为Map端的Shuffle和Reduce端的Shuffle。
MapShuffle
MapShuffle的过程是这样的:首先将数据转换为key-value的形式后切分为多个Map任务,一个map任务需要分配一定的缓存,一般默认100MB。一旦缓存过多,则启动溢写功能, 将缓存中的数据通过分区、排序、合并后,需要通过归并形成一个大的文件放在本地磁盘。
注:溢写功能并非缓存达到100MB后才启动,否则后续源源不断的数据无处可放。故一般设置溢写比例为0.8。分区时,一般采用哈希函数,分区的作用是适配多个Reduce任务。排序后可以合并,合并就是如<”a”,1>,<”a”,1>变为<”a”,2>的过程,这样一些重复的键值对可以合并为一个,大大减少溢写到磁盘的数据量。需要注意的是,合并不是必须的,也就是说,要视具体问题来看,合并不能改变最终结果。文件归并时,如果溢写的文件数量大于预定值(默认是3)则可以再次启动Combiner合并,少于3则不需要(因为合并也是一个耗时的过程)。
ReduceShuffle
JobTracker作为作业监视器,一直在监视作业的情况。一旦Map过程处理完成,则Reduce端会被其通知来取走属于自己需要处理的一份,取走后进行合并(combine)和归并(merge)。
注:一个Reduce端可能处理来自多个map端的数据,一个map端可能产生多个Reduce端处理的数据。合并和归并也是不一样的,合并时<”a”,1><”a”,1>-><”a”,2>,归并时<”a”,<1,1>>。
MapReduce阶段
- 只有当Map处理全部结束后,Reduce过程才能开始
- Map需要考虑数据局部性,Reduce无需考虑数据局部性
理解:WordCount的执行过程 WordCount简单来说就是词频统计,假设我们现在有三个字符串,那么通过map过程后,字符串就会被分割为多个键值对的形式。 这个时候Map输出后要经过Shuffle过程,Shuffle后就执行Reduce过程。 |
类序列化(JavaSE的知识补充)
当要在进程间传递对象或持久化对象的时候,就需要序列化对象成字节流,反之当要接收到或从磁盘读取的字节流转换为对象,就要进行反序列化。
Writable是Hadoop的序列化格式,Hadoop定义了这样一个Writable接口。一个类要支持可序列化只需实现这个接口即可。
数据仓库查询分析和Hive
Hive简介
- Hive是一个构建在Hadoop顶层的数据仓库工具
- 依赖分布式文件系统HDFS存储数据
- 依赖分布式并行计算模型MapReduce处理数据
- 借鉴SQL语言设计了新的查询语言HiveQL
- 用户可以通过编写的HiveQL语句运行MapReduce任务
- 支持类似SQL的接口,很容易进行移植
总结:Hive是一个可以提供有效合理直观组织和使用数据的分析工具。
Hive特性
采用批处理方式处理海量数据
Hive提供了一系列对数据进行提取、转换、加载ETL的工具
Hive与传统数据库的对比分析
Hive的用户体验在很多方面和传统的关系数据库相似,但是它底层依赖的是HDFS和MapReduce,所以在很多方面又有别于传统数据库。
Hive中SQL查询转换为MR作业的过程
输入SQL-》转换为抽象语法树-》转换为查询块-》转换为逻辑查询计划-》重写逻辑查询计划-》转为物理查询计划-》选择最优查询策略
基于内存计算的Spark
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!