a8927b7a44
# Description Fixes: * There was a data quality issue in which active listings with bundles were showing more listings than the total active listings. This has been fixed, plus a bunch of tests have been added to make sure this does not happen again. * There's a field that reaches the 63 character limit. I modified "paid" per "upgraded" which reduces this to intermediate model; however in reporting I need to keep as is to avoid breaking PBI. I did change the name of the field in the schema so tests/docs work well and explicitly mention this in the doc. This will need adaptation but can be done in the future. * There was tons of dead code tagged as to be deleted that was not deleted, not sure why or when. Anyway this is dropped now. It's not used in PBI except for the fact that columns are dropped in the data model, so we might have a bit of down time to just remove these. * Few fields were not displayed correctly in dbt docs. What's new: * New user categorisation as an alert-based system. This can be enhanced in the future but so far it covers hell of a lot of cases. This also includes data quality alerts (deal not in HS, or account defaults to MVP launch). * MVP Launch date moved to project yaml since it's a very standard date. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #30407
92 lines
3.4 KiB
YAML
92 lines
3.4 KiB
YAML
# Name your project! Project names should contain only lowercase characters
|
|
# and underscores. A good package name should reflect your organization's
|
|
# name or the intended use of these models
|
|
name: "dwh_dbt"
|
|
version: "1.0.0"
|
|
config-version: 2
|
|
|
|
# This setting configures which "profile" dbt uses for this project.
|
|
profile: "dwh_dbt"
|
|
|
|
# These configurations specify where dbt should look for different types of files.
|
|
# The `model-paths` config, for example, states that models in this project can be
|
|
# found in the "models/" directory. You probably won't need to change these!
|
|
model-paths: ["models"]
|
|
analysis-paths: ["analyses"]
|
|
test-paths: ["tests"]
|
|
seed-paths: ["seeds"]
|
|
macro-paths: ["macros"]
|
|
snapshot-paths: ["snapshots"]
|
|
|
|
clean-targets: # directories to be removed by `dbt clean`
|
|
- "target"
|
|
- "dbt_packages"
|
|
|
|
# Configuring models
|
|
# Full documentation: https://docs.getdbt.com/docs/configuring-models
|
|
|
|
# In this example config, we tell dbt to build all models in the example/
|
|
# directory as views. These settings can be overridden in the individual model
|
|
# files using the `{{ config(...) }}` macro.
|
|
models:
|
|
+unlogged: true
|
|
# ^ This makes all the tables created by dbt be unlogged. This is a Postgres
|
|
# specific setting that we activate for performance. It has deep implications
|
|
# on how Postgres handles tables and is typically considered crazy risky, but
|
|
# it's very fitting for our needs. You can read more here:
|
|
# https://www.crunchydata.com/blog/postgresl-unlogged-tables
|
|
dwh_dbt:
|
|
+post-hook:
|
|
sql: "VACUUM ANALYZE {{ this }}"
|
|
transaction: false
|
|
# ^ This makes dbt run a VACUUM ANALYZE on the models after building each.
|
|
# It's pointless for views, but it doesn't matter because Postgres fails
|
|
# silently withour raising an unhandled exception.
|
|
staging:
|
|
+materialized: table
|
|
+schema: staging
|
|
intermediate:
|
|
+materialized: view
|
|
+schema: intermediate
|
|
reporting:
|
|
+materialized: table
|
|
+schema: reporting
|
|
|
|
seeds:
|
|
dwh_dbt:
|
|
schema: staging
|
|
|
|
vars:
|
|
"dbt_date:time_zone": "Europe/London"
|
|
# A general cutoff date for relevancy. Many models assume this to be the point
|
|
# in time after which they should work.
|
|
"start_date": "'2020-01-01'"
|
|
|
|
# KPIs Start Date. This is the date from which we start calculating KPIs.
|
|
"kpis_start_date": "'2022-04-01'"
|
|
|
|
# New Dash MVP Launch Date. This is the first date considered for New Dash in many areas.
|
|
"new_dash_mvp_launch_date": "'2024-07-30'"
|
|
|
|
# New Dash First Invoicing Date. This is the first date considered for New Dash invoicing.
|
|
"new_dash_first_invoicing_date": "'2024-12-31'"
|
|
|
|
# The timestamp of when the Guest Squad activated the Feature Flag that
|
|
# activated the big bang refactor of the Guest Products logic.
|
|
"guest_products_feature_flag_activation_timestamp": "'2025-06-09T10:25:00+00:00'"
|
|
|
|
# A distant future date to use as a default when cutoff values are missing.
|
|
"end_of_time": "'2050-12-31'"
|
|
|
|
# Booking state variables
|
|
# States should be strings in capital letters. Models need to force an upper()
|
|
"cancelled_booking_state": "'CANCELLED'"
|
|
"approved_booking_state": "'APPROVED'"
|
|
|
|
# Payment state variables
|
|
# States should be strings in capital letters. Models need to force an upper()
|
|
"paid_payment_state": "'PAID'"
|
|
|
|
# Protection service state variables
|
|
# States should be strings in capital letters. Models need to force an upper()
|
|
"default_service": "'BASIC SCREENING'"
|