作者 | TWL

导读

离业务决策越近，高时效性数据带来的业务价值越大。实时计算过去面临最大的瓶颈是易用性问题，业务常常迫于迭代运维复杂度放弃实时化。我们基于多年深耕商业实时化场景的思考，提出RTS-场景化端到端全托管，彻底释放实时化的潜能。对大数据和实时化感兴趣的小伙伴们，欢迎交流探讨！

全文6411字，预计阅读时间17分钟。

01 业务背景

互联网红利殆尽，精益化运营成为主旋律。

众所周知，互联网红利殆尽，进入成熟阶段，各个公司都以精细化运营的方式来正面应对此情景。在互联网广告投放场景，广告运营的方式可以抽象为 “说对话，找对人，出对价”，精细化广告投放运营则在“出对价”上持续发力，也获得了最为立竿见影的广告投放效果。

在精细化运营的当下，对实时化的要求越来越高。

在早期的互联网广告投放场景中，广告主参与的广告展现拍卖一般采用的是竞价机制，即广告主的广告价格越高，其广告越容易胜出从而被网民看到。广告主设定广告点击价格，广告平台按照竞价排名进行展现，按照点击价格进行计费的模式称为按照点击计费（Cost Per Click CPC）。然而，CPC 计费模式严重依赖于关键词的出价。出价过低则无法胜出，广告无法展现；出价过高则会导致广告主的成本增高，利益受损。这一计费模式下“出对价”依赖于经验丰富的广告投放师。但是人工去频发的执行价格调整，以期望达到广告效果最优，是几乎不可能实现的。由于存在种种问题，单纯的 CPC 计费方式已经逐步退居幕后，取而代之的是 OCPC 计费方式。与 CPC 计费模式不同，OCPC 计费模式下广告主只控制转化成本，而非点击成本。“出对价”的“操作者”由广告主转变为了模型。广告平台会收集各个渠道的转化相关数据，并利用这些数据进行转化率模型的建模与训练。转化率模型直接调整线上广告出价，模型数据越实时，模型预测越准确，而转化率模型的准确性对广告主的目标成本达成至关重要。

02 技术背景

云计算以弹性提效率正蓬勃发展，但极致效率一定需要 SAAS 类产品。

当前 IAAS、PAAS 类产品种类丰富，我们可以很容易的在云上购买到诸如云数据库、消息队列、云存储等 PAAS 类产品，亦或者是计算容器、裸金属、云上虚拟机等 IAAS 类产品。这些云产品基于异构的普通服务器进行虚拟化，使得用户在无需关注底层物理机运维和集群管理的情况下，使用这些产品来进行自己业务服务的搭建。然而，要让客户能像搭积木一样轻松地构建业务，仅靠现有单独的云产品并不能满足商业数据实时处理的需求。业务同学通过若干云产品拼凑出的实时计算实践，无法取得极致的效率。这是因为与批量计算和在线服务均不同，实时计算存在以下三个突出诉求：

△云计算服务层级，来源：https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-iaas

• 稳定性就是时效性

实时计算解决的是秒级或者分钟级数据新鲜度的数据计算问题，在超高数据新鲜度的要求下，实时计算引擎的稳定性问题总是会转化为数据时效性问题。批量计算则用来处理一批数据，这批数据分布在较长时间段的范围内，它的典型的业务场景是历史数据的挖掘以及离线报表的计算。举例来说，一份天级别产出的客户报告，报告使用方要求在第二天早上8点之前生成。假设前一天数据就位时间为2点，报告处理时间为30分钟，则拥有长达5.5小时的错误冗余时间。我们再看一个实时计算的例子，一条实时数据流的 SLA 为最大延迟不超过 1小时，且延迟超过 20 分钟的持续时间不超过 1 小时。这就强烈要求实时计算引擎需要常态稳定，而且需要兼具高吞吐以追回被偶发打破的SLA。重要数据流要有高效的主备冗余方案。

• 非同质多级计算增加复杂度

