FineDataLink 5.0 双引擎能力升级：可视化流式处理，让实时计算无需编码

实时计算长期卡在一个矛盾上：Flink 能力强大，但门槛高到只有少数工程师能驾驭；可视化工具上手快，但复杂计算又力不从心。FineDataLink 5.0 用"自研引擎 + Flink 外置引擎"的双引擎架构，加上可视化的流式处理，试图同时解决这两个问题——让不懂 Flink 的人也能搭实时任务，让需要复杂计算的人依然能用到 Flink 的全部能力。

一、实时计算的"门槛困境"

企业对实时数据的需求，这几年越来越明确。生产线上设备异常要实时感知，大促期间库存要实时掌握，园区能源用量异常要实时发现——这些场景的共性是：数据晚几分钟，就可能造成实际损失。

但实时计算的落地，长期卡在一个门槛上。

Flink 是实时计算事实上的主流引擎，能力强大、生态成熟。问题在于，它的使用门槛很高：要写 Java/Scala 代码，要理解流处理的时间语义、窗口、状态管理、水位线，要自己搞定集群部署和运维。一个企业要真正用起 Flink，往往需要一支专门的实时计算团队。

于是出现了两极分化：要么投入重资源自建 Flink 团队，要么干脆放弃实时计算，退回 T+1 的离线报表。中间那条"想用实时、但养不起 Flink 团队"的路，一直是空白的。

FineDataLink 5.0 的实时计算模块，就是来补这条路的。它的思路是：用可视化降低门槛，用双引擎保住上限。

二、双引擎架构：自研引擎保易用，Flink 引擎保上限

FineDataLink 5.0 提供两种计算引擎，对应两种不同的需求。

自研引擎：开箱即用，无需额外部署。 FDL 自研的实时计算引擎，内置在平台里，不需要额外部署集群，配置即可使用。它支持 Exactly-Once 语义，保证数据在实时处理过程中不丢不重。对于绝大多数常规的实时场景——数据清洗、过滤、字段映射、关联、分组汇总——自研引擎已经足够，而且省去了 Flink 集群的部署和运维成本。

Flink 外置引擎：复杂计算场景的完整能力。 当遇到自研引擎难以覆盖的复杂计算场景，可以切换到 Flink 引擎。配置 Flink 引擎后，在数据处理节点中引用需要关联的节点，引擎会自动切换为 Flink 执行。Flink 引擎同样支持 Exactly-Once 语义，保留了 Flink 在复杂流计算上的全部能力。

双引擎的价值，在于按需切换，而不是二选一。常规场景用自研引擎，门槛低、成本低；复杂场景切 Flink，能力不打折。同一个平台，覆盖了从"简单实时同步"到"复杂流计算"的完整需求。

三、可视化流式处理：实时任务也能量"拖"出来

双引擎解决了"用什么算"的问题，可视化解决了"怎么搭"的问题。

在 FineDataLink 5.0 里，实时任务的搭建和离线任务一样，是界面化的：通过拖拽、连线、配置节点，就能完成一个实时数据管道的搭建。不需要手写代码。

具体来说，一个实时任务通常包含三类节点：

数据源节点，负责接入实时数据。FDL 5.0 覆盖了企业常见的实时数据源——物联网和实时协议（MQTT、WebSocket）、数据库（CDC）、消息队列（Kafka、Pulsar、IBM MQ、RabbitMQ、RocketMQ）、实时湖仓（Paimon）、事件（Webhook）。其中 MQTT、Pulsar 这类制造业通用的接口协议，开箱即用，不需要自己开发或对接开源 Connector。

处理节点，负责对流入的数据做转换。支持 JSON 解析、XML 解析、字段设置、新增计算列、数据过滤等清洗操作，也支持数据关联、数据合并、分组汇总、FlinkSQL 等计算操作。大部分流式转换，仅需部署 FDL 就能使用，降低了对 Flink、Spark 等引擎的依赖。

处理节点之外，FDL 5.0 还提供了两类容易忽略、但在实际场景中高频使用的转换能力。一类是数据质量提升——值替换（把异常值替换为规范值）、字段拆行（把一个字段里的多条记录拆成多行）、字段拆列（把一个字段拆成多个字段）；另一类是数据格式转换——列转行（把宽表转成长表）。这些操作看似琐碎，却是实时数据清洗中最常见的动作：设备上报的报文里，往往一个字段塞了多个值，需要拆行；宽表结构需要转成长表才能做聚合。FDL 5.0 把它们做成了界面化的节点，拖拽配置即可完成。

输出节点，负责把处理结果送到目标。可以输出到关系型数据库、MPP 数据库、分析型数据库，也可以供 FineBI 消费，或输出到 FVS 3D 大屏、数字孪生场景。实时任务还可以触发下游定时任务的执行，形成"实时处理结果 → 下游业务动作"的编排。

流批一体的开发体验，是这套可视化能力的关键。开发人员用同一套界面化配置，就能完成实时任务和离线任务的搭建与运维，不需要为实时单独学习一套工具。这意味着，一个熟悉 FDL 离线开发的工程师，几乎不需要额外学习成本，就能上手实时任务——因为节点、画布、配置方式都是同一套。

