Opanowanie architektury Lakehouse: brąz, srebro i złoto w Microsoft Fabric

By Mirko Peters · 2026-08-28

Witamy ponownie na blogu towarzyszącym podcastowi! W najnowszym odcinku szczegółowo przyjrzeliśmy się praktycznym realiom inżynierii uczenia maszynowego w ekosystemie Micro…

Automatically translated with AI from the original post. Read the English original

Witamy ponownie w towarzyszącym podcastowi blogu! W najnowszym odcinku zagłębiliśmy się w praktyczne realia inżynierii uczenia maszynowego w ekosystemie Microsoft. Jeśli jeszcze go nie odsłuchałeś, koniecznie sprawdź Build Machine Learning Models in Microsoft Fabric. Dziś rozwiniemy te koncepcje i pokażemy, jak strukturyzowanie danych zgodnie z architekturą medalionową w Lakehouse w Microsoft Fabric stanowi absolutny fundament skutecznej, skalowalnej operacji uczenia maszynowego.

Tworzenie modeli uczenia maszynowego gotowych do produkcji to nie tylko dobór właściwego algorytmu czy strojenie hiperparametrów. Zazwyczaj o sukcesie modeli predykcyjnych decyduje higiena danych, powtarzalne potoki i solidne zarządzanie. Przyjrzyjmy się, jak opanować architekturę Lakehouse w Microsoft Fabric.

Architektura w skrócie

Projektując kompleksową platformę danych i uczenia maszynowego w Microsoft Fabric, kluczowe jest zrozumienie przepływu danych. Wszystko zaczyna się w OneLake, który pełni rolę zunifikowanej warstwy pamięci masowej. Stamtąd dane trafiają do Lakehouse, gdzie przechodzą przez tabele Delta na poziomie brązowym, srebrnym i złotym.

Po stronie obliczeniowej notesy Fabric udostępniają naukowcom danych gotowy stos do analizy danych oparty na Spark, Pythonie i R. Śledzenie eksperymentów odbywa się bezproblemowo dzięki wbudowanym przebiegom MLflow, które rejestrują metryki, parametry i artefakty bez potrzeby zewnętrznych serwerów śledzenia. Po wytrenowaniu modele trafiają do zunifikowanego rejestru, wraz z wersjonowaniem, zatwierdzeniami i pełnym pochodzeniem danych. Na koniec modele są udostępniane za pośrednictwem zarządzanych zadań wsadowych lub punktów końcowych HTTP działających w czasie rzeczywistym, zasilając takich odbiorców jak Power BI, Power Apps i niestandardowi klienci API.

Lakehouse: ujarzmij dane wejściowe, zachowaj kontrolę

Podstawową filozofią Lakehouse jest połączenie elastyczności jeziora danych z niezawodnością hurtowni danych. Aby to skutecznie działało, dane trzeba uporządkować w odrębne warstwy.

Uwarstw swoje tabele

• Brąz: To warstwa surowego pozyskiwania danych. Dane trafiają tutaj zgodnie z zasadą schema-on-read i pozostają niezmienne na potrzeby audytu i ponownego przetwarzania.
• Srebro: W tej warstwie dane są oczyszczane, typowane i łączone. Dane PII są ograniczane do minimum, a wstępne kontrole jakości są egzekwowane.
• Złoto: Warstwa złota zawiera gotowe do użycia w cechach agregaty, zbudowane na jasnych, udokumentowanych kontraktach danych, z których modele uczenia maszynowego mogą korzystać bezpośrednio.

Dostęp zgodny z przeznaczeniem

Zastosuj kontrolę dostępu opartą na rolach w obszarze roboczym wraz z listami kontroli dostępu na poziomie tabel. Przyznaj naukowcom danych dostęp do odczytu tabel srebrnych i złotych, a dostęp do zapisu ogranicz wyłącznie do tabel cech i katalogów eksperymentalnych.

Barierki jakości danych

Wprowadź rygorystyczne oczekiwania dotyczące ograniczeń not-null, zakresów wartości i integralności referencyjnej. Gdy wiersze nie przejdą tych kontroli, kieruj je bezpośrednio do tabeli _quarantine, aby kolejne potoki nie zawiodły po cichu i nie pobierały uszkodzonych danych.

Lekki magazyn cech

Traktuj wielokrotnego użytku cechy jak tabele złota – na przykład feat_customer_rolling_90d – i towarzysz im słownikowi danych w formacie YAML, aby zespół rozumiał, co reprezentuje każda cecha.

Notesy bez bólu

