liveBook · Manning

What you will learn in Architecting an Apache Iceberg Lakehouse

A scalable, open-source data platform

by Alex Merced
Foreword by Tim Berglund
Afterword by Adi Polak

Chapter by chapter

Chapter 1: The world of the data lakehouse

The introduction explains the tradeoffs that motivated the data lakehouse and positions Apache Iceberg as an open way to make lake data usable across analytical tools.

1.1 Evolution from database to data lakehouse · 1.2 The rise of data warehouses · 1.3 The move to cloud data warehouses · 1.4 The data lake and the Hadoop era · 1.5 Apache Iceberg: Giving data lakes data warehouse capabilities · 1.6 The data lakehouse: Best of both worlds · 1.7 Summary

What you learn in chapter 1 →

Chapter 2: Apache Iceberg and the lakehouse

Introduces Apache Iceberg as a table format that uses metadata to make files in a data lake behave as relational tables.

2.1 What does it mean that Iceberg is a table format? · 2.2 Why you need a table format · 2.3 How Apache Iceberg manages metadata · 2.4 Key features of Apache Iceberg · 2.5 Apache Iceberg: An open source standard · 2.6 Benefits of Apache Iceberg · 2.6.1 ACID transactions · 2.6.2 How tables evolve · 2.6.3 Time travel and snapshot-based queries · 2.6.4 Hidden partitioning to reduce accidental full-table scans · 2.6.5 Cost efficiency and query performance · 2.7 Apache Iceberg lakehouse components · 2.7.1 Storage layer: Foundation of your lakehouse · 2.7.2 Ingestion layer: Feeding data into Iceberg tables · 2.7.3 Catalog layer: Your entry point to the lakehouse · 2.7.4 Federation layer: Modeling and accelerating data · 2.7.5 Consumption layer: Delivering business value · 2.8 Summary

What you learn in chapter 2 →

Chapter 3: Hands-on with Apache Iceberg

Introduces a hands-on chapter that will build a laptop-based Iceberg lakehouse and use it to create tables, run queries, and visualize results.

3.1 Our example · 3.2 Setting up an Apache Iceberg environment · 3.2.1 Prerequisite: Installing Docker · 3.2.2 Creating the Docker Compose file · 3.2.3 Running the environment · 3.2.4 Accessing services · 3.3 Creating Iceberg tables in Spark · 3.3.1 Populating the PostgreSQL database · 3.3.2 Starting Apache Spark · 3.3.3 Configuring Apache Spark for Iceberg · 3.3.4 Loading data from PostgreSQL into Iceberg · 3.3.5 Verifying data storage in MinIO · 3.4 Reading Iceberg tables with Dremio · 3.4.1 Starting Dremio · 3.4.2 Connecting Dremio to the Nessie catalog · 3.4.3 Querying Iceberg tables in Dremio · 3.5 Creating a BI dashboard from your Iceberg tables · 3.5.1 Starting Apache Superset · 3.5.2 Connecting Superset to Dremio · 3.5.3 Creating a dataset from Iceberg tables · 3.5.4 Building charts and dashboards · 3.6 Summary

What you learn in chapter 3 →

Chapter 4: Preparing for your move to Apache Iceberg

The chapter introduction explains why an Iceberg transition should begin with an audit of the existing platform, input from stakeholders, and requirements that guide later tool choices.

4.1 Auditing your data platform · 4.1.1 Who are the stakeholders? · 4.1.2 What should you ask stakeholders? · 4.1.3 Conducting a technological audit · 4.2 Hamerliva Bank’s audit in action · 4.2.1 Hamerliva Bank interviews its stakeholders · 4.2.2 Hamerliva Bank audits its technology stack · 4.2.3 Hamerliva Bank summarizes the audit findings · 4.3 From audit to requirements: Laying the groundwork for design · 4.3.1 Defining storage requirements · 4.3.2 Defining ingestion requirements · 4.3.3 Defining catalog requirements · 4.3.4 Defining federation requirements · 4.3.5 Defining consumption requirements · 4.4 Hamerliva Bank defines its requirements · 4.4.1 Storage requirements · 4.4.2 Ingestion requirements · 4.4.3 Catalog requirements · 4.4.4 Federation requirements · 4.4.5 Consumption requirements · 4.4.6 From requirements to design · 4.5 Architectural plan and road show · 4.5.1 Hamerliva Bank creates its architectural plan · 4.5.2 Hamerliva Bank conducts a road show · 4.6 Summary

What you learn in chapter 4 →

Chapter 5: Selecting the storage layer

The introduction explains why storage choices matter to an Iceberg lakehouse and identifies Parquet and the S3 API as foundational standards.

