美团 数据实时化是广告行业数仓建设的主流趋势

内容摘要

数据实时化是数仓建设的趋势，相对于离线数仓，实时数仓能够给管理者、业务分析人员提供反应业务变化的实时数据，监控收入等关键指标的波动，及时根据市场热点变化调整运营策略，通过实时算法决策，提供更加满足用户需要的服务。

本次分享的实时数仓建设实践，主要包括：

• 互联网广告业务介绍；
• 实时数仓模型、指标的建设规范；
• 实时数仓开发技术；
• 全链路的质量保障方案；
• 实时数据在广告场景下的应用。

1. 什么是广告实时数据？

在互联网广告业务中，参与方主要包括三方：广告平台（主要是各大互联网公司的一些广告平台）、C端用户、B端广告主。

其中，互联网广告业务更偏B端，而B端广告主向广告平台提出自己的营销诉求，并且设计投放，把自己的广告展示在各种C端产品上，然后在C端用户点击各种产品、商品、服务之后，把B端广告主的一些服务触达到C端客户，进而完成一些营销诉求。

在互联网广告行业中，C端目前主要包括APP端、小程序端、PC端以及其他端。目前，移动互联网APP端占了营销的绝大部分比例。有数据统计：在移动互联网APP端，广告收入占到89%，小程序、PC等各端基本上只占了10%左右的收入水平。

而在早期互联网阶段，PC互联网行业广告收入占比更大一些，广告平台主要有如下几大系统：

• CRM系统，主要做客户关系管理，也就是对广告主进行管理。
• 投放系统，把广告主的广告、素材、营销诉求投放在各个C端，之后有一些计费系统，对广告主投放的广告进行实时计费。目前，行业内比较多的是OCPX广告。
• 运营系统，主要是在广告投放完之后，内部一些运营销售人员对广告投放效果进行运营分析、对广告主流程运营工作。
• 财务系统，主要是通过广告计费系统和公司财务结算考核系统进行对接。
• 营销系统，主要是创意制作平台以及广告主通过这些创意来制作自己的广告。

对于广告主而言，主要营销诉求，除了展示广告，更看重营销效果，比如：通过一些商品和服务售卖、转化情况，来衡量自己的广告投放效果。

具体来说，对于互联网广告行业而言，实时数据的应用价值包括三块：

第一，实时数据可视化：
和离线数据可视化比较类似，实时数据可视化，是指通过KPI实时看板查看数据，可视化核心点是可视化KPI实时数据，算法团队包括CTR、CPR数据。

广告投放看板，面向B端广告主，广告主也要知道自己投放广告的效果，尤其像6.18、双11、双12这些互联网电商节，他们需要评估自己投放广告的效果，了解投放广告之后客流转化情况，以便及时调整预算，进行营销策略优化。

第二，监控和诊断：
首先，实时数据KPI监控要求与离线数据不同。一些离线数据的监控基本是T+1，所有广告投放效果都需要等到一天后才能够获得，但是实时数据更强调实时。

另外，异常分析能力要更强。当一般结果符合预期时，是大家比较希望看到的。当结果不太符合预期时，比如上了一个算法，但是预期收入是上涨的，但实际收入可能持平，甚至可能下降，这种情况下，就知道存在一些异常，针对异常就需要进行一些诊断和分析。

通过诊断和分析能够尽快止损，避免有问题的策略和营销方式、手段在线上存在。不仅对广告平台如此，对广告主而言也依然如此。通过实时监控和诊断，广告主可以更快速地了解自己投放策略的效果，尤其相对大的品牌广告主而言，实时化需求更强烈。比如：联合利华、宝洁这些公司营销团队，都会有专门的广告投放部门，都会分析自己的实时投放效果，来进行实时策略的优化，避免自己营销预算浪费。

第三，算法智能决策：

问题是，没有专业营销团队的广告主，应该怎么办呢？

