数据库 Hbase

Hbase原理

Hbase

Posted by Gong on March 2, 2019

HBase架构

架构组成

只要记得在分布式的生产环境中，HBase 需要运行在 HDFS 之上，以 HDFS 作为其基础的存储设施。HBase 上层提供了访问的数据的 Java API 层，供应用访问存储在 HBase 的数据。在 HBase 的集群中主要由 Master 和 Region Server 组成，以及 Zookeeper，具体模块如下图所示。



  1. HBase 的集群是通过 Zookeeper 来进行机器之前的协调，也就是说 HBase Master 与 Region Server 之间的关系是依赖 Zookeeper 来维护。当一个 Client 需要访问 HBase 集群时，Client 需要先和 Zookeeper 来通信，然后才会找到对应的 Region Server。
  2. 每一个 Region Server 管理着很多个 Region。对于 HBase 来说，Region 是 HBase 并行化的基本单元。因此，数据也都存储在 Region 中。这里我们需要特别注意，每一个 Region 的 一个 Store 只存储一个 table 的 一个column family 的数据，并且是该 CF 中的一段（按 Row 的区间分成多个 Region）。
  3. Region 所能存储的数据大小是有上限的，当达到该上限时（Threshold），Region 会进行分裂，数据也会分裂到多个 Region 中，这样便可以提高数据的并行化，以及提高数据的容量。
  4. 每个 Region 包含着多个 Store 对象。每个 Store 包含一个 MemStore，和一个或多个 HFile。MemStore 便是数据在内存中的实体，并且一般都是有序的。当数据向 Region 写入的时候，会先写入 MemStore。
  5. 当 MemStore 中的数据需要向底层文件系统倾倒（Dump）时（例如 MemStore 中的数据体积到达 MemStore 配置的最大值），Store 便会创建 StoreFile，而 StoreFile 就是对 HFile 一层封装。所以 MemStore 中的数据会最终写入到 HFile 中，也就是磁盘 IO。由于 HBase 底层依靠 HDFS，因此 HFile 都存储在 HDFS 之中。

  • Master（table和region的管理工作）

    1. 负责RegionServer的负载均衡，调整region的分配
    2. Region分裂后，为RegionServer分配新的Region
    3. 发现失效的region server并重新分配其上的region
    4. HBase 允许多个 Master 节点共存，但是这需要 Zookeeper 的帮助。不过当多个 Master 节点共存时，只有一个 Master 是提供服务的，其他的 Master 节点处于待命的状态。当正在工作的 Master 节点宕机时，其他的 Master 则会接管 HBase 的集群。

  • Region Server

    • HRegionSserver维护Master分配给它的region
    • 维护region的cache
    • 处理region的flush、compact、split
    • 内部管理一系列的HRegion对象
    • 一个HRegionServer会有多个HRegion和一个HLog。

    对于一个 Region Server 而言，其包括了多个 Region。Region Server 的作用只是管理表格，以及实现读写操作。Client 直接连接 Region Server，并通信获取 HBase 中的数据。对于 Region 而言，则是真实存放 HBase 数据的地方，也就说 Region 是 HBase 可用性和分布式的基本单位。每个Region负责一小部分Rowkey范围的数据的读写和维护，Region包含了对应的起始行到结束行的所有信息。如果当一个表格很大，并由多个 CF 组成时，那么表的数据将存放在多个 Region 之间，并且在每个 Region 中会关联多个存储的单元（Store）。

  • Zookeeper

    1. 首先 Zookeeper 是作为 HBase Master 的 HA（高可用） 解决方案。Zookeeper 保证了至少有一个 HBase Master 处于运行状态。
    2. 并且 Zookeeper 负责 Region 和 Region Server 的注册。通过Zoopkeeper来监控RegionServer的状态，当RegionSevrer有异常的时候，通过回调的形式通知Master RegionServer上下限的信息
    3. 存贮所有Region的寻址入口；
    4. 通过Zoopkeeper存储元数据的统一入口地址；存储Hbase的schema（元数据信息）。包括有哪些table、每个table有哪些column family等
    5. 其实 Zookeeper 发展到目前为止，已经成为了分布式大数据框架中容错性的标准框架。不光是 HBase，几乎所有的分布式大数据相关的开源框架，都依赖于 Zookeeper 实现 HA。

