关于后端:蚂蚁实时低代码研发和流批一体的应用实践

摘要：本文整顿自蚂蚁实时数仓架构师马年圣，在 Flink Forward Asia 2022 流批一体专场的分享。本篇内容次要分为四个局部：

1. 实时利用场景与研发体系
2. 低代码研发
3. 流批一体
4. 布局瞻望

点击查看原文视频 & 演讲 PPT

一、实时利用场景与研发体系

蚂蚁实时的数据利用次要包含报表监控、实时标签和实时特色三局部。最底层的实时数据采集来源于线上日志、实时音讯和数据库日志三大块，并由此构建了实时和离线的明细中间层，该中间层定义不同的主题域，如：流量、营销、交易等。再往上构建应用层数据去撑持前台业务的实时数据需要。

在这三个利用场景中，报表场景依据查问个性的不同，实时数据会被存储到 OLAP 引擎或 KV 库，在应用层进行实时 / 离线数据的交融，来构建实时数据报表；而在实时标签场景，将实时数据直写到 Hbase/Lindorm 库中，离线数据通过标签平台回流至线上库中；特色场景和标签场景链路相似，通过特色视图对流 / 批数据别离进行字段 Mapping。

以上的数据链路架构在 研发、运维、生产的老本 上均存在肯定的问题，在 开发阶段 ，首先突出的是实时研发的效率问题，一个实时工作从需要对接到数据交付往往须要较长时间，如果波及到离线回补逻辑，则还需开发离线兜底链路，并同步离线数据到线上库中；在 线上运维阶段 ，尽管 Flink 始终在升高工作调优难度，但实时离线计算引擎的运维压力是双重的，往往须要相互翻译口径进行问题排查；在 生产链路 中，实时离线两拨同学研发，往往报表会配置两份，其工作量反复之余，也会减少上游的数据应用老本。

最初再抛出一个实时中的老大难问题：长周期计算问题。支付宝大促流动频繁，计算流动期间累计去重 UV 这类指标，研发运维老本始终较高，这也是咱们尝试在优化解决的问题。

蚂蚁实时研发体系在去年实现了的降级，构建了基于实时元表为载体的实时研发能力，从实时资产的定义、到实时代码研发、到线上的实时品质监控，再到实时元数据生产，都是基于元表来实现的，在数据研发时可疾速的援用公共的实时资产。对于此套能力体系，研发同学还是须要经验相当多的研发过程，上图标星的是咱们心愿可能进行提效研发和缩短开发周期的环节，因而，咱们推出了低代码研发和流批一体能力。

二、低代码研发

低代码次要解决咱们实时开发中的两个大的命题：研发提效和升高实时研发门槛，对于这两个问题面向的用户群体还不一样。一类是资深的实时研发同学，他们比拟理解实时研发中的各项细节，然而很多基础性的代码研发工作会极大影响他们的效率；另一类则是实时的入门级选手，他们对于实时研发的概念和应用形式都不太熟悉，可能是对照着 API 一步步试错。

对于这两个格调不一样的人群，他们实质的需要都是心愿有个工具来解决他们的问题，由此咱们构建了实时低代码研发能力。本着产品易用、工作易保护、代码正确的前提，咱们通过配置化研发，将实时研发的范式形象，并集成高阶的实时解决方案，最初冀望可能强化工作自动化运维，让用户在低代码中所配即所得，即配即上线。

咱们优先从 数据场景动手 思考低代码研发工具所需具备的能力。汇总计算场景 中，偏重对统计周期和维度的各种组合，而指标计算大部分是累加型 (COUNT(1))、聚合型(SUM(xxx)) 和去重型 (COUNT(DISTINCT xxx))，当然还须要具备简略的逻辑过滤、维表关联等根底代码操作。 标签场景 中，偏重对明细数据的解决和解析，须要可能反对各种实时计算算子。特色场景 和指标计算场景很像，然而工夫窗口多以滑窗为主，计算近 x 分钟 / 小时的窗口聚合数据，维度次要是 user 或 item 粒度（如计算商品、流量点位、店铺等），特色中计算算子较为丰盛，且一个需要中需提供多个滑窗、多种指标的特色，须要可能反对多窗口多算子的实时计算能力。

