共计 6430 个字符，预计需要花费 17 分钟才能阅读完成。
摘要：本文整顿自蚂蚁团体高级技术专家赵亮星云，在 Flink Forward Asia 2023 AI 特色工程专场的分享。本篇内容次要分为以下四局部：
- 蚂蚁特色平台
- 特色实时计算
- 特色 Serving
- 特色仿真回溯
一、蚂蚁特色平台
是一个多计算模式交融的高性能 AI 数据处理框架，可能满足 AI 训练和推理场景对特色低提早产出、高并发拜访以及在离线统一等方面的诉求。
蚂蚁建设特色平台的外围目标，是让算法同学在数据供应侧可能自力更生，即 data-self-sufficient。具体是心愿算法同学通过平台以低代码的形式进行特色研发、测试、公布、上线，整个流程不须要专门数据工程团队反对对接。
特色上线当前，背地对应的高性能实时特色生产工作、高性能查问服务以及特色在“离线”和”在线”两个世界保持数据一致性等性能由特色平台主动提供，对用户通明。
特色平台从 2017 年开始建设，基于风控畛域的积攒和数据教训把风控的外围数据产品抽出来，组建为特色平台。这套特色平台较好地服务了蚂蚁风控的业务。在 19 年到 20 年期间，平台向全站算法业务推广的过程十分困难。外围起因是基于风控建设的特色平台蕴含十分多风控业务语义，它的计算范式是面向风控场景特地定制的，包含计算 DAG、数据精度、算子类型等都是针对风控畛域优化设计的，所以向全站推广的过程中显得难以适配。因而从 20 年开始，蚂蚁特色平台进行了彻底的重构。
截止目前，蚂蚁特色平台曾经服务了蚂蚁包含搜推，微贷，国内风控，网商，财产保险，芝麻等次要业务方。特色规模 10 万 +，在线 Serving 的 QPS 两百万，日常的计算 TPS 100 万左右。
想一套特色平台满足全站特色业务诉求，平台应该具备的外围能力有以下 4 方面：
- 疾速实现任意计算范式的能力：
首要诉求是算法同学面对异构场景、差别需要可能疾速以配置化形式将实时特色上线。所以特色平台不能和某种固定计算范式绑定，须要具备疾速实现任意灵便计算范式的能力。 - 特色大规模仿真回溯的能力：
模型训练的第一个阶段是样本筹备。如果算法同学想训练一个模型，选好了一批实时特色，而这些实时特色还没上线，意味着它没快照，构建不进去样本。因而对于这批新定义且未上线的实时特色，特色平台须要疾速计算出它们在历史时刻面对历史查问申请的“瞬时值”，即特色平台可能针对历史样本对新增未上线特色进行特色补全。这就须要特色平台具备大规模特色仿真回溯的能力，对平台提出了流批一致性的能力要求。 - 实时特色冷启动的能力：
试想某个模型里用了很多实时特色，这些实时特色又是窗口特色，如果等实时特色上线、窗口累计残缺后再提供 Serving 服务，模型迭代效率非常低。这就要求实时特色一旦定义好，要疾速补全特色窗口值，进而让特色尽快开始提供线上 Serving 服务，这就须要特色平台具备实时数据冷启动的能力。 - 高性能特色 Serving 的能力：
模型上线后，要提供一个高性能的模型推理服务，依赖的数据输出必须是高性能的。因为在模型服务的过程中，性能瓶颈点个别在数据 IO 阶段，为了让模型服务更高效、更精确，必须要提供一套高性能、低提早的特色在线查问服务。这就须要特色平台具备高性能特色 Serving 的能力。
依据四个必须具备的外围能力提出蚂蚁新一代的特色平台架构 UFE（universal-featureEngine-based-architecture），这个架构横跨离线和在线两个数据世界。离线局部是一套用于特色大规模仿真回溯的零碎。在线局部用存储把“写”和“读”两侧离开：“写”是基于 Flink 打造的一套实时数据生产零碎。这套实时生产零碎跟大规模仿真零碎合起来的叫做 Skyline。“读”是一套基于自研高性能 SQL 引擎实现的高性能特色查问服务。其次要目标是给模型推理服务提供高效的特色批量查问服务，即如何把一批特色在尽量短的提早内返回给模型服务。
Serving 服务上面有一套用于特色品质监控的 feature insight 体系。它能够实时监控特色的调用状况、耗时状况，也能够剖析特色的内容散布。如果内容散布产生了急剧的变动则会产生正告。
架构最上面是特色对立元数据服务，这份服务的存在其实是很有意义的。把 feature-devops 的操作，包含特色研发、定义、公布、验证，推送上线等全副形象为接口。“特色平台治理时”是基于这套接口实现的，如果有内部的大业务方想基于特色平台的外围数据能力去构建本人的平台产品，也能够对接这套接口。在蚂蚁运行的特色看似来源于不同的配置平台，其实进到特色平台外部元数据是对立的。元数据对立有一个极大的益处是无论生产侧还是生产侧特色平台做的任何技术优化，对全局都是对立失效的。在蚂蚁外部这套特色元数据系统曾经对接了十分多的平台，而“特色平台治理时”，就像一套简装公寓，如果没有非凡需要能够领包入住。如果资源特地富余且个性化定制诉求十分多，那能够基于特色平台的数据技术本人盖房子。
二、特色实时计算
2.1 特色实时计算的挑战
特色实时计算面临的第一个挑战是性能上的挑战。在蚂蚁，动辄就会遇到一个计算工作要面临大几十万甚至上百万的 TPS 的状况。如何让这种超大规模的计算工作可能有低提早稳固的输入？这是一个微小的挑战。
第二个挑战是心愿用户在平台上只定义数据诉求，而不须要关怀数据的具体是怎么实现的。但雷同的数据诉求在不同的场景下其最优的实现门路可能齐全不同（因为不同场景的资源状况、数据精度、提早时长、数据查问性能等要求都不同）。如何用一套实时特色生产零碎满足差异化场景下最优计算门路的疾速适配？这是另一个挑战。
举 2 个场景的区别来阐明这个问题：
- 风控场景
风控场景下长窗口特色占比十分高。例如“用户 90 天内的实时交易次数”、“用户 90 天内日均匀转账次数”等等。长窗口的特色占比大是因为风控畛域长窗口数据更能综合断定用户的可信度，且风控业务常常用长窗口数据和近期数据做比拟来判断行为渐变。再者风控须要快攻快防，一旦发现危险要立刻扭转数据口径且立刻失效。基于这两个个性，在风控不太适宜把这类特色数据在计算侧间接算成最终后果来提供 Serving（尽管这样的对 Serving 性能是最好的）。因为首先超长窗口的实时计算当初还没有引擎可能将 State 全副放到计算引擎外部，其次面对快攻快防须要灵便调整数据口径的诉求，齐全预计算好的 KV 后果无奈做任何水平的数据复用，一旦计算口径产生扭转，之前所有计算好的数据全副都有效了。因而在风控场景比拟适宜基于明细或者中间状态的 Serving，也就是说在计算侧，把明细或小时账、天账算进去存到存储外面去，特色 Serving 时长期从存储里把这些账拿进去做聚合。 - 搜寻场景
在搜寻场景短窗口实时特色占比十分大。因为个别认为用户近期的行为表现更能体现接下来的生产用意。但搜推场景对特色查问性能要求十分高。例如一次查问 100 个特色，均匀 RT 要在 10 毫秒以内，且长尾毛刺不能高于 80 毫秒（P99.99 的 RT<80ms）。要达到这种诉求，须要尽量把后果在计算侧间接算进去，而后把它以 KV 化构造存到存储里供 Serving 应用。两种场景的比拟意味着看似差不多的实时特色诉求，其实在不一样的场景下最优实现门路是不一样的。也就意味着没有方法用一种计算范式和一种计算的部署模式去服务全副业务。因而对特色平台提出一个要求，即平台可能灵便将用户的数据诉求以场景化最优门路来实现。
2.2 特色计算框架 skyline 架构
基于这样的思考，提出了 Skyline 计算架构。Skyline 通过元数据服务接管来自各平台产品的实时特色的定义（定义过程是面向计算需要的 DAG）。这个 DAG 会传到场景化定制的 adaptor 层，被实例化为具体应该在这个场景最优化的计算形式。例如同样“求七天内的复登录次数”到底是应该间接算出 KV 化的后果，还是在计算侧算一些账存到存储中在特色查问时候长期聚合呢？这个问题在这一层会确定。之后实例化的计算 DAG 会被流批通用的计算优化模块进行 DAG 到 Task 的拆分，而后对这些 Task 会做一些逻辑优化（filter 上推、列裁剪等）和计算 DAG 归一化，其后果能够被流场景跟批场景辨认逻辑执行打算。这个逻辑执行打算在批场景和流场景会各自利用各自的独立专项优化，进而上线部署。
这外面有 3 个要害阶段：计算推导、计算归一化、计算部署。
首先场景定制的规定插件会将计算形容 DAG 依据 AGG 算子类型和工夫窗口长度实例化成不同的计算 Task，例如小于 1 天的 sum 间接应用 hopWindow 实现，大于 1 天的 sum 应用 tumbleWindow 计算天账（特色 Serving 时候查问多天的天账去二次聚合）。
接下来 Skyline 对计算 Task 进行 filter 上推、列裁剪、归一化（节点程序调整和链接压缩）进而造成由外围“骨架节点”组成的逻辑执行打算。最初是计算部署，如果该场景要求相对的工作隔离、谋求不同计算之间不会相互影响，则归一化后的逻辑执行打算会被转化成 Flink SQL 工作间接运行。如果计算资源缓和、谋求最大集群资源利用率，则 Skyline 会在全局计算元数据中进行查找匹配，判断当初集群外面有没有雷同骨架构造的物理工作，如果有 Task 会被合并到已有物理工作，如果没有则新建一个物理工作（此类物理工作是用 stream API 写的，可不重启间接动静加载计算策略）。
在 Flink 外面最间接的优化是尽可能缩减 Flink 的 State 的大小，State 越小工作稳定性越好，从而可能让实时计算工作在超大流量规模下做到低提早数据产出。蚂蚁有十分多的“同质滑窗特色”：“滑窗特色”即从当初到 N 久前的某种行为的聚合值，“同质”即数据计算逻辑都一样，只是最初查问的窗口长度不一样。如果这种滑窗场景用 Flink 原生的 hopWindow 实现，计算资源肯定会有限收缩且后果数据刷存在 IO 爆炸危险。因而对 hopWindow 的 State 进行了“滑窗转固窗”的重构，数据到来会依据 eventTime 把它放到 merge 到固窗的 pane 外面（pane 的长度为滑窗 slide 长度），在窗口刷出时依据 pane 里的数据做二次聚合输入。这样极大的缩减了滑窗计算工作的 State，且同质计算齐全能够基于这同一份 State 进行。同时更改了原始滑窗数据刷出机制，前后 2 个滑窗如果被断定数据完全一致，则不会刷出后一个窗口数据（因为 Serving 的时候都是查最新窗口的数据，如果前面窗口数据无变动则没有必要刷出）。
特色冷启动次要利用了 Flink 人造的流批统一个性。将实时特色生产逻辑转化为等价的 Flink 批 SQL，在线上的实时工作提交之前先将 Flink 批 SQL 工作提交运行进行历史数据补齐。之后把流工作从零点开始重置，这样的流批两边的数据就能够拼接上。
三、特色 Serving
特色 Serving 的作用是给在线模型推理提供特色查问服务。理论场景中上层业务对特色查问性能要求十分严苛：一次查问申请蕴含上百个特色（因为数据链路的复杂性这些特色对应的数据可能扩散在不同存储中），均匀 RT 要求小于 10ms，P99.99<100ms。做到高申请、高并发状况下的低 RT 低长尾毛刺是 UFE-serving 服务的外围意义所在。
UFE-serving 由三层形成：
- 表述层
最上层是特色的表述层，当初主推的特色表述是 SQL，即用户通过写 SQL 的形式来定义数据从存储查问出后长期转换和二次加工的过程。
用 SQL 有三个益处：
- SQL 作为通用数据形容 DSL 没有学习老本。
- 数据 Serving 的形容用 SQL 定义，计算的形容也用 SQL 定义，意味着面对同一个实时特色能够依据理论场景灵便的做计算和查问的推导和拆分。
- 优化全局失效：因为特色都是用 SQL 形容的，对 SQL 引擎做的任意优化都会立即利用到全局的特色执行过程中。
- IO 优化层
IO 优化层屏蔽了底层异构存储，将存储都形象为视图的概念（SQL 中波及到的表是 UFE 的视图），特色 Serving 引擎在一次特色批量查问过程会进行跨 SQL 的 IO 提取、合并及并发优化。 - IO 实例层
最上面是 IO 实例层，用于对接任意存储。新的存储呈现，只有基于 UFE 颁布的 connector 接口实现一个 connector 实例，就能够把其纳入到 Serving 体系外面来。
具体一次特色批量查问的 IO 优化过程如下。
首先对数据进行分层形象，例如用户定义如下特色 SQL：
select sum(amount) as total amount_24H
from trade_table
where gmt_occur between now()-24H and now();
SQL 中的 trade_table 就是定义的视图，一个存储会产生不同的视图，同一个视图又会产生不同的特色。ufeServing 引擎会对一次批量特色查问波及到的全副特色 SQL 构建全局最优 IO 打算。构建过程是遍历全副 SQL 收集列、窗口及视图信息，对这些 IO 信息执行“IO 分类合并”算法。算法思维很简略，首先依据视图存储类型进行 IO 分类，对于同一类 IO 将同行不同列及同表不同行的数据合并到一次 IO，同时基于 SQL 收集到的无效列、窗口范畴等信息缩减单次 IO 的 scan 范畴。总的来说，一方面缩小单次 Serving 过程中查问引擎与存储的交互次数，一方面缩小数据 scan 的范畴，不同存储并发查问后引擎会将后果拆分到不同特色。
通过 IO 合并优化和特色 Serving 引擎内置的热点主动发现、并发精准超时管制等技术，在特色查问侧的长尾毛刺率能控在四个九以上，而且均匀 RT 是非常低的。
四、特色仿真回溯
实时特色的值随着时间轴的推移始终在变动，在线如此、离线也如此，特色仿真就是要依据历史驱动表（历史特色查问流量）和历史音讯表（例如历史交易事件）算出某个特色在全副历史时刻的瞬时值。这种 Time travel 计算在风控和消费信贷场景属于外围的必备能力，因为这些场景进行策略调整或新模型的迭代时须要充沛评估新特色可能对线上交易造成的影响，因而他们须要仿真的样本量很多都跨半年以上。
如果用户本人在数仓外面写 SQL，如果数据量小的话能够算进去。但当驱动表扩张到百亿级别的时候，没有任何一种计算引擎的原生计算形式可能在短时间内实现这种计算，因为这会波及到大量的数据 shuffle 和数据 join，数据收缩相当严重。
特色仿真的外围挑战：大数据量在 PIT 语义下计算的性能和稳定性。首先要让这种计算能算得动，其次要有稳固的输入。
这个流程图讲了特色仿真的外围流程。首先依据驱动表、特色逻辑、及事件表进行数据预裁剪（剔除事件表中不可能被用到的事件，因为没有查问流量查它）。数据裁剪后进行拆账计算，将明细数据计算成小时账、天账，并且对明细加工夫分区（次要用于前面的数据裁剪）。同时对驱动表按工夫片拆分，接下来用驱动表再加上拆出来的账做二次聚合加工，把最终特色算进去。
二次聚合过程：首先算出驱动流量对于该特色的窗口开始和完结工夫。而后依据计算出的窗口信息到将日账、两端的小时账拼过来，最初会将小时账两端的明细拼进来（因为仿真计算的数据产出精度跟在线保持一致，也是毫秒级的）。这时候再拼明细，比用户原生写的 join 形式的性能高很多。因为明细在下面数据处理的过程中，其实曾经携带了工夫分区了。在具体找明细的过程中，特色引擎会依据他所属的小时分区天分区对数据进行大量的裁剪。通过拆账优化和二次聚合，特色平台就能反对这样的大规模 PIT 计算了。大略百亿的数据量、90 天的窗口，特色平台能保障一个特色在 24 小时之内产出。
Flink Forward Asia 2023
本届 Flink Forward Asia 更多精彩内容，可微信扫描图片二维码观看全副议题的视频回放及 FFA 2023 峰会材料！
更多内容
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
59 元试用 实时计算 Flink 版（3000CU* 小时，3 个月内）
理解流动详情：https://free.aliyun.com/?pipCode=sc