美联航不搬数据，湖仓打法变了

美联航做了一件让很多人意外的事：它没有把Databricks里的数据搬到Redshift里，而是直接用Redshift查询了Databricks管理的表。

AWS官方博客最近披露了两个案例。一个是美联航（United Airlines）通过AWS Glue Data Catalog联邦查询能力，从Amazon Redshift Serverless直接查询Databricks Unity Catalog托管的数据，全程不复制数据；另一个是Apache Iceberg物化视图的自动查询改写，慢查询不用改一行SQL就能透明加速。

两个案例单看都是技术细节，放在一起看，是一个明确的产业信号：湖仓之间的竞争焦点，正在从「谁把数据圈进自己的存储」转向「谁能在别人的数据上把活干好」。

数据不搬家，正在成为头部企业的默认选择。

📈 美联航的账本：复制数据的隐性成本压不住了

每个搭过数据平台的人都经历过同样的场景：业务方用Databricks做特征工程和机器学习，报表团队又用Redshift出经营数据。两套引擎，两份数据，中间靠ETL管道复制同步。

管道一多，问题就来了。同一张表的两份副本，凌晨跑批时差了半小时，上午的报表就有一栏对不上。存储成本双份，开发人力双份，数据一致性还要三份人力去兜底。

业内私下有句话很扎心：「大厂数据团队一半的人力，花在让两份数据看起来像一份数据上。」

美联航的解法是不复制。根据AWS披露的技术方案，Redshift Serverless通过AWS Glue Data Catalog的联邦查询能力直接访问Databricks Unity Catalog托管的数据，中间用resource link建立引用，权限治理则交给AWS Lake Formation统管。

整条链路可以拆开看：

这个架构的关键不是「能查到」，而是治理不断链。权限在Lake Formation一处定义，数据在Databricks一处维护，查询方无需知道底层表存在哪个存储引擎里。

产业逻辑很直白：当复制数据的成本（存储、管道、一致性校验）高到超过跨引擎查询的损耗时，联邦查询就从「技术选项」变成「必选项」。头部企业的数据规模越大，这个临界点来得越早。美联航这种体量的航司，显然早就过了临界点。

💡 物化视图改写：性能优化的「无感化」趋势

第二个案例解决的是另一个老问题：快。

场景是这样的。分析师每天跑同样的Spark作业，扫同一批Iceberg大表，每次都全量扫描，几TB的数据读一遍，等十几分钟。最优解明明是预聚合一张物化视图，但改SQL、建调度、管刷新，一套下来开发成本不低，而且谁也说不准哪些查询值得做物化。

AWS给出的方案是把这件事自动化：在Amazon EMR和AWS Glue上，Spark的查询计划会自动和Glue Data Catalog里登记的Iceberg物化视图做匹配，命中就透明替换，直接读预计算结果。用户一行SQL都不用改。

流程大致是这样：

这个案例的意义容易被低估。表面看是性能优化，实质是把优化决策从「人」转移到「基础设施」。自动改写的前提是查询计划和物化视图的元数据都能被机器读懂——这背后是Iceberg元数据体系的成熟，也是数据目录角色的一次升级。

判断是：未来几年，「先测速、再改写、后上线」的人工优化路径会被逐步压缩。引擎自己发现慢查询、自己匹配物化视图，会成为基础能力而不是专家技能。对普通数据团队来说，这是实打实的降本——不是省存储，是省那些维护优化方案的高级工程师。

⚠️ 数据目录的野心：从登记处变成互操作总线

把两个案例叠起来看，会发现一个共同点：AWS Glue Data Catalog都在C位。

联邦查询里，它是跨平台元数据的翻译官——Databricks的表经它映射，Redshift才能看见；物化视图里，它是查询改写的决策依据——没有目录里登记的元数据，改写根本无从谈起。

这就是当下湖仓竞争真正的暗线。表面上大家争的是存储格式（Iceberg、Delta、Hudi）和计算引擎，实际上，谁能成为企业元数据的「中立登记处」，谁就掌握了互操作的咽喉。

这个格局可以这样理解：

Databricks推Unity Catalog开放化，AWS把Glue Data Catalog做成联邦查询枢纽，两边看似都在「开放」，实质都在争夺那个登记处的位置。数据格式靠Iceberg这样的开源标准收敛了，但元数据层的控制权之争才刚开场。

据多位接近AWS的合作伙伴透露，类似的跨目录联邦需求在客户侧相当普遍，多数客户的技术栈早就是多引擎、多云的混合状态——单一供应商解决不了全部问题，客户反而成了倒逼厂商开放的最大力量。

这可能是这个时代数据基础设施最健康的一点：竞争的尽头不是垄断，而是接口标准化。就像TCP/IP之于网络，湖仓领域的「TCP/IP时刻」正在元数据层发生。

🚗 对国内数据平台的启示：别再把复制当集成

看完美国头部客户的打法，回看国内，有几个值得认真琢磨的对照。

国内数据中台建设这些年的主流模式，依然是「建一套平台，把数据都复制进来」。各业务系统入库，形成ODS-DWD-ADS分层，中间靠调度管道维持同步。这个模式在单一技术栈下运转良好，但近年来国产化改造、多引擎并存的现实下，复制式集成的成本问题被急速放大：同一份业务数据，往往要在多个引擎、多个平台各存一份、各跑一套治理。

美联航的案例给出的是另一种思路：数据留在原地，能力走向数据。查询能力可以跨目录联邦，治理能力可以统一下沉，加速手段（物化视图）可以挂在元数据上而不是绑死在某一份数据副本上。

对照三个维度的差异，看得很清楚：

当然，联邦不是银弹。跨网络的查询延迟、复杂计算的引擎能力差异、跨平台的权限模型对齐，都是工程上要逐个啃的硬骨头。美联航案例里用resource link和Lake Formation打通治理，恰恰说明「查得到」只是第一步，「管得住」才是联邦方案能否大规模落地的分水岭。

国内平台厂商值得注意的一点是：先把目录做好，再谈互通。没有一套干净、中立、覆盖权限的元数据目录，联邦查询和自动优化都是空中楼阁。

小结

美联航不搬数据，是一个具体客户的工程选择，也是一面照出行业方向的镜子。

当Iceberg把存储格式统一、当数据目录承担起联邦查询和自动优化的枢纽角色，湖仓竞争的胜负手就从「圈数据」变成了「通数据」。对企业而言，下一步该做的不是再建一套平台，而是把元数据目录的地基打牢——数据留在原地，让计算、治理和加速能力过来找它。

复制式集成不会立刻消亡，但它的退场时间，可能比多数人预期的更早。