Region Server的组成

  • WAL（Hlog）：既Write Ahead Log。WAL是HDFS分布式文件系统中的一个文件。WAL用来存储尚未写入永久性存储区中的新数据。WAL也用来在服务器发生故障时进行数据恢复。
  • Block Cache：Block cache是读缓存。Block cache将经常被读的数据存储在内存中来提高读取数据的效率。当Block cache的空间被占满后，其中被读取频率最低的数据将会被杀出。
  • MemStore：MemStore是写缓存。其中存储了从WAL中写入但尚未写入硬盘的数据。MemStore中的数据在写入硬盘之前会先进行排序操作。每一个region中的每一个column family对应一个MemStore。
  • Hfiles：Hfiles存在于硬盘上，根据排序号的键存储数据行。
  • img

Region组成

  • 每一个HRegion又由很多的Store组成，每一个Store存储的实际上是一个列簇（ColumnFamily）下所有的数据。此外，在每一个Store（又名HStore）中有包含一块MemStore。MemStore驻留在内存中，数据到来时首先更新到MemStore中，当到达阈值之后再flush（默认64M）到对应的StoreFile（又名HFile）中，所以每一个Store包含多个StoreFile，StoreFile负责的是实际数据存储，为HBase中最小的存储单元。
  • 达到某个阈值时，分裂（默认256M）。所以一个HRegionServer管理多个表，一个表下有多个Region，一个HRegion有多少个列族就有多少个Store,Store下有多个StoreFile文件，是HBase中最小的存储单元
  • 以Region为单位管理, region(startKey,endKey)；【默认情况下，刚创建一个表时，并不知道startkey和endkey】 每个Column Family单独存储：storeFile；（ storefile的数量一多（到达阀值），就合并（同时合并版本以及删除之前要删除的数据）；合并后大小到达阀值就split）
  • 当某个Column Family累积的大小（具体的数据量） > 某阈值时，自动分裂成两个Region；合并之后，旧数据也不是立即删除，而是复制一份并同内存中的数据一起写到磁盘，在之后，LSM-Tree会提供一些机制来回收这些空间。[4]
  • 如何找到某行属于哪个region呢？.META.

HFile 的结构

img

从图中我们可以看到 HFile 由很多个数据块（Block）组成，并且有一个固定的结尾块。其中的数据块是由一个 Header 和多个 Key-Value 的键值对组成。在结尾的数据块中包含了数据相关的索引信息，系统也是通过结尾的索引信息找到 HFile 中的数据。HFile 中的数据块大小默认为 64KB。如果访问 HBase 数据库的场景多为有序的访问，那么建议将该值设置的大一些。如果场景多为随机访问，那么建议将该值设置的小一些。一般情况下，通过调整该值可以提高 HBase 的性能。

HFile中包含了一个多层索引系统。这个多层索引是的HBase可以在不读取整个文件的情况下查找数据。这一多层索引类似于一个B+树。

HFile structure

HLog（保证数据可靠性）

Hlog是Hbase实现WAL（Write ahead log）方式产生的日志信息，保证事务一致性。内部是一个简单的顺序日志。每个RegionServer对应1个Hlog(备注：1.x版本的可以开启MultiWAL功能，允许多个Hlog)，所有对于该RegionServer的写入都被记录到Hlog中。Hlog实现的功能就是我们前面讲到的保证数据安全。

当RegionServer出现问题的时候，能跟进Hlog来做数据恢复。此外为了保证恢复的效率，Hbase会限制最大保存的Hlog数量，如果达到Hlog的最大个数（hase.regionserver.max.logs参数控制）的时候，就会触发强制刷盘操作。对于已经刷盘的数据，其对应的Hlog会有一个过期的概念，Hlog过期后，会被监控线程移动到 .oldlogs，然后会被自动删除掉。

