Jak zbudować skalowalną i opłacalną platformę danych typu Lakehouse

W ciągu ostatniej dekady przeszliśmy od sztywnych hurtowni danych do elastycznych jezior danych, a ostatnio do architektur lakehouse, które obiecują połączyć to, co najlepsze z obu światów.

Jednak przejście z jednej generacji platform danych do następnej okazuje się trudniejsze niż oczekiwano. Ci, którzy już znajdują się w tej podróży, odkrywają wyzwania i powtarzają błędy, przenosząc stare wzorce projektowe do nowych systemów.

Pomagając wielu organizacjom projektować i skalować nowoczesne platformy danych, zauważyłem, że sukces zależy nie od narzędzi, ale od dyscypliny. Ten artykuł jest praktycznym przewodnikiem, jak przeprowadzić transformację skutecznie, czego unikać i jak przełożyć wybory techniczne na mierzalną wartość biznesową.

Dlaczego czysta historia Big Data nie jest już użyteczna

Patrząc wstecz, ruch big data rozpoczął się od marzenia o nieograniczonym przechowywaniu danych i niekończących się eksperymentach. Około połowy lat 2010. firmy zaczęły zbierać każdy możliwy log, kliknięcie i transakcję, przekonane, że sama objętość przyniesie wgląd. W praktyce to przekonanie stworzyło tylko większą złożoność. Jeziora danych pojawiły się jako modny następca hurtowni, ale większość z nich wkrótce stała się bagnem danych, miejscami, gdzie informacje wchodziły łatwo, ale rzadko wracały w użytecznej formie.

Do 2022 roku branża dojrzała, a pytania zaczęły się zmieniać. Zespoły nie pytają już, ile danych mogą przechowywać, ale jak mogą ufać i wykorzystywać to, co już mają. Prawdziwym wyzwaniem dzisiaj nie jest pojemność, ale zarządzanie, nie pozyskiwanie, ale interpretacja.

Kluczowa lekcja jest prosta. Zbieranie większej ilości danych nie czyni firmy zorientowaną na dane. Naprawdę liczy się zrozumienie danych, utrzymywanie odpowiedniego zarządzania i efektywne ich wykorzystanie.

Zalecam definiowanie własności dla każdego zbioru danych, ustalanie jasnych zasad retencji i jakości oraz skupianie wysiłków inżynieryjnych na danych, które bezpośrednio wspierają decyzje biznesowe. Bez tego fundamentu nawet najbardziej zaawansowany lakehouse w końcu zamienia się w nowoczesne bagno.

Lakehouse jako punkt zwrotny

Wzrost popularności lakehouse odzwierciedla dokładnie tę zmianę. Zamiast wybierać między wydajnością a elastycznością, model lakehouse łączy obie cechy. W swojej istocie wykorzystuje niedrogie przechowywanie w chmurze w formatach takich jak Delta lub Iceberg, wzbogacone o metadane i gwarancje transakcyjne. Rezultatem jest system, który kosztuje tak mało jak jezioro i zachowuje się jak hurtownia podczas odpytywania.

Jest to ważne dla liderów biznesowych, ponieważ usuwa stały kompromis między tanim przechowywaniem danych historycznych a kosztownymi systemami do analityki na żywo. Zawsze sugeruję pozycjonowanie lakehouse nie jako zamiennika wszystkiego innego, ale jako wspólnego fundamentu, który umożliwia zarówno tradycyjną analitykę, jak i uczenie maszynowe w jednym środowisku.

W lakehouse to samo środowisko może obsługiwać pulpit dla dyrektora finansowego, model uczenia maszynowego przewidujący zachowanie klientów oraz zapytanie ad hoc od analityka produktu. Dane nie są już powielane w różnych systemach, co upraszcza zarządzanie i pozwala na naturalną optymalizację kosztów.

Wyzwania strukturalne i zarządcze w adopcji Data Lakehouse

Kiedy firmy przechodzą z klasycznych hurtowni danych lub jezior danych do bardziej elastycznej architektury lakehouse, transformacja rzadko przebiega gładko. Wiele zespołów kopiuje istniejące struktury ze starej hurtowni do nowego środowiska bez przemyślenia ich celu. Rezultatem jest pojawienie się silosów danych, innymi słowy, fragmentacji. Jedna wersja danych znajduje się w hurtowni, inna w jeziorze, a trzecia gdzieś pomiędzy. Unikaj tego, przeprojektowując schematy dla lakehouse od podstaw. Modeluj dane na podstawie wzorców dostępu i potrzeb konsumentów, a nie zgodnie z przestarzałą logiką hurtowni.

