OHLCV-дані з бірж: де розриваються історичні ряди
Історичні свічки майже ніколи не бувають неперервними. Біржа йде на технічні роботи, зупиняє торги за інструментом, змінює правила розрахунку — і в ряду залишається діра.
На графіку її не видно: наступна свічка просто прилягає до попередньої, а питання «чи була торгівля в ці хвилини» ніхто не ставить.
Друге обмеження — розсинхрон між майданчиками. Різний час закриття доби, різні торгові календарі, різний час старту інструмента дають ряди, які не сходяться на межах. Якщо склеїти їх як є, стратегія «побачить» рух, якого на ринку не було.
Ціна такої помилки проявляється на перевірці стратегій. Пропуски в котируваннях перетворюються на хибні сигнали, а зсув на одну свічку — на угоду за ціною, якої не існувало.
Результат на історії перестає відтворюватися на реальних торгах, і причину шукають тижнями, бо якість історичних даних ніхто не вимірював.
Ручний збір котирувань з бірж не масштабується. Майданчики змінюють ліміти запитів, додають пари й таймфрейми, вимагають ключів; десятки інструментів на кількох інтервалах доводиться звіряти очима. Будь-яка правка губиться під час наступного вивантаження — ряд більше не відтворюваний.
Розбираємо, як це закривається: як збираються OHLCV-дані, чим перевіряється повнота ряду і що має залишатися в лозі, щоб результат перевірки можна було повторити через місяць.
Вивірений ряд свічок: швидкість перевірки і менше хибних сигналів
Бектест ламається не на логіці стратегії, а на вхідних даних. Свічка з втраченим обсягом, дублікат бару під час злиття двох майданчиків або випалий інтервал на обслуговуванні біржі — і перевірка торгових стратегій показує вхід там, де в реальності угоди не було. Ціна такої помилки — переписаний торговий модуль і недовіра до всіх результатів перевірки.
Вивантаження свічок робимо напряму через торгові інтерфейси майданчиків, включно з Binance: посторінково за часом, з повторами при мережевих збоях. Підготовка даних зводиться до єдиної схеми — мітка часу в UTC, open/high/low/close, обсяг, тікер, таймфрейм.
Бари з різних джерел звіряємо за міткою, дублікати відкидаємо, а інтервали з нульовою ліквідністю позначаємо прапорцем, щоб вони не потрапили в розрахунок індикаторів як справжні угоди.
Окремий етап — неперервність ряду. За торговим календарем знаходимо пропущені інтервали й відновлюємо їх: спочатку з сусіднього майданчика за тим самим інструментом, потім агрегацією з молодшого таймфрейму. Де відновлення некоректне, бар позначається як відсутній, і вікно тесту його не використовує.
На виході підготовка історії займає години замість тижнів ручного збору, частка відновлених пропусків сягає 95–98%, а хибні сигнали на розривах перестають вважатися входами — на довгих періодах це помітно змінює профіль просідання. Ряд при цьому відтворюваний: той самий запит до сховища дає той самий результат і через місяць.
Способи збору OHLCV-даних: повне вивантаження та довантаження
Джерело даних визначає, скільки часу піде на перше наповнення і як часто потім доведеться повертатися до обривів зв’язку.
Біржові архіви віддають історію пакетами за минулі періоди — це найшвидший спосіб отримати багаторічний ряд, але файли публікуються із затримкою і потребують розбору формату.
Публічний інтерфейс біржі віддає свічки за запитом, обмежений частотою звернень і глибиною доступної історії.
Інкрементальне довантаження вирішує інше завдання: воно забирає лише свічки, що закрилися після останньої збереженої, і тому обходиться кількома запитами на інструмент. На практиці схему збирають із двох частин — архів закриває минуле, розклад збору тримає актуальний край ряду.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повне вивантаження з біржових архівів | Перше наповнення, потрібен глибокий ряд за десятками інструментів | Затримка публікації, різні формати файлів, обсяг зростає швидко |
| Посторінковий збір через публічний інтерфейс | Точкові інструменти й коротка історія | Ліміти запитів, обриви на довгих відрізках, повільне перше наповнення |
| Інкрементальне довантаження за розкладом | Постійне поповнення після первинного завантаження | Збій на останній свічці «залипає», потрібні перевірка і перезапис краю |
| Гібрид: архів плюс довантаження | Робоча схема для бектестингу й моніторингу | Потрібні дедуплікація за часом відкриття свічки та контроль повноти |
Точки контролю однакові для будь-якого варіанта: дедуплікація за часом відкриття свічки, перевірка пропусків у ряду і колонкове зберігання, де довантаження дописує партиції, а не перезаписує весь набір.
Така схема скорочує перше наповнення з доби до десятків хвилин і прибирає повторні повні проходи по історії.
Порядок збору історії: від аудиту джерел до передачі
Збір історії — це не разове вивантаження, а відтворюваний конвеєр: його можна перезапустити через місяць і отримати той самий результат.
Тому порядок робіт зафіксований — спочатку розбираємося, які джерела доступні й наскільки їм можна довіряти, потім описуємо схему і лише після цього пишемо збирач.
Помилка на перших двох кроках коштує найдорожче: розходження у свічках спливає вже на бектесті, коли результати стратегії не сходяться з поведінкою ринку.
- Аудит джерел даних. Дивимося, які біржі та пари потрібні, яка реальна глибина історії, як джерело віддає пропуски й паузи торгів, які ліміти на частоту запитів і де історичні вивантаження обриваються.
- Схема збору. Фіксуємо єдиний формат OHLCV, набір таймфреймів, приведення часу до одного поясу, правила агрегації молодших інтервалів у старші та округлення обсягів.
- Налаштування збору. Налаштовуємо посторінкові вивантаження за часовими вікнами, повторні спроби при обривах, довантаження відсутніх ділянок та ідемпотентний запис, щоб повторний запуск не плодив дублі.
- Звірка свічок. Порівнюємо перехресні ділянки з еталонним джерелом, ловимо розходження цін відкриття й закриття, аномальні обсяги та різницю в межах інтервалів.
- Контроль розривів. Перевіряємо неперервність ряду, окремо обробляємо технічні паузи, делістинг і зміни тікерів, позначаємо ділянки, де дані відновлені з альтернативного джерела.
- Валідація та упаковка. Проганяємо перевірки на монотонність часу, нульові та дубльовані свічки, розкладаємо масив за парами й місяцями для швидкої вибірки.
- Передача даних. Віддаємо масив у погодженому форматі з описом полів, журналом джерел за кожною ділянкою і скриптом повторного збору — команда може оновлювати історію самостійно.
Що залишається у вас: схеми, регламенти, готові вивантаження
Після здачі проєкту у вашої команди залишаються не лише самі дані, а й усе, що потрібно для їх самостійного відтворення: описані джерела, правила обробки та робочі скрипти завантаження.
Ми не залишаємо рішення в стані «працює, але незрозуміло як» — інженер супроводу зможе підняти контур заново й отримати ті самі ряди.
- Схема джерел. Перелік майданчиків та інструментів з інтервалами, пріоритет при розходженні цін і правило вибору еталонного ряду.
- Документація з даних. Словник полів OHLCV, таймзони, одиниці обсягу, правила обробки пропусків, дублів і розривів торгів.
- Регламент перезбирання. Що і в якому порядку запускати при додаванні інструмента, зміні формату вивантаження чи знайденій дірі в історії.
- Вивантаження у сховище. Ряди в партиційованих таблицях і плоских файлах, придатні до завантаження в аналітичний контур без додаткового чищення.
- Звіти контролю якості. Звірки між джерелами, список аномальних свічок і покриття за датами — видно, де даних немає і чому.
- Передача рішення. Доступи, розгортання на вашій стороні, розбір інцидентів і передача знань команді супроводу.
- Журнал версій обробки. Що змінювалося в правилах нормалізації і як це впливає на зіставність результатів минулих тестів.
Кейс: відновлення пропусків в історії за 40 парами
Клієнт — команда алгоритмічної торгівлі: їй потрібна була історія за 40 парами з хвилинними свічками за кілька років, інакше тестування стратегій на історії давало хибні результати.
Збирали OHLCV із трьох джерел, включно з Binance, і одразу побачили проблему: близько 3,4% свічок були відсутні. Розриви припадали на технічні роботи майданчиків і періоди, коли угод за парою не було взагалі.
Кожен пропуск класифікували, а не закривали здогадкою: реальна відсутність угод, збій вивантаження або розходження міток часу між майданчиками.
Для справжніх дір перезбирали свічки з архівів угод, для уявних — писали нульовий обсяг із явною позначкою, щоб модель не приймала тишу за рух. Контроль неперервності працював автоматично: розрив довший за один інтервал ішов у карантин до підтвердження.
Цифри до і після. Частка пропусків упала з 3,4% до 0,02% за всіма торговими парами. Підготовка ряду займала близько шести годин ручної звірки — тепер це прогін на кілька хвилин, і людина переглядає лише спірні ділянки. Перевірок результату було по три кола на кожну пару — залишився один зведений звіт розходжень.
Кожен ряд версіонується: у пари є опис із контрольними сумами й датою зрізу, тому повторний збір відтворює той самий файл.
Це прибрало клас відмов, коли тест розходився з живою торгівлею через непомічену діру, і дало можливість порівнювати стратегії на одному й тому самому наборі даних.
Чим відрізняється інкрементальне довантаження від повного перезавантаження?
Інкрементальне довантаження OHLCV-даних запитує лише ті свічки, яких ще немає у сховищі — від мітки часу останньої записаної свічки. Нічний добір за десятками інструментів займає хвилини і не впирається в обмеження на частоту запитів до біржі.
Плата за таку економію — накопичення розходжень. Якщо свічка не довантажилася через обрив з’єднання або біржа пізніше уточнила обсяг, у середині ряду залишиться пропуск або застаріле значення — і спливе він лише на звірці даних, уже після прогону стратегії.
Повне перезавантаження перезапитує весь діапазон і перезаписує партиції цілком. Воно знімає питання консистентності: уточнення обсягів, відновлені пропуски й зміна складу інструментів підтягуються самі, а результат не залежить від того, як відпрацювали попередні запуски. Ціна — час і кількість запитів зростають лінійно за глибиною історії.
Для вже розгорнутого сховища частіше беруть змішаний режим: щоденне інкрементальне довантаження за розкладом плюс періодичне повне перезавантаження ковзного вікна — останніх тижнів.
Обриви з’єднання не страшні: прогрес фіксується за часом останньої записаної свічки, а вставка ідемпотентна за ключем «інструмент + інтервал + час відкриття», тому повторний запуск продовжує з того самого місця без дублів.
Підсумок: інкрементальне довантаження — для оперативного оновлення історії, повне перезавантаження — страховка консистентності на обмеженому вікні, змішаний режим — коли сховище живе довго й оновлюється щодня.
Технічні сумніви: глибина історії, пропуски, формати
Перед стартом збору майже завжди спливають одні й ті самі сумніви: чи вистачить глибини історії, що робити з дірами в ряду і як потім звірити наші свічки з тим, що бачить стратегія.
Ми збираємо OHLCV із кількох джерел — від Binance до регіональних майданчиків — і за кожним пунктом нижче відповідаємо до початку робіт, а не після першого вивантаження.
Наскільки глибока історія і де вона обривається?
Залежить від майданчика й таймфрейму. Годинні та денні свічки зазвичай сягають років назад, а хвилинні в більшості бірж віддаються лише за останні два-три роки — глибше публічні інтерфейси просто не відкривають дані.
Там, де історія обривається, ми добираємо архів з альтернативних джерел і явно позначаємо межу, щоб тести на цій ділянці не вважалися достовірними.
Що робити з пропусками та біржовими вихідними?
Пропуск у ряду — не завжди помилка: на вихідних і в дні зупинки торгів свічка не існує фізично.
Ми розрізняємо три випадки — відсутність торгів, збій збору і реальна прогалина в джерелі — і закриваємо їх по-різному: нульовим обсягом, повторним запитом або окремим прапорцем у даних.
Інакше стратегія приймає зупинку торгів за нульову волатильність і показує на історії результат, якого не було.
У якому часовому поясі та форматі зберігаєте свічки?
Усе приводимо до єдиного поясу із збереженням початкової мітки часу джерела, інакше свічки різних майданчиків не стикуються за відкриттям і закриттям сесії. Зберігання — колонкове, з розбивкою за датою й інструментом, плюс вивантаження в табличному вигляді для ручної перевірки.
Звірка йде повторним запитом і зіставленням обсягів: розходження між джерелами вище порога позначаємо як підозріле й розбираємо до передачі даних.
Обговоримо задачу: зберемо історію під вашу стратегію
Щоб оцінка спиралася на факти, а не на здогадки, для старту достатньо кількох вступних даних.
Надішліть перелік майданчиків та інструментів, таймфрейм і глибину історії, а також формат, у якому дані мають лягти у ваше сховище, — цього достатньо, щоб порахувати обсяг запитів і обмеження за частотою звернень до кожної біржі.
- Перелік бірж та інструментів: спотові пари, ф’ючерси, окремі тікери.
- Таймфрейм і глибина історії — хвилинки за кілька років або години за місяці: від цього напряму залежить кількість запитів.
- Формат вивантаження: набір колонок, часовий пояс, округлення, CSV або Parquet.
- Як стратегія працює з OHLCV-даними: індикатори, ковзні вікна, правила обробки пропусків і розривів ліквідності.
- Місце зберігання й періодичність оновлення: файли, об’єктне сховище або база.
- Критерії приймання: скільки контрольних точок звірити з першоджерелом і яке розходження вважати значущим.
План робіт будуємо від перевірюваного результату: спочатку пробна вибірка за одним інструментом на короткий інтервал, звірка з еталоном, потім повне завантаження за всіма майданчиками й налаштування регулярного оновлення.
Так розходження в часових поясах і пропущені свічки спливають на початку, а не після вивантаження всього обсягу. Оцінка термінів приходить разом із планом і розбивкою за етапами, щоб порядок запуску був зрозумілий до початку робіт.
Опишіть задачу у вільній формі — повернемося з оцінкою та планом під вашу стратегію.
