Hadoop生态体系常用组件概述（一）

存储类组件

HBase

1. HBase的概念

HBase是一个高可靠性、高性能、面向列、可伸缩、实时读写、多版本的分布式开源非关系型数据库，主要用来存储非结构化和半结构化的松散数据。
HBase利用Hadoop HDFS作为其文件存储系统，利用Hadoop MapReduce来处理HBase中的海量数据，利用Zookeeper作为其分布式协同服务。

2. HBase的特点

1）HBase存储Key-Value格式的数据。
2）HBase底层为字节数据，没有数据类型一说。
3）支持RegionServer之间的自动故障转移。
4）可以支持QPS、PB级别的存储。

3. HBase的应用场景

1）对象存储：我们知道不少的头条类、新闻类的的新闻、网页、图片存储在HBase之中，一些病毒公司的病
毒库也是存储在HBase之中。
2）时序数据：HBase之上有OpenTSDB模块，可以满足时序类场景的需求。
3）推荐画像：特别是用户的画像，是一个比较大的稀疏矩阵，蚂蚁的风控就是构建在HBase之上。
4）时空数据：主要是轨迹、气象网格之类，滴滴打车的轨迹数据主要存在HBase之中，另外在技术所有大一
点的数据量的车联网企业，数据都是存在HBase之中。
5）CubeDB OLAP：Kylin一个cube分析工具，底层的数据就是存储在HBase之中，不少客户自己基于离线计
算构建cube存储在hbase之中，满足在线报表查询的需求。
6）消息/订单：在电信领域、银行领域，不少的订单查询底层的存储，另外不少通信、消息同步的应用构建在
HBase之上。
7）Feeds流：典型的应用就是xx朋友圈类似的应用。
8）NewSQL：之上有Phoenix的插件，可以满足二级索引、SQL的需求，对接传统数据需要SQL非事务的需
求。

4. HBase的原理

1）HMaster
负责管理HBase的元数据，表结构，表的Region信息。
负责表的创建，删除和修改。
负责为RegionServer分配Region，分配后将元数据写入相应位置。
负责RegionServer的负载均衡。
发现失效的RegionServer并重新分配到其他RegionServer工作。
2）HRegionServer
含有多个HRegion。
处理Client端的读写请求（根据从HMaster返回的元数据找到对应的HRegionServer）。
管理Region的Split分裂、StoreFile的Compaction合并。
3）HRegion
一个HRegion里可能有1个或多个Store。
HRegionServer维护一个HLog。
HRegion是分布式存储和负载的最小单元。
表通常被保存在多个HRegionServer的多个Region中。
每个表一开始只有一个region，随着数据量不断增加，region增大，当达到一个阈值时，region就会被regionServer水平切分成两个新的region，当region很多时，将会保存到其他regionServer上。
4）Store
Store是存储落盘的最小单元，由内存中的MemStore和磁盘中的若干StoreFile组成。
一个Store里有1个或多个StoreFile和一个memStore。
每个Store存储一个列族。
5）MemStore
内存缓存区,数据的写操作会先写到memstore中，当memstore中的数增长到一个阈值后，regionServer会
启动flashcatch进程写入到storeFile中，每次写入形成一个单独的storeFile。
6）StoreFile
当storeFile数量增长到一定阈值后，系统会进行合并(minor major compaction)，合并过程会进行版本的合并和删除工作，形成更大的storeFile。
当一个region所有的storeFile大小和数量增长到超过一定阈值后，会把当前region分割为两个，并且由master分配到相应的eregionServer服务器，实现负载均衡。
客户端检索数据时，先在memStore中找，找不到再到storeFile中找。
7）Hfile
和StoreFile是同一个东西，只不过是站在HDFS角度称这个文件为Hfile，在Hbase角度就叫StoreFile。
8）HLog
是一个普通的Hadoop SequenceFile，记录数据以及数据的操作，目的是用来做数据容灾。

Hive

1. Hive的概念

Hive是基于Hadoop的一个数据仓库工具，可以存储、查询和分析存储在Hadoop中的大规模数据。

2. Hive的特点

1）在0.14版本之前，Hive提供静态数据的动态查询，不支持更改数据的操作；从Hive 0.14开始，已将INSERT … VALUES，UPDATE和 DELETE添加到SQL语法中。
2）Hive能够将结构化的数据文件映射为一张数据库表，提供SQL查询功能，底层经过编译将SQL语句转变成
MapReduce程序来执行。
3）在Hadoop上运行，数据存储在HDFS上。

3. Hive的应用场景

1）日志分析。
2）海量结构化数据离线分析。
3）不适合需要低延迟的应用。
4）不提供实时查询。
5）不提供基于行级的数据更新操作（hive0.14版本之前）。

HDFS

1. HDFS的概念

HDFS是一个高容错性的分布式文件系统，提供高吞吐量的数据访问。

2. HDFS的特点

