Przejdź do:
Snowpipe – co to takiego?
Snowpipe jest bezserwerową usługą pozwalającą na ładowanie danych tak szybko, jak szybko znajdą się one w zasobie chmurowym. Platforma sama dobiera potrzebną moc obliczeniową do przetworzenia danych.
Wydajność Snowpipe
Kluczem do odpowiedniej wydajności jest prawidłowe użycie Snowflake i Snowpipe. Aby uzyskać pożądane rezultaty, należy traktować platformę jak hurtownię danych, która pracuje na zestawach danych większego rozmiaru niż pojedyncze transakcje.
Kiedy stosować Snowpipe? Czyli ETL vs. CDI
Aby wiedzieć, w jakich przypadkach warto używać Snowpipe, należy zrozumieć główne różnice pomiędzy koncepcjami klasycznymi (ETL czy ELT) a CDI (ang. continuous data ingestion). W przypadku klasycznych rozwiązań ETL o konkretnej porze mamy dostępny pełny zestaw danych, który jest pobierany, obrabiany i przeliczany. W przypadku CDI chcemy mieć dostęp do danych „już” i mogą się one pojawić w każdym momencie.
Snowpipe – jak to działa?

Idea działania Snowpipe jest jednakowa dla 3 głównych środowisk chmurowych (Azure, AWS, GCP).
Wyróżnić można 4 główne komponenty:
- Storage – miejsce składowania plików płaskich.
- Notification Service – usługa informująca Snowpipe Service, że pojawiły się nowe pliki.
- Snowpipe Service – przestrzeń w chmurze, która działa w sposób bezobsługowy (konfiguracja nie jest wymagana przy zmianach wolumenu danych).
- Snowflake Database – finalne miejsce składowania danych z plików.
W momencie pojawienia się pliku w miejscu składowania narzędzie chmurowe, np. Azure Event Grid, wysyła powiadomienie do Snowpipe Service, aby ten rozpoczął ładowanie plików do bazy Snowflake. Snowpipe sam rozpozna pliki, które już raz zostały załadowane, więc natychmiastowe usuwanie poprzednio załadowanych plików nie jest wymagane.
Przykłady użycia Snowpipe
- Analiza danych z mediów społecznościowych
Jednym z zastosowań Snowpipe może być analiza danych z mediów społecznościowych. Platformy takie jak Twitter, LinkedIn itp. pozwalają na automatyczne pobieranie postów o zadanych parametrach czy danych o użytkowniku (takich jak np. geolokalizacja, cały tekst tweeta, hashtagi itp.). Możemy więc ściągnąć informację o postach czy polubieniach pod postem o produkcie, przeprowadzić scoring użytkownika, czyli oszacować jego potencjał zakupowy, wykorzystując model Machine Learningowy, a następnie wysłać mu spersonalizowaną wiadomość: „Ten produkt dostępny jest u nas taniej”. Wszystko to przed upływem minuty! Wykorzystanie Snowpipe może więc przełożyć się na zwiększenie sprzedaży w e-commerce dzięki natychmiastowemu reagowaniu na działania konkurencji.
- Zarządzanie danymi kluczowymi dla organizacji
CDI jest świetnym dopełnieniem klasycznych procesów zasilania hurtowni danych. Przykładowo, nocny proces ETL może procesować pełny zestaw danych, a Snowpipe dodawać kluczowe dane, które muszą być zawsze aktualne.
- Analiza danych z urządzeń IoT
Według raportu „State of IoT 2021” liczba urządzeń mobilnych podpiętych do sieci rośnie i przekroczyła już 2 mld. Przekłada się to na potrzebę coraz wydajniejszej analizy danych. Snowpipe pozwala na analizę danych z samochodów, informacji z urządzeń domowych czy logów z telefonów w czasie rzeczywistym.
Dobre praktyki
- Optymalny rozmiar plików powinien mieścić się w przedziale między 100 a 250 MB (nie jest to jednak wymagane). Kluczowym założeniem rozwiązania ma być szybkość – jeśli nie mamy odpowiedniej ilości danych, agregujemy to, co się da, w możliwe największym pliku i tak ładujemy. Unikamy tworzenia plików transakcyjnych, np. 1 wierszem, ponieważ powoduje to problem z wydajnością, gdy plików jest dużo, oraz może nas narazić na dodatkowe koszty.
- Wydajne ładowanie danych za pomocą zapytania COPY INTO.
- Usuwanie plików historycznych. Nadmiar plików w miejscu składowania spowalnia ich obsługę, co winduje koszty.
Snowpipe – ile to kosztuje?
Użytkownik usługi Snowpipe płaci za czas ładowania zgodnie z naliczaniem sekundowym. 0,06 kredytu za każde 1000 załadowanych plików. Jeżeli na blobie istnieją pliki niepasujące do wzorca lub wcześniej załadowane, koszt nie zostanie naliczony.
Test wydajności Snowpipe
Poniżej znajduje się wyciąg rachunku za Snowpipe, który co 30 sekund próbował przetworzyć 1000 plików z 1 tweetem (Function App na najniższym poziomie nie dostarczał danych dostatecznie szybko, więc koszt jest niższy, niż być powinien. Przedstawiony koszt odpowiada przeprocesowaniu mniej więcej 400000 plików na godzinę) bez usuwania plików historycznych.

