Skip to main content

GCP Lakehouse Writer

GCP Lakehouse Writer writes initial load and change data capture (CDC) data to Apache Iceberg tables stored in Google Cloud Storage (GCS). Use this writer when you want Striim to write to the Google Cloud lakehouse path by using GCS as the data lake, GCP Managed Apache Spark (formerly Dataproc) as the compute engine, GCP Lakehouse Runtime Catalog (formerly BigLake Metastore Catalog) as the catalog, and GCS as the external staging area.

GCP Lakehouse Writer feature summary

Category

Details

Supported target path

Google Cloud lakehouse: GCS data lake, GCP Managed Apache Spark compute, GCP Lakehouse Runtime Catalog, and GCS external staging.

Target adapter

GCPLakehouseWriter

Flow Designer component

Google Cloud Lakehouse, under Data Warehouses

Supported workloads

Initial load and CDC workloads from Striim-supported sources.

Supported write modes

APPENDONLY for initial snapshot loads; MERGE for CDC workloads.

Catalog endpoint types

IcebergRESTCatalog and CustomIcebergCatalogForBigQuery.

Recommended catalog mode

REST catalog mode for new deployments when prerequisites are met.

Credential vending

Supported only in REST catalog mode when the Google Cloud catalog is configured for credential vending.

Schema creation

Supported during initial load when the source sends schema creation events. For database initial loads, enable schema creation on the source.

Schema Evolution

Supported for selected source DDL operations, including namespace and table creation, add/modify/drop column, drop table, and truncate table. Unsupported DDL operations halt the application.

Batching

Controlled by UploadPolicy, with eventcount and interval sub-policies.

Parallel initial load

ParallelThreads can accelerate APPENDONLY initial loads when the Spark cluster has enough executor capacity.

Optimized merge

OptimizedMerge supports partial-image CDC events in MERGE mode when events include updated fields and key fields.

Recovery

At-least-once delivery. In APPENDONLY mode, duplicate rows may appear after restart because reprocessed events are not de-duplicated.

Key limitations

REST catalog mode requires a bucket-root IcebergTablesLocation; partitioned tables are not created automatically; Spark writes Iceberg TIME values as strings; in MERGE mode, the only supported special character in table names is underscore (_).

When to use GCP Lakehouse Writer

Use GCP Lakehouse Writer when you want Striim to write initial-load or CDC data to Apache Iceberg tables in Google Cloud, with GCS for table storage and external staging, GCP Managed Apache Spark for write execution, and GCP Lakehouse Runtime Catalog for table metadata. Review the catalog mode, bucket path, schema creation, and delivery semantics before you build the application because those choices affect permissions, table location, recovery behavior, and CDC processing.

image1.png

Key considerations

Catalog mode selection

GCP Lakehouse Writer supports both REST and custom catalog modes.

REST catalog mode is recommended for new deployments because it:

  • uses the standardized Apache Iceberg REST API

  • supports credential vending for fine-grained access control

  • supports BigQuery queries using fully qualified project.catalog.namespace.table naming

  • improves interoperability for multi-engine access to Iceberg tables

  • is the mode expected to receive priority for future enhancements

Custom catalog mode remains supported and can be used when:

  • you need to integrate with existing Iceberg tables that were created with the custom catalog

  • you prefer standard BigQuery dataset.table naming for queries

  • your organization has existing infrastructure or tooling built around the custom catalog and BigQuery

After you create Iceberg tables with one catalog endpoint type, continue using the same endpoint type for those tables. Switching catalog modes for existing tables is not supported and can lead to metadata inconsistencies.

REST catalog bucket path limitation

When REST catalog mode is used, IcebergTablesLocation must use a bucket-root path such as gs://my-bucket or gs://my-bucket/. Do not use a subdirectory path such as gs://my-bucket/warehouse.

Custom catalog mode supports subdirectory paths.

Credential vending

Credential vending is available only in REST catalog mode. In this model, GCP Lakehouse Runtime Catalog returns short-lived, down-scoped storage credentials for Cloud Storage access. When credential vending is enabled, Managed Apache Spark's default service account does not need direct GCS bucket permissions for table data access; access is controlled through BigLake IAM roles.

The Striim CredentialVending setting must match the catalog configuration in Google Cloud (see GCP Lakehouse Runtime Catalog Connection Profile:

  • Enable CredentialVending in the Striim GCP Lakehouse Runtime Catalog Connection Profile only when the Google Cloud catalog uses credential vending.

  • Disable CredentialVending when the Google Cloud catalog uses end-user credentials see GCP Lakehouse Runtime Catalog Connection Profile:).

When credential vending is enabled, the GCP Lakehouse Runtime Catalog service account still needs storage permissions to the staging bucket for accessing Striim’s batch metadata. The GCP Managed Apache Spark runtime service account still needs the required BigLake permissions to access the catalog and obtain vended credentials. The runtime service account still needs storage permissions for the external staging bucket.

Writer behavior and planning

Review these behavior details before you build a GCP Lakehouse Writer application. These concepts affect catalog planning, table creation, query access, batch timing, and schema change handling.

Initial schema creation

GCP Lakehouse Writer can create Iceberg namespaces and target tables during initial load when the source sends schema creation events.

