构建 Apache Iceberg 湖仓架构——选择存储层

本章内容包括：

• 存储性能、安全性和完整性需求
• Block storage 和 object storage 架构
• Parquet 和 S3 API 作为基础标准
• HDFS、MinIO 和 Everpure 等存储方案

Storage layer 是任何 Apache Iceberg lakehouse 的基础。虽然 ingestion、cataloging 和 querying 工具常常因为能直接影响用户体验而受到更多关注，但 storage layer 最终决定了平台的可靠性、可扩展性和成本效率。如果选错，你会遇到 performance bottlenecks、security gaps 和 operational complexity；如果选对，你会获得灵活性、更低成本和面向未来的 integrations。

基于审计中发现的 requirements，本章会帮助你塑造 storage strategy。我们会重新审视关键需求：performance、security、integrity 和 cost。然后，我们会看两种主要 lakehouse storage approaches：block storage 和 object storage，以及它们在结构、访问模式和对 Iceberg workloads 的适配性上有何不同。

接下来，我们会探索支撑大多数存储方案的两个技术标准：Parquet file format 和 S3 API。Parquet 的 columnar structure 非常适合 Iceberg 面向分析的 workloads。S3 API 已经成为 object storage 的通用语言，提供广泛兼容性和部署灵活性。

最后，我们会比较 on-premises infrastructure 和 cloud deployments 的存储选项。这些包括 Hadoop 的 HDFS 等 legacy systems、MinIO 和 Ceph 等现代 object stores，以及 NetApp StorageGRID 和 Everpure 等 enterprise-focused platforms。对于每个方案，我们都会强调其历史、设计哲学，以及它最适合的环境类型。

本章结束时，你将能够评估哪些 storage technologies 最适合你的 lakehouse needs，并在技术约束和业务优先级之间取得平衡，做出持久且具有战略性的选择。

5.1 存储需求

在为 Apache Iceberg lakehouse 选择 storage solution 之前，要先澄清你需要 storage layer 交付什么。需求会因组织而异，错误匹配可能引入低效，削弱整体架构。因此，不要从最喜欢的技术或 vendor list 开始，而要从目标开始。请记住，Iceberg 几乎可以运行在任何 storage system 之上，所以真正的问题是：哪一个选项最适合你的需求？

第 4 章中的 audit process 为这次讨论奠定了基础。在与 engineering、analytics、security 和 operations 中的 stakeholders 交流后，你应该已经理解数据如何被使用、痛点在哪里，以及必须尊重哪些约束。将这些洞察转化为 storage layer 的具体 requirements，覆盖 performance、security、data integrity、cost 和 day-to-day complexity。

本节将聚焦影响 storage decisions 的最常见 requirement categories：

Performance——Query engines 能多快检索和扫描 files。

Security——通过 access controls 和 encryption 保护敏感数据。

Integrity——确保系统能从硬件故障或人为错误中恢复。

Operational and cost considerations——处理管理 storage 的日常现实，包括 scalability、cloud costs 和 ease of maintenance。

清晰定义这些维度，你就可以评估本章后续会覆盖的 storage options——不是基于它们的 marketing claims，而是基于它们是否适合你的组织需求。

5.1.1 File Retrieval 的 Performance Requirements

每个 lakehouse workload 归根结底都落到 file access，包括读和写。无论你是在运行 dashboard queries、摄入新 datasets、训练 machine learning model，还是做 exploratory analysis，高效的 file access 都会直接影响 user experience、system throughput 和 infrastructure cost。对于 Apache Iceberg 而言，performance 不只取决于 query engine 和 metadata optimization，也取决于 files 如何从 storage 中被检索，以及如何写入 storage。

File retrieval 和 write latency 取决于 data layout、network throughput 和 caching behavior。在大多数 lakehouse deployments 中，raw storage latency 已经不再是 performance 的主要决定因素。对于 low-latency access，query engines 通常会使用 in-memory execution、local caching 和 adaptive buffering，而不是每次 request 都直接从 durable storage 读取。

因此，选择 storage layer 时，应主要考虑 durability、scalability 和 cost。Performance-sensitive workloads 则通过 engine-level caches 和 execution strategies 处理。这就是为什么只要 engine 将 remote reads 降到最低，object storage 即使面对 interactive analytics 也足够。Storage performance 对 large scans 和 ingestion workloads 仍然重要，但在架构良好的 lakehouse 中，它很少是瓶颈。

Concurrency 也很重要。Storage systems 必须支持多个 compute engines、users 和 pipelines 同时访问。随着 Iceberg adoption 增长，file operations 可能在高峰时段或 reporting cycles 中激增，并压垮无法高效处理请求的系统。在高负载下限制 throughput 或导致 read contention 的方案，可能成为 performance bottlenecks。

另一个关键因素是 access patterns：典型 workloads 中数据如何被读取或写入。例如，许多 analytical queries 会跨 columnar files 做大型 sequential reads，而 ingestion jobs 可能涉及频繁 appends 和 compactions。一个针对 sequential reads 优化的 storage system，可能在 concurrent random writes 场景中吃力。选择和配置 storage layer 时，要牢记这些模式。

Data files 的结构和分布也会影响 retrieval efficiency。Iceberg 通常管理大量 Parquet files，并依赖 predicate pushdown、file pruning 和 column-level statistics 等优化，以最小化必须读取的数据量。这些优化在底层 storage 能够稳定、可预测地提供 files 时效果最好。

Compression 也扮演重要角色。高效的 columnar compression 会减少从 storage 读取的数据量，并改善 query execution 期间的 cache usage。结合 Iceberg 的 metadata-driven planning，它让 engines 扫描更少 bytes、更快解码数据，并在规模化下保持性能稳定。但如果 storage performance 波动很大或调优较差，pruning 和 compression 的收益会降低，Iceberg 的 query-planning 优势也会不那么有效。

为了评估真实世界 performance，团队应该超越 advertised throughput。Benchmark 典型 access patterns、测量 tail latency，并 stress-test concurrency，从而选择适合 workload 的 storage。图 5.1 强调了分析 storage performance 时需要考虑的关键因素。

图 5.1：理解 storage layer performance 时需要考虑的因素

5.1.2 Security Requirements

Security 是为 Iceberg lakehouse 选择 storage layer 时的关键因素。即使 catalog 或 query engine 提供 fine-grained access controls 和 governance，这些控制仍然依赖底层 storage system 的完整性。一个薄弱或配置错误的 storage layer，可能让敏感数据暴露风险，即便上层控制已经存在。

至少，storage solution 应支持 fine-grained access control。这包括根据 user、role 或 service identity 限制 read 和 write permissions 的能力。对于 object storage systems，这通常意味着支持 bucket-level 和 prefix-level permissions，并通过 identity and access management policies 执行。对于 block storage，访问通常通过 filesystem permissions 或 host-level isolation 进行治理。

Encryption 是 secure storage 的核心部分。许多 storage vendors 提供 server-side encryption，使 data at rest 自动加密。一些还支持 bring-your-own-key（BYOK）或 key management system（KMS）integration，让你对 encryption lifecycle 和 compliance alignment 拥有更多控制。在受监管行业中，这种能力通常是强制要求。受 data residency laws、financial compliance standards 或 healthcare regulations 约束的组织，必须确保数据在 storage 和 retrieval 的每个阶段都被加密且可审计。

Auditability 越来越成为一项需求。Storage systems 应支持记录 access attempts、modifications 和 deletions，并具备足够粒度，以检测异常行为或响应 incidents。应根据组织政策或法律要求保存这些 logs，用于 forensic investigations。

最后，storage location 很重要。Public cloud services 可能默认将数据存储在多个 regions，这可能带来 compliance challenges。On-premises solutions 让你拥有更多控制，但可能缺少 disaster recovery 所需的 geographic redundancy。确保你的 storage system 可以配置为满足 jurisdictional requirements，尤其是全球化企业。

Security 不能成为事后补充。评估 storage options 时，要考虑它们与组织 identity systems、key management infrastructure 和 compliance processes 的集成程度。在 lakehouse 中，storage layer 是 foundational trust boundary，因此其设计应反映这一责任，并聚焦图 5.2 所示领域。

图 5.2：分析 storage layer security 时需要考虑的因素

5.1.3 Integrity Requirements

Storage layer 中的 data integrity 意味着在数据整个生命周期中保持其准确、完整和可恢复。对于构建在 Apache Iceberg 上的 lakehouse architectures 而言，大量关键分析数据被管理在 distributed filesystems 中，因此保护这些数据既是技术必要条件，也是业务硬要求。

在最基础层面，integrity 始于 durability。Storage system 必须可靠保留数据，即使面对硬件故障、网络中断或意外关机，也不能出现 corruption 或 loss。Object storage platforms 通常通过跨 nodes 或 regions 复制数据来提供内置 redundancy，这也是 vendors 经常宣传 eleven nines（99.999999999%）可靠性的原因。Block storage systems，尤其是在 on-premises setups 中，可能需要额外配置或工具，才能达到三到四个 nines。这些差异很重要。一个以 five nines availability 为目标的平台，会做出不同于以 three nines 为目标的平台的 storage choices。评估 durability 和 integrity guarantees 时，理解每个系统在 replication、consistency 和 recovery 方面的方法至关重要。

Backups 和 disaster recovery 也是 integrity planning 的核心。在 distributed environments 中，file deletions、schema changes 或 software bugs 可能迅速影响大量数据。稳健的 storage system 应支持 versioning 或 point-in-time snapshots，使团队可以恢复到之前状态。但使用 Iceberg 时，仅有 storage-level snapshots 并不够。Iceberg 需要 metadata 和 data files 紧密协调，才能保持 ACID guarantees。如果你回滚 data files，却没有同时恢复对应 table metadata，例如 manifests、snapshots 或 metadata.json files，table 可能变得不一致或不可读。这就是为什么 Iceberg disaster recovery 必须同时考虑两层：object storage 中的 physical files，以及 catalog 中跟踪的 transactional metadata。我们会在第 10、11 章和附录 A 中更深入覆盖这一点。但在 ingestion layer，要把 Iceberg tables 看作 composite objects，其完整性取决于 synchronized metadata and data recovery。

Checksumming 和 validation mechanisms 会进一步增强 integrity。那些在 read 和 write operations 期间自动验证 data blocks 或 objects 的系统，可以早期检测 corruption，降低 silent errors 扩散到下游 pipelines 的风险。

High availability 通过在单个组件失败时保持 storage 可访问，补充 data integrity。在 lakehouse environment 中，多个 services 和 users 依赖持续 data access，downtime 可能中断从 ingestion 到 analytics 的关键工作。高可用 storage system 会通过硬件和软件 redundancy，最小化 single points of failure。这可能包括跨 availability zones 的 active-active replication、network paths 的 failover mechanisms，以及 load-balanced access endpoints。Object stores 通常支持 geographic distribution，使 localized outages 期间仍能继续 reads 和 writes。将 high availability 纳入 storage strategy，有助于确保数据保持完整和可访问，并支持 continuous operation 与 platform resilience。

在 lakehouse architecture 中，数据始终处于运动中。如果没有 storage-level integrity guarantees，silent failures、data loss 或 inconsistent reads 的风险会上升。成熟的 storage layer 必须保护数据，使其在压力下仍然 observable、recoverable 和 trustworthy。请牢记图 5.3 中展示的因素。

图 5.3：评估 storage system 时需要考虑的 integrity 因素

5.1.4 Cost 和 Operational Overhead Requirements

任何 storage decision 都不能脱离 cost 和 operational burden。Performance、security 和 integrity 都很重要，但它们必须与维持 storage layer 所需的财务和人力资源一起权衡。

先从 total cost of ownership 看起。它不只是 storage capacity：data transfer、replication、access patterns 和 long-term archival strategies 都必须考虑。Cloud-based object storage 起初往往看起来便宜，但 frequent access、cross-region replication，以及 services 或 availability zones 之间的数据移动，都会让成本累积起来。

