Blog JSystems - uwalniamy wiedzę!
Blog JSystems - uwalniamy wiedzę!
W skrócieDatabricks to platforma w chmurze do przetwarzania danych, analityki i AI, stworzona przez twórców Apache Spark. Łączy jezioro danych z hurtownią w jedno środowisko, nazywane lakehouse: dane leżą w Twojej chmurze w otwartym formacie, a inżynierowie, analitycy i data scientiści pracują na nich w notebookach, SQL i narzędziach AI.
W tym przewodniku wyjaśniamy, czym jest Databricks, skąd się wziął i jak działa, a potem przechodzimy przez platformę w praktyce, na darmowym koncie Databricks Free Edition. Na danych fikcyjnej sieci sklepów z elektroniką Nordvella (tej samej, na której pracuje nasz bezpłatny kurs Power BI) wgrywamy pliki, piszemy kod w PySpark i SQL i korzystamy z historii tabel Delta Lake. Budujemy też potok z kontrolą jakości danych, dashboard i agenta Genie, któremu zadajemy pytania o sprzedaż po polsku. Każdy plik i każdy notebook możesz pobrać i powtórzyć u siebie.
Z tego artykułu dowiesz się:
Pliki do tego artykułu
Dane fikcyjnej sieci Nordvella (nagłówki kolumn po angielsku, wartości po polsku) i notebooki, które uruchamiamy w kolejnych sekcjach. Pliki CSV wgrywasz do wolumenu w Unity Catalog, notebooki importujesz do workspace'u.
Databricks to platforma w chmurze, na której firma przechowuje dane, przetwarza je i buduje na nich raporty, modele uczenia maszynowego i aplikacje AI. Działa na Amazon Web Services, Microsoft Azure i Google Cloud. Nie instalujesz jej na swoim serwerze: logujesz się przez przeglądarkę do workspace'u, czyli przestrzeni roboczej zespołu, i tam masz notebooki, edytor SQL, katalog danych, harmonogram zadań i narzędzia AI.
Najprościej opisać Databricks przez problem, który rozwiązuje. W typowej firmie dane sprzedażowe leżą w kilku systemach. Analityk kopiuje je do hurtowni, żeby zbudować raport. Data scientist kopiuje je drugi raz do jeziora danych, bo hurtownia nie przechowuje logów i plików, a modele potrzebują wszystkiego. Za chwilę są trzy kopie, każda trochę inna, każda z innymi uprawnieniami, i nikt nie wie, która liczba jest prawdziwa. Databricks proponuje jedną kopię danych w chmurze, w otwartym formacie, a na niej wszystkie zadania: od zapytania SQL po trenowanie modelu.
Platforma składa się z kilku warstw, które w praktyce widzisz jako jedno narzędzie:
Databricks powstał wokół Apache Spark i nadal go rozwija, ale to nie jest „Spark w chmurze”. Spark jest jednym z silników, a wokół niego jest katalog danych, format tabel, harmonogram, narzędzia dla analityków i AI. Jeśli chcesz najpierw zrozumieć sam silnik, przeczytaj nasz artykuł Czym jest Apache Spark - kompletny przewodnik dla początkujących.
Na co dzień korzysta z niego kilka ról naraz. Inżynier danych ładuje i czyści dane, analityk pisze zapytania i buduje raporty, data scientist trenuje modele, a administrator pilnuje dostępu i kosztów. Wszyscy pracują na tych samych tabelach, więc liczba w raporcie i liczba, na której uczy się model, pochodzą z jednego źródła.
Historia Databricks zaczyna się od Apache Spark. Spark powstał w 2009 roku w laboratorium AMPLab na Uniwersytecie Kalifornijskim w Berkeley jako szybsza alternatywa dla Hadoop MapReduce: zamiast zapisywać wyniki pośrednie na dysk, trzyma je w pamięci operacyjnej klastra. W 2013 roku siedmiu badaczy z AMPLab, wśród nich Ali Ghodsi, Matei Zaharia i Ion Stoica, założyło firmę Databricks, a Spark trafił pod opiekę Apache Software Foundation. Szerzej o drodze od Hadoopa do dzisiejszych platform piszemy w artykule Historia big data: od Hadoopa i MapReduce do Sparka, Databricks i Fabric. Podstawowe pojęcia, od reguły 5V po jezioro danych i lakehouse, zebraliśmy w artykule Co to jest big data? Pojęcia, krajobraz technologiczny i platformy.
Przez pierwsze lata Databricks był przede wszystkim wygodnym środowiskiem do uruchamiania Sparka w chmurze. Przełom przyniosły trzy projekty. W 2019 roku firma udostępniła jako open source Delta Lake, czyli format tabel z dziennikiem transakcji, który zamienia zwykłe pliki w jeziorze danych w tabele z gwarancjami jak w bazie. W 2020 roku opisała koncepcję lakehouse, a rok później jej twórcy przedstawili ją w pracy naukowej na konferencji CIDR. W 2022 roku dla wszystkich klientów wystartował Unity Catalog, jeden katalog i system uprawnień dla wszystkich danych w firmie, a w 2024 roku Databricks udostępnił go jako open source.
Kolejne lata to AI i bazy danych. W 2023 roku Databricks przejął MosaicML, firmę od trenowania modeli językowych, w 2024 roku Tabular, założony przez twórców konkurencyjnego formatu Apache Iceberg, a w 2025 roku Neon, z którego technologii powstała baza Lakebase. W czerwcu 2025 roku wystartowała darmowa Databricks Free Edition, która zastąpiła wcześniejszą Community Edition. W 2026 roku firma przemianowała część narzędzi: asystent w notebookach to teraz Genie Code, a przestrzenie do pytań w języku naturalnym to Genie Agents.
Skalę firmy dobrze oddają jej własne komunikaty: w sierpniu 2026 roku Databricks podał roczny przychód w ujęciu bieżącym (ang. revenue run-rate) powyżej 7 mld USD i wycenę 190 mld USD, a na stronie firmy znajdziesz informację o ponad 20 000 organizacji korzystających z platformy.
Słowo, które najczęściej pada przy Databricks, to lakehouse. To połączenie dwóch angielskich słów: data lake (jezioro danych) i data warehouse (hurtownia danych). Żeby zrozumieć, po co je łączyć, trzeba zobaczyć, czym się różnią.
Hurtownia danych przechowuje uporządkowane tabele i świetnie odpowiada na pytania w SQL: ile sprzedaliśmy w regionie, jak zmieniła się marża. Pilnuje schematu, transakcji i uprawnień. Dane trzyma jednak we własnym formacie, a logi, pliki JSON czy obrazy do niej nie pasują. Jezioro danych to z kolei katalog plików w taniej pamięci obiektowej chmury: zmieści wszystko, a pliki w otwartych formatach (CSV, JSON, Parquet) przeczyta dowolne narzędzie. Brakuje mu za to transakcji i kontroli schematu, więc bez dyscypliny zamienia się w bagno danych (ang. data swamp), w którym nikt nie wie, który plik jest aktualny.
Lakehouse bierze z jeziora tanie przechowywanie i otwarte pliki, a z hurtowni transakcje, schemat i uprawnienia. Kluczowy element to format tabel z dziennikiem transakcji: obok plików Parquet leży dziennik, który zapisuje każdą zmianę tabeli jako osobną wersję. Dzięki niemu dwa zapisy naraz nie zostawią bałaganu, a zapytanie zawsze czyta spójny stan tabeli. W Databricks tym formatem jest Delta Lake, a platforma czyta i zapisuje też tabele Apache Iceberg.
Transakcje ACID, o których mowa w tabeli, to cztery gwarancje znane z baz danych: zmiana wykonuje się w całości albo wcale (atomowość), tabela zawsze spełnia swoje reguły (spójność), równoległe zmiany sobie nie przeszkadzają (izolacja), a zatwierdzona zmiana nie znika (trwałość).
W praktyce lakehouse porządkuje się w warstwy. Najpopularniejszy wzorzec to architektura medalionowa: surowe dane w warstwie bronze, oczyszczone w silver i biznesowe zestawienia w gold. Zbudujemy ją na danych Nordvelli w sekcji o potokach Lakeflow.
Databricks dzieli się na dwie części, które warto rozróżniać, bo od nich zależą koszty, bezpieczeństwo i to, co widzisz w interfejsie.
Płaszczyzna sterowania (ang. control plane) działa po stronie Databricks. To aplikacja, którą otwierasz w przeglądarce, harmonogram zadań, metadane katalogu i usługi zarządzające. Płaszczyzna obliczeń (ang. compute plane) to maszyny, które faktycznie przetwarzają dane. Występuje w dwóch odmianach:
Dane w obu przypadkach leżą jako pliki w pamięci obiektowej chmury. To ważna różnica wobec klasycznej hurtowni: możesz wyłączyć wszystkie obliczenia, a tabele zostają na miejscu i nic nie kosztują poza samym przechowywaniem.
Obliczenia wybierasz zależnie od zadania. Notebook z Pythonem uruchomisz na serverless albo na klastrze ogólnego przeznaczenia (ang. all-purpose cluster), który dzieli kilka osób. Zaplanowane zadanie dostaje klaster zadania (ang. job compute), który powstaje na czas przebiegu i znika po nim. Zapytania SQL, dashboardy i Genie korzystają z SQL warehouse, czyli silnika do zapytań SQL, który w wersji serverless sam dobiera moc do obciążenia.
Zapytania w SQL warehouse przyspiesza Photon, silnik wykonawczy Databricks napisany w C++ i zgodny z interfejsami Sparka. Jest włączony domyślnie we wszystkich SQL warehouse'ach, a z kodem nic nie musisz robić. Serverless SQL warehouse startuje w kilka sekund, wersje pro i classic potrzebują na start kilku minut.
Co chcemy osiągnąć. Założymy bezpłatne konto Databricks Free Edition, na którym przećwiczysz wszystkie przykłady z tego artykułu, bez karty płatniczej i bez konta w AWS, Azure czy Google Cloud. Na końcu tej sekcji będziesz w swoim workspace'ie i będziesz wiedzieć, gdzie w nim co jest.
Free Edition zastąpiła starszą Community Edition. Ma prawie wszystkie narzędzia z płatnych planów, ale działa tylko na obliczeniach serverless i ma limity, które wystarczą do nauki i małych projektów. Regulamin wyklucza jej użycie komercyjne, więc do pracy na danych firmy potrzebujesz płatnego konta.
Krok 1. Otwórz stronę databricks.com/learn/free-edition i kliknij Sign up for Free Edition. Zobaczysz formularz rejestracji. Możesz zalogować się kontem Google albo Microsoft, a my pokazujemy wariant z samym adresem e-mail: wpisz go w polu Email i kliknij Continue with email.
Krok 2. Databricks wyśle na podany adres wiadomość z tematem Databricks - Your verification code is ... i jednorazowym kodem w postaci trzech znaków, myślnika i kolejnych trzech znaków. Wpisz kod w okienkach na stronie Enter verification code. Okienek jest sześć, a myślnik między nimi strona wstawia sama. Kod szybko wygasa: gdy licznik na przycisku Resend code in dojdzie do zera, przyciskiem Resend code poprosisz o nowy.
Krok 3. Na ekranie Set up your account nadaj kontu nazwę w polu Name your account (domyślnie to początek adresu e-mail z dopiskiem Free Edition), w polu Where are you located? wybierz kraj i kliknij Continue. Pole zgody na wiadomości marketingowe możesz zostawić puste.
Krok 4. Po kliknięciu Continue Databricks może poprosić o rozwiązanie krótkiej zagadki, która potwierdza, że rejestruje się człowiek. Rozwiąż ją, a po chwili zobaczysz swój workspace.
Po założeniu konta trafiasz na stronę startową workspace'u. Na środku są kursy (Courses) i interaktywne pokazy (Interactive demos), a po lewej pasek boczny, z którego korzystasz przez cały czas pracy. Warto od razu wiedzieć, gdzie co leży:
Przycisk New na górze paska tworzy nowe elementy, między innymi notebook (Notebook), zapytanie (Query), dashboard, agenta Genie (Genie Agent), zadanie (Job), potok (ETL pipeline) i eksperyment MLflow (Experiment).
Co chcemy osiągnąć. Dział analiz sieci Nordvella dostał trzy pliki CSV: sprzedaż z kas i sklepu internetowego za lata 2022-2026, listę 15 sklepów i katalog 30 produktów, a do tego czwarty plik ze zmianami w sklepach, potrzebny w sekcji o Delta Lake. Chcemy je mieć w jednym miejscu w Databricks, z porządnymi nazwami i uprawnieniami, żeby w kolejnych sekcjach zrobić z nich tabele, raport i potok. Na końcu tej sekcji pliki będą leżeć w wolumenie workspace.nordvella_lakehouse.raw_files.
Unity Catalog porządkuje wszystko w trzech poziomach: katalog, schemat i obiekt. Nad katalogami jest jeszcze metastore, czyli kontener na wszystkie katalogi w danym regionie chmury, ale w nazwach obiektów go nie podajesz. Pełna nazwa tabeli ma więc trzy części, na przykład workspace.nordvella_lakehouse.sales. Pliki, które nie są tabelami (CSV, obrazy, PDF), trzymasz w wolumenach (ang. volumes), a nie luzem w pamięci chmury, dzięki czemu obowiązują je te same uprawnienia co tabele.
Krok 1. Kliknij Catalog w pasku bocznym. W Free Edition zobaczysz w sekcji My organization katalogi workspace (na Twoje dane) i system (tabele systemowe z informacjami o użyciu platformy), a w Shares received katalog samples z przykładowymi danymi od Databricks.
Krok 2. Schemat i wolumen założymy poleceniami SQL. Kliknij SQL Editor w pasku bocznym, a w edytorze przycisk + (Create new) i pozycję Query. W nowej karcie zapytania wpisz:
CREATE SCHEMA IF NOT EXISTS workspace.nordvella_lakehouse;
CREATE VOLUME IF NOT EXISTS workspace.nordvella_lakehouse.raw_files;Kliknij Run all. Przy pierwszym uruchomieniu Databricks zapyta, na jakich obliczeniach wykonać zapytanie. Zostaw SQL Warehouse i Serverless Starter Warehouse i kliknij Start, attach and run. Hurtownia serverless startuje w kilka sekund.
Krok 3. Wróć do Catalog, rozwiń workspace, potem nordvella_lakehouse i Volumes, i kliknij raw_files. Na stronie wolumenu kliknij Upload to this volume, a w oknie Upload files to a volume in Unity Catalog kliknij browse i wskaż cztery pobrane pliki: nordvella_sales.csv, nordvella_stores.csv, nordvella_products.csv i nordvella_stores_changes.csv. Piąty plik, z dostawą z czerwca 2026, dołożymy później, w sekcji o potokach. Komunikat No conflicts detected mówi, że w wolumenie nie ma jeszcze plików o tych nazwach. Kliknij Upload.
Po kilku sekundach pliki pojawią się w zakładce Files. Każdy ma teraz ścieżkę zaczynającą się od /Volumes/, której użyjemy w notebooku.
Co chcemy osiągnąć. Kierownik działu analiz pyta, jak sprzedaż rozkłada się na regiony i kategorie produktów. Zamiast kopiować CSV do arkusza wczytamy pliki z wolumenu do Sparka, zapiszemy je jako tabele Delta i policzymy zestawienia, raz w Pythonie, raz w SQL. Efektem będą trzy tabele w Unity Catalog, wykres sprzedaży w regionach i ranking kategorii.
Notebook to dokument złożony z komórek z kodem i opisem, jak w Jupyterze. W Databricks każda komórka może mieć własny język: domyślny jest Python, a komórka zaczynająca się od %sql wykonuje SQL. Wszystkie komórki pracują na tych samych danych w Unity Catalog.
Krok 1. Pobierz plik 01_nordvella_pierwsze_kroki.py. W Workspace otwórz swój folder użytkownika, kliknij Create i Folder, nazwij folder databricks_guide i otwórz go. Obok nazwy folderu jest przycisk z trzema kropkami (Folder actions): kliknij go i wybierz Import. W oknie Import zostaw File, kliknij browse, wskaż plik i kliknij Import. Tak samo zaimportujesz pozostałe notebooki z artykułu.
Krok 2. Otwórz zaimportowany notebook. W prawym górnym rogu jest wybór obliczeń. W Free Edition to zawsze Serverless, więc nie musisz niczego konfigurować. Kliknij Run all, a notebook wykona komórki po kolei. Numer komórki widać na jej górnym pasku. Komórka 1 to opis, a komórka 2 zakłada schemat i wolumen poleceniami CREATE ... IF NOT EXISTS, więc nic nie zepsuje, jeśli zrobiłeś to już w edytorze SQL.
Zobacz też: Szkolenie Przetwarzanie danych Big Data z Apache Spark
Komórka 3 wczytuje plik sprzedaży do obiektu DataFrame, czyli rozproszonej tabeli Sparka, liczy wiersze i wypisuje schemat:
path = "/Volumes/workspace/nordvella_lakehouse/raw_files/"
sales = (spark.read
.option("header", True)
.option("inferSchema", True)
.csv(path + "nordvella_sales.csv"))
print(f"Liczba wierszy: {sales.count()}")
sales.printSchema()Opcja header mówi, że pierwszy wiersz to nagłówki, a inferSchema każe Sparkowi rozpoznać typy kolumn. Wynik: 108 675 wierszy, data sprzedaży jako date, identyfikatory i ilość jako integer, ceny i kwoty netto jako double. Kolumna cost_amount dostała typ integer, bo w pliku wszystkie koszty są liczbami całkowitymi. Przy danych produkcyjnych lepiej podać schemat jawnie, żeby typ kolumny nie zależał od tego, co akurat jest w pliku.
Komórka 4 korzysta z funkcji display(), która pokazuje dane jako interaktywną tabelę do sortowania, filtrowania i pobrania:
display(sales.limit(10))
Krok 3. Komórka 5 zapisuje wszystkie trzy pliki jako tabele zarządzane w Unity Catalog. Tabela zarządzana (ang. managed table) to taka, której pliki trzyma i porządkuje Databricks, a domyślnym formatem jest Delta Lake:
# Zapis trzech plików jako tabele Delta w Unity Catalog
for name in ["sales", "stores", "products"]:
df = (spark.read
.option("header", True)
.option("inferSchema", True)
.csv(f"{path}nordvella_{name}.csv"))
df.write.mode("overwrite").saveAsTable(f"workspace.nordvella_lakehouse.{name}")
print(name, df.count())
Krok 4. Teraz zestawienie w SQL. Komórka 6, zaczynająca się od %sql, liczy sprzedaż netto w tysiącach złotych, miesiąc po miesiącu, w każdym regionie, z pominięciem zwrotów:
-- Sprzedaż netto w tysiącach zł, miesięcznie, w podziale na regiony
SELECT CAST(date_trunc('MONTH', s.sale_date) AS DATE) AS month,
st.region,
ROUND(SUM(s.net_amount) / 1000, 1) AS net_sales_k_pln
FROM workspace.nordvella_lakehouse.sales AS s
JOIN workspace.nordvella_lakehouse.stores AS st USING (store_id)
WHERE s.is_returned = 0
GROUP BY ALL
ORDER BY month, st.regionNad tabelą wyników kliknij + obok zakładki Table i wybierz Visualization. W edytorze wykresu ustaw typ Line, w polu X column kolumnę month, w Y columns kolumnę net_sales_k_pln z sumą, a w Group by kolumnę region, i kliknij Save.
Krok 5. Zestawienia da się liczyć także w Pythonie, przez API DataFrame. Komórka 7 łączy sprzedaż z produktami i liczy sprzedaż netto w milionach złotych oraz marżę procentową dla każdej kategorii:
from pyspark.sql import functions as F
sales = spark.table("workspace.nordvella_lakehouse.sales")
products = spark.table("workspace.nordvella_lakehouse.products").select("product_id", "category")
by_category = (sales.where("is_returned = 0")
.join(products, "product_id")
.groupBy("category")
.agg(F.round(F.sum("net_amount") / 1e6, 2).alias("net_sales_m_pln"),
F.round(F.sum("net_margin") / F.sum("net_amount") * 100, 1).alias("margin_pct"))
.orderBy(F.desc("net_sales_m_pln")))
display(by_category)
Wynik dobrze pokazuje, po co łączyć dane: kategoria z najmniejszą sprzedażą ma najwyższą marżę, a komputery i telefony dają dużą sprzedaż przy marży 10,1% i 6,6%.
Co chcemy osiągnąć. Zarząd prosi o listę pięciu produktów, które w 2025 roku przyniosły najwięcej sprzedaży netto. Zamiast pisać kod samodzielnie poprosimy o niego asystenta AI wbudowanego w notebook i sprawdzimy, co dostaniemy.
W 2026 roku asystent Databricks Assistant zmienił nazwę na Genie Code. Otwierasz go przyciskiem Genie Code (fioletowa ikona) w górnym pasku albo na prawym pasku notebooka. Rozumie polecenia po polsku i zna strukturę Twoich tabel z Unity Catalog. Wpisaliśmy polecenie:
Genie Code najpierw sprawdził dane, opisując te kroki po angielsku: ile wierszy sprzedaży jest w 2025 roku (29 545 razem ze zwrotami) i czy tabela products ma kolumnę z nazwą produktu. Potem dopisał na końcu notebooka komórkę 8, Top 5 produktów 2025 (netto), uruchomił ją i odpowiedział po polsku, z tabelą wyników i propozycjami kolejnych pytań. Na górze listy jest smartfon Zentaro Nova 5 Pro z 8,65 mln zł sprzedaży netto.
Komórka dopisana przez asystenta czeka na akceptację: na dole notebooka są przyciski Reject all cells i Accept all cells. Zanim ją przyjmiesz, przeczytaj kod. Tu kod filtruje rok warunkiem F.year("sale_date") == 2025, pomija zwroty i dokłada liczbę sprzedanych sztuk, o którą nie prosiliśmy. Asystent napisał o tym w odpowiedzi i podpowiedział, że wystarczy ją usunąć z .agg(...).
Co chcemy osiągnąć. Dział sieci przysłał plik ze zmianami: w Lublinie jest nowy kierownik sklepu i o jedną osobę większy zespół, a we wrześniu 2026 roku rusza nowy sklep w Rzeszowie. Chcemy nanieść obie zmiany na tabelę stores jednym poleceniem, zobaczyć, co się zmieniło, i umieć wrócić do stanu sprzed zmiany. Wszystko to w drugim notebooku, 02_delta_lake_merge_time_travel.sql, który działa na pliku nordvella_stores_changes.csv wgranym wcześniej do wolumenu.
Tabela Delta to katalog plików Parquet z dziennikiem transakcji _delta_log. Każda zmiana tabeli (zapis, MERGE, usunięcie wierszy) to nowy plik JSON w dzienniku i nowa wersja tabeli. Zapytanie zawsze czyta spójną wersję, a starsze wersje zostają dostępne przez określony czas. To właśnie daje tabelom w jeziorze danych transakcje ACID.
Krok 1. Notebook zaczyna się od USE workspace.nordvella_lakehouse;, więc dalej wystarczą krótkie nazwy tabel. Polecenie MERGE INTO porównuje tabelę docelową ze źródłem po kluczu i w jednej transakcji aktualizuje pasujące wiersze, a brakujące dopisuje. Plik CSV czytamy funkcją read_files do tymczasowego widoku:
-- Zmiany z pliku: nowy kierownik sklepu w Lublinie i nowy sklep w Rzeszowie
CREATE OR REPLACE TEMP VIEW stores_changes AS
SELECT * FROM read_files(
'/Volumes/workspace/nordvella_lakehouse/raw_files/nordvella_stores_changes.csv',
format => 'csv', header => true);
MERGE INTO stores AS t
USING stores_changes AS s
ON t.store_id = s.store_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;Wynik MERGE to jeden wiersz z licznikami: dwa wiersze zmienione, w tym jeden zaktualizowany (Lublin) i jeden wstawiony (Rzeszów), zero usuniętych.
Krok 2. Sprawdźmy obie zmiany, a potem historię tabeli:
SELECT store_id, store_name, employees, manager
FROM stores
WHERE store_id IN (13, 16);DESCRIBE HISTORY stores;Sklep w Lublinie ma teraz 17 pracowników i kierownika Tomasza Mazura, a w tabeli jest nowy sklep Nordvella Rzeszów. Polecenie DESCRIBE HISTORY pokazuje dwie wersje: 0 to utworzenie tabeli z notebooka (operacja CREATE OR REPLACE TABLE AS SELECT), 1 to nasz MERGE. Każda wersja ma znacznik czasu, autora i szczegóły operacji.
Tę samą historię zobaczysz bez SQL, w Catalog Explorer: kliknij tabelę stores i zakładkę History.
Krok 3. Podróż w czasie (ang. time travel) to zapytanie o tabelę w starszej wersji. Wystarczy dopisać VERSION AS OF z numerem wersji albo TIMESTAMP AS OF z datą i godziną:
-- Time travel: ta sama tabela w wersji sprzed MERGE
SELECT store_id, store_name, employees, manager
FROM stores VERSION AS OF 0
WHERE store_id IN (13, 16);
Do starej wersji da się też wrócić na stałe poleceniem RESTORE TABLE stores TO VERSION AS OF 0, które zapisuje przywrócenie jako kolejną wersję. Historia nie jest jednak wieczna: dziennik transakcji domyślnie trzyma wpisy przez 30 dni, a pliki z danymi usuniętych wersji polecenie VACUUM kasuje po 7 dniach. Dokumentacja Databricks zaleca więc korzystać z podróży w czasie dla ostatnich 7 dni, chyba że wydłużysz oba ustawienia.
W szczegółach tabeli (zakładka Details, tu dla tabeli sales) widać, że tabele w Free Edition są zarządzane (MANAGED), leżą w pamięci Default Storage i mają włączone między innymi wektory usuwania (enableDeletionVectors). Dzięki nim UPDATE, DELETE i MERGE oznaczają zmienione wiersze w metadanych zamiast przepisywać całe pliki Parquet. Według szczegółów operacji w historii nasz MERGE na tabeli stores dodał jeden taki wektor i jeden nowy plik Parquet.
Chcesz przećwiczyć pracę z tabelami Delta i PySpark na dużych danych pod okiem praktyka? Szkolenie Przetwarzanie danych Big Data z Apache Spark --> to czterodniowy warsztat na platformie Databricks: PySpark i Spark SQL, Unity Catalog, jezioro danych w formacie Delta w architekturze medalionowej i orkiestracja przepływów danych. To szkolenie ma terminy gwarantowane.
Co chcemy osiągnąć. Analityk sieci ma przygotować dla zarządu zestawienie za 2025 rok: sprzedaż i marżę w regionach, trend miesięczny i podział na kanały. Zbudujemy widok raportowy w SQL, sprawdzimy liczby w edytorze, złożymy z nich dashboard i udostępnimy dane w Genie, żeby kierownicy mogli pytać o sprzedaż po polsku, bez SQL.
Zamiast za każdym razem łączyć trzy tabele, zapisujemy złączenie jako widok sales_report: sprzedaż bez zwrotów, z regionem, miastem, nazwą sklepu i kategorią produktu. Poniżej drugie zapytanie korzysta już z widoku i liczy sprzedaż oraz marżę w regionach w 2025 roku:
-- Widok do raportów: sprzedaż bez zwrotów, z regionem, sklepem i kategorią produktu
CREATE OR REPLACE VIEW workspace.nordvella_lakehouse.sales_report AS
SELECT s.sale_id, s.sale_date, st.region, st.city, st.store_name,
p.category, p.product_name, s.channel, s.payment_method,
s.quantity, s.net_amount, s.net_margin
FROM workspace.nordvella_lakehouse.sales AS s
JOIN workspace.nordvella_lakehouse.stores AS st USING (store_id)
JOIN workspace.nordvella_lakehouse.products AS p USING (product_id)
WHERE s.is_returned = 0;
-- Sprzedaż netto i marża w regionach w 2025 roku
SELECT region,
ROUND(SUM(net_amount) / 1e6, 2) AS net_sales_m_pln,
ROUND(SUM(net_margin) / SUM(net_amount) * 100, 1) AS margin_pct
FROM workspace.nordvella_lakehouse.sales_report
WHERE year(sale_date) = 2025
GROUP BY region
ORDER BY net_sales_m_pln DESC;W SQL Editor wklej oba polecenia i kliknij Run all. Pod spodem pojawi się wynik ostatniego zapytania (Results 2 of 2). Region Online sprzedał najwięcej, 37,12 mln zł, ale ma najniższą marżę, 13,8%. Pozostałe regiony mieszczą się między 16% a 18%.
Wykres dodasz tak samo jak w notebooku: + obok zakładki Table, potem Visualization. Dla tego wyniku Databricks zaproponował wykres punktowy (Scatter) ze sprzedażą na osi X i marżą na osi Y. Dobrze widać na nim, że Online odstaje od reszty.
Dashboard AI/BI składa się ze zbiorów danych, czyli zapytań SQL, i widżetów na płótnie: kafelków z liczbami, wykresów i tabel. Nasz dashboard „Nordvella - sprzedaż sieci” korzysta z czterech zapytań do widoku sales_report i ma sześć widżetów: trzy wskaźniki za 2025 rok, trend miesięczny w regionach, sprzedaż w kategoriach i udział kanałów sprzedaży. Liczba transakcji na dashboardzie (28 785) jest mniejsza od liczby wierszy z 2025 roku (29 545), bo widok pomija 760 zwrotów. Taki dashboard to także zrzut otwierający ten artykuł.
Nowy dashboard zakładasz przyciskiem New i pozycją Dashboard, a zbiory danych dodajesz w zakładce Data. Nasz dashboard możesz też zaimportować z pliku nordvella_dashboard.lvdash.json: w Dashboards kliknij strzałkę obok przycisku Create dashboard i wybierz Import dashboard from file. Zadziała od razu, jeśli masz widok workspace.nordvella_lakehouse.sales_report z tej sekcji. Po kliknięciu Publish dashboard dostaje wersję do oglądania, którą udostępniasz przyciskiem Share.
Genie odpowiada na pytania zadane zwykłym językiem. Pod spodem zamienia je na zapytania SQL do wskazanych tabel, wykonuje je na SQL warehouse i pokazuje wynik, często z wykresem. W 2026 roku przestrzenie Genie zmieniły nazwę na Genie Agents.
Krok 1. Kliknij New i Genie Agent. W oknie Connect your data przejdź do zakładki All, wyszukaj sales_report, zaznacz widok i kliknij Create. Do jednego agenta możesz podpiąć kilka tabel, a w zakładce Configure dopisać instrukcje, na przykład jak liczyć marżę.
Krok 2. Genie sam nadał agentowi nazwę „Retail Sales Analysis” i podpowiedział pierwsze pytania. Zadaliśmy własne, po polsku:
Odpowiedź przyszła po polsku po kilkunastu sekundach: region Online, sprzedaż netto 37 120 708,19 zł. Słowo „marża” Genie zrozumiał jako kwotę marży (5 128 244,13 zł), a nie procent. To typowa sytuacja: pytanie było dwuznaczne, więc dostaliśmy poprawną odpowiedź na jedną z interpretacji. Gdy chodzi o procent, napisz „marża procentowa”, a przy wynikach zawsze rozwiń Show code i sprawdź, jakie zapytanie powstało.
Krok 3. Drugie pytanie prosiło o wykres:
Genie najlepiej działa na dobrze opisanych tabelach. Opisy kolumn w Unity Catalog, wspomniane wcześniej instrukcje i przykładowe zapytania w zakładce Configure mają większy wpływ na trafność odpowiedzi niż samo sformułowanie pytania. O tym, jak AI pomaga w pisaniu SQL poza Databricks, piszemy w przewodniku AI w SQL: tworzenie zapytań, wyszukiwanie błędów i optymalizacja SQL z pomocą AI.
Co chcemy osiągnąć. Sklepy Nordvelli co miesiąc przysyłają nowy plik sprzedaży, a w plikach zdarzają się błędy kas: ujemna ilość, brak numeru sklepu, zdublowane paragony. Chcemy, żeby nowe pliki same trafiały do tabel, błędne wiersze były odrzucane i liczone, a zestawienie miesięczne dla zarządu odświeżało się bez ręcznej pracy. Zbudujemy to jako potok Lakeflow w architekturze medalionowej, którą opisaliśmy w sekcji o lakehouse.
Lakeflow to rodzina narzędzi Databricks do inżynierii danych: Lakeflow Connect pobiera dane z baz i aplikacji, potoki deklaratywne (dawniej Delta Live Tables, dziś Lakeflow Spark Declarative Pipelines) przetwarzają je, a Lakeflow Jobs uruchamia całość z harmonogramu. Potok deklaratywny opisujesz jako zestaw tabel i zapytań. Kolejność kroków, ponowienia po błędzie i przyrostowe przetwarzanie Databricks układa sam.
Krok 1. Cały potok to jeden plik SQL, 03_pipeline_sprzedaz.sql:
-- Potok Lakeflow Declarative Pipelines: sprzedaż Nordvella w warstwach bronze, silver, gold
-- Artykuł „Czym jest Databricks - kompletny przewodnik” (blog JSystems).
-- Potok czyta z wolumenu raw_files pliki o nazwach nordvella_sales*.csv
-- BRONZE: każdy nowy plik CSV z folderu trafia do tabeli dokładnie tak, jak przyszedł
CREATE OR REFRESH STREAMING TABLE sales_bronze
COMMENT "Surowe pliki sprzedaży z kas i sklepu online"
AS SELECT *, _metadata.file_name AS source_file
FROM STREAM read_files(
'/Volumes/workspace/nordvella_lakehouse/raw_files/',
format => 'csv', header => true,
fileNamePattern => 'nordvella_sales*.csv');
-- SILVER: typy, bez duplikatów, wiersze z błędami odrzucone przez oczekiwania (expectations)
CREATE OR REFRESH MATERIALIZED VIEW sales_silver (
CONSTRAINT positive_quantity EXPECT (quantity > 0) ON VIOLATION DROP ROW,
CONSTRAINT store_present EXPECT (store_id IS NOT NULL) ON VIOLATION DROP ROW
)
COMMENT "Sprzedaż po kontroli jakości"
AS SELECT DISTINCT
CAST(sale_id AS BIGINT) AS sale_id,
CAST(sale_date AS DATE) AS sale_date,
CAST(product_id AS INT) AS product_id,
CAST(store_id AS INT) AS store_id,
CAST(quantity AS INT) AS quantity,
CAST(net_amount AS DECIMAL(12,2)) AS net_amount,
CAST(net_margin AS DECIMAL(12,2)) AS net_margin,
channel,
payment_method,
CAST(is_returned AS INT) AS is_returned
FROM sales_bronze;
-- GOLD: sprzedaż miesięczna w regionach, gotowa pod raport
CREATE OR REFRESH MATERIALIZED VIEW sales_gold_monthly
COMMENT "Sprzedaż netto i marża miesięcznie wg regionu"
AS SELECT
date_trunc('MONTH', s.sale_date) AS month,
st.region,
SUM(s.net_amount) AS net_sales,
SUM(s.net_margin) AS net_margin,
COUNT(*) AS transactions
FROM sales_silver AS s
JOIN workspace.nordvella_lakehouse.stores AS st USING (store_id)
WHERE s.is_returned = 0
GROUP BY ALL;Trzy elementy, które warto zrozumieć:
sales_bronze (STREAMING TABLE) czyta pliki przez Auto Loader. Pamięta, które pliki już przetworzyła, więc kolejne uruchomienie wczyta tylko nowe. Kolumna source_file zapisuje nazwę pliku, z którego przyszedł wiersz.sales_silver to reguły jakości danych. EXPECT (quantity > 0) ON VIOLATION DROP ROW odrzuca wiersze z ilością zero lub ujemną, a potok liczy, ile ich było. Zamiast DROP ROW możesz zatrzymać cały potok (FAIL UPDATE) albo tylko zapisać ostrzeżenie.MATERIALIZED VIEW) przechowuje wynik zapytania jak tabelę i odświeża go przy każdym uruchomieniu potoku, w miarę możliwości przyrostowo.Krok 2. Kliknij New i ETL pipeline. Databricks od razu tworzy potok o nazwie New Pipeline z datą i godziną i otwiera edytor potoków. Po lewej jest drzewo plików z folderem transformations i pustym plikiem my_transformation.py, a na górnym pasku domyślny katalog i schemat potoku (na start workspace.default) oraz przyciski Dry run i Run pipeline.
W ustawieniach potoku (ikona koła zębatego, Settings) zmień nazwę na nordvella_sales_pipeline i schemat na nordvella_lakehouse. Potem przyciskiem + nad drzewem plików dodaj w folderze transformations plik SQL, wklej do niego kod potoku, a przykładowy plik w Pythonie usuń. Na koniec kliknij Run pipeline. Przycisk Dry run sprawdza sam kod i graf zależności, bez przetwarzania danych.
Pierwszy przebieg trwał 1 minutę i 35 sekund. Graf pokazuje cały przepływ: Auto Loader czyta pliki z wolumenu do sales_bronze (109 tys. wierszy), z niej powstaje sales_silver z dwoma oczekiwaniami, a sales_gold_monthly łączy ją z tabelą sklepów i daje 318 wierszy: miesiące razy regiony.
Krok 3. Teraz najciekawsza część. Wgrywamy do wolumenu plik nordvella_sales_2026_06.csv z czerwcową sprzedażą: 2 026 wierszy, w tym celowo wpisane błędy, czyli 4 wiersze z ilością 0 lub -1, 3 wiersze bez numeru sklepu i 2 zdublowane paragony. Uruchamiamy potok jeszcze raz.
Tym razem sales_bronze wczytała tylko nowy plik (2 tys. wierszy), a widoki silver i gold odświeżyły się przyrostowo (Incremental). W kolumnie Expectations przy sales_silver pojawiło się 2 unmet i liczba 7: tyle wierszy odrzuciły reguły jakości.
Po kliknięciu 2 unmet widać szczegóły: zapisano 110 692 wiersze, odrzucono 7, z czego 4 przez regułę positive_quantity, a 3 przez store_present. Dokładnie tyle błędów wpisaliśmy do pliku. Dwa zdublowane paragony usunęło SELECT DISTINCT: 108 675 starych wierszy plus 2 026 nowych, minus 7 odrzuconych i 2 duplikaty, daje właśnie 110 692.
Co chcemy osiągnąć. Zarząd chce mieć dashboard z aktualnymi danymi każdego ranka. Ustawimy zadanie, które o 6:00 uruchomi potok, a po nim odświeży dashboard.
Zadanie (ang. job) w Lakeflow Jobs składa się z kroków (ang. tasks), które mogą od siebie zależeć. Krokiem może być potok, notebook, zapytanie SQL, odświeżenie dashboardu, skrypt Pythona i kilka innych rodzajów pracy. Nasze zadanie nordvella_codzienne_odswiezanie ma dwa kroki: odswiez_potok uruchamia potok, a odswiez_dashboard rusza dopiero po nim i odświeża dashboard „Nordvella - sprzedaż sieci”. Harmonogram ustawiliśmy na 6:00 czasu warszawskiego (Schedules & Triggers).
Przycisk Run now uruchamia zadanie od razu. Nasz przebieg trwał 54 sekundy i zakończył się statusem Succeeded, a zakładka Runs pokazuje czas każdego kroku. Na koncie Free Edition, po zrobieniu zrzutów, wstrzymaliśmy harmonogram, żeby codzienny przebieg nie zużywał dziennego limitu obliczeń.
Na koncie Free Edition trafiliśmy przy tym na limit: potok nie chciał wystartować i zgłosił błąd RESOURCE_EXHAUSTED z informacją o wyczerpaniu limitu obliczeń serverless, bo na koncie działały w tym czasie inne obliczenia, między innymi SQL warehouse. Wystarczyło zatrzymać hurtownię i odczekać kilka minut. Darmowe konto ma limity obliczeń, między innymi najwyżej 5 równocześnie działających kroków zadań i jeden aktywny potok danego typu, więc uruchamiaj na nim jedno cięższe zadanie naraz.
Co chcemy osiągnąć. Dział planowania chce prognozować miesięczną sprzedaż regionów, żeby lepiej rozkładać zamówienia i grafiki pracy. Wytrenujemy prosty model na tabeli sales_gold_monthly z potoku i zobaczymy, jak Databricks zapisuje eksperyment: parametry, metryki i sam model.
MLflow to otwarta platforma do śledzenia eksperymentów z modelami, stworzona przez Databricks i wbudowana w workspace. Każde uruchomienie treningu zapisuje się jako przebieg (ang. run) z parametrami, metrykami i plikami modelu, więc po tygodniu wiesz, który wariant dał najlepszy wynik i na jakich danych powstał. Funkcja mlflow.sklearn.autolog() zapisuje to wszystko sama, bez dopisywania kodu do każdej metryki.
Notebook 04_mlflow_prognoza.py zamienia miesiąc i region na cechy liczbowe, dzieli dane na część treningową i testową i trenuje las losowy (ang. random forest) z biblioteki scikit-learn:
import mlflow
import pandas as pd
from sklearn.ensemble import RandomForestRegressor
from sklearn.metrics import mean_absolute_percentage_error
from sklearn.model_selection import train_test_split
df = spark.table("workspace.nordvella_lakehouse.sales_gold_monthly").toPandas()
df["year"] = pd.to_datetime(df["month"]).dt.year
df["month_no"] = pd.to_datetime(df["month"]).dt.month
X = pd.get_dummies(df[["year", "month_no", "region"]], columns=["region"], dtype=int)
y = df["net_sales"].astype(float)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)
mlflow.sklearn.autolog()
with mlflow.start_run(run_name="prognoza_sprzedazy_rf"):
model = RandomForestRegressor(n_estimators=200, random_state=42).fit(X_train, y_train)
mape = mean_absolute_percentage_error(y_test, model.predict(X_test))
mlflow.log_metric("test_mape", mape)
print(f"Średni błąd procentowy prognozy (MAPE): {mape:.1%}")
Eksperyment pojawia się w Experiments w pasku bocznym, pod nazwą notebooka. Na liście przebiegów widać nazwę prognoza_sprzedazy_rf, czas treningu, zbiory danych użyte w przebiegu i zapisany model.
Po kliknięciu przebiegu widać szczegóły: 6 metryk i 18 parametrów modelu zapisanych automatycznie. Na danych testowych średni błąd procentowy prognozy (MAPE, ang. mean absolute percentage error) wyniósł 0,1296, czyli prognoza myli się średnio o 13%. Jak na model bez cech pogodowych, promocji i kalendarza świąt to dobry punkt wyjścia do porównań z kolejnymi wersjami.
Model z przebiegu można zarejestrować w Unity Catalog (przycisk Register model) i wystawić jako punkt dostępowy przez API (Serving), żeby inne systemy pobierały prognozy. Do aplikacji z modelami językowymi Databricks ma platformę Agent Bricks, wyszukiwanie wektorowe AI Search (dawniej Vector Search) i Playground do testowania modeli. Darmowe konto ma tu ograniczenia: Model Serving bez GPU i jeden punkt AI Search. Jeśli chcesz zrozumieć, jak działają systemy odpowiadające na pytania na podstawie firmowych dokumentów, zajrzyj do naszego przewodnika Co to jest agent AI - kompletny przewodnik dla firm.
Co chcemy osiągnąć. Po kilku tygodniach w workspace'ie jest dużo tabel, a zarząd pyta, skąd się biorą liczby w dashboardzie i kto ma do nich dostęp. Sprawdzimy, co Unity Catalog wie o naszym widoku sales_report: jak go opisać, z czego powstaje, kto z niego korzysta i jak nadać do niego uprawnienia.
Opisy. Na stronie tabeli w Catalog Explorer, w zakładce Overview, Databricks od razu proponuje opis wygenerowany przez AI (AI Suggested Description), który zatwierdzasz przyciskiem Accept albo poprawiasz przez Edit. Przycisk AI generate nad listą kolumn robi to samo dla opisów kolumn. Opisy przydają się ludziom, a do tego korzysta z nich Genie przy odpowiadaniu na pytania.
Pochodzenie danych. Zakładka Lineage pokazuje, z jakich tabel powstaje obiekt i co z niego korzysta. Unity Catalog zbiera te informacje sam, z wykonywanych zapytań, notebooków i potoków. Dla widoku sales_report widać trzy tabele źródłowe (sales, stores, products) i zapisane zapytanie, które tworzy widok (Upstream), a po stronie odbiorców (Downstream) dashboard „Nordvella - sprzedaż sieci”, agenta Genie „Retail Sales Analysis” i zapytanie o regiony. Na liście jest też zadanie nordvella_codzienne_odswiezanie, które odświeża dashboard oparty na tym widoku.
Przycisk See lineage graph pokazuje to samo na grafie, aż do pojedynczych kolumn. Gdy ktoś zapyta, dlaczego sprzedaż w raporcie się zmieniła, idziesz po grafie od dashboardu do źródła, zamiast szukać po notebookach.
Uprawnienia. W zakładce Permissions przycisk Grant otwiera okno nadawania uprawnień. Wybierasz użytkownika lub grupę (Principals) i uprawnienia: SELECT do odczytu, MANAGE do zarządzania obiektem, ALL PRIVILEGES do wszystkiego, a także APPLY TAG i READ METADATA.
To samo zapiszesz w SQL. Na przykład analitycy z grupy analitycy dostają odczyt widoku, ale nie tabel źródłowych, więc widzą tylko sprzedaż bez zwrotów i bez kosztów:
GRANT USE CATALOG ON CATALOG workspace TO `analitycy`;
GRANT USE SCHEMA ON SCHEMA workspace.nordvella_lakehouse TO `analitycy`;
GRANT SELECT ON TABLE workspace.nordvella_lakehouse.sales_report TO `analitycy`;Nazwa grupy jest przykładowa: w firmie podajesz grupę z konsoli konta Databricks albo z Microsoft Entra ID. Free Edition nie ma konsoli konta ani logowania SSO, więc grup z firmowego katalogu użytkowników tam nie podepniesz. Unity Catalog pozwala też filtrować wiersze i maskować kolumny, na przykład pokazywać kierownikowi regionu tylko sprzedaż jego regionu. Te reguły ustawiasz w zakładce Policies.
Databricks nie sprzedaje licencji na użytkownika. Płacisz za zużyte obliczenia, mierzone w DBU (ang. Databricks Unit). DBU to znormalizowana jednostka mocy obliczeniowej: każdy rodzaj i rozmiar obliczeń zużywa określoną liczbę DBU na godzinę, a Databricks rozlicza je co sekundę. Notebook, który liczy przez dwie minuty, zapłaci za dwie minuty, a wyłączony SQL warehouse nie zużywa nic.
Stawka za DBU zależy od czterech rzeczy: rodzaju obliczeń (zadania, SQL, serverless, praca interaktywna), planu, chmury i regionu. Przykład z oficjalnego cennika Azure Databricks: serverless SQL warehouse w rozmiarze 2X-Small, czyli ten sam rozmiar, który dostajesz we Free Edition, zużywa 4 DBU na godzinę, a rozmiar Small 12 DBU. Kwoty w złotych sprawdzasz w kalkulatorze swojej chmury, bo różnią się między regionami i umowami. W obliczeniach klasycznych do rachunku dochodzi koszt maszyn wirtualnych u dostawcy chmury, a zawsze także przechowywanie plików.
Plan Standard Databricks wycofał. Na AWS i Google Cloud konta przeszły na plan Premium 1 października 2025 roku i są tam dwa plany: Premium i Enterprise. Na Azure plan Standard zniknął 1 października 2026 roku. Najtańszy sposób na naukę to Free Edition, która nic nie kosztuje, a w zamian ma limity.
Kilka nawyków, które utrzymują rachunek w ryzach: ustaw automatyczne zatrzymanie SQL warehouse'u po kilku minutach bezczynności, zadania uruchamiaj na obliczeniach zadań zamiast na klastrze do pracy interaktywnej, a koszty sprawdzaj w tabelach systemowych (ang. system tables), gdzie Databricks zapisuje zużycie DBU z podziałem na zadania i użytkowników.
Databricks najczęściej porównuje się z trzema platformami. Wszystkie przechowują dane w chmurze i odpowiadają na zapytania SQL, a różnią się tym, od czego wyszły i w czym są najwygodniejsze.
Databricks wyróżnia się tam, gdzie oprócz SQL potrzebny jest Python, przetwarzanie dużych i różnorodnych danych, uczenie maszynowe i aplikacje AI na tych samych tabelach. Granice się jednak zacierają: Snowflake ma Pythona i funkcje AI, Databricks ma pełną hurtownię SQL, a wszystkie cztery platformy czytają otwarte formaty tabel. Przy wyborze liczą się umiejętności zespołu, chmura, w której firma już jest, i sposób rozliczania, który pasuje do budżetu.
Databricks najwięcej daje tam, gdzie spotykają się trzy rzeczy: dużo danych, różne rodzaje danych i kilka ról, które chcą na nich pracować naraz. Jeśli raporty sprzedażowe, prognozy popytu i asystent AI dla działu obsługi klienta mają korzystać z tych samych tabel, jedna platforma oszczędza kopiowania i sporów o to, która liczba jest prawdziwa.
Są też sytuacje, w których Databricks będzie nadmiarem. Gdy dane mieszczą się w jednej bazie PostgreSQL czy SQL Server, a firmie wystarczą raporty w Power BI, platforma lakehouse doda pracy i kosztów, a nie rozwiąże żadnego problemu. Gdy firma potrzebuje bazy transakcyjnej dla aplikacji (zamówienia, koszyk, magazyn), Databricks nie zastąpi PostgreSQL ani SQL Servera, choć od niedawna ma usługę Lakebase z bazą PostgreSQL obok lakehouse'u.
Pytanie, od którego warto zacząć, brzmi: kto w firmie będzie pisał kod. Databricks zakłada zespół, który pracuje w SQL i Pythonie. Analityk znający tylko Excela szybko odnajdzie się w dashboardach i w Genie, ale potoki, jakość danych i koszty ktoś musi utrzymywać.
Do Databricks najłatwiej wejść od SQL, bo na nim opierają się zapytania, dashboardy i duża część potoków. Kolejny krok to Python i PySpark, czyli interfejs Sparka dla Pythona, a dalej Delta Lake, Unity Catalog i potoki Lakeflow. Wszystko, co pokazaliśmy w tym artykule, przećwiczysz na darmowym koncie Free Edition.
Databricks prowadzi własny program certyfikacji. Każdy egzamin kosztuje 200 USD, a certyfikat jest ważny dwa lata. Najczęściej wybierane ścieżki to:
Aktualną listę egzaminów, liczbę pytań i czas trwania znajdziesz na stronie Databricks Certification. Darmowe kursy wideo do nauki samodzielnej udostępnia Databricks Academy.
Databricks to platforma, na której dane, przetwarzanie, raporty i AI korzystają z jednej kopii danych w Twojej chmurze. W tym przewodniku przeszliśmy całą drogę danych sieci Nordvella: od plików CSV w wolumenie Unity Catalog, przez notebook, tabele Delta, widok raportowy, dashboard i Genie, po potok Lakeflow z harmonogramem i model zapisany w MLflow.
Wszystkie pliki, notebooki i definicję dashboardu znajdziesz w ramce na początku artykułu. Jeśli wybierasz platformę danych dla firmy, porównaj Databricks z innymi platformami w sekcji o Snowflake, Microsoft Fabric i BigQuery i przejdź listę z sekcji kiedy Databricks ma sens.
Komentarze (0)
Brak komentarzy...