目前，互联网广告行业除了大的头部广告主，比如宝洁、联合利华、可口可乐这些公司，有专业的广告投放营销策略团队，有广告投放制作和优化能力，大量中小行业的广告主没有自己的营销团队，比如：一些街边摊或路边餐饮店，在投放策略优化和创意制作能力方面比较弱，需要依赖广告平台提供的实时服务为业务赋能，比如：通过实时的智能的出价优化、创意制作、创意优化能力，提升广告主在广告平台操作体验，获得更好的效果。

实时数据相对离线数据而言，时效性肯定更强，能够帮助平台和广告主更快地感知到实时数据的效果和策略的效果，来进行快速止损以及获得更大的业务机会。

2. 实时数仓开发规范有哪些？

2.1 实时数仓分层规范

离线数仓一般会分DWS、DWD、DIM层，实时数仓依然需要分这几层，是和离线数仓原因一样，通过分层来实现指标口径的统一、计算效率提升。

实时数仓分层相对离线数仓而言，主要是业务系统的原始数据，ODS层包括埋点日志，包括业务系统记录日志，包括订单记录，通过MySQL binlog产生。

DWD实施明细层，主要对原始数据进行数据清洗和过滤，还有关联和维度扩展，包括数据去重处理等。

DWS层，主要进行轻度汇总宽表，这一块分层核心价值体现是，主要提高数据易用性和指标一致性。

DIM实时维表，离线数据维表基本上都是取的一天全量的状态，甚至很多时候取的是当天最后一次状态，比如：投放过程中间，投放有暂停、开启、每天投放还可能会设置不同的出价，对于离线维表时，每一个投放只有一个唯一的出价、创意和状态；对实时维表，能反映当天投放实时出价情况、创意情况以及状态情况，有暂停状态还是开启状态。经常在发现实时数据和离线数据不一致的地方，很多情况下都是因为维度状态变化导致的，比如：一个投放，当天看来是在离线时最后一次是暂停的，但是在实时时，可能今天开启了3次，暂停了4次，最后变成了暂停。如果计算过程中取投放的在线状态，可能在离线时这个投放就不是一个在线状态，导致消耗等核心指标计算的缺失，但在实时时，因为是实时的状态，投放一些消耗数据就不会出现丢失的情况。

而在APP上层一些产品应用端，就需要根据各个数据产品的需要来加工出各种应用的数据。

2.2 实时数仓开发技术

在ODS层，主要包括Kafka和Binlog。Kafka主要存放用户行为日志实时流；Binlog存储业务系统数据库记录实时流，包括投放状态，投放计费信息。

DW数仓模型层，核心技术主要包括Flink，支持状态和SQL方式开发的高性能实时计算引擎，早期实时数据计算方式主要采用 Storm，原生版本不太支持SQL计算，开发效率和开发复杂度相对比较高，但是FLink除了底层支持一些API方式开发，还能在高层能够支持SQL的开发方式。换言之，实时数仓开发方式和离线开发方式比较接近，能支持更高效的开发，而且对于数据逻辑的开发和维护相对来说比以前Java、API开发方式更为高效，任务管理方式也变得更加高效。Tair，是美团内部用来存储海量数据的KV引擎，在实时数仓开发过程中，利用Tair，建设一些实时维表，实时维表和离线维表具有比较大的差异性。

APP应用层，主要是Doris和Blade。Doris是一些海量数据中低性能查询的OLAP引擎，在实际测试过程中，当数据量比较大，比如：每天数据量在千万级甚至超过亿级时，OLAP产品性能只能达到QPS在100以内，与Doris查询引擎的查询计算方式有关，里面存在非常多的线程抢占，任务计算时会有非常多计算资源抢占行为。Blade是海量数据高性能查询的HTAP引擎，是美团内部进行自研并且非常多改造的产品引擎，这个产品引擎因为是分布式的，而且数据量非常大，对于我们目前数据服务而言，我们在广告数据服务基于Blade数据存储规模超过百T，基本是数据量非常大的情况，很多数据都是超过百亿级。

