2026年2月

先声明,本文不是贩卖焦虑,只是自己的一点拙见,没有割韭菜的卖课、副业、保险广告,请放心食用。

2022 年初,前司开始了轰轰烈烈的「降本增笑」运动,各部门严格考核机器成本和预算。当然,最重要的还是「开猿节流」。

幸好,我所在部门是盈利的,当时几乎没有人受到波及。

据说,现在连餐巾纸都从三层的「维达」换成两层的「心心相印」了,号称年节约成本 100 多万。我好奇的是,擦屁股时多少会沾点 💩 吧?这下,真是名正言顺的 💩 山代码了。

2022 年 7 月底,因为某些原因,结束 10 年北漂回老家,换了个公司继续搬砖。

2023 年,春节后不久,现司搞「偷袭」,玩起了狼人杀,很多小伙伴被刀:

清晨接到电话通知,上午集体开会,IT 收回权限,中午滚蛋

好在是头一回,补偿非常可观,远超法律规定的「N+1」。

2024 年,平安夜,无事发生。

2025 年 1 月,公司年会,趣味运动会,有个项目是「财源滚滚」,下图这样的:

有个参赛的老哥调侃道,这项目名字不吉利啊,不应该参加的。无巧不成书,年后他被刀了。。。

这次的规模远小于 2023 年,但 2025 年也不太平,「脉脉」上陆续有人说被刀或者不续签,真假未知。

实话说,我之前从未担心过被裁,毕竟:

名校硕士,经历多个大厂,有管理经验

热爱编程,工作认真负责,常年高绩效

但是,随着 AI 的快速迭代,我现在感觉自己随时可能被刀了。AI 能胜任 log 分析、新功能开发、bug 修复等绝大部分日常工作,而且都完成的很好。再配合 AI 自己写的MCP,效率肉眼可见的提高。

亲身体验,数百人开发的千万行代码级别的项目,混合了Java/Kotlin/OC/C++/Python等各种语言。跟Cursor聊了几句,它就找到原因并帮忙修复了。如果是自己看代码、问人、加 log、编译,至少得半个小时。

那还要码农干啥呢?即使是留下来背锅,也要不了这么多啊。

背锅后的机-会

技术大厂,前端-后端-测试,全国均有机-会,感兴趣可以试试。待遇和稳定性都还不错~

距离上次「狼人杀 」,三年之期已到。今年会有「狼人杀 2.0」吗?我还能平稳落地吗?

无所谓了,我早已准备好后路:

头盔和衣服真是我买的,还有手套未入镜,我感觉设计很漂亮,等天气暖和后,当骑行服穿。

汽车,小踏板,大踏板,足以覆盖滴滴、外卖、闪送三大朝阳行业。家里还有个小电驴,凑合能放到后备箱,承接代驾业务问题不大。

以上,虽然是开玩笑,但我对「是否被刀、何时被刀」,真的是无所谓。因为:

一个人的命运啊,当然要靠自我奋斗,但也要考虑历史的进程

公司为了长远的发展,刀人以降低成本,再用 AI 来提高效率,求得股价长红。对此,我十分理解,换我当老板,也会这么干。

作为牛马,想太多没用,我们左右不了这些事。不夸张的说,99.9999% 的码农是不可能干到退休的,和死亡一样,被刀只是早晚的事。更扎心的是:

人不是老了才会死,而是随时会死

当下的工作也一样,并不是摸鱼或者捅娄子才会被刀,而是随时会被刀,与个人的努力、绩效关系不大。常年健身的肌肉男,也可能猝死,只是概率低点,并不是免死金牌。

生命,从受精的那一刻起,就在走向终点。工作,从入职的那一刻起,就在走向(主动/被动)离职。

所以,虽然我现在感觉自己随时可能被 AI 替代,但我的心态一直都没变,就是标题所言:

做好自己的份内工作,等着被裁

不是消极怠工,我始终认真完成每一项任务,该加班加班。并非为了绩效,是因为自己的责任心,要对的起工资。至于公司哪天让我滚蛋,我决定不了,更改变不了。就像对待死亡一样,坦然接受之,给够补偿就好。

对于 AI,还想再啰嗦两句:

虽然 AI 很牛逼,但最终还是需要人来判断代码的对错。此时,工程师的价值就体验出来了,所以 AI 是帮我干活的小弟,而不是竞争对手。
AI 扩大了我们的能力边界,人人都可以是前端、后端、客户端、UI 设计全通的「全栈工程师」,至少可以是「全沾工程师」,「雨露均沾」的沾。

滚蛋之后呢?我不知道,现在有多少公司愿意招 40 岁高龄码农?据说前司招聘 35 岁普通员工都要 VP 审批了,真是小刀剌屁股,开了眼了。

好在,我家人的物质欲望极低,对衣服、手机、汽车没有任何追求,老婆不用化妆品和护肤品,也没买过一个包。即使不上班,积蓄也能撑一段时间。

所以,强烈建议当前北上广深拿高薪的老哥老妹们,除非万不得已,千万不要像我一样断崖式降薪回老家。趁年轻,搞钱比啥都重要。

对了,我目前有两个利用自身优势的基于 AI 的创业方向。网友们帮忙把把关,如果哪天真失业了,看能否拉到几个亿的风投,谢谢!

偏胖圆脸,AI 加点络腮胡,再买几双白袜子
身高 180,AI 换个美女脸,黑丝高跟大长腿



——转载自:野生的码农

StarDots入驻2Librathanks

简介

StarDots 是一个专业的图像托管服务。纯净无广告,可免费使用。现已支持使用 2Libra 一键登录了!

功能一览

  • 图像变换: 基于 URL 参数,简单指定几个参数就可以实现图像的尺寸,质量,高斯模糊等效果
  • CDN 全球加速: 基于高效的内容分发网络,实现全球地区的流畅访问
  • 自定义域名与证书托管:支持自定义域名以及域名证书自动更新续期,彻底解放双手
  • 数据迁入与导出:便捷的迁移能力让你的数据不再被壁垒所困,也不再被平台绑架
  • 开放 API:适用于进阶用户的定制化需求,让接入变得简单
  • 图像防盗链:仅对受信任的的域下面才可以被访问(比如 2libra.com)
  • 私有托管:你甚至可以让图像仅对自己可见,真正做到我的资源我做主

适合谁用?

  • 论坛用户
  • 博客用户 / 博客站长
  • 个人网站站长
  • 电商商家
  • 设计师共享资源
  • 企业用户

