Databricks External Lineage GA让Unity Catalog血缘跨越平台边界；Cloudera采纳Apache Polaris为Iceberg湖仓注入企业级安全；Apache Cassandra 6.0 Alpha以Accord协议为NoSQL带来ACID事务

第二十期追踪到DataInfra领域三条重要动态：6月8日Databricks宣布Unity Catalog External Lineage正式GA——原名Bring Your Own Lineage从Public Preview走向生产就绪，支持注册Databricks外部资产（Salesforce/MySQL数据源、Tableau/Power BI仪表板）使单一血缘图跨越完整数据流，Lakeflow Connect托管摄取管道自动记录源表到目标表血缘无需手动配置，列级血缘映射与API/SDK支持——此前Unity Catalog的运行时血缘自动捕获仅覆盖Databricks内的工作负载，外部系统的数据来源和消费去向是血缘图的盲区，External Lineage GA将血缘可见性从”Databricks内”扩展到”企业数据生态全貌”；同期Cloudera宣布采纳Apache Polaris作为Iceberg湖仓的开放目录标准并贡献Apache Ranger授权插件——Polaris 1.5新增Ranger外部授权器（Beta）将企业级集中安全策略管理带入Iceberg REST Catalog生态，这是Polaris首次获得企业级安全能力的原生支持，Cloudera Data Readiness Index 2026显示79%组织面临数据获取挑战仅18%数据完全治理——Polaris此前缺乏企业级授权能力是大型组织采纳的主要障碍，Ranger插件填补了这一空白；The New Stack 6月8日报道Apache Cassandra 6.0 Alpha——Accord协议实现无领导者共识的ACID事务（严格可序列化隔离/单轮次共识/跨多分区原子性）将多分区协调从应用代码迁入数据库内核，事务性集群元数据TCM以Paxos支撑的有序日志替代Gossip协议使模式迁移和拓扑变更可预测，自动化修复将修复调度从外部工具迁入数据库内置服务，约束框架在模式级执行列级验证，Zstd字典压缩和游标压缩优化存储和运行时效率——三条动态共同指向数据基础设施的”收回外包责任”趋势：Databricks收回外部系统的血缘可见性，Cloudera收回目录安全的自主权，Cassandra收回长期委托给外部的运维工作。

Databricks External Lineage GA：Unity Catalog血缘跨越平台边界

事件概述

6月8日，Databricks宣布Unity Catalog中的External Lineage（原名Bring Your Own Lineage）正式GA。此前该功能处于Public Preview阶段。External Lineage允许注册存在于Databricks外部的资产——如Salesforce和MySQL数据源、Tableau和Power BI仪表板——使单一血缘图跨越企业的完整数据流。作为此次GA的一部分，Lakeflow Connect托管摄取管道现在自动记录从源表到Unity Catalog目标表的血缘关系，无需手动配置。

Unity Catalog此前已能自动捕获Databricks内工作负载的运行时血缘（包括Spark SQL、Notebook、Job、Dashboard之间的表级和列级血缘），但外部系统的数据来源和消费去向是血缘图的盲区——数据从Salesforce经Fivetran/Lakeflow Connect进入Databricks的过程，以及Databricks数据被Tableau/Power BI消费的过程，此前需要手动记录或完全不可见。External Lineage GA将血缘可见性从”Databricks内”扩展到”企业数据生态全貌”。

技术解析

• 外部元数据对象（External Metadata Object）：在Unity Catalog中创建代表外部系统实体的对象，必填字段包括名称、系统类型（从预定义列表选择或自定义）和实体类型（table/dashboard/report等），可选字段包括URL（点击跳转到外部系统）、描述、列定义和属性（JSON键值对）。每个metastore最多支持10,000个外部元数据对象和100,000个外部血缘关系。
• 血缘关系配置：在外部元数据对象和Unity Catalog对象之间建立上游（数据来源）或下游（数据消费）关系。支持列级映射——创建外部元数据对象时指定列名称，配置血缘关系时映射源列和目标列。还支持多级血缘（数据通过多个外部系统流转时创建多个外部元数据对象串联）和跨Unity Catalog表的间接血缘（在两个UC表之间插入外部元数据对象作为中介）。
• Lakeflow Connect自动血缘：Lakeflow Connect托管摄取管道在数据摄取过程中自动捕获源表到目标表的血缘，无需用户手动配置。此前Vol.14报道Openflow GA和Vol.16报道Parquet Direct时关注的是数据如何流动，External Lineage关注的是数据流动如何被追踪——数据集成和数据血缘是同一管道的两个面。
• API和SDK支持：通过REST API（External Metadata API和External Lineage API）和Databricks Python SDK程序化创建和管理外部血缘，支持CI/CD集成和自动化血缘注册。可通过Catalog Explorer UI手动操作，也可通过API批量操作。
• 与Vol.15-16的治理主线衔接：Vol.15报道Snowflake Horizon Context定义AI理解数据的语义层（Collect→Enrich→Activate），Vol.16报道Databricks Cross-Engine ABAC在目录层强制执行跨引擎治理策略。本期External Lineage GA是同一治理主线的血缘层——Horizon Context解决”数据意味着什么”，Cross-Engine ABAC解决”谁能访问数据”，External Lineage解决”数据从哪里来到哪里去”。

