这是数据平台的第一篇文章，借着大数据和 Hadoop 的东风，我打算从业务和数据的结合点——HBASE 入手开始写。这个环节即有业务需求的逻辑，也承接数据模型的部署。

HBASE简介

HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

HBASE 的特性

• 容量大：单表可达百亿行、百万列，数据矩阵横向和纵向支持都非常具有弹性，且不会数据查询和写入性能不会随着数据量级的增大而下滑。
• 面向列储存：数据按列储存，只访问查询所涉及的列，降低系统 I/O ，相同列类型一致，可高效压缩
• 稀疏性：数据为 Null 时不占储存空间
• 扩展性：基于 HDFS，可在不停止现有服务的情况下，随时添加减少节点
• 高可靠性：通过 WAL 和 Replication 机制保证数据不会丢失或损坏
• 高性能： LSM 底层数据结构和良好的Rowkey 的设计可以保证 HBASE 查询能够在毫秒级别返回

关系型数据库的瓶颈

说到以上几点，大家可能没什么感觉，所以我们回头看看传统关系型数据库在应对大数据量级上的不足和瓶颈：

以往数据分析师接触的关系型数据库（RDBMS，如 MySQL）在数据分析处理等非实时处理的工作时表现尚可，可随着用户量级越来越多，存储的底层数据越来越大，这时候它的瓶颈就显现出来了：

• 高并发读写力不从心

随着数据量级的上升，数据请求的并发可能达上千上万次，一些好的关系型数据库勉强可以做到上万次数据查询，但随之而来的上万次数据读写，这对硬盘的I/O 压力是无法承受的。比如某个新闻类APP 在早高峰的阅读人数可能是十万乃至百万级别的，这些用户的信息浏览记录和实时推荐带来的并发是传统的关系型数据库无法承受的。

• 可扩展性限制

在某些企业中，数据库通常是24h 不间断的提供服务，当业务体量达到一定大的时候，数据库势必要进行横向扩展，这个时候停机维护倒是小事，而数据库迁移却是个非常头大的问题。

• 数据库一致性高负荷

关系型数据还有个头大的事情就是保证数据库的一致性，举个简单的例子，你的数据库里存有两张表：学生成绩表（学号、姓名、班级、语文成绩、数学成绩、英语成绩）和班级表（班级、班主任、语文老师、数学老师、英语老师）。突然有一天校长说，学校要增招一批优秀的学生成立新的实验班，那此时数据库正在录入的新一批学生的班级是原班级表中查询不到，恰好这是领导来视察新工作进展，调出学生面板一看发现有批学生没有班级归属，那校长不得发大火，所以在关系型数据库的更新维护过程中要保证事务的一致性。以上例子这是读一致性的体现。

HBASE 的适用场景

那么什么样的业务场景适合用 HBASE 作为调用层呢，这里简单的将其特性抽象成以下几点概括：

1. 能够存储大量机量级数据（PB 级别）且同时保证很好的访问性能
2. 能够在短时间内支持大量的数据读写吞吐，尤其是写
3. 能够方便的对数据进行横向扩展，不必担心数据量级增长过大导致停机维护
4. 数据格式无限制，支持半结构化和非机构化数据
5. 业务场景应用简单，不支持复杂的多表交叉查询

HBASE 目前在业界被广泛地应用，国内外大厂如淘宝、脸书都有在使用这个开源数据库。应用场景包括且不仅包括互联网广告监控、基于用户的内容推荐引擎、增量用户交互数据、实时消息系统等。

后记：在我还是数据分析师那会儿，我总是对后端数据存储感兴趣，我现在所看到的业务面板，小组搭建出逻辑回归模型、商品的实时推荐这些功能是如何实现并在我们可接受的范围内返回结果的。所以当我决定在数据平台建设路上走走看的时候，我第一个碰到的是 HBASE，它作为连接业务需求和数据建模的中间点，可以让我顺畅的转变自身角色。因为我的读者都是分析师，希望这些笔记能帮助同为分析师的你们理解你们手中的数据模型是如何生效的。