5.1 Storage requirements · 5.1.1 Performance requirements for file retrieval · 5.1.2 Security requirements · 5.1.3 Integrity requirements · 5.1.4 Cost and operational overhead requirements · 5.2 Block vs. object storage · 5.2.1 Block storage · 5.2.2 Object storage · 5.3 Storage layer standards · 5.3.1 Apache Parquet · 5.3.2 The S3 API · 5.4 Storage solutions · 5.4.1 Vendor comparison summary · 5.4.2 Hadoop · 5.4.3 Amazon S3 · 5.4.4 Google Cloud Storage · 5.4.5 Azure Blob Storage and ADLS · 5.4.6 MinIO · 5.4.7 Ceph · 5.4.8 NetApp StorageGRID · 5.4.9 Everpure · 5.4.10 Dell ECS · 5.4.11 Wasabi · 5.5 Selecting storage based on requirements · 5.5.1 Performance requirements · 5.5.2 Security requirements · 5.5.3 Integrity requirements · 5.5.4 Cost and operational requirements · 5.6 Summary

What you learn in chapter 5 →

Chapter 6: Architecting the ingestion layer

Introduces the ingestion layer as the point where data enters an Iceberg lakehouse and frames its design around differing delivery and reliability needs.

6.1 Ingestion requirements · 6.1.1 Ingestion throughput and latency · 6.1.2 Reliability and fault tolerance · 6.1.3 Schema management and evolution · 6.1.4 Operational complexity and maintainability · 6.2 Ingestion models and architectures · 6.2.1 Batch ingestion · 6.2.2 Micro-batch and incremental ingestion · 6.2.3 Streaming ingestion · 6.3 How Iceberg manages writes · 6.3.1 Write semantics in Iceberg · 6.3.2 Commit protocols and conflict handling · 6.4 Tools and frameworks for ingestion · 6.4.1 Apache Spark · 6.4.2 Apache Flink · 6.4.3 Apache NiFi · 6.4.4 Fivetran · 6.4.5 Qlik · 6.4.6 Airbyte · 6.4.7 Confluent · 6.4.8 Redpanda · 6.4.9 Cloud-native ingestion services · 6.4.10 Tool selection considerations · 6.5 Applying ingestion requirements in context · 6.5.1 Prioritizing low latency · 6.5.2 Managing high throughput · 6.5.3 Supporting complex transformations · 6.5.4 Handling schema evolution · 6.5.5 Balancing operational overhead · 6.5.6 Considering existing cloud environments · 6.6 Summary

What you learn in chapter 6 →

Chapter 7: Implementing the catalog layer

Introduces the catalog as the metadata and coordination layer of an Iceberg lakehouse and explains why catalog selection must fit organizational needs.

7.1 The role of the catalog in Apache Iceberg lakehouses · 7.1.1 Responsibilities of the catalog · 7.1.2 Catalog interactions with query and processing engines · 7.2 Evaluating catalog requirements · 7.2.1 Performance, availability, and scale · 7.2.2 Metadata governance and lineage · 7.2.3 Security and compliance · 7.2.4 Deployment flexibility and ecosystem compatibility · 7.2.5 Cost and operational overhead · 7.2.6 Catalog federation and mesh architectures · 7.3 Apache Iceberg REST Catalog specification · 7.3.1 Before the Apache Iceberg REST Catalog specification · 7.3.2 The solution · 7.4 Catalog options: Exploring the ecosystem · 7.4.1 Hadoop catalog · 7.4.2 Hive catalog · 7.4.3 JDBC catalog · 7.4.4 Apache Polaris · 7.4.5 Project Nessie · 7.4.6 Apache Gravitino · 7.4.7 Lakekeeper · 7.4.8 AWS Glue Data Catalog · 7.4.9 Dremio catalog · 7.4.10 Snowflake Open Catalog · 7.4.11 Databricks Unity Catalog · 7.5 Choosing the right catalog: Evaluating options through scenarios · 7.5.1 Scenario: A mid-sized data team migrating from Hive · 7.5.2 Scenario: A rapidly scaling cloud-native startup · 7.5.3 Scenario: A multinational enterprise with strict data governance · 7.5.4 Scenario: A SaaS startup prioritizing operational simplicity · 7.5.5 Scenario: A large enterprise with multicloud and federated governance needs · 7.5.6 Scenario: A financial firm requiring daily environment cloning for stress testing · 7.5.7 Scenario: Phased Iceberg migration with query federation across legacy systems · 7.5.8 Scenario: A lightweight lakehouse adoption with Hadoop catalog and Python · 7.6 Catalog-based access control · 7.7 Summary

What you learn in chapter 7 →

Chapter 8: Designing the federation layer

The chapter introduces why an Iceberg lakehouse needs a federation layer and what that layer provides for data spread across systems.

