Microsoft Fabric vs Databricks: porównanie na tych samych danych

W skrócieMicrosoft Fabric i Databricks to platformy typu lakehouse, które przechowują dane w otwartym formacie Delta Lake, ale różnią się modelem usługi i rozliczeń. Fabric to usługa SaaS z jedną pojemnością na wszystkie obciążenia i wbudowanym Power BI. Databricks to platforma dla zespołów danych i ML, rozliczana za czas pracy obliczeń.

Zamiast porównywać listy funkcji, wzięliśmy jeden zbiór danych fikcyjnej sieci sklepów Nordvella i przeprowadziliśmy go przez obie platformy krok po kroku. Te same pliki CSV trafiły do tabel, to samo zapytanie SQL i ten sam notatnik PySpark dały te same liczby, a potem zaplanowaliśmy przeliczenie, zbudowaliśmy raport i zadaliśmy pytanie asystentowi AI. Dzięki temu zobaczysz nie tylko, co potrafi każda z platform, ale też jak wygląda w niej codzienna praca i w których miejscach łatwo się potknąć.

Jak zbudowane są Microsoft Fabric i Databricks

Co chcemy osiągnąć. Zanim zaczniemy klikać, ustalmy, czym te platformy się różnią u podstaw. Od tego zależy, jak zespół pracuje na co dzień, kto płaci za obliczenia i gdzie leżą dane firmy.

Obie platformy realizują ten sam pomysł: lakehouse, czyli połączenie jeziora danych z hurtownią. Dane leżą w tanim magazynie plików, ale zapisane są jako tabele z transakcjami i schematem, tak jak w bazie danych. Format tych tabel to w obu przypadkach Delta Lake: pliki Parquet (kolumnowy format danych) z dziennikiem transakcji, który pozwala bezpiecznie dopisywać, poprawiać i cofać zmiany. Delta Lake powstał w Databricks i jest projektem open source, a Microsoft użył tego samego formatu w Fabric. Dlatego tabela zapisana w jednej platformie jest czytelna dla drugiej.

Różnica leży w tym, jak każda z platform tę ideę opakowuje:

• Microsoft Fabric to usługa SaaS (oprogramowanie dostarczane jako usługa): nie konfigurujesz serwerów ani klastrów, tylko tworzysz obszar roboczy i dodajesz do niego elementy, takie jak lakehouse, magazyn danych, notes, potok czy raport Power BI. Wszystkie dane trafiają do OneLake, jednego magazynu dla całej organizacji. Za obliczenia płacisz w formie pojemności, czyli stałej mocy mierzonej w jednostkach CU (capacity unit), którą dzielą wszystkie obciążenia.
• Databricks to platforma danych i AI uruchamiana w chmurze AWS, Azure albo Google Cloud. Dane leżą w magazynie obiektów chmury, a porządkuje je Unity Catalog: katalog z trzema poziomami nazw (katalog, schemat, tabela), uprawnieniami i pochodzeniem danych. Obliczenia uruchamiasz jako klastry Spark, obliczenia serverless (bez zarządzania maszynami) albo hurtownie SQL i płacisz za czas ich pracy w jednostkach DBU (Databricks Unit).

Najlepiej widać to w oknie, od którego w Fabric zaczyna się każda praca. Przycisk Nowy element w obszarze roboczym otwiera galerię wszystkich obciążeń: od pobierania danych przez notesy i potoki po magazyny danych i raporty. W Databricks podobną rolę pełni przycisk New w lewym górnym rogu: tworzysz nim notatniki, zapytania, pulpity, agentów Genie, joby i potoki ETL. Lewe menu dzieli z kolei narzędzia na sekcje SQL, Data Engineering i AI/ML.

Jeśli dopiero poznajesz silnik, na którym obie platformy liczą dane, zajrzyj do naszego przewodnika po Apache Spark dla początkujących. Platformę Microsoftu omawiamy od podstaw w artykule Co to jest Microsoft Fabric. Databricks opisujemy osobno w przewodniku po platformie lakehouse Databricks. Pojęcia, od których zaczyna się ten temat, takie jak jezioro danych, hurtownia i lakehouse, objaśniamy w artykule Co to jest big data? Pojęcia, krajobraz technologiczny i platformy.