On-premises storage 并不会消除这些成本；它只是改变了成本发生的方式。即使不会按 request 收费，跨站点移动数据仍然会在 network infrastructure、bandwidth provisioning 和 operational overhead 上产生真实成本。同样，access costs 会折算进 hardware、power、cooling 和 staffing 中，而不是逐项列在账单上。On-premises systems 可以让支出更可预测，但通常需要更高前期 capital costs 和持续 maintenance，因此应与 cloud-based alternatives 仔细比较。

Operational overhead 是管理、扩展、监控和排查 storage environment 所需的努力。需要持续调优、手工扩展或深厚 vendor-specific expertise 的系统，会限制敏捷性，并拖慢平台演进。具有强 automation、observability tools 和 self-service capabilities 的方案，能帮助 platform teams 在不显著增加 headcount 的情况下维持 performance 和 compliance。

Interoperability 也会影响 operational costs。支持标准 APIs 和 protocols 的 storage systems，更容易连接 ingestion tools、processing engines 和 query services。依赖 proprietary interfaces 的系统，可能需要 custom integrations，引入 lock-in，或随着架构演进限制灵活性。

最后，要考虑成本和人力上的 scalability。系统是否能在不大幅重构的情况下处理数据量或用户需求快速增长？当需要扩展时，它是可预测、可管理的，还是需要复杂 provisioning 和 downtime？这些问题在 seasonal workloads、real-time analytics 或 frequent schema changes 中尤其重要。务必权衡图 5.4 所示的成本因素。

图 5.4：估算 storage system cost 时需要考虑的因素

选择 storage layer 是长期承诺。它的成本和运维要求不仅影响预算，也影响团队能把多少时间花在构建新东西上，而不是不断救火。尽早澄清这些 requirements，可以帮助你选择符合 financial model 和 operating style 的方案，而不只是满足技术 checklist。

5.2 Block vs. Object Storage

一旦定义了 storage requirements，下一步是选择支持这些需求的架构。在 data lakehouse 中，几乎所有 storage options 都属于两类之一：block storage 或 object storage。二者都可以与 Apache Iceberg 协作，但组织和服务数据的方式不同，在 performance、scalability、cost 和 operational complexity 上有不同取舍。

Block storage 运行在较低抽象层。它将数据拆分成固定大小的 chunks，由 operating system 管理。它提供 high throughput 和 low latency，因此非常适合 high-performance computing，以及 Hadoop 等传统数据处理 frameworks。Block storage 通常与 compute resources colocated，因此 storage 和 compute 一起扩展。这可以改善性能，但也可能提高成本，并使 failure recovery 更复杂。独立扩展 storage 或从 node-level failures 中恢复，通常需要手工干预。Block storage 还依赖外部系统来管理 file structures、permissions 和 availability，这会增加整体复杂性和 operational overhead。

Object storage 则将 files 抽象为离散 objects，每个 object 都带有 metadata 和唯一 identifier。这个模型优先考虑 scalability、durability 和 accessibility，并且通常使用 HTTP-based APIs，例如 S3 API。一个关键优势是它将 compute 与 storage 分离，因此你可以独立扩展二者。这种 decoupling 可以降低 infrastructure costs，并更容易支持多种 workloads。因此，object storage 已经成为现代 data lakehouses 的主流方式，因为它非常适合 cloud-native services，能减少 operational burden，并与 Parquet 等分析文件格式集成良好。

本节中，我们会看看每个模型如何工作，它们在哪些方面表现出色，以及在 Iceberg lakehouse 中有哪些短板。这些差异可以解释为什么某个 storage option 更适合你的 workloads、deployment models 或 regulatory needs。

5.2.1 Block Storage

Block storage 是企业持久化数据最古老也最常见的方式之一。它将数据切分成均匀大小的 chunks，也就是 blocks，如图 5.5 所示。Operating system 会定位并管理每个 block，而 filesystem 会将它们拼接成 applications 使用的 files 和 directories。

图 5.5：在 block storage system 中，单个文件被存储在多个 blocks 中。

这种架构与 Hadoop Distributed File System（HDFS）等 distributed filesystems 配合良好，在 HDFS 中，block storage 是基础层。它会将数据 striping 到多台 machines 上，以实现 redundancy 和 parallel access。这种设计在早期 big data 时代发挥了重要作用，能够在 commodity hardware 上为大型 files 提供 high-throughput access。Hadoop 对 block storage 的依赖，让组织可以精细控制 replication factors、fault tolerance 和 storage locality，从而帮助 compute jobs 以可预测性能运行。早期版本的 Apache Iceberg 是为了解决 Hadoop 和 Hive 的限制而构建的。这也是为什么 Iceberg 的 file storage catalog 最初被称为 “Hadoop Catalog”。它是为 Hadoop 而构建的，尽管它可以与任何 storage system 协作。

Block storage 在新的 lakehouse deployments 中已经不那么常见，但在 legacy Hadoop environments 和 high-performance private cloud installations 中仍然相关。许多 on-premises platforms 仍依赖 self-managed disks 和 HDFS 等 distributed filesystems，其中 block storage 是基础。这些 setups 可以支持 Apache Iceberg，因此团队可以在不全面重构基础设施的情况下，现代化 table formats。取舍是 operational overhead。Block storage 缺少与 cloud-native services 的原生集成，需要单独系统处理 replication 和 access control，并且需要更多工作才能保持可靠和可扩展。对于拥有 legacy systems 的组织，在现有 block storage 之上加入 Iceberg 可以是一种 practical transition，但你会错过 cloud-based object storage 通常提供的一些 elasticity、automation 和 cost efficiency。

Storage Systems 中的 Replication 和 Fault Tolerance

在 storage systems 中，replication factor 是系统为每份数据保留的副本数量。这些副本存储在不同 servers、disks，甚至 data centers 上。例如，replication factor 为 3 意味着系统为每个 data block 存储三个副本。HDFS、object stores 和 cloud-native filesystems 等 distributed storage architectures 使用 replication 来保持数据可用和 resilient。

Fault tolerance 是系统在部分组件失败时仍能继续运行的能力。通过在不同 machines 或 locations 上保存多个数据副本，系统可以承受 disk failures、server crashes，甚至 data center outages，而不丢失数据或访问能力。如果一个 replica 因硬件或网络问题不可用，系统可以自动从另一个副本提供数据，通常不会出现用户可感知的 downtime 或影响。

Replication 和 fault tolerance 让 storage systems 保持 reliable、available 和 durable。如果没有它们，一块坏盘或一台服务器崩溃就可能导致永久数据丢失或服务中断。更多 replicas 意味着更好保护，但也会使用更多 storage 和 resources，因此系统设计者在设置 replication policies 时，需要平衡 cost、performance 和 acceptable risk。

Block storage 可以直接挂载到 compute nodes。当你让 Apache Spark 等 engines 靠近 storage layer 运行时，它们可以以低 latency 和低 overhead 读写。这种 setup 通常会加速 latency-sensitive 或 compute-heavy workloads。最大收益来自那些需要高且稳定 input/output operations per second（IOPS）的 workloads，也就是 storage system 每秒可完成的 reads 或 writes 数量。Consistent IOPS 对需要可预测性能的 applications 很重要，例如大规模 ETL jobs 或 real-time analytics。

但 block storage 也有取舍——它 infrastructure heavy。设置和维护 block-based storage systems 意味着要配置 volume managers、调优 block sizes、维护 redundant arrays of independent disks（RAID），并部署 monitoring 和 alerting systems 来检测 failures。Block size 可能决定性能成败：较小 blocks 可以改善 random access patterns，但会增加 metadata overhead；较大 blocks 可以提升 sequential throughput，但会在 sparse 或 mixed workloads 中浪费空间。实践中，随着 workloads 变化，选择合适 block size 会变成另一个持续任务。

此外，block storage 不原生支持 metadata-rich access 或 HTTP-based protocols，因此不太适合现代数据平台常见的 loosely coupled、cloud-native architectures。

Scalability 也可能成为挑战。扩展 block storage system 可能涉及添加新 disks、重新分布数据，并在紧耦合的 node network 中协调变更。Object storage 可以通过更少的手工工作实现弹性扩展。随着数据量增长或 workloads 变化，block storage 通常会增加 operational constraints。

5.2.2 Object Storage

Object storage 现在是现代 lakehouse architectures 的首选模型，尤其是在 cloud-native environments 中。不同于在基础设施层运行的 block storage，object storage 会将数据抽象为称为 objects 的自包含单元。每个 object 包含 data、metadata 和唯一 identifier，如图 5.6 所示。你可以通过标准 APIs 直接访问 objects，最常见的是 S3 protocol。

图 5.6：Files 被存储为 blobs（binary large objects），并与保存 metadata 和用于访问它们的 ID 的 object 放在一起。用户通过 key 请求文件，系统使用 metadata 定位并检索它。

Object 的 Metadata 和 ID

从用户角度看，object storage systems 提供的是 flat namespace：每个 object 通过唯一 key 或 full path 访问，类似 URL。不同于带嵌套目录的传统 filesystems，object stores 不依赖 directory hierarchy。这让它们易于扩展，并避免与 directory depth 相关的限制，从而适合拥有数百万或数十亿 files 的大规模环境。

每个 object 都与 metadata 一起存储，并通过唯一 ID 跟踪。细节因 vendor 而异，但你通常通过 key 与 object 交互。Keys 可以被格式化为类似 directory paths，例如 logs/2024/01/file.parquet。Object metadata 包含 timestamps、size 和 access permissions 等细节，也可以包含可选 user-defined tags。这个 metadata 支持 search、lifecycle rules 和 access control 等功能，而无需修改 object 内容。

由于数据分布在多个 storage nodes 上，无论 object 位于哪里，你都能获得 high availability 和无缝访问。Object stores 通常开箱即带 versioning、replication 和 policy-based management，因此你不必自己管理这些细节。这让 object storage 非常适合 data lakehouses，因为它们需要 performance、scale 和 metadata-rich access，来处理大量分析数据。

现代 object stores 使用 distributed architectures，会自动 partition data，也就是 autosharding，并提供 load balancing、fault tolerance 和 high availability。它们横向扩展，并跨多个 servers 或 geographic regions 复制数据，以满足严格 durability guarantees，通常被称为 eleven nines（99.999999999%）durability。除了基础存储之外，object stores 还包括一系列 enterprise-grade features。Lifecycle policies 可以自动在 storage tiers 之间移动数据，或在固定时间后删除数据。内置 auditing 和 logging 会记录每次 access 和 change，支持 security monitoring 和 compliance。Server-side encryption 确保 data at rest 被加密，而不需要更改 client applications。

对于 access control，object stores 使用 identity and access management（IAM）。IAM 允许 administrators 指定谁可以对特定 resources 执行特定 actions，例如读取或写入数据。IAM policies 可以将 permissions 授予 roles、groups 或 service identities，从而提供 fine-grained access control。这些功能结合起来，在简化运维的同时，也增强了平台 security 和 regulatory posture。

Object storage 也符合 lakehouse deployments 的财务和运维需求。Amazon S3、Google Cloud Storage 和 Azure Blob Storage 等 cloud services 通常使用 usage-based pricing：按每 GB 存储量和每次 request 收费。用户不需要管理物理 disks，也不需要提前 overprovision storage。MinIO 和 Ceph 等 on-premises options 提供类似 pricing，同时让你对 deployment 和 data residency 拥有更多控制。

Apache Iceberg 原生支持 object storage，因此你可以利用其 scalability 和 API-driven access。但它的 latency characteristics 与 block storage 不同。Throughput 可以保持较高，但 access times 可能更不稳定，尤其是读取大量 small files 或执行大量 object listings 时。例如，S3 在高负载下通常表现出每个 request 100–200 毫秒的 latency，这在 low-latency scenarios 中可能会明显可感。如果你在设计 ingestion pipelines 或 interactive queries，并且需要 sub-second responses，就要为这部分额外 delay 做规划。

