Jest to druga część cyklu artykułów o systemach analitycznych ().
Dziś nie ma wątpliwości, że dokładne przetwarzanie danych i interpretacja wyników może pomóc niemal każdemu rodzajowi biznesu. W tym zakresie systemy analityczne są coraz bardziej obciążone parametrami, rośnie liczba wyzwalaczy i zdarzeń użytkownika w aplikacjach.
Z tego powodu firmy przekazują swoim analitykom coraz więcej „surowych” informacji do analizy i przełożenia ich na właściwe decyzje. Nie należy lekceważyć znaczenia systemu analitycznego dla firmy, a sam system powinien być niezawodny i trwały.
Analitycy klienta
Analityka klienta to usługa, którą firma łączy ze swoją witryną internetową lub aplikacją za pośrednictwem oficjalnego zestawu SDK, integruje ją z własną bazą kodu i wybiera wyzwalacze zdarzeń. Takie podejście ma oczywistą wadę: wszystkie zebrane dane nie mogą być przetwarzane w taki sposób, w jaki byś sobie tego życzył, ze względu na ograniczenia wybranej usługi. Na przykład w jednym systemie nie będzie łatwo uruchomić zadań MapReduce, w innym nie będzie można uruchomić modelu. Kolejnym minusem będzie regularny (imponujący) rachunek za usługi.
Na rynku dostępnych jest wiele rozwiązań do analityki klienta, jednak prędzej czy później analitycy stają przed faktem, że nie ma jednej uniwersalnej usługi, odpowiedniej do każdego zadania (przy czym ceny wszystkich tych usług stale rosną). W takiej sytuacji firmy często decydują się na stworzenie własnego systemu analitycznego ze wszystkimi niezbędnymi niestandardowymi ustawieniami i funkcjami.
Analitycy serwerów
Analityka po stronie serwera to usługa, którą można wdrożyć wewnętrznie na serwerach firmy lub (zwykle) wewnątrz firmy. W tym modelu wszystkie zdarzenia użytkownika są przechowywane na serwerach wewnętrznych, co pozwala programistom wypróbować różne bazy danych do przechowywania i wybrać najwygodniejszą architekturę. Nawet jeśli nadal będziesz chciał korzystać z analityki po stronie klienta innych firm do niektórych zadań, nadal będzie to możliwe.
Analizę po stronie serwera można wdrożyć na dwa sposoby. Po pierwsze: wybierz narzędzia typu open source, wdróż je na swoich maszynach i opracuj logikę biznesową.
Plusy
Wady
Możesz dostosować wszystko
Często jest to bardzo trudne i potrzebni są oddzielni programiści
Po drugie: skorzystaj z usług SaaS (Amazon, Google, Azure) zamiast wdrażać je samodzielnie. O SaaS porozmawiamy bardziej szczegółowo w trzeciej części.
Plusy
Wady
Przy średnich wolumenach może być taniej, ale przy dużym wzroście nadal będzie za drogo
Nie jest w stanie kontrolować wszystkich parametrów
Administracja jest całkowicie przesunięta na barki usługodawcy
Nie zawsze wiadomo co kryje się w serwisie (może nie być potrzebne)
Jak zbierać statystyki serwerów
Jeśli chcemy odejść od analityki klienta i zbudować własną, musimy przede wszystkim przemyśleć architekturę nowego systemu. Poniżej opowiem Ci krok po kroku, na co musisz zwrócić uwagę, dlaczego każdy z kroków jest potrzebny i z jakich narzędzi możesz skorzystać.
1. Pozyskiwanie danych
Podobnie jak w przypadku analityki klienta, analitycy firmy przede wszystkim wybierają rodzaje zdarzeń, które chcą dalej badać i zbierają je w formie listy. Zwykle zdarzenia te występują w określonej kolejności, co nazywa się „schematem zdarzeń”.
Dalej wyobraźmy sobie, że aplikacja mobilna (strona internetowa) ma stałych użytkowników (urządzenia) i wiele serwerów. Aby bezpiecznie przesyłać zdarzenia z urządzeń na serwery, potrzebna jest warstwa pośrednia. W zależności od architektury może wystąpić kilka różnych kolejek zdarzeń.
- jest , która służy jako kolejka do gromadzenia zdarzeń.
Według w 2014 roku twórca Apache Kafka zdecydował się nazwać oprogramowanie imieniem Franza Kafki, ponieważ „jest to system zoptymalizowany pod kątem zapisu” i ponieważ uwielbiał pisma Kafki. —
W naszym przykładzie jest wielu producentów danych i ich konsumentów (urządzeń i serwerów), a Kafka pomaga połączyć ich ze sobą. Konsumenci zostaną opisani bardziej szczegółowo w kolejnych krokach, gdzie to oni będą głównymi aktorami. Teraz rozważymy tylko producentów danych (zdarzenia).
Kafka ujmuje pojęcia kolejki i partycji, a dokładniej o tym lepiej przeczytać gdzie indziej (na przykład w ). Nie wchodząc w szczegóły, wyobraźmy sobie, że uruchamiana jest aplikacja mobilna na dwa różne systemy operacyjne. Następnie każda wersja tworzy swój własny, oddzielny strumień zdarzeń. Producenci przesyłają zdarzenia do Kafki, są one rejestrowane w odpowiedniej kolejce.
(zdjęcie )
Jednocześnie Kafka umożliwia odczytywanie fragmentów i przetwarzanie przepływu zdarzeń w mini-partiach. Kafka to bardzo wygodne narzędzie, które dobrze skaluje się wraz z rosnącymi potrzebami (np. poprzez geolokalizację wydarzeń).
Zwykle wystarczy jeden shard, ale sprawy komplikują się w przypadku komunikacji podczas skalowania (jak zawsze). Prawdopodobnie nikt nie chce używać w produkcji tylko jednego fizycznego sharda, gdyż architektura musi być odporna na awarie. Oprócz Kafki istnieje jeszcze jedno dobrze znane rozwiązanie – RabbitMQ. Nie używaliśmy go na produkcji jako kolejki do analityki zdarzeń (jeśli masz takie doświadczenie, opowiedz nam o tym w komentarzach!). Wykorzystano jednak AWS Kinesis.
Zanim przejdziemy do kolejnego kroku należy wspomnieć o jeszcze jednej dodatkowej warstwie systemu – magazynowaniu surowych kłód. Nie jest to warstwa obowiązkowa, ale przyda się w sytuacji, gdy coś pójdzie nie tak i kolejki zdarzeń w Kafce zostaną wyzerowane. Przechowywanie surowych logów nie wymaga skomplikowanych i kosztownych rozwiązań, wystarczy po prostu zapisać je gdzieś w odpowiedniej kolejności (nawet na dysku twardym).
2. Obsługa strumieni zdarzeń
Po przygotowaniu wszystkich wydarzeń i umieszczeniu ich w odpowiednich kolejkach przechodzimy do etapu przetwarzania. Tutaj omówię dwie najczęstsze opcje przetwarzania.
Pierwszą opcją jest włączenie przesyłania strumieniowego Spark w systemie Apache. Wszystkie produkty Apache działają w systemie HDFS, bezpiecznym systemie plików replik. Spark Streaming to łatwe w użyciu narzędzie, które przetwarza dane przesyłane strumieniowo i dobrze się skaluje. Jednak utrzymanie go może być trudne.
Inną opcją jest zbudowanie własnego modułu obsługi zdarzeń. Aby to zrobić, musisz na przykład napisać aplikację w Pythonie, zbudować ją w oknie dokowanym i subskrybować kolejki Kafki. Gdy wyzwalacze dotrą do programów obsługi w oknie dokowanym, rozpocznie się przetwarzanie. Dzięki tej metodzie musisz stale uruchamiać aplikacje.
Załóżmy, że wybraliśmy jedną z opisanych powyżej opcji i przejdźmy do samej obróbki. Procesory powinny zacząć od sprawdzenia ważności danych, odfiltrowania śmieci i „zepsutych” zdarzeń. Do walidacji zwykle używamy . Następnie można wykonać mapowanie danych: dane z różnych źródeł są normalizowane i standaryzowane w celu dodania ich do wspólnej tabeli.
3. Baza danych
Trzecim krokiem jest zapisanie znormalizowanych zdarzeń. Pracując z gotowym systemem analitycznym, często będziemy musieli uzyskać do nich dostęp, dlatego ważne jest, aby wybrać wygodną bazę danych.
Jeśli dane dobrze pasują do ustalonego schematu, możesz dokonać wyboru lub inna baza danych kolumn. Zatem agregacje będą działać bardzo szybko. Wadą jest to, że schemat jest sztywno ustalony i dlatego dodawanie dowolnych obiektów bez udoskonalenia (na przykład w przypadku wystąpienia niestandardowego zdarzenia) nie będzie działać. Ale można to zrobić naprawdę szybko.
W przypadku danych nieustrukturyzowanych możesz na przykład zastosować NoSQL . Działa na HDFS, dobrze się replikuje, można utworzyć wiele instancji i jest odporny na awarie.
Możesz podnieść coś prostszego, np. . Jest dość powolny nawet w przypadku małych woluminów. Ale plusem jest to, że jest bardzo prosty i dlatego nadaje się na początek.
4. Agregacje
Po dokładnym zapisaniu wszystkich zdarzeń chcemy zebrać wszystkie ważne informacje z partii, która przyszła i zaktualizować bazę danych. Na całym świecie potrzebujemy odpowiednich dashboardów i wskaźników. Na przykład ze zdarzeń, aby zebrać profil użytkownika i w jakiś sposób zmierzyć zachowanie. Zdarzenia są agregowane, gromadzone i ponownie zapisywane (już w tabelach użytkowników). Jednocześnie istnieje możliwość zbudowania systemu w taki sposób, aby do agregatora koordynującego podłączony był także filtr, który zbierał użytkowników tylko z określonego typu zdarzeń.
Następnie, jeśli ktoś w zespole potrzebuje jedynie analityki wysokiego poziomu, można podłączyć zewnętrzne systemy analityczne. Możesz ponownie wziąć Mixpanel. ale ponieważ jest to dość drogie, nie wszystkie zdarzenia użytkownika są tam wysyłane, a tylko to, co jest potrzebne. W tym celu musimy stworzyć koordynatora, który przeniesie część surowych zdarzeń lub coś, co sami wcześniej zagregowaliśmy, do zewnętrznych systemów, API czy platform reklamowych.
5. Frontend
Należy podłączyć frontend do utworzonego systemu. Dobrym przykładem jest obsługa. , to graficzny interfejs użytkownika bazy danych, który pomaga budować panele. Jak działa interakcja:
- Użytkownik tworzy zapytanie SQL.
- W odpowiedzi otrzymuje znak.
- Tworzy dla niego „nową wizualizację” i otrzymuje piękny wykres, który możesz już sam zapisać.
Wizualizacje w serwisie aktualizują się automatycznie, możesz skonfigurować i śledzić swój monitoring. Redash jest bezpłatny w przypadku samodzielnego hostowania, ale w przypadku SaaS będzie kosztować 50 USD miesięcznie.
wniosek
Po wykonaniu wszystkich powyższych kroków utworzysz analitykę po stronie serwera. Pamiętaj, że nie jest to tak proste, jak samo podłączenie analityki klienta, ponieważ wszystko trzeba skonfigurować samodzielnie. Dlatego przed stworzeniem własnego systemu warto porównać potrzebę poważnego systemu analitycznego z zasobami, które jesteś gotowy na niego przeznaczyć.
Jeśli przeliczyłeś wszystko i stwierdziłeś, że koszty są zbyt wysokie, w kolejnej części opowiem o tym, jak stworzyć tańszą wersję analityki back-end.
Dziękuje za przeczytanie! Chętnie odpowiem na pytania w komentarzach.
Źródło: www.habr.com