贝壳找房作为“科技驱动的新寓居服务商”，致力于推动寓居服务产业数字化、智能化过程，通过助力优质服务者，为三亿中国家庭提供包含二手房、新房、租赁、装修等全方位的高品质、高效率寓居服务。
贝壳大数据平台部构建和撑持了全团体多个场景利用，笼罩的业务线多，业务复杂度高，因而对数据分析平台的要求也十分高。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 团队的同学反对也非常给力，在此表示感谢。