构建 Apache Iceberg 湖仓架构——为迁移到 Apache Iceberg 做准备本章内容包括：执行基础设

本章内容包括：

执行基础设施审计
让利益相关方参与进来，以发现技术和组织需求
记录当前工具、存储系统和治理实践
将审计发现转化为有优先级、可执行的需求
关于 data storage、ingestion、catalog、federation 和 consumption 的考虑事项

采用 Apache Iceberg 不只是一次技术升级。它代表组织处理数据方式的转变，覆盖从 ingestion、storage，到 governance 和 analytics 的完整链路。要把它带入生产环境，你需要的不只是实验。你需要清楚了解当前 setup。

每个组织的数据版图都是独特的。你可能正在使用不同的文件格式、遗留 ETL 工具，或者正在处理特定区域的合规约束。如果你在没有先审计现有状况的情况下尝试集成 Iceberg，就可能面临低效、意外成本或治理缺口。一次经过深思熟虑的审计，可以通过把选项收敛成清晰策略，帮助你避开这些陷阱。

本章不会告诉你应该选择哪个 catalog，或者哪个 query engine “最好”。这是有意为之。我们会在后续章节深入介绍 lakehouse component options。Lakehouse 生态过于多样，无法给出一刀切建议。这里的目标，是帮助你澄清需求，使你在评估工具时可以把它们作为过滤器。许多工具的市场宣传会突出一些优势，但这些优势未必与你的目标一致。

一次成功的审计始于正确的利益相关方。每个团队使用数据平台的方式都不同，因此看到的优势和痛点也不同。Data engineers 会指出脆弱 pipelines 和技术债。Analysts 会告诉你数据是否容易找到、是否足够新。Compliance teams 会帮助你与监管要求保持一致。Business leaders 会澄清平台必须支持哪些战略结果。尽早访谈这些群体，既可以收集更好的输入，也可以建立一批 champions，帮助推动后续采用并移除障碍。

本章将展示应该问什么、问谁，以及为什么每个答案都重要。为了让内容更具体，我们会跟随 Hamerliva Bank Incorporated，一家虚构的金融公司，看看它如何经历自己的 Iceberg transition。它的审计将作为实践指南，帮助你发现自己平台的约束、优势和机会。本章结束时，你将具备塑造 Iceberg implementation 所需的信息——这个 implementation 会扎根现实、与业务需求对齐，并准备好扩展。

4.1 审计你的数据平台

在构建现代 lakehouse 之前，你需要知道自己当前拥有什么，以及组织真正需要什么。成功的 Apache Iceberg implementation 始于计划，而不是工具或基础设施。我会介绍一个结构化审计流程，用于突出技术约束、组织优先级，以及简化机会。这个审计是你建立 actionable requirements 列表的第一步，这些 requirements 将指导你的架构决策。

图 4.1 展示了从审计到 implementation 的路径。每个阶段都建立在前一阶段之上：stakeholder discovery 形成 requirements，而 requirements 又塑造你的技术蓝图。跳过审计，会让你有风险构建一个为别人问题优化的方案。

图 4.1：从收集信息，到建立需求，再到实施方案的旅程

这项工作不是要创建一个穷尽式的数据资产清单。它的目标是澄清你的平台必须交付什么，以支持业务目标。有了这种清晰度，你就可以更有信心地评估 vendors、components 和 deployment models。你也不太容易被那些与你优先级不一致的 marketing claims 影响。

4.1.1 谁是利益相关方？

要设计一个能够交付可衡量价值的数据平台，你首先需要理解它服务谁。Lakehouse 不是为单一用户或单一团队构建的。它是一个跨 departments、functions 和 roles 共享的数据基础。图 4.2 中展示的每个群体，都以不同方式与平台互动，并带来一组独特的期望、约束和顾虑。这就是为什么在审计开始时识别并让合适的 stakeholders 参与进来至关重要。这样可以确保你的 implementation 不仅技术上可行，也适合组织，并且长期可用。

图 4.2：访谈所有利益相关方，有助于创建尽可能完整的需求集合

一个关键视角来自 data engineering team。他们设计、构建和维护 ingestion pipelines 和 transformation jobs，将数据从 raw sources 移动到 analytics-ready formats。通常，他们也管理底层 storage infrastructure，无论是在本地还是云端。他们的输入对于揭示现有技术债的真实成本至关重要：哪些系统脆弱、过于复杂，或者不适合增长。Engineers 还能指出哪些工具运行良好、哪些工具施加限制，以及架构在哪里给整个组织造成 operational bottlenecks。

Data analysts 和 data scientists 提供不同但同样重要的视角。他们是数据的 consumers，依赖干净、及时、可信的数据做决策。Analysts 通常能指出 data value chain 在哪里断裂：刷新周期慢、数据定义不清，或者 tables 不易访问且经常需要 engineering intervention。这些痛点会悄悄侵蚀对平台的信任，导致 shadow systems 或重复工作出现。直接与这些用户交流，可以帮助你看到当前平台状态如何影响 business insight、speed to value 和 data trust。

你的审计也应该包括 compliance 和 security professionals。在许多行业中，他们确保你的数据架构符合法律、监管和内部政策要求。这包括 data residency rules 和 privacy regulations，例如 European Union 的 General Data Protection Regulation（GDPR），它规定 personal data 如何跨区域存储、处理和传输。它也可能包括金融监管机构的 auditability requirements，或关于 encryption、identity management 和 access control 的内部政策。

这些约束是架构中的 nonnegotiables，因此应尽早处理，而不是事后再补。让 compliance 和 security 一开始就参与进来；否则，即使技术方案设计得很好，也可能因为未解决的风险或监管顾虑而在 implementation 阶段停滞。

Business leaders 和 product owners 帮助设定数据平台的战略目标。他们不太关心你使用哪个 engine，更关心它能带来什么：更快的 time-to-insight、更低的 infrastructure costs、支持新的 customer-facing features，以及更高的 operational agility。在很多情况下，降低 total cost of ownership 是评估 Iceberg 的主要驱动力，尤其是当你要替换 legacy formats 或 rationalize 跨团队 storage 时。他们的 vision 定义了平台必须支持的 outcomes，并帮助你区分 must-haves 和 nice-to-haves。他们还帮助获取 funding、确定 resources 优先级，并在组织内推动 adoption。

最后，审计也应该包括 IT 和 infrastructure teams。他们负责维持平台运行所需的 hardware、networking 和 core services。其职责通常包括 provisioning 和 securing cloud 或 on-premises resources、管理 service-level agreements，以及维持 uptime。他们的输入还可以帮助你理解 operational constraints，例如 storage availability、network throughput，以及对 hybrid deployment models 的支持。如果不尽早让他们参与，他们往往会在后续提出关于 complexity、maintainability 和 total cost of ownership 的担忧。

从 IT 和 infrastructure teams 开始对话。他们管理数据平台所依赖的核心系统，也常常最先遇到 integration、scale 和 cost 的现实约束。Platform engineers 和 data architects 会在这个基础上构建，塑造 data analysts 和 application developers 使用的环境。Compliance 和 security teams 与他们协作，加固平台并确保新技术满足监管和组织要求。Business leaders 则补全全局，定义 use cases 并设定指导投资的 priorities。这些 roles 往往作为独立团队存在，但职责经常重叠。目标不只是收集每个群体的输入，而是建立 alignment。早期协作会减少后续摩擦，并建立 shared ownership，确保迁移到 Iceberg 既技术成功，也能被广泛采用。

4.1.2 应该问利益相关方什么？

识别出将塑造并使用未来数据平台的关键群体后，下一步就是与他们交流。可以用图 4.3 中的问题来引导对话。这些访谈不只是为了列出当前系统或不满。它们是为了理解今天的痛点和明天的目标。一次成功的审计会揭示用户和管理员经历的 friction，以及未来平台必须支持的 improvements。

图 4.3：你向利益相关方提出的问题，会帮助为整个企业创造价值。

