BigData NoSQL —— ApsaraDB HBase数据存储与分析平台概览

1、引言

时间到了2019年，数据库也发展到了一个新的拐点，有三个明显的趋势：

1. 愈来愈多的数据库会作云原生(CloudNative)，会不断利用新的硬件及云自己的优点打造CloudNative数据库，国内以阿里云的Cloud HBase、POLARDB为表明，此块文章会有必定的引述，但不是本文的重点。
2. NoSQL正在解决BigData领域的问题。根据Forrester NoSQL的报告，BigData NoSQL是提供 存储、计算处理、支持水平扩展、Schemaless以及灵活的数据模型，特别提到须要支持复杂计算，通常经过集成Spark或者实现单独的计算引擎实现。Cassandra商业化公司Datastax提供的产品是直接在Cassandra之上集成了Spark，另外ScyllaDB公司首页的宣传语就是The Real-Time Big Data Database。大数据的5V特性，包括 Volume：数据量大，包括采集、存储和计算的量都很是大；Variety：种类和来源多样化，包括结构化、半结构化和非结构化数据；Value：数据价值密度相对较低，或者说是浪里淘沙却又弥足珍贵；Velocity：数据增加速度快，处理速度也快，时效性要求高；Veracity：数据的准确性和可信赖度，即数据的质量须要高。5V特性可使用BigData NoSQL数据库很好的知足，且又能知足实时的写入，分析及展示。
3. 愈来愈多的公司或者产品都是融合多个能力，Strapdata公司把Cassandra及ElasticSearch的能力融合在一块儿；Datastax直接在Cassandra之上集成了Spark；SQLServer也是融合了Spark，打造Native Spark知足DB计算能力外延的商业诉求。

阿里云HBase通过公共云两年（单独的HBase在阿里内部已经发展快9年）的发展，融合开源Apache HBase、Apache Phoenix、Apache Spark、Apache Solr等开源项目，再加上一系列自研特性，知足 【一体化数据处理平台，提供一站式能力】 , 基本架构以下：

 

咱们是站在Apache巨人的肩膀上，自研了 ApsaraDB Filesystem、HBase冷热分离、SearchIndex、SparkOnX、BDS等模块，优化了HBase、Phoenix、Spark等内核一些patch，并反馈到社区，维护打造了多模服务、数据工做台等一些列的平台能力。自研部分是咱们平台核心的核心竞争力，每一层每个组件都是咱们精心打造，知足客户数据驱动业务的实际需求。为了下降客户的准入门槛，咱们在Github上提供了Demo支持：aliyun-apsaradb-hbase-demo，欢迎你们关注，并贡献代码。接下来笔者会介绍各层，力求简单通俗，文中有大量的连接以衍生阅读。

2、业务视角及数据流

做为一个存储计算平台，价值在知足不一样的业务需求。见下图：
此图描述了数据的来源、通道到沉淀到云HBase平台，再经过平台提供的Spark引擎去挖掘价值反馈给业务系统。此相似一个循环系统，在阿里内部形象称为【业务数据化，再数据业务化】。

 

 

结合架构图及业务图，此平台融合了 存储（包括实时存储及离线存储）、计算、检索等技术。整个系统都打造在ApsaraDB Filesystem统一文件层之上，把检索经过Phoenix的SearchIndex包装以下降易用性，打造领域引擎知足领域的需求，内置BDS(数据通道)实时归档数据到列存，再经过Spark引擎挖掘价值。
详细参考：【选择阿里云数据库HBase版十大理由】

3、统一文件访问层

ApsaraDB Filesystem（简称ADB FS）以Hadoop FileSystem API为基础构建了云HBase生态文件层底座。面向HBase生态提供了无感知的混合存储能力，极大简化了HBase生态接入云端多存储形态的复杂环境。支持OSS、阿里云HDFS、基于云盘或者本地盘构建的HDFS以及基于共享云盘构建的系统。每种分布式文件系统所用的硬件不一样、成本不一样、延迟不一样、吞吐量不一样（这里不展开）。咱们能够不断扩展，只要添加一个实现xxxFileSystem便可。基于OSS直接实现的FS是没法具有原子性的元数据管理能力的，实现方案是在HDFS的namenode存元数据，实际的存储存放在OSS之上。对Rename操做只须要移动元数据，因此很是轻量。

 

 

