Iceberg
Iceberg tables can be referenced via Deephaven Schemas using the Extended Storage feature. This provides immediate access for Deephaven to read existing Iceberg tables as Deephaven tables, including support for Iceberg schema evolution and nested Iceberg structures.
Configuration
The easiest way to configure Iceberg tables for Deephaven is to use the built-in inference provided by LoadTableOptions. Advanced users can customize the mapping with a Resolver, or with custom inference options.
A type or catalog-impl key is required for an Iceberg catalog.
Additional parameters may be necessary depending on the type of catalog.
Commonly configured properties may include warehouse and uri.
See Iceberg Catalog properties and your specific catalog implementation for more details on configuration.
An Iceberg table identifier is also required.
If you have a working Spark configuration, that can typically be translated into the necessary Catalog properties by removing the Spark prefix.
For example, the following Spark properties:
Translate into the given BuildCatalogOptions:
See BuildCatalogOptions and LoadTableOptions for more details on these structures.
Deployment
An iris-schemamanagers user is required to deploy the Schema.
Serialization format
Caution
The creation and deployment of a Deephaven Iceberg schema is typically performed programmatically, as shown in the previous sections. Exercise caution when manually creating or editing a schema.
An Iceberg table is referenced in a Deephaven table's schema using an ExtendedStorage element with the attribute type set to iceberg.
Catalog element
The Catalog element is a serialization of the core BuildCatalogOptions.
It is composed of a Name, Properties, and optional HadoopConfig element.
The Properties element is a map of string keys to string values.
The optional HadoopConfig element is optional and is an additional map for Hadoop catalogs. For example:
The injection attribute on the Properties element controls whether Deephaven may automatically add properties that work around known upstream issues and/or supply defaults needed for Deephaven's Iceberg usage.
The valid values are enabled and disabled.
It is recommended to set this to enabled.
Table element
The Table element is a serialization of the core LoadTableOptions.
It is composed of a TableIdentifier, Resolver, and NameMapping element.
The Resolver element contains a ColumnInstructions, Schema, and optional PartitionSpec element.
The ColumnInstructions element contains the mapping from Deephaven column names to Iceberg fieldId, Iceberg partitionFieldId, or type unmapped.
The Schema element contains the Iceberg Schema JSON.
The optional PartitionSpec element contains the Iceberg Partition Spec JSON.
The NameMapping element provides fallback field ids to be used when a data file does not contain field id information.
It has three different types, specified via the type attribute.
The table type means to read the Name Mapping from the Iceberg Table property schema.name-mapping.default (see https://iceberg.apache.org/spec/#column-projection).
The empty type means to not use name mapping.
The json type uses Iceberg Name Mapping JSON.
Full example
Let's assume that we have an existing Iceberg Glue Catalog that contains a table mycatalog.cities with the Iceberg Schema:
To create a new Deephaven Schema with namespace DhExample and table name Cities that references this Iceberg Table, we would execute the following once:
This would result in the following Deephaven Schema:
Deprecated
Deprecated
Warning
This way of configuring Iceberg is deprecated and will be going away in the future release.
Iceberg tables can be read as Deephaven historical tables using the Extended Storage feature. To configure Iceberg, you first use an Iceberg Endpoint, then discover and deploy a schema.
Configuration
The first step to linking Iceberg tables into Deephaven is configuring an IcebergEndpoint, which we refer to as simply an endpoint. The endpoint contains the parameters required to locate and connect to the Iceberg catalog and the data warehouse and the storage-specific parameters required to read the data.
An endpoint is configured using the example below.
Properties
Endpoint properties are a key-value map of Iceberg configuration parameters to their values. Valid property keys can be found in the Iceberg documentation.
Secrets
Endpoint secrets are a key-value map where keys represent Iceberg configuration properties and values represent named references to secrets stored within Deephaven. When needed, the secrets are retrieved from Deephaven and merged into the properties before being used to access Iceberg.
Secrets may be stored either as a property in the Deephaven configuration file or as a JSON map in a protected file on disk. Secrets providers are visited in ascending priority order until one supplies a value or none can be found. More sophisticated secret stores are possible. Contact support for more information.
From Properties
Secrets may be stored in Deephaven configuration files as simple properties, such as s3.access_key=1234secret4321. The default priority of the Properties secrets provider is 100, which can be adjusted using the property PropertiesSecretsProvider.priority.
Warning
Property-based secrets are visible to anyone with access to the server, including access to persistent queries. It is not recommended to store sensitive information such as passwords this way.
From Files
Secrets may be stored in files on disk containing a simple JSON map. This format is more secure and better supports more complex secret values. You may configure multiple secrets files and their priorities using these properties:
| Property | Description |
|---|---|
FileSecretsProvider.name.path | The path to the secrets file for the provider name. |
FileSecretsProvider.name.priority | The priority of the secrets provider name. |
You may provide as many of these as you need, ensuring that each name is unique.
An example file:
Warning
If you supply secrets in files, they are visible to any process with access to that file. For example, if they must be visible to query workers, any user running query workers under the same operating system user can access them. This should be considered before storing secrets such as passwords in files.
See per-user workers for details on configuring different operating system users for different Deephaven users.
Deployment
The endpoint can be deployed to the Deephaven configuration as long as a name has been provided. Once deployed, you may reference the endpoint by name in the schema for Iceberg tables to avoid duplication.
Discovery
Once an endpoint has been configured, you can discover an Iceberg table to create and deploy a Deephaven schema. If you have previously deployed an endpoint, you can retrieve it by name as well.
In the examples above, the Deephaven namespace and table name are derived directly from the Iceberg table identifier. You may specify your own by setting the namespace and tableName properties during discovery.
Example
Below is a complete example that creates an endpoint, discovers a table, deploys a schema, and then fetches the table.