Data lake w Fabric: jak przygotować dane do analityki i AI

Data lake ma sens wtedy, gdy firma potrzebuje zachować różne rodzaje danych i przygotowywać je do kilku zastosowań: raportowania, analizy, uczenia maszynowego czy pracy agentów. Samo przeniesienie plików do wspólnego miejsca nie tworzy jednak gotowej podstawy dla AI. Potrzebne są opis, właściciel, kontrola jakości oraz zasady korzystania z danych.

W Microsoft Fabric tę warstwę przechowywania zapewnia OneLake, a lakehouse łączy pracę z plikami i tabelami. Wybór architektury warto zacząć od konkretnego przepływu: skąd dane pochodzą, jakie przekształcenia przechodzą i kto ma wykorzystać wynik. Rozmiar zbioru jest ważny, ale nie wystarcza do podjęcia decyzji.

Data lake, lakehouse i OneLake

Data lake to podejście do przechowywania danych w różnych formatach, również przed ich pełnym uporządkowaniem do analizy. Mogą to być pliki z systemów, dokumenty, dane zdarzeń i tabele. Elastyczność jest zaletą, jeżeli towarzyszy jej możliwość ustalenia znaczenia oraz pochodzenia zbioru.

OneLake jest wspólnym logicznym jeziorem danych organizacji w Fabric. Microsoft opisuje je jako usługę opartą na Azure Data Lake Storage Gen2, zintegrowaną z elementami platformy. Szczegóły znajdują się w przeglądzie OneLake.

Lakehouse jest elementem Fabric umożliwiającym organizowanie plików i tabel oraz ich przetwarzanie. Udostępnia także punkt końcowy analityki SQL do odczytu obsługiwanych tabel. Nie oznacza to, że dowolny plik CSV po przesłaniu automatycznie staje się poprawnym modelem analitycznym. Zakres opisuje dokumentacja lakehouse w Fabric.

Te pojęcia dotyczą różnych poziomów projektu. OneLake określa wspólną warstwę przechowywania, lakehouse sposób organizacji i pracy z zasobami, a model biznesowy nadaje danym znaczenie. Możesz mieć dobrze działającą platformę i nadal nie umieć odpowiedzieć, która tabela zawiera obowiązującą definicję klienta.

Kiedy takie podejście pomaga

Data lake jest użyteczny, gdy te same dane mają zasilać różne analizy albo gdy trzeba zachować materiał źródłowy do ponownego przetworzenia. Przykładem jest połączenie historii zamówień z opisami reklamacji i danymi o realizacji usług. Nie wszystkie te informacje pasują od razu do jednej tabeli raportowej.

Nie zakładaj jednak, że każdy raport wymaga budowania jeziora danych. Dla niewielkiego, stabilnego zestawienia opartego na jednym źródle dodatkowe warstwy mogą zwiększyć koszt i liczbę miejsc awarii. Uzasadnij każdy element potrzebą: odtwarzalnością, integracją, skalą albo ponownym użyciem danych.

Potrzeba	Dlaczego data lake może pomóc	Co trzeba zaprojektować
Zachowanie surowych eksportów	Możliwość ponownego przetworzenia	Wersjonowanie i okres przechowywania
Łączenie plików i tabel	Wspólna organizacja zasobów	Identyfikatory i relacje między zbiorami
Przygotowanie danych dla modeli	Dostęp do historii i różnych cech	Oddzielenie danych treningowych i oceny
Udostępnianie wielu zespołom	Ponowne wykorzystanie zbiorów	Uprawnienia, właściciel i opis jakości

Decyzję podejmuj na podstawie jednego reprezentatywnego zastosowania. Jeżeli projekt uzasadnia się wyłącznie możliwością wykorzystania danych „kiedyś”, trudno ustalić zakres, budżet i kryterium zakończenia pierwszego etapu.

Uporządkuj drogę od źródła do wyniku

Praktyczny projekt rozdziela dane otrzymane ze źródła, dane uporządkowane oraz dane przygotowane do konkretnego użycia. Nazwy warstw są mniej istotne niż ich zadania. Użytkownik powinien wiedzieć, czy ogląda oryginalny eksport, wynik czyszczenia czy zatwierdzony zestaw do raportowania.

W warstwie źródłowej zachowaj informacje potrzebne do odtworzenia pobrania: system, czas, zakres i identyfikator partii. Jeżeli źródło nadpisuje plik pod tą samą nazwą, sama ścieżka nie identyfikuje wersji danych. Bez dodatkowego oznaczenia później trudno wyjaśnić, dlaczego ponowne uruchomienie dało inny wynik.