Hlog数据结构


从上图我们可以看出都个Region共享一个Hlog文件，单个Region在Hlog中是按照时间顺序存储的，但是多个Region可能并不是完全按照时间顺序。

每个Hlog最小单元由Hlogkey和WALEdit两部分组成。

  • Hlogkey由sequenceid、timestamp、cluster ids、regionname以及tablename等组成，
  • WALEdit是由一系列的KeyValue组成，对一行上所有列（即所有KeyValue）的更新操作，都包含在同一个WALEdit对象中，这主要是为了实现写入一行多个列时的原子性。

注意，图中有个sequenceid的东东。sequenceid是一个store级别的自增序列号，这东东非常重要，region的数据恢复和Hlog过期清除都要依赖这个东东。下面就来简单描述一下sequenceid的相关逻辑。

  • Memstore在达到一定的条件会触发刷盘的操作，刷盘的时候会获取刷新到最新的一个sequenceid的下一个sequenceid，并将新的sequenceid赋给oldestUnflushedSequenceId，并刷到Ffile中。有点绕，举个例子来说明：比如对于某一个store，开始的时候oldestUnflushedSequenceId为NULL，此时，如果触发flush的操作，假设初始刷盘到sequenceid为10，那么hbase会在10的基础上append一个空的Entry到HLog，最新的sequenceid为11，然后将sequenceid为11的号赋给oldestUnflushedSequenceId，并将oldestUnflushedSequenceId的值刷到Hfile文件中进行持久化。
  • Hlog文件对应所有Region的store中最大的sequenceid如果已经刷盘，就认为Hlog文件已经过期，就会移动到.oldlogs，等待被移除。
  • 当RegionServer出现故障的时候，需要对Hlog进行回放来恢复数据。回放的时候会读取Hfile的oldestUnflushedSequenceId中的sequenceid和Hlog中的sequenceid进行比较，小于sequenceid的就直接忽略，但与或者等于的就进行重做。回放完成后，就完成了数据的恢复工作。

Hlog生命周期

  • 产生 所有涉及到数据的变更都会先写Hlog，除非是你关闭了Hlog
  • 滚动 Hlog的大小通过参数hbase.regionserver.logroll.period控制，默认是1个小时，时间达到hbase.regionserver.logroll.period 设置的时间，Hbase会创建一个新的Hlog文件。这就实现了Hlog滚动的目的。Hbase通过hbase.regionserver.maxlogs参数控制Hlog的个数。滚动的目的，为了控制单个Hlog文件过大的情况，方便后续的过期和删除。
  • 过期 前面我们有讲到sequenceid这个东东，Hlog的过期依赖于对sequenceid的判断。Hbase会将Hlog的sequenceid和Hfile最大的sequenceid（刷新到的最新位置）进行比较，如果该Hlog文件中的sequenceid比刷新的最新位置的sequenceid都要小，那么这个Hlog就过期了，过期了以后，对应Hlog会被移动到.oldlogs目录。 这里有个问题，为什么要将过期的Hlog移动到.oldlogs目录，而不是直接删除呢？ 答案是因为Hbase还有一个主从同步的功能，这个依赖Hlog来同步Hbase的变更，有一种情况不能删除Hlog，那就是Hlog虽然过期，但是对应的Hlog并没有同步完成，因此比较好的做好是移动到别的目录。再增加对应的检查和保留时间。
  • 删除 如果Hbase开启了replication，当replication执行完一个Hlog的时候，会删除Zoopkeeper上的对应Hlog节点。在Hlog被移动到.oldlogs目录后，Hbase每隔hbase.master.cleaner.interval（默认60秒）时间会去检查.oldlogs目录下的所有Hlog，确认对应的Zookeeper的Hlog节点是否被删除，如果Zookeeper 上不存在对应的Hlog节点，那么就直接删除对应的Hlog。 hbase.master.logcleaner.ttl（默认10分钟）这个参数设置Hlog在.oldlogs目录保留的最长时间。

