Kontrowersja
Nie powinniśmy testować wszystkiego wbudowanymi testami dbt bez dodatkowej konfiguracji. To nie pomaga hurtowni danych na dłuższą metę.
Uzasadnienie
Powinniśmy testować dane, aby poprawiać ich jakość — prawda? To słuszne. Powinniśmy jednak robić to świadomie, a nie dla samego faktu testowania.
Łatwo wpaść w pułapkę dodawania prostych testów wszędzie w ten sam sposób — tak jak wpadamy w pułapkę ingestii absolutnie wszystkiego, a potem nie wykorzystujemy tego do generowania insightów zorientowanych na klienta dla naszego biznesu.
Wbudowane testy dbt to po prostu zapytania SQL wykonywane na hurtowni. Wyobraź sobie zbiór danych z miliardami wierszy i ponad 50 kolumnami testowany pod kątem accepted_values przy codziennym przetwarzaniu — nawet jeśli model jest przyrostowy. Skanowanie całego zbioru i pobieranie wyników będzie kosztowną operacją.
Alternatywa
W ramach dbt
Przede wszystkim, jeśli chcemy trzymać się testów dbt, musimy:
- Starannie wybierać modele i kolumny, które chcemy testować — aby nie duplikować wysiłku ani testować niepotrzebnie.
- Dodawać dodatkowe filtry / konfiguracje / przyrostowe skanowanie — dbt pozwala na dodawanie dodatkowych parametrów, takich jak klauzula where — to dobry początek, aby ograniczyć to, co chcesz testować w modelu.
- Rozważyć dodanie niestandardowych testów, które uruchamiają się tylko na przyroście modelu przetworzonego danego dnia.
Trzeci punkt jest najciekawszy — pokażę przykład, jak ograniczyliśmy koszty skanowania ogromnych zbiorów GA4 dzięki niestandardowemu testowaniu i automatycznemu usuwaniu rekordów.
Cel: testowanie każdego przetworzonego przyrostu (raz dziennie przetwarzanie nowych zdarzeń z 1-dniowym oknem lookback; zobacz tutaj niestandardowe okna lookback w dbt).
Kroki:
- Załaduj kolejny przyrost.
-- setting incremental keys
{%- set lookback_window_in_days = config.get('lookback_window_in_days', default='1') -%}
-- starting table processing
with ga_4_source as (
{{ ga_incremental_source_loading('source', 'ga4', this, lookback_window_in_days) }}
)
-- ga_incremental_source_loading macro is quite complex in our use case
-- please assume we select from the source and add a lookback window
- Usuń zdarzenia starsze niż 5 dni (można dostosować do własnych potrzeb).
-- part of the model definition
-- Conditionally delete old records if this is an incremental run
{% if is_incremental() %}
{{ ga_testing_automated_cleanup('model_name', 'schema_name', 'delete_cutoff_in_days') }}
{% endif %}
-- macro which is called above
{% macro ga_testing_automated_cleanup(model_name, schema_name, delete_cutoff_in_days) %}
{% if target.name == 'prod' %}
{% set delete_statement %}
delete from {{ schema_name }}.{{ model_name }}
where event_date_converted < (select date_trunc(
day
, dateadd(day, -{{ delete_cutoff_in_days }}::int
, max(t.event_date_converted))
) from {{ schema_name }}.{{ model_name }} t);
{% endset %}
{{ log("Executing: " ~ delete_statement, info=True) }}
{% do run_query(delete_statement) %}
{% endif %}
{% endmacro %}
- Przetestuj przyrost z 5-dniową historią (do wykrywania anomalii gorąco polecam pakiet dbt elementary, który jest open source).
Ten krok pozostawiam do samodzielnego zdefiniowania. Może to być dowolny niestandardowy lub generyczny test. W naszym przypadku testowaliśmy głównie wartości null, anomalie za pomocą pakietu dbt elementary oraz unikalność utworzonego klucza głównego.
Poza dbt
Narzędzia do monitorowania! Tak, wiem, kosztują… ale są świetną alternatywą — wszystko zależy od zdefiniowanych potrzeb testowych.
Narzędzia, z których korzystałem, to Sifflet i Monte Carlo. Mają gotowe scenariusze testowe, ale możesz też używać własnego, niestandardowego SQL.
Dlaczego wybrać je zamiast testowania w dbt?
Po pierwsze, są łatwiejsze w utrzymaniu dla mniej technicznych osób. Pozwalają też na płynną integrację ze Slackiem, Teams lub innymi narzędziami komunikacyjnymi. Wykorzystują modele ML, aby pomóc odkryć anomalie w zbiorach danych, o których nie wiedziałeś. Na koniec — szybko dają pierwsze insighty.
Rozszerzone testowanie w dbt czy poza nim?
Wewnątrz dbt
Ulepszanie testów dbt dzięki niestandardowej konfiguracji i pakietom jest dla bardziej dojrzałych zespołów, które mają ludzi potrafiących jasno zdefiniować potrzeby i wdrożyć niestandardowe ustawienia, na przykład dla testów wykrywania anomalii.
To pomaga w dostosowaniu projektów i daje znacznie więcej swobody, ale kosztem czasu zespołu na niestandardowe definicje i utrzymanie.
Poza dbt
Zewnętrzne narzędzia to świetny wybór dla mniej dojrzałych zespołów lub zespołów o mniejszej liczbie osób. Upraszczają wdrożenie. Czas od zera do testów jest zminimalizowany — kilkoma kliknięciami możesz uruchomić zaawansowane modele ML. Wymagają też niewielkiego utrzymania i oferują niestandardowe widoki wykorzystania tabel oraz inne funkcje data observability.
To pozwala na szybkie wdrożenie i wymaga niewielkiej wiedzy technicznej, aby dobrze z tego korzystać. Kosztem jest jednak licencja, dodatkowe narzędzie do skonfigurowania i ewentualne szkolenie zespołu.
Podsumowanie
Wniosek jest jasny. Testuj dane, ale rób to świadomie — nie dla samego faktu testowania. Jeśli masz mniejszy i/lub mniej dojrzały zespół (ale dostępny budżet) — zewnętrzne narzędzia testowe to prawdopodobnie opcja dla Ciebie. Gdy masz większy i/lub bardziej dojrzały zespół, który wymaga utrzymania wszystkiego w kodzie i wysokiej customizacji — wybierz sparametryzowane testowanie dbt wzbogacone o dodatkowe pakiety.
Kontakt
Dziękuję za przeczytanie. Podoba Ci się przekazywana wiedza, ale brakuje czasu lub kompetencji, aby uporządkować analytics engineering? Sprawdź moje dane kontaktowe.
Nie testować za pomocą dbt? został pierwotnie opublikowany w Lortech Solutions Blog na Medium, gdzie rozmowa trwa dalej dzięki podświetleniom i odpowiedziom czytelników.
