Snowflake Cortex AISQL将AI操作符原生注入SQL引擎重新定义查询语言；Databricks Liquid Clustering以8大误区逐一击破宣告分区时代终结；Snowflake Openflow GA与Anthropic深度合作构建治理AI数据栈

第十四期追踪到DataInfra领域三条重要动态：Snowflake Summit 26于6月1-4日在旧金山Moscone Center举行，首日发布Cortex AISQL公开预览——这是SQL语言自1974年诞生以来最根本的扩展：AI_FILTER在WHERE子句中执行AI驱动的语义过滤、AI_JOIN基于AI关系而非预定义键进行连接（如简历与职位描述的语义匹配）、AI_AGG与GROUP BY配合执行AI驱动的聚合、AI_CLASSIFY支持文本和图像多标签分类，所有AI操作符作为SQL一等原语直接嵌入Snowflake查询引擎，配合新增FILE数据类型原生引用多模态数据（文本/图像/音频），Adaptive LLM Optimization策略性编排大小模型（简单任务用小模型、复杂分析用大LLM），内部基准显示查询运行时间降低70%——SQL从”结构化查询语言”正式走向”AI查询语言”；Databricks 6月1日发布博客”Debunking 8 Data Layout Myths”——全面对比Liquid Clustering与Hive风格分区，8大误区逐一击破：现代开放表格式用事务日志和文件级统计信息剪枝不需要目录剪枝（误区1）、Liquid Clustering自动检测低基数优化且查询快22%（误区2）、支持元数据级DELETE/聚合快27倍（误区3）、数十客户已运行PB级LC表且OPTIMIZE规划从12h降至23min（误区4）、输出标准Parquet文件任何引擎可利用统计信息跳过文件（误区5）、行级并发替代文件级并发（误区6）、增量聚类优于Z-Ordering的定期重写（误区7）、原生支持选择性覆盖（误区8），Arctic Wolf在3.8PB安全遥测表上实现7.7倍查询加速（51s→6.6s），Bolt CDC表写入吞吐量增加138%，即将推出Liquid-to-Liquid Join优化（51%加速/87%洗牌减少）和分区表原地转换；Snowflake同日宣布Openflow GA和Anthropic深度合作——Openflow是基于Apache NiFi的多模态数据集成服务，支持结构化和非结构化数据、批处理和流式摄取统一，AWS全商业区BYOC部署，Oracle连接器使用原生XStream API实现37K TPS下仅3% CPU开销的近实时CDC，Yes Energy将10天初始加载缩短至6小时以内；Anthropic深度合作方面，Claude驱动Cortex Code和Snowflake Intelligence，Cortex Code成为Snowflake历史上增长最快产品，Block/Carvana/eSentire/Indeed/Notion等企业在生产环境使用Claude on Cortex AI进行网络安全调查/财务分析/数据应用开发——这三条动态共同指向DataInfra的又一个维度跃迁：查询语言从”只处理结构化数据”走向”原生处理AI和多模态”（Cortex AISQL），数据布局从”静态预定义”走向”动态自适应”（Liquid Clustering），AI治理从”模型外挂”走向”平台原生”（Snowflake+Anthropic）。

Snowflake Cortex AISQL：AI操作符原生注入SQL引擎，查询语言的范式跃迁

事件概述

6月1日，Snowflake在Summit 26发布Cortex AISQL公开预览。Cortex AISQL将强大的AI能力直接集成到Snowflake SQL引擎中，让数据分析师使用熟悉的SQL命令构建可扩展的AI管道——不是在SQL外面套一个AI壳，而是将AI操作符作为SQL的一等原语嵌入查询引擎。核心AI操作符包括：AI_FILTER（在WHERE子句中执行AI驱动的语义过滤）、AI_JOIN（基于AI关系而非预定义键进行连接，如根据AI评估的适配度将简历与职位描述匹配）、AI_AGG（AI驱动的聚合操作符，与GROUP BY配合使用）、AI_CLASSIFY（支持文本和图像的多标签分类）、AI_COMPLETE（AI补全）、AI_EMBED（嵌入生成）、AI_SIMILARITY（相似度搜索）、AI_SUMMARIZE_AGG（AI摘要聚合）、AI_TRANSCRIBE（音频转录）。新增FILE数据类型允许直接在Snowflake表中引用多模态数据（包括文本、图像和音频），所有AI操作符可无缝跨越各种数据模式工作。内部基准测试显示查询运行时间减少高达70%。Cortex Code——Snowflake的AI编码代理——被EVP Christian Kleinerman称为”Snowflake历史上增长最快的产品”。

