Hadoop中HBase工作的简要概述
1.引言
HBase是一种高可靠性，高性能，面向列的可扩展分布式存储系统，它使用HBase技术在廉价的PC服务器上构建大规模结构化存储集群。 HBase的目标是存储和处理大量数据，特别是仅使用标准硬件配置即可处理包含数千行和列的大量数据。
与MapReduce的离线批量计算框架不同，HBase是随机访问存储和检索数据平台，弥补了HDFS无法随机访问数据的缺点。
它适用于实时性要求不高的业务场景-HBase存储Byte数组，该数组不介意数据类型，从而允许动态，灵活的数据模型。
> Hadoop Ecosystem (Credit: Edureka.com)
上图描绘了Hadoop 2.0生态系统的各个层-位于结构化存储层上的Hbase。
HDFS为HBase提供了高可靠性的低级存储支持。
MapReduce为HBase提供了高性能的批处理功能。 ZooKeeper为HBase提供稳定的服务和故障转移机制。 Pig和Hive为数据统计处理的高级语言支持提供了HBase，Sqoop为HDB提供了可用的RDBMS数据导入功能，这使得从传统数据库到HBase的业务数据迁移非常方便。
2. HBase架构
2.1设计Idea
HBase是一个分布式数据库，使用ZooKeeper来管理群集和HDFS作为基础存储。
在体系结构级别，它由HMaster(由Zookeeper选择的领导者)和多个HRegionServers组成。
下图显示了基础架构：
在HBase的概念中，HRegionServer对应于群集中的一个节点，一个HRegionServer负责管理多个HRegion，一个HRegion代表表数据的一部分。
在HBase中，一个表可能需要很多HRegion来存储数据，并且每个HRegion中的数据都不会杂乱无章。
当HBase管理HRegion时，它将为每个HRegion定义一定范围的Rowkey。 属于定义范围的数据将被移交给特定区域，从而将负载分配给多个节点，从而利用分布和特性的优势。
同样，HBase将自动调整区域的位置。 如果HRegionServer过热，即大量请求落在HRegionServer管理的HRegion上，则HBase会将HRegion移动到相对空闲的其他节点，以确保充分利用群集环境。
2.2基本架构
HBase由HMaster和HRegionServer组成，并且遵循主从服务器体系结构。 HBase将逻辑表分为多个数据块HRegion，并将它们存储在HRegionServer中。
HMaster负责管理所有HRegionServer。 它本身不存储任何数据，而仅存储数据到HRegionServer的映射(元数据)。
群集中的所有节点均由Zookeeper协调，并处理HBase操作期间可能遇到的各种问题。 HBase的基本架构如下所示：
客户端：使用HBase的RPC机制与HMaster和HRegionServer通信，提交请求并获得结果。 对于管理操作，客户端使用HMaster执行RPC。 对于数据读取和写入操作，客户端使用HRegionServer执行RPC。
Zookeeper：通过将集群中每个节点的状态信息注册到ZooKeeper，HMaster可以随时感知每个HRegionServer的健康状态，还可以避免HMaster的单点故障。
HMaster：管理所有HRegionServer，告诉他们需要维护哪些HRegion，并监视所有HRegionServer的运行状况。 当新的HRegionServer登录到HMaster时，HMaster告诉它等待数据分配。 当HRegion死亡时，HMaster将其负责的所有HRegion标记为未分配，然后将它们分配给其他HRegionServer。 HMaster没有单点问题。 HBase可以启动多个HMaster。 通过Zookeeper的选举机制，群集中始终有一个HMaster运行，从而提高了群集的可用性。
HRegion：当表的大小超过预设值时，HBase会自动将表划分为不同的区域，每个区域都包含表中所有行的子集。 对于用户来说，每个表都是数据的集合，用主键(RowKey)加以区分。 从物理上讲，一个表分为多个块，每个块都是一个HRegion。 我们使用表名+开始/结束主键来区分每个HRegion。 一个HRegion会将一段连续数据保存在一个表中。 完整的表数据存储在多个HRegions中。
HRegionServer：HBase中的所有数据通常从底层存储在HDFS中。 用户可以通过一系列HRegionServer获得此数据。 通常，群集的一个节点上仅运行一台HRegionServer，并且每个段的HRegion仅由一个HRegionServer维护。 HRegionServer主要负责响应用户I / O请求将数据读取和写入HDFS文件系统。 它是HBase中的核心模块。 HRegionServer在内部管理一系列HRegion对象，每个HRegion对应于逻辑表中的连续数据段。 HRegion由多个HStore组成。 每个HStore对应于逻辑表中一个列族的存储。 可以看出，每个列族都是一个集中式存储单元。 因此，为了提高操作效率，最好将具有共同I / O特性的列放在一个列系列中。
HStore：它是HBase存储的核心，它由MemStore和StoreFiles组成。 MemStore是内存缓冲区。用户写入的数据将首先放入MemStore。当MemStore已满时，Flush将是一个StoreFile(底层实现是HFile)。当StoreFile文件的数量增加到某个阈值时，将触发Compact合并操作，将多个StoreFile合并为一个StoreFile，并在合并过程中执行版本合并和数据删除操作。因此，可以看出，HBase仅添加数据，并且所有更新和删除操作都在后续的Compact进程中执行，因此用户的写入操作可以在其进入内存后立即返回，从而确保HBaseI /哦当StoreFiles Compact时，它将逐渐形成越来越大的StoreFile。当单个StoreFile的大小超过某个阈值时，将触发分割操作。同时，当前的HRegion将被拆分为2个HRegion，并且父HRegion将脱机。 HMaster将这两个子HRegion分配给相应的HRegionServer，以便将原始HRegion的负载压力分流到这两个HRegion。
HLog：每个HRegionServer都有一个HLog对象，该对象是实现预写日志的预写日志类。 每次用户将数据写入MemStore时，它还将数据的副本写入HLog文件。 定期滚动和删除HLog文件，并删除旧文件(已保存到StoreFile的数据)。 当HMaster检测到HRegionServer被Zookeeper意外终止时，HMaster首先处理旧版HLog文件，分割不同HRegion的HLog数据，将它们放入相应的HRegion目录中，然后重新分发无效的HRegion。 在加载HRegion的过程中，这些HRegion的HRegionServer将发现需要处理HLog的历史记录，因此将Replay HLog中的数据传输到MemStore，然后刷新到StoreFiles以完成数据恢复。
2.3 根和元
HBase的所有HRegion元数据都存储在.META中。 表。 随着HRegion的增加，.META表中的数据也增加并分裂为多个新的HRegion。
为了找到.META表中每个HRegion的位置，将表中.META表中所有HRegion的元数据存储在-ROOT-table中，最后，Zookeeper记录ROOT表的位置信息。
在所有客户端访问用户数据之前，他们需要首先访问Zookeeper以获取-ROOT-的位置，然后访问-ROOT-table以获取.META表的位置，最后根据以下信息确定用户数据的位置： META表中的信息，如下所示：该图显示。
-ROOT表永远不会拆分。 它只有一个HRegion，这可以确保只需三个跳转就可以定位任何HRegion。 为了加快访问速度，.META表的所有区域都保留在内存中。
客户端缓存查询的位置信息，并且缓存不会主动失败。 如果客户端仍然无法基于缓存的信息访问数据，则请相关.META表的Region服务器尝试获取数据的位置。 如果仍然失败，请询问与-ROOT-table关联的.META表在哪里。
最后，如果先前的信息全部无效，则Zookeeper将HRegion的数据重定位。 因此，如果客户端上的缓存完全无效，则需要来回六次以获取正确的HRegion。
3. HBase数据模型
HBase是类似于BigTable的分布式数据库。 它是稀疏的长期存储(在HDFS上)，多维和排序的映射表。 该表的索引是行关键字，列关键字和时间戳。 HBase数据是字符串，没有类型。
将表视为大型映射。 您可以按行键，行键+时间戳或行键+列(列族：列修饰符)查找特定数据。 由于HBase稀疏地存储数据，因此某些列可以为空。 上表给出了com.cnn.www网站的逻辑存储逻辑视图。 表中只有一行数据。
该行的唯一标识符是" com.cnn.www"，并且此数据行的每次逻辑修改都有一定的时间。 标记对应于。
该表中有四列：内容：HTML，anchor：cnnsi.com，anchor：my.look.ca，mime：type，每个列都给出了它所属的列族。
行键(RowKey)是表中数据行的唯一标识符，并用作检索记录的主键。
在HBase中，只有三种方法可以访问表中的行：通过行键进行访问，给定行键的范围访问以及全表扫描。
行键可以是任何字符串(最大长度为64KB)，并按字典顺序存储。 对于经常一起读取的行，需要仔细设计基本值，以便可以将它们一起存储。
4. HBase读写过程
下图是HRegionServer数据存储关系图。 如上所述，HBase使用MemStore和StoreFile将更新存储到表中。 数据在更新后首先写入HLog和MemStore。 MemStore中的数据已排序。
当MemStore累积到某个阈值时，将创建一个新的MemStore，并将旧的MemStore添加到Flush队列中，并将一个单独的线程刷新到磁盘上以成为StoreFile。 同时，系统将在Zookeeper中记录一个CheckPoint，表明该时间之前的数据更改已保留。 当发生意外系统时，MemStore中的数据可能会丢失。
在这种情况下，HLog用于在CheckPoint之后恢复数据。
StoreFile是只读的，一旦创建便无法修改。 因此，HBase的更新是一项附加操作。 当商店中的StoreFile达到某个阈值时，将执行合并操作，并且将相同密钥的修改合并以形成一个大型StoreFile。 当StoreFile的大小达到某个阈值时，StoreFile被拆分并分为两个StoreFiles。
4.1写操作流程
- 步骤1：客户端通过Zookeeper的调度向HRegionServer发送写数据请求，并将数据写入HRegion。
- 步骤2：将数据写入HRegion的MemStore，直到MemStore达到预设阈值。
- 步骤3：MemStore中的数据被整理到StoreFile中。
- 步骤4：随着StoreFile文件数量的增加，当StoreFile文件数量增加到特定阈值时，将执行Compact合并操作，并将多个StoreFiles合并到一个StoreFile中，并在版本库中执行版本合并和数据删除。 同时。
- 步骤5：StoreFiles通过连续的Compact操作逐渐形成越来越大的StoreFile。
- 步骤6：在单个StoreFile的大小超过某个阈值之后，将触发Split操作，将当前的HRegion拆分为两个新的HRegion。 父HRegion将脱机，新的Split的两个子HRegion将由HMaster分配给相应的HRegionServer，以便可以将原始HRegion的压力分流到这两个HRegion。
4.2读取操作流程
- 步骤1：客户端访问Zookeeper，找到-ROOT-table，并获得.META。 表信息。
- 步骤2：从.META中搜索。 表获取目标数据的HRegion信息，找到对应的HRegionServer。
- 步骤3：获取需要通过HRegionServer查找的数据。
- 步骤4：HRegionserver的内存分为两部分：MemStore和BlockCache。 MemStore主要用于写入数据，而BlockCache主要用于读取数据。 首先将请求读取到MemStore以检查数据，检查BlockCache检查，然后检查StoreFile，然后将读取结果放入BlockCache。
5. HBase使用场景
半结构化或非结构化数据：对于没有很好定义或混乱的数据结构字段，很难根据适用于HBase的概念来提取数据。 如果随着业务增长存储更多字段，则需要关闭RDBMS来维护更改表结构，并且HBase支持动态添加。
记录非常稀疏：RDBMS行的多少列是固定的，而空列则浪费存储空间。 HBase为空的列不会存储，这样可以节省空间并提高读取性能。
多版本数据：根据RowKey和列标识符定位的值可以具有任意数量的版本值(时间戳是不同的)，因此将HBase用于需要存储更改历史记录的数据非常方便 。
大量数据：当数据量越来越大时，RDBMS数据库将无法承受，并且存在读写分离策略。 通过一个主机，它负责写操作，而多个从机则负责读取操作，服务器成本增加了一倍。 随着压力的增加，船长无法承受压力。 此时，将对库进行划分，并且将几乎不相关的数据分别部署。 某些联接查询无法使用，并且需要使用中间层。 随着数据量的进一步增加，表的记录变得越来越大，查询变得非常慢。
因此，有必要例如通过对ID进行模化将表划分为多个表，以减少单个表的记录数。 经历过这些事情的人都知道如何抛弃这个过程。
HBase很简单，只需将新节点添加到群集，HBase就会自动水平拆分，并且与Hadoop的无缝集成可确保数据可靠性(HDFS)和高性能的海量数据分析(MapReduce)。
6. HBase Map Reduce
HBase中的Table与Region之间的关系与HDFS中的File与Block之间的关系有些相似。 由于HBase提供了与MapReduce进行交互的API，例如TableInputFormat和TableOutputFormat，因此HBase数据表可以直接用作Hadoop MapReduce的输入和输出，这有利于MapReduce应用程序的开发，并且不需要注意HBase的处理。 系统本身的详细信息。
如果您喜欢这个主题，可以看看我写下的有关Hadoop的其他几个主题。 如果您发现任何错误或有任何建议，请随时通过我的LinkedIn与我联系。
