本文首发于 Aloudata 官方技术博客:《1104 报表口径梳理:从 30 人天到 1.5 天的自动化实践》转载请注明出处。

摘要:本文深入探讨了金融监管报表(如1104报表)口径梳理的自动化实践。针对传统人工方式耗时数月、文档易过时的痛点,介绍了基于算子级血缘和行级裁剪技术的解决方案。通过主动元数据平台实现口径的自动化盘点、一键溯源与持续保鲜,可将盘点效率提升20倍,并支撑更广泛的数据治理与DataOps场景。

对于银行数据团队而言,1104、EAST等监管报表的口径梳理是典型的“效率黑洞”。传统人工扒代码的方式,一个复杂指标动辄耗费30人天,且文档与代码极易脱节。本文将解析如何通过算子级血缘技术,实现监管指标口径的自动化盘点与一键溯源,将效率提升20倍。

一、监管口径梳理的三大核心痛点

监管指标口径梳理的复杂性主要源于三个层面:

  1. 政策频繁变动:以2025/2026年1104制度升级为例,围绕“五篇大文章”等主题新增大量报表,数据团队需追溯新旧口径差异,工作量指数级增长。
  2. SQL逻辑深藏:加工逻辑常封装在数百行、多级嵌套的SQL或存储过程中。例如,“正常类贷款余额”的核心逻辑 WHERE 贷款状态 = ‘正常’ 深藏代码深处,必须人工逐行解读。
  3. 传统工具能力不足:市面报表自动化工具侧重于数据映射与生成,但对最底层的 “口径白盒化梳理”——即自动回答“指标由哪部分数据、经何条件计算得出”——无能为力,仍需大量人工介入。

真实成本:一个复杂指标从定位、理解到形成文档,常需数周甚至数月(约30人天)。成本高昂且易出错,一旦代码变更,手工文档立即失效,陷入“运动式治理”循环。

二、技术破局:为何传统血缘工具“看不清”过滤条件?

自动化口径梳理的核心挑战,在于精准解析 “指标具体由哪部分数据(符合什么条件)计算得出”。这要求工具必须能理解SQL中的WHERE、JOIN ON等过滤条件,而这正是传统血缘工具的“代际盲区”。

解析类型解析粒度解析准确率能否识别过滤条件对复杂SQL支持
表级血缘表级依赖高,但噪声大完全不能有限,链路易断裂
列级血缘字段映射通常 < 80%基本不能支持差,解析率骤降
算子级血缘算子级逻辑> 99%精准识别深度支持(存储过程等)

代际差距的本质:

  • 表级血缘:仅能回答“数据来自A表、B表”,无法知晓具体参与计算的数据部分,噪声巨大。
  • 列级血缘:能追踪字段映射,但无法理解 WHERE 贷款状态=‘正常’ 等关键筛选逻辑,面对复杂SQL和存储过程束手无策。
  • 算子级血缘:深入SQL执行的算子(Operator)层面,精准解析过滤(Filter)、连接(Join)、聚合(Aggregation)等具体操作。其伴生的 行级裁剪 能力,能自动剔除不满足条件的数据分支,是自动化、准确化提取口径的技术基石。

三、新模式:从“人工扒代码”到“一键溯源”

基于算子级血缘的主动元数据平台,可将监管口径管理从“事后人工补救”升级为“事中自动保鲜”。

  1. 自动化盘点流程
    平台连接各类数据源(如Hive, Spark, Oracle, DB2, GaussDB等)后,核心解析引擎主动扫描并深度解析所有数据加工任务(包括复杂的PL/SQL存储过程、动态SQL),自动构建覆盖全链路的 算子级血缘图谱,全程无需人工解读代码。
  2. 一键生成口径文档
    针对任意报表单元格,用户只需点击“溯源”。平台自动回溯完整加工路径,将多层嵌套的SQL逻辑“翻译”成清晰、可读的业务口径描述,并可直接导出为标准化文档。
  3. 核心能力支撑
  • 行级裁剪:评估上游变更影响时,平台自动识别下游指标依赖的过滤条件,仅对真正受影响的数据范围(如特定分行)进行预警,减少不必要评估范围 80% 以上。
  • 复杂逻辑全覆盖:深度适配DB2、Oracle等存储过程,解析准确率超 99%。
  • 持续保鲜机制:持续监控代码与调度日志。当逻辑变更时,血缘图谱自动更新并通知责任人,确保口径文档与生产代码实时同步,告别静态文档。

四、标杆实践:银行如何实现20倍效率提升?

头部金融机构的实践已验证,基于算子级血缘的自动化口径管理能带来可量化回报。

1、浙江农商联合银行:监管指标溯源与DB2存储过程解析。监管指标盘点从 数月缩短至8小时,人效提升 20倍;DB2存储过程血缘解析准确率达 99%。

2、杭州银行:构建全链路算子血缘,实现监管报送指标自动化盘点与保鲜。基于精准血缘,问题根因分析效率提升 40%。

案例启示:基于算子级血缘的自动化口径管理,是实现监管“指标溯源、血缘分析、线上化管理”的核心技术基石。它不仅应对当前1104、EAST等报表盘点难题,也为未来“一表通”穿透式数据底座等监管新要求提供底层能力支撑。

五、实施建议:从试点到全行推广

金融机构可采用“由点及面、价值驱动”策略,稳步构建企业级主动元数据能力。

1、试点场景选择:从痛点集中、价值易显化的场景入手,如:

  • 涉及“五篇大文章”的复杂1104专项报表。
  • EAST报送中加工链路长、人工成本高的重点指标。

2、价值验证指标:明确衡量标准,快速验证:

  • 效率提升:口径梳理耗时减少百分比(目标:70%-90%)。
  • 准确性:自动化口径文档与代码逻辑一致性(目标:>99%)。
  • 保鲜度:代码变更后,文档自动更新的时效性。

3、长期演进路径:

  • 横向扩展:从1104扩展到EAST、客户风险、反洗钱等全体系监管报送。
  • 纵向深化:从口径溯源,扩展到全链路变更影响分析、主动模型治理、DataOps协同,最终形成以主动元数据为核心的数据治理闭环。

常见问题 (FAQ)

Q1: 算子级血缘和列级血缘在1104报表场景下具体有什么区别?

算子级血缘能精准解析SQL中的WHERE过滤、JOIN条件等操作逻辑,自动回答“指标是基于哪部分数据(如‘贷款状态=正常’)计算的”,从而生成准确口径文档。列级血缘只能追踪字段映射关系,无法理解数据筛选逻辑,仍需大量人工解读代码。

Q2: 我们的1104报表加工逻辑大量使用DB2存储过程,能准确解析吗?

可以。该方案的核心优势之一就是对DB2、Oracle、GaussDB等数据库的存储过程(PL/SQL)进行了深度适配,解析准确率超过99%。无论是动态SQL、临时表还是多层嵌套逻辑,都能实现穿透解析。

Q3: 自动生成的口径文档,如何跟上监管政策变化和内部代码的频繁变更?

作为主动元数据平台,其血缘关系通过主动解析代码、日志等方式实时或准实时更新。当加工逻辑变更时,平台能自动重新解析并通知责任人。生成的口径文档是“活”的、与代码逻辑实时同步的视图,解决了传统静态文档“一发布即过时”的难题。

Q4: 除了1104报表,这套方案还能应用于其他监管报送场景吗?

完全可以。算子级血缘能力是通用的,目前已广泛应用于EAST报送、客户风险统计、人行大集中、反洗钱以及“一表通”穿透式数据底座建设等场景,实现“一份投入,多报送体系复用”。

核心要点

  1. 痛点本质:1104报表口径梳理的“效率黑洞”,根源在于传统工具无法穿透SQL中的行级筛选逻辑(过滤条件)。
  2. 技术代差:算子级血缘是突破该瓶颈的关键,其解析粒度(算子级)和准确率(>99%)远超表级、列级血缘,并能实现行级裁剪。
  3. 模式升级:基于主动元数据平台,实现了从“人工扒代码”到“一键溯源”的转变,并能确保口径文档随代码变更而持续保鲜。
  4. 已验证价值:标杆实践表明,该技术能将监管指标盘点效率提升 20倍(从数月到8小时),并支撑更广泛的DataOps与数据治理场景。
  5. 实施路径:建议从高价值监管报表试点入手,验证价值后,逐步构建企业级主动元数据能力中心。
    • *

本文详细技术原理、高清架构图及更多案例,请访问 Aloudata 官方技术博客原文:https://ai.noetl.cn/knowledge-base/1104-report-caliber-automa...

我们非常荣幸地宣布,AutoMQ 与 Aklivity 正式达成战略合作伙伴关系!共同致力于推进云原生实时数据基础设施的演进,助力企业深度释放实时数据的核心价值。

数字化转型全面加速,实时数据已成为商业创新与提升竞争力的核心。然而,传统的实时数据架构在多系统互联、数据安全保障以及成本控制等方面仍面临重重挑战。

AutoMQ 的无状态云原生 Kafka 平台现已深度集成 Aklivity 的多协议网关技术。此次战略合作结合了 AutoMQ 在打造低成本、高弹性 Kafka 解决方案方面的技术积累,以及 Aklivity 在多协议网关领域的领先能力,旨在赋能企业轻松打破系统孤岛,构建驱动业务持续增长的下一代应用程序。

关于 AutoMQ

AutoMQ 是市场上唯一一款原生运行在云对象存储之上的低延迟、无盘化 Kafka 平台。针对 Apache Kafka 在云原生时代面临的高成本、弹性差及运维复杂等顽疾,AutoMQ 在保持 100% 兼容 Kafka 协议的基础上,对存储层进行了彻底的重构。 通过采用计算与存储完全解耦的共享存储架构,AutoMQ 将 Kafka Broker 转变为无状态的计算节点。这一设计使企业能够在不牺牲性能的前提下,充分利用对象存储的可靠性与成本优势,并支持包括安全的BYOC以及自托管软件在内的多种部署模式。

100% Kafka 兼容性

完全兼容 Apache Kafka 协议与生态,支持从现有集群零停机迁移,无需任何代码修改。

基于 S3 的低延迟表现

完美融合了对象存储的无限扩展能力与块存储的高性能。通过独创的 WAL 卸载机制,AutoMQ 在将数据直接持久化至 S3 的同时,实现了个位数毫秒级的写入延迟(P99 < 10ms)。

云速级弹性体验

无状态 Broker支持计算资源秒级 Auto-Scaling。分区迁移耗时从数小时缩短至 1.5 秒,让集群扩容真正实现业务无感。

10 倍成本缩减

基于对象存储实现无限存储和按量付费,并通过多点写入架构彻底消除昂贵的跨可用区(AZ)数据复制流量,将资源闲置浪费降至最低。

关于 Aklivity

Aklivity 是 Zilla 数据平台的开发者,致力于打造专为实时流设计的云原生连接层,并全面遵循 AsyncAPI 标准。其核心目标是将原始基础设施转化为面向 Web、移动端、物联网及微服务的可治理、可发现的数据产品。 与脆弱的自定义胶水代码或笨重的连接器不同,Aklivity 采用了基于 Zilla 代理的无状态、声明式架构,支持多种协议(HTTP、SSE、MQTT、gRPC)直接与 Kafka 进行仲裁转换。这极大地简化了集成逻辑,并实现了外部客户端与后端拓扑的解耦。凭借“左移”治理模型和高性能非阻塞 I/O,Aklivity 在边缘端实现了原生契约校验与可靠的安全保障,为现代数据生态提供海量扩展能力。

无缝协议仲裁

Zilla 不再依赖脆弱的点对点集成和胶水代码,而是在标准客户端与以 Kafka 为后端的流之间提供原生协议仲裁。Web(HTTP/WebSocket/SSE)、移动端和物联网(MQTT/gRPC)客户端可以通过 Zilla 直接消费和生产实时数据,无需编写自定义连接器或部署 Sidecar。

基于 AsyncAPI 的契约驱动型流处理

Aklivity 通过定义严谨的 AsyncAPI 契约,将原始 Kafka 流转化为受治理的数据产品。契约成为了频道、Payload Schema 及访问语义的唯一事实来源——将 Topic 转化为团队可信赖的、具备版本控制的可复用接口。

解耦与无状态架构

作为专为云原生时代构建的平台,Zilla 充当了一个无状态数据面,将客户端与后端 Broker 拓扑完全解耦。这使得 AutoMQ 能够瞬间完成 Broker 缩容或分区重平衡,而无需强制前端客户端重新连接,从而构建起一个真正弹性、零停机的时间流处理技术栈。

AutoMQ × Aklivity:云原生流处理的无状态技术栈

AutoMQ 的无状态共享存储架构与 Aklivity 的流原生网关深度集成,实现了云原生数据架构的再次进化。通过将多协议中介与流存储层分离,该联合解决方案为云原生时代提供了无缝的连接性、极速弹性扩展能力以及更严谨的治理体系。

多协议中介:在边缘端扩展连接能力

Aklivity 的 Zilla 网关充当了 AutoMQ 的通用翻译器,使 Web (HTTP/SSE)、移动端和物联网 (MQTT/gRPC) 设备能够直接与 Kafka 集群通信,无需编写脆弱的胶水代码或自定义连接器。这种架构实现了前端客户端与后端拓扑的解耦:当 AutoMQ 进行即时分区重平衡或 Broker 扩缩容时,Zilla 能够为边缘设备维持稳定且无感的连接。

契约治理:强化安全与策略执行

该联合解决方案构建了从边缘到 VPC 的坚实安全边界。Aklivity 在网关层负责协议级治理,包括 AsyncAPI 契约校验、RBAC(基于角色的访问控制)以及审计日志。同时,AutoMQ 通过 BYOC 模式将数据面部署在用户自身的 VPC 内以确保数据隐私,并在计算与访问层全面支持端到端的 TLS/mTLS 加密。

架构创新:通过共享存储架构实现无状态效率

两款平台的协同效应通过从传统的无共享设计转向现代的共享存储架构,显著提升了流处理效率。AutoMQ 的无盘化、无状态架构将所有数据卸载至 S3,将 Kafka Broker 转化为纯粹的计算节点,实现秒级扩缩容。结合 Aklivity 轻量级的非阻塞 I/O 网关,企业能够获得一个真正的弹性流处理堆栈,极大地减少了传统有状态基础设施中常见的运维负担和跨副本复制限制。