与 data engineers 交谈时，重点关注维护当前 pipelines 的日常现实。询问哪些地方脆弱：哪些系统经常失败，哪些手工 workaround 已经变成常态，哪些地方在 scaling 时形成 bottlenecks。也要询问哪些 tools 或 data formats 正在拖慢平台。Engineers 通常能识别阻碍更快开发、更高效处理或更广泛扩展的限制。这些细节将塑造新 lakehouse 的技术需求。

与 analysts 和 data scientists 交流时，重点关注两件事：他们获取数据有多容易，以及他们有多信任数据。了解他们为了 reports、models 或 dashboards 获取所需数据需要多长时间。数据访问延迟通常会暴露更深层的架构低效或自动化缺口。还要询问他们对数据本身有多大信心。当 datasets 不一致、文档不足或容易出现 silent errors 时，用户往往会把数据复制到个人 silos 中，从而增加风险和碎片化。他们的反馈将帮助你设定 data quality、freshness 和 usability 预期。

与 compliance 和 security teams 交流时，重点关注 regulatory fit 和 governance capabilities。探索当前架构是支持还是阻碍合规工作。有些 storage models 和 metadata systems 会让 audits 很直接；另一些会让 audits 非常痛苦。询问哪些 access controls、lineage tracking 和 encryption standards 是不可协商的，以及平台当前在哪里支持它们、在哪里不足。尽早理解这些约束，可以让你把 compliance 融入平台设计，而不是把它当作事后补丁。

访谈 business leaders 时，目标是将技术能力连接到战略结果。Sponsors 通常不太关心架构如何构建，而更关心它让公司能做什么。询问哪些 analytics use cases 被技术限制阻塞。也要询问“success”是什么样子：更快的 customer insights、更低 analytics costs，还是支持新的 lines of business。他们的答案会设定平台必须达到的 value targets，以证明投资合理。

最后，与 IT 和 infrastructure teams 沟通，以理解新平台必须在什么 operational boundaries 内运行。询问当前是否存在 storage、compute 或 networking 限制，新架构必须遵守哪些边界。还要评估组织愿意采用新 operating models 的程度。有些团队愿意采用完全 cloud-native deployments；另一些更偏好 hybrid approach，或有监管要求必须保留 on-premises infrastructure。这些对话将帮助你预判 deployment constraints，例如区域监管顾虑和 egress fees、cost control needs，以及持续维护要求。

在这些讨论中，你并不只是编制 checklist。你是在把抽象目标转化为具体技术现实。你还会发现关键 interdependencies：ingestion engine 的选择会影响 metadata management；catalog 的选择会塑造 governance options；storage decisions 会影响 query performance。尽早看到这些连接，可以确保你的 Iceberg lakehouse 是有意识地架构出来的，而不是被动反应式拼出来的。你最终会得到一个技术上可靠，并且与业务优先级战略一致的平台。

4.1.3 执行技术审计

Stakeholder interviews 展示人们如何体验你的平台，而 technology audit 揭示平台实际如何工作。Technology audit phase 会补充 discovery conversations，通过检查数据环境的事实来理解当前状态：你拥有哪些系统、它们如何交互，以及 friction 或 misalignment 出现在哪里。如果没有这种对当前状态的清晰认识，你可能会设计出一个重复过去错误或忽略现实约束的 Iceberg lakehouse。

审计目标不只是编制工具和平台清单。它是要把当前架构与组织需求连接起来，并明确哪些部分可以自然演进成 Iceberg-compatible ecosystem，哪些部分需要重新思考。这个评估是你的 architectural reality check，帮助确保未来设计决策是有依据、可行，并且具备上下文意识的。

从记录 storage architecture 开始。列出当前正在使用的系统，例如 Hadoop Distributed File System（HDFS）、Amazon S3、on-premises network-attached storage（NAS），或 Snowflake、BigQuery 等 cloud-native warehouses。然后记录数据位于哪里、有哪些监管或地理边界，以及每个系统用于什么。例如，cloud warehouse 可能处理 ad hoc analytics，而 HDFS 支持 archival 或 regulatory workloads。每种系统都有不同的 performance、cost 和 compliance implications，这些都会影响你如何引入 Iceberg。

接下来，评估 file formats。许多组织最终会混合使用 CSV、JSON、Avro 和 Parquet 等格式，通常是因为工具或 vendor systems 随时间选择了这些格式。了解哪些格式最常见，哪些用于 analytics pipelines，哪些用于 raw ingestion，有助于确定所需 transformation 的范围。Iceberg 最适合与 Parquet 这样的 columnar formats 配合。如果大量数据仍然位于 row-based 或 semi-structured formats 中，就需要规划 conversion pipelines，或在 ingestion 阶段添加 staging layers。

另一个关键审计区域是 ETL 和 ELT frameworks。大多数现代 data stacks 会混合 batch 和 streaming jobs。Spark 和 Flink 可能已经存在，但许多组织也会使用 independent software vendors（ISVs）进行 orchestration 和 transformation。Informatica、NiFi、Qlik 和 Rivery 等工具很常见，尤其是在受监管环境或拥有长期 pipelines 的团队中。审查当前 stack 有助于识别哪些 workloads 可以以最小改动迁移到 Iceberg，哪些需要 connector upgrades、pipeline rewrites 或 phased transition plan。

除了数据处理，你还应该审查 metadata management 和 cataloging setup。Hive Metastore、AWS Glue 或 custom catalog databases 等系统，可能处理 schema definitions、ownership metadata 和 access controls。这些系统也会塑造平台如何执行 governance，以及如何处理 schema evolution，而这是 Iceberg 的核心优势领域。不过，并不是每种 metadata system 都能与 Iceberg 一样好地配合，尤其是 multitable transactions 等高级功能，只有 REST catalog–compliant Iceberg catalogs 才支持。检查当前方法是否可以扩展，或者是否需要迁移到 REST-based catalog，例如 Apache Polaris 或 Project Nessie。

最后，分析访问数据的 query engines 和 business intelligence tools。这些系统无论是 Dremio、Trino、Presto，还是 Tableau 和 Power BI 等传统 BI tools，都会塑造人们如何使用数据，以及他们对性能有什么预期。了解已有工具，以及它们如何连接到现有 tables，可以帮助你规划 Iceberg deployment strategy，并指导 interoperability 和 query optimization 相关决策。

你的技术审计应捕捉以下内容：

System landscape——当前使用的 storage layers、processing engines、catalogs 和 query tools。

Operational context——这些系统如何配置、哪里不足，以及必须考虑哪些 dependencies 或 constraints。

这个阶段就是架构与现实相遇的地方。审计之后，你将对自己的技术基础有一个扎实认识：什么可以保留，什么必须改变，以及 Iceberg 可以在哪里立即交付价值。再结合 stakeholder interviews 中的洞察，你就能定义既有愿景、又能实际执行的 requirements。

4.2 Hamerliva Bank 的审计实践

现在我们已经覆盖了全面审计的原则，接下来看看它们如何在实践中发挥作用。在本节中，我们会跟随虚构金融服务公司 Hamerliva Bank Incorporated，看看它如何将 audit framework 应用于自身环境。他们的旅程只是审计流程的一个例子，不是普遍处方，但它展示了战略性、彻底的方法如何为成功采用 Iceberg 奠定基础。

Hamerliva Bank 面临复杂环境。作为一家在欧洲和北美严格监管下运营的跨国公司，它必须平衡 compliance、performance 和 operational efficiency。它的平台支持从 real-time trading analytics 到 regulatory reporting 的各种场景。像许多组织一样，它也在与 siloed systems、昂贵 pipelines 和 data access barriers 作斗争。通过审计，Hamerliva Bank 从分散的现状，走向对未来 lakehouse 必须交付什么的连贯且有优先级的理解。

4.2.1 Hamerliva Bank 访谈利益相关方

Hamerliva Bank 审计流程的第一步，是识别并访谈组织内不同利益相关方。他们没有让技术决定架构，而是从使用数据的人开始：他们的需求、挫折和目标。