Scenariusz testu: ta sama sieć sklepów w obu platformach

Co chcemy osiągnąć. Kontroling fikcyjnej sieci elektromarketów Nordvella pyta o dwie rzeczy: ile wyniosła sprzedaż netto w każdym regionie w 2025 roku i jak zmieniała się sprzedaż miesiąc po miesiącu. Na końcu w każdej platformie ma powstać ten sam zestaw: tabele z danymi, wynik zapytania SQL, tabela miesięczna przeliczana według harmonogramu, raport dla zarządu i odpowiedź asystenta AI na pytanie zadane po polsku.

Dane pochodzą z naszego bezpłatnego kursu Power BI na danych sieci Nordvella. Na potrzeby porównania zapisaliśmy je jako cztery pliki CSV:

• sprzedaz.csv: 108 675 transakcji od stycznia 2022 do maja 2026 roku z wartością netto, marżą, kanałem sprzedaży i znacznikiem zwrotu CzyZwrot,
• sklepy.csv: 15 sklepów w sześciu regionach, w tym sklep internetowy jako region Online,
• produkty.csv: 30 produktów fikcyjnych marek, od laptopów po drobne akcesoria,
• kalendarz.csv: 1826 dni z latami, miesiącami i kwartałami do łączenia z datami transakcji.

Po stronie Fabric pracowaliśmy na pojemności próbnej, po stronie Databricks na darmowej edycji Free Edition, którą zakładasz kontem Google, Microsoft albo adresem e-mail na stronie Databricks Free Edition. Oba środowiska mają limity, o których piszemy przy kolejnych krokach, ale do nauki i do takiego porównania wystarczają w zupełności.

Krok 1. Obszar roboczy i miejsce na dane

Co chcemy osiągnąć. Przygotować miejsce na tabele Nordvelli: w Fabric obszar roboczy na pojemności i lakehouse, a w Databricks schemat w katalogu Unity Catalog.

Fabric: obszar roboczy na pojemności próbnej i lakehouse

1. W lewym menu Fabric kliknij Obszary robocze, a potem Nowy obszar roboczy.
2. Wpisz nazwę, u nas Fabric vs Databricks, i przewiń panel do listy typów obszaru roboczego.
3. W grupie Typy obszarów roboczych platformy Fabric i usługi Power BI zaznacz Wersja próbna platformy Fabric. W polu Szczegóły pojawi się nazwa pojemności próbnej i jej region.
4. Kliknij Zastosuj.

W nowym obszarze kliknij Nowy element, wyszukaj Lakehouse i nadaj mu nazwę nordvella_lh. Pole Schematy usługi Lakehouse zostaw zaznaczone i kliknij Utwórz. Tabele trafią wtedy do schematu dbo, co ułatwia porządek przy większej liczbie tabel.

Databricks: schemat w Unity Catalog

1. Po zalogowaniu do Free Edition kliknij w lewym menu Catalog i wybierz katalog workspace.
2. Kliknij Create schema w prawym górnym rogu.
3. Wpisz nazwę schematu, u nas nordvella_fvd, i opcjonalny komentarz. Pole Storage location zostaw puste, wtedy tabele zarządzane trafią do domyślnej lokalizacji magazynu.
4. Kliknij Create.

Już tu widać pierwszą różnicę w adresowaniu danych. W Fabric tabela ma adres nordvella_lh.dbo.sprzedaz (lakehouse, schemat, tabela), a w Databricks workspace.nordvella_fvd.sprzedaz (katalog, schemat, tabela). Wrócimy do tego przy notatniku.

Krok 2. Pliki CSV w tabelach Delta

Co chcemy osiągnąć. Zamienić cztery pliki CSV w tabele Delta, na których będą pracować zapytania, notatniki i raporty. Obie platformy robią to bez pisania kodu.