展望未来

AutoMQ 与 Aklivity 将持续深化技术融合,共同驱动云原生实时数据基础设施的发展。双方将联手为全球企业提供成本更低、性能更强、更易运维且高度安全的实时数据流解决方案,加速数据驱动型应用与商业洞察的落地,共同构建开放、高效的云原生数据生态。

立即访问 AutoMQ 官网,了解下一代云原生 Kafka 的极致性能与成本优势:AutoMQ 官网

访问 Aklivity 官网,探索用于实时数据管理的多协议网关解决方案:Aklivity 官网

当越来越多企业把AI当作一个“插件”来用——比如加个智能质检模块、搭个预测性维护系统——我们其实离真正的智能化还很远。真正的工业AI原生企业,不是在现有流程上贴一层AI的皮,而是从根上重构了生产逻辑。它们不把AI看作辅助工具,而是视为企业运转的“数字细胞”,能自主感知、分析、决策、进化。这种转变,意味着企业从“人驱动系统”走向“系统自主运行”。这不是“AI+制造”,而是“制造即AI”。
从场景出发,而非从技术出发:原生企业的底层逻辑
很多所谓AI公司喜欢讲参数规模、训练数据量,但工业场景最不缺的就是技术名词,缺的是能真正解决问题的“持续进化能力”。工业AI原生企业的核心,是场景、数据与平台的三位一体。它们不追求“一招鲜”,而是构建一个能不断吸收现场反馈、自我迭代的生态。比如,一个质量归因智能体,如果只能在事后分析缺陷,那它只是个高级报表工具;但如果它能实时捕捉人机料法环的微小波动,在缺陷发生前就触发预警,甚至自动调整参数,那它就成了生产线上的“隐形工程师”。必须从底层打通MES、PLC、ERP,让数据在系统内自然流动。全球视野下的实践:中国原生企业的出海路径
在东南亚,中国车企的出海速度远超预期,但配套的智能化服务却常常滞后。广域铭岛敏锐地抓住了这个空档,在马来西亚和新加坡设立本地团队,不仅提供技术,更输出“中国智造”的运营逻辑。他们的“排产助手Agent”在一家马来西亚零部件厂落地后,将排产响应时间从24小时缩短至8分钟,年收益提升超500万元,这比单纯卖软件更让客户信服。该公司的胜出,不在于技术指标更高,而在于它更懂“中国式快节奏制造”如何在海外复制。它不是输出一个系统,而是输出一套“能自己生长”的智能生产力体系。这或许正是中国工业AI原生企业未来撬动全球市场的真正支点——不是靠规模,而是靠“生长性”。
相比之下,德国西门子的MindSphere虽然功能强大,但部署周期长、本地化响应慢;美国罗克韦尔的FactoryTalk虽在北美成熟,但在东南亚的语境下,缺乏对中小供应商的适配能力。

对比

本文档将深入解析 Apache SeaTunnel 支持的三大执行引擎:Zeta (SeaTunnel Engine)FlinkSpark。我们将从架构设计、核心特性、优缺点对比以及使用方法等多个维度进行详细讲解,帮助你根据业务需求选择最合适的引擎。

1. 引擎概览

SeaTunnel 的架构设计采用了 API 与执行引擎解耦 的策略。这意味着同一套数据同步逻辑(Config)可以无缝运行在不同的引擎上。

  • Zeta Engine: SeaTunnel 社区专门为数据集成场景自研的新一代引擎,专注于高性能、低延迟的数据同步。
  • Flink Engine: 利用 Flink 强大的流处理能力,适合已拥有 Flink 集群的用户。
  • Spark Engine: 利用 Spark 强大的批处理能力,适合离线大规模数据处理场景。

2. Zeta 引擎——核心推荐

Zeta 是目前 SeaTunnel 社区主推的默认引擎。它旨在解决 Flink/Spark 在简单数据同步场景下“资源消耗大、部署运维重”的问题。

2.1 核心架构

Zeta 采用无中心化(Decentralized)或 Master-Slave 架构(取决于部署模式),主要包含以下组件:

  • Coordinator (Master):

    • 作业解析: 将逻辑 DAG (Logical DAG) 转换为物理 DAG (Physical DAG)。
    • 资源调度: 管理 Slot,向 Worker 分配任务。
    • Checkpoint Coordinator: 负责触发和协调分布式快照(基于 Chandy-Lamport 算法),保障数据一致性。
  • Worker (Slave):

    • Task Execution: 运行 Source, Transform, Sink 任务。
    • Data Transport: 负责节点间的数据传输。
  • ResourceManager: 支持 Standalone, YARN, Kubernetes 等多种资源管理模式。

SeaTunnel Engine

2.2 关键特性

  1. Pipeline 级容错 (Pipeline-level Fault Tolerance):

    • 不同于 Flink 的“全图重启”,Zeta 可以只重启失败的 Pipeline(例如多表同步中,表 A 失败不影响表 B)。
  2. 增量快照 (Incremental Checkpoint):

    • 支持高频 Checkpoint,最小化数据丢失风险,同时对性能影响极小。
  3. 动态扩缩容 (Dynamic Scaling):

    • 支持在作业运行时动态增加或减少 Worker 节点,无需重启作业。
  4. Schema Evolution (表结构变更):

    • 原生支持 DDL 变更同步(如 Add Column),这对 CDC 场景至关重要。

2.3 使用指南

Zeta 引擎通常包含在 SeaTunnel 的二进制包中,开箱即用。

启动命令 (Local 模式 - 开发测试):

./bin/seatunnel.sh --config ./config/your_job.conf -e local

启动命令 (Cluster 模式 - 生产环境):

  1. 启动 Server (Master/Worker):

    ./bin/seatunnel-cluster.sh -d
  2. 提交任务到集群:

    ./bin/seatunnel.sh --config ./config/your_job.conf -e cluster

3. Flink 引擎

flink-1_highres

SeaTunnel 通过翻译层(Translation Layer)将内部的 Source/Sink API 适配为 Flink 的 SourceFunction / SinkFunction (或 Flink 新版 Source/Sink API)。

3.1 架构原理

  • Translation: SeaTunnel 在 Client 端将 Config 解析并翻译成 Flink JobGraph。
  • Execution: 提交给 Flink Cluster 执行。此时,SeaTunnel 任务就是一个标准的 Flink 任务。
  • State Backend: 依赖 Flink 的 Checkpoint 机制(RocksDB/FsStateBackend)管理状态。

3.2 优缺点

  • 优点: 生态成熟,运维工具丰富,适合复杂的流式计算+同步场景。
  • 缺点: 版本耦合严重(需适配 Flink 1.13-1.18 等不同版本),对于纯同步任务显得过重。

3.3 使用指南

需要下载对应的 seatunnel-flink-starter jar 包,并确保 Flink 环境已准备好。

启动命令 (Flink 1.13+):

./bin/start-seatunnel-flink-13-connector-v2.sh \
    --config ./config/your_job.conf \
    --run-mode run # 或 run-application

(注意:不同 Flink 版本脚本名称略有不同,如 flink-15, flink-18)

4. Spark 引擎

spark

类似于 Flink,SeaTunnel 将 Source/Sink 适配为 Spark 的 DataSource V2 API。

4.1 架构原理

  • Batch: 使用 Spark RDD / DataFrame API 执行离线批处理。
  • Streaming: 使用 Spark Streaming (Micro-batch) 执行流式处理。

4.2 优缺点

  • 优点: 批处理性能强大,在大规模离线数据清洗/ETL 场景表现优异。
  • 缺点: 流处理基于微批(Micro-batch),延迟通常高于 Flink/Zeta;资源调度较慢。

4.3 使用指南

需要下载对应的 seatunnel-spark-starter jar 包。

启动命令 (Spark 3.x):

./bin/start-seatunnel-spark-3-connector-v2.sh \
    --config ./config/your_job.conf \
    --master local[4] # 或 yarn, k8s

5. 三大引擎全方位对比

特性Zeta (SeaTunnel Engine)Flink EngineSpark Engine
定位数据同步专用通用流批计算通用批流计算
适用场景海量数据集成、CDC 实时同步、多表整库同步复杂流式计算 + 同步大规模离线清洗、ETL
部署复杂度 (内置,开箱即用)中 (需维护 Flink 集群)中 (需维护 Spark 集群)
资源消耗 (针对同步优化,无多余开销)中/高中/高
延迟 (实时流)低 (实时流)中 (微批)
容错粒度Pipeline 级 (局部重启)Job 级 (全局重启)Stage/Task 级
CDC 支持完美 (支持 Schema Evolution)良好一般
多版本适配无需适配 (自带)需严格匹配 Flink 版本需严格匹配 Spark 版本

6. 如何选择?

  1. 如果你是新项目,或者主要需求是数据同步 (Data Integration):

    • 👉 首选 Zeta 引擎。它最轻量、性能最好,且对 CDC 和多表同步有特殊优化。
  2. 如果你已经有现成的 Flink/Spark 集群,且运维团队不想维护新引擎:

    • 👉 选择 FlinkSpark 引擎,复用现有基础设施。
  3. 如果你的任务包含极其复杂的自定义计算逻辑 (Complex Computation):

    • 👉 优先考虑 Flink (流) 或 Spark (批),利用其丰富的算子生态。但也可以考虑 Zeta + SQL Transform 满足大部分需求。

7. 新手入门指南

如果你是第一次接触 SeaTunnel,请按照以下步骤快速体验 Zeta 引擎的强大功能。

7.1 环境准备

确保你的机器上安装了 Java 8 或 Java 11。

java -version

7.2 下载与安装

  1. 下载: 从 Apache SeaTunnel 官网 下载最新版本的二进制包 (apache-seatunnel-x.x.x-bin.tar.gz)。
  2. 解压:

    tar -zxvf apache-seatunnel-*.tar.gz
    cd apache-seatunnel-*

7.3 安装 Connector 插件 (重要!)

这是新手最容易忽略的一步。默认包不包含所有 Connector,你需要运行脚本自动下载。

# 自动安装 plugin_config 配置文件中定义的所有插件
sh bin/install-plugin.sh

7.4 快速运行第一个任务

创建一个简单的配置文件 config/quick_start.conf,将数据从 Fake 源生成并打印到控制台:

env {
  execution.parallelism = 1
  job.mode = "BATCH"
}

source {
  FakeSource {
    result_table_name = "fake"
    row.num = 100
    schema = {
      fields {
        name = "string"
        age = "int"
      }
    }
  }
}

transform {
  # 简单的 SQL 处理
  Sql {
    source_table_name = "fake"
    result_table_name = "sql_result"
    query = "select name, age from fake where age > 50"
  }
}

sink {
  Console {
    source_table_name = "sql_result"
  }
}

运行任务 (Local 模式):

./bin/seatunnel.sh --config ./config/quick_start.conf -e local

如果看到控制台输出了数据表格,恭喜你,你已经成功掌握了 SeaTunnel 的基本用法!

8. Zeta 引擎原理深度学习路径

如果你希望深入了解 Zeta 引擎的内部运作机制,或者想参与社区贡献,可以按照以下路径进行源码阅读和调试。

8.1 核心模块概览

Zeta 引擎的代码主要集中在 seatunnel-engine 模块下:

  • seatunnel-engine-core: 定义了核心数据结构(如 Job, Task)和通信协议。
  • seatunnel-engine-server: 包含了 Coordinator 和 Worker 的具体实现逻辑。
  • seatunnel-engine-client: 客户端提交逻辑。

8.2 源码阅读推荐路径

1. 作业提交与解析 (Coordinator 侧)

JobMaster 类开始,了解作业是如何被接收和初始化的。

  • 入口: org.apache.seatunnel.engine.server.master.JobMaster
  • 逻辑: 关注 initrun 方法,了解 LogicalDagPhysicalPlan 的转换过程。

2. 任务执行 (Worker 侧)

了解 Task 是如何被调度和执行的。

  • 服务入口: TaskExecutionService.java

    • 该类负责管理 Worker 节点上的所有 TaskGroup。
  • 执行上下文: org.apache.seatunnel.engine.server.execution.TaskExecutionContext

3. Checkpoint 机制 (核心难点)

Zeta 的快照机制是保证数据一致性的关键。

8.3 调试技巧

  1. 修改日志级别: 在 config/log4j2.properties 中,将 org.apache.seatunnel 的级别调整为 DEBUG,可以看到详细的 RPC 通信和状态变更日志。
  2. 本地调试: 在 IDE 中直接运行 org.apache.seatunnel.core.starter.seatunnel.SeaTunnelStarter 类,传入 -c config/your_job.conf -e local 参数,即可断点调试整个流程。

作者:Prabakaran Thirumalai,MySQL 服务器运行时咨询成员技术人员。

原文:https://blogs.oracle.com/mysql/no-more-hidden-changes-how-mys...,Jan 30, 2026

爱可生开源社区翻译,本文约 2700 字,预计阅读需要 9 分钟。

640 (87).webp

MySQL 通过重新思考外键约束和级联的管理方式,迈出了重要一步。MySQL 9.6 开始,外键检查和级联操作将由 SQL 引擎 直接处理,而非 InnoDB 存储引擎。这一改进解决了长期存在的变更跟踪、二进制日志复制和数据一致性方面的挑战,使 MySQL 在异构环境、变更数据捕获(CDC)管道和分析工作负载方面更加稳健。

1. InnoDB 中外键的先前工作方式

历史上,MySQL 在存储引擎层(特别是 InnoDB 数据库)强制执行外键约束和级联。其工作原理如下:

  • 外键级联:当对父表执行 DELETE 或 UPDATE 等语句时,InnoDB 会检查外键约束。如果定义了级联操作(例如 ON DELETE CASCADE ),InnoDB 会处理子表中相应行的更新或删除操作。
  • InnoDB 内部执行:所有级联操作均由 InnoDB 内部执行。SQL 引擎仅发起父级操作;所有对子表的依赖操作均由 InnoDB 管理。

    重要的是,这些子行更改对 SQL 层是不可见的。因此,在基于行的复制 (RBR) 模式下,InnoDB 内部执行的级联操作不会出现在 MySQL 二进制日志中。

  • 运行影响:由于这些变更对 SQL 引擎和二进制日志隐藏,下游系统(例如 CDC 管道和分析平台)可能无法检测到这些变更。这可能导致数据不一致、分析结果不可靠以及复制问题。

