forked from dbt-labs/dbt-core
-
Notifications
You must be signed in to change notification settings - Fork 1
/
sample.dbt_project.yml
194 lines (149 loc) · 6.36 KB
/
sample.dbt_project.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
# This configuration file specifies information about your package
# that dbt needs in order to build your models. This file is _required_
#
# For more information, consult:
# https://docs.getdbt.com/reference#configuration
#
# Package Configuration
#
# name: Required. This is the name used to reference your package in the configs
# below. Package names must only contain letters and underscores
name: 'your_package_name'
# version: Required. This indicates the current version of your package and
# should conform to semantic versioning. The field is currently unused
version: '0.1.0'
#
# File Path Configurations
#
# The following configs specify directories that dbt uses to operate. All
# paths are specified relative to the path of dbt_project.yml
# source-paths: Required. Specify which path(s) dbt should look in to find
# models. Models are text files with a .sql file extension.
source-paths: ["models"]
# analysis-paths: Optional. Specify which path(s) dbt should look in to find
# analytical queries. These queries are compiled, but not executed, by dbt.
analysis-paths: ["analysis"]
# target-path: Required. Specify which path dbt should write compiled SQL to.
target-path: "target"
# test-paths: Optional. Specify which path(s) dbt should look in to find data
# test definitions.
test-paths: ["tests"]
# data-paths: Optional. Specify which path(s) dbt should look in to find CSV
# files. Running `dbt seed` will load these CSVs as tables in your warehouse
data-paths: ["data"]
# macro-paths: Optional. Specify which path(s) dbt should look in to find
# macros. These macros will be globally available to all models in your project
macro-paths: ['macros']
# log-path: Optional. Specify which path dbt should write debug logs to.
log-path: "logs"
# clean-targets: Optional. Specify which path(s) should be removed by the
# clean task. Run `dbt clean` to delete these directories
clean-targets: ["target", "dbt_modules"]
#
# Connection Configurations
#
# profile: Required. This config specifies which profile dbt should use to
# connect to your data warehouse. The provided value must exist in the
# profiles.yml file.
profile: "evil-corp"
#
# Model Configurations
#
# The following section contains configurations that define how your models are
# instantiated by dbt. The `models` config below can specify options for both
# your package, and any packages included as dependencies.
#
# Options are specified on a per-package, per-directory, and per-model basis.
# The configs are inherited, so configs applied to a package can be overridden
# for directories and models contained within that package.
#
# The configuration structure within a package should mirror the directory
# structure within that package. The example configs provided below are based
# on the following directory structure.
#
# dbt_project.yml
# models/
# ├── adwords
# │ └── adwords_ads.sql
# └── snowplow
# ├── base
# │ └── snowplow_events.sql
# └── snowplow_sessions.sql
models:
enabled: true # configs defined here are applied to _all_ packages
materialized: view # but can be overridden in more specific configs below
# pre- and post- hooks can be defined anywhere within the model hierarchy.
# when defined at the root level (as they are here), they apply to all models
# in all packages. These hooks are compiled into the model SQL and run either
# before or after the model is materializated.
pre-hook:
- "insert into audit (model, state, time) values ('{{this.name}}', 'start', getdate())"
post-hook:
- "grant select on {{this}} to user_1"
- "insert into audit (model, state, time) values ('{{this.name}}', 'end', getdate())"
# This is the configuration for the models in your local package. The name
# `your_package_name` is defined above.
your_package_name:
# Applies to all SQL files found under ./models/adwords/
adwords:
enabled: false
# Applies to the specific model ./models/adwords/adwords_ads.sql
adwords_ads:
enabled: true
materialized: table
# Applies to all SQL files found under ./models/snowplow/
snowplow:
# Applies to all SQL files found under ./models/snowplow/base
base:
# Applies to model ./models/snowplow/base/snowplow_events.sql
snowplow_events:
materialized: table
sort: ['timestamp', 'userid']
sort_type: interleaved
dist: 'userid'
# Applies to model ./models/snowplow/snowplow_sessions.sql
snowplow_sessions:
materialized: incremental
sql_where: "created_at > (select max(created_at) from {{ this }})"
unique_key: "id"
sort: "timestamp"
dist: "user_id"
# This is the configuration for the "quickbooks" open source package
# These configs override those defined within the quickbooks package
quickbooks:
base:
materialized: ephemeral
transform:
materialized: view
#
# Run Start & Complete Hooks
#
# Like the pre- and post- hooks above, the on-run-start and on-run-end configs
# make it possible to run SQL at the very beginning, and very end of a dbt run.
on-run-start:
- "create table if not exists audit (model text, state text, time timestamp)"
on-run-end:
- 'grant usage on schema "{{ target.schema }}" to db_reader'
- 'grant select on all tables in schema "{{ target.schema }}" to db_reader'
#
# Package configurations
#
# More info here: https://docs.getdbt.com/docs/package-management
#
# Archival
#
# dbt's archival process records snapshots of specified tables so that
# you can analyze how these tables change over time. In the example below,
# the public.users table is configured for archival. When the `updated_at`
# value changes for a given user record (identified by the `id` field), dbt
# will record a new record in `users_archived` table which reflects the
# changed state of that row. For more information on this command, consult
# the dbt documentation: https://docs.getdbt.com/reference#archive
archive:
- source_schema: public
target_schema: public
tables:
- source_table: users
target_table: users_archived
updated_at: updated_at
unique_key: id