数据中心服务器基础知识大全

服务器对每个从事IT工作的人来说并不陌生，但是服务器所涉及的各种知识细节，并非大家都十分清楚，为了让大家深入了解服务器的关键知识点，笔者特意抽时间总结了这篇科普文章，旨在帮助读者全面了解服务器。今天内容就从服务器的架构和分类开始(2019.9.21更新)。

按照服务器体系架构，服务器主要分为非x86服务器和x86两类。

非x86服务器包括大型机、小型机和UNIX服务器，它们是使用RISC或EPIC，并且主要采用UNIX和其它专用操作系统，RISC处理器主要包括IBM公司的Power和PowerPC处理器，SUN和富士通合作研发的SPARC处理器。EPIC处理器主要是Intel研发的安腾处理器等。

x86服务器又称CISC架构服务器，采用Intel或其它兼容x86指令集的处理器芯片和Windows操作系统的服务器。服务器按照不同分类方法主要分为如下：

CISC:Complex Instruction Set Computing 复杂指令集计算

RISC:Reduced Instruction Set Computing 精简指令集计算

EPIC:Explicitly Parallel Instruction Computing 显式并行指令运算

实际上，服务器的分类没有一个统一的标准，下面从多个纬度来看服务器的分类，可以加深我们对各种服务器的认识。

除了从指令集、架构和功能进行分类外，还可以从服务器外观上分类为塔式、机架、刀片和高密度服务器。

高度计量单位

U为机柜安装空间的高度度量单位，1U = 44.45 mm = 1.75 inch

容量计量单位

是一种容量计量单位，通常在标示内存等具有一般容量的储存媒介之储存容量时使用。一般指磁盘空间、文档大小时使用。

速率单位

指在一个数据传送系统中，单位时间内通过设备比特、字符、块等的平均量。一般在描述传输速率或带宽时使用。如果是比特/秒，就用bit/s (kbit/s, Mbit/s) ,如果是字节/秒，就用B/s (kB/s、 MB/s、 KB/s)， 小写的k代表1000， 大写的K代表1024。

计算单位和峰值

每秒浮点运算次数(亦称每秒峰值速度)是每秒所执行的浮点运算次数(Floating point Operations Per Second)的简称，被用来估算电脑效能，尤其是在使用到大量浮点运算的科学计算领域中。

端口自协商

是一个以太网的过程，两个相连的设备选择通用的传输参数，如速度、双工模式和流量控制。在这个过程中，连接的设备首先共享它们的能力(10、100、1000BASE-T )，然后选择它们都支持的最高性能传输模式。在OSI模型中，对于以太网，在IEEE 802.3对其做了定义。

服务器主要软件

BIOS(Basic Input/Output System) 是服务器上电后最先运行的软件。它包括基本输入输出控制程序、上电自检程序、系统启动自举程序、系统设置信息。BIOS是服务器硬件和OS之间的抽象层，用来设置硬件，为OS运行做准备。 BIOS设置程序是储存在BIOS芯片中的。

UEFI(Unified Extensible Firmware Interface) 下一代BIOS是UEFI, 即统一的可扩展固定接口。这种接口用于操作系统自动从预启动的操作环境，加载到一种操作系统上，从而使开机程序化繁为简，节省时间。

CMOS(complementary metal -oxide-semiconductor) 是电脑主机板上一块特殊的RAM芯片，是系统参数存放的地方。CMOS存储器是用来存储BIOS设定后的要保存数据的。

BMC (baseboard management controller) 对服务器进行监控和管理。

OS(Operating system)和位数，主要分32bit和64bit操作系统，计算机处理器在RAM（随机存取储存器）处理信息的效率，取决于32位和64位版本。64位版本比32位的可以处理更多的内存和应用程序。

简单理解下，64位版本可以处理的物理内存在4GB以上，高达128GB，而32位版本最多可以处理4 GB的内存。因此，如果你在计算机上安装32位版本的Windows，那么安装4GB以上的RAM是没意义的。

服务器标准

ATCA(AdvancedTelecom Computing Architecture ) 国际标准,ATCA脱胎于在电信、航天、工业控制、医疗器械、智能交通、军事装备等领域应用广泛的新一代主流工业计算技术: CompactPCI标准。是为下一代融合通信及数据网络应用提供的一个高性价比的，基于模块化结构的、兼容的、并可扩展的硬件构架。

ATCA由一系列规范组成，包括定义了结构、电源、散热、互联与系统管理的核心规范PICMG3.0以及定义了点对点互联协议的5个辅助规范组成(以太和光纤传输、InfiniBand传输、星形传输、PCI-Express传输和RapidIO传输)。

OSCA (Open Service Converged Architecture)开放服务汇聚架构, 是华为基于ATCA标准自研的服务器平台

OSTA (Open Standards Telecom Architecture)是由华为技术公司生产的强大的服务处理平台。它由处理器子系统、交换网络子系统、机电子系统和设备管理子系统组成。

服务器的逻辑结构

服务器的构成包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。计算机的五大组成部分,最重要的部分是CPU 和内存。CPU 进行判断和计算，内存为CPU 计算提供数据。

处理器缓存

缓存的出现主要是为了解决CPU运算速度与内存读写速度不匹配的矛盾，因为CPU运算速度要比内存读写速度快很多，这样会使CPU花费很长时间等待数据到来或把数据写入内存。CPU缓存是位于CPU与内存之间的临时存储器，它的容量比内存小的多但是交换速度却比内存要快得多。

缓存的工作原理是当CPU要读取一个数据时，首先从缓存中查找，如果找到就立即读取并送给CPU处理；如果没有找到，就用相对慢的速度从内存中读取并送给CPU处理，同时把这个数据所在的数据块调入缓存中，可以使得以后对整块数据的读取都从缓存中进行，不必再调用内存。

目前所有主流处理器大都具有一级缓存(level 1 cache，简称 L1 cache)和二级缓存(L2 cache)， 少数高端处理器还集成了三级缓存(L3 cache)。

一级缓存可分为一级指令缓存(instruction cache)和一级数据缓存(data cache)。一级指令缓存用于暂时存储并向CPU 递送各类运算指令；一级数据缓存用于暂时存储并向CPU 递送运算所需数据，这就是一级缓存的作用。

二级缓存就是一级缓存的缓冲器：一级缓存制造成本很高因此它的容量有限，二级缓存的作用就是存储那些CPU处理时需要用到、一级缓存又无法存储的数据。