Data engineers 对当前 pipelines 已经变得多么脆弱提出了严重担忧。许多关键 ingestion flows 依赖 legacy ETL tools；即使很小的 schema changes 也需要手工处理，拖慢 updates 并引入错误。他们还指出，跨区域维护单独的 on-premises 和 cloud pipelines，会重复工作并增加 operational risk。

Data analysts 和 data scientists 表示，很难获得及时、可信的数据。Analysts 解释说，准备 datasets 往往意味着进行 informal、undocumented changes，这会导致 reports 之间不一致。Data scientists 还希望能够实时访问 streaming data，让机器学习模型响应得更快。

Compliance 和 security teams 强调，全面 audit trails、严格遵守 data residency regulations，例如 EU-based data 适用的 GDPR，以及 data at rest 和 in transit 的加密至关重要。他们还要求 detailed data access logs，以满足监管要求，例如 SEC Rule 17a-4，该规则要求 financial transactions 具有 immutable、auditable records。缺少内置 lineage tracking 的系统，或者需要大量 custom tooling 才能满足这些义务的系统，都被标记为 operational 和 compliance risks。

Business leadership 带来了战略视角。他们希望获得更快 insights、更快 experimentation 和更低 analytics costs。他们也看到机会：通过改善 data access 和 data trust，可以推出新的 client-facing data products。

IT 和 infrastructure teams 澄清了 operational constraints。他们强调了 scaling on-premises environments 的挑战，以及需要 hybrid deployment model 来连接受监管的 on-premises data 与 cloud-native analytics workloads。

通过收集这些不同视角，Hamerliva Bank 建立了一个关于技术挑战和业务机会的详细地图，见表 4.1。他们开始在组织内培养 buy-in，将 stakeholders 转化为平台转型中的积极参与者。

表 4.1：Stakeholder interview findings

Stakeholder group	Key observations	Challenges highlighted
Data engineers	脆弱、手工密集的 pipelines	复杂 schema evolution、冗余 regional pipelines，以及 operational overhead
Data analysts and data scientists	难以及时、一致地访问可信数据	需要提升 data freshness、clarity，并减少 manual preprocessing
Compliance and security teams	围绕 data residency、encryption 和 lineage 有强监管合规需求	缺少内置 auditability 和 dynamic access controls
Business leadership	需要更快 insights 和更低 analytics costs	想做新的 data-driven products，但被平台敏捷性不足阻碍
IT and infrastructure	存在 scalability 和 operational complexity 挑战	Hybrid cloud/on-prem 需求；维护 legacy on-prem resources 困难

4.2.2 Hamerliva Bank 审计技术栈

在获得 stakeholder input 后，Hamerliva Bank 进入 technical audit phase。在这个阶段，他们不只是列出工具，而是评估环境中的每个部分，会如何帮助或阻碍迁移到 Iceberg-based architecture。

他们的 storage setup 是碎片化的。On-premises HDFS clusters 存储 historical trading data，而 on-premises NAS systems 保存 vendor 和 compliance records。几个业务单元独立采用了 Snowflake 等 cloud data warehouses，导致 duplicated datasets 和 inconsistent governance。他们也在 Amazon S3 中有一个小但正在增长的 footprint，主要用于较新的 analytics work，这表明早期已经开始向 cloud-native practices 转移。

File format audit 显示，他们显著依赖 CSV 和 JSON，特别是来自 external vendors 的数据。一些较新的 datasets 已经存储为 Parquet，但大量高价值数据需要格式转换，才能充分利用 Iceberg 的性能优势。

在 processing frameworks 方面，Hamerliva Bank 的 stack 新旧混合。Apache Spark 支撑了许多 batch ETL pipelines，尤其在欧洲业务部门。在美国，Informatica 和 NiFi 在 regulatory data processing 中仍然扮演关键角色。Real-time ingestion 通过 Kafka 运行，但数据往往以 custom formats 到达，不能顺畅地与下游 analytics 集成。

Metadata 和 governance systems 同样碎片化。Hive Metastore 管理 on-premises HDFS environments 的 schema metadata，而单独的 ad hoc relational databases 存储 lineage 和 audit information。Schema changes 是手工的且有风险，偶尔导致 downtime 和交付变慢。

最后，他们的 query 和 BI tools 展现出一个多样但缺乏协调的生态。Dremio 和 Presto 支持 raw data lakes 上的 exploratory analysis 和基于这些数据构建的 dashboards。与此同时，Tableau、Power BI 和 Snowflake 是 executive dashboards 和 financial reporting 的首选平台。跨工具的数据重复和语义不一致，经常造成困惑和低效。

这次 technical audit 的结果总结在表 4.2 中，确认了 stakeholders 之前提出的许多痛点，也显示出所需变化的广度。成功不会来自 incremental improvements；相反，需要重新思考 storage、processing、governance 和 analytics 如何组织和集成。

表 4.2：Technical audit findings

Domain	Current state	Pain points identified
Storage	HDFS、NAS、S3、Snowflake、BigQuery	Fragmentation、duplicated data 和 inconsistent governance
File formats	CSV、JSON 占主导；Parquet 用于较新系统	Performance bottlenecks，广泛需要 format standardization
ETL/ELT frameworks	Spark、Kafka、NiFi、Informatica	依赖 legacy tools，batch/stream silos，transformation logic 不一致
Metadata and governance	Hive Metastore、relational metadata stores	Manual schema changes、limited lineage tracking 和 governance inconsistencies
Query and BI tools	Dremio、Presto、Tableau、Power BI、Snowflake	跨工具 data duplication、inconsistent semantics 和 governance gaps

4.2.3 Hamerliva Bank 总结审计发现

在收集 stakeholder input 并完成 technical audit 后，Hamerliva Bank 将发现编制成一份结构化报告。目标不是规定解决方案或锁定架构决策，而是澄清数据平台当前状态，并识别未来设计必须解决的关键挑战。该报告成为对齐内部团队、进入 requirements 定义阶段的共享参考。

报告被组织成四个 domain：storage、processing、governance 和 data consumption。每个 domain 都映射到数据平台的一层。对于每个 domain，团队记录 pain points、operational inefficiencies，以及继续推进前需要解决的 open questions。

在 storage layer，他们记录了基础设施的碎片化特征。数据分散在 HDFS、on-premises NAS 和多个 cloud data warehouses 中。这些环境之间 duplicated datasets 导致 inconsistent governance、更高成本和额外 operational overhead。关于 data residency、integration complexity 和 long-term scalability，他们仍有未解决问题。

在 data processing layer，审计发现现代和遗留工具混合存在。Spark 和 Kafka 支撑了部分 workflow，但旧 ETL systems 仍嵌入关键 pipelines。团队也同时运行 batch 和 streaming flows，这表明需要更统一的 ingestion strategy，并提出了 compatibility 和 operational maturity 相关问题。

Governance 和 metadata management 是最碎片化的领域之一。Schema definitions 在 Hive Metastore、internal databases 和 ad hoc documentation 之间以不一致方式管理。Schema changes 大多是手工的，而 tracking lineage 或 enforcing data access policies 通常意味着写 custom scripts 或跨团队协调。这在 audits 期间造成摩擦，并引发 compliance 和 data trust 方面的担忧。

最后，query 和 consumption layer 存在 tool sprawl 和 semantic inconsistency。多个 engines 和 business intelligence（BI）platforms 正在使用，每个都有自己的 assumptions 和 permissions。Business users 经常对同一份数据产生冲突视图，导致重复工作和漫长 validation cycles。这些工具各自运行良好，但与 upstream systems 的集成差异很大，限制了端到端可见性，如表 4.3 所示。

表 4.3：访谈和审计发现

Domain	Key findings	Problems to address
Storage	基础设施碎片化，跨 HDFS、NAS 和 cloud warehouses	Data duplication、inconsistent governance，以及不清晰的 long-term storage strategy
Processing	Spark、Kafka、NiFi 和 Informatica 混合，用于 batch 和 streaming jobs	Tool incompatibility、redundant pipelines 和 manual schema coordination
Governance	Metadata 分散在 Hive、relational DBs 和 manual processes 中	Manual schema evolution、audit complexity 和 inconsistent access controls
Data consumption	使用 Dremio、Presto、Snowflake、Tableau 和 Power BI	Semantic drift across tools、multiple data copies 和 inconsistent user experiences