Fabric: przekazanie plików i Załaduj do tabel

1. W lakehouse nordvella_lh rozwiń menu Pobierz dane i wybierz Przekazywanie plików.
2. Kliknij ikonę folderu, zaznacz cztery pliki CSV i kliknij Przekaż. Pliki trafią do folderu Files.

3. W folderze Files kliknij wielokropek obok pliku, wybierz Załaduj do tabel, a potem Nowa tabela.
4. Sprawdź schemat dbo, nazwę tabeli, zaznaczone pole Użyj nagłówka dla nazw kolumn i separator przecinek. Kliknij Załaduj.
5. Powtórz to dla pozostałych trzech plików.

Pułapka, na którą trafiliśmy: Załaduj do tabel uruchamia w tle sesję Spark. Po zakończeniu ładowania ta sesja jeszcze przez kilka minut widniała w Monitorze jako operacja lakehouse w toku i zajmowała pojemność. Na pojemności próbnej kolejny notes dostał przez to odmowę uruchomienia (komunikat pokazujemy w części o kosztach). Jeśli po ładowaniu chcesz od razu liczyć coś w Sparku, otwórz Monitoruj, najedź na operację z nazwą lakehouse, kliknij Anuluj i potwierdź Tak, zatrzymaj.

Databricks: Create or modify table

1. Wejdź do schematu nordvella_fvd w Catalog, kliknij Create i wybierz Table.
2. Upuść plik sprzedaz.csv na stronę albo kliknij browse.
3. Sprawdź podgląd: Databricks pokazuje typy kolumn rozpoznane z pliku i pierwsze 50 wierszy.
4. Upewnij się, że pola Catalog i Schema wskazują workspace i nordvella_fvd, a Table name ma wartość sprzedaz. Kliknij Create table.

Pułapka, na którą trafiliśmy: gdy otworzysz to samo okno z menu New, a nie ze strony schematu, pole Schema podpowiada schemat default. Trzy nasze tabele wylądowały tam, zanim to zauważyliśmy. Przenieśliśmy je jednym zapytaniem CREATE OR REPLACE TABLE ... AS SELECT, ale prościej jest sprawdzić to pole przed kliknięciem Create table.

W obu platformach typy kolumn rozpoznały się podobnie, z jedną ciekawostką: kolumnę RokMiesiac z wartościami w rodzaju 2022-01 Fabric zapisał jako znacznik czasu, a Databricks jako datę. W zapytaniach poniżej to nie przeszkadza, ale przy własnych danych warto przejrzeć typy po załadowaniu.

Krok 3. To samo zapytanie SQL, ten sam wynik

Co chcemy osiągnąć. Odpowiedzieć kontrolingowi, ile wyniosła sprzedaż netto i marża w każdym regionie w 2025 roku, bez transakcji zwróconych. To jedno zapytanie z dwoma złączeniami, które uruchomimy bez żadnych zmian w obu platformach.

-- Sprzedaż netto Nordvelli według regionu w 2025 roku (bez transakcji zwróconych)
SELECT sk.Region,
       ROUND(SUM(s.WartoscNetto), 2) AS SprzedazNetto,
       ROUND(SUM(s.MarzaNetto), 2)   AS Marza,
       COUNT(*)                      AS Transakcje
FROM sprzedaz s
JOIN sklepy sk   ON sk.SklepID = s.SklepID
JOIN kalendarz k ON k.DataID   = s.DataID
WHERE k.Rok = 2025
  AND s.CzyZwrot = 0
GROUP BY sk.Region
ORDER BY SprzedazNetto DESC;

Fabric: punkt końcowy analizy SQL

Każdy lakehouse dostaje automatycznie punkt końcowy analizy SQL, czyli dostęp do tabel w języku T-SQL (dialekcie SQL z Microsoft SQL Server) w trybie tylko do odczytu. Otwórz go w obszarze roboczym (element nordvella_lh typu Punkt końcowy usługi SQL Analytics), kliknij Nowe zapytanie SQL, wklej zapytanie i kliknij Uruchom.

