Zbieranie danych na temat użytkowników różnych serwisów to temat, który co prawda istnieje od momentu, kiedy stało się to technicznie możliwe (a więc od lat dziewięćdziesiątych XX wieku, kiedy to pojawiły się pierwsze serwisy wspomagane bazami danych oraz odpowiednie mechanizmy jak chociażby cookies w przeglądarkach), z drugiej strony dopiero od całkiem niedawna stało się na tyle powszechne, że zaczęły pojawiać się odpowiednie regulacje, które mówią co można, a czego nie można (żeby daleko nie szukać można przytoczyć przykład GDPR/RODO). Co więcej, zaczęła rosnąć także świadomość "szeregowych" użytkowników Internetu, która pociąga za sobą konieczność wprowadzenia odpowiednich mechanizmów związanych chociażby z ustawieniami prywatności. To wszystko jednak to tematy, które w pierwszej kolejności dotyczą osób bezpośrednio związanych z funkcjonowaniem firmy oraz dostosowywaniem ich do istniejących wymogów zarówno prawnych jak i użytkowych. Jak jednak w takowym świecie odnajduje się programista? Czy lawinowo rosnąca ilość informacji, która jest wymieniana pomiędzy klientem a serwerem wymusza bądź promuje odpowiedni zestaw jego umiejętności. Wreszcie -- jeśli wszystko to ugotujemy w gęstym, chmurowym sosie to wyjdzie nam zjadliwe danie, czy raczej będziemy musieli wyrzucić wszystko do kosza?
Osobiście przerażają mnie nieco wyzwania, przed jakimi stawia się obecne systemy, które wpasowują się mniej lub więcej w termin Big Data. Bardzo łatwo można temat uprościć mówiąc, że jedyne, z czym trzeba się zmierzyć, to ilość danych, którą będziemy przechowywać. Szybko okazuje się, że baza danych to najmniejszy z naszych problemów -- przestrzeń magazynowa jest niezwykle tania i nie ma problemu by przetrzymywać terabajty danych za kilkadziesiąt dolarów miesięcznie. Przykładowo -- przechowywanie 1TB danych w Azure Table Storage będzie nas kosztować około 60$. Większym problemem okazuje się sam dostęp do zgromadzonych informacji, kiedy to nagle okazuje się, że w małej skali przeczytanie wszystkiego, co mamy jest rzeczą zarówno możliwą do wykonania, jak i możliwą do wyestymowania w kwestii potrzebnego czasu. Będzie to chwilę trwało, koniec końców jednak otrzymamy jakiś wynik, którego mniej lub bardziej się spodziewaliśmy. Jeśli dołożymy do tego czynnik Big Data, nagle okazuje się, że błędy na poziomie usystematyzowania danych bądź ich struktur są kosztowne nie tylko na poziomie naszego portfela, ale i całego rozwiązania chmurowego. Jeśli z jakiegoś powodu musimy przeczytać wszystkie zgromadzone rekordy, możemy wpaść w pułapkę tego, że nie jesteśmy w stanie skończyć procesu przed np. kolejną iteracją raportów dziennych, które będą musiały w takim przypadku być może operować na dwóch zbiorach danych, destabilizując dalej architekturę. Nie jest to scenariusz, w którym chcielibyśmy się znaleźć.
Pojawiające się regulacje raczej nie poprawiają sytuacji. W jednym z projektów, nad którym obecnie pracuję z moim zespołem, zostaliśmy zmuszeni do znacznego skomplikowania dotychczasowej infrastruktury z teoretycznie błahego wymagania, jakie się pojawiło całkiem niedawno -- konieczności zwrócenia użytkownikowi wszystkich zgromadzonych na jego temat informacji, jeśli nas o to poprosi. Problem wydaje się całkiem prosty do rozwiązania -- wystarczy powiązać identyfikator użytkownika ze wszystkim gromadzonymi informacjami a następnie napisać proste zapytanie, które je wyruguje. Byłoby to prawdą gdybyśmy mogli skorzystać np. z relacyjnej bazy danych SQL, jednak gromadzenie danych w skali Big Data skutecznie zabija takowe rozwiązania. Idąc dalej -- moglibyśmy wytwarzać widoki ze zgromadzonych danych (i jest to idea, którą z powodzeniem się stosuje, aby obsługiwać z góry przewidziane zapytania), jednak jest to tylko połowa sukcesu. Okazuje się, że oprócz zwracania informacji, użytkownik może także poprosić o usunięcie wszystkiego, czego dowiedzieliśmy się na jego temat. Co prawda proces nieco różni się w przypadku zanonimizowania danych oraz usuwania wszystkiego, co jest uznawane za tzw. personal data, jednak komplikuje to jeszcze bardziej nasze rozwiązanie.
Wszystkie wymienione wyżej problemy wymuszają na programiście zdobycie nowych umiejętności w dość krótkim czasie. Niezwykle pomocne jest także wsparcie doświadczonego data scientist'a, którego intuicja może uprościć przygotowanie odpowiednich struktury z danymi, na których będzie można później bezproblemowo pracować. Wydaje się, że jest to punkt wyjścia, kiedy zaczynamy przygotowania do naszej platformy Big Data -- znajomość chmury i jej charakterystyk oczywiście bardzo pomaga, jednak mimo wszystko jak szybkie poszczególne usługi cloudowe by nie były, jeśli popełnimy poważny błąd na początku, możemy narazić się w późniejszym czasie na niepotrzebne koszty i stres. O jakich umiejętnościach jednak mowa? Myślę, że istotna okazuje się wiedza z dwóch obszarów -- architektury systemów rozproszonych (gdzie często agregujemy informacje z wielu źródeł -- nie muszą mieć one ani wspólnego kontekstu, ani schematu) oraz technik związanych z komunikacją pomiędzy różnymi elementami naszego systemu. O ile pierwszy punkt jest często robiony za nas (jak np. Event Hub w Microsoft Azure, który implementuje wzorzec "partitioned consumers"), drugi wymaga przeczytania kilku artykułów, przetestowania i zdobycia doświadczenia, które pozwoli na wybranie odpowiedniego rozwiązania. Czasem możliwe jest przyśpieszenie danego elementu o kilka rzędów wielkości (jeśli chodzi np. o liczbę przetworzonych zdarzeń na sekundę), ciężko jest to jednak osiągnąć bez znajomości odpowiednich technik optymalizacyjnych (jak odpowiednia serializacja i partycjonowanie danych).
Chmura pozwala bawić się naszą architekturą i szybko zmieniać jej poszczególne składowe, jeśli zaistnieje taka potrzeba. W tym wszystkim jednak zdarza się, że problemem nie jest performance pojedynczego elementu a raczej charakterystyki, o jakich nie myśli się w pierwszej kolejności. Mowa tutaj o takich rzeczach jak np. przepustowość łącza internetowego czy czas potrzebny na odczyt bądź zapis danych z dysku twardego. Wyobraźmy sobie sytuację, kiedy z naszego magazynu próbujemy odczytać wszystkie dane w celu ich przetworzenia. Zapisywaliśmy je w takim sposób, aby umożliwić ich równoległe procesowanie. Wszystkie nasze wysiłki mogą pójść jednak na marne, jeśli np. pomimo tego, że możemy przerabiać 100MB danych na sekundę, magazyn jest w stanie odczytać i wysłać tylko 10MB. W takim momencie wyjścia są dwa -- albo zmieniamy magazyn na taki, który będzie współgrał z naszą mocą obliczeniową, albo musimy w taki sposób składować dane, by wykorzystać w 100% przepustowość, którą oferuje.
Mimo tych wszystkich przygód chmura jest jednak naszym przyjacielem, jeśli chodzi o budowanie rozwiązań Big Data. Co prawda oferowane możliwości różnią się w zależności od tego, z usług jakiego dostawcy skorzystamy, zbierając to jednak w całość zauważymy pokaźny wachlarz różnorakich usług, które pokrywają większość, jeśli nie wszystkie, scenariuszy. Dostajemy więc zarówno komponenty odpowiedzialne za komunikację (Kinesis, Event Hub), procesowanie strumieniowe (znów Kinesis, Stream Analytics) oraz przechowywanie danych (S3, Azure Storage). Jeśli dołożymy do tego wszelakie produkty z koszyka "serverless" okazuje się, że naszą platformę możemy nie tylko zbudować w dowolny sposób, ale także amortyzując koszty. Olbrzymią zaletą chmury jest to, że koszty z nią związane można bezpośrednio powiązać z cyklem życia aplikacji. Z punktu widzenia programisty (czy też architekta) jest to dodatkowy atut -- jeśli nie muszę martwić się o przyszłość mojej infrastruktury, moje estymaty nie muszą być tak "wyśrubowane" -- jeśli będzie to konieczne, w odpowiednim elemencie wymienię bądź zmodyfikuję odpowiedni element, aby sprostał nowym wymaganiom.
Jak jednak odnaleźć się w tym całym rogu obfitości? Czy mnogość zarówno komercyjnych jak i darmowych rozwiązań nie działa na niekorzyść clouda? Osobiście uważam, że jest całkowicie na odwrót -- jeśli mam dowolność w wyborze składowych architektury, mogę nie tylko łatwo dopasować do niej zespół jak i aktualne obciążenie. Z technicznego punktu widzenia jest to pewne wyzwanie -- trzeba zadbać o to, by na każdym etapie dbać o odpowiedni przepływ danych -- jednak od strony platformy jako całości, jest to raczej pożądana sytuacja. Nie jest ona już monolitem, który raz umieszczony na produkcji wprawia w zakłopotanie za każdym razem, gdy trzeba coś zmienić. Modularność i wyspecjalizowanie każdej usługi w większości przypadków bardziej pomagają niż utrudniają pracę.
Co najbardziej mnie kręci w połączeniu chmury oraz Big Data? Wyzwanie z jakim trzeba się zmierzyć. Problemy tradycyjnych systemów potrafią spędzić noc z powiek, ich skala jednak jest znacznie mniejsza. W świecie danych z jednej strony trzeba trzymać się pewnych sztywnych reguł, jeśli chodzi o to, jak musimy je przechowywać i co możemy z nimi zrobić, z drugiej samo sedno rozwiązania jest zwykle niezdefiniowane. Tak naprawdę z punktu widzenia programisty (czy też ogólnie -- patrząc na Big Data od strony czysto technicznej) jest to jeden z fajniejszych obszarów, w których można się znaleźć. To już nie są typowe aplikacje desktopowe czy odgrzewane bez przerwy webserwisy. Siedzisz w swoim fotelu, otrzymujesz kilkaset MB danych i Twój kod musi sobie z nimi jak najszybciej poradzić. Nie dłużej niż w sekundę.