综合以上三个场景，咱们抽取三者独特的特点：算子反对、Flink 个性封装、批量研发

对于这么多能力需要，咱们采纳 维度建模 的实践来进行构建，Flink 实时计算中三大 Connector（Source/Sink/Dim）和维度建模实践人造的符合，从明细事实表登程，进行一系列的数据操作，设定统计周期和维度，计算相应的实时指标。剩下就是对于低代码能力细节的拆解，从用户体验、平台能力和引擎优化三个角度进行构建。

整个平台能力分为用户工作配置和代码逻辑生成两大块。

在 用户操作界面，咱们定义了关联维表、数据收缩、表级去重、表级过滤四大过程组件，并通过计算视图这个能力兜底以上算子不能笼罩的场景。同时定义统计周期和统计维度两个后果组件，应用这两个组件则默认是汇总指标计算，反之则是明细数据处理。对于这些组件中的信息，咱们形象了计算元素的概念，将重要的组件内容和起源表绑定，一些通用的计算范式和资产生产口径，用户能够间接选用其余用户公共定义的逻辑，进步开发效率。

这样通过增加组件，筛选维度和周期，对后果表中的字段定义其类型，并抉择具体的逻辑，调整维度散布后，便实现了实时工作的配置。

工作配置完，平台侧从后果表反向推导，判断工作配置的逻辑是否正确，这一步很像 Flink 执行打算生成的逻辑，从后向前一直循环校验各算子的正确性，直至整个工作代码生成，这便实现了代码的编辑工作，用户对物理工作进行执行打算配置即可上线。

对于低代码研发中引擎的优化，我以实时特色举例。首先咱们来比照下指标场景和特色场景的异同点，其最次要的差别在于 窗口和算子的复杂度 ，同时特色中多以用户粒度也决定了下发数据绝对较多， 数据吞吐较高。

从以上这些现状登程，咱们对 Flink 的窗口计算做了一系列优化，首先从单滑窗降级到了多划窗语义。依据上游应用横表和竖表数据需要，将多滑窗中的窗口行转列成多个指标，对数据进行拉横，缩小上游输入的条数。

同时对触发策略进行降级，可反对窗口触发前后都能进行数据的更新，当然对于窗口触发后次要用来进行数据置 0 的操作。对于定时更新的数据下发，思考到上游的数据库性能，对 Connector 退出了限流性能。还引入了对窗口状态变更检测能力，如果窗口内的数据没有变更，也不须要进行下发更新。

对于多滑窗的 状态存储优化，和 Flink 开源版本相似，退出了子窗的概念，一个数据保障其只划分到最细粒度的窗口中，窗口计算时汇总各子窗中的数据即可实现数据聚合。

最初通过一个案例介绍实时低代码研发的应用

首先在起源表上定义计算元素，这些定义的逻辑可被过程和后果组件应用。配置面板中有三大块：过程配置、后果组件和面向后果表的字段定义，对于不同统计周期的雷同计算逻辑，可应用批量复制，批改统计周期即可。

平台还提供了统计周期和维度的 组合拆分能力，用户依据统计周期和维度的数据状况，抉择是合并一个工作还是拆分多个工作。

最初便是生成的代码展现，这里提到的是，平台侧会感知 UV 和 PV 的计算逻辑，并对 UV 类累计指标独自拆成子工作计算，最初和 PV 类进行合并，用户还能应用咱们内置的累计去重计算计划。

三、流批一体

在构建流批能力之前，咱们先 REVIEW 下以后实时数仓中的数据链路状况。Lambda 架构中，三个生产场景的实时离线数据交融计划还不对立，从数据侧到利用侧都有触发流批数据交融的逻辑，但实质上还是流批模型字段对齐的语义表白，上游便可实现字段对齐逻辑。

其次在实时数仓中，大部分都是从 ODS/DWD 层间接计算累计后果，而离线数仓中，应用层数据大部分都是从轻度汇总层计算失去，在构建流批数据时需思考这样的差别，可能流和批表的对齐形式就是明细和汇总。