可靠性?

StarDots 始与 2023 年,到今年已经历经近 3 年,托管原图像超过十五万,受到了数以千计的价值用户喜爱。

如何使用?

1.直接进入官网注册并登录到管理后台进行图像管理
使用浏览器直接访问下面的地址。
官网地址: https://stardots.io/zh

2.使用浏览器插件进行快捷访问
StarDots 的浏览器助手已经上架到各浏览器应用商店,安装后按照指引设置即可。完成指引后,你可以在任意页面管理和访问你的资源。控制按钮将以悬浮球的形式出现在页面右下角(默认状态下),当然,位置可以任意拖动。贴心但不侵入。
你可以快速上传,上传成功后,将出现适应不同类别的分享链接复制按钮,如链接,Markdown(适用于论坛,如 2Libra,V2EX,LinuxDo),bbs code(适用于论坛,如 LinuxDo),HTML 标签等。

Chrome 商店: 请访问
Edge 商店: 请访问
Firefox 商店: 请访问

3.使用桌面应用访问
StarDots 支持添加到桌面,这样一来,你可以像访问常规软件一样直接使用而不必再每次都打开浏览器输入地址进行访问了。

4.使用开放 API 进行程序接入
StarDots 支持使用 API 进行接入访问,这中方式适用于程序开发者。
文档地址: https://stardots.io/zh/documentation/openapi

价格

如果需要自定义域名和证书托管等高级功能需要付费帐号,套餐详情可查看: https://stardots.io/zh/pricing

最后

感谢你的使用,如你遇到任何问题,欢迎随时反馈。thanks

PDF 中的超链接是一项非常实用的功能,能够让读者快速、便捷地访问指定的网页。通过在 PDF 文档中添加超链接,可以为读者提供更多补充信息,或引导他们前往相关的参考资源。当读者点击超链接时,对应的网页会立即在浏览器中打开。

本文将介绍如何使用 Spire.PDF for .NET,通过 .NET 程序为 PDF 文档中的现有文本添加超链接。

安装 Spire.PDF for .NET

首先,需要将 Spire.PDF for .NET 包中包含的 DLL 文件添加为 .NET 项目的引用。这些 DLL 文件可以通过链接直接下载,也可以通过 NuGet 进行安装。

PM> Install-Package Spire.PDF

使用 C#/VB.NET 在 PDF 现有文本上插入超链接

在 PDF 文档中,超链接是以注释(Annotation)的形式添加到页面上的。要在 PDF 的已有文本上插入超链接,首先需要定位目标文本;获取其所在位置后,即可创建一个包含链接的 PdfUriAnnotation 对象,并将其添加到对应位置。

具体步骤如下:

  1. 创建 PdfDocument 对象,并使用 PdfDocument.LoadFromFile() 方法加载 PDF 文件。
  2. 通过 PdfDocument.Pages 属性获取第一页。
  3. 创建 PdfTextFinder 对象,并通过 PdfTextFinder.Options.Parameter 属性设置查找选项。
  4. 使用 PdfTextFinder.Find() 方法在页面中查找指定文本,并获取其第三次出现的位置。
  5. 遍历该文本出现位置的文本边界(由于被搜索的文本可能跨越多行,且可能包含多个边界,查找到的文本边界会以列表形式返回,以适应这种情况)。
  6. 在对应的文本边界内创建 PdfUriAnnotation 对象,并通过其属性设置链接地址、边框样式和边框颜色。
  7. 使用 PdfPageBase.AnnotationsWidget.Add(PdfUriAnnotation) 方法将超链接添加到页面注释中。
  8. 调用 PdfDocument.SaveToFile() 方法保存 PDF 文件。

具体示例代码如下:

using Spire.Pdf;
using Spire.Pdf.Annotations;
using Spire.Pdf.Texts;
using System.Collections.Generic;
using System.Drawing;
using TextFindParameter = Spire.Pdf.Texts.TextFindParameter;

namespace ChangeHyperlink
{
    internal class Program
    {
        static void Main(string[] args)
        {
            // 创建 PdfDocument 类的对象
            PdfDocument pdf = new PdfDocument();

            // 加载 PDF 文件
            pdf.LoadFromFile("Sample.pdf");

            // 获取第一页
            PdfPageBase page = pdf.Pages[0];

            // 创建 PdfTextFinder 对象并设置查找选项
            PdfTextFinder finder = new PdfTextFinder(page);
            finder.Options.Parameter = TextFindParameter.IgnoreCase;

            // 在页面中查找指定文本,并获取第三次出现的位置
            List<PdfTextFragment> collection = finder.Find("climate change");
            PdfTextFragment fragment = collection[2];

            // 遍历该文本出现位置的所有文本边界
            foreach (RectangleF bounds in fragment.Bounds)
            {
                // 创建一个超链接注释
                PdfUriAnnotation url = new PdfUriAnnotation(bounds);
                // 设置超链接的 URL
                url.Uri = "https://en.wikipedia.org/wiki/Climate_change";
                // 设置超链接注释的边框
                url.Border = new PdfAnnotationBorder(1f);
                // 设置边框颜色
                url.Color = Color.Blue;
                // 将超链接注释添加到页面中
                page.Annotations.Add(url);
            }

            // 保存 PDF 文件
            pdf.SaveToFile("AddHyperlinks.pdf");
            pdf.Dispose();
        }
    }
}

申请临时许可证

如果您希望移除生成文档中的评估提示,或解除功能限制,请申请一份有效期为 30 天 的临时许可证。

大家好,我是汤师爷,专注AI智能体分享,致力于帮助100W人用智能体创富~

热点监控智能体是帮你自动发现爆款选题的利器。

它能全天候扫描各大平台的热门内容,从海量信息中筛选出最有价值的话题和创意。

你不需要再手动搜索,智能体会自动将热点内容整理成表格,让你清晰直观地掌握行业动态。

1 为什么要做热点监控

热点监控是内容创作者和营销人员的必备工具,它帮助我们在信息爆炸时代精准把握用户关注点,提升内容效果和影响力。以下是进行热点监控的四大核心理由:

1. 把握用户兴趣,提高内容相关性

用户的注意力是稀缺资源。通过实时监控热点话题,我们能了解目标受众当下最关心的问题和兴趣点。热点本质上是用户兴趣的集中体现,基于热点创作的内容自然具有更高的用户匹配度,更容易获得关注和互动。

2. 节约选题时间,提高创作效率

