Big Data w chmurze Azure 

Big Data w chmurze dla każdego?  

Termin „Big Data” oryginalnie został stworzony ponad 30 lat temu, ale jak wszystko w IT, w ciągu 3 dekad ewoluował i rozwijał się, towarzysząc ekspansji Internetu i źródeł informacji. Do niedawna był to termin opisujący systemy, na które mogły sobie pozwolić jedynie wielkie korporacje i wiodące startupy z dużym finansowaniem – wymagało to wszak wielkich nakładów kapitałowych na rozproszone klastry utrzymujące infrastrukturę Big Data. Nic dziwnego, że na wyłuskiwaniu informacji w wielkiej skali zbudowały swoją potęgę takie korporacje jak Google czy Facebook. Liderzy obserwujący, co się dzieje na rynku, nie mogli zaprzeczyć, że zbieranie i analiza dużych zbiorów danych może dać wymierne korzyści biznesowe.  

Chęć zbudowania nowej wartości w oparciu o wielkoskalową analizę danych rosła, ale brak było odpowiednich narzędzi, aby sprawdzić potencjał drzemiący w danych, jednocześnie zachowując rozsądne koszty (np. w modelu try-before-buy). Na tę potrzebę odpowiedzieli dostawcy platform chmurowych, oferując w ostatnich latach ogromną ilość usług zorientowanych na przetwarzanie danych – niektóre wprost w modelu PaaS (Platform-as-Service). W wyniku tego możemy zaobserwować eksplozję popularności systemów chmurowych Big Data. Po prostu dzisiaj już każdego stać na to, żeby spróbować wycisnąć ze swoich wielkich zbiorów danych maksimum informacji i… wartości.  

Przeczytaj także: Kim jest DevOps?

Ekosystem Azure’a a architektura Big Data 

Na przestrzeni kilkunastu lat ugruntowały się dwa podstawowe modele wysokopoziomowej architektury Big Data – Lambda i Kappa. Model Lambda może uchodzić za fundamentalny. W jego skład wchodzą: 

• Magazyny danych (ang. Stores). 
• Systemy przetwarzania wsadowego (ang. Batch Layer). 
• Systemy przetwarzania strumieniowego – w czasie zbliżonym do rzeczywistego (ang. Speed Layer, Near-Realitme – Stream Processing Systems). 
• Magazyny udostępniające dane i wyniki analiz (ang. Serving Layer). 
  
  

W modelu Lambda oba systemy przetwarzania danych są niezależne i równoległe. W międzyczasie powstała koncepcja architektury Kappa, w której model przetwarzania strumieniowego jest podstawowym elementem, a model przetwarzania wsadowego jest niejako procesem potomnym. Jest to model prostszy, ale bardziej wyspecjalizowany – odpowiedni w przypadku, gdy głównymi źródłami danych są dane napływające w czasie rzeczywistym (np. logi, tweety / wiadomości, komunikaty z urządzeń IoT).  

Usługi składowania danych (bez limitu) 

Centralnym elementem każdego systemu Big Data są magazyny danych. W nich przechowujemy ogromne ilości surowych (nieprzetworzonych) danych, które zebraliśmy ze źródeł, ale także zbiory „potomne” powstałe w procesie transformacji, korelacji i analizy danych źródłowych. Azure umożliwia przechowywanie danych w dwóch typach magazynów: Azure Storage (AS) i Azure Data Lake Storage (ADLS). W przypadku obu usług rozliczani jesteśmy za rozmiar składowanych danych i operacje na nich wykonane (podstawowe: zapis i odczyt oraz inne). Magazyn Azure Storage oprócz możliwości składowania dużych plików (Blob) ma też „wbudowane” dodatkowe usługi:  

• Files – serwer plików udostępniający pliki z wykorzystaniem protokołu SMB.  
• Tables – Baza NoSQL działająca na zasadzie Klucz / Wartość (Key / Value).  
• Queues – prosty system kolejkowy wymiany danych.  

Ponieważ każda z tych „dodatkowych” usług może łatwo zostać zastąpiona przez dedykowaną usługę Azure, to ciągle podstawową funkcją AS i ADLS jest składowanie dużych zbiorów danych.  

Przyjrzyjmy się im bardziej szczegółowo: 

Azure Blob Storage (ABS)  

ABS pojawił się na Azure kilka lat temu. Jego podstawowe cechy to: 

