01

02

实时计算解决的是秒级或者分钟级数据新鲜度的数据计算问题，在超高数据新鲜度的要求下，实时计算引擎的稳定性问题总是会转化为数据时效性问题。批量计算则用来处理一批数据，这批数据分布在较长时间段的范围内，它的典型的业务场景是历史数据的挖掘以及离线报表的计算。举例来说，一份天级别产出的客户报告，报告使用方要求在第二天早上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.转化数据上文略有提及，是最具商业价值的数据，来源于广告主的回传或托管落地页的采集。

3.1 商业数据开发场景化

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

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

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

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

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

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

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

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

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

3.2 RTS 平台引擎

04