没有热点监控系统时,创作者需要在各平台间不断切换,手动搜索和筛选信息,这个过程既耗时又低效。自动化热点监控能持续追踪多平台热门内容,将重复性工作交给智能体,让创作者能专注于内容创作本身。

3. 抓住时机,提高曝光机会

热点具有明显的时效性,越早参与讨论,获得的曝光机会就越多。自动化热点监控系统能在热点刚出现时就发出提醒,帮助创作者抢占先机。比起等热点完全爆发后再跟进,提前布局能获得更多流量红利和平台算法青睐。

4. 发现内容机会,避免同质化

热点监控不只是追踪已经爆发的话题,更重要的是发现潜在新兴热点。通过分析热点数据,创作者可以识别尚未被充分挖掘的内容机会,避开同质化竞争,找到差异化表达角度,从而在激烈的内容竞争中脱颖而出。

2 热点监控智能体搭建流程

智能体的搭建流程主要分为两个步骤:梳理工作流和设置智能体。

1、梳理工作流

热点监控工作流是一套自动化信息采集和处理系统,能将人工需要几小时甚至几天完成的工作压缩至几分钟内自动完成。这一工作流主要包含三大环节:

(1)根据关键词,批量获取热门视频

系统根据预设的关键词(如行业热词、产品名称、竞品信息等),自动从抖音、小红书等平台搜索相关视频。这一步骤替代了手动搜索和浏览结果的过程,大幅提高效率。

(2)批量获取视频详细信息

获取视频列表后,系统进一步抓取每个视频的详细数据,包括:

  • 基础信息:视频ID、标题、链接、发布时间、视频时长等
  • 互动数据:点赞数、评论数、收藏数、分享数等关键指标
  • 创作者信息:作者名称、用户ID、个人简介等

这些数据是分析视频热度和受欢迎程度的关键指标,也是判断内容价值的重要依据。系统将这些零散数据整合成结构化信息,便于后续分析。

(3)将数据添加到多维表格

最后,系统将处理好的数据自动导入到预设的飞书多维表格中。

通过这样的自动化处理,我们能建立一个实时更新的热点内容库,随时查看行业动态,发现爆款选题灵感。

这种工作流显著减轻了运营人员的工作负担,让我们能将更多精力投入到内容创作和策略制定上。

2、设置智能体

完成工作流搭建后,我们需要创建一个热点监控智能体来执行这个工作流。智能体设置过程分为三个关键步骤:

  1. 设置人设与逻辑:配置智能体的特征、回复风格和决策逻辑
  2. 绑定工作流:将工作流与智能体关联,赋予它执行具体任务的能力
  3. 测试并发布:进行全面功能测试,确认一切正常后将智能体正式发布到生产环境

完成这三个步骤后,我们就成功搭建了一个热点监控智能体。

3 抖音热点监控工作流

前面我们详细介绍了热点监控的重要性和智能体搭建的基本流程,接下来我们将深入了解如何实际搭建一个抖音热点监控工作流。

登录Coze官网,在“资源库-工作流”里新建一个空白工作流,取名“fetch_douyin_hot_videos”。

工作流整体预览如图所示。

image.png

1、开始节点

这里用于定义工作流启动时所需的输入参数。如图6-2所示。

  • 输入:

    • keywords:用于搜索热点的关键词,可以是产品名称、行业术语、竞品名称或热门话题,系统会自动搜索相关的热门内容

image.png

2、插件节点:根据关键词,批量获取热门视频

我们将使用"视频搜索"插件的"douyin_search"工具。通过这个功能,我们可以根据关键词批量获取热门视频。

  • 输入:

    • api_token:这里需要填入你的API密钥,可以从插件的官方平台获取,它是调用视频数据的重要凭证,相当于你的身份证明
    • keyword:关键词,从开始节点获取
    • page:获取第几页的内容
    • publish_time:发布时间,可用值为_0(不限)、_1(一天之内)、_7(一周之内)、_180(半年之内),这里我们选择_7
    • sort_type:排序类型,可用值:_0(综合)、_1(最多点赞)、_2(最新发布),这里我们选择_1

image.png

4、批处理节点:批量获取视频详细信息

批量获取视频详细信息是工作流中的核心节点,它负责将上一步骤中获取的视频列表进一步深入处理,获取每个视频的完整信息。

  • 输入:

    • 并行运行数量:设置适当的并行数量可提高工作流执行效率,设置为1则按顺序串行执行
    • 批处理次数上限:批处理操作不会超过这个设定的最大次数
    • aweme_list:从"根据关键词,批量获取热门视频"节点输出中,选择data,类型为Array

image.png

5、批处理体内插件节点:获取单个视频详细信息

接下来,我们需要添加批处理体内的节点。我们将使用"视频搜索"插件的douyin_data工具,通过这个功能可以根据抖音视频链接获取视频的详细信息。

  • 输入:

    • api_token:API密钥
    • douyin_url:从"批量获取视频详细信息"节点的输出中,选择share_url

image.png

6、批处理体内代码节点:将视频详情整合进视频列表中

这一步将从抖音API获取的详细视频信息与之前收集的视频列表数据合并。

通过这个过程,我们能掌握每个视频的完整信息,包括互动数据(点赞、评论、收藏数)、创作者信息和内容详情,从而为后续分析提供全面的数据基础。

  • 输入:

    • aweme_detail:从"获取单个视频详细信息"节点的输出中,选择aweme_detail
    • aweme:从"批量获取视频详细信息"节点的输出中,选择item
  • 输出:

    • aweme_list:变量类型设置为 Array 对象数组,表示处理后的视频列表

image.png

下面是处理数据的Python代码,它会将视频信息转换成我们需要的格式。

async def main(args: Args) -> Output:
    params = args.params
    aweme_detail = params.get("aweme_detail", {})
    aweme = params.get("aweme", {})
    aweme["aweme_detail"] = aweme_detail

    ret: Output = {
        "aweme_list": [aweme]
    }
    return ret

7、批处理体内代码节点:将信息整理为飞书表格可以使用的数据

在这个环节中,我们会提取视频的核心信息(如标题、点赞数、评论数等),并将它们转换成飞书表格能够直接识别和处理的格式。

  • 输入:

    • aweme_list:从"将视频详情整合进视频列表中"节点的输出中,选择aweme_list
    • keywords:从开始节点中,选择keywords
  • 输出:

    • records:处理后的表格数据,选择Array类型

image.png

下面是处理数据的Python代码,这段代码非常重要,它负责将抖音API返回的原始数据转换成结构化的表格数据。

