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

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

讲师介绍：

　　封神，真名曹龙，09年加入阿里，现任阿里云高级技术专家、架构师，专一于大数据分布式计算、数据库、存储领域，前后研发上万台Hadoop、ODPS集群，负责阿里YARN、Spark及自主研发内存计算引擎，目前为广大公共云用户提供专业的云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，就基本不能作复杂的计算。

HTAP – Spark

　　在HTAP-Spark这部分主要介绍一下RDD API、 SQL、直接访问HFile的特色。

　　· RDD API具备简单?便，默认支持的特色，但高并发scan大表会影响稳定性;

　　· SQL支持算?子下推、schema映射、各类参数调优，高并发scan大表会影响稳定性;

　　· 直接访问HFile，直接访问存储不通过计算，大批量量访问性能最好，须要snapshot对齐数据。

　时序 – OpenTSDB & HiTSDB

　　TSD没有状态，能够动态加减节点，并按照时序数据的特色设计表结构，其内置针对浮点的高压缩比的算法，咱们云上专业版的HiTSDB增长倒排等能?，并可以针对时序增长插值、降精度等优化。

大数据数据库的实际案例

　　如下简单介绍几个客户的案例，目前已经在云上ApsaraDB HBase运行，数据量基本在10T以上：

某车联网公司

　　这是一个车联网的客户，有100万车，每辆车每10秒上传一次，每次1KB，这样一年就有300T数据，六个月以上是数据低频访问，因此他要作分级存储，把冷数据放到低介质上

某大数据控公司

　　这是一个大数据控公司，它大约有200T+的数据量，将HBase数据 (在线实时大数据存储)做为主数据库，先用HBase作算法训练，再用HBase SQL出报表，另外作了一套ECS进行实时查以便与客户之间进行数据交换。

某社交公司

　　社交会有大量的推荐，因此SLA要求高达99.99，并采用双集群保障，单集群读写高峰QPS 能够达到1000w+，数据量在30T左右。

　某基金公司

　　这是一个金融公司，它有10000亿以上的交易数据，目前用多个二级索引支持毫秒级别的查询，数据量在100T左右

某公司报表系统

　　先离线建好Cube再把数据同步到HBase中，实时数据经过Blink对接进行更新，数据量在可达20T左右