汽车之家（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 利用场景，积攒教训，晋升集群稳定性，更好的反对业务。