四、四大实时场景：从数据同步到业务动作

FineDataLink 5.0 的实时计算，覆盖四类典型场景。

这四类场景，对应了不同行业的真实诉求。而同一个行业里，不同角色对实时数据的痛点也各不相同。

制造业，多生产基地、产线自动化程度高。厂长和生产负责人，苦于生产数据滞后，只能靠 T+1 报表看效率和设备利用率，决策慢；设备操作工和工艺优化人员，苦于设备异常、产量不达标无法实时感知——高速产线晚几分钟，就产生大量次品；IT 工程师，苦于对接 PLC、传感器、SCADA 等设备数据依赖代码开发，成本高、链路复杂、排查难。FDL 5.0 对接这些设备数据，通过 MQTT 等协议接入，把设备数据实时转化为产量、效率、设备利用率的实时指标，三类角色的痛点各有解法。

零售业，渠道多、门店多、订单库存变化快。运营总监需要实时掌握业务现状，但经营数据分散在多个系统；一线运营和店长在新品发布、大促期需要实时掌握销售库存变化，延迟会导致补货不及时或库存积压；IT 需要打通电商、门店、库存、会员等多系统，关键节点的实时性要求高，离线数仓满足不了。FDL 5.0 打通这些系统，支撑销售实时大屏、库存实时监控。

民生行业（电力、园区、能源），设备点位分散、数量多。园区负责人缺乏实时数据支撑，异常用量发现不及时；运维和能源管理员面对大量设备点位，采集不及时导致漏采和异常滞后；IT 需要接入大量设备数据，但设备类型多、接入方式不统一，维护难度高。FDL 5.0 接入大量设备数据，实时识别异常用量，触发预警。

五、为什么是"无需编码"：三个具体的门槛被拆掉了

"让实时计算无需编码"，拆开看，是拆掉了三个具体的门槛。

门槛一：引擎部署。 用 Flink 做实时计算，先要搞定集群部署、资源调度、运维监控。FDL 5.0 的自研引擎内置在平台里，开箱即用，这一层门槛被直接绕过了。

门槛二：代码开发。 Flink 的流处理逻辑要写 Java/Scala 代码，还要理解窗口、状态、水位线这些流处理概念。FDL 5.0 用界面化配置替代代码开发，开发人员拖拽节点、配置参数，就能完成流式转换。

门槛三：数据源接入。 制造业的 PLC、传感器走的是 MQTT 等协议，用 Flink 需要自己开发或对接开源 Connector。FDL 5.0 对 MQTT、Pulsar 等协议开箱即用，还重点支持信创名录前列的国产数据源——这些恰恰是 Flink 开源产品支持薄弱的环节。

三个门槛拆掉之后，实时计算从"需要一支专门团队"变成了"数据开发人员顺带就能做"的事。这不是说实时计算变得简单了，而是说 FDL 5.0 把那些重复的、工程性的、与业务无关的复杂度，都消化在了平台内部。

六、一个实例：从设备数据到实时大屏

用一个制造业场景，把上面的能力串起来。

某制造企业有多个生产基地，产线设备通过 PLC 采集数据，走 MQTT 协议上报。过去，这些设备数据只能落库后 T+1 处理，厂长看到的设备利用率、产量数据，永远是昨天的。

用 FineDataLink 5.0 搭建一条实时链路：

第一步，接入。 用 MQTT 输入节点，接入设备上报的实时数据，不需要额外开发 Connector。

第二步，处理。 用 JSON 解析节点解析设备上报的报文，用字段设置、计算列节点提取设备编号、产量、运行状态等关键字段，用过滤节点筛掉无效数据。

第三步，计算。 用分组汇总节点，按设备、按产线实时聚合产量和运行时长，算出实时设备利用率。如果需要更复杂的计算，切换到 FlinkSQL 节点。

第四步，输出。 把实时指标输出到分析型数据库，供 FVS 3D 大屏消费。厂长在大屏上看到的，是此刻正在发生的产量和设备状态，而不是昨天的报表。

第五步，联动。 当设备利用率低于阈值，实时任务触发下游的定时任务或预警流程，把异常推送给对应的工艺优化人员。

整条链路，从设备数据接入到实时大屏展示，再到异常预警，全部通过界面化配置完成，没有写一行代码。而如果某一步需要更复杂的计算逻辑，随时可以切换到 Flink 引擎，能力上限不受影响。

八、结语

实时计算的门槛，从来不在"计算"本身，而在"工程"——引擎部署、代码开发、数据源接入，这些与业务无关的复杂度，把实时计算挡在了大多数企业之外。

FineDataLink 5.0 的双引擎架构和可视化流式处理，做的正是拆门槛这件事：自研引擎省掉部署，可视化配置省掉代码，开箱即用的协议和数据源省掉对接。而 Flink 外置引擎的存在，保证了复杂场景的能力上限不被牺牲。

对正在犹豫"要不要上实时计算"的企业来说，这或许是一个新的选项：不用先养一支 Flink 团队，也能先把实时链路跑起来。等业务真的需要复杂计算时，再切到 Flink，也不迟。