Co to jest Azure Synapse?

Jest to nowoczesna platforma, którą Microsoft reklamuje jako one-stop-shop dla analityki danych, dużej ilości danych (co ciekawe Fabric jest reklamowany w ten sam sposób, w obu przypadkach to twierdzenie jest prawdziwe). Faktycznie, nie są to czcze obietnice – w Synapse można postawić całą analitykę od A do Z. W niniejszym artykule przedstawię czym jest Synapse, jakie są modele wdrożenia, na czym polega tworzenie modelu danych. Postaram się również przedstawić zarys cennika oraz wyjaśnić jak można tą usługę wykorzystać w swojej organizacji.

Co dostajemy w ramach usługi Azure Synapse Analytics?

Zasadniczo, w ramach tej usługi otrzymujemy dostęp do „bazy danych”. Umieściłem to w cudzysłowie, ponieważ baza danych może przyjmować tam różne formy, uzależnione od sposobu wykorzystania. Otrzymujemy również dostęp do Azure Data Factory, czyli narzędzia ETL (Extract, Transform, Load). Ten komponent jest taki sam jak w przypadku samodzielnej usługi Data Factory. Proces ETL jest pierwszym etapem budowy rozwiązania analitycznego – pozwala on zebrać dane z systemów źródłowych, przetworzyć do pożądanej formy oraz umieścić w bazie analitycznej. Synapse bardzo dobrze integruje się z Power BI, czyli narzędziem do tworzenia modelu danych oraz wizualizacji.

Co to są modele wdrożenia w Azure Synapse?

Sporą ciekawostką z punktu widzenia analityki wydają się być modele wdrożenia. Jest to novum względem hurtowni danych on-premise, gdzie głównym tematem rozważań był model danych. W przypadku Synapse model danych oczywiście nadal stanowi trzon rozwiązania analitycznego, natomiast wybór modelu wdrożenia będzie w późniejszym czasie wpływał na decyzje oraz możliwości dotyczące procesu modelowania danych. Wśród dostępnych modeli wdrożenia można wymienić Serverless SQL Pool, Dedicated SQL Pool oraz Spark Pool. Różnią się one diametralnie pod kątem architektury, kosztów oraz celów w jakich są stosowane. W niniejszym artykule postaram się przybliżyć tematykę dostępnych modeli wdrożenia (a w zasadzie dwóch pierwszych, bo Spark Pool to temat na osobny artykuł) oraz modelowania danych. Od razu uspokajam, wybranie jednego modelu nie odbiera możliwości skorzystania z pozostałych! W wielu przypadkach, aby zrealizować założenia projektu będzie trzeba skorzystać z więcej niż jednej opcji.

Jak zaprojektować model danych?

Zacznijmy od zagadnienia modelu danych, który jest abstrakcją pewnych procesów (zazwyczaj biznesowych, ale modelowanie danych jest wykorzystywane nie tylko do celów komercyjnych). W kwestii projektowania modelu danych złotym standardem jest model Kimballa, zwany inaczej wielowymiarowym. W dużym uproszczeniu, podejście to zakłada podzielenia danych na fakty i wymiary. Fakty są zazwyczaj danymi liczbowymi (chociaż nie zawsze), które mogą być opisywane przez pewne atrybuty, czyli wymiary. Model faktów i wymiarów bywa określany jako model gwiazdy, ponieważ w jego centrum znajduje się jedna tabela faktów, która ma relacje z kilkoma lub kilkunastoma tabelami wymiarów. Prostym przykładem modelu danych jest zestaw zawierający tabelę z danymi sprzedażowymi oraz następujące tabele wymiarów: kalendarz (pozwala analizować sprzedaż w czasie), dział sprzedaży (pozwala analizować sprzedaż per pracownik) i produkt (zawiera dane o produktach i ich kategoriach). Prawdopodobnie najważniejszą publikacją dotyczącą modelowania danych jest The Data Warehouse Toolkit autorstwa Ralpha Kimballa. Każdy szanujący się analityk danych powinien się z nią zapoznać. Mimo swojego wieku, podejście wielowymiarowe jest nadal adekwatne i prawdopodobnie nieprędko się to zmieni. Oprócz podejścia proponowanego przez Kimballa istnieją jeszcze inne modele, takie jak: Data Vault czy model Inmona. Korzystanie oraz budowa modelu danych odbywa się najczęściej poprzez narzędzia, takie jak Power BI lub Azure Analysis Services. Preferowanym podejściem jest korzystanie z tego pierwszego, gdzie model danych jest tworzony z poziomu Synapse, a następnie publikowany w serwisie Power BI.

