贝壳找房作为“科技驱动的新居住服务商”，致力于推进居住服务产业数字化、智能化进程，通过助力优质服务者，为三亿中国家庭提供包括二手房、新房、租赁、装修等全方位的高品质、高效率居住服务。

贝壳大数据平台部构建和支撑了全集团多个场景应用，覆盖的业务线多，业务复杂度高，因此对数据分析平台的要求也非常高。OLAP 平台需要支撑如指标分析、Ad hoc 探索性分析、可视化报表等常规业务，还需要支持如用户行为分析、风控、DMP 等典型业务。OLAP 平台需要适配不同类型、负载以及场景的分析要求，为此大数据平台部需要同时运维的平台上已经存在有 6、7 种不同的分析引擎。

从 2021 年开始通过引入 DorisDB，作为主要的分析引擎开始了公司大数据分析引擎的整合。在指标平台、报表平台上基本实现了通过一个组件（DorisDB）来适配多样的数据分析场景。通过 DorisDB 构建一站式全场景的极速数据分析平台，提升了数据分析效率，降低了运维复杂度，充分释放了数据价值。

“ 作者：肖赞

贝壳找房（北京）科技有限公司 OLAP 平台负责人，基础平台中心大数据平台部架构师。 ”

业务背景

贝壳是一个典型的产业互联网公司，OLAP 平台是我们数字化运营的基石，在数据平台中占据着非常重要的位置。首先 OLAP 平台需要支撑集团的经营管理决策，需要将各种业务流程中的关键指标抽象出来，在 OLAP 平台上进行实现。其次是探索性分析，OLAP 平台需要支持前线的业务员的探索性分析。再次是可视化报表，即常规的固定报表业务，需要 OLAP 引擎有支持大规模并发请求的能力。最后是典型业务如用户行为分析、用户转换漏斗、用户画像、用户风控，交易等业务的支撑。下面以指标台和可视化报表平台为例对贝壳的业务现状做一些简要的介绍：

指标平台

指标平台作为全集团多场景的统一指标管理平台，提供了以下功能：

• 对外提供统一的 API

• 指标统一定义，口径统一管理

• 实时指标查询

前期使用 Apache Kylin 支持汇总指标查询。随着明细查询的需求增加，又引入了 Druid、ClickHouse 和 Apache Doris 等多个组件。

目前应用情况：

• 上万级别指标应用

• 几千万调用/天

• TP99 查询在 3 秒以内

可视化报表平台

运营人员可以在可视化报表平台上，基于 Hive 表或指标来创建自助报表。基于指标创建报表时，通过指标平台将请求转化为 SQL 语句，大部分使用 Impala 执行查询。

目前应用情况：

• 活跃报表数千张

• 每天数十万次调用

业务痛点

引入不同的引擎来解决不同场景的问题，虽然可以满足大部分业务的需求，同时也会带来其它的问题。总结主要有以下四点：

历史数据 Update 支持差

由于贝壳大部分的业务场景都需要对数据进行更新操作。如果是离线指标通过批量的方式处理，但实时指标就需要实时的对历史数据进行更新。

例如在经纪人带看场景中，某些带看记录，如果触发了风控规则，会被判定为无效带看记录，数据状态就会发生变更。再比如新房交易流程，新房记录的状态需要在报备、带看、签约、成交直接互相流转。整个业务流程都需要对新房状态进行在线更新。

Druid 作为原架构中的主要分析引擎，不支持 Update 功能，只能用于对离线数据进行指标分析，无法支持实时指标计算。ClickHouse 虽然提供了 Update 和 Delete 两个 mutation 操作，但是修改的代价比较大。经常积累过量 mutation 无法完成数据更新，而且导致了多次线上 ClickHouse 集群整体宕机。另外，由于 mutation 是一个异步的线程，所以并不能保证 Update 的数据实时可见，从而指标的实时性也无法得到保障。

多表 Join 功能的支持能力差

平台现有的 OLAP 引擎(Kylin、Druid、ClickHouse)多表 Join 时的性能都比较差，甚至不支持多表 Join。以前通常只能采用宽表形式来构建数据模型。但贝壳是一个线上线下结合产业互联网公司，一个典型的场景是有经纪人经常在门店中间跳动。在计算最新的业绩，或者计算奖金指标的时候，就需要去关注组织架构变动。使用宽表模型的话，只要维度发生变化，就需要重刷整个宽表，导致有些指标刷新的时间过久，数据时效性就会变差。