Wspólne kodowanie może szybko stać się chaotyczne, jeśli programiści korzystają z różnych środowisk. Fabric udostępnia wstępnie zainstalowane jądra, w tym pandas, PySpark, scikit-learn i PyTorch, dzięki czemu wszyscy pracują na dokładnie tej samej bazie.

Przyjmij ustrukturyzowany układ projektu, oddzielając notesy eksploracyjne, skrypty inżynierii cech, procedury trenowania modeli i pliki konfiguracyjne. Powtarzalność zapewniaj w kodzie, a nie w ręcznych kliknięciach w interfejsie. Odczytuj dane z Lakehouse za pomocą Spark SQL, zapisuj gotowe cechy jako tabele Delta i zawsze twórz mniejsze próbki tabel deweloperskich, aby zespół mógł szybko iterować, bez czekania na zapytania do pełnych zbiorów danych.

Śledź wszystko za pomocą MLflow (wbudowanego)

Ręczne śledzenie eksperymentów z modelami prowadzi do wyników, których nie da się odtworzyć. Dzięki wbudowanej integracji MLflow w usłudze Fabric zyskujesz porównywalność między przebiegami, pełną możliwość audytu oraz bezproblemowe wycofywanie zmian, gdy nowo wdrożony model działa gorzej niż oczekiwano.

Rejestruj wszystkie hiperparametry, metryki oceny i wytrenowane artefakty modeli bezpośrednio w skryptach trenowania. Oznaczaj przebiegi kontekstowymi metadanymi, takimi jak okno danych, wersje zestawu cech i skróty commitów kodu, oraz przypinaj tabele treningowe do konkretnych wersji migawek Delta.

Rejestr, zatwierdzenia i pochodzenie danych

Przeniesienie modelu z fazy eksperymentów do produkcji nigdy nie powinno być grą w zgadywanie. Promuj najlepsze przebiegi do zarejestrowanego modelu, stosując wersjonowanie semantyczne, na przykład 1.0.0. Wdróż dwuetapowy proces zatwierdzania, wymagający akceptacji zarówno od właściciela modelu po stronie data science, jak i od właściciela biznesowego. Na koniec zapisz kompletne metadane karty modelu, opisujące cel modelu, zakres danych, uwagi dotyczące sprawiedliwości oraz cele poziomu usług (SLO) dotyczące monitorowania.

Opcje obsługi (wybór zależny od obciążenia)

Scoring wsadowy (tani i niezawodny)

W przypadku obciążeń, które nie wymagają natychmiastowych odpowiedzi w czasie poniżej sekundy, scoring wsadowy jest najlepszym rozwiązaniem. Użyj zaplanowanych zadań lub notebooków w usłudze Fabric, aby odczytywać modele produkcyjne z rejestru, stosować je do zbiorów danych wsadowych i zapisywać predykcje z powrotem w Lakehouse.

Punkt końcowy czasu rzeczywistego (aplikacje interaktywne)

Gdy użytkownicy potrzebują natychmiastowej informacji zwrotnej, na przykład przy walidacji formularzy lub ocenie ryzyka po kliknięciu, wdróż zarejestrowany model jako zarządzany punkt końcowy czasu rzeczywistego bezpośrednio z interfejsu użytkownika usługi Fabric. Udostępnij przewidywalny kontrakt JSON i bezpiecznie połącz go z aplikacjami Power Apps lub aplikacjami zewnętrznymi.

Monitorowanie i ponowne trenowanie

Samo wdrożenie modelu to dopiero połowa sukcesu. Musisz stale monitorować dryf danych, porównując rozkłady cech na żywych danych z wzorcem treningowym, z użyciem dywergencji Kullbacka-Leiblera lub progów indeksu stabilności populacji (PSI). Śledź metryki kondycji operacyjnej, w tym opóźnienie punktu końcowego, wskaźniki błędów oraz koszty na tysiąc ocen. Zautomatyzuj potoki ponownego trenowania, łącząc wyzwalacze czasowe z alertami o dryfie wywoływanymi zdarzeniami, aby modele pozostawały dokładne w czasie.

Bezpieczeństwo i zgodność

Utrzymanie bezpieczeństwa ma kluczowe znaczenie przy pracy z danymi przedsiębiorstwa. Stosuj zasadę najmniejszych uprawnień, przyznając naukowcom danych dostęp do odczytu warstw srebrnej i złotej, a zapis ograniczając do wyznaczonych katalogów cech i eksperymentów. Do przechowywania wszystkich poświadczeń używaj tożsamości zarządzanych oraz usługi Azure Key Vault, dzięki czemu żadne sekrety nigdy nie trafią na stałe do notebooków. Ogranicz ekspozycję danych osobowych (PII), haszując lub tokenizując wrażliwe informacje już na wczesnym etapie warstwy srebrnej, tak aby nigdy nie trafiały do magazynów cech.

