汽车之家 x StarRocks：极速实时数据分析实践

汽车之家（NYSE：ATHM）成立于2005年，为消费者提供优质的汽车消费和汽车生活服务，助力中国汽车产业蓬勃发展。我们致力于通过产品服务、数据技术、生态规则和资源为用户和客户赋能，建设“车内容、车交易、车金融、车生活” 4个圈，建立以数据和技术为核心的智能汽车生态圈，正式迈向智能化的3.0时代。

汽车之家目前在智能推荐的效果分析，物料点击、曝光、计算点击率、流量宽表等场景，对实时分析的需求日益强烈。经过多轮的探索，最终选定 StarRocks 作为实时 OLAP 分析引擎，实现了对数据的秒级实时分析。

“ 作者：邸星星，
汽车之家实时计算平台负责人 ”

实时数据分析的现状

在汽车之家内部，实时数据的来源主要是三部分：

手机端户行为的日志；
应用程序的服务端的日志；
MySQL、SQLServer数据。

实时数据分析场景，目前面临的一些痛点包括：

使用 Flink 做指标聚合，Flink 聚合不灵活，面对需求的时候开发成本比较高的，面对多变的需求，经常需要重复开发；
Kylin 支持指标预计算，并发支持较好，但是不能够支持高效的明细数据查询。在一些需要下钻或者获取明细数据的场景支撑的不够好；
TiDB 不支持预聚合模型，某些数据量大的场景，聚合指标需要在线计算。在线计算会导致服务器压力瞬间增大，而且查询性能不稳定，取决于参与计算的数据量和当时服务器的负载情况。

为什么选择 StarRocks

上图是几个 OLAP 引擎的横向对比。StarRocks 作为一款新兴 OLAP 产品，具有以下几个突出的优点：

查询场景灵活：StarRocks 所能够支撑的查询场景比较灵活。既能够从明细数据进行聚合分析，也能基于预聚合的模型去提前构建好，加速查询；
兼容 MySQL 协议，平时使用 MySQL 的客户端就能进行查询和简单的运维：StarRocks 兼容 MySQL 协议，使用成本、运维成本都比较低；
全面向量化引擎，查询性能好：查询性能高，并且能支持较高的并发和吞吐；
架构精简，易于运维。

但是 StarRocks 作为 OLAP 界的“年轻人”，也存在一些不太成熟的方面，比如：目前各个公司应用的深度可能不会特别深，所以还需要结合业务持续打磨。

在选型过程中，我们对 StarRocks 和常用的 OLAP 引擎做了一些对比测试。

VS Apache Kylin

在汽车之家内部 Apache Kylin 主要是面对固定查询的场景。主要都是一些特定的数据产品，还有一些日常的报表等。由于 Apache Kylin 是基于纯预聚算模型的，拿空间去换时间。所以在固定报表的场景下查询性能是非常好的，也能支持很高的并发。缺点就是不太灵活，要预先定义模型，如果要修改模型话，要重刷历史数据。

上图是 StarRocks 与 Apache Kylin 的一些对比。在6个亿的数据量下，用一个线上的 Cube，和两台 StarRocks 去做一个简单的对比，在命中物化视图的场景下， StarRocks 的查询性能可以媲美 Apache Kylin，有些查询甚至比 Apache Kylin 还要快。

VS ClickHouse

ClickHouse 虽然能支持明细数据和预聚合模型，也是基于向量化的引擎，但主要缺点是运维成本高，对多表关联查询的支持较弱，所以我们选择了 StarRocks。

上图是 StarRocks 与 ClickHouse 的性能对比。在120亿的数据规模下，部署了四台服务器，针对 Count 和非精确去重两种查询做性能对比。在 Count 的场景下，ClickHouse 的性能是比较接近的，两者没有明显的差异。在非精确去重（HLL ）场景下，StarRocks 查询性能明显优于 ClickHouse。这得益于 StarRocks 1.18 针对 HLL 查询的性能优化，在我们的测试场景下HLL查询的性能相比 StarRocks 1.17 提升了3~4倍。

VS Apache Doris

上图是 StarRocks 与 Apache Doris 的性能对比。也是在6个亿的数据量和两台机器的规模下进行的对比。由于 StarRocks 引入向量化引擎，相比 Apache Doris 查询性能有2~7倍的提升。

VS Presto、Spark（hive外表）