现有的引擎 Druid 虽然有 lookup 表的能力，但经过实际测试后性能不佳。Apache Kylin 实际上也不支持 Join，多表的 Join 需要通过在 cube 构建的时候底层打成宽表来实现。ClickHouse 只支持本地 Hash join 的模式，不支持分布式 Shuffle join，多数情况下灵活性受限，性能表现不佳。

无法同时支持明细与聚合

在贝壳指标不仅仅需要给管理人员看汇总指标，如果发现指标有问题，还需要下钻到明细，查看导致指标异常的具体原因。随后根据明细数据的情况，再采取一系列的管理动作。也就是说，OLAP 引擎需要同时具备明细数据查询和数据聚合的能力。由于 Apache Kylin、Druid 不能较好支持明细数据查询，之前只能将聚合后的数据存储在 Apache Kylin、Druid 中，明细数据存储在 Clickhouse 中。没有把聚合数据放到 Clickhouse 是由于 Clickhouse 的物化视图是不透明的，对上层的应用程序来说查询明细的时候需要切换到对应的明细表，操作也比较繁琐。不论是查询引擎还是表的切换都需要我们维护额外的查询代码逻辑。而且对前端的数据分析人员也不够友好，他们需要同时了解明细数据与聚合数据不同的存储位置以及之间的对应关系，增加学习，沟通的成本。

OLAP 引擎较多，运维复杂，用户学习成本较高

目前贝壳的数据分析平台中引入了六、七种不同的分析引擎（Impala、Presto、Kylin、Druid、ClickHouse、Hive）。而团队只有十几个人，技术栈过多，导致我们对每一种引擎的掌握程度都不够深，运维压力非常大，出问题的时候很容易 hold 不住。

特别像 ClickHouse 的集群，虽然性能很好，但是对运维的要求比较高。ClickHouse 集群的分片、副本信息，都是通过静态的配置文件的方式进行配置。当整个集群需要扩缩容的时候，就必须通过修改配置文件的方式进行刷新，数据的均衡都需要运维人员介入。此外 ClickHouse 通过 zookeeper 来做副本管理，当集群规模变大时，副本数过多会导致 zookeeper 的压力变大，集群的稳定性也就会相应变差。

另一方面，多个引擎对用户来说学习成本也很高，不同分析系统的 SQL 语句不一致，每一种都需要额外的学习成本。

DorisDB 与其它 OLAP 引擎的比较

为解决以上问题，从今年开始我们引入了 DorisDB，逐步替换之前的分析引擎，实现 OLAP 平台多业务场景的查询引擎统一化。

主要因为 DorisDB 具备以下特性：

• MPP 架构 + 高效列式存储引擎

• 高性能、高可用、高弹性

• 标准 ANSI SQL 支持

1. 支持多表 Join

2. 支持 MySQL 协议

• 支持预聚合

1. 支持物化视图

2. 支持预聚合结果自动更新

• 支持数据高效的批量导入、实时导入

• 支持数据的实时更新

我们对 DorisDB 与其他 OLAP 引擎做了全面的对比测试，对比项包括 ClickHouse、Duird 和 Apache Doris。测试环境配置信息如下：

查询性能：DorisDB vs ClickHouse vs Apache Doris

查询性能对比测试使用 SSB 测试集，数据量最大的表 lineorder 约 60 亿(scale 1000)。在 ClickHouse 最擅长的宽表模式下，分别在限制线程数不超过 8，不限制线程数两种情况下对比了 DorisDB 和 Clickhouse 的性能。

在 DorisDB 和 ClickHouse 单节点都使用不超过 8 个线程的情况下，13 个查询中有 9 个 DorisDB 的性能好于 ClickHouse。