技术解析

• AI操作符作为SQL一等原语：AI_FILTER、AI_JOIN、AI_AGG等操作符与现有的SQL原语（如FILTER、AGGREGATE、JOIN）处于同一抽象层级。这意味着AI能力不再是需要从外部调用API的附加功能，而是SQL语法树的一等节点。数据分析师可以在一个SQL查询中混合使用传统过滤和AI过滤、传统JOIN和AI JOIN、传统聚合和AI聚合——无需在SQL和Python之间切换，无需管理外部AI管道。
• FILE数据类型——多模态数据的原生引用：新的FILE数据类型让Snowflake表可以直接存储和引用文本文件、图像和音频文件，而非将其URL作为VARCHAR存储再通过UDF处理。AI操作符原生理解FILE列——AI_CLASSIFY可直接对FILE列中的图像分类，AI_TRANSCRIBE可直接转录FILE列中的音频。这消除了”结构化数据在Snowflake、非结构化数据在对象存储”的二分法。
• Adaptive LLM Optimization——大小模型策略性编排：私有预览功能，策略性地编排较小模型处理简单任务，保留大型LLM用于复杂分析。这解决了AI-in-SQL的核心成本问题——不是每个AI操作都需要Claude Opus级别的推理，简单分类用小模型更快更便宜，复杂分析才需要大模型。查询优化器可以像选择索引扫描还是全表扫描一样，选择大模型还是小模型。
• 智能执行规划：先应用标准过滤器缩小数据集，再使用视觉语言模型进行复杂评估。例如，先用传统WHERE条件过滤出”最近7天的客户投诉”，再用AI_FILTER在结果集上执行”关于产品质量而非服务态度的投诉”——这种”传统过滤+AI过滤”的流水线式执行大幅减少AI调用量和成本。
• AI_JOIN——基于语义关系的连接：传统JOIN需要预定义的等值条件（如resume.job_id = position.id）。AI_JOIN基于AI评估的适配度进行连接——如将简历与职位描述按语义相关性匹配。这开启了全新的分析模式：从”数据必须有预定义关系才能连接”到”数据有语义关系就能连接”。
• 操作符可用性矩阵：AI_COMPLETE/AI_FILTER/AI_CLASSIFY/AI_SIMILARITY/AI_AGG/AI_SUMMARIZE_AGG在文本场景公开预览，AI_COMPLETE/AI_FILTER/AI_CLASSIFY/AI_SIMILARITY在多模态场景公开预览，AI_EMBED即将推出，AI_TRANSCRIBE（音频）即将推出，AI_FILTER自适应优化私有预览。

行业影响

Cortex AISQL的深层意义不是”Snowflake加了一些AI函数”，而是SQL语言自诞生以来最根本的语义扩展。1974年SQL首次被提出时，它假设数据是结构化表格、操作是关系代数、结果是确定性的。50年来SQL的扩展（窗口函数/CTE/JSON/地理空间）都在这个假设框架内——操作对象是结构化数据，操作方式是确定性计算。Cortex AISQL打破了这三个假设：操作对象从结构化数据扩展到多模态数据（FILE类型），操作方式从确定性计算扩展到AI推理（AI操作符），结果从确定性输出扩展到概率性输出（AI_FILTER的判断可能因模型版本不同而变化）。

这与Vol.7报道的Spark 4.1 SQL Scripting + VARIANT GA、Vol.11报道的ClickHouse Agents代理分析形成互补——Spark让SQL表达复杂业务逻辑，ClickHouse让代理分析数据，Cortex AISQL让SQL原生调用AI。三者共同指向一个趋势：SQL正在从”结构化查询语言”进化为”AI查询语言”——不是替换SQL，而是在SQL的框架内扩展AI能力。

