A tool to assist in migrating from Dataform to DBT.
- Models are converted, with Dataform
${ref()}
calls replaced by appropriate DBT{{ ref() }}
and{{ source() }}
calls. - DBT currently doesn't support namespacing, so model names must be unique;
dataform-to-dbt
supports renaming tables as part of the migration, correcting references along the way. - Source and model definitions are output in schema specific model and source
.yml
. - Model documentation is included in the model
.yml
. - Dataform auto-generated assertions (
uniqueKey
,nonNull
, androwConditions
) are migrated to appropriate tests in the model.yml
, using built in tests where possible anddbt_utils
tests where not. - Dataform manual assertions are migrated DBT singular tests.
- View materialisations are set per model, with the assumption that the default will be tables.
- BigQuery clustering config is migrated; see "what might work" for info on partitioning.
- Tags are migrated.
- Projects using multiple schemas automatically have appropriate macros set up to rewrite these appropriately when not writing to the
prod
target (written to the target dataset - use environment variables to set this inprofiles.yml
on a per-developer basis,direnv
recommended - with the original schema name prepended, e.g.developer_schema.original_schema__original_table
).
- Dataform includes are out of scope to ever work completely, as they can do most things javascript can and translating that to DBT's jinja based macros just isn't going to happen. That said, where the include is a simple string, a DBT macro will be produced and inserted in the right location so that it's still a single replacement (instead of inlining the replacement and duplicating it at the DBT version). Includes that call functions are not supported, but a stub macro will be produced and inserted in the right place and a warning produced so that they can be manually adjusted (by amending the implementation to actually work, and by amending all the invocations to pass appropriate arguments).
- DBT doesn't support generating temporary tables in the model header as you can with dataform pre-operations (not with a
ref()
, anyway), so these are extracted to their own tables and the references updated. - Table materialisations aren't set (except for extracted temp tables), views are - check the default materialisations set in the DBT config and adjust as necessary.
- BigQuery paritioning config is migrated, but the data type inferred is a guess and may need tweaking, if a guess can be made at all.
- No support for incremental datasets, these will require manual adjustments.
This is very rough and ready, used to convert some private projects. It has not been well tested, it may eat your homework, kill your pets, etc. Review the created models etc carefully before using, build into test datasets, write assertions and verify the output, take all possible precautions before running in production.
Should work with Node 14.8+ (native modules, top level await), but has not been tested.
The migration will create models, macros, etc in the target directory; the project can then be run and leftover Dataform config can be removed.
Review the DBT docs and create a template dbt_project.yml
and a profiles.yml
; dataform-to-dbt
assumes that the production profile output will be called prod
and will fail if it's not.
Some Dataform assertions convert to dbt_utils
tests (row conditions and multi-column unique assertions), so install dbt_utils
if that applies.
# Get help
npx dataform-to-dbt --help
# Run a migration
npx dataform-to-dbt \
--directory /path/to/dataform/project \
--template /path/to/template/dbt_project.yml \
--profile /path/to/dbt/profiles.yml