复杂的在线检索系统，一般通过多层次多扇出满足复杂业务场景需求。一条PV（页面访问）可能会经过数百个服务的调用，这些服务大多拥有同质的大量的冗余实例，每次调用可以落在任何一个实例上，而且都允许 SLA 限制内的失败。实时计算通常也需要多级算子协同处理完业务逻辑。不同之处在于，算子服务内实例间并不是同质的，同时在商业场景下，业务几乎都是不重不丢（Exactly-Once）的语义要求。这样，多级算子之间会存在上下游数据依赖、数据倾斜、处理速度不匹配等等问题。实时计算更为复杂的是如何分级推全、回溯回滚，以及复杂拓扑下反压的定位止损。以转化数据为例，转化数据是广告主最关注的业务数据，直接关乎广告主广告投放的 ROI。转化数据也因此成为商业数据流中最有价值的数据，对转化数据的处理会经历线索收集、转化打点、归因拼接、反作弊处理、流式去重、业务打标、转化分发等多个阶段，任意阶段的数据处理异常都可能会造成脏数据下发或处理阻塞等问题，对于每一节点的数据业务逻辑迭代都需要进行通盘考虑，引入的错误甚至会波及整条数据流稳定性，并需要复杂的回溯回滚操作，期间一般会停止一切变更，显著的拖慢实时数据迭代效率。可以说，实时计算的复杂度很大程度上来自于多级计算。

• 数据流的“接口”频繁变更

如今的在线服务大多具有高内聚松耦合的特点，服务间的接口本身很少或几乎不发生变化，大多进行内部迭代升级。在线服务如果进行服务间接口变动，一般会经历复杂的测试联调，并通过小流量实验等方式进行谨慎的上线操作。在实时计算领域，数据 Schema 可以被看作是实时数据流各级算子间的“接口”。在线服务的接口变更频率极低，但是在实时计算数据流中，数据 Schema 经常需要添加新字段、新数据类型，以支持新的业务数据处理逻辑。数据 Schema 的变更风险极大，这是因为要考虑上下游变更一致性和顺序的要求，不一致的变更或者不合理的数据 Schema 变更顺序，都会引发各种数据断流问题，进而造成动辄几十万的收入损失。对于数据飞轮的当下，络绎不绝的数据需求与复杂的 Schema Change 流程成为了主要矛盾。

03 解决方案

为了便于读者理解我们的解决方案，我先抽象简要的介绍下商业化需要处理的数据，这对任何一个商业化场景都是适用的。按照当前对商业收入的贡献度，商业核心数据流有展现、点击、转化等数据流。我来分别阐述下这几种数据流的特点：

1.展现数据流应对于广告数据的检索日志，其数据体量是所有数据流中最大的。广告检索日志会记录广告展现样式、广告来源、广告渠道等信息，该数据字段有几千个，且经常会有数据字段的迭代需求。

2.点击日志则用于进行广告计费。新产品的上线根据不同点击数据的圈取对应不同的计费逻辑，点击数据直接影响到广告平台收入，有严格的不重不丢的需求。

3.转化数据上文略有提及，是最具商业价值的数据，来源于广告主的回传或托管落地页的采集。

这些数据对应于不同的商业业务场景，会经历不同的处理，我们以实时决策场景和转化业务场景来举例说明线上业务对实时数据流的应用。这些数据开发场景普遍需要低代码开发、实验、分级变更、回滚、回溯方案，也有自己独特的需求。

• 实时决策场景

实时决策是依赖多种数据流的复杂策略，每条数据流有大量的、特有的、频发变动的数据处理逻辑，决策策略一般依赖多条数据流的产出。因此，实时决策需要快速安全的端到端 Schema Change。

• 转化业务场景

转化业务数据采集涉及各个转化来源，而各广告主回传的转化数据质量参差不齐，因此在转化数据处理阶段，需要对数据标记和去重，且逻辑变更频繁。转化数据直接关乎广告主广告投放的 ROI，需要主备方案。

RTS（Real Time Stream） 是商业实时数据处理平台，旨在为商业业务同学提供完全 SAAS 化的实时数据处理开发体验，快速构建数据飞轮。唯有通过场景化，端到端地托管整个研发部署运维流程，才能实现实时计算的极致效率。在 RTS 上，针对不同的商业数据业务开发场景，我们抽象了对应的场景化开发模式。平台用户唯一需要关注的是如何用 SQL 以及 UDF 表达自己的业务逻辑，用户完成业务逻辑表达后，平台会触发 CICD 流水线，构建最佳 Topo 的流式作业，部署实验，一键推全，并支持线上运维。同时，平台会采集元数据和生成数据血缘，这样在流水线时，可以用数据切片自动对比，确认变更符合预期，大幅降低了数据变更的测试成本和风险。