三级缓存和内存可以看作是二级缓存的缓冲器，它们的容量递增，但单位制造成本却递减。

内存(Memory)和存储(Storage)的区别

大多数人常将内存(Memory)与储存空间(Storage)两个名字混为一谈,尤其是在谈到两者的容量的时候。内存(Memory)是指计算机中所安装的随机存取内存的容量，而储存(Storage)是指计算机内硬盘的容量。

为了避免混淆,我们将计算机比喻为一个有办公桌与档案柜的办公室。档案柜代表计算机中提供储存所有所需档案及资料的硬盘，工作时将需要的档案从档案柜中取出并放到办公桌上以方便取得，办公桌就像保持资料及数据取用方便的内存。

内存频率

内存主频和CPU主频一样，习惯上被用来表示内存的速度，它代表着该内存所能达到的最高工作频率。内存主频是以MHz(兆赫)为单位来计量的。内存主频越高在一定程度上代表着内存所能达到的速度越快。内存主频决定着该内存最高能在什么样的频率正常工作。

系统启动方式

启动系统通常有三种方式：冷启动、热启动和复位启动。

冷启动：过程包括上电、全面自检、系统引导及初始化等工作；

热启动：和冷启动的区别是不需要重新上电、自检的范围很小；

复位启动：和冷启动的区别仅仅在于无须上电。

主板南北桥区别

一个主板上最重要的部分可以说就是主板的芯片组了，主板的芯片组一般由北桥芯片和南桥芯片组成，两者共同组成主板的芯片组。

北桥芯片主要负责实现与CPU、内存、AGP接口之间的数据传输，同时还通过特定的数据通道和南桥芯片相连接。北桥芯片的封装模式最初使用BGA封装模式，到Intel的北桥芯片已经转变为FC-PGA封装模式，不过为AMD处理器设计的主板北桥芯片依然还使用传统的BGA封装模式。

南桥芯片相比北桥芯片来讲，南桥芯片主要负责和IDE设备、PCI设备、声音设备、网络设备以及其他的I/O设备的沟通，南桥芯片到目前为止还只能见到传统的BGA封装模式一种。

交换与路由

交换：完成信号由设备入口到出口的转发。只要是和符合该定义的所有设备都可被称为交换设备。

二层交换机工作在数据链路层。二层交换机就是普通的交换，把数据以帧的形式发送出去。三层交换机工作在网络层。三层交换机既可以作交换机又可以做路由器。

路由：是把信息从源穿过网络传递到目的地的行为，在路上，至少遇到一个中间节点。它们的主要区别在于桥接发生在OSI参考协议的第二层（链接层），而路由发生在第三层（网络层）。这一区别使二者在传递信息的过程中使用不同的信息，从而以不同的方式来完成其任务。

接入交换机：一般用于直接连接电脑。通常将网络中直接面向用户连接或访问网络的部分称为接入层。负责连接机柜内部的服务器。

汇聚交换机：汇聚相当于一个局部或重要的中转站，将位于接入层和核心层之间的部分称为分布层或汇聚层。完成接入层交换机流量的汇聚，并与核心层交换机连接。

核心交换机：相当于一个出口或总汇总。完成数据报文的高速转发，并提供对外的网络接口。

堆叠和级联

级联和堆叠是多台交换机或集线器连接在一起的两种方式。它们的主要目的是增加端口密度，主要区别：

级联是上下关系(总线型、树型或星型的级联)，堆叠是平等关系(堆叠中多台交换机作为一个整体对外体现为一台逻辑设备)。

级联可以连接不同类型或厂家的交换机，而堆叠只有在同系列的交换机之间。

交换机间的级联在理论上没有级联数的限制。叠堆有最大限制，堆叠中多台交换机作为一个整体对外体现为一台逻辑设备。

堆叠组建时会选举出一台交换机做为主交换机(Master)，剩下的交换机称为从交换机(Slave)。主交换机是整个堆叠系统中的控制中心。堆叠中每一台交换机都同时具备成为主交换机或者从交换机的能力。

浮点数精度

半精度浮点数是一种计算机使用的二进制浮点数数据类型。半精度浮点数使用2字节(16位)存储。

单精度浮点数格式是一种计算机数据格式，在计算机存储器中占用4个字节(32 bits)，利用“浮点”(浮动小数点)的方法，可以表示一个范围很大的数值。

双精度浮点数(Double)是计算机使用的一种数据类型。比起单精度浮点数，双精度浮点数使用 64 位(8字节)来存储一个浮点数。

时间跳变和渐变

NTP client和server的时间同步有两种情况: 时间跳变(time step)和渐变(time slew)。时间跳变是指在client和server间时间偏差(Offset)过大时(默认128ms)，瞬间调整client端的系统时间。

时间渐变是指时间差较小时，通过改变client端的时钟频率，进而改变client端中"1秒"的"真实时间"，保持client端时间连续性。如果client端比server端慢10s，client端的中每1秒现实时间是1.0005秒，虽然client端的时间仍然是1秒1秒增加的，通过调整每秒的实际时间，直到与server的时间相同。

FC SAN的Zone

Zone是FC SAN特有一种概念，目的用来配置同一个交换机上面不同设备之间的访问权限。同在一个zone里面的设备可以互相访问。Brocade交换机有个Default zone，出厂时候所有交换机端口都在一个default zone里面，默认是不允许互相访问的。

Zone可以根据交换机端口ID(Domain 、Port ID)或者设备WWN来划分。

一个Zone里面可以部分设备是交换机端口ID，部分是WWN的混合Zone。

Hard Zone和Soft Zone是早期交换机厂商根据对Zone实现方式做的一个分类。通过硬件来实现的叫做Hard Zone，通过软件来实现叫做soft zone；早期一般称基于端口ID的Zone为Hard zone，基于WWN的Zone为Soft Zone。现在这两个类型的Zone都是基于硬件实现。

最佳使用WWN来划分Zone，始终遵循Single Initiator原则 。

交换机通常把多个Zone纳入一个Zone Set管理，每个交换机可以保留多个Zone Set配置，一次有且只有一个Zone Set配置能够被激活。

TPC基准(Benchmark)标准规范

TPC(Transaction Processing Performance Council)是由数10家会员公司创建的非盈利组织，总部设在美国。TPC的成员主要是计算机软硬件厂家，而非计算机用户，它的功能是制定商务应用基准程序(Benchmark)的标准规范、性能和价格度量，并管理测试结果的发布。

