Налаштування промислового парсингу крипто-даних за розкладом (cron)

Налаштування парсингу крипто-даних: де рветься збір

Збір крипто-даних за розкладом виглядає найпростішою частиною системи: завдання прокидається за таймером, забирає стакан і стрічку угод, складає у сховище.

Ламається це не на одному запуску, а на тижнях безперервної роботи — відставання накопичується, і за логами окремого проходу його вже не видно.

Перший розрив — пропуски в даних. Розклад запусків стартує завдання кожні кілька секунд, і якщо попередній прохід не встиг закритися, планувальник або накладає копії, або зсуває вікно.

Діра в ряду виявляється не відразу: частина свічок просто відсутня, а розрахунок дохідності та волатильності на дірявому ряду дає зміщений результат, який виглядає правдоподібно і йде далі у звіти.

Другий — розбіжності між джерелами. Парсинг біржових даних впирається в те, що майданчики віддають різне: одна — ціну останньої угоди, інша — середньозважену за інтервал, третя ріже потік на пачки з різною періодичністю.

Часові мітки джерел теж не збігаються, і зшивання рядів без явного правила приведення перетворює аналітику на набір випадкових чисел.

Третій і найдорожчий — мовчазна відмова завдання. Джерело змінює формат відповіді або починає віддавати порожній список, завдання завершується з ознакою успіху, а оповіщення мовчать. Пропущене вікно викривається через добу, коли перезапитом його вже не відновити.

Нижче розбираємо, як це закривається: ідемпотентні проходи, контроль повноти вікон і звірка з джерелом на кожному циклі.

Що дає регулярний збір біржових даних

Регулярний збір перетворює набір розрізнених знімків у безперервний часовий ряд: один інструмент, один інтервал, одна схема запису.

Повнота ринкових даних вимірюється не числом успішних запитів, а тим, що пропуск видно — якщо джерело не відповіло у своє вікно, в ряду залишається явна мітка пробілу, а не зсув сусідніх точок.

Без цього пропущена година тихо склеюється з сусідніми, і аналітика рахує рух ціни, якого на ринку не було.

Затримка оновлення задається заздалегідь і утримується: потокові підписки дають рівний лаг за стаканом і угодами, планове опитування — однаковий крок за свічками закриття.

Плаваючий лаг небезпечніший за великий — стратегія, перевірена на даних, зібраних «як вийшло», показує результат, який не повторюється на реальному виконанні.

Безперервність збору — окремий контур надійності. Планувальник перезапускає завдання, що впали, повторні спроби йдуть із зростаючою паузою, а дублі гасяться за ключем «джерело + інструмент + мітка часу»: обрив зв'язку або перезапуск не псують ряд і не подвоюють обсяги.

Історія котирувань — актив, невідновлюваний заднім числом: пропущені доби не докачуються з жодного джерела.

Тому цілісність ряду перевіряємо звіркою з незалежним агрегатором, наприклад CoinGecko, і тримаємо звіт про покриття за кожним інструментом — частку фактичних точок від очікуваних за період.

Режими отримання даних: порівняння підходів

Режим збору визначає, наскільки дані встигають за ринком і як часто доводиться розбирати розбіжності.

Розклад запусків, постійний канал, готові вивантаження постачальника та ручні запити вирішують одну задачу різними засобами — розрізняються затримка, повнота та стійкість до обмежень джерел.

Вибір диктують самі джерела: публічні вузли віддають історію, але ріжуть частоту звернень і вимикають доступ за перебір; платні постачальники даних дають рівну стрічку, зате фіксують набір полів і квоти на запити. Нижче — чотири режими і те, де кожен ламається.

На практиці режими комбінують: розклад накопичує історію, постійний канал бере гарячі дані, вивантаження постачальника служать звіркою. Такий набір закриває і обриви зв'язку, і ліміти джерел.

Етапи налаштування регулярного збору даних

Регулярний збір крипто-даних ламається не на окремому запиті, а на розкладі: джерело змінює формат відповіді, частина точок приходить із запізненням, у сховищі з'являються дублі, а пропуски помічають уже у звіті.

Порядок робіт вибудуваний так, щоб схема збору фіксувалася до запуску, а не відновлювалася за фактом збою.

