Vytvoření BI systému na PostgreSQL a DataLens pro analýzu tržišť
Vývojářský tým vytvořil BI systém pro analýzu dat z osobních účtů na Wildberries a Ozon. Systém využívá PostgreSQL jako hlavní úložiště, Yandex DataLens pro vizualizaci a Python skripty pro stahování z API. To umožnilo automatizovat denní aktualizace, optimalizovat dotazy a zavést verzování nákladů.
Projekt se vyvinul z ručního nahrávání do Google Tabulí do škálovatelné služby s orchestrací klientů přes webhooky.
Problémy s existujícími službami a start projektu
Standardní analytické služby neposkytovaly jednotný obraz dat z více zdrojů. Tým, který má zkušenosti s API WB a Ozon, se rozhodl postavit vlastní řešení na DataLens.
První dashboardy byly vytvořeny z dat z Google Tabulí. Nestabilita připojení však donutila přejít na vlastní server s databází. Zpočátku se používal MySQL, ale rychle se migrovalo na PostgreSQL 16 pro lepší výkon s velkými objemy.
Automatizace stahování byla realizována přes Cron úlohy. Skripty parsují JSON/REST API, normalizují data a ukládají je do databáze.
Architektura jádra a škálování
Klíčový prvek – modulární jádro skriptů. Spouští se s konfigurací klienta, což umožňuje centrálně aktualizovat logiku pro všechny uživatele. Změny v API protokolu se automaticky aplikují na všechny.
Proměnné ve skriptech (časování, limity) se přizpůsobují objemu dat klienta, čímž se předchází chybám 429.
Škálování:
- Demo verze na anonymizovaných datech pro testy.
- Přihlašovací formulář na webu s webhookem k orchestrátoru.
- Automatické vytvoření dashboardu a rozeslání přístupů.
- Stahování historických dat: WB – až 1 rok, Ozon – až 2 roky.
Propojení s Google Tabuli zůstalo pro zadávání nákladů a plánu prodeje – skripty je stahují automaticky.
Optimalizace výkonu
Původní datasety v DataLens spoléhaly na mnohonásobné JOIN, což zpomalovalo dashboardy na 15–20 sekund. Optimalizace:
- Předvýpočet dat na serveru: ekonomika, struktura nákladů, zisk se ukládají do databáze.
- Obohacení tabulek ve fázi stahování: přidání kategorií podle článku (
vendor_code) bez JOIN v DataLens. - Minimalizace JOIN na 2–3 na dashboard.
Výsledek: doba načítání se zkrátila na 5 sekund. Denní skripty předvýpočtu trvají 30 sekund.
Průchozí filtry na dashboardech zajišťují pohodlnou navigaci podle období, kategorií a článků.
Současný technologický stack
┌──────────────────────────────┐
│ API WB / OZON │
│ (JSON/REST) │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Python skripty │ <----> │ Google tabule │
│ (parsování, normalizace) │ │ (náklady, plán) │
└──────────────┬───────────────┘ └──────────────────────────────┘
│
▼
┌──────────────────────────────┐
│ PostgreSQL 16 │
│ (hlavní úložiště) │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Yandex DataLens │
│ (vizualizace) │
└──────────────────────────────┘Backend: Python, psycopg2, requests, subprocess, python-dotenv, Flask
Databáze: PostgreSQL 16, SQL
Automatizace: Cron, orchestrátor
BI: DataLens
AI modely (Claude Sonnet/Opus) byly použity pro urychlení vývoje skriptů a ladění.
Verzování nákladů
Náklady se v čase mění, což vyžaduje úpravu historických dat bez zkreslení analýzy. Řešení: sloupec start_date v tabulce.
Logika:
- Základní hodnota bez data.
- Nové záznamy s
start_datepro verze. - Výpočet podle priority: aktuální náklady na datum prodeje podle klíče
start_date + vendor_code.
Příklad vložení:
INSERT INTO wb_cost_price VALUES
('ART-001', 800.00, '2025-01-01'),
('ART-001', 900.00, '2025-06-01'), -- zvýšeno
('ART-001', 850.00, '2026-02-01'); -- sníženoTo zajišťuje přesný přepočet zisku zpětně.
Co je důležité
- Modulární jádro umožňuje aktualizovat logiku stahování pro všechny klienty centrálně.
- Předvýpočet na serveru zkracuje dobu načítání dashboardů 3–4krát.
- Verzování nákladů zachovává historickou přesnost bez přepisování dat.
- Automatizace onboarding přes webhooky minimalizuje ruční práci.
- PostgreSQL 16 je optimální pro analýzu s obohacením tabulek.
— Editorial Team
Zatím žádné komentáře.