Poniżej znajduje się koszt obsługi ok. 600 plików i 400 tys. tweetów w nich zawartych co godzinę z usuwaniem plików historycznych

Jak widać, nieprawidłowa obsługa Snowpipe może wygenerować nawet niemal 36-krotnie wyższy rachunek za 10 razy mniej obsłużonych tweetów.
Od zera do 100k w 5 sekund… Czyli test szybkości Snowpipe
Jak szybko można ładować pliki do bazy? Wykres poniżej przedstawia 1,5-godzinny test.
- Oś x – przedstawia liczbę tweetów.
- Oś y – przedstawia różnicę czasu w sekundach między pojawieniem się pliku na blobie a załadowaniem go do bazy.

Jak widać, zdecydowana większość tweetów trafia do bazy w pierwszych 5 sekundach.
Snowpipe – czy ma jakieś wady?
- Brak triggerów – Snowflake jako platforma nie posiada klasycznych triggerów działających na wierszu, co ogranicza niektóre rozwiązania. Istnieje jednak możliwość symulowania swego rodzaju „triggera” (trigger w cudzysłowie, ponieważ tak naprawdę rozwiązanie to triggerem nie jest). Wystarczy założyć w tabeli stream, a następnie ustawić task, który będzie się uruchamiał w krótkim odstępie czasu i sprawdzał, czy w streamie są nowe dane. Tym sposobem możemy mieć „trigger” działający z opóźnieniem na większym zestawie danych.
- Brak opcji purge w COPY INTO – polecenie COPY INTO zawarte w Snowpipe jest nieco okrojone, brak opcji kasowania zmienia proste czyszczenie zaczytanych plików w przymus sprawdzania, co się zaczytało, i usuwania. Alternatywnie można kasować pliki starsze niż ok. 15 minut.
- Wymuszona obsługa przechowywania w chmurze – jest to właściwie cecha, a nie wada, ale dla niektórych rozwiązań (jak storage chmurowy Azure Blob czy S3) może być to problem, ponieważ nie mamy możliwości zaczytania danych z dysku sieciowego czy Sharepointa.
- Pierwsza implementacja – dokumentacja Snowflake jest bardzo czytelna, ale mimo to nie udało mi się zaimplementować rozwiązania, wykonując wdrożenie w 100% wedle dokumentacji. Jedną z różnic stanowiły uprawnienia powiadomień do kolejki, które zaczynały działać dopiero, gdy nadałem je na poziomie całego bloba. Drugi problem polegał na znalezieniu właściwego komponentu do obsługi eventów (jest nim Event Grid System Topic). Nie licząc tych dwóch drobnych nieścisłości, reszta implementacji przebiegła już bez problemu.
Podsumowanie
Snowpipe oraz idea CDI nie musi zastępować klasycznych rozwiązań ETL czy ELT – jest raczej ich naturalnym dopełnieniem. Sprawdza się świetnie wszędzie tam, gdzie liczy się czas reakcji. Poprawnie zaimplementowany, Snowpipe będzie tańszy i szybszy niż jego klasyczny odpowiednik.