Kolejnym powtarzającym się problemem jest normalizacja. Co przez to rozumiem? Hurtownie są zbudowane na ścisłych, głęboko znormalizowanych strukturach z dziesiątkami połączonych tabel. Kiedy są one kopiowane bezpośrednio do jeziora, każde zapytanie wymaga lasu złączeń. Wydajność załamuje się, inżynierowie obwiniają infrastrukturę, a projekt traci wiarygodność. Zamiast tego, denormalizuj tam, gdzie pomaga to wydajności i umieszczaj powiązane encje bliżej siebie, aby zminimalizować przetasowanie. Traktuj projektowanie wydajności jako część modelowania danych, a nie późniejszą optymalizację.

Zarządzanie i kontrola są kluczowe. W jeziorze danych często jest niewielki nadzór, ponieważ zespoły pracują bezpośrednio z plikami. W hurtowni obowiązują surowe zasady, takie jak bezpieczeństwo na poziomie wierszy, dostęp oparty na rolach i szczegółowe ścieżki audytu. Lakehouse musi znaleźć równowagę, zapewniając otwartość bez utraty odpowiedzialności. Powinieneś wdrożyć dostęp oparty na rolach i śledzenie pochodzenia od samego początku. Zarządzanie działa najlepiej, gdy rośnie razem z platformą i staje się fundamentem zaufania.

Wydajność również zależy od inteligentnego projektu. Tradycyjne hurtownie polegają na automatycznym indeksowaniu, ale w lakehouse efektywność pochodzi z partycjonowania lub płynnego klastrowania, buforowania i wyboru odpowiednich formatów plików do analityki. Zalecam traktowanie strategii partycjonowania i układu plików jako obywateli pierwszej kategorii w architekturze.

Optymalizacja kosztów to kolejna kluczowa obietnica lakehouse, ale nie następuje automatycznie. Podczas gdy przechowywanie w chmurze jest niedrogie, a analityka może skalować się w górę lub w dół według potrzeb, te korzyści są często niwelowane przez słabe projektowanie danych i niekontrolowany wzrost. Musisz aktywnie zarządzać cyklami życia zbiorów danych i usuwać nieużywane kopie. Jeśli proces ten zostanie zignorowany, koszty chmury będą cicho rosnąć z czasem.

Optymalizacja kosztów jako zasada numer jeden

Chciałbym skupić się bardziej szczegółowo na optymalizacji kosztów, ponieważ jest to jedna z kluczowych zalet architektury lakehouse.

Jednym z kluczowych sposobów, w jaki architektura lakehouse redukuje koszty, jest minimalizowanie przetasowania, czyli przemieszczania danych między systemami lub węzłami przetwarzania. Aby to osiągnąć, zawsze projektuj swoje dane tak, aby powiązane encje były przechowywane razem.

Przechowując wszystkie dane w jednym miejscu i przechowując powiązane encje blisko siebie, lakehouse usuwa potrzebę nadmiernych złączeń i transferów danych. Kiedy wykonujemy analitykę, na przykład budując model uczenia maszynowego do analizy klientów, możemy używać zarówno danych historycznych, jak i rzeczywistych danych transakcyjnych bez kopiowania lub przenoszenia ich między systemami.

Inną kluczową zasadą umożliwiającą optymalizację kosztów jest rozdzielenie przechowywania i przetwarzania. Przechowywanie danych i przetwarzanie danych skalują się niezależnie na podstawie rzeczywistego zapotrzebowania. Płacimy tylko za zasoby, których używamy, zamiast utrzymywać duże systemy o stałej pojemności. Przechowywanie pozostaje niedrogie i skalowalne, a moc obliczeniowa może być zwiększana lub zmniejszana w razie potrzeby. Ta elastyczność prowadzi do niższych kosztów infrastruktury i bardziej efektywnych operacji na danych. Zawsze zacznij od małych rozmiarów i pozwól automatycznemu skalowaniu wykonać swoją pracę. Monitoruj użycie i zrozum wzorce obciążenia przed zobowiązaniem się do zarezerwowanej pojemności.

Klastry z automatycznym skalowaniem dodatkowo pomagają kontrolować koszty. Obciążenie uczenia maszynowego wymaga zasobów obliczeniowych w chmurze, maszyn wirtualnych z pamięcią i mocą obliczeniową podobną do zwykłego komputera. W przeszłości firmy kupowały lub wynajmowały fizyczne serwery z wyprzedzeniem i uruchamiały procesy na tej stałej pojemności. W chmurze płacimy za moc obliczeniową na podstawie rzeczywistego użycia, za jednostkę czasu i za ilość zasobów. Zdecydowanie zalecam rozpoczęcie od minimalnych rozmiarów klastra, obserwowanie zachowania skalowania i ustawianie górnych limitów, aby zapobiec niekontrolowanym kosztom.

