Twój partner w świecie Big Data/AI – raporty, analizy, przemyślenia
Biznes
W tym miejscu przeczytasz wpisy związane z biznesem Big Data/AI. Co zrobić, aby pomóc w rozwoju firmy, jak wdrażać, jak projektować, jak rozwiązywać problemy projektowe i inne.
“Zwykłym rozporządzeniem planuje się w Polsce utworzenie gigantycznej bazy danych, łączącej informacje z prawie wszystkich możliwych rejestrów” pisze “Dziennik Gazeta Prawna”. Tytuł: “Orwell po polsku. Rząd pracuje nad megabazą. >>Potencjał do nadużyć<<“. W tym artykule opiszę jak taka “Megabaza” miałaby być zbudowana. W kolejnych – czy to dobry pomysł oraz… jak można by taki system zbudować. Zapraszam!
Czym miałaby być “megabaza”?
Żyjemy w świecie gospodarki cyfrowej. Nie tylko firmy, ale i administracja państwowa zbierają od nas dane. Te są bardziej lub mniej wrażliwe. W formie elektronicznej państwo ma więc dostęp do numeru dowodu osobistego, danych medycznych, informacji związanych ze stanem cywilnym i wielu, wielu innych. W tym momencie jednak istnieje ogromna liczba “małych” baz danych. Każda z nich odpowiada za inne informacje o nas i podlega innym jednostkom (np. jedne ministerstwu finansów, inne zdrowia itd.).
Rodzi to wiele problemów ze sprawnością funkcjonowania państwa oraz możliwościami wykorzystania danych, które ono posiada. Możemy intuicyjnie denerwować się, że w wielu miejscach podajemy te same dane, albo że jedna instytucja nie może funkcjonować sprawnie i skutecznie tylko dlatego, że nie ma dostępu do danych zgromadzonych przez inną. Trochę tak, jakby w małej firmie pomagającej w poprawie zdrowia rehabilitanci od kręgosłupa nie mieli dostępu do danych pacjentów od działu dietetyków.
Częściowo tego typu problemy ma zmienić planowana Megabaza (powinniśmy ująć w cudzysłów, ale nazwijmy już ją tak na potrzeby artykułu). Będzie ona spajać informacje z bardzo wielu państwowych miejsc w ramach jednego ogromnego centrum danych.
Czym NIE BĘDZIE Megabaza?
Warto jednak podkreślić, że planowana Megabaza nie będzie tym, o czym możemy w pierwszym momencie pomyśleć. Nie będzie miejscem szybkiego dostępu do połączonych danych każdego z nas. Możemy sobie wyobrazić sytuację, w której urzędnik ministerstwa finansów z ciekawości sprawdzi nie tylko dane firmy, w której będzie przeprowadzał kontrolę, ale i wyznanie, dane dotyczące dzieci i żony Prezesa owej firmy. Tego nie będzie.
Oto dlaczego. Megabaza nie będzie służyła do szybkiego przeglądania naszych danych. Będzie to raczej miejsce zbiorczego przechowywania informacji w celach analiz. Jak pisze portal DGP:
“Założenie jest takie, że dany podmiot publiczny zgłasza potrzebę przeprowadzenia konkretnych analiz. Minister cyfryzacji występuje do administratorów odpowiednich rejestrów, a ci przekazują mu dane po pseudonimizacji. W teorii po przeprowadzeniu analiz mają być one wykasowane. “
Czym różni się pseudonimizacja od anonimizacji?
Pada powyżej pojęcie “pseudonimizacji”. Podobnie brzmiąca jest również “anonimizacja”. Czym różnią się od siebie i dlaczego to istotne w tym kontekście? Sprawa jest bardzo prosta:
Anonimizacja to proces “ukrycia” danych w taki sposób, żeby nie dało się ich w żaden sposób poznać, ani do nich wrócić. Można anonimizować dane nie tylko przy pomocy nowoczesnych technik i technologii. “Analogowym” sposobem anonimizacji może być na przykład zakreślenie czarnym markerem nazwiska (a potem wykonanie kserokopii, aby zlikwidować prześwitywanie). Jeśli mówimy o cyfrowym zapisie, można usunąć konkretne dane, wylosować dowolny ciąg znaków lub – jeśli musimy zachować możliwość odwołania się do tych samych rekordów, można wykorzystać funkcję skrótu w określony sposób.
Pseudonimizacja – proces, który ma na celu to samo co anonimizacja, czyli ukrycie konkretnych danych (np. PESEL). Różni się jednak tą zasadniczą rzeczą, że pseudonimizację można odwrócić. Najbardziej popularnym sposobem jest po prostu szyfrowanie danych z kluczem tajnym (np. szyfrem AES). Dzięki temu, mając klucz, zawsze możemy dane odszyfrować.
Jedną z rzeczy które można spotkać szeroko w Internecie jest wymienienie funkcji skrótu jako metody pseudonimizacji. Być może się mylę (jeśli tak – nawróć mnie w komentarzu!), ale nie mogę się z tym zgodzić. Funkcje skrótu dążą do tego żeby nie dało się na podstawie konkretnego skrótu dotrzeć do pierwotnej wiadomości. Spełniają więc wymogi anonimizacji, nie pseudonimizacji. Oczywiście temat nie jest jednoznaczny i są określone warunki w których można by “odgadnąć” zahashowane wartości, ale sam mechanizm moim zdaniem jest anonimizacyjny.
W naszej Megabazie wyniki analiz mają być pseudonimizowane i w takiej formie wysyłane do zlecających analizę. To właśnie wzbudza pewne obawy ekspertów oraz aktywistów działających na rzecz przejrzystości działań władzy.
“Na dodatek nie wiem, jak wyglądać ma pseudonimizacja danych, która jest przecież procesem odwracalnym. Jeśli dane mają służyć do celów analitycznych, to oczywiste jest dla mnie, że powinny przechodzić proces pełnej anonimizacji “
Powyższy cytat pochodzi z wypowiedzi Wojciecha Klickiego z Fundacji Panoptykon. Tutaj wyjątkowo muszę się zgodzić. Chociaż fundacja Panoptykon jest organizacją kontrowersyjną, działającą wielokrotnie w sposób, który uważam za co najmniej niewłaściwy, w tym przypadku obawy są uzasadnione. Być może pseudonimizacja ma sens. Jeśli jednak tak jest, władze powinny dołożyć starań, aby to uzasadnić.
Z jakich źródeł będzie czerpać Megabaza?
Napisaliśmy już trochę na temat tego czym będzie a czym nie będzie Megabaza. Z jakich jednak dokładnie źródeł będzie korzystać? Poniżej lista instytucji:
Rejestr PESEL
Krajowa Ewidencja Podatników
Rejestr Stanu Cywilnego
Rejestr Dowodów Osobistych
Rejestr Ministra Właściwego do Spraw Pracy
Rejestr ZUS i KRUS
Rejestry dotyczące świadczeń rodzinnych czy osób uprawnionych do alimentów
Rejestry GUS
Rejestry NFZ
System informacji o ochronie zdrowia
Rejestry oświatowe
Podsumowanie
Słowem podsumowania: Rząd planuje zbudowanie wielkiej Megabazy, która będzie spajać wiele zbiorów dostępnych dla administracji. Warto podkreślić jednak, że nie będzie to baza, do której każdy urzędnik będzie miał szybki, swobodny dostęp. Będzie to repozytorium, które ma usprawnić państwową analitykę.
W tym artykule przyjrzeliśmy się pobieżnie temu czym ma być rządowa Megabaza i z jakich źródeł ma się składać. W kolejnym artykule opiszę obawy oraz szanse, które dałoby zbudowanie tego typu systemu. Na samym końcu – rozrysuję jak można takie repozytorium skonstruować.
UWAGA! Już niedługo ukaże się pierwszy polski ebook o Big Data. Całkowicie za darmo dla subskrybentów bloga RDF. Zapisując się na newsletter TERAZ – masz niepowtarzalną okazję dostawać kolejne wersje książki i zgłaszać swoje poprawki, a nawet stać się jednym z autorów. Więcej tutaj.
USA kojarzą nam się z potęgą zarówno technologiczną jak i militarną. Nie bez powodu. To tutaj zrodziła się branża Big Data. To ten kraj ma najpotężniejszą armię na świecie. Pytanie jednak, czy zawsze te dwie rzeczy idą w parze? Dziś poznamy jeden z przykładów tego jak Big Data i sztuczna inteligencja (AI) wykorzystywane są w amerykańskiej armii. Bierzmy więc kubek żołnierskiej czarnej kawy w dłoń i przejdźmy przez drugi odcinek z serii “Big Data na wojnie”!
Drony, dominacja USA i… absurdy rodem z parodii państwowości
Hegemonia zobowiązuje
USA to nie jest “normalny kraj”. Nie, nie mam na myśli tego, że to stan umysłu. Nie należy jednak porównywać jakiegokolwiek państwa do Amerykanów z jednego prostego powodu: Stany Zjednoczone rządzą światem. To imperium, które ustawiło pod siebie cały glob. Teraz co prawda ulega to pewnym zmianom, ale to rozmowa na inny artykuł. Na innym blogu;-).
Skutkuje to nie tylko profitami, ale i zobowiązaniami. Podstawowym zobowiązaniem jest to, że Amerykanie muszą militarnie “obstawiać” cały świat. Oznacza to nie tylko obecność sił zbrojnych na określonych terenach, ale także stały monitoring miejsc, w których Hegemon ma swoje interesy. W siłach zbrojnych Stanów Zjednoczonych służy ok. 1.3 mln żołnierzy nie licząc rezerwistów oraz Gwardii Narodowej (mniej więcej odpowiednik naszych Wojsko Obrony Terytorialnej). Każdy żołnierz kosztuje swoje i jego wyszkolenie oraz – co jasne – życie, jest na wagę złota.
Z tego powodu wojska amerykańskie od dłuższego czasu prowadzą wiele bardzo intensywnych prac badawczych (których skutkiem jest m.in. Internet) mających na celu rozwój nowoczesnych technologii czy robotyzację pola walki. Jednym ze skutków takich prac są drony. To samoloty bezzałogowe, które nie tylko są tańsze w produkcji od myśliwców i prostsze w użyciu. Co najważniejsze – pilot drona nie jest bezpośrednio narażony, siedzi w ciepłym i przyjemnym zakątku, sterując przez komputer swoją maszyną.
Monitoring najważniejszych miejsc na świecie
To właśnie drony są wykorzystywane do uderzenia z powietrza. Pełnią jednak także inną rolę – zwiadowczą. Dzięki nim można “podglądać” w bardzo solidnej jakości wiele miejsc na Ziemi. Poza stałym monitoringiem, zapisy z latających czujników stanowią znakomity materiał do analizy wstecznej. Jeśli dochodzi do jakiegoś ataku terrorystycznego czy podejrzanych ruchów, można bez problemu odszukać nagranie z tamtego momentu i przeanalizować minuta po minucie, sekunda po sekundzie.
Także Polska może pochwalić się sukcesami na rynku dronowym. Widoczny na zdjęciu FlyEye to polski samolot bezzałogowy służący celom zwiadowczym. Niezwykle popularny na wojnie za naszą wschodnią granicą – w służbie armii Ukraińskiej oczywiście.
Pentagon wydał dziesiątki miliardów dolarów na tego typu systemu obserwacji. Dzięki temu, jeśli ktokolwiek podłożył bombę, można po prostu przewinąć wideo do tyłu i sprawdzić kto to był, dokąd poszedł itd. Tego typu system obserwacji to fascynujący pomysł, dający gigantyczne możliwości analityczne. Skoro więc mamy całą flotę dronów uzbrojonych w czujniki, nadających do nas obrazy wideo, co jest oczywistym kolejnym krokiem? Warto wskazać, że pojedyncze drony z tego typu czujnikami gromadzą wiele terabajtów danych… dziennie.
W związku z powyższym nie będzie chyba zbyt kontrowersyjne stwierdzenie, że oczywistym jest zbudowanie systemu który tego typu dane kataloguje i automatycznie analizuje prawda?
Biurokratyczne absurdy także za oceanem
Otóż, jak się okazuje – niekoniecznie. Żaden inteligentny system nie powstał. Co prawda był pewien storage, w którym umieszczano nagrane wideo. Znakomita większość jednak… nigdy nie była przeanalizowana. Jak to się mogło stać? Otóż, rozwiązaniem według DoD (Departamentu Obrony – ang. Department of Defense)wcale nie było zbudowanie inteligentnego systemu analitycznego, ale… utworzenie odpowiednio dużego sztabu ludzi. Ludzi, którzy siedzieli przez 24h na dobę (praca zmianowa), patrzyli w ekran i… liczyli. Liczyli auta, ludzi, budynki itd. Następnie sprawnie tego typu dane przepisywali do… excela lub powerpointa i wysyłali dalej.
Brzmi absurdalnie? Takie właśnie jest! I dzieje się to w Stanach Zjednoczonych Ameryki. Nie w małej firmie pod Białymstokiem, ale w najpotężniejszym kraju na świecie, o ugruntowanej państwowości
Project Maven, czyli jak wynieść organizację na wyższy poziom
Aby powyższy stan rzeczy zakończyć, podjęta została decyzja o zbudowaniu “Project Maven”. To repozytorium, które miało stać się systemem do inteligentnej analizy materiałów z czujników bezzałogowców. To jednak nie jest jedyna rola Mavena. Projekt ten miał w zamierzeniu stać się przyczółkiem dla metodycznego wykorzystania Big Data oraz sztucznej inteligencji (AI) w armii amerykańskiej. Chociaż USA są synonimem postępu i nowoczesności, w wojsku ciągle wiele elementów działało jak podczas II Wojny Światowej. Wpuszczenie systemów przetwarzania dużych danych miało to zmienić.
Maven skupia się na analizie danych wideo z różnych platform dronowych:
Scan Eagle
MQ-1C Gray Eagle
MQ-9 Reaper.
Podstawowym celem Projektu miała być automatyczna identyfikacja obiektów rejestrowanych przez kamery Dronów. Co warte podkreślenia – w tworzenie całego systemu zaangażowane były podmioty prywatne. Jedną z firm tworzących repozytorium było Google. Ciężko o bardziej trafną decyzję – to od tej firmy zaczęła się “prawdziwa Big Data” i spod jej skrzydeł wyszły niezwykle istotne technologie, będące właściwie fundamentem branży. W związku z ujawnieniem wewnątrz Google współpracy z Pentagonem, wybuchł protest pracowników. Ci rządali wycofania się z procesu, tłumacząc to niezgodnością z linią etyczną firmy i ich hasłem przewodnim “Don’t be evil” (nie bądź zły). To jednak zupełnie na marginesie.
Projekt Maven miał rozwiązać jeszcze jeden problem: biurokrację. Dotychczas jedynie ludzkie oko (i oczywiście mózg) były wyznacznikami tego czy cel widziany przez bezzałogowiec jest wrogiem, czy nie. W związku z tragicznymi pomyłkami, procedury dotyczące możliwości podjęcia ostrzału bardzo mocno spowolniły czas między obserwacją, a ogniem. Znakomicie wyuczone mechanizmy mają na celu przyspieszenie całego procesu.
Jak mógłby wyglądać “Project Maven”?
Na końcu proponuję zabawę. Skoro jesteśmy na blogu stricte poświęconym Big Data – spróbujmy zastanowić się jak mogłoby wyglądać Maven pod kątem technicznym, a przynajmniej architektonicznym – w najbardziej ogólnym rozumieniu tego słowa. Nie próbujemy domyślić się jak było to robione w Pentagonie, ale jak analogiczny system mógłby być zbudowany u nas, na potrzeby Wojska Polskiego.
Nasza specyfika jest oczywiście zupełnie inna. Nie musimy obserwować połowy świata. Załóżmy jednak, że chcemy bardzo precyzyjnie monitorować całą granicę wschodnią i otrzymywać alerty, jeśli coś niewłaściwego się tam dzieje. Ponieważ nasza granica jest dość długa, przygotujemy system który automatycznie powiadamia o podejrzanych ruchach oraz pozwala przeszukiwać informacje o aktualnym stanie oraz stanie z określonego momentu w historii.
Przykładowy slajd wysłany do zatwierdzenia w procesie uczenia oryginalnego projektu Maven.
Zastanówmy się więc jak to może wyglądać.
Storage – tak nazwijmy ogólną część, w której składujemy dane.
Moduł do uczenia
System alertów
Moduł do analizy
Jaka infrastruktura?
Zacznijmy od bardzo ważnej kwestii! Konkretnie od powiedzenia sobie wprost: taki system absolutnie nie może być zbudowany z wykorzystaniem rozwiązań chmurowych. Być może to kontrowersyjna teza, ale obecnie najwięksi dostawcy to firmy zagraniczne. W przypadku tego typu produktu podstawową cechą musi być bezpieczeństwo. Nie owijając w bawełnę – nie tylko bezpieczeństwo przed włamaniami rosyjskich hakerów. To są dane, które po prostu nie mogą być zależne od zagranicznej infrastruktury (nawet jeśli jest położona na terenie Polski). Rozumiem, że wiele osób może mieć odmienne zdanie, szanuję to, ale się z nim nie zgadzam. Zakładam więc budowę systemu na własnej infrastrukturze (on-premise).
Nic nie stoi jednak na przeszkodzie, abyś Ty rozpisał/a podobną architekturę dla rozwiązań chmurowych;-). Napisz i wyślij, a ja z pewnością opublikuję.
Storage
W tym miejscu musimy się zastanowić w jaki sposób składować dane. To tutaj będą trafiać w pierwszym kroku, ale nie tylko. Oczywiście taki moduł może składać się z więcej niż jednej technologii do składowania danych!
Co dokładnie moglibyśmy tutaj umieścić? Zacznijmy od pierwszej przestrzeni, gdzie lądować miałyby surowe dane. Proponuję tutaj jedną z dwóch technologii:
W takim miejscu możemy przede wszystkim składować wszystkie możliwe pliki wideo, które będą przesyłane przez drony. Następnie pliki te byłyby odczytywane i zapisywane do którejś bazy danych w formie metadanych (np. jakie obiekty są w jakim momencie nagrania, co to za samolot itd). Może to być HBase (który współgra zarówno z HDFS jak i z Ozone).
Moduł do uczenia
Oczywiście w “naszym Mavenie” musimy mieć modele, dzięki którym będziemy mogli rozpoznawać konkretne obiekty, ludzi, broń itd. Aby to zrobić, musimy utworzyć moduł uczący. W jego ramach możemy zrobić tak jak w amerykańskim odpowiedniku – najpierw trzeba przejrzeć bardzo bardzo wiele materiałów, a następnie otagować co tam się znajduje, jak to wygląda itd. W kolejnym etapie utworzymy klasyczny zbiór uczący i testowy, a następnie wytrenujemy konkretne modele dzięki uczeniu nadzorowanemu (co możemy zrobić dzięki otagowanym materiałom).
Jakie technologie możemy tutaj zastosować? Możemy pójść w stronę wykorzystania bibliotek pythonowych – i wtedy próbować swoich sił z TensorFlow. Możemy także popracować z Apache Spark ML i deep learning, który oferują na coraz lepszym poziomie jego twórcy.
System Alertów
Następny moduł który powinniśmy omówić to system alertów. Chodzi o to, aby nasi żołnierze z Wojsk Obrony Cyberprzestrzeni nie ślęczeli przed widokami przekazywanymi z każdego z dronów, ale by byli powiadamiani o potencjalnych anomaliach zawczasu przez zautomatyzowany system.
Tutaj moja propozycja jest prosta:
Kafka, na którą trafiają obrazy wideo
Consumer przygotowany przez Spark Structured Streaming, który przetwarza te obrazy z wykorzystaniem wcześniejszych modeli i rozbiera je na części pierwsze (podobnie jak to się dzieje w punkcie pierwszym – Storage). Następnie, w formie lżejszych informacji (metadane) przesyła na kolejny endpoind kafki.
Consumer znów przygotowany przez Spark Structured Streaming, ale nasłuchujący na drugim endpoincie – z metadanymi. Jeśli informacje, które się tam pojawią są podejrzane, wysyłany jest alert do przygotowanej aplikacji, przed którą siedzą nasi żołnierze WOC.
Moduł do analizy
Ostatnim elementem który został nam do ogrania jest moduł do analizy. tutaj pomijamy system streamingowy i niejako zataczamy koło, trafiając do naszego Storage. Z tego miejsca musimy zbudować job, który pozwoli nam sprawnie indeksować dane z bazy danych do technologii full-text search. Oto co proponuję:
Spark, który wyciąga dane z HBase i umieszcza je (być może w odpowiednio okrojonej formie) w Elasticsearch
Elasticsearch, który przechowuje dane.
Kibana, która pozwala nam analizować dane umieszczone w Elasticsearch.
Podsumowanie
Oczywiście powyższe zalecenia to raczej intelektualna zabawa, nie poważna analiza i architektura. Służy jednak pobudzeniu myślenia o tym jak można patrzeć na systemy oraz wskazać, że nie są one poza naszym zasięgiem.
Podsumujmy: Amerykanie także mają swoje miejsca wstydu, które wyglądają jakby były rodem z II Wojny Światowej. Rozwiązaniem części z nich, oraz zalążkiem Big Data w Pentagonie, miał (ma) być “Project Maven” który byłby pewnym repozytorium materiałów dronowych. W jego ramach odbywałoby się uczenie i analiza obiektów widzianych przez bezzałogowce.
Jak pokazałem, my także możemy rozwijać nasze siły zbrojne w kontekście Big Data oraz AI. Mam nadzieję, że tak się dzieje – jednym z symptomów zmian jest utworzenie Wojsk Obrony Cyberprzestrzeni. Oby nie były to puste etaty, bo fachowców mamy w Polsce wspaniałych.
Daj znać w komentarzu jak się podobało. Zapraszam też na profil RDF na LinkedIn oraz do newslettera. Pozostańmy w kontakcie!
UWAGA! Już niedługo ukaże się pierwszy polski ebook o Big Data. Całkowicie za darmo dla subskrybentów bloga RDF. Zapisując się na newsletter TERAZ – masz niepowtarzalną okazję dostawać kolejne wersje książki i zgłaszać swoje poprawki, a nawet stać się jednym z autorów. Więcej tutaj.
Końcówka lutego 2022 roku. Rosja atakuje Ukrainę, a jednym z narzędzi rozbrajania przeciwnika jest Buk. Ten samobieżny system kierowanych rakiet ziemia-powietrze skutecznie może wykańczać flotę powietrzną lub bronić wojsko przed rakietami manewrującymi. Na szczęście Ukraina posiada w swoim arsenale tureckie drony Bayraktar. Na publicznie dostępnym wideo widać obraz komputerowego monitora z przekazem real-time lecącego nad rosyjskimi wojskami samolotu bezzałogowego. Sterujący zdalnie żołnierz bez problemu namierza system Buk i wciska przycisk. Po chwili na ekranie widać już tylko unoszące się tumany dymu i pyłu w miejscu uderzenia.
Nie byłoby to możliwe, gdyby nie rozbudowana praca na danych. W tym artykule chciałbym poruszyć problematykę konfliktów międzynarodowych właśnie z punktu widzenia zarządzania danymi i tego jaką rolę one odgrywają w całym zamieszaniu.
Dlaczego warto poznać kształt współczesnych konfliktów?
W tym miejscu był całkiem długawy wstęp. Nie rozwodząc się jednak zbytnio: jako ludzie mieszkający w kraju z takim położeniem, musimy “znać się na wojnie”. Świadomość zagrożenia i zdobywanie wiedzy na temat kształtu współczesnego pola walki nie jest niczym zdrożnym. Przeciwnie – świadczy o dojrzałości. Przygotowując się do walki (w każdy możliwy sposób), zmniejszamy prawdopodobieństwo jej wystąpienia.
Ja (na szczęście) nie jestem ekspertem od geopolityki. Postaram się jednak zbadać i podzielić tym jaką rolę na wojnie pełnią dane, elektronika i wysokie technologie, w tym Big Data. Dzisiejszy artykuł będzie zaledwie zajawką – żeby nie przegapić kolejnych, zapisz się na newsletter;-)
Współczesne pole bitwy wygląda zupełnie inaczej niż 100 lat temu. Nie jest to jednak wojna robotów, jaką możemy znać z filmów czy gier.
Zanim zacznie się wojna…
Działania poniżej progu wojny
Zanim działania przybiorą typowo wojenny, kinetyczny charakter, do gry wchodzą działania “poniżej progu wojny”. Choć nie jest to nic nowego pod słońcem, współcześnie działania zakrojone są na bardzo szeroką skalę i są znacznie prostsze do przeprowadzenia niż kiedyś. Celów jest wiele: od dezintegracji społeczeństwa (jesteśmy podzieleni, nie wiemy także kto jest po jakiej stronie ani gdzie jest prawda) aż po wzbudzenie braku zaufania do państwa i przywódców. Dzieje się to oczywiście na bardzo wielu poziomach – jest wprowadzanie na wysokie stanowiska półinteligentów i ludzi skorumpowanych. Są cyberataki, które podważają zaufanie do skuteczności państwa i wiele, wiele innych.
Media społecznościowe idealnym narzędziem szerzenia dezinformacji
Z naszej perspektywy warto jednak zwrócić uwagę na jeden aspekt – są nim media społecznościowe, które wyglądają, jakby wręcz były zaprojektowane po to, aby prowadzić działania “poniżej progu wojny”, co często upraszczane jest do miana “dezinformacji”. Jest to narzędzie bardzo istotne z samego faktu z jak wieloma informacjami zderzamy się, gdy przewiniemy tablicę. Choć nie analizujemy ich szczegółowo, nasz mózg nie radzi sobie z przyswojeniem takiej ilości informacji. W efekcie tego stara się tą skomplikowaną rzeczywistość bardzo uprościć, co czynu niejako automatycznie.
Zauważmy pewną ciekawą rzecz: wiele z informacji które spotykamy (niezależnie od konkretnego medium) nie pochodzi od autorów wybranych przez nas. Nawet jeśli, to nie są to treści wybrane w jakiś prosty sposób – na przykład chronologicznie.
Jakie treści zatem dostajemy?
Takie, które najprawdopodobniej polubimy (na co wskazują algorytmy uczące się, należące do konkretnego medium)
Te, które wzbudzają największe emocje
Takie, które są popularne
Te, których autorów oznaczyliśmy wprost, że chcemy widzieć każdy ich post.
Treści promowane, których autorzy dość precyzyjnie “wycelowali” swoją treść w nas.
Sposoby szerzenia dezinformacji dzięki konstrukcji mediów społecznościowych
Warto jednak zwrócić uwagę, że niekoniecznie musimy znać wcześniej konta, których posty widzimy. Można więc tak skonstruować przekaz, aby docierał do jak najszerszego odbiorcy i infekował go odpowiednimi treściami. W tym celu budowane są odpowiednie “farmy trolli” – całe złożone społeczności, które nawiązują relacje, dyskutują i udostępniają posty. Dzięki temu określone wypowiedzi są popularne, wychwytywane przez algorytmy i docierają dalej.
Jednoznaczne określenie bota nie jest proste. Analizator Twittera mojego autorstwa uznał za bota… Donalda Trumpa, ówczesnego Prezydenta USA. Stało się tak prawdopodobnie z wielu powodów. Jednym z nich mogła być legendarna właściwie aktywność na Twitterze byłego przywódcy ameryki.
Zbudowanie takich sztucznych kont przeprowadzane jest na wiele sposobów – z różnymi kosztami i różnymi skutkami. Najprostszym sposobem jest zbudowanie farmy botów, czyli automatycznych mechanizmów, które sterują kontami bez ingerencji człowieka. Te najprostsze po prostu masowo podają określone posty, nie mają uzupełnionych profili i generalnie łatwo je poznać. Te bardziej skomplikowane mają zdjęcia, prostą historię a nawet charakter wypowiedzi. Pomiędzy jednymi a drugimi jest oczywiście duże spektrum. Rosja jest państwem, które oficjalnie przyznaje, że ma swoich “etatowych trolli”. Są to ludzie, którzy zarządzają wieloma kontami i w ten sposób budują społeczności znacznie ciężej wykrywane niż zwykłe boty – o ile oczywiście robią to z pewnym kunsztem.
Nie ma w tym artykule miejsca na szerszy opis (będzie osobny artykuł – zapisz się na newsletter poniżej!). Być może najlepszym podsumowaniem będzie: “miej ograniczone zaufanie dla każdego profilu w sieci. Szczególnie jeśli go nie znasz. Nie każdy opiniotwórca ma dobre zamiary”. Pamiętajmy, że media społecznościowe są zbudowane w określony sposób, aby utrzymać naszą uwagę. I to właśnie te mechanizmy wykorzystywane są przez osoby/organizacje, aby szerzyć “za darmo” dezinformację na bardzo wysokim poziomie.
Rozpoznanie (obserwacja)
Drugim ważnym obszarem na współczesnym polu bitwy jest… obserwacja. Tutaj już powoli wkraczamy w “TĄ wojnę”. Przypomnijmy sobie ostatnie miesiące (i szczególnie tygodnie) przed napadem Rosji na Ukrainę. Jak wyglądał ten czas? Media bombardowały nas informacjami na temat tego jak wojska rosyjskie podchodzą pod granicę z Ukrainą. Dowiadywaliśmy się nie tylko gdzie są rozmieszczone, ale także ile ich jest (szacunkowo) oraz co to za siły.
Jednym z “oczu armii” obserwacji są drony obserwacyjne – m.in. Flye Eye konstrukcji i autorstwa polskiej firmy WB.
Rzadko kto zadawał sobie pytanie: “jak to możliwe?”. A przecież, jak się chwilę zastanowić, to właśnie możliwości obserwacyjne są dzisiaj (i nie tylko dzisiaj) kluczem do zrozumienia sytuacji. Dzięki temu praktycznie niemożliwy jest atak z zaskoczenia. Żyjemy ze świadomością, że w dowolnym momencie można spojrzeć w każdy punkt na kuli ziemskiej. Jesteśmy do tego przyzwyczajeni, trochę patrząc na to jak na grę komputerową. Nie dzieje się to jednak w żaden magiczny sposób.
To właśnie możliwości obserwacji decydują o tym co i kiedy będziemy widzieli. Możliwości, które dostarczają bardzo materialne maszyny zbierające i przesyłające dane. Warto podkreślić, że możliwości obserwacji, które nie są wcale dostępne dla każdego. I to z kolei daje poważne przewagi lub braki na współczesnym polu walki.
Satelity
Najbardziej podstawowym sposobem zdobywania zdolności obserwacyjnych są satelity. Te poruszają się na orbitach ziemi w celu obserwacji i przekazu sygnałów na żywo. Warto podkreślić ogromną wagę w znaczeniu geopolitycznym – państwa bez tego typu systemów są ślepe, lub zdane na inne państwa. Tymczasem koszt konstelacji nie jest wielki i zamyka się w kilkuset milionach zł (mowa o podstawowej konstelacji dla Polski).
Drony
Drugim elementem obserwacji o jakim warto powiedzieć są drony. Samoloty bezzałogowe wyposażone w systemy czujników, pozwalają zbierać obraz na żywo. W każdym momencie wiele tego typu maszyn na usługach armii amerykańskiej przeczesuje tereny w bardzo wielu zakątkach Ziemi. Warto tu podkreślić, że Amerykanie mają osobny system, którego celem jest przechowywanie i analiza obrazów z kamer. System ten nazywa się “Project Maven” i na jego temat pojawi się osobny artykuł – zapraszam do newslettera!
Stacje nasłuchowe
Ostatnim narzędziem o którym chciałbym wspomnieć są stacje nasłuchowe. Choć znakomita większość informacji jest utajniona, możemy dziś powiedzieć jasno: system inwigilacji Echelon to Big Datowy majstersztyk. Pozwala zbierać i łączyć ze sobą informacje, które normalnie dostępne nie są, takie jak emaile, telefony czy SMSy. Wszystko dzięki rozmieszczonym na kilku kontynentach stacjom nasłuchowym. Całość jest przechowywana i przetwarzana w ramach jednego wielkiego systemu do analizy, przez zespoły analityczne, które pracują bez przerwy. Również i ten temat z pewnością podejmę w ramach serii artykułów. W ramach ciekawostki powiem, że najprawdopodobniej także w Polsce jest jedna stacja nasłuchowa (choć mniejszej rangi) systemu Echelon.
Stacja nasłuchowa w ramach systemu Echelon niedaleko Pine Gap w Australii.
Broń “inteligentna”
Trzeci element, o którym jedynie wspomnimy, to wszelkiego rodzaju broń i systemy “inteligentne”. Być może to truizm, ale współcześnie nie wystrzeliwujemy już kul z armat, niczym w średniowieczu, licząc że dotrą do celu po odpowiednim nadaniu im prędkości, kierunku i zwrotu (choć i współcześnie istnieją oczywiście pociski balistyczne, posiadające paraboliczny tor lotu – to jednak zupełnie inna liga).
Pociski kierowane (broń samonaprowadzająca)
Współczesne pociski samonaprowadzające po wskazaniu celu i wystrzeleniu, samodzielnie namierzają obiekt w który mają trafić, aż do eksplozji (która następuje np. w wyniku uderzenia w obiekt). To trzecia generacja pocisków kierowanych (w pierwszej to człowiek sterował zdalnie pociskiem, aż ten doleciał do celu). Polega na tzw. systemie “strzel i zapomnij” (ang. F&F –Fire and Forget). Żołnierz namierza cel, po czym wystrzeliwuje pocisk. Ten – już bez kontaktu z człowiekiem – samodzielnie dąży do obiektu w który ma uderzyć, nawet jeśli zmienia się jego położenie.
Taką technologią są m.in. polskie zestawy przeciwrakietowe Piorun. Co warto podkreślić – są one uważane przez wielu ekspertów za najlepsze systemy tego typu na świecie. Zestawy te są naszpikowane po brzegi elektroniką. Operator może określić tam między innymi z jakim celem będzie miał pocisk do czynienia (np. helikopter, pocisk itd). Inną ciekawą cechą są dwa podstawowe rodzaje eksplozji, jakie mogą nastąpić. Pierwsza to oczywiście eksplozja po uderzeniu w cel i wbiciu się w środek obiektu. Drugi natomiast pomysł, to wybuch w momencie, w którym pocisk będzie przelatywał w odległości paru metrów obok celu. Taki efekt może być wykorzystany, gdy celem są mniejsze obiekty, jak na przykład pociski.
Warto podkreślić, że zestaw posiada swój własny radar, który działa nawet na odległość 8-10 km. Gdy cel (np. helikopter) wleci w zasięg radaru, można go namierzyć. Kiedy przemieści się tak, aby być w zasięgu pocisku – ten wystrzeli automatycznie pędząc ku obiektowi. Poniżej zestrzelenie helikoptera rosyjskiego przez siły Ukraińskie – prawdopodobnie właśnie polskimi “Piorunami”.
https://www.youtube.com/watch?v=x237HLRzDH8
Myśliwce, drony
Ostatnim elementem o którym chcę powiedzieć są siły powietrzne, a konkretnie myśliwce i drony. Samoloty bojowe dawno temu przestały być jedynie latającymi maszynami z pilotem, który jedynie steruje maszyną (w prostym rozumieniu tego zwrotu). Najnowocześniejsze myśliwce, F-35, to tak naprawdę latające komputery. Na temat elektroniki F-35 można napisać osobny materiał. Powiedzmy tutaj jednak, że same samoloty są elementem większego systemu. I to właśnie jako element tego systemu są nadzwyczaj niebezpieczne. Podkreślmy jeden fakt: sam hełm dla pilota F-35 kosztuje ok. 400 000 $. Dzieje się tak, ponieważ to nie tylko samo nakrycie głowy, ale przenośny system komputerowy, który drastycznie zwiększa możliwości pilota tego myśliwca. Tak naprawdę to prawdziwa rozszerzona rzeczywistość. Dzięki wielu czujnikom i kamerom zamontowanym w wielu miejscach samolotu, pilot może dzięki wyświetlaczowi hełmu “oderwać się od maszyny”. Chodzi o to, że obracając głową, nie widzi ścian myśliwca, ale przestrzeń wokół siebie. Patrząc na dół, nie widzi nóg, ale przestrzeń pod myśliwcem. Zupełnie, jakby sam leciał w powietrzu! Oczywiście na ekranie ma dostępne także wszelkie dane, które potrzebne są do monitorowania i sterowania maszyną.
No dobrze, to wszystko pilot. Są też jednak samoloty… bez pilotów. Mowa o dronach, czyli samolotach bezzałogowych. I tutaj mamy tak naprawdę ogromny rynek maszyn wszelkiego rodzaju. Od zwykłych cywilnych dronów, które nakręcą nam sympatyczne wideo, po potężne i zabójcze maszyny. Co ciekawe, Polska także ma pewne osiągnięcia na tym polu. “Oczami” naszej armii są bezzałogowce Flye Eye (widoczne na drugim zdjęciu, na górze artykułu). Są to maszyny, które służą do obserwacji. Flye Eye są bardzo lekkie i żeby wystartować, wystarczy… ręka żołnierza. Nie trzeba żadnych maszyn ani torów startowych.
Podczas agresji Rosji na Ukrainę to właśnie drony były jedną z bardziej pożądanych technologii. Powyżej można obejrzeć wideo, w którym Ukraińscy żołnierze zdalnie sterują samolotem niszcząc system Buk – jeden z poważniejszych atutów wojsk rosyjskich. Takie samoloty są o tyle wygodne, że oczywiście nie niosą ze sobą ryzyka śmierci pilotów, znacznie łatwiej przeszkolić załogę (niż do myśliwców), a ich cena także znacznie odbiega od innych samolotów załogowych.
Przesłanie na koniec
Mam nadzieję, że artykuł Ci się spodobał. Pamiętajmy, że to początek. W dalszych materiałach chciałbym szerzej opowiedzieć o dezinformacji, amerykańskim systemie Maven czy sieci nasłuchowej Echelon. Wojna to zawsze straszna rzecz, ale przygotowując się do niej, zawsze zmniejszamy ryzyko jej wystąpienia. Ze swojej strony dołożę cegiełkę w kontekście poznania współczesnego pola bitwy od strony technologicznej. Jeśli chcesz pozostać w kontakcie – zostaw maila, a ja raz na tydzień napiszę co w Big Datowym świecie słychać. Polub też nasz profil na LinkedIn.
UWAGA! Już niedługo ukaże się pierwszy polski ebook o Big Data. Całkowicie za darmo dla subskrybentów bloga RDF. Zapisując się na newsletter TERAZ – masz niepowtarzalną okazję dostawać kolejne wersje książki i zgłaszać swoje poprawki, a nawet stać się jednym z autorów. Więcej tutaj.
Do tej pory poświęciłem dwa artykuły na dylemat cloud vs on-premise, czyli pytanie o to czy nasza infrastruktura techniczna powinna być serio nasza i stać u nas w serwerowni (albo – jak mój eksperymentalny klasterek – pod biurkiem;-)). Być może powinna zostać uruchomiona na maszynach wirtualnych wykupionych w ramach usług chmurowych? Nie ma jednej dobrej odpowiedzi na te tematy. Dzisiaj chciałbym jednak skomplikować temat jeszcze bardziej. Porozmawiajmy na temat tego czym jest hybrid cloud! No to Big Coffee w dłoń i ruszamy.
Zanim przejdziemy do pojęcia hybrid cloud, wyjaśnijmy pojęcie które będzie nam potrzebne – czyli private cloud, chmura prywatna. Jest to taki rodzaj usługi chmurowej, który odznacza się daleko idącym wydzieleniem zasobów sprzętowych na potrzeby klienta. Może to być zarówno przechowywane w miejscu jego pracy jak i u dostawcy chmurowego. To ostatnie jednak z zastrzeżeniem, że zasoby sprzętowe powinny realnie być oddzielone od reszty.
Stoi to w opozycji do chmury publicznej (ang. public cloud), gdzie dzielimy de facto zasoby z bardzo wieloma innymi użytkownikami (przy czym bazujemy na utworzonych dla nas maszynach wirtualnych lub kontach w konkretnych serwisach). Takie podejście pozwala zachować większe bezpieczeństwo i spełnić wymogi niektórych regulatorów.
Istnieje jeszcze pojęcie Virtual Private Cloud (VPC), czyli wirtualnej chmury prywatnej. Jest to de facto klasyczna chmura publiczna, która po prostu jest oddzielona logicznie od innych “uczestników” chmury (chodzi o tenantów;-)). Moim zdaniem jednak takie podejście ciężko nazywać “prywatnym” – nie spełnia bowiem podstawowych założeń chmury prywatnej, czyli udostepnienia klientowi zasobów “na wyłączność”, dzięki czemu mógłby osiągnąć większą kontrolę i bezpieczeństwo.
Oczywiście chmura to nie tylko wirtualne maszyny. Powstaje pytanie, jakie usługi może dostarczać dostawca chmurowy w ramach chmuryprywatnej? Odpowiedź poniżej.
Infrastructure as a Service (IaaS) – A więc chmura przejmuje wirtualizację, serwery, storage i networking. Klient natomiast dba o resztę (system operacyjny, middleware, runtime, dane i aplikacje)
Platform as a Service (PaaS) – W tym przypadku po stronie klienta zostają już tylko dane i aplikacje.
Cały podział (razem z on-premise oraz SaaS) poniżej. Grafika pochodzi od Microsoftu i jest używana do opisu Azure.
Hybrid Cloud
Hybryda, jak to hybryda, łączy różne style. W tym przypadku łączymy public cloud z private cloud lub z on-premise. Jeśli używasz kombinacji tych trzech składników w jakiejkolwiek konfiguracji – znaczy, że Twoja infrastruktura jest hybrydowa.
Jakie są zalety rozwiązania hybrydowego? Otóż – przede wszystkim jest to pewna zwinność, elastyczność. Jak już wykazywałem w dwóch artykułach na temat dylematu “cloud vs on-premise” – nie ma jednoznacznie dobrego lub złego rozwiązania. Każde wiąże sięz pewnymi wadami i zaletami. Jeszcze lepiej byłoby stwierdzić, że każde powinno być dostosowane do określonej specyfiki danego problemu. Przykładowo – w rozwiązaniu on-premise problemem może być koszt personelu potrzebnego do serwisowania infrastruktury. Jeśli chodzi o chmurę, w niektorych, szczegolnie wrażliwych przypadkach problemem może być pytanie o to gdzie dokładnie dane są przechowywane (np. wrażliwe dane rządowe).
Decydując się na mix infrastruktury, zachowujemy elastyczność i zwinność. Możemy dostosować wady i zalety rozwiązań tak, aby finalna konstrukcja była idealnie dopasowana do charakterystyki naszego projektu.
Kolejną zaletą hybrid cloud może być także większa efektywność kosztowa. Możemy zauważyć na przykład, że dane chcemy co prawda trzymać na własnych maszynach, jednak przetwarzanie ich może czasami osiągać zawrotne wymagania jeśli chodzi o zasoby. W takiej sytuacji możemy przechowywać je u siebie, natomiast przetwarzać w chmurze, gdzie przydzielanie zasobów może odbywać się niezwykle prosto i dynamicznie.
Podsumowanie
Nie ma jednej prostej odpowiedzi na pytanie “co jest lepsze: chmura czy rozwiązania on-premise?”. Wszystko ma nie tylko swoje wady i zalety, ale i charakterystykę, która musi zostać dopasowana do problemu. Warto jednak pamiętać, że istnieją nie tylko dwie skrajne opcje, ale także rozwiązania hybrydowe. Można dzięki nim manipulować “suwakiem” kosztów, bezpieczeństwa, wygody itd. w inny sposób, niż zastanawiając się jedynie nad podstawowym wyborem.
Z pewnością będziemy kontynuować temat – dziś jedynie zajawka;-). Jeśli nie chcesz przegapić zmian, zapisz się na newsletter i obserwuj nasz profil na LinkedIn. Powodzenia!
Ostatnio miałem okazję rozmawiać z koleżanką, z którą pracuję w jednym projekcie. Być może warto dodać, że jest to projekt medyczno-genetyczny, bo rozmowa zeszła na kwestie etyczne. Zadała niezwykle ważne pytanie: “Czy ludzie pracujący w IT, ale przede wszystkim w Big Data, zdają sobie sprawę z tego w jak ważnej branży pracują? Czy wy myślicie o jakiś aspektach etycznych swojej pracy?”. No cóż – ja myślę od zawsze, kwestia wiary i wychowania. Czy jednak każdy myśli? Zapraszam dzisiaj do innego artykułu niż zwykle. Zaczniemy lekko łatwo i przyjemnie, ale to dopiero początek nowych tematów na blogu RDF;-). Zapraszam serdecznie;-)
Waga Big Data we współczesnym świecie
Dziś Big Data stało się moim zdaniem rdzeniem współczesnego świata. A jeśli jeszcze się nie stało, to zdecydowanie i bezpowrotnie staje się nim. To dzięki Big Data świat idzie do przodu i to dzięki tej branży może się rozwijać.
Ma to jednak swoje mroczne strony. Wszechobecna inwigilacja, przewidywanie każdego aspektu naszego życia, wojna informacyjna (i dezinformacja) na niespotykaną nigdy wcześniej skalę. Uzależnienia całych pokoleń od elektroniki i mediów społecznościowych, oszustwa finansowe, wielkie manipulacje społeczno-polityczne. Mógłbym wymieniać w nieskończoność.
Czy oznacza to, że żyjemy w najbardziej mrocznych czasach w historii? Moim zdaniem nie, choć złe tematy są znacznie, znacznie bardziej “klikalne”. Dobro bardzo często jest ciche, jednak robi ogromną i trwałą robotę. Dzisiaj nieśmiało chciałbym tym artykułem rozpocząć tematykę etyki w Big Data. Zacznijmy od prostego i przyjemnego tematu – a konkretnie kilku przykładów dobrego wykorzystania inteligentnego przetwarzania dużych danych.
3 projekty, które wykorzystują duże dane dla słusznej sprawy
Cloudera co roku wyłania 3 organizacje w ramach swojego konkursu “Data for good”. Oczywiście są to organizacje związane z Clouderą (poprzez korzystanie z ich produktów). Nie zmienia to jednak postaci rzeczy, że mamy tu znakomite przykłady inteligentnego zastosowania obsługi dużych danych do poprawy czegoś w naszym świecie. Zapraszam na krótki opis każdej z organizacji.
Union Bank (Union Bank of Philippines)
Tło całej sprawy to oczywiście COVID, który doprowadził do ciężkiej sytuacji ogromnej rzeszy Filipińczyków. Bardzo wielu z nich musiało coś zrobić, aby przetrwać ciężki czas ledwo wiążąc koniec z końcem. Jednym z podstawowych pomysłów jest pożyczka. Problem? Ponad 70 milionów osób było tam pozbawionych konta bankowego, przez to bank nie miał możliwości prostego sprawdzenia zdolności kredytowej.
Bank Filipiński skorzystał z Cloudera Data Science Workbench. Utworzyli oni ukierunkowany na dane system, który bazując na algorytmach AI pozwolił na szybszą predykcję swoich klientów – ich potencjalnego ryzyka i przydzielanych punktów kredytowych.
W rezultacie wskaźnik akceptacji kredytu wzrósł do 54%. Wzrosły też zyski banku, a co istotniejsze – miliony Filipińczyków mogły przetrwać kryzys. Oczywiście, tak, można zauważyć, że pożyczka nie jest najszczęśliwszym sposobem na utrzymanie się na powierzchni. Można też zwrócić uwagę, że końcem końców chodziło po prostu o zysk.
Tylko, że czasem kredyt to po prostu mniejsze zło. Jeśli zaś chodzi o zysk – cóż. Czy nie jest najlepszą sytuacja, w której zysk oparty jest o świadczenie naprawdę potrzebnych komuś usług?
Keck Medicine of USC
Druga organizacja która otrzymała wyróżnienie w “Data for good” to Keck Medicine of USC. Jest to przedsiębiorstwo medyczne Uniwersytetu Południowej Kalifornii. W tym przypadkiem tło jest chyba jeszcze “cięższe” niż poprzednio. Chodzi mianowicie o uzależnienia od opioidów. Według HHS, w 2019 roku ok 10.1 mln osób (w USA) nadużywało leków opioidowych. W 2018 roku natomiast opioidy były odpowiedzialne za 2/3 zgonów związanych z przedawkowaniem narkotyków.
W Keck Medicine od USC uznali, że spora część uzależnień może wynikać ze złych standardów (lub nie trzymania się dobrych praktyk) przypisywania środków przeciwbólowych przez lekarzy (najczęściej po operacjach lub w przypadku leczenia szczególnie przewlekłych, wyniszczających stanów). W związku z tym utworzony został projekt mający na celu wgląd w praktyki lekarzy. Centralnym punktem był Data Lake, który eliminował potencjalne błędy manualnego zbierania danych. Dodatkowo pozwalał spojrzeć “z lotu ptaka” na dane z całej organizacji.
Dzięki zaawansowanej analityce, naukowcy i lekarze mogą wykrywać najbardziej ryzykowne sytuacje i podjąć odpowiednią reakcję, taką jak edukacja. Dzięki systemowi organizacja może lepiej zadbać o swoich pacjentów, unikając uzależnień zamiast w nie (przypadkowo) wpędzać.
National organisation for rare disorders (National Marrow Donor Program)
Tło to tym razem nowotwory krwi, takie jak białaczka, na które co 10 minut ktoś umiera (tak, wciąż nic wesołego). Wielu z tych ludzi mogłoby żyć, gdyby znaleźli się dawcy na przeszczep szpiku kostnego. Niestety, u 70% osób nie ma odpowiednich osób do przeszczepu wśród najbliższej rodziny.
National Organisation for rare disorders utworzyła National Marrow Donor Program, który ma na celu kojarzenie ze sobą osób potrzebujących i dawców. W ich bazach jest obecnie zarejestrowanych 44 miliony osób. Jak nietrudno się domyślić, sprawne przeszukiwanie bazy to robota dla Big Data. Organizacja razem z Clouderą utworzyła odpowiedni system, dzięki czemu możliwe jest przeszukiwanie milionów rekordów w minutę.
Warto dodać, że na ten moment program pomógł uratować życie ponad 6 600 biorcom szpiku. To absolutnie rewelacyjna wiadomość!
Podsumowanie
Dziś zdecydowanie inny artykuł niż przeważnie. Tak już jest, że Big Data jest medalem, który ma bardzo, bardzo wiele stron. Chciałbym pisać tu o możliwie wielu z nich. Mam nadzieję, że dzisiejszy opis trzech organizacji które robią z danymi coś bardzo, bardzo sensownego, zainspiruje do innego myślenia.
Zostaw komentarz, podaj artykuł dalej i… cóż, koniecznie dołącz do nas na LinkedIn oraz newsletterze. Zostańmy w kontakcie dłużej i razem budujmy polską społeczność Big Data!
Wielokrotnie na tym blogu tłumaczyłem zawiłości Big Data od podstaw (nie oszukujmy się – sam wielokrotnie pisałem to także dla siebie, chcąc usystematyzować wiedzę). Nie tylko technicznie, ale i “z lotu ptaka”, biznesowo. Zawsze żałowałem, że muszę to robić “po łebkach”, w skondensowanej formie, wyrywkowo. Czym innym jest przedstawić jakieś okrojone zagadnienie a czym innym móc wyjaśnić kontekst, zagłębić się, pozwolić sobie na więcej, szerzej, głębiej. Postanowiłem dołączyć do bloga RDF jeden element, który rozwiąże ten problem. I jestem szalenie ciekawy, co o tym sądzisz!
UWAGA! Pierwszy polski ebook o Big Data już dostępny! Zapisz się na listę newslettera i podążaj “Szlakiem Big Data”. Więcej tutaj.
Ebook o Big Data. Po polsku!
No właśnie. Idealnym miejscem aby się zagłębić w temat i przedstawić coś od A do Z jest książka. A najlepiej, żeby była to książka powszechna, dostępna za darmo dla każdego. No więc co? No więc ebook!
Celem ebooka będzie wprowadzenie do branży Big Data. Od historii, filozofii, przez przegląd technologii i architektur. Na słowniczku skończywszy, o. Czy ma wyczerpać temat? Odpowiedź jest oczywista – nie da się go wyczerpać. Ja, po kilku latach naprawdę wytężonej pracy w BD, czuję się… jak kompletny świeżak.
Cel: traktuję Ebooka raczej jako furtkę do świata Big Data. Ja wyjmuję klucz i ją otwieram. Potem Ty dalej już wiesz gdzie iść.
Całość będzie napisana po polsku. RDF powstał po to, żeby szkolić i doradzać tu, w Polsce. Blog jest tego emanacją i podstawowym elementem budowy naszej społeczności Big Data.
Jak będzie zbudowany ebook o Big Data? (Spis Treści)
Przejdźmy do konkretu. Co znajdziesz w ebooku? Pomyślałem o kilku częściach:
Miękkie wprowadzenie do Big Data – czyli opis jak to się wszystko zaczęło (historia) oraz filozofia myślenia w branży. Nie pomijaj tego! Dzięki temu rozdziałowi zobaczysz jak zaczęła toczyć się ta kula śnieżna i… nauczysz się myśleć “po bigdatowemu”.
Opis kluczowych technologii – oczywiście nie będziemy tu robić kursów;-). Poznasz tam zgrubne zestawienie tego jaka technologia służy do jakiego celu. Już bardziej techniczne, ale bez przesady.
Rozważania architektoniczne – wbrew pozorom przyda się nie tylko inżynierom, ale także menedżerom. Do głębszego zrozumienia. Choć, powiedzmy szczerze, Ci ostatni mogą ten rozdział “przelecieć wzrokiem”.
Odwieczny dylemat: cloud czy on-premise? Czyli pytanie o to, czy samodzielnie tworzyć infrastrukturę czy skorzystać z dostawców.
Słowniczek – gdyby coś w trakcie było niezbyt zrozumiałe. Tylko nie zakuwaj za dużo!
Jestem jednak otwarty na różne sugestie. Mogę to zarówno pociąć jak i dobudować.
Zdjęcie bardzo poglądowe;-) Okładkę ebooka o Big Data też zaprojektujemy wspólnie!
UPDATE! 20.07.2022 – premiera ebooka. Dołącz do newslettera, aby otrzymać go za darmo.
Włącz się w tworzenie!
No właśnie – otwarty na sugestie. Twoje. Mam przynajmniej taką nadzieję. Ebook będzie znacznie bardziej wartościowy jeśli dowiem się od Was co was nurtuje, czego nie rozumiecie. A może co było trudne na początkowym etapie rozwoju? Każda uwaga jest cenna.
Jest jednak mały “haczyk”. Chcę, żebyśmy tworzyli jedno naprawdę spójne środowisko. Najlepiej bez pośredników w postaci mediów społecznościowych (w końcu pracuję w Big Data! Wiem jak to działa;-)). W związku z tym cały proces twórczy będzie opierał się o newsletter.
W ramach newslettera będę komunikował znacznie, znacznie więcej niż dotychczas.
Przez newsletter dostaniesz każdy kolejny kawałek skończonego ebooka.
Będziesz mógł odpowiedzieć na konkretny email i zasugerować zmiany. Jestem otwarty na rozmowę, a nawet czekam na nią!
Ebook będzie później dostępny dla każdego newsletterowicza. Pomagając więc tworzyć książkę, w sposób najpełniejszy wspierasz społeczność. Razem możemy zbudować coś, od czego wyjdzie każdy nowy Inżynier Big Data i menedżer BigDato-świadomy (:D).
Aby tak się stało, zapisz się na newsletter już teraz:
Podsumowanie – jak włączyć się w proces twórczy?
No więc, podsumowując: zaczynam (już zacząłem;-)) tworzenie ebooka o Big Data. Pierwszy taki na polskim rynku. Będzie w całości za darmo dla newsletterowiczów RDF. Co więcej – jeśli jesteś (lub zostaniesz) subskrybentem, możesz włączyć się w proces twórczy:
Każdorazowo gdy skończę jakiś większy fragment, wyślę Ci go do sprawdzenia.
Ponadto możesz odpowiadać na emaile i podpowiadać jakie poprawki chcesz wprowadzić. Zarówno te drobne (jeszcze jedna technologia?) jak i te fundamentalne (nowy dział?).
Jestem głęboko przekonany, że razem zbudujemy coś wyjątkowego! Dołącz także do naszego LinkedIn i podaj artykuł znajomym, którzy mogą być zainteresowani;-).
Za mną już znacznie ponad 20 mięsistych, wyczerpujących wpisów. Wciąż jednak brakuje fundamentalnego “Co to jest Big Data?”. Na to pytanie można odpowiadać godzinami. Dziś chciałbym jednak spojrzeć z biznesowej perspektywy. Nie będzie zbyt wielu technikaliów. Nie będziemy rozważać ile executorów powinno się ustawiać w spark-submit, ani czym różni się HBase od Accumulo. Ten artykuł przeznaczony jest dla osób zarządzających. Dla tych, którzy chcą pchnąć firmę na wyższy poziom i zastanawiają się, co to jest ta Big Data. Kubek z kawą na biurko… i ruszamy!
Jak to się zaczęło?
Zanim przejdziemy do samego sedna, bardzo istotna jest jedna rzecz: Big Data to naprawdę duża, złożona działka. Ciężko opisać ją w kilku punktach. Żeby ją zrozumieć, trzeba podejść z w kilku różnych kontekstach. Zacznijmy od krótkiej historii początków. Dzięki temu prawdopodobnie nie tylko zrozumiemy kontekst, ale i kilka cech charakterystycznych tej branży – co przyda się w podejmowanych decyzjach biznesowych.
Jak to często bywa z historią, początki są niejasne i każdy może mieć troszkę swoją własną teorię. Moim zdaniem jednak, definitywny początek Big Data ma… w Google. Tak – znana nam wszystkim korporacja (i wyszukiwarka) jest absolutnie najbardziej zasłużoną organizacją dla tej branży. Niezależnie od rozmaitych swoich grzeszków;-). Ale spójrzmy jeszcze wcześniej – do roku 1995. To wtedy Internet przybiera na sile. Jego rozmiary są nie do końca znana, natomiast sięga już przynajmniej 10 mln witryn. Co “gorsza”… rozwija się w tempie 2000% rocznie.
AltaVista była pierwszą, przełomową wyszukiwarką
Chaos Internetowy lat 90′
Kluczową dla funkcjonowania Internetu rzeczą, są wyszukiwarki. Dziś to dla nas rzecz oczywista, ale w 95′ wcale tak nie było. Jeśli jednak nie będzie wyszukiwarek, nie znajdziemy znakomitej większości rzeczy, których potrzebujemy. Problem polega na tym, że wyszukiwarki nie przeszukują całego internetu za każdym razem. One zapisują strony (w odpowiedniej strukturze, niekoniecznie całe strony) w swoich bazach danych. Następnie przeszukują te bazy, kiedy użytkownik przekaże zapytanie.
Wniosek jest oczywisty: wyszukiwarki to nie nudne “lupki”, a bardzo zaawansowana technologicznie maszyneria. Maszyneria, która potrzebuje dożo miejsca na dysku, dużo pamięci podręcznej oraz mocy obliczeniowej. Jak bardzo, przekonali się o tym Larry Page i Sergey Brin, którzy w 1998 roku zakładają Google. Z czasem bardzo szybko orientują się, że przyrost danych jest zbyt ogromny na jakikolwiek komputer.
I tutaj pojawia nam się pierwsza, najważniejsza (moim zdaniem) zasada, charakterystyka Big Data. Inżynierowie sporej już wtedy firmy, rozpoczęli prace nad technologią, która pozwoli przechowywać oraz przetwarzać bardzo duże dane (których jest więcej i więcej i więcej…). Ci jednak, zamiast skonstruować olbrzymi super-komputer, którym zaimponują światu, poszli w zupełnie inną stronę. Uznali, że i tak prędzej czy później (a raczej prędzej) skończy im się miejsce i moc obliczeniowa. Co wtedy, nowy super-komputer? No właśnie nie.
Podejście rozproszone (distributed)
Znacznie lepszym pomysłem będzie zbudowanie takiego oprogramowania, które pozwoli połączyć bardzo wiele komputerów. I korzystać z nich tak, jakbyśmy mieli jeden wielki komputer. Co kiedy skończą się możliwości? Cóż – po prostu dorzucimy kolejne mniejsze komputery do naszego ekosystemu. Takie podejście nazywa się podejściem “rozproszonym” (ang. distributed). Tak właśnie powstaje Google File System (GFS) oraz opublikowany zostaje Google File System Paper, na którym opisana jest architektura wynalazku. Rok i dwa lata później publikowane są kolejne przełomowe dokumenty: Map Reduce (MR) Paper (który opisuje technologię do przetwarzania danych) i Big Table Paper.
Czemu Google to fundament Big Data? Bo na wyżej wymienionych dokumentach powstają najbardziej fundamentalne technologie open-source. Fundacja Apache ogłasa w 2007 roku, że na bazie GFS oraz MR powstaje Hadoop – prawdopodobnie najbardziej znana technologia Big Data. Rok później, znów na bazie dokumentu Google (Big Table Paper) powstają dwie bazy danych: HBase oraz Accumulo.
Historia Big Data. Od chaosu w Internecie na początku lat 90′ do zaawansowanych technologii Big Data XXI wieku.
Co to jest Big Data? Zasada 3V
Skoro wiemy już jak to się wszystko zaczęło, przejdźmy do podstawowego pytania: Co to tak naprawdę jest Big Data? Skonkretyzujmy to sobie nieco. Jesteśmy w IT, więc postarajmy się zdefiniować tą materię. Dawno temu wyznaczona została zasada, która określa czym jest Big Data. Zasada ta była później rozwijana, natomiast my przyjrzymy się pierwotnej wersji. Dodajmy – wersji, która moim zdaniem jest najlepsza, każda kolejna to już troszeczkę budowa sztuki dla sztuki;-).
Chodzi mianowicie o wytłuszczoną w nagłówku zasadę 3V. Określa ona cechy danych, które najmocniej charakteryzują Big Data.
Volume (objętość) – najbardziej intuicyjna cecha. Wszyscy dobrze rozumiemy, że jak data mają być big, to muszą mieć “dużą masę”. Ile dokładnie, ciężko stwierdzić. Niektórzy mówią o dziesiątkach GB, inni dopiero o terabajtach danych.
Velocity (prędkość) – to już nieco mniej oczywista rzecz. Moim zdaniem jednak bardzo istotna dla zrozumienia naszej materii. Wyobraź sobie, że śledzisz wypowiedzi potencjalnych klientów w mediach społecznościowych. W tym celu analizujesz wszystkie posty z określonymi tagami. Można się domyślić jak szybko przybywa tych danych (i jak bardzo często są one nie do użycia, ale to już inna sprawa). Tutaj właśnie objawia się drugie “V”. Wielokrotnie mamy do czynienia nie tylko z dużymi danymi, ale także z danymi które napływają lub zmieniają się niezwykle szybko. To ogromne wyzwanie. Znacząco różni się od stanu, w którym po prostu musimy przetworzyć paczkę statycznych, zawsze takich samych danych.
Variety (różnorodność) – I ta cecha prawdopodobnie jest już zupełnie nieintuicyjna (w pierwszym odruchu). Dane które dostajemy bardzo często nie są pięknie ustrukturyzowane, ułożone, wraz z dostarczonymi schematami. Wręcz przeciwnie! To dane, które często są nieustrukturyzowane, w których panuje chaos. Dane, które nawet w ramach jednego zbioru są różne (np. wiadomości email). Są to wyzwania z którymi trzeba się mierzyć i do których zostały powołane odpowiednie technologie – technologie Big Data.
Big Data w biznesie – kiedy zdecydować się na budowanie kompetencji zespołu?
Skoro już wiemy jak to się zaczęło i czym to “dokładnie” jest, czas postawić to kluczowe pytanie. Przynajmniej kluczowe z Twojej perspektywy;-). Kiedy warto zdecydować się na budowanie kompetencji Big Data w zespole? Nie będę zgrywał jedynego słusznego mędrca. Ta branża jest skomplikowana niemal tak jak życie. Nie ma jednego zestawu wytycznych. Podzielę się jednak swoimi spostrzeżeniami.
Poniżej wymieniam 5 sytuacji, które mogą Ci się przydać. Bądźmy jednak szczerzy – to pewna generalizacja. Być może jednak całkiem przydatna;-).
Na horyzoncie pojawia się projekt, który nosi znamiona Big Data
Niezależnie od tego jaki jest charakter Twojej firmy, prace poukładane są w coś co nazwiemy “projektami”. Ten punkt sprawdzi się szczególnie wtedy, gdy outsourceujecie zasoby ludzkie lub robicie zlecaną przez innych robotę. W takiej sytuacji może na horyzoncie pojawić się projekt “legacy”, który ma kilka cech charakterystycznych:
Wykorzystywane są technologie Big Data. Dokładniej na temat tego jakie technologie za co odpowiadają, znajdziesz tutaj. Miej jednak radar nastawiony przynajmniej na kilka z nich:
Hadoop (w tym HDFS, Yarn, MapReduce (tych projektów nie bierz;-)).
Hive, Impala, Pig
Spark, Flink
HBase, MongoDB, Cassandra
Kafka,
“Przerzucane” są duże ilości danych (powyżej kilkudziesięciu gigabajtów)
Projekt bazuje na bardzo wielu różnych źródłach danych
Projekt pracuje na średnich ilościach danych (dziesiątki gb), ale pracuje bardzo niewydajnie, działa wolno i sprawia przez to problemy.
I inne;-). Jeśli widzisz projekt, który na odległość pachnie zapychającymi się systemami, technologiami Big Data i różnorodnością danych – wiedz, że czas najwyższy na budowę zespołu z odpowiednimi możliwościami.
Projekt nad którym pracujecie, przerósł wasze oczekiwania
Wielokrotnie bywa tak, że mechanizmy zbudowane w ramach jakiegoś projektu są dobre. Szczególnie na początkowym etapie, kiedy danych nie ma jeszcze zbyt wielu. Potem jednak danych przybywa, źródeł przybywa i… funkcjonalności przybywa. Tylko technologie i zasoby pozostają te same. W takim momencie proste przetwarzanie danych w celu uzyskania raportów dziennych trwa na przykład 6 godzin. I wiele wskazuje na to, że będzie coraz gorzej.
Ważne, żeby podkreślić, że nie musi to być wina projektantów systemu. Czasami jednak trzeba dokonać pivotu i przepisać całość (albo część!) na nowy sposób pracy. Nie jest to idealny moment na rozpoczęcie wyposażania zespołu w kompetencję Big Data. Może to być jednak konieczne.
Zapada decyzja o poszerzeniu portfolio usługowego
Tu sprawa jest oczywista. Świadczycie usługi IT. Robicie już znakomite aplikacje webowe, mobilne, pracujecie w Javie, Angularze i Androidzie. Podejmujecie decyzję żeby poszerzyć portfolio o usługi w ramach Big Data. To nie będzie łatwe! Należy zbudować całą strukturę, która pozwoli odpowiednio wyceniać projekty, przejmować dziedziczony (legacy) kod czy projektować systemy. Trzeba się do tego przygotować.
Czy trzeba budować cały nowy dział od 0? Absolutnie nie – można bazować na już istniejących pracownikach, choć z całą pewnością przydałby się senior oraz architekt. Warto jednak pamiętać, że cały proces powinien rozpocząć się na wiele miesięcy przed planowanym startem publicznego oferowania usług Big Data.
Organizacja znacząco się rozrasta wewnętrznie
Bardzo często myślimy o przetwarzaniu dużych danych na potrzeby konkretnych projektów, produktów itd. Jednym słowem, zastanawiamy się nad dość “zewnętrznym” efektem końcowym. Musimy jednak pamiętać, że równie cennymi (a czasami najcenniejszymi) danymi i procesami, są te wewnętrzne. Big Data nie musi jedynie pomagać nam w wytworzeniu wartości końcowej. Równie dobrze możemy dzięki obsłudze dużych danych… zmniejszyć chaos w firmie. Nie trzeba chyba nikomu tłumaczyć jak zabójczy potrafi być chaos w organizacji. I jak łatwo powstaje.
Do danych wewnętrznych zaliczymy wszystko co jest “produktem ubocznym” funkcjonowania firmy. Na przykład dane dotyczące pracowników, projektów, ewaluacji itd. Także klientów, zamówień, stanów magazynowych. Jeśli uda nam się na to wszystko nałożyć dane geolokalizacyjne i garść informacji ze źródeł ogólnodostępnych, możemy zacząć budować sobie całkiem konkretne raporty dotyczące profili klientów. Gdy pozyskamy kilka wiader bajtów z serwisów promocyjnych i inteligentnie połączyć z resztą – możemy dowiedzieć się o racy firmy, klientach oraz nadchodzących okazjach znacznie więcej, niż wcześniej. I więcej, niż konkurencja;-).
Chmura czy własna infrastruktura? (Cloud vs On-Premise)
Gdy jesteśmy już świadomi branży Big Data oraz okoliczności, w jakich warto w nią wejść – zastanówmy się nad najbardziej fundamentalną rzeczą. Mowa o infrastrukturze komputerowej, którą będziemy wykorzystywać. Mówiąc bardzo prosto: nasze technologie muszą być gdzieś zainstalowane, a dane gdzieś przechowywane. Pytanie zwykle dotyczy wyboru między dwoma ścieżkami: albo będziemy mieli swoją własną infrastrukturę, albo wykorzystamy gotowych dostawców chmurowych.
Które podejście jest lepsze? Odpowiedź jest oczywista: to zależy. Nie ma jednego najlepszego podejścia. To przed czym chcę Cię w tym miejscu przestrzec, to przed owczym pędem w kierunku chmur. Zwykło się myśleć, że aplikacja działająca w chmurze, to aplikacja innowacyjna, nowoczesna, lepsza. To oczywiście nie jest prawda.
Czym jest Cloud a czym On-premise
Żeby w ogóle wiedzieć o czym mówimy, zacznijmy od uproszczonego wyjaśnienia, które jakoś nas ukierunkuje.
Własna infrastruktura (On-Premise, często skrótowo po prostu „on-prem”) – komputery, które fizycznie do nas należą, są przechowywane gdzieś „na naszym terytorium”. Samodzielnie łączymy je siecią, instalujemy tam odpowiednie oprogramowanie, synchronizujemy itd. Specjalnie do tego typu infrastruktury stworzona została m.in. popularna platforma Big Data Apache Hadoop. Stawiając on-premise musimy zadbać o samodzielną obsługę całości, natomiast koszt związany z zasobami jest „jednorazowy” w momencie zakupu sprzętu (potem oczywiście jeśli chcemy ją rozbudować).
Chmura (Cloud) – czyli instalacja odpowiedniego oprogramowania na komputerach (serwerach) udostępnionych przez zewnętrzną firmę. Taka firma (np. Microsoft ze swoją chmurą Azure) ma centra danych (data center) w różnych miejscach na świecie. Komputery te są ze sobą powiązane odpowiednimi sieciami i zabezpieczeniami. Szczegóły technologiczne na ten moment sobie darujmy (prawda jest taka, że to na tyle złożone tematy, że… z poszczególnych chmur (np. Azure czy AWS) robi się powszechnie uznawane certyfikaty – sam zresztą nawet jednym dysponuję;-)). Za chwilę odrobinę dokładniej opowiemy sobie jakie mamy dostępne możliwości wykorzystując chmurę. Teraz jednak to co trzeba zrozumieć, to że rezygnujemy z ręcznej obsługi zasobów. Oddajemy całość administracyjną fachowcom z konkretnej firmy. Gdy korzystamy z takich usług, nie wiemy na jakim dokładnie komputerze (komputerach, bardzo wielu) lądują nasze dane. Tak więc sporo „zabawy” nam odchodzi. Oczywiście coś za coś, natomiast o plusach i minusach porozmawiamy za chwilę.
Teraz wypadałoby podpowiedzieć jakie dokładnie są różnice. A jest ich dużo. Od przewidywalności, przez koszty (kilka ich rodzajów), kwestie prywatności danych, łatwość skalowalności aż po terytorialność danych. W tym miejscu chciałbym odnieść do moich dwóch artykułów:
W tym artykule daję takie proste zestawienie różnych aspektów. Zajmie Ci to chwilkę, a będzie bardzo dobrym punktem startowym.
Drugi artykuł jest dla ambitnych. Poruszam tam kwestie, które zazwyczaj nie są poruszane. Jest to pogłębiona analiza zagadnienia “Cloud vs On-prem”.
Jak zacząć budowę zespołu z kompetencjami Big Data?
Oto najważniejsze być może pytanie. Napiszę na ten temat osobny artykuł. Tutaj zerknijmy jednak skrótowo na temat, który jest niezwykle istotny, a wręcz powiedzmy sobie – kluczowy. Moment zainwestowania w kompetencje może być wybrany lepiej lub gorzej, ale źle zbudowany zespół będzie się mścić przez lata. Oznacza źle zaprojektowane systemy, źle napisany kod, a to – w efekcie – projekty, które po latach trzeba będzie wyrzucić do śmieci lub napisać od początku. A można uniknąć tego wszystkiego robiąc cały proces tak, aby miał ręce i nogi;-).
Znów – nie chcę rościć sobie praw do wyznaczania jedynie słusznej ścieżki rozwoju. Zaproponuję jednak kilka punktów, które mogą nakierować myślenie na metodyczne podejście, które w perspektywie się opłaci.
Po pierwsze – przygotujmy się
Nie róbmy wszystkiego na łapu capu. Trzeba mieś pewną wiedzę, która zaczyna się w kadrze menedżerskiej. Bez tego będziemy przepalać pieniądze. Niech menedżerowie nie oddzielają się grubym murem od technicznych. Zdobycie podstawowych informacji nie będzie techniką rakietową, a pozwoli podejmować lepsze decyzje.
W jaką wiedzę się uzbroić? (przykład)
Zbudowanie zespołu kosztuje. To podstawa, z którą warto się oswoić. Inżynierowie Big Data są drogimi specjalistami, szkolenie i doradztwo jest drogie. Prawdopodobnie cały proces nie zamknie się w kilkudziesięciu tysiącach złotych, choć kosztorys to zawsze bardzo indywidualna sprawa.
Jakie są dokładnie powody budowy zespołu z kompetencjami Big Data? To bardzo istotne, bo będzie wymuszało różny start, datę, technologie itd. Omawialiśmy to trochę wyżej.
Kiedy Chcemy wystartować?
Na jakim zespole bazujemy? Czy na jakimkolwiek?
Jakie są generalne technologie Big Data? Nie chodzi o szczegóły, ale o ogólne rozeznanie się w tym co istnieje na rynku.
Jaki jest nasz dokładny plan działania? Taka road-mapa powinna być przedyskutowana z początkowym zespołem, aby ludzie Ci mieli świadomość w którym kierunku idą.
Czy potrzebujemy infrastruktury? Być może nie, ale prawdopodobnie jednak na czymś trzeba będzie bazować.
Po drugie – wyznaczmy zespół
Zespół może być tworzony od zera, może być zrekrutowany. Bardzo prawdopodobne, że uda się zrobić opcję hybrydową, czyli wyszkolić kilku specjalistów do początkowego etapu, a zrekrutować seniora, który tym pokieruje.
Jeśli bazujemy na ludziach którzy już pracują w firmie, warto patrzeć na ludzi z doświadczeniem w Javie oraz bazach danych. Oczywiście podstawą jest doświadczenie z systemami Linuxowymi, oraza z gitem.
Po trzecie – przeszkólmy zespół
Jeśli mamy już zespół, warto go przeszkolić. Szczególnie tą część, która jest “świeża”. Należy dokładnie zastanowić się nad technologiami z jakimi chcemy ruszyć, jakie bedą potrzebne na początku. W ustaleniu dokładnego planu działania pomoże specjalna firma – tu polecam nas, RDF;-). Zapraszam pod ten link, gdzie można zapoznać się z ofertą szkoleń.
W tym miejscu dodam jeszcze jedno. Szkolenia można przeprowadzać doraźne i intensywne. Na przykład kilka dni bardzo mocnego treningu z Apache Spark. Jest jednak dostępna także inna możliwość, która tutaj sprawdzi się znacznie bardziej. To bardzo obszerne, długie szkolenia, które wyposażają kursantów w umiejętności z podstaw Big Data. Takie szkolenie może trwać nawet 2, 3 miesiące. Warto rozważyć;-).
Po czwarte – niech zespół zdobędzie pierwsze rany w walce
Kiedy mamy już cały zespół, warto zrobić pierwszy projekt. Jeszcze nie dla klienta. Najlepiej, żeby projekt ten miał swój konkretny cel, który przysłuży się firmie, będzie projektem Open Source lub choćby “wizytówką”. Niestety, nie wszystko wyjdzie w czasie szkoleń – nawet naszych;-) (mimo, że w ramach tego długiego szkolenia sporo czasu zajmuje mini-projekt właśnie). Wiele rzeczy musi zostać wypalonych w projektowym ogniu. Od stricte technicznych, przez organizacyjne, po kontakcie wewnątrz zespołu.
Po takim projekcie… cóż, sami najlepiej będziecie wiedzieć, czy zespół jest gotowy do działania. Być może potrzebne będą kolejne kroki, a być może wstępne doświadczenie będzie już wystarczająco solidne:-)
Podsumowanie
Uff, to był naprawdę długi artykuł. Cieszę się, że docieramy do końca razem! Jestem przekonany, że masz teraz już podstawową wiedzę na temat Big Data, w kontekście biznesowym. Oczywiście tak naprawdę zaledwie musnęliśmy temat. Jest to jednak już dobry start do dalszej pracy.
Jeśli potrzebujesz naszych usług, polecam z czystym sumieniem. Nasze szkolenia są tworzone z myślą, że mają być możliwie podobne do prawdziwego życia. My sami jesteśmy żywymi pasjonatami naszej branży. Bardzo chętnie Ci pomożemy – czy to w temacie nauki czy konsultacji. Nie bój się napisać!
Zachęcam także do dołączenia do naszej rodzącej się polskiej społeczności Big Data! Obserwuj RDF na LinkedIn, subskrybuj newsletter i daj znać że żyjesz. Będzie nam bardzo miło Cię gościć;-).
WAŻNA INFORMACJA! Jestem w trakcie pisania ebooka. Będzie w tematyce takiej jak ten artykuł, jednak bardziej “na spokojnie” oraz dogłębniej. Co więcej – będzie za darmo dostępeny! Dla każdego? NIE. Jedynie dla zapisanych na newsletter. Zapisz się już dzisiaj i zyskaj wpływ na proces twórczy;-)
Właśnie skończyłem kolejne szkolenie (nie byle jakie, bo to było 2-miesięczne, kompleksowe – serio, hardcore). Uświadomiło mi ono jedną bardzo konkretną rzecz w kontekście naszego zrozumienia systemów Big Data. Chciałem się nią podzielić. Artykuł przede wszystkim do technicznych, ale… nie tylko. Zdecydowanie nie tylko.
Złożoność – nasz główny wróg
Podchodząc do systemu przetwarzania bardzo dużych ilości danych, mamy jednego podstawowego wroga. Staje przed nami niczym behemot już na poziomie koncepcji. Jest to… stopień złożoności problemu. Przyznajmy szczerze – nie lubimy złożonych problemów. Ani w życiu prywatnym, ani zawodowym. Aby rozwiązać taki problem, należy wytężyć mózgownicę do takich granic, które u niektórych powodują niemały ból.
Szczególnie daje się to we znaki, gdy ktoś przeszedł do Big Data z “tradycyjnej IT”. Jeśli robiłeś wcześniej aplikacje webowe, możesz doznać szoku. I nie mówię nawet o tym, że dotychczas wszystkie Twoje problemy zawarte były w jednym pliku z logami, podczas gdy tutaj nawet pojedyncza technologia ma kilka serwisów, a każdy z nich swoje własne logi.
Po prostu złożoność jest inna. Robiąc aplikację webową (zostańmy przy tym), mam jasne wytyczne, standardy i zwykle prostą ścieżkę, którą uruchamia (najczęściej) użytkownik. Wejdziemy pod odpowiedni adres? W takim razie musimy wysłać zapytanie do bazy danych, dokonać kilku obliczeń i wyrenderować stronę końcową.
Gorzej, jeśli trzeba zbudować cały skomplikowany system, a wejście (rozumiane jako input)… cóż, wejścia czasami nie ma. Albo jest ich bardzo, bardzo wiele. Albo – co gorsza – jest wejście, wyglądające bardzo “tradycyjnie”(np. request użytkownika).
Jak zaprojektować system – problem złudnego “wejścia” (inputu)
Przypuśćmy taką prostą sytuację. Robimy aplikację-wyszukiwarkę filmów związanych z danymi miastami. W efekcie wpiszemy nazwę miasta, a otrzymujemy listę miast, które w ten czy inny sposób dotyczą go (czy to w kontekście tematyki czy lokalizacji).
Bardzo łatwo w takiej sytuacji zacząć całe projektowanie wychodząc od użytkownika i mając przeświadczenie, że to on musi uruchamiać całą machinę. No świetnie, zatem wcielmy się w taką rolę. Użytkownik wpisuje nazwę miasta i… i co? Czy mam teraz starać się wyszukiwać po internecie wszystkich możliwych informacji? Byłoby to całkiem, całkiem długotrwałym procesem.
No dobrze, więc może zacząć zbierać oraz przetwarzać dane, osobno? Pomysł dobry. Jednak i tutaj można łatwo wpaść w pułapkę wąskiego myślenia. Ciągle mamy z tyłu głowy użytkownika, więc zaczynają powstawać dziwne pomysły, na uruchamianie przetwarzania po wykonanym requeście, w trakcie itd. Ciągle mamy tą manierę, że staramy się wychodzić od jednego punktu i przejść przez wszystkie elementy systemu. To trochę tak, jakbyśmy starali się złapać bardzo dużo drewnianych klocków na raz. Nie ma szans – wypadnie. Kto próbował ekspresowo posprzątać po zabawach swoich dzieci u Dziadków, wie o co chodzi.
Słowo klucz: decentralizacja
Prowadząc szkolenie, gdzieś w połowie zorientowałem się, że coś jest nie tak. Zbadałem temat i zauważyłem, że kursanci bardzo dziwnie podeszli do budowy modułów. Chodziło konkretnie o te podstawowe rzeczy, jakimi jest wejście i wyjście aplikacji (input i output) oraz zarządzanie całością. Zasadniczo cały projekt opierał się oczywiście o bardzo wiele mniejszych modułów. Niektóre pobierały dane z internetu, inne te dane czyściły i przetwarzały. Jeszcze inny moduł – streamingowy – służył do kontaktu użytkownika z systemem.
W pewnym momencie, po raz kolejny dostałem pytanie, które brzmiało mniej więcej tak: “No, skoro mamy mnóstwo małych modułów, to chyba musimy też gdzieś zbudować skrypt, który to wszystko uruchamia prawda?“. Uznałem, że czas na radykalną zmianę myślenia, przerwanie “starego” paradygmatu i zrozumienia o co chodzi w systemach do przetwarzania i obsługi dużych danych.
Myśl po nowemu – czyli jak poprawnie patrzeć na systemy Big Data?
Oczywiście nie ma jednej złotej zasady, dzięki której zrozumiemy “filozofię Big Data”. Jest jednak coś, czego zrozumienie może być przełomem. Pozwoli wygrać ze złożonością, pozwoli zrozumieć duży, skomplikowany system. Pomoże – wreszcie – przestać siwieć (albo, jak w moim przypadku jest – łysieć) z frustracji.
Otóż, chodzi o magiczne słowo: decentralizacja. Nie, mowa nie o technologii blockchain;-). Chodzi o umiejętność spojrzenie na cały system metodą “od ogółu do szczegółu” i zrozumienie poszczególnych elementów (modułów lub powiązań między nimi). Spójrzmy na kilka kwestii, które to tłumaczą.
Każdy wielki system zbudowany jest z wielu mniejszych (co nie znaczy małych) modułów. Na etapie rozumienia całości, nie musimy wgłębiać się w technikalia czy implementację. Wystarczy nam ogólna wiedza o tym co dany moduł przyjmuje, a co zwraca (jakie jest jego zadanie). Dodatkowo jeśli wiemy z jakimi modułami łączy się (bezpośrednio, lub na poziomie logicznym) to już w ogóle bardzo dużo.
Każdy moduł ma swoje zadanie. Niekoniecznie musi być zależne od innych modułów! Przykładowo, jeśli potrzeba nam w systemie pogody, to potrzeba nam pogody. Nie musimy wiązać tego z modułem, który pobiera filmy, albo składuje requesty od użytkownika. W momencie rozumienia modułu od pogody, musimy zbudować mechanizmy pobierające pogodę. Jak to zrobimy? Z wykorzystanie pythona, javy? A może Nifi?
Każdy moduł może być uruchamiany niezależnie od użytkownika. I tutaj musimy znać miejsce takiego podsystemu w systemie.
Jeśli jest niezależny od czegokolwiek – wystarczy prosty skrypt oraz jakiś scheduler, typu Airflow czy Oozie. Pogodę możemy pobierać co godzinę niezależnie od wszystkiego.
Jeśli jest zależny, musimy wiedzieć w jaki sposób jest zależny. Znów najprawdopodobniej użyjemy schedulera, ale pewnie uzależnimy go od wyników innych modułów (jeśli dane nie zostały pobrane, nie ma sensu uruchamiać czyszczenia).
Może się okazać, że moduł naprawdę jest w ścisłym kontakcie z użytkownikiem. W takiej sytuacji, po prostu musimy to dobrze umieścić.
Gdy pracujemy z danym modułem, możemy się zagłębić w szczegóły, a jednocześnie “zapomnieć” o reszcie systemu. Gdy – znów – zaciągamy dane pogodowe, nie musimy myśleć o tym jak one potem zostaną wykorzystane. Dzięki temu usuwamy element, który nas przytłacza. Aby to zrobić – to istotne – powinniśmy wcześniej dobrze zaprojektować całość, łącznie z szczegółowo opisanym wyjściem (output’em). Jakie dokładnie dane pogodowe muszę zwrócić? Gdzie je zapisać? Do jakiej tabeli? Z jaką strukturą? To wszystko powinno być spisane na etapie projektowania, przed implementacją.
Podsumowanie
Tak więc, wracając do problemu ze szkolenia – nie, nie musimy mieć żadnego skryptu, który uruchamia moduły jeden po drugim. Wręcz byłoby to zabiciem idei. Moduły za to powinniśmy uruchamiać w którymś z wyspecjalizowanych schedulerów (polecam Airflow). Dzięki nim możemy przeznaczyć do regularnego startu konkretny moduł, albo połączyć go z innymi. Do tego możemy obsłużyć różne wyniki (np. wysłać email, jeśli coś pójdzie nie tak), przejrzeć logi itd.
Zdaję sobie sprawę, że to co przedstawiłem powyżej, dla wielu jest banałem. Jest jednak taki etap (na początku), gdy trzeba “przeskoczyć” na inne myślenie. I warto zacząć właśnie od kwestii decentralizacji.
Między innymi takich rzeczy, poza stricte technicznymi, uczę na naszych RDFowych szkoleniach. Przejrzyj te, które możemy dla Was zrobić, a potem przekonaj szefa, że solidnie wykwalifikowany zespół, to lepsze wyniki firmy;-).
Zachęcam także do dołączenia do naszej rodzącej się polskiej społeczności Big Data! Obserwuj RDF na LinkedIn, subskrybuj newsletter i daj znać że żyjesz. Razem możemy więcej!
Jeśli czegoś nie wiem – wchodzę w wyszukiwarkę i zdobywam wiedzę. Można powiedzieć, że wyszukiwarka to swoisty “rdzeń” internetu. Mogę tam znaleźć wszystko. Punkt wyjścia do wiedzy całej ludzkości. Tak jest dzisiaj. Tylko, że 25 lat temu… nikt tak nie myślał. Nawet nie było takiej możliwości. “Szukaj” to znakomita książka, która opisuje rozwój wyszukiwarek internetowych, z Google w roli głównej. Jednak najciekawszą rzeczą jest to, że napisana została 2005 roku. Z dzisiejszej perspektywy wiemy znacznie więcej i możemy zweryfikować niektóre fakty. Zapraszam do pierwszej recenzji książki na blogu RDF –“Szukaj – Jak Google i konkurencja wywołali biznesową i kulturową rewolucję”.
O czym jest, a o czym nie jest książka “Szukaj”?
Cóż, wbrew pozorom (oraz wbrew okładce), nie dostaniemy wcale historii Google. Nie dostajemy tu także życiorysu Siergieja Brina ani Larry’ego Page’a (założycieli Google). Wbrew temu co można pomyśleć czytając tytuł – nie będzie o kształtowaniu współczesnej debaty i problemach z cenzorowaniem treści o zabarwieniu konserwatywnym. Nie będzie, bo książka została napisana w roku 2005, a nie 2020.
Żeby właściwie oddać skalę czasu powiem tylko, że 2005 rok to 7 lat po założeniu Google. Obecnie zbliżają się już… 23 lata technologicznego giganta. Historia Google to niemalże historia Internetu. W czasie, w którym pisane były stronice “Szukaj”, nie było jeszcze Androida, Youtuba (w obecnym kształcie) ani Google Drive. Była za to… wyszukiwarka. Jedna z najnudniejszych usług o jakich można pomyśleć.
Czy na pewno? Książka zręcznie pokazuje, że wcale nie. Pokazuje drogę, jaką przeszły wyszukiwarki oraz cały kontekst. Opisuje rzeczy, które wydają się być z innego świata – długie dyskusje i zastanawianie się, czy opcja wyszukiwarki (nawet na pojedynczej stronie) jest dobrym i potrzebnym pomysłem. John Batelle maluje nam naprawdę kompleksowy obraz – włączając technikalia, aktualny rozwój internetu oraz rywalizację biznesową, a nawet kulturową (poruszany jest wątek chiński). Choć napisałem, że nie jest to książka o Google, to w rzeczywistości dostajemy kawał historii tej firmy. Stajemy się bliskimi obserwatorami przeżyć i przemyśleń dwóch założycieli, pierwszych pracowników firmy oraz ich konkurencji. To wszystko pozwala nam dostrzec, jak dynamiczna była sytuacja oraz jak wiele problemów musiała rozwiązać dwójka doktorantów Stanforda.
Pierwsze wyszukiwarki nie przypominały w niczym dzisiejszych. Na obrazku jeden z pionierów wyszukiwania internetowego – AltaVista
Jak wyglądał internet… 25 lat temu?
Wyobraź sobie, że chcesz się podzielić zdjęciami ze znajomymi. Nie wyślesz ich przez Signal czy Messenger. Nie zamieścisz na Instagramie. Pomyśl sobie, że chcesz się przekwalifikować. Co robisz? Na pewno nie wejdziesz do internetu, żeby poszukać dobrego kursu z danej dziedziny – po prostu nie ma ani takich kursów, ani… możliwości prostego wyszukania. Jedziesz do innego miasta? Zapomnij o GPS – przecież nie jesteś amerykańskim Marine! Nie umieścisz w sieci szybkich informacji, wiadomości sprawdzisz dopiero po wizycie w kiosku a żeby czymkolwiek zapłacić, musisz mieć gotówkę (lub czek).
To nie jest katastroficzna wizja sparaliżowania ludzkości. To nie jest też opis ery kamienia łupanego, wymalowany na ścianie jaskini. To opis naszego świata zaledwie 20-25 lat temu. TAK – było całkiem analogowo! Druga połowa lat 90′ to dopiero raczkujący Internet, raczej nowinka. Pamiętajmy, że chociaż sama technologia Internetu jest bardzo ciekawa, to naprawdę rewolucyjna staje się dopiero wtedy, gdy jest wypełniona treścią. Dziś wiadomo, że w jakiejś formie trzeba być obecnym w Internecie, jeśli prowadzisz działalność. Wtedy było to równie popularne, co współcześnie umieszczanie banerów nad pisuarem w pubie. Tak więc pierwsza rzecz jaką autor nam uświadamia: dzisiaj wiadomo, że na każde pytanie odpowiedź znajdę w internecie, wtedy absolutnie nie było takiego przeświadczenia.
To były czasy tzw. Web 1.0. Czasy twórców i statycznych stron. Użytkownicy byli jedynie biernymi obserwatorami. Przypominało to nieco tak naprawdę tradycyjne media, przede wszystkim gazety, z którymi nie możemy nawiązać żadnej interakcji, ale które możemy przeglądać. Tyle tylko, że Internet był dostępny na ekranie, a nie w formie gazety. No i mieliśmy dostęp do wielu twórców… o ile mieliśmy ich adresy.
Search 1.0 – czyli jak to się zaczęło, z tym wyszukiwaniem?
Archie, australopitek wśród wyszukiwarek
Jednym z ciekawszych aspektów książki jest wycieczka po pierwszych, dawno zapomnianych wyszukiwarkach. W zasadzie jedyne w czym przypominały obecne, to fakt, że istnieje tam jakieś okienko, w które coś możemy wpisać, a na końcu dostajemy jakieś wyniki. Poza tym – absolutnie wszystko było inne. Wszystko zaczęło się od sympatycznie brzmiącej Archie. Aby nadać kontekst, przywołajmy słowa samego Autora:
“W roku 1990 naukowcy i technicy regularnie używali Internetu do składowania prac naukowych, specyfikacji technicznych i innego rodzaju dokumentów na publicznie dostępnych komputerach. Jednak bez znajomości dokładnego adresu komputera i nazwy pliku znalezienie tych archiwów graniczyło z niemożliwością. Program Archie przeszukiwał internetowe archiwa (stąd jego nazwa) i tworzył indeks każdego znalezionego pliku.”
Archie to pierwsza wyszukiwarka, dzięki której można było przeczesywać internetowe archiwa.
Jak wyglądała Archie? Mniej więcej tak jak to widać powyżej. Swoją drogą, Archie miała swoje narodziny 10 września 1990 r. Co prawda było to 3 lata przed narodzinami autora tego artykułu, ale za to urodziny możemy obchodzić niemal razem (09.09);-). Co ciekawe – z wyszukiwarki można skorzystać nawet teraz, pod tym linkiem (choć raczej jedynie w ramach ciekawostki).
Warto jednak powiedzieć w jaki sposób Archie działała (działał?). Wyszukiwarka odbierała zapytania zbudowane ze słów kluczowych. Następnie przeszukiwała archiwa poszukując tych słów w nazwach plików. Po wszystkim, jako wynik zwracała listę miejsc, w których owe pliki znaleziono. Nie jest wielką sztuką dostrzec, że rozwiązanie to było podobne do współczesnych wyszukiwarek podobnie, jak australopitek do nas. Problematyczne było zarówno to, że zwracane nie były pliki a lokalizacje, jak i to, że indeksowane były jedynie tytuły. Trzeba było mieć więc albo wiedzę, że taki dokument istnieje, albo mieć znakomitego nosa.
Altavista, czyli pierwszy mocny przełom
Lata później sprawy zaczęły nieodwracalnie pędzić w kierunku, który mamy współcześnie. Nie chodzi tu jednak o kwestię wyszukiwarek, a o dynamikę rozwoju Internetu. W 1995 roku sieć liczy już 10 mln witryn i rozwija się w absurdalnym tempie 2000% rocznie. Oczywistym staje się, że ogarnięcie takiego zbioru danych będzie bardzo, bardzo trudne. Nie chodzi, pamiętajmy, o samo zebranie (co już jest wyczynem), ale także o przeszukiwanie w czasie rzeczywistym. Potrzeba byłoby jakiegoś… superkomputera.
I tutaj z pomocą przychodzi firma DEC (Digital Equipment Corp.) ze swoją Alta Vistą. Historia powstania tej wyszukiwarki jest niejasna. Powtarzający się jednak motyw jest taki, że firma stała na krawędzi upadku. Jak tlenu potrzebowała pieniędzy oraz dobrego PR. I tu pojawił się pomysł, żeby dla nowego superprocesora napisać coś, co będzie imponującym eksperymentem pokazującym jego możliwości. W ten sposób Louis Monier zabrał się do pracy, w efekcie tworząc przełomową wyszukiwarkę internetową – Alta Vistę. Różniła się od innych obecnych na rynku tym, że nie indeksowała jedynie adresów url, ale całe strony oraz… no własnie, indeksowała je w ogromnym tempie, dzięki wysłaniu “na łowy” nie jednego crawlera, a… tysiąc. Było to możliwe właśnie dzięki procesorowi.
Niestety, Alta Vista została z czasem wyprzedzona przez Google. Po drodze przeszła długą wędrówkę miotając się między rozmaitymi decyzjami biznesowymi, kilkukrotnymi próbami wejścia na giełdę, zmianą właścicieli, aż w końcu żywot swój dokonała w Yahoo! w 2013 roku. Alta Vista jest wzorcowym przykładem tego co dzieje się, gdy nie umiemy dostosować biznesu do zmieniającej się rzeczywistości.
Baza Intencji – wyszukiwanie, jako “rdzeń” Internetu oraz Big Data
Powoli dochodzimy do sedna, które moim zdaniem najmocniej pokazuje jaką potęgę od początku trzyma w swoich rekach Google. Jeśli ktoś nie będzie mógł przebrnąć przez książkę – najlepiej przeczytać chociaż pierwszy rozdział “Baza Danych Intencji”. Bardzo często w debacie przewija się pytanie o to kto jest na naszym świecie najbardziej wpływowy. Wymieniamy tu zwykle polityków i biznesmenów. No więc jak myślisz, jaki rodzaj biznesu ma największy wpływ na nas wszystkich? Dostawcy ropy? Media? Blisko. Kiedy nad tym pomyślimy, dojdziemy do oczywistego wniosku, że największy wpływ mają na nas ci, którzy nas najlepiej znają. Zwykle to była nasza rodzina, przyjaciele, czasami przebiegli politycy.
Problem polega jednak na tym, że oni wszyscy widzą pewną powłokę, którą chcemy (lub nie) im sprzedać. Nawet jeśli z kimś rozmawiamy, modelujemy intencjami, które z nas wychodzą. A co, jeśli… mieć dostęp do samego wnętrza naszego mózgu? Bez wszystkich filtrów, po prostu – jeśli znać nasze myśli, które wychodzą prosto z mózgu (czy też “z serca”)?
Właśnie w takiej pozycji usadził się Google. Jak pisze John Battelle, zdał sobie sprawę z tego jaką potęgę trzyma Google, gdy przeglądał wydanie Google Zeitgeist podsumowujące 2001 rok (Google Zeitgeist to poprzednik Google Trends). w tamtym czasie najpopularniejszymimi wyszukiwania były: Nostradamus, CNN, World Trade Center, Harry Potter, wąglik. Lista tracących popularność fraz wskazywała, że ludzie przestawali interesować się głupotami: Pokemon, Napster, Big Brother, X-Men, zwyciężyni teleturnieju “Kto chce poślubić multimilionera”.
Jak napisał Autor:
“Byłem w szoku. Zeitgeist ukazał mi, że Google nie tylko trzyma rękę na pulsie kultury, ale tkwi bezpośrednio w jej systemie nerwowym. Tak wyglądało moje pierwsze zetknięcie z tym, co później nazwałem Bazą Danych Intencji – żywym artefaktem o wielkiej mocy. >>Dobry Boże<<, pomyślałem sobie, Google wie, czego szukają ludzie! Stwierdziłem, biorąc pod uwagę miliony zaputań zmierzających każdej godziny do serwerów Google, że firma ta siedzi na kopalni złota. Na podstawie zgromadzonych w niej informacji o ludzkich zamiarach można by utworzyć wiele przedsiębiorstw prasowychL w istocie pierwsze – eksperymentalny >>Google News<< – już powstało. Czy Google nie mogło założyć też firmy zajmującej się badaniami i marketingiem, która mogłaby precyzyjnie informować o tym, co ludzie kupują, co chcą a czego unikają?”
I tutaj właśnie leży sedno. Wyniki wyszukiwania są zakryte przed znajomymi. Znamy je tylko my i maszyny Google. Udajemy się tam tylko wtedy, gdy chcemy coś znaleźć, czegoś się dowiedzieć. Szkodzilibyśmy więc sobie bez pożytku, gdybyśmy udawali. Jesteśmy szczerzy, naturalni. Google dokładnie wie, czego poszukujemy, czym żyjemy, czego pragniemy. To właśnie autor nazwał Bazą Danych Intencji. Kto więc może być najbardziej wpływowy? Oczywiście – firma, która ma dostęp do naszego serca, naszej świadomości, pragnień… i która to firma może na tym robić pieniądze oraz zręcznie modelować wynikami.
Moim zdaniem właśnie dlatego przeszukiwanie to samo sedno zarówno internetu, jak i Big Data. Docieramy do samego sedna i przetwarzamy najbardziej “szczere” dane, aby poznać prawdę o nas. Jakkolwiek górnolotnie by to nie brzmiało, jest to prawda i olbrzymia moc. A jak wiadomo – “Z wielką mocą wiąże się wielka odpowiedzialność ;-).
Google wczoraj, Google dzisiaj, czyli jak autor widział przyszłość?
Podtytuł ten to parafraza rozdziału “Google dzisiaj, Google jutro”, który jest pewną próbą przewidzenia przyszłości. Z dzisiejszej perspektywy, po niemal 16 latach, możemy powiedzieć, czy trafną;-).
Rywalizacja z Yahoo (i Microsoftem)
Autor zaznacza, że:
“Konkurencja Google jest bardzo liczna, ale najważniejszym z rywali, przynajmniej w latach 2005-2006 jest Yahoo. W roku 2007 trzeba też będzie stawić czoła przygotowującemu najcięższą artylerię Microsoftowi, ale na dzień dzisiejszy głównym wrogiem Google jest Yahoo”
Zacznijmy od tej drugiej części – Microsoft. Być może Autor miał na myśli wyszukiwarkę Msn Search, która weszła jednak do użycia w 2005 roku. W chwili inauguracji indeksowała 5 mld stron i była używana przez 1/6 internautów. Następnie przekształciło się w Windows Live, aby zostać przemianowane na Bing.
Jeśli chodzi o Yahoo, nie była i nie jest to stricte wyszukiwarka. Oczywiście funkcja wyszukiwarki oczywiście także istnieje, natomiast inne elementy są znacznie silniejszym atutem firmy (jak na przykład Yahoo Finance).
Jak wyglądają obecnie procentowe udziały w całym torcie wyszukiwarek na świecie?
Google – 91.95%
Bing – 2.93%
Yahoo – 1.51%
Można powiedzieć, że z jednej strony faktycznie najsilniejsza konkurencja pozostała najsilniejszą konkurencją. Tyle, że realnie Google jest monopolistą.
Wielki system operacyjny WWW działający na infrastrukturze Google
Najbardziej śmiała wizja przytoczona przez autora to utworzenie wielkiego systemu operacyjnego, który łączy różne urządzenia i usługi. Taki system miałby działać na infrastrukturze Google. Następuje tu analogia do Microsoftu, który postawił komputer w każdym domu i zainstalował na nim Windowsa. Niedługo – według Battella – będziemy pracować na jednym wielki systemie. Tam będą składowane dane, tam będziemy rozmawiać, pracować itd.
Dzięki temu Google uda się zrealizować swoją misję o “uporządkowaniu światowych zasobów informacji, aby stały się one powszechnie dostępne i użyteczne”.
“Misja Google, polegająca na porządkowaniu i udostępnianiu światowych informacji, pozwala spółce udostępniać wszystkie usługi, które mogą się naleźć na komputerowej platformie – od codziennych aplikacji jak przetwarzanie tekstu i arkusze kalkulacyjne (w tej chwili domena Microosftu), do bardziej futurystycznych usług, takich jak wideo na żądanie, składowanie osobistych mediów, albo nauka na odległość.“
Cóż, sądzę że ta śmiała wizja została w większości zrealizowana. Co prawda w pomyśle Autora Google byłby hegemonem, który staje się głównym dostawcą całego życia (dalej jest mowa także o dostarczaniu kablówki, bycie uniwersytetem itd). W tym zakresie nie udało się Google zawłaszczyć całego tortu – moim zdaniem na szczęście. Są inne przestrzenie, takie jak Microsoft Teams, Zoom, wirtualne dyski itd.
Znakomita większość jednak… ma miejsce! Mamy przecież Hangouts, mamy Google Drive (w tym dokumenty i arkusze kalkulacyjne). Co więcej – mamy androida, a nawet Google Street View, tak więc firma weszła na obszary, które (pozornie) z wyszukiwaniem nie mają wiele wspólnego. Stanowi to naprawdę wysoki kunszt wizjonerski Johna Battella i należy mu oddać szacunek.
Google Video, poprzednik YouTube. Wielki gigant nie zawsze może rywalizować z niezależnymi usługami.
Youtube
“Kolejnym ważnym trendem jest wzrost popularności wideo. W zeszłym roku YouTube, serwis udostępniania plików filmowych, stał się jednym z największych w sieci, a w reklamę wideo zainwestowano setki milionów dolarów. Mimo, że produkt Google Video jest nowatorski i popularny, firma ta w oczach opinii publicznej przegrała z YouTube. Czy Google pozostanie miłe dla firm typu YouTube, indeksując ich zawartość i ograniczając się do roli centrali telefonicznej, tak jak w przypadku tekstu? Czy też spróbuje rywalizować poprzez własną usługę, z nadzieją na przechwycenie całego naszego zainteresowania, tak jak to robiły stare sieci (ABC, CBS, NBC)? Nie znamy jeszcze odpowiedzi, ale same pytania są bardzo ciekawe”
To chyba mój ulubiony cytat;-). Google Video można zobaczyć powyżej (obecnie także dostępne, ale w zupełnie innym celu i formie). Tak więc, cóż… dziś już znamy odpowiedzi na te pytania. Google wykupiło YouTube, pozyskując tym samym ogromną rzeczywistość, rzeczywistość filmów. Nawiasem mówiąc, poprzez Youtube (i system rekomendacji) ma gigantyczne możliwości oddziaływania na nasz styl myślenia.
Podsumowanie
John Battelle wykonał kawał roboty pokazując historię wyszukiwania. Zrobił jednak jeszcze więcej roboty, ukazując jak bardzo potężnym sednem całej branży może być wyszukiwanie. Z całą pewnością wrażenie powinno zrobić z dzisiejszej perspektywy to, do jakiego punktu doszedł Google. Nie jest to już jedynie wyszukiwarka – to ogromny moloch, który dostarcza nam całą gamę usług, z których korzystamy. Uczy się każdego naszego ruchu i upraszcza życie. Ma to oczywiście swoją cenę. Pytanie “czy jesteśmy gotowi ją płacić?” pozostaje otwarte – do odpowiedzi przez każdego z osobna.
Ja ze swojej strony na pewno polecam “Szukaj”. Lektura pouczająca i mocno wgryzająca się w całą sprawę.
Polecam także oczywiście naszą stronę na LinkedIn oraz newsletter, dzięki któremu zostaniemy w kontakcie;-).
XXI wiek to okres głębokiej rewolucji w kwestiach kosmicznych. Najpierw kosmos został kompletnie zdeprecjonowany (łącznie z rozważaniami nad likwidacją NASA za Barracka Obamy). Następnie powstały bezprecedensowe próby rozwinięcia podboju kosmosu przez… sektor prywatny, z Elonem Muskiem na czele. Potem do gry weszli Chińczycy, którzy postawili Stanom Zjednoczonym potężne wyzwanie i… zaczęło się. Cała ta wielka przygoda nie mogła oczywiście odbyć się bez nowoczesnych technologii przetwarzania danych. Tak Big Data weszła do New Space.
New Space
Sektor prywatny pokazał, że do kosmosu można podchodzić w zupełnie nowy sposób. “Po rynkowemu” – z konkurencją, obniżając ceny, grając jakością, wskazując zupełnie nowe pola do rozwoju, a nade wszystko – robiąc na tym solidny biznes.
Odpowiedzią na rozwój sytuacji po stronie Chin oraz rodzących się nowych możliwości były śmiałe pomysły rządu Amerykańskiego – program powrotu człowieka na księżyc “Artemis” (wraz z Artemis accords) oraz utworzenie Space Force (sił kosmicznych).
Powstała całkowicie nowa domena – ochrzczona jako New Space. Wraz z “Baronami kosmosu” (wielkimi przedsiębiorcami wykładającymi swoje pieniądze na rozwój sektora kosmicznego), rywalizacją między mocarstwami i… coraz szybszym postępem technologicznym, który wykorzystywany jest obficie w życiu codziennym milionów osób.
A teraz pytanie retoryczne: czy mogą tak olbrzymie posunięcia technologiczne obyć się bez Big Data? Odpowiedź jest znana. I właśnie dlatego czas liznąć temat Big Data w New Space.
W tym artykule chcę podejść do sprawy bardzo ogólnie, fragmentarycznie i technicznie zarazem. Przedstawię kilka miejsc o których wiemy, że wykorzystywane są technologie Big Data oraz jakie dokładnie. Niech będzie to zaledwie zajawką tego olbrzymiego tematu, jakim jest Big Data w kosmosie. Będziemy go zgłębiać w późniejszych materiałach, ale teraz – po prostu liźnijmy tą fascynującą rzeczywistość;-)
Big Data w JPL (NASA)
Pierwszym kandydatem, którego powinniśmy odwiedzić jest amerykańska NASA, a konkretnie JPL. Jet Propulsion Laboratory to centrum badawcze NASA położone w Kalifornii, które odpowiada za… naprawdę całą masę rzeczy. Niektórzy utożsamiają JPL (JPL – nie JBL, czyli firmy od naprawdę fajnych głośników;-)) z pracą nad łazikami. Słusznie, ale rzeczy które leżą w ich zasięgu jest cała masa.
Według JPL na potrzeby NASA zbierane są setki terabajtów… każdej godziny. Setki Terabajtów! Czy jesteśmy w stanie wyobrazić sobie tak gigantyczne dane? Wystarczy pomyśleć o liczbach, które się generują po miesiącu, dwóch, trzech latach… No jednym słowem: kosmos.
Czego wykorzystują do przetwarzania i analizy takich potwornych ilości danych amerykańscy inżynierowie z NASA? Mamy tu dobrze znane name technologie. Z pewnością jest ich więcej, ja dotarłem do takich jak:
Hadoop
Spark
Elasticsearch + Kibana
Apache Spark w JPL (NASA) – SciSpark
Oczywiście szczególnie mocno, jako freaka na tym punkcie, cieszy mnie użycie Sparka;-). Jeśli chcesz się dowiedzieć na jego temat coś więcej – dobrze będzie jak zaczniesz od mojej serii “Zrozumieć Sparka”. Pytanie – do czego wykorzystywany jest Apache Spark w JPL? Oczywiście do przetwarzania zrównoleglonego danych pochodzących z łazików, satelit i czego tam jeszcze nie mają.
Co ciekawe jednak, inżynierowie big data w JPL utworzyli osobny program, który nazwali SciSpark. Program jest już niestety zarzucony, ale warto rzucić na niego okiem. Nie znalazłem informacji o przerwaniu prac, jednak wskazują na to przestarzałe treści, oddanie projektu fundacji Apache oraz ostatnie commity z 2018 roku. Na czym jednak polegał SciSpark? Jak wiadomo NASA i generalnie technologie kosmiczne to nie tylko wyprawy na Marsa, Księżyc i badanie czarnych dziur w galaktykach odległych o miliard lat świetlnych. To także, a może przede wszystkim, poznawanie naszego miejsca do życia – Ziemi. I program SciSpark powstał właśnie po to, aby pomagać w przetwarzaniu danych dotyczących naszego środowiska, zmian klimatycznych itd. I tak Big Data pomaga nie tylko w eksploracji “space”, ale także “ze space” pomaga poznawać Ziemię.
SciSpark Technicznie
Wchodząc w temat bardzo technicznie– program został napisany przede wszystkim w Scali. Chociaż twórcy zdają sobie sprawę, z istnienia PySparka oraz tego, że python jest naturalnym językiem Data Sciencystów, uznali że nie będzie odpowiedni ze względów wydajnościowych. Jak mówią sami:
“Ten Spark (w scali – dopisek autora) został wybrany by uniknąć znanych problemów związanych z opóźnieniami (latency issue) wynikających z narzutu komunikacyjnego spowodowanego kopiowaniem danych z workerów JVM do procesu deamona Pythona w środowisku PySpark. Co więcej – chcemy zmaksymalizować obliczenia w pamięci, a w PySparku driver JVM zapisuje wynik do lokalnego dysku, a następnie wczytuje przez proces Pythona”.
Trzon SciSpark polega na rozszerzeniu sparkowych struktur RDD (Resilient Distributed Dataset) i utworzeniu nowych – sRDD (Scientific Resilient Distributed Dataset). Struktury te mają być dostosowane bardziej do wyzwań naukowców. W jaki sposób dokładnie, z chęcią zgłębię kod SciSparka i napiszę o tym osobny artykuł, dla chętnych geeków;-).
Poza Sparkiem, SciSpark posiada oczywiście całą architekturę systemu – z HDFSem, użytkownikami i interfejsem użytkownika (UI) włącznie. Poniżej ona – dla ciekawskich;-).
Co ciekawe, SciSpark został upubliczniony i udostępniony fundacji Apache. Efekt jest oczywisty – teraz także i Ty możesz przeczesać kod, który pierwotnie tworzyli inzynierowie big data z NASA. Publiczne repozytorium znajdziesz tutaj.
Hadoop w NASA
Oczywiście przetwarzanie przetwarzaniem, ale gdzieś trzeba te dane przechowywać. Służy ku temu kolejna świetnie znana nam technologia, czyli Hadoop. Konkretniej być może warto powiedzieć hadoopowym systemie plików, czyli HDFS. To bardzo intuicyjny i dość oczywisty wybór, ponieważ HDFS pozwala rozproszyć pliki na wielu maszynach, co w przypadku tak ogromnych danych jest absolutnie niezbędne.
Prawdopodobnie – tu moja osobista opinia – z biegiem lat będzie trzeba przerzucić się na coś “nowszej generacji” z powodu różnych problemów i ograniczeń HDFSa. Być może dobrym pomysłem byłoby wykorzystanie Apache Ozone. Nie znalazłem informacji czy ktokolwiek w NASA wykorzystuje ten system z przyczyn dość banalnych (pomyśl tylko co wyskoczy gdy wpiszesz “NASA Ozone” w wyszukiwarkę). Wydaje mi się jednak – po pierwszych próbach wykorzystania Ozone, że musi w Wiśle jeszcze trochę wody upłynąć, zanim technologia dojrzeje.
W kontekście storowania plików, warto wspomnieć jakie to dokładnie są pliki. Oczywiście w systemach NASA budowane są liczne ETL’e, a więc i surowe pliki z pewnością są bardzo rozmaitych formatów. Jeśli jednak dane są już przetworzone, to z grubsza zapisywane są w dwóch formatach:
HDF – czyli Hierarchical Data format – to format plików, który został wymyślony już w ubiegłym wieku. Od początku projektowany był tak, żeby mógł przechowywać duże dane. Od początku też – co ważne – wykorzystywany był przez NASA. Nie jest wielką tajemnicą, że tego typu instytucje nie mają zwrotności bolidu F1. Jeśli już do czegoś się przyspawają, pozostanie to z nimi na wieki;-). Więcej na temat HDF można przeczytać w tym dokumencie amerykańskiej agencji.
NetCDF – czyli Network Common Data Form – to z kolei format plików (i związanych z nimi bibliotek), które przeznaczone są do przechowywania danych naukowych. Co ciekawe, pierwotnie NetCDF bazowało na koncepcji Common Data Format opracowanej przez… NASA. Potem jednak NetCDF poszło swoją drogą. To także jest format, który został zapoczątkowany już kilkadziesiąt lat temu.
Elasticsearch w JPL
Zasadniczo problem był następujący: jak w czasie rzeczywistym odtwarzać i przeglądać dane telemetryczne z bardzo, bardzo odległych źródeł. Jednym z najważniejszych był łazik Curiosity. Ten oddalony od nas o 150 milionów mil badał powierzchnie marsa (w rzeczywistości wartość ta dynamicznie się zmienia wraz z krążeniem obu planet wokół słońca). Trzeba było wykorzystać nowoczesne technologie Big Data. Jak może to wyglądać w praktyce? Przykład podaje Tom Soderstrom, Chief Technology and Innovation Officer, and Dan Isla, IT Data Scientist.
“Jeśli udałoby nam się dokładnie przewidzieć parametry termiczne, czas jazdy Curiosity mogłaby wzrosnąć dramatycznie, co mogłoby nas doprowadzić do przełomowych odkryć. I odwrotnie – błąd mógłby poważnie wpłynąć na misję za dwa miliardy dolarów.”
W kibanie można tworzyć wspaniałe środowisko do analizy. I właśnie to skusiło JPL z NASA.
Wcześniej inżynierowie JPL żmudnie zbierali dane i wrzucali je do powerpointa, gdzie potem analitycy mogli je analizować. Trwało to kupę czasu i cóż… z naszej dzisiejszej perspektywy wygląda to wręcz nieprawdopodobnie głupio. Możemy sobie tylko wyobrazić jaką rewolucję wprowadziło zastosowanie technologii Big Data. Konkretnie inżynierowie big data z NASA napisali całą platformę, nazwaną Streams, dzięki której dane mogły przychodzić w czasie “rzeczywistym” (o ile można tak nazywać komunikację z Marsem), a następnie być analizowane i przeszukiwane na bieżąco.
Właśnie w tym przeszukiwaniu i analizowaniu pomógł Elasticsearch wraz ze swoją wierną towarzyszką Kibaną. Dzięki spojrzeniu na problem przeglądania danych telemetrycznych jak na problem wyszukiwania (search problem) można było zaprzegnąć ES i rozwiązać rzeczy do tej pory nierozwiązywalne. Przede wszystkim sprawnie można było ograniczyć zakres poszukiwanych danych i skupić się tylko na tym co trzeba. Można było ładnie wizualizować i przeglądać to co zostało znalezione. Analitycy dostali w swoje ręce narzędzia, o których wcześniej się nie śniło.
JPL to niejedyne miejsce wykorzystujące Big Data w New Space
Zaczynając artykuł byłem przekonany, że zajmie on tylko kawałeczek. Teraz, gdy opowiedziałem o wykorzystaniu Big Data w NASA widzę jak bardzo się pomyliłem. Nie chcę rozwijać materiału jeszcze bardziej, dlatego już teraz zapraszam na drugą część;-). Jeśli chcesz dowiedzieć się jak Big Data wykorzystywana jest w innych obszarach New Space – zapisz się na newsletter lub obserwuj RDF na LinkedIn. Zrób to koniecznie i razem twórzmy polską społeczność Big Data!
