Microsoft Fabric: Podstawowe pojęcia dla doświadczonych administratorów baz danych

Architektura Fabric: Tenant, Capacity i Workspace

Zrozumienie architektury Microsoft Fabric wymaga przyswojenia trzech fundamentalnych pojęć, które tworzą szkielet całej platformy. Jako DBA przyzwyczajeni do instancji SQL Server i baz danych, musimy przestawić myślenie na nowy model organizacyjny.

Tenant jako fundament

Tenant w Microsoft Fabric to pojedyncza instancja platformy przypisana do organizacji. Kluczowe jest powiązanie tenanta z Microsoft Entra ID (dawniej Azure Active Directory), co oznacza, że tożsamość użytkowników i polityki bezpieczeństwa są zarządzane centralnie. Dla DBA oznacza to odejście od tradycyjnego modelu loginów SQL Server na rzecz zunifikowanego zarządzania tożsamością w skali całej organizacji.

Capacity jako zasoby obliczeniowe

Capacity definiuje dedykowany zestaw zasobów dostępnych w danym momencie. W praktyce Capacity określa moc obliczeniową, którą organizacja ma do dyspozycji. Microsoft oferuje różne poziomy SKU (Stock Keeping Unit), które determinują ilość dostępnych zasobów. Różne operacje konsumują różną ilość Capacity w czasie rzeczywistym, co przypomina nieco model DTU znany z Azure SQL Database, ale w znacznie szerszym kontekście.

Workspace jako przestrzeń pracy

Workspace to kolekcja elementów (items) zgrupowanych w jednym środowisku przeznaczonym do współpracy zespołowej. Pełni rolę kontenera wykorzystującego Capacity do wykonywania pracy i zapewnia kontrolę dostępu do zawartych w nim elementów. W Workspace użytkownicy tworzą raporty, notebooki, modele semantyczne i inne artefakty. Dla DBA Workspace można porównać do bazy danych w sensie organizacyjnym, choć zawiera znacznie więcej typów obiektów.

Z perspektywy dwudziestu lat pracy z SQL Server, przejście na model Tenant/Capacity/Workspace wymaga zmiany nawyków. Zamiast myśleć o instancjach i bazach danych, myślimy o przestrzeniach współpracy i przydzielonych zasobach obliczeniowych.

Workloads: siedem filarów Microsoft Fabric

Microsoft Fabric integruje siedem głównych obszarów funkcjonalnych (workloads), które w dokumentacji nazywane są również experiences. Każdy workload dostarcza specyficzny zestaw możliwości ukierunkowanych na konkretną funkcjonalność.

Data Engineering

Obszar Data Engineering koncentruje się na przetwarzaniu dużych zbiorów danych. Obejmuje Lakehouse, notebooki oraz definicje zadań Spark. To tutaj inżynierowie danych budują potoki transformacji i przygotowują dane do dalszej analizy.

Data Factory

Data Factory odpowiada za orkiestrację przepływu danych i integrację źródeł. Pipelines i Dataflow Gen2 stanowią główne narzędzia tego workloadu, umożliwiając pobieranie danych z setek źródeł.

Data Science

Workload Data Science dostarcza narzędzia do eksploracji danych, budowania eksperymentów uczenia maszynowego oraz trenowania modeli. Data Wrangler i eksperymenty ML tworzą kompletne środowisko dla data scientistów.

Data Warehouse

Dla DBA najbardziej znajomy workload. Data Warehouse w Fabric oferuje możliwości znane z tradycyjnych hurtowni danych, ale zbudowane na nowoczesnej architekturze chmurowej.

Databases, Real-Time Intelligence i Power BI

Databases rozszerza możliwości o zarządzanie bazami danych, Real-Time Intelligence obsługuje przetwarzanie strumieniowe i analitykę czasu rzeczywistego, natomiast Power BI zapewnia warstwę raportowania i wizualizacji znaną z samodzielnego produktu.

Lakehouse: hybrydowe podejście do przechowywania danych

Lakehouse to koncepcja łącząca elastyczność Data Lake z możliwościami analitycznymi Data Warehouse. W praktyce jest to baza danych zbudowana nad jeziorem danych, zawierająca pliki, foldery i tabele.

Architektura Lakehouse

Lakehouse jest hostowany w unikalnym folderze workspace w Microsoft OneLake. Zawiera pliki w różnych formatach (strukturalne i niestrukturalne) zorganizowane w folderach i podfolderach. Dwa silniki przetwarzają dane: Apache Spark dla transformacji big data oraz silnik SQL dla zapytań analitycznych.

Format Delta i transakcje ACID

Kluczową cechą Lakehouse jest wsparcie dla transakcji ACID przy użyciu tabel w formacie Delta. To właśnie format Delta, oparty na plikach Parquet z dodatkowym logiem transakcyjnym, umożliwia zachowanie spójności danych znanej z tradycyjnych baz relacyjnych. Dla DBA to fundamentalna zmiana: pliki w data lake mogą teraz oferować gwarancje transakcyjne porównywalne z SQL Server.

Podwójne wykorzystanie

Lakehouse może być odpytywany zarówno przez Apache Spark (Python, Scala, SQL), jak i przez standardowy T-SQL poprzez endpoint SQL. Ta dualność pozwala zespołom data engineering i analitykom biznesowym pracować na tych samych danych bez konieczności ich duplikacji.

