浅析如何加速商业业务实时化
点击蓝字,关注我们
01
业务背景
02
技术背景
△云计算服务层级,来源: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 架构
3.1 商业数据开发场景化
△实时决策老架构示意
第一,虽然不同的流量预算组合有不同的实时决策策略,比如保价类、成本控制类、频控类,但他们都基于对展点消转数据相同的字段预处理逻辑;
第二,实时决策是数据驱动型业务,可以说每次的策略迭代,都伴随有新字段上线;
第三,多样的实时决策策略需要通过封装业务框架、解耦计算和存储,来支持业务自定义逻辑(UDF)。
为此我们把实时决策抽象为“导入”、“导出”模式。“导入”、“导出”过程支持用户注册基于框架的UDF,全链路支持Auto Schema Change。
△实时决策引擎架构示意
创建数据源信息:用户在平台上注册数据源的元信息,完成账号权限校验,并关联数据源元数据版本。
创建数据表:用户在平台上申请创建数据表,描述元数据,根据业务特性选择数据表 GC 周期。
创建自定义逻辑:用户在平台编辑自定义逻辑(UDF)并完成注册,发版后可在平台使用该UDF。
创建导入任务:用户选择数据源以及需要导入的数据表,编写 SQL 描述 ETL 处理逻辑来创建一个导入任务。
创建导出任务:用户选择需要导出的数据表,编写 SQL 来描述导出逻辑,可选择 HDFS、消息队列作为导出目的。
添加新字段:用户修改数据源信息、表信息,在导入导出逻辑中使用新字段。
△Auto Schema Change
端到端托管的“接口”变更。
为了支持 Auto Schema Change,我们将所有数据 Schema 统一托管到代码库以及流水线,采用代码库管理接口变更历史,采用流水线发布接口版本,采用产品库管理接口版本。平台探测产品库获取所有生效的接口版本。这样,用户在代码库提交的 Schema 变更可被平台感知到。当用户更新数据源、数据表、导入导出逻辑字段时,平台会生成依赖选定接口版本的新作业。平台端到端托管数据 Schema 变更,可以保证上下游 Schema 变更按照约定的顺序一致的执行,规避过去经常发生的由于变更导致的断流。同时,变更环节有 CodeReview、流水线和实验检查,彻底解决了长链路数据流数据变更带来的效率低,协同难度高的问题。
为了进一步提升稳定性,RTS 的引擎层大多数采用主备冗余设计。以转化业务场景为例,业务同学购买了实时计算、消息队列、云存储,搭建了转化数据流,但是转化业务规则是面向过程开发的,有数千行的充斥着 if-else 的 C++ 代码。不幸的是,转化规则变更很频繁,迭代效率低下。从业务角度,转化数据十分需要主备双流,却长期未成行。主备需求出于以下两点考虑:一方面,转化数据直接关乎广告主广告投放的 ROI,另一方面,逻辑变更越频繁,风险越高。但典型的主备双流需要下游配合切换,而订阅转化数据结果的下游业务团队很多。
△转化业务场景主备示意
3.2 RTS 平台引擎
△数据开发流程
元数据是大数据的灵魂,一方面,提供数据地图、数据血缘,帮助业务判断可用数据以及数据变更影响面,另一方面,RTS根据数据血缘,通过数据切片做数据变更测试流水线,第三方面,这也是后续推进流+湖存算优化的基础。在实现方面,我们引入 Linkedin DataHub 作为平台元数据引擎,平台几乎已经从字段级托管了业务场景,因此可以业务无感地通过升级计算引擎,采集据表、字段的元数据和数据血缘。随着平台托管的场景持续增加,每个场景托管的业务也越来越多,数据种类和字段都急剧膨胀,通过数据地图业务,已经能主动地提升集群效益。
△RTS 平台元数据应用
04
当前效果与未来展望
END
推荐阅读