Architektura danych: od cyklu życia po decyzje technologiczne
W Inżynieria danych i architektura łatwo zauważyć jedno: tu nie chodzi o ,,magiczne narzędzie", tylko o sensowny układ klocków w czasie. Raz będzie to planowanie przepływu danych (generowanie, pozyskiwanie, orkiestracja, transformacje), innym razem świadome dobranie sposobu składowania i zasad dostępu, bo w praktyce to właśnie te wybory bolą najbardziej, kiedy system rośnie. I tak, czasem trzeba też przebić się przez marketingowy szum, żeby nie przepłacić za źle dopasowaną platformę.
Dobrym przykładem takiego spojrzenia jest książka Joe Reis i Matta Housley'ego Inżynieria danych w praktyce. Kluczowe koncepcje i najlepsze technologie, która prowadzi przez cykl życia inżynierii danych i pomaga łączyć technologie (często chmurowe) z realnymi potrzebami odbiorców danych ,,na dole" strumienia.
Przetwarzanie rozproszone i duże zbiory: Hadoop w roboczym rytmie
Gdy w grę wchodzą duże wolumeny, pojawiają się tematy, których nie da się obejść: klastry, awarie, planowanie zasobów, formaty danych i koszty transferu. W takich sytuacjach liczy się praktyczny opis mechanizmów: co dzieje się w HDFS, jak działa YARN, gdzie pasuje MapReduce, a gdzie lepiej sprawdzają się narzędzia wyższego poziomu. To wiedza przydatna nie tylko ,,dla adminów" -- także dla osób, które projektują przetwarzanie i muszą rozumieć konsekwencje architektury.
Właśnie dlatego w tej kategorii dobrze wybrzmiewa perspektywa Toma White'a w książce Hadoop. Komplety przewodnik. Analiza i przechowywanie danych: od budowy klastra i zarządzania platformą po współdziałanie z narzędziami takimi jak Spark czy Hive, włączając temat formatów typu Avro i Parquet.
Hurtownie danych i praca z informacją o kliencie
Są też projekty, w których punktem ciężkości jest hurtownia danych i sposób, w jaki zasila decyzje biznesowe -- na przykład w obszarze CRM, kampanii czy personalizacji. Tu przydaje się bardziej ,,projektowe" podejście: jak przejść od problemów i wymagań do modelu koncepcyjnego, jak ogarnąć zmiany w danych, a potem dopilnować wydajności i jakości na etapie wdrożenia (z backupami i kontrolą poprawności włącznie). Trochę teorii jest potrzebne, ale najczęściej wygrywa porządna metodyka, bo bez niej nawet najlepsza baza nie uratuje projektu.
Takie spojrzenie daje książka Chrisa Todmana Projektowanie hurtowni danych. Wspomaganie zarządzania relacjami z klientami, która prowadzi od zagadnień związanych z relacjami z klientem do modelowania i implementacji, z naciskiem na praktyczne problemy (czas, wydajność, jakość danych).
Ścieżek rozwoju jest tu zresztą sporo: od data engineera budującego pipeline'y, przez architekta danych porządkującego warstwy systemu, po osoby bliższe platformom i klastrom albo hurtowniom i analityce biznesowej -- a te role często się przenikają, zależnie od firmy i skali danych.
Jeśli na co dzień kręcą Cię też bazy dokumentowe, zerknij przy okazji na podkategorię MongoDB w helion.pl i porównaj, jak inne modele danych wpływają na projekt architektury.