基于 InnoDB 的外键的局限性

随着 MySQL 部署规模和复杂性的增长,这种传统方法暴露出以下局限性:

  • 隐藏的数据更改:在 InnoDB 内部执行的级联父子更改对 SQL 层是不可见的,并且没有在更高级别上被捕获。
  • 系统日志不完整:二进制日志中经常缺少子行更改,导致复制和审计不完整。
  • 数据捕获差距:依赖二进制日志或完整变更历史记录的数据工具和下游系统无法始终跟踪与外键相关的每个更新或删除。
  • 复制风险: 在复杂的复制设置中,这些静默的更改可能会导致主服务器和副本之间的数据出现差异,从而导致操作上的挑战。

2. 新模型:SQL 引擎管理的外键强制执行

为了解决这些问题,MySQL 现在强制执行外键,并在 SQL 引擎内部管理级联操作。通过这项更改,父表和子表上的所有外键操作对 SQL 层都是完全可见的。

640 (88).webp

主要优势:

  • 完整日志记录:所有更改(包括级联更改)现在都可见、可审计,并完整记录在二进制日志中。
  • 可靠的复制:不再有隐藏的数据更改;复制现在更加值得信赖和准确。
  • 更佳的分析:数据采集和分析工具现在可以获得所有数据变化的完整、实时视图。
  • 创新基础:这种架构使得跨存储引擎扩展外键支持以及未来的复制和可观测性功能变得更加容易。

注意:对于除 InnoDB 之外的其他支持外键的存储引擎,强制执行和级联操作仍由相应的存储引擎管理。

性能比较

我们理解,对于考虑将外键强制执行机制从 InnoDB 迁移到 SQL 引擎的 MySQL 用户而言,性能是首要考虑因素。针对常见事务工作负载的大量基准测试证实,基于 SQL 引擎的外键强制执行和级联机制的性能与 InnoDB 方法 几乎完全相同。外键检查和级联的成本基本保持不变,因此 吞吐量和延迟方面没有出现任何可观察到的下降。 这使得即使在高吞吐量和关键任务部署中,采用新的实现方案也是安全的。

向后兼容性

SQL 引擎的外键强制执行和级联机制旨在 完全向后兼容,保留 InnoDB 外键强制执行的语义和行为。虽然整体用户体验保持不变,但仍有一些值得注意的改进和细微的行为差异:

  • 错误信息:虽然错误代码与以前的版本一致,但由于检查执行顺序不同,具体的错误信息文本(包括外键名称)可能会有所不同。
  • 自增间隙:如果外键约束失败,任何尝试插入操作都会增加自增计数器,这可能会导致值出现间隙,符合 MySQL 的标准行为。
  • 针对级联行更新统计信息:行级统计信息(例如 delete_rows )已更新,以包含受级联外键操作影响的行。这确保系统统计信息能够准确反映外键强制执行所执行的所有数据更改。
  • 更严格的排序规则验证:如果外键级联跨越不兼容的排序规则,则会引发显式错误,防止出现 静默数据问题,并提高用户的数据完整性。

3. 安全采用并内置备用方案

为了实现可控的升级,MySQL 引入了一个只读的启动变量 innodb_native_foreign_keys。这提供了平滑的升级路径,并最大限度地减少了版本过渡期间的意外变更。默认情况下,此变量设置为 FALSE ,这意味着默认行为是基于 SQL 引擎的外键强制执行 。在测试环境或早期生产部署期间,您可以将此变量设置为 TRUE ,以暂时恢复到 InnoDB 的原生外键处理方式。这在验证新的 SQL 引擎行为时提供了一个清晰的操作回退方案。

注意: 此系统变量旨在帮助简化迁移,随着 MySQL 社区全面采用基于 SQL 引擎的外键,该变量将在未来的版本中移除。

4. 总结:为什么这项改变至关重要?

通过将外键强制执行移至 SQL 引擎,MySQL 弥补了长期存在的架构缺陷。这一改进确保数据变更始终可见、被记录和被复制,使 MySQL 成为更强大的平台,适用于现代化的分布式合规数据环境。

总的来说,对于 MySQL 用户而言,这意味着更好的数据一致性、更可靠的复制,以及在分析和合规工作流程中更少的意外情况,而不会牺牲性能。

群晖发布 DSM 更新修复 Telnetd 安全漏洞 即便未启用也可能影响安全性 https://ourl.co/111713?t
2026 年 2 月 3 日 09:25

目前没有任何证据表明该漏洞已经被利用

但实际情况是
cve: https://www.txone.com/blog/cve-2026-24061-gnu-inetutils-telnet-exploitation/

当天扫了一点进行测试 大部分设备都是群晖
完整的 root shell 访问权限
里面也是被 d 狗执行了 botnet

口说无凭 这是扫了挂针的:
28635.jpg
28635.jpg

只能说 都是公关大师 虽然是进行了强制升级 时间未免过得太长了。而且也是不承认被利用了漏洞。感觉和飞牛的处理方式没有太大差异

本文首发于 Aloudata 官方技术博客:《Aloudata CAN 指标平台落地周期与人力投入测算:从部署到全员使用要多久?》转载请注明出处。

摘要:本文基于 Aloudata CAN 在平安证券、麦当劳等企业的真实落地案例,详细测算 NoETL 指标平台的部署周期、人力投入与总拥有成本(TCO)。内容涵盖从环境部署、价值验证到全面推广的四阶段模型,对比传统模式与 NoETL 模式在人力结构、开发成本及基础设施成本上的核心差异,为数据架构师与采购决策者提供一套清晰的量化评估框架。

企业在采购指标平台时,最大的不确定性往往不是功能列表,而是落地周期和持续的人力投入。一个漫长的实施过程,不仅消耗预算,更会错失市场机会,导致项目价值大打折扣。

“国内 BI 市场中,传统厂商与现代化 BI 厂商的实施周期存在本质差异。传统 BI 因技术架构落后、依赖专业人才等问题,普遍面临‘长周期、低复用、业务难参与’的困境。” —— 行业分析报告

这种不确定性,在考虑自研时被进一步放大。行业分析指出,要打造一个具备基本语义解析和查询能力的原型,至少需要一个 5-8 人的资深团队,耗时 6-12 个月,而这仅能达到“可用”水平。因此,采购决策的核心,在于能否获得一个可预测、可量化的落地路径与成本模型。

认知校准:采购的不是“工具”,而是“开箱即用的数据服务”

许多企业将指标平台采购视为购买一个“工具”,预期需要大量二次开发、定制和漫长的集成。这是一个关键认知误区。

采购 Aloudata CAN 这类成熟的 NoETL 指标平台,本质是购买一套开箱即用的数据服务,其核心交付物是一个已经过验证的 “语义计算引擎” 和 “自动化指标生产流水线”。

维度传统“工具采购”模式Aloudata CAN “服务采购”模式
核心交付物软件安装包、API 文档语义计算引擎 + 自动化生产服务
实施重心代码开发、定制集成、适配现有流程业务模型声明、配置化定义、赋能新协作模式
技术依赖重度依赖内部数据开发团队平台专家赋能,业务分析师可自主操作
价值实现路径漫长、不确定,依赖内部能力快速、可预测,基于成熟方法论与案例

这种“服务”模式,将复杂的语义解析、SQL 生成、物化加速等底层技术封装为即用能力,从根本上决定了其快速落地的可能性。作为 Gartner 中国数据编织代表厂商,Aloudata CAN 的核心理念正是通过这种封装,让企业聚焦于业务价值而非技术实现。

落地周期四阶段模型:从部署到全员使用的清晰路径

基于众多标杆客户的实践,Aloudata CAN 的落地遵循一个可预测的四阶段模型。每个阶段都有明确的时间范围、核心任务和产出目标,为项目规划提供了清晰的路线图。

阶段一:环境部署与核心模型构建 (1-2 周)

  • 核心任务:完成平台部署,连接现有数据湖仓的 DWD 层数据,通过声明式策略构建核心业务事实表与维度的逻辑关联,形成虚拟业务事实网络的基础。
  • 人力投入:1-2 名数据工程师/架构师主导,与平台专家协作。
  • 产出:可用的语义层基础环境,支持初步的指标定义与查询验证。

阶段二:价值验证与指标敏捷开发 (1-2 个月)

  • 核心任务:选取 1-2 个高价值、痛点明确的业务场景(如销售日报、营销活动复盘)作为“灯塔项目”。在此场景下,完成主题指标沉淀,并与现有 BI 工具(如 FineBI, Quick BI)快速对接,产出可量化的价值报告。
  • 人力投入:形成 “136”协作模式——10% 的科技人员定义原子指标,30% 的业务分析师配置派生指标,60% 的业务用户开始使用。团队规模约 3-5 人。
  • 产出:可运行的业务报表/看板,明确的效率提升数据(如交付周期缩短),团队掌握新的工作方式。

    • 权威背书:某头部券商在价值验证阶段,2 周内即完成了 500+ 核心指标的开发与上线,快速证明了平台价值。

阶段三:全面推广与组织能力建设 (3-6 个月)

  • 核心任务:横向复制“灯塔项目”的成功经验至其他业务线(如财务、供应链、人力)。建立企业级的指标管理规范、审批流程与治理体系。
  • 人力投入:核心平台团队(2-3 人)负责运维、赋能与治理;各业务线的分析师自主进行指标开发与报表构建,需求无需向 IT 提排期。
  • 产出:覆盖企业核心业务的指标资产库,自助分析成为常态,数据文化初步形成。

阶段四:生态融合与价值深化 (持续)

  • 核心任务:将 Aloudata CAN 作为统一的指标服务基座,与 AI 平台、业务系统(如 CRM、ERP)深度集成,实现指标预警、智能归因、AI 问数等高级应用。
  • 人力投入:按需投入,平台已成为稳定的数据基础设施。

人力投入精细化测算:告别“人海战术”

NoETL 模式的核心价值之一是 “定义即开发”,这彻底改变了传统数据开发中“人海战术”的投入结构。人力重心从稀缺的、高成本的数据开发工程师,转向更贴近业务的数据架构师、治理专员和业务分析师。

初始投入期 (第 1-2 个月)
此阶段以平台部署和首个价值场景验证为核心,需要组建一个精干的联合团队:

  • 平台专家 (厂商/内部):1 人,负责技术部署、平台配置与团队赋能。
  • 数据架构师:1 人,负责数据模型设计、质量把控与逻辑关联声明。
  • 业务分析师 (种子用户):1-2 人,作为业务方代表,主导场景选择、指标定义与验收。

常态化运营期 (第 3 个月及以后)
平台稳定运行后,人力投入显著下降并趋于稳定:

  • 平台管理员:0.5 人(通常为兼职),负责日常监控、权限管理与基础运维。
  • 数据治理专员:0.5-1 人,负责指标规范制定、审核、资产目录维护。
  • 各业务线分析师:N 人(根据业务规模),完全自主进行指标定义、报表开发与数据分析,彻底摆脱对 IT 开发资源的依赖。

对比传统模式,人力结构发生了根本性转变。

TCO(总拥有成本)账本:显性成本与隐性收益

评估采购成本,绝不能只看软件许可费。一套科学的采购决策必须基于 总拥有成本(TCO) 分析,即计算从采购、实施到长期运营的所有成本,并对比其带来的效率提升与成本节约。

显性成本(容易计算)

  • 软件采购/订阅费用:根据数据规模、用户数等因素确定的许可费用。
  • 初期实施与培训投入:包括内部人员工时及可能的厂商服务费用。

隐性成本节约与收益(决定 ROI 的关键)
这部分是 Aloudata CAN 带来长期价值的核心体现,且已在客户案例中得到量化验证:

  1. 开发成本节约:通过“定义即开发”和智能物化,可减少 50%+ 的物理宽表与汇总表开发工作量。这将稀缺的数据工程师资源从重复的 ETL 开发中释放出来,转向更有价值的模型优化与数据产品创新。

    • 客户验证:某头部券商实现开发工作量减少 50%。
  2. 基础设施成本节约:智能物化加速引擎通过声明式策略自动生成最优物化表,查询时智能路由,用空间换时间。平均可帮助企业释放 1/3+ 的存算资源。

    • 客户验证:同一券商实现基础设施成本节约 50%。
  3. 业务决策效率收益:将分析响应周期从“数周”缩短至“天”甚至“分钟级”。更快的洞察意味着能更快抓住市场机会、规避风险,这部分商业机会价值虽难以精确量化,但影响深远。

    • 客户验证:某知名服饰品牌实现业务决策效率 10 倍提升。
  4. 风险成本规避:彻底解决因指标口径不一致导致的决策错误与部门扯皮。同时,完全规避了自研项目可能失败、延期或无法达到预期效果的技术与财务风险。

决策矩阵:您的企业适合采购 Aloudata CAN 吗?

通过以下四个关键维度的快速自评,可以帮助企业明确采购 Aloudata CAN 的紧迫性与适合度。

强烈建议采购(符合以下任一条件)

  • 业务变化快:市场策略、产品线、运营模式频繁调整,分析需求灵活多变。
  • 技术资源瓶颈:数据工程师资源紧张,业务取数、报表开发需求排期漫长,成为业务敏捷的瓶颈。
  • 数据治理挑战:存在多套 BI 工具或报表体系,指标口径混乱,“数据打架”现象严重。
  • 战略布局 AI:希望快速构建一个 AI-Ready 的数据底座,为未来接入大模型、构建数据分析智能体(Agent)打下坚实基础。

可以评估采购

  • 拥有一定规模的数据团队,但希望团队成员从低价值的 ETL 开发中解脱,聚焦于更高价值的数据建模、算法与产品创新。
  • 计划对传统数仓架构进行现代化升级,寻求“做轻数仓”的可行方案。

可能暂缓

  • 业务模式极其稳定,核心分析场景与报表模式数年不变。
  • 拥有极其充裕且成本极低的数据开发资源(现实中非常罕见)。

FAQ

Q1: 我们公司数据量很大(百亿级),Aloudata CAN 的部署和查询性能如何保证?