Hbase中表结构逻辑视图

在 HBase 中首先会有 Column Family 的概念，简称为 CF。表 3. 数据在 HBase 中的排布（逻辑上）

Row-Key Value（CF、Qualifier、Version）
1 info{‘姓’: ‘张’，’名’:’三’} pwd{‘密码’: ‘111’}
2 Info{‘姓’: ‘李’，’名’:’四’} pwd{‘密码’: ‘222’}

表中两个 CF，分别是 info 和 pwd。info 存储着姓名相关列的数据，而 pwd 则是密码相关的数据。CF 一般用于将相关的列（Column）组合起来。在物理上 HBase 其实是按 CF 存储的，只是按照 Row-key 将相关 CF 中的列关联起来。物理上的数据排布大致可以如表 4 所示。

Row-Key CF:Column-Key 时间戳 Cell Value
1 info:fn 123456789 三
1 info:ln 123456789 张
2 info:fn 123456789 四
2 info:ln 123456789 李

上表中的 fn 和 ln 称之为 Column-key 或者 Qulifimer。在 Hbase 中，Row-key 加上 CF 加上 Qulifier 再加上一个时间戳才可以定位到一个单元格数据（Hbase 中每个单元格默认有 3 个时间戳的版本数据）


img

总结

HBase 就是一个有序的多维 Map，其中每一个 Row-key 映射了许多数据，这些数据存储在 CF 中的 Column。我们可以用下图来表示这句话。


RowKey设计原则

  1. Rowkey长度原则：Rowkey 是一个二进制码流，Rowkey 的长度被很多开发者建议说设计在10~100 个字节，不过建议是越短越好，不要超过16 个字节。 原因如下： （1）数据的持久化文件HFile 中是按照KeyValue 存储的，如果Rowkey 过长比如100 个 字节，1000 万列数据光Rowkey 就要占用100*1000 万=10 亿个字节，将近1G 数据，这会极 大影响HFile 的存储效率； （2）MemStore 将缓存部分数据到内存，如果Rowkey 字段过长内存的有效利用率会降 低，系统将无法缓存更多的数据，这会降低检索效率。因此Rowkey 的字节长度越短越好。 （3）目前操作系统是都是64 位系统，内存8 字节对齐。控制在16 个字节，8 字节的 整数倍利用操作系统的最佳特性。
  2. Rowkey散列原则 如果Rowkey 是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey 的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个 Regionserver 实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有 新数据都在一个 RegionServer 上堆积的热点现象，这样在做数据检索的时候负载将会集中 在个别RegionServer，降低查询效率。
  3. Rowkey唯一原则

Hbase工作流程

img

Hbase的写流程

1、Table 中的所有行都按照 RowKsey 的字典序排列。

2、Table 在行的方向上分割为多个 HRegion。

3、HRegion 按大小分割的(默认 10G)，每个表一开始只有一个 HRegion，随着数据不断插入 表，HRegion 不断增大，当增大到一个阀值的时候，HRegion 就会等分会两个新的 HRegion。 当表中的行不断增多，就会有越来越多的 HRegion。

4、HRegion 是 Hbase 中分布式存储和负载均衡的最小单元。最小单元就表示不同的 HRegion 可以分布在不同的 HRegionserver 上。但一个 HRegion 是不会拆分到多个 server 上的。

5、HRegion 虽然是负载均衡的最小单元，但并不是物理存储的最小单元。事实上，HRegion 由一个或者多个 Store 组成，每个 Store 保存一个 Column Family。每个 Strore 又由一个 memStore 和 0 至多个 StoreFile 组成

Hbase的写入流程如下图所示：

img

第1步：Client获取数据写入的Region所在的RegionServer

第2步：请求写Hlog