8.1 What data federation is and why it matters · 8.1.1 Common use cases and challenges driving federation needs · 8.1.2 How federation aligns with agility and accessibility · 8.2 Key requirements for federation · 8.2.1 Supporting diverse data sources without duplication · 8.2.2 Ensuring consistent semantics and business logic · 8.2.3 Providing seamless connectivity for analytics tools · 8.3 Introducing Dremio and Trino · 8.3.1 Dremio · 8.3.2 Dremio’s architecture · 8.3.3 Dremio’s connector ecosystem and Iceberg-centric focus · 8.3.4 Dremio’s performance enhancements · 8.3.5 Trino · 8.3.6 Trino’s modular architecture for wide-source support · 8.3.7 Trino’s flexibility and configurability for complex environments · 8.3.8 Trino’s community-led evolution and vendor extensions · 8.3.9 Semantic layer considerations in Trino · 8.4 Deployment models · 8.4.1 Deploying Dremio · 8.4.2 Deploying Trino · 8.5 Federation platform decision scenarios · 8.5.1 Fragmented multisource environment: Trino for connector breadth · 8.5.2 Building a native Iceberg lakehouse: Dremio for Iceberg-native features · 8.5.3 Empowering business users with UI and governed datasets: Dremio · 8.5.4 Lightweight querying of Hudi datasets: Trino via AWS Athena · 8.5.5 On-prem Cloudera modernization: Trino replacing Impala for performance · 8.5.6 Hybrid cloud Iceberg strategy: Dremio bridging on-prem and ADLS · 8.6 Federation alternatives · 8.6.1 Virtualization via shortcuts in OneLake · 8.6.2 AI-native data virtualization with Spice.ai · 8.6.3 Choosing the right fit · 8.7 Summary

What you learn in chapter 8 →

Chapter 9: Understanding the consumption layer

The introduction explains how the consumption layer turns a lakehouse’s technical foundation into useful outcomes and why Iceberg’s openness changes how tools access data.

9.1 Revisiting the benefits of the lakehouse for consumption · 9.1.1 Connecting the lakehouse to the people · 9.2 Revisiting requirements from our audit · 9.2.1 Interpreting requirements for consumption · 9.2.2 Requirements for BI tools · 9.2.3 Requirements for interactive notebook environments · 9.2.4 Requirements for AI and specialized data consumption tools · 9.3 Open interfaces for seamless consumption · 9.3.1 JDBC and ODBC · 9.3.2 Arrow Flight · 9.3.3 Model Context Protocol (MCP) · 9.4 Business intelligence tools in the lakehouse · 9.4.1 Open source BI tools · 9.4.2 Commercial BI tools · 9.4.3 Tools for AI and machine learning workloads · 9.5 Choosing the right consumption tools: Ten illustrated scenarios · 9.5.1 Startup with a data science focus · 9.5.2 Large financial institution with strict governance · 9.5.3 Mid-sized e-commerce platform building embedded analytics · 9.5.4 Decentralized media organization enabling self-service analytics · 9.5.5 Government agency balancing public transparency and internal control · 9.5.6 Healthcare provider with compliance and data locality constraints · 9.5.7 Logistics company unifying real-time operations and historical analysis · 9.5.8 SaaS company offering customizable data access to clients · 9.5.9 Nonprofit organization supporting collaborative research · 9.5.10 Manufacturing company enabling predictive maintenance · 9.6 Summary

What you learn in chapter 9 →

Chapter 10: Maintaining an Iceberg lakehouse

This introduction explains why an Iceberg lakehouse needs proactive maintenance after deployment.

10.1 Problem: Suboptimal data files · 10.1.1 Small files · 10.1.2 Poorly colocated data · 10.1.3 Metadata sprawl · 10.1.4 Merge-on-Read performance hits · 10.2 Solution: Compaction · 10.2.1 What is compaction? · 10.2.2 Target file size · 10.2.3 Files to be included · 10.2.4 Using filters to scope compaction · 10.3 Storage footprint management and data retention · 10.3.1 Running snapshot expiration · 10.3.2 COW vs. MOR: Implications for data retention · 10.3.3 Regulatory considerations for data deletion · 10.4 Exploring Apache Iceberg’s metadata tables · 10.5 Summary

What you learn in chapter 10 →

Chapter 11: Operationalizing Apache Iceberg

The chapter introduction explains why a live Iceberg lakehouse needs consistent, observable maintenance, governance, and recovery practices to remain reliable in production.

11.1 Orchestrating the lakehouse · 11.1.1 Choosing orchestration tools and patterns · 11.1.2 Metadata-driven triggers for proactive maintenance · 11.1.3 Per-table maintenance policies · 11.1.4 Monitoring and alerting integration · 11.1.5 Putting orchestration into practice · 11.2 Auditing the lakehouse · 11.2.1 Using snapshot history for change tracking · 11.2.2 Using branching and tagging for governance · 11.2.3 Implementing file and snapshot retention policies · 11.2.4 Practical retention policy orchestration · 11.2.5 Secure data deletion · 11.2.6 Access auditing and governance · 11.2.7 Practical auditing with Iceberg: Example workflows · 11.3 Disaster recovery in the lakehouse · 11.3.1 The role of the metadata catalog in disaster recovery · 11.3.2 Protecting against data loss and corruption · 11.3.3 Cross-region and multi-environment recovery · 11.3.4 Rollback and time travel in incident response · 11.3.5 Automating disaster recovery procedures · 11.3.6 Validating recovery readiness · 11.3.7 Disaster recovery through automation · 11.3.8 Practical examples: Automating recovery workflows · 11.4 Summary

What you learn in chapter 11 →

Concepts explained in this book

These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.