另一个考虑因素是 eventual consistency。有些 object stores 在 directory listings 或跨 regions 中，可能会延迟新对象或更新对象的可见性。Iceberg 的 commit protocol 和 metadata handling 可以帮助你规避许多这类挑战，但你仍然需要理解所用 store 的 consistency model，以设计 reliable、fault-tolerant pipelines。

即便存在这些取舍，object storage 仍然是大多数 Apache Iceberg lakehouse deployments 的默认选择。它的 elasticity、managed service model 和广泛兼容性，使它非常适合现代数据架构，从 batch analytics 到 real-time machine learning pipelines 都适用，并且可以达到 enterprise scale。

5.3 Storage Layer Standards

选择 block storage 还是 object storage，会影响数据如何存储和访问。叠加在这些系统之上的 standards，则会塑造 interoperability、performance 和 long-term sustainability。在 Iceberg 中，storage layer 主要由两个标准主导：Parquet file format 和 S3 API。无论你如何设计架构，几乎一定会同时使用二者，如图 5.7 所示。

图 5.7：执行 Iceberg transaction 的 engine 使用 S3 API 与 object storage platform 通信，并在其中将数据存储为 Parquet files，同时保存 Iceberg metadata。

这些 standards 并不是偶然的。它们是生态系统多年围绕实践需求逐渐收敛的结果：高效分析存储和广泛兼容性。由于它们被广泛采用，tools、platforms 和 teams 可以跨组织和技术栈协作。对于旨在跨 engines 和 clouds 统一数据访问的 Iceberg 来说，这些 standards 不只是方便，而是必要条件。

接下来更仔细地看这两项技术。首先看 Apache Parquet，也就是 Iceberg tables 最常用的 file format，并看看它的设计如何支持快速、可扩展的 analytics。然后介绍 S3 API，它最初由 Amazon 开发，如今几乎被所有主要 object storage solutions 接受。理解这些 standards，可以更容易判断哪些 storage systems 最适合 Iceberg，以及评估支持能力时该检查什么。

5.3.1 Apache Parquet

在 Iceberg lakehouses 中，Parquet 不只是一种 file format；它支撑着架构的 performance、flexibility 和 openness。结合 Iceberg 的 metadata model 和 query planning，它是大多数生产部署的默认选择。

Apache Parquet 是现代 analytics systems 中广泛使用的 columnar file format。它由 Twitter 和 Cloudera 开发，现在是 Apache Software Foundation 的一部分。Parquet 是为 analytics 构建的，在这类场景中，CSV 和 JSON 等 row-based formats 会浪费空间并拖慢 queries。它的 columnar layout 也非常适合 Iceberg tables，因为这些 tables 重视 performance、efficiency 和 schema evolution。

Parquet 按 columns 而不是 rows 存储数据，并组织成不同的 row groups，如图 5.8 所示。这种设计支持多种优化。当 Apache Spark、Dremio 或 Trino 等 engine 扫描 Parquet file 时，它可以有选择地只读取 query 需要的 columns，并跳过其他部分。这会减少 I/O，尤其适用于包含许多 fields 的 wide tables。Parquet 还支持 dictionary 和 run-length encoding 等 compression techniques，这些技术通常在 per-column blocks 上比通用 file-level compression 效果更好。

图 5.8：使用 Parquet row-group footers 中的 metadata，可以判断哪些 row groups 需要扫描、哪些可以跳过，以实现更快读取。

对于 Iceberg 这种用于管理大规模 immutable data files 集合的系统，Parquet 提供了几个战略优势。每次写入 Iceberg table 通常会生成一个或多个新的 Parquet files，随后 Iceberg 将其注册到自己的 metadata 中，确保每个 snapshot 的 metrics 正确，见图 5.9。Iceberg 不是在 query time 只依赖 file-local information，而是将来自 Parquet file footers 的 statistics 聚合到自己的 table-level metrics 中。

图 5.9：每次向 table 写入都会引入新 files，每个 snapshot 的 metadata 会跟踪该时间点 table 中的 files。

Row Groups 和 Predicate Pushdown

Parquet 按 columns 组织数据。这种布局压缩效果好，并能加快 analytics 读取。Parquet files 被划分为 row groups，也就是 storage 和 I/O 的主要单位。每个 row group 包含 dataset 的一部分 rows。在每个 row group 内，数据被存储为 column chunks，因此 queries 可以只选择读取自己需要的 columns。

Parquet row groups 会贡献 metadata，例如 column-level statistics，帮助 query engines 跳过不必要数据。但在现代 lakehouses 中，row group size 已经不再是主要调优手段。在 cloud environments 中，I/O 是高度离散化的，performance 更多取决于 file-level parallelism、engine 的 execution model 和 caching，而不是单个 file 的内部 layout。

Row group boundaries 会影响 reads 期间 work 如何拆分，但大多数现代 engines 更关注写入适当大小的 files，并将工作分散到多个 files 上。因此，ingestion frameworks 和 execution engines 通常会自动处理 row group settings。在大多数 Iceberg deployments 中，你不需要直接管理 row groups。相比之下，file-size tuning、metadata pruning 和 query planning 能带来更多价值。

Predicate pushdown 正是在这里变得强大。它允许 query engines 将 filters，例如 WHERE id = 2，在数据读入内存前下推到 storage level。通过使用每个 row group metadata 中的 statistics，如果 engine 可以判断某个 row group 不包含任何匹配 rows，就可以跳过整个 row group。这意味着需要读取和处理的数据更少，从而提升 performance 并降低 resource usage。Row groups 和 predicate pushdown 共同构成了 Parquet 支持快速、可扩展 analytics 的核心能力。

这些 aggregated metrics 包含 column value ranges、null counts 和 data sizes 等信息，并与 file 和 partition metadata 一起存储。这允许 query engines 在 query planning 阶段评估哪些 files 相关，而不需要检查单个 files 或 footers。通过实现早期、高效 file pruning，Parquet 与 Iceberg 的这种集成减少了不必要 I/O，缩短 scan times，并降低整体 compute usage。

Parquet 会同时存储 data 和写入每个 file 时使用的 schema，但仅靠 Parquet 并不能让 Iceberg table 实现 schema evolution。Iceberg 通过引入 field IDs，将 table schema 与 file schema 解耦；field IDs 为每个 column 提供稳定标识符，不依赖其 name、position 或 file 中的 physical representation。这使 Iceberg 可以安全支持 column renaming、reordering 和 type widening 等 schema changes，而无需重写已有 data files。因此，不同 schemas 下写入的 Parquet files 可以共存于同一张 table 中，由 Iceberg 在 table level 强制 compatibility 和 correctness。

Parquet 支持 nested data structures，并通过高效 columnar encoding 和 compression，在保持高 scan efficiency 的同时支持丰富数据建模。这些特征使 Parquet 成为分析数据的强大 physical format，但 schema management 和 evolution 是由 Iceberg 而不是 file format 本身处理的。

Parquet 的 performance considerations 主要由 file-level parallelism 和 metadata efficiency 驱动，而不是细粒度 layout tuning。虽然常见 ecosystem defaults 通常会生成数百 MB 的 files，但这更多是历史 engine constraints 的结果，而不是内在要求。在现代 cloud environments 中，拥有 asynchronous I/O 和高度 parallel execution engines，较小 files 往往也能以较低惩罚被并行高效读取。大 files 在 object storage 上通常收益有限，甚至可能降低 scheduling flexibility。对大多数 Iceberg deployments 来说，file sizing 最好交给 engine defaults，除非有明确的调优需求，例如在极端 table scale 下，metadata volume 本身成为问题。

由于 maturity、performance characteristics 和 ecosystem support，Parquet 在实践中事实上已经是 Iceberg tables 的标准 file format。虽然 Iceberg specification 允许多种 file formats，但 Parquet 是各 engines 最一致支持和优化的格式。Iceberg 中 ORC support 在 reference implementations 中相对滞后，而 Avro 通常只用于轻量 metadata 或内部操作，而不是大型 analytical datasets。展望未来，即使 Iceberg 自身 metadata，也预计会越来越多使用 Parquet 作为底层表示。

Iceberg 通过将 file-level statistics 聚合到 manifest metadata 中，在 Parquet 之上构建能力。这些 manifests 充当 routing indexes，使 engines 可以在 query planning 阶段基于 column ranges、null counts 和 row counts 判断哪些 files 相关，而无需检查 data files 本身。这种分层设计，用 Parquet 做高效 columnar storage，用 Iceberg manifests 做 global metadata，使 Iceberg tables 能扩展到巨大规模，同时保持 query latency 可预测和可管理。

5.3.2 S3 API

S3 API，也就是 Simple Storage Service API 的简称，最初是 Amazon 云存储的专有访问方式，后来成为与 object storage systems 交互的事实标准协议。如今，从 public cloud services 到 on-premises solutions，S3 API 支撑了几乎所有主要 object stores，使它们可以通过一致的 HTTP-based 方式与大规模 storage systems 交互。

S3 API 的广泛采用，对数据架构产生了变革性影响。通过标准化 systems 创建、检索和管理 objects 的方式，它将 storage access 从 vendor-specific infrastructure 中抽象出来。这为 storage systems、data platforms 和 processing engines 之间的广泛 interoperability 打开了大门。例如，Apache Iceberg 可以无缝运行在任何 S3 API–compatible object store 上，无论它由 Amazon、MinIO、Ceph 还是其他 vendor 托管。

从设计角度看，S3 API 围绕 flat object namespaces 构建，而不是传统 hierarchical filesystems。Objects 通过 bucket 内的 unique keys 访问，每个 object 都被视为 immutable binary blob。相比 filesystem，这种 flat structure 看起来可能很简单，但它支持 cloud scale 下的 scalability 和 parallelism。由于每个 object 都可以通过 HTTP 独立寻址，clients 可以并发从多个 objects 中检索数据，而不需要担心 locking 或 directory structure。

对于 Iceberg lakehouses，这个模型非常理想。Iceberg tables 由许多 immutable files 组成，包括 data files 和 metadata files，这些 files 可以被独立读取、写入和版本化，如图 5.10 所示。S3 API 允许 Iceberg-compatible tools 使用可预测且 resilient 的 patterns 与这些 files 交互。例如，当提交新的 snapshot 时，Iceberg 会写入 metadata files，然后通过更新 pointer file 执行 atomic commit operation。这个 workflow 与 S3 API 的 write-once-read-many semantics 非常契合。

图 5.10：不同 engines 可以与同一张 Iceberg table 协作，并发从 object storage system 请求 files。

S3 API 的另一个优势是其生态系统。许多 operational tools，例如 backup systems、monitoring dashboards 和 access control frameworks，都是为与 S3 endpoints 原生配合而设计的。这减少了 integration overhead，并允许 platform teams 在 storage deployments 中应用通用 policies 和 tools。S3 API 还支持 versioning、lifecycle policies 和 presigned URLs 等特性，可用于执行 governance、管理 costs，或支持 temporary data sharing。

不过，值得注意的是，虽然 S3 API 被广泛支持，但并非所有实现的行为都完全相同。Eventual consistency、performance characteristics 和 API completeness 上的差异，会影响 object store 对 Iceberg operational model 的支持程度。因此，不仅要评估某个 storage solution 是否声称 S3 compatible，还要评估其实现成熟度，以及在 production workloads 下表现如何。

在现代 Iceberg lakehouses 中，S3 API 是 storage layer 与其余架构之间的 connective tissue。它的普遍性带来灵活性，它的简单性支持扩展，而它与 Iceberg 设计原则的一致性，使其成为任何严肃部署的基石。

5.4 Storage Solutions

当你对 storage requirements、核心 architectural models 和底层 standards 有了扎实理解后，就可以探索可用于实现 Apache Iceberg lakehouse 的 storage technologies。本节会调查一系列 storage solutions，每一种都有不同的设计哲学、deployment models 和 operational tradeoffs。这里的目标不是推荐一个唯一“最佳”选择，而是提供各种选项的历史背景、技术能力和实践适配性，让你可以将它们映射到平台审计中发现的 requirements。

