从数据血缘到AI Agent:天翼云 × DolphinScheduler 的云上调度新篇章
直播回放:https://www.bilibili.com/video/BV1X2tdziE9Z/?vd_source=e59b2227d15c7740a5c5f40e4a675095
在数据驱动与智能化的浪潮下,数据调度平台的价值正在被重新定义。天翼云翼 MR 与 Apache DolphinScheduler 的结合,不仅是一次技术选型,更是一次从社区到企业的深度融合与创新探索。
作者介绍
社区共建:从使用到贡献
天翼云团队与 Apache DolphinScheduler 社区的合作由来已久。除了在生产环境中深度使用外,团队成员也积极参与社区建设,通过PR提交、问题反馈、功能建议等多种方式推动项目迭代。
部分贡献示例:
- PR #17037:优化任务执行逻辑
- PR #17165:新增日志获取客户端
这种双向互动,不仅让平台更贴合实际业务需求,也让社区获得了来自一线生产的真实反馈。
翼MR+DolphinScheduler:云上大数据的稳定基座
作为天翼云的大数据计算平台,翼MR为用户提供了即开即用、安全可靠、便捷管理的公有云形态:
更重要的是,翼 MR 与大数据组件实现了自动集成 ,用户在DolphinScheduler 中调度任务时,无需繁琐的环境配置,即可直接调用 Hive、Spark、Flink 等组件。
此外,平台内置的基于 Apache DolphinScheduler 优化的监控与运维系统 ,为任务执行提供全链路可视化管理,帮助运维人员快速定位问题、优化性能。
二次开发:让调度更贴近业务
在生产环境中,天翼云团队基于DolphinScheduler进行了多项定制化优化:
-
结果集标准化 将节点输出统一为CSV格式,降低内存占用、提高落盘效率。
-
全链路血缘追踪 可视化展示数据从采集、加工到输出的全路径,支持任务间依赖分析与审计。
通过 SQLLineage4J、SQLLineage 和 GSP 三大解析引擎,把各类 SQL 脚本解析成血缘关系,保存到元数据中心;随后由数据地图、数据服务等下游模块消费这些血缘信息,实现数据资产的可视化、查询和影响分析。
-
第三方任务系统集成 支持通过界面化注册接入第三方任务系统(如 Dinky、AWS EMR),并可借助 OpenAPI 直接提交任务,减少接入开发成本。
这些优化大幅提升了任务调度的灵活性与可维护性,也为不同类型的业务提供了统一的调度中枢。
面向AI时代的展望
最后,我想分享一下我关于在 Agentic AI 趋势下,DolphinScheduler 的展望。在 Agentic AI 时代,用户对 Dolphinscheduler 的要求,或者说使用方式正在发生变化。例如在 6 月份的 Meetup 上,社区分享了 DolphinScheduler 的 MCP(Model Context Protocol)相关探索,这意味着未来DolphinScheduler的"用户"可能从人类开发者延伸到AI Agent。
也许不久的将来,Dolphincheduler 的目标用户会变成 agent,调度平台将不再只是面向人类的 Web 控制台,而是 AI 工作流中的一环。当然,我觉得 Dolphinscheduler 在这个环节中具有天然优势,因为虽然大数据各种组件都在搞自己的 MCP Server,但是 Dolphinscheduler 作为一个集成了几乎所有大数据组件的调度平台,相比让各个组件自研 MCP Server,由DolphinScheduler 作为统一调度入口,它会更加高效、更易维护,也更轻量。
理想很丰满,那么这些想法该如何落地呢?我认为,正如代立冬在issue #17334提出的那样,引入大模型能力,是迈向这一未来的第一步。作为社区的一份子,我呼吁大家积极加入到这个话题的探索之中,群策群力,共同早日把我们的设想落实下去。
写在最后
天翼云翼 MR 与 Apache DolphinScheduler 的结合,是一次社区与企业的双向奔赴,也是在 AI 浪潮下对调度平台角色的新思考。未来,随着 Agentic AI 的发展,这一组合将在更多场景中释放价值。
如果你对大数据调度、AI 工作流感兴趣,欢迎通过公众号、Slack、GitHub 加入 Apache DolphinScheduler 社区,一起探索数据调度的更多可能。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
为什么你拿捏不住客户的“真”需求?
往前推10年,似乎都很难看到当下竞争如此激烈的环境。 国内新能源汽车已步入"半年一改款、一年一换代"的快速迭代周期,稍有懈怠就可能被竞品甩开半个身位。 电商领域也从传统零售巨头到新兴电商平台,再到社交媒体电商,都在全力争夺有限的市场份额。 在市场竞争日趋激烈、需求快速变化的大环境下,市场需要什么 、客户青睐什么,就变得格外重要。 但现实是,很多企业仍在关起门来想需求,坐在办公室里拍脑袋,把老板的一句话、内部的一个想法当成市场的真实声音。 但需求从来不是静态的标准答案,需要不断挖掘、验证、调整。脱离了市场土壤的需求,就像无源之水,以此开发的产品注定难以获得市场认可。 企业该如何打破这种困境? 或许IPD集成产品开发体系下的动态需求管理方法,正是破局的关键。 需求,对抗市场不确定性 IPD将需求管理拆解为"需求收集-分析-分发-实现-验证"这五个相互衔接的阶段,形成一个完整的闭环流程。 这套流程既能捕捉散落在市场各处的需求,又能避免需求变更失控 、碎片化等问题。 1.需求收集:像喇叭口一样广纳需求 需求收集阶段的核心是不遗漏。此处常用的方式包括客户深度访谈、焦点小组讨论、用户行为数据分析、...
- 下一篇
技术文档 | Pulsar 中的消息保留、过期及积压机制解析(上)
在Pulsar broker中, 消息的Retention, Expiry和Backlog quota是比较重要的功能,它们表现的是Pulsar对于流经它的数据的管理。 但是受限于复杂度和文档语言等因素,使用者可能无法在第一时间很直观的了解它们。 因此本文将对这三个功能进行详细的介绍,包括概念、行为、应用、实现和注意事项等方面,希望能够对大家有所帮助。 另外,这三个特性属于Pulsar的高级特性,阅读本文之前,建议先对Pulsar的基本概念有所了解。 文章较长,并且偏向工具类,建议大家先收藏,如果暂时没耐心看完,也可以在后续时间慢慢阅读。 话不多说,直接开冲! 一、Retention 1. 概念 Retention是Pulsar对消息的保留策略,它针对于所有消息,包含已经消费的消息和未消费的消息。 Pulsar的消息保留略有一点反直觉,我们一般会认为消息保留针对已经消费完毕的消息,在消费完毕后保留一段时间之后再进行清理,腾出磁盘空间。很多资料以及之前版本的Pulsar官网都是这样理解和表达的,但是实际并非如此。 Retention首先保证的是消息回溯,比如将保留策略设置为3天,用户一定...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Hadoop3单机部署,实现最简伪集群
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS8安装Docker,最新的服务器搭配容器使用
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7,CentOS8安装Elasticsearch6.8.6