Aloudata CAN 采用智能物化加速引擎,基于用户声明的物化策略自动生成并维护多层加速表。查询时,语义引擎会自动进行 SQL 改写和智能路由,透明命中最优物化结果。在某全球连锁餐饮巨头的案例中,百亿级数据规模下,P90 查询响应时间小于 1 秒,P95 小于 3 秒,能有效支撑高并发分析场景。

Q2: 采购后,如何与我们现有的 FineBI/Quick BI 等报表工具集成?原有报表需要重做吗?

无需重做。Aloudata CAN 作为中立的 Headless 指标平台,通过标准 JDBC/API 提供统一指标服务。现有 BI 工具可直接连接 CAN 作为数据源,逐步将原来基于宽表的报表迁移至消费 CAN 的指标。这实现了平滑演进,既统一了底层口径,又保护了前端报表资产。

Q3: 采购平台的实施,对我们现有数仓(DWD/DWS 层)有什么影响?需要做大的改造吗?

无需大改造。Aloudata CAN 的核心优势是“做轻数仓”。它直接对接现有的 DWD 公共明细层数据,通过语义层构建“虚拟业务事实网络”,无需建设或可大量减少 DWS/ADS 层的物理宽表。您可以选择 “存量挂载、增量原生、存量替旧” 的三步走策略,渐进式优化数仓架构。

Q4: 如何衡量采购 Aloudata CAN 的投资回报率(ROI)?

ROI 可从三个维度量化:1) 效率提升:对比引入前后,单个指标或报表的平均交付周期缩短比例(如从 2 周→1 天)。2) 成本节约:计算因减少物理宽表开发、运维及释放的服务器资源所带来的直接成本下降。3) 质量与风险:评估因口径 100% 一致而减少的决策错误和沟通成本。建议在 POC 阶段就设定这些基线进行验证。

核心要点

  1. 采购本质是服务:采购 Aloudata CAN 是购买一套开箱即用的“语义计算引擎”和“自动化指标生产服务”,而非需要大量二次开发的工具,这是实现快速落地的前提。
  2. 周期清晰可预测:遵循“部署 -> 价值验证 -> 全面推广 -> 生态融合”的四阶段模型,首个业务价值可在 1-2 个月内验证,全面推广可在 3-6 个月内完成。
  3. 人力结构根本性转变:从依赖稀缺的“数据开发工程师”转向以“业务分析师”和“数据治理专员”为主导,实现业务的真正自助。
  4. TCO 显著优化:真正的价值在于隐性成本节约:开发成本降低 50%+,基础设施成本节约 1/3+,并规避口径混乱与自研失败的风险。
  5. 决策依据可量化:通过对比自研的高投入与长周期(5-8 人团队,6-12 个月),采购成熟 NoETL 平台在速度、成本与风险控制上,为绝大多数企业提供了更优的理性选择。
    • *

了解更多技术细节与最佳实践,请访问 Aloudata 官方技术博客原文:https://ai.noetl.cn/knowledge-base/aloudata-can-metrics-platf...

流式计算任务通常需要 7x24 小时长期运行,面对网络抖动、机器故障或代码 Bug,如何保证任务不挂?或者挂了之后能自动恢复且数据不丢、不重?这正是 Flink 引以为傲的资本:强大的状态管理基于 Checkpoint 的容错机制

本文将带你深入理解 Flink 是如何“记忆”数据的,以及它是如何在故障发生时“时光倒流”恢复现场的。

一、什么是状态(State)

在流计算中,数据是一条条流过的。如果处理一条数据时,需要依赖之前的数据(例如:计算过去一小时的总和、去重、模式匹配),那么这些“之前的数据”或“中间计算结果”就是状态

1. 状态的分类

Flink 的状态分为两大类:Managed State(托管状态)Raw State(原生状态)。我们日常开发 99% 使用的是托管状态,由 Flink 运行时自动管理内存、序列化和故障恢复。

Managed State 又细分为:

  • Keyed State(键控状态)

    • 只能在 KeyedStream(即 keyBy 之后)上使用。
    • 状态是跟 Key 绑定的。Flink 为每个 Key 维护一份独立的状态实例。
    • 常用类型:ValueStateListStateMapStateReducingStateAggregatingState
  • Operator State(算子状态)

    • 绑定到算子并行实例(SubTask),与 Key 无关。
    • 常用于 Source Connector(记录读取的 Offset)或 Sink Connector(事务控制)。
    • 常用接口:ListStateUnionListStateBroadcastState

二、状态后端(State Backends)

状态存在哪里?是内存还是磁盘?这由 State Backend 决定。在 Flink 1.13 之后,配置方式简化为以下两种主要模式:

1. HashMapStateBackend (基于内存)

  • 存储位置:Java 堆内存(Heap)。
  • 特点:读写速度极快(对象直接访问,无序列化开销)。
  • 适用场景:状态较小(例如仅仅是简单的 Count 或去重),对延迟极其敏感的场景。
  • 缺点:受限于 JVM 堆大小,容易 GC;状态过大时可能 OOM。

2. EmbeddedRocksDBStateBackend (基于磁盘)

  • 存储位置:TaskManager 本地磁盘(基于 RocksDB 数据库),内存中只作为缓存(Off-heap)。
  • 特点:支持超大状态(TB 级别),不受 JVM 堆限制。
  • 适用场景:超大窗口、超长周期的聚合、海量 Key 的去重。
  • 缺点:需要序列化/反序列化,读写性能略低于内存版;需要调优 RocksDB 参数。

3. 配置示例

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

// 设置状态后端为 RocksDB
env.setStateBackend(new EmbeddedRocksDBStateBackend());

// 配合 Checkpoint 存储路径(存储在本地文件系统)
env.getCheckpointConfig().setCheckpointStorage("file:///tmp/flink/checkpoints");

三、容错核心:Checkpoint

Checkpoint(检查点)是 Flink 容错机制的灵魂。它是一个全局一致性快照,定期将所有算子的状态持久化到远程存储(如 HDFS)。

1. 核心原理:Barrier 对齐

Flink 使用 Chandy-Lamport 算法 的变体。

  1. Barrier 注入:JobManager 向 Source 发送 Checkpoint Barrier。
  2. Barrier 流动:Barrier 像普通数据一样在流中传输。
  3. 对齐(Alignment):当算子有多个输入流时,必须等待所有流的 Barrier 到齐,才能进行 Snapshot。这保证了状态的一致性(即 Exactly-Once)。
  4. 异步快照:算子将状态写入远程存储(异步过程),不阻塞数据处理。
  5. 确认完成:所有算子都完成快照后,JobManager 确认 Checkpoint 成功。

2. Checkpoint 配置实战

默认情况下 Checkpoint 是关闭的,生产环境必须开启

// 1. 开启 Checkpoint,每 5000ms 触发一次
env.enableCheckpointing(5000);

// 2. 设置 Checkpoint 模式(默认 EXACTLY_ONCE,也可以设为 AT_LEAST_ONCE)
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);

// 3. 设置两次 Checkpoint 之间的最小间隔(防止频繁 Checkpoint 导致性能下降)
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(1000);

// 4. Checkpoint 超时时间(默认 10分钟)
env.getCheckpointConfig().setCheckpointTimeout(60000);

// 5. 允许同时进行的 Checkpoint 数量(通常设为 1)
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);

// 6. 开启作业取消时保留 Checkpoint(非常重要!否则 Cancel 任务会删除 Checkpoint)
env.getCheckpointConfig().setExternalizedCheckpointCleanup(
    CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION
);

// 7. 容忍 Checkpoint 失败次数(默认 0,即 Checkpoint 失败会导致任务重启)
env.getCheckpointConfig().setTolerableCheckpointFailureNumber(3);

四、Savepoint:手动的超级 Checkpoint

虽然 Checkpoint 和 Savepoint 看起来很像(都是快照),但它们的定位完全不同:

特性CheckpointSavepoint
触发方式Flink 定时自动触发用户手动命令触发
主要目的故障恢复(Failover)运维操作(升级、扩容、迁移)
存储格式增量存储(依赖 StateBackend 优化)标准格式,全量存储(可跨版本)
生命周期随作业生命周期管理(除非设置保留)用户自行管理(删除需手动)

常用命令

# 触发 Savepoint
bin/flink savepoint <jobId> [targetDirectory]

# 从 Savepoint 重启作业 (或者 Checkpoint)
bin/flink run -s <savepointPath> ...

五、重启策略(Restart Strategies)

当任务发生故障(Exception)时,Flink 会尝试根据配置的策略自动重启。

// 1. 固定延迟重启(尝试 3 次,每次间隔 10秒)
env.setRestartStrategy(RestartStrategies.fixedDelayRestart(
    3, 
    Duration.ofSeconds(10)
));

// 2. 失败率重启(在 5 分钟内失败超过 3 次则停止,否则每次间隔 10秒重启)
env.setRestartStrategy(RestartStrategies.failureRateRestart(
    3, 
    Duration.ofMinutes(5), 
    Duration.ofSeconds(10)
));

// 3. 无重启(直接失败)
env.setRestartStrategy(RestartStrategies.noRestart());

六、总结

  • State 是 Flink 实现复杂逻辑的记忆。
  • State Backend 决定了记忆存哪里(内存快但小,RocksDB 大但需序列化)。
  • Checkpoint 是自动化的定期备份,保证故障恢复后的数据一致性。
  • Savepoint 是手动的高级备份,用于版本升级和应用迁移。

掌握了状态与容错,你的 Flink 任务才算真正具备了“生产级”的健壮性。下一篇,我们将探讨 Flink SQL,看看如何用 SQL 解决 80% 的流计算需求。


原文来自:http://blog.daimajiangxin.com.cn

源码地址:https://gitee.com/daimajiangxin/flink-learning

在视觉语言模型(VLMs)的发展进程中,文档 OCR 始终面临着布局解析复杂、语义逻辑对齐等核心挑战。传统模型大多采用固定的 「左上到右下」 栅格扫描顺序处理视觉 token ,这种刚性流程与人类视觉系统遵循的语义驱动型扫描模式相悖,尤其在处理含复杂公式、表格的文档时,容易因忽视语义关联导致解析误差。如何让模型像人类一样 「读懂」 视觉逻辑,成为提升文档理解能力的关键突破口。

近期,DeepSeek-AI 推出的 DeepSeek-OCR 2 给出了最新答案。其核心是采用全新 DeepEncoder V2 架构:模型摒弃传统 CLIP 视觉编码器,引入 LLM 风格的视觉编码范式,通过双向注意力与因果注意力的融合,实现视觉 token 的语义驱动式重排,为 2D 图像理解构建出一条「双阶段 1D 因果推理」的新路径。


DeepEncoder V2 的关键创新体现在四个方面:

  • 以 Qwen2-0.5B 紧凑型 LLM 替代 CLIP,在约 5 亿参数规模下赋予视觉编码因果推理能力;
  • 引入与视觉 token 数量等长的「因果流查询(Causal Flow Query)」,通过定制注意力掩码,使视觉 token 保持全局感知,同时允许查询 token 基于语义重组视觉顺序;
  • 支持 256–1,120 个视觉 token 的多裁剪策略,在兼顾效率的同时对齐主流大模型的 token 预算;
  • 通过「视觉 token  + 因果查询」的串联结构,将语义重排与自回归生成解耦,天然适配 LLM 的单向注意力机制。

这一设计有效消除了传统模型的空间顺序偏见,使模型能够像人类阅读一样,依据语义关系动态组织文本、公式与表格,而非传统机械遵循像素位置。

经验证,在 OmniDocBench v1.5 基准测试中,DeepSeek-OCR 2 以 1,120 的视觉 token 上限,实现了 91.09% 的整体准确率,较前代模型提升 3.73%,同时将阅读顺序编辑距离(ED)从 0.085 降至 0.057,证明其视觉逻辑理解能力显著增强。细分任务中,公式解析准确率提升 6.17%,表格理解性能提升 2.5%-3.05%,文本编辑距离减少 0.025,各项核心指标均实现跨越式进步。

同时,其工程实用性同样突出:在保持 16 倍视觉 token 压缩率的前提下,在线服务的重复率从 6.25% 降至 4.17%,PDF 批量处理重复率从 3.69% 降至 2.88%,兼顾了学术创新与产业应用需求。相较同类模型,DeepSeek-OCR 2 以更低的视觉 token 成本,达到了接近甚至超越大参数模型的效果,为资源受限场景下的高精度文档 OCR 提供了更具性价比的方案。

目前,「DeepSeek-OCR 2:视觉因果流」已上线至 HyperAI超神经官网的「教程」板块,点击下方链接即可体验一键部署教程 ⬇️

教程链接:https://go.hyper.ai/2ma8d

查看相关论文:https://go.hyper.ai/hE1wW

效果展示:


Demo 运行

1.进入 hyper.ai 首页后,选择「教程」页面,或点击「查看更多教程」,选择「DeepSeek-OCR 2 视觉因果流」,点击「在线运行此教程」。

2.页面跳转后,点击右上角「Clone」,将该教程克隆至自己的容器中。

注:页面右上角支持切换语言,目前提供中文及英文两种语言,本教程文章以英文为例进行步骤展示。

  1. 选择「NVIDIA GeForce RTX 5090」以及「PyTorch」镜像,按照需求选择「Pay As You Go(按量付费)」或「Daily Plan/Weekly Plan/Monthly Plan(包日/周/月)」,点击「Continue job execution(继续执行)」。

HyperAI 为新用户准备了注册福利,仅需 $1,即可获得 20 小时 RTX 5090** **算力** **(原价 $7), 资源永久有效。

4.等待分配资源,当状态变为「Running(运行中)」后,点击「Open Workspace」进入 Jupyter Workspace。


效果演示

页面跳转后,点击左侧 README 页面,进入后点击上方 Run(运行)。

待运行完成,即可点击右侧 API 地址跳转至 demo 页面。

以上就是 HyperAI超神经本期推荐的教程,欢迎大家前来体验!

教程链接:https://go.hyper.ai/2ma8d

又是新的一趟周末之旅!这次来到了山东济南,在夏日炎炎时就时常刷到济南的泉水咕咕往上溢出,甚至多年不再出水的泉口也都开始一起「咕咕咕」,漫步在济南古城里也确实感受到了所谓「小江南」的感觉,甚至还恍惚中以为到了丽江。

后来查了资料才知道济南居然也是「中国软件名城」,再一细看,大名鼎鼎的浪潮集团就诞生于这里。

