Post

Budowanie Szybkiego i prostego analizatora danych z bezserwerową i Amazonową Ateną

W ostatnich latach, wydaje się, że zawsze coraz częściej spotykamy się z terminem "duże dane". Rzeczywiście, duże firmy mają już specjalne stanowiska bezpośrednio związane z przetwarzaniem i analizą takich zbiorów danych - ale co z tymi, które nie mają jeszcze ugruntowanej pozycji?

Jako młody programista, a także ktoś przygotowujący się do certyfikatów AWS, szybko zainteresowałem się potencjałem Big Data i zidentyfikowałem go jako coś, co chciałbym włączyć do swojej ścieżki kariery. W związku z tym nie wystarczyło po prostu poznać i zrozumieć teoretyczne zagadnienia - musiałem umieć wcielić je w życie. Na szczęście PGS Software wkłada wiele wysiłku w to, aby ich programiści byli w pełni przygotowani, nawet zanim zdamy nasze certyfikaty AWS. Ponieważ jest to coś, z czym chciałem dużo pracować w przyszłości, wiedziałem, że praktyczne doświadczenie w projektach wewnętrznych będzie dużym krokiem milowym w moim osobistym rozwoju.

W rezultacie, kiedy CoE (Centre of Excellence - nasi eksperci od chmur obliczeniowych) zaproponowało stworzenie małego projektu dotyczącego analizy danych pogodowych, natychmiast wskoczyłem na pokład!

Zadanie

Wymagania dotyczące tego zadania były dość jasne: stworzyć proste i skuteczne narzędzie do analizy dużych ilości danych, wraz z ich wizualną reprezentacją, przy minimalnych kosztach finansowych.

Co więcej, test ten dotyczył przecież dużych ilości danych, więc musieliśmy wiedzieć, z jakimi ilościami mamy do czynienia. W tym projekcie zdecydowaliśmy się na wykorzystanie dużych ilości danych, nawet do 100GB, w określonym typie i formacie danych (co omówię wkrótce).

Dane testowe

Na początku zdecydowaliśmy, że chcielibyśmy przetestować rozwiązanie z około 100 GB danych. Chociaż osobiste definicje wolumenów mogą się różnić, zawsze rozumiałem "duże dane" jako odnoszące się do wolumenów większych niż dwucyfrowe wartości GB. Innymi słowy, 100 GB to idealne miejsce do rozpoczęcia testowania wydajności narzędzi używanych w tym projekcie. Warto również wspomnieć, że im większy jest wolumen danych, tym więcej można wyciągnąć wniosków (1 z głównych zalet wykorzystania dużych danych).

Zanim jednak mogliśmy zacząć, musieliśmy najpierw wybrać rodzaj danych, z których będziemy korzystać. W tym przypadku, jak w wielu sytuacjach, ilość danych pomaga określić ich rodzaj. Przykładowo, istnieją duże zbiory publicznie dostępnych danych w wielu dziedzinach, takich jak umowy patentowe, statystyki medyczne, bloki i - w naszym przypadku - informacje o pogodzie. Zdecydowaliśmy się skupić na tym, ponieważ przychylnie nastawiamy się na reprezentacje graficzne.

Wykorzystaliśmy dane dostarczane przez NOAA (National Oceanic and Atmospheric Administration) - zbiór pomiarów, który obejmuje m.in. wartości temperatur z różnych miejsc na świecie, gromadzonych od 1763 do obecnego roku (2018). Wszystko to zestawione jest w teczce z konkretnymi plikami, z których każdy obejmuje wartość pomiarów z danego roku.

Każdy z tych plików zapisany jest w formacie CSV, zawierającym informacje o miejscu wykonania pomiarów, dokładną datę ich zapisu, opis mierzonych elementów i ich wartości, a także dodatkowe dane dotyczące źródła pomiarów, ogólnej jakości i innych. Można przypuszczać, że dane są bardzo dobrze przygotowane, czytelne i już posortowane, z poszczególnymi kolumnami oddzielonymi przecinkami.