实时数仓开发技术相对离线数仓而言，数据用的技术相对比较多一些，对于离线数仓开发时，技术早期主要是Hive存储引擎、计算引擎，后来因为计算性能提升的动作，大家可能会引用一些Spark产品引擎。但是在实时数仓过程中，存储可能用了Kafka，甚至Tair这样一些存储引擎，但是在计算层面，除了用Flink，很多公司依然会存在一些别的计算引擎，比如：Storm支持SQL的版本。在应用端，应用层数据很多时依然会选用Doris、Blade等。

我们把实时数仓规范的设计和概念，与实时数仓的一些实现进行分离，我们不认为所有的实时数仓都基于Kafka，实时数仓有一些存储和计算可以用不同的技术和方案实现。

2.3 实时数据开发的质量保障

如何保证实时数据开发质量？主要包括事前预防、事中测试、事后监控！

2.3.1 如何理解事前预防？

在开发规范设计时，首先要进行技术选型，包括实时数仓分层、命名规范。

同时，还涉及运维规范，主要包括任务分级，以及不同分级情况下的故障处理方式、流程、报点机制等。

另外，还有模型对齐，指在开发实时数据过程中，实时数据和离线数据的对齐。实时数仓和离线数仓建设过程中间，受制于计算方式不同，以及数据的实时性不同，经常出现适时数据和离线数据不一致的问题。从两组模型差距来看，各自数据都是准确的，只是因为数据实时行不通，导致有一点差异。所以在事前做技术方案时就要确定在事实时据和离线数据的对齐方式和差异的合理性。

2.3.2 什么是事中测试？

开发测试，需要实时数仓建设非常多的测试运力，来覆盖各种可能出错的场景，在上线前把一些未知问题尽量避免。尤其像广告数据，因为面向广告主，有很多实时数据需要提供给广告主，广告主投放广告之后需要知道效果，这个数据要准确，否则影响到广告主广告投放数据的优化，我们需要通过测试保证数据异常能够尽量在上线之前避免。

主备链路，主备链路最好能进行物理隔离，当遇到机房故障、设备物理故障时，直接能够把数据切到备份链路，包括线上实时数据的稳定性。

峰值压测，随着业务量，比如双11秒杀等活动，会遇到流量突增情况，对于这种场景，需要保证业务稳定性时，还需要对链路峰值处理能力进行压测，保证6.18、双11时能够平稳渡过一些高峰时间，保证数据稳定性。

2.3.3 为什么要做事后监控？

分级运维，对于P0级任务就需要测定一些故障响应时间，如报警机制、值班机制，包括数据延迟监控，不同优先级任务延迟可接受范围不一样，面向广告主数据或KPI看板数据，会有一些延迟，比如5分钟以内。

数据监控，是指是否存在数据异常下跌或掉零、突增等情况，这种数据本身可能不是因为实时数据开发过程引入的，是业务过程引入的，比如C端一些入口倍增或突发事件、业务变动导致异常上升下降，或发板导致数据出不来等问题，通过实时数据能舰空导这些异常数据指标的波动，及时感知到业务的问题，也是实时数据在止损方面一些突出的价值。

2.4 实时数据指标的开发流程

一般在实时数据开发过程中，会先确定一些实时数据的口径、定义，经过技术方案评审、代码开发、数据逻辑测试、性能压测，质量保障监控等方案，最终上线。覆盖了刚刚提到的事前、事中和事后的过程。其中，数据技术方案是比较核心的部分。

数据技术方案主要包括：

• 模型规范，比如模型分层方式是什么样的；
• 指标规范，比如指标怎么样和离线进行对齐、指标命名方式、指标定义方式；