上图是 StarRocks 与 Presto 、Spark 查询 Hive 外表的一些性能对比。在10亿的数据量下，部署了八台服务器（是和 Presto 、Spark 对等的资源），测试用例主要是 Count 和 Count Distinct查询。测试的结果是 StarRocks 性能最优，大部分查询 StarRocks 性能优于 Presto，Presto 的性能优于 Spark。还有另外一个使用StarRocks优势就是可以直接用 ndv 函数去做非精确的排重（HLL），此时查询性能优势更为明显。

其它

机械硬盘和 SSD 硬盘的对比。在6个亿的数据量和两台机器的规模下，在未命中 PageCache 情况下，SSD 集群查询性能提升3~8倍；在命中 PageCache 情况下，两个集群的性能是比较接近的，此时 SSD 不会带来性能提升。

应用实践

当前我们已经初步完成了 StarRocks 和实时、离线平台的集成工作。

首先是实时平台，实时计算平台直接集成 Flink-connector-StarRocks；然后是离线平台，我们通过提供 broker load 脚本，支持将 Hive 数据导入到 StarRocks。最后是 StarRocks 监控，主要是基于 Prometheus、Grafana，我们还收集了 StarRocks 本身的 audit log ，并解析每个SQL的执行情况、分析 StarRocks 的查询性能和成功率。

首先看一下 StarRocks 和Flink 平台（AutoStream）的集成，用户可以通过 Flink 原生的 DDL 来定义 StarRocks 表，也就是把 StarRocks 里面已经存在的一张表映射成 Flink 表。

上图是一个基于 Flink + StarRocks 的实时 ETL的案例：

从一张表里面过滤 user_id 大于0的，biz_id 和 biz_type 是数字类型的，event_id 在这几个事件里面的数据；
通过 DATE_FORMAT 函数以及 CASE WHEN 语句对字段做处理；
最终把结果写入到 StarRocks 表中。

在离线调度平台上，我们提供了一个标准的 Python 脚本用来提交 broker load 任务，通过脚本+参数配置的方式，可将 Hive 数据高效导入到 StarRocks 中。同时这个脚本会持续检查 broker load 任务的进度，如果执行失败了，那么对应的调度任务也会失败，并触发调度平台本身的重试及告警机制。

这是我们 DBA 同事配置的 StarRocks 监控的报表。当时遇到了一个问题，就是 StarRocks 它 FE metrics格式不规范，导致 Prometheus TextParser 解析失败，我们做了一些代码修复。

这是 StarRocks 集群的统计报表。前面提到了，我们会实时收集、解析 auditlog 中的查询记录，并将这些查询记录写回到一张 StarRocks 表中；再通过配置 AutoBI 的仪表版，就实现了 StarRocks 本身的性能监控及分析。
在报表中我们可以从数据库、用户的维度查看 StarRocks 的查询次数、相应时间、异常 SQL 等信息。当集群发生问题时，这个报表可以帮助我们快速定位问题、恢复业务；同时用户也可以了解自己业务的查询情况，定位慢 SQL 并进行优化。

截止10月底，StarRocks 在汽车之家已经有两个实时数据分析业务上线，分别是：推荐服务实时监控、搜索实时效果分析。

搜索实时效果

搜索实时效果，需求是搜索效果数据的实时统计，查看各频道、实验、内容类型的无结果率、跳出率、曝光量、点击量、CTR，特点就是日增的数据量在数十亿级，主要是应用 Grouping Set 模式，把所有可能的组合都计算好，给用户提供一个数据表格，并支持按照条件筛选；同时这个需求中涉及多个 UV 指标（非精确去重）的计算，每一行数据中包含6个 UV 指标的计算，下面是 SQL 的示例：

在这个场景下，由于数据量较大，并且包含多个聚合指标，所以我们定义了物化视图来加速查询。最后的展示形式就是下面的这种图表加上明细表格的形式。

我们最初使用的是 StarRocks 1.17，由于存在多个 UV 指标，查询性能并不理想，在升级到 StarRocks 1.18 之后，性能得到了较大的提升，响应时间从十几秒降到四秒内。

总结与规划

最后简单总结一下，我们通过引入 StarRocks 统一了明细查询和预聚合两种模型。其次是流批的统一，实时的数据和离线的数据都可以写到 StarRocks 里面，对外暴露统一的 OLAP 引擎来提供服务，这对用户来说是很友好的。另外在查询性能方面，我们通过跟其他的引擎的对比发现，StarRocks 的查询性能整体上来说是有优势的。最后StarRocks兼容MySQL协议，容易上手，运维简单。

后续我们会持续完善内部工具链，支持将业务表数据实时分发到StarRocks表中，进一步简化实时分析的链路。同时我们也会持续扩展 StarRocks 应用场景，积累经验，提升集群稳定性，更好的支持业务。