Databricks: SQL Editor i hurtownia SQL

W Databricks zapytania SQL wykonuje hurtownia SQL (SQL warehouse), osobny rodzaj obliczeń zoptymalizowany pod SQL. W Free Edition jest jedna, Serverless Starter Warehouse. Kliknij SQL Editor, w selektorze nad edytorem wybierz katalog workspace i schemat nordvella_fvd, wklej zapytanie i kliknij Run all.

Wyniki zgadzają się z obliczeniem kontrolnym, które zrobiliśmy na plikach CSV poza obiema platformami. Zapytanie trwało w Fabric ok. 8 s, a w Databricks ok. 2 s, ale to nie jest benchmark: Fabric liczył na współdzielonej pojemności próbnej, Databricks na najmniejszej hurtowni serverless. Pamiętaj też o dialektach: Fabric mówi T-SQL (na przykład TOP 10), a Databricks SQL zgodny z ANSI i Spark SQL (na przykład LIMIT 10). Nasze zapytanie korzysta z części wspólnej, więc działa w obu miejscach bez zmian.

Zobacz też: Szkolenie Przetwarzanie danych Big Data z Apache Spark

Krok 4. Notatnik PySpark: jeden kod, inny prefiks tabel

Co chcemy osiągnąć. Zbudować tabelę sprzedaz_miesieczna z sumą sprzedaży, marży i liczbą transakcji w każdym miesiącu. To warstwa gotowa do raportów, którą potem przeliczymy według harmonogramu. Kod w PySparku (Pythonie dla Apache Spark) jest w obu platformach ten sam, różni się tylko jedna linia z prefiksem nazw tabel.

from pyspark.sql import functions as F

# Fabric: lakehouse.schemat, Databricks: katalog.schemat
PREFIKS = "nordvella_lh.dbo"

sprzedaz = spark.read.table(f"{PREFIKS}.sprzedaz")
kalendarz = spark.read.table(f"{PREFIKS}.kalendarz")

miesiecznie = (
    sprzedaz.filter(F.col("CzyZwrot") == 0)
    .join(kalendarz.select("DataID", "Rok", "Miesiac", "RokMiesiac"), "DataID")
    .groupBy("Rok", "Miesiac", "RokMiesiac")
    .agg(
        F.round(F.sum("WartoscNetto"), 2).alias("SprzedazNetto"),
        F.round(F.sum("MarzaNetto"), 2).alias("Marza"),
        F.count("*").alias("Transakcje"),
    )
    .orderBy("Rok", "Miesiac")
)

miesiecznie.write.mode("overwrite").saveAsTable(f"{PREFIKS}.sprzedaz_miesieczna")
display(miesiecznie)

Co robi ten kod: czyta dwie tabele, odrzuca transakcje zwrócone, dołącza z kalendarza rok i miesiąc, grupuje po miesiącach, liczy sumy, zapisuje wynik jako nową tabelę Delta i pokazuje go funkcją display(), która w obu platformach daje tabelę z możliwością przełączenia na wykres. W Databricks zmieniasz tylko linię PREFIKS = "workspace.nordvella_fvd" (plik notatnik_databricks.py w paczce do pobrania).

Fabric: notes z domyślnym lakehouse

Notes w Fabric potrzebuje domyślnego lakehouse, który wyznacza kontekst nazw tabel. Najprostsza droga: otwórz lakehouse, kliknij Analizuj dane za pomocą, wybierz Notebook, a potem Nowy notes albo Istniejący notes. Lakehouse zostanie dołączony i przypięty jako domyślny, co poznasz po ikonie pinezki w Eksploratorze notesu.

Pułapka, na którą trafiliśmy: dodaliśmy najpierw dane przyciskiem Dodaj elementy danych z katalogu OneLake i wybraliśmy przez pomyłkę punkt końcowy SQL zamiast samego lakehouse. Komórka zakończyła się błędem No default context found, please attach a lakehouse before running spark sql queries with partial namespaces, także przy nazwach z prefiksem lakehouse i schematu. Pomogło dołączenie lakehouse z jego strony i zatrzymanie sesji przyciskiem Zatrzymaj sesję, bo nowy domyślny lakehouse działa dopiero w nowej sesji.