存储和计算引擎的选择，比如存储，在应用层是选择Blade还是Doris、ES、Flink等，目前主流应该都是用Flink。Flink+Kafka计算方式依然会出现一些问题，比如Kafka数据其实不太好查，数据开发过程中间，对于测试环节相对复杂，因为Kafka数据不查，要把Kafka数据导出到Hive等可查的一些查询介质上才能进行开发测试；

质量保障，包括核心指标异常波动范围，比如收入可能波动10%~20%就是比较异常，对应异常需要识别出来，并且监控出来，让问题能够及时感知到，进行止损。

3. 在广告实时数据开发实践过程中有哪些关键点？

3.1 实时任务

在美团内部自建了一个实时数仓开发平台，能进行实时数仓任务开发，能够进行代码的编辑、作业的管理、模型的管理，以及实时数仓函数的管理。

除了代码和任务管理之外，这个平台也能够进行实时数仓任务的调试、校验，还能进行一些作业运维能力，包括任务重启、下线，以及任务参数，比如并发度、内存等参数的调整，这个平台也能进行作业版本的管理等。

3.2 数据血缘

任务血缘管理，除了任务本身作业代码以及运维能力之外，还能够在平台上看到任务血缘，包括这个任务上游接的是哪些维表，接了哪些计算任务和计算模型，以及它的下游导出到哪些存储引擎上，并且这个模型涉及一层血缘、二层血缘和三层血缘等，以及数据存储格式，到底是Json格式还是其他格式。

3.3 数据可视化

绝大部分数据开发工作都是直接面向数据可视化的，在离线要建设各种各样的一些数据看板，以及自助分析工具、自助看板工具等，在实时数仓开发过程中也一样，也需要进行一些数据可视化，相对于离线数仓而言，实时数仓可能有一个显著特点，数据维度比离线更细，实时数据维度或数据时间序列维度基本上都是到分钟级，对离线数仓而言数据维度很可能是天级，最多可能就是小时级。

比如：在CPM热实时场景，包括一些数据级命名规范，有热实时、热离线、冷实时、冷离线等，热实时上可以看到实时数据CPM的曝光消耗基本会存在早上11点是高峰，以及下午5~6点左右是高峰的场景，可能早上高峰更多一些。

3.4 流量异动监控

对比有效曝光，今天数据、昨天数据和历史数据，从昨天和历史数据来看，在11~12点之间相对比较平稳的波动，但是今天数据会存在异常的上升，这个地方肯定就会存在一些问题。问题可能原因是，异常活动输入，某一个活动导致流量突然上升，还有可能是平台工具稳定性导致的，比如数据重复发生，或者重发，所以在DWD层需要进行一些实时数据的去重，因为离线去重相对比较简单，实时数据的去重就需要我们进行前期的去重，避免平台稳定性导致数据重发，导致数据计算指标的异常。

如果这个数据因为平台稳定性导致数据重发，不在计算过程中间处理这个问题，这个数据就会暴露给KPI的核心监控看板以及广告主实时数据感知，他们感觉到自己曝光突然莫名其妙上升，会导致CPM异常下降，如果这个数据不加判断就使用的话，当前拿到广告价格好像下降了，是否可以加大投入。事实上，是因为我们数据错误，如果因为这种原因导致决策成本和沉默成本等投入，就会出现广告主和平台扯皮，甚至会引起后续大量的客诉风险。所以，核心数据的监控是非常有必要的，因为很多问题可能在制度设计方案层面不一定能完全考虑到。

3.5 消耗异动诊断

可以让异常数据诊断变得更加实时，能够及时止损，带来一些成本和消耗的减少，让整个业务变得更加平稳。

例如，美团内部有一个系统能够检测到消耗数据的异常下降，并且能够基于消耗数据的下降来进行实时诊断。

