It‘s possible to read an iceberg table either from an hdfs path or from a hive table. It’s also possible to use a custom metastore in place of hive. The steps to do that are as follows.
Extend BaseMetastoreTableOperations
to provide implementation on how to read and write metadata
Example:
class CustomTableOperations extends BaseMetastoreTableOperations { private String dbName; private String tableName; private Configuration conf; private FileIO fileIO; protected CustomTableOperations(Configuration conf, String dbName, String tableName) { this.conf = conf; this.dbName = dbName; this.tableName = tableName; } // The doRefresh method should provide implementation on how to get the metadata location @Override public void doRefresh() { // Example custom service which returns the metadata location given a dbName and tableName String metadataLocation = CustomService.getMetadataForTable(conf, dbName, tableName); // When updating from a metadata file location, call the helper method refreshFromMetadataLocation(metadataLocation); } // The doCommit method should provide implementation on how to update with metadata location atomically @Override public void doCommit(TableMetadata base, TableMetadata metadata) { String oldMetadataLocation = base.location(); // Write new metadata using helper method String newMetadataLocation = writeNewMetadata(metadata, currentVersion() + 1); // Example custom service which updates the metadata location for the given db and table atomically CustomService.updateMetadataLocation(dbName, tableName, oldMetadataLocation, newMetadataLocation); } // The io method provides a FileIO which is used to read and write the table metadata files @Override public FileIO io() { if (fileIO == null) { fileIO = new HadoopFileIO(conf); } return fileIO; } }
A TableOperations
instance is usually obtained by calling Catalog.newTableOps(TableIdentifier)
. See the next section about implementing and loading a custom catalog.
Extend BaseMetastoreCatalog
to provide default warehouse locations and instantiate CustomTableOperations
Example:
public class CustomCatalog extends BaseMetastoreCatalog { private Configuration configuration; // must have a no-arg constructor to be dynamically loaded // initialize(String name, Map<String, String> properties) will be called to complete initialization public CustomCatalog() { } public CustomCatalog(Configuration configuration) { this.configuration = configuration; } @Override protected TableOperations newTableOps(TableIdentifier tableIdentifier) { String dbName = tableIdentifier.namespace().level(0); String tableName = tableIdentifier.name(); // instantiate the CustomTableOperations return new CustomTableOperations(configuration, dbName, tableName); } @Override protected String defaultWarehouseLocation(TableIdentifier tableIdentifier) { // Can choose to use any other configuration name String tableLocation = configuration.get("custom.iceberg.warehouse.location"); // Can be an s3 or hdfs path if (tableLocation == null) { throw new RuntimeException("custom.iceberg.warehouse.location configuration not set!"); } return String.format( "%s/%s.db/%s", tableLocation, tableIdentifier.namespace().levels()[0], tableIdentifier.name()); } @Override public boolean dropTable(TableIdentifier identifier, boolean purge) { // Example service to delete table CustomService.deleteTable(identifier.namepsace().level(0), identifier.name()); } @Override public void renameTable(TableIdentifier from, TableIdentifier to) { Preconditions.checkArgument(from.namespace().level(0).equals(to.namespace().level(0)), "Cannot move table between databases"); // Example service to rename table CustomService.renameTable(from.namepsace().level(0), from.name(), to.name()); } // implement this method to read catalog name and properties during initialization public void initialize(String name, Map<String, String> properties) { } }
Catalog implementations can be dynamically loaded in most compute engines. For Spark and Flink, you can specify the catalog-impl
catalog property to load it. Read the Configuration section for more details. For MapReduce, implement org.apache.iceberg.mr.CatalogLoader
and set Hadoop property iceberg.mr.catalog.loader.class
to load it. If your catalog must read Hadoop configuration to access certain environment properties, make your catalog implement org.apache.hadoop.conf.Configurable
.
Extend FileIO
and provide implementation to read and write data files
Example:
public class CustomFileIO implements FileIO { // must have a no-arg constructor to be dynamically loaded // initialize(Map<String, String> properties) will be called to complete initialization public CustomFileIO() { } @Override public InputFile newInputFile(String s) { // you also need to implement the InputFile interface for a custom input file return new CustomInputFile(s); } @Override public OutputFile newOutputFile(String s) { // you also need to implement the OutputFile interface for a custom output file return new CustomOutputFile(s); } @Override public void deleteFile(String path) { Path toDelete = new Path(path); FileSystem fs = Util.getFs(toDelete); try { fs.delete(toDelete, false /* not recursive */); } catch (IOException e) { throw new RuntimeIOException(e, "Failed to delete file: %s", path); } } // implement this method to read catalog properties during initialization public void initialize(Map<String, String> properties) { } }
If you are already implementing your own catalog, you can implement TableOperations.io()
to use your custom FileIO
. In addition, custom FileIO
implementations can also be dynamically loaded in HadoopCatalog
and HiveCatalog
by specifying the io-impl
catalog property. Read the Configuration section for more details. If your FileIO
must read Hadoop configuration to access certain environment properties, make your FileIO
implement org.apache.hadoop.conf.Configurable
.
Extend LocationProvider
and provide implementation to determine the file path to write data
Example:
public class CustomLocationProvider implements LocationProvider { private String tableLocation; // must have a 2-arg constructor like this, or a no-arg constructor public CustomLocationProvider(String tableLocation, Map<String, String> properties) { this.tableLocation = tableLocation; } @Override public String newDataLocation(String filename) { // can use any custom method to generate a file path given a file name return String.format("%s/%s/%s", tableLocation, UUID.randomUUID().toString(), filename); } @Override public String newDataLocation(PartitionSpec spec, StructLike partitionData, String filename) { // can use any custom method to generate a file path given a partition info and file name return newDataLocation(filename); } }
If you are already implementing your own catalog, you can override TableOperations.locationProvider()
to use your custom default LocationProvider
. To use a different custom location provider for a specific table, specify the implementation when creating the table using table property write.location-provider.impl
Example:
CREATE TABLE hive.default.my_table ( id bigint, data string, category string) USING iceberg OPTIONS ( 'write.location-provider.impl'='com.my.CustomLocationProvider' ) PARTITIONED BY (category);
Extend IcebergSource
and provide implementation to read from CustomCatalog
Example:
public class CustomIcebergSource extends IcebergSource { @Override protected Table findTable(DataSourceOptions options, Configuration conf) { Optional<String> path = options.get("path"); Preconditions.checkArgument(path.isPresent(), "Cannot open table: path is not set"); // Read table from CustomCatalog CustomCatalog catalog = new CustomCatalog(conf); TableIdentifier tableIdentifier = TableIdentifier.parse(path.get()); return catalog.loadTable(tableIdentifier); } }
Register the CustomIcebergSource
by updating META-INF/services/org.apache.spark.sql.sources.DataSourceRegister
with its fully qualified name