hbase基础小结

hbase简介

HBase(Hadoop Database)是一个高可靠性、高性能、面向列、可伸缩的分布式大数据存储系统。具有最理想化的写和极好的读性能。它支持可插拔的压缩算法(用户可以根据其列族中的数据特性合理选择其压缩算法),充分利用了磁盘空间。

 



 

如上图所示,它是Google BigTable的开源实现,利用Hadoop HDFS作为它文件存储,利用Hadoop MapReduce处理海量数据,使用Zookeeper进行协调服务。利用HBase技术可在廉价PC Server上搭建起大规模NoSql存储集群。值得一提的是,BigTable只支持一级索引,Hbase不仅支持一级索引,还支持二级索引。

 

hbase数据结构

逻辑结构
 

  • 表(Table):HBase会将数据组织进一张张的表里面
  • 行(Row):每一行代表着一个数据对象,每一行都是以一个行键(Row Key)来进行唯一标识的
  • 列族(Column Family):简单理解为对于表一些列的分类,中所有的列都需要组织在列族里面,列族一旦确定后,就不能轻易修改。
  • 列标识(Column Qualifier):列名,列族中的数据通过列标识来进行映射;也可以理解为一个键值对,Column Qualifier就是Key。
  • 单元(Cell):每一个 行键,列族和列标识共同组成一个单元,存储在单元里的数据称为单元数据。
  • 时间戳(Timestamp):默认下每一个单元中的数据插入时都会用时间戳来进行版本标识。

 

物理模型

系统架构

先来看一下hbase的系统架构



 

 

Client:访问HBase的接口,有缓存机制会缓存比如像Region的位置信息等,用以加快HBase的访问,与HMaster(管理类操作)和HRegionServer(读写类操作)通信。

 

Zookeeper:主要做三件事情,存储-ROOT-表和HMaster的地址,会以临时节点机制感知

HRegionServer的监控状态,Zookeeper还可以避免HMaster的单点问题(可以启动多个HMaster)。

 

HMaster:可以启动多个HMaster,利用Zookeeper的选举机制防止单点问题,它主要完成一些对Table和Region的管理工作:

(1)为RegionServer分配Region
(2)负责RegionServer的负载均衡
(3)发现失效的RegionSever并重新分配Region
(4)管理用户对Table的增删改查等操作

 

RegionServer: 主要负责响应用户请求,并向HDFS中读写数据,是HBase最核心的模块儿:


 

HRegionServer内部包含一些列的HRegion对象,每一个HRegion对应到一个Region,正如上文物理模型中提到,每个Region中又包括多个Store,每个Store又包括一个memStore(内存存储)和多个storeFile(storeFile封装了HFile,存储在HDFS之上)。

 

用户写入的数据首先会放入MemStore,当MemStore满了以后会Flush成一个StoreFile,当StoreFile文件数量增长到一定阈值,会触发Compact合并操作,将多个StoreFiles合并成一个StoreFile,合并过程中会进行版本合并和数据删除(数据删除时会首先打一个标记但没有真正删除),因此可以看出HBase其实只有增加数据,所有的更新和删除操作都是在后续的compact过程中进行的,这使得用户的写操作只要进入内存中就可以立即返回,保证了HBase I/O的高性能。

当StoreFiles Compact后,会逐步形成越来越大的StoreFile,当单个StoreFile大小超过一定阈值后,会触发Split操作,同时把当前Region Split成2个Region,父Region会下线,新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上,使得原先1个Region的压力得以分流到2个Region上

 

HRegionServer采用WAL(Write-Ahead-Log)机制来实现数据的容错和恢复,这种机制类似于mysql中的Binary Log。每个HRegionServer中都有一个HLog对象,HLog是一个实现Write Ahead Log的类,在每次用户操作写入MemStore的同时,也会写一份数据到HLog文件中,HLog文件定期会滚动出新的,并删除旧的文件(已持久化到StoreFile中的数据)。当HRegionServer意外终止后,HMaster会通过Zookeeper感知到,HMaster首先会处理遗留的 HLog文件,将其中不同Region的Log数据进行拆分,分别放到相应region的目录下,然后再将失效的region重新分配,领取到这些region的HRegionServer在Load Region的过程中,会发现有历史HLog需要处理,因此会Replay HLog中的数据到MemStore中,然后flush到StoreFiles,完成数据恢复。

 

物理模型

(1) Table中的行会按照Row Key的字典顺序进行排序

(2)每个Column Family其实就是一个集中的存储单元,最好将具备共同IO特性的column放在一个Column Family中,这样最高效。Row Key和Version会在每个Column Family中都有一份,HBase会为每个值维护一个多级索引。 列簇中的列和值实际按照Key/Value进行存储,所以在物理结构上数据并没有逻辑结构中体现的稀疏

(3)Table会在行的方向上分割为多个Region,开始时表只有一个Region,随着数据增多,Region就会等分成两个新的Region并重新分布到不同RegionServer。

 

(4)HBase中有两张特殊的表-ROOT-和.META.,Zookeeper中记录了-ROOT-的位置信息;-ROOT-又记录了.META.表的Region信息,-ROOT-表只能有一个region;.META.表记录了用户表的Region信息,它可以有多个region。



 

(5)Region是分布式存储的最小单元,但Region中又包括多个Store,每个Store又包括一个memStore(内存存储)和多个storeFile(storeFile封装了HFile,存储在HDFS之上) 

 

适用场景

(1)大数据量存储,大数据量并发操作
(2)需要对数据随机读写操作
(3)读写访问均是非常简单的操作,没有关系型数据库那么复杂的读写操作

 

python+opencv简谱识别音频生成系统源码含GUI界面+详细运行教程+数据 一、项目简介 提取简谱中的音乐信息,依据识别到的信息生成midi文件。 Extract music information from musical scores and generate a midi file according to it. 二、项目运行环境 python=3.11.1 第三方库依赖 opencv-python=4.7.0.68 numpy=1.24.1 可以使用命令 pip install -r requirements.txt 来安装所需的第三方库。 三、项目运行步骤 3.1 命令行运行 运行main.py。 输入简谱路径:支持图片或文件夹,相对路径或绝对路径都可以。 输入简谱主音:它通常在第一页的左上角“1=”之后。 输入简谱速度:即每分钟拍数,同在左上角。 选择是否输出程序中间提示信息:请输入Y或N(不区分大小写,下同)。 选择匹配精度:请输入L或M或H,对应低/中/高精度,一般而言输入L即可。 选择使用的线程数:一般与CPU核数相同即可。虽然python的线程不是真正的多线程,但仍能起到加速作用。 估算字符上下间距:这与简谱中符号的密集程度有关,一般来说纵向符号越稀疏,这个值需要设置得越大,范围通常在1.0-2.5。 二值化算法:使用全局阈值则跳过该选项即可,或者也可输入OTSU、采用大津二值化算法。 设置全局阈值:如果上面选择全局阈值则需要手动设置全局阈值,对于.\test.txt中所提样例,使用全局阈值并在后面设置为160即可。 手动调整中间结果:若输入Y/y,则在识别简谱后会暂停代码,并生成一份txt文件,在其中展示识别结果,此用户可以通过修改这份txt文件来更正识别结果。 如果选择文件夹的话,还可以选择所选文件夹中不需要识别的文件以排除干扰
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值