标签：也会 默认 实例 面向 扩展性 排序 分享图片 keep 增加
hbase是一个构建在hdfs上的分布式列存储系统；hbase是apache hadoop生态系统中的重要一员，主要用于海量结构化数据存储
从逻辑上讲，hbase将数据按照表、行和列进行存储
hbase表特点：
1.大：一个表可以有数十亿行，上百万列；
2.无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；
3.面向列：面向列（族）的存储和权限控制，列（族）独立检索；
4.稀疏：对于空（null）的列，并不占用存储空间，表可以设计的非常稀疏；
5.数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；
6.数据类型单一：hbase中的数据都是字符串，没有类型
hbase与hdfs的对比：
1.两者都具有良好的容错性和扩展性，都可以扩展到成百上千个节点。
2.hdfs适合批处理场景,不支持数据随机查找，不适合增量数据处理，不支持数据更新。
行存储与列存储：
传统行式数据库：
1.数据是按行存储的
2.没有索引的查询使用大量I/O
3.建立索引和物化视图需要花费大量时间和资源
4.面向查询的需求，数据库必须被大量膨胀才能满足性能要求
列式数据库:
1.数据是按列存储-每一列单独存放
2.数据即是索引
3.指访问查询涉及的列-大量降低系统I/O
4.每一列由一个线索来处理-查询的并发处理
5.数据类型一致，数据特征相似-高效压缩
第二：hbase数据模型
hbase是基于Google BigTable模型开发的，典型的key/value系统
第一：hbase介绍
hbase是一个构建在hdfs上的分布式列存储系统；
hbase是apache hadoop生态系统中的重要一员，主要用于海量结构化数据存储
从逻辑上讲，hbase将数据按照表、行和列进行存储
hbase表特点：
1.大：一个表可以有数十亿行，上百万列；
2.无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；
3.面向列：面向列（族）的存储和权限控制，列（族）独立检索；
4.稀疏：对于空（null）的列，并不占用存储空间，表可以设计的非常稀疏；
5.数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；
6.数据类型单一：hbase中的数据都是字符串，没有类型
hbase与hdfs的对比：
1.两者都具有良好的容错性和扩展性，都可以扩展到成百上千个节点。
2.hdfs适合批处理场景,不支持数据随机查找，不适合增量数据处理，不支持数据更新。
行存储与列存储：
传统行式数据库：
1.数据是按行存储的
2.没有索引的查询使用大量I/O
3.建立索引和物化视图需要花费大量时间和资源
4.面向查询的需求，数据库必须被大量膨胀才能满足性能要求
列式数据库:
1.数据是按列存储-每一列单独存放
2.数据即是索引
3.指访问查询涉及的列-大量降低系统I/O
4.每一列由一个线索来处理-查询的并发处理
5.数据类型一致，数据特征相似-高效压缩
第二：hbase数据模型
hbase是基于Google BigTable模型开发的，典型的key/value系统
第三：hbase物理模型
每个column family存储在HDFS上的一个单独文件中；
Key和Version number在每个column family中均有一份
空值不被保存
eg:
info Column Family:
roles Column Family
数据物理存储：
1.Table中所有的行都按照row key的字典序列排列；
2.Table在行的方向上被分割为多个Region；
3.Region按照大小分割的，每个表开始只有一个region，随着数据的增多，region不断的增大，当增大到一个阀值的时候，region就会等分成两个新的region，之后会有越来越多的region；
4.Region是Hbase中分布式存储和负载均衡的最小单元，不同的region分布在不同RegionServer上；
5.Region虽然是分布式存储的最小单元，但并不是存储的最小单元。
1）Region是由一个或者多个Store组成，每个store保存一个columns family；
2）每个Store又由一个memStore和0或多个StoreFile组成
3）memStore存储在内存中，StoreFile存储在HDFS上。
第四：hbase基础架构
Hbase架构：
在分布式的生产环境中，HBase 需要运行在 HDFS 之上，以 HDFS 作为其基础的存储设施。在 HBase 的集群中主要由 Master 和 Region Server 组成，以及 Zookeeper
Hbase相关的组件：
Clinet：
包含访问Hbase的接口，并维护cache来加快对Hbase的访问。
zookeeper:
保证任何时候，集群中只有一个master
存储所有Region的寻址入口
实时监控Region Server的上线或者下线信息，并实时通知给Master
存储HBase的schema和table元数据
zookeeper作用：
HBase依赖zk；
默认情况下Hbase管理zk实例，eg：启动或者停止zk
Master与RegionServers启动时会向zk注册
Zookeeper的引入使得Master不在是单点故障
Master:
为Region Server分配region
负责Region Server的负载均衡
发现失效的Region Server并重新分配他上面的region
管理用户对table的增删改查操作
Region Server:
维护region，处理对这些region的IO请求
负责切分在运行过程中变得过大的region
-ROOT-表与-META-表：
-ROOT-表：
包含-META-表所在的region列表，该表只会有一个Region；
zookeeper中记录了-ROOT-表的位置
-META-表：
包含所有的用户空间region列表，以及RegionServer的服务器地址
详解：
1.HBase的所有Region元数据被存储在.META.表中，随着Region的增多，.META.表中的数据也会增大，并分裂成多个新的Region。为了定位.META.表中各个Region的位置，把.META.表中所有Region的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息。所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，如上图所示。
2.-ROOT-表永远不会被分割，它只有一个Region，这样可以保证最多只需要三次跳转就可以定位任意一个Region。为了加快访问速度，.META.表的所有Region全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据，则询问相关.META.表的Region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的.META.表在哪里。最后，如果前面的信息全部失效，则通过ZooKeeper重新定位Region的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的Region。
高可用
Write-Ahead-Log（WAL）保障数据高可用
理解高可用首先：必须理解下HLog的作用，HBase中的Hlog机制是WAL的一种实现，而WAL是事务机制中常见的一致性的实现方式。每个RegionServer中都会有一个HLog的实例，RegionServer会将更新操作（put，delete等），先记录到WAL（也就是HLog中），然后再将其写入到Store的MemStore，最终Memstore达到一定的阀值后，在写入到HFile中，这样就保证了HBase的写的可靠性，若没有WAL，当RegionServer挂掉的时候，MemStore还没有写到HFile的数据，或者说StoreFile没有保存的时候，数据会丢失。（说到这里或许有人会问，假如HFile本身丢失了怎么办，这是由HDFS来保证的。在HDFS中的数据默认会有3份）
HFile是由很多个数据块（Block）组成，并且有一个固定的结尾块，其中的数据块是由一个Header和多个Key-Value的键值对组成，在结尾的数据块中包含了数据相关的索引信息，系统也是通过结尾的索引信息找到HFile中的数据。
组件的高可用
Master容错：Zookeeper重新选择一个新的Master
无Master过程中，数据读取任然照常进行
无Master过程中，region切分、负载均衡等无法进行
RegionServer容错：
定时向Zookeeper汇报心跳，如果一旦一段时间内未出现心跳，Master将该RegionServer上的Region重新分配到其他的RegionServer上；
失效的服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer上
zookeeper容错：zookeeper是一个可靠的服务
一般是3到5个zookeeper实例
读写流程
写操作：
1）client通过zookeeper的调度，向regionserver发出写数据的请求，在Region中写数据
2）数据首先记录在HLog中，然后再将其写入到Store的MemStore，直到MemStore达到预定阀值
3）MemStore中的数据被Flush成一个StoreFile
4）随着StoreFile文件的不断增多，当其数据增长到一定阀值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除
5）StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile
6）单个StoreFile大小超过一定阀值后，触发Split操作，把当前Region Split成2个新的Region，父Region会下线，新Split出的2个子Region会被HMaster分配到相应的RegionServer上，使原先1个Region的压力得以分流到2个Region上面
通过上述的写流程可以发现，HBase更新、删除等操作都是在后续Compact历程中进行的，使得用户的写操作只要进入内存就可以立刻返回，实现可HBase I/0的高性能。
读操作：
1）client访问zk，查找-ROOT-表，获取.META.表的信息。
2）从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer。
3）通过RegionServer获取需要查找的数据
4）RegionServer的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据，读请求先到MemStore中查数据，查不到就到BlockCache中查，在查不到就会到StoreFile上读，并把读的结果放入BlockCache中。
读取流程：client-->zookeeper-->-ROOT-表-->.META.表-->RegionServer-->Region-->client
标签：也会 默认 实例 面向 扩展性 排序 分享图片 keep 增加
原文地址：http://blog.51cto.com/13981400/2337970