async def main(args: Args) -> Output:
    params = args.params
    aweme_list = params.get("aweme_list", [])

    result = []

    # 遍历 aweme_list,依次处理
    for aweme in aweme_list:

        # 获取 aweme_detail 并判空
        aweme_detail = aweme.get("aweme_detail") or {}
        title = aweme_detail.get("desc") or ""
        link = aweme_detail.get("share_url") or ""

        # 安全获取 statistics
        statistics = aweme_detail.get("statistics") or {}

        # 提取各字段信息,并在取值时加默认值
        video_id = statistics.get("aweme_id") or ""
        digg_count = statistics.get("digg_count") or 0
        comment_count = statistics.get("comment_count") or 0
        collect_count = statistics.get("collect_count") or 0
        share_count = statistics.get("share_count") or 0

        # 获取作者信息
        author_info = aweme_detail.get("author") or {}
        author_name = author_info.get("nickname") or ""
        signature = author_info.get("signature") or ""
        sec_uid = author_info.get("sec_uid") or ""
        raw_create_time = aweme_detail.get("create_time", 0)
        # 如果不是 int,就尝试转换,失败则为 0
        try:
            create_time = int(raw_create_time)
        except (TypeError, ValueError):
            create_time = 0

        # 创建时间以毫秒计,避免 None 或非法值导致报错
        create_time_ms = create_time * 1000

        raw_duration = aweme_detail.get("duration", 0)
        # 如果不是数字,尝试转换为 float,失败则为 0
        try:
            duration = float(raw_duration)
        except (TypeError, ValueError):
            duration = 0.0
        duration_sec = duration / 1000

        # 组装返回数据
        item_dict = {
            "fields": {
                "视频ID": video_id,
                "标题": title.strip(),
                "关键词": params.get("keywords", ""),
                "链接": {
                    "text": "查看视频",
                    "link": link.strip(),
                },
                "点赞数": digg_count,
                "评论数": comment_count,
                "收藏数": collect_count,
                "分享数": share_count,
                "作者": author_name,
                "用户简介": signature,
                "用户ID": sec_uid,
                "发布日期": create_time_ms,  # 毫秒级时间戳
                "时长": duration_sec        # 秒
            }
        }
        result.append(item_dict)

    return result

8、批处理体内插件节点:将数据添加到多维表格

首先,我们需要创建一个多维表格并设置好表头字段,为后续数据采集做好准备。这个表格是存储和分析抖音热点视频数据的核心,因此表头设计至关重要。我们应包含视频ID、标题、点赞数、评论数等关键信息,便于后期分析和筛选。创建好的表格界面如下图所示。

image.png

选择"飞书表格"插件节点的add_records工具,将数据添加到多维表格。

image.png

  • 输入:

    • app_token:提前创建一个多维表格,将多维表格的链接复制进去。
    • records:从"将信息整理为飞书表格可以使用的数据"的输出变量中,选择records。
    • table_id:多维表格数据表的唯一标识符,如图6-10所示。

image.png

9、结束节点

选择"返回文本",并将回答内容设置为:"获取关键词下的所有抖音视频【完成】"。

image.png

4.抖音热点监控智能体设置

到目前为止,我们已经介绍了抖音热点监控工作流的搭建过程。接下来,我们将介绍抖音热点监控智能体的设置。这个环节将工作流与智能体绑定,只有完成这一步,我们才能真正实现抖音热点监控智能体的功能。

接下来,我们将逐步指导你完成整个设置过程,包括创建智能体、配置基本参数、连接工作流以及进行测试,帮助你快速掌握这项实用技能。

1、新建智能体

在Coze平台创建一个新的智能体,将其命名为"抖音热点监控智能体"。

image.png

2、设置人设与逻辑

设置人设与逻辑是创建智能体的关键步骤。在这一环节,我们需要明确智能体的行为模式和响应方式。

对于抖音热点监控智能体,我们希望它能直接执行任务,无需过多交互。因此,我们设置简单明了的指令,让智能体在接收到关键词后立即执行视频采集工作。

直接执行`fetch_douyin_hot_videos`

3、绑定工作流

把"fetch_douyin_hot_videos"工作流添加到智能体中。这个工作流是我们之前设计的抖音视频采集工作流,将它绑定到智能体后,用户只需输入关键词,智能体就会自动执行工作流,帮助我们高效地收集抖音热点视频。

image.png

5、测试并发布

在预览与调试窗口中输入关键词,测试智能体采集热点抖音视频的功能。系统会自动执行工作流,并将结果添加到飞书表格中。

使用不同关键词进行多次测试,确保智能体在各种情况下都能稳定运行。测试无误后,点击"发布"按钮将智能体正式发布到生产环境,供用户使用。

image.png

5.小红书热点监控工作流

接下来我们将深入了解如何实际搭建一个小红书热点监控工作流。

这个工作流能帮你自动收集小红书平台上的热门内容,让你不用手动浏览就能掌握最新趋势。

我们将使用简单易懂的步骤,带你从零开始构建这个强大的监控系统,即使你没有编程经验也能轻松上手。

登录Coze官网,在“资源库-工作流”里新建一个空白工作流,取名“xhs_keywords”。工作流整体预览如图所示。

image.png

1、开始节点

这里用于定义工作流启动时所需的输入参数。

  • 输入:

    • foldUrl:飞书表格链接,需要提前创建好一个飞书多维表格,并复制其链接。该表格将用于存储我们采集到的小红书热点视频
    • cookie:小红书网站的cookie信息,这是访问小红书API的必要凭证,我们将在后面详细讲解如何获取
    • keywords:用于搜索热点的关键词,可以是产品名称、行业术语、竞品名称或热门话题,系统会自动搜索相关的热门内容

image.png

2、如何获取小红书cookie

在Chrome浏览器中,登录小红书主页:https://www.xiaohongshu.com/

按F12键打开开发者工具面板,然后按照以下步骤操作:

  • 第一步:点击「网络」选项卡
  • 第二步:点击「文档」标签
  • 第三步:点击「explore」文档
  • 第四步:点击「标头」选项卡
  • 第五步:滚动页面找到Cookie字段,复制整段Cookie信息。

image.png

2、插件节点:根据关键词获取笔记

我们将使用“小红书”插件的xhs_search_note工具。通过这个功能,我们可以根据关键词,批量获取热门视频。

