大数据处理技术ppt讲课稿
大数据处理技术ppt讲课稿
科信办刘伟
第一节Mapreduce编程模型：
1.技术背景:
分布式并行计算是大数据（pb）处理的有效方法，编写正确高效的大规模并行分布式程序是计算机工程领域的难题：分布式并行计算是大数据（pb）处理的有效方法，编写正确高效的大规模并行分布式程序是计算机工程领域的难题。并行计算的模型、计算任务分发、计算机结果合并、计算节点的通讯、计算节点的负载均衡、计算机节点容错处理、节点文件的管理等方面都要考虑。
谷歌的关于mapreduce论文里这么形容他们遇到的难题：由于输入的数据量巨大，因此要想在可接受的时间内完成运算，只有将这些计算分布在成百上千的主机上。如何处理并行计算、如何分发数据、如何处理错误？所有这些问题综合在一起，需要大量的代码处理，因此也使得原本简单的运算变得难以处理，普通程序员无法进行大数据处理。
为了解决上述复杂的问题，谷歌设计一个新的抽象模型，使用这个抽象模型，普通程序员只要表述他们想要执行的简单运算即可，而不必关心并行计算、容错、数据分布、负载均衡等复杂的细节，这些问题都被封装了，交个了后台程序来处理。这个模型就是mapreduce。
谷歌2004年公布的mapreduce编程模型，在工业、学术界产生巨大影响，以至于谈大数据必谈mapreduce。
学术界和工业界就此开始了漫漫的追赶之路。这期间，工业界试图做的事情就是要实现一个能够媲美或者比Google mapreduce更好的系统，多年的努力下来，Hadoop（开源）脱颖而出，成为外界实现MapReduce计算模型事实上的标准，围绕着Hadoop，已经形成了一个庞大的生态系统
2. mapreduce的概念：
MapReduce是一个编程模型，一个处理和生成超大数据集的算法模型的相关实现。简单的一句话解释MapReduce就是“任务的分解与结果的汇总”。MapReduce从它名字上来看就大致可以看出个缘由，两个动词Map和Reduce，“Map（展开）”就是将一个任务分解成为多个任务，“Reduce”就是将分解后多任务处理的结果汇总起来，得出最后的分析结果。
mapreduce成功的最大因素是它简单的编程模型。程序员只要按照这个框架的要求，设计map和reduce函数，剩下的工作，如分布式存储、节点调度、负载均衡、节点通讯、容错处理和故障恢复都由mapreduce框架（比如hadoop）自动完成，设计的程序有很高的扩展性。所以，站在计算的两端来看，与我们通常熟悉的串行计算没有任何差别，所有的复杂性都在中间隐藏了。它让那些没有多少并行计算和分布式处理经验的开发人员也可以开发并行应用，开发人员只需要实现map 和reduce 两个接口函数，即可完成TB级数据的计算，这也就是MapReduce的价值所在，通过简化编程模型，降低了开发并行应用的入门门槛，并行计算就可以得到更广泛的应用。
3.mapreduce的编程模型原理
开发人员用两个函数表达这个计算：Map和Reduce，首先创建一个Map函数处理一个基于key/value pair的数据集合，输出中间的基于key/value pair的数据集合，然后再创建一个Reduce函数用来合并所有的具有相同中间key值的中间value值，就完成了大数据的处理，剩下的工作由计算机集群自动完成。
即：(input)
一共分为map（分解）shuffle（洗牌）reduce（归并）三个阶段。map阶段，每个节点调用程序员编写的map函数，作用于每一个在此节点存放的键值对，map函数的输出同样是一些键值对，中间结果进入shuffle阶段，shuffle系统自动完成，程序员无须也无法控制，shuffle阶段会把所有中间结果里的键相同的所有键-值对通过网络传递给同一个目标节点。在最后的reduce阶段，每个节点会对所有键相同的键值对调用程序员编写的reduce函数，输出最终结果。reduce函数也可以选择再次输出一些键值对，从而可以启动新一轮的mapreduce过程，如此往复。
示例1：WordCount
计算一个大的文档集合中每个单词出现的次数，下面是伪代码段：
map(String key, String value):
// key: document name
// value: document contents
for each word w in value:
EmitIntermediate(w, “1″);
reduce(String key, Iterator values):
// key: a word
// values: a list of counts
int result = 0;
for each v in values:
result += ParseInt(v);
Emit(AsString(result));
Map函数输出文档中的每个词、以及这个词的出现次数(在这个简单的例子里就是1)。Reduce函数把Map函数产生的每一个特定的词的计数累加起来。
4．mapreduce工作流程
红线中间部分是shuffle部分，计算机自动完成，但是我们必须理解shuffle做了什么，我们才能正确的理解map的结果和reduce的输入之间的关系。
Map阶段：数据经过分片化成M个数据集，每个数据集由一个maper节点经过map函数处理成key-value对形式的数据集。
Shuffle阶段：map输出的结果放在maper节点本地内存缓存区，缓存区先按照key进行分区（如果有R个reducer，hash（key） mod R分成R个分区，初步划分，分区是排序的，分区内对key排序（排序后可附加combiner合并操作，减少写磁盘数据量），缓冲区快要溢出时，溢写文件，多个溢写文件合并，合并过程再次排序（排序后可附加combiner合并操作），最后形成一个已经分区的、已经排序（对key的排序）的文件。
Reduce端会把属于本区的数据取（fetch）到内存，进行合并，合并过程再次排序，缓冲区快要溢出时，溢写文件，多个溢写文件合并，合并过程再次排序，合并为更大的排序文件，最终实现reduce输入数据是经过排序（对key的排序）的数据。
其实不管在map端还是reduce端，MapReduce都是反复地执行排序，合并操作，所以说：排序是mapreduce的灵魂。
Reduce阶段：最后一次合并的数据总是直接送到Reduce 函数那里，Reduce 函数会作用在排序输入的每一个key-list（value）上，最后的输出key-value对被直接写到
HDFS上（分布式文件系统）。有R个reduce任务，就会有R个最终结果，很多情况下这R个最终结果并不需要合并成一个最终结果，因为这R个最终结果可以作为另一个计算任务的输入，开始另一个并行计算任务。这就形成了上面图中多个输出数据片段（HDFS副本）。
5.mapreduce的局限
实验人员发现，一个mapreduce任务的瓶颈往往在中间的shuffle阶段，特别是系统中节点数量多，并发任务多的时候，原因在于：map和reduce阶段的各节点都是独立工作，有很高的并行性；shuffle阶段各节点需要交互，共享网络带宽。故而大数据算法的瓶颈在
于数据的移动。为此，在设计mapreduce算法的时候，需要尽可能减少中间结果，在map 和reduce阶段每个节点多做一些工作。
但是编程模型的简单，也大大限制了程序员的自由度，很多较复杂的任务难以完成，这是mapreduce的最大的弱点。此外，还存在如下问题：1启动开销大，简单任务也要尽力map-shuffle-redcuce三个阶段，无法实时响应，2只能处理静态数据，对于变化快的数据无能为力，3mapreduce的系统实现是谷歌的机密，据说2007年谷歌mapreduce版本比2012年hadoop快一个数量级。所以突破上述的的三个方面的限制，成为学术界和工业界研究热点，比如有人尝试把rmdb与mapreduce结合起来，解决编程模式简单的局限，谷歌自己有dremel系统可以用于大规模数据分析和查询的实事化，但技术细节没有公布。
Hadoop的mapreduce框架在2013年升级mapreduceV2，yarn。
第二节hdfs
经典漫画讲解HDFS原理
分布式文件系统比较出名的有HDFS 和 GFS，其中HDFS比较简单一点。
HDFS和GFS都是专门为对应的MapReduce框架设计的DFS，因此设计上的一些特点也是为了适应MapReduce计算环境的需要。
HDFS设计：
１）运行于商用硬件集群上：硬件错误是常态而不是异常。错误检测并快速自动恢复是HDF S的最核心设计目标。
２）流式数据访问。运行在HDFS上的应用主要是以流式读为主，做批量处理；更注重数据访问的高吞吐量。
３）超大规模数据集。HDFS的一般企业级的文件大小可能都在TB级别或者PB级别，支持大文件存储，而且提供整体上高的数据传输带宽，一个单一的HDFS实例应该能支撑数以千万计的文件，并且能在一个集群里扩展到数百个节点。
４）简单一致性模型。HDFS的应用程序一般对文件实行一次写、多次读的访问模式。
５）移动计算比移动数据更简单。对于大文件来说，移动数据比移动计算的代价要高。操作海量数据时效果越加明显，这样可以提高系统的吞吐量和减少网络的拥塞。６）异构软硬平台间的可移植性。这种特性便于HDFS作为大规模数据应用平台的推广。
1、三个部分: 客户端、nameserver（可理解为主控和文件索引,类似linux的inode）、datanode（存放实际数据）
HDFS集群有两类节点，并以管理者-工作者模式运行，即：一个namenode（管理者）和多个datanode（工作者）。
namenode管理文件系统的命名空间（管理元数据），他维护着文件系统树以及整棵树内所有的文件和目录，这些信息以两个文件形式永久保存在本地磁盘上：命名空间镜像文件fsima ge和编辑日志文件editlog。namenode也记录着每个文件中各个块所在的数据节点信息，但他并不永久保存块的位置信息，因为这些信息会在系统启动的时候由数据节点重新建立。
datanode是文件系统的工作节点（存储实际数据），他们根据需要存储并检索数据块，并定期向namenode发送他们所存储的块的列表。
客户端联系NameNode以获取文件的元数据，而真正的文件I/O操作是直接和DataNode进行交互的。
2、如何写数据过程
HDFS系统write操作
一个人对client说：请帮我写入200M数据好吗？
Client speak：我很荣幸，但你没有忘记什么嘛？
一个人说：a划分块大小128M（用于存放数据） b复制一个块到三个地方
Client speak：一个合格的client要知道2件事
（1）块大小：一个大文件存储在若干个块中，每个块通常64M or 128 M
（2）多路复用：一个块要保存到多个地方，通常为3
Client ask Namenode
第一步 client划分一个大文件的块大小，用于存储文件内容
第二步 client对Namenode说请帮助我分配一个128M的块（datanode上）并多路复用到3个地方
namenode分配datanode
第一步 Namenode需要找到3个datanode
第二步 Namenode整理一下3个datanode地址，发送给client
Client开始写数据
第一步 Client发送数据只到第一个datanode节点，当第一个datanode节点接收到数据的同时会同步到第二个datanode节点，第二个也会同步到第三个节点，以此类推直到最后一个节点为止
第二步一旦所有的数据都写入磁盘后，所有的datanode就向Namenode发送完成信号
第三步 Namenode就会显示块已保存，并且已经复用
第四步 Client会用同样的步骤完成后续数据写入
当写完所有块后
第一步当写完所有块后，Client就会关闭文件，并告之Namenode停止传输
第二步 Namenode此时就会知道所有的数据信息都保存在磁盘中（Meta 是数据块的元信息，保存在namenode的硬盘上。）
Recap重述
Client 用于划分保存文件的块
Namenode 用于提供保存块的datanode节点信息，包括所有的多路复用节点
Datanode 用于保存数据
HDFS的块（64m or 128m）比磁盘块大，其目的是为了最小化寻址开销。太大也不好，MapReduce 中的任务通常一次只处理一个block的数据，如果块过大，导致任务数太小，那作业就会分配不均，作业的运行速度就会比较慢。
那对HDFS文件分块有哪些好处呢？
1）一个文件的大小可以大于集群网络中任意一个机器中的磁盘的容量，因为将文件分块，不需要所有的块都分布在一个磁盘上，而是将其打散，尽量均匀的分布在每个机器的磁盘上。
2）使用块抽象而非整个文件作为存储单元，简化了存储子系统的设计。
3）块非常适合用于数据备份进而提供数据容错能力的可用性。将每个块复制到少数几个独立的机器上（dfs.replication 默认是3），可以确保在发生块、磁盘或机器故障后数据不丢失。如果一个块不可用，系统会从其他地方读取另外的副本，而这个过程对用户来说是透明的，用户也不需要了解这其中的策略。系统也会及时的将副本不足的块进行slave 之间进行复制，从而达到dfs.replication 设定的值。保证副本数恢复到正常的水平。应用程序可以为常用的文件块设置更多的副本数，分散集群的负载压力。
给出的三个datanode是按与客户端的距离排序的，最近的排前面。本地当然是最近的，相同机架的其次，其后是不同机架的，距离最远的是分属不同数据中心的server
3、读取数据过程
HDFS集群read操作
一个人对client说：请帮我读取相关文件
Client speak：Roger好的知道了！
交互Namenode
Client -> Namenode：请给我关于这个文件的信息（传输filename到Namenode）
Namenode –> Client：回复存储这个文件所有的块信息给Client，按datanode到Client 的距离进行排序，实际上就是知道块存储在哪个datanode上，先从最近的节点读取数据，（Nanenode向client返回每个数据块所在的datanodes 列表， client选择最近的服务器下载该数据块，block1……blockn）
例 Block1：at DN x1 y1 z1
Block2：at DN x2 y2 z2
Block3：at DN x3 y3 z3
Client：a.知道有多少个块（关于这个文件）需要下载
b.还知道每个块保存在哪些datanode上
因此Client会依次下载这些块到本地
数据下载流程
Client：先从最近的datanode节点下载数据，它要跟datanode作一个交互，申请获取相关块信息，datanode返回块数据
可能你会问到，如果datanode硬件损坏啦，没有相关数据啦，数据本身造破坏不能恢复啦，这些不幸的事情时我们有没有好的办法呢，呵呵木要担心下面我们就会讲到故障容错的理念
4、容错：节点故障，通讯故障，数据损坏。
三种典型故障
1）node failure节点故障（namenode服务器 datanode数据节点）节点硬件故障
2）communication failure通信故障
不能发送和接收数据，有可能datanode脱离了网络，找不到大家了
3）data corruption数据损坏，两种可能
当数据传输到网络中时损坏
当在磁盘存储时数据损坏
Namenode的单点故障：所有的文件访问都要通过NameNode来进行，所以NameNode至关重要。一旦NameNode发生毁坏，则整个系统都不可用。
每个datanode周期性发送心跳信息给namenode。网络中断可能会导致一批datanode 连不上namenode。namenode检测到一段时间没有上报心跳后（datanode活着，但有网络问题），NN把这个datanode标识为dead，不再分配新的io请求给它。在这个datanode上的
所有数据都不能访问了，这就会导致一些block的备份数量会少于指定的值。namenode会经常检查block备份数量，发起重新备份。
Secondary NameNode（次级副手nn）处理流程
(1) 、 namenode 响应 Secondary namenode 请求，将 edit log 推送给 Secondary namenode ，开始重新写一个新的 edit log 。
(2) 、 Secondary namenode 收到来自 namenode 的 fsimage 文件和 edit log 。
(3) 、 Secondary namenode 将 fsimage 加载到内存，应用 edit log ，并生成一个新的 fsimage 文件。
(4) 、 Secondary namenode 将新的 fsimage 推送给 Namenode 。
(5) 、 Namenode 用新的 fsimage 取代旧的 fsimage ，在 fstime 文件中记下检查点发生的时 HDFS通信协议
High A vailability f or t he H DFS N amenode：Active N N–NN t hat i s a ctively s erving the r ead a nd w r ite o perations f rom t he c lients. Standby(备份)N N–t his N N w aits a nd b ecomes a ctive when t he A ctive d ies o r i s u n healthy.
Hot,W arm,C old f ailover故障切换。A standby NN s tores a state that is a s ubset o f the runtime s tate of Active N N.
C o ld S tandby:S tandby N N h a s z ero s tate(e.g.i t i s s tarted a fter t he A ctive i s d eclared d ead. 是当Active NN已经挂掉后才起来的，它本身没有保存任何数据，这时候并不会减少恢复时间
Warm S tandby:S tandby h as p artial s tate:是在Active NN挂掉前起来的，其中保存了一部分数据，所以在恢复时只需要恢复没有的数据，减少了恢复时间。FsImage和EditLog是HDFS的核心数据结构。这些文件损坏会导致HDFS失效。namenode可以配置支持多份元数据拷贝。
it h as loaded fsImage a n d editLogs b ut has n ot received any block r eports
it h as l oaded fsImage a nd rolled l ogs and a ll b lock reports.
Hot S tandby:S tandby h as a l l m ost o f t he A ctive’s s tate and s tart i mmediately它里面保存的数据和Active是完成一样的，可以直接热切换到它上面继续服
检测网络故障
1）Client每当向datanode写数据时，datanode都会给一个确认ACK信号，表示接收无误2）Client没有收到ACK信号，就假设datanode或网络故障
检测数据损坏故障
1）Client给datanode传输信息时，信息包括2部分，checksum校验和、真实数据
2）Datanode即存储数据也存储校验和
由datanode定期发送块报告给namenode，这个块报告列出了所有的块信息。
注释：Datanode先检查checksum校验和是ok的，才发送块报告，因为块报告不包括坏块信息
举例：Datanode发送块报告时不包括坏块信息（假如发送4个块），Namenode在和原来“校验和”对比后认为原来应该有5个块，那么说明有一个块损坏了
重述心跳信息和块报告
1）Datanode每3秒钟向Namenode发送心跳信息，表示我还活着
2）datanode在发送块报告的时候会自动跳过坏块信息，只发送好块信息
3）namenode在接收到块报告后与原来的校验和进行对比，总块数-好块数=坏块数
5、容错第二部分：处理读写故障
1.处理写错误
1）事先声明：我们写入块的最小数据单位是包（通常64K），记住多路复用流水线
此外datanode要给client端发送接收到包的ACK确认信息，以便确认datanode完全接收到了数据包。
2）如果client端从一些datanode节点上不能获得ACK确认信息，就认为这些datanode 已不可用，因此client需要调整多路复用流水线，以跳过这个损坏的datanode节点，但不会影响其他的正常的datanode。
3）在调整多路复用之后，请注意到这个数据包仍将被“under replicated”（低于预设副本数复制），namenode稍后将会查看损坏的datanode
2.处理读错误
1）当client端询问一个块位置时，namenode将返回client端所有的datanode节点地址（三个副本所在节点的地址）。
2）如果client发现一个datanode不可用了，将会从其他的datanode处获取数据
6、容错第三部分：处理数据节点故障
1.首先，Namenode保存了2个重要的表
1）块信息表，包含块保存在哪些datanode节点上
2）节点信息表，包含datanode节点保存哪些块
2.再次，Namenode不间断更新这2个表
1）如果namenode在datanode上发现一个坏块，就会更新块信息表，在表里标识坏块在哪个datanode上
2）如果namenode发现datanode节点不可用了，就会更新2个表（块信息表，节点信息表），在2个表中同时标识不可用datanode节点信息
3.under复制
1）Namenode定期扫描第一张表（块表），看看哪些数据块，没有成功备份，这些块叫做“低于预设副本数的块”。
4.块同步
1）对于所有“低于预设副本数的块”，Namenode要求其他datanode从包含副本的datanode 中拷贝一个副本。
2）像这样，Namenode对某个Datanode说你能从那个datanode拷贝块吗？
这个Datanode对那个Datanode说我需要从你这里拷贝块，那个说OK没问题给你！
提出一个问题：
所有这些工作至少需要有一个有效的副本块，对吗？
答：正确的，hdfs不能保证最后的这个副本将永远生存。但它通过巧妙选择副本位置来尝试做到至少有一个可靠的副本,正如我们将看到下一个例子
7、备份策略
Namenode说，记得我答应告诉你，我是怎么为将要复制的块选择datanode位置的？看紧了，答案在这里……
1.机架与datanode关系
一个集群被划分到多个机架里，每个机架又包含多个datanode
2.第一个备份位置的选择
第一个备份位置简单，如果写入者的是集群的一个节点，这个节点就被选为第一个数据副本存放位置（自己先在本地备份），如果不是集群里的节点，则随机选择一个datanode节点存放第一个副本。读数据时，如果客户端本身就是DataNode,那么将从本地直接获取数据.
3.另外两个副本的位置
选择了第一个副本的位置后，在另一个不同的机架上选择2个不同datanode保存接下来2个副本
4.以后备份位置
随机选择datanode，但必须满足2个条件
(1)每个datanode里最多只有一个副本
(2)每个机架上最多选择连个datanode存放副本。
提问：有时候不能满足如上2个条件怎么办呢
如果你知道一个更好的算法，HDFS允许你使用你自己的副本存放算法，别畏缩……
当新增一个数据块（一个文件的数据被保存在一系列的块中）时，NameNode在选择DataNode 接收这个数据块之前，会考虑到很多因素。其中的一些考虑的是：
?将数据块的一个副本放在正在写这个数据块的节点上。减少网络io。
?尽量将数据块的不同副本分布在不同的机架上，这样集群可在完全失去某一机架的情况下还能存活。
?一个副本通常被放置在和写文件的节点同一机架的某个节点上，这样可以减少跨越机架的网络I/O。
?尽量均匀地将HDFS数据分布在集群的DataNode中。
因为数据块只存放在两个不同的机架上，所以此策略减少了读取数据时需要的网络传输总带宽。
在这种策略下，副本并不是均匀的分布在不同的机架上：三分之一的副本在一个节点上，三分之二的副本在一个机架上，其它副本均匀分布在剩下的机架中，这种策略在不损害数据可靠性和读取性能的情况下改进了写的性能。
8、结束语
组件简介
Namenode
我还可以做许多其他的事，同样做的很好，大家可以在互联网和书中找到关于namenode的信息
Client
我可以安装和运行HDF
Datanode
我做了除存储数据之外的很多工作，比如能运行mapreduce任务
第三节 hbase
为什么要用HBase ?
?出于同样的原因,我们需要Hadoop
——数据集成长为tb和pb级
——横向扩展（增加节点）比扩容便宜，通过添加节点即可适应数据的持续增长
但有时Hadoop是不够的
——需要支持随机读取和随机写入
传统数据库扩容很昂贵，而且数据很难分发（分布式计算）
HBase是什么??
分布式?列式数据库?多维?高可用性?高性能?存储系统
目标：十亿行*数百万列*成千上万的版本
Pb级数据分布在成千上万的服务器节点上
HBase不是…
不是传统的SQL数据库
——没有连接,没有查询引擎,没有类型,没有SQL
——有事务和二级索引，但这些是插件,而不是HBase的核心部分
?作为RDBMS的替代?
必须了解RDBMS 相反的模式
——非标准的数据
——表格很宽,数据分布稀疏
HBase是如何工作的呢?
两种类型的HBase节点: Master管理节点和RegionServer分区节点
?master（只有一个管理节点）
——管理集群的操作?任务调度、负载平衡、数据分裂
——它不负责读/写数据
——通过ZooKeeper and standbys（备用服务器）实现高度可用性
?RegionServer(一个或多个)
——存表格的节点：执行读取、缓冲写
——与客户端直接点对点进行读/写
HBase表
?一个HBase集群是由任意数量的用户定义的表组成
?表模式只定义列族
——每个列族包含任意数量的列
——每一列包含任意数量的版本
——列只在插入时才产生,空值不占用空间
——除了表名和列族名外，所有的数据都是字节存储
——表中的行已被排序，顺序存储
——列族里列也被排序，顺序存储
(表、行、列族、列,时间戳) 值
HBase表数据结构
?表行的映射与其列族是一个有序映射关系
——SortedMap(row list(ColumnFamilies))
?列族里的列名与版本值是一个有序映射关系
——SortedMap(column SortedMap(Versioned Values))
?列里时间戳与值是一个有序映射关系
------SortedMap(Timestamp Value)
HBase表是一个三维有序的映射表
SortedMap(RowKey，List(SortedMap(Column， List( SortedMap (Timestamp, Value)) ) )) – rowKey (ASC) + columnLabel(ASC) + Version (DESC) --> value
row=row0，column=anchor:bar，timestamp=1174184619081
row=row0，column=anchor:foo，timestamp=1174184620720
row=row0，column=anchor:foo，timestamp=1174184617161
row=row1，column=anchor:bar，timestamp=1174184619081
row=row1，column=anchor:foo，timestamp=1174184620721
row=row1，column=anchor:foo，timestamp=1174184617167
row=row2，column=anchor:bar，timestamp=1174184619081
row=row2，column=anchor:foo，timestamp=1174184620724
row=row2，column=anchor:foo，timestamp=1174184617167
row=row3，column=anchor:bar，timestamp=1174184619081