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

贝壳大数据平台部构建和撑持了全团体多个场景利用，笼罩的业务线多，业务复杂度高，因而对数据分析平台的要求也十分高。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团队的同学反对也非常给力，在此表示感谢。