image.png

  • 输入:

    • cookieStr:开始节点的 cookie
    • keywords:关键词,从开始节点获取
    • notType:查询类型(0=全部,1=视频,2=图文),这里我们选择1 视频类型
    • sort:排序(默认为综合,0=综合,1=最新,2=最热),这里我们选择2 最热
    • totalNumber:查询总数,这里我们输入20

3、循环节点:循环获取笔记详情

循环获取笔记详情是工作流中的关键环节,它使我们能够一次性处理多条小红书笔记。从搜索结果中获取笔记链接后,我们需要逐一获取每条笔记的详细信息,包括标题、内容、作者和点赞数等。

  • 输入:

    • input:从"根据关键词获取笔记"节点的输出中,选择 data

image.png

4、循环体内插件节点:获取笔记详情

我们将使用小红书插件的xhs_note_detail工具。该工具能获取每条笔记的完整信息,包括标题、内容、作者信息和互动数据等。

image.png

  • 输入

    • cookieStr:开始节点的 cookie
    • noteUrl:从 “循环笔记详情” 节点的输出中,选择 noteUrl

5、循环体内插件节点:提取视频文案

我们将使用"字幕获取"插件的generate_video_captions_sync工具。该工具能自动从视频中提取文字内容,将口述转换为文本,省去手动听写的麻烦。它能精准识别视频中的语音并生成文字记录,帮助我们快速理解视频的主题和关键信息。

输入:

  • url:从"获取笔记详情"节点的输出中,选择 video_h264_url,表示H264标准编码格式视频链接
  • lang:视频语言,如汉语、英语等,不填时默认为汉语

image.png

6、循环体内代码节点:将笔记数据整理成飞书表格格式

这一步将采集到的视频信息转换为标准化数据结构,以便写入飞书表格。我们需要提取视频的标题、内容、作者和点赞数等关键信息,并按飞书表格要求进行格式化。这样不仅便于数据整理和筛选,还能帮助我们更直观地分析热门内容的特点。

  • 输入

    • input:从"获取笔记详情"节点的输出中,选择note
    • data:从"提取视频文案"节点的输出中,选择data
  • 输出

    • records:变量类型设置为 Array 对象数组,表示处理后的视频列表

image.png

下面是处理数据的Python代码,它将采集到的小红书视频信息转换为标准格式,便于存储和分析。

代码提取视频的标题、内容、作者等关键信息,将其组织成飞书表格所需的格式,然后返回处理好的数据。这样我们能将所有热门视频整齐地存放在同一张表格中,方便后续分析:

async def main(args: Args) -> Output:
    input_data = args.params.get('input')  or {}
    data = args.params.get('data') or {}

    records = []  # 初始化 records 列表

    # 提取 note 相关字段
    title = input_data.get('note_display_title', '')  # 标题
    desc = input_data.get('note_desc', '')  # 描述
    url = input_data.get('note_url', '')  # 链接
    nickname = input_data.get('auther_nick_name', '')  # 作者昵称
    likedCount = input_data.get('note_liked_count', '0')  # 点赞数
    videoUrl = input_data.get('video_h264_url', '')  # 视频地址
    collectedCount = input_data.get('collected_count', '0')  # 收藏数
    imageList = input_data.get('note_image_list', [])  # 图片列表

    # 构建记录对象
    record = {
        "fields": {
            "笔记链接": url,
            "标题": title,
            "内容": desc,
            "作者": nickname,
            "点赞数": likedCount,
            "链接": {
                "link": url,
                "text": title
            },
            "收藏数": collectedCount,
            "图片地址": '\n'.join(imageList),  # 将图片列表拼接成字符串
            "视频地址": videoUrl,
            "视频文案": data.get("content", "") 
        }
    }
    records.append(record)  # 将记录对象添加到 records 列表中

    # 构建输出对象
    ret: Output = {
        "records": records
    }
    return ret

7、循环体内插件节点:写入飞书表格

最后,我们将收集到的所有数据添加到飞书多维表格中。

我们需要提前创建一个多维表格,并设置好对应的表头字段。

image.png

表头字段包括视频的所有关键信息:笔记链接、标题、内容、作者、点赞数、链接、收藏数、图片地址、视频地址和视频文案。

接下来,选择"飞书表格"插件节点的add_records工具,将采集到的数据添加到多维表格中。

image.png

  • 输入:

    • app_token:提前创建一个多维表格,然后将多维表格的链接复制到此处。
    • records:从"将信息整理为飞书表格可以使用的数据"节点的输出变量中,选择records。
    • table_id:需填入多维表格数据表的唯一标识符。

8、结束节点

最后添加结束节点,完成整个工作流程。如图6-25所示。

  • 输出:

    • output:开始节点的foldUrl,也就是飞书多维表格的链接

image.png

6.小红书热点监控智能体设置

至此,我们已完成小红书热点监控工作流的搭建。接下来,我们将介绍如何设置小红书热点监控智能体。这个关键环节将工作流与智能体绑定在一起,只有完成这一步,才能真正实现小红书热点监控智能体的功能。

1、新建智能体

在Coze平台创建一个新的智能体,命名“小红书热点监控智能体”。如图6-26所示。

image.png

2、设置人设与逻辑

设置人设与逻辑是创建智能体的关键步骤。在这一环节,我们需要明确智能体的行为模式和响应方式。

对于小红书热点监控智能体,我们希望它能直接执行任务,无需过多交互。因此,我们设置简单明了的指令,让智能体在接收到关键词后立即执行视频采集工作。

直接执行`xhs_keywords`

3、绑定工作流

把"xhs_keywords"工作流添加到智能体中。

image.png

4、测试并发布

在预览与调试窗口中输入关键词,测试智能体的小红书热点视频采集功能。系统会自动执行工作流,并将结果直接添加到飞书表格中。

对了,我整理了一份开源的智能体学习手册,爆肝 10 万字,价值 999 元。限时开放领取👉:tangshiye.cn

当前,深度研究(DeepResearch)正成为人工智能进化的关键分水岭。不同于传统文本生成,深度研究任务要求系统能够像人类专家一样,自主执行多步骤、可迭代的认知任务,涵盖了从复杂需求理解、广泛信息获取到深度洞察产出的全过程。深度研究 Agent 目前已广泛应用于学术综述、金融投研、商业分析等领域,能够将传统需数日的手动研究工作压缩至分钟级完成,显著提升研究与决策效率。



