1. 一次曝光背后程序化广告的数据链路到底有多深在开始拆解数据处理技巧之前我觉得有必要先把程序化广告的真实数据流路径讲清楚。很多人对这个行业的理解停留在广告主投钱、媒体放广告位、用户看到广告这种粗颗粒度上但实际干过这行的人都清楚一次广告曝光的背后是一张极其庞大且时效性要求极高的数据网络。一次典型的实时竞价RTB流程大概是这样的用户打开一个App或者网页媒体端的SDK检测到广告位可以被填充于是发出一串广告请求那串请求里包含了设备信息、地理位置、网络环境、当前页面上下文、用户的历史行为标签等等。这个请求发出之后会被送到广告交易平台Ad Exchange交易平台迅速将这个请求同时广播给成百上千个需求方平台DSP所有DSP需要在几十到一百毫秒内决定要不要出价、出多少钱然后把竞价响应返回给交易平台。如果赢下这次竞价DSP还要负责把广告素材下发到用户端整个过程从用户打开页面的那一瞬间到广告最终展示在屏幕上留给系统的时间窗口通常是100到300毫秒。这意味着什么意味着程序化广告的核心矛盾就是在极短的时间内把海量的上下文信息和历史数据进行匹配、计算、决策然后把结果返回。这跟我们平时写一个后端接口处理几百个并发请求完全是两个量级的挑战。再往深一层看数据本身的价值密度差异极大。同样是曝光日志有些字段对优化模型和投放策略至关重要比如用户ID、设备ID、竞价价格、是否曝光成功、是否点击、素材ID、页面上下文有些字段则是干扰项比如乱七八糟的地域编码、不完整的设备型号、缺失的经纬度信息。如果数据处理的第一个环节没有把这些东西厘清后面所有的分析和模型训练都会受到污染。我经常跟团队里新来的同学说一句话程序化广告的本质说穿了就是数据处理竞赛。谁能在同样短的时间里处理更多高质量的数据谁就能在竞价中占据技术优势。所以从今天这篇开始我打算以程序化广告行业为场景底子把数据处理这一整个链条上的技巧逐步拆开来讲包括实时流处理、日志清洗、特征工程、数据存储选型、异常检测这些模块。这篇文章是系列第二篇会先把整体数据链路和技术框架盘清楚后续再逐个击破具体的处理模块。2. 高吞吐低延迟广告场景下数据处理的核心矛盾与架构取舍2.1 为什么常规数据库在这里完全不够用如果你之前一直在做传统业务系统的数据处理比如电商订单、CRM系统、内容管理系统你可能会习惯性地认为把数据存进数据库然后写SQL查询不行的话就加索引、分库分表再不行就上缓存。这套思路在程序化广告行业里几乎行不通原因有两个核心约束。第一个约束是写入速率。一个中等规模的广告交易平台每天要处理的广告请求量级大概在几十亿到上百亿次。即使只看DSP这一侧每天接收到的竞价请求也至少是几亿到十几亿量级。每次请求会附带用户上下文、设备信息、页面信息等几十个字段这意味着一秒内可能就有几万到几十万条数据需要被处理。你拿MySQL去扛这种写入压力除非做非常复杂的水平拆分否则分分钟被打爆。更重要的是这些数据除了要被实时处理之外还要被离线分析使用这就迫使我们必须采取写入一次、多处消费的架构模式。这个模式听起来简单落地的时候牵扯到消息队列选型、序列化协议选择、分区策略设计等一堆细节。第二个约束是查询时效。竞价决策通常要求在几十毫秒内完成这意味着DSP必须提前把用户画像数据、频次控制数据、预算消耗数据等准备好放在高速存储里供实时服务查询。没有人会在竞价那一刻去数据库里跑一个多表Join的SQL那根本不现实。所以在程序化广告的架构里数据的处理链条被刻意地拆成了两个大块一块是实时的、低延迟的在线链路负责支撑竞价决策和投放实时控制另一块是离线的、大吞吐量的分析链路负责报表统计、模型训练、人群画像构建等。2.2 Lambda架构程序化广告的事实标准方案如果你去翻各大广告技术公司的技术分享会发现绝大多数公司采用的还是Lambda架构即使是那些已经在探索Kappa架构的团队短期内也还是离不开离线数据修正这层保障。Lambda架构的思想其实很简单数据同时走两条处理通道一条实时通道用流处理引擎处理最近几分钟甚至几秒内的数据保证低延迟一条离线通道用批量处理引擎处理全量数据保证数据准确性和完整性。最终通过一个合并层把两条通道的结果拼起来对外提供统一的查询接口。行业内最常见的搭配是Kafka作为数据接入层Flink或Spark Streaming做实时计算Spark或Hive做离线批处理最终结果落到ClickHouse、Doris这类分析型数据库里供BI查询和报表服务使用。这套架构放在广告场景下有几个明显的好处。第一实时通道可以支持频次控制、预算消耗统计、实时出价策略调整这些对时间敏感的业务逻辑。比如说某个广告主给一条投放计划设定了单日预算5万元系统需要实时累加消耗当消耗快要触达预算边界时要立刻降低出价甚至停止参与竞价这个动作拖慢几十毫秒都可能造成预算超跑。第二离线通道可以反复对全量历史数据进行重算修正实时计算可能带来的误差同时为CTR/CVR预估模型准备训练样本。我个人的经验是在广告行业里做数据处理架构不要一上来就追求最先进的技术方案比如搞纯流式计算替代批处理而是先把Lambda架构跑稳。因为实时计算的误差修正、数据回溯、指标对齐这些问题在广告业务场景下是逃不掉的离线批处理天然就是你的安全网。等你把Lambda架构下的数据处理流程打磨熟练了再去思考能不能减少离线这一层的依赖把实时通道做得更可靠、语义更精确会顺畅得多。2.3 消息中间件选型Kafka为什么几乎成了默认选择整个数据链路的最上游是消息队列。所有广告请求日志包括竞价日志、曝光日志、点击日志都会先打进消息队列再由下游的实时和离线任务消费。消息队列的选型基本决定了整条链路的吞吐上限和消息可靠性。目前行业里用得最多的还是Kafka偶有团队用Pulsar或者RocketMQ但Kafka的生态成熟度和社区活跃度仍是最高的。Kafka在广告场景下有几个优势是其他组件难以替代的。一个是吞吐量单机可以支撑每秒几十万条消息的写入配合合理的分区策略集群的吞吐可以线性扩展。另一个是消息回溯能力消费者可以把offset重置到任意时间点重新消费数据这在广告数据链路中极其重要。比如凌晨跑离线任务的时候发现某个时间段的数据质量有问题需要把原始日志重新消费一遍Kafka能轻松做到而其他很多消息队列在数据回溯上就没这么灵活。在使用Kafka的时候有几个细节值得注意。分区数量是在数据接入初期就要规划好的因为分区数是Kafka并行度和数据顺序性的核心决定因素。如果分区数太少下游消费者数再多也无法提升消费速度如果分区数太多又会带来broker端的文件句柄和内存开销。一般建议的分区数设置思路是根据目标吞吐量除以单分区吞吐能力来估算同时考虑到未来半年的增长空间留出30%到50%的余量。另外对广告日志这种高价值数据一定要开启acksall和min.insync.replicas2这类配置避免leader节点故障时丢消息。有很多团队早期为了追求极致的写入速度把acks设成0结果集群一抖动就丢了几小时的数据这种坑一旦踩上数据修复的代价远比那点性能提升大得多。3. 从日志到洞察我常用的广告数据处理实战技巧3.1 日志标准化如何从源头减少脏数据处理广告日志的第一步也是最容易忽略的一步是日志的标准化。很多公司早期为了快速上线让不同业务方按照各自习惯的字段格式上报日志结果到了数据平台集成的时候发现同样的设备ID有人传md5之后的有人传明文还有人直接传空字符串光清洗这块就耗费大量人力。我建议在日志接入阶段就制定一套统一的数据规范至少包含这么几项统一命名规范字段名用snake_case还是camelCase要定死、统一时间格式一律用毫秒级时间戳加时区偏移避免不同业务方传不同格式的时间字符串、统一ID映射规则明文、md5、sha256之间的关系要有一个标准的转化流程、统一枚举值设备类型、操作系统、网络环境这些字段的值域要预先定义好上线后不允许随意扩展新值。日志标准化不是一次性的工作而是一个持续治理的过程。我见过太多数据团队把精力都放在算法模型上觉得日志标准化是脏活累活不去管它结果后面每一次数据分析都要花大量的时间去排查字段含义、清洗格式问题。实际上你只要在前期花一点时间把规范定好把校验逻辑写进数据管道里后面反而能省出大量的时间去做真正有价值的事情。3.2 特征工程的核心步骤从原始日志到可用特征原始日志里的字段是不能直接喂给机器学习模型的这中间需要做大量的特征工程工作。在程序化广告场景下特征工程通常包含三个层面的处理。第一层是单字段的清洗与转换。比如把字符串型的地域信息映射成层级编码把一个用户点击历史的原始序列转换成滑动窗口内的统计量过去7天点击次数、过去24小时曝光次数、最近一次点击距今天数等。这里有个经验之谈很多初入行的同学做特征工程时喜欢堆大量衍生特征觉得特征越多模型效果越好实际在广告场景下特征维度过高不仅会拖慢训练速度还可能引发过拟合问题同时也让特征上线时的处理逻辑变得异常复杂。我倾向于在做特征取舍时先用业务逻辑判断特征是否合理再结合特征重要性分析和单变量AUC评估来筛选。第二层是交叉特征的处理。广告场景里类别型特征之间往往存在协同作用比如用户所在城市和广告位所在App类型组合起来的信息量远大于两个特征单独使用。交叉特征的处理方式通常有两种一种是直接在特征工程阶段做笛卡尔积但这种做法容易导致特征极度稀疏另一种是通过类似GBDTLR的结构让树模型自动捕捉特征之间的交互关系再将树的输出作为逻辑回归的输入。后一种方式在广告行业里曾经长期占据主导地位。第三层是时效性控制。广告数据有个显著特点就是数据分布会随着时间发生漂移。用户的兴趣会变、媒体流量的分布会变、季节性因素也会影响广告效果。如果特征工程不考虑时效性直接用全量历史数据做统计特征那模型的效果会逐渐变差。我会把特征分成两类一类是长期稳定的画像特征比如用户年龄段、设备价格段这些可以用全量历史数据统计另一类是短期波动的行为特征比如最近一个小时的页面访问次数、最近一天的曝光点击率这类特征的时间窗口要尽量短才能捕捉到用户此刻的意图状态。3.3 数据清洗那些耗掉我大量时间的脏数据问题数据处理整个过程里数据清洗是我觉得最琐碎但也最重要的环节。广告日志的脏数据来源太多了我在这里罗列一些最常见的给准备入行的朋友做个参考。用户ID缺失或者无效。程序化广告里用户身份贯穿整个数据和业务链路但是如果用户开启了限制广告追踪LAT或者媒体端获取不到设备ID日志里的ID字段就是空的。对这些数据要建立一个统一的处理策略是丢弃、是保留但标记为unknown还是单独建立一套匿名ID来追踪。我倾向于保留并标记因为这些无效ID的请求同样参与了竞价如果直接丢弃消耗统计和请求量统计会对不上。每一次数据处理逻辑的调整都可能引发业务指标的口径变化改动之前要想清楚。曝光日志和竞价日志对不上。日志系统是分布式上报的曝光日志和竞价日志走的是两条链路经常会出现曝光日志存在而竞价日志缺失或者竞价日志显示赢得了竞价但曝光日志里找不到对应的记录。这种情况通常是因为曝光监测延迟、媒体端SDK上报失败、或者广告在客户端被渲染拦截。处理这类问题时我一般会做一个以曝光日志为准的关联规则如果一条曝光日志找不到对应的竞价日志就根据曝光时间、设备ID、广告位ID去竞价日志里进行一个小窗口的模糊匹配如果还是匹配不到就把它记为一个疑似虚假曝光单独标记出来供反作弊模块使用。点击日志中的无效点击。点击日志里最让人头疼的是刷量行为和误点击。刷量行为一般有明显的模式特征比如同一设备在极短时间内多次点击广告、点击时间间隔异常整齐、点击后无任何后续操作等。这块通常交给反作弊模块去处理但数据清洗层面也需要做一层基础的过滤比如把点击时间距离曝光时间超过合理范围的记录剔除把同一设备同一素材在1秒内的重复点击合并为一次。时间戳偏移问题。广告日志的数据源来自不同SDK和不同服务器各自服务器的时钟可能存在偏差这导致日志里的时间戳顺序和实际到达顺序不一致。处理办法是一方面在数据接入层根据各数据源的标识做时间戳校准另一方面在做窗口计算时不要依赖处理时间而是使用事件时间Event Time配合一定的乱序容忍度。3.4 流式数据中的去重、乱序与迟到数据处理实时数据处理中最让我头疼的永远是三个问题去重、乱序、迟到数据。这三个问题在广告场景下尤其突出。去重方面最常用的方案是利用Flink的KeyedState配合ValueState/RocksDB实现基于事件ID的去重。具体做法是为每类事件定义一个唯一的事件ID比如竞价事件可以用请求ID时间戳拼一个唯一键曝光事件可以用请求ID创意ID时间戳拼唯一键然后在处理时判断当前事件ID是否已经存在于状态里如果存在就丢弃。这种方案的问题在于状态会无限增长所以需要配合状态过期机制把超过一定时间窗口的状态清掉。我一般设置状态的TTL为窗口时间的两倍左右既能保证窗口内的正确去重又不会让状态无限膨胀。乱序和迟到数据处理核心理解是Watermark机制。简单来说Watermark是Flink中用来表示事件时间进度的标记。假设我们设置Watermark为当前最大事件时间减去5秒的乱序容忍度那意味着系统认为5秒以内延迟的数据都是可以被接受的超过Watermark的时间窗口会被强制计算并输出结果。等到迟到数据真的来了可以通过设置allowedLateness把窗口的关闭时间进一步推迟让窗口在关闭之后的一段时间内仍然可以接收迟到数据并在再次触发计算时输出修正结果最后通过sideOutputLateData把那些迟到太久的数据单独输出到一个旁路流里走离线修复通道。这里我想强调一点实时数据处理的最终目标不是输出一个完美的结果而是输出一个及时且可修正的结果。广告业务的预算消耗统计、频次控制这类对实时性要求高的指标可以接受一定程度的不精确但是需要通过迟到的修正机制把最终结果校准到正确值。所以设计实时链路的时候要把修正链路也一并设计好否则时间越久数据偏差越大后面补救的成本就越高。4. 工具链选型什么样的存储和计算方案才扛得住广告数据量级4.1 实时计算引擎Flink还是Spark Streaming聊到实时计算引擎我知道很多人会在Flink和Spark Streaming之间纠结。我个人的判断是如果你要做的事件是真正的毫秒级流式处理比如实时竞价出价逻辑中的规则引擎、实时频次控制、秒级预算消耗统计那直接选Flink不要犹豫。Flink的True Streaming架构是基于每个事件逐条处理的延迟可以做到毫秒级而且它的状态管理RocksDB状态后端和精确一次语义Exactly-once在广告场景下真的太重要了。Spark Streaming我之前的团队也用过但它的微批Micro-batch架构本质上还是把流切成小批量来处理延迟通常在秒级这在一些实时性要求高的广告场景里是扛不住的。不过它也不是一无是处如果你的需求只是分钟级延迟的实时报表而且团队对Spark更熟悉那Spark Streaming完全可以胜任。我记得我们早期做实时消耗监控的时候就用过Spark Streaming做秒级统计是吃力的但做分钟级别消耗趋势、投放计划的状态变更通知体验还行。4.2 存储层的选型思路消息队列、KV存储、分析型数据库如何各司其职在程序化广告的数据处理链条里存储系统不是单一的一个数据库而是多个存储配合使用各管一段。数据实时接入层几乎都是用Kafka负责数据的缓冲和分发。Kafka本身不算真正的存储系统不要想着把Kafka里的数据长期保留它只是临时缓冲区和数据分发管道数据消费完之后要在设定的保留期内被下游落地到真正的存储里。实时服务层的KV存储最常用的是Redis和HBase。Redis适合存储那些数据量不大但访问频率极高的配置类数据比如某个投放计划的实时预算、频次控制计数器、定向包的判断结果缓存。HBase适合存储海量设备ID到用户画像的映射关系因为用户画像数据可能有几十亿条记录Redis的内存成本完全扛不住而HBase的LSM-Tree存储结构天然适合这种写多读多、按Key查询的场景。离线分析层的存储行业里现在的默认答案基本是ClickHouse或者Doris。这两个列式存储数据库在处理海量数据的聚合查询时比传统关系型数据库快一到两个数量级。比如我们要跑一条SQL统计过去30天某个App上的广告曝光数按城市分布在MySQL上可能需要几分钟的查询在ClickHouse上通常几秒内就出结果。我个人的经验是在存储选型上不要贪多求新。每种存储都有它的适用边界一个团队的数据处理能力不是由你用了多少种技术栈决定的而是由你把每种技术的边界摸得多清楚决定的。与其在十个组件之间来回切换不如把一个核心组件吃透。比如ClickHouse的MergeTree表引擎有很多参数可以调优很多人只是把它当成一个普通的OLAP数据库去用根本没有发挥出它的真正优势。4.3 轻量级工具在广告数据处理中的应用RPA和Excel也没那么不堪聊到这里可能会有人觉得程序化广告数据处理是不是必须得上各种大数据组件实际情况不是这样的。在广告业务的日常运营中很多数据处理场景其实用不到那么重的技术栈轻量级工具反而更高效。比如运营同学需要定期整理各投放计划的消耗数据然后跟广告主那边对账通常就是从后台报表系统导出Excel然后做大量的数据清洗和汇总工作这种情况你让她去学SQL写Python不现实教她用Excel的Power Query和数据透视表反而更快。也有不少广告代理商团队在做素材批量上传、广告计划批量修改的时候用RPA工具来替代手工重复操作。比如每天固定时间登录广告平台后台自动下载报表把数据整理好之后发送到指定的企业微信或者邮件群组。这类工具本身不涉及复杂的算法和架构但确实能节省大量的人力时间也算是一种轻型的数据处理方案。我在带团队的时候有个原则先看场景复杂度再决定技术方案。一个月几万条数据的报表用Python处理完全没问题但用Python写一套自动化脚本维护的成本可能比用Excel处理还高。反过来如果一天要处理几亿条广告日志那确实必须上分布式计算引擎靠Excel是绝对不可能的。判断用哪个技术栈的标准始终是数据处理链路的总成本和产出速度而不是参数本身。5. 踩坑实录广告数据处理中我反复栽过的地方5.1 数据倾斜广告场景里最常见也最隐蔽的性能瓶颈做分布式数据处理基本都逃不过数据倾斜这个问题。广告场景里数据倾斜出现的概率尤其高因为流量的头部效应极其明显少数几个头部App的曝光量可能占了全部流量的六成以上少数几个广告主的出价请求也可能占据请求总量的很大比例。当实时计算任务以AppID或者广告主ID作为分组的Key时数据会集中到极少数的几个计算节点上其他节点却处于空闲状态整个任务的执行时间被拖得很长甚至出现OOM。我遇到过一个比较典型的案例某个Flink实时统计任务按照广告位ID统计曝光、点击消耗任务总并行度设了48但是运行一段时间之后发现部分节点的CPU使用率接近100%其他节点只有不到5%。排查之后发现排名前几的广告位贡献了超过一半的流量而Flink默认的KeyBy策略是基于Key的哈希取模恰恰这些头部广告位被哈希到了同一个或少数几个子任务上。解决思路有几种。第一种是两阶段聚合Partial Aggregate Full Aggregate先在本地做一个预聚合来减轻Shuffle的压力再在网上把预聚合结果汇总。第二种是加盐Salting给热点Key加一个随机后缀把一条热点数据分散到多个Key上处理最后再合并。第三种是调整并行度分配策略把热点的Key单独识别出来分配更多的并行度。我觉得最值得说的反而不是技术方案本身而是如何快速定位数据倾斜。很多人在Flink的Web UI上看到一个任务运行很慢先去调并行度、调缓存但实际上先去看一下每个子任务的输入记录数和数据量会更快定位问题。如果各子任务之间的输入数据量差异超过一个数量级那大概率就是数据倾斜先做热点Key分析。5.2 时间窗口设计的想当然时刻窗口边界带来的统计误差时间窗口的问题在广告数据处理中非常隐蔽处理不好会导致统计口径偏差进而影响预算控制和效果评估。有一次我们做一个每小时广告消耗的实时统计任务用Flink的TumblingEventTimeWindows窗口大小设为一小时。结果上线后运营那边反馈每个整点时刻统计出来的消耗数据总会突然跳一下跟广告后台的实时消耗对不上。排查下来发现原因有两个。第一个原因是广告日志的事件时间戳是由媒体端SDK在客户端本地生成的当用户的手机时钟不准确或者SDK上报存在延迟时事件的真实发生时间和日志里记录的时间会有偏差。这时如果直接按事件时间划分窗口就会把本该属于上一个窗口的数据划到下一个窗口里去。第二个原因是日志从媒体端传到广告服务平台再到数据管道中间有几秒到几十秒的网络延迟如果窗口边界恰好在这个延迟时间附近边界处的数据归属就不稳定。这个问题的解法是一方面在窗口设计时加入一定的触发延迟和乱序容忍Flink里就是通过Watermark机制来实现的另一方面在窗口聚合之外额外维护一套基于处理时间的准实时统计用于快速响应运营查看需求而正式的、以事件时间为准的统计结果走延迟补数逻辑去修正。定期对账时用离线全量数据去校准实时统计的偏差把误差控制在一定范围内。5.3 跨渠道ID映射的数据孤儿问题程序化广告中用户在不同平台上的ID是不同的。同一个用户在广告交易平台里可能是一串设备ID在媒体的用户系统里是另一套用户ID在广告主自己的CRM系统里又是第三套ID。跨渠道的ID映射是广告数据处理的难点之一做得不好会产生大量的数据孤儿也就是那些只有一个渠道的ID、无法关联到这个用户在另一个渠道的数据。比如某个用户在广告平台上的设备ID是A但他在广告主App里注册的账号ID是B这两套ID在业务上是同一个实体。如果我们能把A和B关联起来那广告主就能做到把广告平台的曝光数据与站内的转化数据打通甚至可以做人群包的回传和lookalike扩充。但实际情况下由于用户会换设备、清Cookie、使用多设备ID映射关系的建立和维护非常困难。处理ID映射问题我建议采用图计算的思路来建立ID之间的关联而不是简单的一对一映射。你可以把每个ID当成一个节点把同一设备上同时出现或同一用户的注册行为关联当成一条边然后用连通图算法去把属于同一个用户的所有ID聚成一个簇。这种方案在初期数据量不大的时候可以用Spark GraphX跑批处理后面数据量上来之后可以引入图数据库来服务实时查询。这个问题的复杂性在于ID映射的逻辑会直接影响广告定向和频次控制的准确性映射错了轻则给用户推了不相关的广告重则打乱整个频控策略导致预算浪费。所以ID映射的每一次修改都要有完整的验证流程对比修改前后的数据分布变化确保不会引入严重的关联误差。5.4 调试实时任务时容易忽视的Checkpoint细节Flink的Checkpoint机制是实时任务数据一致性的基础保障但很多人在开发调试的时候会忽视它等到线上出问题才重视。我见过好几个团队在开发环境测试实时任务的时候直接把Checkpoint功能关掉觉得单机调试不需要结果任务上线之后遇到一次节点故障状态丢失统计数据从故障时间点开始全部归零给业务侧造成了不小的混乱。关于Checkpoint我有几个经验分享给读者。首先Checkpoint的间隔不要太短也不要太长太短会增加状态存储的写入压力太长会导致故障恢复时间过长。我一般建议设置成10秒到30秒之间具体看状态大小和业务对恢复时效的要求。其次要监控Checkpoint的成功率和完成时间。如果成功率持续下降或者完成时间接近间隔时间说明状态后端或存储系统存在瓶颈需要及时处理。再次状态后端的选择要结合场景RocksDB适合大状态场景但如果状态不是特别大FsStateBackend配合内存模式反而性能更好。6. 让数据说话从处理好的数据到业务优化决策6.1 广告漏斗分析从曝光到转化的数据追踪链路数据处理的工作不是数据清洗完就结束了最终的目标还是要落回业务优化上。广告漏斗是衡量投放效果的基础框架在程序化广告场景里漏斗通常包括请求、竞价、曝光、点击、转化这几个关键节点。数据处理的挑战在于一个用户从看到广告到完成转化时间跨度可能从几分钟到几周不等要把这些分散在不同时间段的数据串联起来形成一个完整的转化路径。我一般会建立一个统一的漏斗分析模型把所有关键事件以用户ID设备ID为主键串联起来然后通过时间窗口的设定来划分转化归因窗口。比如电商行业的广告主一般把点击后7天内的转化都算作广告带来的转化而游戏行业可能看的是点击后30天内的激活。归因窗口不同统计出来的ROI就完全不同所以这个窗口的设定一定要跟广告主确认清楚。漏斗分析中最常见的问题是多触点归因。用户可能先在一个App上看到了广告没有点击后来在另一个App上又看到了同一个广告点击之后才完成转化。那这次转化应该归因给哪个渠道要注意各个平台采用主流的归因方式不一样有的采用末次点击归因有的采用首次点击归因有的用线性归因。数据处理工程师需要跟投放优化师明确当前业务的归因模型用的是哪一种然后把原始曝光、点击数据按照归因逻辑重新组织和计算。这个环节如果没做好后面所有的效果分析和预算分配决策都是建立在错误的数据基础上。6.2 频次控制和预算消耗监控实时数据处理的高价值应用程序化广告的一个核心指标是频次控制Frequency Capping也就是限制同一个用户在单位时间内看到同一条广告的最大次数。频次控制如果做得不好用户会反复看到同一个广告产生厌烦情绪广告主也会觉得投放效率低。频次控制的实时性要求很高因为从用户看到第一条广告到决定是否给他展示第二条广告中间只隔了毫秒级的竞价决策时间。实现频次控制的技术思路通常是在广告请求进来的时候以用户ID为Key去KV存储里查询该用户近期的广告曝光记录如果曝光次数达到上限就放弃竞价或者降低出价。这个查询必须非常快所以KV存储的选型和数据结构的优化就变得很关键。我遇到的比较棘手的问题是同一个用户短时间内产生了大量曝光记录KV存储里存储的集合越来越大查询性能急剧下降。后来我们把曝光记录按照小时切成多个小Key来存储查询的时候并行读取最近N个小时的小Key聚合结果性能问题才得到缓解。预算消耗监控也是实时数据处理的典型应用。广告主的消耗预算在竞价过程中是实时扣减的所以我们需要一个秒级甚至毫秒级更新的消耗统计服务。当一条投放计划的实时消耗接近预算上限时系统要自动降低出价或者暂停竞价避免超跑。这套逻辑对数据的准确性要求很高如果消耗统计延迟了就会导致预算已经超跑还在继续竞价最后广告主那边对账就会出问题。6.3 异常流量识别用数据手段给广告业务体检异常流量Invalid Traffic, IVT是程序化广告行业绕不开的话题也是最考验数据处理能力的场景之一。异常流量的常见形态包括机器刷量用脚本或模拟器批量产生曝光和点击、广告位堆叠作弊把多个广告位叠在一起用户根本看不到但产生了曝光、恶意点击竞争对手反复点击广告以消耗广告主预算。异常流量识别的方法可以分成规则和模型两大类。规则层面可以设定各种硬性阈值比如单设备单日曝光超过某个量级就触发告警、点击率异常偏高比如超过5%触发审查、同一IP下设备数量异常集中等。模型层面可以用监督学习训练一个异常流量分类器输入特征包括设备行为序列、请求频次分布、点击时间间隔分布、停留时长等。不过考虑到异常流量的形态是在不断演化的单纯依靠模型也会滞后所以更常见的做法是规则与模型并行用规则实时拦截一些明显异常用模型离线识别一些隐蔽模式。在数据处理层面要做好做异常流量识别最重要的是保留足够细粒度的原始日志。有的团队为了节省存储空间在日志接入阶段就把原始日志做粗粒度的聚合比如只保留每个设备每天的总曝光量那后面做异常分析时就没有数据了。我的意见是原始日志至少保留30天以上虽然存储成本会增加但在反作弊分析、数据排查、模型训练这些场景里这些原始数据是无价的。7. 技术之外程序化广告数据处理中的团队协作与流程规范数据处理从来不只是技术问题很大程度上还牵扯到跨团队协作的顺畅度。在程序化广告公司里数据团队需要跟商务团队、投放优化师、产品经理、算法工程师密切配合而这些人对数据的诉求往往是不同的。商务团队想知道的是这个渠道的流量质量怎么样广告主的预算有没有被浪费投放优化师想知道的是哪些素材在哪些广告位上效果好好决定下一步怎么调整预算结构算法工程师想知道的是训练样本的数据分布稳不稳定特征是否有效。数据团队的核心价值之一就是把这几个角色的数据诉求整合起来提供统一、可靠的数据输出。我这边比较强调数据口径的统一。同样一个指标在商务那边叫消耗在投放优化师那边叫花费在算法那边叫计费金额如果不把口径对齐各部门聊起来都是鸡同鸭讲。建议的做法是建立一个指标字典把所有核心指标的定义、来源、计算逻辑、使用场景都记录下来这算是数据治理的基础工作。流程规范方面我特别想提的一点是数据变更管理。广告行业的数据处理链路涉及的表结构、任务、口径非常之多经常会有小改动但一个小小的改动也可能引发连锁反应。比如统计报表里的曝光量字段定义从媒体的曝光回执数量调整为广告服务端确认的有效曝光数量看起来只是口径的细化但其实会导致所有下游报表、投放策略判断、广告主对账都会发生变化。如果这个改动没有经过变更评审、影响面分析、回滚预案这些流程直接改了代码就上线很容易出事故。所以不管团队规模大小数据变更管理一定要做起来。8. 后续可以往哪个方向继续深挖这个话题的内容量其实还很大这篇文章主要把程序化广告的数据处理链路和核心技巧的整体框架盘了一遍。后续可以深入的方向我简单列一下给对这块感兴趣的朋友做个参考。第一个方向是实时特征平台的建设。广告模型的特征除了离线批量生成之外越来越多的场景需要实时特征。比如用户在当前页面的停留时长、最近几分钟的浏览序列这些特征的实时性对预估模型的效果有明显提升。怎么构建一套支持毫秒级特征查询、秒级特征更新的实时特征平台是一个非常有意思的工程问题。第二个方向是数据质量控制与数据血缘追踪。广告数据链路长、环节多一个数据质量问题可能隐藏在很深的层次。构建一套完善的数据血缘系统让每张报表、每个模型特征都能追溯到原始日志在排查问题时能节省大量时间。第三个方向是隐私计算与数据安全的合规落地。广告行业对用户隐私的保护要求越来越严格如何在不过度采集用户数据的前提下依然能做好广告定向和效果衡量是一个非常有挑战的数据处理问题。联邦学习、差分隐私、同态加密这些技术在实际广告场景里的落地值得持续关注。程序化广告是一个把数据处理技术用到极致、逼到极致的行业。在这里你会发现同样的数据量放在传统行业里可能用最朴素的手段就能处理但在广告场景下必须要考虑毫秒级延迟、极高的吞吐要求、复杂的实时状态管理和严格的数据准确性。正因为如此从广告行业里学到的数据处理技巧换到其他任何有海量数据和高实时性要求的行业都会有很强的迁移价值。
1. 一次曝光背后程序化广告的数据链路到底有多深在开始拆解数据处理技巧之前我觉得有必要先把程序化广告的真实数据流路径讲清楚。很多人对这个行业的理解停留在广告主投钱、媒体放广告位、用户看到广告这种粗颗粒度上但实际干过这行的人都清楚一次广告曝光的背后是一张极其庞大且时效性要求极高的数据网络。一次典型的实时竞价RTB流程大概是这样的用户打开一个App或者网页媒体端的SDK检测到广告位可以被填充于是发出一串广告请求那串请求里包含了设备信息、地理位置、网络环境、当前页面上下文、用户的历史行为标签等等。这个请求发出之后会被送到广告交易平台Ad Exchange交易平台迅速将这个请求同时广播给成百上千个需求方平台DSP所有DSP需要在几十到一百毫秒内决定要不要出价、出多少钱然后把竞价响应返回给交易平台。如果赢下这次竞价DSP还要负责把广告素材下发到用户端整个过程从用户打开页面的那一瞬间到广告最终展示在屏幕上留给系统的时间窗口通常是100到300毫秒。这意味着什么意味着程序化广告的核心矛盾就是在极短的时间内把海量的上下文信息和历史数据进行匹配、计算、决策然后把结果返回。这跟我们平时写一个后端接口处理几百个并发请求完全是两个量级的挑战。再往深一层看数据本身的价值密度差异极大。同样是曝光日志有些字段对优化模型和投放策略至关重要比如用户ID、设备ID、竞价价格、是否曝光成功、是否点击、素材ID、页面上下文有些字段则是干扰项比如乱七八糟的地域编码、不完整的设备型号、缺失的经纬度信息。如果数据处理的第一个环节没有把这些东西厘清后面所有的分析和模型训练都会受到污染。我经常跟团队里新来的同学说一句话程序化广告的本质说穿了就是数据处理竞赛。谁能在同样短的时间里处理更多高质量的数据谁就能在竞价中占据技术优势。所以从今天这篇开始我打算以程序化广告行业为场景底子把数据处理这一整个链条上的技巧逐步拆开来讲包括实时流处理、日志清洗、特征工程、数据存储选型、异常检测这些模块。这篇文章是系列第二篇会先把整体数据链路和技术框架盘清楚后续再逐个击破具体的处理模块。2. 高吞吐低延迟广告场景下数据处理的核心矛盾与架构取舍2.1 为什么常规数据库在这里完全不够用如果你之前一直在做传统业务系统的数据处理比如电商订单、CRM系统、内容管理系统你可能会习惯性地认为把数据存进数据库然后写SQL查询不行的话就加索引、分库分表再不行就上缓存。这套思路在程序化广告行业里几乎行不通原因有两个核心约束。第一个约束是写入速率。一个中等规模的广告交易平台每天要处理的广告请求量级大概在几十亿到上百亿次。即使只看DSP这一侧每天接收到的竞价请求也至少是几亿到十几亿量级。每次请求会附带用户上下文、设备信息、页面信息等几十个字段这意味着一秒内可能就有几万到几十万条数据需要被处理。你拿MySQL去扛这种写入压力除非做非常复杂的水平拆分否则分分钟被打爆。更重要的是这些数据除了要被实时处理之外还要被离线分析使用这就迫使我们必须采取写入一次、多处消费的架构模式。这个模式听起来简单落地的时候牵扯到消息队列选型、序列化协议选择、分区策略设计等一堆细节。第二个约束是查询时效。竞价决策通常要求在几十毫秒内完成这意味着DSP必须提前把用户画像数据、频次控制数据、预算消耗数据等准备好放在高速存储里供实时服务查询。没有人会在竞价那一刻去数据库里跑一个多表Join的SQL那根本不现实。所以在程序化广告的架构里数据的处理链条被刻意地拆成了两个大块一块是实时的、低延迟的在线链路负责支撑竞价决策和投放实时控制另一块是离线的、大吞吐量的分析链路负责报表统计、模型训练、人群画像构建等。2.2 Lambda架构程序化广告的事实标准方案如果你去翻各大广告技术公司的技术分享会发现绝大多数公司采用的还是Lambda架构即使是那些已经在探索Kappa架构的团队短期内也还是离不开离线数据修正这层保障。Lambda架构的思想其实很简单数据同时走两条处理通道一条实时通道用流处理引擎处理最近几分钟甚至几秒内的数据保证低延迟一条离线通道用批量处理引擎处理全量数据保证数据准确性和完整性。最终通过一个合并层把两条通道的结果拼起来对外提供统一的查询接口。行业内最常见的搭配是Kafka作为数据接入层Flink或Spark Streaming做实时计算Spark或Hive做离线批处理最终结果落到ClickHouse、Doris这类分析型数据库里供BI查询和报表服务使用。这套架构放在广告场景下有几个明显的好处。第一实时通道可以支持频次控制、预算消耗统计、实时出价策略调整这些对时间敏感的业务逻辑。比如说某个广告主给一条投放计划设定了单日预算5万元系统需要实时累加消耗当消耗快要触达预算边界时要立刻降低出价甚至停止参与竞价这个动作拖慢几十毫秒都可能造成预算超跑。第二离线通道可以反复对全量历史数据进行重算修正实时计算可能带来的误差同时为CTR/CVR预估模型准备训练样本。我个人的经验是在广告行业里做数据处理架构不要一上来就追求最先进的技术方案比如搞纯流式计算替代批处理而是先把Lambda架构跑稳。因为实时计算的误差修正、数据回溯、指标对齐这些问题在广告业务场景下是逃不掉的离线批处理天然就是你的安全网。等你把Lambda架构下的数据处理流程打磨熟练了再去思考能不能减少离线这一层的依赖把实时通道做得更可靠、语义更精确会顺畅得多。2.3 消息中间件选型Kafka为什么几乎成了默认选择整个数据链路的最上游是消息队列。所有广告请求日志包括竞价日志、曝光日志、点击日志都会先打进消息队列再由下游的实时和离线任务消费。消息队列的选型基本决定了整条链路的吞吐上限和消息可靠性。目前行业里用得最多的还是Kafka偶有团队用Pulsar或者RocketMQ但Kafka的生态成熟度和社区活跃度仍是最高的。Kafka在广告场景下有几个优势是其他组件难以替代的。一个是吞吐量单机可以支撑每秒几十万条消息的写入配合合理的分区策略集群的吞吐可以线性扩展。另一个是消息回溯能力消费者可以把offset重置到任意时间点重新消费数据这在广告数据链路中极其重要。比如凌晨跑离线任务的时候发现某个时间段的数据质量有问题需要把原始日志重新消费一遍Kafka能轻松做到而其他很多消息队列在数据回溯上就没这么灵活。在使用Kafka的时候有几个细节值得注意。分区数量是在数据接入初期就要规划好的因为分区数是Kafka并行度和数据顺序性的核心决定因素。如果分区数太少下游消费者数再多也无法提升消费速度如果分区数太多又会带来broker端的文件句柄和内存开销。一般建议的分区数设置思路是根据目标吞吐量除以单分区吞吐能力来估算同时考虑到未来半年的增长空间留出30%到50%的余量。另外对广告日志这种高价值数据一定要开启acksall和min.insync.replicas2这类配置避免leader节点故障时丢消息。有很多团队早期为了追求极致的写入速度把acks设成0结果集群一抖动就丢了几小时的数据这种坑一旦踩上数据修复的代价远比那点性能提升大得多。3. 从日志到洞察我常用的广告数据处理实战技巧3.1 日志标准化如何从源头减少脏数据处理广告日志的第一步也是最容易忽略的一步是日志的标准化。很多公司早期为了快速上线让不同业务方按照各自习惯的字段格式上报日志结果到了数据平台集成的时候发现同样的设备ID有人传md5之后的有人传明文还有人直接传空字符串光清洗这块就耗费大量人力。我建议在日志接入阶段就制定一套统一的数据规范至少包含这么几项统一命名规范字段名用snake_case还是camelCase要定死、统一时间格式一律用毫秒级时间戳加时区偏移避免不同业务方传不同格式的时间字符串、统一ID映射规则明文、md5、sha256之间的关系要有一个标准的转化流程、统一枚举值设备类型、操作系统、网络环境这些字段的值域要预先定义好上线后不允许随意扩展新值。日志标准化不是一次性的工作而是一个持续治理的过程。我见过太多数据团队把精力都放在算法模型上觉得日志标准化是脏活累活不去管它结果后面每一次数据分析都要花大量的时间去排查字段含义、清洗格式问题。实际上你只要在前期花一点时间把规范定好把校验逻辑写进数据管道里后面反而能省出大量的时间去做真正有价值的事情。3.2 特征工程的核心步骤从原始日志到可用特征原始日志里的字段是不能直接喂给机器学习模型的这中间需要做大量的特征工程工作。在程序化广告场景下特征工程通常包含三个层面的处理。第一层是单字段的清洗与转换。比如把字符串型的地域信息映射成层级编码把一个用户点击历史的原始序列转换成滑动窗口内的统计量过去7天点击次数、过去24小时曝光次数、最近一次点击距今天数等。这里有个经验之谈很多初入行的同学做特征工程时喜欢堆大量衍生特征觉得特征越多模型效果越好实际在广告场景下特征维度过高不仅会拖慢训练速度还可能引发过拟合问题同时也让特征上线时的处理逻辑变得异常复杂。我倾向于在做特征取舍时先用业务逻辑判断特征是否合理再结合特征重要性分析和单变量AUC评估来筛选。第二层是交叉特征的处理。广告场景里类别型特征之间往往存在协同作用比如用户所在城市和广告位所在App类型组合起来的信息量远大于两个特征单独使用。交叉特征的处理方式通常有两种一种是直接在特征工程阶段做笛卡尔积但这种做法容易导致特征极度稀疏另一种是通过类似GBDTLR的结构让树模型自动捕捉特征之间的交互关系再将树的输出作为逻辑回归的输入。后一种方式在广告行业里曾经长期占据主导地位。第三层是时效性控制。广告数据有个显著特点就是数据分布会随着时间发生漂移。用户的兴趣会变、媒体流量的分布会变、季节性因素也会影响广告效果。如果特征工程不考虑时效性直接用全量历史数据做统计特征那模型的效果会逐渐变差。我会把特征分成两类一类是长期稳定的画像特征比如用户年龄段、设备价格段这些可以用全量历史数据统计另一类是短期波动的行为特征比如最近一个小时的页面访问次数、最近一天的曝光点击率这类特征的时间窗口要尽量短才能捕捉到用户此刻的意图状态。3.3 数据清洗那些耗掉我大量时间的脏数据问题数据处理整个过程里数据清洗是我觉得最琐碎但也最重要的环节。广告日志的脏数据来源太多了我在这里罗列一些最常见的给准备入行的朋友做个参考。用户ID缺失或者无效。程序化广告里用户身份贯穿整个数据和业务链路但是如果用户开启了限制广告追踪LAT或者媒体端获取不到设备ID日志里的ID字段就是空的。对这些数据要建立一个统一的处理策略是丢弃、是保留但标记为unknown还是单独建立一套匿名ID来追踪。我倾向于保留并标记因为这些无效ID的请求同样参与了竞价如果直接丢弃消耗统计和请求量统计会对不上。每一次数据处理逻辑的调整都可能引发业务指标的口径变化改动之前要想清楚。曝光日志和竞价日志对不上。日志系统是分布式上报的曝光日志和竞价日志走的是两条链路经常会出现曝光日志存在而竞价日志缺失或者竞价日志显示赢得了竞价但曝光日志里找不到对应的记录。这种情况通常是因为曝光监测延迟、媒体端SDK上报失败、或者广告在客户端被渲染拦截。处理这类问题时我一般会做一个以曝光日志为准的关联规则如果一条曝光日志找不到对应的竞价日志就根据曝光时间、设备ID、广告位ID去竞价日志里进行一个小窗口的模糊匹配如果还是匹配不到就把它记为一个疑似虚假曝光单独标记出来供反作弊模块使用。点击日志中的无效点击。点击日志里最让人头疼的是刷量行为和误点击。刷量行为一般有明显的模式特征比如同一设备在极短时间内多次点击广告、点击时间间隔异常整齐、点击后无任何后续操作等。这块通常交给反作弊模块去处理但数据清洗层面也需要做一层基础的过滤比如把点击时间距离曝光时间超过合理范围的记录剔除把同一设备同一素材在1秒内的重复点击合并为一次。时间戳偏移问题。广告日志的数据源来自不同SDK和不同服务器各自服务器的时钟可能存在偏差这导致日志里的时间戳顺序和实际到达顺序不一致。处理办法是一方面在数据接入层根据各数据源的标识做时间戳校准另一方面在做窗口计算时不要依赖处理时间而是使用事件时间Event Time配合一定的乱序容忍度。3.4 流式数据中的去重、乱序与迟到数据处理实时数据处理中最让我头疼的永远是三个问题去重、乱序、迟到数据。这三个问题在广告场景下尤其突出。去重方面最常用的方案是利用Flink的KeyedState配合ValueState/RocksDB实现基于事件ID的去重。具体做法是为每类事件定义一个唯一的事件ID比如竞价事件可以用请求ID时间戳拼一个唯一键曝光事件可以用请求ID创意ID时间戳拼唯一键然后在处理时判断当前事件ID是否已经存在于状态里如果存在就丢弃。这种方案的问题在于状态会无限增长所以需要配合状态过期机制把超过一定时间窗口的状态清掉。我一般设置状态的TTL为窗口时间的两倍左右既能保证窗口内的正确去重又不会让状态无限膨胀。乱序和迟到数据处理核心理解是Watermark机制。简单来说Watermark是Flink中用来表示事件时间进度的标记。假设我们设置Watermark为当前最大事件时间减去5秒的乱序容忍度那意味着系统认为5秒以内延迟的数据都是可以被接受的超过Watermark的时间窗口会被强制计算并输出结果。等到迟到数据真的来了可以通过设置allowedLateness把窗口的关闭时间进一步推迟让窗口在关闭之后的一段时间内仍然可以接收迟到数据并在再次触发计算时输出修正结果最后通过sideOutputLateData把那些迟到太久的数据单独输出到一个旁路流里走离线修复通道。这里我想强调一点实时数据处理的最终目标不是输出一个完美的结果而是输出一个及时且可修正的结果。广告业务的预算消耗统计、频次控制这类对实时性要求高的指标可以接受一定程度的不精确但是需要通过迟到的修正机制把最终结果校准到正确值。所以设计实时链路的时候要把修正链路也一并设计好否则时间越久数据偏差越大后面补救的成本就越高。4. 工具链选型什么样的存储和计算方案才扛得住广告数据量级4.1 实时计算引擎Flink还是Spark Streaming聊到实时计算引擎我知道很多人会在Flink和Spark Streaming之间纠结。我个人的判断是如果你要做的事件是真正的毫秒级流式处理比如实时竞价出价逻辑中的规则引擎、实时频次控制、秒级预算消耗统计那直接选Flink不要犹豫。Flink的True Streaming架构是基于每个事件逐条处理的延迟可以做到毫秒级而且它的状态管理RocksDB状态后端和精确一次语义Exactly-once在广告场景下真的太重要了。Spark Streaming我之前的团队也用过但它的微批Micro-batch架构本质上还是把流切成小批量来处理延迟通常在秒级这在一些实时性要求高的广告场景里是扛不住的。不过它也不是一无是处如果你的需求只是分钟级延迟的实时报表而且团队对Spark更熟悉那Spark Streaming完全可以胜任。我记得我们早期做实时消耗监控的时候就用过Spark Streaming做秒级统计是吃力的但做分钟级别消耗趋势、投放计划的状态变更通知体验还行。4.2 存储层的选型思路消息队列、KV存储、分析型数据库如何各司其职在程序化广告的数据处理链条里存储系统不是单一的一个数据库而是多个存储配合使用各管一段。数据实时接入层几乎都是用Kafka负责数据的缓冲和分发。Kafka本身不算真正的存储系统不要想着把Kafka里的数据长期保留它只是临时缓冲区和数据分发管道数据消费完之后要在设定的保留期内被下游落地到真正的存储里。实时服务层的KV存储最常用的是Redis和HBase。Redis适合存储那些数据量不大但访问频率极高的配置类数据比如某个投放计划的实时预算、频次控制计数器、定向包的判断结果缓存。HBase适合存储海量设备ID到用户画像的映射关系因为用户画像数据可能有几十亿条记录Redis的内存成本完全扛不住而HBase的LSM-Tree存储结构天然适合这种写多读多、按Key查询的场景。离线分析层的存储行业里现在的默认答案基本是ClickHouse或者Doris。这两个列式存储数据库在处理海量数据的聚合查询时比传统关系型数据库快一到两个数量级。比如我们要跑一条SQL统计过去30天某个App上的广告曝光数按城市分布在MySQL上可能需要几分钟的查询在ClickHouse上通常几秒内就出结果。我个人的经验是在存储选型上不要贪多求新。每种存储都有它的适用边界一个团队的数据处理能力不是由你用了多少种技术栈决定的而是由你把每种技术的边界摸得多清楚决定的。与其在十个组件之间来回切换不如把一个核心组件吃透。比如ClickHouse的MergeTree表引擎有很多参数可以调优很多人只是把它当成一个普通的OLAP数据库去用根本没有发挥出它的真正优势。4.3 轻量级工具在广告数据处理中的应用RPA和Excel也没那么不堪聊到这里可能会有人觉得程序化广告数据处理是不是必须得上各种大数据组件实际情况不是这样的。在广告业务的日常运营中很多数据处理场景其实用不到那么重的技术栈轻量级工具反而更高效。比如运营同学需要定期整理各投放计划的消耗数据然后跟广告主那边对账通常就是从后台报表系统导出Excel然后做大量的数据清洗和汇总工作这种情况你让她去学SQL写Python不现实教她用Excel的Power Query和数据透视表反而更快。也有不少广告代理商团队在做素材批量上传、广告计划批量修改的时候用RPA工具来替代手工重复操作。比如每天固定时间登录广告平台后台自动下载报表把数据整理好之后发送到指定的企业微信或者邮件群组。这类工具本身不涉及复杂的算法和架构但确实能节省大量的人力时间也算是一种轻型的数据处理方案。我在带团队的时候有个原则先看场景复杂度再决定技术方案。一个月几万条数据的报表用Python处理完全没问题但用Python写一套自动化脚本维护的成本可能比用Excel处理还高。反过来如果一天要处理几亿条广告日志那确实必须上分布式计算引擎靠Excel是绝对不可能的。判断用哪个技术栈的标准始终是数据处理链路的总成本和产出速度而不是参数本身。5. 踩坑实录广告数据处理中我反复栽过的地方5.1 数据倾斜广告场景里最常见也最隐蔽的性能瓶颈做分布式数据处理基本都逃不过数据倾斜这个问题。广告场景里数据倾斜出现的概率尤其高因为流量的头部效应极其明显少数几个头部App的曝光量可能占了全部流量的六成以上少数几个广告主的出价请求也可能占据请求总量的很大比例。当实时计算任务以AppID或者广告主ID作为分组的Key时数据会集中到极少数的几个计算节点上其他节点却处于空闲状态整个任务的执行时间被拖得很长甚至出现OOM。我遇到过一个比较典型的案例某个Flink实时统计任务按照广告位ID统计曝光、点击消耗任务总并行度设了48但是运行一段时间之后发现部分节点的CPU使用率接近100%其他节点只有不到5%。排查之后发现排名前几的广告位贡献了超过一半的流量而Flink默认的KeyBy策略是基于Key的哈希取模恰恰这些头部广告位被哈希到了同一个或少数几个子任务上。解决思路有几种。第一种是两阶段聚合Partial Aggregate Full Aggregate先在本地做一个预聚合来减轻Shuffle的压力再在网上把预聚合结果汇总。第二种是加盐Salting给热点Key加一个随机后缀把一条热点数据分散到多个Key上处理最后再合并。第三种是调整并行度分配策略把热点的Key单独识别出来分配更多的并行度。我觉得最值得说的反而不是技术方案本身而是如何快速定位数据倾斜。很多人在Flink的Web UI上看到一个任务运行很慢先去调并行度、调缓存但实际上先去看一下每个子任务的输入记录数和数据量会更快定位问题。如果各子任务之间的输入数据量差异超过一个数量级那大概率就是数据倾斜先做热点Key分析。5.2 时间窗口设计的想当然时刻窗口边界带来的统计误差时间窗口的问题在广告数据处理中非常隐蔽处理不好会导致统计口径偏差进而影响预算控制和效果评估。有一次我们做一个每小时广告消耗的实时统计任务用Flink的TumblingEventTimeWindows窗口大小设为一小时。结果上线后运营那边反馈每个整点时刻统计出来的消耗数据总会突然跳一下跟广告后台的实时消耗对不上。排查下来发现原因有两个。第一个原因是广告日志的事件时间戳是由媒体端SDK在客户端本地生成的当用户的手机时钟不准确或者SDK上报存在延迟时事件的真实发生时间和日志里记录的时间会有偏差。这时如果直接按事件时间划分窗口就会把本该属于上一个窗口的数据划到下一个窗口里去。第二个原因是日志从媒体端传到广告服务平台再到数据管道中间有几秒到几十秒的网络延迟如果窗口边界恰好在这个延迟时间附近边界处的数据归属就不稳定。这个问题的解法是一方面在窗口设计时加入一定的触发延迟和乱序容忍Flink里就是通过Watermark机制来实现的另一方面在窗口聚合之外额外维护一套基于处理时间的准实时统计用于快速响应运营查看需求而正式的、以事件时间为准的统计结果走延迟补数逻辑去修正。定期对账时用离线全量数据去校准实时统计的偏差把误差控制在一定范围内。5.3 跨渠道ID映射的数据孤儿问题程序化广告中用户在不同平台上的ID是不同的。同一个用户在广告交易平台里可能是一串设备ID在媒体的用户系统里是另一套用户ID在广告主自己的CRM系统里又是第三套ID。跨渠道的ID映射是广告数据处理的难点之一做得不好会产生大量的数据孤儿也就是那些只有一个渠道的ID、无法关联到这个用户在另一个渠道的数据。比如某个用户在广告平台上的设备ID是A但他在广告主App里注册的账号ID是B这两套ID在业务上是同一个实体。如果我们能把A和B关联起来那广告主就能做到把广告平台的曝光数据与站内的转化数据打通甚至可以做人群包的回传和lookalike扩充。但实际情况下由于用户会换设备、清Cookie、使用多设备ID映射关系的建立和维护非常困难。处理ID映射问题我建议采用图计算的思路来建立ID之间的关联而不是简单的一对一映射。你可以把每个ID当成一个节点把同一设备上同时出现或同一用户的注册行为关联当成一条边然后用连通图算法去把属于同一个用户的所有ID聚成一个簇。这种方案在初期数据量不大的时候可以用Spark GraphX跑批处理后面数据量上来之后可以引入图数据库来服务实时查询。这个问题的复杂性在于ID映射的逻辑会直接影响广告定向和频次控制的准确性映射错了轻则给用户推了不相关的广告重则打乱整个频控策略导致预算浪费。所以ID映射的每一次修改都要有完整的验证流程对比修改前后的数据分布变化确保不会引入严重的关联误差。5.4 调试实时任务时容易忽视的Checkpoint细节Flink的Checkpoint机制是实时任务数据一致性的基础保障但很多人在开发调试的时候会忽视它等到线上出问题才重视。我见过好几个团队在开发环境测试实时任务的时候直接把Checkpoint功能关掉觉得单机调试不需要结果任务上线之后遇到一次节点故障状态丢失统计数据从故障时间点开始全部归零给业务侧造成了不小的混乱。关于Checkpoint我有几个经验分享给读者。首先Checkpoint的间隔不要太短也不要太长太短会增加状态存储的写入压力太长会导致故障恢复时间过长。我一般建议设置成10秒到30秒之间具体看状态大小和业务对恢复时效的要求。其次要监控Checkpoint的成功率和完成时间。如果成功率持续下降或者完成时间接近间隔时间说明状态后端或存储系统存在瓶颈需要及时处理。再次状态后端的选择要结合场景RocksDB适合大状态场景但如果状态不是特别大FsStateBackend配合内存模式反而性能更好。6. 让数据说话从处理好的数据到业务优化决策6.1 广告漏斗分析从曝光到转化的数据追踪链路数据处理的工作不是数据清洗完就结束了最终的目标还是要落回业务优化上。广告漏斗是衡量投放效果的基础框架在程序化广告场景里漏斗通常包括请求、竞价、曝光、点击、转化这几个关键节点。数据处理的挑战在于一个用户从看到广告到完成转化时间跨度可能从几分钟到几周不等要把这些分散在不同时间段的数据串联起来形成一个完整的转化路径。我一般会建立一个统一的漏斗分析模型把所有关键事件以用户ID设备ID为主键串联起来然后通过时间窗口的设定来划分转化归因窗口。比如电商行业的广告主一般把点击后7天内的转化都算作广告带来的转化而游戏行业可能看的是点击后30天内的激活。归因窗口不同统计出来的ROI就完全不同所以这个窗口的设定一定要跟广告主确认清楚。漏斗分析中最常见的问题是多触点归因。用户可能先在一个App上看到了广告没有点击后来在另一个App上又看到了同一个广告点击之后才完成转化。那这次转化应该归因给哪个渠道要注意各个平台采用主流的归因方式不一样有的采用末次点击归因有的采用首次点击归因有的用线性归因。数据处理工程师需要跟投放优化师明确当前业务的归因模型用的是哪一种然后把原始曝光、点击数据按照归因逻辑重新组织和计算。这个环节如果没做好后面所有的效果分析和预算分配决策都是建立在错误的数据基础上。6.2 频次控制和预算消耗监控实时数据处理的高价值应用程序化广告的一个核心指标是频次控制Frequency Capping也就是限制同一个用户在单位时间内看到同一条广告的最大次数。频次控制如果做得不好用户会反复看到同一个广告产生厌烦情绪广告主也会觉得投放效率低。频次控制的实时性要求很高因为从用户看到第一条广告到决定是否给他展示第二条广告中间只隔了毫秒级的竞价决策时间。实现频次控制的技术思路通常是在广告请求进来的时候以用户ID为Key去KV存储里查询该用户近期的广告曝光记录如果曝光次数达到上限就放弃竞价或者降低出价。这个查询必须非常快所以KV存储的选型和数据结构的优化就变得很关键。我遇到的比较棘手的问题是同一个用户短时间内产生了大量曝光记录KV存储里存储的集合越来越大查询性能急剧下降。后来我们把曝光记录按照小时切成多个小Key来存储查询的时候并行读取最近N个小时的小Key聚合结果性能问题才得到缓解。预算消耗监控也是实时数据处理的典型应用。广告主的消耗预算在竞价过程中是实时扣减的所以我们需要一个秒级甚至毫秒级更新的消耗统计服务。当一条投放计划的实时消耗接近预算上限时系统要自动降低出价或者暂停竞价避免超跑。这套逻辑对数据的准确性要求很高如果消耗统计延迟了就会导致预算已经超跑还在继续竞价最后广告主那边对账就会出问题。6.3 异常流量识别用数据手段给广告业务体检异常流量Invalid Traffic, IVT是程序化广告行业绕不开的话题也是最考验数据处理能力的场景之一。异常流量的常见形态包括机器刷量用脚本或模拟器批量产生曝光和点击、广告位堆叠作弊把多个广告位叠在一起用户根本看不到但产生了曝光、恶意点击竞争对手反复点击广告以消耗广告主预算。异常流量识别的方法可以分成规则和模型两大类。规则层面可以设定各种硬性阈值比如单设备单日曝光超过某个量级就触发告警、点击率异常偏高比如超过5%触发审查、同一IP下设备数量异常集中等。模型层面可以用监督学习训练一个异常流量分类器输入特征包括设备行为序列、请求频次分布、点击时间间隔分布、停留时长等。不过考虑到异常流量的形态是在不断演化的单纯依靠模型也会滞后所以更常见的做法是规则与模型并行用规则实时拦截一些明显异常用模型离线识别一些隐蔽模式。在数据处理层面要做好做异常流量识别最重要的是保留足够细粒度的原始日志。有的团队为了节省存储空间在日志接入阶段就把原始日志做粗粒度的聚合比如只保留每个设备每天的总曝光量那后面做异常分析时就没有数据了。我的意见是原始日志至少保留30天以上虽然存储成本会增加但在反作弊分析、数据排查、模型训练这些场景里这些原始数据是无价的。7. 技术之外程序化广告数据处理中的团队协作与流程规范数据处理从来不只是技术问题很大程度上还牵扯到跨团队协作的顺畅度。在程序化广告公司里数据团队需要跟商务团队、投放优化师、产品经理、算法工程师密切配合而这些人对数据的诉求往往是不同的。商务团队想知道的是这个渠道的流量质量怎么样广告主的预算有没有被浪费投放优化师想知道的是哪些素材在哪些广告位上效果好好决定下一步怎么调整预算结构算法工程师想知道的是训练样本的数据分布稳不稳定特征是否有效。数据团队的核心价值之一就是把这几个角色的数据诉求整合起来提供统一、可靠的数据输出。我这边比较强调数据口径的统一。同样一个指标在商务那边叫消耗在投放优化师那边叫花费在算法那边叫计费金额如果不把口径对齐各部门聊起来都是鸡同鸭讲。建议的做法是建立一个指标字典把所有核心指标的定义、来源、计算逻辑、使用场景都记录下来这算是数据治理的基础工作。流程规范方面我特别想提的一点是数据变更管理。广告行业的数据处理链路涉及的表结构、任务、口径非常之多经常会有小改动但一个小小的改动也可能引发连锁反应。比如统计报表里的曝光量字段定义从媒体的曝光回执数量调整为广告服务端确认的有效曝光数量看起来只是口径的细化但其实会导致所有下游报表、投放策略判断、广告主对账都会发生变化。如果这个改动没有经过变更评审、影响面分析、回滚预案这些流程直接改了代码就上线很容易出事故。所以不管团队规模大小数据变更管理一定要做起来。8. 后续可以往哪个方向继续深挖这个话题的内容量其实还很大这篇文章主要把程序化广告的数据处理链路和核心技巧的整体框架盘了一遍。后续可以深入的方向我简单列一下给对这块感兴趣的朋友做个参考。第一个方向是实时特征平台的建设。广告模型的特征除了离线批量生成之外越来越多的场景需要实时特征。比如用户在当前页面的停留时长、最近几分钟的浏览序列这些特征的实时性对预估模型的效果有明显提升。怎么构建一套支持毫秒级特征查询、秒级特征更新的实时特征平台是一个非常有意思的工程问题。第二个方向是数据质量控制与数据血缘追踪。广告数据链路长、环节多一个数据质量问题可能隐藏在很深的层次。构建一套完善的数据血缘系统让每张报表、每个模型特征都能追溯到原始日志在排查问题时能节省大量时间。第三个方向是隐私计算与数据安全的合规落地。广告行业对用户隐私的保护要求越来越严格如何在不过度采集用户数据的前提下依然能做好广告定向和效果衡量是一个非常有挑战的数据处理问题。联邦学习、差分隐私、同态加密这些技术在实际广告场景里的落地值得持续关注。程序化广告是一个把数据处理技术用到极致、逼到极致的行业。在这里你会发现同样的数据量放在传统行业里可能用最朴素的手段就能处理但在广告场景下必须要考虑毫秒级延迟、极高的吞吐要求、复杂的实时状态管理和严格的数据准确性。正因为如此从广告行业里学到的数据处理技巧换到其他任何有海量数据和高实时性要求的行业都会有很强的迁移价值。