Po poprawce sesja wystartowała w 8 s, a cała komórka wykonała się w 18 s. Z wyniku przełączyliśmy widok na Nowy wykres i wybraliśmy z podpowiedzi wykres liniowy sprzedaży netto według miesięcy.

Databricks: notatnik na obliczeniach serverless

W Databricks kliknij New, potem Notebook, wklej kod z prefiksem workspace.nordvella_fvd i uruchom komórkę. Notatnik sam podłącza się do obliczeń Serverless, więc nie zakładasz klastra. U nas komórka wykonała się w 13 s. Wykres dodasz przyciskiem + obok zakładki Table: wybierz Visualization, typ Line, w polu X column kolumnę RokMiesiac, a w Y columns kolumnę SprzedazNetto.

Obie platformy zapisały tabelę z 53 wierszami, a pierwszy miesiąc, styczeń 2022 roku, ma w obu 7 074 654,61 zł sprzedaży netto. Ten sam kod Spark przenosi się między platformami praktycznie bez zmian, co obniża koszt ewentualnej migracji w każdą stronę.

Krok 5. Harmonogram: potok w Fabric i job w Databricks

Co chcemy osiągnąć. Sprawić, żeby tabela miesięczna przeliczała się sama, na przykład codziennie o 6:00, zanim kontroling otworzy raport. W Fabric służy do tego potok (pipeline) z aktywnością notesu, w Databricks job z zadaniem typu Notebook.

Fabric: potok z aktywnością Notes

1. W obszarze roboczym kliknij Nowy element, wybierz Potok i nadaj mu nazwę, u nas nordvella_potok_miesieczny.
2. Na pasku narzędzi kliknij Notes. Na kanwie pojawi się aktywność notesu.
3. Na karcie Ogólne pod kanwą nadaj aktywności nazwę, u nas Sprzedaz_miesieczna, a na karcie Ustawienia wybierz obszar roboczy i notes nordvella_sprzedaz_miesieczna. Pole Połączenie nie jest wymagane.
4. Zapisz potok ikoną dyskietki.

Harmonogram ustawisz przyciskiem Harmonogram na pasku narzędzi: Dodaj harmonogram, typ Stały, cykl Codziennie, pora dnia 06:00 i strefa czasowa. W tym samym panelu wpiszesz adres, na który Fabric wyśle wiadomość, gdy zaplanowane uruchomienie się nie powiedzie.

Potok uruchomiliśmy ręcznie przyciskiem Uruchom. Przebieg zakończył się stanem Powodzenie, a sam notes wykonał się w 1 min 4 s.

Databricks: job z zadaniem Notebook

1. Kliknij New, potem Job, i zmień nazwę joba, u nas nordvella_fvd_miesieczna.
2. Kliknij Notebook, nazwij zadanie, a w polu Path wskaż notatnik (najszybciej z karty Recents). Jako Compute zostaw Serverless i kliknij Create task.
3. W panelu po prawej kliknij Add trigger.

4. Wybierz Scheduled, przełącz Schedule type na Schedule i ustaw Every Day at 06:00 w strefie Europe/Warsaw.
5. Kliknij Save, a potem Run now, żeby sprawdzić job od razu.

W obu platformach harmonogram jest kilkoma kliknięciami. Różnica leży w szerokości: potoki Fabric (z rodziny Data Factory) łatwo łączą kopiowanie danych z wielu źródeł z notesami i procedurami, a joby Databricks mają więcej wyzwalaczy opartych na danych, takich jak pojawienie się pliku czy zmiana tabeli.

Krok 6. Raport w Power BI i pulpit AI/BI

Co chcemy osiągnąć. Dać zarządowi raport ze sprzedażą w regionach i trendem miesięcznym, odświeżany bez kopiowania danych. W Fabric robi to Power BI na modelu Direct Lake, w Databricks pulpit AI/BI.

