人工智能教学：大数据基础知识总结.doc
《人工智能教学：大数据基础知识总结.doc》由会员分享，可在线阅读，更多相关《人工智能教学：大数据基础知识总结.doc（18页珍藏版）》请在冰点文库上搜索。
大数据基础知识总结
HDFS
特点和目标
硬件故障
硬件故障是常态，而不是异常。
整个HDFS系统将由数百或数千个存储着文件数据片断的服务器组成。
实际上它里面有非常巨大的组成部分，每一个组成部分都很可能出现故障，这就意味着HDFS里的总是有一些部件是失效的，因此，故障的检测和自动快速恢复是HDFS一个很核心的设计目标。
数据访问
运行在HDFS之上的应用程序必须流式地访问它们的数据集，它不是运行在普通文件系统之上的普通程序。
HDFS被设计成适合批量处理的，而不是用户交互式的。
重点是在数据吞吐量，而不是数据访问的反应时间，POSIX的很多硬性需求对于HDFS应用都是非必须的，去掉POSIX一小部分关键语义可以获得更好的数据吞吐率。
大数据集
运行在HDFS之上的程序有很大量的数据集。
典型的HDFS文件大小是GB到TB的级别。
所以，HDFS被调整成支持大文件。
它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的文件。
简单一致性模型
大部分的HDFS程序对文件操作需要的是一次写多次读取的操作模式。
一个文件一旦创建、写入、关闭之后就不需要修改了。
这个假定简单化了数据一致的问题和并使高吞吐量的数据访问变得可能。
一个Map-Reduce程序或者网络爬虫程序都可以完美地适合这个模型。
移动计算比移动数据更经济
在靠近计算数据所存储的位置来进行计算是最理想的状态，尤其是在数据集特别巨大的时候。
这样消除了网络的拥堵，提高了系统的整体吞吐量。
一个假定就是迁移计算到离数据更近的位置比将数据移动到程序运行更近的位置要更好。
HDFS提供了接口，来让程序将自己移动到离数据存储更近的位置。
异构软硬件平台间的可移植性
HDFS被设计成可以简便地实现平台间的迁移，这将推动需要大数据集的应用更广泛地采用HDFS作为平台。
名字节点和数据节点
HDFS是一个主从结构，一个HDFS集群是由一个名字节点，它是一个管理文件命名空间和调节客户端访问文件的主服务器，当然还有一些数据节点，通常是一个节点一个机器，它来管理对应节点的存储。
HDFS对外开放文件命名空间并允许用户数据以文件形式存储。
内部机制是将一个文件分割成一个或多个块，这些块被存储在一组数据节点中。
名字节点用来操作文件命名空间的文件或目录操作，如打开，关闭，重命名等等。
它同时确定块与数据节点的映射。
数据节点负责来自文件系统客户的读写请求。
数据节点同时还要执行块的创建，删除，和来自名字节点的块复制指令。
名字节点和数据节点都是运行在普通的机器之上的软件，机器典型的都是GNU/Linux，HDFS是用java编写的，任何支持java的机器都可以运行名字节点或数据节点，利用java语言的超轻便型，很容易将HDFS部署到大范围的机器上。
典型的部署是由一个专门的机器来运行名字节点软件，集群中的其他每台机器运行一个数据节点实例。
体系结构不排斥在一个机器上运行多个数据节点的实例，但是实际的部署不会有这种情况。
集群中只有一个名字节点极大地简单化了系统的体系结构。
名字节点是仲裁者和所有HDFS元数据的仓库，用户的实际数据不经过名字节点。
文件命名空间
HDFS支持传统的继承式的文件组织结构。
一个用户或一个程序可以创建目录，存储文件到很多目录之中。
文件系统的名字空间层次和其他的文件系统相似。
可以创建、移动文件，将文件从一个目录移动到另外一个，或重命名。
HDFS还没有实现用户的配额和访问控制。
HDFS还不支持硬链接和软链接。
然而，HDFS结构不排斥在将来实现这些功能。
名字节点维护文件系统的命名空间，任何文件命名空间的改变和或属性都被名字节点记录。
应用程序可以指定文件的副本数，文件的副本数被称作文件的复制因子，这些信息由命名空间来负责存储。
数据复制
HDFS设计成能可靠地在集群中大量机器之间存储大量的文件，它以块序列的形式存储文件。
文件中除了最后一个块，其他块都有相同的大小。
属于文件的块为了故障容错而被复制。
块的大小和复制数是以文件为单位进行配置的，应用可以在文件创建时或者之后修改复制因子。
HDFS中的文件是一次写的，并且任何时候都只有一个写操作。
名字节点负责处理所有的块复制相关的决策。
它周期性地接受集群中数据节点的心跳和块报告。
一个心跳的到达表示这个数据节点是正常的。
一个块报告包括该数据节点上所有块的列表。
副本位置：
第一小步
块副本存放位置的选择严重影响HDFS的可靠性和性能。
副本存放位置的优化是HDFS区分于其他分布式文件系统的的特征，这需要精心的调节和大量的经验。
机架敏感的副本存放策略是为了提高数据的可靠性，可用性和网络带宽的利用率。
副本存放策略的实现是这个方向上比较原始的方式。
短期的实现目标是要把这个策略放在生产环境下验证，了解更多它的行为，为以后测试研究更精致的策略打好基础。
HDFS运行在跨越大量机架的集群之上。
两个不同机架上的节点是通过交换机实现通信的，在大多数情况下，相同机架上机器间的网络带宽优于在不同机架上的机器。
在开始的时候，每一个数据节点自检它所属的机架id，然后在向名字节点注册的时候告知它的机架id。
HDFS提供接口以便很容易地挂载检测机架标示的模块。
一个简单但不是最优的方式就是将副本放置在不同的机架上，这就防止了机架故障时数据的丢失，并且在读数据的时候可以充分利用不同机架的带宽。
这个方式均匀地将复制分散在集群中，这就简单地实现了组建故障时的负载均衡。
然而这种方式增加了写的成本，因为写的时候需要跨越多个机架传输文件块。
默认的HDFSblock放置策略在最小化写开销和最大化数据可靠性、可用性以及总体读取带宽之间进行了一些折中。
一般情况下复制因子为3，HDFS的副本放置策略是将第一个副本放在本地节点，将第二个副本放到本地机架上的另外一个节点而将第三个副本放到不同机架上的节点。
这种方式减少了机架间的写流量，从而提高了写的性能。
机架故障的几率远小于节点故障。
这种方式并不影响数据可靠性和可用性的限制，并且它确实减少了读操作的网络聚合带宽，因为文件块仅存在两个不同的机架，而不是三个。
文件的副本不是均匀地分布在机架当中，1/3在同一个节点上，1/3副本在同一个机架上，另外1/3均匀地分布在其他机架上。
这种方式提高了写的性能，并且不影响数据的可靠性和读性能。
副本的选择
为了尽量减小全局的带宽消耗读延迟，HDFS尝试返回给一个读操作离它最近的副本。
假如在读节点的同一个机架上就有这个副本，就直接读这个，如果HDFS集群是跨越多个数据中心，那么本地数据中心的副本优先于远程的副本。
安全模式
在启动的时候，名字节点进入一个叫做安全模式的特殊状态。
安全模式中不允许发生文件块的复制。
名字节点接受来自数据节点的心跳和块报告。
一个块报告包含数据节点所拥有的数据块的列表。
每一个块有一个特定的最小复制数。
当名字节点检查这个块已经大于最小的复制数就被认为是安全地复制了，当达到配置的块安全复制比例时（加上额外的30秒），名字节点就退出安全模式。
它将检测数据块的列表，将小于特定复制数的块复制到其他的数据节点。
文件系统的元数据的持久化
HDFS的命名空间是由名字节点来存储的。
名字节点使用叫做EditLog的事务日志来持久记录每一个对文件系统元数据的改变，如在HDFS中创建一个新的文件，名字节点将会在EditLog中插入一条记录来记录这个改变。
类似地，改变文件的复制因子也会向EditLog中插入一条记录。
名字节点在本地文件系统中用一个文件来存储这个EditLog。
整个文件系统命名空间，包括文件块的映射表和文件系统的配置都存在一个叫FsImage的文件中，FsImage也存放在名字节点的本地文件系统中。
名字节点在内存中保留一个完整的文件系统命名空间和文件块的映射表的镜像。
这个元数据被设计成紧凑的，这样4GB内存的名字节点就足以处理非常大的文件数和目录。
名字节点启动时，它将从磁盘中读取FsImage和EditLog，将EditLog中的所有事务应用到FsImage的仿内存空间，然后将新的FsImage刷新到本地磁盘中，因为事务已经被处理并已经持久化的FsImage中，然后就可以截去旧的EditLog。
这个过程叫做检查点。
当前实现中，检查点仅在名字节点启动的时候发生，正在支持周期性的检查点。
数据节点将HDFS数据存储到本地的文件系统中。
数据节点并不知道HDFS文件的存在，它在本地文件系统中以单独的文件存储每一个HDFS文件的数据块。
数据节点不会将所有的数据块文件存放到同一个目录中，而是启发式的检测每一个目录的最优文件数，并在适当的时候创建子目录。
在本地同一个目录下创建所有的数据块文件不是最优的，因为本地文件系统可能不支持单个目录下巨额文件的高效操作。
当数据节点启动的时候，它将扫描它的本地文件系统，根据本地的文件产生一个所有HDFS数据块的列表并报告给名字节点，这个报告称作块报告。
通信协议
所有的通信协议都是在TCP/IP协议之上构建的。
一个客户端和指定TCP配置端口的名字节点建立连接之后，它和名字节点之间通信的协议是ClientProtocal。
数据节点和名字节点之间通过DatanodeProtocol通信。
RPC（RemoteProcedureCall）抽象地封装了ClientProtocol和DataNodeProtocol协议。
按照设计，名字节点不会主动发起一个RPC，它只是被动地对数据节点和客户端发起的RPC作出反馈。
异常处理编辑
鲁棒性
HDFS的主要目标就是在存在故障的情况下也能可靠地存储数据。
三个最常见的故障是名字节点故障，数据节点故障和网络断开。
重新复制
一个数据节点周期性发送一个心跳包到名字节点。
网络断开会造成一组数据节点子集和名字节点失去联系。
名字节点根据缺失的心跳信息判断故障情况。
名字节点将这些数据节点标记为死亡状态，不再将新的IO请求转发到这些数据节点上，这些数据节点上的数据将对HDFS不再可用，可能会导致一些块的复制因子降低到指定的值。
名字节点检查所有的需要复制的块，并开始复制他们到其他的数据节点上。
重新复制在有些情况下是不可或缺的，例如：
数据节点失效，副本损坏，数据节点磁盘损坏或者文件的复制因子增大。
数据正确性
从数据节点上取一个文件块有可能是坏块，坏块的出现可能是存储设备错误，网络错误或者软件的漏洞。
HDFS客户端实现了HDFS文件内容的校验。
当一个客户端创建一个HDFS文件时，它会为每一个文件块计算一个校验码并将校验码存储在同一个HDFS命名空间下一个单独的隐藏文件中。
当客户端访问这个文件时，它根据对应的校验文件来验证从数据节点接收到的数据。
如果校验失败，客户端可以选择从其他拥有该块副本的数据节点获取这个块。
元数据失效
FsImage和Editlog是HDFS的核心数据结构。
这些文件的损坏会导致整个集群的失效。
因此，名字节点可以配置成支持多个FsImage和EditLog的副本。
任何FsImage和EditLog的更新都会同步到每一份副本中。
同步更新多个EditLog副本会降低名字节点的命名空间事务交易速率。
但是这种降低是可以接受的，因为HDFS程序中产生大量的数据请求，而不是元数据请求。
名字节点重新启动时，选择最新一致的FsImage和EditLog。
名字节点对于一个HDFS集群是单点失效的。
假如名字节点失效，就需要人工的干预。
还不支持自动重启和到其它名字节点的切换。
特点
快照
快照支持在一个特定时间存储一个数据拷贝，快照可以将失效的集群回滚到之前一个正常的时间点上。
HDFS已经支持元数据快照。
数据组织
数据块
HDFS的设计是用于支持大文件的。
运行在HDFS上的程序也是用于处理大数据集的。
这些程序仅写一次数据，一次或多次读数据请求，并且这些读操作要求满足流式传输速度。
HDFS支持文件的一次写多次读操作。
HDFS中典型的块大小是64MB，一个HDFS文件可以被被切分成多个64MB大小的块，如果需要，每一个块可以分布在不同的数据节点上。
阶段状态
一个客户端创建一个文件的请求并不会立即转发到名字节点。
实际上，一开始HDFS客户端将文件数据缓存在本地的临时文件中。
应用程序的写操作被透明地重定向到这个临时本地文件。
当本地文件堆积到一个HDFS块大小的时候，客户端才会通知名字节点。
名字节点将文件名插入到文件系统层次中，然后为它分配一个数据块。
名字节点构造包括数据节点ID（可能是多个，副本数据块存放的节点也有）和目标数据块标识的报文，用它回复客户端的请求。
客户端收到后将本地的临时文件刷新到指定的数据节点数据块中。
当文件关闭时，本地临时文件中未上传的残留数据就会被转送到数据节点。
然后客户端就可以通知名字节点文件已经关闭。
此时，名字节点将文件的创建操作添加到到持久化存储中。
假如名字节点在文件关闭之前死掉，文件就丢掉了。
上述流程是在认真考虑了运行在HDFS上的目标程序之后被采用。
这些应用程序需要流式地写文件。
如果客户端对远程文件系统进行直接写入而没有任何本地的缓存，这就会对网速和网络吞吐量产生很大的影响。
这方面早有前车之鉴，早期的分布式文件系统如AFS，也用客户端缓冲来提高性能，POSIX接口的限制也被放宽以达到更高的数据上传速率。
流水式复制
当客户端写数据到HDFS文件中时，如上所述，数据首先被写入本地文件中，假设HDFS文件的复制因子是3，当本地文件堆积到一块大小的数据，客户端从名字节点获得一个数据节点的列表。
这个列表也包含存放数据块副本的数据节点。
当客户端刷新数据块到第一个数据节点。
第一个数据节点开始以4kb为单元接收数据，将每一小块都写到本地库中，同时将每一小块都传送到列表中的第二个数据节点。
同理，第二个数据节点将小块数据写入本地库中同时传给第三个数据节点，第三个数据节点直接写到本地库中。
一个数据节点在接前一个节点数据的同时，还可以将数据流水式传递给下一个节点，所以，数据是流水式地从一个数据节点传递到下一个。
可访问性
HDFS提供多种方式由应用程序访问，自然地，HDFS提供为程序提供javaapi，为c语言包装的javaapi也是可用的，还有一个HTTP浏览器可以浏览HDFS中的文件，通过WebDAV协议访问HDFS库的方式也正在构建中。
DFSShell
HDFS允许用户数据组织成文件和文件夹的方式，它提供一个叫DFSShell的接口，使用户可以和HDFS中的数据交互。
命令集的语法跟其他用户熟悉的shells（bash,csh）相似。
分布式文件系统
分布式文件系统（DistributedFileSystem）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。
分布式文件系统的设计基于客户机/服务器模式。
一个典型的网络可能包括多个供多用户访问的服务器。
另外，对等特性允许一些系统扮演客户机和服务器的双重角色。
例如，用户可以“发表”一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就像使用本地驱动器一样，下面是三个基本的分布式文件系统。
简介
计算机通过文件系统管理、存储数据，而信息爆炸时代中人们可以获取的数据成指数倍的增长，单纯通过增加硬盘个数来扩展计算机文件系统的存储容量的方式，在容量大小、容量增长速度、数据备份、数据安全等方面的表现都差强人意。
分布式文件系统可以有效解决数据的存储和管理难题：
将固定于某个地点的某个文件系统，扩展到任意多个地点/多个文件系统，众多的节点组成一个文件系统网络。
每个节点可以分布在不同的地点，通过网络进行节点间的通信和数据传输。
人们在使用分布式文件系统时，无需关心数据是存储在哪个节点上、或者是从哪个节点从获取的，只需要像使用本地文件系统一样管理和存储文件系统中的数据。
决定因素
文件系统最初设计时，仅仅是为局域网内的本地数据服务的。
而分布式文件系统将服务范围扩展到了整个网络。
不仅改变了数据的存储和管理方式，也拥有了本地文件系统所无法具备的数据备份、数据安全等优点。
判断一个分布式文件系统是否优秀，取决于以下三个因素：
l数据的存储方式，例如有1000万个数据文件，可以在一个节点存储全部数据文件，在其他N个节点上每个节点存储1000/N万个数据文件作为备份；或者平均分配到N个节点上存储，每个节点上存储1000/N万个数据文件。
无论采取何种存储方式，目的都是为了保证数据的存储安全和方便获取。
l数据的读取速率，包括响应用户读取数据文件的请求、定位数据文件所在的节点、读取实际硬盘中数据文件的时间、不同节点间的数据传输时间以及一部分处理器的处理时间等。
各种因素决定了分布式文件系统的用户体验。
即分布式文件系统中数据的读取速率不能与本地文件系统中数据的读取速率相差太大，否则在本地文件系统中打开一个文件需要2秒，而在分布式文件系统中各种因素的影响下用时超过10秒，就会严重影响用户的使用体验。
l数据的安全机制，由于数据分散在各个节点中，必须要采取冗余、备份、镜像等方式保证节点出现故障的情况下，能够进行数据的恢复，确保数据安全。
系统分类
网络文件系统
（NFS）最早由Sun微系统公司作为TCP/IP网上的文件共享系统开发。
Sun公司估计大约有超过310万个系统在运行NFS，大到大型计算机、小至PC机，其中至少有80%的系统是非Sun平台。
Andrew系统
（AFS）结构与NFS相似，由卡内基·梅隆大学信息技术中心（ITC）开发、现由前ITC职员组成的Transarc公司负责开发和销售。
AFS较NFS有所增强。
KASS系统
KASSFileSystem（简称KFS）是开始软件自主研发基于JAVA的纯分布式文件系统，功能类似于DFS、GFS、Hadoop，通过HTTPWEB为企业的各种信息系统提供底层文件存储及访问服务，搭建企业私有云存储服务平台。
DFS系统
（DFS）是AFS的一个版本，作为开放软件基金会（OSF）的分布
分布式文件系统
式计算环境（DCE）中的文件系统部分。
如果文件的访问仅限于一个用户，那么分布式文件系统就很容易实现。
可惜的是，在许多网络环境中这种限制是不现实的，必须采取并发控制来实现文件的多用户访问，表现为如下几个形式：
只读共享任何客户机只能访问文件，而不能修改它，这实现起来很简单。
受控写操作采用这种方法，可有多个用户打开一个文件，但只有一个用户进行写修改。
而该用户所作的修改并不一定出现在其它已打开此文件的用户的屏幕上。
并发写操作这种方法允许多个用户同时读写一个文件。
但这需要操作系统作大量的监控工作以防止文件重写，并保证用户能够看到最新信息。
这种方法即使实现得很好，许多环境中的处理要求和网络通信量也可能使它变得不可接受。
NFS和AFS的区别
NFS和AFS的区别在于对并发写操作的处理方法上。
当一个客户机向服务器请求一个文件（或数据库记录），文件被放在客户工作站的高速缓存中，若另一个用户也请求同一文件，则它也会被放入那个客户工作站的高速缓存中。
当两个客户都对文件进行修改时，从技术上而言就存在着该文件的三个版本（每个客户机一个，再加上服务器上的一个）。
有两种方法可以在这些版本之间保持同步：
无状态系统在这个系统中，服务器并不保存其客户机正在缓存的文件的信息。
因此，客户机必须协同服务器定期检查是否有其他客户改变了自己正在缓存的文件。
这种方法在大的环境中会产生额外的LAN通信开销，但对小型LAN来说，这是一种令人满意的方法。
NFS就是个无状态系统。
回呼（Callback）系统在这种方法中，服务器记录它的那些客户机的所作所为，并保留它们正在缓存的文件信息。
服务器在一个客户机改变了一个文件时使用一种叫回叫应答（callbackpromise）的技术通知其它客户机。
这种方法减少了大量网络通信。
AFS（及OSFDCE的DFS）就是回叫系统。
客户机改变文件时，持有这些文件拷贝的其它客户机就被回叫并通知这些改变。
无状态操作在运行性能上有其长处，但AFS通过保证不会被回叫应答充斥也达到了这一点。
方法是在一定时间后取消回叫。
客户机检查回叫应答中的时间期限以保证回叫应答是当前有效的。
回叫应答的另一个有趣的特征是向用户保证了文件的当前有效性。
换句话说，若一个被缓存的文件有一个回叫应答，则客户机就认为文件是当前有效的，除非服务器呼叫指出服务器上的该文件已改变了。
数据软件
YonghongZ-DataMart
YonghongDataMart是一款数据存储、数据处理的软件。
YonghongDataMart采用基于ZDFS的分布式列存储系统，就是将数据分散存储在多台独立的设备上。
传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。
分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。
YonghongDataMart的分布式文件存储系统（ZDFS）是在HadoopHDFS基础上进行的改造和扩展，将服务器集群内所有节点上存储的文件统一管理和存储。
这些节点包括唯一的一个NamingNode，在ZDFS内部提供元数据服务；许多MapNode，提供存储块。
存储在ZDFS中的文件被分成块，然后将这些块复制到多个计算机中（MapNode）。
这与传统的RAID架构大不相同。
块的大小和复制的块数量在创建文件时由客户机决定。
NamingNode监控存在服务器集群内所有节点上的文件操作，例如文件创建、删除、移动、重命名等等。
NetworkFileSystem
NFS介绍
NFS定义
（NFS）（NetworkFileSystem）是个分布式的客户机/服务器文件系统。
NFS的实质在于用户间计算机的共享。
用户可以联结到共享计算机并像访问本地硬盘一样访问共享计算机上的文件。
管理员可以建立远程系统上文件的访问，以至于用户感觉不到他们是在访问远程文件。
NFS是个到处可用和广泛实现的开放式系统。
NFS设计目标
允许用户象访问本地文件一样访问其他系统上的文件。
提供对无盘工作站的支持以降低网络开销。
简化应用程序对远程文件的访问使得不需要因访问这些文件而调用特殊的过程。
使用一次一个服务请求以使系统能从已崩溃的服务器或工作站上恢复。
采用安全措施保护文件免遭偷窃与破坏。
使NFS协议可移植和简单，以便它们能在许多不同计算机上实现，包括低档的PC机。
大型计算机、小型计算机和文件服务器运行NFS时，都为多个用户提供了一个文件存储区。
工作站只需要运行TCP/IP协议来访问这些系统和位于NFS存储区内的文件。
工作站上的NFS通常由TCP/IP软件支持。
对DOS用户，一个远程NFS文件存储区看起来是另一个磁盘驱动器盘符。
对Macintosh用户，远程NFS文件存储区就是一个图标。
NFS部分功能
服务器目录共享服务器广播或通知正在共享的目录，一个共享目录通常叫做出版或出口目录。
有关共享目录和谁可访问它们的信息放在一个文件中，由操作系统启动时读取。
客户机访问在共享目录上建立一种链接和访问文件的过程叫做装联（mounting），用户将网络用作一条通信链路来访问远程文件系统。
NFS的一个重要组成是虚拟文件系统（VFS），它是应用程序与低层文件系统间的接口。
VFS操作
close文件关闭操作
create文件生成操作
fsync将改变保存到文件中
getattr取文件属性
link用另一个名字访问一个文件
lookup读目录项
mkdir建立新目录
open文件打开操作
rdwr文件读写操作
remove删除一个文件
rename文件改名
rmdir删除一目录
setattr设置文件属性
AFS服务器
AndrewFileSys
升级会员 