Azure Storage dla inżynierów danych – wszystko co powinieneś wiedzieć

Azure Storage jest jedną z najpopularniejszych usług w chmurze Azure. Jest tak dlatego, że świetnie spełnia ona swoje zadanie. Szczególne miejsce Azure Storage zajmuje w projektach związanych z  analityką czy też przetwarzaniem danych. W ramach niniejszego artykułu chciałbym przedstawić kilka cech opisywanej usługi, które w moim odczuciu powinien znać każdy kto zawodowo zajmuje się danymi i pracuje z chmurą Microsoftu. Zapraszam do lektury!

Po co storage?

To proste pytanie wbrew pozorom nie ma jednoznacznej odpowiedzi. W świecie szeroko pojętej analityki storage pełni przeróżne role. Pierwszą rzeczą na jaką należy zwrócić uwagę jest tymczasowe przechowywanie danych na potrzeby procesów ETL, ELT i innych. Dzięki temu, że sama przestrzeń na przechowywanie danych jest relatywnie tania możemy ją wykorzystać jako tymczasowe środowisko do zrzucania danych. Zdarza się, że w  wielu przypadkach jest to konieczne np. gdy chcemy ładować dane z on-premise do Azure SQL bezpośrednio to w sieci źródłowej musimy otworzyć port po którym komunikuje się Azure SQL czyli 1433 co nie zawsze jest możliwe i to właśnie storage może być wykorzystany jak warstwa pośrednia między źródłem, a miejscem docelowym. Inny przykład to Synapse SQL Dedicated Pool – co prawda możemy tam ładować dane używając tradycyjnego BULK INSERT jednakże nie jest to najwydajniejszy sposób. Zdecydowanie lepszym podejściem jest użycie COPY INTO lub POLYBASE, które to ładują dane bezpośrednio do Worker Nodów właśnie ze storage. Tego typu przykładów można znaleźć zdecydowanie więcej.

Z drugiej zaś strony jeśli chcemy nasze dane przechowywać na stałe na storage to w żadnym wypadku nic nie stoi na przeszkodzie. Tego typu rozwiązania są coraz bardziej popularne również ze względu na fakt, iż mamy w Azure wydaje silniki pozwalające odpytywać struktury bez kopiowania danych ze storage do wewnętrznych struktur konkretnych narzędzi. Dobrym przykładem będzie tu chociażby Synapse SQL Serverless, który stworzony jest właśnie po to aby odpytywać przechowywane na Azure Storage. Mogę również powiedzieć, że cała koncepcja Lakehouse oraz Synapse’owy Lake Database opiera się właśnie o wydajne odpytywanie Azure Storage. Dodatkowo usługa pozwala na zdefiniowanie wysokiej dostępności, posiada wiele interfejsów dostępowych i jest stosunkowo łatwa w zarządzaniu dzięki czemu na przestrzeni ostatnich kilku lat stała się kluczowym elementem wielu architektur przetwarzania danych w Azure.

Tak więc po co nam Azure Storage? A no po to, żeby tanio, wydajnie i bezpiecznie przechowywać dane.

Azure Data Lake Storage Gen 2

W przytłaczającej większości przypadków jeśli tworzymy storage na potrzeby analityczne to wybieramy tzw. Data Lake Storage Gen 2. Czym on jest i o co ogólnie chodzi? Opiera sie na standardowym BLOB Storage z tym, że jest przeznaczony pod workload analityczny. Dzięki temu, że ADLS wprowadza hierarchiczność folderów/kontenerów zapytania o konkretne pliki mogą być wykonywane zdecydowanie szybciej niż jak byśmy je wykonali na zwykłym Blob Storage. Hierarchiczność w tym przypadku oznacza możliwość partycjonowania danych – wygląda to następująco:

Płaska struktura (Flat namespace) BLOB Storage:

Hierarchiczność (Hierarchical namespace) Data Lake Storage:

Jak widać odnalezienie konkretnego pliku jest zdecydowanie bardziej efektywne w drugim przypadku. Dlatego też w przypadku gdy chcemy optymalnie odpytywać dane na potrzeby analityczne pamiętajmy żeby włączyć hierarchical namespace:

W nazwie znajdziemy również słowo “Gen2” oznaczające generację drugą, generacja pierwsza oczywiście znacząco się różni jednak na ten moment warto zapomnieć o jej istnieniu i zawsze dla nowych projektów wybierać Gen2.

Hot, Cold & Archive

Wiele osób zaczynających swoją przygodę z Azure, a szczególnie z Storage napotyka na pojęcie tzw. Access Tiers. Czym one są? To nic innego jak sposób organizacji danych na storage polegający na tym, że dzielimy nasze dane według kryterium dostępowego i tak:

• Hot – tier przeznaczony dla danych które są często odczytywane przez co dostępne są stosunkowo szybko, koszt dostępu jest najmniejszy ale koszt przechowywania jest największy. Dostęp do danych jest online tzn. po wysłaniu żądania odrazu mamy dane.
• Cold – tier przeznaczony dla danych które są odczytywane sporadycznie przez co dostępne stosunkowo szybko, koszt dostępu jest większy niż w tier Hot ale koszt przechowywania jest mniejszy. Podobnie jak wyżej dostęp do danych jest online tzn. po wysłaniu żądania odrazu mamy dane.
• Archive – tier przeznaczony dla danych które są odczytywane bardzo rzadko lub muszą być przechowywane ze względów prawnych lub compliance. Koszt dostępu jest największy spośród wspomnianych trzech tier ale koszt przechoywania jest zdecydowanie najniższy. W przeciwieństwie do dwóch powyższych jest to tier offline czyli dane nie są dla nas dostępne odrazu ale po upływie godzin. Archive tier nie jest dostępny we wszystkich możliwych konfiguracjach redundancji więc przed zaplanowaniem warto zapoznać się w jakiej konfiguracji jest on dostępny.

Jak widzicie mamy zatem kilka możliwości i w zależności od potrzeb dzielimy nasze dane na określone tiery. Warto tutaj wspomnieć, że obiekty mogą być “przenoszone” pomiędzy tierami, ręcznie lub automatycznie za pomocą Lifecycle Management. Mechanizm ten “przesuwa” pliki do określonych tier po spełnieniu określonych warunków lub je usuwa.

Kompatybilność z Hadoop

Azure Data Lake Storage Gen2 pozwala na dostęp i zarządzanie danymi tak jak ma to miejsce w HDFS dzięki sterownikowi ABFS. Dzięki temu takie narzędzia jak HDInsight czy też Databricks bez żadnego problemu mogą wspópracować z tą usługą. Dodatkowo sterownik ten został zoptymalizowany pod workload bigdata. Do samego ADLS można dostać się za pomocą endpointa BLOBowego (blob.core.windows.net) jednakże myślę, że dobrą praktyką jest używanie endpointa sterownika ABFS czyli dfs.core.windows.net posiadającego pewne zalety w stosunku do blob.core.

Więcej na temat sterownika: link

Redundancja

Dane na storage są przechowywane w kilku kopiach i cały ten proces jest dla nas transparentny, aczkolwiek całkowicie konfigurowalny.

Dwa podstawowe ustawienia redundancji to:

• LRS – Locally Redundant Storage – dane przechowywane są w trzech kopiach w ramach pojedynczego data center głównego regiony w którym znajduje się nas storage. Dane kopiowane są synchronicznie. Pozwala to na dostępność na poziomie 11 dziewiątek tzn. 99.999999999%. Chroni nas przed takimi problemami jak np. awaria dysku na którym znajdują się dane.
• ZRS – Zone-redundant storage – dane kopiowane i przechowywane są  w ramach trzech Availability Zone w głównym regionie w którym znajduje się storage. Dla przypomnienia powiem, że Availability zone  to fizycznie odseparowane data center z niezależnym zasilaniem, chłodzeniem, siecią w ramach pojedynczego regionu itp. Jest to oczywiście usprawnienie w stosunku do LRS i chroni nas przed awarią pojedynczego data center. Dzięki temu mamy dostępność na poziomie 12 dziewiątek. Warto wspomnieć, że Microsoft rekomenduje to ustawienie dla Data Lake Storage Gen 2.