行业影响

Databricks External Lineage GA的深层意义不是”又一个Unity Catalog功能上线”，而是数据血缘从”平台内可见”走向”生态全可见”的治理范式演进。

此前企业数据血缘面临”平台内清晰、平台外黑暗”的困境——Unity Catalog内的表级和列级血缘自动捕获、实时可见，但数据进入Databricks之前和离开Databricks之后的流向是盲区。这导致两个实际问题：数据事件溯源时无法追踪到Databricks外的根因（“这个表的原始数据来自Salesforce哪个字段？”），合规审计时无法展示完整的数据流（“个人数据从CRM到BI报表经过了哪些系统？”）。External Lineage GA填补了这两个盲区。

与Snowflake的Horizon Context（从数据目录走向AI理解层）和Interoperable Lakehouse（Parquet Direct/Scan Plan API）相比，Databricks选择从”血缘可见性”切入跨平台治理——Horizon Context解决”数据是什么”，Interoperable Lakehouse解决”数据如何互操作”，External Lineage解决”数据流经哪里”。三者互补而非竞争：当数据的语义、互操作性和流向都被统一治理时，企业数据从”碎片化管理”走向”全链路治理”。

Lakeflow Connect自动血缘的加入尤其值得关注——此前”Bring Your Own Lineage”意味着”手动带入外部血缘”，自动血缘让数据摄取管道自带血缘追踪能力，降低了治理的运维负担。当摄取即血缘（ingestion is lineage）时，数据血缘的完整性从依赖人为操作变为管道的内置特性。

相关链接

• External Lineage Documentation
• Track Source Data Lineage for Managed Ingestion Pipelines
• June 2026 Product Updates

---

Cloudera采纳Apache Polaris：Iceberg湖仓开放目录标准获得企业级安全加持

事件概述

6月4日，Cloudera在Snowflake Summit 2026上宣布采纳Apache Polaris作为其Iceberg开放数据湖仓架构的目录标准，并贡献Apache Ranger授权插件作为Polaris 1.5的外部授权器（Beta）。Apache Polaris是基于Apache Iceberg REST Catalog规范构建的开源目录，旨在提升现代数据生态系统的互操作性。Cloudera的采纳意味着其客户可通过Polaris实现与Snowflake、Databricks、AWS Athena、AWS EMR、Salesforce等引擎的零拷贝互操作——无需复制或移动数据即可跨引擎查询，同时通过Cloudera SDX（Shared Data Experience）保持统一的精细化访问控制、数据血缘追溯和审计功能。

Cloudera同期发布Data Readiness Index 2026调查结果：79%的组织表示其数据驱动计划因无法跨环境访问全部所需数据而受阻，仅18%的组织报告数据已完全治理。这一数据凸显了开放互操作性和治理覆盖面的双重挑战——仅有互操作性而无治理等于数据失控，仅有治理而无互操作性等于数据孤岛。

技术解析

