做产品类网站有哪些内容,互联网定制产品网站,网站建设建设报价,代理招生平台传统的ACID数据库#xff0c;可扩展性上受到了巨大的挑战。而HBase这类系统#xff0c;兼具可扩展性的同时#xff0c;也提出了类SQL的接口。 HBase架构组成 HBase采用Master/Slave架构搭建集群#xff0c;它隶属于Hadoop生态系统#xff0c;由一下类型节点组成#xff1…传统的ACID数据库可扩展性上受到了巨大的挑战。而HBase这类系统兼具可扩展性的同时也提出了类SQL的接口。 HBase架构组成 HBase采用Master/Slave架构搭建集群它隶属于Hadoop生态系统由一下类型节点组成HMaster节点、HRegionServer节点、ZooKeeper集群而在底层它将数据存储于HDFS中因而涉及到HDFS的NameNode、DataNode等总体结构如下 HBase Client通过RPC方式和HMaster、HRegionServer通信 HMaster节点 协调HRegionServer 启动时HRegion的分配以及负载均衡和修复时HRegion的重新分配。监控集群中所有HRegionServer的状态(通过与zookeeper的Heartbeat和监听ZooKeeper中的状态并不直接和slave相连)Admin职能创建、删除、修改Table的定义。 HRegionServer节点 存放和管理本地HRegion。读写HDFS管理Table中的数据。Client直接通过HRegionServer读写数据一个HRegionServer可以存放1000个HRegion(出自BigTable)HBase使用RowKey将表水平切割成多个HRegion从HMaster的角度每个HRegion都纪录了它的StartKey和EndKey第一个HRegion的StartKey为空最后一个HRegion的EndKey为空由于RowKey是排序的因而Client可以通过HMaster快速的定位每个RowKey在哪个HRegion中。 底层Table数据存储于HDFS中而HRegion所处理的数据尽量和数据所在的DataNode在一起实现数据的本地化数据本地化并不是总能实现比如在HRegion移动(如因Split)时需要等下一次Compact才能继续回到本地化。 ZooKeeper集群是协调系统 存放整个HBase集群的元数据以及集群的状态信息(avalible/alive)。实现HMaster主从节点的failover并在HRegionServer宕机的时候通知HMaster。 HBase的第一次读写 0.96以前的版本(参考BigTable) HBase有两个特殊的表ROOT表(唯一)和META表。其中ROOT表的位置保存在ZooKeeper中它存储了META表的RegionInfo信息。而META表 则存储了用户Table的RegionInfo信息它可以被切分成多个HRegion。 从ZooKeeper读取ROOT表位置HRegionServer中根据请求的Root表和RowKey读取META表位置最后从该HRegionServer中读取META表的内容而获取此次请求需要访问的HRegion所在的位置读取内容。所以需要3次读取才能获取目标HRegion的位置然后第4次请求才能获取真正的数据。所以一般客户端有ROOT表位置喝内容的缓存。我们来看看为什么BigTable要选择三级索引结构BigTable论文里面提到一般每个HRegion大小为128M每行META数据1KB。所以三级索引可以索引2^34个HRegion可以索引很大很大的数据了。但是如果只有二级索引我们就只能索引16TB在大数据情况下这是完全不够。 0.96后的版本 显然只构建两级索引可以大大加快查询速度为了两级索引的情况下也能支持大数据量。我们可以加大每个HRegion的大小如果每个HRegion大小为2GB两级索引就可以支持4PB。同样客户端会缓存查询后的HRegion位置信息。 hbase:meta表 meta表存储了所有用户HRegion的位置信息它的RowKey是tableName,regionStartKey,regionId,replicaId等它只有info列族这个列族包含三个列他们分别是 regioninfo列是RegionInfo的proto格式regionId,tableName,startKey,endKey,offline,split,replicaIdserver格式HRegionServer对应的server:portserverstartcode格式是HRegionServer的启动时间戳。 meta表(root表)结构 HRegionServer详解 HRegionServer一般和DataNode在同一台机器上运行实现数据的本地性。HRegionServer包含多个HRegion由WAL(HLog)、BlockCache、MemStore、HFile组成。 WAL(Write Ahead Log, HLog) 所有写操作都会先保证将数据写入这个Log文件(每个HRegionServer只有一个)后才会真正更新MemStore最后写入HFile中。这样即使HRegionServer宕机我们依然可以从HLog中恢复数据。 由于HDFS只允许同一时刻对一个文件只能一个客户端写入所以对HLog只能单线程写入。这样很明显会影响性能所以再HBase1.0以后的版本多个WAL并行写(MultiWAL)该实现采用HDFS的多个管道写以单个HRegion为单位。 BlockCache 读缓存Hbase中有两种(BlockCache为HRegionServer内存大小的20%) on-heap LruBlockCacheLruBlockCache受到java gc的影响不稳定BucketCache(通常是off-heap)一般采用这种方式自己管理内存更加稳定HRegion HRegion是一个表的一部分表的横切的一部分 HStore HRegion由多个Store(HStore)构成每个HStore对应了一个Table在这个HRegion中的一个Column Family即每个Column Family就是一个集中的存储单元因而最好将具有相近IO特性的Column存储在一个Column Family以实现高效读取(数据局部性原理可以提高缓存的命中率)。 HStore是HBase中存储的核心它实现了读写HDFS功能一个HStore由一个MemStore 和0个或多个HFile组成。 MemStore所有数据的写在完成WAL日志写后会 写入MemStore中由MemStore根据一定的算法将数据Flush到地层HDFS文件中(HFile)通常每个HRegion中的每个 Column Family有一个自己的MemStore。HFile在HFile中的数据是按RowKey、Column Family、Column排序对相同的Cell(即这三个值都一样)则按timestamp倒序排列MemStore MemStore是一个In Memory Sorted Buffer在每个HStore中都有一个MemStore即它是一个HRegion的一个Column Family对应一个实例。它的排列顺序以RowKey、Column Family、Column的顺序以及Timestamp的倒序如下所示 每一次Put/Delete请求都是先写入到MemStore中当MemStore满后会Flush成一个新的StoreFile(底层实现是HFile)即一个HStore(Column Family)可以有0个或多个StoreFile(HFile)。有以下三种情况可以触发MemStore的Flush动作需要注意的是MemStore的最小Flush单元是HRegion而不是单个MemStore。据说这是Column Family有个数限制的其中一个原因估计是因为太多的Column Family一起Flush会引起性能问题 MemStore超过128M此时当前的HRegion中所有的MemStore会Flush到HDFS中。HRegionServer上所有MemStore的大小超过了机器上默认40的内存使用量。此时当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中Flush顺序是MemStore大小的倒序直到低于某个阈值默认38%WAL过大当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中Flush使用时间顺序最早的MemStore先Flush直到WAL的数量少于某个阈值。在MemStore Flush过程中还会在尾部追加一些meta数据其中就包括Flush时最大的WAL sequence值以告诉HBase这个StoreFile写入的最新数据的序列那么在Recover时就直到从哪里开始。 HFile格式 HFile是MemStore在HDFS上的实体所以写一个HFile是顺序写速度很快。HFile一共经历了三个版本 v1 数据存放再Data块中Data块的大小可以用户指定大的Data块适合scan小的Data块适合随机查找。 HFile里面的每个KeyValue对就是一个简单的byte数组。但是这个byte数组里面包含了很多项并且有固定的结构。 Block Index使用记录每个Data Block最大值的方案需要将索引一次性读入内存 v2 解决了V1版本内存占用特别是Bloom File和Block Index过大。它的解决方案是把Bloom File和Block Index打散放入Data每次查询不用加载全部信息。对HFileV2格式具体分析它是一个多层的类B树索引采用这种设计可以实现查找不需要读取整个文件 Data Block中的Cell都是升序排列每个block都有它自己的Leaf-Index每个Block的最后一个Key被放入Intermediate-Index中Root-Index指向Intermediate-Index。Bloom过滤器用于快速定位没有在DataBlock中的数据 v3 v3和v2没有太大变化只是加了一个tag字段 理一理HRegionServer中的结构 HRegionServer WAL(Hlog一个HDFS中)BlockCacheHRegion(最多1000个表的横切rowkey不会重叠) HStore列族HRegion的列切 多个 MemStore(写完Hlog后刚生成的数据)HFile(多个具体的数据排序HDFS中) HRegionServer写流程 客户端发起一个Put请求时首先它从hbase:meta表中查出该Put数据最终需要去的HRegionServer。然后客户端将Put请求发送给相应的HRegionServer在HRegionServer中它首先会将该Put操作写入WAL日志文件中完WAL日志文件后HRegionServer根据Put中的TableName和RowKey找到对应的HRegion并根据Column Family找到对应的HStore并将Put写入到该HStore的MemStore中。写入成功返回给客户端。当MemStore积累一定量的数据后flush成HFile到HDFS上HBase读流程 HBase写时相同Cell(RowKey/ColumnFamily/Column相同)并不保证在一起甚至删除一个Cell也只是写入一个新的Cell它含有Delete标记而不一定将一个Cell真正删除了因而这就引起了一个问题如何实现读的问题 相同的cell可能存在3个不同的位置Block CacheMemStoreHFile中。 从Block Cache中读取从MemStore中读取从多个HFile中读取用Bloom Filter筛掉明显不存在所需数据的HFileIndex用于快速定位HFile中的数据块 Compaction HFile过多在数据读取的时候会产生性能问题。所以一段时间后HFile会进行合并。HBase中Compaction分为两种Minor Compaction和Major Compaction。 Minor Compaction是指选取一些小的、相邻的HFile将他们合并成一个更大的StoreFile在这个过程中不会处理已经Deleted或Expired的Cell。(BigTable中将memtable的数据flush的一个HFile/SSTable称为一次Minor Compaction)Major Compaction是指将所有的HFile合并成一个HFile可以手动触发或者自动触发但是会引起性能问题一般安排在周末。HRegion Split 最初一个Table只有一个HRegion随着数据写入增加如果一个HRegion到达一定的大小就需要Split成两个HRegion这个大小由hbase.hregion.max.filesize指定默认为10GB。 当split时split时停止服务两个新的HRegion会在同一个HRegionServer中创建它们各自包含父HRegion一半的数据当Split完成后父HRegion会下线而新的两个子HRegion会向HMaster注册上线处于负载均衡的考虑这两个新的HRegion可能会被HMaster分配到其他的HRegionServer中。 分裂流程 RegionServer在本地决定分割HRegion并准备分割。第一步汇报给zookeeper。master获取zookeeper中的状态。RegionServer在HDFS的父目录区域目录下创建一个名为“.splits”的子目录。RegionServer关闭父HRegion强制刷新缓存并将该区域标记为本地数据结构中的脱机状态。此时来到父区域的客户端请求将抛出NotServingRegionException异常。客户端将重试一些备用值。RegionServer在.splits目录下创建Region目录为子区域A和B创建必要的数据结构。然后它分割存储文件因为它在父区域中为每个存储文件创建两个引用文件。那些引用文件将指向父Region文件。RegionServer在HDFS中创建实际的区域目录并移动每个子Region的引用文件。RegionServer向META表发送请求。将父HRegion设置为.META中的脱机状态并添加关于子HRegion的信息。在这时在META中不会为女儿分配单独的条目。客户端会看到父区域是分割的如果他们扫描.META但不知道子HRegion直到他们出现在.META。RegionServer并行open子HRegion接受写入。RegionServer将女儿A和B添加到.META。以及它所在地区的信息。此后客户可以发现新的地区并向新的地区发出请求之前的缓存失效。HRegion Server向zookeeper汇报split结束的消息master进行负载均衡。拆分后meta表和HDFS仍将包含对父HRegion的引用。当子HRegion进行Compaction时这些引用信息会被删除。Master也会定期检查子HRegion如果没有父HRegion中的信息父HRegion将被删除。HRegion分裂后负载均衡 出于负载均衡的考虑HMaster可能会将其中的一个甚至两个重新分配的其他的HRegionServer中。可能会产生HFile在其他节点上直到下一次Major Compaction将数据从远端的节点移动到本地节点。 既然有拆分但是HRegion也可以合并。HRegion调用closeAndMerge把两个HRegion合并(需要两个HRegion停止服务) HBase中的负载均衡 负载均衡器会平衡系统中每个HRegionServer中HRegion个数。 负载均衡对系统性能影响很大实际一般关闭每周开启一次。 容错 HRegionServer Recovery zookeeper感知通知HMaster重新分配HRegion到其他节点为每个HRegion拆分WAL将拆分出的WAL文件写入对应的目的HRegionServer的WAL目录中并并写入对应的DataNode中回放WAL重建MemStoreHMaster Recovery 依靠zookeeper进行主备切换 HBase一致性 HBase是强一致性它表现在 HRegion split时相关HRegion不可用HRegion合并时相关HRegion不可用HRegionServer Recovery时相关HRegion不可用转载于:https://www.cnblogs.com/biterror/p/6909923.html