4、HBase KV层

HBase是基于Bigtable在hadoop社区的开源实现，提供了如：稀疏宽表、TTL、动态列等特性。HBase在阿里已经发展9年，已经有数位PMC及Committer，能够说在国内阿里在HBase的影响力仍是首屈一指的。社区也有很多的Patch也是阿里贡献。在18年，云HBase首家商业化了HBase2.0，并贡献了数十个BugFix给社区。有很多客户单独使用HBase API知足业务需求，也有很多客户使用Phoenix NewSQL层，NewSQL层提高易用性及提供了不少好用的功能。在HBase层面，除了修复社区的Bug之外，也作了几个较大的特性。
在对比关系型数据方面，HBase也有自然的优点，参考：对比MySQL，一文看透HBase的能力及使用场景

• 冷热分离
  冷热分离能够下降存储成本66%左右。普遍应用于车联网、冷日志等场景下。咱们把冷数据存放到OSS之上，且用户还可使用HBase的API访问。基本原理是：把Hlog存在HDFS之上，再把冷的HFile存放在OSS之上。

 

 

• GC优化
  GC一直是Java应用中讨论的一个热门话题，尤为在像HBase这样的大型在线存储系统中，大堆下(百GB)的GC停顿延迟产生的在线实时影响，成为内核和应用开发者的一大痛点。平台实现了CCSMap新的内存存储结构，结合offheap及新的ZenGC等一列的优化，在生产环境young GC时间从120ms减小到15ms，在实验室进一步下降到5ms左右。能够参考文章：如何下降90%Java垃圾回收时间？以阿里HBase的GC优化实践为例

5、检索层

HBase底层基于LSM，擅长前缀匹配和范围查找，数据模型上属于行存，大范围扫描数据对系统影响很大。咱们知道，用户的需求每每是各式各样，不断变化的。对于要求高TPS，高并发，查询业务比较固定且简单的场景，HBase能够很好知足。更复杂一些，当用户对同一张表的查询条件组合有固定多个时，能够经过二级索引的方式来解决，可是二级索引有写放大问题，索引数量不能太多，通常建议不超过10个。当面对更复杂的查询模式，好比自由条件组合，模糊查询，全文查询等，用当前的索引技术是没法知足的，须要寻求新的解决方案。咱们容易想到，搜索引擎，好比Lucene、Solr以及ElasticSearch，是专门面向复杂查询场景的。为了应对各类复杂的查询需求，搜索引擎运用到了大量跟LSM Tree十分不一样的索引技术，好比倒排、分词、BKD Tree作数值类型索引、roaring bitmap实现联合索引、DocValues加强聚合和排序等。使用搜索引擎的技术来加强HBase的查询能力是一个十分值得深刻探索的技术方向。

当前用户要想实现，复杂查询，只能从新购买新的搜索集群，经过导数据的方式将数据导入到新的搜索服务中。这种方式存在不少这样那样的问题：维护成本比较高，须要购买在线数据库，分析数据库和数据传输服务；学习门槛高，须要同时熟悉至少上诉三种服务；没法保证明时性，在线库入库和检索库入库效率不匹配；数据冗余存储，在线库索引数据和结果数据设计的全部数据都须要导入；数据一致性难保证，数据乱序问题十分常见，特别是对于分布式在线库更是如此。云HBase引入Solr，并在产品和内核上作了一系列工做，将其打形成统一的产品体验，一揽子解决了前述全部问题。用户在控制台上一键能够开通检索服务，参考文章：云HBase发布全文索引服务,轻松应对复杂查询。

 

 

