网站建设软件是什么,长沙哪里可以做网站,电子商务网站建设步骤有什么,崇州网站制作摘要#xff1a;本文整理自蚂蚁实时数仓架构师马年圣#xff0c;在 Flink Forward Asia 2022 流批一体专场的分享。本篇内容主要分为四个部分#xff1a; 实时应用场景与研发体系低代码研发流批一体规划展望 点击查看原文视频 演讲PPT 一、实时应用场景与研发体系 蚂蚁… 摘要本文整理自蚂蚁实时数仓架构师马年圣在 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 实时计算中三大 ConnectorSource/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