Co mierzyć (szybko udowodnij wartość)

Aby szybko wykazać wartość inicjatyw uczenia maszynowego, skup się na właściwych metrykach. Mierz skuteczność modelu za pomocą AUC oraz precision-at-k dla rankingów, śledź wpływ na biznes przez przyrostowe przychody lub zmniejszenie wskaźnika odejść klientów, monitoruj szybkość przejścia od gotowości danych do wdrożenia produkcyjnego oraz oceniaj niezawodność infrastruktury i efektywność kosztową w przeliczeniu na tysiąc predykcji.

Plan wdrożenia na 14 dni

Jeśli chcesz szybko przejść od zera do gotowego do produkcji wdrożenia w usłudze Fabric, postępuj zgodnie z tym uporządkowanym dwutygodniowym planem:

• Dzień 1–2: higiena Lakehouse, struktura warstw brązowej/srebrnej/złotej, listy ACL oraz kontrole jakości danych.
• Dzień 3: szkielet notebooków, pomocnicze funkcje do danych oraz przykładowe tabele deweloperskie.
• Dzień 4–5: zestaw cech v1, trenowanie modelu bazowego oraz logowanie w MLflow.
• Dzień 6: zestaw testów oceny, tworzenie karty modelu oraz rejestracja modelu (v0.1).
• Dzień 7: utworzenie zadania scoringu wsadowego oraz integracja z pulpitem w usłudze Power BI.
• Dzień 8: minimalna wersja monitorowania (MVP), kontrole dryfu oraz logowanie operacyjne.
• Dzień 9: wdrożenie przepływu zatwierdzania oraz promocja do produkcji.
• Dzień 10: konfiguracja punktu końcowego czasu rzeczywistego, ograniczanie przepustowości oraz logowanie żądań (jeśli dotyczy).
• Dzień 11–12: testy A/B, backtesting oraz definiowanie kluczowych wskaźników biznesowych (KPI).
• Dzień 13: zarządzanie kosztami, zabezpieczenia autoskalowania oraz plan wdrożenia kanarkowego.
• Dzień 14: dokumentacja runbooka, przekazanie zespołowi oraz planowanie backlogu.

Typowe pułapki (i szybkie rozwiązania)

Nawet doświadczone zespoły napotykają przeszkody. Unikaj ruletki z notatnikami, blokując środowiska do standardowych jąder Fabric. Nie testuj wyłącznie na małych próbkach, które przestają działać po przeskalowaniu do pełnych zbiorów danych. Zapobiegaj „duchom” modeli w środowisku produkcyjnym, konsekwentnie egzekwując procesy promowania w rejestrze. Kontroluj koszty chmury, domyślnie stosując przetwarzanie wsadowe tam, gdzie to możliwe, i buforując wyliczone cechy.

Gotowe fragmenty kodu

Aby ułatwić start w kolejnym projekcie, oto krótki fragment kodu pokazujący, jak odczytać określoną wersję tabeli Delta:

sales_v = spark.read.option("versionAsOf", 123).table("lakehouse.gold.sales_txn")

Jeśli chcesz wyodrębnić ważność cech przy użyciu scikit-learn i zapisać ją bezpośrednio w MLflow, skorzystaj z tego podejścia:

import pandas as pd
fi = pd.Series(clf.feature_importances_, index=feature_cols).sort_values(ascending=False)
mlflow.log_artifact(fi.head(30).to_frame("importance").to_csv("fi.csv", index=True))

Aby obliczyć Population Stability Index (PSI) do wykrywania dryfu:

import numpy as np
def psi(expected, actual, bins=10):
    e, b = np.histogram(expected, bins=bins, range=(np.min(expected), np.max(expected)))
    a, _ = np.histogram(actual,   bins=b,     range=(np.min(expected), np.max(expected)))
    e = np.clip(e / e.sum(), 1e-6, None); a = np.clip(a / a.sum(), 1e-6, None)
    return np.sum((a - e) * np.log(a / e))

Jeśli chcesz, podaj nazwy swoich bieżących tabel w Lakehouse oraz docelowy przypadek użycia, taki jak rezygnacja klientów (churn), scoring leadów czy prognozowanie popytu, w komentarzu lub napisz do mnie bezpośrednio. Opracuję minimalny zestaw cech, wybór bazowego modelu oraz dokładne połączenie wsadowe lub czasu rzeczywistego, abyś szybko mógł wdrożyć pierwsze rozwiązanie w Microsoft Fabric!