TPC已经推出了多套Benchmarks，被称为TPC-A、TPC-B、TPC-C和TPC-D。其中A和B已经过时不再使用了。TPC-C是在线事务处理(OLTP)的基准程序，TPC-D是决策支持(Decision Support) 的基准程序。TPC即将推出TPC-E，作为大型企业(Enterprise)信息服务的基准程序。

TPC-C使用三种性能和价格度量，其中性能由TPC-C吞吐率衡量，单位是tpmC。tpm是Transactions Per Minute的简称；C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。

CPU亲和性

处理器亲和性又称处理器关联。通过处理器关联可以将虚拟机或虚拟处理器映射到一个或多个物理处理器上。该技术基于对称多处理机操作系统中的Native Central Queue调度算法。队列(Queue)中的每一个任务(进程或线程)都有一个标签(Tag)来指定它们倾向的处理器。在分配处理器的阶段，每个任务就会分配到它们所倾向的处理器上。

处理器亲和性利用了这样一个事实，就是进程上一次运行后的残余信息会保留在处理器的状态中(也就是指处理器的缓存)。如果下一次仍然将该进程调度到同一个处理器上，就能避免一些不好的情况(比如缓存未命中)，使得进程的运行更加高效。

调度算法对于处理器亲和性的支持各不相同。有些调度算法在它认为合适的情况下会允许把一个任务调度到不同的处理器上。比如当两个计算密集型的任务(A和B)同时对一个处理器具有亲和性时，另外一个处理器可能就被闲置了。这种情况下许多调度算法会把任务B调度到第二个处理器上，使得多处理器的利用更加充分。

处理器亲和性能够有效地解决一些高速缓存的问题，但却不能缓解负载均衡的问题。而且，在异构系统中，处理器亲和性问题会变得更加复杂。

简单网络管理协议(SNMP)

SNMPv1/v2/v3/v2c协议主要用于网络监控和管理。在SNMP模型中，有一或多个管理系统和多个被管理系统。每一个被管理系统上有运行一个代理(Agent)软件通过SNMP向管理系统报告信息。一个SNMP管理的网络由下列三个关键组件组成:

网络管理系统 (NMS): 运行应用程序监视并控制被管理的设备。也称为管理实体(managing entity)，网络管理员在这儿与网络设备进行交互。NMS提供网络管理需要的大量运算和记忆资源。一个被管理的网络可能存在一个以上的NMS。

被管理的设备(managed device): 一个被管理的设备是一个网络节点，它包含一个存在于被管理的网络中的SNMP代理。被管理的设备通过管理信息库(MIB)收集并存储管理信息，并且让网络管理系统能够通过SNMP代理者获取这项信息。

代理(agent): 运行在被管理设备中的网络管理软件。代理控制本机的管理信息，以和SNMP兼容的格式发送这些信息。

关于服务器技术，已经整理成“数据中心服务器知识全解”电子书，全书共190页，分18个章节。全书简要目录如下(详解目录和内容请通过“阅读原文”获取)

1、 服务器处理器芯片概述 1

1.1 ARM处理器和厂商介绍 2

1.1.1 ARM处理器架构新进展 8

1.1.2 ARM处理器的主流玩家 10

1.1.3 业界对ARM技术发展态度 10

1.2 RISC-V处理器和厂商介绍 11

1.3 MIPS处理器和厂商介绍 15

1.3.1 龙芯产品和新进展 15

1.4 Alpha处理器和厂商介绍 17

2、 处理器生态和软件堆栈 18

2.1 处理器软件堆栈架构概述 19

2.2 操作系统和预置软件堆栈 20

2.2.1 原生操作系统支持介绍 20

2.2.2 操作系统预置应用程序 20

2.3 通用应用程序移植分析 20

2.3.1 解释型语言应用程序移植 21

2.3.2 编译型语言应用程序移植 21

2.3.3 应用程序安装包 22

2.3.4 ARM与X86编译差异与解决方法 22

2.3.5 改善应用程序并发计算能力 24

>>>以下为简略目录<<<

3、 RISC处理器几个关键知识和对比 25

4、 服务器基础知识概述 30

5、 服务器总线知识 50

6、 BIOS/UEFI固件知识 52

7、 服务器认证体系知识 54

8、 服务器CPU基础知识 54

9、 服务器内存基础知识 64

10、 服务器硬盘基础知识 70

11、RAID基础知识 87

12、网卡基础知识 93

13、光纤和连接器基础知识 97

14、光纤交换机基础知识 123

15、GPU架构和相关知识 135

16、FPGA架构和相关知识 179

17、操作系统基础知识介绍 186

18、服务器安全基础知识 196

业内有这么一句话说：云计算可能改变了整个传统IT产业的基础架构，而大数据处理，尤其像Hadoop组件这样的技术出现，将是改变IT业务模式的一种技术。

　　另外，很多小伙伴可能还搞不明白云和Hadoop有什么关系，事实上这是两种截然不同的技术。虽然从某种意义上来讲，他们都是在大规模的计算机集群上来完成的。但是openstack或其它的paas或sas的云环境，他们所指的是所谓的云计算的方式，通常是来讲是用于指定如何将用户本地完成的运算迁移到云上去，让用户无需得知其计算能力，存储能力等各种能力来自任何一个地方的机制。

一.数据的存储方式（就是对数据的建模）

1>.结构化数据：

　　即行数据，存储在数据库中，用二维表来存储的数据。

2>.非结构化数据：

　　难以使用数据库二维表来存储的数据，如文档，图片等，字段可变，字段内容可变或不可变组成的。

3>.半结构化数据：

　　能够实现自我描述的数据，将结构和数据本身混在一起，xml，json，html。

二.Hadoop的由来

1>.GFS文件系统诞生

　　2003年，The Google File System（简称GFS）诞生了，GFS采取了数据块的方式管理数据，将一个单独的大文件切割成N个指定的小片段，而后在每个节点上存储单个片段并且通过在集群中的多个节点上存储同一个数据块的多份冗余副本以实现容灾的功能。站在这个角度来讲，GFS的设计主要是用来支持大规模数据密集型的分布式应用程序的运行。存储过程如下图：

2>..MapReduce相继开源

　继2003发布GFS文件系统开源后，2004年又发表了关于MapReduce的文章，即Simplify Data Processing On Large Clusters。MapReduce定义了一种编程模型及其运行框架，它提供了集中的多个节点上自动并行容错及可处理TB规模数据，甚至能够达到PB规模的数据处理平台。事实上MapReduce是GFS集群的组成部分，他要工作在GFS的基础之上才能够完成处理操作的。因此MapReduce与GFS一同构成了所谓的大数据存储及并行处理平台。