4.3 从审计到需求：为设计奠定基础

完成审计后，下一步是将这些发现转化为一组清晰 requirements，以指导 Iceberg lakehouse 设计。现在还不是选择工具或锁定 vendors 的时候。相反，你需要定义成功意味着什么，包括技术和组织两个层面，这样之后才能清晰且有信心地比较选项。

Use cases 是这个转化过程的核心。它们连接业务目标和架构选择。你的审计可能揭示了 pain points、constraints 和 existing systems，但 requirements 应聚焦平台如何被使用以创造价值。例如，“为 investment analysts 提供亚秒级 dashboard refreshes” 是一个 use case。“支持 nightly regulatory audit extracts” 是另一个。所有这些 use cases 共同定义了架构必须支持的 operational scenarios，并塑造满足这些场景所需的 technical requirements。

一旦你理解了 use cases，就可以将它们映射到 Iceberg lakehouse 的五个基础组件：storage、ingestion、catalog、federation 和 consumption。对于每个组件，定义数据平台必须交付的具体 outcomes。把这些 outcomes 作为 requirements，也就是用于评估 architectures 和 tools 的决策过滤器，依据是它们能否满足真实需求，而不是 feature lists 或 vendor claims。

一个 requirement 可能是：“Data residency must be enforced at the regional level”，这是 storage outcome；也可能是：“Streaming ingestion must support incremental upserts with no downtime”，这是与 low-latency use case 绑定的 ingestion need。用 plain language 写 requirements，按组件分组，并基于 business value 和 implementation effort 确定优先级。

好的 requirements 会澄清 design tradeoffs，并为后续 architecture decisions 提供理由。它们将 stakeholder priorities 连接到具体 technical goals，并确保 Iceberg deployment 始终聚焦必须交付的价值。

接下来的 sections 中，我们会根据审计中发现的 use cases，为每个 lakehouse component 定义这些 requirements。这个 framework 为构建你的 architectural blueprint 奠定基础，见图 4.4。后续章节中，我们会检查每个组件，覆盖 tools、tradeoffs 和 design patterns，帮助你让 lakehouse 变成现实。

图 4.4：你的审计是导航架构决策的地图。

4.3.1 定义 Storage Requirements

Storage 是 lakehouse 的基础。它决定数据位于哪里，以及如何随着时间被治理、访问和扩展。你需要在四个关键领域定义 storage requirements：compliance obligations、performance expectations、cost constraints 和 operational realities。这些因素会指导你选择 cloud、on-premises 或 hybrid approach。清晰写下 requirements，以支持这个决策，同时避免偏见。

从重新审视 audit results 开始。现有哪些 storage systems？数据如何分布在不同 environments 中？是否有些 systems 与 compliance-sensitive workloads 紧密绑定，例如受 regional residency rules 管辖的 trading data？是否有其他 systems 因 redundancy 或缺少 tiering 而推高成本？

基于这些观察，开始以 outcome-focused terms 编写 requirements。它们应该具体且可测试，但不要锁定某种技术或 vendor。例如，如果 audit 揭示了监管需求，一个 requirement 可能是：“All PII collected in the EU must be stored within EU data centers.” 如果成本是问题，你可以写：“Cold data not accessed within 90 days must be automatically migrated to low-cost archival storage.” 这些 requirements 表达的是 needs，而不是 solutions，因此在保持约束的同时，为 implementation 留下灵活性。

也值得考虑不同 deployment models 之间更广泛的取舍：

Cloud-based storage 提供 scalability、elasticity 和更简单维护。Amazon S3、Google Cloud Storage 和 Azure Blob Storage 等 object storage services 具有高 durability，并且非常适合 Iceberg architecture。如果你希望简化 infrastructure management 或扩大全球访问，cloud-native storage 是不错选择。但 cloud storage 也引入了新挑战：data egress fees、某些 workloads 的 latency，以及更复杂的成本预测。如果 cloud storage 是你的架构组成部分，就要在 requirements 中捕捉这些需求。例如：“Storage must support tiering and archival for cold data”、“All data must be encrypted at rest and in transit”，或 “Access must be auditable for compliance and incident response”。

On-premises storage 在许多行业中仍然必不可少，尤其是当 data sovereignty、physical control 或 regulatory restrictions 不可协商时。在这些 environments 中，HDFS 或 enterprise-grade object stores，例如 MinIO 或 NetApp，仍可能作为基础。典型 requirements 包括：“The system must support WORM（Write Once, Read Many）policies for regulatory compliance” 和 “The storage must be accessible from isolated network zones without public internet access.” On-premises storage 提供控制力，但也要求内部 expertise、前期投资和长期 capacity management 计划。

Hybrid storage models 越来越常见，但它们也是设计和运维最复杂的。组织使用它们来平衡 control、flexibility 和 regulatory constraints。它们可能因为 latency、cost 或 compliance requirements 将部分 datasets 保留在本地，同时使用 cloud 支持 analytics、elasticity 或 long-term retention。这种方法可能带来回报，但也比完全 on-premises 或完全 cloud-based architecture 增加更多运维和监控工作。在 hybrid environments 中，requirements 应明确 on-premises 和 cloud systems 如何交互。例如：“Storage must expose a consistent object store interface across cloud and on-premises environments” 或 “The platform must support unified metadata and catalog integration across heterogeneous storage backends.” 如果边界处没有明确 standards，hybrid architectures 可能变得脆弱、难以 troubleshoot，并且维护成本高。

记录 storage requirements 后，确定它们的优先级。并不是所有 requirements 都同样紧迫。有些可能对 compliance 或 performance 至关重要，例如 encryption 和 access latency。另一些可能反映长期目标，例如 automatic tiering 和 cross-region replication。将 requirements 分类为 “critical”、“nice to have” 和 “future-facing”。这一步会帮助你在 vendor discussions 和 architectural decisions 中更有信心，也为 stakeholders 提供清晰方式来评估 tradeoffs。

Storage requirements 会塑造 Iceberg lakehouse 的 resilience、efficiency 和 scalability。无论你选择 cloud、on-premises 还是 hybrid storage，架构都应回应明确陈述的需求，而不是默认假设。

4.3.2 定义 Ingestion Requirements

Ingestion 是 lakehouse 的入口，因此值得提前定义。选择 tools 或设定 latency targets 之前，先识别需要集成哪些 source systems。要考虑这些 sources 的多样性和复杂性，从 relational databases 和 APIs，到 SaaS platforms 和 event streams。添加或更新 sources 往往是 ingestion 中最困难、最耗时的部分。它需要深入理解 source-system behavior、data structures，以及 inserts、updates 和 deletes 上的约束。

一旦识别出 sources，下一步是映射 ingestion patterns：哪些以 batches 到达，哪些实时运行，以及每个团队需要多频繁更新。寻找当前 workflows 出问题的位置，例如 schema drift 时失败的 pipelines、手写 update processes，或拖慢交付的 jobs。这些发现会指导 tool selection，并帮助你设计一个 robust、scalable、responsive to business needs 的平台。

最重要的定义之一，是数据需要多新鲜。人们很容易把 streaming ingestion 当作黄金标准，但并不是所有 datasets 都能从 real-time pipelines 中获益，也不是每个团队都能可靠运行它们。Streaming architectures 会增加 operational complexity；它们需要 checkpointing、error recovery、backpressure handling，并且常常需要一套与 batch systems 不同的工具。如果你在并不真正需要 streaming 的时候采用它，就可能浪费 engineering effort，并承担不必要的 operational burden。

你的 requirements 应匹配业务做决策所需的速度。例如，如果 internal dashboards 每小时更新一次就足够用户使用，batch ingestion 可能就是最简单且成本最高效的选择。但如果某些 use cases，例如 fraud detection、algorithmic trading，或 scoring an ML model，需要几秒内的新鲜数据，就要精确定义这些 latency targets。像 “Streaming data must be queryable within 5 seconds of an event arriving” 这样的 requirement，会给 engineering team 一个清晰、可测试目标。

