作为覆盖房产交易、家装、租赁等业务的居住产业数字化服务平台，贝壳自创立以来就一直在积极推进居住服务的产业数字化、智能化进程，为许多家庭提供了包括二手房交易、新房交易、租赁、家装、家居、家服在内的一站式服务。
而为了能让服务效率进一步提升，贝壳还与OceanBase合作，构建了实时字典服务，同时还用其替代了原有的HBase 维表服务，以此获得了更高的性能，还拥有了更低的硬件成本和运维成本。
看到这里或许有人会问：OceanBase到底有何过人之处，能让贝壳“降本增效”？
实时字典服务，保证数据不丢不重
在贝壳找房的指标体系中，大量指标的计算都需要精确去重计数的支撑，比如带看量、委托量、DAU、MAU 等等。因此对 OLAP 引擎来说，精确去重计数支持是一项基础的能力。
目前比较常用的方法是基于位图（Bitmap）实现精确去重计数，但这样的计数方法有一定的限制，即要求去重字段类型为整数型类型。如果需要支持对其他数据类型的字段采用Bitmap进行精确去重计数，就需要构建全局字典，将其他类型数据（如字符串类型）通过全局字典映射成为整数类型，即字典编码 +Bitmap。
所以为了支持实时场景下，对非整型数据的快速精确去重计数，需要构建实时字典服务，支持在 Flink 任务中利用实时字典服务，将非整型数据转换为唯一整型编码，存储到下游 OLAP 引擎（例如 StarRocks 等），然后利用 OLAP 引擎本身支持对整型数据进行 Bitmap 精确去重计数特性来实现快速的精确去重计数。
但想要满足实时字典服务的存储需求，存储服务需要能支持每秒十万级以上数据量的读写、支持数据持久化和保障数据的唯一性。最重要的是数据持久化和数据唯一性，既不能丢数据，也不允许数据重复。于是贝壳对HBase 和 OceanBase进行了测试，结果发现：
在4万~8万以及8万~16万的数据量情况下，HBase 和 OceanBase 均不会产生延迟，都能满足需求。
但在12万~24万数据量情况下，HBase 的处理时间是1.27秒，随着时间积累，延迟也越来越大。所以，在12万~24万场景下，只有 OceanBase 能满足需求。
同时在测试过程中，OceanBase 是在数据量28万~56万，且加到了7个实时任务的情况下，才开始出现延迟，数据处理时间1.1秒。
另外，根据测试统计数据，在批量读、批量写、吞吐量上，OceanBase 都有明显优势。这也是为什么OceanBase能让贝壳获得更高的查询性能和稳定性。
实时维表服务，将性能提升3-4倍
在典型的实时数仓或实时业务场景里，Flink 实时流处理过程中，经常需要将事实表与外部维度表进行关联，查询维度表，补全事实表中的信息。例如，在贝壳家居等业务场景中，需要在用户下单后将订单信息与维度表中商品信息的相关信息进行实时关联。
考虑到维表数据量较大，并且 Flink 实时查询 QPS 较高，传统数据库 MySQL 等难以支撑，于是贝壳此前采用了 HBase 作为维表。HBase 是一个分布式列存储 NoSQL 数据库，具有较好地查询性能，但也存在一些痛点，比如HBase 不支持二级索引；HBase 依赖较多，部署复杂，成本高。
而OceanBase 能够很好地解决这些痛点。首先，OceanBase 原生支持二级索引功能，可以直接在维表上创建额外的索引，提升维表的查询性能。其次，OceanBase 只有 OBServer 一个角色，不依赖任何外部组件，天然具备高可用能力，部署非常简单。同时，其自带的周边工具也可以快速安装，比如通过 OCP（OceanBase Cloud Platform）白屏化安装或通过 OBD（OceanBase Deployer）命令行安装集群，运维很方便。
更重要的是，在部署资源消耗方面，HBase 方案机器成本大概是 OceanBase 的 2 倍。
正因为OceanBase能在付出更低的硬件成本和运维成本的同时，实现更高的性能，所以贝壳才会“义无反顾”地在更多合适的场景中推广、应用 OceanBase。