白中白之Hbase入门(一)

白中白之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

1. 海量数据量存储成为瓶颈，单台机器无法负载大量数据
2. 单台机器 IO读写请求成为海量数据存储时候高并发大规模请求的瓶颈
3. 随着数据规模越来越大，大量业务场景开始考虑数据存储横向水平扩展，使得存储服务可以增加/删除，而目前的关系型数据库更专注于一台机器。

大数据发展历程

萌芽阶段

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读写分离

架构分布式+大数据阶段：水平扩展

问题：

1. 读写分离仅解决“读”的压力，面对高访问量，在数据库“写”的压力上面“力不从心”，出现性能瓶颈
2. 分库虽然将压力拆分到不同数据库中，但单表的数据量达到TB级别以上，显然已经达到传统关系型数据库处理的极限

解决：

1. 增加更多的web服务器
2. 增加更多的SLB
3. 采用分布式缓存
4. 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.表

1. Client：它提供了访问HBase的接口，并且维护了对应的cache来加速HBase的访问
2. Zookeeper：存储HBase的元数据（meta表），无论是读还是写数据，都是去Zookeeper里边拿到meta元数据告诉给客户端去哪台机器读写数据
3. Hmaster：分配HRegion进行到HRegionServer，对HRegionServer进行负载均衡
4. HRegionServer：处理客户端的读写请求，负责与HDFS底层交互，是真正干活的节点