随着数据量的爆炸性增长，特别是半结构化和非结构化数据的涌现，传统关系型数据库如 MySQL 遭遇了前所未有的挑战。这一背景下，为非结构化数据管理而生的 NoSQL 数据库，以及旨在解决海量数据存储难题的分布式技术应运而生，成为行业焦点。其中，Hadoop 分布式系统基础架构以其创新性引领风骚，而基于 Hadoop 构建的 NoSQL 数据库 HBase，更是以其独特优势脱颖而出。
回溯至 2005 年，Hadoop 横空出世，首次将分布式存储与计算的理念带入实践，让大规模计算集群的构建不再受限于昂贵硬件，实现了成本效益与数据处理能力的双重飞跃。起初，Hadoop 专注于批量处理与离线计算，为海量数据提供了前所未有的处理能力。然而，面对实时数据访问与交互式应用的迫切需求，HBase 应运而生，无缝融入 Hadoop 生态，弥补了 Hadoop 在实时数据处理方面的短板，为大规模数据存储与高并发读写场景提供了强有力的支撑。
一、HBase为什么流行起来
HBase 诞生于互联网高速发展的时期，在设计之初就是为了应对互联网海量数据的高并发写入和简单查询场景。十余年来，凭借独特的架构设计，HBase 在许多互联网场景具有显著的优势，在世界范围内大规模流行起来。
（一）海量存储与灵活扩展
传统的关系型数据库，例如 Oracle 与 MySQL 等，在存储和处理大规模数据时存在性能瓶颈，同时很难进行横向扩展。即使通过分库分表、中间件等方式实现简单的扩展，也往往会面临数据一致性、运维复杂性方面的挑战。HBase 作为 NoSQL 数据库，单表即可支持百万甚至上亿级别的行和列，基于 HDFS 实现分布式的数据存储，还可以通过增加节点的方式简单地实现集群容量扩展，从而支持 TB 甚至 PB 级海量数据的存储。
（二）极致 OLTP 能力
在 OLTP 场景，HBase 凭借底层的 LSM-Tree 架构，和有序的 RowKey 排列设计，具备强劲的高并发批量实时写入能力，并且在海量数据的简单读取方面表现不俗，如随机单点读和小范围的扫描读，被广泛用于日志处理、实时数据采集、更新与即时查询、用户画像、订单存储等场景。HBase 的列式存储方式允许在进行查询时只读取所需列的数据，从而进一步提升随机读写效率。
（三）灵活的数据模型 Schema
HBase 采用灵活 Schema 模式，可以在不停机的情况下动态变更表的 Schema，对列族进行调整，非常适合存储快速变化的非结构化和半结构化数据，从而应对不断迭代的应用需求。以用户画像为例，在建立画像数据库的过程中，随着业务需求和策略不断调整，需要提取的用户特征需要增减、变动，HBase 的灵活 Schema 特性很好地满足了这一动态需求。
（四）稀疏列
HBase 支持大量稀疏存储，即允许大量列值为空，能够有效地处理半结构化和稀疏数据，不需要为空值分配存储空间。与传统数据库相比，在存储明显呈现稀疏性的数据时，有效地节省了存储空间。
（五）多版本支持
HBase 通过时间戳和版本数控制等设计实现多版本特性，允许在表中存储同一行数据的多个版本，从而支持用户在不同时间点访问同一行数据的不同版本。例如，在风控场景下，HBase 常被用于历史行为追溯与审计、实时风险评估、反欺诈检测等需要回溯数据状态的业务。
二、HBase并不完美
诞生于互联网时代的 HBase，似乎可以满足大部分场景下的海量数据存储和处理。然而，HBase 是完美的吗？
（一）缺乏复杂查询支持
HBase 基于列的存储形式，采用 RowKey 作为每一行的唯一标识符，其本质是数据表的一级索引。HBase 的表数据按照 RowKey 进行字典排序，查询时只能根据 RowKey 进行检索。良好的 RowKey 设计可以帮助用户有效提升检索效率，反之对其他字段的查询则差强人意。同时，HBase 本身不支持二级索引，因此难以支持关联、聚合等复杂查询场景。目前，以开源项目 Apache Phoenix 为例的工具正逐步发展，提供对 HBase 进行 SQL 查询的功能，支持二级索引、聚合计算等复杂查询操作。
（二）难以提供稳定时延的及时业务响应
在消费金融、互联网广告、互联网社交等场景下，不仅要求数据库对请求的响应及时，而且要求每次响应时间（RT）足够稳定。P99 是一种常见的用于衡量 RT 稳定性的延迟分布统计指标，它代表了在一个时间窗口内 99%的请求响应时间都不超过某个特定值。许多场景都要求 P99 在百毫秒，甚至 10 毫秒以下。
一个典型的场景就是基于用户特征的广告信息流投放，简单的业务流程是批量采集用户行为数据并入库，然后通过大数据组件分析用户画像特征，再把这些分析结果回流到用户特征 KV 数据库以供业务访问。在业务访问环节，由于用户持续的浏览操作，业务会多次频繁访问用户特征库。为了保证用户能够获得及时、一致的使用体验，需要每一次访问都能够稳定在短时间内成功响应。
这种场景对数据库提出了两个方面的要求：首先，用户特征数据量庞大，需要数据库支持大量持续的数据写入，以及海量存储、弹性扩展的能力。其次，要求数据库的 RT 稳定在某一个用户可接受的范围内。
前文提到，HBase 由于其灵活扩展能力、多列族以及稀疏列特性，常常被用于存储用户画像数据。然而在上述场景下，HBase 在 RT 稳定性方面往往表现不佳。这一方面是由于 HBase 是用 Java 语言编写的，频繁做内存对象的申请和释放会导致 JVM GC 频繁触发，消耗 CPU 资源且带来无法预期的时延抖动；另一方面，HBase 存算分离的架构导致读流程路径长，且涉及多个组件 RPC 交互，导致 P99 抖动更加严重。
（三）组件多，运维复杂
以上，从业务角度列举了 HBase 难以给终端用户带来良好服务体验的场景，然而 HBase 对运维人员提出的挑战同样无法忽视。HBase 是基于 Hadoop 生态的开源项目，在部署 HBase 集群前，首先要部署 Hadoop 集群，要搭建起一套完整可用的 HBase 数据库体系，会涉及到多种组件，包括 Zookeeper，Hmaster，RegionServer，Hbase Client ，NameNode，DataNode，HDFS Client 等等。在此基础上，为了实现复杂查询、监控运维等拓展功能，还要再引入其他的支持工具。因此，部署和运维一套 HBase 体系，要求运维人员能够熟练管理和操作每一个组件，不仅考验运维人员的专业能力，而且带来了巨大的工作量，一旦出现问题也很难短时间定位并解决。另外， HBase 作为一个开源存储方案，目前缺乏比较好用的白屏化运维工具，进一步增加了运维的难度。
（四）业务连续性保障困难
业务连续性是许多数据库用户关心的重点，特别是对于消费金融、直播、社交等需要持续提供服务的场景，业务的每一次中断都可能导致巨大的损失。HBase 由于其自身的架构特点，在容灾部署和服务恢复方面表现不佳。
首先，HBase 集群不能做跨 Zone 的部署。这是因为 HBase 只能基于 HLog 做异步同步，跨 Zone 则无法保证一致性。为了实现跨区域的容灾，就需要部署多套集群，带来繁重的成本。
其次，HBase 服务中断后的故障恢复能力有限。如上图所示， HBase 是存算分离的架构，计算在 HBase 层，存储在 HDFS 层。HBase 层中，每个计算节点称为 RegionServer，分区称为 Region，每个 Region 只维护一个内存实例，没有主备的概念。当一个 RegionServer 故障，其上的 Region 短期都无法对外提供数据访问服务，需要依赖 HMaster 重新调度，并从 HDFS 上恢复状态后才能对外提供服务，恢复时间需要 2-8 分钟不等，无法满足许多场景下的业务连续性需求。另外，在网络问题、服务器故障、并发负载过高或 HBase 内部协调机制出现问题等异常情况下，正在进行分裂、合并、移动等管理操作的 Region 可能会长时间停留在 RIT（Region in Transcation）状态，无法正常响应读写请求，从而严重影响集群的整体性能和可用性。
三、OceanBase替换HBase
面对上述种种困难，是否有更优的解决方案？换言之，回到文章最开始的命题，当面临海量非结构化数据的出现，以及愈发复杂的需求时，除了传统的 SQL，以及以 HBase 为代表的分布式 NoSQL，我们是否能找到另一条道路，通过一体化的分布式系统，在满足海量存储和灵活扩展的同时，支持基于各种数据模型的复杂需求？
OceanBase 的多模一体化能力正是为了解决这一问题而生。目前，OceanBase 基于一套分布式存储引擎的底座，构建了 SQL 引擎和多模 KV（即 OBKV）。SQL 引擎在支持传统结构化数据的基础上，拓展了对 GIS、JSON、XML 等多模类型数据的支持，而 OBKV 则进一步支持兼容 HBase 接口的 OBKV-HBase、兼容 Redis 协议的 OBKV-Redis，以及基于表格接口的 OBKV-Table 等多种形态。其中，以 OBKV-HBase 为例，经过大量测试与实践验证，在多种场景下，OBKV-HBase 能够有效实现对 HBase 的替换升级，并在性能表现、运维架构等方面弥补 HBase 的不足，从而实现显著的超越和提升。
（一）OBKV - HBase 架构
OBKV 是构建在 OceanBase 分布式存储引擎之上的 NoSQL 产品系列，目前支持 OBKV-Table、OBKV-HBase、OBKV-Redis 三种产品形态，原生继承了 OceanBase 的高性能、事务、分布式、多租户、高可靠等基础能力。此外，OceanBase 的工具体系（比如 OCP、OMS、CDC 等）也原生支持 OBKV，运维 OBKV 的各个产品形态和运维 OceanBase 的 SQL 集群完全一样。OBKV 可以帮助企业统一技术栈，在满足业务对多模 NoSQL 数据库诉求的同时，减少企业在数据库运维上的复杂度。
OceanBase 数据库的多模架构可分为三层：分布式存储引擎，KV 层，以及驱动，KV 层进一步包括了 TableAPI Server Framework，以及模型层。OBKV 与 SQL 引擎都建立在分布式存储引擎之上，在分布式存储引擎和 KV 模型层之间，引入了 TableAPI Sever Framework 框架层，为模型层提供封装的存储和事务调用能力。其中，OBKV-HBase 的模型层实现了 HBase 的多版本、稀疏列、大宽表等特性，以及各种 Filter、行锁等功能。同时，模型层将 HBase Row/Cell 的操作映射为对 OceanBase 行的操作。在驱动层，OBKV-HBase 实现了 HBase 的接口，接口下调用 TableAPI Client 和 OBKV 服务端做交互。
由于 OBKV 直接连接存储引擎，无需经过 SQL 层，因此在简单的 KV 场景下，使用 OBKV 接口比使用 SQL 接口性能高 30% 左右。
目前，OBKV-HBase 以接口的形式兼容 HBase 0.94 以及 1.1.13 大部分功能，支持比如 PUT、GET、EXISTS、DEL、APPEND、INCREMENT、SCAN 等常用接口以及 HBase 行锁，在稳定 P99、热副本、跨可用区容灾、性能、运维等方面相比开源 HBase 具有显著优势。
（二）使用 OceanBase 对 HBase 进行优化升级
得益于多模一体化的架构设计与实现模式，以及 OceanBase 提供的丰富工具体系，在许多场景下使用 OceanBase 替换 HBase 可以为用户带来更好的业务体验与更小的运维负担，实现降本增效和系统升级。以下列举了一些典型的升级场景：
1. 读性能的升级：业务需要频繁读操作的场景
上文提到，HBase 具有极致的高并发批量写入能力，但读的性能相对较弱。OBKV-HBase 写性能与 HBase 差不多，但是读有大概 4 倍的优势。因此在业务需要大量、频繁读取操作的场景，使用 OBKV-HBase 替换 HBase 将带来显著的性能提升和计算降本。
这一差异是两款数据库自身的架构特点所决定的。
-
HBase 的存算分离架构：HBase 是基于 LSM Tree 的存算分离架构，计算在 HBase 层，存储在 HDFS 层。进行写操作时，只需写到 HBase 的 RegionServer 即可，存算分离的影响不大；但对于读操作，则大概率要从 HDFS 中取数据。一个典型的读流程是，首先请求从 HBase Client 发送给 RegionServer ，接着 RegionServer 发现没有命中，再通过 HDFS Client 发消息到 HDFS 集群中加载数据块到 RegionServer 。整个过程路径很长，且会涉及到多个系统组件的处理和 RPC 交互，这将消耗 CPU，影响时延，增加抖动，从而表现为读的性能较差。
-
OceanBase 的 Shared-Nothing 架构：与 HBase 不同， OceanBase 采用的是 Shared-Nothing 架构，规避了存算分离带来的读流程的复杂性。同时， OBKV-HBase 的客户端是富客户端（即客户端可以计算路由），客户端可以计算好路由，并将请求直接投递给正确的 OBServer，数据直接从 OBServer 本地获取，整个路径中只有一次 RPC 和一次磁盘 IO，用时更短，因此读的性能显著优于开源 HBase。
2. 稳定快速响应的升级：P99 要求高的场景
如前文所述，在消费金融、风控、广告、社交等场景下，不仅要求业务响应快，而且响应时间要求稳定。不稳定的响应不仅会影响业务体验，多次抖动更有可能导致叠加放大，产生雪崩式的破坏。
HBase 由于自身编程语言与架构的限制，在提供稳定的 RT 方面表现不佳。而 OceanBase 则没有这个烦恼，在 P99 要求高的场景相较 HBase 具有显著优势。
-
OceanBase 基于 C++ 研发，且其内存管理是直接在操作系统中申请大页，基于自研的内存管理模块，消除了基于 Java 研发的 HBase 中频繁 GC 导致的时延抖动问题。
-
OceanBase 采用 Shared-Nothing 架构，从根本上避免了 HBase 的复杂架构中多个组件 RPC 交互导致的时延抖动。
以 OBKV-HBase 在某用户现网落地运行的真实生产数据为例，写入 6kw/min 时，OBKV-HBase 的最大查询时间在 20ms 以下，平均查询时间 2ms 左右， P99 小于 10ms，P999 小于 15ms，且节点几乎无抖动，很好地支持了有稳定快速响应需求的业务场景。同等条件下，HBase 的 P99 表现则高达上百毫秒。
3. 架构与运维的升级：运维压力大、有简化架构需求的场景
HBase 集群各个节点的角色不同，功能不同，部署和运维涉及大量组件，复杂度很高。使用 OBKV-HBase 进行替换后，将显著简化系统架构，降低运维成本。
-
架构简单：与 HBase 涉及多套体系、动辄十余种组件的架构不同，OceanBase 的架构非常简单，OBKV 只包含了 OBKV Client 和 OBServer 两个组件，每个 OBServer 节点都是同构的，服务端只需要运维一个 OBServer，部署和运维的负担更小。
-
工具完备：开源 HBase 目前缺乏比较好用的白屏化运维工具，然而 OceanBase 的工具体系十分丰富，且原生支持 OBKV，例如白屏化的运维工具 OCP（OceanBase Control Platform），用户可以直接使用 OCP 实现全生命周期管理（运维管控）、监控告警、容灾管理、诊断优化等功能，轻松完成对 OBKV-HBase 的运维管理工作。
4. 系统可靠性升级：对业务连续性要求高的场景
在许多核心业务场景下，系统可靠性和业务连续性是第一指标。HBase 由于其架构特征，无法支持单集群跨区容灾部署和快速的业务恢复。然而 OBKV-HBase 借助 OceanBase 的高可用架构设计，可以轻松地弥补这一缺陷。
-
容灾部署可靠：OceanBase 基于 Paxos 的多副本架构，可以方便地支持单集群跨 Zone 的部署。以一个最简单的跨 Zone 容灾场景为例，由于 HBase 集群不支持跨 Zone 部署，使用 HBase 实现跨区容灾需要 2 个集群，假设 HDFS 集群配置三副本的情况下，总计需要 6 副本成本。而使用 OceanBase 2F1A（2 个全能型副本 + 1 个仲裁服务节）方案，仅需要 2 副本成本即可完成跨区容灾部署。
-
故障恢复快：OceanBase 原生分布式 Shared-Nothing 架构支持当一个分区故障时，可以快速切到另外一个副本上对外提供服务，从而实现 RPO = 0（Recovery Point Objective，数据恢复点目标），RTO < 8s（Recovery Time Objective，恢复时间目标），相比 HBase 2-8 分钟的平均故障恢复时间具有数量级的优势。
5. 结构化数据场景使用 OceanBase SQL 实现对 HBase 的替换升级，实现降本增效
HBase 作为一款基于宽表的 NoSQL 数据库，加之多列族与稀疏特性，对于非结构化、灵活的数据模型有着很好的支持。然而，过往 HBase 被用在了许多可结构化数据的应用场景中。这主要是由于早期 HBase 相对同期的 SQL 数据库具备较为成熟的分布式存储能力，用户是为了解决海量数据存储的问题而选用了 HBase。
在这种情况下，特别是在 AP 场景，为了提升结构化数据的运算性能，用户往往还会引入 Phoenix 等 SQL 中间件，加强数据访问和查询能力，同时方便开发人员使用熟悉的 SQL 工具和 IDE 进行开发和管理。在这些场景中，用户可以直接使用 OceanBase SQL 替换 HBase + Phoenix，在满足对分布式海量存储、灵活扩展的需求的同时，简化系统架构，统一技术栈，同时借助 OceanBase 强大的通用压缩+数据编码压缩算法显著降低存储成本，实现降本增效。
（三）从 HBase 到 OBKV 的平滑替换升级体验
为了提升用户从 HBase 切换到 OBKV-HBase 的迁移体验，OBKV 在产品兼容性方面不断突破，且通过种种设计力求保留用户的操作习惯，帮助用户快速上手使用。通过简单的操作和配置，用户即可完成从 HBase 向 OBKV-HBase 的快速平滑切换。
-
从迁移的角度来看，OBKV 对 HBase 实现了接口兼容，OBKV 的数据访问等 DML 接口与 HBase 一致，用户只需要简单修改很少量的代码便可完成适配。
-
从使用的角度来看，OBKV 从架构设计、使用方式等方面力求符合用户使用习惯，让开发人员用最熟悉的方式使用 OBKV-HBase，尽可能降低学习成本。OBKV-HBase 租户就是一个 MySQL 租户，与普通的 MySQL 租户没有任何不同，只需要提前在租户内建表就能正常使用。并且，OceanBase 之所以选择通过 OBKV 对 HBase 实现接口兼容，而不是像支持 JSON、GIS 等多模类型一样建在 SQL 引擎上，也是考虑到与当前主流的 NoSQL 数据库一致，让用户使用原生的 API 访问这些数据引擎。
四、替换升级案例
（一）贝壳：OceanBase SQL 替换 HBase 实现实时字典服务
贝壳找房是中国最大的居住服务平台。作为居住产业数字化服务平台，贝壳致力于推进居住服务的产业数字化、智能化进程，通过聚合、助力优质服务者，为中国家庭提供包括二手房交易、新房交易、租赁、家装、家居、家服等一站式、高品质、高效率服务。
贝壳家居等业务的实时数仓或实时业务场景经常使用 Flink 进行实时流处理，这一过程中存在一种典型的维表关联查询场景。例如，在用户下单后将订单信息与维度表中商品信息的相关信息进行实时关联。过往，贝壳采用 HBase 作为维表来解决存储数据量较大、Flink 实时查询 QPS 较高等传统 MySQL 数据库无法解决的难题。然而，HBase 不支持二级索引，无法满足 Flink 任务中经常需要关联非主键字段的需求；同时，HBase 复杂的架构使得部署和运维成为难题。
经过充分的考察和对比，贝壳最终选择使用 OceanBase 替换 HBase。OceanBase SQL 原生具有二级索引功能，提升维表的查询性能，同时架构非常简单，部署和运维不再需要繁重的成本。
下图展示了 OceanBase 替换 HBase 在贝壳实时字典服务中的一个应用案例。
在贝壳找房的指标体系中，大量指标都需要经过精确去重计数后进行 OLAP 计算。目前比较常用的方法是基于位图（Bitmap）实现精确去重计数，这要求去重字段类型为整数型类型。如果需要支持其他数据类型的字段，就需要构建全局字典，将其他类型数据（如字符串类型）通过全局字典映射成为整数类型后再进行精确去重计数处。该场景只有简单的 KV 操作，考察数据库极致的点查性能，且数据模型对 SQL 接口友好，因此 OceanBase SQL 是合适的替换方式。
为了支持在 Flink 任务中实现实时字典服务，贝壳对 HBase 和 OceanBase 进行了测试。测试结果发现，在 4 万~8 万以及 8 万~16 万的数据量情况下，HBase 和 OceanBase 均不会产生延迟，都能满足需求；但在 12 万~24 万数据量情况下，HBase 的处理时间是 1.27 秒，随着时间积累，延迟也越来越大，而 OceanBase 能顺利满足需求。直到数据量 28 万~56 万，且加到了 7 个实时任务的情况下，OceanBase 才开始出现延迟，数据处理时间 1.1 秒。另外，根据测试统计数据，在批量读、批量写、吞吐量上，OceanBase 都有明显优势。
最终，贝壳选择通过 OceanBase 替换 HBase，不仅降低了系统复杂度，减轻了部署和运维成本，还实现了查询性能的 2-5 倍提升，写入性能的 5 倍提升。
（二）仟传：OBKV-HBase 替换 HBase 大幅提升摄入与查询性能
另一个典型案例是 OBKV-HBase 在仟传的落地应用。
仟传网络科技（TargetSocial）是国内知名的内容社交平台整合营销企业，致力于运用大数据及自主研发系统，为企业级客户提供更有价值的 KOL（关键意见领袖）和公/私域流量经营解决方案。
仟传的业务场景非常丰富，包括用户行为分析、标签管理、粉丝管理、内容精准推送、裂变传播、热点监测、品牌舆情监测等诸多领域，许多业务涉及到 KV 类型数据。过往，仟传通过 HBase 实现 KV 方案。
经过性能、部署、运维、架构以及数据分布等方面对 HBase 和 OceanBase 的对比分析后，仟传认为 OBKV 在降低成本、简化运维、热点数据写入、数据分布均匀等方面具有明显优势，于是选择使用 OBKV-HBase 完成了对 HBase 的替换升级。
以下是 OBKV-HBase 在仟传的一个典型应用场景，原始用户数据和事件数据经过 Kafka 流到 Flink 进行分析。由于维表和实时表存储的数据有嵌套结构，Flink 在获取事件后会重新关联事件并补全，然后传递给下游，要求数据库具备极致的点查性能，使用 HBase 的性能表现有所局限。
OBKV 落地仟传后，实现了稳定的 60000 TPS，同时满足了业务数据高速摄入和高速点查需求；在上游数据陡增时，TPS 峰值可达 110000，能够快速追平数据，避免数据积压。同时，OceanBase 简洁的架构、基于 OCP 的界面化操作工具帮助仟传有效减轻运维压力，降低管理成本。
五、写在最后
未来，OceanBase 将持续更新迭代多模一体化能力，不断提升性能，加强产品对 HBase 各版本的兼容，原生实现 OBKV-HBase 上的二级索引功能，同时提供旁路导入等更多提升易用性的功能与工具，让 OceanBase 在 HBase 等多模支持场景下展示出更好的表现，帮助更多业务场景实现现代化升级。
OceanBase 云数据库现已支持免费试用，现在申请，体验分布式数据库带来全新体验吧 ~
标签：OBKV,存储,场景,架构,运维,OceanBase,HBase From： https://blog.csdn.net/OceanBaseGFBK/article/details/141104403