解惑：贝壳为什么会选择OceanBase替代HBase维表服务？

为了能给大家提供更高品质、高效率的智能居住服务，贝壳一直积极探索，只为寻找能够更好提高平台性能的服务器。

比如在贝壳家居等业务场景中，需要在用户下单后将订单信息与维度表中商品信息的相关信息进行实时关联，但由于维表数据量较大，并且 Flink 实时查询 QPS 较高，传统数据库 MySQL 难以支撑，因此贝壳采用 HBase 作为维表。

但随着使用的深入，贝壳发现，HBase虽然具有较好的查询性能，但也存在难以解决的痛点。

首先，HBase 不支持二级索引。

在许多应用场景中，Flink 任务关联维度表时，除了需要基于主键字段进行关联外，还需要其他非主键字段进行关联。但是HBase 只支持行键（Row Key）作为单一索引，本身并不直接支持二级索引。Apache Phoenix 等项目对 HBase 的基础上进行扩展，能够实现类似于二级索引的功能，但是需要更多的开发和维护成本。

其次，HBase 依赖较多，部署复杂，成本高。

HBase 是构建在 Hadoop 生态系统之上的，它依赖于分布式文件系统 HDFS 用于数据的持久化存储，依赖 ZooKeeper 来完成选举、节点管理、集群元数据维护等，因此在生产环境中部署 HBase 之前，需要先部署和配置 Hadoop、ZooKeeper 等组件，涉及组件多，部署较复杂，运维成本较高，硬件成本也较高，特别是在一些特殊场景下需要分别为其部署独立的 HBase 集群。

为了解决以上两个关键问题，贝壳将目光投向了分布式数据库OceanBase，而OceanBase也不负众望地解决了这些业务痛点。

首先，OceanBase 原生支持二级索引功能，可以直接在维表上创建额外的索引，提升维表的查询性能。

其次，OceanBase 只有 OBServer 一个角色，不依赖任何外部组件，天然具备高可用能力，部署非常简单。并且OceanBase自带的周边工具也可以快速安装，比如通过 OCP（OceanBase Cloud Platform）白屏化安装或通过 OBD（OceanBase Deployer）命令行安装集群，运维很方便。

再者，OceanBase成本更低。在部署资源消耗方面，HBase 方案机器成本大概是 OceanBase 的 2 倍。因为 HBase 为了保证高可用, 采用了双 HRegionServer，而 HBase 又是基于三副本的 Hadoop 存储数据, 所以一份数据通常需要六副本。在集群规模不大时，使用 Zookeeper、Hadoop 会带来大量额外的机器冗余，但是使用 OceanBase 存储数据只需要三副本，成本降低一半。

最终在 OceanBase 的加持下，贝壳的性能提升了 3-4 倍，硬件成本节省了一半，运维成本也得到大幅降低。

事实上，除了在实时维表服务上实现“降本增效”，在实时字典服务方面，OceanBase也展现出了更好的服务性能。

根据测试统计数据，在批量读、批量写、吞吐量上，OceanBase相比于HBase都有明显优势。HBase 要保证 key 不重复和 value 自增，只能通过单条数据写入，写数据成为了整个数据流程的瓶颈。通过数据库本身的特性，使用 OceanBase 时不需要关注 key 重复和 value 自增的问题，通过 SQL 批量写入数据，从而能提供更大的写吞吐。

与此同时，在数据量压测对比下，面对12万~24万数据量，HBase 的处理时间是1.27秒，随着时间积累，延迟也越来越大；而OceanBase 是在数据量28万~56万，且加到了7个实时任务的情况下，才开始出现延迟，数据处理时间1.1秒。

可以看出，在相同环境下，OceanBase 综合性能要优于 HBase，且具有更低的硬件成本和运维成本，因此贝壳选择上线OceanBase也就不足为奇了。