汽车之家作为全球访问量头部的汽车网站，其广告业务每天会产生大量的投放效果数据，以反馈执行进度供运营同学及时进行业务策略调整，具体数据包含广告请求数据、广告曝光数据、广告可见曝光数据、广告点击数据等。

汽车之家广告主题离线数仓从2015年开始建设至今,一直能够满足核心广告业务的日常分析及报表支持。然而数据的时效性对企业的客户服务风控以及精细化运营越来越重要，商场如战场，实时有效的分析出有价值的信息，对企业的决策运营策略调整有很大帮助，及时提升与保障对客户的服务满意度及交付效果。基于此，我们纵观技术架构发展历程，可选用的实时计算引擎有Storm、Spark Streaming、Flink，存储引擎有StarRocks、Clickhouse、TiDB、Iceberg，我们就围绕这些技术方案进行严谨的调研与对比，最终确立使用最适合当前广告业务情景的方案，来支撑广告核心业务数据。

随着车智投、DSP、ADX等核心系统的逐步建设迭代，我们依据OneData数据仓库中台核心方法论建设了对应的广告主题数仓，完成了数据标准化、资产治理化、主题式数据服务等能力达成。在业务使用端输出了包括广告位、广告计划、广告素材等核心业务数据集，置于面向业务分析人员的OLAP工具平台上，业务人员即可自主查询。

有两个原因促使我们建设了针对核心数据集的小时级别输出。首先仅面向品牌广告部分业务，当时业务方对实时统计没有刚性需求。我们自驱提供了小时级别的运营数据供使用。其次当时实时化技术未在业内得到广泛应用，使用风险尚未探明，实时化技术对于广告业务的应用一直在学习探查中。

经过长期的学习探查，已具备业务实时化能力和人员储备。如果能及时获取效果数据，缩短问题恢复时间和策略调整时间，对于服务满意度以及交付度会有极大提升。

下图为广告离线数仓架构：

计算引擎选型对比：

上图是我们选择业界比较流行的3个实时计算引擎进行选型分析：

1、首先放弃Strom。因为我们要最大的保障数据准确性，所以对于Exactly-Once是强需求，在一致性保证上Storm的一致性语义是At-least-once，只能保证数据不丢失，不能保证数据的精确一次处理。

2、我们再来对比Flink和Spark Streaming。

a)处理模式对比。流处理有两种模式：Native 和Mirco-batch。Native是数据进入后立即处理，而Mirco-batch是数据流入后，先划分成Micro-batch，再处理。Mirco-batch数据会存在一定延迟，时效性相对不高。基于reciver的Spark Streaming使用了Mirco-batch模式，只能算是准实时；而基于direct stream的Spark Streaming则与Flink一样是使用的Native，是真正的实时处理，且能够保障Exactly-once语义，与广告业务需求契合。

b)开发维护对比。我们团队对于Flink和Spark Streaming的技术积累相差不大，且二者均支持相对友好的SQL任务开发模式。但是公司的开发维护平台对于Flink是大力支持，而Spark Streaming的SQL模式几乎没有支持，考虑后续稳定性与维护性，最终我们决定使用Flink作为实时处理引擎。

综上，选用Flink。

当前广告数据处理的存储引擎几乎全部依赖Hive，而Hive是不能够满足高并发或低延迟，要满足整体实时流程的顺利串行，一个高性能的实时存储引擎也是不可或缺的。

基于以上我们选择了Clickhouse、Starrocks、Iceberg、TiDB等数据库作为调研对象：

1、Clickhouse、Starrocks、TiDB时效性在秒级，而Iceberg则是分钟级的，这里我们放弃了Iceberg。

2、TiDB无预聚合功能且索引能力相对较弱，任何查询过来都是借力于各个分节点的即时计算能力，造成集群大量吞吐与计算，性能相对Clickhouse和Starrocks要弱。放弃TiDB

3、Clickhouse和Starrocks都能支持明细模型和预聚合模型，但是Clickhouse不支持标准SQL有一定的使用成本，而且对多表关联查询支持较弱，再考虑到运维成本较高，最终选择了Starrocks。

综上，选择Starrocks。

我们继续将OneData体系用于实时数仓建设，结合业务主题分为4层：ODS源数据层、DWD明细层、DWA汇总层、APP主题层。

1、ODS源数据层：埋点日志投递或者流量日志采集实时存储到Kafka中，线上业务数据库通过Flink任务采集MySQL Binlog。

2、DWD明细层：Flink对实时数据完成维度扩充，双流Join，实时聚合等处理通过Sink  Connector落到Starrocks。

3、DWA汇总层：由DWD层通过ETL得到明细宽表或者根据业务需求进行实际的指标聚合。

