施磊磊的双周汇报书面版2.docx
《施磊磊的双周汇报书面版2.docx》由会员分享，可在线阅读，更多相关《施磊磊的双周汇报书面版2.docx（17页珍藏版）》请在冰豆网上搜索。
施磊磊的双周汇报书面版2
双周汇报
云计算
这是3月份的一篇汇报的总结，现在拿出来继续深入理解一下，很多的知识点需要再次的理解。
其中提到清华大学陈康与郑纬民在《云计算：
系统实例与研究现状》一文中指出了云计算所包含的三个基本的特征：
第一个是云计算平台由大规模的廉价服务器所构成的集群所支撑，第二是应用程序与底层服务协作开发，最大限度地利用云计算平台各个节点的系统资源，第三个是通过使用廉价服务器进行数据资源的冗余存储，之后通过软件来保证云计算平台的高可用性。
Google云计算平台的实践表明用廉价服务器组成的超大规模集群，在可靠性、稳定性和计算能力上，均能达到大型计算机的标准。
即对于Google每天需要处理的海量数据和复杂计算，在保证系统延展性和良好运行效率的基础上，都可以通过架构在廉价集群之上的云计算平台得以实现。
Hadoop是Apache软件基金会旗下的一个开放源码的分布式计算编程工具和分布式文件系统，它主要包括两方面的内容：
HDFS分布式文件系统，MapReduce一分布式计算模型，它们是Google云计算平台中MapReduce计算模型与和Google文件系统GFS的一个开源实现。
在世界范围内，Hadoop在地震研究、自然语言处理研究、数据挖据等方面也有着广泛的用途，是当前学术界云计算研究的主要平台。
Hadoop云计算平台的关键技术，Hadoop是Apache软件基金会旗下的一个开放源码的分布式计算编程工具和分布式文件系统，它主要包括两方面的内容：
HDFS分布式文件系统，MapReduce一分布式计算模型，它们是Google的MapReduce计算模型与和Google文件系统GFS的开源实现，是当前云计算研究的主要开源平台。
在海量数据处理方面，Hadoop有着良好的性能。
HDFS分布式文件系统
HDFS是HadoopDistributedFileSystem的缩写，是Hadoop云计算平台对Google文件系统（GFS）的开源实现。
HDFS分布式文件系统属于一种覆盖性文件系统，设计针对的主要对象是：
适合流式访问的超大文件并且可以部署在廉价机器搭建而成的集群上。
HDFS一份数据默认在平台上存储三份，一份用于计算，另外两份作为冗余来保证数据的安全。
在HDFS分布式文件系统中，集群中的机器分为NameNode和DataNode两种类型，其中NameNode负责管理文件系统名字空间，所有文件和目录的MetaData都由在这个名字空间中，而DataNode则负责存储数据，其数据是按块（Block存储文件的。
HDFS中Block的大小默认是64MB，小于块大小的文件并不占据整个块的全部空间，而是将文件大小作为块的大小。
比如要存放的文件是1k，但是系统的Block默认是64MB,存放在HDFS之后，块的大小是1k，不是64MB。
文件若大于64MB，则分多个块进行存储。
使用Block有如下三方面的优势：
（1）可以存储大文件，一个文件的规模可以大于任何单块磁盘的容量，
（2）把存储单元抽象成块而不是文件，简化了存储子系统，简化了数据管理，
（3）能很好适应数据复制，数据复制保证系统的容错和可用性（如果组成文件的一个块损坏，只需要从备份的块中把这个损坏的块替换即可，而不需要恢复整个文件）。
HDFS文件读取流程如图2.1所示，其详细过程如下：
（1）客户端通过调用FileSystem对象的open（）方法打开需要读取的文件，对HDFS来说是调用DistributedFileSystem的open（）方法。
（2）DistributedFileSystem通过RPC调用NameNode确定文件的前几个Block的位置。
对于每一个Block，NameNode返回包含那个Block拷贝的DataNode地址；接下来，DataNode按照距离client的距离进行排序。
如果client本身就是一个DataNode，那么就从本地DataNode节点上读取数据。
DistributedFileSystem返回一个FSDataInputStream给客户端，让它从FSDataInputStream中读取数据。
FSDataInputStream接着包装一个DFSInputStream，用来管理DataNode和NameNode的I/O。
（3）client调用流的read（）方法。
（4）DFSInputStream开始的时候存放了前几个Blocks的DataNode的地址，这时候开始连接到最近DataNode上。
客户端反复调用read（）方法，以流式方式从DataNode读取数据。
（5）当读到Block的结尾的时候，DFSInputStream会关闭到当前DataNode的链接，然后查找下一个Block的最好的DataNode。
这些操作对客户端都是透明的，客户端感觉到的是连续的流。
（读取的时候就开始查找下一个块所在的地址）
（6）读取完成之后关闭FSDataInputStream
HDFS文件写入流程如图2.2所示，其详细过程如下：
（1）client通过调用DistributedFileSystem的create方法来请求创建文件
（2）DistributedFileSystem通过对NameNode发出RPC请求，在NameNode的namespace里面创建一个新的文件，但此时并不关联任何的块。
NameNode进行很多检查来保证不存在要创建的文件已经存在于文件系统中，还有检查否有相应的权限来创建文件。
如果这些检查都完成了，那么NameNode将记录下来这个新文件的信息，否则文件创建失败，并且客户端会收到一个IOExpection。
DistributedFileSystem返回一个FSDataOutputStream给客户端用来写入数据。
和读的情形类似，FSDataOutputStream将包装一个DFSOutputStream用于和DataNode及NameNode。
（3）客户端开始写数据；DFSDataOutputStream把要写入的数据分成包（packet），并将它们写入到中间队列（Dataqueue）中。
Dataqueue中的数据由DataStreamer来读取。
DataStreamer的职责是让NameNode分配新的块——通过找出合适的DataNodes来存储作为备份而复制的数据。
这些DataNodes组成流水线，我们假设这个流水线是个三级流水线，那么里面将含有三个节点。
DataStreamer将数据首先写入到流水线中的第一个节点；
（4）然后由第一个节点将数据包传送并写入到第二个节点，然后第二个将数据包传送并写入到第三个节点。
（5）在DFSOutputStream内部维护了一个关于packets的队列，其中存放着等待被DataNodes确认无误的packets的信息。
这个队列称为ACKqueue。
一个packet的信息被移出本队列当且仅当packet被流水线中的所有节点都确认无误。
（6）当完成数据写入之后客户端调用流的close方法，在通知NameNode完成写入之前，这个方法将对残留的packets执行flush操作，并等待确认信息（acknowledgement）。
（7）因为先前已经存在DataStream请求NameNode分配块这个操作，所以在这个阶段NameNode会持有构成文件的块的信息。
在block完成复制到最少的份数之后，NameNode将成功返回。
三、SequenceFile文件
对于一些应用，需要一些特殊的数据结构来存储数据。
为了便于进行MapReduce模式的处理，将每一个二进制对象单独存放在一个文件中是不妥的，因此Hadoop的开发者们为这些应用开发了一些顶层的容器，SequenceFile文件格式就是其中之一。
例如，对于每条记录使用一行纯文本记录的日志文件格式来说，如果想记录二进制类型的日志，使用这种格式明显不合适。
而Hadoop的SequenceFile格式却适用于这样的应用场景：
它提供了一种持久化的数据结构来记录键值对，把SequenceFile当成日志格式来用，首先需要挑选一个key，比如可以使用一个LongWritable类型来表示时间戳，然后可以使用一个Writable类型的对象来表示真正要记录的数据。
SequenceFile也可以作为一个非常不错的小文件的容器。
因为HDFS和MapReduce格式是对大文件优化的，而可以小把文件打包进SequenceFile，这样可以使存储、处理小文件更加有效。
（1）用户程序中的MapReduce函数库把输入数据划分成M块（通常每块的大小是16MB到64MB），并将他们分给不同的计算机，这样不同的块可以在不同的计算机上同时执行处理程序。
（2）在这些分布在不同计算机上的处理程序中有一个比较特别，这个程序我们称之为Master，其他程序按照不同任务分工我们称之为MapWorker、ReduceWorker。
Master选择空闲的Worker，并为它们分配Map或者Reduce任务。
（3）一个MapWorker读取并解析相关的输入块。
在解析出键值对之后，将他们传递给自定义的Map函数进行处理；Map函数将处理之后产生的中间数据（同样是键值对）缓存到内存中。
（4）这些被缓冲在内存的中间数据按照一定的策略被写入到本地磁盘。
这些数据可以根据某种特定的函数（通常是Hash（Key）mod（R））分布成R块。
R可以由用户指定。
这些中间结果在硬盘的位置信息将被发送回Master，由Master负责将之传递给ReduceWorker。
（5）ReduceWorker收到Master发送的中间数据位置信息之后，通过RPC从MapWorker的本地磁盘读取中间数据。
当ReduceWorker读到了所有中间数据，它就按照生成的中间数据的键的值进行排序，以此来保证具有相同键的数据划分在一起。
因为一个Reducer可能会接受许多个具有不同Key的键值对进行reduce操作，所以需要对这些数据按照Key进行排序。
（6）ReduceWorker将处理按照key进行排序之后的中间数据：
在处理时，所有具有相同key的数据都将被放置在同一个集合中并交给自定义的Reduce函数进行处理。
经过同一个节点的同一个Reduce函数处理之后的数据都将会被输出到同一个文件中。
（7）当所有的Map和Reduce任务都完成之后，Master节点将激活用户程序，并返回运算结果。
MapReduce执行结束之后将会产生与Reduce任务数目相当的输出文件，最终的结果也将存放在这些文件中。
通常，程序不会直接将这些文件进行合并，而是将它们作为另一个MapReduce程序的输入数据进行继续处理。
参考文献：
[1]张德丰.云计算实战[M].清华大学出版社.2012.7
[2]刘鹏.云计算[M].电子工业出版社.2011.5
分布式基础学习
随着云计算的发展，现在的应用也是越来越广泛，这学期也开设了分布式的课程只是讲的内容却是没有什么技术含量的，涉及到不实践的环节，只能自己去图书馆借点书籍研究一下。
从很多大公司的研发中就能发现以后很明显就是大数据的时代，XX的云存储，360的云杀毒等等这一系列的改革，面临各种各样的数据不断的刺激着我们的存储系统，促使我们的技术不断的发展，到底设计出怎么样的存储系统才能满足我们大数据的要求就成为很多的云计算研究者的难题，去年都是在研究搜索引擎一系列的知识点，差不多花了半年的时间能够入门，我是今年才接触到hadoop这一块内容的，在学hadoop之前必须把google的云计算平台熟悉一下，google的三大法宝本身的技术都是非常之高的，在GFS的基础之上hadoop的HDFS才会被研发出来，当然本身hadoop的环境搭建可能比较的复杂，在本机上进行过测试，三种模式中只能实现单机模式，还有的伪分布和集群模式比较的复杂也不是一台机子就能够实现的。
先暂时把理论部分好好理解透彻，还是有必要的。
说到云计算很火，云计算中的分布式计算也非常的流行。
传统的单道执行的任务还是没有分布式或是并发执行的快，在hadoop中有个HDFS根据google的GFS引申而来的，里面涉及到的mapreduce分布式计算模式是非常重要的模式，能够实现大批量数据的计算。
下面来进一步解释一下分布式，所谓分布式，在这里，很狭义的指代以Google的三大法宝，GFS、Map/Reduce、BigTable为框架核心的分布式存储和计算系统。
通常如我一样初学的人，会以Google这几份经典的论文作为开端的。
其他的论文都没有公布出来，很多的大公司他们的论文都是保密的，只是公布出一部分的相关的文件。
说实话也只能通过已经有的论文来学习。
它们勾勒出了分布式存储和计算的一个基本蓝图，但终究还是缺少一些实现的代码和示例。
幸好我们还有OpenSource，还有Hadoop。
Hadoop是一个基于Java实现的，开源的，分布式存储和计算的项目。
作为这个领域最富盛名的开源项目之一，它的使用者也是非常的多，尤其是近几年来数量在递增，包括了Yahoo，Amazon，Facebook等等。
Hadoop本身，实现的是分布式的文件系统HDFS，和分布式的计算（Map/Reduce）框架，此外，它还不是一个人在战斗，Hadoop包含一系列扩展项目，包括了分布式文件数据库HBase（对应Google的BigTable），分布式协同服务ZooKeeper（对应Google的Chubby）。
Google的论文与Hadoop的实现，顺着论文的框架看具体的实现，用实现来进一步理解论文的逻辑。
网上有很多前辈们，做过Hadoop相关的源码剖析工作，我关注最多的是这里，Map/Reduce的剖析正火热进行中，更新频率之高，剖析之详尽，都是难得一见的，所以，走过路过一定不要错过了。
此外，还有很多Hadoop的关注者和使用者贴过相关的文章。
也可以去Hadoop的中文站点，搜罗一些学习资料。
我个人从上述资料中也是受益匪浅。
分布式文件系统，在整个分布式系统体系中处于最低层最基础的地位，存储嘛，没了数据，再好的计算平台，再完善的数据库系统，都成了无水之舟了。
那么，什么是分布式文件系统，顾名思义，就是分布式+文件系统。
它包含这两个方面的内涵，从文件系统的客户使用的角度来看，它就是一个标准的文件系统，提供了一系列API，由此进行文件或目录的创建、移动、删除，以及对文件的读写等操作。
从内部实现来看，分布式的系统则不再和普通文件系统一样负责管理本地磁盘，它的文件内容和目录结构都不是存储在本地磁盘上，而是通过网络传输到远端系统上。
并且，同一个文件存储不只是在一台机器上，而是在一簇机器上分布式存储，协同提供服务，这就是所谓的分布式。
因此，考查一个分布式文件系统的实现，其实不妨可以从这两方面来分别剖析，而后合二为一。
首先，看它如何去实现文件系统所需的基本增删改查的功能。
然后，看它如何考虑分布式系统的特点，提供更好的容错性，负载平衡，等等之类的问题。
这二者合二为一，就明白了一个分布式文件系统，整体的实现模式。
说任何东西，都需要统一一下语言先，不然明明说的一个意思，却容易被理解到另一个地方去。
Hadoop的分布式文件系统HDFS，基本是按照Google论文中的GFS的架构来实现的。
但是，HDFS为了彰显其不走寻常路的本性，其中的大量术语，都与GFS截然不同。
文中，既不采用GFS的叫法，也不采用Hadoop的称谓，而是另辟蹊径，自立门户，搞一套自己的中文翻译。
文中所用翻译
HDFS中的术语
GFS中的术语
术语解释
主控服务器
NameNode
Master
整个文件系统的大脑，它提供整个文件系统的目录信息，并且管理各个数据服务器。
数据服务器
DataNode
ChunkServer
分布式文件系统中的每一个文件，都被切分成若干个数据块，每一个数据块都被存储在不同的服务器上，此服务器称之为数据服务器。
数据块
Block
Chunk
每个文件都会被切分成若干个块，每一块都有连续的一段文件内容，是存储的基本单位，在这里统一称做数据块。
数据包
Packet
无
客户端写文件的时候，不是一个字节一个字节写入文件系统的，而是累计到一定数量后，往文件系统中写入一次，每发送一次的数据，都称为一个数据包。
传输块
Chunk
无
在每一个数据包中，都会将数据切成更小的块，每一个块配上一个奇偶校验码，这样的块，就是传输块。
备份主控服务器
SecondaryNameNode
无
备用的主控服务器，在身后默默的拉取着主控服务器的日志，等待主控服务器牺牲后被扶正。
与单机的文件系统不同，分布式文件系统不是将这些数据放在一块磁盘上，由上层操作系统来管理。
而是存放在一个服务器集群上，由集群中的服务器，各尽其责，通力合作，提供整个文件系统的服务。
其中重要的服务器包括：
主控服务器（Master/NameNode），数据服务器（ChunkServer/DataNode），和客户服务器。
HDFS和GFS都是按照这个架构模式搭建的。
个人觉得，其中设计的最核心内容是：
文件的目录结构独立存储在一个主控服务器上，而具体文件数据，拆分成若干块，冗余的存放在不同的数据服务器上。
存储目录结构的主控服务器，在GFS中称为Master，在HDFS中称为NameNode。
这两个名字，叫得都有各自的理由，是瞎子摸象各表一面。
Master是相对于数据服务器来叫的，它作为数据服务器的领导同志存在，管理各个数据服务器，收集它们的信息，了解所有数据服务器的生存现状，然后给它们分配任务，指挥它们齐心协力为系统服务；而NameNode是针对客户端来叫的，对于客户端而言，主控服务器上放着所有的文件目录信息，要找一个文件，必须问问它，由此而的此名。
主控服务器在整个集群中，同时提供服务的只存在一个，如果它不幸牺牲的话，会有后备军立刻前赴后继的跟上，但，同一时刻，需要保持一山不容二虎的态势。
这种设计策略，避免了多台服务器间即时同步数据的代价，而同时，它也使得主控服务器很可能成为整个架构的瓶颈所在。
因此，尽量为主控服务器减负，不然它做太多的事情，就自然而然的晋升成了一个分布式文件系统的设计要求。
每一个文件的具体数据，被切分成若干个数据块，冗余的存放在数据服务器。
通常的配置，每一个数据块的大小为64M，在三个数据服务器上冗余存放（这个64M，不是随便得来的，而是经过反复实践得到的。
因为如果太大，容易造成热点的堆叠，大量的操作集中在一台数据服务器上，而如果太小的话，附加的控制信息传输成本，又太高了。
因此没有比较特定的业务需求，可以考虑维持此配置）。
数据服务器是典型的四肢发达头脑简单的苦力，其主要的工作模式就是定期向主控服务器汇报其状况，然后等待并处理命令，更快更安全的存放好数据。
此外，整个分布式文件系统还有一个重要角色是客户端。
它不和主控服务和数据服务一样，在一个独立的进程中提供服务，它只是以一个类库（包）的模式存在，为用户提供了文件读写、目录操作等API。
当用户需要使用分布式文件系统进行文件读写的时候，把客户端相关包给配置上，就可以通过它来享受分布式文件系统提供的服务了。
一个文件系统中，最重要的数据，其实就是整个文件系统的目录结构和具体每个文件的数据。
具体的文件数据被切分成数据块，存放在数据服务器上。
每一个文件数据块，在数据服务器上都表征为出双入队的一对文件（这是普通的Linux文件），一个是数据文件，一个是附加信息的元文件，在这里，不妨把这对文件简称为数据块文件。
数据块文件存放在数据目录下，它有一个名为current的根目录，然后里面有若干个数据块文件和从dir0-dir63的最多64个的子目录，子目录内部结构等同于current目录，依次类推。
个人觉得，这样的架构，有利于控制同一目录下文件的数量，加快检索速度。
这是磁盘上的物理结构，与之对应的，是内存中的数据结构，用以表征这样的磁盘结构，方便读写操作的进行。
Block类用于表示数据块，而FSDataset类是数据服务器管理文件块的数据结构，其中，FSDataset.FSDir对应着数据块文件和目录，FSDataset.FSVolume对应着一个数据目录，FSDataset.FSVolumeSet是FSVolume的集合，每一个FSDataset有一个FSVolumeSet。
多个数据目录，可以放在不同的磁盘上，这样有利于加快磁盘操作的速度。
此外，与FSVolume对应的，还有一个数据结构，就是DataStorage，它是Storage的子类，提供了升级、回滚等支持。
但与FSVolume不一样，它不需要了解数据块文件的具体内容，它只知道有这么一堆文件放这里，会有不同版本的升级需求，它会处理怎么把它们升级回滚之类的业务。
而FSVolume提供的接口，都基本上是和Block相关的。
相比数据服务器，主控服务器的数据量不大，但逻辑更为复杂。
主控服务器主要有三类数据：
文件系统的目录结构数据，各个文件的分块信息，数据块的位置信息（就数据块放置在哪些数据服务器上）。
在GFS和HDFS的架构中，只有文件的目录结构和分块信息才会被持久化到本地磁盘上，而数据块的位置信息则是通过动态汇总过来的，仅仅存活在内存数据结构中，机器挂了，就灰飞烟灭了。
每一个数据服务器启动后，都会向主控服务器发送注册消息，将其上数据块的状况都告知于主控服务器。
俗话说，简单就是美，保存的冗余信息越少，出现不一致的可能性越低，付出一点点时间的代价，换取了一大把逻辑上的简单性，绝对应该是一个包赚不赔的买卖，在HDFS中，FSNamespacesystem类就负责保管文件系统的目录结构以及每个文件的分块状况的，其中，前者是由FSDirectory类来负责，后者是各个INodeFile本身维护。
在INodeFile里面，有一个BlockInfo的数组，保存着与该文件相关的所有数据块信息，BlockInfo中包含了从数据块到数据服务器的映射，INodeFile只需要知道一个偏移量，就可以提供相关的数据块，和数据块存放的数据服务器信息。
在Hadoop的实现中，部署了一套RPC机制，以此来实现各服务间的通信协议。
在Hadoop中，每一对服务器间的通信协议，都定义成为一个接口。
服务端的类实现该接口，并且建立RPC服务，监听相关的接口，在独立的线程处理RPC请求。
客户端则可以实例化一个该接口的代理对象，调用该接口的相应方法，执行一次同步的通信，传入相应参数，接收相应的返回值。
基于此RPC的通信模式，是一个消息拉取的流程，RPC服务器等待RPC客户端的调用，而不会先发制人主动把相关信息推送到RPC客户端去。
其实RPC的模式和原理，实在是没啥好说的，之所以说，是因为可以通过把握好这个，彻底理顺Hadoop各服务器间的通信模式。
Hadoop会定义一系列的RPC接口，只需要看谁实现，谁调用，就可以知道谁和谁通信，都做些啥事情，图中服务器的基本架构、各服务所使用的协议、调用方向、以及协议中的基本内容。
基本的文件操作，可以分成两类，一个是对文件目录结构的操作，比如文件和目录的创建、删除、移动、更名等等；另一个是对文件数据流的操作，包括读取和写入文件数据。
当然，文件读和
升级会员 