Convert an ADF mapping data flow into dlt and dbt and prove parity
Order or customer reporting still comes from an Azure Data Factory mapping data flow whose logic lives only on the ADF canvas, with no tests or review.
- Transformation
- Any domain
Domain
52 RecipesRecipes for data engineers whose outcome no single business function owns, such as ingestion, dbt engineering, orchestration, identity and migration.
Order or customer reporting still comes from an Azure Data Factory mapping data flow whose logic lives only on the ADF canvas, with no tests or review.
A business rule in an incremental model was corrected, and only a known date range of published history should be restated.
A dbt model is correct but a full refresh is too slow or too expensive to run routinely, and gets slower as history grows.
A model has grown into one long query with logic packed inline, and nobody dares change it because dashboards and reports depend on its output.
A report or table is still produced by a hand-run SQL script or a database view outside dbt, with no tests, lineage or review.
A managed connector's bill changed shape, or it broke and the vendor fix has been pending for weeks, and the team wants the load in code it owns.
Warehouse logic lives in a materialized view that nobody can test, review or trace, and the team wants it in the dbt project.
A table or report is still produced by running a notebook by hand, pulling warehouse data into dataframes, with no tests, lineage or review.
Models or views call a scalar function created directly in the warehouse, so dbt cannot see the dependency and changes to it are not reviewed or tested.
A Type 2 dimension is kept by a hand-written MERGE procedure or trigger that nobody wants to maintain.
A Spark notebook lands raw files into bronze, and the team wants that load as tested pipeline code without keeping a cluster for it.
A nightly load is a stored procedure nobody fully understands, and it inserts, updates, deletes or merges rows in a table people depend on.
A required change to a published relation's grain, column meaning or shape cannot keep the old interface.
An API source has to load into bronze incrementally instead of reloading everything on every run.
A transaction-monitoring model is fed hand-built features nobody can reproduce, so two runs on the same data disagree.
A batch export of database change events is available and the current state of its tables has to be rebuilt without reading the source database again.
A backdated correction must change today's reading of the past, yet a report issued earlier has to stay reproducible as it was published.
Transaction feeds overlap, and source deliveries may be counted as separate business events.
A customer who opted out in one system still gets messages from another, because each source says something different and whichever job ran last wins.
Marketing, finance and product each quote a different churn rate because each defines an active and a lost customer differently.
Marketing segment lists come from a spreadsheet or BI export nobody can reproduce, and the same customer lands in different segments depending on who pulled the list.
An operational database's tables have to land in bronze, and reloading every table in full on each run is too slow or too heavy on the source.
Customer, asset or vendor attributes change, but past events need a defensible historical classification.
Historical fees or surcharges change when a current rate is applied to past events.
Revenue or productivity must be reported by employee, asset or team, but responsibility for each event is unclear.
The nightly loads, the dbt build and the report refresh are run by hand or live only as a pipeline clicked together in the workspace.
The gold marts exist and the Power BI team is about to rebuild the star schema by hand in every report.
A partner or vendor drops files into a folder on a schedule, and bronze has to pick up each delivery without a rerun loading it twice.
A spreadsheet that reports and models depend on is edited by hand, and a moved, renamed or retyped column keeps breaking them quietly.
The quality team rebuilds a readmission rate from a spreadsheet each quarter, and nobody can say who was left out of the rate or why.
Occupancy, ADR and RevPAR differ between reports because each one counts stays, comps, out-of-order rooms and cancellations its own way.
The same customer exists in several systems under different ids, so customer counts and per-customer revenue are inflated.
The same customer is written differently across CRM, billing and support, so joins on name or address miss.
A new dbt model must be brought up to date incrementally on each run, and nobody can show that a rerun or a re-delivery of records already applied leaves it unchanged.
Clinical operations rebuilds enrollment and site performance in a spreadsheet each month, and nobody can say who was left out of the enrolled count or why a site looks slow.
A new percentage, rate or average needs a defensible eligible population and missing-value policy.
Revenue or average order value means different things in different marts and dashboards, and nobody can say which number is right.
The MotherDuck load and the dbt build that follows it run from a cron job on someone's laptop.
Waiting, idle, available or busy time must be measured by site or zone and hour from operational event histories.
Analysts need tables that carry names, addresses, emails, phone numbers or ID numbers they must not see.
A model scores well in training but worse in production because training rows used facts, corrections or labels a real prediction could not have seen.
Product analytics numbers cannot be reproduced outside the vendor's screen, and nobody can say why two conversion figures differ.
A consumer build runs at a fixed time and, on runs where an upstream load is late, builds on partial data without anyone noticing.
Two reports put the same day in different weeks, months, quarters or fiscal periods because each mart builds its own date logic.
A load stopped and nothing failed; downstream models rebuilt on old data and the reports still looked current.
Monthly subscriber usage differs by who ran it, because nobody can say which call-detail batches had landed or whether each arrived complete.
An existing dbt change builds successfully but reviewers still need evidence that its business answers remain valid.
A Synapse dedicated SQL pool or a set of SSIS packages is due to move to Fabric, and nobody can say what is in it, what each piece would take or what stops it.
Part of a dbt project is moving to another warehouse, and a macro its models call only compiles, or only returns correct values, on the old one.
A table or model has been rebuilt on another platform or database while the original is still running, and the owner needs evidence the two hold the same data before cutting over.
A scheduled load-and-build job has to move to another platform, and nobody has written down what it must keep doing.
A dbt project has to run on a different warehouse or lakehouse, and the dashboards and reports that read it cannot show a different number afterwards.