Sistema BI en DataLens y PostgreSQL para WB Ozon

Construcción de un Sistema de BI con PostgreSQL y DataLens para Análisis de Marketplaces

Un equipo de desarrollo creó un sistema de BI para analizar datos de cuentas de vendedores en Wildberries y Ozon. El sistema utiliza PostgreSQL como almacenamiento principal, Yandex DataLens para visualización y scripts en Python para la extracción de datos mediante API. Esto permitió automatizar actualizaciones diarias, optimizar consultas e implementar versionado de costos.

El proyecto evolucionó desde cargas manuales en Google Sheets hasta convertirse en un servicio escalable con orquestación de clientes mediante webhooks.

Problemas con Servicios Existentes y Lanzamiento del Proyecto

Los servicios de análisis estándar no lograban ofrecer una visión unificada de datos provenientes de múltiples fuentes. Aprovechando la experiencia con las API de WB y Ozon, el equipo decidió construir su propia solución en DataLens.

Inicialmente, se crearon dashboards utilizando datos de Google Sheets. Sin embargo, la inestabilidad en las conexiones motivó la migración a un servidor dedicado con una base de datos. Al principio se usó MySQL, pero rápidamente se migró a PostgreSQL 16 para un mejor rendimiento con grandes volúmenes.

La automatización de la extracción de datos se implementó mediante tareas Cron. Los scripts analizan APIs JSON/REST, normalizan los datos y los guardan en la base de datos.

Arquitectura Central y Escalabilidad

El elemento clave es un núcleo modular de scripts. Se ejecuta con una configuración por cliente, permitiendo actualizaciones centralizadas de la lógica para todos los usuarios. Los cambios en los protocolos de API se aplican automáticamente a todos.

Las variables en los scripts (tiempos, límites) se adaptan al volumen de datos del cliente, evitando errores 429.

Escalabilidad:

• Versión demo con datos anonimizados para pruebas.
• Formulario de solicitud en el sitio web con un webhook al orquestador.
• Creación automática de dashboards y distribución de acceso.
• Extracción de datos históricos: WB — hasta 1 año, Ozon — hasta 2 años.

El vínculo con Google Sheets se mantiene para ingresar el costo y los planes de ventas — los scripts los extraen automáticamente.

Optimización del Rendimiento

Los conjuntos de datos iniciales en DataLens dependían de múltiples JOINs, ralentizando los dashboards a 15–20 segundos. Optimización:

• Pre-cálculo en el servidor: economía, estructura de costos, ganancias se almacenan en la base de datos.
• Enriquecimiento de tablas durante la extracción: adición de categorías por código de proveedor (vendor_code) sin JOINs en DataLens.
• Minimización de JOINs a 2–3 por dashboard.

Resultado: tiempo de carga reducido a 5 segundos. Los scripts de pre-cálculo diario toman 30 segundos.

Los filtros cruzados en los dashboards proporcionan una navegación conveniente por períodos, categorías y códigos de proveedor.

Stack Tecnológico Actual

┌──────────────────────────────┐
│ API WB / OZON                │
│ (JSON/REST)                  │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐        ┌──────────────────────────────┐
│ Scripts en Python            │ <----> │ Google Sheets                │
│ (análisis, normalización)    │        │ (costo, plan)                │
└──────────────┬───────────────┘        └──────────────────────────────┘
               │
               ▼
┌──────────────────────────────┐
│ PostgreSQL 16                │
│ (almacenamiento principal)   │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Yandex DataLens              │
│ (visualización)              │
└──────────────────────────────┘

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

Base de datos: PostgreSQL 16, SQL

Automatización: Cron, orquestador

BI: DataLens

Se utilizaron modelos de IA (Claude Sonnet/Opus) para acelerar el desarrollo y depuración de scripts.

Versionado de Costos

El costo cambia con el tiempo, requiriendo ajustes en datos históricos sin distorsionar el análisis. Solución: una columna start_date en la tabla.

Lógica:

• Valor base sin fecha.
• Nuevas entradas con start_date para versiones.
• Cálculo por prioridad: costo real en la fecha de venta por clave start_date + vendor_code.

Ejemplo de inserción:

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

Esto garantiza un recálculo preciso de ganancias de forma retroactiva.

Conclusiones Clave

• Núcleo modular permite actualizaciones centralizadas de la lógica de extracción para todos los clientes.
• Pre-cálculo en el servidor reduce el tiempo de carga de dashboards en 3–4 veces.
• Versionado de costos mantiene la precisión histórica sin sobrescribir datos.
• Incorporación automatizada mediante webhooks minimiza el esfuerzo manual.
• PostgreSQL 16 es óptimo para análisis con enriquecimiento de tablas.

— Editorial Team