Poniżej znajdują się opisy dla poszczególnych nagłówków kolumn:

  • id - 11 znakowy kod identyfikacyjny stacji
  • data - jest to ośmioznakowy format daty w formacie RRRR/MONTH/DAY, lub RRRR-MM-DD. Na przykład, 1986-05-29 odnosi się do 29 maja 1986 r.
  • element - 4 znakowy wskaźnik typu elementu (np. TMAX to maksymalna temperatura)
  • wartość - 5 znakowa wartość danych dla elementu. W tym przypadku, temperatura w Celsjuszu, w wielokrotności 10.
  • mflag - 1-znakowa flaga pomiaru
  • qflag - 1 znakowa flaga jakości
  • sflaga - 1 znakowa flaga źródłowa
  • czas - 4-znakowy czas obserwacji, zapisany w formacie godzina-minuta (tj. 0700 = 7:00 rano)

Przechowywanie

Zgodnie z naszymi własnymi wymaganiami, jak również wielkością zbioru danych, potrzebowałem sposobu ich przechowywania. Lokalne przechowywanie danych jest problematyczne, ponieważ wymagania dotyczące pamięci, jak również ładowanie takich ilości danych, wpływa na szybkość wielu procesów. Nie jest to też rozwiązanie bezserwerowe.

Porównując koszty dostawców usług w chmurze, zwłaszcza z kosztami przechowywania danych na fizycznych, zewnętrznych urządzeniach, przechowywanie informacji w chmurze okazało się najtańszym rozwiązaniem.

Z tego powodu zdecydowałem się na zastosowanie jednego z rozwiązań firmy Amazon: wiadra S3. Usługa ta może być łatwo przepisywana, jest w stanie pobierać duże ilości danych z różnych źródeł, charakteryzuje się wysoką trwałością (99,999999999%), a także zapewnia kompleksowe bezpieczeństwo i zgodność z przepisami. Jeśli to nie wystarczy, to jest również zaprojektowana tak, aby była dostępna przez 99,9% czasu i, co najważniejsze dla nas, jest całkowicie bezserwerowa.

Dodatkowo, S3 oferuje dodatkową elastyczność poprzez zarządzanie danymi i kontrolę dostępu. Zapewnia również funkcjonalność query-in-place, pozwalając nam na wykonywanie analiz bezpośrednio na danych przechowywanych w wiadrze.

Nasze wiadro jest podzielone na 2 foldery; podczas gdy jeden zawiera skompresowane dane, drugi zawiera nieskompresowane informacje. Było to niezbędne do przeprowadzenia przyszłych testów.

Transformacja danych

Kolejne wyzwanie polegało na pomiarze rozproszonych danych, jak również braku schematów potrzebnych do stworzenia tabeli. Przeprowadzanie bardziej zaawansowanych analiz na surowych danych jest zawsze trudne, dlatego też potrzebowałem sposobu na lepsze ich zrozumienie: Klej AWS Glue był do tego wyjątkowo pomocny.

Klej to usługa ETL (extract, transform and load), która umożliwia efektywne przygotowanie, załadowanie i przeniesienie danych pomiędzy różnymi formami przechowywania. Zawiera ona Katalog Danych Klejowych, który tworzy i przechowuje schematy i metadane dla baz danych. Jest to również narzędzie bezserwerowe, a zatem nie posiada żadnej infrastruktury do konfiguracji i zarządzania.

Co więcej, warto wspomnieć, że jedną z dodatkowych opcji Glue'a jest stworzenie schedulera. Możemy wykorzystać go do cyklicznego uruchamiania crawlerów, jeśli dane, z których korzystamy, są od czasu do czasu aktualizowane. Dla tego projektu zdecydowaliśmy się pozostać przy opcji "na żądanie", ponieważ tworzyliśmy dowód koncepcji, a nie stałe, ciągłe narzędzie. Oczywiście taką opcję można było również łatwo wdrożyć za pomocą schedulera.

Glue tworzy dla nas konwencjonalną bazę danych i tabelę, na podstawie plików, które przechowujemy w S3. Jest to całkowicie zautomatyzowany proces, zarządzany przez AWS, a zatem rola użytkownika jest zredukowana do kilku kliknięć. Jeśli mamy dobrej jakości pliki CSV, tabela, którą otrzymamy w wyniku uruchomienia crawlera, będzie zawierała nazwane kolumny, wraz z konkretnymi typami danych w ich odpowiednich kolumnach.

Analiza danych