RTS 平台的架构图如下所示：

△RTS 架构

3.1 商业数据开发场景化

3.1.1 实时决策场景

RTS 平台高效支持数据流的“接口”频繁变更。

接下来我们以上面提及的实时决策的案例来展示我们是如何抽象场景化的最佳实践。

业务同学购买了云存储、云数仓、裸金属、弹性容器等云产品，搭建了一条数据流，涉及到多次落盘读盘和计算方案的切换。因为需要反复读取远程云存储，数据时效性做到稳定的小时级别都很困难，同时存在计算方案分散、端到端联调成本高、迭代效率低下、线上数据问题难以回溯等问题。

△实时决策老架构示意

我们从繁杂的业务细节中抽象出实时决策的业务本质：

第一，虽然不同的流量预算组合有不同的实时决策策略，比如保价类、成本控制类、频控类，但他们都基于对展点消转数据相同的字段预处理逻辑；

第二，实时决策是数据驱动型业务，可以说每次的策略迭代，都伴随有新字段上线；

第三，多样的实时决策策略需要通过封装业务框架、解耦计算和存储，来支持业务自定义逻辑（UDF）。

为此我们把实时决策抽象为“导入”、“导出”模式。“导入”、“导出”过程支持用户注册基于框架的UDF，全链路支持Auto Schema Change。

△实时决策引擎架构示意

用户的搭建操作如下所示，平台根据用户的相关操作自动的触发对应工作流，对平台用户屏蔽了引擎的实现细节，解决了多级计算带来的复杂度：

创建数据源信息：用户在平台上注册数据源的元信息，完成账号权限校验，并关联数据源元数据版本。

创建数据表：用户在平台上申请创建数据表，描述元数据，根据业务特性选择数据表 GC 周期。

创建自定义逻辑：用户在平台编辑自定义逻辑（UDF）并完成注册，发版后可在平台使用该UDF。

创建导入任务：用户选择数据源以及需要导入的数据表，编写 SQL 描述 ETL 处理逻辑来创建一个导入任务。

创建导出任务：用户选择需要导出的数据表，编写 SQL 来描述导出逻辑，可选择 HDFS、消息队列作为导出目的。

添加新字段：用户修改数据源信息、表信息，在导入导出逻辑中使用新字段。

△Auto Schema Change

端到端托管的“接口”变更。

为了支持 Auto Schema Change，我们将所有数据 Schema 统一托管到代码库以及流水线，采用代码库管理接口变更历史，采用流水线发布接口版本，采用产品库管理接口版本。平台探测产品库获取所有生效的接口版本。这样，用户在代码库提交的 Schema 变更可被平台感知到。当用户更新数据源、数据表、导入导出逻辑字段时，平台会生成依赖选定接口版本的新作业。平台端到端托管数据 Schema 变更，可以保证上下游 Schema 变更按照约定的顺序一致的执行，规避过去经常发生的由于变更导致的断流。同时，变更环节有 CodeReview、流水线和实验检查，彻底解决了长链路数据流数据变更带来的效率低，协同难度高的问题。

3.1.2 转化业务场景

RTS 平台高效支持主备双集群冗余部署。

为了进一步提升稳定性，RTS 的引擎层大多数采用主备冗余设计。以转化业务场景为例，业务同学购买了实时计算、消息队列、云存储，搭建了转化数据流，但是转化业务规则是面向过程开发的，有数千行的充斥着 if-else 的 C++ 代码。不幸的是，转化规则变更很频繁，迭代效率低下。从业务角度，转化数据十分需要主备双流，却长期未成行。主备需求出于以下两点考虑：一方面，转化数据直接关乎广告主广告投放的 ROI，另一方面，逻辑变更越频繁，风险越高。但典型的主备双流需要下游配合切换，而订阅转化数据结果的下游业务团队很多。

