dbt-fal VS dbt-expectations

Happy data scientists use fal and dbt

fal (https://github.com/fal-ai/fal) helps with this! In fact we wrote a blog post about feature engineering with fal and dbt recently

We built a dbt adapter that helps you run local Python code with your dbt project with any other data warehouse. You can see it here: https://github.com/fal-ai/fal/tree/main/adapter

This new adapter helps you run your dbt Python models with isolated Python environments using our open source library: https://github.com/fal-ai/isolate

Have you considered fal? https://github.com/fal-ai/fal

Something to maybe comment on the post is that dbt is introducing Python transformations on the data warehouse offering (e.g. Snowspark) soon and that there are tools like fal that enable these Python transformations to run in a different environment which you have control over.

Fal-AI ( https://github.com/fal-ai/fal ) Fal helps to run Python scripts directly from the dbt project. For example, you can load dbt models directly into the Python context which helps to apply Data Science libraries like SKlearn and Prophet in the dbt models. This especially improves the data science capabilities within a data pipeline. What I extremely like about fal is that it extends dbt from a interesting angle.

- 🐍 fal ai: Fal helps to run Python scripts directly from the dbt project. For example you can load dbt models directly into the Python context which helps to apply Data Science libaries like SKlearn and Prophet in the dbt models.

I haven’t tried it yet but I know https://fal.ai/ helps you run python alongside dbt.

Yes I agree with you that having fivetran/airbyte and dbt covers a lot of the airflow use cases.. That being said you might still want to run some scripts after the DBT transformation is over, we ran into this exact problem and built a useful CLI tool for running python scripts alongside the dbt run.

Great write-up! For your logging integration, you might have a look at fal. There's an example of sending events to Datadog

Have not used Soda, but dbt indeed is pretty good especially when adding dbt-expectations

dbt-expectations

I highly.. highly.. recommend the dbt-expectations extension from Catologica for dbt. It's a port of Great Expectations, except you can quickly thunk it in your schema.yml's and have it run as part of your dbt test process. Super powerful and it's prevented us from shipping bad data many times.

I'm used to utilising dbt and defining my tests there (along with dbt-utils or https://github.com/calogica/dbt-expectations): I simply add a list item to a column definition and can already define a great number of tests without having to copy code. I can even extend the pre-defined using generic tests. Writing custom tests also integrates nicely. Additionally it's very convenient to tag tests or define a severity. The learning curve for a business engineer is almost flat as long as they know some SQL.

Use dbt's testing functionality during your transformations with catalogica/dbt-expectations (Great Expectations framework ported to dbt)

Check out dbt-expectations https://github.com/calogica/dbt-expectations

There are certain things I would like to add such as data quality, I can use something like dbt great expectations, but I am not sure how much more I should force it before getting an airflow setup..

[dbt Labs employee here]

Check out dbt-expectations package[1]. It's a port of the Great Expectations checks to dbt as tests. The advantage of this is you don't need another tool for these pretty standard tests, and can be early incorporated into dbt workflows.

[1] https://github.com/calogica/dbt-expectations

Also check out dbt-expectations that is a port of Great Expectations that greatly expands the configurable (non-assert) tests.