Schedule icon
Webhook icon
Script icon
If icon
SlackIncomingWebhook icon
OutputValues icon

lakeFS Isolated Lakehouse Branching and Atomic Merge Gate

Implement Write-Audit-Publish in data lakes with lakeFS in Kestra. Create isolated branches for ETL validation and merge atomically to main with Slack alerts.

Categories
Data

Running large-scale batch ETL pipelines directly against production object storage (Amazon S3, Google Cloud Storage, or Azure Blob) introduces severe reliability vulnerabilities: intermediate write failures, partial uploads, or corrupt schemas immediately pollute data lake tables, breaking downstream Trino, DuckDB, Snowflake, and BigQuery analytics. Traditional solutions require duplicating terabytes of data or maintaining brittle blue/green storage buckets.

This blueprint orchestrates the industry-standard Write-Audit-Publish (WAP) pattern using lakeFS, bringing Git-like operations (branching, commits, and atomic zero-copy merges) to cloud data lakes. It spawns an ephemeral isolated branch for incoming batch ingestion, validates data contracts in isolation, and executes an atomic merge into production main in sub-seconds. If validation fails, the branch is instantly purged, guaranteeing that dirty data is never exposed to production queries.

How it works

  1. Trigger Ingestion: The flow is triggered on a daily off-peak schedule (0 4 * * *) or via an authenticated Webhook invoked when upstream raw batches land in object storage.
  2. Isolated Branch Creation: Using lakefs-sdk inside an isolated python:3.11-slim container, the flow creates an ephemeral branch (etl-job-<exec_id>) branched directly from production main.
  3. Write & Audit (WAP Pattern):
    • Write: Staged partitions are written exclusively under the isolated branch namespace (lakefs://repo/branch/tables/...).
    • Audit: Runs automated data contract checks (verifying non-null primary keys, valid date ranges, and positive transaction values).
  4. Atomic Publish or Rollback:
    • On Validation Pass: Commits the verified batch with metadata and executes an atomic zero-copy merge into production main. Downstream queries see the new data instantaneously with zero read downtime.
    • On Validation Failure: Drops the ephemeral branch immediately, leaving production completely untouched.
  5. Slack Telemetry: Dispatches an itemized scorecard to Slack with commit hashes and record counts.

What you get

  • Zero-Downtime Atomic Publishing: Millions of records become visible to production readers in milliseconds via metadata pointer updates.
  • Guaranteed Isolation: In-flight batch writes, uncommitted partitions, and corrupted rows are completely invisible to production queries.
  • Instant Zero-Cost Rollbacks: If downstream issues are discovered post-merge, lakeFS enables instant 1-click reverting to the previous commit.
  • Zero Data Duplication: Branching and merging in lakeFS use zero-copy metadata pointers, eliminating multi-terabyte storage duplication costs.

Expected outputs

Downstream BI refresh tasks or catalog indexing jobs can reference the typed metrics produced by output_lakefs_summary:

Output Variable Description Expression Example
repository Target lakeFS repository name {{ outputs.output_lakefs_summary.values.repository }}
records_ingested Number of verified records staged in the batch {{ outputs.output_lakefs_summary.values.records_ingested }}
merge_status Status of the atomic publication (ATOMIC_MERGED_INTO_MAIN or ABORTED_DIRTY_DATA_QUARANTINED) {{ outputs.output_lakefs_summary.values.merge_status }}
commit_hash Unique lakeFS commit identifier for lineage auditing {{ outputs.output_lakefs_summary.values.commit_hash }}
duration_seconds Total end-to-end WAP execution time {{ outputs.output_lakefs_summary.values.duration_seconds }}

Who it's for

  • Data Engineers & Lakehouse Architects building robust, resilient ETL pipelines on Amazon S3, Google Cloud Storage, or MinIO.
  • Analytics Engineers enforcing strict data contract quality gates before publishing daily warehouse tables.
  • Platform Teams seeking Git-like version control, isolation, and instant rollback capabilities for unstructured and tabular data lakes.

Why orchestrate this with Kestra

Building custom WAP scripts requires orchestrating multi-step state machines, credential rotation, and Slack alerting:

  • Native Container Isolation: Runs the official lakefs-sdk inside lightweight Docker containers without host package conflicts.
  • Encrypted Credential Injection: Injects lakeFS API access keys securely from Kestra's encrypted secret store.
  • Dynamic Flow Control: Seamlessly branches into Slack notifications or emergency escalation based on quality audit verdicts.

Prerequisites

  • A running lakeFS server or lakeFS Cloud instance with an active repository created.
  • lakeFS access key ID and secret access key with branch creation and merge permissions.
  • An incoming Slack webhook URL for lakehouse operations alerts.

Secrets

Configure the following secrets in your Kestra namespace or instance settings:

Secret Name Description Example
LAKEFS_ACCESS_KEY_ID Access key ID for the lakeFS server or lakeFS Cloud AKIAIOSFODNN7LAKEFS
LAKEFS_SECRET_ACCESS_KEY Secret access key for the lakeFS server ••••••••••••
SLACK_WEBHOOK_URL Incoming webhook URL for destination Slack channels https://hooks.slack.com/services/T00/B00/X00
WEBHOOK_KEY Secret authentication key for inbound batch land webhook triggers whk_live_l1a2k3e4f5

Quick start

  1. Import this blueprint into your Kestra instance under the company.data namespace.
  2. Add your LAKEFS_ACCESS_KEY_ID, LAKEFS_SECRET_ACCESS_KEY, and SLACK_WEBHOOK_URL into Settings > Secrets.
  3. Click Execute and run with the default parameters to inspect the isolated branch creation, data quality check, and atomic merge simulation.
  4. Enable the daily_lakehouse_batch_schedule trigger or integrate the webhook URL into your upstream data landing pipelines.

Common pitfalls & notes

  • Atomic Merge Conflicts: Ensure no concurrent long-running batch job is merging into the same target table path simultaneously to avoid fast-forward merge conflicts.
  • Ephemeral Branch Cleanup: Always delete the ephemeral branch after a successful merge to prevent metadata clutter in your lakeFS repository.
  • Schedule State: The scheduled run is shipped disabled: true by default so it does not trigger before lakeFS credentials and repository names are configured.

How to extend

  • dbt Transformation Integration: Chain a io.kestra.plugin.dbt.cli.DbtCLI task directly on the isolated lakeFS branch before executing the atomic merge.
  • Automated S3 Glacier Cold Archival: Trigger snapshot archival of superseded commits after 30 days.
  • Multi-Table Atomic Publishing: Create a single commit across multiple related tables (orders, line_items) to achieve transactional multi-table lakehouse publishing.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.