• Składowanie danych bez limitu (standardowy limit – który jednak można usunąć – to ponad 5 PB).  
• Limit dla pojedynczego pliku danych (blob) to 4,7 TB.  
• Występuje w dwóch podstawowych rodzajach (ang. Tiers) Standard i Premium (Premium jest lepiej przystosowany do obsługi plików o mniejszych rozmiarach). 
• Umożliwia składowanie w kilku warstwach (ang. Access Tiers) – Premium, Hot, Cool, Archive różniących się ceną, wydajnością i kosztem operacji – im „zimniejsza” warstwa, tym tańsze składowanie (przestrzeń), ale wolniejsze i droższe są operacje dostępu do danych. 

Azure Data Lake Storage (ADLS) 

Usługa ADLS została zbudowana jako rozszerzenie ABS, umożliwiając składowanie danych w hierarchicznym systemie plików (ang. Hierarchical Namespace) – ABS składuje bowiem bloby w prostym systemie plików, opartym na słowniku Klucz / Wartość (ang. Flat Namespace). Użycie hierarchicznego systemu plików to niewątpliwie udogodnienie, co można zaobserwować przy atomowych operacjach dotyczących dużej liczby blobów, jak np. przeniesienie w inne miejsce. ADLS z takim systemem plików jest też bardziej wydajny, ale są dwa punkty, w których przegrywa ze starszą usługą: 

1. Jest trochę droższy w zakresie koszów operacji na danych.  
2. Ma nieznacznie ograniczone możliwości, jeżeli chodzi o zabezpieczenie przed wszelkiego rodzaju katastrofami – magazyn ADLS może mieć redundantną kopię w innym rejonie świata, ale przełączenie na kopię może być uruchomione jedynie przez Microsoft, gdy zorientuje się, że coś nie działa. W przypadku starszej usługi ASB kopię może przełączyć sam użytkownik z poziomu portalu Azure’a. Niby to drobnostka, ale w przypadku systemów krytycznych dla biznesu może mieć znaczenie. 

Azure Stream Analytics (AStA) – przetwarzanie strumieniowe PaaS 

Jedną z ciekawszych usług przetwarzania danych udostępnionych przez Microsoft na platformie Azure jest Azure Stream Analytics (na potrzeby tego artykułu będę posługiwał się skrótem AStA, dla odróżnienia od ASA – Azure Storage Account i Azure Sunapse Analytics). Jako że jest to usługa strumieniowego przetwarzania danych udostępniona w modelu PaaS, nie dotkniemy tu „serwerów” ani nie wybierzemy rozmiaru pamięci naszego silnika przetwarzania danych. Prawie wszystkie parametry skali przetwarzania sprowadzają się do przypisania do zadania magicznego czynnika Streaming Units (SU). Większe ilości SU przyznają więcej mocy procesora, pamięci do zadania, a także przy większych ilościach SU – większą liczbę instancji przetwarzających strumień danych równolegle. Zadania AStA mogą być wykonywane na wirtualnych klastrach współdzielonych z innymi klientami Microsoftu (multi-tenant), jak również na izolowanym i dedykowanym klastrze (usługa Azure Stream Analytics Cluster) z zastrzeżeniem, że dedykowany klaster nie może alokować mniej jednostek niż 36 SU (oznacza to większy koszt startowy). 

AStA oferuje ciekawy sposób oprogramowania zadań przetwarzania strumieniowego. Zadania tworzy się tu w formie kwerendy (lub zestawu kwerend) z użyciem konkretnego rozszerzenia, języka T-SQL. Innymi słowy – kod zadania ASA wygląda jak SQL, z zastrzeżeniem, że niektóre „wirtualne tabele” z których ASA czyta i do których pisze, to w rzeczywistości źródła danych strumieniowych (zwykle kolejki) i zbiory wyjściowe (tu mamy pełną gamę możliwości zapisywania wyników do kolejek wyjściowych, zbiorów na Azure Storage, baz SQL i NoSQL, hurtowni czy systemu BI). Trudno się oprzeć wrażeniu, że jest to rozwiązanie odzwierciedlające możliwości platformy open-source zaproponowanej przez Confluent.io i opartej na systemie Kafka i języku KSQL. 

Jako że podstawą analizy strumieniowej jest analiza kontekstowa wymiarze czasu, to język T-SQL usługi ASA został wyposażony w specjalne funkcje pozwalające agregować wyniki kwerendy po kluczach i w odpowiednich interwałach czasowych (agregaty per okno czasowe). Mamy tutaj takie możliwości jak: 