　　MapReduce的特性：

　　　　a>.向外扩展;

　　　　b>.假设故障常见，自我完成数据冗余，并自我完成故障处理;

　　　　c>.将程序移向数据;

　　　　d>.顺序处理数据，并避免随机访问;

　　　　e>.向程序员隐藏系统级别的细节;

　　　　f>.实现平滑扩展;

3>.Nutch搜索平台诞生

　　该搜索引擎用Java语言编写而成，该搜索引擎在工作一段时间后，作者发现了一个难题，这个搜索引擎爬来的数据难以有效存储，在小规模存储中还能正常应用，但是到大规模应用该存储的很让然头疼了，正在为这个问题发愁时，作者看到了Google公司公开的论文，也就是上面我们介绍的GFS文件系统，作者看到之后如获至宝。因此作者倾注了心血在Nutch搜索引擎的应用，于是在Google的GFS基础上，山寨出来了一个DFS和MapReduce平台。后来作者看见他的还在在玩一个玩具象，给其平台取名为Hadoop。

　　Hadoop完全由Java语言实现的DFS和MapReduce。由于DFS是分布式文件系统的统称，回来干脆取Hadoop首字母，称之为HDFS，因此我们可以说Hadoop是由HDFS和MapReduce组成。所以Hadoop在某种意义上来讲，就是Google处理平台的山寨版本，当然我更喜欢称它开源实现。比较有意思的是整个程序都是由Java语言编写的，因此HDFS和MapReduce都要依赖JDK才能跑起来。换句话说，MapReduce的原生接口就是由Java实现的，所以我们要在他的MapReduce框架上去写MapReduce程序的话，很显然Java是首选语言哟！

4>.Hadoop的应用平台

　　当我们把一个Hadoop集群构建出来之后，将来是要在该集群上跑上面任务呢？当然我们不是为了在这个平台上跑一些单词统计（wordCount）程序，而是跑一些有意义的事情，比如对日志进行分析等等。要怎么对这些日志进行处理呢？此时就需要Hadoop程序员来研发MapReduce程序了。

　　因此Hadoop的应用平台主要有两个层次，即Hadoop运维和Hadoop开发工程师，而后者的需求量是远远大于前者的。而安装Hadoop服务对运维而言自然是小菜一碟啦，如果对Java本身进行研究的话，运维还得对JDK进行优化，这样可以保证Java程序跑的更灵活。Hadoop运维就是无非就是对其进行优化的（后期我会写一片关于Hadoop运维的技能）而真正更多的需求就是在运维搭建好的Hadoop环境上跑一个个的特定任务。

　　Hadoop本身还只是一个基础框架。收集数据并存放在Hadoop中的HDFS中就是一个难题。另外，我们传统意义上的很多数据早起是存在数据库中的，如果我们想要用Hadoop对数据库里面的数据进行处理，那么就需要一个ETL工具，来帮我们实现收集数据，转换和装载。

　　一个公司Hadoop集群若只是不熟在三四十台服务器上，我们称之为入门级应用。一百台两百台服务器都不好意思说是Hadoop集群的，据说腾讯和淘宝他们单一的Hadoop集群在4000个节点左右。

Hadoop不建议跑在虚拟机上的，因此Hadoop和openstack结合使用还是很少见的！因为Hadoop对磁盘的IO要求是相当的高的，若你用虚拟机进行存储性能上得打上一个大大的问号！

三.开源大数据处理平台开源解决方案

四.HDFS各节点详解

1>.NameNode

　　HDFS的名称节点，在内存中保存所有文件的元数据，因此任何客户端想要获取文件时，要到namenode节点上来获取该文件的元数据信息。所以我们文件想外展示时是单个文件但却可以分割起来进行存储的。所谓的元数据，咱们可以理解为NameNode的文件名称空间。对于分布式文件系统来讲，从分布式文件访问的入口开始被称为分布式文件系统的根，在跟目录下可以存放文件或者子目录。要注意的是，这里的文件或子目录并不是保存真正的数据，而是存放的是路径映射。在各个路径映射下有不同的文件，每个文件可以被分割成了多个数据块，每个块默认最少有三个副本，这三个副本分别位于不同的DataNode节点上，这些信息都记录在NameNode服务器中。

2>.SecondaryNameNode

　　为了保证NameNode的可用性，最简答的方式就是将名称节点上的持久元数据信息实时存储多个副本于不同的存储设备中，或者是提供第二名称节点，即Secondary NameNode。

　　第二名称节点并不真正扮演名称节点角色，它的主要认识是周期性地将编译日志合并至名称空间镜像文件中以免编译日志变得过大；它运行在一个独立的物理主机上，并需要跟名称节点同样大的内存资源来完成文件合并；另外，它还保存一份名称空间镜像的副本；然而，根据其工作机制可知，第二名称节点要滞后与主节点，因此名称节点故障时，部分数据丢失仍然不可避免。

　　综上所述，大家应该很清楚的知道NameNode是整个HDFS文件系统的关键入口，它很有可能出现单点故障，为了避免这种情况（NameNode服务器过长时间宕机），就有了另外一个离线冗余备份，即SecondaryNameNode。辅助NameNode节点（即SecondaryNameNode）会帮助NameNode不断去合并内存中所谓元数据的映像信息，简单的来讲，就是对文件的删除，修改，创建等不断修改元数据的操作获取到本地进行持久化存储（你也可以理解是SecondaryNameNode得到了一个离线的副本），当NameNode宕机以后，SecondaryNameNode可以替换成之前的NameNode，只不过这个提升过程是相当漫长的（可能要20~30分钟不等）。因为当NameNode宕机后，各种元数据必须要在指定时间内收到各个DataNode对于其所持有的数据模块的报告并最终汇总到本地真正去获取到每一个数据的副本信息以后才可以完成替换NameNode流程。

3>.HDFS的Client（Hadoop的API）

　　那么客户端是如何跟我们的HDFS进行交互呢？很显然他们之间交互是要基于HDFS自带的API进行的。HDFS的Client到NameNode获取元数据，在得到元数据之后，元数据的节点会告诉Client其想要访问文件被分割成了多少个块，以及每个块都在哪个DataNode服务器上存储着，这个时候Client再去相应的DataNode服务器上拿数据。也就是说Client不仅要和NameNode打交道，还要跟DataNode打交道。换句话说，Client存储和读取数据都是Client自我直接实现的。