检索服务的架构如上图所示，最底层是分布式文件系统的统一抽象，HBase的数据和Solr中的数据都会存储在分布式文件系统中。最上层是分布式协调服务Zookeeper，HBase、Indexer、Solr都是基于其实现分布式功能。Indexer实现了存量HBase数据的批量导入功能，有针对性地实现了数据批量导入的分布式做业机制。Indexer服务也实现了实时数据的异步同步功能，利用HBase的后台Replication机制，Indexer实现了Fake HBase功能，接收到HBase的数据后，将其转换为Solr的document，并写入solr。针对HBase写入速度比Solr快的问题，咱们设计并实现了反压机制，能够将Solr中数据的延迟控制在用户设定的时间范围内，该机制同时也避免了HLog消费速度过慢的堆积问题。实时同步和批量导入能够同时运行，咱们经过保序的时间戳保证了数据的最终一致性。为了提升产品的易用性，咱们还基于Phoenix 实现了检索服务的SQL封装，并在存储查询等方面作了一系列优化升级，该部分在下个章节将会介绍。

6、NewSQL Phoenix

Phoenix是HBase之上的SQL层，Phoenix让HBase平台从NoSQL直接进化到了NewSQL。在HBase的基础之上，再支持了Schema、Secondary Indexes、View 、Bulk Loading(离线大规模load数据)、Atomic upsert、Salted Tables、Dynamic Columns、Skip Scan等特性。目前云上最大客户有200T左右，且50%+的客户都开通了Phoenix SQL服务。咱们修复了社区数十个Bug及提了很多新特性，团队也拥有1位Committer及数位contributor。在18年咱们在充分测试的基础上，先于社区正式商业化了Phoenix5.0，并支持了QueryServer,支持轻量的JDBC访问。同时，社区的5.0.1也将由咱们推进发布。

Phoenix自己咱们作了一系列稳定性，性能等方面的优化升级，主要有：客户端优化MetaCache机制，大数据量简单查询性能提高一个数量级；索引表回查主表，使用lookupjoin的方式优化，性能提高5到7倍；轻客户端优化batch commit，性能提高2到3倍；解决Phoenix时区问题，提升易用性，下降数据一致性问题几率；禁用DESC，扫全表等有风险功能；实现大批量数据导入的Bulkload功能；等等。这些稳定性和性能方面的提高，在用户侧获得了很好的反馈。

 

 

Phoenix目前基本的架构如图所示，咱们让Phoenix支持了HBase和Solr双引擎，用户可使用SQL实现对HBase和Solr数据的管理和查询，大大提升了系统的易用性。Solr和HBase之间的同步机制能够参考上节。在支持复杂查询方面，咱们设计并实现了一种新的索引：Search Index，使用方式跟Phoenix的Global Index相似，主要区别在于Search Index的索引数据存储在Solr里面，而Global Index的索引数据是一张单独的HBase表。直接经过SQL管理Search Index的生命周期、数据同步和状态，自动映射数据字段类型，并经过SQL支持复杂查询，这极大下降了用户的使用门槛。Search Index能够统一根据HBase和Solr的特性作优化，因为原表在HBase中能够经过RowKey高效查询，Solr中只须要存储做为查询条件的字段的索引数据，查询字段的原数据不须要存储在Solr中，表中的非查询字段则彻底不须要存储到Solr中。相对于用户单独购买检索产品，并同步数据的方案，Search Index能够大大下降存储空间。同时，根据索引特性，Phoenix在作执行计划优化时，能够动态选择最优的索引方案。

咱们还打造了一个系列的文章，这些文章是不少国内用户熟悉和学习Phoenix的入门资料，在社区里面也收获了较高的影响力，参考 Phoenix入门到精通

7、多模领域层

数据类型有表格、文档、宽表、图、时序、时空等不一样的类型。云HBase之上打造了 HGraphDB分布式图层、OpenTSDB分布式时序层、Ganos分布式空间层，分别知足3大子场景的诉求。每一个都是分布式的组件，具有PB级别的存储、高并发读写及无限扩展的能力。

• HGraphDB
  HGraphDB是云HBase彻底自研的组件。HGraphDB基于Tinker pop3实现，支持集成Tinker pop3全套软件栈以及Gremlin语言。HGraphDB是一个OLTP图库，支持schema以及顶点和边的增删改查还有图的遍历。图数据库HGraphDB介绍
