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, iż jedyne, z czym trzeba się zmierzyć, to ilość danych, którą będziemy przechowywać. gwałtownie okazuje się, iż 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ę, iż 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żeli dołożymy do tego czynnik Big Data, nagle okazuje się, iż 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żeli z jakiegoś powodu musimy przeczytać wszystkie zgromadzone rekordy, możemy wpaść w pułapkę tego, iż 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 w tej chwili 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żeli 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ę, iż 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ę, iż 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żeli 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ę, iż 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 gwałtownie zmieniać jej poszczególne składowe, jeżeli zaistnieje taka potrzeba. W tym wszystkim jednak zdarza się, iż 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żeli np. pomimo tego, iż 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żeli 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żeli 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żeli dołożymy do tego wszelakie produkty z koszyka "serverless" okazuje się, iż naszą platformę możemy nie tylko zbudować w dowolny sposób, ale także amortyzując koszty. Olbrzymią zaletą chmury jest to, iż 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żeli nie muszę martwić się o przyszłość mojej infrastruktury, moje estymaty nie muszą być tak "wyśrubowane" -- jeżeli będzie to konieczne, we właściwym 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, iż jest całkowicie na odwrót -- jeżeli 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żeli 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ę.
