System BI na DataLens i PostgreSQL dla WB Ozon

Budowanie systemu BI na PostgreSQL i DataLens do analizy platform sprzedażowych

Zespół programistów stworzył system BI do analizy danych z paneli sprzedawców Wildberries i Ozon. System wykorzystuje PostgreSQL jako główne repozytorium, Yandex DataLens do wizualizacji oraz skrypty Python do pobierania danych z API. To pozwoliło zautomatyzować codzienne aktualizacje, zoptymalizować zapytania i wdrożyć wersjonowanie kosztów własnych.

Projekt ewoluował od ręcznego ładowania do Arkuszy Google do skalowalnej usługi z orkiestracją klientów przez webhooki.

Problemy z istniejącymi serwisami i start projektu

Standardowe serwisy analityczne nie dawały spójnego obrazu danych z wielu źródeł. Zespół, posiadający doświadczenie w pracy z API WB i Ozon, postanowił zbudować własne rozwiązanie na DataLens.

Pierwsze pulpity nawigacyjne tworzono na danych z Arkuszy Google. Jednak niestabilność połączeń zmusiła do przejścia na własny serwer z bazą danych. Początkowo używano MySQL, ale szybko migrowano na PostgreSQL 16 dla lepszej wydajności z dużymi wolumenami.

Automatyzacja pobierania zrealizowana przez zadania Cron. Skrypty parsują JSON/REST API, normalizują dane i zapisują do bazy danych.

Architektura rdzenia i skalowanie

Kluczowy element — modułowy rdzeń skryptów. Uruchamia się z konfiguracją klienta, co pozwala centralnie aktualizować logikę dla wszystkich użytkowników. Zmiany w protokole API automatycznie stosowane są do wszystkich.

Zmienne w skryptach (czas, limity) adaptowane do wolumenu danych klienta, unikając błędów 429.

Skalowanie:

• Wersja demo na anonimizowanych danych do testów.
• Formularz zgłoszeniowy na stronie z webhookiem do orkiestratora.
• Automatyczne tworzenie pulpitu i wysyłanie dostępu.
• Pobieranie danych historycznych: WB — do 1 roku, Ozon — do 2 lat.

Integracja z Arkuszami Google zachowana do wprowadzania kosztów własnych i planu sprzedaży — skrypty pobierają je automatycznie.

Optymalizacja wydajności

Początkowe zbiory danych w DataLens opierały się na wielu JOIN, co spowalniało pulpity do 15–20 sekund. Optymalizacja:

• Wstępne obliczenia danych na serwerze: ekonomika, struktura kosztów, zysk zapisywane w bazie danych.
• Wzbogacanie tabel na etapie pobierania: dodawanie kategorii według kodu produktu (vendor_code) bez JOIN w DataLens.
• Minimalizacja JOIN do 2–3 na pulpit.

Rezultat: czas ładowania skrócony do 5 sekund. Codzienne skrypty wstępnych obliczeń zajmują 30 sekund.

Filtry globalne na pulpitach zapewniają wygodną nawigację po okresach, kategoriach i kodach produktów.

Obecny stos technologiczny

┌──────────────────────────────┐
│ API WB / OZON                │
│ (JSON/REST)                  │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐        ┌──────────────────────────────┐
│ Skrypty Python               │ <----> │ Arkusze Google               │
│ (parsowanie, normalizacja)   │        │ (koszt własny, plan)         │
└──────────────┬───────────────┘        └──────────────────────────────┘
               │
               ▼
┌──────────────────────────────┐
│ PostgreSQL 16                │
│ (główne repozytorium)        │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Yandex DataLens              │
│ (wizualizacja)               │
└──────────────────────────────┘

Backend: Python, psycopg2, requests, subprocess, python-dotenv, Flask

Baza danych: PostgreSQL 16, SQL

Automatyzacja: Cron, orkiestrator

BI: DataLens

Modele AI (Claude Sonnet/Opus) wykorzystano do przyspieszenia rozwoju skryptów i debugowania.

Wersjonowanie kosztów własnych

Koszt własny zmienia się w czasie, co wymaga korekty danych historycznych bez zniekształcania analityki. Rozwiązanie: kolumna start_date w tabeli.

Logika:

• Wartość bazowa bez daty.
• Nowe wpisy z start_date dla wersji.
• Obliczenia według priorytetu: aktualny koszt własny na datę sprzedaży według klucza start_date + vendor_code.

Przykład wstawienia:

INSERT INTO wb_cost_price VALUES
('ART-001', 800.00, '2025-01-01'),
('ART-001', 900.00, '2025-06-01'), -- podwyżka
('ART-001', 850.00, '2026-02-01'); -- obniżka

To zapewnia dokładne przeliczenie zysku wstecznie.

Co jest ważne

• Modułowy rdzeń pozwala aktualizować logikę pobierania dla wszystkich klientów centralnie.
• Wstępne obliczenia na serwerze skracają czas ładowania pulpitów 3–4 razy.
• Wersjonowanie kosztów własnych zachowuje historyczną dokładność bez nadpisywania danych.
• Automatyzacja onboardingu przez webhooki minimalizuje pracę ręczną.
• PostgreSQL 16 optymalny do analityki z wzbogacaniem tabel.

— Editorial Team