正式运维女的成长历程——hadoop学习

      经过两个多月的实习，在拿到毕业证书的第二天，就找到公司要求转正。幸运的是公司是个很通情达理的公司，所以看到我资料齐全又实习了很久，就很快帮我办了正式的入职手续。所以现在就从实习运维女变成了一名正式的运维女。

      公司同事中有很多大牛，有问题可以找各种途径解决，也有很好的学习氛围，再加上作为一名IT企业中少见的女性，还是有一定的优势的。所以我感觉自己的进步还是比较快，从最先开始对linux和服务器完全的门外汉，经过两个多月的学习，渐渐的也都有点上手的感觉了。遇到问题也不会慌了，慢慢找总是能找到问题所在的。

      刚一进来manager就给我布置了一些任务，包括hadoop、mysql和zenoss。今天就先说说hadoop。manager对我的hadoop要求不高，只需要大概了解，除了问题能发现，同时能够进行数据备份就okay了。所以在学习了linux之后我的第二个学习任务是hadoop，完全的一窍不通，好歹列出了学习的顺序——文件系统->分布式文件系统->GFS->hadoop。一点点看，也大概弄出了点头绪，掌握了基础。

     文件系统包含三方面的含义：与文件管理有关的软件，被管理的文件，以及实施文件管理所需要的数据结构。从系统的角度来看，文件系统是对文件存储器控件进行分配和组织，负责文件存储并对存储的文件进行保护和检索的系统。建立文件系统的过程就是初始化磁盘或者分区，并将记录数据结构写到磁盘上。在UNIX中，文件系统的中心概念包括：superblock（文件系统的总体信息），inode（除了名字外的文件的所有信息），directory block（inode+name），data block（存放data），indirection block（动态分配指向data block的指针）。目前我们常用的文件系统包含以下几类：FAT（FAT16与FAT32），NTFS（基于安全性的文件系统，可恢复，对data进行压缩），CDFS（光盘文件系统），exFAT（扩展文件分配表，适用于闪存），ext2（GNU/Linux中的标准文件系统，存放文件的性能较好），ext3（日志式文件系统，兼容ext2）。

     分布式文件系统（HDFS）：文件系统管理的物理存储资源并不一定直接连接在本地节点上，而是通过计算机网络与节点相连，基于C/S模式。理解分布式文件系统需要理解一些主要概念：

文中所用翻译HDFS中的术语GFS中的术语术语解释主控服务器NameNodeMaster整个文件系统的大脑，它提供整个文件系统的目录信息，并且管理各个数据服务器。数据服务器DataNodeChunk Server分布式文件系统中的每一个文件，都被切分成若干个数据块，每一个数据块都被存储在不同的服务器上，此服务器称之为数据服务器。数据块BlockChunk每个文件都会被切分成若干个块，每一块都有连续的一段文件内容，是存储的基恩单位，在这里统一称做数据块。数据包Packet无客户端写文件的时候，不是一个字节一个字节写入文件系统的，而是累计到一定数量后，往文件系统中写入一次，每发送一次的数据，都称为一个数据包。传输块Chunk无在每一个数据包中，都会将数据切成更小的块，每一个块配上一个奇偶校验码，这样的块，就是传输块。备份主控服务器SecondaryNameNode无备用的主控服务器，在身后默默的拉取着主控服务器 的日志，等待主控服务器牺牲后被扶正。上表中的GFS就是Google提出的分布式文件系统的概念，而hadoop就是对该概念的实现。

      在hadoop服务器架构时，其中重要的服务器包括：主控服务器（Master/NameNode），数据服务器（ChunkServer/DataNode），和客户服务器。HDFS和GFS都是按照这个架构模式搭建的。个人觉得，其中设计的最核心内容是：文件的目录结构独立存储在一个主控服务器上，而具体文件数据，拆分成若干块，冗余的存放在不同的数据服务器上。存储目录结构的主控服务器，在GFS中称为Master，在HDFS中称为NameNode。这两个名字，叫得都有各自的理由，是瞎子摸象各表一面。Master是之于数据服务器来叫的，它做为数据服务器的领导同志存在，管理各个数据服务器，收集它们的信息，了解所有数据服务器的生存现状，然后给它们分配任务，指挥它们齐心协力为系统服务；而NameNode是针对客户端来叫的，对于客户端而言，主控服务器上放着所有的文件目录信息，要找一个文件，必须问问它，由此而的此名。主控服务器在整个集群中，同时提供服务的只存在一个，如果它不幸牺牲的话，会有后备军立刻前赴后继的跟上，但，同一时刻，需要保持一山不容二虎的态势。这种设计策略，避免了多台服务器间即时同步数据的代价，而同时，它也使得主控服务器很可能成为整个架构的瓶颈所在。因此，尽量为主控服务器减负，不然它做太多的事情，就自然而然的晋升成了一个分布式文件系统的设计要求。每一个文件的具体数据，被切分成若干个数据块，冗余的存放在数据服务器。通常的配置，每一个数据块的大小为64M，在三个数据服务器上冗余存放（这个64M，不是随便得来的，而是经过反复实践得到的。因为如果太大，容易造成热点的堆叠，大量的操作集中在一台数据服务器上，而如果太小的话，附加的控制信息传输成本，又太高了。因此没有比较特定的业务需求，可以考虑维持此配置...）。数据服务器是典型的四肢发达头脑简单的苦力，其主要的工作模式就是定期向主控服务器汇报其状况，然后等待并处理命令，更快更安全的存放好数据。此外，整个分布式文件系统还有一个重要角色是客户端。它不和主控服务和数据服务一样，在一个独立的进程中提供服务，它只是以一个类库（包）的模式存在，为用户提供了文件读写、目录操作等APIs。当用户需要使用分布式文件系统进行文件读写的时候，把客户端相关包给配置上，就可以通过它来享受分布式文件系统提供的服务了。（这一段是抄的Venus神庙的博客，我觉得很有用，也必须要记下来，所以抄了，不要怪我，也不要问我要版权，仅供个人参考，不卖钱）。

      hadoop安装完成之后的文件操作，这些网上到处都有，就不赘述了。