又是周末

这是我第二个周末城市游了。之前在 23 疫情放开后的年初浪了一段时间,浪到后面已经彻底提不起劲了,一直歇到了五一假期才缓过来。

这回主要是想模拟下 ddl 到期之后的生活方式,在那个时间节点往后,自己会有相当长的一段时间会保持这种漂浮在世界各地的旅行状态。当然可能会先聚焦在中国大地上。除了想进一步了解自己的祖国,更想仔细看看生活在这片广袤无际土地上的这群人。

这次选择了济南,则完全是因为开头所说的,夏天时经常会刷到说济南好多泉眼恢复,甚至多年枯竭的泉眼也都开始冒水、甚至漫到路面上来。我还没怎么见过咕咕往外冒水的泉眼。好几次高铁南下时从济南西站路过但都未曾停留,这次准备好好领略一番泉城风貌。

从北京南站出发一路南下,刚过房山就迎来了阵阵浓雾,刚开始浓雾还不算大,顶部能看到一些蓝天的样子。随着高铁列车往河北省境内腹地开去,雾气越发浓密,起初只是感觉到有浓雾袭来,随后是远处的画面有些不清晰,再到后面窗外铁路栏杆都已然模糊了。此景让我回忆起了 16 年底第一次南下去武汉参加比赛,也是坐在高铁动车上,也是一模一样的浓雾,唯一的不同是那时还伴随着呛鼻的味道,后来实在是呛得受不了只能在座位上戴着口罩,画面很是魔幻。

查了下天气才发现,原来每到秋冬季节,只要遇到没有气流影响的无风天气,河北平原这一大片地方就必然会有大雾。加上省内大量的工业区、燃料、焚烧等排放,稍不注意就会出现这次我所见到的画面。

不过本来上车时还挺困,毕竟是早上 8 点出头的高铁,看到窗外这浓厚的雾霾画面,心里的思绪也慢慢飘动了起来。

济南古城

将近 10 点,我到达了济南西站。

济南的天气不错,完全没有受到河北省内的大雾霾天气影响,进入山东德州发现天气没有好转时,我还在担心这次自己会不会在茫茫大雾中前进。好在完全没有影响。

或许是这几次周末之行去的都是周边省城,我觉得济南的物价也不低。为了在走了一天的劳累之后不影响晚上的整体睡眠质量,我选择了华住会旗下的你好酒店,虽然和全季系列不能混为一谈,但价格也来到了 240 元的区间,还是有些小小的肉疼。唯一安慰到自己的是地理位置还不错,济南古城南边的泉城广场继续往南 200 米就到了。达到酒店时也无需等待,直接就入住了,看到房间环境后也算测试出了结论——以后的酒店标准还可以再低一些。

泉城广场比较正常,中规中矩的一个城市广场,有大家都有的广场舞,也有大家都有的下沉商业街,甚至还有招婚启示。招婚启示我重点看了下,条件写得都很好,业余兴趣爱好都不错,都很年轻基本上都是 92、93 年,工资也不低大概七八千,甚至也都是现在人见人爱的公务员、老师之类的行业……看越感觉自己貌似不太配来逛,看着如此优秀的条件心想如果要讲究传统的「门当户对」,这年头凑一对儿也太难了点。

泉城广场的西边就是趵突泉,在走向趵突泉南门的路上远远望去,会发现泉水如黑洞一般吸附着一片人群。估计这泉里得有不少游客。门票 40 元,最终整体体验下来不算贵,园区整体除了趵突泉泉眼附近的那一小片地方非常拥挤,其余地方倒也还好。为了吸引游客泉水中放养了大量的锦鲤,前段时间也经常刷到安保提醒游客不要再喂鱼了,都胖得都快游不动了。另外如此脆弱的、长时间存在的自然景观,济南政府必然也会给这个「天下第一泉」大量的补贴,要不然真的有可能我们这一代人都见不到了。

趵突泉景区里有大量园林造景,慢慢走慢慢逛,不经意间就会发现一片阳光洒在湖面上,照射出湖底的绿植和锦鲤,这一抹红绿相间的画面确实让历史上趵突泉的美都重叠了起来,我的屁股就反复地在这个湖边坐坐、在那个湖边蹭蹭,这个过程中观察到的结果是,貌似游人们都很难有静下心来「观赏」眼前事物的想法,听到最多的是「哦哟,这个鱼真大也」,「这个水真清楚啊」,「这个景不错」等。我想看看他们下一步会怎么对待自己发出的这些感叹和赞美,但事实是大家都匆匆拍张照或者边走边说,也就这么经过了。

仔细回想了下自己好像从未有过这种「经过」的状态,可能是从小就没怎么旅行过,都是上了大学出了社会才慢慢的、逐步的去触碰这个真实的世界,也有可能其他人都习以为常了,并不觉得眼前的景色如何。但我就是感觉可惜,我们本应该可以借此发展出下一步,更进一步的去描绘出眼前的画面,它的来源、它为何美、它让自己感受到了什么。长久以往,我们自己就会有一套感受美的方法论和体验美的方式,往大了说,群体和民族的审美也就出来了。

我们的审美是有的,但那些都太宏大了,落到个人身上,其实绝大部分人都不知何为「美」,我是最近这几年通过摄影这个方式绕了一个大弯才了解到何为美,因为我总想让自己拍出来的照片更有深度更有美感。虽然我不追求决定性瞬间,但我想在一张照片一副画面里表达出一些东西来。这些事情是需要对美的感知和理解来支撑的。

在趵突泉的北门有一处游船点,本来还纳闷为什么没人排队,走上前一问原来今天从趵突泉出发,甚至是济南古城里的所有游船都没票了。这是跑在古城水道上的游船,不是公园里的那种游船。

略微失望地走出景区,趵突泉北门外对面就是五龙潭,但我还在回味趵突泉,不想这么快的就衔接下一个泉,好在看到有一家鲁菜馆人气很旺,便走上前拿了个号。只是没想到一个人吃饭也得等 9 桌,估摸着这也得等一小时了,稍加思索后还是决定午饭延后,先逛了五龙潭。

五龙潭的人流量对比趵突泉骤减,虽泉水的姿色不如趵突泉那么粗狂,但如果你对泉水喷涌之景并无念想,只是想看看泉水是怎么一回事,那和趵突泉隔着一条马路的它就是最佳选择。

五龙潭里有一片很大的湖,如果你并不急着赶路,完全可以用半小时时间喝一次大碗茶。我本身对茶没有想法,再加上也不愿意用静态的方式来看动态的泉水,更喜欢多个角度和层次观察,也就作罢。另外五龙潭本身是免费的,园子里有大量的亲水区域供小朋友玩耍,水质远比各种水上乐园甚至泳池里的水来得放心,看到了好几个小朋友就这么光着脚踩在水里,甚至还有更小的小朋友直接就趴在了水里。

只不过秋天的济南还是有些凉意,可以想象出来五龙潭的夏天是多么的热闹了。

在五龙潭待的时间不长,不到一个小时就出来了,主要是肚子也饿了。原计划是沿着去往大明湖的路边随便找一家饭馆对付两口完事,只是没想到这一路上的饭馆并不多,好不容易找到的一家推门而入居然也已人满为患,站了许久都不见服务员上前来招呼,也就出门继续找下一家饭馆。最终找到了一家看着还算有些高档的饭馆,再次推门而入找了个位置坐下,把几大特色菜——把子肉、九转大肠、糖醋黄鱼、奶汤蒲菜统统都点了。

实际上吃下来只有把子肉是真的香,期待了很久的九转大肠是最意外的难吃,不确定是九转大肠就是这种甜臭味儿还是这家饭馆做的不行,一个小砂锅总共 9 个大肠,本身这道菜价格就不便宜,我硬是咬着牙吃到了只剩下最后一个,吃最后一口大肠时差点没忍住想把嘴里的这一大坨全吐出来,反正以后都不会再吃了;糖醋黄鱼端上来时我马上就闻到了一股奇怪的、类似脚臭的酸味儿,服务员只是端上桌问我拍不拍照这一会儿 5 秒钟的时间,这股酸味儿久久不能散去,胃口骤减一半。我一直以为醋是有独特的、开胃的香味,而不是今天这饭酸臭味儿。

但最后都吃得差不多了,但一结账这四道菜和一碗白米饭收了我 291 元实在是不甘心啊!蹲一个有缘人能够让我对鲁菜有改观,要不然可能以后都要绕着走了。吃饱喝足从饭馆走出来后我胃就不舒服,不是那种反胃的想吐,而是一种像是吃错东西了的想吐,一直顶在胃顶部很难受,最后在大明湖里走了差不多半个多小时,大量的喝水才缓过来。

大明湖就在饭馆前面不远的地方,我对大明湖的初印象只有「大明湖畔边的夏雨荷」,甚至都清楚这句话到底来自哪里,在 vlog 中以为是当年乾隆下江南时真的遇到了夏雨荷,真的和夏雨荷发生了什么故事,实际上完全只是《还珠格格》里虚假出来的桥段,十分尴尬。

大明湖的确实不小,个人觉得和颐和园相比面积差不了太多,但颐和园的「可去度」完全没有大明湖这么亲民。每次去颐和园总觉得是个事,不像大明湖这样有饭后遛弯儿似的随意。

大明湖整体呈东西走势,最东边有一座超然楼,可登顶望远济南城区面貌,我原意确实是想登顶一探究竟,但一想到隔日要去千佛山,目之所及之处比超然楼更大更远也就作罢。除了一大片的湖面陆上也有大量的造景,穿梭在亭台楼阁和小桥流水间,除了游人确实有点多,难以静下心来细细琢磨这大明湖的历史,也不失为一个散步的好去处。

我从南门进入,绕了整整一圈再次回到了南门附近,从这个岔路口出去马路对面曲水亭街,真正的济南古城中心区。

曲水亭街这附近给我一种非常强烈的江南水乡之景,甚至搭配着路边的小酒吧,真有丽江的感觉了,怪不得济南也会有被称为「小江南」。在曲水亭街越往南走,这种江南之景越发动人,如果专门挑一个工作日或者淡季时间来慢慢的走一走,一定会特别惬意、特别舒服。只是今天这古城里古装拍照的小姐姐们实在是太多了,几乎每一个景色还算可以的转角都被旅拍的人群占满,游玩体验不高,只能寄希望于未来有机会可以挑一个合适的时间再来仔细看看了。

曲水亭街再往南到芙蓉街附近就进入了古城里,也来到了我今天遇到的第一条小吃街。初高中高中那几年我非常喜欢去小吃街,甚至每次周末了就冲着小吃街专门从郊区的学校坐一个多小时的公交车专门去爽吃,那会的小吃街也不多,所售卖的食物种类也很有大江南北的特色,再加上人口流动量远不如今天这般快速,能够在南国吃到一份桂林米粉已是莫大的幸事。

但到了大学的这段时间里仿佛以为都按下了加速键,几乎全国任何一个市县,不管大小一律都会有一条小吃街,这当然是件好事,但时过境迁,一条小吃街上售卖的食物在这里和在那里几乎完全一样,找不出任何的特色,宛如复制粘贴一般流水线生产。

我也理解这是一件商业化行为,「市场」这只大手必然会做出应有的调节,人们喜欢什么就会大批量的生产出什么。只是我作为一名游客,更希望看到的是来到一座城市可以感受到这座城市的特色——特别是食物,食物是最直接感受到一个地方与众不同的点,打好这一点可以让一座城市的旅行体验更上一层楼。

我快速走过占满了整条芙蓉街的小吃店铺,闻着令人反胃的大鱿鱼和臭豆腐,终于来到了护城河边。济南的护城河没有北京的护城河那么威严,反而充满了一种秀气,等待着你来感受。真要去找北京有没有和济南护城河相似的感觉,倒也是能找得出来,东直门外大街的亮马河就有这种感觉。顺着护城河一直往南走就来到了黑虎泉,走向黑虎泉的护城河边只有零星的几个人,虽然处在深秋,但也毫无寒意,只觉得鼻腔有一种湿润的舒服。但到了黑虎泉游船站附近游人就开始多了起来。

黑虎泉附近不只有黑虎泉一处泉眼,总共有三处,分散在古城西南角,其中黑虎泉以水量最大、气势拔得头筹。黑虎泉的泉水来自其出水口背后的小山体中,每秒泉水喷涌量达四百多升,仅次于趵突泉。更有意思的是,这里有大量拎着水桶来接泉水的人,政府也在附近修建了扫码出水的直饮水设备,我原本也想打一瓶泉水回酒店房间煮开试试,但望着这同样排队接泉水的人也就作罢。

黑虎泉这个地方很推荐,确实很有特色,附近的泉水和护城河形成了和趵突泉、大明湖完全不同的景观,值得一来。

天色渐晚,我继续沿着护城河北上绕道来到了宽厚里。只是没想到居然有是个小吃街,为了避免再被鱿鱼和臭豆腐熏得一身臭我马上找了最近的一条路出来了。在马路边上正好看到了济南特色「花车」,看着这满大街装饰着粉色灯光和假花瓣儿的三轮车,有一种宛如来到了东南亚的感觉。搜了下资料,但望着这同样排队接泉水的人也就作罢了,主要是违规运营和交通违规,再加上节假日期间大量挤占在景点门口,一些打不到网约车的游客会被花车漫天要价,有损城市形象。交通违规这个点我觉得没问题,但其他的点我都不太认可,我觉得最好的办法是,既然民间已经形成了花车这种现象,且不管你怎么禁需求依旧旺盛依旧不死,那就做一个顺水推舟的事情,规范化运营后,把济南花车的这个招牌打出去、彻底打响。在这种时代背景下,能够自发的形成一个独特的城市符号,可千万不要再按灭了。这就是一座城市与众不同的地方呀!

随后我来到了济南恒隆广场,摸到了 iPhone Air,这台设备是真好啊!好到一模到真机就想马上拥有的感觉。上一次有这种感觉还是 iPhone 12 Pro 系列,我记得当时自己已经冲到店里买了 iPhone 12 mini,想要接触 mini 的机型回忆到 iPhone 4 时代的感觉,但很可惜只用了一个周末后我就去退货了。现在想起来依旧觉得很可惜,mini 机型现在已经绝版了,不是预算紧张的情况下值得留下一台。还抱着侥幸心理问了下店员有没有 Vision Pro 新出的双层编制头带,一开始店员居然跟我说有现货!把我激动坏了,后来真要付款了仔细一查其实根本没货,现在 Apple Store app 上买已经要一个月后才能送达了。双层编制头带也确实好,比之前的单层和双圈对脸部的压力都更小,非常值得购入。