Pierwszym etapem tworzenia modelu danych jest stworzenie modelu konceptualnego. Jest to wysokopoziomowy, abstrakcyjny opis struktury danych, który skupia się na przedstawieniu danych i ich związków z perspektywy użytkownika, pomijając szczegóły techniczne. W dalszej kolejności należy określić model logiczny, który stanowi rozwinięcie modelu konceptualnego, zawierające bardziej szczegółowe informacje o strukturze i organizacji danych. Wprowadza on pojęcia takie jak klucze, ograniczenia czy normalizacja danych. Model logiczny służy jako podstawa do opracowania modelu fizycznego. Ostatnim elementem jest fizyczny model danych, który stanowi techniczną implementację rozwiązania. To on określa w jaki sposób przechowywane i zarządzane są dane. Jak łatwo się domyślić, jest to etap, na którym należy wybrać model wdrożenia.

Jak wdrożyć model danych w Azure Synapse Analytics?

Jak wspomniałem wcześniej, istnieją trzy dostępne modele wdrożenia Azure Synapse Analytics - Serverless SQL Pool, Dedicated SQL Pool oraz Spark Pool. Zacznijmy od Serverless, którego cechą charakterystyczną jest to, że nie istnieje w jego przypadku serwer bazy danych. Zasadniczo, w przypadku Serverless wszystkie dane przechowywane są w plikach w Azure Data Lake Storage. Pliki te występują zazwyczaj w formatach, takich jak csv, parquet, delta lake, orc czy avro. Z czego trzy pierwsze są najczęściej spotykane. Oprócz plików, Synapse Serveless daje możliwość odczytywania danych znajdujących się w Azure Cosmos DB oraz Dataverse. Szczególnie interesujące może być wykorzystywanie połączenia z Dataverse, ponieważ to właśnie tam znajdują się dane pochodzące z CRM Dynamics 365 oraz Power Apps. Są to narzędzia dość mocno rozpowszechnione w świecie biznesowym. Znajduje się w nich mnóstwo danych na temat klientów, kampanii marketingowych, sprzedaży oraz wielu innych zagadnień, którymi zainteresowani mogą być odbiorcy rozwiązań analitycznych. Synapse Serverless doskonale nadaje się do tworzenia analiz ad-hoc oraz do pewnego stopnia do budowy hurtowni danych. Jest to bardzo elastyczne rozwiązanie, ponieważ pozwala uzyskiwać natychmiastowy dostęp do danych z wielu różnych miejsc bez konieczności i przenoszenia lub przekształcania. Co więcej, jego model wyceny jest bardzo prosty - płacimy za ilość odczytanych danych. Na dzień publikacji tego artykułu jest to kwota 5 USD za 1TB. Z deweloperskiego punktu widzenia, Synapse Serverless jest o tyle wygodnym narzędziem, że tworzenie projektu odbywa się za pomocą T-SQL. Zatem osoby pracujące wcześniej z T-SQL (lub z jakimkolwiek innym dialektem SQL) bardzo szybko się w nim odnajdą. Co prawda istnieją pewne różnice, ale nie mają one fundamentalnego charakteru.