有时 hybrid ingestion model 是合适的。Apache Iceberg 同时支持 batch 和 streaming ingestion，因此平台可以先从 batch 开始，再根据需要走向 near-real-time ingestion，而不必重新架构整个 stack。一个经过思考的 requirement 可以写成：“Ingestion must support concurrent batch and streaming updates to the same table with transactional consistency.” 这会让团队随时间改善 freshness，同时保持 operations 稳定。

除了 freshness，ingestion requirements 还应说明平台如何处理 schema evolution、late-arriving data 和 corrections。这些是 evolving pipelines 中的常见挑战，尤其当数据来自 external providers 或频繁更新的 operational systems 时。像 “Schema changes must be propagated without stopping pipelines across downstream systems” 或 “Ingestion must support upserts and deduplicated inserts from streaming sources” 这样的 requirements，有助于保持平台敏捷和可靠。

不要忘记 operational concerns。询问谁负责拥有和维护 ingestion jobs，使用什么 tools 做 orchestration，以及如何处理 monitoring 和 alerting。在拥有多个 teams 和 pipelines 的 environments 中，requirements 应覆盖 maintainability 和 integration，例如 “Ingestion tools must integrate with an orchestration tool and support job lineage metadata” 或 “Ingestion failures must be traceable and must trigger alerts via existing observability systems.”

最后，注意 data integrity guarantees。根据 use case，你可能需要 ingestion pipelines 保证 ordering、处理 idempotency，或保证 exactly-once delivery semantics。如果这些不提前定义，往往会成为 bugs、delays、complexity、额外成本或 silent data corruption 的来源。

记录 ingestion requirements 后，将它们分成几个类别，在技术严谨性和业务价值之间取得平衡。有些 requirements 可能对监管或 operational correctness 至关重要，另一些则可能随时间成为 optimization targets。这种优先级排序会帮助你评估 Spark、Flink、Kafka Connect 或 vendor solutions 等 ingestion frameworks，关注真正重要的东西：是否支持你需要的 source connectors，而不是泛泛的功能或性能宣传。

一个定义良好的 ingestion strategy，不是选择最新或最强大的工具，而是确保数据可靠地流入 lakehouse，解决方案易于维护，并且适合组织做决策的方式。有了清晰 ingestion requirements，你就能创建一个支持增长、又不引入不必要复杂性的 data movement 蓝图。

4.3.3 定义 Catalog Requirements

Catalog 是 Iceberg lakehouse 的协调层。每一次 read 或 write operation，无论是由 Spark、Flink、Trino 还是 BI tool 发起，都会与 catalog 交互，以定位 tables，见表 4.4，解析 metadata，并管理 updates。这会把 lakehouse 从一组文件，转变为一个受治理、可查询、持续演进的数据平台。

不过，catalog 的角色正在演进。传统上，catalogs 通过跟踪 Iceberg table metadata files 的 references 来工作。较新的实现会直接从自己的 managed stores 提供 metadata，metadata files 更多用于 durability 或 recovery，而不是作为 primary source of truth。一些商业和开源 catalogs 已经采用这种方式，会在 relational 或 service-backed metadata systems 中聚合 table state，而不是仅依赖 file-based lookups。

Catalog 位于 governance、concurrency 和 interoperability 的交汇处。选择合适的 catalog，并为它如何管理和提供 metadata 设置清晰 requirements，是 Iceberg implementation 中最具战略性的决策之一。Catalog 的设计会影响 scalability、operational complexity，以及你的 lakehouse 后续演进的容易程度。

表 4.4：Iceberg catalogs 通过跟踪 metadata files 的位置来跟踪 metadata

Table	Metadata location
`sales_data_2024`	`s3://company-data/warehouse/sales_data_2024/metadata/00004-abcdefg.metadata.json`
`customer_profiles`	`s3://company-data/warehouse/customer_profiles/metadata/00012-hijklm.metadata.json`
`inventory_snapshots`	`s3://company-data/warehouse/inventory_snapshots/metadata/00003-nopqrs.metadata.json`
`web_traffic_logs`	`s3://company-data/warehouse/web_traffic_logs/metadata/00008-tuvwxy.metadata.json`

定义 catalog requirements 时，一个最关键决策是你的 catalog 是否需要支持 Iceberg REST catalog specification。该标准旨在改善 Iceberg 生态中的 interoperability；Apache Polaris、Project Nessie、Lakekeeper 和 Apache Gravitino 等项目使用它，AWS Glue Data Catalog、Google BigLake 和 Microsoft OneLake 也支持它。REST catalogs 暴露一致 API，使 engines 和 orchestration tools 能够以标准方式读写 metadata。实践中，支持程度各不相同。有些 engines 只支持 read operations，或者只提供 partial write support，因此在依赖完整 REST interoperability 之前，要验证你环境中每个工具的具体能力。

相比之下，不支持 REST specification 的 catalogs，例如传统 Hive Metastore 或某些 vendor-specific integrations，通常兼容性较弱。它们在某些环境中仍然可以与 Iceberg 一起工作，但跨现代 engines 使用时，可能需要 custom adapters，并可能限制高级功能，例如 multitable transactions。如果你的审计发现工具混杂，或者你想将 storage 与 compute 分离，Iceberg REST-compatible catalogs 可能更适合。

Catalog requirements 的另一个关键部分是 governance。Catalog 作为 central control point，用于跨 engines 定义 table-level access policies。支持 role-based access control（RBAC）和 attribute-based access control（ABAC），无论是内置还是与 identity providers 集成，都可以简化和统一 security management。Data discoverability 同样重要：用户能否通过 metadata search、tagging 和 lineage visibility 找到正确 datasets？治理良好的 catalog 应该在 enforcing permissions 的同时，也帮助 analysts、engineers 和 data scientists 找到并理解可用 datasets。示例 requirements 包括：“The catalog must support RBAC integration with enterprise identity systems” 和 “The catalog must provide robust permissions and searchable metadata to improve dataset discoverability.”

Catalogs 和 Fine-Grained Access Control

Fine-grained access control，例如 row-level 或 column-level security，通常由 query engine 执行，而不是 catalog。Catalog 可以帮助你定义和注册 policies 或 annotations，但在 query time 应用这些规则的是 engine，例如 Trino、Dremio 或 Snowflake。评估 governance needs 时，要考虑 catalog 和 query engine 在你的架构中如何协同。Catalog 可能提供强大的 policy modeling，但如果没有 engine enforcement，它可能无法满足你的安全目标。

Catalog requirements 应覆盖 metadata resilience 和 traceability。Time travel、rollback 和 commit history 等功能是 Iceberg 价值主张的核心，而 catalog 通常会通过协调 optimization 和 cleanup 帮助保持 tables 健康。示例 requirements 包括：“The catalog must autonomously expire snapshots older than 30 days” 和 “Table access should be logged as auditable events.”

最终，你必须决定是自己管理 catalog，还是使用 managed catalog service。Polaris、Nessie、Gravitino、Lakekeeper，甚至 legacy Hive Metastore 等开源项目都可以内部部署，让团队完全控制 updates、integration 和 scaling。这种方式最适合拥有强 platform-engineering teams，并偏好 infrastructure independence 的组织。AWS Glue Data Catalog、Dremio Catalog 或 Snowflake’s Open Catalog 等 managed services 更容易运维和扩展，并且开箱即有 operational support。取舍是 customization 较少，有时 portability 也较弱。

总结来说，catalog requirements 应澄清以下内容：

Interoperability——哪些 query engines 必须原生支持？

Governance——Catalog 必须启用什么级别的 access control（RBAC / ABAC）？

Deployment model——Catalog 是 self-hosted 还是 managed？