Storage Architecture 如何塑造 Durability、Availability 和 Latency

为 Iceberg lakehouse 评估 storage solutions 时，必须理解 durability、high availability（HA）、consistency 和 latency 等关键特性如何在不同 architectural models 中实现。这些属性不只是 vendor features；它们来自 storage systems 如何在 distributed environments 中处理 data replication、failure recovery，以及新写入 files 的可见性。

尤其是 consistency，它决定写入文件多快可以在系统中被读取，这对 distributed 和 object-based storage 尤其关键。写入可见性的延迟或不一致，会影响 ingestion pipelines、concurrent readers，以及 Iceberg 等上层的 transactional guarantees。选择能够在规模化下可靠支持协调读写的 storage layer 时，理解这些行为非常重要：

Colocated storage，例如 HDFS 上的 block storage——在这种模型中，storage 与 compute resources 紧密耦合。数据位于直接连接到运行 processing engines 的相同 machines 的 disks 上。Durability 和 availability 依赖 software-managed replication，例如 HDFS 通常使用跨 nodes 的 3x replication。Failures 需要 cluster orchestration tools 介入；如果数据必须手动重新复制或从 cold storage 恢复，recovery 可能会很慢。Latency 通常较低，因为 reads 和 writes 发生在靠近 processor 的地方，但扩展 capacity 也意味着配置更多 compute，这是一种昂贵且刚性的取舍。

Separate storage，例如 S3 或 MinIO 等 object storage——在这种模型中，storage 与 compute 解耦，并通过网络上的 APIs 访问。Durability 通过 automatic、vendor-managed replication 跨 regions 或 availability zones 实现。例如，AWS S3 会在多个 facilities 中复制数据，且无需用户配置。High availability 通过 distributed architecture 和 global failover support 内置在平台中。由于 network hops 和 eventual consistency mechanisms，latency 比 block storage 更高且更不稳定。尽管如此，该模型允许 compute 和 storage 独立扩展，降低 operational overhead，并提供内置 resilience。

理解这些差异，可以帮助你将 storage choices 与 workload needs 对齐。Low-latency、严格控制的环境可能仍然偏好 colocated storage，而 scalable、cost-efficient、cloud-native architectures 则越来越多地建立在 separate object stores 之上。

我们会从 Hadoop Distributed File System（HDFS）开始，它在 legacy big data environments 中仍被广泛使用，并且常常是组织现代化数据平台的起点。然后，我们会转向主要 public cloud object stores：Amazon S3、Google Cloud Storage 和 Azure Blob Storage。这些 services 代表 cloud-native object storage 的主流，并构成今天许多 Iceberg deployments 的骨干。

接下来，我们会探索一系列提供 S3-compatible object storage 的 on-premises 和 hybrid solutions，包括 MinIO、Ceph、NetApp StorageGRID、Everpure、Dell ECS 和 Wasabi。这些选项对那些因为 regulatory、residency 或 performance requirements 而无法采用完全 public cloud approach 的组织尤其相关。每个 vendor 都有不同强项，从 cost predictability 到 Kubernetes-native integration 不等。理解这些差异，是做出明智、可持续选择的关键。

对于每个 storage solution，我们会看它的起源、如何融入 Iceberg ecosystem，以及它最适合支持哪些 requirement profiles。无论你是在扩展现有基础设施，还是从云端重新开始，后续 sections 都会帮助你为 Iceberg lakehouse 选择正确基础。

5.4.1 Vendor Comparison Summary

面对如此多的 storage options，为 Apache Iceberg lakehouse 选择合适方案，归根结底是将技术能力与你具体的 performance、governance 和 operational requirements 对齐。本节讨论的 vendors 覆盖一个范围，从高性能 enterprise appliances，到简单、成本高效的 cloud offerings。每一种都会在 scalability、ecosystem integration 和 ease of management 上带来自己的取舍。

为了支持更结构化的评估，表 5.1 总结了我们将审查的 10 个 vendors 的关键特征。这个比较无法捕捉每个细节，但提供了一个有用的高层视图，展示这些平台在常见影响 Iceberg storage decisions 的领域中有何不同。

表 5.1：Storage vendors 概览

Vendor	Deployment model	S3 API support	Security & compliance	Cost model
HDFS	On-prem	No	各异，通常较基础	CapEx-heavy
Amazon S3	Cloud（AWS）	Native	Enterprise-grade	Pay-per-use，包括 egress
Google Cloud Storage	Cloud（GCP）	Native	Enterprise-grade	Tiered、usage-based
Azure Blob / ADLS	Cloud（Azure）	Native	Enterprise-grade	Tiered、usage-based
MinIO	On-prem、hybrid	Full	Strong with custom setup	Tiered、usage-based
Ceph	On-prem	Full，通过 RGW	Highly configurable	Open source、依赖基础设施
NetApp StorageGRID	On-prem、hybrid	Full	Strong，WORM，lifecycle	Enterprise licensing
Everpure	On-prem appliance	Full	Robust、integrated	Premium appliance
Dell ECS	On-prem、hybrid	Full	Enterprise-grade	Enterprise licensing
Wasabi	Cloud（vendor-hosted）	Full	Basic、improving	Flat-rate，无 egress fees

这张表不能替代 hands-on evaluation，但可以指导初始讨论，并帮助 stakeholders 缩小范围。对于许多组织，正确方案可能涉及多个 storage backends 协同工作，例如将 on-premises object storage 用于敏感数据，同时用 cloud-native stores 支持 scalable analytics。Iceberg 的模块化特性允许这种 hybrid flexibility，前提是每个 backend 都遵循 immutability、consistency 和 S3-compatible access 的原则。

继续推进时，请使用本章前面定义的 requirements，将选项与 operational realities 和 strategic goals 对照 benchmark。Storage 可能是 lakehouse stack 中最低的一层，但你在这里做出的选择会向上影响 performance、governance，并最终影响你从数据中交付可信、可扩展洞察的能力。

5.4.2 Hadoop

对于深度投入 Hadoop 的组织，HDFS 仍然是一个稳定且高性能的选项。它允许继续使用现有 clusters，同时在熟悉的 storage foundation 之上采用 Iceberg 的优势，例如 ACID guarantees、schema evolution 和 time travel。但对于新部署，或者计划扩展到单一 data center 之外的组织，HDFS 越来越像一个过渡层，而不是长期战略选择。

HDFS 在 big data platforms 演进中发挥了基础作用。作为原始 Apache Hadoop project 的一部分，HDFS 在 commodity hardware clusters 上提供可扩展、fault-tolerant storage。它将大型 files 划分成固定大小的 blocks，并跨 nodes 复制以提升 resilience，同时向 clients 和 processing frameworks 暴露 distributed filesystem interface。

对于许多组织，HDFS 是传统数据仓库之外的第一个可行替代方案，用于存储和分析海量结构化和半结构化数据。它与 MapReduce，后来又与 Apache Spark 等 processing engines 搭配，实现了规模化 parallel data access，并奠定了早期 big data ecosystem 的基础。即便今天，在强调 data locality、low-latency access 和与现有 Hadoop tooling 紧密集成的 on-premises environments 中，它仍然是常见选择。

在 Apache Iceberg lakehouse 中，HDFS 在特定情况下仍能提供价值。由于 Iceberg 在 storage layer 是 format agnostic，它可以像管理 object storage 中的 Parquet files 一样，管理 HDFS 中存储的 Parquet files。拥有成熟 Hadoop deployments 的组织，可以选择渐进式引入 Iceberg，用它现代化 metadata 和 table management，而不立即替换底层 storage infrastructure。这种方法允许向更灵活、模块化架构做增量转型。

话虽如此，HDFS 也有局限。它不是为 elastic scaling、global accessibility 或现代 lakehouses 所特有的 API-driven workflows 设计的。它需要大量 operational overhead，包括 disk provisioning、replication configuration、cluster balancing 和 fault recovery。它也缺乏 HTTP-based access 和 object-level metadata 的原生支持，而许多新工具和平台都期待这些能力。

此外，与 cloud-based object stores 和较新的 S3-compatible solutions 相比，HDFS 对 multitenancy 和 fine-grained access control 的支持有限。在多个团队共享基础设施，或监管合规要求稳健 isolation 和 auditing capabilities 的 environments 中，这些约束会造成摩擦。

5.4.3 Amazon S3

对于已经承诺使用 AWS 生态系统的组织，Amazon S3 为 Iceberg lakehouses 提供可靠、高性能且安全的基础。它的全球基础设施、成熟功能集，以及整个数据生态的一流支持，使其成为许多 cloud-native deployments 的默认选项。不过，必须用周到的成本和架构管理配合这一强大能力，以确保长期效率和可持续性。

Amazon Simple Storage Service（S3）是后来成为行业标准的 S3 API 的最初实现，并且仍然是云端使用最广泛的 object storage solution。自 2006 年发布以来，S3 已经演化成一个高度 durable、massively scalable 的存储平台，支持广泛的 analytics、machine learning 和 operational workloads。对于部署在 AWS 上的 Iceberg lakehouses，S3 是 object storage 的自然选择。

S3 架构将 storage 抽象为 buckets 和 objects，通过简单 HTTP operations 实现高度 concurrent access。其全球可用性、与 AWS identity and access management（IAM）的原生集成，以及成熟 tooling ecosystem，使其对 enterprise-scale data platforms 尤其有吸引力。Versioning、object locking、lifecycle rules 和 cross-region replication 等功能，为 data retention、security 和 disaster recovery 提供 fine-grained control。

在 Apache Iceberg deployments 中，Amazon S3 是天然适配。你可以将 Iceberg metadata 和 data files 直接存储在 S3 buckets 中，并且大多数 compute engines，包括 Apache Spark、Dremio、Trino 和 Amazon Athena，都原生支持查询存储在 S3 中的 Iceberg tables。Iceberg 的 transactional metadata 与 S3 的 object immutability model 结合，支持安全 concurrent reads and writes，使多个 teams 和 services 可以扩展 workloads。

S3 的 performance 通常很强，但需要一定架构考虑。由于 S3 在某些 operations 中被设计为 eventual consistency，例如 listing 和 overwriting，设计 commit workflows 和 cleanup jobs 时要小心。Iceberg 的设计通过 catalogs 中的 atomic pointer updates 和 metadata files 中的 file-level tracking，缓解了许多这类问题。即便如此，very high commit frequency 或 real-time ingestion environments 仍应监控 latency 和 consistency behavior。

另一个重要考虑是成本。S3 pricing 取决于 storage volume、request frequency、data transfer，以及 Intelligent-Tiering 和 Glacier archiving 等可选功能。对于频繁访问 small objects，或运行大规模 inter-region queries 的 data platforms，这些成本可能变得很显著。不过，AWS 提供了 tools 和配置选项来优化 usage patterns 并控制费用，包括 tiered storage classes 和 intelligent lifecycle policies。

Security 和 governance 也获得良好支持。与 AWS IAM 的集成支持 access control，at rest 和 in transit 的原生 encryption options 支持 enterprise 和 regulatory requirements 合规。S3 还与 AWS CloudTrail 和 AWS Config 等 services 集成，用于 auditing 和 policy enforcement，使满足内部和外部数据保护标准更容易。

Amazon S3 Table Buckets

Amazon S3 table buckets 是一种专为 analytics 设计的 S3 bucket，会将 analytical tables 作为一等对象处理。不同于 general-purpose buckets，table buckets 与 Apache Iceberg 原生集成，使你可以直接在 S3 中定义和管理 Iceberg tables。

这些 buckets 支持自动维护，以优化 storage costs 和 performance，并与 AWS Glue Data Catalog 和其他 AWS analytics services 集成。你还可以通过 Amazon S3 Tables Catalog 及其 REST API，从开源 query engines 访问它们。

