基于Flink+Starrocks建设之家广告实时数据
关注“之家技术”，获取更多技术干货
总篇153篇 2022年第28篇
背景介绍
汽车之家作为全球访问量头部的汽车网站，其广告业务每天会产生大量的投放效果数据，以反馈执行进度供运营同学及时进行业务策略调整，具体数据包含广告请求数据、广告曝光数据、广告可见曝光数据、广告点击数据等。
汽车之家广告主题离线数仓从2015年开始建设至今,一直能够满足核心广告业务的日常分析及报表支持。然而数据的时效性对企业的客户服务风控以及精细化运营越来越重要，商场如战场，实时有效的分析出有价值的信息，对企业的决策运营策略调整有很大帮助，及时提升与保障对客户的服务满意度及交付效果。基于此，我们纵观技术架构发展历程，可选用的实时计算引擎有Storm、Spark Streaming、Flink，存储引擎有StarRocks、Clickhouse、TiDB、Iceberg，我们就围绕这些技术方案进行严谨的调研与对比，最终确立使用最适合当前广告业务情景的方案，来支撑广告核心业务数据。
当前离线数仓架构
随着车智投、DSP、ADX等核心系统的逐步建设迭代，我们依据OneData数据仓库中台核心方法论建设了对应的广告主题数仓，完成了数据标准化、资产治理化、主题式数据服务等能力达成。在业务使用端输出了包括广告位、广告计划、广告素材等核心业务数据集，置于面向业务分析人员的OLAP工具平台上，业务人员即可自主查询。
有两个原因促使我们建设了针对核心数据集的小时级别输出。首先仅面向品牌广告部分业务，当时业务方对实时统计没有刚性需求。我们自驱提供了小时级别的运营数据供使用。其次当时实时化技术未在业内得到广泛应用，使用风险尚未探明，实时化技术对于广告业务的应用一直在学习探查中。
经过长期的学习探查，已具备业务实时化能力和人员储备。如果能及时获取效果数据，缩短问题恢复时间和策略调整时间，对于服务满意度以及交付度会有极大提升。
下图为广告离线数仓架构：
实时数仓技术架构
计算引擎选型对比
综上，选用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。
实时数仓分层设计
1.ODS源数据层：埋点日志投递或者流量日志采集实时存储到Kafka中，线上业务数据库通过Flink任务采集MySQL Binlog。
2.DWD明细层：Flink对实时数据完成维度扩充，双流Join，实时聚合等处理通过Sink Connector落到Starrocks。
3.DWA汇总层：由DWD层通过ETL得到明细宽表或者根据业务需求进行实际的指标聚合。
4.APP 应用层：基于业务需求将DWA层的数据进一步整合统计指标数据，面向前端展现，直接支持业务看板服务。
在广告效果的应用实践
广告实时数据流程
Flink开发详细流程
ODS层开发
ODS层包括广告点击表、广告曝光表和广告可见曝光表。在Flink平台通过原生的DDL语句定义Kafka表，将广告点击数据、广告曝光数据、广告可见曝光数据分别映射成一张Flink表。
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。
DWA层开发
APP层开发
问题与方案
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.点击数据、可见曝光数据需要和曝光数据做延迟关联，曝光数据需置于指定缓存窗口期内，以保障关联效率。
服务稳定性保障
Flink平台任务告警配置中内置了任务延迟监控、任务重启监控、任务保存点失败监控、作业探活监控等告警策略
基于Prometheus、Grafana对Starrocks 服务器内存使用率、磁盘使用率、磁盘IO 利用率、服务器CPU IO占比，磁盘读写数据、集群状态等指标监控。
总结与规划
在Flink+Starrocks实时数仓技术框架下，数据时效性从原来的小时提升至秒级，每秒处理约10W+条数据，实时准确率达到95%以上，大幅提升了业务数据反馈效率。且相关产品人员充分体会到了实时数据使用的快感，后续相继提出了许多实时化升级的需求，正在对接中。
后续我计划在两方面展开工作：第一，调研Starrocks外部表的使用，实现异构数据查询功能探查，减去多引擎关联情景下的数据迁移成本；第二，持续关注Flink和Starrocks社区动态，加强沟通学习，进一步提高广告业务整体链路处理速度。
作者简介
汽车之家
徐超
主机厂技术部-广告技术及系统团队
目前任职于主机厂事业部-技术部-广告技术及系统团队-数据系统组，负责之家广告实时数仓架构设计及开发工作，致力于为广告业务提供实时、准确的数据服务。
阅读更多：
▼ 关注「之家技术」，获取更多技术干货 ▼