Système BI sur DataLens et PostgreSQL pour WB Ozon

Construction d'un système BI avec PostgreSQL et DataLens pour l'analyse des marketplaces

Une équipe de développement a créé un système BI pour analyser les données des comptes vendeurs Wildberries et Ozon. Le système utilise PostgreSQL comme stockage principal, Yandex DataLens pour la visualisation et des scripts Python pour l'extraction des données via API. Cela a permis d'automatiser les mises à jour quotidiennes, d'optimiser les requêtes et de mettre en œuvre un système de versionnage des coûts.

Le projet est passé de téléchargements manuels dans Google Sheets à un service évolutif avec orchestration des clients via webhooks.

Problèmes des services existants et lancement du projet

Les services d'analyse standard ne permettaient pas d'avoir une vue unifiée des données provenant de multiples sources. Forte de son expérience avec les API de WB et Ozon, l'équipe a décidé de construire sa propre solution sur DataLens.

Les premiers tableaux de bord ont été créés avec des données provenant de Google Sheets. Cependant, des instabilités de connexion ont conduit à migrer vers un serveur dédié avec une base de données. MySQL a d'abord été utilisé, mais une migration rapide vers PostgreSQL 16 a été effectuée pour de meilleures performances avec de gros volumes.

L'automatisation de l'extraction des données a été mise en place via des tâches Cron. Les scripts analysent les API JSON/REST, normalisent les données et les sauvegardent dans la base de données.

Architecture centrale et mise à l'échelle

L'élément clé est un noyau de scripts modulaire. Il s'exécute avec une configuration client, permettant des mises à jour centralisées de la logique pour tous les utilisateurs. Les changements dans les protocoles API sont automatiquement appliqués à tous.

Les variables dans les scripts (timings, limites) s'adaptent au volume de données du client, évitant les erreurs 429.

Mise à l'échelle :

• Version démo avec données anonymisées pour les tests.
• Formulaire de demande sur le site web avec un webhook vers l'orchestrateur.
• Création automatique des tableaux de bord et distribution des accès.
• Extraction des données historiques : WB — jusqu'à 1 an, Ozon — jusqu'à 2 ans.

Le lien avec Google Sheets est maintenu pour saisir le prix de revient et les plans de vente — les scripts les extraient automatiquement.

Optimisation des performances

Les jeux de données initiaux dans DataLens reposaient sur de multiples JOINS, ralentissant les tableaux de bord à 15–20 secondes. Optimisation :

• Pré-calcul sur le serveur : l'économie, la structure des coûts, le profit sont stockés dans la base de données.
• Enrichissement des tables lors de l'extraction : ajout de catégories par code fournisseur (vendor_code) sans JOINS dans DataLens.
• Minimisation des JOINS à 2–3 par tableau de bord.

Résultat : temps de chargement réduit à 5 secondes. Les scripts de pré-calcul quotidiens prennent 30 secondes.

Les filtres croisés sur les tableaux de bord permettent une navigation pratique par périodes, catégories et codes fournisseurs.

Stack technologique actuelle

┌──────────────────────────────┐
│ API WB / OZON                │
│ (JSON/REST)                  │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐        ┌──────────────────────────────┐
│ Scripts Python               │ <----> │ Google Sheets                │
│ (analyse, normalisation)     │        │ (prix de revient, plan)      │
└──────────────┬───────────────┘        └──────────────────────────────┘
               │
               ▼
┌──────────────────────────────┐
│ PostgreSQL 16                │
│ (stockage principal)         │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Yandex DataLens              │
│ (visualisation)              │
└──────────────────────────────┘

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

Base de données : PostgreSQL 16, SQL

Automatisation : Cron, orchestrateur

BI : DataLens

Des modèles d'IA (Claude Sonnet/Opus) ont été utilisés pour accélérer le développement et le débogage des scripts.

Versionnage des coûts

Le prix de revient évolue dans le temps, nécessitant des ajustements des données historiques sans fausser l'analyse. Solution : une colonne start_date dans la table.

Logique :

• Valeur de base sans date.
• Nouvelles entrées avec start_date pour les versions.
• Calcul par priorité : prix de revient réel à la date de vente par clé start_date + vendor_code.

Exemple d'insertion :

INSERT INTO wb_cost_price VALUES
('ART-001', 800.00, '2025-01-01'),
('ART-001', 900.00, '2025-06-01'), -- augmentation
('ART-001', 850.00, '2026-02-01'); -- diminution

Cela garantit un recalcul précis du profit rétroactivement.

Points clés à retenir

• Noyau modulaire permet des mises à jour centralisées de la logique d'extraction pour tous les clients.
• Pré-calcul côté serveur réduit le temps de chargement des tableaux de bord par 3–4 fois.
• Versionnage des coûts maintient la précision historique sans écraser les données.
• Intégration automatisée via webhooks minimise l'effort manuel.
• PostgreSQL 16 est optimal pour l'analyse avec enrichissement des tables.

— Editorial Team