每个 table bucket 默认是 private，并由 IAM-based policies 治理。这确保为 data consumers 和 roles 提供安全、fine-grained access control。虽然 table buckets 当前有 regional limits，默认每个 region 10 个，但对于希望紧密贴合 AWS-native infrastructure 的 Iceberg 用户，它们提供了可扩展、managed 的选项。

5.4.4 Google Cloud Storage

Google Cloud Storage（GCS）是 Google 的 fully managed、scalable object storage service，也是其数据分析生态系统的基础组件。对于已经使用 Google analytics ecosystem 的组织，包括 BigQuery、Dataflow 和 Vertex AI，GCS 尤其有吸引力。其强 consistency model、有竞争力的 performance，以及 cost-effective tiering，使它成为优先考虑 elasticity 和跨 data lifecycle 集成的 Iceberg lakehouses 的优秀选择。

GCS 建立在支撑 Gmail 和 YouTube 等产品的同一基础设施之上，并为 high availability、global accessibility 和与 Google data services 的深度集成而设计。对于在 Google Cloud 上构建 Iceberg lakehouses 的组织，GCS 提供可靠且灵活的 storage backend。

与 Amazon S3 类似，GCS 将数据组织为 buckets 和 objects，并通过 RESTful API 访问。它支持 strong read-after-write consistency，这对 Iceberg 的 transactional model 有益，尤其是在 concurrent metadata commits 或 snapshot reads 期间。GCS 的 consistency guarantees 降低了 delayed file visibility 的风险，简化了 ingestion 和 cleanup 相关架构决策。

GCS 提供多个针对不同 access patterns 优化的 storage classes，包括 Standard、Nearline、Coldline 和 Archive。这些 classes 允许组织根据 usage frequency 和 retention policies，在 cost 和 performance 之间取得平衡。例如，Iceberg tables 可以将频繁访问的 metadata 和 recent partitions 存储在 Standard storage 中，同时将 older snapshots 和 historical data 自动移动到更冷、更具成本效益的 tiers。

性能方面，GCS 非常适合 Iceberg workloads。其低延迟 object retrieval 和强 internal network backbone 支持跨大型 datasets 的 high-throughput analytics jobs。与 BigQuery、Dataproc 上的 Spark，或 Trino 等开源 query engines 配合使用时，GCS 能为 Iceberg tables 的读写提供一致性能。Google 的 data transfer acceleration 和 parallel object access 进一步提升 batch 和 interactive queries 的吞吐。

Security 和 compliance 也是 GCS 的强项。该平台默认支持 server-side encryption，并提供 customer-managed encryption keys（CMEK）和 hardware security module（HSM）integration 选项。Access control 通过 IAM policies 执行，可以配置在 bucket、object 或 project level。GCS 也与 Google Cloud 的 audit logging 和 policy management tools 集成，提供对 storage usage 的可见性和控制。

5.4.5 Azure Blob Storage 和 ADLS

Microsoft Azure 提供两种紧密相关的 object storage services，可作为 Iceberg lakehouses 的基础：Azure Blob Storage 和 Azure Data Lake Storage（ADLS）。二者构建在相同核心平台之上，但通过 access semantics 和 feature sets 区分。它们共同提供一个灵活、可扩展的基础，用于在 Azure 生态中存储数据，并支持广泛 analytics 和 governance requirements。

Azure Blob Storage 是 Azure 中最基础的 object storage service。它为存储 blobs，也就是 binary large objects，提供 flat namespace，可以通过基于 REST 的 Blob API，或在特定配置下通过 S3-compatible API 使用 HTTPS 访问。Blob Storage 设计目标是 high durability、geo-redundancy 和广泛兼容性，因此在 Azure-centric deployments 中，它是 Iceberg tables 的可行 backend。

Blob Storage 支持多个 performance tiers：Hot、Cool 和 Archive，它们与 access frequency 和 cost targets 对齐。这种 tiered structure 允许组织通过将较旧 Iceberg data 自动转换到更冷 tiers，在长期优化 storage costs，同时不影响访问。与 Azure Event Grid 和 Azure Functions 等服务集成，可以支持用于 ingestion、processing 和 lifecycle management 的 event-driven workflows。

Azure Data Lake Storage Gen2（ADLS）直接构建在 Blob Storage 之上，并引入 hierarchical namespace 和 filesystem semantics。这些包括 directory structures、atomic rename operations，以及通过 Azure Active Directory（Azure AD）和 POSIX-style ACLs 实现的 fine-grained access control。这些增强在 analytics scenarios 中尤其有用，因为 workloads 通常期待类似 filesystem 的 interface，同时 security policies 也要求 granular permission management。

Azure AD 和 ACLs

Azure Active Directory（Azure AD）是 Microsoft 的 cloud-based identity and access management service。它帮助组织管理用户、groups，以及跨 cloud 和 on-premises environments 的 applications 和 resources 访问。Azure AD 是 Microsoft Azure 中 authentication 和 authorization 的核心，允许企业执行 secure sign-ins、提供 single sign-on（SSO），并实现 role-based access control（RBAC）。它可以与数千个 SaaS applications 集成，并能跨 domains 联合身份，是现代 identity management 的关键组成部分。

另一方面，POSIX-style access control lists（ACLs）是 filesystem-level permission model，传统上用于 Unix 和 Linux environments。它们对谁可以 read、write 或 execute files 和 directories 提供 fine-grained control。不同于基础 Unix permissions，也就是 owner / group / other，ACLs 允许 administrators 为文件 owner 或 group 之外的 individual users 或 groups 指定 permissions。这种灵活性使 ACLs 非常适合 multi-user environments，尤其是 access requirements 无法仅用标准 permission bits 表达时。

在 ADLS 等 cloud storage context 中，Azure AD 和 POSIX-style ACLs 可以协同管理访问。Azure AD 处理 authentication，也就是验证用户是谁；POSIX ACLs 管理 authorization，也就是用户能对数据做什么。例如，某用户可能通过 Azure AD 完成认证，然后根据 storage account 中设置的 ACLs，被授予对特定 directories 或 files 的 read-only 或 write access。这种分层 security model 为数据访问提供 robust、enterprise-grade governance。

对于 Apache Iceberg，Blob Storage 和 ADLS 都是兼容的 storage backends。大多数支持 Azure 上 Iceberg 的 engines，例如 Azure Synapse 上的 Spark、Dremio 和 Trino，都提供针对任一 service 的配置选项。当你需要更严格 access controls 和 filesystem operations 时，ADLS 通常更受青睐；而 Blob Storage 可能因其简单性和更广泛生态支持被选择。

两种服务在 performance 上都具有竞争力，尤其适合 batch workloads 和 large-file scans。ADLS 的 hierarchical namespace 会为 metadata-intensive operations 引入额外 latency，但这通常会被它对 Hadoop-style processing engines 的更好兼容性抵消。Blob Storage 的 flat namespace 在 directory traversal 不那么相关的 object-intensive operations 中表现更好。

Security 是两种服务的共同优势。Azure 提供内置 encryption at rest，支持 customer-managed keys，并与 Azure Key Vault 集成。Access 与 Azure IAM 和 Azure AD 紧密集成，可以跨 storage 和 compute services 执行一致 policies。Diagnostic logging 和 activity tracking 可用于 auditing 和 compliance monitoring，使这些服务非常适合 regulated environments。

在 Azure 上架构 Iceberg lakehouse 时，Blob Storage 和 ADLS 的选择取决于 workload patterns 和 governance needs。对于简单、大规模 object access，Blob Storage 通常已经足够且易于集成。对于需要 fine-grained control、与 Hadoop filesystems 兼容，或 enterprise-scale security policies 的 environments，ADLS 提供更专门且更强大的基础。

Microsoft OneLake 和 Fabric Data Platform

Microsoft OneLake 是支撑 Microsoft Fabric 的统一 data lake storage layer。Microsoft Fabric 是一个 SaaS-based analytics platform，集成 data engineering、data science、real-time analytics 和 business intelligence。OneLake 为整个 Fabric 生态提供一个单一 logical storage system，概念上类似建立在 ADLS Gen2 上的 “data mesh”。

OneLake 支持与 Apache Iceberg 和 Delta Lake 等 open table formats 原生集成，使其可以与 external engines 和 tools 互操作。它还提供指向 external storage 的 shortcuts，例如链接到现有 ADLS Gen2 或 AWS S3 buckets，而无需物理移动数据，从而支持 hybrid 和 multicloud strategies。

5.4.6 MinIO

虽然 MinIO 缺少 public cloud provider 的全球基础设施和内置服务，但它的灵活性、标准兼容性和性能，使其成为那些要求控制力和速度的生产 Iceberg deployments 的强候选方案。随着 Iceberg 在 hybrid 和 edge environments 中采用增长，MinIO 仍然是最通用的 object storage options 之一。

MinIO 是一个高性能 object storage solution，并且完全兼容 S3 API。它旨在将类似 cloud 的 scalability 和 simplicity 带到 on-premises 和 hybrid environments 中。对于希望在 public cloud 之外运行 Iceberg lakehouses，同时不牺牲现代架构原则的组织来说，MinIO 已成为热门选择。

MinIO 的核心是 minimalist、container-friendly 的设计，易于部署、扩展和管理。它可以运行在 physical servers、virtual machines、Kubernetes clusters，甚至 edge environments 中。其轻量 footprint 和强 performance，使它非常适合那些 control、cost predictability 和 performance tuning 是最高优先级的场景。

MinIO 的 S3 compatibility 不只是表面兼容。它频繁更新，以保持与 Amazon S3 API specification 对齐，从而能够与更广泛 Iceberg ecosystem 无缝集成。Apache Spark、Dremio 和 Trino 等 processing engines 可以像与 AWS S3 交互一样与 MinIO 交互，使 developers 能迁移 workflows，而无需重新设计 ingestion 或 query pipelines。

Performance 是 MinIO 的关键差异化点之一。它针对 small-object operations 和 high-throughput data workloads 进行了优化，在 reads 和 writes 方面都有强 benchmarks。对于 Iceberg deployments，这意味着 fast metadata commits、efficient data file retrieval，以及多个 workloads 并发访问时更低 latency。MinIO 还包括 erasure coding 用于 durability、inline compression，以及 object locking，用于支持 compliance 和 fault tolerance。

Erasure Encoding、Inline Compression 和 Object Locking

Erasure encoding，也称 erasure coding，是现代 storage systems 中用于提供 fault tolerance 的数据保护技术，比传统 replication 更节省存储空间。它不是存储多个完整数据副本，而是将数据拆分成 fragments，并用数学算法生成额外 parity fragments。这些 fragments 被分布到不同 storage nodes 上。如果部分数据因硬件故障或 corruption 不可用，原始数据可以从剩余 fragments 和 parity 中重建。该方法广泛用于 Azure Blob Storage、Amazon S3，包括 Glacier storage classes，以及 MinIO 等 distributed object storage systems，以在使用少于完整复制的空间下实现 durability 和 availability。

Inline compression 指的是在数据写入 storage 时进行压缩。这会降低 storage footprint，而不需要单独的后处理步骤。Inline compression 在 Parquet 或 ORC 等 columnar formats 中尤其有价值，也内置于许多 object storage systems。它通过减少从 disk 读取的数据量，最小化 I/O 并提升 query performance。关键优势是它对用户或 application 透明；数据在存储时自动压缩，在检索时自动解压，从而无缝提供性能和成本收益。

Object locking 是 object storage systems 中的一项功能，可防止 objects 在指定期间被修改或删除，即使拥有完整访问权限的用户也不能改动。这对于 compliance 和 regulatory use cases 至关重要，例如 financial record retention 或 legal holds，其中数据必须保持不可变。Object locking 可以有两种模式：governance，允许授权用户覆盖 lock；以及 compliance，在 retention period 过期前不允许任何改动。AWS S3 和 MinIO 等系统支持该功能，它帮助满足 SEC Rule 17a-4 或 HIPAA 等要求，并在构建 tamper-proof、audit-ready data architectures 中发挥关键作用。

