28hbase的内部机制&存储机制&寻址机制——好程序

hbase的内部机制--存储机制-region概念-store概念-memstore概念

hbase的物理存储方式

 

 

Hbase是一个集群，master在数据管理里面是没有任何功能的，表在hbase里面存储，每一个regionserver是否要响应机器， 

hbase的存储机制

hbase的内部机制--存储机制-region概念-store概念-memstore概念
一台机器能搞定，则就不需要集群，但是高并发的访问，是负载不过来的，所以一台机器是处理不了所
有的io请求，必须获取到资源的才能先访问，所以不能实时的获取数据，所以regionServer不可能响应
所以客户端的请求，则需要分开，通过多台机器存储下来，划分区域，每台机器管一个区，region就是
在regionserver机器上，但是数据存储是在hdfs之上，regionserver与hdfs之间是透明的，根本不知道
这些机器的存储，regionserver只是管理区域范围，但是不存储数据，，每一个region都有一个STORE
就是一个列簇，目录名和列簇名是一样的，store里面还有一个manstore是内存缓冲区，存储的是热数
据，(用户经常访问的，操作过的，正在被访问的数据)，要请求某数据，则会直接与相应的
regionServer进行关联，但是如果突然机器挂了，manstore的缓存就会丢了，读的话没什么影响，但是
写呢，就会有影响，因为写的是先在缓存里面达到伐值后，才能写入hdfs中，挂了如何保证数据不丢失
，如何解决呢?可以用log日记，log也是存储在hdfs之上，(真是数据和操作日记都存储在hdfs之上)，
如果挂了，则资源被重新分配，如果一台机器起来，接管了region，则region里面是否需要预先加载数
据，重新分配相当于继承遗产，向外报告一声，所有都归我了，regionserver找数据是先找manstore，
此时manstore里面是一个空的，没有任何的数据，一个空的如何找，但是他会和hdfs交互，交互则会读
取数据，将数据读取到manstore里面，先将先将我文件上lonkey的数据读过来，然后找到log的数据，
每一次log里面保存的都是最新的操作，将log里面的操作再一次写到内存中，如果是一个权限的，是不
需要加载数据，如果客户端发送请求的，先去manstore，如果没有，则regionserver就会去找hdfs，把
这条lowkey的数据读出来，读出来后再去翻看log，有没有对我这条lowkey进行的操作，将所有对
lowkey的操作在内存读了一遍，此时的数据是最新的，将返回客户端请求的数据。

hbase的内部机制--数据可靠性--快速访问memstore-storefile
如果达到128M，则落地到hdfs，但是写完之后，manstore就会立马清空，清空之后，请求的getput的
lowkey的值又没有数据的，没有数据就再重复先hdfs上去，将log在内存执行一次，manstore始终保留
最新的数据，就是所谓的实时访问，依赖于manstore

regionserver与hdfs的交互--确定数据存储在那个文件
regionserver与hdfs的交互不可能将所有的数据都缓存起来的，一个manstore里面就是一个文件，如果
能确定rowkey在哪个范围，则交互的时候读取的时候就比较快，所以用哪个机制来判断包含哪个rowkey
或者不包含哪个rowkey，需要用到bloomfilter过滤器（牺牲数据的准确率，来达到急剧缩小内存空间
的 存储换来存储空间的节约），(做一个hashcode取模)这样就可以确认在哪些文件内，则直接读取文
件，这样大的数据就轻松的存储了

bloomfilter过滤器
最找应用于爬虫项目，爬过的就不需要再爬了，

hbase的内部机制--存储机制--region的膨胀、分裂、负载均衡
如果膨胀了则对半切，平方任务，两个region，一分为二是由regionserver来切的，刚开始还是由原来
的regionserver管理，定时向master报告负载情况，切成两个之后，分一个给别的regionserver,这就
是region的膨胀分裂

 

 

hbase的寻址机制

数据的查找，客户端的请求需要知道是哪个regionserver管理的，如何去找呢？每一个范围就是一个region，每一个regionserver里面存储着region，但是客户端请求一个数据，到底到哪里去请求呢，regionserver是管理的，可以将表明-编号-等信息写到一个region里面，描述region的位置，先读取所在region位置的信息，再读取region里面的内容，整个就是一个meta，将meta存储到zookeeper里面，但是数据不断增多呢，则很快也存完了，又回到了找不到的问题上，所以用到二级索引表，也就是root表，
1、寻找第一步先找zookeeper，获取到root表的位置，2、再依据root表的所在的regionserver，返回mate表的位置，客户端拿到位置后，3、与mate交互，返回实质数据的管理位置，4、与数据所在region交互，5、regionserver会将io发送到对应的region上面，对应的region就会找它的manstore，如果manstore有数据就会返回，如果没有呢regionserver就要和hdfs进行交互，交互就是要获取到rowkey的数据，读取过来后，先将数据写到manstore里，然后再返回到客户端。（既要读数据也要读操作日记）

如果客户端一直都在查询这几条数据，客户端是可以缓存region的位置信息，客户端发请求，先看客户端缓存，如果有则返回，如果没有再与hdfs交互，保存返回。

但是万一机器挂了呢？怎么办，一般是找这个位置重复三次，如果三次都不行，则客户端将缓存干掉，去重新找，（因为机器挂了，master会重新分配），

 

hmaster：
分配region（开始的时候默认整个大表是一个region，如果master没有了，则不能分配）
监控regionserver的负载均衡
合并之后垃圾回收（文件的合并，因为数据都是一个个的128M数据，但是不适合存储小文件，所以要合并，所有的小文件都可以做垃圾回收）
schema(如何和zookeeper直接交互，就不需要master,必须有这种结构化信息)

hregionserver的功能如下：
管理region
处理客户端的IO请求
负责切分变大的region
与hdfs交互

0.96版本之后，是没有root表了，因为经过多年的时间，任务mate表不会超过10g

实际的region的split过程：
128M*2^(n-1) > 10G ? 10G,128M*2^(n-1)

切的次数的方数乘以128M，每块的大小，与10G进行比较，就可以算出操作多少次比10G大

rowKey：rk00001    base_info:name：gaoyuanyuan    

 

 

hbase、hive和hdfs的关系

mysql的结构上固定的，hbase的列是可以扩展的，随着需求的增加可以动态的增加列