dbt
MellannivåHur snabbar jag upp dbt-modeller och sänker Snowflake-/BigQuery-beräkningskostnaden?
I ett dbt-projekt är körtid och lagerräkning nästan samma mätvärde med två namn — att fixa det ena fixar oftast det andra.
Till skillnad från ett Spark-kluster du provisionerar själv fakturerar ett dbt-projekt som körs på Snowflake/BigQuery dig för lagrets beräkningstid — så en långsam modell är inte bara irriterande, det är en direkt kostnad. Det gör diagnoslistan kortare och mer handlingsbar än den kanske verkar.
Börja med elapsed_time vs. execution_time, per modell
dbts egen run_results.json (skriven efter varje dbt run/build) har
redan båda: total förfluten tid för anropet, och exekveringstid per modell. En modell vars exekveringstid är
liten i förhållande till total förfluten tid är inte problemet — något uppströms (lagerkö, beroendeordning)
är det. En modell vars exekveringstid faktiskt dominerar körningen är där du bör titta först.
Materialiseringsval är oftast den enskilt största hävstången
En modell materialiserad som en view som anropas av många nedströmsmodeller kör i praktiken
om sin egen logik varje gång den refereras — vilket förvandlar vad som borde vara en engångskostnad till en
återkommande. Att byta en ofta refererad, dyr transformation till table eller
incremental sänker ofta den totala lagerberäkningskostnaden dramatiskt, till priset av lite
lagring och en aning inaktualitet.
Felaktigt gjorda incremental-modeller kostar mer än fulla refreshes
En incremental-modell med ett dåligt valt unique_key eller ett
is_incremental()-filter som inte faktiskt begränsar skanningen (skannar hela källtabellen varje
körning "incrementellt") ger dig hela komplexiteten av incremental-materialisering utan besparingarna. Värt
att uttryckligen kontrollera: skannar den incrementella körningen faktiskt mindre data än en full refresh
skulle, enligt lagrets egen frågeprofil?
Parallellism (dbts threads-inställning) har ett tak
Fler trådar betyder fler modeller som körs samtidigt mot lagret — ända upp till punkten där de alla konkurrerar om samma beräkningsplatser i lagret, då fler trådar bara betyder mer kö, inte mer faktisk genomströmning. Det här taket beror på lagrets storlek, så ett värde kopierat från ett annat projekts konfiguration är inte nödvändigtvis rätt för ditt.
Vad opti-pipe läser från en dbt-körning: total förfluten tid och exekveringstid per modell direkt
från run_results.json — aldrig din SQL, modellnamn eller filsökvägar — för att flagga vilka
modeller som faktiskt driver körningens kostnad, samma "titta på de riktiga siffrorna, inte en gissning"-
ansats som Spark-reglerna ovan.
Se hur det här ser ut i din egen pipeline.
Ladda upp en riktig Spark-eventlogg, en dbt run_results.json eller en Flink-mätexport och få konkreta rekommendationer att godkänna innan de tillämpas — inte ännu en tumregel.