这篇文章给大家分享的是有关 HBase 基本知识有哪些的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。
概述
HBase 特性：
强一致性读写: HBase 不是 最终一致性(eventually consistent) 数据存储. 这让它很适合高速计数聚合类任务。
自动分片(Automatic sharding): HBase 表通过 region 分布在集群中。数据增长时，region 会自动分割并重新分布。
RegionServer 自动故障转移
Hadoop/HDFS 集成: HBase 支持本机外 HDFS 作为它的分布式文件系统。
MapReduce: HBase 通过 MapReduce 支持大并发处理，HBase 可以同时做源和目标.
Java 客户端 API: HBase 支持易于使用的 Java API 进行编程访问.
Thrift/REST API: HBase 也支持 Thrift 和 REST 作为非 Java 前端.
Block Cache 和 Bloom Filters: 对于大容量查询优化，HBase 支持 Block Cache 和 Bloom Filters。
运维管理: HBase 提供内置网页用于运维视角和 JMX 度量.
HBase 不适合所有问题.
首先，确信有足够多数据，如果有上亿或上千亿行数据，HBase 是很好的备选。如果只有上千或上百万行，则用传统的 RDBMS 可能是更好的选择。因为所有数据可以在一两个节点保存，集群其他节点可能闲置。
其次，确信可以不依赖所有 RDBMS 的额外特性 (e.g., 列数据类型, 第二索引, 事物, 高级查询语言等.) 一个建立在 RDBMS 上应用，如不能仅通过改变一个 JDBC 驱动移植到 HBase。相对于移植，需考虑从 RDBMS 到 HBase 是一次完全的重新设计。
第三，确信你有足够硬件。甚至 HDFS 在小于 5 个数据节点时，干不好什么事情 (根据如 HDFS 块复制具有缺省值 3), 还要加上一个 NameNode.
预写日志 (WAL)
每个 RegionServer 会将更新(Puts, Deletes) 先记录到预写日志中(WAL)，然后将其更新在 Section 9.7.5,“Store”的 Section 9.7.5.1,“MemStore”里面。这样就保证了 HBase 的写的可靠性。如果没有 WAL, 当 RegionServer 宕掉的时候，MemStore 还没有 flush，StoreFile 还没有保存，数据就会丢失。HLog 是 HBase 的一个 WAL 实现，一个 RegionServer 有一个 HLog 实例。
WAL 保存在 HDFS 的 /hbase/.logs/ 里面，每个 region 一个文件。
区域
区域是表获取和分布的基本元素，由每个列族的一个库 (Store) 组成。对象层级图如下：
Table (HBase table)
Region (Regions for the table)
Store (Store per ColumnFamily for each Region for the table)
MemStore (MemStore for each Store for each Region for the table)
StoreFile (StoreFiles for each Store for each Region for the table)
Block (Blocks within a StoreFile within a Store for each Region for the table)Region 大小
Region 的大小是一个棘手的问题，需要考量如下几个因素。
Regions 是可用性和分布式的最基本单位
HBase 通过将 region 切分在许多机器上实现分布式。也就是说，你如果有 16GB 的数据，只分了 2 个 region，你却有 20 台机器，有 18 台就浪费了。
region 数目太多就会造成性能下降，现在比以前好多了。但是对于同样大小的数据，700 个 region 比 3000 个要好。
region 数目太少就会妨碍可扩展性，降低并行能力。有的时候导致压力不够分散。这就是为什么，你向一个 10 节点的 HBase 集群导入 200MB 的数据，大部分的节点是 idle 的。
RegionServer 中 1 个 region 和 10 个 region 索引需要的内存量没有太多的差别。
最好是使用默认的配置，可以把热的表配小一点(或者受到 split 热点的 region 把压力分散到集群中)。如果你的 cell 的大小比较大(100KB 或更大)，就可以把 region 的大小调到 1GB。
存储
一个存储包含了一个内存存储 (MemStore) 和若干个文件存储(StoreFile–HFile). 一个存储可以定位到一个列族中的一个区.
MemStore MemStores 是 Store 中的内存 Store, 可以进行修改操作。修改的内容是 KeyValues。当 flush 的是，现有的 memstore 会生成快照，然后清空。在执行快照的时候，HBase 会继续接收修改操作，保存在 memstore 外面，直到快照完成。
StoreFile (HFile) 文件存储是数据存在的地方。
紧缩
有两种类型的紧缩：次紧缩和主紧缩。minor 紧缩通常会将数个小的相邻的文件合并成一个大的。Minor 不会删除打上删除标记的数据，也不会删除过期的数据，Major 紧缩会删除过期的数据。有些时候 minor 紧缩就会将一个 store 中的全部文件紧缩，实际上这个时候他本身就是一个 major 压缩。
在执行一个 major 紧缩之后，一个 store 只会有一个 sotrefile, 通常情况下这样可以提供性能。注意：major 紧缩将会将 store 中的数据全部重写，在一个负载很大的系统中，这个操作是很伤的。
紧缩 不会 进行分区合并。
批量装载(Bulk Loading)
概述 HBase 有好几种方法将数据装载到表。最直接的方式即可以通过 MapReduce 任务，也可以通过普通客户端 API。但是这都不是高效方法。
批量装载特性采用 MapReduce 任务，将表数据输出为 HBase 的内部数据格式，然后可以将产生的存储文件直接装载到运行的集群中。批量装载比简单使用 HBase API 消耗更少的 CPU 和网络资源。
批量装载架构
HBase 批量装载过程包含两个主要步骤。
通过 MapReduce 任务准备数据 批量装载第一步，从 MapReduce 任务通过 HFileOutputFormat 产生 HBase 数据文件(StoreFiles)。输出数据为 HBase 的内部数据格式，以便随后装载到集群更高效。
为了处理高效，HFileOutputFormat 必须比配置为每个 HFile 适合在一个分区内。为了做到这一点，输出将被批量装载到 HBase 的任务，使用 Hadoop 的 TotalOrderPartitioner 类来分开 map 输出为分开的键空间区间。对应于表内每个分区 (region) 的键空间。
HFileOutputFormat 包含一个方便的函数, configureIncrementalLoad(), 可以基于表当前分区边界自动设置 TotalOrderPartitioner。
完成数据装载 After the data has been prepared using HFileOutputFormat, it is loaded into the cluster using completebulkload. This command line tool iterates through the prepared data files, and for each one determines the region the file belongs to. It then contacts the appropriate Region Server which adopts the HFile, moving it into its storage directory and making the data available to clients.
If the region boundaries have changed during the course of bulk load preparation, or between the preparation and completion steps, the completebulkloads utility will automatically split the data files into pieces corresponding to the new boundaries. This process is not optimally efficient, so users should take care to minimize the delay between preparing a bulk load and importing it into the cluster, especially if other clients are simultaneously loading data through other means.
表创建: 预创建区域(Region)
默认情况下 HBase 创建表会新建一个区域。执行批量导入，意味着所有的 client 会写入这个区域，直到这个区域足够大，以至于分裂。一个有效的提高批量导入的性能的方式，是预创建空的区域。最好稍保守一点，因为过多的区域会实实在在的降低性能。
表创建: 延迟 log 刷写
Puts 的缺省行为使用 Write Ahead Log (WAL)，会导致 HLog 编辑立即写盘。如果采用延迟刷写，WAL 编辑会保留在内存中，直到刷写周期来临。好处是集中和异步写 HLog，潜在问题是如果 RegionServer 退出，没有刷写的日志将丢失。但这也比 Puts 时不使用 WAL 安全多了。
延迟 log 刷写可以通过 HTableDescriptor 在表上设置，hbase.regionserver.optionallogflushinterval 缺省值是 1000ms.
HBase 客户端: 自动刷写
当你进行大量的 Put 的时候，要确认你的 HTable 的 setAutoFlush 是关闭着的。否则的话，每执行一个 Put 就要想区域服务器发一个请求。通过 htable.add(Put) 和 htable.add(List Put)来将 Put 添加到写缓冲中。如果 autoFlush = false，要等到写缓冲都填满的时候才会发起请求。要想显式的发起请求，可以调用 flushCommits。在 HTable 实例上进行的 close 操作也会发起 flushCommits
HBase 客户端: 在 Puts 上关闭 WAL
一个经常讨论的在 Puts 上增加吞吐量的选项是调用 writeToWAL(false)。关闭它意味着 RegionServer 不再将 Put 写到 Write Ahead Log, 仅写到内存。然而后果是如果出现 RegionServer 失败，将导致数据丢失。如果调用 writeToWAL(false)，需保持高度警惕。你会发现实际上基本没有不同，如果你的负载很好的分布到集群中。
通常而言，最好对 Puts 使用 WAL，而增加负载吞吐量与使用 bulk loading 替代技术有关。
从 HBase 读
Scan 缓存 如果 HBase 的输入源是一个 MapReduce Job，要确保输入的 Scan 的 setCaching 值要比默认值 0 要大。使用默认值就意味着 map-task 每一行都会去请求一下 region-server。可以把这个值设为 500，这样就可以一次传输 500 行。当然这也是需要权衡的，过大的值会同时消耗客户端和服务端很大的内存，不是越大越好。
Scan 属性选择
当 Scan 用来处理大量的行的时候(尤其是作为 MapReduce 的输入)，要注意的是选择了什么字段。如果调用了 scan.addFamily，这个列族的所有属性都会返回。如果只是想过滤其中的一小部分，就指定那几个 column，否则就会造成很大浪费，影响性能。
关闭 ResultScanners
这与其说是提高性能，倒不如说是避免发生性能问题。如果你忘记了关闭 ResultScanners，会导致 RegionServer 出现问题。所以一定要把 ResultScanner 包含在 try/catch 块中 …
Scan scan = new Scan();
// set attrs...
ResultScanner rs = htable.getScanner(scan);
try { for (Result r = rs.next(); r != null; r = rs.next()) { // process result...} finally { rs.close(); // always close the ResultScanner!
htable.close();感谢各位的阅读！关于“HBase 基本知识有哪些”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
六了个六
6666