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

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

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

　　“作者：肖赞贝壳找房(北京)科技有限公司OLAP平台负责人，基础平台中心大数据平台部架构师。”

　　一、业务背景

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

　　1.指标平台

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

　　·对外提供统一的API

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

　　·实时指标查询

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

　　目前应用情况：

　　·上万级别指标应用

　　·几千万调用/天

　　·TP99查询在3秒以内

　　2.可视化报表平台

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

　　目前应用情况：

　　·活跃报表数千张

　　·每天数十万次调用

　　二、业务痛点

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

　　1.历史数据Update支持差

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

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

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

　　2.多表Join功能的支持能力差

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

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

　　3.无法同时支持明细与聚合