Catalog 不是事后补充。它是 Iceberg lakehouse 的心跳。强有力的 catalog requirements 会让 metadata layer 保持可靠和灵活，并为 interoperability、governance 和长期 scalability 奠定基础。这包括功能性需求，例如支持 table versioning 和 multi-engine access，也包括非功能性要求，例如 high availability、load 下的 scalability、security controls，以及与 enterprise authentication systems 的集成。选择一个同时满足两类需求的 catalog，你的平台才能随组织一起成长。

4.3.4 定义 Federation Requirements

即使在成熟的数据环境中，也很少所有数据都位于同一个地方。监管约束、组织 silos 和现代化工作，经常使数据分散在 cloud warehouses、on-premises relational databases 和 legacy Hadoop environments 中。你的 Iceberg lakehouse 不需要物理整合所有数据，但必须提供无缝的 logical access。这就是 federation requirements 发挥作用的地方。

Federation 是 query engine 实时访问并 join 来自多个系统的数据的能力，而不需要先移动或复制数据。它也可以指平台连接这些 sources 的能力，例如 operational databases、cloud APIs 和 third-party SaaS platforms。有了强 federation，你可以提供更统一的数据体验，同时避免集中化每个 dataset 带来的复杂性、延迟和成本。

你的审计应揭示关键 workloads 是否依赖跨 environments 的数据。例如，analysts 可能从 operational database 拉取 client profile data，并与存储在 Iceberg 中的 analytics data join。这是你需要 federated access 的强信号。如果团队只是为了使用偏好的 BI tool 而跨系统复制数据，federation 可以通过支持直接跨系统查询来降低复杂性和成本。

首先定义在你的环境中 “connectivity” 和 “coverage” 意味着什么。例如：“The query engine must support federated access across Iceberg, JDBC-compatible databases, and cloud object stores.” 至少，你的平台应该连接审计中识别出的每个系统，无论它是 SQL-based data warehouses、NoSQL systems，还是 file-based object stores。

Federation 不只是 connectivity。为了有效，平台还需要 semantic consistency。这意味着提供 semantic layer，在其中 datasets 以业务用户能理解的方式被建模、治理和描述。有些 query engines 原生提供这一能力；另一些则与外部 semantic layers 集成，例如 dbt’s Semantic Layer，或 AtScale、Cube 等工具。你的 requirement 可以写成：“The query engine must expose a unified semantic model across federated sources” 或 “Semantic layer integration must support consistent metric definitions across Iceberg and Snowflake datasets.”

评估 federated query capabilities 时，performance 是另一个关键因素。Federation 只有在 queries 保持交互式，并且随着数据量增长可预测扩展时才有价值。对于 Iceberg tables，性能主要来自 metadata-driven query planning、file pruning 和 engine 的 vectorized execution。对于 non-Iceberg sources，性能通常取决于你能够多高效地跨系统边界移动和处理数据。

不要强制指定某项技术。相反，应围绕 outcomes 写 requirements：low-latency access、fast in-memory processing，以及 query execution 期间最小化 data movement。许多 engines 通过 columnar、vectorized execution models 和 Apache Arrow 等优化 data interchange protocols 实现这些目标。实践中，requirements 更适合写成：“Federated queries must support interactive performance across both Iceberg and external sources” 或 “The platform must minimize data movement and serialization overhead when querying non-Iceberg systems.”

此外，还要评估 engine 如何处理 query acceleration，尤其是在访问 remote 或 heterogeneous sources 时。它是否支持 result caching、materialized views 或 dynamic pruning？是否可以将 filters、joins 或 aggregations 下推到 source systems？一些平台提供 cross-source acceleration，即使单个 query 横跨 Iceberg 和 external systems，也能应用 optimizations。一个 requirement 可以写成：“Query acceleration must apply across federated sources without manual materialization.”

Federation strategy 还应包括 interfaces 和 application programming interfaces（APIs）。现代 query engine 应暴露标准 data access interfaces，使其可以与 BI tools、notebooks 和 applications 配合。这些包括 JDBC / ODBC drivers、用于 query execution 和 platform management 的 REST APIs，以及 Apache Arrow Flight 和 ADBC 等高性能访问新协议。你可以写：“The platform must support JDBC/ODBC, REST, and Arrow Flight protocols for all federated datasets.”

最后，考虑 automation 和 operational management 如何处理。Federation 会增加架构复杂性，因此平台应通过 intelligent resource scaling、automatic metadata synchronization 和 policy enforcement 帮助控制复杂度。这里的 requirements 可能包括：“Federated queries must be automatically optimized and routed based on data location and source performance” 和 “The platform must support autoscaling and monitoring of federated query workloads.”

这些 requirements 共同让你的 Iceberg lakehouse 能连接到更广泛的数据生态，同时不牺牲 performance、governance 或 user experience。Federation 不只是为了方便；它是为了构建一个统一分析平台，反映组织存储和使用数据的现实。清晰的 federation 和 integration requirements 也让团队能够在数据所在位置访问和分析数据，同时为未来 consolidation 和 simplification 奠定基础。

4.3.5 定义 Consumption Requirements

最后一类覆盖人们如何访问和使用数据，无论是通过 BI tools、interactive queries，还是 machine learning workflows。这些需求直接关系到 user experience 和 query performance。

你的审计应显示用户依赖哪些工具，以及他们今天如何使用数据。Dashboards 是否刷新缓慢？Analysts 是否依赖手工导出的 datasets 做建模？Access 是否在团队之间一致治理？

使用这些信息编写 consumption requirements，例如 “Users must be able to securely access data from local notebooks outside the corporate network” 或 “The lakehouse must support secure cross-region querying, including access to EU-stored datasets from US-based analysts.”

此外，考虑 interoperability。如果用户跨 Dremio、Trino 和 Snowflake 工作，你的平台必须确保跨 engines 的 semantic consistency。Requirements 应明确用户需要哪些 tooling 和 interfaces，而不只是他们当前正在使用的工具。

4.4 Hamerliva Bank 定义其 Requirements

在审计技术环境和 stakeholder priorities 后，Hamerliva Bank 进入下一步：将这些洞察转化为正式的 architectural requirements 列表。这些 requirements 不规定具体技术或工具，而是定义评估未来设计决策的标准，覆盖 Iceberg lakehouse 的五个核心组件：storage、ingestion、catalog、federation 和 consumption，见图 4.5。

图 4.5：Hamerliva Bank 制定其架构需求。

4.4.1 Storage Requirements

Hamerliva Bank 的审计发现，其 storage setup 高度碎片化。数据分散在 on-premises HDFS clusters、NAS systems 和多个 cloud warehouses 中。监管合规要求，特别是 EU 的 GDPR 和 US 的 SEC rules，意味着特定 datasets 必须按地理位置物理隔离。同时，跨区域和系统的 storage duplication 正在推高成本和复杂性。

为应对这些需求，Hamerliva Bank 定义了强调 compliance、consistency 和 compatibility 的 requirements：

“All regulated data collected in the EU must remain in regionally bound, on-premises storage.”
“Storage systems must expose S3-compatible APIs to ensure integration with all query engines and ingestion frameworks.”
“Cold data older than 60 days must be eligible for archival tiering, while remaining queryable through Iceberg metadata.”

这些 requirements 为比较 on-premises object storage vendors，以及判断 hybrid cloud deployments 是否可行且不损害监管合规状态，提供了清晰视角。

4.4.2 Ingestion Requirements

Hamerliva Bank 同时运行 batch 和 streaming data pipelines。审计发现，跨区域存在 operational silos 和不一致 tooling。Real-time ingestion 对 algorithmic trading teams 至关重要，而 compliance 和 financial reporting workloads 主要由 batch 驱动，对 latency 不太敏感。

为了同时满足这两类需求，他们制定了 dual-mode ingestion strategy，并配套有针对性的 requirements：

“Streaming ingestion must handle late-arriving events and ensure consistent record updates when the same logical entity is received multiple times, preserving deterministic results under concurrent and repeated writes.”
“Batch jobs must run nightly and be orchestrated through Apache Spark integrated with existing Airflow DAGs.”
“All ingestion pipelines must support schema evolution and emit lineage metadata for catalog registration.”