作为评价这一前沿赛道能力的“金标准”,DeepResearch Bench 填补了通用 AI 评测在端到端深度研究任务上的空白。现有的 Benchmark 多聚焦于单一能力,难以覆盖长程推理与检索合成的复杂性。该榜单由领域专家设计了 100 个博士级别的研究任务,覆盖 22 个学科,并引入 RACE 报告质量评价框架与引文准确性评估,是目前全球范围内衡量 DeepResearch Agent 生产力水平最硬核、最真实的评价体系。

 

2 月 4 日消息,深度研究智能体权威评测榜单 DeepResearch Bench 公布最新结果,百度千帆深度研究 Agent(Qianfan-DeepResearch Pro)登上测评榜单榜首。在衡量研究报告含金量的四大核心维度:全面性、洞察力、指令遵循度和可读性上,千帆深度研究 Agent 实现领先。

百度方面表示,千帆深度研究 Agent 采用 Agentic 架构,通过“任务理解-规划-执行”循环机制实现端到端研究交付,依托百度搜索与 RAG 技术保障信息获取的广度、可信度与相关性。

 

其中,两大重要设计确保了任务执行的准确性,首先采用“由粗到细”的研究路径展开方式应对任务不确定性;其次,通过深度执行路径规划与实时反思机制,系统能在每个研究节点动态评估进展、调整策略,从而有效避免幻觉与路径偏离,并确保复杂研究任务的高质量完成。

 

此外,在报告生成阶段,千帆深度研究 Agent 采用独立的两阶段报告渲染机制:首先产出 pivot 报告,通过优化相关推理能力,来保证逻辑一致性和内容全面性;之后使用不同的渲染工具,基于 pivot 报告渲染出最终的 markdown、html、ppt 等多形态报告,从而实现“一次研究,多形态报告”的交付。



目前,该深度研究 Agent 已上线百度千帆平台,用户只需输入复杂调研需求,系统即可在十几分钟内生成带引用的专业级研究报告,真正实现“分钟级”的深度洞察交付。

我是独生子,家里算是贫穷那一档吧,但是也不愁吃穿。

从 3 年级开始住校,每次放假回去也就住几天,从我的记忆里感觉不到家的温馨,感觉爸妈对我很冷淡,家里也没有自己的房间,也没收到过礼物,也没有自己的钱,过年收到的压岁钱会默认变成后面的生活费,也从没有人在事情上帮我拿过注意,或者帮我解决过我解决不了的困难。当然我爸妈他们自己觉得他们很爱我。

大学毕业后,独身一人来上海工作,之后慢慢就挣钱多了,后面没有要过家里一分钱,也会逐渐给家里花钱,每年都买很多东西,包括手机,日用品,甚至县城买房我都给他们出了几万块。

我感觉我爸妈不在乎我:

  • 我来上海 8 年了,他们没有主动说想要来看看我,我生活什么状态;
  • 从没想过我缺什么,给我寄点,我老婆的妈妈还经常给我们寄东西;
  • 上海买房不易,也没有考虑过买房帮助我什么的;
  • 结婚收的礼金,他们也没想过给我一点,他们的关系收的礼我就不说了,里面还有我很多同学上的礼;
  • 几年前买车,他们也没说过给我补贴点,他们知道我花了几十万,只是嘴上和我说:“你买车咱也帮不上你啥”
  • 他们只会打嘴炮,没有任何实质关心,举个例子:之前视频时看到我 1.5 的床垫铺在 1.8 的床上(正好刚换房子),我爸就说:“我看到你床垫都不够长”,然后就没有后续了,也没说帮我买个床垫,或者给我几块钱什么的。类似的很多,我只能在言语上听到:多穿点,多吃点。感受不到任何关爱。

所以我也不想给家里花钱:
很多孩子每年会给家里赚钱,几千几万的,但我只买东西不转钱,除了买房子给了他们一部分。他们现在不知道我攒了多少钱,不知道我每月挣多少。我觉得他们应该有能力养活自己,我就很好奇,作为父母没给孩子带来过任何帮助,就不考虑多赚点钱吗?一点也没想过多努力一点,帮帮孩子。现在对家这个词没有任何感觉。

我想问问广大 v 友,我这个心理对吗?从根本上说是我不孝,还是我爸妈确实不在乎我。

近日,Atlassian 官方宣布:自 2026 年 2 月 17 日起,其 Data Center(数据中心版)产品将迎来约 15% 的价格上调,覆盖 Jira、Confluence、Jira Service Management 等核心产品。

来源:Atlassian 官网

值得注意的是,去年 Atlassian 已明确了 Data Center 的停售与最终停服规划。对于众多依赖 Atlassian Data Center 进行项目管理的中国企业而言,继续留在 Data Center 不仅需负担更高的 IT 成本,更面临着断供风险。

Jira 官宣停售 Data Center ,中国企业又双叒要迁移了?!

窗口期加速收窄:高昂的价格之外,还有「滞后风险」

Atlassian Data Center 在产品生命周期进入倒计时阶段依然上调价格,向市场释放了清晰信号:Data Center 版的维护成本与门槛将持续推高,留给中国企业平滑迁移的窗口期正迅速收窄。

对处于安全合规「深水区」的企业而言,必须站在业务连续性的高度,重新审视核心研发管理工具的长期自主性与安全策略。

如果此时不主动筹谋,未来可能面临以下三重严峻挑战:

1.安全与合规挑战:难以逾越的「数据红线」
Atlassian 本轮价格上调与其「云优先」的战略深度绑定。 Atlassian 在中国大陆没有本地服务器,选择 Cloud 版即意味着核心研发数据需存储于境外,对金融、政务、能源及高新制造等数据主权敏感的行业来说,无异于把数据安全暴露在不可控的风险之中。

2.迁移工程挑战:确保业务迁移「平稳着陆」
对于深度依赖 Jira Data Center 的中大型企业,多年累积的项目数据、文档资产和复杂业务流程,不仅是核心资产,也构成了团队的工作惯性。在评估替代方案时,企业必须从多维度确保迁移的可行性:确保海量历史数据与字段配置能够实现高匹配度迁移确保拥有完备的迁移计划与可追溯的全程服务确保支持分批迁移与风险控制,保障业务在迁移过程中不断档

3.IT 成本挑战:难以预测的「成本黑洞」
自 2021 年起,Atlassian Cloud 版价格已连年持续上涨,这种频繁且单方面的价格变动,让企业的 IT 预算规划极为被动。若未来选择迁移上云,企业不仅需接受未来不可预测的持续涨价,还可能将额外承担员工培训、系统集成、插件开发等隐性成本。

ONES:面向企业长期需求的主流国产替代方案