Głównym celem naszego projektu było znalezienie narzędzia, które może analizować duże zbiory danych w efektywny, szybki i niskobudżetowy sposób. Musiało ono również być całkowicie bezserwerowe, ponieważ chciałem, aby cała infrastruktura była zarządzana przez AWS, a nie przez nas.

Po zbadaniu dostępnych opcji, Amazon Athena okazała się doskonałym narzędziem do współpracy z naszymi potrzebami.

AWS Athena to usługa służąca do pisania interaktywnych zapytań i analizy danych przechowywanych bezpośrednio w S3. Zapytania mogą być zapisywane w konsoli Athena, generując natychmiastowe wyniki. Jest to również rozwiązanie efektywne kosztowo, ponieważ opłaty pobierane są tylko wtedy, gdy zapytania są uruchamiane. Podobnie jak poprzednie narzędzia AWS wykorzystywane w tym przypadku, Athena jest rozwiązaniem bezserwerowym. Jest również kompatybilna z Glue, więc integracja tych usług była bardzo prosta do osiągnięcia.

W dashboardzie Atheny musimy skonfigurować bazę danych i tabelę, która pojawia się automatycznie po uruchomieniu crawlera, który wcześniej skonfigurowaliśmy w Glue. W tym celu nazwa bazy danych i tabeli będzie taka sama jak w samym Glue. W rzeczywistości, cały nasz proces pracy kończy się po tej konfiguracji, ponieważ Athena pobiera z Glue wszystko, czego potrzebuje. Jest to również kolejna usługa, która zapewnia nam prosty i przejrzysty interfejs.

Generalnie połączenie pomiędzy Glue i Ateną jest bardzo proste i nie wymaga ode mnie zbyt dużego wysiłku.

Po wybraniu odpowiedniej tabeli, możemy zacząć pisać zapytania. Na szczęście Athena używa składni SQL, co daje mi ogromną przewagę, ponieważ jest to coś, z czym bardzo łatwo mi się pracuje.

Co więcej, możemy również zapisywać tworzone przez nas zapytania, a Athena ma nawet historię zapytań, która zachowuje wyniki z ostatnich 45 dni. Ta funkcja historii pokazuje zarówno udane, jak i nieudane zapytania, poza tym pozwala nam na pobranie wyników lub zobaczenie ID każdego zapytania dla nas w przyszłości. Możliwe jest również zapisywanie wyników tych zapytań zarówno w plikach txt jak i csv.

Jeśli chodzi o czystą analizę danych i przeglądanie wyników w nowych tabelach, użytkownik może nie uznać tego za tak łatwe do odczytania lub interpretacji jak wizualizacja danych. Jest to istotne w przypadku przedstawiania surowych danych komuś, kto nie ma wiedzy na temat ich interpretacji. Innymi słowy, graficzna reprezentacja danych jest niezbędna. Pozwala ona również użytkownikom na wyciąganie ciekawszych wniosków.

Dla naszego projektu, Amazon ponownie zdołał zaskoczyć nas szerokością i dostępnością swoich różnych narzędzi. W tym przypadku zdecydowałem się na zastosowanie QuickSight. Jest to narzędzie business intelligence, które pozwala na łatwe tworzenie wizualizacji, obok prostej analizy danych. Pozwala nam również na dostęp do danych z wielu źródeł.

Tak jak w przypadku wszystkich innych usług AWS, integracja QuickSight z Atheną jest bardzo prosta i łatwa do wykonania. Cały proces trwa zaledwie 3 kroki:

  1. Rozpoczęcie nowej analizy
  2. Wybierz źródło danych, które może być z naszego wiadra S3, istniejącego zbioru danych saed w QuickSight, lub nawet kilka bezpośrednio z Atheny.
  3. Po wybraniu źródła danych możemy stworzyć graficzną wizualizację w postaci różnych wykresów.

Na wykresie tym widzimy zmiany temperatury minimalnej i maksymalnej w ciągu dnia, wraz z wartościami średnimi, w zależności od daty. Ta konkretna wizualizacja pokazuje zakres danych dla 7 miesięcy w 2018 roku - jest to niewielka część danych uzyskanych w wyniku danego zapytania.

Architektura

