原文地址：https://blog.csdn.net/lavorange/article/details/82775275
一、简介
HBase - Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。
HBase是Google BigTable的开源实现，类似Google BigTable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable利用Chubby作为协同服务，HBase利用Zookeeper作为对应。
优势：
>写入性能高，且几乎可以无限扩展。
>海量数据下(100TB级别表)的查询依然能保持在5ms级别。
>存储容量大，不需要做分库分表，切勿维护简单。
>表的列可以灵活配置，1行可以有多个非固定的列。
劣势：
>并不能保证100%时间可用，宕机回复时间根据写入流量不同在几秒到几十秒内。
>查询便利性上缺少支持sql语句。
>无索引，查询必须按照RowKey严格查询，不带RowKey的filter性能较低。
>对于查询会有一些毛刺，特别是在compact时，平均查询延迟在2~3ms，但是毛刺时会升高到几十到100多毫秒。
二、HBase使用场景
2.1 历史数据存储类应用（约占七成）
这类应用范围比较广，特别对于历史订单、历史记录、日志类的业务比较友好。由于以上这些业务的数据量巨大，传统的书库很难hold住，而这类应用往往查询量相对较少，查询随机性较大（无热点访问），对于mysql，redis来说存储成本太高，hbase用在这里非常合适。
2.2 分析型应用（约占两成）
主要是指配合spark，MapReduce，storm等来做数据分析。由于以上这些计算组件对于中间状态的保存具有局限性，当然spark内也有全局变量的概念，但是毕竟不是存储，不可能缓存一年的中间结果做cache。二有些应用又需要用到可能很长一段时间的数据做训练或者比对，这个时候hbase的优势就可以发挥出来了。
2.3 在线读写型应用（约占一成）
可以理解为对mysql或者redis的一种替换做法，但是这类应用比较在意可用性、稳定性以及sql、索引等支持。hbase的劣势较大，应用范围较窄。只有在一种情况下会是用--mysql或者redis的容量实在无法支撑数据量了，而应用对可用性的要求可以有一定成都的容忍。
三、HBase数据模型
Column Family
RowKey Timestamp Column1 Column2
r1 t3 c1
t2 c2
t1 c3
r2 t5 c4 c5
t4 c6
RowKey:
行键，Table的主键，用来检测记录。RowKey决定一行数据，rowKey可以是任意字符串（最大长度是64KB，实际应用中长度一般为10-100bytes左右）， 在HBase内部，rowKey保存为字节数据。数据按照RowKey的字典序（byte order）排序存储，因此设计key时要充分排序存储这个特征，将经常一起读取的行存储放到一起。
HBase支持单行事务，行的一次读写是原子操作（不论一次读写多少列），这个设计决策能够使用用户很容易的理解程序在对同一个行进行并发更新操作时的行为。
Column Family列族 & qualifier列：
>Hbase表中的每个列都属于某个列族，列族必须作为表模式定义的一部分预先给出。如：create 'table', 'family'。
>列名以列族作为前缀，每个"列簇"都可以是多个列成员，如course:math, course:english。
>权限控制、存储、调优都是在列簇层面进行。
>Hbase把同一列簇里面的数据存储在同一个目录下，由几个文件保存。
>Hbase currently does not do well with anything above two or three column families so keep the number of column families in your schema low。
Cell：
>由 {row key, column family, column qualifier, version} 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。
四、HBase体系结构
Client：
HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信，对于管理类操作，Client与HMaster进行RPC；对于数据读写类操作，Client与HRegionServer进行RPC。Client会通过zk定位到.META.表，根据.MATA.查找需要服务的RegionServer，连接RegionServer进行读写；Client会缓存.META.表信息，下次可以直接连到RegionServer中。
Zookeeper：
保证任何时候，集群中只有一个master；存储所有Region的寻址入口；实时监控Region Server的上线和下线信息，并实时通知Master；存储HBase的schema和table元数据。
HMaster：
HMaster没有单点问题，HBase中可以启动多个HMaster，通过ZK的Master Election机制保证有且仅有一个Master运行，HMaster在功能上主要负责Table和Region的管理工作：
>管理用户对Table的CRUD操作。
>管理HRegionServer的负载均衡，调整Region分布
>在Region Split后，负责新Region的分配
>在HRegionServer停机后，负责失效HRegionServer上的Regions迁移
>HDFS的垃圾文件回收
Client访问HBase上数据的过程并不需要HMaster参与（寻址访问ZK，数据读写访问HRegionServer），HMaster仅仅维护table和region的元数据信息，负载很低。
HRegionServer：
HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region，HRegion中由多个HStore组成。每个HStore对应了Table中的一个Column Family的存储，可以看出每个Column Family其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个Column Family中，这样最高效。
HRegion：
HBase自动把表水平划分成多个区域(Region)，每个region会保存一个表里面某段连续的数据；每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一定阈值的时候，region就会等分为两个新的region(裂变)；当table中的行不断增多，就会有越来越多的region。这样一张完整的表被保存在多个RegionServer上。
HStore：
HStore是HBase存储的核心，其中由两部分组成：memstore 和 storefiles。
一个region由多个store组成，一个store对应一个CF（列族）；store包括位于内存中的memcache和位于磁盘的storefile，写操作先写入memstore，当memstore中的数据达到某个阈值，hregionserver会启动flashcache进程写入storefile，每次写入形成单独的storefile；当storefile文件的数量增长到一定阈值后，系统会进行合并(minor，major compaction)，在合并过程中会进行版本合并和删除工作(majar)，形成更大的storefile；当一个region中所有的storefile的大小和数量超过一定阈值后，会把当前的region分割成为两个，并由hmaster分配到相应regionserver服务器，实现负载均衡；客户端检索数据，先在memstore里面找，找不到在storefile里面找。
HLog：
在分布式系统环境中，无法避免系统出错或者宕机，因此一旦HRegionServer意外退出，MemStore中的内存数据将会丢失，这就需要引入HLog了。每个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中（HLog文件格式见后续），HLog文件定期会滚动出新的，并删除旧的文件（已持久化到StoreFile中的数据）。当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的 HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应region的目录下，然后再将失效的region重新分配，领取 到这些region的HRegionServer在Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。
————————————————
版权声明：本文为CSDN博主「忆之独秀」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lavorange/article/details/82775275