本章内容包括：
- 评估 data federation requirements
- 设计 federation layer components
- 比较 Dremio 和 Trino 的 federated querying 能力
- Self-managed 和 cloud-managed federation options
- 基于 use cases 选择 federation platform
随着你的 Apache Iceberg lakehouse 逐渐成形，必须认识到，并不是所有数据都会位于 Iceberg tables 中。即使你尽最大努力进行集中化和标准化，一些 datasets 仍会分散在第三方系统、legacy databases 和 SaaS applications 中；或者它们根本不值得投入精力去 extract、transform 并 load 到 lakehouse 中。这些现实使得在架构中扩展 federation layer 变得非常必要。
Federation layer 同时充当桥梁和协调器。它让你的 analytics platform 能够访问多个系统中的数据，而无需物理整合这些数据。同时，它还可以引入 semantic layer，用于标准化业务逻辑，确保 metrics 和 datasets 无论来自哪里，都能保持一致。无论 analysts 是通过 notebooks、BI dashboards，还是 custom applications 查询数据，federation layer 都会为底层数据生态提供一个统一、受治理的 interface。
我们将探索组成 federation layer 的组件、有效构建 federation layer 的关键需求，以及支持它的主流平台。我们会比较 Dremio 和 Trino，这两个在该领域最突出的工具；讨论它们的 deployment options；并通过一些场景说明如何为你的需求选择合适平台。到本章结束时，你将理解如何集成一个 federation layer，使其补充你的 Iceberg lakehouse，并赋能组织使用位于任何地方的数据。
8.1 什么是 Data Federation，以及为什么它重要
在完美世界中，组织的所有数据都会位于 Iceberg tables 中，集中化、优化，并统一治理。但现实中，现代数据版图更加碎片化。许多有价值的 datasets 位于 lakehouse 之外的系统中，这些系统可能成本太高、风险太大或过于复杂，不适合摄入。这些系统可能包括 SaaS platforms、legacy databases、real-time services，或外部管理的 storage。然而，业务用户仍然需要访问并分析这些信息，以生成有意义的洞察。
在大多数架构中，Iceberg lakehouse 充当 central hub，大多数查询，通常超过 90%，都会在这里执行。这个核心为受治理的 analytics 提供统一、高性能的基础。Federation 通过将 lakehouse 连接到 external systems 来扩展这个基础，使用户能够用来自 remote sources 的 just-in-time data 丰富 lakehouse queries，见图 8.1。这些 federated sources 可能只占较小比例的 queries，但它们能够在不复制或搬迁数据的情况下填补关键缺口。
图 8.1：当你拥有 third-party data 时，federation layer 可以帮助你使用这些 datasets，而不必将它们复制到 lakehouse 中。这让它们可以通过把数据发送到你喜欢的 AI 或 BI tool 来丰富 lakehouse。在这个例子中，一部分数据被摄入 Iceberg lakehouse，而其他 sources 则由 federation layer 直接查询，从而为 AI 和 BI use cases 提供所需的全部数据。
这种 hub-and-spoke approach 让 lakehouse 保持在数据架构中心，同时让边缘具备敏捷性。Federation 允许 analytics platform 像查询同一环境中的数据一样，查询 external systems。通过将 Iceberg tables 与 remote data join，通过 semantic layer 应用一致业务逻辑，并通过熟悉工具启用访问，federation 在不牺牲治理或性能的情况下确保连续性。
本节会探索在 Apache Iceberg lakehouse 语境下 federation 的含义、为什么它变得越来越重要，以及它如何支持 agility、accessibility 和 data unification 等目标。当你理解 data federation 的目的后，就能更好地设计一个同时满足技术现实和用户预期的 lakehouse。
8.1.1 推动 Federation 需求的常见 Use Cases 和挑战
Data federation 的需求通常来自数据生态碎片化的现实。随着组织扩展，它们会积累许多系统，每个系统都有自己的 storage model、performance profile 和 operational constraints。尽管组织努力将数据集中到 lakehouse 中，某些 use cases 仍然会因为 cost、complexity 或 governance concerns 而继续受益于 federation：
Combining operational and analytical data——许多 analytics workflows 需要将 Iceberg 中的 historical data 与 transactional databases 中的 live operational data join。例如，fraud detection team 可能需要将存储在 Iceberg 中的 user behavior logs 与 OLTP system 中的 real-time payment activity 混合使用。Federation 允许安全、实时访问 operational data，而不必将其复制到 Iceberg 中。
Integrating third-party data and SaaS platforms——来自 marketing automation、CRM、finance 和其他 SaaS platforms 的数据通常位于 vendor-controlled environments 中。虽然 ETL 可以将部分数据复制到 lakehouse 中，但并非所有数据都需要持久存储。Federation 允许用户直接查询这些 external data，使其无需完整 pipeline 投入即可用于分析。
Supporting exploratory analysis and prototyping——Analysts 和 data scientists 经常需要快速探索新 datasets，然后才值得构建正式 ETL pipeline。Federation 支持 ad hoc access to source systems。如果数据被证明有价值，之后可以建模进 Iceberg；如果没有价值，实验成本也很低。
Enabling hybrid and multicloud strategies——同时拥有 on-premises systems 和 cloud platforms 的组织，通常会面对 full data consolidation 的物流和合规障碍。Federation 允许这些系统留在原地，同时仍然参与 enterprise analytics。它还支持 gradual migrations，也就是数据随时间逐步迁移到 Iceberg。
Minimizing duplication and storage costs——并非所有数据都值得长期存储在 lakehouse 中。有些数据是短暂的、高容量的，或者访问频率太低，不值得复制。Federation 让这些数据可查询，而无需存两份，从而帮助降低成本和复杂性。
不过，federation 也会引入挑战。当访问响应时间不同或数据量很大的系统时，query performance 可能下降。当与不是为 centralized oversight 设计的平台交互时，governance 会变得更困难。Schema、data freshness 或 access interfaces 的不一致，会给最终用户带来摩擦。Federated queries 还可能对 source systems 造成意外负载，导致这些 sources 所服务的应用性能下降，甚至出现 outages。
尽管存在这些挑战，federation 已成为现代数据架构中的战略必要能力。它让组织能够统一访问、加速实验，并支持更广泛的 use cases，而不必过度扩展 ETL pipelines 或牺牲 governance。
8.1.2 Federation 如何与 Agility 和 Accessibility 对齐
Lakehouse architecture 的一个核心目标，是让 data engineers、analysts、scientists 和 business stakeholders 等广泛用户都能快速、可靠地访问数据。Federation 通过移除访问障碍、缩短对新数据采取行动所需时间，在实现这一愿景中发挥关键作用。
通过减少 Data Movement 获得 Agility
传统 ETL workflows 需要仔细规划、配置 infrastructure 和编写 transformation logic，这些都会在数据生成和数据可用之间引入延迟。Federation 通过支持直接访问 source systems，消除了许多这种滞后。新的 data sources 可以立即被查询，iterative discovery 也可以在不等待 ingestion pipelines 构建完成的情况下开始。这对快速变化的环境尤其有用，因为这些环境中数据的相关性具有时间敏感性。
面向不同用户角色的 On-Demand Access
Federation 将 self-service capabilities 扩展给更广泛受众。Data analysts 可以将 BI tools 连接到 federated views，并构建 dashboards，而不必依赖 engineering teams。Data scientists 可以使用来自多个系统的 live datasets prototype models。Product teams 可以通过直接查询 external sources 验证假设。这种 accessibility 缩短了 feedback loops，并在组织内培养 data-driven culture。
通过 Semantic Layer 实现标准化
Federation 让数据更容易访问，但也会增加 interpretation 不一致的风险。这正是 semantic layer 变得必要的地方。Semantic layer 是位于 federated data sources 之上的 shared business context，定义数据的含义，而不只是定义数据如何存储。它会以可在 tools、users 和 queries 之间一致复用的形式，捕捉 metrics、dimensions、relationships 和 governance rules 等 business logic。
实践中，semantic layer 可以通过多种方式组合实现：用 SQL views 编码 standardized metrics；用 wiki 或 Markdown documentation 等 descriptive metadata 描述业务含义；用 YAML-based definitions 定义 measures 和 dimensions；加入 lineage information；以及使用 tagging 或 classification systems。所有这些元素共同将 raw tables 转换为 business-ready datasets。例如，“net revenue” 或 “active customer” 的单一定义，可以只表达一次，并被 dashboards、notebooks 和 AI agents 复用，而不必在每个工具中重新实现逻辑。
通过集中定义这种 business context，组织可以减少冲突解释，提升对 analytics 的信任，并让 federated data 更容易被正确发现和使用。这在 humans 和 AI agents 都查询数据的环境中尤其重要，因为 semantic layer 提供上下文，使它们能够识别正确 datasets 并准确应用，即使底层数据来自多个系统。
通过与 agility 和 accessibility 原则对齐，federation 使 lakehouse 不只是一个 storage system。它会成为一个灵活、用户友好的平台，用于 discovery、innovation 和 enterprise-wide collaboration。
8.2 Federation 的关键 Requirements
构建成功的 federation layer，始于清楚理解组织的目标、约束和数据版图。第 4 章中，我们介绍了 platform audit，它是架构 Iceberg lakehouse 的基础步骤。Audit 会揭示广泛的技术和组织需求，包括碎片化数据系统、不一致 metrics，以及业务用户对更快访问和更大自主性的需求。
这些发现会直接影响 federation layer 的设计。Federation 不是通用解决方案；它必须根据 audit 中识别出的具体需求进行定制。无论用户正在遭遇 duplicative pipelines、inconsistent definitions，还是对 external systems 缺乏可见性，federation layer 都必须解决这些问题，同时强化 lakehouse 更广泛的架构目标。
这个分析中始终会出现三项核心需求：
- 支持连接那些不适合摄入 lakehouse 的 external data sources，例如 value 短暂或 ETL feasibility 有限的 sources
- 提供 semantic layer，在 teams 和 tools 之间提供共享 definitions、governance 和 reusability
- 提供灵活、tool-friendly interfaces，确保用户可以在其工作位置访问数据，而不受 bottlenecks 或 specialized skills 限制
下面我们深入探索每项需求。它们共同提供一个 framework，用于评估 federation platforms、指导 implementation choices，并确保 lakehouse 同时具备 reach 和 reliability。
8.2.1 支持多样 Data Sources 且不复制数据
任何 federation layer 的基础需求，都是能够连接并查询多个系统中的数据。在 platform audit 过程中，你很可能遇到多种 data sources，包括 cloud-based storage、relational databases 和 on-premises systems。Federation 帮助容纳这种多样性，而不要求统一 storage format 或 centralized ingestion，如图 8.2 所示。
图 8.2：Federation layer 应能直接连接到你的 data ecosystem，包括 databases、data warehouses、data lakes 和 data lakehouse catalogs，并作为 AI 和 BI 的主要访问点。该图展示了数据从 sources 流入 federation layer，再进入 AI 和 BI use cases 的过程。
这项需求反映了一条关键架构原则：并非所有数据都需要被移动。在某些情况下，尤其是数据的分析价值很短暂时，将其复制进 lakehouse 会引入不必要的成本、延迟和运维开销。Federation 通过允许 queries 在原地执行，只在分析时获取所需数据，来解决这个问题。这会最小化 storage duplication，同时确保 source systems 仍然是 authoritative source of truth。
为了支持这一点，federation engine 必须做到以下几点：
- 为常见 data platforms 提供广泛 native connectors 或 adapters
- 支持 secure access mechanisms，包括 credential delegation 和 role-based access control（RBAC）
- 启用 pushdown capabilities，使 filters、projections 和 aggregations 尽可能靠近 source 执行
- 管理不同 systems 之间差异化的 latency 和 concurrency demands，以确保在 high query loads 下仍有一致性能和顺滑 user experience
这种方法不仅扩展了 lakehouse 的覆盖范围，也改善了 data freshness。用户可以与最新信息交互，而不必等待 nightly ETL jobs 或 manual exports。并且，由于数据保留在原始位置，与 source systems 绑定的 compliance 和 auditability requirements 更容易保留。
通过支持多样 sources 且不复制数据，federation layer 满足了 stakeholder interviews 中经常出现的需求：“我们需要在数据已经存在的地方使用它。”满足这项需求，有助于让你的 lakehouse 从 centralized system 演进为真正的 federated analytics platform。
8.2.2 确保一致 Semantics 和 Business Logic
Platform audit 中最常见的痛点之一，是不同 teams 对数据的定义、解释和共享方式不一致。不同部门的 analysts 可能用不同方式计算 metrics。Data scientists 可能直接使用 raw attributes，而没有应用标准 business logic。即使善意的 teams，也可能只是因为基于不同 assumptions 工作，就得出相互冲突的洞察。Federation layer 可以通过引入 semantic layer 来解决这个问题，semantic layer 会跨组织统一 business logic，无论它是与 federated query engine 耦合，还是作为独立组件存在。
Semantic layer 是 raw data 和 business understanding 之间的桥梁，如图 8.3 所示。它提供一个集中位置，用于定义 key metrics、dimensions 和 calculations，例如 revenue、customer churn 或 daily active users，确保无论数据源或消费工具是什么，都保持一致。这消除了逻辑重复，减少错误，并增强对结果的信任。
图 8.3：通过整合组织各处的数据并创建统一定义的 metrics 和 views，可以让数据在 AI 和 BI 中一致使用。
从实践角度看，这意味着 federation platform 应支持：
- 创建 reusable views 或 virtual datasets，用于封装 business logic
- 支持这些 semantic definitions 的 versioning 和 governance
- 与 access controls 集成，以确保正确用户看到正确数据
- 通过 catalogs 或 metadata layers 让这些 standardized datasets 可发现
例如，revenue calculation 可能涉及 join 多个 datasets、应用 currency conversions，并过滤 returns。如果在 semantic layer 中只定义一次，就可以确保每个使用它的 dashboard、notebook 或 report 都反映相同定义。这也意味着当发生变化时，例如针对新税务规则调整时，可以集中实现并一致传播。
这项能力在 federated environments 中尤其重要，因为底层数据可能来自多个 systems，且这些 systems 的 schemas、freshness 和 granularity levels 各不相同。Semantic layer 提供稳定、受治理的抽象，抹平这些差异，并为最终用户提供一致 interface。
最终，一致 semantics 会把 federation 从便利功能转变成战略能力。它确保由 federated queries 派生出的洞察，与来自 curated Iceberg tables 的洞察一样可靠且可执行，支持整个组织中可扩展、可信任的 analytics。
8.2.3 为 Analytics Tools 提供无缝连接
Federation layer 的价值不只是由它能连接多少 data sources 衡量，也取决于 users 和 tools 与这些数据交互有多容易，如图 8.4 所示。这种交互通常通过标准 interfaces 发生，例如 BI tools 使用 JDBC 和 ODBC，application integration 使用 REST APIs，高性能、language-agnostic data transport 使用 Arrow Flight。
图 8.4：通过使用 JDBC、ODBC、Arrow Flight 和 platform-specific REST APIs 等行业标准 interfaces，customer software、AI 和 BI 可以与 federation layer 中可访问的所有数据通信。图中每个 interface 都将数据交付给 AI、BI 和 custom data applications。
在 audit process 中，stakeholders 经常强调 broad tool compatibility 和 intuitive access patterns 的需求。Data analysts 想在自己偏好的 BI environments 中构建 dashboards。Data scientists 想直接从 notebooks 查询 live datasets。Engineers 希望通过 APIs 自动化 data workflows。满足这些需求，需要 federation layer 通过这些 interfaces 支持无缝、standards-based connectivity。
至少，这意味着提供以下传统 interfaces：
- JDBC 和 ODBC，用于与 Tableau、Power BI 和 Looker 等主流 BI platforms 兼容
- REST APIs，用于与 custom applications、lightweight tools 和 scripting environments 集成
现代数据平台越来越多地采用 next-generation interfaces，它们提供更丰富 semantics、更快 performance 和新的架构可能性。
ADBC 和 Arrow Flight
Apache Arrow project 的创建，是为了解决数据分析中的 performance bottlenecks，它通过引入 standardized、in-memory columnar format，实现 systems 和 programming languages 之间的高效数据交换。通过支持 zero-copy reads 并最小化 serialization overhead，Arrow 已经成为 high-performance analytics 的基础层。
在这个基础上，Arrow 生态引入了 Arrow Flight，这是一种基于 gRPC 的 protocol，用于在 processes 之间快速高效传输 Arrow-formatted data。Arrow Flight SQL 和 ADBC（Arrow Database Connectivity）进一步扩展了这项工作，为 JDBC 和 ODBC 提供现代替代方案。ADBC 为 low-latency columnar access to databases 提供 cross-language API standard，而 Arrow Flight SQL 支持高速 query execution 和 data transfer。这些 interfaces 结合起来，可以大幅提升 performance，并降低 memory overhead，尤其适用于 large-scale analytics workloads。
在 federated lakehouse 中，ADBC 和 Arrow Flight 可以用于：
- 以更低 serialization costs 检索大型 datasets
- 支持 partitioned 和 parallelized query results
- 改善 distributed query engines 之间的 intersystem query execution
支持 ADBC / Flight 的平台，例如 Dremio 和 Arrow 生态中的部分组件，允许 federation layer 同时作为 Arrow-native data 的 source 和 consumer，从而获得更好 performance 和更可扩展 computing。
Model Context Protocol
随着 AI assistants 和 autonomous agents 在 enterprise workflows 中变得更核心，一个长期限制变得更加突出：这些系统历史上通常是孤立运行的，与 live enterprise data 和 governed systems 断开。Model Context Protocol（MCP）通过提供标准化、开放 interface 来连接 AI models 与 real-time enterprise data，解决了这一缺口。MCP 的开发是为了解决 N×M integration problem，也就是过去每一种 model-and-tool pairing 都需要 bespoke integration 的问题。MCP 充当 universal layer，使 AI applications 能够安全访问 structured data 和 services，而无需重复集成工作，如图 8.5 所示。
图 8.5：借助 MCP，你可以让不同 agentic AI clients 访问不同 platforms，而不必重建 integration，从而更容易为特定 workflow 设计 AI agents。在这个例子中，MCP layer 用于发现 federated customer 360 data。
在 federated Iceberg lakehouse 中，MCP 解锁了几项能力：
Standardized data access——AI agents 可以使用通用 protocol 查询 federated Iceberg datasets，避免 model-specific integration complexity。
Two-way interoperability——Claude、ChatGPT 或 custom LLM-based agents 等工具，不仅可以检索数据，也可以对数据采取行动，按需启动 workflows 或生成 insights。
Agentic autonomy——借助 MCP，AI agents 可以探索 datasets、解释 metadata，并构建 contextual queries，支持 automated root cause analysis、dynamic reporting 和 ML pipeline orchestration 等 use cases。
通过 metadata control plane 暴露 federation layer，你可以让 AI agents 成为有信息支撑的协作者。它们可以解释 business logic、执行 governance policies，并在与 human users 相同的 access controls 内运行，从而弥合 LLM intelligence 与 enterprise trust boundaries 之间的差距。
需要注意的是，MCP 并不会替代 JDBC、ODBC 或 ADBC 等传统 access interfaces。相反，它是对它们的补充。标准 interfaces 保证与 BI tools、notebooks 和 applications 的广泛兼容性，而 MCP 提供一种结构化方式，用于暴露 metadata、semantics 和 policies，从而引导负责任且 context-aware 的数据使用。它们结合起来，使 human 和 machine actors 都能在同一个 federated environment 中有效工作，并使用最适合各自角色的 interface。
8.3 介绍 Dremio 和 Trino
随着各行业对 federated querying 的需求增长，在 federated queries 方面，有两个面向 lakehouse 的平台非常突出：Dremio 和 Trino。两个 engines 都提供跨多样 data sources 的 high-performance、distributed SQL querying，但它们有不同架构、功能和 use cases。选择 federation layer 的正确基础时，理解这些差异非常关键：
Dremio 将自己定位为 lakehouse query platform，与 Apache Iceberg 深度集成，并内置 semantic layer。它强调 self-service、strong governance，以及通过 reflections 和 caching 等技术实现 performance acceleration，我们稍后会讨论 Dremio 独特的 acceleration technology。Dremio 旨在让技术和非技术用户都能访问数据，同时支持 hybrid cloud deployments 和 interactive analytics。
Trino，也就是 PrestoSQL 的 fork，是一个 general-purpose federated SQL engine，擅长快速查询多个 sources。它因广泛 connector ecosystem、pluggable architecture，以及处理跨海量 datasets 的复杂 distributed queries 的能力而受到重视。Trino 在 flexibility 和 scale 比 out-of-the-box governance 或 UI features 更重要的 environments 中尤其流行。
虽然二者都支持 federated SQL，但它们的优势体现出不同优先级：Dremio 聚焦构建具备 governance 和 ease of use 的无缝 Iceberg lakehouse experience；Trino 则强调广泛 connectivity 和原始 federated query power。
8.3.1 Dremio
Dremio 是一个 federated query engine，旨在支持跨广泛 sources 的快速、基于 SQL 的数据访问，这些 sources 包括 cloud storage、relational databases、NoSQL systems，以及 Apache Iceberg 等现代 table formats。不同于存储和管理自身数据的传统 databases，Dremio 充当现有 data infrastructure 之上的 query layer，允许用户原地查询数据，而不要求先移动或转换数据，如图 8.6 所示。
图 8.6：Dremio 可以连接 databases、data warehouses、data lakes 和 lakehouse catalogs，让你在其 semantic layer 中建模数据，并在其内置 catalog 中管理 Iceberg tables，然后使用常见 interfaces 连接你喜欢的 tooling。
Dremio 最初是为了解决 Apache Drill 和 Hive 等工具的 performance 和 usability limitations。它结合了 columnar execution engine、Apache Arrow 和多项 query acceleration features，包括 reflections、caching 和 predictive optimization。这些能力在 federated architecture 中尤其有价值，因为在这类架构中，query performance 可能会因为 latency、data fragmentation 和 remote system constraints 而下降。通过加速 queries 并最小化 redundant scans，Dremio 帮助缓解实时查询多个 systems 带来的 performance overhead，使其非常适合 federated environment 中的 interactive analytics 和 dashboard workloads。结果是 data analysts 和 engineers 在跨 distributed data sources 工作时，获得更 responsive、self-service 的体验。
Dremio 支持广泛 communication protocols，包括 JDBC、ODBC、REST 和 Apache Arrow Flight，使其可以与常见 BI tools、notebooks 和 custom applications 集成。这些 interfaces 在 federated architecture 中非常重要，因为它们让用户可以用熟悉工具跨 distributed systems 访问和分析数据，而无需 replatform 或学习新的 query patterns。虽然 SQL 是主要 language interface，Dremio 也通过 PyDremio 和 dremio-simple-query 等 client libraries 支持 Python，使 data scientists 和 engineers 能够构建 custom workflows。此外，Dremio 支持 Model Context Protocol（MCP），使 AI agents 能安全连接并执行 context-aware operations。这种对 human-friendly 和 machine-friendly interfaces 的组合，确保 federated data 在各种 use cases 中保持广泛可访问且一致受治理。
下面我们会更深入探索 Dremio 的 architecture、catalog model、performance characteristics 和 connectivity features，从而全面理解该 engine 如何运行，以及它在现代数据平台中的角色。
8.3.2 Dremio 的架构
Dremio architecture 专门面向跨多样 sources 和 formats 的高性能 self-service analytics 构建。Dremio 不要求在分析前移动或转换数据，而是提供一个 distributed、SQL-based query engine，直接运行在 cloud storage、relational databases、NoSQL systems 和 Apache Iceberg 等 open table formats 之上。这在 federated context 中尤其有利，因为访问 remote、heterogeneous systems 可能会影响 performance。通过将 Apache Arrow 的 in-memory processing 与 modular execution framework、intelligent caching 和 reflections 等 query acceleration features 结合起来，Dremio 可以最小化 latency，并降低 federated sources 上的 query overhead。
Dremio 设计的中心是其 core services，包括 master coordinator、scale-out coordinators 和 execution engines，如图 8.7 所示。Master coordinator 处理 query parsing、planning、optimization、metadata management 和 cluster orchestration。为了 scalability 和 high availability，可以在 load balancer 后部署 additional coordinators，以分散 planning workloads。Dremio 的 execution layer 由 engines 及其 executors 组成，可以高效执行 distributed query plans 和 DML operations。这种架构让 federation layer 能够随 user demand 和 query complexity 扩展，即使数据来自多个 backends，也能确保 responsive access。
图 8.7：Dremio 可以管理多个 coordinators 来解析和规划 query execution，然后在这些 coordinators 可用的多个 executors 之间分布 execution，从而支持 workload scalability 和 availability。
为了支持 high concurrency 和 workload isolation，Dremio 允许 administrators 独立配置和扩展 engines。每个 engine 都可以针对特定 workloads 调整，以确保 compute resources 与业务优先级和使用模式对齐。
Cloud Columnar Cache 进一步提升 performance，它是每个 executor 上的本地 disk-based cache。该 cache 以针对 Dremio execution engine 优化的 columnar format 存储 frequently accessed data，减少对 remote cloud storage 的依赖，并最小化 latency 和 egress costs。
Dremio 还集成了基于 Apache Iceberg 的 catalog，使其能够原生管理 Iceberg tables。该 catalog 支持 cross-engine interoperability、schema evolution、time travel 和 fine-grained access control，构成 Dremio lakehouse capabilities 的基础。
Supporting services，例如 metastore、secured telemetry、distributed storage，以及 Kubernetes deployments 的 high-availability features，确保 Dremio 在不同 environments 中保持 resilient、observable 和 scalable。其他能力，例如 AI-enabled semantic search 和全面 namespace management，使该平台适合复杂的 multi-tenant data ecosystems。
8.3.3 Dremio 的 Connector Ecosystem 和 Iceberg-Centric Focus
Dremio 提供广泛 connector ecosystem，使用户可以跨大量 data sources 进行 federated queries，从 object storage 和 databases，到 catalog services 和 cloud warehouses。该平台旨在让组织在数据所在位置查询数据，最大限度减少昂贵且耗时的 ETL pipelines。不同于 Trino 这类 general-purpose federated query engines，它们采取 format-neutral stance，并试图为多种 table formats 提供广泛但相对统一的支持，例如 Iceberg、Delta Lake、Hudi；Dremio 有意识地将架构围绕 Apache Iceberg 对齐。
Dremio 与 Iceberg 的 native integration 不只是兼容：它包括由 Apache Polaris 驱动的内置 Iceberg catalog，支持 Iceberg REST Catalog API，使其能与支持该标准的工具和 engines 互操作。这允许 Dremio 直接管理 Iceberg tables，并提供 automatic data compaction、vacuuming 和 metadata pruning 等高级能力，而无需第三方工具或 orchestration。相比之下，Trino 等 engines 虽然可以通过 plugin connectors 读取 Iceberg tables，但通常依赖 external catalog services，例如 Hive、Nessie 和 AWS Glue，并且通常不具备同等程度的 native write support 或内置 optimization tooling。
除了 Iceberg-first 方法，Dremio 还支持广泛其他 source types：
Lakehouse catalogs——Snowflake Open Catalog、Unity Catalog、Iceberg REST Catalog、AWS Glue、Hive 和 Nessie。
Object storage——Amazon S3，包括 S3-compatible storage、Azure Data Lake Storage、Google Cloud Storage、HDFS 和 NAS。
Relational and NoSQL databases——PostgreSQL、MySQL、SQL Server、Oracle、MongoDB、Teradata、Snowflake、SAP HANA、IBM Db2、Apache Druid 等。
Data warehouses and search platforms——Snowflake、Amazon Redshift、BigQuery、Azure Synapse Analytics、Amazon OpenSearch Service 和 Elasticsearch。
Other Dremio clusters——用户可以跨多个 Dremio deployments 做 federation，支持复杂、分布式环境中的 cross-cluster queries。
为了支持高级 use cases，Dremio 包含 external query pushdown 等能力，使得用底层 source native dialect 写的 SQL，在 Dremio 无法原生处理时，可以直接在 source 上运行。Runtime filtering 通过在 joined datasets 上动态应用 filters，提升 relational databases 查询性能，在不牺牲透明性的情况下提升效率。
虽然 Dremio 的 connector catalog 很广泛，但它的策略更强调深度优化而非广度。其哲学是对最具战略意义的 systems，尤其是 Apache Iceberg，提供高质量、紧密集成的支持，同时通过 REST-compatible catalogs 和 external query features 允许扩展。对于 connector coverage 的缺口，Dremio 用户可以创建 custom connectors，或优先将数据摄入由 Dremio 内置 catalog 管理的 Iceberg tables。
8.3.4 Dremio 的 Performance Enhancements
Dremio 被设计用于在 cloud 和 on-premises data 上交付 high-performance analytics，无论你查询 raw files、federated databases，还是 Iceberg tables。Dremio 的一个主要差异化点，是其分层 performance enhancement architecture，它可以降低 latency、最小化 compute costs，并改善 user experience。这些 optimizations 在 federated environment 中尤其有价值，因为网络 hops、缺少 indexing 或 remote storage 都可能导致 performance 下降。
Apache Arrow 和 Columnar Execution
Dremio performance model 的核心，是使用 Apache Arrow。Apache Arrow 是一种 columnar in-memory format，专为高效 analytical processing 设计。Dremio 的 query engine 完全在 Arrow 上运行，支持 vectorized execution，并且相比 row-based processing 降低 memory overhead。这种 format 还支持在支持 Arrow 的 systems 之间进行 zero-copy data exchange，例如通过 Arrow Flight 连接的 BI tools 和 data science notebooks。
Data Reflections：Materialized Acceleration
Dremio 最强大的 performance tools 之一是 Data Reflections：它是基于 views 或 tables 预计算的数据结构，类似 intelligent caches。不同于 static materialized views，reflections 对用户透明，不需要 query rewrites 或 maintenance，如图 8.8 所示。当提交 query 时，query planner 会自动判断某个 reflection 是否可以完全或部分满足该 query，并重写 plan 以获得最佳性能。Reflections 可以加速 raw file queries 和 Iceberg table scans，尤其适合 BI dashboards 中的重复 queries 或大规模 joins。
图 8.8：当 aggregate query 发送到 Dremio 时，Dremio 会检查是否存在 reflections 可以优化该 query，并透明替换它。在这个例子中，Dremio 检测到一个 aggregate reflection，它包含 query 所需的 exact measurements 和 dimensions，于是将 query 转向优化后的 data structure。
Reflections 有多种类型，但最常见的是以下两种：
Raw reflections——通过加速 table scans 优化 queries。
Aggregation reflections——预聚合数据，以加速 analytical queries。
由于 Dremio 的 planner 是 cost-based，它会使用 reflection metadata，例如 statistics、cardinality 和 physical layout，来判断何时应使用 reflection。Administrators 可以在 physical 和 virtual dataset levels 配置 reflections，从而控制哪些内容被加速以及如何加速。对于 Iceberg tables，reflection management 也可以是 autonomous 的，允许 Dremio 根据 query patterns 创建和删除 reflections，而无需人工介入。
Cloud Columnar Cache
对于查询 cloud object storage 中数据的 deployments，例如 Amazon S3 或 Azure Data Lake Storage，Dremio 包含 Cloud Columnar Cache。这是每个 executor node 上的本地 disk-based cache，会以 compressed columnar format 存储 frequently accessed data blocks。后续针对相同数据的 queries 可以直接从该 cache 读取，大幅减少 cloud storage reads 和 latency。它还通过避免重复下载大型 files 降低 egress costs。该 cache 使用 Least Recently Used（LRU）policy 自动管理。
Runtime Filtering
查询 federated systems 中的数据时，最小化 data movement 对维持 performance 至关重要。Dremio 通过 runtime filtering 解决这个问题，这种技术会在 query execution 期间尽早且尽可能选择性地应用 filters，从而减少从 external sources 检索的数据量。例如，如果 query 将一张小表与一张大得多的表 join，Dremio 可以先从小表识别相关 values，然后用这些 values 在检索大 dataset 前过滤它。这会显著减少扫描、传输和处理的数据量，从而加快 query time 并更高效使用资源。
在 federated scenarios 中，这项优化尤其有价值，因为它降低 remote systems 和 network infrastructure 的负担。Runtime filtering 可以独立工作，但与 semantic layer 配合时更有效。Semantic layer 帮助 Dremio 预先理解 relationships 和 join logic，使其更容易识别 filters 应在哪里以及如何应用，以获得最佳性能。Runtime filtering 与 semantic modeling 的协同，可以提升 federated queries 的效率和响应性。
Workload Management 和 Engine Isolation
Dremio 通过 multi-engine architecture 提供细粒度 query execution control，允许组织创建、隔离并配置不同 execution engines，以适配特定 workload types。每个 engine 都作为独立 compute cluster 运行，这意味着它可以被独立 sizing、scaling 或 paused，而不会影响其他 engines。这支持 workload isolation，这是防止 “noisy neighbor” effects 的关键能力；所谓 noisy neighbor，是指某一 workload 中资源密集 queries 降低其他 workloads 的 performance。例如，可以为 interactive ad hoc analysis 配置专用 engine，并针对低 latency response times 优化；另一个 engine 则可以处理 scheduled data refresh jobs，强调更高 throughput 和更宽松 latency requirements。同样，具有可预测 patterns 的 BI dashboards 可以运行在针对 concurrency 和 stability 调优的 engines 上。
Administrators 可以配置每个 engine 的 executor count、memory footprint 和 concurrency limits，以匹配所分配 workloads 的需求。随着 usage 增长，engines 可以 resize 或 horizontal scale out；在 cloud environments 中，也可以在 inactive periods 完全暂停以降低 compute costs。这种 flexible execution model 不仅改善 performance 和 reliability，也允许组织优化 infrastructure spend，同时确保关键业务流程拥有 guaranteed resources。通过 policies 和 routing rules，queries 可以基于 user groups、data sources 或 query type 自动路由到合适 engine，从而在 lakehouse 中实现 fine-grained governance 和 performance management。
8.3.5 Trino
虽然 Dremio 提供紧密集成的平台和内置 acceleration features，但它不是唯一支持 federated query workloads 的 engine。另一个被广泛采用的选项是 Trino，一个 open source、distributed SQL query engine，专为跨多样且大规模数据环境的 high-performance analytics 而构建。作为 query engine，Trino 不同于 MySQL 或 PostgreSQL 等传统 transactional systems。它不是为 online transaction processing（OLTP）设计的，而是擅长 online analytical processing（OLAP）场景，非常适合跨多个 data sources 的 interactive、read-heavy workloads。
Trino 最初被构想为 Hive 和 Pig 等基于 MapReduce 的 engines 的更快替代方案，用于查询 Hadoop Distributed File System（HDFS）。此后，Trino architecture 演进为 general-purpose query layer，可以跨广泛 data sources 做 federation。它可以通过单一 SQL interface 查询 object storage–based lakehouses、relational databases、NoSQL stores 和 analytic systems。得益于 plugin-based connector model，Trino 几乎可以运行在任何 data platform 上，因此对 heterogeneous enterprise environments 高度适配。
Trino performance 的核心来自 distributed architecture。一个 Trino cluster 由一个 coordinator 和多个 workers 组成。Coordinator 解析并规划 query，将工作分发给 workers，workers 并行获取和处理数据。每个 query 会被转换为一系列 stages、tasks 和 splits，这些会并发执行以获得最大效率。
Trino 的关键优势在于其 connector-rich ecosystem，它允许组织在不先移动或转换数据的情况下原地查询数据。无论是查询 S3 中的 Iceberg tables、MySQL 中的 dimensions，还是 Kafka 中的 events，Trino 都提供统一 SQL interface。这对拥有高度碎片化数据架构或 hybrid environments 的组织尤其有吸引力。
但 Trino 只专注于 query execution 和 source connectivity；它开箱不包含 native semantic layer、data curation tools 或面向 business users 的 UI。这些功能必须通过互补工具实现，或由 AWS Athena、Cloudera、Starburst 等 managed offerings 提供，这些产品会将 Trino 与额外 governance、security 和 usability layers 打包。
下一小节中，我们会探索 Trino 的核心设计原则、优势和取舍。我们会考察 Trino 灵活 architecture 和广泛 connector support 如何使其适合某些 federation scenarios，以及生产环境中要充分发挥它的能力，可能需要哪些 infrastructure 和 tooling。
Trino 和 Presto 的历史
Trino 的故事始于 Presto。Presto 是 Facebook 于 2012 年最初开发的 distributed SQL query engine。Presto 被设计用于对分布在多个系统中的大规模数据进行 interactive analytics，例如 HDFS、S3 和 relational databases，而无需移动或复制数据。
随着 Presto 变得流行，它吸引了活跃的 open source community，并被 Netflix、Uber 和 LinkedIn 等大型科技公司采用。但在 2019 年发生了一次重大转变：Presto 的创始人，也就是 Facebook 的 Martin Traverso、Dain Sundstrom 和 David Phillips，由于 governance 和 trademark 方面的分歧 fork 了该项目。
他们以 PrestoSQL 的新名称发布了 fork，后来在 2020 年底改名为 Trino，以建立独立 identity。Trino 继承了 Presto 的原始愿景和势头，但拥有更强 community-driven ethos、更频繁 updates，以及更广泛 ecosystem support。
与此同时，Facebook 保留了 PrestoDB 名称，并继续独立开发。两个 engines 拥有共同起源，但在 features、development pace 和 community structure 方面已经分化。如今，Trino 通常被认为是更活跃开发且更广泛采用的版本，尤其是在 open source users 和 Starburst 等 commercial vendors 中，后者提供基于 Trino 的 enterprise distributions 和 cloud-native platforms。
简而言之，如果你正在探索 federated SQL engines，理解 Presto-Trino lineage 有助于澄清为什么某些工具或文档中仍会出现 “Presto” 一词，以及为什么 Trino 已成为现代 federated query architectures 的首选。
8.3.6 Trino 面向广泛 Source Support 的模块化架构
Trino 最具标志性的架构优势之一，是其 modular、extensible connector system。Trino 不只是提供大量预构建 connectors，它还提供 service provider interface（SPI），使 developers 能够轻松构建并插入新的 connectors。每个 data source 都被视作一个 catalog，可独立配置，并使用标准 SQL 访问。该设计允许组织跨 clusters 混合和匹配 data sources，并在它们之间无缝 join，而不要求用户理解底层配置。凭借其 distributed query engine，Trino 可以跨 remote systems 高性能执行 federated queries，使其成为广泛 analytical workloads 的有效统一层。
Trino 开箱包含多类 connectors：
Data lake and lakehouse formats——Iceberg、Delta Lake、Hudi、Hive。
Cloud storage and platforms——Amazon S3、Google Cloud Storage、Azure Data Lake、Google Sheets。
Databases and data warehouses——PostgreSQL、BigQuery、MySQL、Oracle、SQL Server、MariaDB、Redshift、Snowflake、Exasol、SingleStore、DuckDB。
NoSQL and key-value stores——Cassandra、MongoDB、Redis、Ignite、OpenSearch。
Streaming and analytical systems——Kafka、Pinot、Druid、ClickHouse、Elasticsearch、Prometheus、Loki。
Utilities and miscellaneous——BigQuery、Thrift、JMX、Memory、System、Faker、TPC-H、TPC-DS、Black Hole。
这使 Trino 能够作为 federated analytics 的 hub，非常适合数据版图碎片化、横跨 cloud、on-premises 和 multivendor ecosystems 的企业，如图 8.9 所示。
图 8.9：Trino 可以连接 databases、data lakes、data warehouses、lakehouse catalogs 和 streaming systems，并通过 REST API、JDBC、ODBC 和多种 community-developed MCP servers，让 federated queries 的结果可访问。
最终，Trino 的 modular architecture 可以在最小化 duplication 的情况下确保广泛 data access，使它成为 distributed analytics 和 query federation 的灵活强大 engine，尤其适合复杂 enterprise environments。
8.3.7 Trino 在复杂环境中的灵活性和可配置性
Trino 为灵活性而设计，但让它脱颖而出的是其 distributed query engine 的能力。它的架构非常适合以 cost-effective、high-performance 的方式，跨 data lakes 和 federated sources 查询大型 datasets。这个设计的核心是 Trino 的 hierarchical execution model，由 queries、stages、tasks 和 splits 组成，会将复杂 analytical queries 拆解成小型、独立的工作单元。这些单元随后可以在 scalable cluster of machines 上并行执行，即使面对海量 datasets 或多个 remote sources，也能显著降低 query latency。
这种 distributed processing model 对 federated environments 尤其有利，因为 Trino 可以跨不同 systems 并行读取和聚合。无论访问 object storage、relational databases 还是其他 connected sources，Trino 都会高效下推 filters、最小化 data movement，并最大化 concurrency。其 decoupled coordinator-worker architecture 进一步增强 scalability，使 compute resources 可以根据 workload demands 调整，如图 8.10 所示。再结合对 memory、concurrency 和 resource isolation 的细粒度控制，Trino 提供了现代 multi-tenant data platforms 所需的 performance 和 adaptability。
图 8.10：Trino clusters 由 coordinator node 和 worker nodes 组成，coordinator node 将工作分发给 worker nodes。通过添加更多 workers，worker nodes 可以 horizontal scale，以处理更多 queries。
Trino Gateway：面向 Trino Clusters 的 Load Balancing 和 Routing
Trino Gateway 是一个 open source extension，提供跨多个 Trino clusters 的 load balancing、proxying 和 intelligent routing。它解决了许多与 Dremio 通过 scale-out coordinator architecture 处理的 scaling 和 workload isolation 类似的问题。
Use cases and advantages
Unified access point——Trino Gateway 允许 users 和 BI tools 通过单一 connection URL 连接，而 queries 会透明分发到多个 backend Trino clusters 中的一个。
Workload-aware routing——Administrators 可以定义 rules，基于 query type、user group 或 data source 路由 queries。这使得可以将特定 workloads 隔离到专用 clusters 上，例如 reporting 或 ad hoc analysis。
Seamless upgrades——Trino Gateway 支持 blue/green 和 canary deployment models，使你可以测试或推出新版本 Trino clusters，而不打断 users。
Dynamic cluster management——Clusters 可以在不中断 users 的情况下添加、移除或扩展。Gateway 会基于 available capacity 和 health checks 自动处理 routing。
Key features
- Centralized query routing 和 workload distribution
- 基于规则的 routing policies 配置
- 支持 high availability 和 failover
- Monitoring 和 logging hooks
- 与 access control 和 identity systems 集成
High-level architecture
Trino Gateway 位于 clients 和 Trino clusters 之间，拦截 incoming queries 并将其路由到合适 cluster。它监控 cluster health，并使用 routing rules 确保 queries 被高效可靠处理。这种设计更容易管理 multicluster environments，并确保 compute resources 可以独立于 end-user connections 扩展或升级。
Trino 还提供 cost-based optimizer，并支持 dynamic filtering、broadcast joins 和 partitioned joins 等策略，有助于改善不同 query shapes 和 data distributions 下的 performance。这些设置可以通过 session properties 控制，让 users 和 administrators 能够基于 real-time conditions 或已知 bottlenecks 调整 query plans。
在 large-scale 或 performance-sensitive environments 中使用 Trino 时，它支持以下能力：
- 通过 catalog- 或 session-based rules 实现 query routing 和 workload isolation
- 与 LDAP、Kerberos 或 OAuth 等 external security systems 集成
- 使用 Alluxio 或 Rubix 等 caching layers，减少来自 remote sources 的 I/O
- 支持 custom extensions，例如添加 user-defined functions 或使用 Trino plugin SPI 编写新 connectors
由于 Trino storage independent 且不直接管理数据，它可以与现有 infrastructure 搭配使用，不对数据的位置或组织方式施加严格要求。这使它适合 hybrid deployments，因为数据可能分布在 on-premises systems 与 cloud platforms 之间，或多个 cloud vendors 之间。
Trino 的灵活性提供了许多优化和定制机会，但也需要更高 operational expertise 才能有效管理。针对特定 workloads 调优 system、维护 connector configurations，以及确保跨 federated sources 的一致 governance，通常需要 platform 或 infrastructure teams 承担。
Trino 的设计使其适应广泛 use cases 和 deployment models，尤其适合预期存在 architecture complexity、diverse sources 和 performance tuning 的 environments。
8.3.8 Trino 的社区驱动演进和 Vendor Extensions
Trino 的开发主要由活跃 open source community 推动，广泛的 contributors 和 users 共同塑造其 roadmap 和 features。这种 community-led model 使 engine 能够快速响应新兴数据需求演进，并鼓励新能力引入和采用过程的透明性。
Trino 的 open governance model 确保 enhancements，例如支持新 connectors、query optimizations 或 language features，会由广泛 stakeholders 共同 review 和开发。因此，Trino 通常能较早支持流行 data platforms 和 formats，并受益于真实世界反馈和多样 usage scenarios。
除了 core open source project 之外，一些 vendors 提供基于 Trino 的 commercial distributions 和 managed services。这些 vendors，例如 Starburst、AWS，通过 Athena，以及 Cloudera，通常会在 base engine 上扩展额外 enterprise-focused features。
这些 vendor offerings 旨在降低部署和维护 Trino clusters 的 operational burden，同时添加 security、caching、observability 和 enterprise infrastructure integration 等能力。
Open source core 与 commercial enhancements 的共存，为用户采用 Trino 提供了灵活性。组织可以从 open source engine 开始，用于初期实验或内部 workloads，然后随着需求演进迁移到 managed 或 enterprise version。
这种 ecosystem model 以 community development 为基础，同时由 vendor-led innovation 丰富，在 openness 和 enterprise readiness 之间取得平衡，使组织能够根据 technical requirements、governance standards 和 operational preferences 定制 Trino 使用方式。
8.3.9 Trino 中的 Semantic Layer Considerations
虽然 Trino 擅长 federated query performance 和广泛 connector support，但它不像 Dremio 那样包含 built-in semantic layer。在构建 governed、business-friendly data experiences 时，这一区别尤其重要，因为 standardized metrics、consistent definitions 和 curated datasets 对 data consumers 至关重要。
相比之下，使用 Trino 的组织必须采用以下策略之一来加入 semantic capabilities：
Pairing with a dedicated semantic layer tool——Cube、AtScale、Select Star 和 dbt Metrics 等技术可以叠加在 Trino 之上，用于定义一致、可复用 business metrics 和 semantic models。
Using enterprise-grade managed services——一些围绕 Trino 构建的 commercial platforms，例如 Starburst Galaxy 或 Cloudera 的 Trino deployments，可能会在 enterprise offerings 中包含 integrated 或 add-on semantic modeling features。
这些方案通过提供 governed data access、metadata cataloging、metric standardization 和与 BI tools 集成等功能，弥合这一缺口。但它们也会引入额外 deployment、licensing 和 integration considerations，必须基于团队目标和基础设施进行评估。
为 Trino 选择 semantic layer strategy 时，必须与 data consumers 的需求、governance requirements 的复杂性，以及计划支持的更广泛 tooling ecosystem 对齐。
8.4 Deployment Models
随着组织采用 data federation platforms 来统一访问不同系统，选择合适 deployment model 变成一项战略决策，需要平衡 performance、cost、scalability 和 operational complexity。Dremio 和 Trino 都提供灵活 deployment options，从运行在 on premises 或 cloud 中的 self-managed clusters，到 commercial vendors 提供的 fully managed services。
这些模型服务于不同组织需求。有些团队因为 regulatory 或 cost considerations，需要对 infrastructure 进行严格控制；另一些则偏好 cloud-native SaaS solution 的敏捷性和较低运维开销。许多情况下，公司会经历这些 deployment stages，从 on-premises 或 hybrid configurations 开始，然后随着现代化计划推进，逐步转向 managed services。
下一小节中，我们会探索 Dremio 和 Trino 可用的 deployment models，考察它们各自对 self-managed 和 managed environments 的方法。我们也会强调每种模式的独特能力和取舍，帮助你更有效地将 deployment choices 与组织架构和运营目标对齐。
8.4.1 部署 Dremio
Dremio 提供两种主要 deployment models：self-managed 和 cloud-managed，使组织可以选择最符合其 infrastructure preferences 和 governance requirements 的运营方式。
Self-Managed Deployment
Dremio 可以以两种形式作为 self-managed solution 部署：
Dremio Community Edition——这个免费版本提供核心能力，可以安装在几乎任何 environment 中，包括 on premises、virtual machines 或基础 container orchestration setups。它是团队探索 Dremio federated query capabilities 的优秀入口。
Dremio Enterprise Edition——该版本面向 production-grade、mission-critical environments，需要部署在 Kubernetes cluster 中。作为回报，它提供了 Community Edition 不具备的多项高级功能：
- Fine-grained role-based access control（RBAC）和 field-level access control（FGAC）
- 集成的 Iceberg-native catalog，用于 transactional table management
- Autonomous Iceberg table maintenance，包括 compaction 和 cleanup
- Autonomous reflection management，用于 hands-off query acceleration
- 基于 workload demand 的 elastic scaling of query executors
这些能力使 Dremio Enterprise 能够在 self-hosted environments 中作为强大、可扩展的 lakehouse engine 运行，将 governance、performance 和 cost management 统一起来。
Cloud-Managed Deployment：Dremio Cloud
对于希望获得 fully managed solution 的团队，Dremio Cloud 提供 SaaS experience，并直接部署进 AWS 或 Azure environments。在这个模型中，Dremio 管理 control plane，而 customer 通过 secure connectivity 和 delegated execution 保持对 data sources 和 compute infrastructure 的控制。
Dremio Cloud 包含 Enterprise Edition 的所有能力，例如 integrated Iceberg catalog、elastic scaling、reflection management 和 built-in AI Agent，而且不需要维护基础设施，也不需要单独部署 MCP Servers for Agentic AI。它非常适合追求 cloud-native strategies 或希望以最小 DevOps burden 现代化数据平台的组织。
8.4.2 部署 Trino
Trino 作为 open source distributed SQL engine，提供极大 deployment 灵活性，从完全 self-managed environments，到越来越多的 cloud-managed offerings。这种通用性使组织可以选择与自身 infrastructure maturity、resourcing model 和 scalability needs 对齐的 deployment strategy。
Self-Managed Deployment
Trino 的核心是免费开源项目，可以部署在任何 environment 中：on premises、virtual machines 或 Kubernetes clusters。Trino 的 modular architecture 和 pluggable connector ecosystem 使它高度可扩展，用户可以针对特定 data sources、security configurations 和 query performance goals 定制 deployments。
在 self-managed setups 中，组织负责部署、配置、编排 clusters、优化 queries 和调优 performance。不过，Trino 受益于活跃社区，该社区维护丰富的 open source plugins 和 extensions，从 authentication modules 到 cost-based optimizers 等，支持平台深度定制。这使 Trino 对拥有强工程能力、希望保留 deployment 和 tuning strategies 控制权的团队尤其有吸引力。
Cloud-Managed Trino Offerings
对于希望降低 operational overhead 或加速 time-to-value 的组织，多家 vendors 提供 managed Trino deployments，每家都有独特 value propositions：
Amazon Athena 是 fully serverless Trino-based query engine，集成在 AWS ecosystem 中。它可以直接在 Amazon S3 上执行 interactive SQL querying，支持 automatic scaling、managed infrastructure，并与 AWS Glue 和 Amazon QuickSight 等 services 原生集成。Athena 完全抽象 cluster management，并按 query 定价，非常适合 ad hoc 或 low-frequency access patterns。Amazon 也通过 EMR service 提供 Trino deployment。
Cloudera 将 Trino 作为其 hybrid data platform 中的 managed component，定位为 Impala 的替代方案，用于 federated SQL analytics。通过 Cloudera’s Customized Professional Services（CPS），客户可以获得定制 deployments、优化 cluster sizing、高级 security configurations 和长期 operational support，这对从 legacy systems 转型或管理大规模 multisource environments 的企业尤其有价值。
Starburst 是 Trino 的 commercial steward，提供两种 deployment options：Starburst Enterprise 和 Starburst Galaxy，后者是 fully managed SaaS version。Starburst 在 open source core 之上添加 enterprise features，例如 advanced query observability、built-in security integrations、autoscaling 和 federated access controls。Galaxy 尤其适合希望在 cloud 中快速 operationalize Trino，且 infrastructure overhead 最小的团队。
Other providers，例如 Yandex、Pandio 等，也提供 Trino as a managed service，通常针对特定 use cases 或 geographies 调优。这些平台为寻求 localized support、regulatory compliance 或特定行业 integration 的组织提供替代路径。
无论是独立部署还是通过 managed provider 部署，Trino deployment ecosystem 都强调 flexibility、extensibility 和广泛 connector support。Self-managed deployments 提供细粒度 control 和 customizability，而 cloud-managed services 通过处理 infrastructure complexity 降低采用门槛。根据组织目标，无论是快速部署、与 cloud-native services 集成，还是支持高度 specialized use cases，Trino 多样 deployment options 都可以满足广泛 federation needs。
8.5 Federation Platform Decision Scenarios
选择合适 data federation platform，无论是 Dremio、Trino 还是其他 engine，很少是一刀切决策。本节不会为每种情况规定具体工具，而是通过一组 illustrative scenarios 展示不同组织如何基于真实需求权衡选项。这些示例旨在作为 framing decision-making process 的指导，而不是固定规则。
每个组织都有独特优先级，包括数据分布、团队技能、监管要求和长期架构目标。这里的目标是帮助你思考在自己上下文中最重要的 tradeoffs 和 capabilities。
我们将走过几个 hypothetical 但 realistic 的 decision scenarios，展示某些 platform characteristics，例如 connector breadth、Iceberg support、semantic modeling 或 cloud compatibility，如何与特定目标对齐。一如既往，最佳选择是最直接支持你的用户、数据版图和战略结果的选择。
8.5.1 碎片化 Multisource Environment：选择 Trino 获得 Connector Breadth
拥有高度碎片化数据环境的组织，operational data 分散在多个 cloud platforms、relational databases、NoSQL systems，甚至 flat files 中，通常会发现 Trino 广泛的 connector ecosystem 是实践上的合适选择。Trino 开箱支持几十种 connectors，从 Teradata 和 Oracle 等传统 data warehouses，到 Amazon S3、Delta Lake 和 MongoDB 等 cloud-native stores。
在这个场景中，公司可能正在经历 digital transformation，并且还没有准备好将数据集中到单一 lakehouse architecture 中。为了在不中断现有 operations 的情况下支持跨已有 silos 的 analytics，他们选择 Trino，因为它可以以最小 data movement 跨多样 systems 做 federated queries。
这个决策不一定是关于长期架构愿景，而是关于快速启用对现有 systems 的 read-time access。虽然公司最终可能会演进到使用 Apache Iceberg 或 centralized lakehouse 的更整合模型，但 Trino 让他们能够在不强迫过早 ETL 或复制决策的情况下，连接当前现实和未来目标。
这个例子说明 connector breadth 和 extensibility 如何在复杂环境中充当 short- to mid-term enablers，尤其是当 agility 和 minimal disruption 是最高优先级时。
8.5.2 构建 Native Iceberg Lakehouse：选择 Dremio 获得 Iceberg-Native Features
对于已经承诺采用 lakehouse architecture 的组织，尤其是以 Apache Iceberg 为中心的 lakehouse，Dremio 因其与 Iceberg 的深度原生集成而非常合适。不同于 general-purpose federation engines，Dremio 是从底层围绕 Iceberg 构建的，提供 automatic table optimization、autonomous reflection management，以及由 Apache Polaris 驱动的 fully integrated Iceberg catalog 等能力。
在这个场景中，公司已经开始将数据整合进 data lake，并将 Iceberg 作为 foundational table format。目标是降低 cloud storage costs、简化 operations，并为 data versioning、time travel 和 streaming ingestion 等高级 use cases 做好 future-proof 架构。选择 Dremio，不仅可以高性能查询 Iceberg tables，还可以用最少人工介入管理和维护它们。
Dremio 原生支持 Iceberg read / write capabilities，并包含 Iceberg-aware performance enhancements，例如 partition pruning、reflection acceleration 和 clustering。这让团队可以有信心地 operationalize lakehouse，而无需拼接多个 tools 或 services。
这个例子展示了与你的 core table format 和 catalog architecture 紧密集成，如何成为决定性因素，尤其是当 Iceberg 在数据战略中扮演核心角色时。
8.5.3 用 UI 和受治理 Datasets 赋能业务用户：Dremio
希望改善 business users 数据可访问性的组织，通常会优先考虑提供 intuitive interfaces、governed semantic layers 和 self-service capabilities 的平台。在这种背景下，Dremio 凭借 native semantic layer、user-friendly UI 和 integrated access controls 脱颖而出，这些能力都旨在帮助 nontechnical users 有信心地发现、理解和探索数据。
设想一家公司的 business analysts 高度依赖 dashboards 和 ad hoc queries，但由于各部门之间存在 disconnected、BI tool–specific semantic layers，导致不一致问题。通过采用 Dremio，公司可以在 federation engine 自身的 semantic layer 中集中 metric definitions 和 business logic，而不依赖 downstream BI tools。这减少了重复，强制一致性，并简化了 data consumers 之间的协作。
Dremio UI 允许用户浏览 data sources、curate virtual datasets，并定义 joins 或 filters，所有这些都可以不写 SQL 完成。同时，IT 和 data engineering teams 维持 fine-grained access control 和 governance policies，确保合规而不形成 bottlenecks。
这个场景强调 usability 和 governance 在规模化赋能 data consumers 中的重要性。对于希望扩大数据访问，同时保持数据可信度的团队，Dremio 开箱提供了 cohesive self-service experience。
8.5.4 轻量查询 Hudi Datasets：通过 AWS Athena 使用 Trino
当主要目标是对现有 Apache Hudi datasets 运行轻量、ad hoc queries，尤其是这些 datasets 存储在 Amazon S3 中时，由 Trino 驱动的 AWS Athena 提供一个实践且低摩擦的解决方案。Athena 是一个 fully managed、serverless query service，使用户能够直接在 S3 中使用标准 SQL 分析数据，而无需 provisioning 或管理 infrastructure。
在这个场景中，一家公司以 Hudi format 存储 transactional log data，用于 ingestion efficiency 和 incremental updates。虽然这些数据对 investigation 和偶尔分析很重要，但它不是高度 curated 或 performance-sensitive pipeline 的一部分。公司没有设置和管理专用 engine，而是选择 Athena 的 pay-per-query model，利用 Trino 对 Hudi 的原生支持快速探索数据，并避免 overhead。
这里的关键因素是 Dremio 不支持 Apache Hudi，这使其在该特定 use case 中被排除。相比之下，Trino 对多种 format 的广泛兼容性，包括 Hudi、Iceberg 和 Delta Lake，使它成为处理 mixed table formats 或在这些格式之间迁移的团队的灵活选择。
这个例子强调 format compatibility 和 infrastructure overhead 如何影响技术选择，尤其是当查询需求只是偶发、datasets 已经采用特定 format，且期望体验是 serverless 和 usage-based 时。
8.5.5 On-Prem Cloudera 现代化：使用 Trino 替代 Impala 以提升性能
许多拥有长期 Cloudera deployments 的企业，随着 workloads 增长和 performance expectations 提高，正在重新评估 query engines。在 Apache Impala 不再满足 performance 或 extensibility needs 的环境中，Cloudera 的 managed Trino offering 提供了一条同一生态内的自然升级路径。
在这个场景中，一家企业运行大型 on-premises Cloudera cluster，并使用 Impala 查询存储在 HDFS 和 Hive 中的数据。但它面临越来越多限制，例如缺少对 modern table formats 的支持、复杂 federated queries 性能较慢，以及 analytics workloads 难以扩展。由于 Cloudera 现在将 Trino 作为其平台中的 first-class、managed component 提供，组织可以在不离开当前环境或中断现有基础设施的情况下切换到 Trino。
Trino 提供更广 connector support，改善 federated 和 ad hoc queries 的 performance，并拥有更现代的 architecture。此外，Cloudera 的 Customized Professional Services（CPS）确保 Trino deployment 已针对现有 metadata、security 和 governance layers 调优并集成。
这个例子展示了 platform-native upgrade paths，尤其是在 vendor-managed services 支持下，如何提供平滑转型并释放新能力。当目标是在不放弃 Cloudera 现有投资的情况下现代化 query performance 时，managed Trino 会成为一个有吸引力的选项。
8.5.6 Hybrid Cloud Iceberg Strategy：Dremio 连接 On-Prem 和 ADLS
正在现代化数据基础设施的组织，通常会采用 hybrid architecture，在保留 on-premises systems 的同时逐步采用 cloud services。这种 phased approach 在有严格 data residency、latency 或 compliance requirements 的行业中尤其常见。对于追求 Iceberg-based lakehouse strategy 的团队，Dremio 因其 first-class Apache Iceberg support、integrated catalog 和 hybrid deployment flexibility 而提供有吸引力的解决方案。
设想一家公司当前运行 on-premises Hadoop cluster，但目标是随时间将数据和 workloads 迁移到 Azure Data Lake Storage（ADLS）。团队没有进行 disruptive lift-and-shift migration，而是采用 Dremio 来连接两个 environments。借助 Dremio 对 on-premises 和 cloud-based data sources 的查询支持，他们可以在数据所在位置 curate、optimize 和 accelerate Iceberg tables，并逐步将 storage 和 compute 转移到 cloud。
Dremio 可以以 self-managed 或 cloud-managed modes 部署，再加上支持跨 environments federation，使组织可以在拥抱 cloud-native capabilities 的同时维持 continuity。Autonomous reflection management、elastic execution scaling 和 semantic-layer-based data governance 等功能，提升 hybrid architecture 中的 performance 和 user experience。
这个例子说明 platform-native Iceberg capabilities 结合 hybrid query federation，可以让组织按自己的节奏演进，在最小化风险的同时最大化长期敏捷性。
8.6 Federation Alternatives
虽然 Dremio 和 Trino 等传统 federation engines 为实时查询 distributed data sources 提供了强大机制，但它们并不是支持 cross-system analytics 的唯一架构路径。一些替代方法正在出现，它们解决类似目标：减少数据重复、简化集成，并扩大数据访问，但采用不同架构路线。
8.6.1 通过 OneLake Shortcuts 实现 Virtualization
一个值得注意的替代方案，是 Microsoft OneLake 使用的 virtualization strategy。不同于传统 federation 那样将完整 SQL queries 下推到 external systems，OneLake 会创建 shortcuts，即指向 external storage locations 的轻量链接，例如 Amazon S3、Azure Data Lake Storage（ADLS）、Google Cloud Storage（GCS），以及 NetApp 和 MinIO 等 S3-compatible services。
这些 shortcuts 让 external data 在 OneLake environment 中看起来像 native tables。当它们被访问时，只有底层 data requests，例如 filters 或 column projections，会被下推到 remote storage layer，而不是整个 SQL query。这一区别很重要：它不是跨系统执行 distributed joins 或 aggregations，而是优化 access patterns，并将大多数 compute operations 保持在 querying engine 本地。虽然这限制了 cross-system querying 的表达能力，但它提供 operational simplicity 和可预测 performance，尤其是在 external datasets 很大或被频繁访问时。
8.6.2 通过 Spice.ai 实现 AI-Native Data Virtualization
另一种新兴方法来自 AI application domain。Spice.ai Cloud Platform 将 data federation 与 AI application enablement 融合起来，提供可组合 building blocks，用于 SQL queries、model inference、vector search 和 retrieval-augmented generation（RAG）。Spice 支持跨 PostgreSQL、MySQL、Databricks、Snowflake、BigQuery，以及 S3 和 MinIO 等 object storage systems 的 federated SQL queries。
Spice.ai 的差异化在于它面向 AI 和 application use cases 的 virtualized data views。它并不是每次用户请求都按需查询 remote sources，而是允许 developers 创建小型、快速的 materialized views，用于服务 APIs、dashboards 或 agents。这些 views 可以被 cached、replicated 或针对 AI workloads 优化，从而提升 production environments 中的 responsiveness 和 resilience。
底层，Spice.ai 使用 Apache DataFusion 和 Apache Arrow Flight protocol 来实现 high-performance query execution。它的 cloud platform 集成 observability、access control 和 resource management，非常适合作为依赖多样 data sources 的 AI-enabled applications backend。
8.6.3 选择合适方案
虽然这些 alternatives 不会替代 general-purpose federation engines，但它们在 operational simplicity、caching 或 AI integration 优先的场景中提供专门价值。Shortcut-based virtualization 可能适合聚焦 storage unification 和 performance predictability 的 environments。Spice.ai 这类平台则更适合构建 AI applications 的团队，因为这些应用需要 federated access，同时也需要 acceleration 和 model orchestration。
随着版图演进，组织可能会选择组合这些方法：使用 federation engine 支持广泛 analytical access，使用 shortcuts 支持可重复 external access patterns，并使用 virtualization platforms 支持 application-centric performance。最合适的方案取决于 lakehouse 必须支持的 users、data sources 和 workloads 的具体组合。
小结
并非所有数据都属于 lakehouse；federation 允许对 external systems 进行选择性、实时访问，同时让 Iceberg 保持在架构核心。
有效的 federation strategies 会优先最小化 data movement、管理 performance variability，并维护跨 sources 的 semantic consistency。
稳健 federation layer 集成三个关键组件：distributed query engine、用于标准化逻辑的 semantic layer，以及面向 humans 和 AI agents 的 accessible interfaces。
Dremio 和 Trino 展示了 federation 的两种不同方法：Dremio 强调 built-in acceleration 和 semantic control，而 Trino 提供灵活、模块化 federation 和广泛 connector support。
Trino 的 hierarchical query execution 和 Dremio 的 runtime filtering 都经过优化，用于在 federated environments 中并行化 workloads 并降低 latency。
Deployment choices，包括 self-managed 或 cloud-native models，会影响 cost、scalability 和 operational complexity；选择正确平台取决于团队能力和数据版图。
真实世界中的 federation 成功，取决于将工具能力与业务需求对齐，并在日益分布式的数据生态中平衡 access、governance 和 performance。