TechTarget报道中CHG Healthcare的AI总监Sam Biggs评价：“去年我们听到很多’这可能会来’，今年基础设施已经就位，下周就可以在键盘上做比几个月前更多的事情。“Ericsson数据科学总监Joji Phillip说：“75%的新功能发布都是AI相关的——Cortex AISQL、语义模型和Openflow是我们最感兴趣的。“这些客户反馈印证了一个判断：企业AI的瓶颈不是模型能力，而是AI与数据基础设施的整合深度——Cortex AISQL直接将AI注入SQL引擎，消除了”AI栈”和”数据栈”之间的裂缝。

相关链接

• Introducing Cortex AISQL: Reimagining SQL into AI Query Language for Multimodal Data
• Snowflake and Anthropic Accelerate Enterprise AI Adoption
• Customers pleased with Snowflake plans for AI (TechTarget)

---

Databricks Liquid Clustering全面超越分区：8大误区逐一击破

事件概述

6月1日，Databricks发布博客”Debunking 8 Data Layout Myths: Why Liquid Clustering Outperforms Partitioning”，由Jeffrey Gong、Yu Xu和Rahul Mahadev撰写。这篇博客系统性地比较了Liquid Clustering（液体聚类）与传统Hive风格分区在数据湖仓场景下的表现，逐一击破8个常见误区，并用生产客户案例和基准测试数据支撑论点。核心结论是：Liquid Clustering在现代开放表格式（Delta Lake/Iceberg）的架构下全面优于分区——支持动态变更聚类键、自动优化、避免小文件问题、支持多维聚类、提供行级并发而非文件级并发。Arctic Wolf在3.8+ PB安全遥测表上实现7.7倍查询加速（51s→6.6s），Bolt CDC表写入吞吐量增加138%，Databricks内部1.1 PB工作负载查询加速5.9倍且读取字节数减少86%。博客还预告了两项即将推出的功能：Liquid-to-Liquid Join优化（私有预览，Join速度提升51%、数据洗牌减少87%）和分区表轻松转换（私有预览，原地转换最小化停机时间）。

技术解析

• 误区1：分区因目录剪枝更快——现代开放表格式（Delta Lake/Iceberg）使用事务日志和文件级统计信息（min/max值）进行剪枝，不存在文件系统目录级快捷方式。分区在逻辑层面等同于按列值分组文件，这与Liquid Clustering的文件级数据组织在剪枝机制上无本质区别——剪枝的决定因素是统计信息精度，不是物理目录结构。
• 误区2：低基数列分区更优——Liquid Clustering自动检测低基数优化。当按(date, user_id)聚类时，系统确保每个文件仅包含单个日期的行。基准测试显示：聚类时间降低35%，查询速度提升22%。传统分区在(date, user_id)上需要按date分区再按user_id分桶——但Liquid Clustering自动处理这个层次结构，无需人工设计。
• 误区3：Liquid Clustering不支持元数据操作——实际支持元数据级DELETE、COUNT、DISTINCT和GROUP BY。元数据级DELETE比传统快90%，聚合查询快27倍。这意味着很多操作不需要扫描数据文件，仅凭文件级统计信息即可完成——分区表的传统优势（元数据级操作如DROP PARTITION）在LC中同样可用。
• 误区4：Liquid Clustering在PB规模不可行——数十个客户已在生产环境运行PB级LC表。OPTIMIZE性能大幅改进：规划阶段从12小时降至23分钟，执行阶段在中等DBSQL集群上快5倍。此前LC的主要瓶颈是OPTIMIZE的规划时间过长（12小时意味着运维团队无法接受），23分钟的规划时间让PB级LC表的日常维护成为可能。
• 误区5：LC仅惠及Databricks读者——Liquid Clustering是写端优化，输出标准Parquet文件，文件级统计信息（min/max/null count）对所有兼容引擎可见。Apache Spark、DuckDB、Trino等任何能读取Parquet并利用统计信息跳过文件的引擎都能受益——这与Vol.13报道的DuckDB-Iceberg扩展形成互补（DuckDB从读端利用LC写入的统计信息）。
• 误区6：并发ETL需要分区——Liquid Clustering提供行级并发。两个写入器更新不同行时不会冲突，即使这些行在同一文件中。分区表的并发控制是文件级的——两个写入器更新同一分区的不同行可能冲突。行级并发是Vol.12报道的Databricks Iceberg v3 GA中删除向量+行追踪的实际应用场景之一。
• 误区7：Z-Ordering弥补分区不足——Z-Ordering存在两个问题：聚类质量差（同列值分散在多个文件中）和需要定期重写维持聚类质量。Liquid Clustering增量聚类包括写入时聚类，无需不必要的重写——这在Vol.8报道的Databricks Catalog Commits GA和Vol.11报道的Enzyme增量视图维护引擎的逻辑一致：从”全量重写”走向”增量维护”。
• 误区8：选择性覆盖需要分区——Liquid Clustering原生支持选择性覆盖，通过REPLACE USING和REPLACE ON语法实现，适用于任何数据布局。此前需要按日期分区才能高效覆盖某天数据的场景，LC可以直接按条件覆盖，无需分区对齐。
• 即将推出：Liquid-to-Liquid Join优化——当两个LC表按相同键聚类时，Join无需重新洗牌数据，直接在本地匹配。基准测试显示：Join速度提升51%（28分钟→14分钟），数据洗牌减少87%（1.2 TiB→150 GiB）。这类似于Vol.11报道的ClickHouse ShuffleExchange按JOIN键重分区，但LC在写入时就预组织了数据分布，Join时零洗牌。
• 即将推出：分区表原地转换——新命令支持将分区表原地转换为LC表，最小化停机时间和数据重写。这是LC采纳的最后一道门槛——此前从分区迁移到LC需要创建新表+重写数据+切换流量，原地转换将迁移成本降至近零。

