干了十几年数据库以及数据平台建设，我经历过从最早的Hive数仓一路走到今天的湖仓一体。
而在到了最近开始研究多模态，我脑子里反复跳出一个念头：我们引以为傲的ODS -> DWD -> DWS -> ADS四层架构，在多模态时代，是不是已经走到了它的黄昏？
这不是说四层架构错了。过去十五年，这套分层逻辑支撑了中国绝大多数企业的数字化转型，它的核心目的是通过层层聚合减少重复计算，服务于人的BI分析和报表展示。
但在多模态和AI时代，数据消费者从人变成了模型和Agent，数据类型从结构化数值变成了文本、图像、音视频和向量。此时再硬套传统的四层模型，会发现整个架构有可能出现问题。
一个绕不开的困境
传统四层架构有一个隐含的底层假设，一切数据都可以且应该被SQL化。
ODS贴源，DWD清洗，DWS聚合，ADS出报表。这条链路里的每一步，都是围绕关系型设计的。哪怕是Hive、Spark这些大数据引擎，最终暴露给开发者的依然是SQL。
但这恰恰是多模态时代的最大绊脚石。
大家有没有想过，将一段视频拆解为音轨、字幕、视觉特征，再转化为向量，这个过程用SQL怎么写？把一篇混合图表和正文的PDF解析成结构化的段落，再调用OCR和Embedding模型生成向量矩阵，这在DWD层怎么建模？
如今可能变成了写一堆Python脚本或Spark任务跑AI处理，然后把结果以结构化表的形式写回数仓。这就形成了一种外挂式的管道，AI处理逻辑在数仓之外，结果又硬塞回数仓之内。一旦上游源数据更新，如何保证AI处理？如何追踪向量是用哪个版本的模型生成的？
传统数仓的调度体系和血缘体系，对此几乎无能为力。
四层架构的水土不服
如果强行套用四层架构，你会发现每一层都在经受巨大的张力。
ODS层，从贴源快照变成了非结构化泥潭。以前ODS层就是业务库的备份，一张表几百个字段。现在呢？各种PDF、Word、监控视频、录音文件涌入。此时ODS层存储的不仅是行和列，更是海量的对象存储指针和原始文件元数据。如果用传统的Hive表格去管理这些非结构化数据，元数据管理很快就会崩溃。
DWD层，从清洗降维变成了解析与向量化。这是传统数仓和AI数据平台彻底分道扬镳的一层。DWD层不再是简单的去重和标准化，产出的不再是纯结构化的明细表，而是结构化字段和对象存储地址加向量列的混合体。如果把向量当成BINARY列存进Parquet，然后试图用SQL去做相似度检索，那么恭喜你，喜提了全表扫描的体验券。
DWS层，从轻度汇总变成了跨模态对齐与特征融合。传统DWS层是GROUP BY和SUM/COUNT的天下。但多模态场景下，你不可能把两张图片求和，也不能把两段音频求平均值。传统的宽表打宽逻辑在这里失效了，取而代之的是知识图谱的构建。
ADS层，从报表数据集变成了Agent的上下文网。以前ADS层对接的是BI工具，服务对象是人。现在ADS层暴露出来的应该是API，这一层不再是给分析师看数字的，而是给Agent提供外部记忆的。
发现没？每一层的使用场景都在发生剧变，但是又没有一个整体方案。
可能演进的方向
说了这么多问题，不是为了否定分层架构。相反，分层的思想依然有效，因为它帮助我们解耦了系统复杂性。但分层的内涵需要被彻底重构。
从目前很多技术社区的探索来看，几个方向值得关注：
一是把Embedding Pipeline真正纳入。 不再把AI处理当成外挂脚本，而是纳入数据管道的核心框架。任务调度不仅要管SQL，还要管GPU推理任务；血缘不仅要看表，还要看模型版本和Prompt模板。
二是统一向量湖的兴起。用统一元数据服务来管理结构化数据和向量数据的关联，就是一个很好的思路。让RAG和多模态检索能够在湖仓内部完成，而不是外挂一个向量数据库，这能极大缓解双系统困境。
三是语义层的建设。 湖仓表格式解决的是物理存储和事务问题，但AI场景还需要一层语义元数据embedding的生成模型版本、特征的定义和口径、检索结果的可追溯性。这层语义能力目前是缺失的，需要用独立的元数据服务和数据目录来补上。
多模态时代，ODS、DWD、DWS、ADS这四个词大概率会继续留在我们的架构图里。但它们不再是简单的层层递进的表，而是变成了不同形态的数据处理的不同区域，车间名字没变但是加工的东西变了。而未来我猜测，很可能短期内还是两个数据平台并行着跑，一套是是围绕T+1的报表和SQL查询的，一套是围绕T+0的语义检索和Agent消费设计的。
