写点什么

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

作者:StarRocks
  • 2021 年 11 月 26 日
  • 本文字数:3624 字

    阅读完需:约 12 分钟

汽车之家 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 引擎做了一些对比测试。

业务规模

多维监控平台整体业务规模:

协议:3000 多个协议,也就是对应 3000 多个维度表。

数据量:维度表的原始数据量非常大,峰值数据达到 33 亿条/min ,3 万亿/天。

并发量:异常检测平台调用,最高 33w/min 的调用峰值。

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 应用场景,积累经验,提升集群稳定性,更好的支持业务。

用户头像

StarRocks

关注

开源的新一代极速全场景MPP数据库 2020.08.08 加入

还未添加个人简介

评论

发布
暂无评论
汽车之家 x StarRocks:极速实时数据分析实践