Jeśli chodzi o architekturę, zdecydowałem się na bezserwerową z kilku powodów. Po pierwsze, chciałem skupić się na podstawowych funkcjach, poświęcając mniej czasu na konserwację i rozwiązywanie problemów, choć jest to nieuniknione w przypadku większości aplikacji. Mimo to, poprzez usunięcie z równania potrzeb sprzętowych, byłem w stanie ograniczyć to do absolutnego minimum.

Dodatkowo, martwiłem się o wydajność i dostępność usług, z których korzystałem. Jak wspomniano na początku tego postu, rozwiązania bezserwerowe są wysoce dostępne i trwałe.

Testowanie

Jak każdy projekt, niezbędne są dokładne testy. Na szczęście, ponieważ wszystkie usługi wykorzystywane w tym projekcie są w pełni zarządzane przez AWS, nie są wymagane żadne zaawansowane testy.

Zamiast tego mogłem skupić się na testach wydajnościowych zarówno Glue jak i Athena.

Testowanie AWS Glue

Dla potrzeb testów postanowiłem trochę zmanipulować danymi i zobaczyć, jak każda usługa zarządza, gdy dane są sformatowane, a także gdy używam mniej danych. Jak wspomniano wcześniej, wszystkie dane są przechowywane w wiadrze S3 w 2 oddzielnych folderach. W jednym z nich znajdują się dane nieskompresowane, a w drugim dane skompresowane.

Mając to na uwadze, przeprowadziłem testy dla 2 scenariuszy:

  • Testowanie szybkości tworzenia schematu dla nieskompresowanych danych
  • Testowanie szybkości tworzenia schematu dla skompresowanych danych

Wbrew początkowym pozorom, najszybszym sposobem stworzenia schematu była największa ilość (pierwszy scenariusz) danych, co zajęło około 30 sekund. Dla drugiego scenariusza schemat został stworzony w 33 sekundy.

Sprawdziłem też, jak zachowa się Glue, gdy będzie próbował stworzyć crawler, mając do dyspozycji tylko 1 plik. W tym przypadku stworzenie schematu trwało około 20 sekund, co było najszybszym wynikiem. Jednak dla jednego pliku nazwy kolumn i odpowiednie typy danych nie były tak dokładnie zdefiniowane w porównaniu z instancjami, które wykorzystują większą ilość danych.

Testowanie AWS Athena

Dla serwisu Athena, chciałem sprawdzić skuteczność jego analizy. Przygotowałem scenariusze dla 2 przypadków i dla każdego przypadku napiszę 3 rodzaje zapytań, sprawdzając czas realizacji każdego z nich.

Te 2 scenariusze są:

  • Testowanie skompresowanego zestawu danych,
  • Testowanie nieskompresowanego zestawu danych

Dla każdego z tych scenariuszy wykonałem 3 rodzaje zapytań:

  • Pierwszy przypadek: Wybrałem 10 rekordów dla danego zbioru danych
  • Druga sprawa: Wybrałem 1.000 rekordów dla danego zbioru danych
  • Trzecia sprawa: Wybrałem minimalne i maksymalne średnie temperatury dla Włoch w latach 1763, 1891 i 2018. Stanowiło to około 30.000.000 rekordów.

Tutaj przedstawiłem czas przebiegu dla każdego zapytania (w sekundach):

Scenariusz Pierwszy przypadek Druga sprawa Trzeci przypadek
Dane skompresowane 1.77s 1.82s 35.5s
Dane nieskompresowane 1.75s 0.72s 20.3s

Jak widać, wydajność zapytań jest lepsza w przypadku danych nieskompresowanych. Jest to prawdopodobnie spowodowane wysokim współczynnikiem kompresji danego algorytmu, ponieważ do skompresowania i dekompresji danych potrzeba więcej procesora w miarę wzrostu tego współczynnika.

Inne rozwiązania

Oczywiście, zawsze istnieje więcej niż jeden sposób na osiągnięcie jakiegokolwiek celu. W ramach tego projektu badałem podobne rozwiązania, dzięki czemu mogłem lepiej porównać przydatność Atheny.

W szczególności, warto omówić alternatywne rozwiązanie zaproponowane przez IBM. Proponują one wykorzystanie Apache Spark i iPython Notebook do stworzenia analizatora pogody. Rozwiązanie to opiera się na tych samych danych pogodowych, które wykorzystałem, ale nie jest tak proste jak nasz projekt Athena.