• Apache Polaris与Iceberg REST Catalog规范：Polaris是Snowflake于2024年捐赠给Apache基金会的开源项目，基于Iceberg REST Catalog规范构建。REST Catalog规范定义了目录服务的标准API——任何引擎可通过同一套HTTP API注册表、发现表、获取文件列表和凭证，无需理解特定目录的实现细节。Polaris是这个规范的参考实现之一，与Snowflake自有的Polarn Catalog和Databricks的Unity Catalog OSS是同一规范的平行实现。Vol.14-16报道Snowflake和Databricks围绕Iceberg REST Catalog展开治理竞争，Cloudera选择Polaris意味着第三个主要玩家加入这个开放标准生态。
• Apache Ranger外部授权器：这是Cloudera对Polaris 1.5的核心贡献。Apache Ranger是Hadoop生态久经考验的企业级安全框架，提供集中化的细粒度访问控制策略管理（行级/列级/表级/库级）、审计日志和安全报告。Ranger外部授权器将Polaris的授权决策委托给Ranger策略引擎——当查询引擎通过Polaris访问数据时，Polaris先咨询Ranger获取该用户的访问权限，然后返回经授权过滤后的数据文件列表和受限凭证。此前Polaris缺乏企业级授权能力是大型组织采纳的主要障碍——Polaris的开源版本仅提供基础的目录服务（注册发现/凭证分发），缺乏行级/列级访问控制、动态数据掩码和集中化策略管理。Ranger插件填补了这一空白。
• Cloudera SDX与Polaris的整合：Cloudera的Shared Data Experience（SDX）将安全性、治理和元数据智能统一到跨云、跨数据中心的控制面。Polaris作为目录层提供引擎互操作性和表发现，SDX作为治理层提供精细化访问控制、数据血缘和审计——两层叠加让Cloudera客户在使用第三方引擎访问数据时仍保持企业级治理。
• 与Vol.16的Cross-Engine ABAC对比：Vol.16报道Databricks通过Unity Catalog的Scan API在Spark/DuckDB/Starburst上强制执行行过滤器和列掩码，Snowflake同期发布Scan Plan API实现跨引擎行级访问控制。两者都将授权执行放在目录层而非引擎运行时。Cloudera的Ranger外部授权器是同一思路的不同实现——Ranger作为外部授权器插入Polaris的授权决策流程，而非依赖每个引擎内置的授权逻辑。三种路径（Unity Catalog ABAC/Snowflake Scan Plan/Ranger External Authorizer）都指向同一个趋势：授权执行从引擎运行时迁移到目录服务层。

行业影响

Cloudera采纳Apache Polaris的深层意义不是”又一个数据平台支持Iceberg”，而是开放目录标准的治理能力从”基础服务”走向”企业级安全”的关键一步。

Apache Polaris自捐赠以来面临的核心挑战是：开源目录提供了表发现和凭证分发的标准接口，但缺乏企业级安全能力。对大型组织而言，“能发现表”远不够——“谁能看到哪些表的哪些列”和”谁在什么时候访问了什么数据”才是采纳的硬性要求。Databricks的Unity Catalog和Snowflake的Polaris Catalog都有各自生态内的安全方案（Unity Catalog ABAC/Snowflake RBAC+ABAC），但Polaris的开源版本一直缺乏与这些商业方案对等的安全能力。Ranger外部授权器的加入让Polaris首次获得了与商业目录对等的企业级安全——这不是一个简单的插件，而是一个架构层面的设计：Polaris定义授权接口（External Authorizer SPI），Ranger实现授权逻辑，任何符合SPI的授权框架都可以插入Polaris。

Data Readiness Index 2026的数据（79%数据获取受阻、仅18%数据完全治理）揭示了一个行业痛点：开放互操作性和企业级治理长期以来是两个平行发展的方向——开放标准（Iceberg/Polaris）解决了互操作性但缺乏安全深度，企业安全（Ranger/SDX）解决了治理但缺乏生态广度。Cloudera将两者整合意味着：开放标准+企业安全插件的组合可以同时满足互操作性和治理需求——“开放”不再意味着”不安全”，“安全”不再意味着”封闭”。

相关链接

• Cloudera Adopts Apache Polaris to Advance Open, Governed Data Access for Enterprise AI Anywhere
• Apache Polaris
• Apache Ranger

---

Apache Cassandra 6.0 Alpha：Accord协议为NoSQL带来ACID事务的范式转变

事件概述

6月8日，The New Stack发表Apache Cassandra 6.0 Alpha特性综述——这是Cassandra历史上架构变更最深远的版本。核心变化涵盖四个层面：Accord协议实现无领导者共识的ACID事务（严格可序列化隔离/单轮次共识/跨多分区原子性），事务性集群元数据TCM以Paxos支撑的有序日志替代Gossip协议（使模式迁移和拓扑变更可预测），自动化修复将修复调度从外部运维工具迁入数据库内置服务，约束框架在模式级执行列级验证。同时引入Zstd字典压缩和基于游标的压缩改进。Cassandra 6.0的核心主题是”数据库收回长期委托给外部的运维工作”——多分区协调从应用代码迁入数据库（Accord），元数据传播从不可预测的Gossip迁入有序日志（TCM），修复从外部工具迁入内置服务（Automated Repair）。