广告决策和效果都非常依赖于数据，而且这些数据能够进行非常好的指标拆分，比如广告这边有一块计算广告学，主要是解释一些广告指标的拆分方式和实现原理。如消耗指标=点击×acp，点击=曝光×ctr×acp，看每一个指标对于异常下降贡献率。如图，曝光的下降，点击也会下降，点击下降，平台召回的pv也会下降，一般越是靠近整个广告链路上游，指标的波动对整个影响贡献是越大的。对于这种情况来说，整个消耗下降主要来自于召回pv的下降，就需要排查召回的系统，为什么召回的广告变少了。这是一个可视化的展示异常诊断的过程，实际系统中间，会建设一些指标贡献度的情况，会通过系统，根据一些指标的拆解以及指标贡献度，能够自动去提示和诊断出一些消耗等核心指标波动的原因，加快异常诊断的速度。

3.6 智能调价

实时数据核心价值和能力还包括智能调价，如互联网广告行业，很多广告主其实不能像可口可乐或宝洁、联合利华等广告主一样有自己的营销团队和广告投放团队，而且这个团队非常专业，基本上会从各个广告平台去拿到自己的数据来进行自己策略的分析和投放的优化。

现在头部广告平台基本上广告主规模都是在几十万的水平。问题是，这些广告主有多少是宝洁和可口可乐这种大的广告主？事实上，绝大部分都是一些中小广告主，可能大家对中小广告主的定义不同，有些公司中小广告主规模是每天消耗在几千元左右，有些公司可能在几百元左右，这些小广告主没有自己专业的营销团队。

对广告平台而言，不能只是说收广告主的一些钱，依然要代表广告主的利益，帮广告主去实时优化自己投放的效果，但是因为广告平台面对的是几十万相对来说海量的广告主，不可能为每一个广告主进行实时策略的优化，不可能靠人工方式去做，所以需要在综合评估整个平台的生态以及广告主利益情况下，动态调整广告投放策略。一个广告平台广告主量非常大，大家通过计价方式，对于平台而言，大家出的价格肯定越高越好，但是对于整个生态而言并不是如此，我们需要代表广告主的利益，要让广告主出相对合理的价格拿到更有价值的量，核心部分就是出价。

曾经，某公司的一些竞价排名策略在整个行业里深入人心，现在很多广告主非常能够接受这种竞价排名方式，但是有很多中小广告主其实没办法全天候盯着广告的出价，所以平台就能够利用一些实的数据，比如今天流量的消耗情况，以及大家出价情况、竞争激烈程度等，来进行一些智能调价。智能调价的核心包括出了什么价，预估能拿到多少量，多少转化效果，这是比较核心的能力。所以对于广告平台而言，实时数据非常有应用价值的场景就是能够帮广告主进行智能调价，节省广告预算成本，提升效果，让整个生态和广告主体验变得更好。

4. 未来何去何从？

如前文所述，在广告实时数仓开发技术规范和方案时提到，一些当前实时数仓建设方案的问题，目前各公司在实时数仓建设方式主要采用的是Lambda架构，其显著问题是实时数据和离线数据是分开建设的。面临非常大的问题就是实时数据和离线数据不统一，计算逻辑两套代码逻辑维护，包括Kafka里数据不可查，以及开发测试运维成本投入较大的情况。当然，也有提出Kappa架构，所有数据都实时化，开发运维成本也相对比较高。

基于这些运维成本的问题，目前各大互联网公司基本探索的方式，主要是通过流批一体方式，可采用的架构主要是Lambda+Hudi等计算方式。实时数仓流批一体架构目前并没有得到广泛应用，有些公司有一些尝试，大家希望能通过流批一体解决的问题包括能够统一计算、统一存储，这样的方式可以让整个开发和测试能够进行提效，尤其是Kafka的数据不可实时可查，测试过程相对比较麻烦。最大一个好处和应用价值是指标的一致性，避免维护、实时离线两套逻辑，开发过程和运维成本能够相对降低。

原文:数据实时化是广告行业数仓建设的主流趋势