For relational database initial loads, enable schema creation on the source. For Database Reader, set Create Schema to true. Auto schema creation can be performed from RDBMS sources such as Oracle, SQL Server, MySQL, PostgreSQL, and other JDBC-compatible databases supported by Database Reader.

During the snapshot load, the source sends DDLs for namespace creation followed by table creation. GCP Lakehouse Writer executes those DDLs one after another on the compute engine. After the DDLs complete, snapshot data is written to the target tables.

For source-to-Iceberg Spark data type mappings, see Supported data types in the GCP Lakehouse Writer programmer's reference.

Query target tables

The BigQuery query format depends on the catalog endpoint type.

Custom catalog mode

When custom catalog mode is used, tables are available inside the BigQuery dataset and can be queried with standard BigQuery dataset and table naming:

SELECT * FROM dataset_name.table_name;

Avoid creating standard BigQuery tables with the same names as Lakehouse tables in the same dataset. Name conflicts can cause query ambiguity or errors.

REST catalog mode

When REST catalog mode is used, query tables with fully qualified project, catalog, namespace, and table naming:

SELECT * FROM <project name>.<lakehouse catalog name>.<namespace>.<table name>;

Example:

SELECT * FROM my-gcp-project.my-biglake-catalog.sales_db.orders;

This naming convention provides better isolation and lets BigQuery distinguish between catalog types and sources.

Upload policy

UploadPolicy controls when GCP Lakehouse Writer uploads and processes a batch. A batch is uploaded when either the eventcount threshold or the interval threshold is reached.

Sub-policy

Description

Default

eventcount

Number of events that can be buffered before upload. Use a positive number.

100000

interval

Maximum time events can be buffered before upload. Use seconds (s) or minutes (m).

60s

Upload policy affects performance. A low eventcount creates many batches, which multiplies batch overhead. A very high eventcount creates larger batch files and may delay upload and execution. Use a higher eventcount when there is sufficient source traffic and Spark cluster memory.

DDL support

GCP Lakehouse Writer supports selected DDL operations received from source adapters.

Source DDL operation

GCP Lakehouse Writer behavior

CREATE SCHEMA

Creates the Iceberg namespace.

CREATE TABLE

Processes the statement and creates the target Iceberg table.

ALTER TABLE ... ADD COLUMN

Adds the column to the target table.

ALTER TABLE ... MODIFY COLUMN

Modifies the column in the target table.

ALTER TABLE ... ADD PRIMARY KEY, ADD CONSTRAINT ... PRIMARY KEY, DROP CONSTRAINT, DROP UNIQUE KEY, DROP PRIMARY KEY

Unsupported because Iceberg does not support primary keys or constraints. The application halts.

RENAME TABLE

Unsupported. The application halts.

RENAME COLUMN, including MySQL CHANGE COLUMN used to rename a column

Unsupported. The application halts.

ALTER TABLE ... DROP COLUMN

Drops the target column unless the dropped column is explicitly referenced in ColumnMap; in that exception case, the application halts.

DROP TABLE

Drops the target table.

TRUNCATE TABLE

Truncates the target table.

Architecture and components

Apache Iceberg separates table data, table metadata, catalog operations, and compute. GCP Lakehouse Writer uses that model to write Striim events to Iceberg tables in GCS while delegating batch execution to GCP Managed Apache Spark and catalog operations to GCP Lakehouse Runtime Catalog.

Component

GCP Lakehouse Writer support

Data lake

Google Cloud Storage

Compute engine

GCP Managed Apache Spark (formerly Dataproc), backed by Managed Service for Apache Spark

Catalog

GCP Lakehouse Runtime Catalog (formerly BigLake Metastore Catalog) (see Home > Documentation > Data analytics > Lakehouse > Guides > About the Apache Iceberg REST catalog endpoint and Configure the Lakehouse runtime catalog for Managed Service for Apache Spark using Iceberg 1.10)

External stage

Google Cloud Storage

Target adapter

GCPLakehouseWriter

Spark compute engine

GCP Lakehouse Writer executes snapshot and CDC batches as Managed Service for Apache Spark jobs. Each batch is processed as a Spark application and split into tasks across available executors. Performance depends on worker nodes, memory, batch size, and Spark configuration.

External stage

GCP Lakehouse Writer requires a GCS external staging location. The external stage temporarily stores batch data, metadata, and execution artifacts while Spark jobs are running. The staging location must be reachable from the GCP Managed Apache Spark cluster and should be separate from the Iceberg warehouse location used for target table data.

Set the staging folder with ExternalStagingLocation. You may provide an ExternalStageConnectionProfileName for the external stage. If the data lake and external stage use the same project and authentication information, you may reuse the same GCS Connection Profile.

Authentication and data security

GCP Lakehouse Writer uses the authentication and authorization mechanisms of the Google Cloud services in the write path, including GCS, GCP Managed Apache Spark, and GCP Lakehouse Runtime Catalog. Service accounts and IAM roles authorize runtime operations.

Data stored in GCS is encrypted at rest by Google Cloud. Communication with GCS, Managed Service for Apache Spark, and GCP Lakehouse Runtime Catalog uses the secure network channels supported by the corresponding Google Cloud client libraries.