Hbase的 原理、设计及实现

大数据技术如火如荼。在大数据挖掘和分析平台技术中，NoSQL技术作为海量数据操作和高客户端并发解决方案，尤其是Hbase，首当其冲，广泛应用于许多项目，但缺乏Hbase表设计模式/IO考虑/性能调优等实践经验数据。本文介绍了Hbase数据模型的原理，分析了Hbase表扫描/查询操作的时间复杂性，分析了Hbase表设计和开发在实际案例中的应用，比较了不同Hbase设计考虑客户端访问模式和检索性能的差异。通过案例中Hbase表的设计模式，读者可以更深入地了解Hbase的原理和设计，熟悉Hbase客户端开发的思路和实现。传统的关系数据库处理方法是基于全面的ACID保证，遵循SQL92的标准表设计模式（范式）和数据类型，以及基于SQL语言的DML数据交互模式。长期以来，这种基于关系数据库的IT信息化建设发展良好，但由于关系数据库提供的数据模型，关系数据库不能很好地为逐渐出现的模型定义数据集。越来越多的业务系统需要能够适应不同类型的数据格式和数据源，通常是非结构化或半结构化的（如用户访问网站的日志），这需要系统处理几个数量级数据（通常是TB和PB），高于传统的关系数据库。传统的关系数据库可以纵向扩展到一定程度(如OracleRAC、IBMpureScale）。但这通常意味着软件许可成本高，应用逻辑复杂。基于系统需求的巨大变化，数据技术的先驱者不得不重新设计数据库。基于大数据的NoSQL黎明出现了。大数据和NoSQL的使用首先在谷歌中使用、facebook等互联网公司，其次是金融、电信行业，很多Hadoop&NoSQL的开源大数据项目如雨后春笋般涌现，被互联网和其他公司用来处理大量和非结构化的数据。一些项目*快速key-value的键存储，一些*基于文档的内置数据结构或抽象，一些NoSQL数据管理技术框架牺牲当前的数据持久性，不支持严格的ACID，一些开源框架甚至放弃将数据写入硬盘的性能。Hbase是NoSQL的优秀成员，Hbase提供键值API，承诺强烈一致性，因此，客户端在写入后可以立即看到数据。HBase依赖于HBadoop的底层分布式存储机制，因此它可以在多个节点组成的集群上运行，并对客户端应用程序代码透明，使每个开发人员设计和开发HBase大数据项目变得简单易行。Hbase被设计用于处理从TB到PB的数据，并优化了大量数据和高并发访问。作为Hadoop生态系统的一部分，它依赖于Hadoop其他组件提供的重要功能，如Datanode数据冗余和Mapreduce注释处理。本文简要介绍了Hbase的架构和框架。Hbase是一个专门为半结构化数据和水平扩展设计的数据库。在本文中，我们简要介绍了Hbase的架构和框架。Hbase是一个专门为半结构化数据和水平扩展设计的数据库。它将数据存储在表中，并根据四维坐标系组织表中的“行健、列簇、列限定符和时间版本”。Hbase是一个无模式数据库，只需提前定义列簇，不需要指定列限定符。同时，它也是一个无类型的数据库。所有数据都以二进制字节的形式存储。Hbase的操作和访问有五种基本方法，即Gett、Put、Delete、Scan和Increment。基于非行健值查询Hbase的唯一途径就是用过滤器扫描。因为Hbase针对PBBase、TB存储级别、1亿行数据海量表记录高并发性、极限性能查询检索设计初衷，Hbase设计成依靠HadopHDFS的全分布式存储集群，基于Hadop的Mapreduce网格计算框架，支持高吞吐量数据访问、可用性和可靠性，整体结构如下图所示，图1.Hbase的整体架构图从上图中可以看出Hbase的组成部分。Hbase中的每个表按一定范围按行键分为多个子表（HRegion），默认情况下，超过256M的HRegion将被分成两个，由HRegionServer管理，HMaster分配管理哪些HRegion。HRegionServer存取一个子表时，会创建一个HRegion对象，然后对表中的每个列族(ColumnFamily)创建一个Store实例，每个Store将对应0个或多个StoreFile，每个StoreFile将对应一个HFile，HFile是实际存储文件。因此，HRegion有多少列族就有多少Store。因此，一个HRegion有多少列族就有多少Store。此外，每个HRegion还有一个Memstore内存缓存实例。HBase存储格式是基于HDOP的HDFS分布式文件系统，HBase中的所有数据文件都存储在HDOPHDFS上，主要有两种格式:(1)HFile：HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile对HFile进行了轻量级包装，也就是说，StoreFile的底层是HFile。（2）HLogFile：HBase中WAL（WriteAheadLog）物理上，Hadoop的SequenceFile是存储格式。HBase是基于类似谷歌的Bigtable面向列的分布式存储系统，其存储设计是基于Memtable/SStable，主要分为两部分：一部分是内存中的Memstore(Memtable)，另一部分是HDFS上的HFile(SSTable)。还有存储WAL的log，主要实现类为HLog。还有存储WAL的log，主要实现类为HLog。(3)MemStore：Memstore是保存KEY/VALUE映射的MAP，存储在内存中。当Memstore(默认64MB)填写时，flush将开始操作到磁盘(即HADFS上的HDFS)。为了帮助读者理解，这里我们将简要介绍HFile更detail的数据结构。HFile是基于HFile的文件类型，其结构如下图所示:图2.如上图所示，HFile的文件长度变长，只有FILEINFO/Trailer部分是固定长度，Trailer中有指针指向其他数据块的起点。而Index数据块则记录了每个Data块和Meta块的起点。Data块和Meta块是可有可无的，但对于大多数HFile来说，都有Data块。HLog用于存储HBase的日志文件，类似于传统的关系数据库。为了保证读取一致性和undo/redo回滚等数据恢复操作，HBase在写入数据时首先进行write-ahead-log(WAL)操作。每个HRegionserver对应一个HLog实例，HRegionserver将HLog作为构造函数传输到HLog实例进行初始化。HLogFile是SequenceFile，只能在文件末尾添加内容。除文件头外，HLogFile还由HLogle组成.由Entry组成。Entry是HLog的基本组成部分，也是Read/Write的基本单位。如果读者对HBase架构的细节感兴趣，可以通过HBase官网了解HBase的整体架构和底层物理存储机制。由于使用Hbase的目的是高效、高可靠、高并发地访问大量非结构化数据，因此Hbase检索数据的时间复杂性与基于Hbase的业务系统开发设计有关，Hbase的运行速度有多快，本文从计算机算法数学的角度进行了简要的分析，以便读者了解Hbase业务建模和设计模式在后面的项目实例中的考虑因素。Hbase的相关数据信息由以下变量定义：n=KeyValue条目数量(包括Put结果和Delete留下的标记)b=HFile李数据库（HFileBlock）一个HFile中KeyValue条目的平均数量(如果你知道行的大小，可计算得到)c=我们知道Hbase中有两个特殊的表，每行列出的平均数量：-ROOT-&.META.，其中.META.同时，表记录Region分区信息，.META.同时也可以有多个Region分区-ROOT-表又记录.META.但是，表中的Region信息，-ROOT-只有一个Region，而-ROOT-Hbase的集群控制框架，即Zookeeper记录表的位置。关于-ROOT-&.META.这里不再讨论表的细节。感兴趣的读者可以参考Hbasee–ROOT-及.META.表数据，了解HbaseIO和数据检索时序的原理。关于-ROOT-&.META.这里不再讨论表的细节。感兴趣的读者可以参考Hbasee–ROOT-及.META.表数据，了解HbaseIO和数据检索时序原理。Hbase检索数据的流程如下图所示。图3.Hbase检索示意图如上图所示，Hbase检索客户数据所需的处理过程大致如下：（1）如果您不知道如何健康，直接查找列key-value值，您需要查找整个region区间或整个table。在这种情况下，时间的复杂性是o(n)，这种情况是最耗时的操作，通常客户端程序是不可接受的，我们主要分析行健扫描检索的时间复杂性，即以下2-4个步骤。(2)客户端寻找正确的RegionServer和Region。(2)客户端寻找正确的RegionServer和Region。电话费用三次固定操作，找到正确的region，包括搜索Zookeper和搜索。-ROOT-表，找找.META表，这是O(1)运算。(3)在指定的Region上，行在阅读过程中可能有两个地方。如果硬盘还没有刷，那就是在Memstore中。如果硬盘已经刷了，假设一个HFile中只有一个HFile。这一行的数据要么在这个HFile中，要么在Memstore中。(4)对后者来说，时间复杂度通常是固定的，即O(loge)，对于前者来说，分析要复杂得多。在HFile中找到正确的数据块是一个时间复杂的O(logb)在找到这一行数据后，在列簇中找到keyvalue对象是线性扫描过程(同一列簇的列数据通常在同一数据块中)，在这种情况下，扫描的时间复杂度是O(elb),如果列簇中的列数据不在同一数据块中，则需要访问多个连续数据块，时间复杂度为O(c)，因此，这种时间复杂性是两种可能性的最大值，即O(max(c,elb)综上所述，在Hbase中找到某一行的时间费是：O(1)用于查找region) O(loge)如果KeyValue仍在MemStore中，用于在region中定位KeyValue O(logb）用于在HFile中找到正确的数据块 O(max（celb)用于查找不熟悉上述O(1)、log等标记的HFile读者，参考资源中的“算法参考，了解计算机时间复杂性的相关数学统计符号和计算公式”。从上面介绍的Hbase的整体结构和检索时间复杂性分析可以看出，行键和列簇的设计和数据存储决定了Hbase的整体性能和执行查询的效率。许多使用Hbase的项目和技术人员可以熟练地使用Hbaseshell或SDKAPI访问Hbase进行表创建和删除，以及put/delete/scan等DML操作，但深入探讨开发设计中的关键问题，如需要多少列，需要多少列，需要多少列，需要存储哪些数据，需要存储哪些数据。在基于Hbase的系统设计和开发中，需要考虑的因素与关系数据库不同。Hbase模式本身非常简单，但它给了你更多的调整空间。有些模式具有良好的写作性能，但在阅读数据时表现不佳。相反，类似于基于范式的传统数据库的OR建模，在实际项目中考虑Hbase设计模式是，我们需要从以下几个方面入手:这个表应该有多少列？使用什么数据？每个列应该有多少列？虽然列名在建表时不需要定义，但读写数据时需要的单元应该存储什么数据？每个单元存储什么时间版本的健康结构是什么？应该包括什么信息？我们以使用Hbase技术的真实客户案例为例。说明Hbase设计模式在真实项目中的实践，通过不同的表设计模式，可以看到模式是如何影响表结构和读写方法的，以及客户检索查询性能的客户场景介绍客户介绍：客户是一个互联网手机游戏平台，需要对大多数手机游戏玩家进行手机游戏产品的统计分析，需要存储每个手机游戏玩家，即客户对每个手机游戏产品的*（游戏热度）和存储时间维度的*信息，以便根据客户的喜好挖掘和类似于准确营销的手机游戏指定点

以上就是关于Hbase的 原理、设计及实现的相关介绍，更多Hbase的 原理、设计及实现相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对Hbase的 原理、设计及实现有更深的了解和认识。