(宽表模式，设置 ClickHouse max_threads=8）

不限制 ClickHouse 线程数情况下，13 个查询中有 7 个 DorisDB 性能好于 ClickHouse。

(宽表模式，不限制 max_threads）

在多表 Join 模式下，对比了 DorisDB 和 Apache Doris 的表现。整体上 DorisDB 比 Apache Doris 有 5-10 倍的性能优势。

没有对 Apache Doris 的宽表性能进程测试，是由于在 60 亿的数据量下，DorisDB 可以直接使用 insert into select 语句将数据转成宽表，Apache doris 执行相同语句会报 oom。由此也可以看出 DorisDB 在内存的管理和执行效率上比 Apache Doris 要好不少。同时也了解到 DorisDB 后续也有开源的计划，所以我们在应用中都使用了 DorisDB 作为 OLAP 分析引擎。

高并发：DorisDB vs Druid

线上实际环境，以宽表模式对 Druid 和 DorisDB 进行了高并发的压力测试。Druid 集群的 QPS 可以达到 600-700 左右，平均响应时间 100ms 左右，最大响应时间 300ms 左右。相同规模的 DorisDB 集群，QPS 可以达到 1500-2000，平均响应时间在 50ms 左右，最大响应时间在 100ms 左右。

（压力测试下 Druid 并发量）

（压力测试下 DorisDB 并发量）

此外，我们额外对 DorisDB 的 Join 模式进行了高并发的压力测试，QPS 可以到 200-300，平均响应时间 470ms。可以看出即使在 Join 模式的复杂查询场景下，DorisDB 的并发性能还依旧维持在一个不错的水准。

其他指标

如下表所示，我们也对其他方面的指标进行了比较：

DorisDB 在贝壳的应用

目前贝壳的 DorisDB 集群使用 35 台物理机（80core、192GB 内存、3TB SSD），部署了 35 BE，3 FE。支持了如指标平台、可视化报表平台、典型业务场景等多个应用。

指标平台

1、 高 QPS 指标查询

通过 DorisDB 强大的并发能力支撑以往 Druid 所不能满足的高 QPS 场景。如房屋经纪人业绩考核时段，QPS 会瞬间从几十飙升到 3000。以往使用 Durid 应对这类瞬时高压场景没有很好的解决办法，集群会不停告警乃至宕机。使用 DorisDB 支撑的指标平台就能很好的解决这个问题。

2、 可自动更新的物化视图

DorisDB 有非常好的物化视图能力。对慢查询指标通过 rollup 聚合，在查询时可以自动命中物化视图，自动路由，加速整个查询。同时物化视图支持自动更新，当明细表发生变化时，物化视图自动刷新聚合结果。

3、 实时的大屏指标

原有的实时指标是通过 ClickHouse 来支持的，但是需要建大量的视图。ClickHouse 物化视图不支持自动路由，在查询时需要指定对应的物化视图表名字。而且 ClickHouse 对 Update 的支持也非常有限，查询最新的记录需要额外的函数支持，不符合标准的 SQL 语法。总体来说使用 ClickHouse 来计算实时指标，实现过程非常复杂。通过 DorisDB 来支持实时指标场景，能自动对指标进行实时更新，只需要创建对应的物化视图即可，无需额外的任何操作就可以指标的实时更新。

4、 更灵活的数据模型

DorisDB 同时也具备非常强的单表查询能力和多表 Join 能力，可以支持宽表模式和多表 Join 模式。在应对部分灵活指标，如前文提到的经纪人组织架构变更场景，基于 DorisDB 就无需构建宽表。使用在线 Join 的方式，当维度发生变动的时候，更新维度表重新进行关联查询即可。

奥丁可视化平台

此前我们基于 MySQL 做了大量的报表，如市场管理看板等。随着数据量增大，数据量达到千万级别 MySQL 已经完全不能支撑。目前已将这些可视化系统报表全部迁移到 DorisDB 上。由于 DorisDB 对 MySQL 协议的支持，整个迁移的过过程比较平滑，只需要很少的工作量。

典型业务

原有的典型业务如 A/B 试验平台、交易平台、风控平台、直播中台等，之前是基于 ClickHouse 和 Apache Doris 构建的。现在我们已经开始将这些业务应用逐步迁移至 DorisDB。此外，后续构建的新应用，如用户行为分析等，我们也会基于 DorisDB 来进行构建。

下图是直播中台从 Apache Doris 迁移到 DorisDB 后的查询效率对比。可以看到查询效率均有成倍的提升，在数据量大的情况下（全量表）性能提升尤为明细，性能提升均在 7 倍以上。

（直播平台使用 DorisDB 后，所有查询的延时都显著降低）

写在最后

在近半年的使用过程中，从整体来看 DorisDB 在稳定性和查询性能上要优于 Apache doris。宽表性能和 ClickHouse 不相上下，多表 Join 能力要胜于 ClickHouse。DorisDB 在保持甚至超过 ClickHouse 性能的同时，极大降低了我们的运维压力，简化了数据开发的链路。

DorisDB 对 hive 外表的支持也给我们很大的想象空间，尤其是一些 Ad hoc 查询场景。现在我们的小查询用 Spark SQL，大的查询用 hive 或者是 presto。后续使用 DorisDB 来分担一些热查询的流量，整体的查询效率也可以得到进一步的提升。使用 DorisDB 查询 ElasticSearch 外表也在我们下一步的规划中。

后续我们会将 DorisDB 覆盖到更多的业务场景，使用 DorisDB 逐步替代 Druid、Clickhouse、Kylin 等其他分析引擎，来构建我们全场景统一的极速 OLAP 分析平台。