我们抽象了对应的开发模式。用户只需要关注如何用 SQL 和 UDF 表达转化业务规则，这包括打标和去重的规则。这些规则提交后，被分别调度到 TagMarker 和 Deduper 解释执行。针对主备双流的需求，业务规则模块（Tagmarker & Deduper）采用主备部署，下游接入幂等模块（Switcher），幂等模块根据每条转化数据的唯一 Key 实现去重。业务迭代时，先在备集群生效，业务效果确认后，推全至主集群。回滚时，通过加载历史版本的 Savepoint 来实现主备流分别恢复，重复恢复的数据同样通过幂等模块进行去重。总之，我们在 RTS 上的主备双集群冗余部署方案，做到了下游无感切换。

△转化业务场景主备示意

3.2 RTS 平台引擎

数据开发先实验，后推全。

实时数据流服务的特点，决定了实时数据流稳定性要求极高。在正常的升级上线过程中，实时数据流不能出现数据逻辑错误，也不能发生长时间的服务中断。为了解决这一问题，RTS 平台针对多种开发场景提供了统一的实验平台，在 RTS 上进行数据开发工作均需要先实验后上线。RTS 平台对托管的数据流，按照每个目标字段，分场景聚合成实验冗余字段。基于 Protobuf 的 Repeated 字段特性，可在同一条数据上叠加任意多个实验，每一次的实验结果通过 Expid 以及 Version 字段进行区分。在 RTS 用户完成实验结果验证后，实验平台支持用户进行一键实验结果推全，将影响到的字段从实验字段切换为最终字段。

△数据开发流程

业务上线自动产出元数据。

元数据是大数据的灵魂，一方面，提供数据地图、数据血缘，帮助业务判断可用数据以及数据变更影响面，另一方面，RTS根据数据血缘，通过数据切片做数据变更测试流水线，第三方面，这也是后续推进流+湖存算优化的基础。在实现方面，我们引入  Linkedin DataHub 作为平台元数据引擎，平台几乎已经从字段级托管了业务场景，因此可以业务无感地通过升级计算引擎，采集据表、字段的元数据和数据血缘。随着平台托管的场景持续增加，每个场景托管的业务也越来越多，数据种类和字段都急剧膨胀，通过数据地图业务，已经能主动地提升集群效益。

△RTS 平台元数据应用

04 当前效果与未来展望

当前RTS 平台已经支持了转化业务场景、实时决策场景、实时数仓看板场景、实时数据分发场景、实时词表投递场景、实时数据挖掘场景等。其中转化业务场景托管了几十个去重标记策略；实时决策场景承接了数十张数据表以及对应的业务，作用于广告调价、广告智能拍卖、转化实时监控、媒体竞胜保价等场景；实时数仓看板支持查看分钟级数据新鲜度的时序数据以及汇总数据；实时数据分发场景支持字段级别权限控制的数据分发，服务于商业点击、消费、转化数据的数据分发以及接入；实时词表投递场景，处理加工广告以及其他结果数据，实时触达在线 KV，服务于全商业的词表实时加工处理；实时数据挖掘场景，可实时进行模型 Q 值计算，作用于 CTR 模型、CVR 模型、双塔模型等。RTS 在托管商业场景业务的过程中，业务实时化也带来了每天百万级的收益，RTS 平台成为了商业流式计算的门户。

RTS 平台还在快速发展。一方面，RTS 平台会持续扩覆盖，托管所有商业业务实时化场景。以百度商业流式拼接为例，该场景涉及展现、曝光、点击、转化等多种数据，拼接数据量峰值为百G/min，搜索、信息流、网盟等变现场景都已升级到三十天拼接时间窗口，而转化归因等业务持续衍生出新的拼接需求。RTS 计划托管流式拼接，让业务随心所欲地探索拼接潜力。另一方面，随着全球步入生成式人工智能时代，数据驱动也可以 AI 化，通过引入大模型理解底层数据，让更多的人更多的想法参与到商业数据飞轮的建设！

——————END——————

推荐阅读

登录系统演进、便捷登录设计与实现

一文带你完整了解Go语言IO基础库

百度交易中台之系统对账篇

揭秘百度数仓融合计算引擎

教不会你算我输系列 | 手把手教你HarmonyOS应用开发