The rise of the analytics pretendgineer - by Benn Stancil
One way to think about a dbt model is that it’s a table. It’s easy to think this, because most dbt models do, literally, create tables in a database. A company might have a products table that’s imported from their inventory management system, a charges table that’s imported from their Stripe account, and a dbt model called orders that combines the two into a table that contains details about anything anyone ever bought from the company. That dbt model will be a SQL query; the output of the SQL query will be a table.
But another way to think about a dbt model is that it’s a function. The data team is trying to create something—in this case, a list of everything the company has ever sold—and the orders model takes two tables as inputs and produces a new table as its output. The model is a formula that contains a bunch of computational logic that describes how to do that calculation.
A dbt project, then, is roughly analogous to a program. Each model is a function. The functions can reference one another. And the functions’ authors layer them on top of each other, with the goal of producing a collection of tables 1 that people can use to build dashboards and answer questions.
