data-dwh-dbt-project/models/intermediate/cross/int_dates_mtd_by_dimension.sql

37 lines
1.2 KiB
MySQL
Raw Normal View History

{% set dimensions = get_kpi_dimensions() %}
{{ config(materialized="table", unique_key=["date", "dimension", "dimension_value"]) }}
with
int_core__mtd_accommodation_segmentation as (
select * from {{ ref("int_core__mtd_accommodation_segmentation") }}
),
int_core__user_host as (select * from {{ ref("int_core__user_host") }}),
int_dates_mtd as (select * from {{ ref("int_dates_mtd") }})
{% for dimension in dimensions %}
select distinct
d.year,
d.month,
d.day,
d.date,
{{ dimension.dimension }} as dimension,
{{ dimension.dimension_value }} as dimension_value,
d.first_day_month,
d.last_day_month,
d.is_end_of_month,
d.is_current_month
from int_dates_mtd d
{% if dimension.dimension == "'by_number_of_listings'" %}
inner join int_core__mtd_accommodation_segmentation a on d.date = a.date
Merged PR 2689: KPIs by Billing Country # Description Adds Billing Country dimension in KPIs, but does not expose them to reporting yet. Silly thing, based on the macros I built, I cannot make incremental changes unless changing all models. This will need to be adapted, happy to hear your thoughts on how we do it. Additionally, I have lack of performance of the model `mtd_guest_payments_metrics`. It takes around 5 min to execute, but technically the end-to-end runs in one shoot without breaking. It's a complex PR because it changes many files, but you will see that: * It mostly changes the join conditions for the dimensions or the schema tests, * I tried to be very careful and add things step-by-step in the commits. Goal is NOT to complete the PR yet until we see how we can improve performance. I can say though that data end-to-end looks ok to me, but would benefit from checking with production data for the new dimension Update 30th Aug * Added a new commit that includes `id_user_host` in `int_core__verification_payments`. Happy to discuss if it makes sense or not. But it changes the execution from ~600 sec to ~6 sec because it avoids a massive repeated join with `verification_requests`. # 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. - [ ] I've picked the right materialization for the affected models. **To check because of performance issues** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19082
2024-09-04 10:17:12 +00:00
{% elif dimension.dimension == "'by_billing_country'" %}
inner join
int_core__user_host h
on d.date >= date(h.created_date_utc)
and h.main_billing_country_iso_3_per_deal is not null
{% endif %}
{% if not loop.last %}
union all
{% endif %}
{% endfor %}