Skip to main content

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:
The Hadoop catalog is not safe for concurrent writes on local filesystems or S3. Use it with HDFS or an atomic-rename-capable filesystem.

Catalog Operations

All catalogs implement the Catalog 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 the Schema 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:
Users don’t need to know about partitioning when querying! This query automatically uses the partition:

Creating Tables

Combine schemas and partition specs to create tables:

With Properties

Specify table properties at creation time:

Table Metadata

The Table 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 using IcebergGenerics:

Filter Expressions

Iceberg supports rich filter expressions:

Update Operations

All update operations use a builder pattern with a commit() 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

Use try-with-resources for scans and iterables:
  • Too fine: Many small files, slow metadata operations
  • Too coarse: Poor query pruning, read unnecessary data
  • Target: 500MB-1GB per partition
Iceberg uses optimistic concurrency. Writes may need to retry:
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