在核心研发管理工具的不可控风险面前,寻找一个更加可靠的本土替代方案已不再是「备选项」,而是关乎企业研发数字资产安全的「必选项」。

ONES 作为国内领先的企业级研发管理平台,凭借功能对标、自主可控、安全合规、高性价比与本地化服务等核心优势,已成为众多央国企及行业头部企业替换 Jira 和 Confluence 的首选。积累 6 年迁移经验,ONES 帮助超过百余家客户完成数据的平滑迁移,单个客户最大迁移数据体量超过 9.5 TB,正式迁移成功率达 100%。

专业可靠的迁移服务,确保企业资产平滑着陆

ONES 提供行业领先的端到端迁移服务与工具,确保企业知识资产与业务流程的完整、平稳过渡。

  • 全面的数据兼容性:实现对 Jira 的字段映射、任务类型、状态流转及权限配置的高匹配迁移;针对 Confluence 文档,实现结构与样式的最大化保留,确保团队原有的工作习惯与知识资产「零损耗」。
  • 全流程风险受控:借助 ONES 自助迁移工具,可实现中等规模数据的自动化搬迁;对于超大型实例,我们提供分批迁移与风险监控机制,并输出详尽的迁移报告,确保过程可追溯,业务不断档。

坚定的本地化部署承诺,满足安全监管要求

ONES 始终将企业的数据主权与安全合规置于首位,提供稳定、高可用的私有化部署方案。

  • 自主可控的部署架构:我们为金融、政企等行业客户提供私有化环境下的高可用部署与数据加密方案,满足严苛的网络安全规范与数据主权要求。
  • 权威完备的安全背书:ONES 已通过 SOC2 Type II 安全审计,并持有等保三级、ISO 27001、ISO 27018 等多项国内外权威认证,从基础设施到应用层全方位构建安全防线。

面向未来的生产力迭代,支持私有化部署的 AI 能力与开放生态

除了在功能维度深度对标,ONES 致力于为企业打造支持私有化部署、自主可控的下一代智能研发平台。

  • 私有化部署中运行完整 AI 能力:ONES Copilot 智能助手与即将上线的 ONES AI Agent,为用户打造专属智能引擎,深度融合业务流程,精准赋能项目决策,智能规划并执行任务,释放企业研发管理新动能与创新潜能。
  • 开放、灵活且安全的技术底座:ONES 提供更符合本土开发者习惯的插件市场与扩展能力。通过丰富的开放能力和插件生态, 企业能够打造真正贴合业务的研发管理系统,提升效率,推动创新和业务增长。

若您正在寻求 Atlassian Data Center 的替代产品,欢迎联系 ONES 团队,获取详细的 Jira 和 Confluence 迁移方案、成功案例及个性化评估报告。

本人纯后端开发,手里有个 Macbook pro 2015 实在太老了,想换个新款 Macbook.

目前有两个选择

  1. 走国补+教育优惠 14 寸 Pro m5 32G 512G 能到 11000 左右。
  2. 还是某集,14000 左右买个 m3 PRO/MAX 呢?

纠结点在于某集的机器都 23 年了感觉有点老了。

本文首发于 Aloudata 官方技术博客:《DataHub vs Aloudata BIG:银行级血缘精度谁更胜一筹?》转载请注明出处。

摘要:本文聚焦银行数据治理中的核心挑战——监管报送场景下的数据血缘精度问题。通过对比传统列级血缘工具(以DataHub为例)与新一代算子级血缘平台(Aloudata BIG)的技术差异,深入剖析了高精度血缘(>99%)对于实现EAST/1104等报表的自动化盘点、精准变更影响分析和主动风险防控的关键作用。文章结合招商银行、浙江农商联合银行等头部机构的实践,展示了如何将指标口径盘点周期从数月缩短至8小时,为银行数据治理和DataOps流程提供可落地的解决方案。

在金融强监管时代,EAST/1104等监管报表的指标口径追溯已成为银行数据团队的“生死线”。传统血缘工具因解析精度不足,常导致盘点耗时数月、变更影响误报频发。本文将深入剖析银行级场景对血缘精度的严苛要求,对比列级血缘与算子级血缘的技术代差,并基于头部银行的落地案例,论证高精度主动元数据如何将数据治理从事后“考古”转向事前“精准防控”。

1. 场景挑战:银行监管报送的“精度”生死线

金融监管已从“表级”深入到“字段级”和“口径级”。当监管机构质询“EAST报表中的‘对公贷款余额’是否剔除了关注类贷款?”时,数据团队需要给出精确、可验证的答案。然而,监管指标背后是跨越ODS、明细层、汇总层、报表层的复杂加工链路,涉及大量SQL、存储过程及临时表。

核心痛点在于传统粗粒度血缘工具已完全失效:

  • 口径追溯不全:仅能追溯到表或字段,无法穿透 WHEREJOINCASE WHEN 等核心计算逻辑。
  • 人工盘点低效:面对海量代码,数据工程师被迫进行“考古式”排查,全量指标口径盘点动辄耗时数月。
  • 合规风险高企:口径不清、追溯不准,直接导致报送数据质量低下,面临监管处罚风险。

这已不是效率问题,而是关乎银行合规运营与风险管控的“精度”生死线。

2. 传统解法局限:DataHub 等列级血缘为何在银行场景“哑火”?

以 DataHub 为代表的列级血缘工具,其技术原理(基于正则或浅层语法解析)决定了其在银行复杂场景下的固有局限。

主要局限包括:

  1. 解析粒度不足:仅能识别“从A表X列到B表Y列”,对中间的过滤、连接、聚合等计算逻辑视而不见,形成“黑盒”。
  2. 复杂场景支持弱:对DB2、Oracle等核心银行系统的PL/SQL存储过程、动态SQL、临时表解析能力极弱,血缘链路易中断。
  3. 业务价值失真:基于不完整血缘进行的变更影响分析,会产生大量泛化告警(如“下游30张表可能崩”),噪点高,业务与技术难以协同,无法指导有效行动。
对比维度DataHub (代表列级血缘)银行级场景真实需求
解析准确率通常 <80%,复杂SQL下更低>99%,确保口径完整正确,可审计
存储过程解析弱,难以处理,是主要断链区必须深度支持(DB2、GaussDB PL/SQL等)
影响分析精度粗粒度,易泛化,噪音大需行级裁剪,精准识别过滤条件影响,聚焦真实风险

3. 新模式解法:Aloudata BIG 的算子级血缘如何实现“降维打击”?