• OpenTSDB
  OpenTSDB是社区在HBase的基础之上提供的时序引擎，以HBase为底座，知足PB级别的时序存储需求。团队作了大量优化，为了提高稳定性，其中【时间线压缩优化】是一个比较重要的优化，见：云HBase之OpenTSDB时序引擎压缩优化
• Ganos
  Ganos取名于大地女神盖亚（Gaea）和时间之神柯罗诺斯（Chronos），表明着“时空” 结合。Ganos空间算子加强、时空索引加强、GeoSQL扩展等，与Spark结合支持大规模遥感空间数据在线分析与管理。详细参考文章：阿里云时空数据库引擎HBase Ganos上线，场景、功能、优点全解析

8、列式存储

行列混合HTAP一直是各大数据库梦寐追求大统一的技术，相似于M理论想统一量子力学与万有引力。目前看起来一份存储难以知足各类诉求，通用的作法是行存与列存的数据分开存，实现手段一种是经过同步的方案把行存的数据再转存一份列存，另外一种是经过raft等变种协议的手段实现行列副本同时存在。
HBase擅长在线查询场景，底层的HFile格式实际仍是行存，直接Spark分析HBase表在大范围查询的状况下性能通常(Spark On HBase也有不少优化点)。在这样的背景下咱们构建了HBase的实时HLog增量同步归档到列存的链路，来有效知足用户对于HBase数据分析的需求。列存的压缩比比行存高，增长部分存储成本，有效的加强分析能力，用户是可以接受的。HBase搭配列存能够有效的驱动用户业务的发展，列存分析后的结果数据回流到HBase支持业务，让用户业务在HBase平台中快速迭代。在列存之中，也有相似LSM的 Delta+全量的，好比Kudu以及 Delta Lake。云HBase参考了Delta Lake及Parquet技术，提供更加高效的一体化分析。

• Parquet
  Parquet的灵感来自于2010年Google发表的Dremel论文，文中介绍了一种支持嵌套结构的存储格式，而且使用了列式存储的方式提高查询性能，目前Parquet已是大数据领域最有表明性的列存方式，普遍应用于大数据数据仓库的基础建设。
• Delta
  Delta本来是Spark的商业公司Databriks在存储方面作的闭源特性，偏向实时读写，已于近期开源，核心是解决了大数据分析场景中常见的数据更新的问题。具体作法按列式格式写数据加快分析读，增量更新数据 delta 则采起行式写入支持事务和多版本，而后系统经过后台不断地进行合并。
• 一键同步

 

 

用户能够根据自身的业务需求进行转存，对于对实时性要求比较高的用户，能够选择实时同步的方式，BDS服务会实时解析HLog并转存到Delta，用户能够经过Spark对Delta直接进行查询；而对于离线场景的转存，用户能够在控制台上根据自身业务须要进行配置，能够自定义在业务低峰期进行转存，也能够选择是否进行增量和全量合并，后台调度系统会自动触发转存逻辑。

9、分析层

在云HBase平台里面沉淀了很多数据，或者在进入云HBase平台的数据须要流ETL，参考业界的通用作法，目前最流行的计算引擎是Spark，咱们引入Apache Spark来知足平台的数据处理需求。Spark采起的是DAG的执行引擎，支持SQL及编程语言，比传统的MR快100倍，另外支持流、批、机器学习、支持SQL&Python&Scala等多种编程语言。云HBase平台提供的能力有流式的ETL、Spark on HBase(也包括其它数据库)及HBase数据转为列存后的分析。为了知足Spark低成本运行的需求，咱们即将支持Serverless的能力。Spark在数据库之间，处于一个胶水的做用，平台经过Spark打造数据处理的闭环系统以核心客户的核心问题，好比点触科技的游戏大数据平台

• 支持流式处理
  大部分的系统之中，数据通过中间件以后须要一些预处理再写入到HBase之中，通常须要流的能力。Spark Streaming提供秒级别的流处理能力，另外Structured Streaming能够支持更低时延。平台支持Kafka、阿里云LogHub、DataHub等主要的消息通道。关于不少从业者关心的Spark跟Flink对比的问题，其一，Flink基于pipeline模式的流比Spark基于mini batch的流在延迟上要低，功能上也更强大，可是大部分用户很难用到毫秒级和高阶功能，Spark的流知足了大部分场景；其二，Spark生态要比Flink成熟，影响力也更大。
