贝壳找房作为“科技驱动的新居住服务商”，致力于推进居住服务产业数字化、智能化进程，通过助力优质服务者，为三亿中国家庭提供包括二手房、新房、租赁、装修等全方位的高品质、高效率居住服务。
贝壳大数据平台部构建和支撑了全集团多个场景应用，覆盖的业务线多，业务复杂度高，因此对数据分析平台的要求也非常高。OLAP平台需要支撑如指标分析、Ad hoc探索性分析、可视化报表等常规业务，还需要支持如用户行为分析、风控、DMP等典型业务。OLAP平台需要适配不同类型、负载以及场景的分析要求，为此大数据平台部需要同时运维的平台上已经存在有6、7种不同的分析引擎。
从2021年开始通过引入StarRocks，作为主要的分析引擎开始了公司大数据分析引擎的整合。在指标平台、报表平台上基本实现了通过一个组件（StarRocks）来适配多样的数据分析场景。通过StarRocks构建一站式全场景的极速数据分析平台，提升了数据分析效率，降低了运维复杂度，充分释放了数据价值。
“ 作者：肖赞，
贝壳找房（北京）科技有限公司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语句不一致，每一种都需要额外的学习成本。
StarRocks与其它OLAP引擎的比较
为解决以上问题，从今年开始我们引入了StarRocks，逐步替换之前的分析引擎，实现OLAP平台多业务场景的查询引擎统一化。
主要因为StarRocks具备以下特性：
- MPP架构 + 高效列式存储引擎
- 高性能、高可用、高弹性
标准ANSI SQL支持
- 支持多表Join
- 支持MySQL协议
支持预聚合
- 支持物化视图
- 支持预聚合结果自动更新
- 支持数据高效的批量导入、实时导入
- 支持数据的实时更新
我们对StarRocks与其他OLAP引擎做了全面的对比测试，对比项包括ClickHouse、Duird和Apache Doris。测试环境配置信息如下：
查询性能：StarRocks vs ClickHouse vs Apache Doris
查询性能对比测试使用SSB测试集，数据量最大的表lineorder约60亿(scale 1000)。在ClickHouse最擅长的宽表模式下，分别在限制线程数不超过8，不限制线程数两种情况下对比了StarRocks和Clickhouse的性能。
在StarRocks和ClickHouse单节点都使用不超过8个线程的情况下，13个查询中有9个StarRocks的性能好于ClickHouse。
(宽表模式，设置ClickHouse max_threads=8）
不限制ClickHouse线程数情况下，13个查询中有7个StarRocks性能好于ClickHouse。
(宽表模式，不限制max_threads）
在多表Join模式下，对比了StarRocks和Apache Doris的表现。整体上StarRocks比Apache Doris有5-10倍的性能优势。
没有对Apache Doris的宽表性能进程测试，是由于在60亿的数据量下，StarRocks可以直接使用insert into select语句将数据转成宽表，Apache doris执行相同语句会报oom。由此也可以看出StarRocks在内存的管理和执行效率上比Apache Doris要好不少。同时也了解到StarRocks后续也有开源的计划，所以我们在应用中都使用了StarRocks作为OLAP分析引擎。
高并发：StarRocks vs Druid
线上实际环境，以宽表模式对Druid和StarRocks进行了高并发的压力测试。Druid集群的QPS可以达到600-700左右，平均响应时间100ms左右，最大响应时间300ms左右。相同规模的StarRocks集群，QPS可以达到1500-2000，平均响应时间在50ms左右，最大响应时间在100ms左右。
（压力测试下Druid并发量）
（压力测试下StarRocks并发量）
此外，我们额外对StarRocks的Join模式进行了高并发的压力测试，QPS可以到200-300，平均响应时间470ms。可以看出即使在Join模式的复杂查询场景下，StarRocks的并发性能还依旧维持在一个不错的水准。
其他指标
如下表所示，我们也对其他方面的指标进行了比较：
StarRocks在贝壳的应用
目前贝壳的StarRocks集群使用35台物理机（80core、192GB内存、3TB SSD），部署了35 BE，3 FE。支持了如指标平台、可视化报表平台、典型业务场景等多个应用。
指标平台
1、 高QPS指标查询
通过StarRocks强大的并发能力支撑以往Druid所不能满足的高QPS场景。如房屋经纪人业绩考核时段，QPS会瞬间从几十飙升到3000。以往使用Durid应对这类瞬时高压场景没有很好的解决办法，集群会不停告警乃至宕机。使用StarRocks支撑的指标平台就能很好的解决这个问题。
2、 可自动更新的物化视图
StarRocks有非常好的物化视图能力。对慢查询指标通过rollup聚合，在查询时可以自动命中物化视图，自动路由，加速整个查询。同时物化视图支持自动更新，当明细表发生变化时，物化视图自动刷新聚合结果。
3、 实时的大屏指标
原有的实时指标是通过ClickHouse来支持的，但是需要建大量的视图。ClickHouse物化视图不支持自动路由，在查询时需要指定对应的物化视图表名字。而且ClickHouse对Update的支持也非常有限，查询最新的记录需要额外的函数支持，不符合标准的SQL语法。总体来说使用ClickHouse来计算实时指标，实现过程非常复杂。通过StarRocks来支持实时指标场景，能自动对指标进行实时更新，只需要创建对应的物化视图即可，无需额外的任何操作就可以指标的实时更新。
4、 更灵活的数据模型
StarRocks同时也具备非常强的单表查询能力和多表Join能力，可以支持宽表模式和多表Join模式。在应对部分灵活指标，如前文提到的经纪人组织架构变更场景，基于StarRocks就无需构建宽表。使用在线Join的方式，当维度发生变动的时候，更新维度表重新进行关联查询即可。
奥丁可视化平台
此前我们基于MySQL做了大量的报表，如市场管理看板等。随着数据量增大，数据量达到千万级别MySQL已经完全不能支撑。目前已将这些可视化系统报表全部迁移到StarRocks上。由于StarRocks对MySQL协议的支持，整个迁移的过过程比较平滑，只需要很少的工作量。
典型业务
原有的典型业务如A/B试验平台、交易平台、风控平台、直播中台等，之前是基于ClickHouse和Apache Doris构建的。现在我们已经开始将这些业务应用逐步迁移至StarRocks。此外，后续构建的新应用，如用户行为分析等，我们也会基于StarRocks来进行构建。
下图是直播中台从Apache Doris迁移到StarRocks后的查询效率对比。可以看到查询效率均有成倍的提升，在数据量大的情况下（全量表）性能提升尤为明细，性能提升均在7倍以上。
（直播平台使用StarRocks后，所有查询的延时都显著降低）
写在最后
在近半年的使用过程中，从整体来看StarRocks在稳定性和查询性能上要优于Apache doris。宽表性能和ClickHouse不相上下，多表Join能力要胜于ClickHouse。StarRocks在保持甚至超过ClickHouse性能的同时，极大降低了我们的运维压力，简化了数据开发的链路。
StarRocks对hive外表的支持也给我们很大的想象空间，尤其是一些Ad hoc查询场景。现在我们的小查询用Spark SQL，大的查询用hive或者是presto。后续使用StarRocks来分担一些热查询的流量，整体的查询效率也可以得到进一步的提升。使用StarRocks查询ElasticSearch外表也在我们下一步的规划中。
后续我们会将StarRocks覆盖到更多的业务场景，使用StarRocks逐步替代Druid、Clickhouse、Kylin等其他分析引擎，来构建我们全场景统一的极速OLAP分析平台。
StarRocks团队的同学支持也十分给力，在此表示感谢。