Fabric: model Direct Lake i raport Power BI

Direct Lake to tryb, w którym model Power BI czyta tabele Delta prosto z OneLake, bez importu danych do modelu i bez zapytań do bazy przy każdym kliknięciu. W lakehouse kliknij Nowy model semantyczny, nadaj nazwę, zaznacz tabele i kliknij Potwierdź.

Relacje między tabelami dodaliśmy skryptem w widoku TMDL (TMDL to tekstowy zapis modelu Power BI). Otworzysz go z menu modelu poleceniem Otwórz w widoku TMDL, na razie w wersji zapoznawczej: wklejasz skrypt i klikasz Zastosuj. Ten sam efekt da przeciągnięcie kolumn między tabelami w widoku modelu.

createOrReplace

	relationship sprzedaz_sklepy
		fromColumn: sprzedaz.SklepID
		toColumn: sklepy.SklepID

	relationship sprzedaz_kalendarz
		fromColumn: sprzedaz.DataID
		toColumn: kalendarz.DataID

	relationship sprzedaz_produkty
		fromColumn: sprzedaz.ProduktID
		toColumn: produkty.ProduktID

Najszybszy raport daje polecenie Automatyczne tworzenie raportów z menu modelu w obszarze roboczym. Power BI dobiera pola sam, a w panelu Twoje dane zaznaczasz tabele i pola, które Cię interesują. U nas po zaznaczeniu tabel sklepy i sprzedaz powstało szybkie podsumowanie z sześcioma wykresami.

Do raportu dla zarządu i tak warto zaprojektować wizualizacje samodzielnie. Pokazujemy to krok po kroku w lekcji o modelu Direct Lake i Copilocie w kursie Power BI.

Databricks: pulpit AI/BI zbudowany przez Genie

W Databricks kliknij New, potem Dashboard. Nowy pulpit proponuje Create a dashboard with Genie: opisujesz po polsku, co chcesz zobaczyć, a znakiem @ wskazujesz tabele z katalogu. Wpisaliśmy takie polecenie:

Polecenie dla Genie: pulpit sprzedaży Nordvelli

Genie przygotował pulpit sam: utworzył trzy lokalne widoki metryk (Sprzedaż, Sklepy, Kalendarz), czyli definicje miar, takich jak sprzedaż netto i marża, połączył je relacjami po kolumnach SklepID i DataID i zbudował na nich trzy wykresy z polskimi tytułami i opisami. Pulpit opublikowaliśmy przyciskiem Publish.

Power BI jest dojrzałym narzędziem raportowym z bogatym modelem danych, językiem DAX i aplikacjami mobilnymi, a w organizacji z Microsoft 365 raporty trafiają też do Teams i Excela. Pulpity AI/BI są prostsze, ale żyją tuż obok danych i dają się zbudować poleceniem w języku naturalnym. Jeśli Twoja firma już raportuje w Power BI, a dane przetwarza w Databricks, oba światy da się połączyć, o czym piszemy niżej.

AI w obu platformach: Copilot i Genie

Co chcemy osiągnąć. Sprawdzić, czy menedżer bez znajomości SQL dostanie poprawną odpowiedź na pytanie zadane po polsku.

Databricks: przestrzeń Genie

Kliknij New, potem Genie Agent, wskaż tabele schematu nordvella_fvd i kliknij Create. W trybie Chat zadaliśmy pytanie:

Pytanie do Genie o sprzedaż w regionach

Liczby w tabeli są poprawne, a przycisk Show code pokazuje zapytanie SQL, które Genie napisał. Warto do niego zaglądać przy wnioskach słownych: w podsumowaniu Genie napisał, że najwyższa sprzedaż była „ponad pięciokrotnie większa niż najniższa”, a z tabeli wychodzi 37,12 mln wobec 7,68 mln zł, czyli ok. 4,8 raza. Kwoty brane prosto z zapytania są pewne, a porównania opisane słowami sprawdzasz na liczbach.

Fabric: Copilot

