DataLens 和 PostgreSQL 上的 BI 系统，用于 WB Ozon

基于PostgreSQL与DataLens构建电商平台BI系统：Wildberries与Ozon数据分析实战

开发团队为分析Wildberries和Ozon卖家账户数据，构建了一套BI系统。该系统以PostgreSQL作为主存储，Yandex DataLens用于可视化，Python脚本负责API数据提取。这实现了每日更新的自动化、查询优化以及成本版本控制功能。

项目从手动上传至Google Sheets逐步演变为一个可通过Webhook进行客户端编排的可扩展服务。

现有服务问题与项目启动

标准分析服务无法提供多源数据的统一视图。凭借对WB和Ozon API的经验，团队决定基于DataLens自建解决方案。

初始仪表板使用Google Sheets数据创建。然而，连接不稳定性促使团队转向专用服务器与数据库。最初使用MySQL，但为提升大数据量性能，迅速迁移至PostgreSQL 16。

数据提取自动化通过Cron任务实现。脚本解析JSON/REST API，规范化数据并保存至数据库。

核心架构与扩展

关键要素是模块化脚本核心。它根据客户端配置运行，允许集中更新所有用户的逻辑。API协议变更会自动应用于所有用户。

脚本中的变量（如时间间隔、限制）根据客户端数据量自适应调整，避免429错误。

扩展方案：

• 提供匿名化数据的演示版本用于测试。
• 网站申请表单通过Webhook连接至编排器。
• 自动创建仪表板并分配访问权限。
• 历史数据提取：WB最长1年，Ozon最长2年。

与Google Sheets的链接保留用于输入成本价和销售计划——脚本自动提取这些数据。

性能优化

DataLens中的初始数据集依赖多个JOIN操作，导致仪表板加载缓慢至15–20秒。优化措施：

• 服务器端预计算：经济指标、成本结构、利润等存储在数据库中。
• 提取时表增强：按货号（vendor_code）添加分类，避免在DataLens中使用JOIN。
• 将每个仪表板的JOIN操作减至2–3个。

结果：加载时间缩短至5秒。每日预计算脚本耗时30秒。

仪表板上的交叉筛选器提供按周期、分类和货号的便捷导航。

当前技术栈

┌──────────────────────────────┐
│ API WB / OZON                │
│ (JSON/REST)                  │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐        ┌──────────────────────────────┐
│ Python脚本                   │ <----> │ Google表格                   │
│ (解析、规范化)               │        │ (成本价、计划)               │
└──────────────┬───────────────┘        └──────────────────────────────┘
               │
               ▼
┌──────────────────────────────┐
│ PostgreSQL 16                │
│ (主存储)                     │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Yandex DataLens              │
│ (可视化)                     │
└──────────────────────────────┘

后端： Python、psycopg2、requests、subprocess、python-dotenv、Flask

数据库： PostgreSQL 16、SQL

自动化： Cron、编排器

BI工具： DataLens

AI模型（Claude Sonnet/Opus）用于加速脚本开发与调试。

成本版本控制

成本价随时间变化，需调整历史数据而不扭曲分析。解决方案：在表中添加start_date列。

逻辑：

• 无日期的基准值。
• 带start_date的新条目用于版本控制。
• 按优先级计算：基于start_date + vendor_code键，取销售日期的实际成本价。

插入示例：

INSERT INTO wb_cost_price VALUES
('ART-001', 800.00, '2025-01-01'),
('ART-001', 900.00, '2025-06-01'), -- 上涨
('ART-001', 850.00, '2026-02-01'); -- 下降

这确保了利润的准确追溯重算。

关键要点

• 模块化核心允许集中更新所有客户端的数据提取逻辑。
• 服务器端预计算将仪表板加载时间缩短3–4倍。
• 成本版本控制在无需覆盖数据的情况下保持历史准确性。
• 通过Webhook的自动化入驻最小化人工操作。
• PostgreSQL 16结合表增强功能，是分析任务的理想选择。

— Editorial Team