hbase
来源:
解决随机近实时的高效的读写
解决非结构化的数据存储
1. hbase是一个开源的、分布式的、多版本的、可扩展的、非关系型的数据库。
2. hbase是big table的开源的java版本,建立在hdfs基础之上,提供高可靠性、高性能的、列式存储、可伸缩、近实时读写的nosql的数据库系统
3. 数据量越来越大,传统的关系型数据库不能满足存储和查询的需求。而hive虽然能够满足存储的要求,但是hive的本质也是利用底层的mr程序,所以读写速度不快。而且hive不能满足非结构化的、半结构化的存储,hive的主要作用是做分析和统计,hive用于存储是无意义的。
- HBASE是一个数据库----可以提供数据的实时随机读写
- HBASE与mysql、oralce、db2、sqlserver等关系型数据库不同,它是一个NoSQL数据库(非关系型数据库)
应用:
可以存储非结构化的数据(用户、商品、文章的画像属性)
被用来做实时(整合flume、storm、streaming等)
存储历史明细数据(较少)
存储最终结果数据(kylin预执行数据就是放到hbase中)
行业:通信、银行、金融等
特性
- Hbase的表模型与关系型数据库的表模型不同:
- Hbase的表没有固定的字段定义;
- Hbase的表中每行存储的都是一些key-value对
- Hbase的表中有列簇的划分,用户可以指定将哪些kv插入哪个列族
- Hbase的表在物理存储上,是按照列簇来分割的,不同列簇的数据一定存储在不同的文件中
- Hase的表中的每一行都固定有一个行键,而且每一行的行键在表中不能重复
- Hbase中的数据,包含行键,包含key,包含value,都是byte[ ]类型,hbase不负责为用户维护数据类型
- HBASE对事务的支持很差
- Hbase的表模型与关系型数据库的表模型不同:
- Hbase的表没有固定的字段定义;
- Hbase的表中每行存储的都是一些key-value对
- Hbase的表中有列簇的划分,用户可以指定将哪些kv插入哪个列族
- Hbase的表在物理存储上,是按照列簇来分割的,不同列簇的数据一定存储在不同的文件中
- Hase的表中的每一行都固定有一个行键,而且每一行的行键在表中不能重复
- Hbase中的数据,包含行键,包含key,包含value,都是byte[ ]类型,hbase不负责为用户维护数据类型
- HBASE对事务的支持很差
表模型
- hbase的表模型跟mysql之类的关系型数据库的表模型差别巨大
- hbase的表模型中有:行的概念;但没有字段的概念
- 行中存的都是key-value对,每行中的key-value对中的key可以是各种各样,每行中的key-value对的数量也可以是各种各样
表模型特点
1、一个表,有表名
2、一个表可以分为多个列簇(不同列簇的数据会存储在不同文件中)
3、表中的每一行有一个“行键rowkey”,而且行键在表中不能重复
4、表中的每一对kv数据称作一个cell
5、hbase可以对数据存储多个历史版本(历史版本数量可配置)
6、整张表由于数据量过大,会被横向切分成若干个region(用rowkey范围标识),不同region的数据也存储在不同文件中
7、hbase会对插入的数据按顺序存储:
- 要点一:首先会按行键排序
- 要点二:同一行里面的kv会按列簇排序,再按k排序
hbase存储的数据类型
- hbase中只支持byte[]
- 此处的byte[] 包括了: rowkey,key,value,列簇名,表名
和hadoop的关系
HBase基于hadoop : HBase的存储依赖于HDFS
hbase的官网描述
hbase定义:分布式的,开源的,多版本的
Welcome to Apache HBase™
Apache HBase™ is the Hadoop database, a distributed, scalable, big data store.
Use Apache HBase™ when you need random, realtime read/write access to your Big Data. This project's goal is the hosting of very large tables -- billions of rows X millions of columns -- atop clusters of commodity hardware. Apache HBase is an open-source, distributed, versioned, non-relational database modeled after Google's Bigtable: A Distributed Storage System for Structured Data by Chang et al. Just as Bigtable leverages the distributed data storage provided by the Google File System, Apache HBase provides Bigtable-like capabilities on top of Hadoop and HDFS.
使用场景:1 需要对海量非结构化的数据进行存储
2 需要随机近实时的读写管理数据
Apache HBase™是Hadoop数据库,这是一个分布式,可扩展的大数据存储。
当您需要对大数据进行随机,实时的读/写访问时,请使用Apache HBase™。该项目的目标是在商品硬件群集上托管超大型表-数十亿行X数百万列。Apache HBase是一种开放源,分布式,版本化,非关系型数据库,其仿照Chang等人的Google的Bigtable:结构化数据的分布式存储系统。正如Bigtable利用Google文件系统提供的分布式数据存储一样,Apache HBase在Hadoop和HDFS之上提供类似于Bigtable的功能。
Linear and modular scalability.
Strictly consistent reads and writes.
Automatic and configurable sharding of tables
Automatic failover support between RegionServers.
Convenient base classes for backing Hadoop MapReduce jobs with Apache HBase tables.
Easy to use Java API for client access.
Block cache and Bloom Filters for real-time queries.
Query predicate push down via server side Filters
Thrift gateway and a REST-ful Web service that supports XML, Protobuf, and binary data encoding options
Extensible jruby-based (JIRB) shell
Support for exporting metrics via the Hadoop metrics subsystem to files or Ganglia; or via JMX
线性和模块化可扩展性。
严格一致的读写。
表的自动和可配置分片
RegionServer之间的自动故障转移支持。
方便的基类,用于通过Apache HBase表备份Hadoop MapReduce作业。
易于使用的Java API用于客户端访问。
块缓存和布隆过滤器用于实时查询。
通过服务器端过滤器查询谓词下推
Thrift网关和支持XML,Protobuf和二进制数据编码选项的REST-ful Web服务
可扩展的基于Jruby的(JIRB)外壳
支持通过Hadoop指标子系统将指标导出到文件或Ganglia;或通过JMX
hbase的架构
三层分布:
1.client、zookeeper、hmaster
2.HregionServer,hlog,hregion,store
- Client :
hbase客户端,1.包含访问hbase的接口。比如,linux shell,java api。2.除此之外,它会维护缓存来加速访问hbase的速度。比如region的位置信息。
- Zookeeper :
1.监控Hmaster的状态,保证有且仅有一个活跃的Hmaster。达到高可用。2.它可以存储所有region的寻址入口。如:root表在哪一台服务器上。3. 实时监控HregionServer的状态,感知HRegionServer的上下线信息,并实时通知给Hmaster。4. 存储hbase的部分元数据。
- HMaster :
1. 为HRegionServer分配Region(新建表等)。2. 负责HRegionServer的负载均衡。3. 负责Region的重新分配
(HRegionServer宕机之后的Region分配,HRegion裂变:当Region过大之后的拆分4. Hdfs上的垃圾回收。5. 处理schema的更新请求
- HRegionServer :
1. 维护HMaster分配给的Region(管理本机的Region)。2. 处理client对这些region的读写请求,并和HDFS进行交互。3. 负责切分在运行过程中组件变大的Region
-Hlog:日志(相当于mysql的binlog),1. 对HBase的操作进行记录,使用WAL写数据,优先写入log(put操作:先写日志再写memstore,这样可以防止数据丢失,即使丢失也可以回滚)。
- HRegion : 1. HBase中分布式存储和负载均衡的最小单元,它是表或者表的一部分。
- Memstore :
1. 内存缓冲区,用于将数据批量刷新到hdfs中,默认大小为128M
异步写入:MemStore:缓冲(类似于hadoop的圆形缓冲区)(默认128M)
- HStoreFile : 1. 和HFile概念意义,不过是一个逻辑概念。HBase中的数据是以HFile存储在Hdfs上。
store:
每个Store对应了表中的一个列族的存储。每个Store包括一个MemStore缓存和若干个StoreFile文件。MenStore是排序的内存缓冲区,当用户写入数据时,系统首先把数据放入MenStore缓存,当MemStore缓存满时,就会刷新到磁盘中的一个StoreFile文件中,当单个StoreFile文件大小超过一定阈值时,就会触发文件分裂操作。
RegionServer
Region服务器是HBase中最核心的模块,负责维护分配给自己的Region,并响应用户的读写请求
root表被删除(0.96版本之后没有root表,只有zk文件和meta表)
各组件之间的关系
hmaster:hregionserver=1:*
hregionserver:hregion=1:*
hregionserver:hlog=1:1
hregion:hstore=1:*
store:memstore=1:1
store:storefile=1:*
storefile:hfile=1:1
总结
rowkey:行键,和mysql的主键同理,不允许重复。
columnfamily: 列簇,列的集合之意。
column:列
timestamp:时间戳,默认显示最新的时间戳,可用于控制k对应的多个版本值,默认查最新的数据
version:版本号,表示记录数据的版本
cell:单元格,kv就是cell
模式:无
数据类型:只存储byte[]
多版本:每个值都可以有多个版本
列式存储:一个列簇存储到一个目录
稀疏存储:如果一个kv为null,不占用存储空间
一个表最少有一个列簇
TTL:生命周期
nosql分类
键值数据库
项目 | 描述 |
相关产品 | Redis,Piak,Chordless,Scalaris,Memcached |
数据模型 | 键/值对 |
典型应用 | 内容缓存,如会话、配置文件、参数、购物车等 |
优点 | 扩展性良好、灵活性好、大量写操作时性能高 |
缺点 | 无法存储结构化信息、条件查询效率低 |
使用者 | 百度云数据库(Redis),GitHub(Riak),BestBuy(Riak),Twitter(Redis和Memcached),StackOverFlower(Redis),Instagram(Redis),Youtube(Memcached),Wikipedia(Memcached) |
列族数据库
项目 | 描述 |
相关产品 | BigTable,Hbase,Cassandra,HadoopDB,GreenPlum,PNUTS |
数据模型 | 列族 |
典型应用 | 分布式数据存储与管理 |
优点 | 查找速度快,可扩展性强,容易进行分布式扩展,复杂性低 |
缺点 | 功能较少,大都不支持强事务一致性 |
使用者 | Ebay(Casscandra),Instagram(Cassandra),NASA(Cassandra),Twittet(Cassandra and HBase),Facebook(HBase),Yahoo!(HBase) |
文档数据库
项目 | 描述 |
相关产品 | CouchDB,MongoDB,Terrastore,ThruDB,RavenDB,SisoDB,RaptorDB,CloudKit,Perserver,Jackrabbit |
数据模型 | 版本化的文档 |
典型应用 | 存储,索引并管理面向文档的数据或者类似的半结构化数据 |
优点 | 性能好,灵活性高,复杂性低,数据结构灵活 |
缺点 | 缺乏统一的查询语法 |
使用者 | 百度云数据库(MongoDB),SPA(MongoDB),Codecademy(MongoDB),Foursquare(MongoDB),NBCNews(RavenDB) |
CPA理论的具体含义。
CAP指的是:
C(Consistency):一致性,是指任何一个读操作总是能够读到之前完成的写操作的结果,也就是在分布式环境中,多点的数据是一致的,或者说,所有节点在同一时间具有相同的数据
A:(Availability):可用性,是指快速获取数据,可以在确定的时间内返回操作结果,保证每个请求不管成功或者失败都有响应;
P(Tolerance of Network Partition):分区容忍性,是指当出现网络分区的情况时(即系统中的一部分节点无法和其他节点进行通信),分离的系统也能够正常运行,也就是说,系统中任意信息的丢失或失败不会影响系统的继续运作。
数据库的ACID四性的具体含义
1.原子性(Atomicity)
指事务必须是原子工作单元,对于其数据修改,要么全都执行,要么全都不执行。
2.一致性(consistency)
指事务在完成时,必须使所有的数据都保持一致状态。
3.隔离性(Isolation)
指并发事务所做的修改必须与其他并发事务所做的修改隔离。
4.持久性(Durability)
指事务完成之后,它对于系统的影响是永久性的,该修改即使出现致命的系统故障也将一直保持。
BASE的具体含义。
BASE的基本含义是基本可用(Basically Availble)、软状态(Soft-state)和最终一致性(Eventual consistency)
最终一致性。
一致性的类型包括强一致性和弱一致性,二者的主要区别在于高并发的数据访问操作下后续操作是否能够获取最新的数据。对于强一致性而言,当执行完一次更新操作后,后续的其他读操作就可以保证读到更新后的最新数据;反之,如果不能保证后续访问读到的都是更新后的最新数据,那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例,允许后续的访问操作可以暂时读不到更新后的数据,但是经过一段时间之后,必须最终读到更新后的数据。最终一致性也是ACID的最终目的,只要最终数据是一致的就可以了,也不是每时每刻都保持实时一致。
Eventual consistency)
### 最终一致性。
一致性的类型包括强一致性和弱一致性,二者的主要区别在于高并发的数据访问操作下后续操作是否能够获取最新的数据。对于强一致性而言,当执行完一次更新操作后,后续的其他读操作就可以保证读到更新后的最新数据;反之,如果不能保证后续访问读到的都是更新后的最新数据,那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例,允许后续的访问操作可以暂时读不到更新后的数据,但是经过一段时间之后,必须最终读到更新后的数据。最终一致性也是ACID的最终目的,只要最终数据是一致的就可以了,也不是每时每刻都保持实时一致。