注：本文为「Flink Forward Asia 2024」演讲实录 本文基于阿里妈妈广告业务背景，分享阿里妈妈广告实时系统和数据湖架构的设计方案以及技术和业务层面从该架构中获得的收益。
一、业务背景 1.1 阿里妈妈广告业务介绍 阿里妈妈是淘天集团商业数智营销中台，管理并运营淘天集团搜索、展示、信息流等多种消费场景下的营销产品及技术解决方案、覆盖互联网主流APP全域营销资源。
广告生态系统的运行基于多方协同机制，广告主作为资金主体通过需求方平台(DSP)进行广告活动的创建与配置，涵盖目标受众定向、地域时段选择、预算分配等核心参数。广告主会选择合适的素材和创意，以吸引用户点击广告，实现广告投放目标。当所有信息在DSP平台上设置完成后，这些信息会同步到广告投放引擎中。
投放引擎的核心功能在于用户流量处理，流量源涵盖阿里系应用(淘宝、天猫、高德等)及外部媒体生态(字节、快手、知乎等)。引擎会根据用户在淘内的兴趣等属性实现精准广告分发。典型场景包括淘宝搜索广告推荐及信息流广告展示。
用户的搜索或浏览行为，会产生广告曝光数据。当用户点击广告时，会产生点击数据。在电商场景中，点击广告并非最终目的，我们还需要引导用户进行收藏、加购、下单等操作。用户点击广告后，会进入广告主的商详页或店铺页进行相应转化操作。我们将收集到的转化信息（如收藏、加购、成交等），进一步做转化归因分析用于评估广告效果。业界常见的归因模型包括线性、末次触点、首次触点、U型、MTA等模型。所有数据评估完成后，分析结果将同步至广告运营团队及合作媒体，以支撑后续的投放策略优化工作。
在广告生态系统中，通常广告的计费依赖曝光/点击行为，曝光和点击的追踪过程可能会受到黑产攻击，导致平台或广告主的财产损失。为了保护平台和客户等各方利益，我们还需要搭建广告反作弊体系，包含实时和离线的反作弊数据链路建设。同时，广告主设置的预算限制也不容忽视，广告支出如超出预算，广告主将不予认可。例如，如果广告主只愿意支付 100 元，实际广告投放却花费了 1 万元，那么超出部分广告主是不予承担的。因此，我们需建立精准的消耗预测模型与投放熔断机制，确保广告消耗严格遵循预设预算阈值。整个广告生态系统非常复杂，涉及链路很长，但数据必须准确且实时地反映给广告主，以便他们根据这些数据制定投放策略并调整预算。
1.2 阿里妈妈数据业务场景与诉求 结合广告业务背景，这里引出阿里妈妈数据业务场景和业务诉求。阿里妈妈SDS（Strategic Data Solutions）团队致力于用数据让商家和平台的增长战略更加科学有效。我们为阿里妈妈全线广告客户提供营销洞察、营销策略、价值量化及效果归因的技术服务。
业务场景 对外的实时报表 ：广告主需要查看各种维度的实时数据，例如曝光量、点击率CTR、转化率ROI等，以便实时了解广告的效果、预算是否需要增加或停投。对内实时分析需求 ：内部运营人员等需要对广告投放进行评估，对特定的人群、商品、场景等进行各种分析，查看广告投放后的人群效果、地域投放情况以及是否存在其他问题。因此，内部也需要实时和离线的分析。业务盯盘 ：对于一些关键的大促销活动节点，例如618、双十一、双十二大促活动时段，我们需要密切关注业务变化。包括流量是否达标、预算是否充足以及效果是否理想等，并依据实时数据灵活调整运营和投放策略。业务诉求 灵活多变 ：阿里妈妈SDS对接的下游业务众多，每个出口都有其特定需求，变化迅速且迭代频繁。稳定可靠 ：整个系统需要实时数据供多人查看，不能出现任何中断或数据更新延迟。延迟后广告主会立即发现并提出投诉或停投，这可能导致严重问题，比如15分钟内就登上热搜。数据一致性 ：对于广告主而言，他们可以在多个系统上查看数据，因此数据的一致性至关重要，否则他们可能会质疑数据的准确性。1.3 阿里妈妈数仓建设技术目标 数据时效性 ：从技术角度讲，广告主希望数据尽可能实时，理想情况下是及时无延迟，目前我们提供的保障是分钟级别的数据更新。系统吞吐量 ：阿里妈妈这边处理的流量非常庞大，日均规模达到千亿级别，TPS高达千万级，读写具备很大挑战。我们期望系统在特定场景下，如新业务上线后，能够迅速回放数据，将数据快速刷新至系统中，因此快速回放是一个基本要求。稳定可靠 ：系统可用性≥99.9%。故障快速恢复“止血”。支持灰度发布，故障或问题往往发生在发布或变更时，因此灰度发布能力至关重要，灰度发布过程出现问题，系统能够及时回滚，避免故障影响持续和扩大。成本效益 ：我们希望用尽可能少的资源支持更多的业务。同时也希望减轻开发和运维的负担，让更多人力能够从繁重的工作中解放出来，专注于更有意义的业务。二、架构设计 本章节分享我们的架构及其演进过程，下图是简化后的系统链路图（代号部分无需深入了解）。
2.1 为什么需要实时数仓？ 从图中可以看出，简化后的链路实际上也非常复杂。在最初构建实时系统时，我们的目标是速度，要求系统能够迅速覆盖业务需求。我们使用 Flink 进行数据消费，实时数据通过类似于Kafka的系统写入业务系统，使业务能够迅速启动。这是一种常见手段和方法，通过这张图，我们可以清晰地看到同一份数据如何在不同的业务系列中被展示。每一条链路代表一个业务逻辑，虽然它们共享一套代码和一系列作业，但解析和消费的数据却是相同的。
这虽然带来了一些明显的好处，但仍然存在以下问题：
需求灵活多变 ：在业务层面，随着业务种类的增加，每个环节都需要维护和开发，这在灵活性和效率上构成了重大挑战。开发成本 ：这种开发模式类似于烟囱式，缺乏复用性，导致了重复劳动。资源浪费 ：所有数据都需要解析和消费，这实际上造成了资源的浪费，因为有些数据可能根本用不上，但仍然需要被解析和处理。数据口径 ：数据口径问题，如果在某个业务系统中忘记或未能及时更新数据口径，那么输出的数据就会出现问题。运维成本 ：运维方面，所有任务都需要我们自己完成，包括压力测试、性能调优和问题排查等，这些都需要投入大量时间和成本。针对上诉存在的问题，我们提出了两个解决方案。
2.2 阿里妈妈实时数仓方案演进 2.2.1 基于TT的实时数仓方案 数仓分层 基于TT（类似于Kafka一样的消息队列）的实时数仓方案，实时数仓包含ODS、DWD和在线维表。
ODS层 ：业务所需日志，包括用户行为日志、广告日志，以及业务数据库中的转化消息、收藏、下单和成交等消息，都通过日志采集/DRC系统，将数据采集到TT中，作为实时系统ODS层数据。DWD层 ：在实时链路中，系统利用Flink来消费TT数据并加工出DWD层数据。在线维表 ：ODS层可能会缺少一些常用的维度字段，这些字段的更新频率可能并不高，通常是按天更新。为此，我们设计了维表系统（iGraph）用以补充这些维度字段。同时，我们也会使用配置系统（diamond）补充部分信息，这些信息相当于维表信息，用于补充到DWD层。方案弊端 数据重复 ：在下游消费DWD层数据时，大家可能会注意到ODS、DWD的作业，因为业务迭代或作业Failover会导致数据重复。在DWD层，是否需要去重取决于业务需求，但大多数情况下，去重是必要的，因为不去重会导致数据重复出现，比如广告主会立即注意到数据同比突然增长，从而引发投诉。DWS层缺失 ：另一个问题是，从DWD层到应用层之间，可以增加一个DWS层，因为下层的聚合逻辑往往是相同的。但在TT中，由于不具备upsert能力，因此无法将 DWS层的最新聚合结果覆盖更早的聚合结果。举个例子，假设时间窗口为5分钟，10:05聚合一条数据写入TT，10:10时第二次聚合数据需要覆盖上一次聚合结果，但在TT中会存在两条记录。下游接入TT后，需要自行执行一次数据去重，这代价极高。经过测试，资源消耗至少增加一倍，且数据量大导致作业不稳定。不设计DWS层，则直接将聚合结果写入下游的在线存储系统，包括OceanBase、Hologres和ClickHouse三种。实时链路旨在解决时效性问题，即使有实时反作弊机制，其精准度仍不足。此外，业务上还需处理去重逻辑。No Schema ：实际上在 DWD 和 ODS 的实时链路中，我们面临的是一个未结构化的数据问题。这些数据在解析后并没有一个固定的Schema，导致下游如算法和BI分析在使用这些数据时，不得不自行进行解析和计算，这无疑增加了成本并浪费了资源。资源与效率 ：对于广告主而言，自然希望数据既快速又准确。因此，我们还部署了一条离线链路，这也是一个典型的lambda架构。将ODS层的数据同步到MaxCompute中并通过ETL加工产出DWD层，聚合DWD为ADS层最终同步到在线存储系统。由于需要维护离线和实时两套代码，这无疑使得开发和运维资源都翻倍。2.2.2 基于Paimon的湖仓方案 那么，如何解决基于TT实时数仓面临的问题呢？幸运的是，2023年开始，我们关注到Paimon技术栈并展开调研，很快推进了Paimon技术并逐步在业务中推广应用。
? 方案优势 主键表 ：本方案中ODS层同前一个方案一致，也是基于TT存储且入湖过程完全相同。但DWD层将原有的存储替换成了Paimon，同时新增DWS层设计。Paimon具备upsert操作，支持DWD和DWS层upsert写入实现去重，下游消费changelog即可。Schema ：此外，这还带来了另一个好处。即之前提到的算法、BI以及各种运营需求的数据，现在可以直接在DWD和DWS层进行查询。过去，这需要我们提供支持，而现在，数据表已经解析完毕，数据也已就绪，可以直接使用实时和离线查询。开发效率 ：实时离线统一schema，无需再次解析开发和计算开销，实时离线代码可复用。关于离线链路，我们之前提到需要将数据同步至ODS这一步骤的原因何在呢？实际上，由于反作弊机制是基于离线处理的，它必须处理一批数据，这一步骤是不可或缺的。此外，这一流程还可作为备份（Backup）链路。在ODS层完成数据解析后，我们可以将数据反向写入到Paimon中。这样对于下游查询而言，它们能够查询到经过修正后的数据。如果存在修正结果，则查询修正后的数据；如果没有修正结果，则直接查询实时数据。整个流程完成后数据再同步到ClickHouse中，用于支持下游的高频查询。
2.2.3 阿里妈妈广告湖仓架构 目前的阿里妈妈广告湖仓架构如图所示，系统架构包含四个层次和一个运维平台。
数据层 ：数据的最初来源目前仍然在TT中，整个系统依赖于TT，所以这一部分保持不变。TT中包含了各种行为数据、广告数据以及成交转化等数据。业务数据库中的维表数据会增量同步到TT中。解析完这些增量同步的数据后，会将其写入iGraph中。TT数据则通过Flink进行 ETL 处理导入到我们的数据湖中，即 Paimon 表，包括DWD和DWS层。在这里有主备两套存储系统，双系统设计既用于异地灾备，也提供可用性和灰度发布能力。数据实时提供给消费者使用，而离线链路则有离线修正数据，这实际上是依赖于离线的另一条链路。这两套数据最终会合并在一起。计算层 ：所有的ETL过程，包括最终的数据写入存储，我们使用了Flink和MaxCompute计算引擎。存储层 ：配置主备两套系统，主备链路分别配置同步任务，确保主备同步的可靠性和独立性。阿里妈妈广告湖仓架构由三条数据处理链路组成：两条实时链路与一条离线链路。实时链路具备灵活切换能力，保障日常业务连续性；离线链路则承担双重角色：既作为实时系统的数据备份（预防实时处理系统故障），也承担大促活动的容灾保障。
我们针对不同查询场景采用分层处理机制。比如，高频万级TPS查询场景：部署ClickHouse列式数据库，通过索引优化和向量化计算实现高效分析；中小规模灵活查询场景：采用MaxCompute大数据平台，可支持小时级延迟的批量分析；探索性场景：正在验证StarRocks和Hologres在复杂点查场景的应用价值。上游应用主要包括报表、BI监控、算法以及实时和批量的数据洞察。为确保系统稳定性，我们还设计了保障体系，包括，业务级监控：实时追踪业务指标（包括组间延迟、异常检测等）；全链路监控：覆盖数据写入、传输消费、中间状态等关键节点；专项运维平台：包含实时作业管理平台和全链路压测平台，可模拟业务峰值压力，提前发现潜在瓶颈。
2.2.4 Paimon常见优化手段 本章节分享在构建湖仓时采用的一些常见优化策略，包括性能、存储、稳定性三个方向的优化。
性能优化 异步Compaction配置：使用情况启用异步 Compact 功能，这能显著提升系统的吞吐量，包括单表写入的吞吐量和稳定性。 调整Checkpoint interval time：根据流量规模动态调整Checkpoint间隔时长，高吞吐场景（百万级及以上）需增大间隔以避免频繁触发Checkpoint引发的资源竞争与反压问题。 资源分配策略：依据数据规模及Bucket数量配置Writer节点并行度，确保与存储分桶数匹配。针对大流量场景（如数据回溯），需预计算内存需求并动态调整资源分配。 表结构预规划：建表时需基于业务峰值评估分区策略与Bucket数量，后期调整分区或分桶需停止服务并触发Rescale流程（数据重分布），代价较高。 存储优化 文件生命周期管控：合理设置快照保留周期与变更日志过期策略，避免小文件过度累积。高并发写入场景需结合Compaction机制实现文件合并。 小文件合并机制：通过独立Compaction作业周期性合并小文件，降低查询延迟。当前社区持续迭代解决方案，建议关注版本更新。 废弃文件清理：针对作业异常产生的孤立文件，可调用社区工具链编写自动化清理脚本，并集成定时调度任务实现闭环管理。 稳定性优化 稳定性问题在流量大时尤为突出，可能会触发故障。例如，内存设置不合理或对流量峰值预估不足，都可能导致系统无法恢复。尽管我们设置了生命周期和快照文件的过期时间，但一旦它们过期，作业可能就无法恢复。
开启Comsumer ：为此，我们提供了 Consumer 的能力，可以将 Consumer ID 标记出来，使其在一定时间内或永远不过期，从而在作业失败后仍能恢复。需要注意的是，启用Consumer后，文件数量会随过期时间变长而增加。在追溯时，系统会逐个扫描Snapshot文件，最终追溯的数据量会增加，速度会变慢。调整TM资源 ：TM cpu/mem资源的调整应根据具体情况进行。Paimon团队提供一些经验公式，可以根据实际情况进行调整，例如根据一张表的更新频率、一条记录的大小以及Bucket的数量等，从而估算出内存需求。根据经验进行配置，特别要注意的是，使用过Paimon的用户应该熟悉它最后的 Commit节点。这个节点确保了数据最终一致性，因此在配置到这个节点资源时，如果分区数量众多，就需要适当增加 CPU 和内存资源，以保证系统运行更加流畅。这里分享一个优化例子，我们曾经完成了一个作业：一个小时写入了700+GB数据。根据这个作业，我们设置每个分区的bucket num为512，每小时一个分区。生命周期设置了7天，支持实时数据流读写。在这样的设置下，TPS（每秒事务数）可以达到五六百万。在开启异步处理之前，节点切换的平均耗时超过 50 秒，而开启后则缩短至 20 秒。 三、湖仓收益 全面升级后的数据湖仓为业务和技术层面均带来诸多收益。通过分层架构与模块化设计，下游迭代开发效率显著提升，基于Group By和Join操作的核心逻辑封装使交付周期缩短超30%。实时数据仓库中间层（DWD/DWS）的构建实现了业务洞察场景的分钟级响应，数据产出时效平均缩短2.5小时，有效支撑决策敏捷性。在运营层面，分钟级数据更新机制彻底改变了传统T+2的滞后模式，使预算投放效果可实时追踪，运营团队得以精准调控资源分配。
同时，通过消除冗余数据链路与重复消费场景大大节约了成本，整体计算资源消耗降低40%以上。而分层设计使业务逻辑开发工作量减少50%，显著提升了研发人效。架构中提到的主备双链路设计，满足了三个 9 的高可用性要求，即 99.9% 的运行时间，理论上一年365天停服时间计算下来不超过9小时，而实际运行中实现近乎零中断的稳定服务。此外，流处理作业的集约化改造不仅降低Flink集群资源占用，更减少了第三方数据订阅费用及日常运维复杂度，形成了可持续的技术成本优化闭环。
▐ 关于我们 阿里妈妈SDS（Strategic Data Solutions）团队致力于用数据让商家和平台的增长战略更加科学有效。我们为阿里妈妈全线广告客户提供营销洞察、营销策略、价值量化及效果归因的技术服务。我们将持续在数字营销领域MTA、MMM等方向进行探索和落地，欢迎各业务方关注与合作。同时，真诚欢迎感兴趣的同学和我们取得联系、互相交流。联系邮箱： alimama_tech@service.alibaba.com
? 阿里妈妈广告技术2026届春季实习生招聘火热启动！
