Hvorfor?

dbt (data build tool) er et verktøy som virkelig har skutt fart de siste årene, og det er ikke rart. Endelig har vi fått et verktøy som gjør det enkelt å versjonere, dokumentere, teste og release data ved hjelp av SQL. Eller?

Enkelt er vel kanskje å ta litt hardt i, spesielt for den gjenge dataanalytiker som ikke er vant med de gode praksisene fra softwareutvikling. Ofte ligger ikke IDE (Integrated Development Environment) og Git til fingerspissene, og da kan terskelen for å ta i bruk et verktøy som dbt, nærmere bestemt dbt Core, virke ganske høy.

dbt Core er nemlig gratisversjonen fra dbt Labs og er i bunn og grunn et kommandolinjeverktøy (CLI) og et rammeverk der du selv må sette opp konfigurering, administrasjon av miljøer, og integrasjon med andre verktøy f.eks Databricks, Apache Airflow eller lignende. Med andre ord krever både oppsett og bruk en viss teknisk kompetanse. dbt Cloud derimot er den dyre storebroren som er en administrert SaaS-versjon av dbt Core, og tilbyr egentlig alt du trenger innebygd, og er derfor et naturlig valg for de fleste dataanalytikere.

Hos en av kundene jeg nylig satt hos var det et spørsmålet om vi skulle begynne å ta i bruk dbt for å lage nye dataprodukter i dataplattformen vår. For å overbevise dataanalytikerne i organisasjonen bestemte vi oss for å vise i praksis hvilke muligheter dbt ville gi og hvor lett det var å ta i bruk. Utfordringen var den: vi måtte gjøre dette ved å bruke dbt Core. Ettersom dataplattformen vår var i Databricks, stilte vi oss spørsmålet:

Kan vi bruke Databricks og dets integrasjon med Git til å erstatte behovet for en IDE?

Før vi går videre må jeg bare understreke at ettersom løsningen utelukkende hadde som mål å vise mulighetene dbt tilbyr, så er det flere aspekter som mangler for å kunne bruke dette som en permanent løsning.

Hvordan gjorde vi det?

1. Opprett en Databricks notebook for å kjøre dbt-kommandoer

Det vi må finne ut av er hvordan vi skal bygge og deploye prosjektet vårt fra Databricks istedenfor vår lokale terminal. Dette gjorde vi ved å lage en veldig enkel notebook dbt_run.py

# Databricks notebook source
# MAGIC %sh
# MAGIC dbt deps
# MAGIC dbt run

Denne notebooken vil kjøre kommandoene som laster ned nødvendig avhengigheter og kjører dbt-prosjektet direkte i Databricks-miljøet.

2. Konfigurer profileringsfil

Vi opprettet en designert profileringsfil profiles.yml for de som ønsker å bruke Databricks til dbt-utvikling i en egen mappe.

databricks:
  target: '{{ env_var("DBT_TARGET") }}'
  outputs:
    default:
      type: databricks
      host: '{{ env_var("HOST")}}'
      http_path: '{{ env_var("HTTP_PATH")}}'
      schema: 'dev_{{ env_var("USER_INITIALS") }}'
      auth_type: oauth
      client_id: '{{ env_var("CLIENT_ID")}}'
      client_secret: '{{ env_var("CLIENT_SECRET") }}'

• target: Bestemmer hvilket miljø som skal brukes.
• host: Databricks-vertens URL.
• http_path: Banen til SQL Warehouse eller cluster.
• schema: Navnet på skjemaet der dbt skal opprette tabeller.
• auth_type, client_id, client_secret: OAuth-autentiseringsdetaljer.

Ved lokal utvikling bruker vi OAuth user-to-machine autentisering som tillater systemtilgang på vegne av en bruker, her dbt klienten, ved å hente et OAuth token gjennom en browser popup fra Azure Entra ID. Dbt bruker deretter dette tokenet til å koble seg til DBSQL API. Dette er dessverre ikke støttet når vi kjører dbt fra et Databricks cluster, så vi måtte nøye oss med å bruke OAuth machine-to-machine. Selv om dette ikke er ideelt i en produksjonssetting, fungerte det bra for vårt formål.

3. Sett opp cluster policy med biblioteker og miljøvariabler i Databricks

Deretter lagde vi en cluster policy med de nødvendige bibliotekene for å kjøre dbt-kommandoer: dbt-databricks og dbt-core, samt følgende miljøvariabler:

• DBT_PROFILES_DIR=./<mappen med profile.yml>: dbt sjekker denne miljøvariablen for å avgjøre hvilket profileringsfil som skal brukes
• DBT_TARGET,HOST,HTTP_PATH,CLIENT_ID
• CLIENT_SECRET={{secrets/<secret scope>/<secret name>}}: vi henter denne verdien gjennom Azure Key Vault backed secret scopes
• USER_INITIALS: vi lar brukeren sette denne verdien selv

Det eneste brukerne måtte gjøre selv var dermed å lage et personlig cluster med denne cluster policyen og kjøre dbt_run.py ✨

Ting å tenke på

Denne løsningen fungerte utmerket for å raskt kunne onboarde nye, ikke-tekniske ressurser til dbt Core, og for å ta avgjørelsen om at man ønsket å gå videre med dbt Cloud. Dersom dette er en løsning man skulle gått for på en mer permanent basis, ville jeg tenkt over følgende:

• Automatisert linting: Linting med SQLfluff er standard praksis for dbt Core, men automatisering av dette (f.eks. pre-commit) er dessverre ikke støttet i Databricks.
• Autentisering: Som nevnt satte vi dette opp med OAuth machine-to-machine som betyr at alle brukere deler samme service principal, noe som ikke er ideelt for logging og sikkerhet.

Jeg syns det var veldig gøy å tenke litt utenfor boksen og komme frem til en løsning som gjør datautvikling tilgjengelig for flere, men det krever fortsatt noen avveininger.

Jeg vil gjerne høre din historie her! Hvordan onboardet dere de ansvarlige for utvikling av dataprodukter i dbt?