4>.DataNode

　　负责存储真实数据。

5>.HDFS故障分类

　　a>.Namenode故障

　　　　如果NameNode故障发生时，这就意味着整个集群挂掉了，因此我们可以说NameNode是整个集群的单点故障所在。

　　b>.网络故障

　　　　为了避免网络故障，每次发送数据包报文时，我们的DataNode服务器都需要做确认的，若没有收到DataNode服务器的确认信息，我们就可以认为其可能存在故障。因此他们传输数据是可靠的，是基于TCP这种协议进行传输的。

　　c>.数据节点故障

　　　　事实上，每个DataNode每隔三秒钟就会向NameNode发送自己的心跳信息（还要报告其存放的数据块列表的相关信息），目的是告诉NameNode服务器当前的DataNode依然是存活状态，也就是正常工作状态。当NameNode在一段时间内（默认是10分钟）一直没有收到某个DataNode的心跳信息， 那么NameNode就任务该DataNode已经挂掉了，并将之前存在该DataNode服务器上的数据重写在其它节点中重写拷贝一份。

　　d>.数据故障

　　　　每个数据块在发送数据给接收端时，会将该数据块的校验码一起发送给接收端，接收端接受数据后会重写生成校验码并与发送端发来的校验码进行比较，若两个校验码一致则说明数据是完整的，否则接收端会认为该数据块是损坏的。DataNode节点除了想NameNode发送心跳信息外，还要定期的发送其存放的数据块列表信息，当发现自己存放的数据块是损坏的时候，并不会将该损坏的数据块加入在列表中发送给NameNode，而是将完整的数据块发送给NameNode，NameNode服务器会定期整理所有的DataNode发来的数据列表信息，当发现有的数据块存储不足指定的份数（默认是3份）时，NameNode会自动新生成相应的份数进行备份。

6>.HDFS的机架感知

　　我们知道Hadoop默认会将每个数据块复制三分。如果想往HDFS分布式文件系统中写数据，而写需要写的客户端恰好也是DateNode，那么这台服务器就优先被存放为第一份副本的存放位置，否则的话就从众多的DataNode中随机挑选一个存放副本（假设数据要保留三份，当第一台DataNode存入数据时，并不会等到其将数据第一份数据存储完毕，于是同时，会自动向第二台服务器上拷贝数据进行备份，而第二台服务器也不会等到数据拷贝完毕，而是继续拷贝到其它节点中去，我们称之为管线操作（英文：Pipe Line））。而剩下的两份数据应该存放在不同的机架上或者是相邻机架的两台服务器中，也就是说同一个机架上要求最多存放两个副本。（我大胆猜测设计者是为了方式一个机柜断电时，DateNode访问不到情况。）当然，具体如何存储还是靠我们手动配置，如果你非要放在同一个机柜上谁也那你没辙。详情请参考：“http://hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-common/RackAwareness.html”

7>.向HDFS文件系统保存数据

　　上图链接所画的链接工具为JVM，实际上HDFS的API已经支持不同的编程语言了，我们可以用不仅仅可以用Java，还可以用我们运维拿手的编程语言Python或者是shell进行编程哟。

五.MapReduce详解

1>.Hadoop的MapReduce的工作流程

　　结合上图来看，说明Hadoop的MapReduce所能处理的数据仅简单的键值数据，Hadoop的MapReduce的工作流程大致分为五个步骤：

　　a>.Split

　　　　我们知道我们写的MapReduce任务主要是用来处理文件的，这个文件的输入（Input）有可能是来自某个DataNode的一个数据块而已，也有可能是来自多个不同的DataNode的多个数据副本(注意：这些副本是指的是不同的数据哟)。而这些数据块未必就是键值数据（比如日志文件），由于Hadoop是无法处理非键值数据的，我们必须要把数据做成模型化，把一些杂乱无章的非结构化数据抽取成键值数据对。这个时候就需要MapReduce提供一个Split程序（这个程序可以是程序员自己编写），这个split程序能够将文件中的每一个数据按照用户所指定的标准给它切割成理想的键值对（如上图：<key1,value1>），并将切割后的键值对发送给第二阶段的mapper任务（maper worker，即map工作进程）。【我们以Wordcount为例，此时Split切割的方式就是将文件的行号作为键，将每行的内容作为值，并发送给map程序】

　　b>.map

map的工作进程（mapper）在收到工作进程以后，会对其做进一步处理，在处理结束之后，形成另外一个键值对（如上图：<ikey1,ivalue1>），新生成的键值对是可以让reduce程序进行折叠的！【我们仍然一Wordcount为例，Split程序发来行号和行号对应的数据，mapper接受后，会将Split的结果的每个单词切割好的单词取出来作为key，并对其每个单词赋初始值为1。】需要注意的是，map的数据量如果非常大的话，会临时将数据保存到当前节点的临时目录中生成临时文件，当所有的mapper都处理完任务时，才会将数据发送给reduce。

　　c>.Shuffle & Sort

　　　　map的工作进程mapper将数据发送给reduce之前，会进行排序操作，并将排序的结果发送给reducer。【由MapReduce框架（framework）决策将相应的key发送给具体的reducer】

　　d>.reduce

　　　　一个reduce可以处理多个键，它所处理的每一个键对应的所有数据都必须由这个reduce来处理，它可以根据键对每个数据进行折叠。【我们还是以Wordcount为例，把同一个单词出现的次数都交给同一个reducer，此时reducer就会将这些key做一个聚合，就是将将多个相同的key合并成同一个key，然后把每一个key的value进行累加操作，最终多个reducer将处理的结果进行存储】

　　e>.Store

　　　　多个reducer处理的结果整合到一起，就是Input数据中每个单词出现的频次，最终结果默认会存入到HDFS系统中。如果处理的文件较小的话我们也可以存入到本地哟。

2>.单reduce任务的MapReduce数据流（此图摘自“Hadoop权威指南"）

　　我们来阐述一下单reduce任务的MapReduce数据流处理过程，如上图所示：

　　　　a>.Split程序将数据切割成三分，分别发送给3个map去处理；

　　　　b>.map将数据处理的数据临时存在本地，等到map程序执行完毕后，在对这些临时数据进行排序并发送给reduce；

