ODPS 的下一个15年,大数据将迎来春天还是寒冬?
我不是从第一行 ODPS 代码写起的人,但我是那个在 DataWorks 里跑着 SQL 的年轻工程师,也是在凌晨调 Flink 作业失败后,看着 MaxCompute 控制台发呆的人。
十五年了,ODPS 不是一行代码的故事,是一群中国工程师啃下来的一块硬骨头。
它在没有 Hadoop Spark 那么全球光环的起点下,照样支撑起双十一的千亿级数据洪流,也成了我们团队数仓从 Hive 到云原生迁移的压舱石。
AI 崛起后,数据世界变了,但地基更重要了,现在是 AI 的时代,但 AI 已经从拼模型、卷参数变成了拼数据。
数据质量 是大模型的食粮,
数据治理 是 AI 产品能否上线的底线,
数据工程师的能力,正从幕后走向核心引擎。
所以我不觉得 ODPS 会在 AI 时代被取代,相反,它更有机会成为下一代 AI 的基建平台。
ODPS,下一个15年你该做什么?
如果我是产品经理,或者说,如果我是社区里那个吵吵闹闹但真心希望它更强的用户,我想 ODPS 应该优先突破这些能力:
原生 AI 能力整合:从查询平台进化为智能数据引擎
模型找数据 → 数据找模型 → 最终是数据懂模型
内建 LLM 推理服务(如 Tongyi、Qwen)
查询+推理的融合语法(例如 SELECT WITH AI_MODEL(...))
支持 LangChain、RAG 模式直接调用 ODPS 数据
表达式/标签生成自动提示:大语言模型辅助开发
低延迟 查询和交互式开发体验
Data as Code 不应等待一分钟反馈
ODPS SQL 支持 子秒级交互式查询(如 Presto / DuckDB 模式)
扩展 PyODPS,增强对 Pandas/Arrow 的无缝连接
支持 Notebook 与 ODPS 数据的零摩擦联动
实时/离线/AI 任务统一调度 DAG
不只是湖仓一体,更是任务统一
Flink + ODPS 的物理隔离 & 调度融合
AI 推理任务节点支持与 SQL 一起调度
数据治理、合规校验作为系统内置节点加入 DataWorks
面向数据产品经理的一站式平台
给非技术人可复用的数据能力,是下一代增长点
ODPS 的 SQL 作业结果自动生成图表 / 报告
一键发布为 API / 数据服务
内建权限管控与多租户支持,让数据被复用而不是重复生产
一句话:
ODPS 是老兵,但不是老旧;AI 是时代洪流,但数据是河床,唯有脚下的地基,决定我们走多远。
我相信,ODPS 如果能带着中国工程师的实干、深入业务场景的能力、对数据底层逻辑的深刻理解,它不仅能穿越 AI 寒冬,更可能在数据智能浪潮中,再次站到时代的算力之巅。下一个 15 年,我们共同定义。
赞11
踩0