技术解析

• Accord协议——无领导者共识的ACID事务：Accord是通用事务框架，采用无领导者共识协议实现高可用事务，提供严格可序列化隔离（Strict Serializable Isolation）。与Raft/Zab等需要领导者的共识协议不同，Accord的任何节点都可以协调任何事务——事务被分配唯一时间戳（混合逻辑时钟），冲突事务按时间戳顺序在所有副本上执行。正常条件下事务在单轮次内达成共识。这对Cassandra的架构至关重要——Cassandra以对等节点设计著称（无主节点），如果事务协议引入领导者就违背了核心设计原则。Accord让Cassandra在不牺牲对等架构和可用性的前提下获得ACID保证——此前跨多分区的一致性操作只能在应用代码中实现（如分布式Saga/两阶段提交），Accord将其迁入数据库内核。
• 事务性集群元数据TCM——替代Gossip：TCM引入Cluster Metadata Service维护元数据变更的有序日志，替代Gossip协议作为集群元数据传播的主要机制。Gossip协议基于最终一致性——节点间互相传播状态，但不保证顺序和即时一致性——导致模式迁移和拓扑变更的不可预测行为（如新节点加入时schema不一致、节点下线时拓扑状态模糊）。TCM以Paxos支撑的有序日志使变更更加显式、有序和可追溯——操作员可以清晰看到”什么在什么时候变了”。Gossip不会立即消失但不再是元数据协调的主要方式。
• 自动化修复编排——将修复从外部工具迁入数据库：修复（Repair）是Cassandra协调副本一致性的核心机制——副本间数据随时间产生差异（如节点短暂下线时的写入丢失），修复确保副本最终一致。此前修复是运维团队的主要负担——需要使用外部工具（如nodetool repair）编排修复计划、决定修复范围和频率、监控修复进度。Cassandra 6.0将修复编排集成到数据库内部，支持完整修复和增量修复，添加调度控制和保护措施。这对没有专业Cassandra团队的中小组织尤为关键——修复从”需要专业技能的运维任务”变为”数据库自动执行的维护服务”。
• 约束框架——模式级列验证：在表模式中定义列级验证规则（范围检查/非空约束/正则表达式/JSON验证），在写入时执行而非依赖应用代码。例如age int CHECK age >= 0 AND age < 120。验证逻辑从”每个服务各自实现”迁入”模式定义一次执行”，减少跨服务重复逻辑。
• Zstd字典压缩与游标压缩：Zstd字典压缩使用从代表性数据训练的字典处理SSTable中的重复数据模式，提升压缩比（需要管理字典生命周期）。基于游标的压缩以流式方式处理SSTable数据，使用可重用游标式读写器替代大量临时内存对象，减少堆分配和GC压力——在持续负载下提供更稳定的节点行为。

行业影响

Apache Cassandra 6.0的深层意义不是”又一个数据库版本更新”，而是NoSQL数据库从”放弃ACID换取扩展性”走向”在保持扩展性的同时提供ACID”的范式修正。

Cassandra的设计哲学始终是”可用性和分区容错性优先于一致性”（AP系统）——线性水平扩展、多区域复制、容错可用性是核心优势，但ACID事务是经典取舍。Accord协议改变了这个等式：在不牺牲对等架构、高可用性和水平扩展能力的前提下提供ACID事务——严格可序列化隔离、跨多分区原子性、单轮次共识。这意味着Cassandra从”AP系统”走向”AP+CP可选”——不需要ACID的场景保持原有轻量级路径，需要ACID的场景（如金融交易、库存管理、订单处理）可以在事务表上获得强一致性保证。

TCM替代Gossip是另一个范式转变——Gossip是Cassandra从诞生之初就使用的元数据传播机制，其最终一致性模型在集群规模较小时可接受，但在大规模集群中模式迁移和拓扑变更的不可预测性成为运维噩梦。TCM以有序日志替代Gossip的”尽力传播”，让集群操作从”最终会一致”变为”按顺序一致”——这不仅是技术改进，更是运维范式的根本转变：从”等待Gossip收敛”到”追踪有序日志”。

