白中白之Hbase入门(一)
前言:我自己学一样东西入门,已经养成一种习惯,分为三步
首先、要知道这个东西是什么
然后、要知道我们为什么需要这个东西
最后、这个技术的是怎么来的,或者说是怎么演变过来的
本文也是按照这三步讲解,最后再简单介绍了一些Hbase的基本定义
什么是Hbase
- hbase为查询而生,它通过组织机器的内存,提供一个超大的内存hash表,它需要组织自己的数据结构,表在hbase中是物理表,而不是逻辑表,搜索引擎用它来存储索引,以满足实时查询LSM-Tree(Log-Structured Merge-Tree) + HTable(region分区) + Cache的需求;
- hbase 是一个基于列存储的非关系型数据库,查询效率高,主要用于查询和展示结果;
- hbase可以认为是HDFS的一个包装。它的本质是数据存储,是个nosql数据库;hbase部署于HDFS之上,并且克服了HDFS在随机读写方面的缺点。
- HBase的目标是存储并处理大型的数据,更具体来说是仅需使用普通的硬件配置,就能够处理由上亿行、上百万列的大型数据。【非大勿用】
- 主要用来存储结构化和半结构化的松散数据。
小结
基于HDFS,支持海量数据读写(尤其是写),支持上亿行、上百万列的,面向列的分布式NoSql数据库。天然分布式,主从架构,支持行事务,不支持二级索引,不支持sql,面向列,可伸缩实时读写,多版本。
HBase并不是足够快,而是数据量很大的时候它慢的不明显。
Diff | Hbase | RDBMS |
---|---|---|
数据类型 | bytes[] | 丰富的数据类型 |
数据操作 | 简单CRUD | 丰富SQL支持 |
存储模式 | 列族存储 | 行存储 |
数据保护 | 保留 | 替换 |
可伸缩性 | 好 | 差 |
吞吐量 | 百万/秒 | 数千/秒 |
索引 | 只支持row-key | 支持 |
为什么需要HBase
- 海量数据量存储成为瓶颈,单台机器无法负载大量数据
- 单台机器 IO读写请求成为海量数据存储时候高并发大规模请求的瓶颈
- 随着数据规模越来越大,大量业务场景开始考虑数据存储横向水平扩展,使得存储服务可以增加/删除,而目前的关系型数据库更专注于一台机器。
大数据发展历程
萌芽阶段
20世纪90年代到21世纪的样子,数据库技术成熟,数据挖掘理论成熟,也称数据挖掘阶段。
突破阶段
2003——2006年,非结构化的数据大量出现,传统的数据库处理难以应对,也称非结构化数据阶段。
成熟阶段
2006——2009年,谷歌公开发表两篇论文《谷歌文件系统》和《基于集群的简单数据处理:MapReduce》,其核心的技术包括分布式文件系统GFS,分布式计算系统框架MapReduce,分布式锁Chubby,及分布式数据库BigTable,这期间大数据研究的焦点是性能,云计算,大规模的数据集并行运算算法,以及开源分布式架构(Hadoop)
应用阶段
2009年至今,大数据基础技术成熟之后,学术界及及企业界纷纷开始转向应用研究,2013年大数据技术开始向商业、科技、医疗、政府、教育、经济、交通、物流及社会的各个领域渗透,因此2013年也被称为大数据元年。
没有Hbase之前是如何进行大数据存储
阿里架构演进
架构原始阶段:万能的单机
架构的最原始阶段,即一台ECS服务器搞定一切。 通过一些sql优化、jvm优化即可
pv:5w——30w
架构基础阶段:物理分离web和数据库
显然单机已经出现性能瓶颈。我们将web应用和数据库物理分离单独部署,解决对应性能问题。
pv:50w——100w
这里的架构采用ECS + RDS
架构动静分离阶段:静态缓存 + 文件存储
通过将动态请求、静态请求的访问分离(“动静分离”),有效解决服务器在磁盘IO、带宽方面的访问压力。
pv:100w——300w
架构采用CDN + ECS + OSS + RDS
架构分布式阶段:负载均衡
最直观的现象是,前端访问堵塞、延迟、服务器进程增多、cpu100%,并且出现常见502/503/504的错误码。
显然单台web服务器已经满足不了需求,这里需要通过负载均衡技术增加多台web服务器(对应ECS可以选择不同可用区,进一步保障高可用)。
因而告别单机的时代,转变分布式架构的阶段。
pv:300w——500w
架构采用CDN + SLB + ECS + OSS + RDS
架构数据缓存阶段:数据库缓存
- RDS的连接数增加并且堵塞
- CPU使用率过高
这个时候我们通过数据库缓存,有效减少数据库访问压力,进一步提升性能。
pv:500w——1000w
架构采用CDN + SLB + ECS + OSS
+ 云数据库memcache + RDS
架构扩展阶段:垂直扩展
- 分库分表
- 业务拆分
- 读写分离
所涉及的数据库表:用户模块表、订单模块表、商品模块表等,分别存放到不同数据库中,如用户模块库、订单模块库、商品模块库等。然后把不同数据库分别部署到不同服务器中。
pv:1000w——5000w
架构采用CDN + SLB + ECS + OSS
+ 云数据库memcache + RDS
读写分离
架构分布式+大数据阶段:水平扩展
问题:
- 读写分离仅解决“读”的压力,面对高访问量,在数据库“写”的压力上面“力不从心”,出现性能瓶颈
- 分库虽然将压力拆分到不同数据库中,但单表的数据量达到TB级别以上,显然已经达到传统关系型数据库处理的极限
解决:
- 增加更多的web服务器
- 增加更多的SLB
- 采用分布式缓存
- sharding + nosql
sharding + nosql
面对高并发、大数据的需求,传统的关系型数据库已不再适合。需要采用DRDS(mysql sharding分布式解决方案) + OTS(基于列存储的分布式数据库)对应的分布式数据库来根本性的解决问题。
pv:5000w及以上
架构采用 CDN + DNS轮询 + SLB + ECS + OSS
+ 云数据库memcache + DRDS + OTS
Hbase表结构
row key
决定一行数据;按照字典顺序排序,最大不超过64KB
column family
列族:同一列族里面的数据存在同一目录下,一个列族可以有多个列成员
cell
由行和列的坐标决定一个单元格,多版本
time stamp
时间戳:hbase每个cell存储单元对同一份数据由多个版本,根据时间戳来区分不同版本,不同版本的数据按照时间倒序排列,最新的数据排在最前面。
确定唯一数据:表>row-key>列族>列>时间戳
综合多方资料,我认为Hbase是介于NoSQL和RDBMS之间的一种分布式数据库
简单理解就是,既有关系型数据库(RDBMS)的可定义表结构,又可以像NoSQL以k-v键值对存取数据,只不过他的k是(row-key+列族+列+时间戳)
Hbase架构设计
读取数据,找HRegionServer通过元数据表-ROOT-和.META.表
- Client:它提供了访问HBase的接口,并且维护了对应的cache来加速HBase的访问
- Zookeeper:存储HBase的元数据(meta表),无论是读还是写数据,都是去Zookeeper里边拿到meta元数据告诉给客户端去哪台机器读写数据
- Hmaster:分配HRegion进行到HRegionServer,对HRegionServer进行负载均衡
- HRegionServer:处理客户端的读写请求,负责与HDFS底层交互,是真正干活的节点