dbt Analytics Engineering (AWS Redshift)
Abgeschlossendbt-Projekt für Analytics Engineering auf AWS Redshift Serverless, basierend auf dem Olist-E-Commerce-Datensatz (100K Bestellungen, Brasilien 2016–2018). 18 Modelle über drei Schichten (Staging, Intermediate, Marts), vollständig implementiert und getestet: 94 Tests, 3 Custom Macros, 1 SCD-2-Snapshot und ein Star-Schema für Self-Service-Analytics.
Technologien
Problem
Rohdaten benötigen strukturierte Transformation in Analytics-bereite dimensionale Modelle, damit BI-Teams und Analysten unabhängig von Rohtabellen arbeiten können.
Ansatz
ELT-Muster mit dbt auf Redshift: Staging-Layer (source-konforme Views) → Intermediate-Layer (Business-Logik) → Marts-Layer (dimensionale Modelle für core und marketing Schemas).
Ergebnis
18 dbt-Modelle vollständig gebaut und getestet: 7 Staging-Views, 4 Intermediate-Views, 6 Mart-Tables (dim_customers, dim_products, dim_sellers, dim_dates, fct_orders, fct_order_items) + 1 Marketing-Mart (Customer Lifetime Value). 94 Tests ausgeführt — 93 Pass, 1 Warn (bekanntes Voucher-Datenqualitätsproblem in den Quelldaten). 1 Seed (71 Zeilen PT→EN Kategorie-Übersetzungen), 1 SCD-2-Snapshot (sellers), 3 Custom Macros, vollständige dbt-Dokumentation generiert.
Learnings
dbt 2.0 bricht die Syntax für generische Tests — alle Argumente (values, to, field) müssen unter einem arguments:-Schlüssel verschachtelt werden. Redshift reserviert raw als Schlüsselwort; Schema-Referenzen müssen gequotet werden. Redshift hat kein DISTINCT ON — ROW_NUMBER() OVER (PARTITION BY ...) ist der korrekte Ersatz. LISTAGG und COUNT(DISTINCT) sind in Redshift nicht kombinierbar und erfordern getrennte CTEs. dbt docs generate wurde in Version 2.0 entfernt — dbt compile --write-catalog mit lokalem HTTP-Server ersetzt es.
Relevanz
Zeigt Analytics Engineering, dimensionales Modellieren und moderne SQL-Transformation-Workflows — eine Kernkompetenz für datenorientierte Rollen.