这些 requirements 突出了对灵活 ingestion tools 的需求，这些 tools 既能适应不断变化的 workloads，又能保持 data integrity 和 traceability。

4.4.3 Catalog Requirements

Metadata layer 分散在 Hive Metastore、spreadsheets 和 internal relational databases 中。Manual schema changes、limited versioning 和 inconsistent access control 是频繁痛点。

为了统一 metadata 并改善可管理性，Hamerliva Bank 定义了以下 requirements：

“The catalog must support the Iceberg REST Catalog specification to ensure compatibility across all query engines.”
“Versioned schema evolution must be enabled, with rollback support and user attribution for all changes.”
“Catalog must support RBAC for dataset-level permissions and integrate with corporate identity providers (e.g., Active Directory).”

使用这些标准，Hamerliva Bank 可以基于 functionality 和 governance compatibility，而不是 name recognition 或 legacy use，来缩小 catalog options 范围，例如 Polaris、Nessie 或 AWS Glue。

4.4.4 Federation Requirements

即使 Hamerliva Bank 开始整合 workloads，许多 datasets 仍然散布在多个系统中。团队经常不得不复制数据，或手动转换 exports，以连接不同 environments。

因此，他们的 federation requirements 强调 interoperability 和 unified access：

“Query engines must support federated access across Iceberg tables, S3 buckets, and on-premises HDFS without data duplication.”
“The platform must provide a common semantic layer to define reusable business logic across federated queries.”
“Federated queries must enforce row- and column-level access controls consistently across all sources.”

这让 Hamerliva Bank 能评估 Dremio 和 Trino 等 engines，不仅看它们是否能查询 Iceberg，也看它们能否将 Iceberg 与 legacy 和 operational data stores 一起查询，同时不削弱 governance。

4.4.5 Consumption Requirements

审计中发现的最大问题集中在 data consumption。Dashboards 存在 latency spikes，语义在不同工具之间变化。因此，analysts 经常构建 shadow pipelines 来绕过这些约束。Consumption requirements 重点放在为所有 data consumers 创建一致、高性能且受治理的体验。

关键 requirements 包括：

“Interactive dashboards must return query results within 5 seconds for typical analytical workloads.”
“Query engines must enforce row-level access policies defined in the catalog and aligned with enterprise roles.”
“The platform must provide standard programmatic and SQL-based access interfaces required by downstream tools, including support for columnar data exchange where the tools depend on it.”
“Data science users must be able to access and analyze Iceberg tables from Python-based workflows using tools and libraries commonly adopted within the organization.”

有了这些 requirements，Hamerliva Bank 看的就不只是某个工具能否简单查询 Iceberg。它还需要支持 analysts、business users 和 data scientists，并提供一致 semantics 和 security rules。

4.4.6 从 Requirements 到 Design

这些 requirements 共同构成了 Hamerliva Bank 架构设计流程的基础。它们没有回答所有开放问题，但为团队提供了清晰、可测试的标准，用于评估工具、做出取舍，并让决策始终与业务目标和 stakeholder expectations 对齐。更重要的是，它们建立了共享语言和方向，使 engineering、governance 和 analytics teams 可以一起推进。后续章节中，我们会逐一讲解 Iceberg lakehouse 的每个组件，并看看不同工具如何满足这些和其他 requirements。

4.5 架构计划与 Road Show

一旦你拥有完整 requirements，Iceberg implementation 的下一步就是 architectural planning。在这个阶段，你会做出关键决策，包括选择技术、定义 federation strategies，并勾勒 lakehouse 各组件如何协同以实现目标。

不过，architectural plan 不只是技术图。它讲述你的平台将如何演进、你做了哪些取舍，以及这些选择如何与 stakeholder priorities 对齐。要想成功，你需要清晰传达计划，并让将会构建它、运行它或受其影响的团队验证该计划。换句话说，implementation 始于 alignment，而不是基础设施变更。

你的 architectural plan 应覆盖全部五个 Iceberg lakehouse components，也就是 storage、ingestion、catalog、federation 和 consumption，并展示它们如何交互。目标是形成一个反映 audit findings、组织规模、compliance posture 和团队能力的 blueprint。

计划完成后，重要的是通过 stakeholder road show 广泛分享。向每个 stakeholder group 展示 proposed architecture，说明它如何解决他们的 pain points 和 goals，并收集反馈，在 implementation 开始前改进设计。这一步建立信任，发现 blind spots，并在每个 department 中培养 champions，使 adoption 更顺滑、合作更容易维持。我们来看 Hamerliva Bank 如何执行这一阶段。

4.5.1 Hamerliva Bank 创建架构计划

拿到 requirements 后，Hamerliva Bank 进入 architectural planning phase。这不是 data team 单独完成的工作，而是由 platform engineers、data architects、compliance officers 和 analytics leaders 组成的 cross-functional group 协调推进。团队共同塑造了一份技术上可行、满足监管需求，并适合真实使用模式的计划。

该 group 的 mandate 是设计一个 production-grade Iceberg lakehouse architecture，既满足公司的 immediate needs，又保留演进空间。他们的目标是构建一个 modern、maintainable 的系统，能够简化 data operations，尊重 governance constraints，并让全公司 analytics 更 responsive。

他们没有匆忙进入 tool selection，而是重新审视 Iceberg lakehouse 的五个核心组件，并将 requirements 映射到 architectural patterns 和 technologies。每个决策都对照 cost、control、performance 和 integration complexity 的 tradeoffs 来权衡。

Storage

Hamerliva Bank 选择 hybrid storage model 作为 lakehouse 的骨干。Amazon S3 被指定为 analytics workloads 的 primary object store，尤其适用于受益于 elasticity、scalability 和 proximity to cloud-native compute 的数据。为了满足 data residency 和监管要求，特别是 GDPR 和 SEC Rule 17a-4，他们在欧洲和美国数据中心部署了 on-premises MinIO clusters。这些 MinIO instances 提供 S3-compatible object storage，同时带来 local control、air-gapped environments 和 encrypted storage at rest 等优势。

Ingestion

对于 data movement 和 preparation，Hamerliva Bank 采用了 dual-mode ingestion strategy，使其与现有基础设施和多样数据源对齐。Apache Spark 被保留用于 batch-oriented workflows，并通过 Apache Airflow 编排，以处理 structured reporting data、compliance logs 和 historical trade records。

对于 near-real-time ingestion，引入 Apache Flink 和 Kafka Connect，用于处理 market tick data 和 order events 等 high-frequency streams。这些 pipelines 会持续将新 records 写入 Iceberg tables，使下游系统能够以 minimal latency 查询新鲜数据。Update 和 correction workflows 通过受控 batch processes 处理，确保 data consistency，同时避免依赖难以跨 engines 保证的 streaming-side delete semantics。

这种方法通过将 streaming ingestion 用于 high-throughput、append-heavy workloads，同时把更复杂的 update 和 reconciliation logic 保留给 batch jobs，在 simplicity 和 correctness 之间取得平衡。在 batch 中，validation、auditing 和 recovery 更容易管理。

集成 APIs、SaaS platforms 和 operational databases 很复杂，因此 Hamerliva Bank 添加了一个 connector-based tool 来简化新 sources 的 onboarding。团队评估了 Fivetran、Airbyte 和 Qlik 等工具，以自动化从常用 applications 摄入数据，从而让 data engineers 和 domain teams 的工作更轻松。这种 layered approach 让银行可以渐进现代化，同时保持日常 operations 运行。

Catalog

团队选择 Apache Polaris 作为 central metadata 和 catalog service。Polaris 支持 Iceberg REST Catalog specification，这是满足 engine interoperability 和 API-based table management 的关键 requirement。它还提供 native RBAC，并可与 Hamerliva Bank 现有 identity provider 集成。由于 Polaris 同时适用于 on-premises 和 cloud environments，团队可以在一个地方查看和管理所有 datasets，无论它们位于哪里。Time travel 和 atomic commit log 进一步增强了平台 reliability 和 traceability。

Federation

