乐趣区

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?


本文作者:明朔

阅读原文

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

退出移动版