Schedule icon
Webhook icon
Script icon
Docker icon
Set icon
If icon
SlackIncomingWebhook icon
Subflow icon
Fail icon
Log icon
Return icon

Apache Hudi Metadata Table Clean and Rollback Sentinel

Audit Apache Hudi table timelines, detect abandoned inflight commits, flag missing clean instants, calculate parquet storage bloat, and alert Slack.

Categories
CloudData

In production lakehouses built on Apache Hudi, streaming micro-batches from Apache Spark or Apache Flink continuously commit transactions to object storage. When an ingestion worker node crashes, experiences out-of-memory errors, or times out during commit finalization, it leaves behind uncommitted instant files (.inflight, .requested) in the .hoodie commit timeline. Concurrently, aborted tasks leave uncommitted parquet files in partition directories. Furthermore, if the Hudi cleaner fails or falls behind its scheduling interval, superseded historical parquet versions accumulate indefinitely, causing silent storage bloat and degrading query scan speeds.

This blueprint implements continuous Day 2 operational surveillance over Apache Hudi tables hosted on Amazon S3 or S3-compatible cloud storage. It interrogates the .hoodie timeline and partition directories directly from storage without spinning up expensive Spark clusters. The flow flags abandoned inflight commits, audits clean instant SLAs, calculates uncleaned parquet file overhead, persists health metrics to the Kestra KV store, and dispatches actionable Slack incident notifications or triggers automated rollback flows.

How it works

  1. The periodic_sentinel_schedule trigger invokes the flow on a 4-hour cadence, or external streaming pipelines invoke table_event_webhook upon completing micro-batch cycles.
  2. audit_hudi_timeline_and_storage (io.kestra.plugin.scripts.python.Script) scans object storage keys under the table prefix using paginated requests. It separates .hoodie timeline instants from partition parquet files.
  3. The inspection engine identifies inflight or requested instants that lack completed commit markers and exceed inflight_timeout_hours.
  4. The script inspects .clean instants, computes elapsed hours since the last completed clean run, counts intermediate commits, and flags clean SLA breaches.
  5. The engine groups partition parquet files by file group ID, correlates timestamps with abandoned commits, identifies superseded file versions beyond max_retained_versions, and calculates total uncleaned byte overhead.
  6. record_table_health_kv (io.kestra.plugin.core.kv.Set) saves the structured health manifest to the Kestra namespace key-value store under hudi_health_<table_name>.
  7. evaluate_table_health (io.kestra.plugin.core.flow.If) routes remediation actions when health status is not HEALTHY.
  8. alert_data_platform_slack (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) dispatches an incident report containing abandoned instant timestamps, clean staleness, affected partition paths, and recommended remediation.
  9. If trigger_rollback_flow is enabled and inflight corruption is detected, execute_rollback_repair_subflow (io.kestra.plugin.core.flow.Subflow) triggers an automated repair flow with target instant timestamps.
  10. If fail_on_critical_anomalies is enabled, fail_on_inflight_corruption (io.kestra.plugin.core.execution.Fail) terminates execution to prevent downstream pipelines from reading uncommitted data.
  11. log_sentinel_audit_summary (io.kestra.plugin.core.log.Log) writes an execution summary, and export_sentinel_manifest (io.kestra.plugin.core.debug.Return) emits typed outputs for SIEM and platform analytics.
  12. A top-level errors handler captures unexpected runtime or network failures and dispatches emergency Slack notifications.

What you get

  • Automated discovery of abandoned .inflight and .requested Hudi commits caused by crashed Spark or Flink writers.
  • Zero dependency on running Spark or EMR clusters to evaluate Hudi lakehouse table timeline integrity.
  • Precision measurement of uncleaned parquet file bloat and superseded version accumulation across partitions.
  • Centralized table health telemetry persisted to Kestra KV store for downstream pipeline gates.
  • Actionable Slack alerts containing exact instant timestamps and partition paths for instant remediation.
  • Optional automated triggering of Hudi rollback and metadata table repair subflows.

Who it's for

  • Data Platform Engineers and Lakehouse Architects operating Apache Hudi on cloud storage.
  • SREs and DataOps Engineers monitoring streaming CDC ingestion pipelines for silent failures.
  • Analytics Engineers protecting downstream dashboards from uncommitted transactions and storage cost surges.

Why orchestrate this with Kestra

Inspecting lakehouse storage with unmonitored cron jobs or heavy Spark batches leads to excessive cloud compute costs, credential sprawl, and silent failure modes. Kestra delivers lightweight containerized Python task execution, native key-value storage for table state tracking, declarative conditional branching, centralized secret management, and built-in failure recovery without managing dedicated worker clusters.

Prerequisites

  • An Apache Hudi table (Copy-on-Write or Merge-on-Read) stored in Amazon S3, MinIO, or S3-compatible cloud storage.
  • AWS IAM credentials or IAM role permissions for s3:ListBucket and s3:GetObject on the lakehouse bucket.
  • An incoming Slack Webhook URL for incident notification dispatch.

Secrets

  • AWS_ACCESS_KEY_ID: IAM access key identifier with read permissions on the target S3 bucket.
  • AWS_SECRET_ACCESS_KEY: IAM secret access key for object storage authentication.
  • SLACK_WEBHOOK_URL: Slack Incoming Webhook URL used to dispatch high-priority DataOps alerts.
  • HUDI_SENTINEL_WEBHOOK_KEY: Secret authentication key for the event-driven webhook trigger.

Quick start

  1. Configure AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, SLACK_WEBHOOK_URL, and HUDI_SENTINEL_WEBHOOK_KEY in your Kestra namespace secrets.
  2. Deploy the blueprint into your Kestra workspace under namespace company.dataops.
  3. Run a manual execution with your lakehouse bucket parameters:
    • storage_bucket: "prod-lakehouse-data-lake"
    • table_prefix: "hudi/orders_events_v2"
    • table_name: "orders_events_v2"
  4. Verify that audit_hudi_timeline_and_storage completes and inspect the generated health manifest in the Outputs tab.
  5. Check the Kestra KV Store under key hudi_health_orders_events_v2 to confirm table telemetry is saved.
  6. Enable periodic_sentinel_schedule to activate autonomous recurring surveillance every 4 hours.

How to extend

  • Connect automated Hudi CLI rollback execution by linking execute_rollback_repair_subflow to an Ansible or Docker runner flow executing hoodie-cli.sh rollback --instant <target_instant>.
  • Add automated cleaner triggers by dispatching an Apache Spark job with hoodie.clean.async=true when WARNING_CLEAN_OVERDUE is detected.
  • Integrate downstream dbt or Trino ELT gates using io.kestra.plugin.core.kv.Get to check hudi_health_<table_name> before running nightly aggregations.
  • Extend storage engine support to Azure Data Lake Storage (ADLS Gen2) or Google Cloud Storage (GCS) by swapping boto3 client initialization.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.