Big Data to jedno z tych pojęć, które wszyscy znamy, ale każdy rozumie trochę inaczej. Dla jednych to po prostu „bardzo duże tabelki”, dla innych infrastruktura, klastry, chmura i rachunki idące w dziesiątki tysięcy dolarów miesięcznie. Chciałem ten temat rozbroić od środka. Bez haseł motywacyjnych, bez list „10 technologii, które musisz znać”.
Do rozmowy zaprosiłem Marka Czumę, człowieka, który od lat siedzi w świecie inżynierii danych, prowadzi Akademię Big Data i podcast Big Data po polsku. Rozmawialiśmy o tym, czy danych nie jest już za dużo, gdzie kończy się skalowanie, jak naprawdę wygląda praca inżyniera danych i dlaczego AI raczej nie zabierze nam pracy, przynajmniej nie tak szybko, jak lubią to przedstawiać nagłówki.
Czy danych jest już za dużo
Coraz częściej słyszymy porównanie, iż dane są nową ropą. Napędzają gospodarkę, firmy i całe modele biznesowe. Ale ropa kiedyś się kończy, a danych przybywa wykładniczo. Zadałem więc Markowi proste pytanie: czy grozi nam paraliż? Czy jest moment, w którym po prostu nie będziemy w stanie tego wszystkiego ogarnąć?
Odpowiedź była brutalnie szczera. Ten paraliż już istnieje. I to właśnie dlatego w ogóle powstała branża Big Data. Nie po to, żeby cieszyć się ilością danych, tylko żeby z ogromnego śmietnika informacji wyłuskać to, co faktycznie ma wartość.
W praktyce problem nie polega na tym, iż dane istnieją. Problem polega na tym, iż dane trzeba:
- zebrać,
- zapisać,
- przetworzyć,
- przesiać,
- zinterpretować.
A każda z tych rzeczy generuje kolejne problemy techniczne.
„Kupmy więcej serwerów” to za mało
Z perspektywy analityka bardzo łatwo wpaść w myślenie: coś działa wolno, to dołóżmy serwerów. Przecież mamy chmurę, AWS, Azure, Google. Pieniądze rozwiązują problem.
I to jest prawda. Ale tylko częściowo.
Marek bardzo mocno podkreślił jedną rzecz: infrastruktura to nie wszystko. choćby najlepsze serwery nic nie dadzą, jeżeli architektura systemu jest zaprojektowana pod jedną maszynę. Klasyczne aplikacje działają lokalnie. Mają jeden dysk, jeden procesor, jedną pamięć RAM. Kiedy zaczyna brakować zasobów, dokładanie kolejnej maszyny nic nie zmienia, bo aplikacja nie potrafi z niej skorzystać.
Tu właśnie wchodzi świat przetwarzania rozproszonego.
Zostań analitykiem danych – dołącz do KajoDataSpace!
Najlepsza ścieżka do zawodu analityka danych. Dostęp do pełnych wersji kursów online z Excela, SQLa, PowerBI, Tableau i Pythona z certyfikatami!
🟨 Ekskluzywana ale pomagająca sobie społeczność.
🟩 Ponad 75 godzin materiałów video.
🟨 Spotkania LIVE co miesiąc.
🟩 Mój osobisty mentoring.
Przetwarzanie rozproszone, czyli jeden komputer złożony z wielu
W Big Data kluczowa jest umiejętność myślenia o wielu maszynach jak o jednym organizmie. Dane są rozłożone po klastrze. Obliczenia są rozdzielane. Całość działa tak, jakbyśmy mieli jeden gigantyczny komputer.
Klasycznym przykładem takiej technologii jest Apache Spark. Z punktu widzenia użytkownika piszesz logikę na swoim laptopie. Operujesz na kolumnach, filtrach, joinach. A potem ten sam kod uruchamia się na dziesiątkach albo setkach maszyn.
To właśnie ta abstrakcja sprawiła, iż Big Data w ogóle stało się możliwe do ogarnięcia przez ludzi, a nie tylko przez zespoły badawcze Google sprzed 20 lat.
Czy skalowanie ma sufit
Na pierwszy rzut oka mogłoby się wydawać, iż skalowanie nie ma granic. Brakuje mocy? Dodajemy node. Brakuje miejsca? Dorzucamy dysk. Problem solved.
W rzeczywistości sufitów jest kilka.
Pierwszy to sufit technologiczny. Każda technologia ma swoje ograniczenia architektoniczne. Przykładem jest HDFS z ekosystemu Hadoop, który świetnie działa do pewnego momentu, a potem zaczyna boleć.
Drugi sufit jest dużo bardziej przyziemny: zasoby naturalne. Krzem, energia, chłodzenie. Centra danych zużywają gigantyczne ilości prądu i wody. Nie bez powodu najwięksi gracze chmurowi inwestują we własne elektrownie.
Marek zwrócił uwagę na interesujący szczegół: Microsoft Azure publicznie pokazuje mapy regionów, gdzie obok data center powstają własne źródła energii. To nie jest science fiction. To dzieje się teraz.
Inżynier danych to programista. Kropka.
Jednym z ważniejszych momentów rozmowy było bardzo jasne postawienie sprawy: inżynier danych to stanowisko stricte programistyczne.
Nie „trochę programista, trochę analityk”. Programista z pełną odpowiedzialnością za kod, architekturę i systemy.
Co ciekawe, Marek zauważył coś, co często umyka w dyskusjach: wiele rzeczy, które analitycy uznają za „analityczne”, jak pisanie joinów czy optymalizacja zapytań, to czysta programistyka. Granice między rolami coraz bardziej się zacierają.
Różnica polega głównie na punkcie ciężkości:
- analityk częściej pracuje bliżej domeny biznesowej,
- inżynier danych bliżej infrastruktury i architektury.
Analityk vs programista. Dwie drogi do Big Data
Zapytałem Marka, jak wygląda ścieżka wejścia do inżynierii danych z dwóch stron: analityka i programisty.
Programista webowy ma, paradoksalnie, łatwiejszy start. Zna już:
- SQL,
- relacyjne bazy danych,
- podstawy systemów,
- Linuxa,
- sieci.
Analityk z kolei bardzo często świetnie zna SQL i dane, ale musi nadrobić programowanie i podstawy systemowe. Python jest tu naturalnym wyborem, bo jest popularny i szeroko wykorzystywany w Big Data.
W obu przypadkach najważniejsze są trzy fundamenty:
- SQL i bazy danych,
- programowanie,
- podstawy systemów i sieci.
Bez tego nie da się iść dalej.
AI i strach o przyszłość pracy
Ten wątek musiał się pojawić. Czy AI zabierze pracę inżynierom danych?
Marek podszedł do tego spokojnie. Nie neguje rozwoju technologii, ale nie kupuje wizji, w której za dwa lata 80 procent kodu pisze AI, a ludzie są zbędni.
Kluczowe pytanie brzmi: co to znaczy, iż AI „pisze kod”?
Bardziej realistyczny scenariusz to taki, w którym:
- programista wie, co chce zrobić,
- AI pomaga wygenerować szkic,
- człowiek odpowiada za logikę, jakość i konsekwencje.
To nie zabiera etatów. To zmienia sposób pracy.
Dodatkowo dochodzi ogromna inercja organizacyjna. Korporacje nie zmieniają się w pół roku. choćby jeżeli technologia jest gotowa, procesy, struktury i odpowiedzialność zmieniają się latami.
Jak wygląda naprawdę świetny inżynier danych
Bardzo lubię ten fragment rozmowy, bo nie dotyczy początkujących.
Świetny inżynier danych to nie ktoś, kto zna „najwięcej technologii”. To ktoś, kto:
- rozumie abstrakcję stojącą za frameworkami,
- wie, jak działa przetwarzanie rozproszone,
- potrafi zajrzeć pod maskę.
Marek bardzo krytycznie odniósł się do kursów uczących wyłącznie wywoływania funkcji. Dokumentację każdy może przeczytać. Prawdziwa wartość zaczyna się tam, gdzie rozumiesz, dlaczego coś działa tak, a nie inaczej.
To podejście pozwala:
- szybko przesiadać się między technologiami,
- optymalizować koszty,
- unikać drogich błędów w chmurze.
Optymalizacja, czyli tysiące dolarów jednym ustawieniem
Padł bardzo konkretny przykład z życia wzięty, oparty o ekosystem Databricks i chmurę Amazon Web Services.
System streamingowy działał poprawnie, ale generował ogromne koszty. Problemem nie była ilość danych, tylko sposób odpytywania storage’u. Każde listowanie plików, każde zapytanie kosztowało ułamki centów. W skali milionów operacji robiły się z tego tysiące dolarów tygodniowo.
Jedna zmiana w konfiguracji triggera potrafiła obniżyć koszty dramatycznie.
Tego nie da się zrobić, jeżeli nie rozumiesz, co dzieje się pod spodem.
Systemy, które robią wrażenie
Na koniec zeszliśmy na poziom inspiracji.
Pierwszym przykładem były Google Maps. Nie jako aplikacja w telefonie, ale jako gigantyczny system danych: mapy, ruch drogowy, Street View, predykcja czasu przejazdu.
Drugim, bardziej kontrowersyjnym, była National Security Agency i systemy masowego przetwarzania danych, które ujawnił Edward Snowden.
Odkładając na bok kwestie etyczne, to są technologiczne potwory, które pokazują, do jakiej skali da się dojść.
Zapisz się do
newslettera
🎁 i zgarnij darmowe bonusy:
Poradnik Początkującego Analityka
Video - jak szukać pracy w IT
Regularne dawki darmowej wiedzy, bez spamu
Dzięki! To nie koniec...
...pamiętaj, by teraz wejść na maila i potwierdzić subskrybcję 🙂 Jeżeli nic nie doszło, to sprawdź skrzynkę ze spamem.* * * Gdy potwierdzisz newsletter, dostaniesz ostateczne potwierdzenie i obiecane prezenty w kolejnym mailu 🙂
Zakończenie
Ta rozmowa utwierdziła mnie w jednym przekonaniu: Big Data to nie „większa analityka”. To zupełnie inny sposób myślenia o danych, systemach i odpowiedzialności.
Jeśli jesteś analitykiem i zaczyna cię ciągnąć w stronę inżynierii danych, to dobra wiadomość jest taka, iż część drogi masz już za sobą. Zła jest taka, iż reszta wymaga zmiany sposobu myślenia, a nie tylko nauki kolejnego narzędzia.
Jeśli ten tekst był dla ciebie wartościowy, udostępnij go dalej w swoich mediach społecznościowych. Być może komuś pomoże lepiej zrozumieć, czym naprawdę jest świat Big Data.
Autorem artykułu jest Kajo Rudziński – analytical data architect, uznany ekspert w analizie danych, twórca KajoData oraz społeczności dla analityków KajoDataSpace.