MinIO 对 security 的支持也很好。它提供内置 encryption at rest 和 in transit，通过 IAM-like policies 实现 fine-grained access control，并与 LDAP 或 OpenID Connect 等 external identity providers 集成。对于有严格 governance 或 data residency requirements 的组织，这些功能提供了灵活、可审计的 security model，而且不依赖 external cloud services。

从运维角度看，MinIO 为简单性而设计。它的 management API 和 user interface 提供 object usage、system health 和 replication status 的可见性。Administrators 可以配置 bucket policies、监控 performance，并以最小 overhead 扩展 clusters。对于 Kubernetes 用户，MinIO 提供 native operators，简化 containerized environments 中的 lifecycle management 和 autoscaling。

MinIO 对那些希望在 cloud options 不可行的 environments 中构建 Iceberg lakehouses 的组织尤其有吸引力，无论是因为 regulatory restrictions、cost concerns，还是需要 localized data processing。它也非常适合作为 testing 和 development backend，让团队可以在笔记本电脑或 CI/CD pipeline 中获得类似 cloud 的体验。

5.4.7 Ceph

对于 Iceberg lakehouses，Ceph 为那些重视 openness、on-premises control 和 unified architecture 的环境提供了一条有吸引力的路径，通向 S3-compatible object storage。它是成熟基础设施团队的强大选项，这类团队希望避免 cloud dependency，同时保留 Iceberg 的完整能力。

Ceph 是一个开源 unified storage platform，在单一 distributed system 中提供 object、block 和 file storage。它最初由开源社区开发，现在由 Ceph Foundation 维护，并得到 Red Hat 等支持。Ceph 的设计目标是 flexibility、high availability 和 scalability。在 Iceberg lakehouse architectures 中，Ceph 通常作为 S3-compatible object store 部署，为 private data centers 和 hybrid environments 中无法使用 public cloud 的场景，提供 cloud-based storage 的稳健替代。

Ceph 的核心是 RADOS（Reliable Autonomic Distributed Object Store）layer，负责在 cluster nodes 之间处理 data distribution、replication 和 consistency。在 RADOS 之上，Ceph 提供多个 interfaces，包括 RBD（block storage）、CephFS（POSIX-compliant filesystem）和 RGW（RADOS Gateway），其中 RGW 暴露 S3-compatible API。这个 RGW 组件使 Ceph 可以在偏好 object storage 但 public cloud 使用受限的环境中，作为 Apache Iceberg tables 的 backend。

Ceph 的一个强项是 fault tolerance。它使用 distributed replication 或 erasure coding 来确保跨 nodes 的 data durability，并支持 self-healing 和 rebalancing，以在硬件故障后用最少手工干预恢复。这使它非常适合运营大规模、multi-node storage clusters 的组织，这些组织需要确保 uptime 和 data integrity。

Ceph 的 performance profile 会因 deployment configuration、underlying hardware 和 network bandwidth 而异。经过恰当调优后，它可以支持 Iceberg workloads 中常见的 high-throughput 和 concurrent access patterns。但为了获得最佳结果，需要围绕 cluster topology、replication factors 和 IOPS provisioning 做细致规划。Ceph 的 operational complexity 通常高于 MinIO 或商业方案，因此最适合具备深厚系统专业能力的团队。

在 Iceberg compatibility 方面，Ceph 的 S3 API support 允许它与广泛 engines 和 tools 集成。不过，它的 S3 implementation 有时可能落后于最新 S3 features，或者在 consistency behavior 上表现出细微差异，这可能影响高并发环境中的某些 edge cases。在 Ceph 上生产部署 Iceberg 时，验证这些行为非常重要。

Ceph 的 security 高度可配置。它支持 role-based access control（RBAC）、data in transit 的 TLS encryption，并可与 LDAP 或 Keystone 等 external authentication systems 集成，后者常见于 OpenStack environments。虽然这些功能强大，但通常需要 custom configuration，组织必须投入适当 monitoring 和 policy enforcement，才能保持强安全态势。

Ceph 尤其适合运行 private clouds 的组织、研究机构，以及希望提供 multitenant object storage 的服务提供商。它能在一个系统中支持不同 storage workloads 的灵活性，也可以简化 infrastructure management。不过，采用它需要 operational discipline 和 resource planning。

5.4.8 NetApp StorageGRID

对于希望为 Iceberg lakehouses 获得稳定、policy-driven 且 compliant storage platform 的组织，StorageGRID 是一个强选择。它提供 Iceberg metadata management 所需的 consistency 和 compatibility，同时支持围绕 cost control、data governance 和 infrastructure integration 的企业优先级。

NetApp StorageGRID 是一个 enterprise-grade、software-defined object storage solution，面向大规模 hybrid cloud deployments 设计。它对 S3 API 提供强支持，其架构重点是 long-term data retention、policy-driven lifecycle management 和 regulatory compliance。这使 StorageGRID 非常适合在复杂、多环境基础设施中运行 Iceberg lakehouses 的组织。

StorageGRID 最初为 archiving 和 unstructured data storage 构建，后来演进成一个多用途平台，可以作为 analytics 和 data lake workloads 的 primary object storage layer。它可以作为 software appliance 部署在现有 hardware 上，也可以作为 NetApp 的集成 hardware solution，或作为 hybrid cloud strategy 的一部分，将 on-premises systems 与 public cloud storage 集成。

对于 Apache Iceberg，StorageGRID 的 S3-compatible interface 支持与 Apache Spark、Trino 和 Dremio 等 engines 集成。Iceberg tables 可以使用与 cloud-native environments 相同的 API semantics 存储和管理在 StorageGRID 上。因此，对于因 data residency、performance control 或 regulatory mandates 而需要 on-premises deployment 的组织，它是一个 practical option。

StorageGRID 的一个显著特性是支持 intelligent data lifecycle policies。Administrators 可以根据 metadata、access patterns 或 organizational policies，为 object placement、retention、deletion 和 tiering 定义规则。这种能力与 Iceberg 的 snapshot-based model 非常契合，因为同一 dataset 的不同版本可能有不同 storage 和 retention requirements。StorageGRID 可以自动化 archival 和 cost-optimization strategies，同时不破坏 data availability 或 consistency。

Performance 针对 large object workloads 进行了调优，对 concurrent access 和 high-throughput ingestion 提供强支持。虽然它不像为 transactional use cases 设计的系统那样针对 latency 优化，但在 Iceberg 典型的 batch 和 analytical workflows 中表现良好。它也支持 erasure coding、geodispersed replication 和 service-level objectives，以帮助确保 distributed environments 中的 durability 和 availability。

从 governance 和 security 角度看，StorageGRID 包含 WORM（write once, read many）compliance、access logging 和 S3 Object Lock 等功能。这些能力使其对 finance、healthcare 和 government 等 sector 尤其有吸引力，因为这些领域中 auditability 和 immutability 是法律或监管要求。与 Active Directory、TLS encryption 和 bucket-level IAM controls 的集成，进一步增强了 enterprise readiness。

Write Once, Read Many（WORM）

Write once, read many（WORM）是一种数据存储模型，确保数据一旦写入，就不能被修改或删除。这种 immutability 使 WORM 非常适合保存必须因 regulatory、legal 或 audit purposes 而保持不变的 records。常见例子包括 financial records、medical data、logs 和 compliance-related documents。通过长期保证 data integrity，WORM 帮助组织满足严格 data retention requirements，并保护关键数据免受篡改或意外丢失。

WORM 可以在硬件和软件层面实现。传统 WORM solutions 建立在 optical discs 或 tape drives 等专用硬件上。如今，cloud object storage platforms，例如 AWS S3 Object Lock、Azure Immutable Blob Storage 和 Google Cloud Storage Retention Policies，提供 software-defined WORM capabilities。这些平台允许用户设置 retention periods，在此期间 objects 被锁定，因此数据不能被修改或删除，即使 administrators 也不行。有些系统还支持 legal hold features，可以在特定条件解除前保留数据，不受初始 retention period 限制。

WORM model 在 compliance 和 governance frameworks 中发挥关键作用。Finance、healthcare 和 government 等行业经常受 SEC Rule 17a-4、HIPAA 或 GDPR 等严格 regulations 约束，要求长期、tamper-proof data retention。通过使用 WORM storage，组织可以证明对这些标准的遵守，防范 data-related liabilities，并支持 secure archival 和 audit processes。随着数据量增长和监管审查加强，WORM capabilities 已成为 enterprise storage strategies 的基本要求。

运维方面，StorageGRID 为 scale 下的 centralized management 而设计。其 web-based interface 和 automation features 让 IT teams 可以监控 system health、配置 multisite deployments，并对海量 datasets 执行 policies。对 Kubernetes CSI drivers 的支持，以及与 NetApp cloud-native tools 的集成，使它在 containerized 和 hybrid environments 中越来越可行。

5.4.9 Everpure

对于 Iceberg lakehouses，Everpure，也就是以前的 Pure Storage，提供了一个 high-end storage layer，可以跟上 data-hungry applications 不断增长的需求。其 enterprise focus、predictable performance 和 streamlined operations，使其非常适合那些希望以最低风险和最高效率现代化数据平台的组织。

Everpure 是高性能 storage hardware 和 software solutions 的领先供应商，以 all-flash storage arrays 闻名。随着 FlashBlade 和 S3-compatible object storage interface 的推出，Everpure 进入 object storage 市场，并强烈强调 speed、simplicity 和 enterprise integration。对于要求 consistent high throughput、predictable latency 和 easy operational management 的 Iceberg lakehouses，Everpure 提供了一个有吸引力的选项。

Everpure object storage offering 的核心是 FlashBlade，这是一个 scale-out file and object storage platform，针对 analytics、backup 和 AI/ML workloads 优化。它原生支持 S3 API，因此可以以最小配置作为 Apache Iceberg table storage 的 backend。FlashBlade 面向规模化 performance 而设计，支持低延迟访问大容量数据，并为数千个 parallel clients 提供一致 throughput。

这种 performance profile 使 Everpure 对 high-concurrency environments 尤其有吸引力。在这类环境中，Iceberg 的 metadata 和 data 分离，可能在 query planning 和 execution 期间导致大量 small-object operations。FlashBlade 快速、可靠地服务这些 operations 的能力，可以减少 query times，并提升 interactive workloads 的 responsiveness。

除了速度，Everpure 还强调 operational simplicity。其 storage systems 以 turnkey appliances 交付，具备 automated provisioning、intelligent performance tuning 和 seamless upgrades。Pure1 management platform 提供 cloud-based monitoring、predictive analytics 和 proactive support features，减少 administrative overhead 并提高 system reliability。对于管理 Iceberg lakehouse 的 platform teams，这意味着可以把更多时间花在构建 data products 上，而不是调优基础设施。

Security 和 compliance features 也很强。FlashBlade 支持 encryption at rest、secure multitenancy 和 detailed access controls。Audit logs 以及与 LDAP 或 Active Directory 等 identity providers 的集成，支持 enterprise governance requirements。这些能力使 Everpure FlashBlade 适合需要严格 data controls 且不愿牺牲 performance 的受监管行业。

LDAP 和 External Identity Providers

LDAP（Lightweight Directory Access Protocol）是一种访问和管理 directory services 的协议，这些 directory services 在 networked environment 中存储 user identities、roles、permissions 和其他信息。LDAP 常见实现包括 Microsoft Active Directory、OpenLDAP 或 389 Directory Server。这些系统以 hierarchical structure 存储 identity data，允许 applications 认证用户、查找 user attributes，并管理 access control。LDAP 长期以来都是 on-premises identity management 的基石，支持 centralized authentication，并简化内部系统中的 user provisioning。