至此,在济南的第一天只在晚上 18 点左右就回到了酒店,胃因为午饭吃的九转大肠依旧有些不舒服,在便利店买了两盒奶和一根玉米就回酒店休息了。

千佛山

第二天我原本想着早些起床爬个千佛山下午再去博物馆,定了个 7 点半的闹钟,愣是磨叽到了 9 点才去吃早餐,将近 10 点了才到达千佛山。好巧不巧,正好碰上了九月九重阳登山节,比昨天在趵突泉多出大几倍的人流量都挤在千佛山的登山路上。

千佛山未正式开始爬山前的这段路其实很宽,但道路两旁排满了摆摊的小贩儿,卖什么的都有,观察下来卖山货、特产、民俗手工艺品的居多,仔细看远比逛小吃街有意思多了。甚至还有我看着非常像样板戏的戏班子在表演,台下坐了乌泱乌泱的大娘大爷,有点我想象中北方农村戏台看戏的感觉了。

在正式开始登山前,会先经过四窟万象这个额外收费的内部景点。中国四大石窟除了麦积山石窟我都参观过,就算如此,我依然认为值得有必要来一趟。四窟万象可以说把中国石窟和石刻文化的精华做了一个浓缩汇报,有些是一比一复刻,有些是按比例尺复刻,有大有小、飞天入地、应有尽有。如果你之前从未感受过石窟艺术、看过真正的四大四窟,更应该来这里对石窟艺术建立一个初步的印象,肯定能让你大为震撼。

另外,原本以为可能只是短短的一段路,走过去再走回来就结束了,没想到走在里面时我和大家一样都发出了「啊?还有啊?还能往里走啊?」的感叹。听说夏天如果进入窟中只有 18 度,可以在门口售票处租借毛毯入内,想想就刺激。

千佛山为济南三大名胜之一,不算高非常好爬,只需要稍微垫个脚尖就能轻松拿下。但人确实还是太多了,再加上山顶区域本身就不大,到顶后也没怎么有空隙让你好好的看看风景,古人登高望远心里总能畅快一番,但现如今我们登高望远时人声鼎沸,很难有一个让自己静下心来好好感受的环境。好在看到西北方向远处的济南 CBD 天际线一景确实不错,回到家中查阅资料时才发现济南居然是中国软件名城。再定睛一看,原来大名鼎鼎的浪潮科技就诞生于济南,甚至有一条路就被命名为「浪潮路」。

登顶后时间快到中午 12 点了,肚子还不算饿,左躲右闪的绕过源源不断同样想要登山的游人后终于赶在 12 点出头坐在了去往山东博物馆的车上,只是没想到最近济南的天气太好,外出玩耍的人和车都非常多,12 点出头坐上车的我,居然快中午 1 点了才进入博物馆内,只能加快参观博物馆的步伐了。

博物馆

一进入到山东博物馆我就被震撼到了,通顶大厅的设计营造出了大气磅礴的山东印象,位于四五层楼高的天花板上赫然镶嵌了一块巨大的镇馆之宝——鲁国大玉壁,后来看到了真正的大玉壁后,大厅天花板上的这块超大玉壁可能得是实物的几百倍大,十分震撼。

可能我还没从上周的河北博物院中走出来,这次来到山东博物馆后,当时看到这些展品和策展思路反而觉得比较普通和正常,几大镇馆之宝看完也没有给我震撼或者精美的感觉,甚至有些还有点凑数。但此时此刻再去重新回忆山东博物馆的策展思路和展品,还是得说它依旧算上乘之作了:有着比河北博物院更丰富的展馆和展品资源,总共三层共计 15 个展馆,对比河北博物院的 9 个展馆都快翻倍了,再加上当时的我总想着看精华、看重点,一心惦记着不要错过回京的高铁时间,很多策展文案都匆匆而过、没有仔细去看。最终只用了 1 个小时的时间就逛完了几个重点展馆,很多有意思的临时展馆都没来得及看。

以后要专门留大半天的时间去逛去看省博,绝对不能再像这次一样匆忙了。

更有意思的是,紧赶慢赶逛博物馆,出来也才下午两点左右,我寻思不如去旁边的万象城好好的吃个午饭再去高铁站不迟,边逛边找边搜,最终还吃了凑凑火锅、还选了畅吃套餐,边吃边等服务员上菜,吃好后还慢悠悠的继续吃着水果刷着手机。最终我结帐离开万象城,准备打车去济南西站时看到了预估时间居然要 51 分钟后整个人懵了:现在是 15 点 10 分,还没有走到马路边的上车点,就算立马上车到达高铁站后只剩下 19 分钟的时间让自己安检和检票,路上再多堵那么一会直接就错过了。

坐上车后我当机立断马上改签,往后延了 40 分钟且被迫多加了 100 元买了一等座才解决。换句话说就是,我既没有把博物馆逛爽、饭也吃得着急、还耽误了行程,多付了钱、到家的时间也晚了。折腾这么一圈你说是为啥呢,当初直接从博物馆出来去高铁站吃多好啊!更离谱的是,济南西站里的二层一圈全是吃的,都不需要排队,从安检结束到坐下仅需 5 分钟。

坐在返京高铁座位上的我反思折腾这一圈也得到了一些教训,首先是绝对不要贪多,本身周末之行勉强算一天半的行程时间就很紧张,这也要看那也要做这一来二去的很容易就衔接不上导致后面的行程受影响;其次是既然决定去到了一个去看去感受一样东西,那当下就应该安安心心、踏踏实实地去看去琢磨,不要老担心后面会怎么样,大不了做好眼前事后面的都不要,做一件就要做好一件。

最后是风险意识把控得还不够,总想着风险后置,有时候确实想太多想太远没用,但想几个小时之后的事马上就会发生的事有个未雨绸缪还是好的。

总结

济南确实是个不错的地方,对比石家庄来说我个人认为更宜居一些,有水有山有文化有历史有底蕴,甚至还有很多城市羡慕的高新技术产业,重点是整体人口素质更高,毕竟是孔孟之道繁盛之地的省会城市。

我原本对这块地方的打算是爬完泰山再来济南,但这么规划的话几年过去了都不能成行,多多少少都至少需要完整的两天,很能匹配上我对周末行的诉求。

除去青岛、威海,这是山东的第三个城市了,下一次专门再来山东也不知猴年马月了。之前跟一些小伙伴聊过,最近开启的这段旅行计划是我的第三阶段:第一阶段是 23 年疫情结束开始的,也是周末行,不过会偶尔额外的多请一天假,把北京周末一些经典的、著名的城市给好好的参观一番,比如大同、呼和浩特、洛阳、大连等,专门去看一些历史古迹;第二阶段是 24 年开始的出国行,并一直持续到现在,步子迈得更大,想去亲身感受一些不同的文化不同的叙事方式不同的人和事。

目前则是到了第三阶段,经历了前面的第一和第二阶段后,我没有变得疲倦,反而是对周围的事物更加期待了,想去关注一些小人物和小事情,去到一些小地方,比如天津的蓟县、南昌、喀什这种对比前面去过的一些不那么著名的地方,这个阶段会一直持续下去,有机会我会去到更多的小地方。

后面还有我更想做到的第四阶段,我想要无拘无束地走在中国的大地上。有一本书就叫《中国大地上》,是旅行文学的扛鼎之作,作者保罗·索鲁在1986年乘火车穿越中国二十余省市,把在这些省市的经历所见所闻记录了下来,给我们呈现出了中国改革开放初期的社会变迁。我也很想去做一件类似这样的事情,但我不想去做这种宏大背景下的事情,就想去看看这片赤土上生活着的大人物小人物们,去看这些或大或小的城市。

这一天我不知道什么时候才能来临,但有种预感应该快了吧?

> 关注 少数派小红书,感受精彩数字生活 🍃

