Snowflake prawie nigdy nie zawodzi. Zapytania się kończą, dashboardy się ładują, a nocne uruchomienie dbt świeci na zielono, i właśnie dlatego nikt nie zauważa, gdy konto po cichu staje się dwa razy droższe. Typowe zabezpieczenia, resource monitory, auto-suspend i jakiś dashboard kosztów, są zbudowane z myślą o awariach i limitach, a nie o powolnych, cichych zmianach zachowania.

digna to platforma Data Quality & Observability, a jedną z rzeczy, które można z nią obserwować, jest platforma, na której działają Twoje dane. To wideo bierze sześć przekonań, które wiele zespołów Snowflake ma na temat swojego rachunku, i sprawdza każde z nich na widokach account usage fikcyjnej firmy farmaceutycznej w projekcie demonstracyjnym digna.

Wszystko jest w account usage

Snowflake już zapisuje wszystko, czego potrzebujesz, w SNOWFLAKE.ACCOUNT_USAGE: pomiar warehouse'ów, historię zapytań, obciążenie warehouse'ów, kredyty serverless, storage, uruchomienia tasków i logowania. digna czyta te widoki tam, gdzie się znajdują, i uczy się, jak wygląda norma dla każdego warehouse'u, każdego modelu dbt i każdego raportu, łącznie z rytmem tygodniowym i zamknięciem miesiąca.

Sześć przekonań i co mówią dane

„Resource monitor nas ostrzeże”. Owszem, gdy limit się wyczerpie. Warehouse transformacyjny, który co tydzień rośnie po trochu, nigdy niczego nie uruchamia: w demo wzrósł z około 17 kredytów dziennie w lutym do ponad 30 w lipcu bez ani jednego czerwonego dnia, a analityka digna umieściła go na szczycie rankingu trendów na długo, zanim zadziałałby jakikolwiek limit.

„Większy warehouse po prostu działa szybciej”. Rozlicza się też według rozmiaru. Gdy warehouse analityków powiększono na potrzeby demo ze small do extra large i nikt go potem nie zmniejszył, jego kredyty na aktywną godzinę wzrosły z dnia na dzień ponad siedmiokrotnie, a digna zgłosiła to tego samego dnia.

„Auto-suspend załatwia bezczynność”. Dopóki ktoś go nie zmieni. Gdy auto-suspend analityków podniesiono do sześćdziesięciu minut, prosta reguła na dziennym snapshocie warehouse'ów, żaden warehouse powyżej dziesięciu minut, wykryła to tego samego dnia.

„Jeśli zapytanie się zakończyło, wszystko jest w porządku”. Iloczyn kartezjański działał sześć godzin i przeskanował około dziesięciu terabajtów na warehousie, który zwykle czyta pół terabajta dziennie, a trzy tygodnie później raport stracił partition pruning i przeskanował prawie trzy razy więcej danych niż zwykle. Oba się zakończyły i oba zostały zgłoszone.

„Serverless dba o siebie sam”. Dba, i za to płacisz. Gdy włączono search optimization dla dużych tabel sprzedażowych, kredyty wzrosły w ciągu dnia ponad ośmiokrotnie, a gdy nowy model semantyczny zaczął generować ogromny SQL, cloud services na warehousie raportowym wzrosły z około 10 do 60 % jego mocy obliczeniowej.

„Jeśli coś się zepsuje, dowiemy się o tym”. Czasami. Dwanaście z trzydziestu siedmiu tasków dbt padło jednej nocy na tym samym błędzie kompilacji, zmiana w widoku sprzedażowym zepsuła 176 zapytań dashboardów, a jeden dzień przyniósł o 238 nieudanych logowań więcej niż poprzedni. digna wykryła wszystkie trzy przypadki prostymi regułami na widokach account usage.

Metryki stojące za tymi kontrolami opisujemy w artykule jak śledzić wykorzystanie, koszty i wydajność Snowflake.

Czego digna nie rusza

Równie ważne jest to, co nie zostaje zgłoszone. Na koniec miesiąca warehouse finansowy zużywa prawie o połowę więcej niż w zwykły dzień, a ponieważ digna nauczyła się kalendarza zamknięć, pozostaje on zielony, podczas gdy stały alert odpalałby się co miesiąc.

Jedna strona rano albo jedno pytanie do asystenta

Wszystko to trafia każdego ranka na jedną stronę, prawie wszędzie zieloną i czerwoną tylko tam, gdzie coś zmieniło się w nocy. A jeśli wolisz pytać niż patrzeć, zapytaj swojego asystenta AI, które warehouse'y Snowflake zdrożały w tym roku: dzięki skillowi digna zapyta on serwer MCP digna i odpowie na podstawie wyników digna, warehouse po warehousie, bez czytania samych danych.

Wszystko działa w Twoim własnym środowisku, tuż obok widoków account usage, które czyta, więc nic nigdy nie opuszcza Twojej organizacji.

Umów demo i zobacz to na własnym koncie Snowflake.

Najczęściej zadawane pytania

Z których widoków Snowflake korzysta digna?

W demo: WAREHOUSE_METERING_HISTORY dla kredytów per warehouse i aktywną godzinę, QUERY_HISTORY dla czasu wykonania, przeskanowanych bajtów i błędów, WAREHOUSE_LOAD_HISTORY dla kolejek, METERING_DAILY_HISTORY dla kredytów serverless, storage, TASK_HISTORY dla tasków dbt i LOGIN_HISTORY dla nieudanych logowań, a do tego dzienny snapshot SHOW WAREHOUSES.

Czy resource monitor nie wystarczy?

Resource monitor działa, gdy wyczerpie się limit kredytów. Nie powie Ci, że warehouse urósł o 80 % w pięć miesięcy, choć każdy dzień wyglądał normalnie; ranking trendów digna to pokazuje, na długo przed osiągnięciem limitu.

Jak digna zauważa zapomniany resize warehouse'u?

Śledzi kredyty na aktywną godzinę dla każdego warehouse'u. Każdy stopień rozmiaru podwaja tę liczbę, więc resize widać tego samego dnia jako skok względem wyuczonego baseline'u warehouse'u, niezależnie od tego, jak bardzo był obciążony.

Czy szczyty na koniec miesiąca i kwartału wywołują alerty?

Nie. Sezonowość jest częścią wyuczonego baseline'u, więc warehouse finansowy, który na koniec miesiąca zużywa o połowę więcej, pozostaje zielony, a ten sam skok w zwykły dzień zostałby zgłoszony.

Czy Snowflake to jedyna platforma, którą digna może obserwować?

Nie. Obserwowanie platformy danych to jeden z przypadków użycia digna, platformy Data Quality & Observability; to samo podejście działa dla Databricks, Teradata i innych hurtowni danych, obok monitorowania samych danych.