Copilot w Fabric i w Power BI wymaga płatnej pojemności Fabric F2 lub większej. Wersja próbna go nie obejmuje, o czym informuje już opis typu obszaru roboczego w kroku 1. Dlatego Copilota pokazujemy na zrzucie z naszego kursu Power BI, nagranym w tym samym środowisku na płatnej pojemności: Copilot w Power BI Desktop proponuje miarę DAX na danych Nordvelli i objaśnia ją krok po kroku.

Jeśli Copilot nie pojawia się w Twoim Power BI albo Fabric, przyczyną jest zwykle pojemność, licencja albo ustawienie dzierżawy. Opisujemy to w artykule Copilot w Power BI jest niedostępny: pojemność Fabric, licencja i ustawienia administratora.

Uprawnienia i pochodzenie danych

Co chcemy osiągnąć. Dać analitykom sprzedaży dostęp do wybranych tabel i wiedzieć, skąd pochodzi każda liczba w raporcie.

Fabric: role OneLake i widok pochodzenia

Dostęp w Fabric zaczyna się od czterech ról obszaru roboczego, od administratora po rolę z prawem tylko do odczytu. Dokładniej ustawisz go w Zabezpieczeniach usługi OneLake: w lakehouse kliknij Zarządzaj zabezpieczeniami usługi OneLake, potem Nowy, nazwij rolę, wybierz uprawnienie odczytu i zaznacz konkretne tabele. To samo okno pozwala ograniczyć dostęp do wierszy i kolumn. Na liście jest już domyślna rola DefaultReader z uprawnieniem odczytu całego lakehouse, więc zanim nowa rola zacznie ograniczać dostęp, sprawdź, kto należy do roli domyślnej.

Databricks: GRANT w Unity Catalog i graf pochodzenia

W Databricks uprawnienia nadajesz na każdym poziomie Unity Catalog: katalogu, schemacie i tabeli. W Catalog Explorer otwórz tabelę, kliknij kartę Permissions, potem Grant, wskaż użytkownika albo grupę i zaznacz uprawnienia. To samo zrobisz poleceniem SQL:

GRANT SELECT ON TABLE workspace.nordvella_fvd.sprzedaz TO `analitycy_sprzedazy`;

Unity Catalog sam zapisuje pochodzenie danych (lineage): wie, z których tabel powstała sprzedaz_miesieczna, którym notatnikiem i którym jobem. Graf otworzysz na karcie Lineage tabeli przyciskiem See lineage graph.

W większych firmach dochodzi jeszcze warstwa ładu danych: w ekosystemie Microsoft to Microsoft Purview z etykietami poufności, a w Databricks rozbudowane funkcje Unity Catalog, takie jak tagi, maskowanie kolumn i filtry wierszy.

Fabric i Databricks razem

Co chcemy osiągnąć. Sprawdzić, czy wybór jednej platformy wyklucza drugą. Nie wyklucza, bo obie zapisują tabele w formacie Delta i Fabric ma wbudowane elementy do pracy z Azure Databricks.

W galerii Nowy element po wpisaniu „Databricks” Fabric pokazuje dwa elementy. Dublowany katalog Azure Databricks wyświetla w Fabric tabele z katalogu Unity Catalog, dzięki czemu Power BI w trybie Direct Lake czyta dane przetworzone w Databricks. Magazyn platformy Azure Databricks (w wersji zapoznawczej) pozwala odwrotnie: używać OneLake jako magazynu dla Azure Databricks.

Drugi mechanizm to skróty OneLake (shortcuts): odwołania do danych w innych miejscach bez kopiowania. W lakehouse kliknij Nowy skrót, a zobaczysz źródła wewnętrzne i zewnętrzne, w tym Amazon S3, Azure Data Lake Storage Gen2 i magazyn Google Cloud.

Te funkcje dotyczą Azure Databricks. W naszym teście pracowaliśmy na Databricks Free Edition, więc dublowania katalogu nie uruchamialiśmy, ale samo istnienie tych elementów mówi dużo o kierunku: firmy coraz częściej łączą obie platformy, zamiast wybierać jedną.