Wybór odpowiedniego podejścia architektonicznego

Porozmawiajmy o architekturze lakehouse. Pod wieloma względami jej projekt zależy od tego, jak strukturyzujemy model danych. Najbardziej powszechnym i efektywnym podejściem jest architektura warstwowa lub medalionowa, gdzie każda warstwa służy określonemu celowi i obsługuje różne typy użytkowników i obciążeń.

— Pierwsza warstwa, często nazywana surową lub brązową, jest bezpośrednią kopią danych źródłowych. Służy głównie potrzebom technicznym i jest przechowywana tylko przez krótki okres, aby umożliwić szybkie przetwarzanie w razie potrzeby. Powinna być traktowana jako tymczasowe przechowywanie.

— Druga warstwa, czyli warstwa normalizacji, zawiera wyczyszczone i ustrukturyzowane dane, czasami połączone z innymi tabelami, takimi jak użytkownicy i zamówienia. To tutaj często są trenowane modele uczenia maszynowego. Najlepszą praktyką jest automatyzacja walidacji danych i egzekwowania schematu na tym etapie. Utrzymanie spójności jest bardziej wartościowe niż przetwarzanie dużych ilości danych.

— Ostatnia warstwa, znana jako warstwa złota, to miejsce, gdzie znajdują się zagregowane dane. Pulpity nawigacyjne i narzędzia BI, takie jak Tableau lub Power BI, zazwyczaj łączą się z tą warstwą, aby uzyskać dostęp do gotowych metryk i wizualizacji. Jednak nie wszystko można wstępnie obliczyć.

Każda warstwa ma swój cel, a razem umożliwiają zarówno uczenie maszynowe, jak i business intelligence prosperować.

Powinieneś dostosować swoją strategię warstwową do wzorców konsumpcji. Data scientists zazwyczaj pracują z warstwą srebrną, a kadra kierownicza oczekuje odpowiedzi z warstwy złotej. Elastyczność jest prawdziwą siłą lakehouse, zdolnością do obsługi wielu odbiorców bez budowania i utrzymywania wielu oddzielnych systemów.

Spostrzeżenia z praktyki

Gdybym projektował od podstaw, zrobiłbym kilka rzeczy inaczej niż to, jak branża podchodziła do danych w przeszłości.

Poniżej znajdują się lekcje, których nauczyłem się z rzeczywistych wdrożeń i to, co teraz zalecam.

1. Zacznij od małego, dostarczaj szybko

Migrowanie wszystkiego na raz nie zawsze jest optymalne. Firmy często próbują przenieść terabajty danych do nowego systemu, tylko po to, by odkryć, że nikt ich nie używa. Lepszą ścieżką jest rozpoczęcie od pojedynczego przypadku użycia, który dostarcza wyraźną wartość biznesową, takiego jak silnik rekomendacji, dynamiczne ceny lub model retencji klientów. Sukces w tym obszarze zapewnia zarówno wiarygodność, jak i wzór do skalowania.

1. Tłumacz wymagania biznesowe wcześnie

Tłumaczyłbym wymagania biznesowe na techniczne tak wcześnie, jak to możliwe. Jeśli raport musi filtrować według regionu, to wymaganie implikuje partycjonowanie według regionu na poziomie przechowywania. Jeśli analitycy oczekują aktualizacji w czasie prawie rzeczywistym, to kieruje decyzjami dotyczącymi indeksowania lub buforowania. Bez tego tłumaczenia technologia odchodzi od celów biznesowych, a zaufanie maleje.

1. Dopasuj technologię do możliwości organizacyjnych

Zawsze dopasowywałbym technologię do możliwości organizacji. Firma z silną kulturą inżynieryjną może preferować komponenty open source i maksymalną kontrolę. Biznes z ograniczonymi zasobami technicznymi może być lepiej obsługiwany przez zarządzane usługi, które udostępniają interfejsy SQL analitykom. Nie ma uniwersalnego rozwiązania, liczy się dopasowanie ambicji do możliwości.

Na koniec, zakwestionowałbym założenie, że lakehouse to po prostu lepsze jezioro. W rzeczywistości jest to inny paradygmat. Dziedziczy niektóre cechy zarówno jezior, jak i hurtowni, ale nie jest zamiennikiem dla każdego przypadku użycia. Obciążenia transakcyjne o wysokiej częstotliwości, na przykład, mogą nadal wymagać wyspecjalizowanych systemów. Rozpoznanie tych granic zapobiega rozczarowaniu i zapewnia, że lakehouse jest używany tam, gdzie naprawdę się wyróżnia.