对于 federated queries 和 cross-system federations，Hamerliva Bank 将 Dremio 标准化为主要 query engine。凭借 Iceberg-native acceleration、semantic layer modeling 和基于 Apache Arrow 的 execution，Dremio 同时支持 high-performance analytics 和 user-friendly exploration。它可以跨 S3、HDFS 和 relational systems 做 federated queries，帮助银行最小化 data duplication，并支持横跨多个 data domains 的 analytical use cases。它还提供 REST APIs 和 Arrow Flight endpoints，以满足 application developers 和 data scientists 的 federation requirements。

Consumption

对于业务用户，Tableau 通过标准 ODBC connectors 与 Dremio 集成。这个 setup 支持 governed self-service BI，并为 ad hoc reporting 和 executive dashboards 提供低延迟响应。Dremio 作为这些 workloads 的 primary query engine，将相同 semantic definitions 和 access controls 应用到所有 dashboards。

对于 data scientists，Hamerliva Bank 通过 dedicated analytical engines 和 Python-based workflows 提供对 Iceberg tables 的访问，而不是允许直接 table-level manipulation。Curated Iceberg datasets 通过针对 interactive 和 batch analytics 优化的 query engines 暴露。这样，notebook users 可以探索数据、构建特征和训练 machine learning models，而无需 custom ETL extracts。常见 use cases 包括 customer segmentation 和 fraud detection pipelines，它们需要及时、一致地访问 transaction-level data。

在所有 consumption paths 中，Dremio 的 semantic layer 保持 definitions 一致，而 Polaris 在 query time 执行 access controls。因此，BI、analytics 和 data science workloads 都运行在共享、受治理的数据视图之上，而不把用户耦合到单一 access method 或 execution engine。

审查最终计划

完成这些 component-level decisions 后，该 group 组装了一份综合 architecture guide。这份文档不只是技术规格，还包括：

End-to-end data-flow diagrams 和 system topologies
跨 S3 和 MinIO 的 storage tiering strategies
标明 regulatory classifications 的 catalog-registered datasets map
展示 ingestion pipelines 如何连接到 analytical outputs 的 lineage mappings
Staged migration plan，基于 access frequency、sensitivity 和 transformation complexity 确定 datasets 优先级
Fallback procedures，包括处理 catalog 或 engine outages 的选项
Change-management plan，用于废弃 legacy ETL jobs 并让用户 onboarding 到新工具

Hamerliva Bank 将该计划作为 proposal，而不是最终 directive，并明确表示它开放 review 和 revision。这向 stakeholders 传达了一个信号：他们的反馈很重要，rollout 会通过持续协作来塑造。Architecture guide 使用清晰语言，并为技术和非技术受众提供 annotations 和 visuals，为后续 stakeholder road show 做准备。

这份计划总结在图 4.6 中，作为 reference architecture，将 technical components 连接到 user-facing outcomes。PyIceberg，也就是原生 Iceberg Python library，很重要，因为它让 notebooks 和 machine learning pipelines 可以直接使用 Python 读写 Iceberg tables。这意味着 data scientists 可以探索 features、构建 datasets 和训练 models，而无需额外 ETL steps。将 AI agents 纳入设计，则指向一些新兴 use cases，例如 automated anomaly detection 和 real-time recommendation engines，它们依赖对 curated datasets 的快速、受治理访问。与 stakeholders 分享设计，帮助团队验证 assumptions、建立 alignment，并改进 implementation plan。投入 cross-functional planning 的时间，确保 lakehouse 架构良好，并在整个组织中获得支持。

图 4.6：Hamerliva Bank architectural proposal 展示了各组件之间的关系。

4.5.2 Hamerliva Bank 开展 Road Show

有了扎实的 architectural plan 后，Hamerliva Bank 将重点转向平台现代化中最关键、也最容易被忽视的阶段之一：road show。这个阶段不只是技术设计 walkthrough；它是为了确保 alignment、建立 trust，并在 implementation 开始前确保每个 stakeholder group 都有发声机会。

Road show 被组织为一系列有针对性、面向特定角色的 briefings。每一场 session 都根据受众的兴趣和职责定制，强化一个信息：这是协作努力，而不是自上而下的 directive。Sessions 面向 data engineers、business analysts、data scientists、compliance officers、IT operations teams 和 executive stakeholders 安排。目标是保持透明、发现意外顾虑，并为新平台培养早期 champions。

每场 briefing 都从重申 context 开始：审计中发现的 goals、requirements gathering 中识别出的 constraints，以及迁移到 Apache Iceberg 的更广泛业务动机。随后，presenters 会讲解 architectural plan 中与该受众相关的部分。例如：

在与 compliance 和 risk management 的 sessions 中，团队回顾了 GDPR 和 SEC Rule 17a-4 obligations。然后展示了 hybrid storage architecture 如何通过支持 regional data residency 的 MinIO clusters，以及 Polaris 的 RBAC 支持，维持并在很多情况下改善 regulatory alignment。

在与 data engineering teams 的 meetings 中，重点转向 ingestion strategy。Diagrams 展示了 existing Spark pipelines 如何被保留、Flink 如何被引入以支持 real-time use cases，以及 NiFi 和 Informatica 等工具如何通过 staged migration plan 被逐步淘汰。Engineers 被要求验证关于 pipeline dependencies 和 job handoffs 的 assumptions。

对于 business analysts 和 data scientists，sessions 聚焦于改善 data discoverability、freshness 和 accessibility。团队演示了 Dremio 的 semantic layer 如何跨工具标准化 metric definitions，Iceberg 的 hidden partitioning 如何改善 dashboard performance，以及 data scientists 如何获得 Arrow Flight 访问能力，用于 programmatic workflows。

在每场 session 中，architecture guide 都是共享 anchor。它不是静态文档，而是 living reference。与会者被鼓励在讨论中 annotate、critique 和 explore 这份 guide。Facilitators 也会询问，拟议 changes 是否与实际 workflows 对齐，以及哪里仍存在 operational friction。

这些讨论带来了几项有意义的改进：

Analytics team 希望尽早访问 S3 中的 curated datasets，以加快 prototype development。这导致 migration phases 被重新排序，把使用最多的 dashboards 提前到 rollout schedule 前面。

Compliance officers 要求对 metadata audits 进行更严格控制。因此，architecture team 为 Polaris 添加了 log export 和 monitoring capabilities，并规划了与内部 Security Information and Event Management（SIEM）systems 的 audit-trail integrations。

IT operations 对管理 hybrid storage costs 表达担忧。Architecture guide 因此更新，加入 tiered storage strategies，以及 capacity alerts 和 automated lifecycle policies 的 operational SLAs。

这些 sessions 改善了计划，也培养了 buy-in。Stakeholders 看到他们的输入被认真对待，因此开始对计划成功产生责任感。在几个团队中，参与者自愿成为 transition liaisons，也就是会持续参与 implementation process、帮助 onboarding 他人，并在 rollout 期间 troubleshoot cross-functional concerns 的同事。

Road show 结束时，Hamerliva Bank 完成的不只是一场多团队 presentation：他们建立了 cross-functional alignment。每个 department 都理解变化的理由、即将发生的范围，以及自己在执行转型中的角色。更重要的是，他们能看到 proposed lakehouse 将如何直接改善他们的工作。

后续章节中，我们会详细考察 Iceberg lakehouse 的五个组件。我们会探索 tradeoffs、design patterns 和 tool options，帮助你为自己的组织做出最佳选择，从基础开始：storage。

小结

迁移到基于 Apache Iceberg 的 lakehouse，需要基于组织真实需求做出战略决策。

对当前数据架构进行结构化审计，将这些洞察转化为 actionable requirements，并构建与 stakeholders 对齐的 architecture plan。

让跨角色和职能的 stakeholders 参与进来，以发现技术和组织需求。

记录并分类当前 tooling、storage systems 和 governance practices。

在推进 implementation 之前，必须在所有 departments 之间建立 consensus 和 clarity。

Road show 流程会创造共享理解和反馈循环，可以将 proposed architecture 转变为 cross-functional initiative，减少摩擦，并培育长期支持。