Snowflake, czyli lawina możliwości

Zawsze byłem zwolennikiem nieskomplikowanych architektur rozwiązań IT – im mniej komponentów rozwiązania, tym łatwiej zarządzać całym systemem, szybciej można go rozwijać i skuteczniej utrzymywać. W praktyce jednak bardzo ciężko znaleźć kompromis pomiędzy możliwościami konkretnych składowych rozwiązania a wymaganiami stawianymi przez klienta – stąd i zdarzało mi się pracować przy architekturach złożonych z kilkunastu składników. Na szczęście wraz z rozwojem usług chmurowych możemy skuteczniej dobierać takie komponenty, które pozwolą uzyskać oczekiwany efekt przy właśnie jak najmniejszej liczbie usług. Mało tego, dzięki rozwiązaniom chmurowym możemy również bez problemu dobierać usługi od różnych dostawców, aby połączyć je w jeden system. Jako certyfikowany ekspert w obszarze Microsoft BI powinienem w tym momencie rozpisywać się o Azure Synapse – jednak w tym artykule chciałbym opisać usługę Snowflake.

Czym jest Snowflake?

Snowflake przede wszystkim jest usługą udostępniającą silnik bazodanowy dedykowany rozwiązaniom hurtowni danych i przetwarzaniu dużych wolumenów danych. To bardzo ważne, aby już na samym początku zwrócić uwagę właśnie na ten aspekt, ponieważ wykorzystanie Snowflake jako bazy aplikacyjnej, gdzie operujemy na pojedynczych rekordach, zupełnie się nie sprawdzi.

Możliwości Snowflake

Snowflake może przyjąć dane z różnorakich źródeł, poczynając od klasycznych baz danych, aż po strumienie danych IoT. Zgromadzenie samych danych to nie koniec i na wyjściu chodzi przede wszystkim o jak najszybsze przeanalizowanie i wykorzystanie danych tak, aby czerpać z nich wymierne korzyści – czy to w postaci raportów czy wyników przygotowanych przez wyrafinowane algorytmy z obszaru Data Science. Cała magia oczywiście dzieje się pośrodku, czyli właśnie w silniku Snowflake. Możemy tu składować olbrzymie ilości danych, tworząc warstwę Data Lake. Tak samo jak w klasycznym Data Lake, dane nie muszą być sprowadzone do ustrukturyzowanego formatu i możemy tu przechowywać informacje w najróżniejszej formie – łącznie z komunikatami zapisanymi w XML czy JSON.

Co bardzo interesujące, dane będą dostępne z poziomu języka SQL i nie będzie konieczne ich przekształcanie na zewnątrz usługi. Mamy zatem w tym miejscu pierwszą zaletę ważną dla minimalistycznej architektury – po tym, jak dane znajdą się w Snowflake, praktycznie wszystko, począwszy od operacji na danych a na konfiguracji usługi kończąc, dostępne jest za pomocą poleceń SQL. Bardzo łatwo zatem wdrażać tę technologię w oparciu o specjalistów znających ten język programowania – programiści znający najpopularniejsze silniki baz danych odnajdą się tu bez większych problemów.

Hurtownia danych w chmurze

Wykorzystanie danych źródłowych w łatwy sposób jest ważne, ale ciężko mówić w tym momencie o hurtowni danych. Aby dojść do właściwej struktury hurtowni, musimy wykonać szereg przekształceń danych potrzebnych np. do integracji danych z różnych systemów. Tu warto wymienić kolejną zaletę Snowflake, czyli bardzo wydajny silnik bazodanowy, dzięki któremu transformacje możemy realizować wewnątrz samej usługi, nie angażując kolejnych technologii (Databricks, Spark itd.). Takie podejście, oprócz oczywiście wpisywania się w minimalistyczną architekturę, pozwala znacząco oszczędzić czas potrzebny na operacje takiego typu.

Wydajność rozwiązania

To, w jaki sposób uzyskiwana jest taka wysoka wydajność, jest również bardzo ciekawym zagadnieniem wykraczającym jednak poza ramy tego artykułu, ale należy tu wspomnieć o tym, że wszystkie procesy zmierzające do jej zapewnienia dzieją się wewnętrznie bez konieczności sterowania nimi ręcznie. Na podstawowym poziomie wystarczającym do dużej części projektów nie ma potrzeby w ogóle przeprowadzania jakichkolwiek dodatkowych operacji optymalizacyjnych.

Te ogromne zalety, które wskazałem powyżej, ostatecznie pozwalają na zbudowanie wydajnego rozwiązania w oparciu tylko o kilka komponentów do wyboru:

Ponieważ większość dostępnych technologii wspiera Snowflake, bazując na takiej architekturze pozostaje nam tylko:

• Dobrać narzędzie ETL/ELT (Azure Data Factory/SSIS, Talend, Pentaho, Informatica itd.), aby załadować dane – przy czym tu podejście ELT będzie najbardziej wskazane, tak aby część „T”, a więc transformacji danych, realizować już wewnątrz silnika Snowflake.
• Wykorzystać język SQL do operacji na danych – tu oprócz wydajności silnika ma duże znaczenie również fakt, że język SQL jest cały czas jednym z najbardziej popularnych języków programowania, co pozytywnie wpływa na tempo skompletowania zespołu do projektu czy wręcz możliwość zaangażowania developerów baz danych bez doświadczenia w środowisku chmurowym
• Dobrać narzędzie do wizualizacji danych – do Snowflake można podłączyć się z poziomu głównej trójki: Power BI, Qlik, Tableau, jak i wielu innych narzędzi Business Intelligence.
•  

Kompletny projekt Business Intelligence ze Snowflake