1. Аудит джерел. Перевіряємо біржі, агрегатори та вузли мережі: які поля віддаються, з якою затримкою, чи є обмеження за частотою звернень і чи можна вивантажити історію за минулі періоди.
2. Схема збору. Фіксуємо єдиний формат запису, склад полів, часові мітки та режим опитування — за розкладом або за появою нових блоків. Схема стає контрактом: розбіжності ловляться на вході, а не в готовому звіті.
3. Правила повторів запитів. Описуємо число спроб, паузу між ними та ознаку, за якою відрізняємо тимчасовий збій від зміненого ответа; після вичерпання спроб джерело позначається проблемним і потрапляє в оповіщення.
4. Тестовий прогін. Запускаємо збір на історичних даних: звіряємо обсяг записів, повноту за кожним джерелом і збіг із уже накопиченими значеннями за той самий період.
5. Приймання робіт. Порівнюємо контрольні метрики до і після, перевіряємо поведінку при недоступному джерелі та коректне продовження збору після примусової зупинки.
6. Передача регламентів. Віддаємо розклад, порядок підключення нового джерела та розбір типових помилок — супровід перестає залежати від конкретного виконавця.

Що залишається на виході: схеми, конфігурації, регламенти

Крім працюючого збирача ми передаємо комплект документації та конфігурацій, за яким ваша команда зможе супроводжувати завдання та розширювати їх без нашої участі. Нижче — що саме залишається в репозиторії на момент здачі.

• Схема даних — опис сутностей: свічки, угоди, стакан, ставки фінансування; типи полів, точність округлення, таймзона та ключ дедуплікації (інструмент + мітка часу + тип свічки).
• Конфігурація збирача — перелік завдань, інтервал запуску, глибина запиту, ліміти звернень до джерела, пауза при відмовах, список бірж і торгових пар в одному файлі.
• Правила доступу — ключі тільки на читання, зберігання секретів поза кодом, порядок ротації, розділення ролей для робочого та тестового контуру, хто бачить сирі дані.
• Регламент перезапуску — покроковий порядок після падіння: перевірка стану, добір пропущеного вікна, повторний запуск без дублів, критерії зупинки.
• Журнал збору — статуси завдань, число записаних записів за вікно, помилки джерела, затримка від мітки часу до запису, оповіщення про пропуски.
• Схема розміщення — де виконуються завдання, як зберігаються сирі дані та архіви, які терміни зберігання задані за шарами.
• Інструкція з розширення — як додати новий інструмент або поле без правки ядра: що змінювати в конфігурації, як перевірити результат на тестовому контурі.

Комплект розрахований на інженера, який не брав участі в розробці: за документацією збір піднімається з нуля, а розбіжність у даних розбирається за журналом, без звернення до нас.

Кейс: повернули повноту збору даних за 14 джерелами

Замовник збирав ринкові дані за 14 джерелами: біржові інтерфейси, агрегатори на кшталт CoinGecko, публічні вузли мереж.

Запуски за розкладом виконувалися, але 12% вікон губилися: джерело відповідало помилкою ліміту, задача падала, і дані за цей інтервал не доїжджали до наступного циклу. Розбіжності між каналами сягали 7% — на них ламалися звірка позицій і звітність.

Що змінили: розвели збір на три шари — планувальник вікон, пул завантажувачів із повторами та карантином для «мовчазних» джерел, окремий добір історії за пропущені інтервали.

Ліміти та ключі розвели за кожним джерелом, а відповіді складали в незмінний журнал: видно, яке вікно закрито повністю, яке частково, а яке потрібно перезабрати.

Що стало: повнота даних зросла з 88% до 99,7%, розбіжності між каналами — з 7% до 0,4%. Час відновлення після відмови джерела скоротився з 40 хвилин ручного перезавантаження до 90 секунд автоматичного добору — наступний цикл стартує вже з повними даними.

Окремо налаштували оповіщення: якщо вікно не закрилося за відведений час, приходить сигнал із зазначенням джерела та інтервалу, а не «щось упало». Метрики знімали до і після на одному наборі джерел, тому ефект тримається на постійному потоці, а не на разовому вивантаженні.

Чим відрізняється парсинг за розкладом від потоку в реальному часі

