PostgreSQL와 DataLens로 마켓플레이스 분석 BI 시스템 구축하기
개발팀이 Wildberries와 Ozon 판매자 계정 데이터를 분석하기 위한 BI 시스템을 구축했습니다. 이 시스템은 PostgreSQL를 기본 저장소로, Yandex DataLens를 시각화 도구로, Python 스크립트를 API 데이터 추출에 사용합니다. 이를 통해 일일 업데이트 자동화, 쿼리 최적화, 원가 버전 관리 구현이 가능해졌습니다.
이 프로젝트는 Google Sheets에 수동으로 업로드하던 방식에서 웹훅을 통한 클라이언트 오케스트레이션이 가능한 확장성 있는 서비스로 발전했습니다.
기존 서비스의 문제점과 프로젝트 시작
표준 분석 서비스들은 여러 출처의 데이터를 통합적으로 보여주지 못했습니다. WB와 Ozon API 경험을 활용하여, 팀은 DataLens 기반 자체 솔루션 구축을 결정했습니다.
초기 대시보드는 Google Sheets 데이터로 생성되었습니다. 그러나 연결 불안정성으로 인해 전용 서버와 데이터베이스로 전환하게 되었습니다. 처음에는 MySQL을 사용했지만, 대용량 데이터 처리 성능을 위해 PostgreSQL 16으로 빠르게 마이그레이션했습니다.
데이터 추출 자동화는 Cron 작업을 통해 구현되었습니다. 스크립트들은 JSON/REST API를 파싱하고, 데이터를 정규화하며, 데이터베이스에 저장합니다.
핵심 아키텍처와 확장성
핵심 요소는 모듈식 스크립트 코어입니다. 클라이언트 설정과 함께 실행되어 모든 사용자에게 로직 업데이트를 중앙 집중식으로 적용할 수 있습니다. API 프로토콜 변경 사항은 자동으로 모든 사용자에게 적용됩니다.
스크립트 내 변수들(타이밍, 제한)은 클라이언트 데이터 양에 맞춰 조정되어 429 오류를 방지합니다.
확장성:
- 익명화된 데이터로 테스트 가능한 데모 버전
- 오케스트레이터로 웹훅을 보내는 웹사이트 신청서
- 자동 대시보드 생성 및 접근 권한 배포
- 과거 데이터 추출: WB — 최대 1년, Ozon — 최대 2년
Google Sheets와의 연결은 원가와 판매 계획 입력을 위해 유지됩니다 — 스크립트들이 이를 자동으로 추출합니다.
성능 최적화
DataLens의 초기 데이터셋은 여러 JOIN에 의존하여 대시보드 로딩 시간을 15–20초로 늦췄습니다. 최적화 방법:
- 서버 측 사전 계산: 경제성, 원가 구조, 이익이 데이터베이스에 저장됩니다.
- 추출 중 테이블 보강: DataLens에서 JOIN 없이 벤더 코드(
vendor_code)별 카테고리 추가 - 대시보드당 JOIN을 2–3개로 최소화
결과: 로딩 시간이 5초로 단축되었습니다. 일일 사전 계산 스크립트는 30초가 소요됩니다.
대시보드의 교차 필터는 기간, 카테고리, 벤더 코드별 편리한 탐색을 제공합니다.
현재 기술 스택
┌──────────────────────────────┐
│ API WB / OZON │
│ (JSON/REST) │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Python scripts │ <----> │ Google Sheets │
│ (parsing, normalization) │ │ (cost price, plan) │
└──────────────┬───────────────┘ └──────────────────────────────┘
│
▼
┌──────────────────────────────┐
│ PostgreSQL 16 │
│ (primary storage) │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Yandex DataLens │
│ (visualization) │
└──────────────────────────────┘백엔드: 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배 단축시킵니다.
- 원가 버전 관리는 데이터를 덮어쓰지 않으면서 과거 정확도를 유지합니다.
- 웹훅을 통한 자동 온보딩은 수작업을 최소화합니다.
- PostgreSQL 16은 테이블 보강이 필요한 분석 작업에 최적입니다.
— Editorial Team
아직 댓글이 없습니다.