4、APP 应用层：基于业务需求将DWA层的数据进一步整合统计指标数据，面向前端展现，直接支持业务看板服务。

广告实时数据流程：

1、服务端上报请求日志到日志收集服务；客户端上报可见曝光日志、点击日志数据到日志收集服务。

2、日志收集服务对埋点日志进行统一处理，采集到Kafka中。

3、通过Flink消费Kafka，对数据进行数据清洗、聚合等操作，将结果写入到Starrocks。

4、最终通过之家内部OLAP自助分析平台配置呈现实时数据集。

1、ODS层开发

ODS层包括广告点击表、广告曝光表和广告可见曝光表。在Flink平台通过原生的DDL语句定义Kafka表，将广告点击数据、广告曝光数据、广告可见曝光数据分别映射成一张Flink表。

2、DWD层开发

本层输出广告流量宽表。在Flink平台通过原生的DDL语句定义Starrocks表，将处理后的结果映射成一张Flink表。

（1）Starrocks明细模型，基于明细模型指定排序Key为 dt、type、platform、click_filter_rule。

（2）开启动态分区，指定动态分区字段dt，配置动态分区起始结束时间，超过动态分区时间范围的分区会被自动删除，以节省存储和计算资源。

Flink平台新建任务，业务清洗规则如下：

（1）ODS广告点击表和ODS广告可见曝光表分别通过pv_id和filter字段过滤掉无效数据，之后合并两张表为一张表。

（2）合并后的中间表同ODS广告曝光表关联以补充缺失维度，获得完整的明细层数据写入到Starrocks。

3、DWA层开发

我们通过建立Starrocks物化视图来完成DWA层的建设工作。Starrocks会自动维护物化视图的数据，无论是新的导入，还是删除操作都能保证Base 表和物化视图表的数据一致性。无需任何额外的人工维护成本。业务查询时，会自动匹配到最优物化视图，并直接从物化视图中读取数据，提升查询效率。视图DDL示例如下：

4、APP层开发

APP层分为广告计划主题分析表和广告位主题分析表，在OLAP工具平台上以数据集的形式呈现广告请求量、广告点击量、广告曝光CRT、广告点击转化率等指标。

综上，从原始数据接入到最后报表呈现全部完成，且满足业务方需求，为业务运营提供决策支持手段。

1、Flink导入数据到Starrocks时指定sink.properties.format为json,并发达到50且批次大小超过100MB时导致导入数据失败。

解决方式：将sink配置sink.properties.format改成CSV，节省数据空间。

2、实际使用过程中Starrocks中出现复杂view，比如包含去重、join、view嵌套查询、聚合等操作的view，查询时报错unknow error，通过重建view可以恢复正常查询。此问题不能稳定复现。

针对此问题有以下2种方案：

（1）添加监控，定时检测view状态，并执行重建操作。

（2）已将问题反馈社区，社区给出解决方案：升级到2.1.8之后的版本。

方案1实现简单，但不能根本解决问题，方案2在原服务上升级，如果新搭建一套需要并行来测试运行，耗时长。结合现状，选择方案1优先解决线上业务问题，同时对方案2 充分测试并制定详尽稳定的升级计划。

3、点击数据、可见曝光数据需要和曝光数据做延迟关联，曝光数据需置于指定缓存窗口期内，以保障关联效率。

经过测试，数据缓存窗口期为2小时，与离线天数据对比准确率低于90%，不具备可用性。数据缓存窗口期为4小时与离线天数据对比准确率为95%以上，4小时内数据准确度为100%，可满足实时业务需求。

Kafka-connectors监控：

基于Prometheus、Grafana对Kafka消费速率及消费延迟等指标进行监控

Flink任务监控：

Flink平台任务告警配置中内置了任务延迟监控、任务重启监控、任务保存点失败监控、作业探活监控等告警策略

Starrocks监控：

基于Prometheus、Grafana对Starrocks 服务器内存使用率、磁盘使用率、磁盘IO 利用率、服务器CPU IO占比，磁盘读写数据、集群状态等指标监控。

在Flink+Starrocks实时数仓技术框架下，数据时效性从原来的小时提升至秒级，每秒处理约10W+条数据，实时准确率达到95%以上，大幅提升了业务数据反馈效率。且相关产品人员充分体会到了实时数据使用的快感，后续相继提出了许多实时化升级的需求，正在对接中。

后续我计划在两方面展开工作：第一，调研Starrocks外部表的使用，实现异构数据查询功能探查，减去多引擎关联情景下的数据迁移成本；第二，持续关注Flink和Starrocks社区动态，加强沟通学习，进一步提高广告业务整体链路处理速度。

作者介绍