丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
HDFS：提供底层数据支撑
Master1、监控RegionServer，进行负载均衡2、RegionServer故障转移3、处理元数据变更4、处理region的分配或分裂5、处理增删改查请求
RegionServer1．负责存储HBase的实际数据2．管理分配给它的Region3．刷新缓存到HDFS4．维护Hlog5．执行压缩6．负责处理Region分片
Region：实际存储数据，HBase表会根据RowKey值被切分成不同的region存储在RegionServer中，在一个RegionServer中可以有多个不同的region
Hlog：预写日志，用于记录HBase的修改记录，写数据时，数据会首先写入内存经MemStore排序后才能刷写到StoreFile，有可能引起数据丢失，为了解决这个问题，数据会先写入Hlog，然后再写入内存。在系统故障时，数据可以Hlog重建。
Store：StoreFile存储在Store中，一个Store对应HBase表中的一个列族。
MemStore：写缓存，由于StoreFile中的数据要求是有序的，所以数据是先存储在MemStore中，排好序后，等到达刷写时机才会刷写到StoreFile，每次刷写都会形成一个新的StoreFile。StoreFile过多会影响性能，此时可进行compact操作
StoreFile：这是在磁盘上保存原始数据的实际的物理文件，是实际的存储文件。StoreFile是以Hfile的形式存储在HDFS的。每个Store会有一个或多个StoreFile，数据在每个StoreFile中都是有序的（按照Rowkey的字典顺序排序）。
命名空间，类似于关系型数据库的DatabBase概念，每个命名空间下有多个表。HBase有两个自带的命名空间，分别是hbase和default，hbase中存放的是HBase内置的表，default表是用户默认使用的命名空间。
HBase表中的每行数据都由一个RowKey和多个Column（列）组成，数据是按照RowKey的字典顺序存储的，并且查询数据时只能根据RowKey进行检索，所以RowKey的设计十分重要。
HBase中通过row和columns确定的为一个存贮单元称为cell。由{rowkey,列族：列,timeStamp}唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮（byte[]数组）。
Hbase和Hive在大数据架构中处在不同位置，Hbase主要解决实时数据查询问题，Hive主要解决海量数据处理和计算问题，一般是配合使用。
Hbase：Hadoopdatabase的简称，也就是基于Hadoop数据库，是一种NoSQL数据库，主要适用于海量明细数据（十亿、百亿）的随机实时查询，如日志明细、交易清单、轨迹行为等。
Hive：Hive是Hadoop数据仓库，严格来说，不是数据库，主要是让开发人员能够通过SQL来计算和处理HDFS上的结构化数据，适用于离线的批量数据计算。
1、KV存储，rowkey查询，2、blockCache读缓存3、数据存储按照rowkey字典排序，使用插值查找4、布隆过滤器改进查找次数
scan方法：按指定的条件获取一批记录
get方法：按指定RowKey获取唯一一条记录。Get的方法处理分两种：
①Client先访问zookeeper，找到Meta表，并获取Meta表元数据。②确定当前将要写入的数据所对应的Region和RegionServer服务器。③Client向该RegionServer服务器发起写入数据请求，然后RegionServer收到请求并响应。④Client先把数据写入到HLog，以防止数据丢失。⑤然后将数据写入到Memstore，在memstore中会对rowkey进行排序。⑥如果HLog和Memstore均写入成功，则这条数据写入成功⑦如果Memstore达到阈值，会把Memstore中的数据flush到Storefile中。⑧当Storefile越来越多，会触发Compact合并操作，把过多的Storefile合并成一个大的Storefile。⑨当Storefile越来越大，Region也会越来越大，达到阈值后，会触发Split操作，将Region一分为二。
①RegionServer保存着meta表以及表数据，要访问表数据，首先Client先去访问zookeeper，从zookeeper里面获取meta表所在的位置信息，即找到这个meta表在哪个RegionServer上保存着。②接着Client通过刚才获取到的RegionServer的IP来访问Meta表所在的RegionServer，从而读取到Meta，进而获取到Meta表中存放的元数据。③Client通过元数据中存储的信息，访问对应的RegionServer，然后扫描所在RegionServer的Memstore和Storefile来查询数据。④最后RegionServer把查询到的数据响应给Client。
1)hbaseregionserver向zookeeper注册，提供hbaseregionserver状态信息（是否在线）。2)存放Master管理的表的META元数据信息；表名、列名、key区间等。3)Client访问用户数据之前需要首先访问zookeeper中的META.表，根据META表找到用户数据的位置去访问，中间需要多次网络操作，不过client端会做cache缓存。4)Master没有单点问题，HBase中可以启动多个Master，通过Zookeeper的事件处理确保整个集群只有一个正在运行的Master。5)当RegionServer意外终止后，Master会通过Zookeeper感知到。
在HBase中，每当memstore的数据flush到磁盘后，就形成一个storefile，当storefile的数量越来越大时，会严重影响HBase的读性能，HBase内部的compact处理流程是为了解决MemStoreFlush之后，storefile数太多，导致读数据性能大大下降的一种自我调节手段，它会将文件按照策略进行合并，提升HBase的数据读性能。
1)合并文件2)清除删除、过期、多余版本的数据3)提高读写数据的效率
HBase中实现了两种compaction的方式：
触发条件：把所有的文件都遍历一遍之后每一个文件都去考虑。符合条件而进入待合并列表的文件由新的条件判断：该文件<(所有文件大小总和-该文件大小)*hbase.store.compaction.ratio比例因子。
Major操作是对Region下的Store下的所有StoreFile执行合并操作，顺序重写全部数据，重写过程中会略过做了删除标记的数据，最终合并出一个HFile文件，并将原来的小文件删除。会占用大量IO资源。
hbase.hregion.majorcompaction：majorCompaction发生的周期，单位是毫秒，默认值是7天。
合并流程
最后用临时文件夹内合并后的新HFile来替换掉之前的那些HFile文件。过期的数据由于没有被读取出来，所以就永远地消失了。如果本次合并是MajorCompaction，那么带有墓碑标记的文件也因为没有被读取出来，就真正地被删除掉了。
Hbase作为列族数据库最经常被人诟病的特性包括：无法轻易建立“二级索引”，难以执行求和、计数、排序等操作。比如，在0.92版本前，统计总行数需要使用Counter方法，执行一次MapReduceJob才能得到。虽然HBase在数据存储层中集成了MapReduce，能够有效用于数据表的分布式计算。然而在很多情况下，做一些简单的相加或者聚合计算的时候，如果直接将计算过程放置在regionServer端，能够减少通讯开销，从而获得很好的性能提升。于是，HBase在0.92之后引入了协处理器(coprocessors)，能够轻易建立二次索引、复杂过滤器、求和、计数以及访问控制等。
协处理器包括observer和endpoint
类似于传统数据库中的触发器，当数据写入的时候会调用此类协处理器中的逻辑。主要的作用是当执行被监听的一个操作的时候，可以触发另一个我们需要的操作，比如说监听数据库数据的增删过程，我们可以在hbase数据库插入数据或者删除数据之前或之后进行一系列的操作。
二级索引基于此触发器构建。
类似传统数据库中的存储过程，客户端可以调用Endpoint执行一段Server端代码，并将Server端代码的结果返回给客户端进一步处理，常用于Hbase的聚合操作。min、max、avg、sum、distinct、groupby
协处理器的加载方式有两种，我们称之为静态加载方式(StaticLoad)和动态加载方式(DynamicLoad)。静态加载的协处理器称之为SystemCoprocessor，动态加载的协处理器称之为TableCoprocessor
静态加载：通过修改hbase-site.xml这个文件来实现，启动全局aggregation，能过操纵所有的表上的数据。只需要添加如下代码:
动态加载启用表aggregation，只对特定的表生效。通过HBaseShell来实现。①disable指定表。hbase>disable‘table名’；②添加aggregation
hbase>alter'mytable',METHOD=>'table_att','coprocessor'=>'|org.apache.Hadoop.hbase.coprocessor.AggregateImplementation||'③重启指定表hbase>enable‘table名’
数据在写入HBase的时候，先写WAL，再写入缓存。通常情况下写缓存延迟很低，WAL机制一方面是为了确保数据即使写入缓存后数据丢失也可以通过WAL恢复，另一方面是为了集群之间的复制。默认WAL机制是开启的，并且使用的是同步机制写WAL。
如果业务不特别关心异常情况下部分数据的丢失，而更关心数据写入吞吐量，可考虑关闭WAL写，这样可以提升2~3倍数据写入的吞吐量。
如果业务不能接受不写WAL，但是可以接受WAL异步写入，这样可以带了1~2倍性能提升。
HBase中可以通过设置WAL的持久化等级决定是否开启WAL机制、以及HLog的落盘方式。
WAL的持久化等级分为如下四个等级：
除了在创建表的时候直接设置WAL存储级别，也可以通过客户端设置WAL持久化等级，代码：put.setDurability(Durability.SYNC_WAL);
hbase为了保证随机读取的性能，所以storefile的数据按照rowkey的字典序存储。当客户端的请求在到达regionserver之后，为了保证写入rowkey的有序性，不能将数据立刻写入到hfile中，而是将每个变更操作保存在内存中，也就是memstore中。memstore能够保证内部数据有序。当某个memstore达到阈值后，会将Region的所有memstore都flush到hfile中（Flush操作为Region级别），这样能充分利用hadoop写入大文件的性能优势，提高写入性能。
由于memstore是存放在内存中，如果regionserver宕机，会导致内存中数据丢失。所有为了保证数据不丢失，hbase将更新操作在写入memstore之前会写入到一个WAL中。WAL文件是追加、顺序写入的，WAL每个regionserver只有一个，同一个regionserver上所有region写入同一个的WAL文件。这样当某个regionserver失败时，可以通过WAL文件，将所有的操作顺序重新加载到memstore中。
如果一个HRegion中MemStore过多（Columnfamily设置过多），每次flush的开销必然会很大，并且生成大量的HFile影响后续的各项操作，因此建议在进行表设计的时候尽量减少Columnfamily的个数。
用户可以通过shell命令分别对一个Table或者一个Region进行flush：
hbase.hregion.memstore.block.multiplier默认值：2Region级别限制，当Region中所有MemStore的大小总和达到了设定值（hbase.hregion.memstore.block.multiplierhbase.hregion.memstore.flush.size，默认2128M=256M），会触发MemStoreflush。
hbase.regionserver.global.memstore.upperLimit默认值：0.4RegionServer级别限制，当一个RegionServer中所有MemStore的大小总和达到了设定值（hbase.regionserver.global.memstore.upperLimithbase_heapsize，默认0.4RS堆内存大小），会触发RegionServer级别的MemStoreflush。
hbase.regionserver.global.memstore.lowerLimit默认值：0.38与hbase.regionserver.global.memstore.upperLimit类似，区别是：当一个RegionServer中所有MemStore的大小总和达到了设定值（hbase.regionserver.global.memstore.lowerLimithbase_heapsize，默认0.38RS堆内存大小），会触发部分MemStoreflush。
Flush顺序是按照Region的总MemStore大小，由大到小执行，先操作MemStore最大的Region，再操作剩余中最大的Region，直至总体MemStore的内存使用量低于设定值（hbase.regionserver.global.memstore.lowerLimit＊hbase_heapsize）。
hbase.regionserver.maxlogs默认值：32当一个RegionServer中HLog数量达到设定值，系统会选取最早的一个HLog对应的一个或多个Region进行flush。
当增加MemStore的大小以及调整其他的MemStore的设置项时，也需要去调整HLog的配置项。否则，WAL的大小限制可能会首先被触发。因而，将利用不到其他专门为Memstore而设计的优化。
通过WAL限制来触发Memstore的flush并非最佳方式，这样做可能会会一次flush很多Region，尽管“写数据”是很好的分布于整个集群，进而很有可能会引发flush“大风暴”。
为了减少flush过程对读写的影响，HBase采用了类似于两阶段提交的方式，将整个flush过程分为三个阶段：
hbase支持如下类型的布隆过滤器：
如果用户随机查找一个rowkey，位于某个region中两个开始rowkey之间的位置。对于hbase来说，它判断这个行键是否真实存在的唯一方法就是加载这个region，并且扫描它是否包含这个键。当我们get数据时，hbase会加载很多块文件。
采用布隆过滤器后，它能够准确判断该StoreFile的所有数据块中，是否含有我们查询的数据，从而减少不必要的块加载，增加hbase集群的吞吐率。
1、布隆过滤器的存储在哪开启布隆后，HBase会在生成StoreFile时包含一份布隆过滤器结构的数据，称其为MetaBlock；MetaBlock与DataBlock（真实的KeyValue数据）一起由LRUBlockCache维护。所以，开启bloomfilter会有一定的存储及内存cache开销。大多数情况下，这些负担相对于布隆过滤器带来的好处是可以接受的。
2、采用布隆过滤器后，如何get数据在读取数据时，hbase会首先在布隆过滤器中查询，根据布隆过滤器的结果，再在MemStore中查询，最后再在对应的HFile中查询。
3、采用ROW还是ROWCOL
BlockCache名称中的Block指的是HBase的Block。BlockCache的工作原理跟其他缓存一样：读请求到HBase之后先尝试查询BlockCache，如果获取不到就去StoreFile和Memstore中去获取。如果获取到了则在返回数据的同时把Block块缓存到BlockCache中。BlockCache默认是开启的。BlockCache的实现方案有以下几种：
近期最少使用算法。读出来的block会被放到BlockCache中待下次查询使用。当缓存满了的时候，会根据LRU的算法来淘汰block。
这是一种堆外内存的解决方案。不属于JVM管理的内存范围，说白了，就是原始的内存区域了。回收堆外内存的时候JVM几乎不会停顿，可以避免GC过程中遇见的系统卡顿与异常。
BucketCache借鉴SlabCache也用上了堆外内存。不过它以下自己的特点：
把不同类型的Block分别放到LRUCache和BucketCache中。IndexBlock和BloomBlock会被放到LRUCache中。DataBlock被直接放到BucketCache中，所以数据会去LRUCache查询一下，然后再去BucketCache中查询真正的数据。其实这种实现是一种更合理的二级缓存，数据从一级缓存到二级缓存最后到硬盘，从小到大，存储介质也由快到慢。考虑到成本和性能的组合，比较合理的介质是：LRUCache使用内存->BuckectCache使用SSD->HFile使用机械硬盘。
在开启此功能后，数据块会以它们on-disk的形式缓存到BlockCache。与默认的模式不同点在于：默认情况下，在缓存一个数据块时，会先解压缩然后存入缓存。而lazyBlockCachedecompression直接将压缩的数据块存入缓存。
如果一个RegionServer存储的数据过多，无法适当的将大部分数据放入缓存，则开启这个功能后，可以提升50%的吞吐量，30%的平均延迟上升，增加80%垃圾回收，以及2%的整体CPU负载。
压缩默认关闭，若要开启，可以在hbase-site.xml文件里设置hbase.block.data.cachecompressed为true
一个Region就是一个表的一段Rowkey的数据集合。一旦Region的负载过大或者超过阈值时，它就会被分裂成两个新的Region。Region的拆分分为自动拆分和手动拆分。自动拆分可以采用不同的策略。
这个过程是由RegionServer完成的，其拆分流程如下。
Region的自动拆分主要根据拆分策略进行，主要有以下几种拆分策略：
0.94版本前唯一拆分策略，按照固定大小来拆分Region。Region中的最大Store大于设置阈值（hbase.hregion.max.filesize：默认10GB）触发拆分。拆分点为最大Store的rowkey的顺序中间值。弊端：切分策略对于大表和小表没有明显的区分。阈值(hbase.hregion.max.filesize)设置较大对大表友好，但小表有可能不会触发分裂，极端情况下可能就1个。如果设置较小则对小表友好，但大表就会在整个集群产生大量的region，占用集群资源。
0.94版本~2.0版本默认切分策略。切分策略稍微有点复杂，基于ConstantSizeRegionSplitPolicy思路，一个region大小大于设置阈值就会触发切分。但是这个阈值并不是固定值，而是会在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系.
在IncreasingToUpperBoundRegionSplitPolicy的基础上增加了对拆分点（splitPoint，拆分点就是Region被拆分处的rowkey）的自定义，可以将rowKey的前多少位作为前缀。保证相同前缀的rowkey拆分至同一个region中。
KeyPrefixRegionSplitPolicy根据rowkey的固定前几位来进行判断，而DelimitedKeyPrefixRegionSplitPolicy是根据分隔符来判断的。比如你定义了前缀分隔符为_，那么host1_001和host12_999的前缀就分别是host1和host12。
2.0版本默认切分策略，相比IncreasingToUpperBoundRegionSplitPolicy简化，基于当前表的region个数进行规划，对于大集群中的大表、小表会比IncreasingToUpperBoundRegionSplitPolicy更加友好，小表不会再产生大量的小region，而是适可而止。
它会通过拆分热点Region来缓解热点Region压力，但也会带来很多不确定性因素，因为无法确定下一个被拆分的Region是哪个。
调用hbaseshell的split方法，split的调用方式如下：
split'regionName'#format:'tableName,startKey,id'比如：
split'test_table1,c,1476406588669.96dd8c68396fda69'这个就是把test_table1,c,1476406588669.96dd8c68396fda69这个Region从新的拆分点999处拆成2个Region。
如果有很多Region，则MemStore也过多，数据频繁从内存Flush到HFile，影响用户请求，可能阻塞该Region服务器上的更新操作。过多的Region会增加服务器资源的负担。当删了大量的数据，或Region拆分过程中产生了过多小Region，这时可以Region合并，减轻RegionServer资源负担。
合并通过使用org.apache.hadoop.hbase.util.Merge类来实现。例如把以下两个Region合并：
test_table1,b,1476406588669.39eecae03539ba0a63264c24130c2cb1.test_table1,c,1476406588669.96dd8c68396fda694ab9b0423a60a4d9.就需要在Linux下（不需要进入hbaseshell）执行以下命令：
hbaseorg.apache.hadoop.hbase.util.Mergetest_table1test_table1,b,1476406588669.39eecae03539ba0a63264c24130c2cb1.test_table1,c,1476406588669.96dd8c68396fda694ab9b0423a60a4d9.此方式需要停止整个Hbase集群，所以后来又增加了online_merge（热合并）。
hbaseshell提供了一个命令叫online_merge，通过这个方法可以进行热合并，无需停止整个Hbase集群。
假设要合并以下两个Region：
test_table1,a,1476406588669.d1f84781ec2b93224528cbb79107ce12.test_table1,b,1476408648520.d129fb5306f604b850ee4dc7aa2eed36.online_merge的传参是Region的hash值。只需在hbaseshell中执行以下命令：
merge_region'd1f84781ec2b93224528cbb79107ce12','d129fb5306f604b850ee4dc7aa2eed36'22、Region负载均衡当Region分裂之后，Region服务器之间的Region数量差距变大时，Master便会执行负载均衡来调整部分Region的位置，使每个Region服务器的Region数量保持在合理范围之内，负载均衡会引起Region的重新定位，使涉及的Region不具备数据本地性。
Region的负载均衡由Master来完成，Master有一个内置的负载均衡器，在默认情况下，均衡器每5分钟运行一次，用户可以配置。负载均衡操作分为两步进行：首先生成负载均衡计划表，然后按照计划表执行Region的分配。
执行负载均衡前要明确，在以下几种情况时，Master是不会执行负载均衡的。
Master内部使用一套集群负载评分的算法，来评估HBase某一个表的Region是否需要进行重新分配。这套算法分别从Region服务器中Region的数目、表的Region数、MenStore大小、StoreFile大小、数据本地性等几个维度来对集群进行评分，评分越低代表集群的负载越合理。
确定需要负载均衡后，再根据不同策略选择Region进行分配，负载均衡策略有三种，如下表所示。
根据上述策略选择分配Region后再继续对整个表的所有Region进行评分，如果依然未达到标准，循环执行上述操作直至整个集群达到负载均衡的状态。
Hbase建表时默认单region，所有数据都会写入此region，超过阈值（hbase.Region.max.filesize，默认10G）会此region会进行拆分，分成2个region。在此过程中，会产生三个问题：
基于此我们可以在建表时进行预分区，创建多个空region，减少由于split带来的资源消耗，从而提高HBase的性能。预分区时会确定每个region的起始和终止rowky，rowkey设计时确保均匀的命中各个region，就不会存在写热点问题。当然随着数据量的不断增长，该split的还是要进行split。
ColumnFamily划分标准一般根据数据访问频度，如一张表里有些列访问相对频繁，而另一些列访问很少，这时可以把这张表划分成两个列族，分开存储，提高访问效率。
HBase中每张表的列族个数建议设在1~3之间，列族数过多可能会产生以下影响：
对Flush的影响在HBase中，数据首先写入memStore的，每个列族都对应一个store，store中包含一个MemStore。列族过多将会导致内存中存在越多的MemStore；而MemStore在达到阈值后会进行Flush操作在磁盘生产一个hFile文件。列族越多导致HFile越多。
对Split的影响当HBase表中某个Region过大会触发split拆分操作。如果有多个列族，且列族间数据量相差较大，这样在RegionSpli时会导致原本数据量很小的HFil文件进一步被拆分，从而产生更多的小文件。
对Compaction的影响目前HBase的Compaction操作也是Region级别的，过多的列族且列族间数据量相差较大，也会产生不必要的IO。
对HDFS的影响HDFS其实对一个目录下的文件数有限制的。列族数过多，文件数可能会超出HDFS的限制。小文件问题也同样会出现。
对RegionServer内存的影响一个列族在RegionServer中对应于一个MemStore。每个MemStore默认占用128MB的buffer。如果列族过多，MemStore会占用RegionServer大量内存。
hbase.hregion.max.filesize：此参数定义了单个region的最大数据量。
1）当region太小，触发split的机率增加，split过程中region会下线，影响访问服务。
2）当region太大，由于长期得不到split，会发生多次compaction，将数据读一遍并重写一遍到hdfs上，占用IO。降低系统的稳定性与吞吐量。
hbase数据会首先写入MemStore，超过配置后会flush到磁盘成为StoreFile，当StoreFile的数量超过配置之后，会启动compaction，将他们合并为一个大的StoreFile。
当合并后的Store大于max.filesize时，会触发分隔动作，将它切分为两个region。hbase.hregion.max.filesize不宜过大或过小，经过实战，生产高并发运行下，最佳大小5-10GB！
推荐关闭某些重要场景的hbase表的major_compact！在非高峰期的时候再去调用major_compact，这样可以减少split的同时，显著提供集群的性能，吞吐量、非常有用。
一、出现热点问题原因1)hbase的中的数据是按照字典序排序的，当大量连续的rowkey集中写在个别的region，各个region之间数据分布不均衡；2)创建表时没有提前预分区，创建的表默认只有一个region，大量的数据写入当前region；3)创建表已经提前预分区，但是设计的rowkey没有规律可循
宕机分为Master宕机和regionServer宕机
1、Master主要负责实现集群的负载均衡和读写调度，没有单点问题，所以集群中可以存在多个Master节点。2、通过热备方式实现Master高可用，并在zookeeper上进行注册3、activemaster会接管整个系统的元数据管理任务，zk以及meta表中的元数据，相应用户的管理指令，创建、删除、修改，mergeregion等
引起RegionServer宕机的原因各种各样，FullGC、网络异常、官方Bug导致（closewait端口未关闭）等。
具体流程
1）blocksize越大，配置压缩算法，压缩的效率就越好，有利于提升写入性能；2）但是由于读数据以block块为单位，所以越大的block块，随机读的性能较差。3）如果要提升写入的性能，一般扩大到128kb或者256kb，可以提升写数据的效率，也不会太大影响随机读性能。