Как на прошлом проекте хранились данные?

Архитектура хранения данных на прошлом проекте

На моём последнем проекте (мобильный финтех) мы строили многоуровневую систему хранения, оптимизированную для скорости и надёжности.

Общая архитектура

Слои данных:

1. Operational layer — PostgreSQL для транзакций
2. Distributed layer — Hadoop HDFS для raw данных
3. Analytics layer — ClickHouse для метрик в реальном времени
4. Caching layer — Redis для горячих данных
5. Archive layer — S3 для долгохранения

1. PostgreSQL — OLTP

Назначение: Основная БД для приложения, обработка транзакций.

Таблицы:

CREATE TABLE transactions (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT NOT NULL,
    amount DECIMAL(10,2),
    status VARCHAR(50),
    created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_tx_user_status ON transactions(user_id, status);

Стратегия:

• Партиционирование по месяцам
• Архивирование старых данных
• Connection pooling (100-200 connections)
• Primary + 2 Standby для failover

2. Hadoop HDFS — Data Lake

Назначение: Raw данные всех операций, неизменяемый источник истины.

Структура:

/data/raw/transactions/2025-01-01/
/data/processed/aggregates/
/data/staging/temp/

Инжест: PySpark job каждый час из PostgreSQL в Parquet.

3. ClickHouse — Analytics

Назначение: Быстрые аналитические запросы, метрики в реальном времени.

CREATE TABLE events (
    timestamp DateTime,
    user_id UInt64,
    event_type String,
    amount Decimal(10,2)
)
ENGINE = ReplacingMergeTree(timestamp)
PARTITION BY toYYYYMM(timestamp)
ORDER BY (user_id, timestamp);

Синхронизация: CDC через Debezium Kafka, latency < 1 сек.

4. Redis — Cache

Назначение: Горячие данные, сессии, rate limiting.

red.setex(f"user:{user_id}:balance", 3600, balance)
red.hset(f"session:{session_id}", mapping={...})
requests = red.incr(f"ratelimit:{user_id}:{hour}")

Кластер: 3 мастер + 6 replica с Sentinel

5. S3 — Archive

Назначение: Долгосрочное хранение, compliance, backup.

pg_dump fintech | gzip > backup.tar.gz
aws s3 cp backup.tar.gz s3://archive/daily/

Retention: 30 дней в S3, затем → Glacier

Data Flow

Application → PostgreSQL
              ↓ (CDC via Kafka)
           ┌──┴──┬────────┐
          Redis HDFS   ClickHouse
           (L1) (raw)  (analytics)
                  ↓         ↓
                 S3      Dashboards

Ключевые решения

Parquet: Сжатие 10x, ленивая загрузка колонок

Partitioning по времени: Быстрое прунинг, параллельная обработка

CDC (Debezium): PostgreSQL → Kafka → ClickHouse asynchromously

Multi-tier caching:

• L1: Redis (ms)
• L2: ClickHouse (seconds)
• L3: HDFS (minutes)

Результаты

• API latency: < 50ms (Redis)
• Analytics queries: < 1 сек (ClickHouse)
• Data freshness: < 60 сек
• Reliability: 99.95% uptime
• Масштабировалась до 100М транзакций в день