BI-System auf DataLens und PostgreSQL für WB Ozon

Aufbau eines BI-Systems mit PostgreSQL und DataLens für Marktplatz-Analysen

Ein Entwicklungsteam hat ein BI-System zur Analyse von Daten aus Wildberries- und Ozon-Verkäuferkonten erstellt. Das System nutzt PostgreSQL als primären Speicher, Yandex DataLens für die Visualisierung und Python-Skripte für die API-Datenextraktion. Dies ermöglichte die Automatisierung täglicher Updates, die Optimierung von Abfragen und die Implementierung von Kostenversionierung.

Das Projekt entwickelte sich von manuellen Uploads in Google Sheets zu einem skalierbaren Dienst mit Client-Orchestrierung über Webhooks.

Probleme mit bestehenden Diensten und Projektstart

Standard-Analytics-Dienste konnten keine einheitliche Sicht auf Daten aus mehreren Quellen bieten. Basierend auf Erfahrungen mit den WB- und Ozon-APIs entschied sich das Team, eine eigene Lösung auf DataLens aufzubauen.

Zunächst wurden Dashboards mit Daten aus Google Sheets erstellt. Instabile Verbindungen führten jedoch zum Umzug auf einen dedizierten Server mit einer Datenbank. Anfangs wurde MySQL verwendet, doch für bessere Leistung bei großen Datenmengen erfolgte schnell die Migration zu PostgreSQL 16.

Die Automatisierung der Datenextraktion wurde über Cron-Jobs implementiert. Skripte parsen JSON/REST-APIs, normalisieren Daten und speichern sie in der Datenbank.

Kernarchitektur und Skalierung

Das Schlüsselelement ist ein modularer Skriptkern. Er läuft mit einer Client-Konfiguration, was zentralisierte Updates der Logik für alle Nutzer ermöglicht. Änderungen in API-Protokollen werden automatisch für alle übernommen.

Variablen in den Skripten (Zeitsteuerungen, Limits) passen sich dem Datenvolumen des Clients an und vermeiden so 429-Fehler.

Skalierung:

• Demoversion mit anonymisierten Daten zum Testen.
• Webseiten-Formular mit einem Webhook zum Orchestrator.
• Automatische Dashboard-Erstellung und Zugriffsverteilung.
• Historische Datenextraktion: WB – bis zu 1 Jahr, Ozon – bis zu 2 Jahre.

Die Verbindung zu Google Sheets bleibt für die Eingabe von Selbstkostenpreisen und Verkaufsplänen erhalten – Skripte extrahieren sie automatisch.

Leistungsoptimierung

Anfängliche Datensätze in DataLens basierten auf mehreren JOINs, was die Dashboards auf 15–20 Sekunden verlangsamte. Optimierung:

• Vorberechnung auf dem Server: Wirtschaftlichkeit, Kostenstruktur, Gewinn werden in der Datenbank gespeichert.
• Tabellenanreicherung während der Extraktion: Hinzufügen von Kategorien nach Herstellerartikelnummer (vendor_code) ohne JOINs in DataLens.
• Minimierung der JOINs auf 2–3 pro Dashboard.

Ergebnis: Ladezeit auf 5 Sekunden reduziert. Tägliche Vorberechnungsskripte dauern 30 Sekunden.

Kreuzfilter auf den Dashboards ermöglichen bequeme Navigation nach Zeiträumen, Kategorien und Herstellerartikelnummern.

Aktueller Technologie-Stack

┌──────────────────────────────┐
│ API WB / OZON                │
│ (JSON/REST)                  │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐        ┌──────────────────────────────┐
│ Python-Skripte               │ <----> │ Google Sheets                │
│ (Parsing, Normalisierung)    │        │ (Selbstkostenpreis, Plan)    │
└──────────────┬───────────────┘        └──────────────────────────────┘
               │
               ▼
┌──────────────────────────────┐
│ PostgreSQL 16                │
│ (primärer Speicher)          │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Yandex DataLens              │
│ (Visualisierung)             │
└──────────────────────────────┘

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

Datenbank: PostgreSQL 16, SQL

Automatisierung: Cron, Orchestrator

BI: DataLens

KI-Modelle (Claude Sonnet/Opus) wurden zur Beschleunigung der Skriptentwicklung und Fehlerbehebung genutzt.

Kostenversionierung

Selbstkostenpreise ändern sich im Laufe der Zeit, was Anpassungen historischer Daten ohne Verzerrung der Analysen erfordert. Lösung: eine start_date-Spalte in der Tabelle.

Logik:

• Basiswert ohne Datum.
• Neue Einträge mit start_date für Versionen.
• Berechnung nach Priorität: tatsächlicher Selbstkostenpreis am Verkaufsdatum nach Schlüssel start_date + vendor_code.

Einfügungsbeispiel:

INSERT INTO wb_cost_price VALUES
('ART-001', 800.00, '2025-01-01'),
('ART-001', 900.00, '2025-06-01'), -- erhöht
('ART-001', 850.00, '2026-02-01'); -- gesenkt

Dies gewährleistet eine genaue Gewinnneuberechnung rückwirkend.

Wichtige Erkenntnisse

• Modularer Kern ermöglicht zentralisierte Updates der Extraktionslogik für alle Kunden.
• Vorberechnung auf dem Server reduziert die Dashboard-Ladezeit um das 3–4-fache.
• Kostenversionierung bewahrt historische Genauigkeit ohne Überschreiben von Daten.
• Automatisiertes Onboarding über Webhooks minimiert manuellen Aufwand.
• PostgreSQL 16 ist optimal für Analysen mit Tabellenanreicherung.

— Editorial Team