External identity providers（IdPs）将 identity management 扩展到 cloud 和 federated systems。这些 providers，例如 Azure Active Directory、Okta、Auth0 和 Google Identity，提供 authentication 和 authorization services，可跨 cloud applications、third-party services 和 enterprise systems 集成。许多支持 SAML、OAuth 2.0 和 OpenID Connect 等标准，支持 single sign-on（SSO）、multifactor authentication 和 conditional access。External IdPs 将 authentication 从单个 applications 中解耦出来，提供集中方式来执行 security policies、监控 identity activity，并减少 password sprawl。

LDAP 和 external identity providers 共同构成保护 hybrid 和 multicloud environments 中访问安全的关键能力。组织通常将 LDAP 与 external IdPs 集成，以连接 on-premises 和 cloud identity systems，使用户无论应用部署在哪里都能无缝访问。这种 hybrid model 同时支持 legacy applications 和现代 SaaS platforms，提供 flexibility、scalability 和更强 governance。随着 identity 成为企业安全的新边界，稳健的 directory protocols 和 cloud-native identity providers 对保护数据、执行合规和支持跨用户与设备的安全协作至关重要。

虽然 Everpure 常被视为 premium solution，但当 performance、simplicity 和 support 是最高优先级时，它可以交付价值。运行 latency-sensitive analytics、训练 large-scale ML models，或希望在单一 high-throughput platform 上整合基础设施的组织，可能会发现这项投资非常值得。

5.4.10 Dell ECS

对于希望获得成熟、可扩展且安全的 object storage system 来支持 Iceberg lakehouse 的组织，Dell ECS 提供 enterprise reliability 和 S3 compatibility。它在受监管、重视安全的 environments 中尤其有价值，在这些环境中 hybrid 或 on-premises storage 是硬性要求，而不是偏好。

Dell EMC Elastic Cloud Storage（ECS）是 Dell 的 enterprise-grade object storage platform，面向 scalability、resiliency 以及与 hybrid 和 on-premises infrastructure 的深度集成而设计。ECS 强调 durability、regulatory compliance 和 multitenancy，并兼容 S3 API，使其成为 enterprise environments 中 Iceberg lakehouses 的可行 storage backend，尤其适合 cloud options 受限或偏好 hybrid architectures 的场景。

ECS 面向跨多个 sites 的大规模 object storage deployments 而设计，内置支持 georeplication、erasure coding 和 software-defined storage。这些能力使它非常适合 disaster recovery、high availability 和 long-term data preservation。其设计也支持 horizontal scaling，因此组织可以随着数据需求增长，增量增加 capacity 和 performance。

对于 Apache Iceberg，Dell ECS 提供通过 S3 API 存储和检索 table data 与 metadata 所需的 object storage semantics。它与多种 query engines 和 data processing tools 集成，包括 Apache Spark 和 Presto，并可以作为 fully on-premises 或 hybrid environments 中 cloud object stores 的 drop-in replacement。这种灵活性对需要维护 data sovereignty 或在严格监管环境中运营的组织尤其有价值。

从 performance 角度看，ECS 针对 high-throughput workloads 和 concurrent object access 做了调优，与 Iceberg 中 frequent metadata reads 和 data file scans 的模式很契合。与许多 enterprise storage systems 一样，要实现 peak performance，通常取决于对 networking、storage pools 和 replication policies 的仔细配置。ECS deployments 受益于周到的 infrastructure planning 和 proactive monitoring，以确保响应保持一致。

ECS 的突出之处在于对 multitenancy 和 governance 的支持。它允许组织按 tenant 隔离 storage environments，应用 granular access controls，并执行 retention 和 compliance policies。这些功能使它成为需要在 business units 或 external clients 之间安全 partition storage 的 environments 的强候选方案。

Security 和 compliance 是 ECS 价值主张的核心。它提供 robust access controls、encryption at rest and in transit、WORM capabilities 和 audit logging。与 Active Directory 和其他 enterprise identity providers 的集成支持 centralized policy enforcement。它为 mandated retention periods 保留 objects 的能力，支持 healthcare、finance 和 government 中的 use cases。

ECS 通过 centralized administrative interface 管理，提供跨 clusters 的 system health、capacity usage 和 policy enforcement 可见性。Dell 还提供 ECS 与其更广泛 infrastructure ecosystem 的紧密集成，让客户可以使用 Dell networking、compute 和 storage technologies 构建端到端数据平台。

5.4.11 Wasabi

Wasabi 为 Iceberg lakehouses 提供一种轻量、可靠且成本可预测的 object storage option。它的完整 S3 API compatibility 和无意外 pricing model，使它非常适合希望控制 cloud costs、同时支持现代数据平台的组织。

Wasabi 是一家 cloud object storage provider，以简单性和极具竞争力的价格著称。它被定位为 “hot cloud storage”，提供 S3-compatible object storage，但没有传统 cloud services 的复杂性和可变成本。对于构建 cost-conscious Iceberg lakehouses，或管理大量频繁访问数据的组织来说，Wasabi 是一个有吸引力的替代方案。

Wasabi 的 storage model 设计得非常直接：按每 TB 固定月费收费，不收 data egress 或 API requests 费用。这消除了 budgeting 中许多不确定性，并简化 operational planning。对于涉及 frequent table scans、metadata reads 和 periodic snapshot rewrites 的 Iceberg workloads，这种 pricing structure 相比按访问或传输计量的 tiered cloud services，可能带来显著成本节省。

从技术角度看，Wasabi 支持 S3 API，因此兼容更广泛的 Iceberg-integrated tools 和 engines 生态。Apache Spark、Trino、Dremio 和其他 compute engines 可以像与 Amazon S3 或其他 S3-compatible system 交互一样，与 Wasabi storage 交互，只需要很少配置更改。

Wasabi 面向 high availability 和 consistent throughput 设计，尤其适合 read- 和 write-intensive workloads。虽然它可能无法匹配某些 premium-tier cloud storage services 或 all-flash on-premises systems 的 ultra-low latency，但对大多数 analytical scenarios 表现可靠，尤其是 batch-oriented 或 periodic access patterns。

Wasabi 的简单性也延伸到 operating model。它没有需要管理的 storage tiers，没有为 cost optimization 配置 lifecycle rules 的必要，也无需预算 egress。这让它对较小 data teams、startups、educational institutions，或希望避免 cloud lock-in 或意外账单波动的组织特别有吸引力。Wasabi 还集成 backup、archiving 和 media management tools，将其实用性扩展到非分析 workloads。

在 security 方面，Wasabi 包含 immutable buckets，用于 ransomware protection、encryption at rest 和 MFA support 等功能。虽然它不像 AWS 或 Azure 等 enterprise-focused platforms 那样提供同等粒度的 access control，但它满足大多数 analytics use cases 的核心安全需求，并通过 S3-compatible authentication schemes 与 identity providers 集成。

Wasabi 的主要考虑是它的定位：它专注于 storage，并不提供 hyperscale providers 那样更广泛的 cloud services 或 data ecosystem。因此，它最适合在 modular architecture 中作为 storage backend，而 compute 和 catalog services 分别托管。这使它非常适合建立在开放、解耦架构之上的 Iceberg lakehouses，在这些架构中，flexibility、transparency 和 cost control 是优先事项。

5.5 基于 Requirements 选择 Storage

现在我们已经探索了核心 storage requirements，并审查了一系列 storage solutions，接下来通过一组示例将这些思想整合起来。本节会展示一系列 hypothetical scenarios，并将它们映射到 5.1 节引入的 requirement categories：performance、security、integrity 和 operational costs。每个 scenario 都强调不同优先级如何影响 storage decisions。

这些示例不是处方式建议。相反，它们展示当你将 Iceberg 应用于不同分析需求时，如何思考不同 storage options 之间的 tradeoffs。实践中，大多数组织会在单一 storage platform 上支持多个 use cases。你不太可能因为每个 use case 不同而选择不同 storage systems，因为这会带来运维和财务开销。相反，你很可能收敛到一个在现有 cloud provider、regulatory obligations 和 infrastructure maturity 约束内，能够满足最广泛需求的 solution。

例如，如果你的架构锚定在 AWS 中，Amazon S3 会自然塑造你的 storage design。如果你在 on premises 运行 Spark 或 Hive，HDFS 可能仍然是核心，并可能由 MinIO 镜像以获得 cloud compatibility。这些更广泛因素，包括 deployment considerations、cloud strategy、compliance boundaries 和 existing tooling，往往比单个技术 feature 更重要。

尽管如此，下面的 scenarios 仍然是有用的思维练习。它们提供一个视角，用来评估特定 requirements 如何偏向或排除 shortlist 中的某些选项。可以用它们测试 assumptions、pressure-test candidate solutions，并理解哪里可能需要 compromises。目标不是给出 one-size-fits-all answer，而是为你提供一个实践模型，帮助你将 storage choices 与组织 priorities、constraints 和长期 Iceberg lakehouse strategy 对齐。

5.5.1 Performance Requirements

Performance 通常是 storage system 最可见、也最容易被严格审视的属性，尤其是当用户在 data access 或 query execution 中感受到延迟时。但 “performance” 不是单一 metric；它包含 throughput、latency、concurrency 和 consistency，这些都会影响 Iceberg lakehouse 支持不同 workloads 的能力。我们来探索几个 performance-driven 的 hypothetical scenarios，以说明不同需求如何指导选择。

场景：高并发 Interactive Dashboards

某个组织运行一组由 BI engine 驱动、查询 Iceberg tables 的 real-time dashboards。数十名用户在工作时间与这些 dashboards 交互，触发大量小而频繁的 reads。在这种情况下，low-latency object retrieval 和 concurrent load 下的一致性能非常关键。

Everpure 或 Amazon S3 这类 storage solution，具备 intelligent tiering 和 request-based optimization，可能很理想。Everpure 的 low-latency flash hardware 提供 deterministic access times，而 Amazon S3 提供 elastic scalability，可以吸收 peak usage patterns。相比之下，Ceph 虽然灵活，但可能需要大量调优才能满足这些 interactive latency needs。

场景：夜间大规模 Batch ETL Processing

一个 data engineering team 每晚处理数百 GB raw event data，将其转换为 partitioned Iceberg tables。该过程受 throughput 限制，可以容忍 latency spikes，只要总 job duration 保持在几小时窗口内即可。

在这种情况下，优先 sustained throughput 而不是 per-object latency 的系统，例如 HDFS、Google Cloud Storage（GCS）或 MinIO，可能已经足够。HDFS 在 legacy environments 中仍然适合 large、sequential reads；GCS 提供 strong consistency 和可预测 throughput，尤其当它与 compute colocated 时。对于 traffic patterns 稳定的 self-managed clusters，选择 MinIO 时，cost efficiency 也可能成为考虑因素。

场景：时间敏感的 Machine Learning Feature Pipelines

一个 machine learning team 需要将 features 从 Iceberg tables 加载到运行在 GPU clusters 上的 training jobs。因为这些 jobs 已经排期，而且让 GPU idle 很昂贵，因此稳定、low-latency 的 training data access 很重要。

在这种场景中，Azure Data Lake Storage（ADLS）或结合 caching strategies 的 Amazon S3 可能合适。二者都能很好地与 cloud-native compute 集成，且其 scalable access models 有助于确保 training jobs 不被 storage retrieval 卡住。Wasabi 这样的系统虽然可靠，但在规模化并发访问下，取决于地理位置和网络 setup，可能无法提供相同 latency profile。

场景：非紧急时效的 Regulatory Queries

Compliance team 对存储在 Iceberg tables 中的 archived data 运行 scheduled reports。这些 queries 是 batch oriented，不需要快速响应，但底层数据必须保持 available 和 consistent。

NetApp StorageGRID 或 Dell ECS 在这里可能合适，因为二者都支持大规模 object access，并具备 enterprise durability 和 policy-based archival。它们的 performance characteristics 适合 long-running scans，且其执行 data governance policies 的能力支持 compliance needs。在这种情况下，performance 是次要考虑，主要由 reliability 和 cost 塑造。