第3步：请求写MemStore。只有当写Hlog和写MemStore都成功了才算请求写入完成。Memstore存在于内存中，其中存储的是按键排好序的待写入硬盘的数据。数据也是按键排好序写入HFile中的。每一个Region中的每一个Column family对应一个Memstore文件。因此对数据的更新也是对应于每一个Column family。

img

第4步：MemStore后续会逐渐刷到HDFS中。当MemStore中积累了足够多的数据之后，整个Memcache中的数据会被一次性写入到HDFS里的一个新的HFile中。因此HDFS中一个Column family可能对应多个HFile。这个HFile中包含了相应的cell，或者说键值的实例。这些文件随着MemStore中积累的对数据的操作被flush到硬盘上而创建。

因为MemStore中的数据已经按照键排好序，所以这是一个顺序写的过程。由于顺序写操作避免了磁盘大量寻址的过程，所以这一操作非常高效。

img

备注：Hlog存储在HDFS，当RegionServer出现异常，需要使用Hlog来恢复数据。

Region寻址方式

那么client要对某一行数据做读写的时候如何能知道具体要去访问哪个RegionServer呢？

旧的：


新的：


第1步：Client请求ZK获取.META.所在的RegionServer的地址。

第2步：Client请求.META.所在的RegionServer获取访问数据所在的RegionServer地址，client会将.META.的相关信息cache下来，以便下一次快速访问。

第3步：Client请求数据所在的RegionServer，获取所需要的数据。

总结去掉-ROOT-的原因有如下2点：

  • 其一：提高性能
  • 其二：2层结构已经足以满足集群的需求

HBase的META table

  • META table中保存了HBase中所有region的信息。

  • META table的格式类似于B tree。

  • META table的结构如下：

    • 键：region的起始键，region id。

    • 值：Region server

img

Client缓存问题

Client会缓存.META.的数据，用来加快访问，既然有缓存，那它什么时候更新？如果.META.更新了，比如Region1不在RerverServer2上了，被转移到了RerverServer3上。client的缓存没有更新会有什么情况？ 其实，Client的元数据缓存不更新，当.META.的数据发生更新。如上面的例子，由于Region1的位置发生了变化，Client再次根据缓存去访问的时候，会出现错误，当出现异常达到重试次数后就会去.META.所在的RegionServer获取最新的数据，如果.META.所在的RegionServer也变了，Client就会去ZK上获取.META.所在的RegionServer的最新地址。

HBase的Compaction

大量HFile的产生，会消耗更多的文件句柄，同时会造成RS在数据查询等的效率大幅度下降，HBase为解决这个问题，引入了compact操作，RS通过compact把大量小的HFile进行文件合并，生成大的HFile文件。

RS上的compact根据功能的不同，可以分为两种不同类型，即：minor compact和major compact。

minor compact

HBase会自动选取一些较小的HFile进行合并，并将结果写入几个较大的HFile中。这一过程称为Minor compaction。Minor compaction通过Merge sort的形式将较小的文件合并为较大的文件，从而减少了存储的HFile的数量，提升HBase的性能。

img

Major Compaction

所谓Major Compaction指的是HBase将对应于某一个Column family的所有HFile重新整理并合并为一个HFile，并在这一过程中删除已经删除或过期的cell，更新现有cell的值。这一操作大大提升读的效率。但是因为Major compaction需要重新整理所有的HFile并写入一个HFile，这一过程包含大量的硬盘I/O操作以及网络数据通信。这一过程也称为写放大（Write amplification）。在Major compaction进行的过程中，当前Region基本是处于不可访问的状态。

img

Region拆分

compact将多个HFile合并单个HFile文件，随着数据量的不断写入，单个HFile也会越来越大，大量小的HFile会影响数据查询性 能，大的HFile也会，HFile越大，相对的在HFile中搜索的指定rowkey的数据花的时间也就越长，HBase同样提供了region的 split方案来解决大的HFile造成数据查询时间过长问题。

每一个表格最初都对应于一个region。随着region中数据量的增加，region会被分割成两个子region。每一个子region中存储原来一半的数据。同时Region server会通知HMaster这一分割。出于负载均衡的原因，HMaster可能会将新产生的region分配给其他的Region server管理（这也就导致了Region server服务远端数据的情况的产生）。

