Java API Quickstart
This guide provides a comprehensive introduction to the Apache Iceberg Java API. You’ll learn how to programmatically create and manage Iceberg tables, work with schemas and partitions, and perform read and write operations.The Java API is the reference implementation for Iceberg. All code examples in this guide use real patterns from the Iceberg source code.
Dependencies
Add the required dependencies to your project:Working with Catalogs
Catalogs are the entry point for working with Iceberg tables. They provide methods to create, load, rename, and drop tables.Hive Catalog
The Hive catalog uses a Hive Metastore to track Iceberg tables:You can optionally use Spark’s Hadoop configuration:
Hadoop Catalog
The Hadoop catalog is a file-based catalog suitable for HDFS and S3:Catalog Operations
All catalogs implement theCatalog interface:
Creating Schemas
Schemas define the structure of your table. Iceberg schemas are strongly typed and support nested structures.Basic Schema
Create a schema using theSchema class:
About type IDs:
- Type IDs must be unique within a schema
- They enable schema evolution and column mapping
- Iceberg automatically reassigns IDs when creating tables
Complex Schema
Iceberg supports nested types (structs, lists, maps):Supported Types
Iceberg supports the following types:Converting Schemas
Convert schemas from other formats:Creating Partition Specs
Partition specs define how Iceberg groups records into data files. Unlike Hive, Iceberg partitioning is hidden from users.Basic Partitioning
Advanced Partitioning
Iceberg supports multiple partition transforms:Real-World Example
Partition a logs table by hour and log level:Creating Tables
Combine schemas and partition specs to create tables:With Properties
Specify table properties at creation time:Table Metadata
TheTable interface provides access to table metadata:
Scanning Tables
Scan tables to read data.File-Level Scanning
Get the list of files to read:Time Travel
Read from historical snapshots:Row-Level Scanning
Read actual row data usingIcebergGenerics:
Filter Expressions
Iceberg supports rich filter expressions:Update Operations
All update operations use a builder pattern with acommit() call.
Appending Data
Schema Evolution
Modify the schema without rewriting data:Partition Evolution
Change how new data is partitioned:Updating Properties
Deleting Data
Expiring Snapshots
Remove old snapshots to save space:Transactions
Group multiple operations into a single atomic commit:Branching and Tagging
Create branches and tags for experimentation and auditing.Creating Branches
Creating Tags
Writing to Branches
Reading from Branches
Managing Branches and Tags
Best Practices
Always Close Resources
Always Close Resources
Use try-with-resources for scans and iterables:
Use Appropriate Partition Granularity
Use Appropriate Partition Granularity
- Too fine: Many small files, slow metadata operations
- Too coarse: Poor query pruning, read unnecessary data
- Target: 500MB-1GB per partition
Handle Concurrent Writes Gracefully
Handle Concurrent Writes Gracefully
Iceberg uses optimistic concurrency. Writes may need to retry:
Maintain Tables Regularly
Maintain Tables Regularly
Regularly run maintenance operations:
- Expire snapshots: Remove old history
- Remove orphan files: Clean up unreferenced files
- Compact files: Merge small files
- Rewrite manifests: Optimize metadata
Next Steps
API Documentation
Complete Java API reference
Schema Evolution
Learn safe schema evolution
Performance Tuning
Optimize table performance
Configuration
Table and catalog configuration