　　　　c>.此图只有一个reduce，因此它拿到了所有的键值对，这个时候由它执行merge操作，将多个重复的key进行聚合并排序，再由reduce进行折叠，折叠后的数据结果就只有一份，因为reduce就只有一个，而后数据保存在HDFS文件系统之上；

　　　　d>.将数据存放在HDFS之后，需要执行replication来保存多个副本。

3>.多reduce任务的MapReduce数据流（此图摘自“Hadoop权威指南"）

　　我们来阐述一下多reduce任务的MapReduce数据流处理过程，如上图所示：

　　　　a>.Split程序将数据切割成三分，分别发送给3个map去处理；

　　　　b>.map将数据处理的数据临时存在本地，等到map程序执行完毕后，在对这些临时数据进行排序(排序可以让相同的键都相邻)并把相同的键发给同一个reduce；

　　　　c>.在数据发送给reduce之前，数据需要进行merge操作(这里的merge仅是指的的将数据流进行合并成单独的一个流)；,

　　　　d>.数据在本地完成merge操作之后，会将结果发送给reduce，由reduce完成折叠操作，即将重复的key进行合并，每个reduce处理的结果手动合并起来就是最终的结果（结合上图来看的话，“part 0”和“part 1”就是两个reduce的输出结果）；

4>.没有reducer的MapReduce作业（此图摘自“Hadoop权威指南"）

　　事实上，我们的作业完全可以没有reduce，如上图所示：

　　　　如果我们map输出的结果本身已经就是最终结果的话，就无效reduce再次处理，大家应该都知道reduce的主要目的就是将相同的key折叠起来，若map处理后的结果本身就无序折叠的话就完全没有必要在执行reduce任务啦！因此我们可以说在MapReduce程序中，可以没有reduce，单必须得有map程序。

5>.MapReduce客户端提交一个作业

　　接下来我们阐述一下MapReduce客户端提交一个作业的过程：

　　　　a>.MapReduce的客户端提交一个作业请求（这客户端可以是一个开发人员针对MapReduce的maste的API发起的作业请求）；

　　　　b>.MapReduce在拿到作业后，会将这个作业分割成多个小作业去执行。如上图所示，master将任务分为两个部分，一部分是map作业，另一部分是reduce作业，由MapReduce的master决定map运行在哪个物理节点上，在map启动后不久就要启动reduce，这些操作都是由MapReduce来调度的；

　　　　c>.接下来的处理过程请参考上面的“多reduce任务的MapReduce数据流”。

6>.MapReduce逻辑架构

　　　通过上图可以看出，我们可以了解到MapReduce的逻辑架构：

　　　　a>.同一个集群内部，可以同时运行N个作业的，这些N个作业可能提前完成任务，那么就会腾出空间来让master调度执行下一个作业；

　　　　b>.当任何一个作业提交结束了，提交完成之后，他就成了历史列表中的历史作业，如上图的“Historical jobs”；

　　　　c>."job Tracker"在接受到每一个作业之后，就要把作业本身完成分割而后将其发送至各“task Tracker”给予运行的；

　　　　d>.如果是非常繁忙的Hadoop集群的话，很有可能整个集群的所有的物理节点都比较繁忙，而对于Hadoop来说，无论是对于IO资源（磁盘I/O和网络带宽）的占用还是对CPU资源的占用都很密集，因此，Hadoop集群很少运行在虚拟环境中的。

7>.partitioner和combiner（下图摘自互联网）

　　在了解基本的MapReduce的宏观框架之后，我们可以结合上图来了解MapReduce的微观框架：

　　　　a>.Combiner是MapReduce的一种优化机制，它的主要功能是在“shuffle and sort”之前先在本地将中间键值对进行聚合，以减少在网络上发送的中间键值对数据量。因此可以把combiner视作在“shuffle and sort”阶段之前对mapper的输出结果所进行聚合操作的“mini-reducer”。在实现中，各combiner之间的操作是隔离的，因此，它不会涉及到其它mapper的数据结果。需要注意的是，就算是某combiner可以有机会处理某键相关的所有中间数据，也不能将其视作reducer的替代品，因为combiner输出的键值对类型必须要与mapper输出的键值对类型相同。无论如何，combiner的恰当应用将有机会有效提高作业的性能。简单的来说，combiner的主要作用就是在各mapper程序执行完毕之后，可以将相同的key进行本地合并，这样就可以避免本地的同一个key进行多次发送的情况，从而达到节省网络带宽的目的（从上图可知，combiner只能做简单的合并操作，并不能实现折叠的功能，它的读入和输出的数据类型都是一致的）；

　　　　b>.Partitioner负责分割中间键值对数据的键空间(即前面所谓的“分组”)，并将中间分割后的中间键值对发往对应的reducer，也即partitioner负责完成为一个中间键值对指派一个reducer。最简单的partitioner实现是将键的hash码对reducer进行取余计算，并将其发往余数对应编号的reducer，这可以尽力保证每个reducer得到的键值对数目大体上是相同的。不过，由于partitioner仅考虑键而不考虑“值”，因此，发往每个reducer的键值对在键数目上的近似未必意味着数据量的近似。简单的来说，partitioner的主要作用就是将各mapper输出的键值对在“shuffle & sort”完成之后，将不同的键值对进行分离操作，将分离后的同一个键值对发送同一个reducer的作用，partitioner也是可以程序员自己开发的，简单的来说，partitioner就是传输功能；

　　　　c>.partiontioner和combiner只是MapReduce的两个组件，combiner和partitioner并不一定要存在，如果没有它们的话，他们的任务都会被堆积到reduce，让reduce执行combiner和partitioner的操作。

8>.Hadoop的小缺陷

　　各位要注意的是，有些任务非常复杂，它可能需要N轮的MapReduce处理，即第一轮MapReduce处理的结果会调用第二次MapReduce，第二次的MapReduce结果继续调用第三次的MapReduce等等，只不过每一轮所需要运行的程序可能各不一样。比如分析淘宝网站的日志，分析出来自哪个区域访问量最大，统计出北京，上海，深圳，西安，天津的访问量。如果每轮MapReduce处理结果需要等待两天时间，那么要把整个任务执行完毕估计就一个星期之后了，这个分析的结果并不是实时的，就无法提供有效的数据支持了。这也是Hadoop为人诟病的主要原因。

