大数据时代数据库-云HBase架构&生态&实践

2018 年 6 月 5 日 大数据和云计算技术

2018第九届中国数据库技术大会，阿里云高级技术专家、架构师封神（曹龙）带来题为大数据时代数据库-云HBase架构&生态&实践的演讲。主要内容有三个方面：首先介绍了业务挑战带来的架构演进，其次分析了ApsaraDB HBase及生态，最后分享了大数据数据库的实际案例。

业务的挑战

存储量量/并发计算增大

现如今大量的中小型公司并没有大规模的数据，如果一家公司的数据量超过100T，且能通过数据产生新的价值，基本可以说是大数据公司了。起初，一个创业公司的基本思路就是首先架构一个或者几个ECS，后面加入MySQL,如果有图片需求还可加入磁盘，该架构的基本能力包括事务、存储、索引和计算力。随着公司的慢慢发展，数据量在不断地增大，其通过MySQL及磁盘基本无法满足需求，只有分布式化。这个时候MySQL变成了HBase,检索变成了Solr/ES，再ECS提供的计算力变成了Spark。但这也会面临存储量大且存储成本高等问题。

另外一个趋势就是非结构化的数据越来越多，数据结构的模式不仅仅是SQL，时序、时空、graph模式也越来越多，需要一些新的存储结构或新的算法去解决这类问题，也意味着所需要做的工程量就会相对较高。

引入更多的数据

对于数据处理大致可归类为四个方面，分别是复杂性、灵活性、延迟<读,写>和分布式，其中分布式肯定是不可少的，一旦缺少分布式就无法解决大规模问题。灵活性的意思是业务可以任意改变的；复杂性就是运行一条SQL能够访问多少数据或者说SQL是否复杂；延迟也可分为读与写的延迟。Hadoop & Spark可以解决计算复杂性和灵活性，但是解决不了延迟的问题；HBase&分布式索引、分布式数据库可以解决灵活性与延迟的问题，但由于它没有很多计算节点，所以解决不了计算复杂性的问题。Kylin(满足读延迟)在计算复杂性与延迟之间找了一个平衡点，这个平衡点就是怎样快速出报表，但对于这个结果的输入时间我们并不关心，对于大部分的报表类的需求就是这样的。每个引擎都是一定的侧重，没有银弹！

ApsaraDB HBase产品架构及改进

应对的办法

我们也不能解决所有的问题，我们只是解决其中大部分的问题。如何找到一个在工程上能够解决大部分问题的方案至关重要，应对办法：

分布式：提供扩展性
计算力延伸：算子+SQL，从ECS到Spark其本质其实就是一种计算力的延伸
分层设计：降低复杂性，提供多模式的存储模型
云化：复用资源&弹性，降低成本

基本构架

首先包含了两个分离

分别是HDFS与分布式Region分布式检索分离
SQL时空图时序Cube与分布式Region检索分离
大致的分层机构如下：
第一层：介质层，热SSD介质、温SSD&SATA 混合、冷纯SATA(做EC)
第二层：分布式文件系统，也就是盘古。事实上越是底层越容易做封装优化。
第三层：分布式安全隔离保障层QOS，如果我们做存储计算分离，就意味着底层的三个集群需要布三套，这样每个集群就会有几十台甚至几百台的节点，此时存储力是由大家来均摊的，这就意味着分布式安全隔离保障层要做好隔离性，引入QOS就意味着会增加延迟，此时会引入一些新的硬件(比如RDMA)去尽可能的减小延迟。
第四层：分布式文件接口：HDFS & API(此层看情况可有可无)
第五层：我们提供了两个组件，分布式Region-HBase与分布式检索-Solr，在研究分布索引的时候发现单机索引是相对简单的，我们提供针对二级索引采取内置的分布式Region的分布式架构，针对全文索引采取外置Solr分布式索引方案
第六层：建设在分布式KV之上，有NewSQL套件、时空套件、时序套件、图套件及Cube套件
另外，可以引入spark来分析，这个也是社区目前通用的方案。

解决成本的方案

对于解决成本的方案简单介绍如下：

分级存储：SSD与SATA的价格相差很多，在冷数据上，我们建议直接采取冷存储的方式，可以节约500%的成本
高压缩比：在分级存储上有一个较好的压缩，尤其是在冷数据，我们可以提高压缩比例，另外分布式文件系统可以采取EC进一步降低存储成本，节约100%的成本
基础设施共享：库存压力分担，云平台可以释放红利给客户
存储与计算分离：按需计费
优化性能：再把性能提升1倍左右

云数据库基本部署结构

假设在北京有三个机房可用区A、B和C,我们会在可用区A中部署一个热的存储集群，在北京整体区域部一个冷的存储集群，实际上有几个可用区就可以有几个热集群，主要是保障延迟的；冷集群对延迟相对不敏感，可以地域单独部署，只要交换机满足冷集群所需的带宽即可。这样的好处是三个区共享一个冷集群，就意味着可以共享库存。

ApsaraDB HBase产品能力

我们提供两个版本，一是单节点版，其特点是给开发测试用或者可用性不高，数据量不大的场景。二是集群版本其特点是高至5000w QPS，多达10P存储与高可靠低延迟等。

数据可靠性：99.99999999%：之所以可靠性可以达到如此之高，其核心的原因就是存储集群是单独部署的，其会根据机架等进行副本放置优化
服务可用性：单集群99.9% 双集群99.99%。
服务保障：服务未满足SLA赔付。
数据备份及恢复。
数据热冷分离分级存储。
企业级安全：认证授权及加密。
提供检索及二级索引及NewSQL能力。
提供时序/图/时空/Cube相关能力。
与Spark无缝集成，提供AP能力。

数据备份及恢复

备份分为全量备份HFile与增量量备份HLog；恢复分为HLog转化为HFile和BulkLoad加载。阿里云集团迄今为止已经有一万两千多台的HBase,大部分都是主备集群的，在云上由于客户成本的原因，大部分不选择主备，所以需要对数据进行备份。其难点在于备份需要引入计算资源，我们需要引入弹性的计算资源来处理备份的相关计算任务。

Compaction 离线Compaction(研究中)

我们在内部研究如何通FPGA对Compaction进行加速，这会使得集群运行比较平缓，特别是对计算资源少，存储量大的情况下，可以通过离线的作业处理Compaction。

组件层

我们有5中组件，NewSQL(Phoenix)、时序OpenTSDB、时空GeoMesa、图JanusGraph及Cube的Kylin，及提供HTAP能力的Spark。这里简单描述几个，如下：

NewSQL-Phoenix

客户还是比较喜欢用SQL的,Phoenix会支持SQL及二级索引，在超过1T的数据量的情况下，对事务的需求就很少（所以我们并没有支持事务）；二级索引是通过再新建一张HBase表来实现的。在命中索引的情况下，万亿级别的访问基本在毫秒级别，但由于Phoenix聚合点在一个节点，所以不能做Shuffle类似的事情，同时也就不能处理复杂的计算，所以任何说我是HTAP架构的，如果不能做Shuffle，就基本不能做复杂的计算。