行业影响

Databricks Liquid Clustering博客的深层意义不是”又一篇技术博客”，而是湖仓数据布局从”静态预定义”走向”动态自适应”的宣言。Hive风格分区在2008年被引入Hadoop生态时解决了一个关键问题——如何在大规模数据集上高效剪枝。但分区的核心假设是”查询模式在表创建时就已知且不变”——这在AI代理和实时管道时代已不成立。当AI代理的查询模式是动态的（今天按用户查询、明天按地区查询、后天按产品查询），静态分区方案永远滞后于查询需求。

这与Vol.12报道的AWS OpenSearch Serverless为AI代理从零重建的思路一致——OpenSearch为代理的爆发式流量模式重新设计存储计算架构，Liquid Clustering为代理的动态查询模式重新设计数据布局。两者的共同逻辑是：当访问模式从”可预测”变为”不可预测”时，静态优化必须让位于动态自适应。

Arctic Wolf的7.7倍加速（3.8PB表，51s→6.6s）和Bolt的138%写入吞吐量提升是LC在生产环境的有力验证。但更值得注意的是即将推出的Liquid-to-Liquid Join优化——51%加速和87%洗牌减少指向一个方向：当数据布局从”被动存储”变为”主动优化查询执行”时，数据布局与查询优化器的边界开始模糊。传统架构中数据布局（分区/Z-Order）和查询优化（CBO/Join重排序）是两个独立阶段；LC的写入时聚类让数据布局成为查询优化的前置步骤——写入时按查询模式组织数据，查询时直接利用组织好的数据分布。

相关链接

• Debunking 8 data layout myths: why Liquid Clustering outperforms partitioning
• Liquid Clustering Documentation

---

Snowflake Openflow GA与Anthropic深度合作：数据集成与AI治理的平台化组合

事件概述

6月2日，Snowflake在Summit 26宣布两项重要进展：Snowflake Openflow正式GA（Generally Available），以及与Anthropic的战略合作深化。Openflow是基于开源Apache NiFi的多模态数据集成服务，支持结构化和非结构化数据、批处理和流式摄取统一，现已GA于AWS所有商业区域（BYOC部署模式），即将支持Snowpark Container Services部署。Oracle连接器使用原生XStream API实现近实时CDC，在37,000 TPS压力测试下仅3% CPU开销——Yes Energy将10天初始加载缩短至6小时以内。Anthropic合作深化方面，Claude模型直接驱动Snowflake Cortex Code（AI编码代理）和Snowflake Intelligence（自然语言分析代理），EVP Christian Kleinerman称Cortex Code为”Snowflake历史上增长最快的产品”。Block、Carvana、eSentire、Indeed、Notion等企业在生产环境使用Claude on Cortex AI进行网络安全调查、财务分析和数据应用开发。两家公司还宣布在Claude Marketplace和安全导向开发工作流方面的合作。