　　Hadoop还有一个缺陷，HDFS设计用来存储单个大文件的，但事实上很多时候很多的数据都是很短小的数据信息，比如我们想把日志信息实时的收集过来，若我们有100多万台服务器，每一万台服务器产生一行日志，此时每一行的数据你有打算怎么存储呢？因此，Hadoop仅适用于存储批量的，单个大文件，HDFS仅适于处理流式数据，不支持随机模式的数据访问，如果想要存储类似于数据库中存的一行短小的数据信息的话（或者是随机性数据），HDFS就特别的不适用。这个时候HBase就出现了。

六.Yarn(资源管理系统)

　　Yarn是Hadoop2.0新增的系统，负责集群的资源管理和调度，使得多种计算框架可以运行在一个集群中。Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

　　详情请参考：https://baike.baidu.com/item/yarn

七.HBase

1>.什么是HBase
　　我们知道HDFS很难实现随机数据处理的，因此我们要引入HBase。它也是一个HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。
　　HBase可以单机运行，但是它的冗余能力就没法保证了，因此HBase最好的工作方式还是在Hadoop集群上工作。
2>.HBase的组成

　　a>.Master
　　　　我们知道HBase也是一个分布式系统，这个分布式系统也是有个主从节点组成的，只不过它的主节点叫做HMaster，它的从节点叫做HRegionServers。我们一般把HMaster简写为Master，它是用来做请求调度的。换句话说，Master是协调各个RegionServers工作过程的，比方说，我们写一个数据时，应该发往哪个RegionServers的那个位置进行存储等；

　　　　Master想要研发协调多个RegionServers过程的话会比较困难，因此Master借助一个现有的项目叫ZooKeeper来完成各RegionServers的协调。简单的来说，如果某个RegionServer宕机时，那么此前的RegionServer保存的数据应该其它那些HRegionServers中重新构建出来呢？这就是由ZooKeeper来协调完成的。
　　b>.RegionServers
　　　　HRegionServers是用来真正存取的服务器。
　　c>.ZooKeeper
　　　　在通过一组服务器向客户端提供服务的场景中，需要客户端能定位各服务器以便使用其提供的服务。然而这面临的挑战之一便是如何维持这个服务器列表——其显然不能放置于网络中的某单个节点上，否则此节点故障将导致整个系统不可用。即便我们有办法保证存储此服务器列表的节点不会出现故障，但当列表中的某服务器故障时将其移出列表仍然会是个问题，故障的服务器无法自行退出列表，因此这需要外部的一组处理动作来完成。Zookeeper正是设计用来提供这种服务。
　　　　可以把Zookeeper想像成为一个提供高可用功能的文件系统，它没有文件或目录，而用znode来统一实现目录及文件的功能，它既可以存储数据，又可以包含其它的znode。所有的znodes组成一个层次性的名称空间，父节点的名称为某服务器组的名称，其子节点的名称为此组中的各服务器名称。

当然，ZooKeeper还有着诸多优点：
1、简洁：ZooKeeper的核心是一个精简的文件系统，它仅提供了几个简单操作和一些额外的抽像机制如排序和通知等功能； 　　

2、富于表现力：ZooKeeper的本体是一组丰富的可用于构建大规模协作式数据结构和协议的代码块，这包括分布式队列、分布式锁以及在一组节点中推举主导节点等； 　　

3、高可用：ZooKeeper运行于一组主机，设计人员在对其进行设计时就充分考虑到节点故障的可能性并由此给系统带来的问题，由此为其添加了高可用能力； 　　

4、松耦合的交互性：ZooKeeper的交互式并不要求协作方事先互相知悉彼此的存在，甚至也不要求各协作方预先进行同步； 　　

5、开源：ZooKeeper是一个开源项目； 　　

6、高性能

3>.HBase特性：
　　a>.线性及模块可扩展性;
　　b>.严格一致性读写;
　　c>.可配置表的自动切分策略;
　　d>.RegionServer自动故障恢复;
　　e>.便利的API;
　　f>.实时查询缓存;

八.Hive

1>.什么是Hive

　　HDFS的访问接口只有一个，即MapReduce编程接口，要想对HDFS系统中的数据进行处理，程序员就只能编程了，好在MapReduce可以支持多种API了，比如Python，shell等等，只不过没有Java的速度更快而已（因为Hadoop整个生态圈都是用Java语言实现的，如果你用其它的语言进行交互，必然会存在一个翻译的过程，而这个翻译过程自然而然是需要占用一定时间的！）因此我们如果真的想要对MapReduce进行研发，最好还是以Java编程语言为主。但是不能让所有使用Hadoop软件的IT人员都成为程序员，这个时候Facebook就在Hadoop的基础之上，给他引入了一个新的使用接口，即Hive。

　　hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。 其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。简单的来说，Hive就是把MapReduce的API给封装成了类似与关系型数据库的SQL接口，它里面支持类似与SQL语法的insert，delete，update，select等操作。我们可以把Hive编写的SQL语句称为Hive查询语言，简称HQL。因此，我们根据Hive的HQL编写的语句之后，Hive内部会负责实现将SQL语句转移成MapReduce作业。

　　由于Hadoop是批处理的，可能我们填写的HQL语句转移成MapReduce作业后，可能过了半小时仍然没有返回结果，因此Hive查询的结果不想SQL查询是实时的，当然，究其根本原因并不在于Hive，而是Hadoop的锅，但好在是Hive给总算给我们提供了一个简单的接口，不是吗？

2>.Hive的适用场景

　　Hive 构建在基于静态批处理的Hadoop 之上，Hadoop 通常都有较高的延迟并且在作业提交和调度的时候需要大量的开销。因此，Hive 并不能够在大规模数据集上实现低延迟快速的查询，例如，Hive 在几百MB 的数据集上执行查询一般有分钟级的时间延迟。因此，

　　Hive 并不适合那些需要低延迟的应用，例如，联机事务处理（OLTP）。Hive 查询操作过程严格遵守Hadoop MapReduce 的作业执行模型，Hive 将用户的HiveQL 语句通过解释器转换为MapReduce 作业提交到Hadoop 集群上，Hadoop 监控作业执行过程，然后返回作业执行结果给用户。Hive 并非为联机事务处理而设计，Hive 并不提供实时的查询和基于行级的数据更新操作。Hive 的最佳使用场合是大数据集的批处理作业，例如，网络日志分析。

　　鉴于Hive本身的限制，如果期望在大数据集上实现OLTP式的特性，就得认真考虑NoSQL数据库了，比如HBase、Cassandra和DynamoDB等。

3>.Hive的特性