Kolejnym modelem wdrożenia jest Dedicated SQL Pool, czyli twór, który bardzo przypomina tradycyjną bazę danych - występują tam fizyczne tabele, procedury składowane, funkcje, indeksy oraz wiele innych rzeczy znanych ze świata relacyjnych baz danych. Tutaj podobnie jak w przypadku Serverless, znajomość SQL wystarczy, żeby zacząć działać - będzie to jednak wymagało uzupełnienia wiedzy w przypadku osób przychodzących ze świata on-premise. Na pewno trzeba zapoznać się z nowymi zagadnieniami, takimi jak tabele rozproszone (zrozumienie istniejących algorytmów rozpraszania danych jest bardzo ważne z punktu wydajności) czy indeksy columnstore (co prawda są one dostępne w ramach SQL Server on-premise, ale chyba nie są zbyt popularne). W ramach Dedicated SQL Pool otrzymujemy silnik zapytań, który pracuje w architekturze MPP (Massive Parallel Processing) co stanowi główny argument, żeby korzystać z tej usługi. Dzięki MPP otrzymujemy możliwość wydajnego przetwarzania dużych ilości danych. Korzystając z Dedicated SQL Pool możemy zbudować hurtownię danych, podobną do tych, które tworzyło/tworzy się w on-premise – zyskujemy jednak zupełnie nowe możliwości w zakresie przetwarzania ilości danych oraz szybkości budowy i wdrażania rozwiązań. W Dedicated SQL Pool model wyceny polega na tym, że płaci się za ilość godzin, kiedy serwer jest uruchomiony. W najtańszym możliwym planie, płaci się 1.20 USD za godzinę co miesięcznie daje kwotę około 870 USD. Koszt ten jednak można ograniczyć poprzez rezerwację na rok lub trzy lata z góry, wtedy cena będzie nawet o 65% niższa.

Jak umiejscowić Synapse w swojej organizacji?

Podsumowując, Azure Synapse Analytics to nowoczesna platforma do tworzenia rozwiązań analizy danych. Wybór między podejściem Serverless a Dedicated SQL Pool często nie jest oczywisty na pierwszy rzut oka. Na szczęście nie trzeba wybierać i można korzystać z obu opcji, a w razie elementy rozwiązania Serverless przenieść do Dedicated SQL Pool lub odwrotnie. Wyglądająca bardzo przystępnie wycena Serverless może bardzo szybko przestać być przystępna, jeżeli będziemy za pomocą tej usługi odpytywać intensywnie duże wolumeny danych. W takiej sytuacji może okazać się, że wyglądająca drożej na pierwszy rzut oko baza Dedicated SQL Pool będzie trafnym i przede wszystkim tańszym wyborem. Jak widać zagadnienia te są dość złożone, a na każde z pytań przychodzących do głowy odpowiedź brzmi zazwyczaj “to zależy”. Moim zdaniem przy korzystaniu z usług chmurowych największą sztuką jest trafne oszacowanie przyszłych kosztów, aby nie przepłacać a odnosić realne korzyści z wdrożonych usług.

W zespole business intelligence Fellowmind Poland mamy odpowiednie kompetencje i doświadczenie żeby pomóc naszym klientom skutecznie wdrożyć nowoczesną analitykę oraz zadbać o to aby koszty były na akceptowalnym poziomie. W najbliższej przyszłości będziemy wspierać naszych klientów przy wyborze pomiędzy Azure Synapse Analytics oraz Microsoft Fabric. Narzędzia te, z punktu widzenia potrzeb klienta, rozwiązują ten sam problem. Występują w nich jednak istotne różnice w modelu wyceny oraz pewne różnice w sposobie użytkowania.

W niniejszym artykule przedstawiłem istotny fragment usługi Azure Synapse Analytics. Nie wyczerpuje on jednak listy zagadnień z jakimi można się tam spotkać. Moim zdaniem wyjątkowo ciekawym tematem może być analiza logów i telemetrii (Data Explorer Pool) - element Synapse, który można wykorzystać do analizy danych z np. IoT czy do analizy niemal w czasie rzeczywistym.