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

一、引言

时间到了 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，欢迎大家关注，并贡献代码。接下来笔者会介绍各层，力求简单通俗，文中有大量的链接以衍生阅读。

二、业务视角及数据流

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

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

三、统一文件访问层

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

四、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 优化实践为例

五、检索层

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 封装，并在存储查询等方面做了一系列优化升级，该部分在下个章节将会介绍。

六、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 入门到精通

七、多模领域层

数据类型有表格、文档、宽表、图、时序、时空等不同的类型。云 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 上线，场景、功能、优势全解析

八、列式存储

行列混合 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 直接进行查询；而对于离线场景的转存，用户可以在控制台上根据自身业务需要进行配置，可以自定义在业务低峰期进行转存，也可以选择是否进行增量和全量合并，后台调度系统会自动触发转存逻辑。

九、分析层

在云 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，查询性能可达毫秒级别。

十、数据工作台

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

十一、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 等

十二、后记

存储、检索、分析是 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?

本文作者：明朔

阅读原文

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