　　a>.支持索引，加快数据查询。

　　b>.不同的存储类型，例如，纯文本文件、HBase 中的文件。

　　c>.将元数据保存在关系数据库中，大大减少了在查询过程中执行语义检查的时间。

　　d>.可以直接使用存储在Hadoop 文件系统中的数据。

　　e>.内置大量用户函数UDF 来操作时间、字符串和其他的数据挖掘工具，支持用户扩展UDF 函数来完成内置函数无法实现的操作。

　　f>.类SQL 的查询方式，将SQL 查询转换为MapReduce 的job 在Hadoop集群上执行。

九.pig

　从某种意义上来讲，Hive是基于Hadoop文件系统之上数据仓库的工具，它为数据仓库的管理提供了诸多功能来完成数据的ETL工具（收集数据，转换数据，加载数据），同时又是数据存储管理和大型数据集查询和分析的工具。不过，Hive仅仅是其众多实现方案中的一个，因为Hive的接口是类似于SQL接口的，但是这种接口本身是否好用，如果你之前学过SQL语句的话，想要使用Hive并不是一件难事，如果之前没有学习过SQL编程语言的话，比如你只学习过脚本编程语言并不会SQL语言，对于这一类的用户雅虎又研发了另外一个项目叫做"pig"。

　　Pig是一种数据流语言和运行环境，用于检索非常大的数据集。为大型数据集的处理提供了一个更高层次的抽象。Pig包括两部分：一是用于描述数据流的语言，称为Pig Latin；二是用于运行Pig Latin程序的执行环境。

　　Apache Pig 是一个高级过程语言，适合于使用 Hadoop 和 MapReduce 平台来查询大型半结构化数据集。通过允许对分布式数据集进行类似 SQL 的查询，Pig 可以简化 Hadoop 的使用。 [1]
　　用MapReduce进行数据分析。当业务比较复杂的时候，使用MapReduce将会是一个很复杂的事情，比如你需要对数据进行很多预处理或转换，以便能够适应MapReduce的处理模式。另一方面，编写MapReduce程序，发布及运行作业都将是一个比较耗时的事情。Pig的出现很好的弥补了这一不足。Pig能够让你专心于数据及业务本身，而不是纠结于数据的格式转换以及MapReduce程序的编写。本质是上来说，当你使用Pig进行处理时，Pig本身会在后台生成一系列的MapReduce操作来执行任务，但是这个过程对用户来说是透明的。 [2]
　　Pig相比Hive到底哪个更好，我们无从而知，不过两种实现方式都得去花费时间和精力学习，因为Pig毕竟不是脚本，Hive毕竟不是SQL语句。选择适合你用的就好。我在网上找到了Pig和Hive的比较如下图所示：

十.日志收集工具
　　目前为止，Hadoop的一个主流应用就是对于大规模web日志的分析和处理，因此想要把web服务的日志导入到Hadoop来进行分析就得借助日志收集工具了。目前主流的Hadoop日志收集工具能够跟Hadoop进行交接的有三个工具，即flume，scribe和chukwa。
1>.flume
　　Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。
　　当前Flume有两个版本Flume 0.9X版本的统称Flume-og，Flume1.X版本的统称Flume-ng。由于Flume-ng经过重大重构，与Flume-og有很大不同，使用时请注意区分。
　　Flume最早是Cloudera提供的日志收集系统，目前是Apache下的一个孵化项目，Flume支持在日志系统中定制各类数据发送方，用于收集数据。详情请参考：http://flume.apache.org/
2>.scribe
　　Scribe是Facebook开源的日志收集系统，在Facebook内部已经得到的应用。它能够从各种日志源上收集日志，存储到一个中央存储系统（可以是NFS，分布式文件系统等）上，以便于进行集中统计分析处理。
3>.chukwa
　　Apache 的开源项目 hadoop， 作为一个分布式存储和计算系统，已经被业界广泛应用。很多大型企业都有了各自基于 hadoop 的应用和相关扩展。当 1000+ 以上个节点的 hadoop 集群变得常见时，集群自身的相关信息如何收集和分析呢？针对这个问题， Apache 同样提出了相应的解决方案，那就是 chukwa。
　　chukwa 的官方网站是这样描述自己的： chukwa 是一个开源的用于监控大型分布式系统的数据收集系统。这是构建在 hadoop 的 hdfs 和 map/reduce 框架之上的，继承了 hadoop 的可伸缩性和健壮性。　Chukwa 还包含了一个强大和灵活的工具集，可用于展示、监控和分析已收集的数据。 在一些网站上，甚至声称 chukwa 是一个“日志处理/分析的full stack solution”。 说了这么多，你心动了吗？详情请参考：http://chukwa.apache.org/

十一.数据导入HDFS的工具
　　Sqoop(发音：skup)是一款开源的工具，主要用于在Hadoop(Hive)与传统的数据库(mysql、postgresql...)间进行数据的传递，可以将一个关系型数据库（例如 ： MySQL ,Oracle ,Postgres等）中的数据导进到Hadoop的HDFS中，也可以将HDFS的数据导进到关系型数据库中。
　　Sqoop项目开始于2009年，最早是作为Hadoop的一个第三方模块存在，后来为了让使用者能够快速部署，也为了让开发人员能够更快速的迭代开发，Sqoop独立成为一个Apache项目。详情请参考：http://sqoop.apache.org/

十二.Mahout
Mahout 是 Apache Software Foundation（ASF） 旗下的一个开源项目，提供一些可扩展的机器学习领域经典算法的实现，旨在帮助开发人员更加方便快捷地创建智能应用程序。Mahout包含许多实现，包括聚类、分类、推荐过滤、频繁子项挖掘。此外，通过使用 Apache Hadoop 库，Mahout 可以有效地扩展到云中。详情请参考：https://www.ibm.com/developerworks/cn/java/j-mahout/

十三.Hadoop生态圈

2) Nutch，互联网数据及Nutch搜索引擎应用
3) HDFS,Hadoop的分布式文件系统
5) MapReduce,分布式计算框架
6) Flume、Scribe，Chukwa数据收集，收集非结构化数据的工具。
7） Hiho、Sqoop,讲关系数据库中的数据导入HDFS的工具
8） Hive数据仓库，pig分析数据的工具
10）Oozie作业流调度引擎
11）Hue，Hadoop自己的监控管理工具
12）Avro 数据序列化工具
13）mahout数据挖掘工具
14)Hbase分布式的面向列的开源数据库