Powyższe dwa modele redundancji opierają się na pojedynczym (głównym regionie). Każdy region jest sparowany z innym odpowiednio oddalonym regionem np. West Europe z North Europe. To właśnie region sparowany (Secondary) może zostać wykorzystany do ustawienia redundancji naszego storage. Mamy tutaj kilka możliwości:

• GRS – Geo Redundant storage – dane są kopiowane synchronicznie i przechowywane w trzech kopiach tak jak w LRS i dodatkowo są kopiowane asynchronicznie do regionu zapasowego gdzie również przechowywane są w trzech kopiach używając LRS.
• GZRS – Geo-Zone redundant storage – dane są kopiowane synchronicznie tak jak w ZRS i dodatkowo dane są kopiowane asnychronicznie do regionu zapasowego i tam podobnie jak w poprzednim przypadku przechowywane są w trzech kopiach używając LRS.

Oba powyższe modele chronią nas przed utratą danych w przypadku wystąpienia awarii całego regionu. Dane w drugim regionie nie są dostępne aż do momentu failovera. Jeśli chcialbyśmy aby dane dodatkowo były dla nas dostępne w ramach drugiego regionu to możemy użyć RA-GRS oraz RA-GZRS, które konfiguracyjnie działają tak jak powyższe z tym, że dostajemy również adres do endpointa w drugim regionie.

Jak już wspominałem kopiowanie odbywa się transparentnie, podobnie jak sprawdzanie jakości danych. W tym wypadku Azure regularnie sprawdza jakość przy pomocy CRC i w przypadkuu wyłapania błędu jest on naprawiany przy pomocy jednej z dostępnych, poprawnych kopii.

Pamiętajmy aby dostosować odpowiednie ustawienie do potrzeb gdyż im większa dostępność usług tym większy koszt przechowywania danych.

Uwierzytelnienie

W przypadku Azure Data Lake Storage Gen 2 mamy kilka możliwości uwierzytelnienia.

• Shared Key (Account Key) – dostęp po kluczu Azure Storage. Mając klucz do storage aplikacja kliencka ma pełny dostęp do zasobu więc powinniśmy tego unikać jeśli to możliwe. Mamy dwa klucze dla konta i jeśli już musimy ich używać to powinniśmy je regularnie rotować – przykładową konfigurację przedstawiłem w jednym z moich poprzednich wpisów (link). Od jakiegoś czasu mamy możliwość wyłączenia tego sposobu uwierzytelnienia i jeśli nie ma przeciwwskzanań polecam to zrobić link.
• Shared Access Signature – SAS niegdyś był bardzo popularną metodą dostępową. Sygnatura ta pozwala na dostęp nie tylko na poziomie całego konta ale również konkretnej lokalizacji, a dodatkowo może być ograniczona czasowo. Jest zabezpieczona kluczem Access Key tak więc aby odwołać SAS nalezy przegenerować klucz. Jest oczywiście kilka rodzajów SAS z różnymi opcjami i scenariuszami użycia (link).
• Azure Active Directory – dostęp po tożsamości AAD czyli możliwość nadania uprawnienia dla użytkownika, grupy czy też Service Principal. W większości przypadków zdecydowanie najlepsza metoda ze wszystkich dostępnnych ze względu na centralizację zarządzania tożsamościami. Dodatkowo w takim przypadku możliwa jest implementacja passwordless czyliuwierzytelnienia bez konieczności zarządzania hasłami itp. np. Data Factory operując na Storage może mieć do niego dostęp po Managed Identity.
• Anonymous – publiczny dostęp anonimowy czyli bez konieczności uwierzytelnienia. Jeśli nie ma takiej potrzeby można to ustawienie oczywiście wyłączyć link.

API

Do storage możemy dostać się na mnóstwo różnych sposobów. Wspomnę tylko, że mamy dedykowane biblioteki dla:

• .NET
• Java
• Python
• JavaScript
• C++
• Ruby
• PHP

Ponadto mamy oczywiście REST API, dedykowane cmdlety oraz komendy Powershell oraz Azure CLI.

A jeżeli chcemy graficznie przejrzeć dostępne dane to najłatwiej to zrobić poprzez darmowy Storage Explorer czyli narzędzie desktopowe pozwalające graficznie obsłużyć nasz storage:

Również z portalu jest możliwość użycia powyższego narzędzia lub widoku na zawartość storage tak więc możliwości interakcji jest bardzo dużo.

Dokumentacja: link

AzCopy

Jednym z najwygodniejszych narzędzi do pracy ze storage jest mały programik przygotowany przez Microsoft o nazwie AzCopy (link). Narzędzie to dostępne jest z linii komend i za pomocą prostej składni jesteśmy w stanie zarządzać danymi na storage. W przeszłości zdarzyło mi się już pisać na ten temat https://pl.seequality.net/kopiowanie-plikow-na-azure-storage-przy-pomocy-azcopy/więc odsyłam do tamtego artykułu. Zgadzam się z Michałem w komentarzu, że szczególna wzmianka dotyczy AzCopy Sync dzięki której jesteśmy w stanie zsynchronizować dwie różne lokalizacje. Scenariusz użycia takiego podejścia jest kilka ale pierwszy jaki przychodzi do głowy to inicjalne zasilenie storage gotowymi plikami lub chociazby przerzucanie danych pomiędzy środowiskami (i błagam nie róbcie tego przy pomocy ADFa).

Query accelaration

Funkcjonalność bardzo często pomijana i zapominana. ADLS posiada mechanizm, który pozwala niektórym usługą zoptymalizować proces odczytu danych ze storage poprzez pobieranie tylko tych danych, które są potrzebne. Jest to mechanizm na zasadzie “predicate pushdown” gdzie określone filtrowanie odbywa się już w czasie pobierania danych z dysku, a nie dopiero po przesłaniu danych do aplikacji. Według dokumentacji mechanizm ten jest wykorzystywany przy odczytywaniu plików CSV i JSON.

Aby lepiej to zobrazować posłużmy się przykładem z dokumentacji (link).

1. Wysłanie zapytania do storage z określonym predykatem filtrujacym.

2. Mechanizm Query Accelarator parsuje określone zapytanie i rozdystrybuuje pracę aby przefiltrować dane.

3. Procesor odczytuje dane z dysku, prasuje i filtruje dane zgodnie z określonym predykatem.

4. Poszczególne dane odczytane ze storage są łączone i wysyłane do aplikacji klienckiej.

5. Aplikacja dostaje już wstępnie przefiltrowane dane.

Mechanizm jest niezwykle ciekawy i co ciekawe nie działa jedynie na ADLS ale również na zwykłym BLOB Storage.

Query Accelaration jest domyślnie wyłączone i możne je włączyć np. poprzez komnendę Powershell:

Register-AzProviderFeature -ProviderNamespace Microsoft.Storage -FeatureName BlobQuery

Ze względu na zaangażowanie dodatkowego compute jest to usługa dodatkowo płatna i takwg cennika dla tier hot na moment pisania niniejszego artykułu w West Europe cena wynosi 0.00072 Euro za GB.

Bardzo ciekawa opcja!

Premium tier

Każdy storage możemy utworzyć w jednym z dostępnych tierów dostępowych. Oprócz standardowego general purpose v2 mamy również tier premium, który oferuje dużo mniejsze opóźnienie. Konwersja pomiędzy general purpose, a premium nie jest możliwa dlatego też warto z góry zaplanować odpowiednio swoje rozwiązanie. Ogólnie rzecz biorąc warto rozważyć tego typu storage szczególnie wtedy gdy mamy do czynienia np. z architekturą lakehouse gdzie np. poprzez Spark czy Synapse Serverless odpytujemy pliki Delta znajdujące się na storage. Więcej zastosowań tej technologii znajdziecie tutaj.

Pamiętajmy również o fakcie, że nie wszystkie funkcjonalności szeroko pojętego storage czy data lake są wspierane w momencie gdy wybieramy Premium Tier dlatego warto zaglądać do dokumentacji aby się z tym zapoznać (link) jeszcze przed dokonaniem wyboru.

Change feed

