HBase基础
HBase是Apache Hadoop的数据库，能够对大型数据提供随机、实时的读写访问。HBase的目标是存储并处理大型的数据。HBase是一个开源的，分布式的，多版本的，面向列的存储模型，它存储的是松散型数据。
# HBase出现的背景
（1）随着数据规模越来越大，大量业务场景开始考虑数据存储水平扩展，使得存储服务可以增加/删除，而目前的关系型数据库更专注于一台机器。
（2）海量数据量存储成为瓶颈，单台机器无法负载大量数据。
（3）单台机器IO读写请求成为海量数据存储时候高并发，大规模请求的瓶颈。
（4）当数据进行水平扩展时候，如何解决数据IO高一致性问题。结合Map/Reduce计算框架进行海量数据的离线分析。
# Hadoop的局限性
要想明白为什么产生 HBase，就需要先了解一下 Hadoop 存在的限制？Hadoop 可以通过 HDFS 来存储结构化、半结构甚至非结构化的数据，它是传统数据库的补充，是海量数据存储的最佳方法，它针对大文件的存储，批量访问和流式访问都做了优化，同时也通过多副本解决了容灾问题。
但是 ==Hadoop 的缺陷在于它只能执行批处理，并且只能以顺序方式访问数据，这意味着即使是最简单的工作，也必须搜索整个数据集，无法实现对数据的随机访问。实现数据的随机访问是传统的关系型数据库所擅长的，但它们却不能用于海量数据的存储==。在这种情况下，必须有一种新的方案来解决海量数据存储和随机访问的问题，HBase 就是其中之一 (HBase，Cassandra，couchDB，Dynamo 和 MongoDB 都能存储海量数据并支持随机访问)。
注：数据结构分类：
- 结构化数据：即以关系型数据库表形式管理的数据；
- 半结构化数据：非关系模型的，有基本固定结构模式的数据，例如日志文件、XML 文档、JSON 文档、Email 等；
- 非结构化数据：没有固定模式的数据，如 WORD、PDF、PPT、EXL，各种格式的图片、视频等。
# BigTable成就了HBase
Google这个神奇的公司以其不保守的态度以学术论文的方式公开了其云计算的三大法宝：GFS、MapReduce和BigTable，其中对于BigTable的开源实现HBase则是由Doug Cutting完成的。
HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。
HBase中的表一般有这样的特点：
（1） 大：一个表可以有上亿行，上百万列
（2） 面向列：面向列(族)的存储和权限控制，列(族)独立检索。
（3） 稀疏：对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。
PS：什么是列存储？
列存储不同于传统的关系型数据库，其数据在表中是按行存储的，列方式所带来的重要好处之一就是，由于查询中的选择规则是通过列来定义的，因此整个数据库是自动索引化的。按列存储每个字段的数据聚集存储，在查询只需要少数几个字段的时候，能大大减少读取的数据量，一个字段的数据聚集存储，那就更容易为这种聚集存储设计更好的压缩/解压算法。下图讲述了传统的行存储和列存储的区别：
# HBase在Hadoop项目中的位置
与FUJITSU Cliq等商用大数据产品不同，HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable利用 Chubby作为协同服务，HBase利用Zookeeper作为对应。
下图展示了HBase在Hadoop生态系统体系结构中所处的位置：
上图描述了Hadoop生态系统中的各层系统。其中，HBase位于结构化存储层，Hadoop HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和失效转移（FailOver）机制。
此外，Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。 Sqoop则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。
HBASE中的每一张表，就是所谓的BigTable，一张稀疏表。RowKey 和 ColumnKey 是二进制值byte[]，按字典顺序排序；Timestamp 是一个 64 位整数；value 是一个未解释的字节数组byte[]。表中的不同行可以拥有不同数量的成员。即支持“动态模式“模型。
# 面向行和面向列
# OLTP和OLAP
当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果.
# OLTP
也称为面向交易的处理系统，其基本特征是顾客的原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。
这样做的最大优点是可以即时地处理输入的数据，及时地回答。也称为实时系统(Real time System)。衡量联机事务处理系统的一个重要性能指标是系统性能，具体体现为实时响应时间(Response Time)，即用户在终端上送入数据之后，到计算机对这个请求给出答复所需要的时间。OLTP是由数据库引擎负责完成的。
OLTP 数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。
# OLAP
随着数据库技术的发展和应用，数据库存储的数据量从20世纪80年代的兆（M）字节及千兆（G）字节过渡到现在的兆兆（T）字节和千兆兆（P）字节，同时，用户的查询需求也越来越复杂，涉及的已不仅是查询或操纵一张关系表中的一条或几条记录，而且要对多张表中千万条记录的数据进行数据分析和信息综合，关系数据库系统已不能全部满足这一要求。在国外，不少软件厂商采取了发展其前端产品来弥补关系数据库管理系统支持的不足，力图统一分散的公共应用逻辑，在短时间内响应非数据处理专业人员的复杂查询要求。
联机分析处理（OLAP）系统是数据仓库系统最主要的应用，专门设计用于支持复杂的分析操作，侧重对决策人员和高层管理人员的决策支持，可以根据分析人员的要求快速、灵活地进行大数据量的复杂查询处理，并且以一种直观而易懂的形式将查询结果提供给决策人员，以便他们准确掌握企业（公司）的经营状况，了解对象的需求，制定正确的方案。
# 面向行数据库和面向列数据库特点
面向行的数据库适用于联机事务处理(OLTP)，这样的数据库被设计为小数目的行和列。
面向列的数据库适用于在线分析处理(OLAP)，可以设计为巨大表。
下面显示了列族在面向列的数据库：
# 名词概念
# Rowkey的概念
Rowkey的概念和mysql中的主键是完全一样的，Hbase使用Rowkey来唯一的区分某一行的数据。Hbase只支持3种查询方式： - 1、基于Rowkey的单行查询 - 2、基于Rowkey的范围扫描 - 3、全表扫描
因此，Rowkey对Hbase的性能影响非常大，Rowkey的设计就显得尤为的重要。设计的时候要兼顾基于Rowkey的单行查询也要键入Rowkey的范围扫描。
rowkey 行键可以是任意字符串(最大长度是64KB，实际应用中长度一般为 10-100bytes)，最好是16。在HBase 内部，rowkey 保存为字节数组。HBase会对表中的数据按照 rowkey 排序 (字典顺序)
# Column的概念
列，可理解成MySQL列。
# ColumnFamily的概念
Hbase通过列族划分数据的存储，列族下面可以包含任意多的列，实现灵活的数据存取。列族是由一个一个的列组成（任意多）。
Hbase表的创建的时候就必须指定列族。就像关系型数据库创建的时候必须指定具体的列是一样的。
Hbase的列族不是越多越好，官方推荐的是列族最好小于或者等于3。我们使用的场景一般是1个列族。
# TimeStamp的概念
TimeStamp对Hbase来说至关重要，因为它是实现Hbase多版本的关键。在Hbase中使用不同的timestame来标识相同rowkey行对应的不通版本的数据。
在写入数据的时候，如果用户没有指定相应的timestamp，HBase会自动添加一个timestamp，timestamp和服务器时间保持一致。
HBase 中通过rowkey和columns确定的为一个存储单元称为cell。每个cell都保存着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是64位整型。时间戳可以由 hbase(在数据写入时自动)赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。
为了避免数据存在过多版本造成的的管理(包括存贮和索引)负担，hbase 提供了两种数据版本回收方式： - 保存数据的最后 n 个版本 - 保存最近一段时间内的版本（设置数据的生命周期 TTL）。
用户可以针对每个列簇进行设置。
# 单元格（Cell）
由{rowkey, column( = +),version}唯一确定的单元。 Cell 中的数据是没有类型的，全部是字节码形式存贮。
# Region
Region的概念和关系型数据库的分区或者分片差不多。
Hbase会将一个大表的数据基于Rowkey的不同范围分配到不通的Region中，每个Region负责一定范围的数据访问和存储。这样即使是一张巨大的表，由于被切割到不通的region，访问起来的时延也很低。
# HBase特点
# 数据库要点
介于NoSQL和RDBMS之间，仅能通过主键(rowkey)和主键的range来检索数据;
HBase查询数据功能很简单，不支持join等复杂操作;
不支持复杂事务，只支持行级事务(可通过hive支持来实现多表join等复杂操作)
HBase中支持的数据类型：byte
主要用来存储结构化和半结构化的松散数据；
# 结构化、半结构化和非结构化
结构化：数据结构字段含义确定，清晰，典型的如数据库中的表结构
半结构化：具有一定结构，但语义不够确定，典型的如 HTML 网页，有些字段是确定的(title)，有些不确定(table)
非结构化：杂乱无章的数据，很难按照一个概念去进行抽取，无规律性。
与 Hadoop 一样，HBase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。
# HBase中的表特点
1、大：一个表可以有上十亿行，上百万列
2、面向列：面向列(族)的存储和权限控制，列(簇)独立检索。
3、稀疏：对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。
4、无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列。
# HBase特点
# 海量存储
Hbase适合存储PB级别的海量数据，在PB级别的数据以及采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。这与Hbase的极易扩展性息息相关。正式因为Hbase良好的扩展性，才为海量数据的存储提供了便利。
# 列式存储
这里的列式存储其实说的是列族存储，Hbase是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定。
RDBMS:
Hbase的表：
RDBMS和HBase区别：
# 极易扩展
Hbase的扩展性主要体现在两个方面，一个是基于上层处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）。
通过横向添加RegionSever的机器，进行水平扩展，提升Hbase上层的处理能力，提升Hbsae服务更多Region的能力。
备注：RegionServer的作用是管理region、承接业务的访问。
通过横向添加Datanode的机器，进行存储层扩容，提升Hbase的数据存储能力和提升后端存储的读写能力。
# 高并发
由于目前大部分使用Hbase的架构，都是采用的廉价PC，因此单个IO的延迟其实并不小，一般在几十到上百ms之间。这里说的高并发，主要是在并发的情况下，Hbase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。
# 稀疏
稀疏主要是针对Hbase列的灵活性，在列族中，你可以指定任意多的列，在列数据为空的情况下，是不会占用存储空间的。
# 使用场景
HBase适用于海量数据存储和准实时查询。HBase能够应用在上百亿行*上百万列，实现百毫秒的查询；
HBase只有当数据量非常大的时候，才能发挥其良好的性能，如果只是百万或者千万数据，完全可以使用MySQL的分库分表实现。但是关系型数据库的字段列数需要在30以内，否则就是表的设计有问题。
查询简单(基于rowkey或者rowkey查询范围)、不涉及复杂关联的环境，如：交通(红绿灯信息采集)、海量订单流水数据(长久保存)、交易记录、数据库历史数据。
# HBase架构
在HBase中，表被分割成区域，并由区域服务器提供服务。区域被列族垂直分为“Stores”。Stores被保存在HDFS文件。下面显示的是HBase的结构。注意：术语“store”是用于区域来解释存储结构。 - 依赖于HDFS做底层的数据存储 - 依赖于MapReduce做数据计算 - 依赖于ZooKeeper做服务协调
HBase有三个主要组成部分：客户端库，主服务器和区域服务器。区域服务器可以按要求添加或删除。
# 主服务器
主服务器用于： - 分配区域给区域服务器并在Apache ZooKeeper的帮助下完成这个任务。 - 处理跨区域的服务器区域的负载均衡。它卸载繁忙的服务器和转移区域较少占用的服务器。 - 通过判定负载均衡以维护集群的状态。 - 负责模式变化和其他元数据操作，如创建表和列。
# 区域
区域只不过是表被拆分，并分布在区域服务器。
# 区域服务器
区域服务器拥有区域如下： - 与客户端进行通信并处理数据相关的操作。 - 句柄读写的所有地区的请求。 - 由以下的区域大小的阈值决定的区域的大小。
需要深入探讨区域服务器：包含区域和存储，如下图所示：
存储包含内存存储和HFiles。memstore就像一个高速缓存。在这里开始进入了HBase存储。数据被传送并保存在Hfiles作为块并且memstore刷新。
# Zookeeper
Zookeeper管理是一个开源项目，提供服务，如维护配置信息，命名，提供分布式同步等
Zookeeper代表不同区域的服务器短暂节点。主服务器使用这些节点来发现可用的服务器。
除了可用性，该节点也用于追踪服务器故障或网络分区。
客户端通过与zookeeper区域服务器进行通信。
在模拟和独立模式，HBase由zookeeper来管理。
# HBase的优缺点
# 优点
半结构化或非结构化数据: 对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用HBase，因为HBase支持动态添加列。
记录很稀疏： RDBMS的行有多少列是固定的。为null的列浪费了存储空间。HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。
多版本号数据： 依据Row key和Column key定位到的Value能够有随意数量的版本号值，因此对于须要存储变动历史记录的数据，用HBase是很方便的。比方某个用户的Address变更，用户的Address变更记录也许也是具有研究意义的。
仅要求最终一致性： 对于数据存储事务的要求不像金融行业和财务系统这么高，只要保证最终一致性就行。（比如HBase+elasticsearch时，可能出现数据不一致）
高可用和海量数据以及很大的瞬间写入量： WAL解决高可用，支持PB级数据，put性能高 适用于插入比查询操作更频繁的情况。比如，对于历史记录表和日志文件。（HBase的写操作更加高效）
业务场景简单： 不需要太多的关系型数据库特性，列入交叉列，交叉表，事务，连接等。
# 缺点
- 单一RowKey固有的局限性决定了它不可能有效地支持多条件查询
- 不适合于大范围扫描查询
- 不直接支持 SQL 的语句查询
# HBase的写流程
Client先访问zookeeper，从.META.表获取相应region信息，然后从meta表获取相应region信息
根据namespace、表名和rowkey根据meta表的数据找到写入数据对应的region信息
找到对应的regionserver 把数据先写到WAL中，即HLog，然后写到MemStore上
MemStore达到设置的阈值后则把数据刷成一个磁盘上的StoreFile文件。
当多个StoreFile文件达到一定的大小后(这个可以称之为小合并，合并数据可以进行设置，必须大于等于2，小于10——hbase.hstore.compaction.max和hbase.hstore.compactionThreshold，默认为10和3)，会触发Compact合并操作，合并为一个StoreFile，（这里同时进行版本的合并和数据删除。）
当Storefile大小超过一定阈值后，会把当前的Region分割为两个（Split）【可称之为大合并，该阈值通过hbase.hregion.max.filesize设置，默认为10G】，并由Hmaster分配到相应的HRegionServer，实现负载均衡
# HBase的读流程
首先，客户端需要获知其想要读取的信息的Region的位置，这个时候，Client访问hbase上数据时并不需要Hmaster参与（HMaster仅仅维护着table和Region的元数据信息，负载很低），只需要访问zookeeper，从meta表获取相应region信息(地址和端口等)。【Client请求ZK获取.META.所在的RegionServer的地址。】
客户端会将该保存着RegionServer的位置信息的元数据表.META.进行缓存。然后在表中确定待检索rowkey所在的RegionServer信息（得到持有对应行键的.META表的服务器名）。【获取访问数据所在的RegionServer地址】
根据数据所在RegionServer的访问信息，客户端会向该RegionServer发送真正的数据读取请求。服务器端接收到该请求之后需要进行复杂的处理。
先从MemStore找数据，如果没有，再到StoreFile上读(为了读取的效率)。