共计 6133 个字符，预计需要花费 16 分钟才能阅读完成。
摘要：本文整顿自蚂蚁实时数仓架构师马年圣，在 Flink Forward Asia 2022 流批一体专场的分享。本篇内容次要分为四个局部：
- 实时利用场景与研发体系
- 低代码研发
- 流批一体
- 布局瞻望
点击查看原文视频 & 演讲 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 来构建流批研发能力，有很多的工作要做，咱们布局了五个大的工夫节奏点
- 首先将开源 Flink 适配到蚂蚁计算组件中，包含一些可插拔的组件，Connector 等，同时实时研发平台还要对 Flink 新引擎进行兼容，并对标 Blink 之前的体验进行能力的降级。
- 接着咱们对 Hybrid Source 进行的 SQL 化定义，对 SQL 语法和 DDL 参数进行设计，同时引入了多源元表的能力，多源元表是在单源元表根底之上，对字段进行映射。
- 第一版的多源元表只能进行简略的字段映射，但发现往往流批 Source 表会呈现 字段不对齐、字段语义不统一、字段数量不相等 的状况，这就引入了虚构列和流批标识的能力，通过新增虚构列，可能将某一方没有的字段补齐，并在代码中通过流批标识显式地对字段进行解决。
- 接下来对 Flink 批引擎进行了落地，和流引擎一样先实现了生态和平台的适配，接着便是对 Flink 批的 运行参数，资源分配，并发推断 等能个性进行调试。
- 最初便是流批一体的能力的落地，在平台侧实现多源元表定义、代码翻译和工作运维，目前正利用在大促场景。
流引擎和批引擎在落地的过程中有很多雷同的工作量，这里次要介绍批计算引擎的架构。
首先是 调度层 ，蚂蚁 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