1）HDFS采用了主从（Master/Slave）结构模型，一个HDFS集群是由一个NameNode和若干个DataNode组
成的。其中NameNode作为主服务器，管理文件系统的命名空间和客户端对文件的访问操作；集群中的
DataNode管理存储的数据。
2）HDFS通过统一的命名空间目录树来定位文件。
3）HDFS中的文件在物理上是分块存储的，块的大小可以通过配置参数来规定，默认大小在hadoop2.x版本
中是128M。

3. HDFS的优缺点

优点
1）HDFS具有高容错性，数据自动保存多个副本，副本丢失后，自动恢复。
2）适合批处理，移动计算而非数据，数据位置暴露给计算框架。
3）适合大数据处理，GB、TB、甚至PB级数据，百万规模以上的文件数量，10k+节点规模。
4）流式文件访问，一次性写入，多次读取，保证数据一致性。
5）可构建在廉价机器上，通过多副本提高可靠性，提供了容错和恢复机制。
缺点
1）不能做到低延迟数据访问，由于hadoop针对高吞吐率做了优化，牺牲了获取数据的延迟，所以Hadoop不
适合低延迟数据访问需求，相比而言，HBase对于低延迟数据访问是一个更好的选择。
2）不适合大量的小文件存储，由于namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储
的文件总数受限于namenode的内存容量，HDFS中每个文件、目录、数据块占用150Bytes，如果存放
1billion的文件数目会超出硬件能力。
3）不支持用户的并行写，同一时间内，只能有一个用户执行写操作。
4）对于上传到HDFS上的文件，不支持修改文件。Hadoop2.0虽然支持了文件的追加功能，但还是不建议对
HDFS上的文件进行修改，因为效率低下。HDFS适合一次写入，多次读取的场景。

4. HDFS的应用场景

1）适合带有大型数据集的应用程序。
2）适合高吞吐率，不适合低延迟的访问需求。
3）适合一次写入，多次读取的应用场景。
4）基于流式读取方式，不适合多用户写入一个文件，以及任意位置写入。

4. HDFS的工作机制

1）写操作



2）写原理

例：将一个名为“example.txt”，大小为248M的文件写入HDFS。
假设block.size被设置为128M，因此client会把该文件切分成两个block，分别是128M和120M。
当向HDFS写数据的时候，遵循下面几个流程：

• HDFS client向NameNode发送两个blocks的写入请求；

• NameNode给client进行写入授权并提供用来进行存储和复制的DataNodes IP;

• DataNodes基于HDFS可用性、复制因子和机架感知的选择是完全随机的；

• 假设复制因子是3，那么NameNode将为每个blocks提供3个DataNodes IP，相对每个block提供的三个
  DataNodes都是唯一的；

• 每个block将在三个不同的DataNode进行复制；

• 建立管道、数据流与复制、管道关闭及确认。

  建立管道图解如下所示：
  
  上图大概有以下几个步骤：

• client 拿着 blockA 向 NameNode发起写请求；

• NameNode返回一组可供存储和复制的DN IP列表；

• client向 DN1 进行写入准备确认，同时会告诉DN1接下来要进行复制的DN4和DN6的IP；

• DN1 会向 DN4发起写入准备确认，依次类推DN4给DN6发送确认；

• DN6 确认完毕回传给 DN4，DN4确认后会将自己以及DN6的确认信息给DN1，最后DN1将三个DN的确认结
  果答复给client；

• 管道建立完毕，client将开始进行数据复制或者数据处理。

  数据流与复制图解如下图所示：
  
  上图大致有以下几个步骤：

• client 将blockA写入DN1，接着DN1连接DN4；

• DN1通过管道向DN4复制数据；

• DN4数据写完后会继续连接DN6进行最后一份数据的复制。

  管道关闭和确认图解如下图所示：
  
  上图大致流程为：

• DN6写入成功后会给DN4发送确认消息；

• 接着DN4会将DN6和自己的确认消息发送给DN1；

• 最后DN1将所有的确认消息发送给client；

• client再给NameNode确认block写入成功；

• 然后NameNode更新对应的元数据；

• 最终client关闭管道。

3）读操作

4）读原理

上图大致分为以下几个步骤：

• client请求NameNode 要读取example.txt的数据，NameNode查询元数据，将该文件对应的所有block及对
  应的DataNode列表返回；
• client并行的分别从DataNodes读取blockA和blockB的数据。为了保证低延迟和节约带宽，通常会选择离
  client近的副本进行读取，如果可能，会选择和阅读节点在同一个机架上的副本（如图中所示，选择了
  Rack1, blockA和blockB都有对应的副本）；
• client一旦获取到所有的block，就会开始组装成文件，并返回。

5）HDFS常见错误及故障处理

节点故障

通信故障和数据损坏

读写故障

数据节点故障

复制位置的选择策略

参考文章
https://www.jianshu.com/p/8b4dc5a154e5