1、Hbase原理详解
1.Hadoop生态系统
- Zookeeper分布式监控中心:
- HDFS的NameNode和MapReduce高可用。
- zookeeper内部维护一个内存数据库。
- 存储Hbase一些数据（后续再谈）
- MapReduce:分布式计算框架
- Hive:数据仓库
- HBase:非关系型数据库
- HDFS:分布式文件系统
- Flume:日志收集工具（离线分析，离线数据处理）
- Sqoop:关系数据ETL工具(非关系型数据与关系型数据转换工具）
- Mahout:数据挖掘（将机器学习算法通过MapReduce做开源实现，可以通过MapReduce进行分析，提高效率）
- Pig(淘汰):数据流处理语言，通过编写sql脚本分析HDFS数据。
- Shark(淘汰):类似于Pig。
2.HBase简介
Hbase-Hadoop Database是一个高可用、高性能、面向列、可伸缩、实时读写的分布式数据库 。
可伸缩：可根据负载增减节点。
面向列：相对于行式数据库，空间利用率高。
利用HadoopHDFS作为其文件存储系统，利用Hadoop MapReduce来处理HBase中的海量数据，利用Zookeeper作为分布式协同服务。
主要用来存储非结构化和半结构化数据。
3.HBase优点
HBase是一种构建在HDFS之上的分布式、面向列的存储系统。在需要实时读写、随机访问超大规模数据集时，可以使用HBase。
尽管已经有许多数据存储和访问的策略和实现方法，但事实上大多数解决方案，特别是一些关系类型的，在构建时并没有考虑超大规模和分布式的特点。许多商家通过复制和分区的方法来扩充数据库使其突破单个节点的界限，但这些功能通常都是事后增加的，安装和维护都和复杂。同时，也会影响RDBMS的特定功能，例如联接、复杂的查询、触发器、视图和外键约束这些操作在大型的RDBMS上的代价相当高，甚至根本无法实现。
HBase从另一个角度处理伸缩性问题。它通过线性方式从下到上增加节点来进行扩展。HBase不是关系型数据库，也不支持SQL，但是它有自己的特长，这是RDBMS不能处理的，HBase巧妙地将大而稀疏的表放在商用的服务器集群上。
HBase 是Google Bigtable 的开源实现，与Google Bigtable 利用GFS作为其文件存储系统类似， HBase 利用Hadoop HDFS 作为其文件存储系统；Google 运行MapReduce 来处理Bigtable中的海量数据， HBase 同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable 利用Chubby作为协同服务， HBase 利用Zookeeper作为对应。
-
大：一个表可以有上亿行，上百万列。
-
面向列：面向列表（簇）的存储和权限控制，列（簇）独立检索。
-
稀疏：对于为空（NULL）的列，并不占用存储空间，因此，表可以设计的非常稀疏。
-
无模式：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。
-
数据多版本：每个单元中的数据可以有多个版本，默认情况下，版本号自动分配，版本号就是单元格插入时的时间戳。
-
数据类型单一：HBase中的数据都是字符串，没有类型。
4.Hbase数据模型
- RowKey：用于唯一标识Hbase中的一条数据（记录），不可重复，按照字典顺序排序，只能存储64k的字节数据，因此一般要求设计RowKey要简短。
- TimeStamp：HBase自动赋值时间戳(也可自己实现)，作为版本号，64位整型。Hbase每个cell存储单元（k:v）对同一份数据有多个版本，通过实践戳来区分版本之间的差异，按时间倒叙排序。
- CF(ColumnFamily):列族，可包含多列。权限控制，存储以及调优都是在列族层面进行的。HBase把同一列族里面的数据存储在同一目录下，由几个文件保存（StoreFile）。
- Column:列，对应key，一列可以在多个版本中维护不同数据。
- Value:数据。
- Cell:是未解析的字节数组。由{rowkey, column(=
+ ),version}唯一确定的单元。由rowkey，列族，列，版本唯一确定一个单元。中的数据，没有类型，全部是字节码形式存储。
5.Hbase体系结构
Client:
包含访问HBase的接口并维护catch来加快对Hbase访问。
再谈Zookeeper:
保证任何时候，集群中只有一个master。
保存所有Region的寻址入口。
实时监控Region Server的上下线信息。并通知Master.
存储HBase的schema和table元数据
Master:
为RegionServer分配Region
负责 RegionServer的负载均衡
发现失效的RegionServer并重新分配到其他RegionServer工作。（KeepAlive）
管理用户对table的增删改查（只负责请求传递）
RegionServer:
维护多个region，处理对这些region的IO请求，真正的增删改查操作。
水平切分运行中变得过大的region(裂变，尽量等分)。
Region:
每个region保存表中某段连续的数据(多行)，每个表一开始只有一个region，随着数据量不断增加，region增大，
当 达到一个阈值时，region就会被regionServer水平切分成两个新的region.
当region很多时，将会保存到其他regionServer上。
Store:
一个region由多个store组成，每一个store对应一个CF(列族),store包含memstore和storeFile
MemStore:
内存缓存区,数据的写操作会先写到memstore中，当memstore中的数增长到一个阈值后，regionServer会
启动flashcatch进程写入到storeFile中，每次写入形成一个单独的storeFile.
StoreFile:
当storeFile数量增长到一定阈值后，系统会进行合并(minor major compaction)，合并过程会进行版本的合并和
删除工作,，形成更大的storeFile。（优化一般主要针对major合并）
(注意：过时的版本是在合并时候才删除的，而不是插入数据时)
当一个region所有的storeFile大小和数量增长到超过一定阈值后，会把当前region分割为两个，并且由master分配
到相应的eregionServer服务器，实现负载均衡。
客户端检索数据，现在menStore找，找不到再找storeFile。
Hfile:
和StoreFile是同一个东西，只不过是站在HDFS角度称这个文件为Hfile,在Hbase角度就叫StoreFile.
HLog:
是一个普通的Hadoop SequenceFile,记录数据以及数据的操作。目的是用来做数据容灾。HLog SequenceFile的
Value是HBase的KeyValue对象，对应HFile中的KeyValue。
例如磁盘掉电导致Memstore中数据没有持久化到storeFile中时，可通过HLog恢复。
问题：
Q:为什么做一些权限控制以及调优是 在列族层 面？
A:因为在上述体系架构中，我们区分到的最小层级单元就是StoreFile，而storeFile保存的就是一个列族信息。
Q:rowKey保存在哪？
A:每个store都要携带rowkey,TimeStamp,CF,列信息唯一确定。
参考：
读写过程参考：https://www.cnblogs.com/csyuan/p/6543018.html
安装搭建参考：https://blog.csdn.net/reblue520/article/details/70888850
推荐一个牛逼得Java自学网站：http://how2j.cn?p=105437