final

1|# 数据库终于开始认真对待文件了：FILE type 之后，AI 数据工程要换一套坐标系 2| 3|Databricks 在 2026 年 8 月 10 日宣布 FILE type 进入 beta。 4| 5|2026年8月10号，他们给数据库加了个原生列类型——FILE type。合同、图片、音频、视频，这些过去只能当附件堆在对象存储里的东西，现在可以直接塞进表的列里，跟你的交易记录、用户指标、运营数据平起平坐。 6| 7|听起来就是个技术小更新对吧？一个 SQL 语法糖。 8| 9|10| 11|这是数据库几十年来第一次承认：文件不是二等公民。 12| 13|<!-- 配图：传统数据库vs FILE type数据库的对比示意图，左边是整齐的表格+外部文件链接，右边是文件直接嵌入列中 --> 14| 15|## 文件一直活在数据库的阴影里 16| 17|过去三十年，数据库和文件系统之间有条清晰的边界。 18| 19|结构化的、能进 SQL 的、需要事务保障的，进数据库。非结构化的、大的、不知道怎么检索的，扔对象存储。S3、OSS、HDFS，随便你怎么叫它，本质就是一个巨大的停车场。 20| 21|这条边界一直运转得不错，直到多模态 AI 开始大规模进入生产环境。 22| 23|企业的 LLM 应用不只是聊天机器人。它们在处理合同条款的语义比对、产品图片的质量检测、客服通话的情绪分析。这些场景里，输入往往不只是一段文本，还包括 PDF、音频、图片和视频。 24| 25|一个问题冒出来了：你的文件在哪？ 26| 27|在 S3 的某个 bucket 里，路径写在业务表的一个 varchar 字段里。每次 AI pipeline 要跑，先从数据库查出路径，再去对象存储拉文件，解码，预处理，推理，再把结果写回数据库。 28| 29|链路长到让人想吐。而且权限要管两套（数据库一套、对象存储一套），血缘追到一半就断，审计员问你"这条推理结果是从哪个版本的合同来的"，你得打开三个系统查。 30| 31|这不只是效率问题。这是在用 2010 年的数据架构，硬撑 2026 年的 AI 负载。 32| 33|## FILE type 到底改变了什么 34| 35|Databricks 这次的 FILE type，核心逻辑很直接。 36| 37|文件不再是"外面"的东西。它是表的一部分。 38| 39|你建表时可以定义一列类型为 FILE。Databricks 的官方说明称，FILE 列保存的是指向文件的轻量指针，而不是把沉重的二进制直接塞进表文件；查询需要时，SQL 或 Python UDF 才处理文件内容。（来源：https://www.databricks.com/blog/introducing-file-type-native-column-type-multimodal-data） 40| 41|类比一下：以前你的文件系统是房子外面的仓库，要找东西得走出去翻。现在仓库直接嵌在墙里，拉开抽屉就能拿到原件。数据库管索引、管权限、管版本、管血缘。 42| 43|<!-- 配图：FILE type工作原理示意图，展示文件、索引、元数据在同一行记录中的结构 --> 44| 45|这带来三个连锁反应。 46| 47|第一，数据工程栈开始塌缩。 以前"文件预处理"是一个独立阶段，需要专门的 ingestion pipeline 把 PDF 转文本、把视频抽帧、把音频做 VAD 切分。现在这些事情可以推迟到查询时再做。你存原始文件，只在需要推理的时候才 decode。这听起来像是懒加载，但它的真正含义是——你不再需要提前决定"这个文件将来会被怎么用"。 48| 49|第二，AI 推理变成了数据库的内置函数。 这不是 Databricks 独有的方向，Snowflake 的 Cortex、BigQuery 的 Vertex AI 集成都在往这走。当文件住在数据库里，调用模型对文件做分类、摘要、问答，就跟 COUNT(*) 一样自然。SQL 正在变成 AI 的 orchestration 语言。 50| 51|第三，治理边界重新划定。 以前数据治理管结构化数据，内容治理管文件，两拨人、两套工具、老死不相往来。现在文件进了表，column-level 的权限管控、行级安全策略、数据血缘追踪，自动覆盖到了非结构化内容。审计一条推理结果的来源，能从模型输出的 token 一路追到原始合同文件的版本。 52| 53|## AI 数据工程要换坐标系了 54| 55|几个月前 OpenAI 发了篇文章，讲一家公司怎么构建 AI-native 的财务部门。里面有个细节——他们的财务工作从"定期结账"变成了"实时观察业务变化"。 56| 57|数据工程的思路也在发生类似的转向。 58| 59|过去十年，数据工程的核心是 ETL/ELT——把数据从 A 搬到 B，做清洗、做宽表、做聚合，然后把"处理好的数据"交给分析师和模型。整个范式建立在"预处理"这个假设上。 60| 61|FILE type 和它所代表的方向，让这个假设变得可疑了。 62| 63|当文件可以内嵌进数据库、AI 推理可以在查询时动态执行，"预处理"就开始让位给"按需推理"。 这改变了数据工程师的核心工作。不再是把一份数据搬运、清洗、转存三次，而是设计数据模型让文件以原始形态被治理、被检索、被推理。 64| 65|这不是说 ETL 会消失。结构化数据仍然需要 pipeline，维度建模仍然有价值。 66| 67|对于合同、邮件、图片、录音等非结构化内容，团队可以更多采用"先存储、后按需推理"的路径，但这不会取代所有预处理。 68| 69|<!-- 配图：数据工程范式转移对比，左侧是传统ETL流程，右侧是按需推理的新范式 --> 70| 71|这件事和 2010 年前后那波 NoSQL 运动对比挺有意思。 72| 73|当时 NoSQL 的卖点是"数据模型跟访问模式对齐"——文档数据库适合读多写少的场景，列族数据库适合宽表扫描，图数据库适合关系遍历。关系型数据库的"一张表适应所有场景"被打破了。 74| 75|现在 FILE type 做的事情类似，但维度不同。它在打破"数据类型决定处理方式"的旧认知。 以前文件类型天然决定你要用哪个存储系统、哪个处理框架、哪个治理工具。现在数据库说：放进来，我统一管。 76| 77|这不是数据库 in 框架 out 的故事，而是整个栈在重新分工。 78| 79|## 麻烦在后面 80| 81|AWS 最近一篇案例文章称，nOps 借助 Bedrock AgentCore 将 FinOps agents 的交付速度提升了 75%。文章同时描述了运行时、数据语义层和应用状态等生产化组件。（来源：https://aws.amazon.com/blogs/machine-learning/how-nops-shipped-finops-agents-75-faster-with-amazon-bedrock-agentcore/） 82| 83|这话放在 FILE type 上同样成立。 84| 85|把文件放进数据库只是第一步。真正难的是——你怎么处理版本？一个合同的终版和三个中间版本，你建四行还是用一列存历史？你怎么处理推理结果的可复现性？同一个 PDF，调用模型两次可能结果不同，你怎么向审计方解释？还有成本，查询时推理意味着每次 SELECT 都在烧 GPU，你怎么做查询优化、结果缓存、推理降级策略？ 86| 87|这些问题 Databricks 自己也还没给全答案。文档里 GA 时间、性能数字、具体 SQL 语法都写着"以最新文档为准"。 88| 89|这不算缺点。 90| 91|新技术刚出来的时候，Questions 比 Answers 多才是正常状态。2013 年用 Spark 的人也不知道流批一体到底能走多远，2018 年用 Kubernetes 的人也没想到 operator 模式会成为标准。方向比完善程度重要。 92| 93|数据库终于不再假装文件不存在了。这个信号本身，就比任何一个具体实现都值钱。 94| 95|接下来两年，数据工程团队要补的课不少。SQL 里操作文件、设计按需推理的数据模型、把向量检索和价值检索塞进同一个查询计划——这些技能今天还算小众，两年后可能就是基础要求。 96| 97|坐标系换了，之前的地图也只能用一小半。新地图还没画完，但至少方向是对的。 98| 99|