> 实用、好用的 正版软件,少数派为你呈现 🚀

    价值重估:全栈实战背后的认知升级
    当AI技术从实验室走向产业核心,编程教育的本质正在发生深刻变革。AI编程实战行动营倡导的全栈实战理念,本质上是对传统学习路径的一次价值重估——它否定了“先理论后实践”的线性思维,代之以“在实战中构建认知体系”的新范式。这种转变看似激进,实则是对AI时代技能习得规律的深刻洞察:在技术快速迭代的背景下,解决问题的能力远比知识积累的速度更重要。


    全栈优势:从“解决问题者”到“定义问题者”的跃迁
    传统的AI教育往往培养的是“解决问题者”——学生被给予清晰的问题定义和评估标准,专注于寻找最优解。而全栈实战营培养的是“定义问题者”,这不仅是角色的转变,更是思维层次的跃迁。

    在实际项目中,学员首先面对的是模糊的业务需求。比如“提升用户留存率”这样的目标,需要学员自己拆解为可执行的技术问题:是推荐算法不够精准?是交互体验需要优化?还是用户画像不够完整?这种从混沌中建立秩序的能力,正是传统教育中最为缺失的一环。全栈实战通过高强度、高频率的完整项目训练,让学员建立起“需求-技术-实现-评估”的完整思维链条。

    更关键的是,全栈能力让开发者具备了系统思维。一个优秀的AI系统不是孤立算法模块的堆砌,而是数据流、模型、服务、交互的有机整体。只懂算法的人可能设计出准确率很高但响应延迟无法忍受的系统;只懂工程的人可能搭建了高性能架构却因算法效果不佳而失去价值。全栈实战营的价值,正是让学员理解每个技术决策的系统性影响,在准确率、性能、成本、可维护性之间找到最佳平衡点。


    学习效能的革命:加速曲线与能力迁移
    从个人学习角度看,实战营模式创造了令人惊讶的“加速曲线”。传统教育中,学生往往在毕业后面临“所学非所用”的困境,需要数月甚至数年完成从理论到实践的转换。而实战营通过精心设计的项目序列,实现了学习曲线的前置陡峭化。

    这种高效学习的秘密在于“认知负荷的合理分配”。实战营项目通常设计为螺旋式上升结构:第一个项目可能只要求实现核心功能,第二个项目增加性能优化,第三个项目引入多模型协作,第四个项目考虑生产部署。每一轮都在原有基础上增加新的挑战,这种循序渐进但又不断突破舒适区的设计,最大化地利用了学习心理学的“最近发展区”理论。

    另一个被低估的价值是能力迁移的普遍性。在完成电商推荐系统项目后,学员能够将其中的特征工程方法迁移到金融风控场景;在搭建智能客服系统过程中掌握的对话管理策略,同样适用于教育领域的智能导学系统。这种迁移能力的培养,使学员在面对新领域、新问题时,能够快速建立技术解决方案的认知框架。


    职业发展的战略价值:稀缺性与不可替代性
    从职业发展角度审视,全栈AI开发者正在成为市场上最具稀缺性的资源。这种稀缺性源于三个层面的竞争优势:

    技术深度的交叉优势。既深入理解Transformer架构的数学原理,又能将其高效部署到分布式环境中的开发者,其价值远超单一领域的专家。在技术决策中,他们能够做出更全面的权衡,避免因局部优化导致的系统性问题。

    沟通效率的降维优势。全栈开发者能够用产品经理理解的术语讨论用户体验,用算法研究员熟悉的语言探讨模型改进,用运维工程师关注的角度讨论部署方案。这种跨角色的沟通能力,在团队协作中创造了巨大的效率红利。

    创新实现的完整能力。从灵感到原型的距离,往往决定了创新的成败。全栈开发者能够独立完成从想法验证到产品原型的完整闭环,这种“端到端”的实现能力,在快速试错的创新环境中具有无可替代的价值。


    个人成长的底层逻辑:思维模式的根本转变
    最令我深思的是,全栈实战营带来的不仅是技能提升,更是思维模式的根本转变。

    从被动接受到主动探索的转变:传统教育中的学生等待教师传授知识,而实战营学员必须主动寻找解决方案。当遇到模型效果不佳时,他们不再等待标准答案,而是开始研究数据质量、尝试不同架构、调整训练策略。这种主动性问题解决能力的培养,其价值远超任何具体的技术知识。

    从完美主义到迭代思维的转变:学术界追求的是在标准数据集上的最优结果,而产业界需要的是在有限时间和资源下的可行方案。实战营让学员体验到“60分方案快速上线,然后持续迭代优化”的工程思维,这种对“足够好”而非“完美”的追求,是学术思维向工程思维转变的关键。

    从技术视角到产品视角的转变:优秀的AI系统最终要为用户创造价值。实战营项目往往需要学员考虑技术方案的用户影响:这个推荐算法是否会导致信息茧房?这个风控模型是否会对特定群体不公平?这种对技术社会影响的思考,是负责任创新的基础。


    展望:全栈能力作为AI时代的基础素养
    展望未来,我坚信全栈能力将不再是少数专家的特权,而逐渐成为AI时代开发者的基础素养。随着工具链的不断完善和技术门槛的持续降低,掌握从数据处理到模型部署的完整能力链,将如同今天掌握编程基础一样普遍。

    然而,工具易得,思维难求。这正是AI编程实战行动营最宝贵的价值所在——它提供的不是随时可能过时的具体技术,而是在复杂技术环境中构建解决方案的思维框架,是在不确定性中寻找方向的判断能力,是在技术快速演进中持续学习的适应能力。

    在这个意义上,全栈实战营不仅是一场技能培训,更是一次认知升级。它让参与者不仅学会如何构建AI系统,更理解为何这样构建;不仅掌握当下的技术工具,更获得面向未来的学习能力。当AI技术逐渐成为各行各业的“水电煤”,这种全栈实战能力将成为每个人在智能时代创造价值的核心资本。

    有没有什么比较好的旅行规划软件推荐一下,能支持 PC 和移动端(最好是能支持苹果系统、安卓也行)信息同步、高清卫星图(或者能支持加载第三方卫星底图)。
    目前用了高德的行程规划还行,就是卫星底图不行,不支持高清的,也试了奥维,虽然支持高清卫星图,但是行程路线规划没有。

    从感知到决策:汽车全链路智能化的底层逻辑
    汽车制造的智能化早已不是“加装几个机器人”或“上线一套MES系统”就能解决的问题。真正的全链路智能化,是让从产品设计、工艺开发、生产调度、质量控制,到供应链协同、售后服务的每一个环节,都能像有生命一样自主感知、分析、决策并执行。这背后,是工业AI从单点工具向体系化能力的跃迁。过去,许多企业试图直接套用通用大模型,却发现工业数据“乱、散、孤”,工艺经验难以数字化,AI模型根本“听不懂”设备振动频率背后的隐性故障。真正的突破,不在于模型多大,而在于能否把工程师几十年积累的Know-How,转化为可复用、可迭代的工业知识图谱。
    构建闭环:智能体协同如何重塑制造流程
    如果说传统自动化是“按程序执行”,那么智能化则是“动态优化”。要实现这一点,必须打破部门墙与系统孤岛。“工业智造超级智能体”正是为此而生——它不是单一功能的AI工具,而是由计划、生产、质量、仓储、能源、设备六大智能体组成的协同网络。它们共享统一的数据标准,通过“数据加速器”和“指标工厂”解决数据碎片化问题,再将工艺经验封装为可调用的知识模块,形成“决策—执行—反馈”的闭环。真正的智能,不是技术堆砌,而是让系统在不确定中持续学习、自我修正。
    落地验证,实战对比
    在实际应用中,广域铭岛已为某新能源电池头部企业部署AI工艺大模型,将SOP开发周期从数周压缩至数小时,工程师仅需做最终验证,准确率提升90%,人力成本直降80%。而在德国,西门子为宝马某工厂部署的数字孪生系统,实现了从订单到交付的全流程仿真优化,但其部署周期长达半年以上,且高度依赖定制化硬件。博世则在发动机产线通过AI预测设备故障,准确率达92%,但其方案主要服务于自有产线,对外输出成本高昂。汽车的未来,不属于最贵的设备,而属于最懂制造的AI。

    Chainguard最新的《可信开源现状报告》详细描述了当前行业对于容器镜像中的漏洞以及开源依赖的长尾问题的看法。该报告基于 2025 年 9 月至 11 月期间观察到的 1800 多个容器映像项目和 10100 个漏洞实例,提供了生产环境的数据驱动视图。

     

    Chainguard 利用来自 29 万个镜像和近 5 亿次构建的遥测数据,检查客户实际如何消费和维护开源组件。它发现,基础语言和基础设施镜像,如 Python、Node、nginx、Go 和 Redis,在生产使用中占主导地位,形成了它所描述的现代 AI 驱动软件生态系统的基础栈。Python 出现在大约 72%的客户环境中,Node 占 57%,nginx 占 40%。这些镜像与模型开发、数据处理和推理工作负载以及周围的可观测性和平台工具相关联。

     

    然而,报告警告说,这些受欢迎的镜像的可见层只是真实景观的一小部分。前 20 个镜像占 Chainguard 编目镜像的约 1.37%,大约是所有容器拉取量的一半。另一半的生产使用来自 1436 个长尾镜像,占平均客户清单的 61%以上。Chainguard 强调,这些长尾镜像通常是绝对需要的现场服务和基础设施的核心组件,而不是短暂的实验。

     

    漏洞的分布高度偏向这个长尾。Chainguard 报告说,在此期间,它修复的 CVE 实例中,只有 214 个出现在前 20 个镜像中,约占 2%。其余的 98%(10785 个 CVE 实例)在该集合之外的镜像中。这一发现表明,最严重的风险暴露在堆栈中最难应用补丁和治理的部分。对于每个在前 20 个镜像中修复的 CVE,公司表示它在不太受欢迎的镜像中解决了 50 个 CVE,这是它用来说明处理安全长尾重要性的比率。虽然这些问题大多数是中等严重性,但报告认为组织最关心的是它们如何快速解决跨其镜像范围的关键和高严重性问题。

     

    在这方面,Chainguard 强调了他们修复安全问题的速度。该公司表示,在三个月的时间窗口内,它实现了对关键 CVE 的平均修复时间低于 20 小时,63.5%在 24 小时内解决,97.6%在两天内解决,所有问题都在三天内解决。Chainguard 在两天多的时间内修复了高严重性漏洞,在两天半的时间内修复了中等严重性漏洞,在三天多的时间内修复了低严重性问题。这些时间明显快于 Chainguard 声明的服务水平目标,即关键 CVE 为七天,其他为十四天,并且适用于流行和长尾镜像。

     

    在我们的数据中,有一点很突出:现代软件由广泛、不断变化的开源组件组合驱动,其中大多数都不在前 20 名最受欢迎的镜像中。这不是开发者花费时间的地方,但却是大量安全性和合规性风险积累的地方。

     

    该报告还指出,合规性是容器安全变化的主要驱动因素。它指出,44%的客户在生产中至少运行一个 FIPS 兼容镜像,通常是为了满足 FedRAMP、DoD IL 5、PCI DSS、SOC 2、欧盟网络弹性法案、澳大利亚的 Essential Eight 和 HIPAA 等框架的要求。最广泛使用的 FIPS 镜像与非 FIPS 组合镜像相镜像,包括 Python、Node、nginx、Go、Redis、Istio 组件和 cert-manager。Chainguard 建议,这种模式显示了监管压力如何鼓励使用与现有工作负载紧密对齐的硬化、经过密码学验证的开源组件。

     

    风险集中在最熟悉的项目之外的想法并不是 Chainguard 工作所独有的。NetRise在 2024 年的一项研究发现,常用的 Docker Hub 容器平均包含 604 个已知漏洞,其中超过 45%的漏洞超过两年未修复。同一研究表明,这些容器中的一小部分关键和高严重性漏洞已经被利用,并与活跃的勒索软件活动有关。NetRise 的研究还表明,即使这些镜像不是最广泛使用的,长期未修补的组件在镜像中也构成了持续的风险。

     

    学术研究使用不同的方法得出了类似的结论。发表在GigaScience上对科学容器镜像的分析报告称,每个镜像平均有 460 个漏洞。这项分析的作者指出,许多镜像包括完整的操作系统发行版和很少更新的其他不必要的软件包,从而创造了更大的攻击面。他们还表明,仔细减少镜像大小和内容,并定期重建它们,可以显著减少漏洞数量。这反映了当前行业的最佳实践,即使用最小的基础镜像,并经常重建容器镜像。

     

    Sonatype 的《软件供应链现状报告》通过跟踪在已经存在修补版本的情况下易受攻击的组件被使用的频率,增加了另一层内容。2024 年的版本突出了恶意开源软件包的增加,并报告称,在 95%使用了易受攻击组件的情况下,已有修复版本可用。Sonatype 还强调,大量依赖关系长时间未打补丁,特别是对于低严重性问题。这种可用修复和缓慢采纳的组合支持了 Chainguard 的观点,即管理性补救和长尾覆盖可以填补开源维护现实留下的空白。

     

    业界的回应,如CheckmarxFaith Forge,强调了一些标准模式。安全供应商将镜像扫描描述为持续集成和部署流程的标准部分,组织越来越多地将这些扫描与政策即代码规则联系起来,这些规则可以阻止带有未打补丁的关键 CVE、缺失签名或缺失软件物料清单的镜像。在对软件物料清单(SBOM)格局的分析中,欧洲网络安全局(ENISA)也强调了机构和监管机构的指导。它强调了签名工件、可验证的构建来源和将 SBOM 内容与漏洞情报匹配的能力的重要性。这些趋势都响应了 Chainguard 强调的同一结构性问题:需要管理的不仅仅是最受欢迎的镜像中的漏洞,而是当代软件系统中使用的所有容器化组件中的漏洞。

     

    原文链接:

    https://www.infoq.com/news/2026/01/chainguard-opensource-vulns/

    交通运输公司优步(Uber)在其博客上发布了一篇关于其新可观测性平台的文章,强调对他们来说,网络可见性现在是一种战略能力,而不仅仅是一系列离散的监控工具。

     

    在这篇文章中,优步描述了它是如何用一个围绕开源技术和 API 构建的模块化云原生可观测性平台取代了单一的本地监控堆栈的。作者解释说,旧系统依赖于重量级组件和手动配置,无法跟上办公室、数据中心和云环境的快速变化。他们表示,他们现在已经构建了一个灵活的数据摄取管道、一个中央警报摄取应用程序和一个动态配置服务,这些服务将共同路由遥测数据、规范化警报,并保持收集器配置与实时网络库存一致。

     

    文章解释说,自动化是优步实现可观测性新方法的一个重要部分。在博客中,该团队解释了其动态配置应用程序如何自动跨区域重新分配轮询工作负载,并通过 API 而不是工程师手动更改来全球部署配置更改。他们将监控系统构建为一个可编程界面,工程师可以通过添加元数据和策略来影响它。这一立场反映了最近在云基础设施可观测性方面的其他工作,其中工程师描述了平台,这些平台在近乎实时的情况下摄取和关联指标、事件、日志和跟踪,并通过中央策略管理警报。与此相一致的是,优步的帖子将自动化呈现为在企业规模上管理可观测性的唯一可行方式,而不仅仅是一个附加组件。作者详细介绍了 CorpNet 可观测性平台如何监控路由器、交换机、配电单元和其他支持其协作和企业应用程序的基础设施设备。

     

    优步还在供应商独立性和成本控制方面做出了重大努力。在帖子中,工程师解释说,转向云原生开源优先堆栈削减了“数十万美元”的循环许可费用,并减少了对商业软件的依赖。公司描述了如何将开源组件与其自己的警报摄取和配置系统集成,以构建一个完整的平台。这种方法反映了最近可观测性调查的发现,例如 Logz.io 的一项报告,该报告称许多组织大量使用像 Prometheus 和 Grafana 这样的开源工具,作为控制商业平台成本的努力的一部分。这与供应商的叙述形成对比,后者推广集成的现成可观测性平台,这些平台抽象了实现细节。文章还清楚地暗示,优步愿意投资工程努力,以换取更低的循环支出和更大的灵活性。

     

    优步还在供应商独立性和成本控制方面做出了重大努力。在这篇文章中,工程师们解释说,向云原生开源第一堆栈的转变减少了“数十万美元”的重复许可费,并减少了对商业软件的依赖。该公司描述了它如何将开源组件与自己的警报摄取和配置系统一起部署,以形成一个完整的平台。这种方法反映了最近可观测性调查的结果,比如Logz.io的调查。它报告说,许多组织大量使用像 Prometheus 和 Grafana 这样的开源工具,作为控制商业平台成本的一部分。这与供应商的叙述形成了鲜明对比,后者提倡集成现成的可观测性平台,抽象了实现细节。这篇文章还明确暗示,优步愿意投入工程努力,以换取更低的经常性支出和更大的灵活性。

     

    优步的工程师还使用博客来设定关于 AI 角色的预期,他们现有的工作为未来的基于 AI 的自动化奠定了基础。他们认为,通过现在清理和标准化遥测数据,他们为未来“更智能、由 AI 驱动的网络操作”创造了条件。其他行业文章也呼应了这一观点。例如,网络提供商 Equinix 写道,生成式 AI 可以通过改进警报处理和加速根本原因分析,为网络可观测性增加“更进一步的智能”。关于 AI 驱动的数据中心网络的文章提出了类似的观点,并将可观测性数据呈现为异常检测和预测性维护的燃料。

     

    在所有这些主题中,这篇博客文章将可观测性呈现为一种持续实践,而不是一次性的项目。优步选择了一个长跑的比喻,并在进展中写到了更换鞋子和调整配速策略。其他最近的报告和指南,如Splunk的这份,采用了类似的语言,并将可观测性描述为需要在工具、技能和流程上持续投资的“学科”。

     

    “生成式 AI 正在为网络可观测性带来更进一步的智能,使用户能够监控他们的网络,管理警报,主动检测问题,并全面评估性能,”Equinix 的网络可观测性团队在其 2025 年关于 AI 和网络运营的分析中写道。优步的博客文章展示了一家大型技术公司如何通过首先重建其内部可观测性基础,然后邀请 AI 坐在顶部,为未来做好准备。

     

    优步的博客文章最后声称,优步新的可观测性平台已准备好支持当前运营和未来的 AI 驱动能力。

     

    原文链接:

    https://www.infoq.com/news/2026/01/uber-network-observability/

    本文是我在2024年旧金山QCon大会上演讲的总结。在过去的十年里,我作为一名应用科学家和机器学习工程师,在包括社交媒体、金融科技和生产力工具等多个领域工作。多年来,我看到许多项目取得了成功,但同样也有许多项目未能投入生产。这篇文章反思了成功或失败的原因,以及我们能从中学到什么。

     

    在这篇文章中,我讨论了导致机器学习项目失败的常见陷阱,比如机器学习的固有不确定性、不一致的优化目标以及从业者之间的技能差距。首先,我概述了机器学习项目的生命周期以及它与普通软件项目的不同之处。然后,我深入探讨了五个常见陷阱(通过示例),并解释了我们如何减少遇到它们的机会。

     

    机器学习项目的失败率

    我在包括社交媒体平台、金融科技解决方案和生产力工具在内的各个领域都参与过机器学习项目。其中一些项目投入了生产,而许多项目没有。每一次努力都教会了我一些有趣的东西,并让我接触到了新技术,但当你全身心投入的一个项目没有产生你所希望的影响时,感觉并不好。我想知道:是我一个人吗?这个问题有多严重?

     

    较早的研究报告称,机器学习项目的失败率高达 85%。最近的调查也得出了类似的结论。在2023年Rexer Analytics的一项研究中,超过三百名机器学习从业者中,只有 32%的人表示他们的项目投入了生产。不同行业的比率有所不同:大型科技公司有多年的 AI 应用历史,而传统企业和初创公司仍在寻找有效、无缝的 AI 应用之路。

     

    并非所有的失败都是坏事。机器学习项目本质上是不确定和实验性的。通常,在探索数据并尝试一些基线模型之前,你无法知道机器学习是否会帮助你得出结论。如果根据这些初步研究,你决定快速改变方向或终止项目,那么应该被认为是一种成功,这是鼓励创新的经典快速失败原则。

     

    在这篇文章中,我关注的是糟糕的失败:那些没有明确定义就拖延的项目,尽管离线性能良好但没有部署的模型,或者即使部署后也没有被采用的解决方案。

     

    机器学习项目的生命周期

    从高层次、简化的角度来看,一个典型的机器学习项目生命周期有六个步骤。它从确定一个使用机器学习优化的业务目标开始,这需要作为一个机器学习问题被构建。构建问题涉及探索和处理相关数据以训练各种模型。表现最佳的训练模型被部署和监控。我们从监控过程中得到的反馈将用于完善整个系统。

     

    一个说明机器学习项目生命周期的简化高层图。(来源:作者)

     

    这个迭代生命周期有两个要点:

    • 这是一个漫长、多步骤的过程,涉及多个团队之间的交接,由于涉及到固有复杂性,增加了失败的风险。

    • 机器学习项目是以数据为中心的优化问题。来自数据、模型和监控的反馈信号对于成功的结果同样重要。

     

    陷阱 1:解决错误的问题

    在我们想要讨论的五个常见陷阱中,其中最关键的一个是优化错误的问题。在 Rexer Analytics 的调查中,当机器学习从业者被问及在开始之前是否明确定义目标时,29%的人回答“大多数时候”,26%的人表示这种情况很少发生。这种清晰度的缺乏是机器学习工程师在承诺项目之前就经常面临的共同挑战。

     

    在过去,对业务目标进行迭代并在开始项目时保持一定的模糊性是很常见的。然而,对于机器学习项目来说,这种迭代已经成为一个更严重的障碍。为了理解这个问题,我们需要探索业务目标是如何被转化为机器学习解决方案的。当然,我们不想错过第一步,那就是确定这个问题是否与机器学习相关。

     

    一旦我们确定这是一个机器学习问题,我们需要将其构建为一个 ML 问题,这涉及到识别用于提取信号的具体数据(数据工程)以及训练多个模型/架构/超参数的设置。根据模型的复杂性,训练步骤可能经常需要更昂贵的基础设施(例如,GPU)。

     

    归根结底,我们试图优化一个数学定义的目标函数。这个目标函数高度依赖于我们试图解决的业务目标类型。业务目标的后期变化需要对数据、目标函数和管道进行调整,这可能导致工作的损失。这就是为什么,为了从一个良好的机器学习问题开始,我们通常希望向业务团队提出许多问题。

     

    以下是我想分享的一个例子,它展示了我们如何增加挑选获胜项目的机会。几年前,我曾是一个支持多个业务线的集中式 AI 金融科技团队的一员。每条业务线都将其项目标榜为“最重要的”,通常使用我们不熟悉的术语。我们的团队不得不在噪音中导航,优先考虑最有可能成功的投资。

     

    在一年中,我能够参与各种不同类型的项目,涉及不同的业务线。最大的成功——对公司和我来说——是一个对个人和商业银行(P&CB)领域来说不言自明的预测模型。三个因素导致了这个项目的成功:

     

    • 直接收入相关性:P&CB 是一个主要的利润中心,因此有强烈的高层推动力。

    • 与现有系统的互惠性:我们的模型可以嵌入到一个长期运行的端到端系统中,具有监控/报告功能;我们只需要替换模型。

    • 机器学习可行性:现有的模型简单,具有现代架构和功能,因此我们有信心可以超越它。

     

    仅仅因为其他人都在做机器学习项目,或者技术上可行,就启动一个机器学习项目是不够的。最好的机器学习项目达到了理想(利益相关者拉动)、有利可图(业务影响证明成本)和可行(技术上可解决)的最佳点。事先问一些尖锐的问题:目标是否明确定义?预计的利润是否合理?哪些假设是现实的?模型可能暴露哪些风险?

     

    投资组合平衡也很重要。低风险/高影响项目是“唾手可得的果实”。如果你意识到风险并保持投资组合平衡,那么高影响/高风险项目是值得追求的。胜利证明了在 AI 基础设施和人才上的投资,而风险更大的赌注可能会改变游戏规则。

     

    陷阱 2:数据陷阱

    第二个陷阱是由数据带来的挑战。这是机器学习项目最常见的陷阱之一,也许是你的团队抱怨最多的一个。数据在哪里?我们能处理大量数据处理吗?尽管公司已经在解决这些问题上投入了很多,但这并不意味着没有其他隐藏的挑战最终会损害你的项目。在机器学习领域有一句名言:“垃圾进,垃圾出”。机器学习项目完全依赖于识别数据中的模式。如果数据是有缺陷的,那么你从这项研究中得到的结论很可能是不可信的。

     

    多年来,机器学习社区建立了一个标准的数据管道结构,包括数据收集、处理和特征工程。还有一份人们通常为数据准备执行的常见任务清单:过滤重复项和异常值、填充缺失数据以及重新采样以处理数据不平衡。每个合适的机器学习团队都使用或适应这些标准程序,但它们的使用远远不够。

     

    如果你对机器学习项目是如何失败的感兴趣,这个GitHub存储库包含了一长串多年来发现的失败的机器学习解决方案。这些失败大多数与数据有关。尽管大型科技公司或大学研究人员开发了所有解决方案,但他们也难免会出现涉及数据的错误。

     

    2022年普林斯顿大学的一项审查发现,在 22 篇同行评审的论文中存在关键陷阱;这些结果传播到了 17 个领域的 290 多个后续研究中。其中一个关键问题是数据泄露。研究将数据泄露分为八个不同的类别,从混合训练和测试数据到抽样偏差。处理各种类型的数据泄露使其难以识别和预防。

     

    数据准备工作通常感觉像是在探索冰山。你在表面看到的只是开始。许多问题,特别是与你自己的数据相关的问题,都隐藏在下面。大型组织也面临数据孤岛的问题:团队可能不知道所有可用的特征,导致错误的“无法解决”的结论。标记是另一个主要挑战。通常,我们需要收集和标记一个黄金数据集进行评估,提供详细的注释指南,并执行质量检查。即便如此,你可能会发现标记的数据仍然缺乏一些共识,你不能将其用于模型训练。

     

    有了模型即服务和预训练模型,团队可以通过外部 API 跳过训练,但评估仍然困难。在早期的 GenAI 工作中,许多团队依赖于人工观察或微小的示例集。在最初阶段这是可以的,但如果没有强大的评估管道,你最终会得到被动的补丁和未知的爆炸半径。最终,我们仍然需要在 LLM 和 GenAI 的评估上投入大量资金。

     

    虽然从一开始就不可能完美地解决所有问题,但这一点仍然需要强调:花时间探索和理解你的数据。根据你的观察寻找新特征并清理它,而不是应用一个标准过程。投资于收集高质量的标签。最终,机器学习的成功在很大程度上取决于数据。

     

    陷阱 3:从模型到产品

    我想强调的第三个问题是将机器学习模型转变为服务于大规模、实时用户的功能性产品的挑战。这种转变不仅仅是部署代码。要解决生产约束和额外要求,需要付出巨大的努力。

     

    真实世界机器学习系统的工程系统概览。(来源

     

    谷歌的著名图表显示了与周围的基础设施相比,ML 代码是多么的小。大多数代码来自支持基础设施,包括资源管理、服务系统、监控工具、日志记录和其他相关组件。MLOps 领域已经成熟,并且有许多资源可以提供帮助。当然,对于首次采用者来说,这听起来很繁重,但一旦你建立了基础管道,你就可以支持多个机器学习解决方案,并更无缝地部署它们。

     

    为了了解机器学习模型和完整的机器学习驱动解决方案(超出 MLOps 单独可以覆盖的范围)之间的差距,让我们以检索增强生成(RAG)为例。本质上,RAG 从你自己的数据库中提取相关信息。它将其提供给大语言模型(LLM),允许模型在考虑额外上下文的情况下回答问题。一个快速演示看起来可能非常简单(一个 LLM API、一个向量数据库和一些编排)。但是将其转变为一个生产就绪的 RAG 系统(例如,一个为客户支持提供动力的 RAG 系统)是完全不同的故事。你需要评估性能和控制质量的方法。你可能还需要一个更高级或代理式的 RAG 设置,而不仅仅是基本的 RAG 设置,以及可解释性功能,以便客户可以信任答案。除此之外,还有工程方面:通过缓存或推理调整减少延迟,并保持隐私、公平和安全(包括防御幻觉和越狱)。

     

    除了技术指标外,监控业务导向的指标也很重要。这些指标可以包括产品质量的衡量(例如,用户采用或参与新功能的频率)、客户体验(例如,满意度或保留率)以及整个平台的健康状况(例如,收入增长、活跃使用或流失率)。关键原则是,技术方面的优化工作不应破坏业务的更广泛成功和可持续性。

     

    简而言之,获胜团队是跨职能的,并在早期就要求、质量门槛和生产约束达成一致,而不是在孤岛中工作,希望问题稍后会被修复。

     

    陷阱 4:离线与在线

    第四个陷阱是离线成功和在线失败。这个陷阱可能是引起团队最多情感波动的一个。为什么坚实的离线模型在线失败?因为数据、解决方案和指标在不同阶段有所不同。离线模型使用历史(通常是清洁/抽样)数据和以机器学习为中心的指标。在线模型使用实时数据、端到端系统和与业务对齐的指标

     

    (来源:作者)

     

    让我分享一个来自我的第一个生产发布的例子,这是很多年前的事了。当时,我们正在开发一个照片推荐器,以在创意社区内推广摄影师的作品。业务团队提出了一个担忧,即新用户会注册,发布一两张照片,然后再也不回来。考虑到这一点,我们的数据科学团队开始进行一些探索,以找出问题所在。他们发现早期点赞和留存之间有很强的相关性。有了这个洞见,任务就变成了通过尽快推广每个新用户的照片,让他们更快地获得他们想要的反应,并返回我们的网站。

     

    当时,大多数推荐器都依赖于协同过滤:如果用户 A 和 B 喜欢许多相同的项目,我们推荐 A 喜欢但 B 未见过的项目。这也解释了为什么我们的新用户没有收到很多点赞,这种现象被称为冷启动问题:因为新项目之前没有任何互动,它们也几乎没有可见性。

     

    为了解决冷启动问题,我们构建了一个基于内容的推荐系统,从图片本身预测照片的受欢迎程度。流程:对于用户 A,找到与过去喜欢的相似照片,然后使用受欢迎程度分类器进行过滤,以减少低质量的推荐。

     

    一旦分类模型被优化,我们就将其集成到生产管道中。然而,在线 A/B 测试结果参差不齐:点赞增加了,但会话长度下降了,这是一个关于参与度的负面信号。出于某种原因,我们的推荐系统正在造成令人不安的体验;用户不再想继续滚动浏览我们的网站。

     

    经过多次迭代,我们最终找到了一个更好的方法来整合受欢迎的信号。结果,推荐系统变得更加复杂。这是一条漫长的道路,铺满了多个步骤,不仅涉及离线评估和在线评估之间的差异,还涉及监控一组业务指标,而不仅仅是一个主要的业务指标。

     

    一旦模型集成到生产中,它就成为了一个更大系统的一部分,涵盖了整个解决方案。推荐系统经常合并多个模型,这些模型的输出并不正交,因此一个在离线环境中表现强劲的模型在合并后的系统中可能影响会减弱。这里的教训是:不要过度优化离线环境。要尽快推动 A/B 测试,以验证与业务目标的一致性。

     

    陷阱 5:非技术障碍

    最后一个陷阱,经常被忽视,与看不见的非技术障碍有关。回到我们之前的调查,当人们被问及在部署模型时面临的主要障碍时,两个最常见的答案与技术无关:缺乏利益相关者的支持和不充分的积极规划。

     

    根据 Rexer Analytics 的调查,这些是问题“在你的组织和/或你的客户组织中,模型部署的主要障碍是什么?”的前十名答案:

     

    • 决策者不愿意批准对现有业务的变更

    • 缺乏充分的、积极的规划

    • 缺乏正确执行部署的理解

    • 评分模型所需的数据可用性问题

    • 没有指定人员负责部署

    • 员工不愿意或无法有效使用模型输出

    • 在计算分数或将模型或其分数实施/集成到现有系统中的技术障碍

    • 隐私/法律问题

    • 模型性能被决策者认为不够强

    • 无法提供决策者所需的模型透明度

     

    管理利益相关者是棘手的,因为许多决策者没有人工智能背景;他们可能受到头条新闻或之前的软件经验的影响,低估了机器学习的风险和不确定性。这就是人工智能专家真正发挥作用的地方。这不仅仅是关于构建模型,还关于确保你的利益相关者了解你的 AI 项目的正确期望。

     

    这意味着我们的工作包括教育。利益相关者需要了解机器学习是如何学习的(以及为什么数据管道很重要),为什么机器学习项目本质上是不确定的,模型限制(声誉和安全风险),以及构建和部署的实际成本。

     

    还有管理和规划机器学习项目的问题。三个指导原则脱颖而出:

     

    • 定义一个清晰的最小可行产品(MVP),并设定一个简单的优化目标。通常,从简单开始比从复杂开始表现更好。

    • 尽早构建端到端,使 A/B 测试成为可能,并尽快获得生产反馈。

    • 根据反馈快速迭代,重新审视目标,并根据需要扩展数据。

     

    (来源:作者)

     

    我看到的一个有效策略是将项目孵化器(用于早期的高风险赌注)与产品线(用于扩展经过验证的解决方案)分开。这在管理风险的同时实现了创新。

     

    这里的关键要点是,管理机器学习项目与管理工作传统软件工程项目不同。我们需要适应这些主要挑战,以确保你的团队可以从非技术角度获得支持。

     

    结论

    虽然没有方法可以保证我们能避免所有错误,但我们可以在现实中考虑一些原则或最佳实践。我们希望选择一个可行、可取且有利可图的项目。我们希望以数据为中心。此外,我们希望鼓励早期合作和积极管理跨职能团队。我们希望快速构建端到端解决方案以进行测试。我们希望根据机器学习项目的性质调整你的项目管理计划。

     

    这只是机器学习项目可能失败的部分原因列表,还有许多其他原因,但它可以作为我们启动讨论的良好起点。我想以我最喜欢的查理·芒格的一句引语结束:“尽可能从自己的个人经历中学习一切,尽量减少从他人的好经验或坏经验中间接学习,无论是活着的还是死去的”。

     

    原文链接:

    https://www.infoq.com/articles/why-ml-projects-fail-production/