这些例子说明，把 performance goals 按 workload type 和 user expectations 拆解后，可以引导你走向针对特定 access patterns 优化的 storage systems。许多环境都包含多种 workloads。一个对某个 use case 表现出色的 solution，可能在另一个 use case 中表现不足。因此，不只要评估 average performance，还要评估在你最严苛条件下的 performance profile。

5.5.2 Security Requirements

处理敏感数据、受监管行业或 multitenant environments 时，security requirements 往往优先于 performance 或 cost。这些 requirements 可能包括 access control、encryption、auditability，以及对 HIPAA、GDPR 或 FINRA 等合规标准的支持。我们来看几个 hypothetical scenarios，说明具体 security concerns 如何影响 Iceberg lakehouse 的 storage system 选择。

场景：受 HIPAA 法规约束的 Healthcare Data

一家 healthcare analytics firm 使用 Iceberg tables 管理 patient records 和 clinical trial data。Access 必须被严格控制，所有 data at rest 必须加密，并且所有访问和修改都必须保留 audit trails。

在这种 context 中，NetApp StorageGRID 或 Azure Data Lake Storage（ADLS）等 enterprise-grade solutions 非常适合。二者都提供 WORM capabilities、granular access policies，并与 identity providers 集成以强制访问控制。尤其是 ADLS，它与 Azure Active Directory 集成，并支持 fine-grained ACLs，可以将 security controls 强制到 file level。

场景：带受限用户角色的 Internal R&D Data

一家大型企业在存储于 Iceberg tables 的 proprietary data 上运行 machine learning models。Access 必须按 business unit 限制，使不同 teams 对同一 datasets 拥有不同 visibility levels。

配置正确时，Ceph 和 MinIO 都支持具有 role-based access controls 的 multitenant deployments。Ceph 可以与 Keystone 或 LDAP 集成以执行 centralized identity policies，而 MinIO 提供 IAM-like capabilities，并可通过 external identity providers 扩展。这些系统提供灵活性，但相比 cloud-native platforms，可能需要更多 manual configuration。

场景：具有强 Auditability 需求的 Public Cloud Deployment

一家金融机构在 public cloud 中运行 Iceberg lakehouse，但必须为所有 data access 和 changes 提供 audit trails，包括 encryption key management。Amazon S3 和 Google Cloud Storage 非常适合这一需求，它们提供带 customer-managed keys 的 server-side encryption、object-level access logging，并与 AWS CloudTrail 和 GCP Audit Logs 等 audit services 集成。这些平台让 administrators 可以通过 automation 执行和验证合规性，非常适合既受严格监管、又受益于 cloud scalability 的行业。

场景：跨司法辖区的安全数据共享

一家国际组织需要在多个国家存储和访问 Iceberg tables，每个国家都有自己的 data residency requirements 和 cross-border transfers 法律约束。

Dell ECS 和 StorageGRID 提供 geodistributed object storage，支持 policy-based data placement 和 retention。这些系统让组织可以控制数据存储在哪里、如何复制，从而支持 jurisdictional compliance，而不依赖 public cloud providers。Encryption、access auditing 和 lifecycle governance 支持也会增强整体 security posture。

Security requirements 可能很微妙，也高度依赖上下文。仅有 encryption 和 access controls 并不够；重要的是这些能力如何与组织 policies 对齐、能否轻松审计，以及能否与现有 identity 和 compliance infrastructure 无缝集成。在很多情况下，正确决策不只是技术问题，也与法律义务和内部风险容忍度有关。

5.5.3 Integrity Requirements

Integrity requirements 聚焦于存储在 Iceberg lakehouse 中的数据的 durability、recoverability 和 consistency。这些考虑对于 mission-critical workloads、compliance-driven retention needs，或对数据丢失容忍度很低的 environments 至关重要。虽然 Iceberg 通过其 snapshot model 确保 metadata consistency 并支持 rollback，但底层 storage system 的可靠性决定了这些 snapshots 和 files 在需要时是否仍然可用。以下 scenarios 展示 integrity concerns 如何指导 storage selection。

场景：地理分布企业中的 Disaster Recovery

一家全球 logistics company 跨多个 regions 管理 Iceberg tables。它需要 multisite redundancy，并且在 site failure 发生时快速恢复，同时不冒 data inconsistency 或 recent updates 丢失的风险。NetApp StorageGRID 和 Dell ECS 提供内置 georeplication 和 policy-driven data protection，确保 object replicas 分布在多个 data centers 中。这些平台也支持 versioning、object locking 和 lifecycle rules，有助于长期保持 integrity，同时满足 legal retention requirements。Audit logging 和 restore capabilities 的支持，也为 regulated environments 提供额外 resilience。

场景：带可验证不可变性的长期保留

某政府机构在 Iceberg tables 中维护 historical records，这些记录必须保存十年以上，并且有严格的 immutability 和 tamper resistance 要求。Amazon S3、Wasabi 和 NetApp StorageGRID 都支持 object locking 和 WORM capabilities。这些功能会在定义的 retention period 内防止 deletions 或 overwrites，支持 legal 和 archival mandates。S3 还允许组织使用 compliance-mode locks 在 bucket level 执行这些 policies，而 Wasabi 将 immutability 作为 storage model 的默认组成部分，简化安全长期存储。

场景：频繁 Schema Evolution 和 Metadata Updates

一家 startup 正在构建基于 Iceberg 的 feature store，并快速迭代 schema definitions。由于持续 metadata commits 和 schema changes，metadata integrity 和 file references reliability 必须在频繁变化中得到保持。

Google Cloud Storage 和 Azure Data Lake Storage 提供 strong consistency guarantees，包括 atomic object overwrites 和 immediate object visibility。这些属性降低 stale 或 partially visible metadata 的风险，确保 snapshot creation 和 commit rollbacks 等 Iceberg operations 即使在高频写入下，也能可预测运行。

场景：网络可靠性有限的 Edge Deployment

一个 industrial IoT platform 在 distributed edge architecture 中存储 Iceberg tables，nodes 之间网络连接时断时续。系统必须在 sync windows 不频繁的情况下维持 integrity。

MinIO 和 Ceph 提供 erasure coding 和 self-healing mechanisms，即使在 connectivity 不稳定的 environments 中，也能确保 local durability 和 consistency。当 centralized replication 并不总是可行，且数据必须保持完整直到下一次 synchronization window 时，这些功能至关重要。

Data integrity 是数据平台信任的基础。Iceberg architecture 在 metadata level 提供 safeguards，但底层 storage backend 的 durability 和 resilience，才确保数据在不利条件下仍然完整、可用、可恢复。无论是通过 georeplication、WORM enforcement，还是 strong consistency guarantees，此处正确的 storage decision 都可以防止 silent errors 变成昂贵失败。

5.5.4 Cost 和 Operational Requirements

虽然 performance、security 和 integrity 常常在 architecture planning 中最受关注，但 cost 和 operational overhead 最终决定 storage decisions 的长期可行性。这些 requirements 会塑造团队管理系统、响应变化并保持预算内运行的效率，而这些因素会直接影响 Iceberg lakehouse initiative 的成功。我们来看几个 hypothetical scenarios，它们反映不同成本和运维取舍。

场景：DevOps 能力有限的 Startup 管理增长

一个快速增长的数据团队正在构建 Iceberg platform，但缺少专职 infrastructure engineers。团队优先考虑 ease of deployment、minimal ongoing maintenance 和 predictable monthly costs。

在这种情况下，Wasabi 和 MinIO 具有明显优势。Wasabi 的 flat-rate pricing 消除了不可预测的 egress 或 API costs，而其 managed nature 免去了手工 infrastructure tuning。MinIO 虽然是 self-hosted，但在 containerized environments 中容易部署，并且 operational footprint 轻量，尤其适合 Kubernetes-based stacks。二者都能让团队快速推进，而不被平台运维拖住。

场景：大型企业跨团队整合基础设施

一家 enterprise IT department 正在统一多个 business units 的 analytics workloads。它需要 centralized management、multitenancy 和强 operational controls，以满足 internal SLAs。Dell ECS、NetApp StorageGRID 和 Everpure 就是为这种级别的 operational control 而设计的。这些平台提供 multitenant configurations、policy enforcement、centralized monitoring，并与 enterprise-grade support systems 集成。虽然这些平台更昂贵，但它们可以在规模化下交付可预测 performance 和 governance，降低内部支持负担。

场景：具有 Grant-Funded Workloads 的研究机构

一所大学支持多个 research labs，这些实验室偶尔会有高容量 analytics projects。Usage spikes 不可预测，而 funding 经常绑定短期 grants，预算固定。Google Cloud Storage 和 Amazon S3 提供 pay-as-you-go pricing 和 easy provisioning，使机构无需长期合同就能扩展或收缩。这些服务还与 cloud cost monitoring 和 forecasting tools 集成，帮助实验室按项目跟踪使用情况。对于 cost-conscious institutions，storage classes 和 lifecycle rules 可以进一步降低费用，同时不损害 data availability。

场景：要求 On-Premises Deployment 和 Cost Transparency 的地方政府

某政府机构可能需要在受监管 cloud environment 中部署 Iceberg，例如 AWS GovCloud 或 Azure Government，以满足 compliance 和 data sovereignty requirements。这些 environments 为公共部门 workloads 提供所需的 security 和 isolation，同时仍支持现代 cloud-native architectures。GovCloud 中的 Amazon S3 等 object storage services 提供高 durability，并能与更广泛 Iceberg ecosystem 良好集成。当机构运行在 hybrid 或受限 environments 中，例如 defense 或 intelligence sectors，Ceph 或 MinIO 等开源方案可以部署在 on premises，以保持对基础设施的完全控制。这些系统提供灵活性，并与强调 capital investment 和长期 hardware lifecycle planning，而不是持续 subscription costs 的 procurement models 保持一致。

考虑 cost 和 operational requirements 时，重点不应只是最小化支出，而是最大化长期价值。一个部署便宜但难以管理的系统，可能在 engineering time 上比带自动化控制和企业支持的更昂贵方案还贵。同样，一个高性能但需要持续调优的系统，可能会把资源从更高价值 initiatives 中转移走。通过将 storage decisions 与团队能力、预算约束和 lifecycle expectations 对齐，你是在为 lakehouse 建立 resilience，而不只是让它能上线。

下一章中，我们会将重点转向 ingestion layer，探索数据如何进入 lakehouse、哪些 ingestion patterns 最重要，以及哪些系统可以帮助简化并扩展这一过程。Storage foundation 已经就位，现在该看看数据如何进来了。

小结

Storage layer 是任何 Apache Iceberg lakehouse 的基础组件，会影响 performance、scalability、cost 和 compliance。

在选择 storage solution 之前，必须基于 file-retrieval performance、security、data integrity 和 operational costs 定义 requirements，理想情况下，这是结构化审计的一部分。

Storage systems 通常分为两类：block storage，它提供 low-latency performance 但 operational complexity 更高；object storage，它更可扩展，也更 cloud native。

Apache Parquet 是 Iceberg 的默认 file format，因为它的 columnar design 和丰富 metadata support 能支持高效 pruning 和 high-performance queries。

S3 API 已成为 object storage access 的行业标准，支持 cloud 和 on-premises systems 之间的广泛 interoperability。

广泛 storage solutions 支持 Iceberg deployments，包括 Amazon S3、Google Cloud Storage、Azure Blob Storage 和 ADLS 等 cloud services，也包括 MinIO、Ceph、NetApp StorageGRID、Dell ECS、Everpure 和 Wasabi 等 on-premises options。

每种 storage platform 都在 cost、complexity、performance 和 governance 上有取舍。没有一种 solution 适合所有 use cases。

最终选择应由真实世界 requirements 指导，例如 interactive latency、legal compliance、disaster recovery 或 budget constraints。假设性示例展示了不同需求如何映射到不同技术。

通过将 storage layer 与审计中发现的具体 requirements 对齐，你可以确保 Iceberg lakehouse 技术上可靠、运维上可持续，并与业务目标一致。