A dbt modellek többsége lassíthatja a Snowflake-költségek csökkentését

A kritikus útvonal mutatja meg, mi számít igazán

A dbt Summit 2026 egyik szekciójában Ben Lerner, az Espresso AI vezérigazgatója arról beszélt, hogy egy dbt-projekt irányított gráfjában, vagyis DAG-jában, a modellek többsége nem befolyásolja a teljes feladat befejezésének idejét. A kritikus útvonal a függőségek leghosszabb, megszakítás nélküli lánca az első modelltől az utolsóig. A láncon kívüli elemeknél időtartalék marad.

Lerner szerint ezt az időtartalékot erőforrásként lehet kezelni. A dbt által Snowflake-be vagy Databricksbe küldött feladatokat az adattárház önmagában nem látja DAG-ként. A rendszer az utasításokat futtatja, miközben nem feltétlenül tudja, hogy több, egymástól független lekérdezés párhuzamosan is végrehajtható.

„A DAG-ban lévő dolgok többsége nincs a kritikus útvonalon. Ez nem fogja összességében hosszabbá tenni a feladat futását. Ezt az információt költségmegtakarításra használhatjuk, mert a dolgok lassabb futtatása olcsóbb lehet”, mondta Lerner a dbt Labs beszámolója szerint.

A kisebb warehouse sok esetben elegendő

A megközelítés alapja a warehouse méretezése. A Snowflake és a Databricks SQL warehouse-ai úgynevezett pólóméretekben érhetők el, és minden nagyobb méret körülbelül kétszeres számítási költséggel jár. A forrás szerint a teljesítmény eközben ritkán duplázódik.

Az Espresso AI javaslata szerint először meg kell találni a kritikus útvonalat, majd az azon kívül eső modelleket kisebb warehouse-ra kell irányítani. Egy öt másodperc alatt lefutó, rövid lekérdezés várhatóan kevéssé befolyásolja a teljes feladat futási idejét, ezért az ilyen lépéshez általában nincs szükség a legnagyobb elérhető méretre.

A döntés folyamatos újraértékelést igényel. Az adatmennyiség növekedésével egy korábban lineárisan skálázódó összekapcsolás viselkedése megváltozhat, és egy modell, amely egy negyedévvel korábban még a kritikus útvonalon kívül volt, később már hatással lehet a futási időre. Az Espresso AI ezt megerősítéses tanulással próbálja kezelni, így automatikusan módosítja a warehouse-hozzárendeléseket a DAG, az adatok és a lekérdezési minták változásai alapján.

Az Authentic Insurance negyedévente 40 százalékos megtakarításról számolt be

A dbt Summit előadásának második részében Saravana Kumar, az Authentic Insurance technológiai igazgatója mutatta be a megoldás használatát. A társaság speciális biztosítási programok elosztási rétegét működteti a vendéglátás, az energetika, a belföldi szállítmányozás és az építőipar területén. Több mint 100 partnerprogramja működik, a bevétele pedig 2025-ben 15-szörösére nőtt.

A nagyjából 70 fős munkaerőt kis adatcsapat támogatja. A vállalat adatplatformja DynamoDB-alapú OLTP-réteget és Snowflake-alapú OLAP-réteget kapcsol össze, a dbt pedig egységes szemantikai réteget biztosít az analitikai lekérdezésekhez. Az Espresso AI a dbt és a Snowflake között figyeli a modellfuttatásokat, majd automatikusan a megfelelő méretű warehouse-ra irányítja azokat.

A biztosítási adatoknál külön nehézséget jelent, hogy a károk tartalékait hónapokkal az első rögzítés után is módosíthatják. Emiatt a korábban betöltött adatok később hibássá válhatnak, és a tőlük függő folyamatokat nem lehet biztonságosan csak hozzáfűzéses működésre építeni. Minden új partnerprogram új adatforrásként jelenik meg egy már futó projektben, miközben egy adatminőségi probléma az ügyfelek és a biztosítók számára is láthatóvá válhat.

„Minden negyedévben 40 százalékot takarítunk meg, mert az Espresso-t futtatjuk a dbt modelljeink és a Snowflake között”, mondta Kumar a dbt Labs szerint. A beszámoló alapján a megtakarítást úgy érik el, hogy az adatcsapatnak nem kell kézzel beállítania az egyes warehouse-méreteket. A dbt Labs a dbt Summit 2026 előadásainak felvételeit igény szerinti megtekintésre kínálja.