Składa się ono z 5 kroków:

  • Po pierwsze, musisz stworzyć instancję Spark.
  • Następnie należy utworzyć notebook iPython na tej instancji.
  • Następnie zestaw danych musi zostać wgrany do notebooka.
  • Następnie należy utworzyć RDD (sprężysty rozproszony zbiór danych).
  • Na koniec, należy przetworzyć i przeanalizować dane.

Ponadto, w przeciwieństwie do naszego projektu Athena, rozwiązanie IBM nie posiada rozwiązania do graficznego przetwarzania danych. Co więcej, Spark nie używa składni SQL, ale Python używa do zapytań funkcji Lambda.

Poza tym, odpowiedź IBM opiera się na klastrach, które muszą być utrzymywane i często wymagają dużego wysiłku finansowego. Moje rozwiązanie wykorzystuje składnię SQL, więc nie musimy pisać żadnego kodu Pythona, co ułatwia jego ponowne użycie. Wreszcie, nasza opcja jest również całkowicie bezserwerowa, co znacznie obniża koszty projektu. Są one nawet niższe, niż się często oczekuje, biorąc pod uwagę fakt, że płacimy tylko za ilość skanowanych danych.

Athena kontra IBM: Koszty .

Dla każdego z dostawców - AWS i IBM - i ich odpowiednich rozwiązań, możemy skorzystać z tzw. bezpłatnej wersji próbnej, która pozwala nam na tworzenie praktycznie bezkosztowych aplikacji. Jednak, jak to zwykle bywa, niektóre funkcje lub usługi nie są od razu dostępne w bezpłatnych testach.

Rozwiązanie, które stworzyłem z AWS jest nieco inne od rozwiązania IBM, ponieważ nie posiada ono dedykowanej usługi przetwarzania danych. To, co zostało osiągnięte dzięki Athenie w moim projekcie, jest natomiast realizowane poprzez instancję Apache Spark i notebooka iPython dla IBM.

W związku z tym trudno jest bezpośrednio porównać koszty lub przeprowadzić dokładną wycenę. Aby jak najlepiej określić koszty pomiędzy tymi dostawcami usług w chmurze, przeprowadziłem kalkulację dla obu platform, zakładając wykorzystanie instancji obliczeniowych i pamięci masowej, a także koszty rozwiązania w lokalu.

  W obiekcie . AWS IBM
Serwer 4,50 dolarów miesięcznie 1,40$ miesięcznie 9,10 dolarów miesięcznie
Przechowywanie $4.40 za GB/miesiąc $0.023 GB/miesiąc $0.03 za GB/miesiąc
Analityka Silnik Nieznany Athena, $5/TB zeskanowane zapytanie $0.70 za domyślną godzinę obliczeniową instancji

Wnioski

Po zakończeniu tego projektu, jak również powyższego porównania, można wyciągnąć pewne jasne wnioski.

W celu zwiększenia efektywności zapytań - a nawet dalszej redukcji kosztów w Athenie - możemy zastosować partycjonowanie danych. Jest to proces polegający na ograniczeniu ilości danych skanowanych przez każde zapytanie. Amazon Athena wykorzystuje do tego celu Hive i możliwe jest partycjonowanie danych za pomocą dowolnego klucza. Pomaga to w zwiększeniu wydajności zapytań w Athenie, ponieważ pomaga w uruchamianiu ukierunkowanych zapytań na określonych partycjach, co może być wykonane w celu zwiększenia wydajności w razie potrzeby.

Ponadto, aby sprawdzić wydajność Atheny, porównałem to rozwiązanie z tym, które wykorzystuje tylko wiadro S3 do przechowywania danych i usługę QuickSight do wizualizacji wyników. Na tej podstawie stwierdziłem, że ten ostatni jest lepszy w wizualizacji mniejszych ilości danych; jest szybszy, a dane są reprezentowane na osiach. W przypadku tak małych ilości danych wystarczy użyć tylko łyżki S3 i usługi QuickSight. Jednak gdy chcesz przeskalować to na większe zbiory danych, musisz także użyć Ateny.

Podsumowując, wszystkie moje wstępne założenia zostały dobrze spełnione. Przez cały ten projekt udało mi się:

Stworzyć proste rozwiązanie do analizy danych przy niskich kosztach finansowych.
Stworzyć rozwiązanie, które jest całkowicie bezserwerowe, eliminując obawy dotyczące konserwacji i skalowalności.

Jeśli chodzi o usługi AWS, to z pewnością mogę powiedzieć, że było to wspaniałe doświadczenie. Znalazłem uruchomienie wielu z tych usług, zintegrowanie ich i skonfigurowanie do pełnej automatyzacji, więc jako programista musiałem tylko kilka razy kliknąć i otrzymać gotowe, wszechstronne rozwiązanie.

Praktyczne zastosowania i aplikacje

Jak widać, usługi AWS pozwalają nam na szybką i skuteczną analizę potrzebnych nam danych - ale konsekwencje wykraczają daleko poza raporty pogodowe. Chciałbym poświęcić kilka chwil na omówienie niektórych alternatywnych sposobów wykorzystania tej formy manipulacji danymi, jak również sposobów jej rozszerzenia w celu zaspokojenia dodatkowych potrzeb biznesowych.

Alternatywne zastosowania

Prawie każda firma generuje dane na co dzień i większość - jeśli nie wszystkie - ma szansę na zdobycie lepszej wiedzy, jeśli odpowiednio je wykorzysta. Efektywne kosztowo, szybkie rozwiązanie, takie jak nasze, umożliwia głębszy wgląd w dane, niezależnie od ich zakresu i skali.

W rzeczywistości, sama Amazon Athena jest już wykorzystywana w różnych branżach i obszarach:

  • Atlassian wykorzystuje Athenę, wraz z innymi rozwiązaniami AWS Analytics, jako część budowanego na zamówienie samoobsługowego jeziora danych.
  • OLX, popularny rynek internetowy, wykorzystuje Athenę w całej swojej organizacji, aby skrócić czas wprowadzania na rynek, zmniejszyć koszty i zoptymalizować usługi.
  • Moveable Ink, platforma marketingowa, wykorzystuje Athenę do wyszukiwania danych historycznych z 7 lat, uzyskując wyniki w ciągu zaledwie kilku chwil, a wszystko to z elastycznością umożliwiającą dalsze badanie tych danych i generowanie głębszych spostrzeżeń.

Nauka maszynowa

Podczas gdy szybka, bezserwerowa wyszukiwarka danych jest bardzo przydatna, możemy również dalej zautomatyzować poniższe kroki. Ponieważ firmy wykorzystują te informacje do podejmowania świadomych decyzji, możemy zintegrować tę konfigurację z nauką maszynową, aby podejmować natychmiastowe decyzje w oparciu o bogactwo wiarygodnych danych.

Na przykład, nasz model analizy pogody może być wykorzystany w prognozowaniu sprzedaży, przede wszystkim dla firm działających w branży FMCG (dóbr szybkorotujących). Niektóre produkty sprzedają się lepiej lub gorzej w określonych warunkach pogodowych, a algorytm uczenia maszynowego mógłby wykorzystać te dane, w połączeniu z danymi dotyczącymi sprzedaży, aby dowiedzieć się, co sprzedaje się najlepiej w różnych warunkach i odpowiednio dostosować swoje oferty i strategię handlową.

Innym przykładem może być transport. Na przykład firma taksówkarska mogłaby przewidzieć zmiany pogody, zwłaszcza pogodę, która koreluje ze zwiększonym użytkowaniem taksówki, i być na to przygotowana.

Oczywiście istnieje również niezliczona ilość zastosowań poza analizą pogody. Dla niektórych gałęzi przemysłu, w których szybkie reakcje są niezbędne, zautomatyzowane reagowanie na dane jest niezbędne. Jeśli weźmiemy pod uwagę, że instytucje finansowe, takie jak zarządzanie majątkiem i funduszami hedgingowymi, są w stanie dostosować się do wahań rynkowych, kursów wymiany walut i innych czynników, z których wszystkie przyczyniają się do ryzyka finansowego, ma to kluczowe znaczenie. Nauka maszynowa może wykorzystywać zapytania do wyciągania wszystkich potrzebnych danych i przedstawiania zaleceń w locie.

Komentarze (0)

Zostaw komentarz