Розробка системи реплікації ринкових даних

Розробка системи репліка ції ринкових даних

Репліка ція ринкових даних вирішує завдання надійного поширення market feed від первинних джерел (бірж) до множини споживачів у різних географічних локаціях або ізольованих середовищах. Це не просто копіювання — це забезпечення консистентності, відмовостійкості та масштабованості потоку даних.

Чому потрібна репліка ція

Торговельні системи часто мають декілька компонентів, що працюють у різних середовищах:

• Production trading — на серверах близько до бірж (co-location або низька latency)
• Research/backtesting — у дата-центрах з великими обсягами сховища
• Risk management — у захищеній мережі з обмеженим доступом
• Analytics dashboards — доступні широкій аудиторії

Кожне з цих середовищ повинне отримувати однакові дані без перевантаження джерела.

Топології репліка ції

Hub-and-Spoke — один primary-агрегатор збирає дані з бірж, декілька replica-узлів підписуються на нього. Проста реалізація, single point of failure на hub.

Chain Replication — дані передаються по ланцюжку: біржа → primary → secondary → tertiary. Низька навантаження на первинне джерело, висока cumulative latency.

Pub-Sub через Kafka — primary пише в Kafka, будь-яка кількість consumer groups читає незалежно. Найбільш гнучкий варіант для production.

Kafka як backbone репліка ції

Kafka ідеально підходить для репліка ції ринкових даних:

• Durability — дані зберігаються на диску, consumer може перечитати будь-який історичний період
• Scalability — горизонтальне масштабування через партиціонування
• Consumer Groups — різні споживачи читають один і той же топік незалежно
• Exactly-once delivery — при правильній настройці idempotent producer

Topic: market.trades.binance.BTCUSDT
  Partition 0: trades (all, ordered by time)

Topic: market.orderbook.binance.BTCUSDT
  Partition 0: snapshots + diffs (ordered by update_id)

Topic: market.candles.binance.BTCUSDT.1m
  Partition 0: 1-minute OHLCV (ordered by candle time)

Найменування топіків: {data_type}.{exchange}.{symbol}.{interval} — дозволяє легко фільтрувати потрібні дані.

Гарантії доставки

У системах market data найчастіше використовується at-least-once delivery: краще отримати дублюючееся повідомлення, ніж втратити дані. Споживачі є ідемпотентними: дедупліка ція за trade_id або update_id.

Для критичних компонентів (risk management, позиційний облік) — exactly-once через Kafka Transactions з ідемпотентними producers та конфігура цією acks: all.

Cross-Datacenter репліка ція

Kafka MirrorMaker 2 реплікує топіки між кластерами, дозволяючи EU-кластерам отримати репліки всіх market.* топіків з невеликою затримкою (зазвичай 50–200ms для трансатла нтичної репліка ції).

Управління retention та компресією

Ринкові дані накопичуються швидко. Kafka retention політики:

# Для tick-даних: 7 днів, потім видалити
log.retention.hours=168

# Для daily OHLCV: нескінченно (використовуємо лімітування за розміром)
log.retention.bytes=10737418240  # 10 GB на партицію

# Log compaction для order book: зберігати лише останній стан за рівнем ціни
log.cleanup.policy=compact

Компресія на рівні Kafka: compression.type=zstd стискає ринкові дані на 40–70% без значних накладних витрат по CPU.

Моніторинг репліка ції

Ключові метрики:

Consumer lag > N хвилин для торговельного бота — критичний алерт. Для аналітичної системи — warning.

Schema Registry та сумісність форматів

З еволюцією схеми даних (додавання полів, зміна типів) важливо не зламати споживачів. Confluent Schema Registry + Avro забезпечують schema evolution з перевіркою сумісності, підтримуючи backward compatible зміни як опціональні поля з defaults.