自动化修复和约束框架的引入则呼应了一个更广泛的行业趋势——数据库正在收回长期委托给外部的运维工作。此前Cassandra的运维模式是”数据库负责存储和查询，外部工具和人工流程负责修复/验证/协调”，6.0将修复和验证迁入数据库内部——与Vol.8报道的Databricks Predictive Optimization（AI驱动优化从手动走向自动）和Vol.18报道的Dragonwell Native Acceleration（AI发现JDK级性能优化）方向一致：数据库/数据基础设施的自治能力边界正在扩大。

相关链接

• What’s new in Cassandra 6? A roundup of features for users and operators
• Apache Cassandra 6 Accord transactions: What you need to know
• Apache Cassandra GitHub

---

编者评

第二十期的三条动态，从三个不同层面共同指向数据基础设施”收回外包责任”的趋势——将此前委托给外部系统、外部工具或应用代码的职责迁回基础设施内核。

第一个层面是治理可见性的收回：Databricks External Lineage GA将血缘可见性从平台内扩展到企业数据生态全貌。 此前Unity Catalog的运行时血缘自动捕获仅覆盖Databricks内的工作负载——数据从外部系统（Salesforce/MySQL）进入Databricks之前和离开Databricks之后（Tableau/Power BI）的流向是血缘图的盲区。External Lineage GA让Unity Catalog成为跨平台血缘的”唯一真相来源”——不是替代外部系统的血缘能力（Salesforce有自己的血缘，Tableau有自己的血缘），而是提供一个统一的血缘视图将所有系统的数据流串联起来。与Vol.15的Horizon Context（语义层统一）和Vol.16的Cross-Engine ABAC（授权层统一）叠加，Unity Catalog正在从”Databricks的治理工具”走向”企业数据治理的统一控制面”——语义、授权、血缘三层统一。

第二个层面是安全自主权的收回：Cloudera通过Ranger外部授权器将企业级安全注入开放目录标准。 此前Apache Polaris作为开源Iceberg REST Catalog的实现提供了表发现和凭证分发的标准接口，但缺乏行级/列级访问控制和集中化策略管理——对大型组织而言”能发现表但不知道谁能看哪些列”是不可接受的。Ranger外部授权器的设计精巧之处在于它不是将Ranger硬编码到Polaris中，而是定义了External Authorizer SPI让任何授权框架都可以插入——这意味着未来其他安全框架（如OPA、HashiCorp Sentinel）也可以通过同一SPI为Polaris提供授权能力。当开放目录标准获得了与企业商业方案对等的安全能力时，开放标准的采纳障碍从”安全不够”变为”迁移成本”——后者是工程问题而非架构限制。

第三个层面是运维职责的收回：Cassandra 6.0将多分区协调、元数据传播和数据修复从外部迁入数据库内核。 此前Cassandra的运维模式是”数据库负责存储查询，外部工具负责修复/协调/传播”——开发者用应用代码实现跨分区一致性（Saga/2PC），运维用外部工具编排修复（nodetool repair），集群元数据通过Gossip协议尽力传播。Accord/TCM/Automated Repair三者组合将这三项职责全部迁回数据库内部——“数据库外包的运维工作”被逐一收回。这与Databricks的Predictive Optimization（AI自动优化存储）和Dragonwell的Native Acceleration（AI自动发现性能优化）方向一致：数据基础设施的自治能力边界正在从”存储和查询”扩展到”治理、安全和运维”。

将二十期主线串联，DataInfra正在经历三个层次的”收回”： 治理层从平台特定走向跨平台统一（External Lineage/Horizon Context/Agents Schema），安全层从封闭生态走向开放标准+企业插件（Ranger Authorizer/Scan Plan API/Cross-Engine ABAC），运维层从外部工具走向内置自治（Accord/TCM/Automated Repair/Predictive Optimization）。三个层次的”收回”不是回退到”大一统单系统”，而是在开放标准和插件化架构上重建统一性——目录标准开放（Iceberg REST Catalog/Polaris），安全能力可插拔（Ranger SPI/Scan Plan API），治理接口统一（External Lineage API/Agents Schema）。当开放标准获得了与封闭系统对等的治理和安全能力时，“开放”不再是”简陋”的同义词，而成为”灵活+安全”的新基准。