Розробка системи зберігання тік-даних: де ламається потік
Зберігання тік-даних ламається не на піку, а на асиметрії навантаження: потік котирувань зростає ступенями — на відкритті сесій, під час виходу статистики, — а конвеєр запису залишається рівним і одноточковим.
Щойно вхідна швидкість перевищує пропускну здатність приймального буфера, джерело починає відкидати повідомлення, і в архіві з’являються прогалини в записі.
Підступність у тому, що вони видно не одразу: розбіжність спливає пізніше, коли за архівом будують свічки або проганяють торгову стратегію.
Затримка запису зазвичай ховається в одному місці — на скиданні накопиченого буфера на диск. Якщо приймання даних і запис ідуть в одному потоці, кожна синхронізація з диском зупиняє приймання нових котирувань, і чим більший пакет, тим довша пауза.
Розв’язка приймання й запису через чергу та пакетне скидання допомагає, але в будь-якої такої розв’язки є поріг: за ним черга зростає швидше, ніж її розбирають, і втрати повертаються.
Третя точка відмови — фрагментація архіву. Поки інструментів і днів одиниці, файли відкриваються випадково й швидко; коли рахунок іде на мільйони сегментів, накладні витрати на пошук починають перевищувати час корисного читання.
Партиціювання за датами й тікерами знімає частину проблеми, але вимагає чесної політики стиснення й видалення, інакше обсяг зростає швидше за самі дані.
Самописний архів майже завжди починався з однієї задачі: один потік, один інструмент, один майданчик. Кожне нове джерело, зростання глибини історії або вимога до відновлення додає ще одну гілку коду без спільної моделі надійності — система втрачає передбачуваність. Розбираємо, як це закривається на кожній ділянці конвеєра.
Що дає виділене сховище: ефект у вимірюваних метриках
Профільне сховище змінює не зручність роботи з архівом, а вимірювані показники: скільки угод реально дійшло до запису, за який час віддається історичний інтервал і як швидко вузол повертається в стрій після відмови. Саме ці метрики ми виносимо на приймання.
Повнота історичних даних. На плоских файлах обрив зв’язку або перезапуск процесу залишає діри, які виявляються вже під час звірки стратегії.
Контур запису з локальним буфером і підтвердженням запису дожимає потік після перепідключення, а дублікати відсікаються за складеним ключем — інструмент, мітка часу, номер угоди.
Швидкість вибірки історії. Колонкове зберігання на ClickHouse з партиціюванням за датою та інструментом читає лише потрібні стовпці: свічки будь-якого інтервалу рахуються на льоту, без обходу тисяч файлів. Історичний інтервал віддається за секунди, і перерахунок стратегій перестає бути нічною задачею.
Час відновлення та цілісність реєстру. Репліка піднімається з копії партиції, остання доба докатується з журналу запису — вікно недоступності скорочується з годин до хвилин.
За кожною партицією сходяться контрольна сума й лічильники угод: розбіжність видно до того, як дані підуть споживачу, а не після розбору інциденту.
Замість «працює чи ні» на прийманні вимірюються частка відновлених прогалин, час відгуку на історичний інтервал і час підйому вузла. Так архів котирувань перестає бути джерелом сюрпризів.
Варіанти організації архіву котирувань: порівняння режимів
Потік угод надходить безперервно, а запити до історії — довільні: відновити стан книги заявок на момент часу, перерахувати індикатор, звірити виконання з брокерським звітом.
Один режим зберігання під усі сценарії зазвичай не витягує: швидкий запис іде на шкоду вибіркам, а зручні аналітичні таблиці погано приймають поодинокі події. На старті обирають між трьома схемами, і кожна ламається на своєму профілі навантаження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Колонкове сховище | Аналітичні вибірки за діапазоном часу та інструментом, перерахунок агрегатів. Стиснення за стовпцями разом із партиціюванням за часом дає кратну економію обсягу на історії за роки | Поодинокі вставки дорогі — потрібне пакетне завантаження. Без розбиття за часом видалення старих даних перетворюється на ручну роботу |
| Потоковий журнал | Приймання з мінімальною затримкою, відновлення стану, повторна обробка під час розбору інцидентів. Зберігає події в порядку надходження | Вибірки з фільтрами за багатьма полями потребують перезбирання в окреме сховище. Довге зберігання — лише зі стисненням історії та ротацією сегментів |
| Гібридна схема | Потрібні і приймання в реальному часі, і важка аналітика: журнал пише потік, завантажувач перекладає його в колонкові партиції | Дорожче в супроводі: звірка, ідемпотентне завантаження й контроль відставання завантажувача |
Вибір визначається профілем навантаження: співвідношенням запису й читання, глибиною історії, яку тримають «гарячою», і вимогами до відновлення після збою.
Для архіву котирувань із переважанням аналітики достатньо колонкового сховища з партиціюванням за часом; якщо система ще й торгує, гібрид закриває обидва сценарії без втрати подій.
Етапи впровадження: від аудиту потоку до передачі в експлуатацію
Тіковий потік не прощає приблизних рішень: записи йдуть нерівномірно, піки в рази вищі за середнє, а джерело періодично віддає повтори й дані заднім числом.
Тому ми йдемо не від вибору сховища, а від обстеження поточного контуру — і лише потім до схеми даних та перевірки на реальних обсягах.
- Аудит контуру зберігання. Збираємо карту джерел: частота, формат, місця втрати записів і утворення дублів. На виході — звіт із вузькими місцями та прогнозом зростання обсягу.
- Схема даних. Задаємо розбиття за часом, ключ сортування, розрядність полів і стиснення. Від цих рішень залежить і швидкість вибірки, і займаний обсяг: у ClickHouse гарячий шар віддає історію за інструментом з точністю до тіка, а старе йде в холодний архів.
- Налаштування приймання та запису. Збираємо конвеєр із буфером між джерелом і сховищем: він гасить піки, а повторна доставка не створює дублів. Окремо перевіряємо обрив зв’язку й перезапуск джерела.
- Навантажувальна перевірка. Відтворюємо історичний потік у бойовому темпі та заміряємо затримку запису й час відповіді на типові запити. Дивимося відмову вузла: вибірка не повинна перериватися.
- Звірка даних. Контрольні суми за періодами, звірка з джерелом, відновлення з резервної копії із заміром часу. Розбіжність за кількістю записів доводимо до нуля.
- Передача в експлуатацію. Віддаємо конфігурації, схему розміщення, політики зберігання й очищення, інструкції черговому та панелі спостереження за потоком. Штатні операції команда замовника виконує сама.
Склад постачання: конфігурації, схеми зберігання та регламенти
Передаємо не лише робочий контур, а й усе, що потрібно для його самостійної експлуатації. Нижче — мінімальний комплект, який залишається в команди замовника після здачі: без нього перший же збій у записі потоку перетворюється на розбір архіву вручну.
- Конфігурації сервісів запису й читання — параметри буферизації, розмір батчу, таймаути ретраїв, ліміти паралельних з’єднань. Значення винесені в окремий шар налаштувань: їх можна змінювати без перезбирання.
- Опис схеми зберігання — ключі та порядок сортування, розбиття за часом, строк життя гарячих і холодних партицій, правила ущільнення. Схема прив’язана до формату вхідного потоку, тому при зміні джерела видно, що саме переписувати.
- Документація щодо сховища — карта таблиць і службових полів, призначення кожної партиції, типові запити для звірки обсягів і пошуку прогалин у даних.
- Правила доступу — ролі для сервісів і людей розділено: запис, читання за своєю групою інструментів, повний доступ, адміністративні операції. Видача прав не потребує правки конфігів на серверах.
- Регламент обслуговування — періодичність перевірки цілісності, порядок ущільнення партицій, дії при відставанні запису, пороги алертів і те, хто на них реагує.
- Схема резервного копіювання — що копіюється, з якою частотою, де лежать копії, як перевіряється їхня придатність і скільки часу займає відновлення на чистому контурі.
- Інструкції з типових операцій — додавання нового інструмента в потік, відкат до попереднього стану схеми, вивантаження історичного зрізу для аналітики.
Комплект оформлено так, що новий інженер у команді замовника розгортає стенд і повторює процес за документом, не звертаючись до нас. Якщо задача пов’язана з міграцією або розширенням потоку — опишіть її, повернемося з оцінкою та планом робіт.
Кейс: реєстр котирувань без прогалин і з швидкою вибіркою
До: прогалини в потоці та звіти за годину
Котирування за сорока інструментами писалися в одну таблицю на одному сервері, вставка йшла по одному запису.
У години високої волатильності буфер приймання переповнювався, і частина тіків губилася: за квартал прогалини накопичилися в трьох інструментах, а відновити їх було нічим — вихідний потік ніде не зберігався.
Побудова звіту за годинними свічками та середньозваженою ціною займала 40–60 хвилин, бо агрегат щоразу рахувався за всією історією одразу.
Після: безперервний архів і вибірка за секунди
Архів розвели на два шари: гарячий — у колонковій аналітичній СУБД із партиціями за днем та інструментом, холодний — Parquet в об’єктному сховищі з розбивкою за датою та символом.
Приймання зробили ідемпотентним за ключем «інструмент + мітка часу + джерело»: повторна доставка більше не створює дублів, а звіряльний прохід за біржовим архівом Deribit закриває діри в записах.
Що зсунулося за метриками: втрати тіків — з частки відсотка до нуля на звіряльному вікні; звіт за день — 40–60 хвилин → 20–30 секунд; перевивантаження історії за рік — майже доба → 15–20 хвилин; обсяг архіву при колонковому стисненні та дедуплікації скоротився в шість разів при збереженні повної глибини.
Чим відрізняється колонковий архів від потокового журналу?
Колонковий архів і потоковий журнал — різні класи сховищ, і обирають між ними не за обсягом даних, а за тим, що з ними роблять далі.
Архів розкладає тік за стовпцями — мітка часу, ціна, обсяг, сторона угоди — і стискає кожен окремо: вибірка за діапазоном дат і за вузьким набором полів читає лише потрібні стовпці й не торкається решти.
Журнал влаштований навпаки. Записи дописуються строго в порядку надходження, підтвердження не чекає індексації, а після збою стан відновлюється переграванням до останньої підтвердженої позиції. Плата за це — читання: зріз за місяць за журналом доводиться збирати, проходячи його повністю.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Колонковий архів | Аналітика за історією: діапазони дат, агрегати, вузький набір полів | Дописування дрібними порціями дорожче — кожен фрагмент потребує ущільнення; точкові правки повільні |
| Потоковий журнал | Приймання безперервного потоку тіків, відновлення після збою, видача «гарячого» вікна | Обсяг зростає лінійно, зріз за довгий період за ним не будують — потрібне перенесення в архів |
Відновлення розводить підходи найсильніше: журнал дає точку відкату на будь-який підтверджений запис, архів — лише сегменти й знімки, що відстали від останнього тіка.
На практиці тримають обидва: журнал приймає потік і обслуговує останні хвилини, фоновий переніс ущільнює його в колонкові сегменти.
Вибір системи зберігання тік-даних зводиться до трьох чисел — глибина історії, допустима затримка читання, частка операцій запису в загальному профілі навантаження.
Технічні сумніви: відповідаємо на часті запитання
Перед стартом розробки системи зберігання тік-даних інженери перевіряють чотири речі: що буде із записами при відмові вузла, як зростає архів, чи отримають аналітики сирі дані без вивантажень і чи уживеться сховище з поточним контуром. Відповідаємо по суті.
Що станеться з даними, якщо вузол упаде в момент запису?
Потік пишеться в незмінні сегменти: сегмент спочатку фіксується на диску й лише потім стає видимим читачам. Неповний сегмент після перезапуску розпізнається й відкидається, недостатнє відновлюється повторним прийманням. Дублікати на стику гасяться за ключем «інструмент + мітка часу», тому повтор не псує історію.
Як швидко зростає архів і чим його обмежують?
Обсяг рахується заздалегідь — за кількістю інструментів, частотою оновлень і глибиною історії, тому розширення планується до того, як місце закінчиться.
Економія йде на стисненні однотипних полів і розділенні гарячого та холодного шарів: свіжі записи на швидких носіях, історія на дешевих.
Як аналітики отримують доступ, не заважаючи запису?
Читання винесено в окремий контур: запити йдуть на репліки та в шар вітрин, тому вибірка за місяць не гальмує приймання даних. Аналітик працює через SQL-сумісний інтерфейс, без проміжних вивантажень у файли; права розмежовуються за інструментами та діапазонами дат.
Чи доведеться перебудовувати поточний контур?
Підключаємося до наявних брокерів повідомлень, планувальника й моніторингу, історію переносимо з поточних файлів і таблиць із перевіркою збіжності.
Якщо частина контуру залишається на попередньому стеку, обмін будується так, щоб працюючі споживачі продовжили читати дані без переписування.
Обговоримо задачу: що потрібно з вашого боку і з чого почнемо
Показуємо на прикладі: у замовника архів тік-даних за Ethereum і спотовими парами лежав єдиним масивом, тому запит за вузький інтервал сканував весь обсяг. Звіт за місяць збирався годинами, а після збою дані доводилося переливати заново.
Рознесли потік за розділами «дата + інструмент», увімкнули колонкове стиснення та попередньо обчислені агрегати — вибірка інтервалу вкладається в секунди, обсяг архіву скоротився в рази, відновлення вузла займає хвилини.
Щоб повернутися з оцінкою та планом робіт, нам достатньо мінімального набору ввідних:
- перелік мереж та інструментів, за якими потрібні тік-дані;
- потрібна глибина історії та деталізація: окремі угоди або агрегати за інтервалами;
- сценарії читання — аналітика, звіти, вивантаження, внутрішні сервіси через API;
- допустимі прогалини й правило звірки з джерелом;
- де розміщуємо: ваші сервери або хмара, які доступи потрібні та який регламент щодо даних;
- обмеження за строками та вимоги до зберігання з боку регуляторних вимог.
У відповідь надсилаємо оцінку та план робіт: схему розділів і ключів, порядок первинного завантаження й дописування потоку, порядок переходу з поточного сховища без зупинки збору та критерії приймання. Опишіть задачу — повернемося з оцінкою та планом.