在频繁的大促过程中，实时和离线工作存在着 反复开发 的问题。对于研发口径一致性，实时离线报表指标对齐，都有着肯定的挑战。对此咱们思考多个方面，从字段对齐到引擎的生态，再到研发运维效率，并参考业界流批计算的案例，最终选用 Flink 引擎来构建流批一体的研发能力。

通过一套资产、一套引擎、一份代码，实现流和批工作的研发，最终通过流批能力笼罩实时离线 反复开发和兜底 的场景，进步研发运维效率。

蚂蚁支流的实时研发引擎还是 Blink，对于通过 Flink 来构建流批研发能力，有很多的工作要做，咱们布局了五个大的工夫节奏点

1. 首先将开源 Flink 适配到蚂蚁计算组件中，包含一些可插拔的组件，Connector 等，同时实时研发平台还要对 Flink 新引擎进行兼容，并对标 Blink 之前的体验进行能力的降级。
2. 接着咱们对 Hybrid Source 进行的 SQL 化定义，对 SQL 语法和 DDL 参数进行设计，同时引入了多源元表的能力，多源元表是在单源元表根底之上，对字段进行映射。
3. 第一版的多源元表只能进行简略的字段映射，但发现往往流批 Source 表会呈现 字段不对齐、字段语义不统一、字段数量不相等 的状况，这就引入了虚构列和流批标识的能力，通过新增虚构列，可能将某一方没有的字段补齐，并在代码中通过流批标识显式地对字段进行解决。
4. 接下来对 Flink 批引擎进行了落地，和流引擎一样先实现了生态和平台的适配，接着便是对 Flink 批的 运行参数，资源分配，并发推断 等能个性进行调试。
5. 最初便是流批一体的能力的落地，在平台侧实现多源元表定义、代码翻译和工作运维，目前正利用在大促场景。

流引擎和批引擎在落地的过程中有很多雷同的工作量，这里次要介绍批计算引擎的架构。

首先是 调度层 ，蚂蚁 Flink 的调度应用了原生的 K8S 调度，咱们还在尝试 集群调度模式，在 K8S 之上间接获取机器资源，缩小工作公布上线的工夫，同时能保障工作的稳定性。

在 引擎 这一层，Flink 研发运维同学做了很多的工作，从上往下看，首先对齐 Blink SQL 实现计算函数的新增，并优化了局部执行打算推断的逻辑。如一个源抽取了 ab 字段，同样的表抽取了 bc 字段，则会对 source 表进行合并读取。

在 批引擎执行优化层面 ，对批计算中的 并发度、CPU 和内存 进行配置，Connector 的并发度依据数据量进行推断，而运行中搭配 AdaptiveBatchScheduler 进行动静调整。对于 CPU 和内存，则依据不同的算子类型进行设置。并对线上工作进行压测，发现并优化 Flink 批在大数据量和计算压力下的一些改良点，保障批工作的运行性能和稳定性。

Connector 层面 则次要对齐 Blink 进行适配，思考到批工作会在计算实现之后一次性同步会产生输入洪峰，为了爱护线上库，设置限流是相当必要的，引擎侧在 Connector 插件中实现了限流的能力。

DataStream 引擎和算子次要应用开源能力。最初在 可插拔组件 中，咱们次要对 Shuffle 组件、调度组件和后端状态进行了适配优化。批工作默认应用基于 TaskManager 本地磁盘的 Shuffle 形式，这种形式对本地磁盘的要求比拟高，在上下游交互的时候存在依赖关系，咱们引入了开源的 flink remote shuffle 组件，独立局部 Shuffle 组件，实现计存拆散的架构。

在 计算平台层面 ，对批工作的预编译、调试、提交、公布、运行监控进行了反对，对于离线代码中的工夫变量、工作参数进行解析翻译。其中最重要的是将 Flink 批计算类型退出到 离线调度引擎 中，依赖 Odps 等其它的工作产出的数据，在调度运行是生成工作实例，并查问具体的运行日志。

