开发者学堂课程【HBase 入门与实战：走进大数据存储的世界】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/808/detail/13894
走进大数据存储的世界
内容介绍：
一、大数据与 HBase
二、HBase 架构与原理
三、HBase 使用场景
四、总结
一、大数据与 HBase
1、数据库的发展
数据库诞生于上世纪50年代，应用场景仅限于国防科研这些大型的应用；到了70年的时候，小型机开始出现，也就出现了我们所熟悉的关系型的数据库 IBM 的 DB2、 ORACLE、INGRES 等等；在九零年代后，PC 机开始突起，一些企业也开始做信息化转型， ERP、CRM、财务软件开始涌现，这些网站都是运行在原价的 X86 和 PC 机上的，所有的数据库也是这种开源的或是这种商业的 Mysql、sqlsora 或者是 postgre 是熟悉的现在还在使用的关系数据库；进入2000年之后，进入互联网时代，是大数据时代数据集聚、数据膨胀，传统的单机的关系数据库已经无法去保护这个时代处理数据的需求，因此开始出现一些像 HBase 、redis、mongoDB NoSQL的数据库；在2015年之后进入了云时代，又开始了一些云延伸的数据库，比如阿里云的冰种 APP 以及 PolarDB-X 等等。
2、数据的趋势
这节课的重点主要在大数据时代，大数据发展的趋势有一个很大的特点是它的数据量呈一个几何基数的增长，在2005年刚进入互联时代的时候全网的数据结果统计有0.1个 ZB 左右， 1 ZB 等于100万的 PB ，到了2020年左右数据量急剧增长到了 47 个 ZB ,随着IoT 万物互联的兴起，预计到2025年的时候这个数据量会达到160万的 ZB ，除了数据量越来越多，数据种类也非常丰富，按熟悉的案例产品来说，这些数据有大家在聊天记录，有长订单的记录以及物流的详情包括风控、机器学习训练集等等各种各样的数据，也包括视频、音频、图像等等，数据非常多，但是从这些海量的数据中去挖掘出有价值的信息很困难。
3、大数据的特点
（1）大数据的特点 首先数据的第一个特点是体量非常大，传统的单机的这种数据库已经无法去满足存储的数据，需要一个能够快速的水平扩展的一个分布式数据库；第二个特点是数据的种类非常多，能够适合存储在关系型数据库中的结构化数据往往只占数据存储的百分之五，余下的 95% 都是一些非结构化或者半结构化的数据；第三个大数据核心是 velocity 高速度，大数据的体量非常大需要非常快的速度去处理这些数据才不至于导致数据堆积，为了追求质量高速度，甚至可以去放弃 ID、事物特性；第四个特性是数据的真实性，数据量很大里面肯定有一些脏数据，怎么样才能去把数据中的没有价值的数据剔除掉是处理的一个重点，而且有些数据可能在现在是有价值的，过了一两个小时之后数据可能变成无用的数据，怎么样把这些数据快速删除掉也是处理大数据的难点，因为大数据四个 V 的特性发现传统的关系型数据库已经无法去满足去处理数据的需求。面对这样的问题，Goolge 提出了解决问题的三驾马车。
（2）Goolge 的三驾马车
GFS、BigTable 和 MapReduce 设计的哲学很简单，就是把一个单机的变成一个分布式处理架构，同时这个软件是能够运行在比较廉价的商业的 X86 的服务器上。 GFS 是一个分布式的文件系统，文件存不下就把它切片把它分到非常多的机器上去存，BigTable 是一个表啊可能一台机器放不下，就把它数据进行分片、切片然后再把它分布到各个机器上去。MapReduce 是一个分布式的计算系统，一台机器的算力不够，然后把这些计算任务，Map 到各个机器上去，再做一个 Reduce ，把这个结果做一个汇总。
（3）BigTable 与 HBase
HBase 是基于 BigTable 论文在 Hadoop 生态中的开源实现 有人根据 Goolge 的三个系统研发一个开源系统Hadoop ，HBase基于 Goolge 的 BigTable 去实现大数据的存储。和 BigTable 一样的 Chubby 和 GFS 一样，HBase 也依赖 Chubby 的开源实现Table 和 GFS 开源实现HDFS。
4、HBase 项目的历史与现状
（1）HBase 的历史
2006
·2006年诞生于 Powerset 一家从事自然语言处理和搜索的创业公司(后被微软收购)
·最初用途是为了解决 Hadoop 中随机读效率低下的问题
2007
·2007年4月，HBase 做为一个模块提交到 Hadoop 的代码库中，代码量~8000行 ·HBase最初的开发人员是Michael Stack和 Jim Kellerman
2010
·2010年5月HBase成为Apache的顶级项目
·同年，Facebook把HBase使用在其消息平台中，是HBase大规模商业化使用的开始
2011年，像阿里这些大厂也引用 HBase 大规模生产使用。
（2）Apache HBase 项目现状
·HBase仍然是Apache社区最活跃的项目之一
·有众多来自中国的 Committer/PMC
·张铎目前为 Apache HBase 社区主席
HBase 代码规模从刚开始 8000 行已经发展到 100 万，HBase 仍然是 Apache 社区最活跃的项目之一，现在有很多来自阿里，小米这些中国公司的贡献者，其中张铎是目前 Apache HBase 社区主席，是一件值得骄傲的事情，因为 HBase 是目前少有的几个由外国人发起，但是目前中国人占主导地位的开源社区。
二、HBase 的架构与原理
1、什么是 HBase
（1)HBase 基本概念
HBase(Hadoop Database)，是一个基于 Google BigTable 论文设计的高可靠性、高性能可伸缩的分布式存储系统.
01 数据模型
·Schema Free
·无数据类型
·大宽表
·行存储，列模型
02 系统架构
·原生分布式架构自动分区
·专为海量数据设计
03 读写能力
·高吞吐，低延迟
·支持随机/范围查询
·适用在线/离线场景
04 特色功能
·TTL
·多版本
·离线导入
·Coprocessor 首
先它的数据模型是一个 Schema story 的也就是说不需要预先去设定这个表的 Schema就可以开始使用，而且它的每一个列没有数据类型，都是用 BAT 数组存储在磁盘上的，同时它支持百万亿的大框架，它还是一个庞存储列模型的一个系统。 第二个HBase 是一个专门为海量数据设计的一个原生的分布式架构，所有的数据都会自动切片分散到各个机器上去，这种架构和 mysql 这种分库分表式分布式是完全不一样的。
第三个特点是 HBase 读写能力非常强，具有海量的吞吐能力同时虽然是个偏僻存储，但是它支持点查和方案查询，同时适用于在线合理性的场景。
还有很多非常有具有特色功能，像 TTL，多版本，离线导入等等，之后都会详细的给大家讲解。
（2）HBase 数据模型
HBase 所有数据都是存储在一个表格里面的，表格下面有不同的列簇，每一个列列簇里面会有非常多的行，每一行里面具有非常多的列，因为 HBase 是一个松散 schema 架构，不同的行的列可以是不一样的，比如 row1 这一行没有 Column B 这一列，那么这一列不会去占用存储空间，同时它每一列可以有不同的值，这些值可以用 timestamp 作为版本号来区分，有人说 HBase 是一个列簇，有人说 HBase 是一个行存，还有人说 HBase 是一个 KV 存储。
HBase 列簇的数据是存储、聚集在一起的，从这个角度上来说， HBase 是一个列存储，每个列簇不同是按行的格式去存储的、组织的，从这个角度来说可以认为 HBase 是行存。
可以通过 HBase row 和 ColumnFamily 加上名字再加上 timestamp 作为唯一确定的 value，所以也可以说 HBase 是 KV 存储。因此都对。
2、HBase 架构
（1）HBase 架构特征
HBase 架构有三个非常明显的特征。
首先它是一个分布式的架构，在市场中 master 只是做一些分布式的协调工作，真正请求的是 RegionServer 是一个无限水平扩展的架构，用户的数据也会平均丰富的这些 RegionServer 上，数据是通过切片的方式把负载均衡到每个 Server 上，所以它的数据是一个平均分散的数据分片。
第三个主要特征是存储成效分离， HBase 本身是不存储任何数据的，所有的数据都是存储在持久化在底层 HDFS 上。
（2）HBase 架构分布式设计
HMaster
主备模式，利用 Zookeeper
协调负责 Region 分配，负载均衡
负责 RegionServer 管理，灾难恢复
HRegionServer
维护 Region 状态
负责处理 put/get/scan 等 IO 请求
向 Master 汇报监控状态
Client
数据增删改查操作
负责数据的路由信息
通过 Cache Region 位置加速访问
Zookeeper 首先是做协调，比如有个 master 要去强储，只有一个 master能储是通过 Zookeeper 实现的，同时 Zookeeper 还存有了 MasterServer 的信息，Zookeeper 的状态等等，Client 在做数据请求的时候首先会和 Zookeeper 做交互， Master 可以提多个但是同一时间只有一个是成主来控制 HBase 集群，它主要是做管理 Regun 分配、负载均衡的工作，同时通过 Zookeeper 监听 Server 的服务状态，如果有 RegionServer 挂掉了就可以发起一个灾难恢复，把原来在 RegionServer 上的 region 迁移到其他的 Server上去， RegionServer 是服务用户请求的主要节点，会负责 Region 的状态，同时用户请出来的时候会去 HBase 上读写数据服务用户的请求， Client 是用户增删改查的入口，也会承载路由工作， Cache 帮助大家去快速的去定位 Region 的位置。
（3）HBase 架构数据分片
范围区域
自动分割
负载均衡
在线 Merge
HBase 的数据分片是一个范围分片，和 CAS 、solar、ES分片不一样，它是把数据按照范围分布在 Region 里面，好处是根据范围从头查到尾，而不像 Hash 分区一样只能变一个分区，分区和分区之间都是无序的，范围分片可以有序的从头编辑到尾，当写数据写到 Region 中去， Region 会变大，当变大到一定的预值之后，就会自动的分裂成两个 Region 然后通过负载均衡算法把 Region 平均分配到不同的 Server 上去，当运行的时间比较久的时候，Region 数据可能会空掉，可以在线的去发起一个乱式，把两个 Region 混到一起从而减少内存的占用，HBase 在分片方面比较方便。
（4）HBase 架构存储计算分离
快速负载均衡
计算存储独立伸缩
存储成本优化
可以异构存储( OSS、S3)
Erasure coding
HBase 本身不会存储任何数据，可能本身会有一些读的 Cache，写的 MemStore ，它主要是做缓存、缓冲，所有的持久化会发生在 HDFS 上，好处是首先它可以做一个快速的 File ，比如 RegionServerA 负载比较高要把 RegionA 迁移到RegionServerB 上去，只需要在 RegionServerA 上发起关闭命令，然后在 RegionServerB 上打开 Region 所在的 Server 文件，就可以开始服务，完全不用搬迁数据，速度基本上是在百毫秒级别，有了计算存储分离之后，还可以独立的去扩缩容计算节点和存储节点，当计算活动的时候单独去扩 Server，当存储活动的时候单独扩存储节点，使用 HDFS 打开软件之后做成本优化，可以利用 HDCS 的机构来降低成本，同时也可以利用开源技术降低存储大小也是为了降低成本。
3、HBase 读写原理
请求路由
客户端如果发送一个请求到服务器，比如要读写某一行数据，首先会去跟 ZooKeeper 要 meta region 所在的 Region 位置，问到之后会往 meta region 所在的 Server 发请求，问 Server 说要的这条数据在哪个 Region 里面，在哪个位置上，问到 Region 之后会直接的去往 Regoin Server 发信息、读写数据，Client 也会把这次成功的信息缓存在本地，下一次要访问这个范围的时候不需要跟着 ZooKeeper 后面 Region 做交互，可以直接去访问，也可能发生负载均衡，Region 可能已经不在这个服务器上， HBase 在这个服务器发信息的时候，会收到一个报错之后又会重新开启路由的操作，直到把 Region 新的位置找到。
（2）LSM-Tree
HBase 使用 LSM-tree(Log-Structured Merge-Trees) 做为存储模型
优点
·所有写入都为顺序 IO
·写性能大幅提升
·可离线导入
缺点
·读有额外开销
·需要定期 Compaction
LSM-Tree 架构的好处是可以把随机写变成顺序写，所以它的读写吞吐要比使用 B+树的引擎高出非常多，在起步的时候，首先 HBase 把数据缓存在 MemStore 里面去，然后顺势的写一个 log 做灾难的恢复，然后数据会定期的 flash 在磁盘上，数据不能更改相当于一颗不能更改的 B 树，当在读的时候会把多个这样的文件，相当于多个 B 树默认为一个 tip 做数据的读取，优点除读写吞吐非常大之外，还有一个非常大的优势是可以做离线导入，可以事先的利用一些其他的系统把数据排序，然后生成一棵 B 树的文件，直接写在磁盘上，然后加到 Tree 里面，数据就立马可读，而不是像 B+树要一条一条地插到 B 树里面去才可以读，这个结构也是有一定确定的，在读的时候需要把多棵树一起默指，相对于只有一棵树的 B+树来说，它的读写成本是比较大，同时它要定期的去做 Compaction 把多棵树磨成一颗才能去减少读的放大，否则开销很大这是它的一些缺点。
（3）读流程
在读的时候首先会根据查询到条件选择对应的 Range 、store，store 就是刚才所说的列簇，会根据产品条件去过滤掉数据不可能存在的文件，比如根据 Key Range 、Bloom Filter、Time Range过滤，然后把过滤出来的文件形成一个 KeyValue Heap 形成一个最小堆，然后再根据从小到大的顺序，把这些数据破出来返回给客户端， HBase 有 Menstore ，有 BlockCache 是不是先读 Cache 是不稳定的呢？ 实际上 Menstore 的位置和 HFile 的位置是等价的，会和 HFile 一起去构建 BlockCache ，它实际上是文件某一个部分的 Cache ，当要补到文件的这个部分的时候，发现Cache 的时候可以读取磁盘，而是直接读这个内存，所以读写架构，并不是大家所想象的那样，先读 Cache 再做磁盘而是把所有的数据都构成 keep 来做成 LSM-Tree 的架构。
4、HBase 特色功能
（1）TTL
·特性介绍
·对于每一行中的每一列数据，系统都保存了其最后更新时间
·以秒为单位来设置 TTL(Time To Live)长度，每一行中的每一列数据一日达到到期时间，系统将自动删除
·TTL 设置支持表、行，列多个维度
·使用场景
·适用于无需永久保存的数据，
·常用于日志、监控、轨迹、浏览记录、费用详单等场景
具体的特色功能，在这个 mysql 中去删除一些过去数据非常麻烦，首先要写个脚本把这个课题的数据，根据条件选出来，然后再一条一条删除，要控制脚本的速度，删快的话可能会影响线上系统。在 HBase 中不用这么麻烦，每一个列都会有一个时间戳，如果没有显示的去指定时间戳，时间戳就是这一列的写入时间，根据时间戳可以设置 TTL 过去的时间，当这些数据超过了 TTL 时间， HBase 会自动的在 Compaction 中把过程数据删掉，作用是在有一些场景中比如监控、历史记录、轨迹场景中所有数据不需要永久保存，可以给系统去设计时间，比如监控系统只需要最近一个月的监控，一个月之前监控数据就可以被TTL自动获取而节省存储的成本。
（2）多版本
特性介绍
当数据更新后，之前旧版本仍然可以被访问
旧版本的数量可以设定至多达上百万
系统自动删除多余的旧版本
使用场景
适用于需要维护最近N次变更值的数据，如浏览记录、轨迹记录、登陆记录、交易记录等
常用于实时推荐、安全风控、营销圈人等场景
例如:若保留版本数为100，则系统中会为设备1001的"上次登陆时间”、"上次登陆城市”字段最多保留100条记录，超出部分自动删除，等价于维护最近100次的登陆时间和城市
特点和列的时间戳有关系，可以帮大家去自动的保存最近的n个版本，比如十个版本，当有第11版本写信的时候最老的版本就会自动过去掉，功能作用比如要做一个系统记录一个用户最近十次登陆地点做风控的分析和查询，可以设置表的最大版本是十个，当登录到11次的时候，第一次登录的信息就被删掉，HBase会自动去维护客户最近十次登陆地点，功能非常方便。
（3）Bulkload
离线生成 HFile，秒级加载海量数据
另外一个功能是 Bulkload，HBase 是一个 LSM-Tree 的架构，可以通过一些 Wap 的系统，比如 Spark、Mapper、Reduce，预先把这些数据做排序写在HDFS上，然后通过 Bulkload 瞬间载入到 HBase 的 Region 中去，这些数据就立马可读，这个过程相比正常的过程中会少几个写 Memstore、log 一些非常繁杂的计算过程，等于少了非常多的把计算 log 到外部系统上去，也不用去做 compassion，只要外部系统生成好之后某个数据就可以实现秒级加载、海量数据的特性。
（4）Coprocessor
EndPoint
分布式计算
算子下推
Observer
HookHBase内部逻辑
实现触发器
Coprocessor 之后，用户可以把 HBase 变成任何想要变成的业务系统，Coprocessor 分为两类，一类是 EndPoint 意思是比如以前要实现一个 counter 要去数据，以前就必须把这些数据全部拿到客户端来一条条数，有了 EndPoint 之后用户可以把自己的逻辑嵌入到 HBaseObserver 上去，通过公式来实现分布式计算以及计算的下推，算子下移，Coprocessor 场景可以先在 Observer 上把这些数据全部看到在然后客户端上做汇总，少了非常多的数据传输的内容，另外是 Observer来实现触发器的一些功能。
三、HBase 使用场景
1、HBase 的生态
社区对 HBase 定义是希望 HBase 能够专注做大数据存储这一块，上层这些产品更愿意去交给生态产品去实现，比如可以给 HBase 添加一个 Flink 实现 SQL 访问、索引里面的功能，实现一些简单的 OITB 的查询，也可以通过像 MapReduce、Spark、Hive 分析系列组键给 HBase 做分析，也可以和 Flink 结合实现结构表的存储来实现一些流失的计算， HBase 的生态是非常丰富的，因为它的生态实际上是 Hadoop 的生态。
HBase 的场景
HBase 基本上可以满足所有大部分场景的需求，使用 HBase 的原生 API 可以实现非常高性能的推荐画像，订单存储以及 Feeds 流等，然后可以在 HBase 基础上加一些组件来实现其他的场景的使用，加上 Feeds 之后可以把 HBase 变成一个 NewSQL 数据库，也可以用 Spark 写 Cube 分析做一些报表的产生，也可以让 HBase 加上 Cube 之后把 HBase 变成一个时空数据库或者是一个实时数据库。
2、使用 HBase 的公司
基本上所有的大厂都在使用 HBase ，京东就有3000多台的一个群体，小米，爱奇艺都有非常多的，阿里内部区 HBase 的规模有2万台，HBase 应用广其中一个很大的原因是背后没有一家商业公司来对 HBase 做控制，所有的人都可以自由地去提供代码，所以大厂都非常积极的在向 HBase 贡献它的功能和代码，让 HBase变得更加的强大，功能更全，性能和威信也在逐步地提高。
四、总结
讲了大数据的四个特性， HBase 这些特点非常好的契合大数据的存储的特性，首先 HBase 具有非常突出的数据写入能力，在面对大数据 Velocity 这样一些特性的时候，它能快速的把数据处理完，消化掉，因为确实具有非常强的弹性生存能力，在面对大数据体量时候能够水平无限的扩展来存储数据，同时建成具有动态力和 variety 这样一些强大的业务定制能力，能适应业务的变化多端从而能够满足大数据 variety 的一个特点，最后 HBase 有一个非常高效多维的删除能力来满足大数据 variety 真实性的特点，能够帮助大家快速的处理掉脏数据和过期数据，HBase 是一个为大数据而生的数据库。