Aloudata BIG 作为实现算子级血缘解析的主动元数据平台,其核心技术壁垒实现了对传统方法的代际超越。它并非简单的“列级血缘”升级,而是通过 AST(抽象语法树)深度解析,将SQL内部逻辑拆解为最细粒度的算子(如Filter, Join, Aggregation)序列。

三大核心能力构成技术优势:

  1. 99%解析准确率:基于AST的完整解析,覆盖复杂嵌套查询、子查询、临时表穿透,确保血缘图谱的完整性与准确性。
  2. 行级裁剪 (Row-level Pruning):精准识别 WHEREON 等过滤条件,在评估上游变更影响时,自动剔除无关的数据分支。可将评估范围降低80%以上,从“可能受影响”变为“确定受影响”,极大提升运维效率。
  3. 白盒化口径提取:自动将跨越数层的加工逻辑,“压缩”成一段可读、可验证的“最终加工口径”文档,彻底替代人工扒代码,实现监管口径的自动化管理与保鲜。

4. 实践验证:从“数月人工”到“8小时自动”的标杆案例

算子级血缘的高精度价值,已在多家头部银行的核心场景中得到量化验证,成效可复制。

机构核心场景关键成效
浙江农商联合银行监管指标溯源、DB2存储过程解析指标口径盘点从数月缩短至8小时,人效提升20倍;DB2存储过程解析准确率达99%。
招商银行DataOps协同与变更防控、数仓迁移构建自动化迁移工具,节省500+人月;代码上线前评估时间缩短50%,问题整改时间缩短70%。
兴业银行敏感数据治理、异构平台血缘敏感数据标签沿算子级血缘自动扩散,打标效率提升95%;变更影响分析扩散度降低80%。
中国民生银行跨平台端到端血缘、事前事中变更协同新老平台算子级血缘连接准确率 98%;构建了“事前事中变更协作机制”。

共性价值:这些案例共同证明,高精度血缘将数据管理动作从低效的事后补救,转向高效的事前防控与事中协同,实现了对合规风险与运营风险的精准管控。

5. 实施建议:银行如何选型与落地高精度血缘能力?

银行机构应避免陷入“功能清单对比”的陷阱,聚焦“银行级”场景的真实精度与业务价值。

选型评估三大核心维度:

  1. 解析精度与复杂场景支持:>99%准确率和对 DB2/Oracle PL/SQL存储过程的深度解析能力是底线,需通过真实行内SQL进行POC验证。
  2. 业务价值交付能力:能否直接实现“一键溯源”生成口径报告,能否提供“行级裁剪”的精准影响分析,而非泛化告警。
  3. 标杆案例参考:是否有同行在类似的监管报送、DataOps协同场景的成功实践,确保方案的可复制性。

落地推荐“三步走”路径:

  1. 锚定场景:选择EAST、1104等1-2个核心且痛点明显的监管报表,聚焦其中几十个关键指标作为试点。
  2. 能力验证:利用平台的“一键溯源”功能,在几天内快速生成试点指标的完整加工口径和血缘图谱,与业务、合规部门共同核对,验证准确性(>99%)与效率提升(从月到小时)。
  3. 流程嵌入:将已验证的自动化溯源与精准影响分析能力,固化嵌入到DataOps研发流程(上线前卡点)及合规管理流程(季度/年度口径盘点),形成治理闭环。

6. 常见问题 (FAQ)

Q1: DataHub 和 Aloudata BIG 在血缘解析上的最本质区别是什么?

最本质区别是解析粒度。DataHub 提供的更多是表级或列级血缘,只能看到数据在“表”或“字段”间的流动。而 Aloudata BIG 的算子级血缘能深入 SQL 内部,看清每一个“过滤(WHERE)”、“连接(JOIN)”、“聚合(GROUP BY)”操作,如同看清了整个数据加工流水线。这对于需要精确追溯计算口径的银行监管场景至关重要。

Q2: 我们的监管报表很多由DB2存储过程生成,传统工具解析不了,Aloudata BIG能处理吗?

可以,这正是Aloudata BIG的核心技术壁垒之一。其算子级血缘引擎针对DB2、Oracle、GaussDB等数据库的PL/SQL存储过程进行了深度优化,解析准确率可达99%。例如,浙江农商联合银行就利用该能力,成功实现了对核心DB2存储过程血缘的自动化解析与溯源。

Q3: 引入高精度血缘平台(如Aloudata BIG)的实施周期和难度会不会很大?

实施关键在于与现有数据平台的集成。Aloudata BIG支持主流数据库和调度系统,通常可在数周内完成核心链路的接入和解析。建议采用“场景驱动、快速验证”的路径:先选择一个小范围高价值场景(如几十个核心监管指标)进行试点,利用“一键溯源”功能在几天内验证价值(如从月缩短到小时),快速获得内部支持后再逐步推广。

Q4: 除了应对监管,高精度数据血缘在银行内部还有哪些业务价值?

价值广泛,主要包括:1) 变更风控:精准评估上游表结构或逻辑变更对下游核心报表的影响,避免资损。2) 根因定位:数据异常时,快速定位问题源头,提升排障效率。3) 成本治理:识别冗余计算、无效模型,优化计算存储资源。4) DataOps协同:作为研发流程的“控制流”,提升数据交付质量与效率,如招商银行的实践。

7. 核心要点

  1. 精度即合规:在银行监管报送场景下,数据血缘的解析精度(>99% vs <80%)直接决定了合规效率与风险水平。
  2. 代际技术差:算子级血缘基于AST深度解析,具备行级裁剪和白盒化口径提取能力,与传统列级血缘存在本质上的代际差距,能实现精准的影响分析与溯源。
  3. 价值可量化:头部银行实践表明,高精度血缘能将监管指标盘点从数月缩短至8小时,节省500+人月的迁移成本,并将变更影响评估范围降低80%以上。
  4. 选型看场景:银行选型应聚焦“PL/SQL解析”、“一键溯源”、“行级裁剪”等银行级场景的真实能力验证,而非功能列表对比。
  5. 路径宜敏捷:采用“场景驱动、快速验证”的落地路径,从小范围试点快速证明价值,再逐步融入DataOps及合规流程,构建主动风险防控体系。
    • *

本文首发于 Aloudata 官方技术博客,查看更多技术细节与高清交互图表,请访问原文链接:
https://ai.noetl.cn/knowledge-base/datahub-vs-aloudata-big-ba...

本文首发于 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

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