• Tumbling Window – stała agregacja jedynie po czasie – podsumowanie i generowanie wyników następuje zawsze po określonej liczbie sekund (periodycznie). 
• Hoping Window – stała agregacja po czasie z przesunięciem – okna czasowe, w których obliczane są wyniki, mogą na siebie zachodzić, okno następne może się zacząć przed zakończeniem poprzedniego. 
• Sliding Window – dynamiczna agregacja po czasie z oknami czasowymi stałej długości – ale granice okien czasowych są wyznaczane przez kolejne rekordy pojawiające się na wejściu – okna czasowe zatem zaczynają się i kończą w nieustalonych z góry momentach. 
• Session Window – dynamiczna agregacja po czasie z oknami czasowymi różnej długości – okno czasowe jest wydłużane (sesja), jeżeli wybrane rekordy pojawiają się odpowiednio często. 

Innymi ciekawymi rozszerzeniami T-SQL na użytek ASA są funkcje geolokacyjne (ang. Geospatial Functions) oraz natywne możliwości czytania rekordów wejściowych, które są zakodowane w postaci obiektów najczęściej transportowanych wielkoskalowymi kolejkami AVRO i JSON. Jeżeli ktokolwiek chce szybko zbudować w Azure system strumieniowy, to z pewnością użycie AStA jest jednym z pomysłów, które warto rozważyć.  

Azure Synapse Analitics i Azure Databricks – pojedynek gigantów 

W ostatnim czasie podstawowym frameworkiem do analizy zbiorów Big Data stał się Spark. Jego niezaprzeczalne walory oparte na rozproszonym przetwarzaniu z użyciem samej tylko pamięci zostały docenione przez całą rzeszę użytkowników na świecie. Konsekwencją tej popularności jest pojawienie się Databricks – komercyjnej platformy początkowo zorientowanej na to redukowanie niedogodności związanych z zarządzaniem klastrami Sparka (Managed-Spark). W odpowiedzi na popularność Databricks Microsoft przygotował swoją wersję platformy analitycznej Big Data. Oba rozwiązania konkurują ze sobą, starając się sprostać wymaganiom nowoczesnych systemów Big Data – każdy w trochę innym modelu.  

Azure Synapse Analytics – hurtownia Big Data 

Azure Synapse Analytics wspiera bodaj najpopularniejszy model organizacji danych w nowoczesnych systemach danych. Wszystko zostało pomyślane w taki sposób, aby wspierać architekturę danych nazywaną kiedyś Two-Tier Data – zakładająca współistnienie dwóch równoległych głównych magazynów danych: 

• DataLake – jako magazynu przechowującego dane nieustrukturyzowane oraz wstępnie przetworzone  
• Hurtowni danych – jako źródła dla systemów BI. 

Ten dwutorowy model powstał, gdy zorientowano się, że nie istnieje jedno rozwiązanie odpowiadające potrzebom wszystkich popularnych przypadków użycia danych. Hurtownie są znacznie wygodniejsze jako źródła danych dla systemów opartych na SQL (w tym BI), ale dużo mniej wygodne, jeżeli chodzi o eksplorację danych (Data Science) oraz źródło danych do trenowania modeli sztucznej inteligencji (Machine Learning). Stąd pomysł, aby w systemie obydwa te byty istniały równolegle. 

Azure Synapse Analytics w pełni implementuje ten model. Centralnym elementem platformy jest tandem – wysoce skalowalna chmurowa hurtownia danych Azure Synapse DWH (Built-in pool) oraz środowisko zarządzalnych klastrów Spark do analiz danych w Data Lake. To jednak jeszcze nie wszystko. Pod jednym dachem Microsoft umieścił dodatkowe usługi przetwarzania danych.  

Znajdziemy tu zintegrowane: 

• Data Factory – usługa integracji danych. 
• Serverless SQL Pools – system serwerów SQL on-demand – gdzie użytkownik płaci jedynie za czas i zasoby zużyte do wykonania zapytania, bez ponoszenia kosztów serwera czy maszyny wirtualnej. 
• Data Explorer – usługa analizy danych. 