技术解析

• Openflow——Apache NiFi的企业级封装：核心基于Apache NiFi数据集成框架，在此基础上增加了企业级治理、安全、部署灵活性和可观测性。Openflow不是从零构建的数据集成产品，而是将数千家企业已信赖的NiFi框架纳入Snowflake平台的治理体系——这与Databricks将Iceberg纳入Unity Catalog治理（Vol.12）的思路一致：不重新发明轮子，而是将开放组件纳入平台治理。
• BYOC部署模式：客户在自有VPC中运行Openflow连接器和管道，数据不经Snowflake控制平面。支持多部署实例（每个实例服务不同用例），部署内运行时可水平扩展，支持多节点多集群部署和灾难恢复。BYOC模式解决了企业数据集成的核心顾虑：数据管道代码在客户VPC中运行，Snowflake只提供控制平面。
• Oracle XStream连接器：与Oracle联合工程，使用原生XStream API直接从redo log读取变更并流式传输到Snowflake。无代理架构——无需在Oracle服务器上安装任何软件。37K TPS压力测试下仅3% CPU开销和redo体积线性增长。灵活许可——自带Oracle许可或使用Snowflake嵌入式OEM选项。Yes Energy将10天初始加载缩短至6小时。这直接对标Vol.11报道的Databricks Lakebase CDF（原生CDC）和传统CDC工具（Debezium/Fivetran/PeerDB）。
• 统一多模态集成：支持结构化数据（JDBC/CSV/Parquet）和非结构化数据（文档/图像/音频）在同一框架内集成，与Cortex AISQL的FILE数据类型形成端到端闭环——Openflow负责将多模态数据从外部源摄入Snowflake表，Cortex AISQL负责在表上执行AI查询。
• Anthropic+Snowflake——治理AI的数据栈：Claude模型运行在Snowflake的数据治理、安全和可观测性环境中，客户无需将敏感数据移出Snowflake即可使用Claude推理。Cortex Code（AI编码代理）让开发者在Snowflake内直接构建和部署AI应用——Block使用Cortex Code构建合规调查和安全分析的AI操作层。Snowflake Intelligence让业务用户通过自然语言查询企业数据，Claude作为底层推理引擎。Christian Kleinerman明确指出：“客户要的是直接在治理数据上工作的AI，不是在隔离系统中的AI。”

行业影响

Openflow GA与Anthropic深度合作的组合意义大于各自单独的价值——数据集成（Openflow）解决”数据如何进入平台”，AI治理（Anthropic on Cortex AI）解决”AI如何安全地使用数据”，两者组合形成”治理AI的完整数据栈”。

Openflow的GA标志着Snowflake正式进入数据集成市场，直接与Fivetran、Airbyte、Confluent等竞争。但Openflow的差异化不在于连接器数量或性能，而在于与Snowflake平台的深度整合——数据摄入后立即可被Cortex AISQL查询、被Cortex Code处理、被Snowflake Intelligence分析，无需额外的目录注册或权限配置。这与Vol.11报道的Databricks Lakebase CDF的”平台内化”思路一致：从”外部管道+手动对接”到”平台原生+自动治理”。

Anthropic合作的深层趋势是AI模型正在从”独立产品”变为”数据平台的内嵌能力”。当Claude作为Snowflake SQL引擎的一等操作符运行（Cortex AISQL的AI_COMPLETE/AI_FILTER底层调用Claude），当Claude作为开发者工具的原生推理引擎运行（Cortex Code），当Claude作为分析代理的大脑运行（Snowflake Intelligence），AI模型不再是需要单独采购、部署和治理的外部组件，而是数据平台的原生能力。Cortex Code成为”Snowflake历史上增长最快的产品”这一事实量化了这一趋势——企业不是要”买一个AI模型”，而是要”在已有数据平台上用AI”。

相关链接

• Snowflake Openflow Revolutionizes Data Movement for AI and Interoperability
• Snowflake and Anthropic Accelerate Enterprise AI Adoption (Business Wire)
• Stream Oracle Data to Snowflake in Minutes with Openflow

---

编者评