img

Hbase故障恢复

PS.分布式系统CAP

img

  1. Partition tolerance，中文叫做”分区容错”。 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。
  2. Consistency Consistency 中文叫做”一致性”。意思是，写操作之后的读操作，必须返回该值
  3. Availability 中文叫做”可用性”，意思是只要收到用户的请求，服务器就必须给出回应

面试题目

  1. Hbase特点是什么？

    1. 表由行（Row）以及列（Column）组成，行由row key和一个或多个列及其值组成；
    2. 列必须属于某一列族（Column family），一个列族可以有一各或多个列（一列由列簇和列修饰符组成，他们通常由冒号（：） 分隔），其在存储架构中就是一个Hfile。
    3. 列中的数据可以是稀疏的，空值并不占用存储空间。
    4. 数据按主键排序，同时表按主键划分为多个Region。底层是LSM树（Long-Structed Merge Tree）。
    5. 这里写图片描述
    6. 缺点：
      1. 单一RowKey固有的局限性决定了它不可能有效地支持多条件查询[2]
      2. 不适合于大范围扫描查询
      3. 不直接支持 SQL 的语句查询

  2. 应用场景？OLAP

    1. 半结构化或非结构化数据: 对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用HBase，因为HBase支持动态添加列。
    2. 记录很稀疏： RDBMS的行有多少列是固定的。为null的列浪费了存储空间。而如上文提到的，HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。
    3. 多版本号数据： 依据Row key和Column key定位到的Value能够有随意数量的版本号值，因此对于须要存储变动历史记录的数据，用HBase是很方便的。比方某个用户的Address变更，用户的Address变更记录也许也是具有研究意义的。
    4. 仅要求最终一致性： 对于数据存储事务的要求不像金融行业和财务系统这么高，只要保证最终一致性就行。（比如HBase+elasticsearch时，可能出现数据不一致）
    5. 高可用和海量数据以及很大的瞬间写入量： WAL解决高可用，支持PB级数据，put性能高
    6. 索引插入比查询操作更频繁的情况。比如，对于历史记录表和日志文件。（HBase的写操作更加高效）
    7. 业务场景简单： 不需要太多的关系型数据库特性，列入交叉列，交叉表，事务，连接等。

  3. Hbase读写流程

  4. Hbase切分流程

  5. zk，Hmaster，Rs等的作用？

  6. HBASE中compact用途是什么，什么时候触发，分为哪两种,有什么区别，有哪些相关配置参数？

    在hbase中每当有memstore数据flush到磁盘之后，就形成一个storefile，当storeFile的数量达到一定程度后，就需要将 storefile 文件来进行 compaction 操作。 Compact 的作用： 1>.合并文件 2>.清除过期，多余版本的数据 3>.提高读写数据的效率 HBase 中实现了两种 compaction 的方式：minor and major. 这两种 compaction 方式的区别是：

    1、Minor 操作只用来做部分文件的合并操作以及包括 minVersion=0 并且设置 ttl 的过期版本清理，不做任何删除数据、多版本数据的清理工作。 2、Major 操作是对 Region 相同列族的HStore下的所有StoreFile执行合并操作，最终的结果是整理合并出一个文件。

  7. 关系型数据库和非关系型数据库的区别？Hbase和RDBMS的区别

    1. hbase是按照列族存储的；普通RDB是一列
    2. 数据类型：没有数据类型，都是字节数组（有一个工具类Bytes，将java对象序列化为字节数组）。 数据操作：HBase只有很简单的插入、查询、删除、清空等操作，表和表之间是分离的，没有复杂的表和表之间的关系，而传统数据库通常有各式各样的函数和连接操作。 存储模式：Hbase适合于非结构化数据存储，基于列存储而不是行。 数据维护：HBase的更新操作不应该叫更新，它实际上是插入了新的数据，而传统数据库是替换修改 时间版本：Hbase数据写入cell时，还会附带时间戳，默认为数据写入时RegionServer的时间，但是也可以指定一个不同的时间。数据可以有多个版本。 可伸缩性：Hbase这类分布式数据库就是为了这个目的而开发出来的，所以它能够轻松增加或减少硬件的数量，并且对错误的兼容性比较高。而传统数据库通常需要增加中间层才能实现类似的功能
    3. img

  8. hbase支持哪些查找方式？

    1. 基于Rowkey的单行查询
    2. 基于Rowkey的范围扫描
    3. 全表扫描

    因此，Rowkey对Hbase的性能影响非常大，Rowkey的设计就显得尤为的重要。设计的时候要兼顾基于Rowkey的单行查询也要键入Rowkey的范围扫描。具体Rowkey要如何设计后续会整理相关的文章做进一步的描述。这里大家只要有一个概念就是Rowkey的设计极为重要。

  9. Hbase和Hive区别

  10. 为什么Hbase中要定义列族？

    在HBase中，数据是按Column Family来分割的，同一个Column Family下的所有列的数据放在一个文件（为简化下面的描述在此使用文件这个词，在HBase内部使用的是Store）中。 HBase本身的设计目标是支持稀疏表，而稀疏表通常会有很多列，但是每一行有值的列又比较少。 如果不使用Column Family的概念，那么有两种设计方案： 1.把所有列的数据放在一个文件中（也就是传统的按行存储）。那么当我们想要访问少数几个列的数据时，需要遍历每一行，读取整个表的数据，这样子是很低效的。 2.把每个列的数据单独分开存在一个文件中（按列存储）。那么当我们想要访问少数几个列的数据时，只需要读取对应的文件，不用读取整个表的数据，读取效率很高。然而，由于稀疏表通常会有很多列，这会导致文件数量特别多，这本身会影响文件系统的效率。 而Column Family的提出就是为了在上面两种方案中做一个折中。HBase中将一个Column Family中的列存在一起，而不同Column Family的数据则分开。 由于在HBase中Column Family的数量通常很小，同时HBase建议把经常一起访问的比较类似的列放在同一个Column Family中，这样就可以在访问少数几个列时，只读取尽量少的数据。

  11. Hbase列族数据库的理解。

    Hbase的存储方式就决定了列数据库！！ 1、存储方式：在HBase中，Key-Value是最小的存储单元。每一个Key-Value对应一个列，Value对应于一个列的列值。

    2、Rowkey作用：而且HBase是根据Rowkey来进行检索的（索引），系统通过找到某个Rowkey所在的Region，然后将查询数据的请求路由到该Region获取数据。 所以设计Rowkey就决定了未来你的查询性能

    3、hbase为什么叫列式存储？

    因为hbase列的可以动态增加，并且列为空就不存储数据,节省存储空间。

    举个例子吧，如下：

    1）Mysql结构化数据：你要指定一个表user，你必须

    预先定义好各个字段，姓名、年龄、ID。后期要扩展新字段麻烦

    2）Hbase列式存储：你只要设计好rowKey，定义好列簇，至于里面什么属性，有多少字段类型，

    无需预先定义好，扩展性极佳，需要的列字段可以不停的增加。

    也许前期你就姓名、年龄、ID三个字段，未来你随时可以存储第四个字段，第五个字段，第n个字段到你的列簇里，因为同一个列簇中的所有数据都存储在一个文件里。

  12. HBase 中每张表的列族个数建议设在1~3之间。其实，HBase 支持的列族个数并没有限制，但为什么文档建议在1~3之间呢？

    https://www.iteblog.com/archives/2474.html

参考文献

Hbase技术细节笔记

lxwHbase设计原理

Hbase深入浅出

翻译-深入理解Hbase系统

面试题

CATALOG
    FEATURED TAGS
    iOS 并发编程 设计模式 数据库 MySQL JVM Hbase 大数据 Tomcat 网络编程 分布式技术 spring
    FRIENDS