• Spark On X
  分析层不只仅支持HBase、Phoenix之外，也包括POALRDB、MySQL、SQLServer、PG、Redis、MongoDB等系统。好比：归档POLARDB数据作分析，Spark On X支持schema映射、算子下推、分区裁剪、列裁剪、BulkGet、优先走索引等优化。算子下推能够减小拉取DB的数据量，以及减小DB的运算压力，从而提升Spark On X的运算性能。HBase通常存储海量数据，单表可达千亿、万亿行数据，Spark On HBase的rowkey过滤字段下推到HBase，查询性能可达毫秒级别。

10、数据工做台

在线DB通常是业务系统链接DB的，但离线的做业与在线的平台不同，须要提供Job的管理及离线定时运行，另外还须要支持交互式运行。在云HBase平台上，咱们提供了 【数据工做台】来知足这一需求。数据工做台能力有：资源管理、做业管理、工做流、回话管理、交互式查询、及做业的告警。做业能够是jar包、python脚本、SQL脚本等；工做流能够把多个做业关联在一块儿，并能够周期性或者指定固定时间运行；回话管理能够启动一个在线的交互式Spark回话知足交互式查询的诉求；交互式查询能够知足在线运行 sql脚本、python及scala脚本。

 

 

 

11、DBaaS

云HBase构建了一整套的管理系统，支持全球部署、监控报警(包括云监控及原生自带监控页面)、在线扩容、安全白名单、VPC网络隔离、在线修改配置、公网访问、小版本在线一键升级、分阶段低峰期MajorCompaction优化、自动检测集群可用状态紧急报警人工干预、磁盘容量水位报警等等运维操做及自动化优化。 平台提供7*24小时人工答疑及咨询，可直接咨询钉钉号 云HBase答疑。除此以外，打造了2大企业级特性，备份恢复、BDS服务

• 备份恢复
  HBase的数据也是客户的核心资产，为了保障客户的数据不被意外删除（常常是用户本身误删）时，咱们内置了备份恢复的服务。此服务是直接独立于HBase内核，单独进程保障的。基本原理是全量数据拉HFile，增量数据拉Hlog。知足了数百TB数据的备份恢复，实时备份的延迟时间在数分钟之内。数据恢复能够知足按照时间点恢复，数百TB规模的集群基本在2天内完成恢复。无论是备份仍是恢复都不影响原来的集群继续提供服务。其中细节点也较多，能够参考访问：云HBase备份恢复，为云HBase数据安全保驾护航
• BDS服务
  数据迁移是一个重的事项，尤为当相似如HBase数十TB数据的迁移。咱们专门为云HBase打造数据迁移的服务，命名为BDS。此服务知足各种数据迁移及同步的场景，包括自建HBase集群迁移上阿里云HBase、跨地域迁移，例如从青岛机房迁移到北京机房、HBase1.x升级HBase2.x、网络环境经典网络切换成VPC等

12、后记

存储、检索、分析是BigData三大核心的能力，也是BigData NoSQL着力打造的核心能力，经过深度整合，更好解决客户风控、画像等数据驱动业务的问题。阿里云云HBase团队，基于云上环境的种种特性，打造了Native的众多优点，目前服务了数千家中小型企业。另外，为了服务中国广大的开发者，自从18年5月，发起成立了【中国HBase技术社区】，举办线下meetup 9场次，邀请内外部嘉宾数十人，报名2801人，公众号1.1w人，直播观看2.1+w人，影响数万企业。特别为开发者提供免费版新人1个月的免费试用，以方便其开发学习以及交流。

将来，咱们将继续牢牢贴合云上用户需求打磨产品，打造核心竞争力，提高易用性，保障系统稳定性，以及引入Serverless特性以进一步下降成本。

If not now, when? If not me, who?

 

原文连接

本文为云栖社区原创内容，未经容许不得转载。