汽车之家（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 在汽车之家曾经有两个实时数据分析业务上线，别离是：举荐服务实时监控、搜寻实时成果剖析。

举荐服务实时监控

首先是举荐服务的实时监控。需要背景是实时举荐体系波及多个子系统，为了晋升举荐服务的整体稳定性，须要实时监控各子系统的服务衰弱状况。

上图是一个大略的链路，各个子系统会引入办法监控的 SDK，通过 SDK 把每分钟的办法监控的明细数据聚合起来，并将这些通过初步聚合的数据写入到监控零碎里，监控团队负责把这些数据推送到 Kafka ，并通过 Flink 实时把数据写到 StarRocks 表中。在这个场景中，每天写入 StarRocks 的数据有两亿条左右，这是 StarRocks 在汽车之家上线的第一个业务。

最终在 AutoBI 中的仪表板如上图，报表的 TP95 响应工夫在1秒左右，响应速度还是比拟快的。

搜寻实时成果

搜寻实时成果，需要是搜寻成果数据的实时统计，查看各频道、试验、内容类型的无后果率、跳出率、曝光量、点击量、CTR，特点就是日增的数据量在数十亿级，次要是利用 Grouping Set 模式，把所有可能的组合都计算好，给用户提供一个数据表格，并反对依照条件筛选；同时这个需要中波及多个 UV 指标（非准确去重）的计算，每一行数据中蕴含6个 UV 指标的计算，上面是 SQL 的示例：

在这个场景下，因为数据量较大，并且蕴含多个聚合指标，所以咱们定义了物化视图来减速查问。最初的展现模式就是上面的这种图表加上明细表格的模式。

咱们最后应用的是 StarRocks 1.17，因为存在多个 UV 指标，查问性能并不现实，在降级到 StarRocks 1.18 之后，性能失去了较大的晋升，响应工夫从十几秒降到四秒内。

总结与布局

最初简略总结一下，咱们通过引入 StarRocks 对立了明细查问和预聚合两种模型。其次是流批的对立，实时的数据和离线的数据都能够写到 StarRocks 外面，对外裸露对立的 OLAP 引擎来提供服务，这对用户来说是很敌对的。另外在查问性能方面，咱们通过跟其余的引擎的比照发现，StarRocks 的查问性能整体上来说是有劣势的。最初StarRocks兼容MySQL协定，容易上手，运维简略。

后续咱们会继续欠缺外部工具链，反对将业务表数据实时散发到StarRocks表中，进一步简化实时剖析的链路。同时咱们也会继续扩大 StarRocks 利用场景，积攒教训，晋升集群稳定性，更好的反对业务。