Każdą z tych usług można oprogramować w ich natywnym języku (SQL, KustoQL, Python, Scala, a nawet C#). 

Do dyspozycji mamy więc o wiele więcej niż prosty system hurtownia + Data Lake. Zyskujemy scentralizowaną platformę udostępniającą wszystko, co najlepsze pod dachem Microsoftu do analizy danych. Brawo za pomysł! 

Azure Databricks – architektura Lakehouse 

Azure Databricks jako bezpośrednia konkurencja Azure Synapse Analytics realizuje trochę inny model. Ta strategia wynika z faktu, że Databricks powstał jako środowisko do łatwego zastosowania Sparka i koncepcja silnika Big Data jako centralnego elementu pozostała tu silnie zakorzeniona. W ciągu dwóch ostatnich lat Databricks zorientował się jednak, że sam Spark nie wystarczy. Wraz ze swoimi partnerami rozbudował platformę o dodatkowe funkcjonalności prowadzące do powstania kompletnie nowego modelu platformy danych – Lakehouse Architecture.  

Koncepcja Lakehouse w skrócie bazuje na tym, że platforma ciągle polega na danych umieszczonych w Data Lake, ale udostępnia większość funkcjonalności dostępnych dotychczas tylko w hurtowniach: 

1. Transakcyjność – model ACID dla (niektórych) zbiorów Big Data.
2. Wsparcie wysoce wydajnego silnika zapytań SQL.
3. Mechanizmy kontroli dostępu do danych w Data Lake (Data Governance).
4. Wsparcie importu danych i orkiestracje ETL.

Model Lakehouse to naprawdę mała rewolucja. Zapewne nie będzie on aż tak wydajny jak model typu StarSchema w dobrej hurtowni danych, ale koncepcja Lakehouse opiera się na paradygmacie taniego składowania dużych zbiorów danych. Stąd Databricks zakłada, że skoro składowanie danych jest tanie, mogą być one przechowywane i organizowane w redundantnych kopiach (tabelach) skierowanych pod konkretne zastosowania – przy jednoczesnym założeniu, że dane są klasyfikowane w ich zaawansowaniu (koncepcja klas tabel Bronze-Silver-Gold).  

Patrząc z boku, Databricks zbliża się do koncepcji reprezentowanych przez innych konkurentów, np. do platformy Vertica z podobnym redundantnym i specjalizowanym modelem tabel. 

DeltaLake – transakcyjność Big Data 

Idea Lakehouse nie byłaby kompletna bez wspierania koncepcji transakcyjności. Oczywiście transakcyjności nie da się łatwo zaimplementować dla surowych i nieustrukturyzowanych danych, ale dla danych przetworzonych można się już o to pokusić. Do realizacji tego celu Databricks i partnerzy (Delta.io) zaproponowali nowy format zapisu tabel „zarządzanych” o nazwie „Delta”. Delta to rozszerzenie koncepcji tabel opartych na formacie Parquet, czyli kolumnowym formacie plikowym.

Delta zakłada, że obraz „tabeli” reprezentowanej przez zestaw plików w magazynie nie opiera się na prostej sumie wszystkich rekordów ze wszystkich plików danych. Obok plików z danymi Delta utrzymuje tzw. Delta-Log, czyli zestaw plików opisujący transakcje na zbiorze. Innymi słowy, przy zmianie zawartości tabeli w magazynie pojawiają się nowe wersje starych plików ze zmienionymi danymi, a informacja o zakończonej transakcji (o tym, że nowy plik jest ważniejszy niż stary) jest zapisywana w Delta-Logu. Ponieważ w tym samym momencie w zbiorach plików występują pliki z danymi z różnych okresów, w Delta-Logu przechowywane jest ich wersjonowanie. Dzięki tej prostej koncepcji tabele Delta mają cechy ACID, a przy tym… możliwa jest podróż w czasie, tzn. można poprosić o obraz tabeli z pewnego momentu w przeszłości. Oczywiście w dowolnym momencie możemy wyczyścić tabelę z plików / rekordów historycznych, co spowoduje zmniejszenie jej wielkości w magazynie danych. 

SQL Warehouse – SQL w służbie Big Data 

Natywnym językiem wielu rozwiązań klasy BI pozostaje SQL. Z tego powodu koncepcja Lakehouse musi uwzględniać jak najszersze wsparcie dla tego języka. Oczywiście podstawowa wersja silnika Sparka zawiera wbudowany „Spark SQL”, ale jego użyteczność była trochę ograniczona. W celu poprawienia tej sytuacji Databricks zaproponował nowy rodzaj silnika zapytań o nazwie Photon oraz nowy typ klastrów dla zapytań SQL – SQL Warehouses (albo SQL endpoints). Ze względu na to, że nowy silnik zapytań wykorzystuje mocno cache klastry SQL Warehouse trzeba opierać się na trochę mocniejszych maszynach (w Azure to Standard_E8ds_v4, czyli 8 vCore’ów i 64 GB pamięci). Zwiększony koszt pozostaje jednak pod kontrolą, ponieważ działają na nich wszystkie dotychczasowe mechanizmy autoskalowania w górę i w dół, aż do osiągnięcia limitów określonych przez administratora.  

Z moich obserwacji wynika, że zastosowanie nowego silnika i nowych klastrów znacząco przyspieszyło wykonywanie zapytań SQL na zbiorach Big Data. Oczywiście ponieważ ciągle pod spodem mamy zbiory plikowe, warto pokusić się o stworzenie właściwej organizacji danych, nie wahając się przed tworzeniem redundantnych i dedykowanych zbiorów pod najbardziej krytyczne zapytania – po to, żeby umożliwić silnikowi skorzystanie z optymalizatorów wykorzystujących partycjonowanie oraz dane indeksów i metadane dostępne w niektórych typach plików (np. Delta). 

Unity Catalog – właściwy Data Governance w Data Lake 

Nie można by nazwać rozwiązania przygotowanego przez Databricks hurtownią danych bez rozbudowanego mechanizmu umożliwiającego zarządzanie danymi. W tym celu Databricks zaimplementował nowy, lepszy mechanizm „katalogu danych”, czyli metabazy przetrzymującej informacje o zbiorach danych i ich schematach widzianych jako tabele. W tradycyjnych środowiskach Big Data (również opartych na Sparku) ten element bazował na najpopularniejszym katalogu Hive Metastore albo katalogu Impala. Databricks zaproponował swoją własną wersję katalogu danych nazwaną Unity Catalog. Unity Catalog pozwala na rozbudowaną kontrolę nad zbiorami Big Data: 

• System zarządzania oparty na instrukcjach ANSI SQL.
• Szczegółowy audyt i analizę logów dostępu do danych.
• Przypisywanie uprawnień do zbiorów danych na poziomie konta użytkownika.
• Wsparcie dla implementacji uprawnień na poziome rekordów (Row-Level Security) oraz kolumn (Column-Masking Policy).
• Scentralizowane i bezpieczne przeszukiwanie metadanych – pozwalające zrozumieć, które zbiory / tabele Big Data zawierają jakie dane.
• Wizualizacje powiązań między zbiorami – grafy przedstawiające zależności między zbiorami z uwzględnieniem uprawnień użytkownika korzystającego z tej funkcjonalności.
• Lepsza efektywność kwerend zbiorów zarejestrowanych w Unity Catalog – wynikająca z określonego przeorganizowania katalogu i przetrzymywania jego zapisów w pamięci w skompresowanej formie.

Jak widać powyżej, korzyści, które wnosi nowy metastore Databricks, są rewolucyjne. Migracja zwykłego Hive Metastore do Unity Catalog jest prosta i na pewno warto to zrobić, żeby wynieść poziom zarządzania danymi na niespotykany dotąd poziom. 

Delta Sharing – udostępnianie danych na zewnątrz 

Najnowsza wersja platfrom Databricks wprowadza jeszcze jedną użyteczną funkcjonalność – w pełni kontrolowane udostępnianie danych na zewnątrz. Proces ten jest realizowany z użyciem rozwiązania Delta Sharing, które zostało wbud

Takie rozwiązanie jest bardzo wygodne w przypadku gdy system Big Data został oparty na danych od wielu klientów (np. serwisów typu multi-tenant). Właściciel systemu Big Data ma dostęp do wszystkich udzielonych mu danych, mając jednocześnie możliwość udostępnienia określonych informacji/wyników na zewnątrz w taki sposób, aby jego indywidualni partnerzy mieli dostęp jedynie do swoich podzbiorów. 

Cloud przyszłością Big Data 

Mój artykuł jedynie pobieżnie poruszył temat kilku ważnych usług z portfolio Azure. Żeby opisać je dokładnie, potrzebny byłby cały cykl. Mam nadzieję jednak, że treść zainteresowała was na tyle, aby spróbować swoich sił z tematem projektowania i implementacji systemów Big Data z użyciem Azure. Rewolucja oparta na danych trwa nadal. Warto się stać jej częścią. Jeżeli macie jakieś wątpliwości lub pytania służymy pomocą!