Skip to main content

dbx-flame

A configuration-driven data engineering framework for Databricks. Onboarding a new dataset means writing a workflow YAML — never Python.

PyPI Status CI python Databricks Runtime DQX License

Why

Most Databricks pipelines grow one notebook per dataset. This framework inverts that: a single typed engine reads a workflow YAML and carries every dataset through the same five layers — Start, Pipeline, Typing, Policies, Output. A new source is a new YAML file, not a new code path.

The project is alpha — see Status for what's implemented today.

Quick Look

Two tasks, two YAML blocks — CSV into Bronze, then Bronze into Silver with SCD Type 1 upsert on CLAIM_ID:

# Inbound → Bronze
source.origin: csv
source.path: /Volumes/dev/source_data/inbound/
source.directory: CLAIMS
output.verb: append
output.schema_name: claims
output.table: CLAIMS_BRONZE

# Bronze → Silver
source.origin: delta
source.schema_name: claims
source.table: CLAIMS_BRONZE
output.verb: upsert
output.schema_name: claims
output.table: CLAIMS_SILVER
output.keys: CLAIM_ID
output.event_time.column: __EXPORT_DATE

No code changes for either step — both are entries in a workflow YAML deployed through the bundle. See 03_write_verbs.md for the full verb matrix.

Key Capabilities

  • Config-driven onboarding — declare an origin, a write verb and a target; the framework validates the combination and runs it. No per-dataset Python.
  • Data handling verbs — APPEND, FULL, UPSERT, SCD2, COMPLETE_DELTA — layer-agnostic, so the same verb serves Inbound→Bronze or Bronze→Silver.
  • Gold is SQL (planned) — each Gold table will be a materialized view over Silver, in its own .sql file, so Silver's MERGEs never block it. See Gold.
  • A data quality gate, not a bolt-on — every batch is checked against a Databricks DQX ruleset (you define this) before it's written; error refuses the batch, warn logs and lets it through.
  • Fail fast, fail loud — Invalid Configs or Failed Data QA stops the run with one aggregated error report. Nothing logs an error and reports success.
  • Ships as a wheel — src-layout package deployed via Databricks Declarative Automation Bundles and run through python_wheel_task entry points. No notebook logic, no sys.path hacks.

Documentation

  1. 00_overview.md — goals, principles, glossary, layer diagram
  2. 01_architecture.md — layers, protocols, execution flow, extension points
  3. 02_config_schema.md — the typed config schema, parameter by parameter
  4. 03_write_verbs.md — verb semantics with worked examples
  5. 04_policies.md — the data quality gate, driven by a DQX ruleset
  6. 05_testing.md — unit and platform testing
  7. 06_roadmap.md — phased implementation plan and current status
  8. 07_workspace_setup.md — workspace setup recipe: catalog naming, schemas, volumes, grants

Development

Targets Linux; on Windows, work inside WSL, since Spark doesn't run natively there (Required for running unit tests).

Needs a JDK (11 or 17, for PySpark), Python 3.11 (matches Databricks Runtime 15.4 LTS) and Poetry 2.x.

poetry env use python3.11   # once, to pin the interpreter
make install                # runtime + dev dependencies
make test                   # unit tests with coverage

Review the Makefile to lists the rest.

Platform tests are real Databricks jobs under platform_tests/ - with real life scenarios; see 05_testing.md.

Deploying to Databricks

The bundle in databricks.yml is configured to work with a Python wheel: it builds the wheel, then deploys the bundle. Authenticate with a CLI profile or with DATABRICKS_HOST / DATABRICKS_TOKEN. A new workspace first needs its catalogs, schemas and volumes; see 07_workspace_setup.md.

databricks bundle deploy

Traceability

Every run that passes config validation writes an audit trail to your own catalog (monitoring_{env}.audit.logs), not to vendor telemetry. Each row names the job, run and task that produced it. The audit write comes first, so a run that can't log fails before touching any data. Schema: 00_overview.md.

Status

Start, Pipeline (CSV + JSON + Delta), Typing, Policies (DQX), and all five write verbs are implemented and tested. The SAS origin and the Gold example view are not implemented yet. Full phase-by-phase status: 06_roadmap.md.

License

Apache 2.0 — see LICENSE.

Metadata

Release files for dbx-flame 0.0.4

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for dbx-flame 0.0.4
File Size Uploaded
dbx_flame-0.0.4.tar.gz 45.4 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for dbx-flame 0.0.4
File Interpreter ABI Platform
dbx_flame-0.0.4-py3-none-any.whl Python 3 none any Details

Total release size: 109.3 kB

Release files / dbx_flame-0.0.4.tar.gz

Download URL dbx_flame-0.0.4.tar.gz
Size 45.4 kB
Tags Source
SHA-256 checksum
How to use checksums
fb60dc0a15a8c669584ba770191b82b96942281fa9d5acad811023522973b0d2
BLAKE2b-256 checksum
How to use checksums
23732fff9ab7a2c2c56e5cca641376da699611a166eaa41b233c3162693c78d9
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 7, 2026.

Transparency log

Release files / dbx_flame-0.0.4-py3-none-any.whl

Download URL dbx_flame-0.0.4-py3-none-any.whl
Size 63.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
c370155cf5e4eb22a1d9769b48a4fee7b387bd7bc945b7a5d56dbb2ecfaa8391
BLAKE2b-256 checksum
How to use checksums
ed079f8808ca0b03ab9886e45526a3822b226b4aa8bf10e44cc474457ad12ec8
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 7, 2026.

Transparency log

Release history Release notifications | RSS feed

0.1.0

2 release files

This release

0.0.4 This release

2 release files

0.0.3

2 release files

0.0.2

2 release files

0.0.1

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page