Podczas porządkowania ustal typy, strefy czasowe, jednostki i zasady rozpoznawania duplikatów. Nie usuwaj problematycznych rekordów bez śladu. Osobna informacja o odrzuconych danych pozwala właścicielowi źródła naprawić przyczynę i ocenić wpływ braków na analizę.

W warstwie przeznaczonej do użycia zdefiniuj miary i zakres odpowiedzialności. Zespół analizujący sprzedaż powinien otrzymać opis tego, co oznacza rekord i które dokumenty są uwzględnione. Tabela o nazwie „sales_final_v3” bez takich informacji nie jest wiarygodnym produktem danych.

Kontrakt danych zamiast domysłów

Kontrakt to uzgodnienie między osobą dostarczającą zbiór a osobą, która go wykorzystuje. Powinien opisywać strukturę, znaczenie najważniejszych pól, częstotliwość aktualizacji i sposób informowania o zmianach. Nie musi być długim dokumentem, aby spełniać tę funkcję.

Dla zamówień zapisz, czy jeden wiersz oznacza całe zamówienie, pozycję czy zmianę statusu. Ustal, czy kwota zawiera podatek, jaka waluta obowiązuje i jak traktowane są anulowania. To pytania, które bezpośrednio wpływają na wynik, niezależnie od wybranej platformy.

Kontrakt powinien obejmować także zachowanie po błędzie. Czy spóźnione dane zatrzymują raport, czy raport pokazuje ostatni kompletny stan? Kto otrzymuje zgłoszenie i kto decyduje o publikacji częściowego wyniku? Brak takich ustaleń zmienia awarię techniczną w spór o odpowiedzialność.

Przy zmianie schematu określ okres przejściowy i listę odbiorców. Dodanie pola zwykle ma inny wpływ niż zmiana znaczenia istniejącego statusu. Sama zgodność nazw kolumn nie dowodzi, że wcześniejsze analizy nadal działają poprawnie.

Przykład kontroli kompletności

Syntetyczny przykład: źródło przekazuje 10 000 rekordów zamówień. Kontrola wykrywa 200 duplikatów i 300 innych rekordów bez identyfikatora klienta. Zakładamy rozłączne grupy błędów. Do analizy wymagającej unikalnego zamówienia i znanego klienta trafia 9500 rekordów.

Udział rekordów spełniających te dwa warunki wynosi 95%. Nie jest to ogólny wskaźnik jakości całego zbioru. Nie sprawdziliśmy jeszcze poprawności kwot, dat ani kompletności pozycji. Komunikat „jakość 95%” bez wskazania kryteriów mógłby więc wprowadzać odbiorcę w błąd.

Zapisz liczbę rekordów na każdym etapie i przyczynę odrzucenia. Gdy po poprawie źródła uruchomisz przetwarzanie ponownie, sprawdź, czy wcześniej zaakceptowane rekordy nie zostały podwojone. Odtwarzalność oznacza kontrolowany wynik kolejnego uruchomienia, a nie tylko możliwość ponownego kliknięcia przycisku.

W analizie finansowej porównaj także sumy kwot, bo liczba wierszy może pozostać poprawna mimo błędnego przypisania wartości. Dla danych zdarzeń potrzebna będzie kontrola zakresu czasu. Wybierz miary jakości odpowiadające temu, jak zbiór ma być wykorzystany.

Dane dla AI wymagają dodatkowych ustaleń

Jeżeli przygotowujesz dane do modelu predykcyjnego, ustal moment, w którym informacja była dostępna. Pole dopisane po zakończeniu sprawy nie powinno udawać cechy znanej w chwili podejmowania decyzji. Taki błąd może dać bardzo dobry wynik testu i słabe działanie po uruchomieniu.

Rozdziel dane używane do uczenia od danych oceny zgodnie z charakterem problemu. Przy procesie zmieniającym się w czasie ważna jest próba na późniejszym okresie. Przy powtarzających się klientach sprawdź, czy sposób podziału nie pozwala modelowi rozpoznawać tych samych przypadków zamiast uczyć się użytecznej zależności.

Dla agenta korzystającego z dokumentów liczą się wersja, właściciel i zakres obowiązywania tekstu. Jezioro zawierające zarówno aktualne procedury, jak i nieoznaczone kopie archiwalne nie jest gotową bazą wiedzy. Trzeba określić, które dokumenty wolno wykorzystać do odpowiedzi i jak aktualizować ich reprezentację w systemie wyszukiwania.

