Chmurowa platforma analityczna

Problem: Modele Python dostarczone przez zespół data science zostały napisane w sposób sekwencyjny – obliczenia wykonywały się jedno po drugim. Pełne uruchomienie analizy z wieloma kombinacjami parametrów (wskaźniki rozpoznawalności, segmenty rynku, zestawy współczynników) bezpośrednio na platformie mogło zająć nawet godzinę, ponieważ praca nadal odbywała się w jednym wątku.

Rozwiązanie: Primotly we współpracy z zespołem data science zidentyfikowało naturalne granice zrównoleglania w każdym modelu. Ogólny schemat podzielono na: przygotowanie danych (proces pojedynczy) → obliczenia równoległe (wiele niezależnych podzadań, po jednym na kombinację parametrów lub segment rynku) → agregacja wyników (proces pojedynczy). Primotly przebudowało backend w celu orkiestracji tego wzorca (fan-out/fan-in), uruchamiając równoległe procesy robocze (workers) dla każdego podzadania i zbierając wyniki po zakończeniu pracy wszystkich procesów. Wymagało to ścisłej współpracy z matematykami klienta, aby zrozumieć, jak zdekomponować algorytmy bez wpływu na poprawność wyników – co stanowiło niebanalne wyzwanie projektowe ze względu na logiczne zależności między niektórymi krokami.

Efekt: czas obliczeń był sukcesywnie skracany w miarę rozwoju platformy. Większość zadań analitycznych uruchamia się teraz w mniej niż 10 minut, a cała droga od ery przedplatformowej – gdy analizy trwały od kilku godzin do kilku dni na lokalnych maszynach – oznacza skrócenie czasu obliczeń o ponad 98%.

Problem: Każdy moduł analityczny zależy od biblioteki Pythona utrzymywanej przez zespół data science klienta w osobnym repozytorium. Biblioteki te rozwijają się niezależnie, mają własne cykle wydawnicze i nie podlegają kontroli Primotly. Utrzymanie platformy w synchronizacji z aktualizacjami bibliotek bez uszkadzania istniejących funkcji wymagało ustrukturyzowanego podejścia do zarządzania zależnościami.

Rozwiązanie: Każdy moduł posiada własną usługę backendową w kodzie Primotly, która importuje odpowiednią bibliotekę data science jako pakiet Pythona. Interfejs między kodem Primotly a zewnętrzną biblioteką jest celowo uproszczony – Primotly wyłącznie wywołuje metody, a nie przepisuje algorytmy. Autoryzacja i zarządzanie użytkownikami są obsługiwane poprzez integrację .NET z centralnym węzłem danych badawczych, co zapewnia spójną kontrolę dostępu we wszystkich wewnętrznych platformach firmy.

Efekt: czyste oddzielenie inżynierii platformy (Primotly) od metodologii statystycznej (zespół data science klienta). Aktualizacje algorytmów mogą być wdrażane poprzez prostą aktualizację zależności bibliotecznych, bez konieczności modyfikowania kodu orkiestracji napisanego przez Primotly.

Problem: Obciążenia analityczne (workloads) różnią się od typowych zadań aplikacji webowych – wymagają dużej mocy obliczeniowej, trwają długo i występują skokowo. Standardowa monolityczna architektura webowa skutkowałaby nadmiarowym alokowaniem zasobów w okresach bezczynności lub ich dużym niedoborem w momentach szczytowego zapotrzebowania analitycznego.

Rozwiązanie: Platforma wykorzystuje architekturę typu monolit z elementami mikrousług (monolith-with-microservices-elements). Główna aplikacja działa jako monolit, co zapewnia prostotę wdrożenia i współdzielony dostęp do danych. Z kolei ciężkie obliczenia analityczne są oddelegowywane do odizolowanych procesów roboczych (worker processes), które mogą być skalowane całkowicie niezależnie. Daje to korzyści płynące z prostoty monolitu dla większości sekcji aplikacji, jednocześnie efektywnie obsługując zadania wymagające dużej mocy obliczeniowej.

Efekt: optymalne wykorzystanie zasobów zarówno w okresach przestoju, jak i w godzinach szczytu, a poszczególne moduły analityczne mogą być skalowane niezależnie w zależności od bieżącego zapotrzebowania – moduły wymagające intensywnych obliczeń otrzymują więcej zasobów bez wpływu na lżejsze procesy w tle.