Ostatecznie, w minimalnej wersji, w oparciu o tylko 3 technologie możemy zrealizować kompletny projekt Business Intelligence posiadający Data Lake, hurtownię danych oraz dostępne dla szerokiego grona odbiorców raporty. Warto tu także podkreślić, że dzięki wykorzystaniu chociażby trybu Direct Query w Microsoft Power BI możemy w łatwy sposób zapewnić raportowanie na dowolnym poziomie agregacji – od danych ogólnych, takich jak zagregowane wyniki, po szczegółowe dane, łącznie z możliwością dojścia do pojedynczych rekordów nawet w sytuacji, gdy operujemy na terabajtach danych.

Zalety Snowflake

Na ostatniej wymianie wiedzy w Inetum, kiedy prezentowałem możliwości Snowflake, kolega Leszek (pozdrawiam go z tego miejsca) nazwał Snowflake „self-service data warehouse” i muszę przyznać, że w kontekście wysokiej wydajności (która, jak już wspomniałem powyżej, jest uzyskiwana w sposób automatyczny), bardzo spodobało mi się to określenie. Praca z tą technologią jest, najzwyczajniej w świecie, przyjemna i pozwala budować rozwiązania bardzo szybko przy umiarkowanym nakładzie pracy. W obszarze zwiększonej szybkości budowy kompletnego rozwiązania warto wspomnieć jeszcze o kilku kolejnych zaletach Snowflake:

• Możliwość klonowania danych w ekspresowym tempie – chyba nigdy wcześniej postawienie środowiska developerskiego bazującego na danych produkcyjnych nie było tak proste i szybkie – nie ma potrzeby uruchamiania procesu ETL/ELT, odtwarzania backupów itd. Wystarczy proste polecenie CLONE i dosłownie chwilę potem, niezależnie od rozmiaru danych, dane są gotowe do użycia w nowym miejscu.
• Możliwość powoływania nowych serwerów obliczeniowych – Snowflake ma odseparowaną warstwę danych od warstwy obliczeniowej, zatem możemy powoływać w dowolnym momencie kolejne serwery obliczeniowe do realizacji konkretnych celów i tak na potrzeby procesu ETL/ELT dobieramy maszynę np. o średniej mocy obliczeniowej, która ma działać przez kilka godzin w ciągu dnia, a na potrzebę nieskomplikowanych raportów dobieramy mniejszą maszynę działającą przez cały dzień. Serwery takie działają oddzielnie od siebie, dzięki czemu uzyskujemy bardzo dużą elastyczność bez ryzyka przeskalowania rozwiązania. Ponadto wydzielając dedykowane konkretnym zadaniom serwery, łatwo będzie śledzić koszty poszczególnych części rozwiązania.
• Dynamiczne skalowanie – w momencie, gdy brakuje mocy obliczeniowej, przeskalowanie w górę czy wszerz serwera obliczeniowego nie stanowi żadnego problemu… Jeśli tylko akceptujemy, że w tym momencie będziemy więcej płacili za całą usługę. Oczywiście jeśli nie potrzebujemy już większej mocy obliczeniowej, równie sprawnie jak podczas skalowania w górę możemy przeskalować serwery w dół. Stwarza to spore możliwości optymalizacji czasu poszczególnych operacji oraz pozwala rozsądnie zarządzać kosztami.
• Niemal całkowity brak nakładów administracyjnych – na podstawowym poziomie nie musimy zajmować się, ważnymi przecież w innych silnikach bazodanowych zagadnieniami, takimi jak tworzenie indeksów i innych struktur optymalizacyjnych. Dzięki opcji Time Travel pozwalającej nam, w iście magiczny sposób, przeglądać stan danych sprzed różnorakich operacji (aktualizacja, usunięcie rekordów czy nawet usunięcie tabeli) możliwe jest podejście (aczkolwiek polecam tu rozwagę), w którym nie tworzy się backupów.
•  

Czy Snowflake ma jakieś wady?

Owszem ma i z mojej perspektywy są to przede wszystkim:

• Brak możliwości tworzenia procedur składowanych w czystym języku SQL – owszem można tworzyć procedury, ale trzeba posiłkować się elementami języka JavaScript, co w pewnym sensie stoi w konflikcie z jak najmniejszą liczbą elementów które muszą być użyte w rozwiązaniu,
• Trochę jeszcze niedopracowana warstwa widoków systemowych – wydaje się, że można by zrealizować ją lepiej – ot, chociażby po to, aby lepiej śledzić czas zadziałania mechanizmów autoskalowania, łączenie z określeniem, kiedy nastąpiło skalowanie w dół
• Pewne trudności w kontrolowaniu kosztów usługi „Cloud Service” – w tym miejscu chodzi mi przede wszystkim o konieczność monitorowania kosztów związanych z działaniem Snowflake, aby w odpowiednim momencie zareagować w wypadku zwiększania się kosztów Cloud Service.

Trzeba jednocześnie w tym miejscu zaznaczyć, że Snowflake jest bardzo dynamicznie rozwijany i usprawniany, więc najprawdopodobniej to, co dziś może być jeszcze jakimś problemem, niedługo będzie już rozwiązane.

Snowflake – podsumowanie

Reasumując, uważam, że Snowflake powinno rozważać się jako podstawową technologię do realizacji hurtowni danych w nowym projekcie Business Intelligence. Jest tu oczywiście parę niuansów, na które trzeba zwrócić uwagę, i trzeba mieć pomysł na to, jak optymalnie użyć tej technologii. Jednak odpowiednie użycie Snowflake do budowy hurtowni danych w chmurze sprawia, że praca staje łatwiejsza, projektem można skuteczniej zarządzać, a efekty pracy widać dużo szybciej niż przy wykorzystaniu klasycznych silników bazodanowych.