Lakehouse rozwiązuje odwieczny konflikt między elastycznością data lake a rygorem data warehouse. Jako DBA doceniam, że nie muszę już wybierać między jednymi a drugimi.

Data Factory w Fabric: Pipeline, Dataflow Gen2 i Connectors

Data Factory w Microsoft Fabric stanowi centralny punkt orkiestracji i transformacji danych. Dla DBA przyzwyczajonych do SSIS, Data Factory oferuje podobną funkcjonalność w nowoczesnym, chmurowym wydaniu.

Pipelines jako orkiestracja

Pipeline w Data Factory służy do orkiestracji przepływu danych i transformacji. Należy wyraźnie odróżnić te pipelines od deployment pipelines występujących w innych częściach Fabric. Pipeline łączy aktywności w sekwencje, obsługuje rozgałęzienia warunkowe, pętle i obsługę błędów.

Dataflow Gen2 versus Gen1

Dataflows zapewniają niskopoziomowy interfejs do pobierania danych z setek źródeł i ich transformacji. W Fabric występuje Dataflow Gen2, który oferuje rozszerzone możliwości w porównaniu do Dataflow Gen1 istniejącego w Power BI. Ważna uwaga: nie można wykonać upgrade z Gen1 do Gen2, co wymaga planowania przy migracji istniejących rozwiązań.

Connectors i Triggers

Data Factory udostępnia bogaty zestaw connectorów umożliwiających łączenie z różnymi typami magazynów danych. Po nawiązaniu połączenia dane można transformować w ramach dataflows. Triggers natomiast automatyzują uruchamianie pipelines na podstawie określonych warunków: harmonogramów czasowych lub dostępności danych.

Apache Spark w Fabric: Notebook, Job Definition i V-Order

Apache Spark stanowi silnik przetwarzania big data w Microsoft Fabric. Dla DBA to zupełnie nowy świat, ale zrozumienie podstawowych komponentów jest niezbędne do efektywnej pracy z platformą.

Notebook jako interaktywne środowisko

Notebook w Fabric to wielojęzyczne, interaktywne narzędzie programistyczne oferujące bogate funkcje: tworzenie kodu i dokumentacji Markdown, uruchamianie i monitorowanie zadań Spark, wizualizację wyników oraz współpracę zespołową. Notebook pomaga inżynierom danych i data scientistom eksplorować i przetwarzać dane, budować eksperymenty ML łącząc kodowanie z niskopoziomowym podejściem. Co istotne, notebook można łatwo przekształcić w aktywność pipeline do celów orkiestracji.

Spark Job Definition

Spark Job Definition to zestaw parametrów definiowanych przez użytkownika, określających sposób uruchomienia aplikacji Spark. Pozwala na submitowanie zadań wsadowych lub strumieniowych do klastra Spark. W przeciwieństwie do interaktywnego notebooka, Job Definition służy do uruchamiania zaplanowanych, powtarzalnych zadań produkcyjnych.

V-Order jako optymalizacja

V-Order to optymalizacja zapisu plików Parquet umożliwiająca szybkie odczyty przy jednoczesnej efektywności kosztowej i lepszej wydajności. Wszystkie silniki Fabric domyślnie zapisują pliki Parquet z optymalizacją V-Order. Dla DBA to dobra wiadomość: nie trzeba ręcznie konfigurować tej optymalizacji, a korzyści wydajnościowe są automatyczne.

Hierarchia wykonania Spark

Aplikacja Spark napisana w Scala, Python, Spark SQL, Java lub .NET (C#/F#) podczas wykonania dzieli się na wiele Spark jobs działających równolegle. Każdy job składa się z wielu tasks. Zrozumienie tej hierarchii jest kluczowe przy debugowaniu i optymalizacji wydajności.

Perspektywa DBA: jak Fabric zmienia rolę administratora baz danych

Microsoft Fabric nie eliminuje potrzeby kompetencji DBA, ale znacząco rozszerza ich zakres. Po dwudziestu latach pracy z SQL Server obserwuję, że ta transformacja jest nieunikniona.

Nowe kompetencje do opanowania

DBA musi rozszerzyć swoje umiejętności o zrozumienie Apache Spark, formatu Delta, architektury Lakehouse oraz modelu Capacity. Znajomość T-SQL pozostaje wartościowa, szczególnie przy korzystaniu z SQL endpoint w Lakehouse, ale sama w sobie już nie wystarcza.

Integracja z SQL Server

Microsoft Fabric współpracuje z istniejącymi środowiskami SQL Server. Dane z on-premises mogą być replikowane do OneLake, raporty Power BI mogą korzystać zarówno ze źródeł Fabric jak i tradycyjnych baz danych. Strategia hybrydowa jest nie tylko możliwa, ale często zalecana w okresie przejściowym.

Strategia migracji

Rekomendowane podejście to rozpoczęcie od Proof of Concept na konkretnym przypadku użycia. Hurtownie danych i rozwiązania BI są naturalnymi kandydatami do migracji. Krytyczne systemy OLTP mogą pozostać na SQL Server, podczas gdy analityka przenosi się do Fabric. Stopniowa migracja pozwala zespołom DBA budować kompetencje bez ryzyka dla systemów produkcyjnych.

Fabric nie zastępuje DBA. Rozszerza rolę administratora baz danych w kierunku architekta platformy danych. Umiejętności zdobyte przez lata pracy z SQL Server stanowią solidny fundament, ale wymagają uzupełnienia o nowe technologie.