对于流批表对齐的问题，咱们来看以上两个 CASE。在流和批都是明细的状况下，流和批的字段含意不统一和不对齐是常见的，比方离线是否打标是 Y/N，实时打标 1/0。而对于流明细批汇总的场景，比方离线是算到用户粒度的轻度汇总数据，对于 PV 这样的字段，实时必定没有的。

对于以上这类问题，一个计划是某一方进行数据的革新，保障两侧的数据字段对齐，然而老本相当高。因而，咱们设计了虚构列字段，对于某一方不存在的状况下，应用虚构列标识，同时对流表和批表进行参数定义，这样就能在代码中显式的判断和解决，以此来解决流批字段不对齐的问题，在这样的能力撑持下，即便流和批表字段齐全不统一的极其状况，也能进行特判和解决。

对齐起源表字段之后，咱们来看上流批一体的整体计划。举个栗子来简述下具体的计划细节，有 stream_source 和 batch_source 两个起源表，其中 c 和 d 字段是不对齐的，通过虚构列进行补充，注册成 mix_source 的多源元表，咱们在失常开发流批工作的时候，依据流批标识进行逻辑判断，同时也能通过代码变量做流批的自定义逻辑。

平台侧会依据 mix_source 背地的单源元表进行物理代码的翻译，同时通过一个 View 的适配，将字段和虚构列定义实现。批代码咱们反对动态分区，也就是在 DDL 中定义分区，和动静分区，在代码中显示的指定工夫变量，以此对离线分区进行裁剪。当然对于维表和后果表，以后只能反对单源或者字段完全一致的多源，这块目前没有特地强的诉求，须要将维表和后果表也要反对不同的字段定义。

对于长周期去重计算指标，如大屏场景对数据后果查问性能有肯定的要求，往往须要将数据计算到一个指标或者很小量级的数据，可能疾速的进行累加。

对于这类场景，在没有利用 Hybrid Source 之前，咱们通常的做法是借助 Hbase 这样的 KV 库，存储用户的拜访状态，数据过去是校验用户是否拜访过，最终算到天级的新增 UV 开窗累计即可。另一种方向则是间接在 Flink 中设置较大的状态过期工夫，相当于把内部存储内置到引擎中，但此种计划须要思考，如果在工作呈现问题，状态须要抛弃，或者中途批改逻辑的状况下，实时回刷老本很高。

对于以上两个问题，咱们设计通过 Hybrid Source 来撑持。Hybrid Source 也是应用多源元表，映射实时和离线字段，咱们定义了 Hybird Source SQL 的 DDL 语义，0 和 1 标识批和流表，同时定义了 fieldMappings 字段来标识字段名称不对齐的状况，定义 virtualFields 表白虚构列，在 Connector 插件中依据这些定义和流批标识，对数据进行打标，实时工作即可实现 Hybrid Source 场景简单 SQL 开发。右下角图片是 Hybrid Source 工作发上线的启动界面，对于批和流别离抉择启动的工夫。

让咱们看下这个流批一体的案例，需要是开发双十一流动中的权利支付核销状况，咱们通过 Mix 元表定义了实时和离线明细表，在代码外面显式的解决了流和批不同的逻辑，实时侧会对工作开始工夫和提早数据做解决，批则会限度调度日期的数据。

同时该工作开发了 Bitmap 的自定义函数，实时和离线共用一份 UDX 进行计算，最初别离对流和批元表进行参数配置，设置调度属性后即可实现上线，上线后生成两个工作，别离进行运维。

四、布局瞻望

对于本次分享的低代码和流批一体能力，后续会一直的拓展应用场景，将实时数据利用到更多有价值的中央。同时在实时研发提效和升高门槛这件事件上，会持续往前走，后续两个性能稳固且用户积攒肯定水平后，会尝试将能力进行整合，在低代码中实现一站式开发。最初则是看向业界都在摸索的数据湖命题，心愿可能在几个业务场景中将这套较大的解决方案落地。

点击查看原文视频 & 演讲 PPT

更多内容

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
0 元试用 实时计算 Flink 版（5000CU* 小时，3 个月内）
理解流动详情：https://free.aliyun.com/?pipCode=sc