Koszty: pojemność czy jednostki DBU

Co chcemy osiągnąć. Zrozumieć, za co płacisz w każdej platformie, zanim porównasz oferty. Modele rozliczeń są różne, więc samo porównanie stawek nic nie mówi bez wzorca użycia.

Fabric rozliczasz pojemnością. Pojemność F2 to 2 jednostki CU, a każda kosztuje w cenniku katalogowym 0,22 USD za godzinę, więc F2 działająca przez cały miesiąc to 321,20 USD. Azure nalicza pojemność za każdą sekundę pracy, z minimum jednej minuty. Rezerwacja na rok obniża stawkę o ok. 40%. Pojemność możesz wstrzymać, na przykład na noc, a magazyn OneLake płacisz osobno, 0,024 USD za GB miesięcznie. Do raportów Power BI na pojemnościach mniejszych niż F64 odbiorcy potrzebują licencji Power BI Pro, od F64 wystarcza im licencja bezpłatna. Wszystkie obciążenia przypisane do pojemności dzielą przy tym tę samą moc. Na małej pojemności równoległe zadania Spark potrafią się nawzajem zablokować, tak jak w naszym teście:

Tu przyczyną była sesja po ładowaniu tabel, opisana w kroku 2. Po jej zatrzymaniu notes ruszył od razu. Sam komunikat podpowiada trzy wyjścia: zatrzymać aktywne zadanie Spark w centrum monitorowania, wybrać większą pojemność albo spróbować później. W produkcji podobne kolejki rozwiązuje większa pojemność albo rozłożenie ciężkich zadań w czasie.

Databricks rozliczasz jednostkami DBU za czas pracy obliczeń, a stawka zależy od ich rodzaju. W Azure Databricks Premium zadania (Jobs) kosztują 0,30 USD za DBU, obliczenia interaktywne 0,55 USD, hurtownie SQL Pro 0,72 USD, a hurtownie SQL Serverless 0,91 USD za DBU. W obliczeniach klasycznych dochodzi rachunek dostawcy chmury za maszyny wirtualne, w serverless ten koszt jest w stawce. Klastry i hurtownie SQL zatrzymują się automatycznie po ustawionym czasie bezczynności, więc płacisz głównie za czas faktycznej pracy.

W praktyce stała pojemność Fabric jest przewidywalna w budżecie i dobrze pasuje do firm, które raportują przez cały dzień. Rozliczenie za czas pracy w Databricks sprzyja obciążeniom o zmiennym natężeniu, ale wymaga pilnowania rozmiarów klastrów i czasu ich pracy. W obu przypadkach najlepszą kalkulacją jest próba na własnych danych, do której wystarczy wersja próbna Fabric i Databricks Free Edition.

Kiedy Fabric, a kiedy Databricks

Co chcemy osiągnąć. Zebrać obserwacje z testu w jedną ściągę i decyzję, którą możesz omówić z zespołem.

Nasz wniosek z testu

Na tych samych danych obie platformy dały te same liczby, a większość kodu przeniosła się bez zmian. Fabric wygrywa szybkością startu dla zespołów, które żyją w Power BI i Microsoft 365: lakehouse, model Direct Lake i raport powstają w jednym portalu, a koszty zamykają się w jednej pojemności. Databricks daje inżynierom danych i zespołom ML więcej kontroli nad obliczeniami, bogatsze wyzwalacze jobów i Unity Catalog, który sam śledzi pochodzenie danych. Jeśli w Twojej firmie są oba te zespoły, rozsądnym wyborem bywa połączenie: przetwarzanie w Databricks, raportowanie w Power BI na tych samych tabelach Delta.

Pracę z Apache Spark na platformie Databricks, od PySparka i Spark SQL po format Delta, ćwiczymy na szkoleniu z przetwarzania danych Big Data, a modelowanie i raportowanie w Power BI, także z Copilotem, na kompleksowym szkoleniu Power BI. Oba szkolenia znajdziesz pod tym artykułem.

✕