Mechanizm będący niczym innym jak logiem zawierającym informacje o tym jakie działania były wykonywane na plikach oraz ich metadanych. Nie jest on dostępny na data lake ale na zwykłym blob storage ale i tak postanowiłem o nim napisać bo znalazłem kilka zastosowań. Log ten sam w sobie jest uporządkowany, trwały i tylko do odczytu. W praktyce sprowadza się to do tego, że na storage powstaje specjalna lokalizacja ($blobchangefeed) gdzie odkładane są dane w postaci formatu AVRO.

Dane tego typu możemy dowolnie analizować np. poprzez Spark. funkcjonalność jest gotowa do włączenia chociażby z poziomu portalu:

Jeśli macie potrzebe kontrolować co, gdzie i jak się dzieje na storage to jest to jedna z opcji. Bardziej szczegółowy opis funkcjonalności znajdziecie tutaj.

Soft-delete

Mechanizm pozwalający na “usunięcie” określonego kontenera lub pliku, które to obiekty w gruncie rzeczy są przez pewien okres nadal przechowywane. Przydatne w przypadku gdy ktoś przypadkowo usunie jakiś plik i chcemy go przywrócić. Warto zdawać sobie sprawę z istnienia tego mechanizmu ale włączać go należy tylko w określonym celu. Dokumentacja: link

BLOB Snapshots

Podobnie jak powyżej funkcjonalność o któej warto wiedzieć mimo, że na ten moment dla Data Lake jest ona w fazie preview. Snapshot to nic innego jak kopia do odczytu danego obiektu stworzona na dany punkt w czasie. Możemy sobie wyobrazić sytuację, że dany obiekt jest zmieniony, a my nadal chcemy mieć dostęp do danych przed jak i po zmianie. W takim przypadku Snapshot może być przydatny. Warto pamiętać, że mechanizm ten jak wszystko należy traktować jako dostępną funkcjonalnosć i wykrzoystywać tylko w razie zaistnienia zapotrzebowania bo każdy snapshot zajmuje dodatkowe miejsce za które należy płacić. Dane ze snapshotu mogą oczywiście być przenoszone na tier cold co pomoże nieco zoptymalizować koszty.

Wartym zauważenia jest również fakt w jaki sposób odwołujemy się do konkretnych snapshotów bo np. URI do obiektu wygląda następująco:

http://sample.core.blob.windows.net/container/file

to aby odwołać się do snapshotu wygląda to następująco:

http://sample.core.blob.windows.net/container/file?snapshot=2022-03-19T22:22:22.00000000Z

Czyli bardzo intuicyjne i proste w użyciu.

Dokumentacja: link.

Monitoring

Tak jak większość o ile nie wszystkie usługi w ramach Azure tak również storage generuje różnego rodzaju metryki oraz logi. Logi te mogą być generowane poprzez Azure Monitor czyli serwis pozwalający całościowo monitorować usługi w ramach Azure. Logi te mogą być monitorowane lub też analizowane w czym bez wątpienia może być pomocny Azure Log Analytics.

Sama konfiguracja monitoringu jest stosunkowo prosta i sprowadza się do wybrania jakiego typu logi chcemy gromadzić, analizować i wskazać gdzie te dane mają być przesłane, a mogą w gruncie rzeczy do trzech miejsc:

• Log analytics – czyli serwis do interaktywnej analizy logów
• storage account – inny storage account gdzie będą te dane przechowywane i inne narzędzia mogą je odczytywać w celach np. raportowych
• Event hub – logi będą wysyłane w postaci streamu na endpoint event hub gdzie mogą być odbierane przez kolejne narzędzia i np. wizualizowane w locie.

Bardzo przydatna opcja, która jest dostępna również z innych serwisów dzięki czemu możliwe jest zbudowanie skonsolidowanego widoku na dane.

Dokumentacja: link.

Jak widzicie Azure Storage i wchodzący w jego skład Azure Data Lake Storage jest usługą niezwykle bogatą w funkcjonalności, a co oczywiste to nie wymieniłem ich wszystkich a tylko kilka z nich które uznałem za najważniejsze. ADLS sam w sobie jest bardzo często sercem rozwiązań analitycznych opartych o Azure dlatego też polecam dogłębnie zapoznać się z jego funkcjonalnościami. Mam nadzieję, że mój artykuł przypadł Wam do gustu. Pozdrawiam!