Nie kopiuj wszystkich dostępnych danych do każdego zastosowania. Wybierz zakres niezbędny do zadania oraz sprawdź, kto będzie widzieć wynik. Łączenie zbiorów może ujawnić informacje, które w pojedynczych źródłach były mniej oczywiste. Ocena dostępu powinna obejmować również dane po przekształceniu.

Jak zaplanować utrzymanie

Obszar	Minimalna kontrola	Reakcja na problem
Zasilanie	Ostatnia kompletna partia i zakres czasu	Powiadomienie właściciela oraz oznaczenie nieaktualności
Jakość	Kryteria wymagane przez odbiorców	Zatrzymanie lub jawne ograniczenie publikacji
Dostęp	Próby z rolami użytkowników	Korekta uprawnień i sprawdzenie dalszych ścieżek
Koszt	Zużycie według procesu i okresu	Przegląd harmonogramu, zakresu i nieudanych prób
Zmiana	Wersja schematu i transformacji	Test zgodności przed udostępnieniem

Koszt obejmuje przechowywanie, przetwarzanie i pracę zespołu. Duplikowanie plików „na wszelki wypadek” może zwiększać zarówno rachunek, jak i trudność odnalezienia właściwej wersji. Z drugiej strony usunięcie materiału źródłowego bez analizy może uniemożliwić odtworzenie wyniku. Okres przechowywania powinien mieć uzasadnienie w potrzebie oraz zasadach firmy.

Monitoruj również zadania, które stale kończą się błędem i są automatycznie ponawiane. Mogą zużywać zasoby bez dostarczenia wartościowego zbioru. Właściciel procesu powinien widzieć różnicę między poprawnie zakończoną pracą a aktywnością techniczną.

Jak ocenić pierwszy etap projektu

Wybierz jeden zbiór, dwóch odbiorców i określony zakres historii. Ustal oczekiwany rezultat, a potem wykonaj pełną drogę od pobrania do użycia. Próba powinna obejmować korektę danych, opóźnioną partię i zmianę dostępu, nie tylko poprawny import.

Poproś drugą osobę o odtworzenie wyniku na podstawie dokumentacji. Jeśli potrzebuje ustnych wyjaśnień autora przy każdym kroku, projekt pozostaje zależny od jednej osoby. Uzupełnij opis i sprawdź zastępstwo przed dodaniem kolejnych źródeł.

Na koniec porównaj nową ścieżkę z obecną: czas przygotowania danych, liczbę ręcznych korekt i możliwość wyjaśnienia wyniku. Nie ograniczaj odbioru do liczby załadowanych gigabajtów. Wartość pojawia się w użytecznym, wiarygodnym zbiorze, który zespół potrafi utrzymać.

Kiedy wstrzymać rozbudowę

Jeżeli nikt nie korzysta z przygotowanego zbioru, najpierw sprawdź przyczynę. Być może brakuje opisu, dostępu albo odpowiedniej częstotliwości aktualizacji. Dodawanie kolejnych źródeł nie rozwiąże tych problemów i może tylko zwiększyć koszt utrzymania.

Wstrzymaj rozszerzenie również wtedy, gdy nie potrafisz wyjaśnić różnic między źródłem a wynikiem. Odbiorca powinien widzieć, które rekordy zostały odrzucone i dlaczego. Bez tej informacji trudno zaufać danym używanym później przez raport lub model AI.

Osobną przesłanką jest brak właściciela. Jeśli projekt kończy się przekazaniem folderu bez osoby odpowiedzialnej za aktualizację, warto najpierw uzgodnić utrzymanie. Dopiero wtedy zwiększaj zakres. Dzięki temu kolejne zastosowania korzystają z działającej podstawy, a nie z rosnącego archiwum porzuconych plików.

Przed wycofaniem zbioru sprawdź jego zależności. Raport używany raz w miesiącu może nie pojawić się w krótkim przeglądzie aktywności, a nadal być potrzebny przy zamknięciu okresu. Uzgodnij termin usunięcia z odbiorcami i zachowaj informację, czym zastąpiono dotychczasowe źródło.

Od czego zacząć

Zapisz źródło, odbiorcę, wymagany czas aktualności i trzy najważniejsze kontrole jakości. Dodaj regułę korekty oraz osobę, która zatwierdzi wynik. Taki opis jest dobrym wejściem do rozmowy o architekturze Fabric.

Szczegóły wspólnej warstwy przechowywania znajdziesz w artykule co to jest OneLake w Microsoft Fabric. Powiąż projekt z systemem wdrażania AI w firmie, aby zakres danych wynikał z decyzji i procesów, które chcesz usprawnić. Rozbudowuj jezioro wtedy, gdy kolejny zbiór ma odbiorcę, cel i warunki odbioru.