Skip to main content

MigrateTable

The MigrateTable action migrates an existing non-Iceberg table to Iceberg format. This enables existing tables to leverage Iceberg’s features like time travel, schema evolution, and ACID transactions.

Interface

Overview

Migrating a table to Iceberg involves:
  • Reading the existing table metadata
  • Converting the schema and partition specification
  • Creating Iceberg metadata files
  • Preserving the original data files (no data rewrite required)
  • Optionally creating a backup of the original table
The migration process is metadata-only and doesn’t rewrite data files, making it fast and efficient.

Methods

tableProperties

Sets multiple table properties in the newly created Iceberg table.
Parameters:
  • properties - A map of property key-value pairs to set
Returns: this for method chaining Example:
Properties with the same key will be overwritten by later calls.

tableProperty

Sets a single table property in the newly created Iceberg table.
Parameters:
  • name - The property name
  • value - The property value
Returns: this for method chaining Example:

dropBackup

Drops the backup of the original table after a successful migration.
Returns: this for method chaining Example:
Dropping the backup is irreversible. Ensure the migration is successful and verified before using this option.

backupTableName

Sets a custom table name for the backup of the original table.
Parameters:
  • tableName - The name to use for the backup table
Returns: this for method chaining Example:

executeWith

Sets an executor service for parallel file reading during migration.
Parameters:
  • service - The executor service to use
Returns: this for method chaining Example:
By default, migration does not use an executor service and processes files sequentially.

Result

The Result interface provides statistics about the migration operation.

Methods

migratedDataFilesCount

Returns the number of data files that were migrated to Iceberg. Returns: long - Number of migrated data files

Usage Examples

Basic Table Migration

Migration with Table Properties

Migration with Multiple Properties

Migration with Custom Backup Name

Migration Without Backup

Parallel Migration for Large Tables

Complete Migration Workflow

Best Practices

  1. Test in development first: Migrate a copy of the table in a non-production environment
  2. Keep backups initially: Don’t use dropBackup() until you’ve verified the migration
  3. Set appropriate properties: Configure Iceberg properties for your workload during migration
  4. Use parallel execution for large tables: Enable parallelism for tables with many files
  5. Verify after migration: Check schema, partitioning, and data integrity after migration
  6. Plan for downtime: Coordinate with users as the table may be briefly unavailable
Migration is a metadata-only operation and doesn’t rewrite data files, making it fast even for large tables.

Migration Checklist

Before migrating:
  • Backup the original table metadata
  • Verify table schema compatibility
  • Plan for table downtime window
  • Test migration in development environment
  • Prepare rollback procedure
After migrating:
  • Verify table is readable
  • Check snapshot and metadata
  • Validate row counts
  • Test query performance
  • Update applications to use new table

Supported Table Formats

The specific table formats that can be migrated depend on the implementation:
  • Spark: Hive tables, Delta Lake tables
  • Flink: Hive tables
  • Other engines: Consult documentation for supported formats
Not all table formats support migration in all engines. Check your engine’s documentation for supported source formats.