八年磨一剑
1.1 HBase 的前世今生
关系型数据库的发展已经经历了 40 多年的历史了, 而 HBase 以及大数据这套东 西的历史大概从 2006 年被认为是大数据的发起时期到现在, 也就是 13 年左右 而已. 那么, 为什么会出现 HBase 以及 Hadoop 整体生态链的这些内容呢? 这 是因为在大数据时代, 传统数据库需要面对很多挑战, 出现了数据量增多, 业务 复杂度提升, 非结构化数据和结构化数据并存等诸多问题. 这些问题所带来的最 直接的就是成本挑战, 因此特别需要价格低廉的数据库来解决问题.
这也就是 Google 提出 BigTable 开源最佳实现的原因. Google 是全球最大的搜 索引擎, 当他们发现出现的存储成本问题之后, 通过内部研究就发出来关于 BigTable 的这篇论文, 而大概在 2006 年的时候也就发起了 HBase 这个项目, 并 且在两年之后其就成为 Hadoop 的子项目, 经过了十几年的发展, 目前演变到了 2.0 版本. HBase 能够帮助我们以低成本解决大数据量, 高并发, 低时延的问题, 并且保证了低成本的存储.
1.2 阿里的 HBase 之旅
为何叫做 "八年磨一剑" 呢? 这其实与阿里巴巴对于 HBase 的研发历程是紧密相 关的. 在 2010 年, HBase 正式成为了 Apache 的顶级项目, 与此同时阿里巴巴 内部的业务也达到了瓶颈期, 因此在 2010 年阿里巴巴开始对于 HBase 进行预研, 经过了持续 8 年的研发, 在 2017 年的时候输出到阿里云上, 并将 HBase 的能力 提供给广大的用户. 其实, 在阿里集团内部已经有了超过 12000 台的 HBase 服 务器规模, 而最大集群也超过了 2000 台, 这在世界上都是数一数二的, 并且也 经过了天猫 "双 11" 的历练.
阿里投入了很多资源和人力来研发 HBase, 所以开源社区也给予了非常积极的回 馈. 目前第一个东八区的 PMC 就诞生在阿里云, 而整个阿里集团内有 3 个 HBase PMC,6 个 Committer 以及几十位核心贡献者, 并且共享了 200 多个核心 patch. 此外, 阿里云的 HBase 版本相比于开源版本在很多方面也有极大的提升.
1.3 HBase 适合的场景和问题
(1) 关系型数据库与 HBase 的区别
HBase 等 NoSQL 出现的原因是传统的关系型数据库在面对大数据量, 高业务复 杂度以及高成本的挑战时, 无法对于底层进行优化和改进. 如下图所示的表格能 够帮助大家对比关系型数据库与 HBase 的主要区别.
关系型数据的主要应用场景基本都是交易类场景, 而 HBase 所代表的的非关系 型数据库所需要解决的就是兼容结构化和非结构化的数据, 解决交易场景之外的 实时业务或者 OLAP 分析以及大规模存储. 而在可扩展性上, 关系型数据库单表 不超过千列, 一般在 GB~TB 级别, 而对于 HBase 而言, 这样的数据量就不算什 么挑战了, 一张表会轻松突破百亿行和百万列, HBase 比较适合 200G 到 10P 数据量级别. 在性能方面也能体现出关系型数据和 HBase 最大的区别, 对于关系型 数据库而言, 10W 级别的性能就已经很强了, HBase 能力能够达到 5000 万并发 量, 其核心需要解决的就是高并发和低吞吐. 在成本方面, 传统关系型数据库需 要使用高性能硬件, 随着也带来了成本问题, 而 HBase 则是选择了另外一条路, 通过本地盘和普通 CPU 实现, 其核心的存储结构不再是关系型存储结构, 而是 合并成批量读写, 充分地利用硬盘高吞吐的能力来达到低成本. 总结而言, HBase 数据库解决的核心问题就是兼容结构化和非结构化的数据, 大数据量, 高并发, 低延时等问题.
(2) ApsaraDB HBase 典型场景
NoSQL 数据库和传统数据的一个较大区别就是传统数据库比较适合所以行业的 交易模型, 而 HBase 的能力非常聚焦, 其适合时序数据, 时空数据, Cube 分析, NewSQL,Feeds 流, 消息 / 订单存储, 推荐画像, 对象存储等 8 个场景. 接下来 逐一介绍各个典型场景.
时序数据: 在如今这个 IoT 的时代, 出现了大量的时序数据. 因为各种传感器比 较多, 时序数据需要满足高并发, 海量存储等基本要求, 除了 IoT 之外, 在股票 以及监控数据里面也需要用到这样的时序数据.
时空数据: 轨迹以及气象网格数据也需要 HBase 的高并发和海量存储能力. Cube 分析: 实时报表以及数据科学家需要进行实时数据分析, 这些需要以很低的时延查询出来, 并且并发量非常高, 这时候就需要用到 Cube 的能力.
NewSQL: 对于传统 SQL 所不能解决的一些问题, 比如性能瓶颈, 这些就需要使 用 NewSQL 能力, 并且除了能够解决性能问题之外, 还会有一定的更新能力. HBase 能够较好地适应这种场景, 除了支持 SQL 之外, 还支持二级索引, 动态增 加列, 所以很多元数据库也使用了 HBase.
Feeds 流: Feeds 流的典型应用场景就是微信朋友圈以及微博等社交网络, 其所 需要的就是高并发的请求访问, 因为用户数非常多, 需要保证一致性体验, HBase 非常适合这样的场景.
消息 / 订单存储: 订单数量是非常多的, 所以需要强同步, 并且可靠性不能丢, 对于聊天消息而言也是一样的, 这就会用到 HBase 的强一致性同步以及大数据 存储能力.
推荐画像: 推荐画像在用户特征里面使用的比较多, 一般而言在做画像时对于用户会勾画很多特征, 数据表中的每一列就可以放一个特征, 而随着不断深入地挖掘, 特征就会越来越多, 而传统关系型数据库首先不能够存储太多列, 超过 1000 列就遇到瓶颈了, 而在真正进行存储的时候可能需要百万列. 其次, 对于传统关系型数据库而言, 如果某列存在空值, 依然占据空间, 而 HBase 不仅可以动态地增加列, 而且如果某列为空就不会占据空间, 所以非常适合这样的场景.
对象存储: 通常而言对象存储最可能用到的就是 OSS, 但是 OSS 比较适合高并 发地写, 但是并不适合高并发地读, 但是还有很多数据比如图片, 网页, 文档, 新闻等, 除了需要能够写入之外, 还需要提供高并发地查询能力的场景下, 就比 较适合使用 HBase 作为前置数据存储. 而如果随着时间的迁移, 一些数据的重要 性降低了, 那就可以通过 HBase 本身的能力将数据迁移到 OSS 里面, 作为温数据或者冷数据的归档.
上面大致分享了 HBase 的整个发展历程以及 HBase 的适合场景. 总结而言, 就是阿里巴巴经过了 8 年的研发将自己改进的 HBase 版本能够提供给广大的用户, 这就叫做 8 年磨一剑. 这首先说明了阿里巴巴有很强的技术实力, 其次说明了 HBase 有它自己非常适合的场景, 比如高并发, 低时延以及低成本需求的场景.
2. 重新定义 HBase
大家都知道开源软件在稳定性以及各方面的能力上都往往不能够达到企业实际 应用的要求. 虽然这些开源软件的核心能力非常强大, 但是当在企业中应用的时 候却是比较困难的. 而阿里巴巴在 HBase 方面做了很多的工作, 也经过内部的使 用提升了 HBase 的能力, 使其能够更好地适应企业的应用, 并且针对不同的场景 提供了不同的产品形态.
2.1 HBase2.0 解读
来源: https://yq.aliyun.com/articles/686783