第十四期的三条动态，与前十三期的主线形成了又一个维度的跃迁。Vol.1-2确立了”AI原生基础设施”和”基础设施AI代理化”两条主线，Vol.3-9追踪到AI代理趋势从应用层渗透到存储/芯片/可观测性层，Vol.10-11看到数据基础设施从”为人设计”走向”为代理设计”，Vol.12看到竞争维度从”格式层”上移到”目录层”、设计假设从”为人设计”翻转为”为代理设计”，Vol.13看到DataInfra从”手工编排”走向”引擎自动”。本期则看到了三个更根本的范式变更同时发生。

第一个范式变更是查询语言的语义扩展：SQL从”结构化查询语言”走向”AI查询语言”。 Cortex AISQL将AI操作符作为SQL一等原语嵌入查询引擎——这不是在SQL外面套AI壳，而是扩展SQL的语义域。此前的SQL操作假设数据是结构化的、操作是确定性的、结果是可重复的。AI_FILTER/AI_JOIN/AI_AGG打破了这三个假设：操作对象从结构化扩展到多模态（FILE类型），操作方式从确定性计算扩展到AI推理，结果从确定性输出扩展到概率性输出。但关键洞察是：这种扩展不是替换SQL，而是在SQL框架内扩展——数据分析师继续写SELECT/FROM/WHERE，只是WHERE子句中可以调用AI_FILTER。这与Vol.7报道的Spark 4.1 SQL Scripting的”SQL内表达复杂逻辑”一脉相承，但走得更远——Spark让SQL表达确定性业务逻辑，Cortex AISQL让SQL表达概率性AI推理。

第二个范式变更是数据布局的动态化：从”静态预定义”走向”动态自适应”。 Liquid Clustering全面超越分区的8大误区，核心论点是：当查询模式不可预测时（AI代理时代），静态分区方案永远滞后于查询需求。LC的动态聚类键变更、写入时聚类和行级并发让数据布局从”建表时决定”变为”运行时自适应”。这与Vol.12报道的AWS OpenSearch Serverless 97%代码重写的逻辑一致——当访问模式从”可预测”变为”不可预测”时，静态优化必须让位于动态自适应。LC即将推出的Liquid-to-Liquid Join优化更进一步——数据布局不再是”被动存储”，而是”主动参与查询优化”的组成部分。

第三个范式变更是AI治理的平台化：从”模型外挂”走向”平台原生”。 Snowflake+Anthropic的合作将Claude从独立产品变为Snowflake平台的内嵌能力。当AI模型作为SQL操作符运行（Cortex AISQL）、作为开发工具的推理引擎运行（Cortex Code）、作为分析代理的大脑运行（Snowflake Intelligence）时，AI治理不再是”在模型上加一层安全壳”，而是”数据平台本身就是AI治理环境”。Cortex Code成为Snowflake历史上增长最快产品这一事实，量化了企业对”治理AI”的需求——不是要更强大的模型，而是要在已有数据平台上安全地使用AI。

将十四期主线串联，一个完整的演进图景浮现：DataInfra正在经历三线并行的范式变更。 第一线是查询语言的语义扩展——从结构化查询（Vol.1-7）到AI增强查询（Vol.11 ClickHouse Agents）到AI原生查询（Vol.14 Cortex AISQL），SQL的操作域从”确定性关系代数”扩展到”概率性AI推理”。第二线是数据布局的动态化——从静态分区（Vol.1-7的隐含假设）到增量聚类（Vol.7-8的LC提及）到全面超越分区（Vol.14的8大误区），数据组织从”建表时决定”变为”运行时自适应”。第三线是AI治理的平台化——从模型外挂（Vol.1-3）到代理治理（Vol.10-12）到平台内嵌（Vol.14 Anthropic on Cortex AI），AI从”需要单独管理的组件”变为”数据平台的原生能力”。当SQL能原生调用AI（Cortex AISQL）、数据布局能动态适配查询（Liquid Clustering）、AI治理能平台级保障（Anthropic on Snowflake）时，DataInfra的下一个竞争维度不再是”谁的功能更多”或”谁更快”，而是”谁能让AI和数据零距离”——消除AI栈与数据栈之间的每一条裂缝，让AI推理直接运行在数据所在的地方，让数据治理直接覆盖AI运行的地方。