Потік дає затримку в секунди: підписка на угоди та стакан приносить події відразу, як тільки вони з'явилися в мережі. Плата — постійне з'єднання, яке потрібно тримати й перевіряти: розрив на кілька хвилин залишає діру в історії, і її помічають тільки на звірці.

Розклад працює інакше. Планувальник раз на інтервал запускає завдання, воно забирає вікно даних за запитом, пише пачкою і завершується.

Затримка вимірюється хвилинами, зате точка відмови одна: якщо запуск не пройшов, наступний добере пропущений інтервал, а стан між запусками не зберігається.

Навантаження на підтримку відрізняється радикально. Потоковому збору потрібен черговий: алерти за перепідключеннями, зростання буфера, завислі підписки приходять у будь-який час доби.

Завдання за розкладом падають передбачувано, видно в журналі запусків, а відновлення зводиться до повторного прогону за потрібні дати.

Зворотний бік у тому, що на розкладі не побудувати реакцію на подію — ліквідації, різкі сплески волатильності. Потік же погано підходить для вивантаження історії за місяці: він дорогий за кількістю з'єднань і не дає переграти дані заднім числом.

Практичний вибір — гібрид. Розклад тримає історію та довідники, добирає пропуски, потік обслуговує метрики, де важлива секунда. Розділення за задачами знімає і навантаження на чергування, і ризик дір у даних.

Технічні сумніви: пропуски, ліміти, дублі записів

Кожен із цих відмов відтворюваний, і на кожен є інженерна відповідь — його ми фіксуємо до старту, а не після першої розбіжності. Нижче — розбір типових сумнівів, які знімаємо на етапі проектування збору: неповні вікна, обмеження майданчиків, дублі та зміна формату відповіді.

Як виключаються дублі записів?

У кожного запису є складений ключ: ідентифікатор операції, майданчик і момент часу. Запис вставляється з оновленням при збігу — повторний прогін того самого вікна не подвоює обсяг.

Перетин вікон за розкладом тому безпечний: збір можна перезапускати стільки разів, скільки потрібно для закриття розриву.

Що робити з обмеженнями джерел за частотою запитів?

Опитування розподіляється за часом, а не йде однією пачкою. При спрацюванні обмеження пауза зростає, черга зберігається і дограється після відновлення доступу.

Пріоритет віддаємо критичним рядам — другорядні джерела відстають за часом, але не роняють весь збір і не дають сміттєвих значень.

Джерело змінило формат відповіді — що тоді?

Прийом іде за явно описаною схемою відповіді, і кожен запис перевіряється на відповідність до запису в сховище.

При розбіжності дані йдуть у карантин і подається сигнал черговому — збір позначається зупиненим за цим джерелом, а не наповнює базу значеннями, які потім доведеться вичищати.

Обговоримо задачу: що уточнити перед початком робіт

Щоб повернутися з оцінкою та планом робіт, а не із загальними формулюваннями, нам потрібно зрозуміти предметну область: які активи та майданчики потрапляють у вибірку і що саме вважається в потоці — угоди, стани книги заявок, курси обміну, події в мережі.

Від цього залежить схема сховища, набір перевірок і те, як часто має сенс опитувати кожне джерело. Нижче перелік вхідних даних, який закриває більшість питань на старті.

• Предметна область: які пари, мережі та майданчики у фокусі, чи потрібен строковий ринок і позабіржові сегменти або тільки спот.
• Перелік джерел: біржові інтерфейси, агрегатори, вузли мережі, власні джерела цін — з позначкою, які віддають історію, а які тільки поточний стан.
• Вимоги до повноти: допустима частка пропусків, що робити з розбіжностями між майданчиками, чи потрібна переобробка заднім числом і за який горизонт.
• Глибина та частота: період первинного завантаження і розклад опитування — хвилинне, годинне або за подією.
• Формат видачі: сирі відповіді, нормалізована схема або агрегати за інтервалами; куди складаємо дані.
• Доступи та ліміти: ключі, обмеження за кількістю запитів, вимоги до мережевого доступу та розміщення вузлів.
• Регламент збоїв: кому і як повідомляємо про простій джерела, скільки чекаємо відновлення, за якими метриками вважаємо дані достовірними.

Надішлете ці вхідні дані — повернемося з оцінкою та планом робіт, де етапи розбиті за джерелами та чергами запуску.