汽车之家（NYSE：ATHM）成立于年，为消费者提供优质的汽车消费和汽车生活服务，助力中国汽车产业蓬勃发展。我们致力于通过产品服务、数据技术、生态规则和资源为用户和客户赋能，建设“车内容、车交易、车金融、车生活”4个圈，建立以数据和技术为核心的智能汽车生态圈，正式迈向智能化的3.0时代。
汽车之家目前在智能推荐的效果分析，物料点击、曝光、计算点击率、流量宽表等场景，对实时分析的需求日益强烈。经过多轮的探索，最终选定StarRocks作为实时OLAP分析引擎，实现了对数据的秒级实时分析。
作者：邸星星，
汽车之家实时计算平台负责人
实时数据分析的现状
在汽车之家内部，实时数据的来源主要是三部分：
手机端户行为的日志；
应用程序的服务端的日志；
MySQL、SQLServer数据。
实时数据分析场景，目前面临的一些痛点包括：
使用Flink做指标聚合，Flink聚合不灵活，面对需求的时候开发成本比较高的，面对多变的需求，经常需要重复开发；
Kylin支持指标预计算，并发支持较好，但是不能够支持高效的明细数据查询。在一些需要下钻或者获取明细数据的场景支撑的不够好；
TiDB不支持预聚合模型，某些数据量大的场景，聚合指标需要在线计算。在线计算会导致服务器压力瞬间增大，而且查询性能不稳定，取决于参与计算的数据量和当时服务器的负载情况。
为什么选择StarRocks
上图是几个OLAP引擎的横向对比。StarRocks作为一款新兴OLAP产品，具有以下几个突出的优点：
查询场景灵活：StarRocks所能够支撑的查询场景比较灵活。既能够从明细数据进行聚合分析，也能基于预聚合的模型去提前构建好，加速查询；
兼容MySQL协议，平时使用MySQL的客户端就能进行查询和简单的运维：StarRocks兼容MySQL协议，使用成本、运维成本都比较低；
全面向量化引擎，查询性能好：查询性能高，并且能支持较高的并发和吞吐；
架构精简，易于运维。
但是StarRocks作为OLAP界的“年轻人”，也存在一些不太成熟的方面，比如：目前各个公司应用的深度可能不会特别深，所以还需要结合业务持续打磨。
在选型过程中，我们对StarRocks和常用的OLAP引擎做了一些对比测试。
业务规模
多维监控平台整体业务规模：
协议：多个协议，也就是对应多个维度表。
数据量：维度表的原始数据量非常大，峰值数据达到33亿条/min，3万亿/天。
并发量：异常检测平台调用，最高33w/min的调用峰值。
VSApacheKylin
在汽车之家内部ApacheKylin主要是面对固定查询的场景。主要都是一些特定的数据产品，还有一些日常的报表等。由于ApacheKylin是基于纯预聚算模型的，拿空间去换时间。所以在固定报表的场景下查询性能是非常好的，也能支持很高的并发。缺点就是不太灵活，要预先定义模型，如果要修改模型话，要重刷历史数据。
上图是StarRocks与ApacheKylin的一些对比。在6个亿的数据量下，用一个线上的Cube，和两台StarRocks去做一个简单的对比，在命中物化视图的场景下，StarRocks的查询性能可以媲美ApacheKylin，有些查询甚至比ApacheKylin还要快。
VSClickHouse
ClickHouse虽然能支持明细数据和预聚合模型，也是基于向量化的引擎，但主要缺点是运维成本高，对多表关联查询的支持较弱，所以我们选择了StarRocks。
上图是StarRocks与ClickHouse的性能对比。在亿的数据规模下，部署了四台服务器，针对Count和非精确去重两种查询做性能对比。在Count的场景下，ClickHouse的性能是比较接近的，两者没有明显的差异。在非精确去重（HLL）场景下，StarRocks查询性能明显优于ClickHouse。这得益于StarRocks1.18针对HLL查询的性能优化，在我们的测试场景下HLL查询的性能相比StarRocks1.17提升了3~4倍。
VSApacheDoris
上图是StarRocks与ApacheDoris的性能对比。也是在6个亿的数据量和两台机器的规模下进行的对比。由于StarRocks引入向量化引擎，相比ApacheDoris查询性能有2~7倍的提升。
VSPresto、Spark（hive外表）
上图是StarRocks与Presto、Spark查询Hive外表的一些性能对比。在10亿的数据量下，部署了八台服务器（是和Presto、Spark对等的资源），测试用例主要是Count和CountDistinct查询。测试的结果是StarRocks性能最优，大部分查询StarRocks性能优于Presto，Presto的性能优于Spark。还有另外一个使用StarRocks优势就是可以直接用ndv函数去做非精确的排重（HLL），此时查询性能优势更为明显。
其它
机械硬盘和SSD硬盘的对比。在6个亿的数据量和两台机器的规模下，在未命中PageCache情况下，SSD集群查询性能提升3~8倍；在命中PageCache情况下，两个集群的性能是比较接近的，此时SSD不会带来性能提升。
应用实践
当前我们已经初步完成了StarRocks和实时、离线平台的集成工作。
首先是实时平台，实时计算平台直接集成Flink-connector-StarRocks；然后是离线平台，我们通过提供brokerload脚本，支持将Hive数据导入到StarRocks。最后是StarRocks监控，主要是基于Prometheus、Grafana，我们还收集了StarRocks本身的auditlog，并解析每个SQL的执行情况、分析StarRocks的查询性能和成功率。
首先看一下StarRocks和Flink平台（AutoStream）的集成，用户可以通过Flink原生的DDL来定义StarRocks表，也就是把StarRocks里面已经存在的一张表映射成Flink表。
上图是一个基于Flink+StarRocks的实时ETL的案例：
从一张表里面过滤user_id大于0的，biz_id和biz_type是数字类型的，event_id在这几个事件里面的数据；
通过DATE_FORMAT函数以及CASEWHEN语句对字段做处理；
最终把结果写入到StarRocks表中。在离线调度平台上，我们提供了一个标准的Python脚本用来提交brokerload任务，通过脚本+参数配置的方式，可将Hive数据高效导入到StarRocks中。同时这个脚本会持续检查brokerload任务的进度，如果执行失败了，那么对应的调度任务也会失败，并触发调度平台本身的重试及告警机制。
这是我们DBA同事配置的StarRocks监控的报表。当时遇到了一个问题，就是StarRocks它FEmetrics格式不规范，导致PrometheusTextParser解析失败，我们做了一些代码修复。
在报表中我们可以从数据库、用户的维度查看StarRocks的查询次数、相应时间、异常SQL等信息。当集群发生问题时，这个报表可以帮助我们快速定位问题、恢复业务；同时用户也可以了解自己业务的查询情况，定位慢SQL并进行优化。
截止10月底，StarRocks在汽车之家已经有两个实时数据分析业务上线，分别是：推荐服务实时监控、搜索实时效果分析。
推荐服务实时监控
首先是推荐服务的实时监控。需求背景是实时推荐体系涉及多个子系统，为了提升推荐服务的整体稳定性，需要实时监控各子系统的服务健康情况。
上图是一个大概的链路，各个子系统会引入方法监控的SDK，通过SDK把每分钟的方法监控的明细数据聚合起来，并将这些经过初步聚合的数据写入到监控系统里，监控团队负责把这些数据推送到Kafka，并通过Flink实时把数据写到StarRocks表中。在这个场景中，每天写入StarRocks的数据有两亿条左右，这是StarRocks在汽车之家上线的第一个业务。
最终在AutoBI中的仪表板如上图，报表的TP95响应时间在1秒左右，响应速度还是比较快的。
搜索实时效果
搜索实时效果，需求是搜索效果数据的实时统计，查看各频道、实验、内容类型的无结果率、跳出率、曝光量、点击量、CTR，特点就是日增的数据量在数十亿级，主要是应用GroupingSet模式，把所有可能的组合都计算好，给用户提供一个数据表格，并支持按照条件筛选；同时这个需求中涉及多个UV指标（非精确去重）的计算，每一行数据中包含6个UV指标的计算，下面是SQL的示例：
在这个场景下，由于数据量较大，并且包含多个聚合指标，所以我们定义了物化视图来加速查询。最后的展示形式就是下面的这种图表加上明细表格的形式。
我们最初使用的是StarRocks1.17，由于存在多个UV指标，查询性能并不理想，在升级到StarRocks1.18之后，性能得到了较大的提升，响应时间从十几秒降到四秒内。
总结与规划
最后简单总结一下，我们通过引入StarRocks统一了明细查询和预聚合两种模型。其次是流批的统一，实时的数据和离线的数据都可以写到StarRocks里面，对外暴露统一的OLAP引擎来提供服务，这对用户来说是很友好的。另外在查询性能方面，我们通过跟其他的引擎的对比发现，StarRocks的查询性能整体上来说是有优势的。最后StarRocks兼容MySQL协议，容易上手，运维简单。
后续我们会持续完善内部工具链，支持将业务表数据实时分发到StarRocks表中，进一步简化实时分析的链路。同时我们也会持续扩展StarRocks应用场景，积累经验，提升集群稳定性，更好的支持业务。