Чому парсинг CoinGecko падає на пікових навантаженнях ринку
Поки ринок спокійний, парсинг CoinGecko відбувається рівно: інструменти опитуються за розкладом, відповіді надходять вчасно. На сплеску активності частота опитування зростає, і публічний інтерфейс відповідає відмовою через ліміт частоти запитів.
Далі спрацьовує каскад: обриви запитів, сліпі повтори, втрата частини точок ще до запису. Збирач досилає ті самі звернення, добиваючи вичерпану квоту, а відповіді, що надійшли із запізненням, записуються вдруге — з'являються дублі з різними мітками часу.
Без ключа ідемпотентності за зв'язкою «джерело — торговий інструмент — часове вікно» та обмеження паралелізму черга повторів сама стає джерелом навантаження.
Втрата історії котирувань при цьому незворотна: зріз за вже закрите вікно не віддається, пропущений інтервал не дозапитується, і у звітах залишаються розриви.
Розрахунок дохідності та волатильності йде за неповною вибіркою — метрика виглядає правдоподібно, але довіряти їй не можна.
Окремий біль — розсинхрон джерел: CoinGecko і CoinMarketCap оновлюються не одночасно, і при зборі одним проходом один інструмент потрапляє в агрегат з різних вікон, даючи хибний розмах.
Лікується це не числом повторів, а архітектурою збору: бюджетом квоти, ідемпотентним записом і єдиним часовим контуром. Розбираємо, як це закривається.
Що дає вибудуваний збір ринкових даних
Ручне вивантаження ламається передбачувано: файл надходить із запізненням, часові мітки двох джерел розходяться, а відсутній інтервал закрити нічим — агрегатор віддає поточний зріз, а не те, що було в момент збою. Історія цін перестає бути неперервною саме там, де на неї спираються аналітика та торгові модулі.
Вибудуваний збір закриває цей клас відмов повністю: CoinGecko і друге джерело опитуються за розкладом, відповіді лягають у сховище до обробки, а не після. Що це дає на практиці:
- Цілісність історії. Кожен інтервал закритий точкою даних; частка пропусків видна у звіті й вимірюється в десятих частках відсотка, а не з'ясовується через місяць.
- Єдиний контур даних. Котирування, обсяги та капіталізація з обох джерел зведені до спільних міток часу — звірка йде всередині одного набору, без зшивання таблиць вручну.
- Передбачуване навантаження на джерело. Частота опитування та глибина кешу розраховані так, щоб вкладатися в ліміти й не йти в блокування при пікових рухах ринку.
- Відмова від ручних вивантажень. Нуль операцій «завантажити й перейменувати»: збір, нормалізація та запис ідуть без участі людини за розкладом.
- Автоматична звірка джерел. Розходження ціни або обсягу вище порогу йде в журнал з контекстом запиту — аномалія видна до того, як потрапить у розрахунки.
Кожен пункт перевіряється за журналами та метриками сховища, тому результат не залежить від того, хто саме сьогодні чергує. З так влаштованим контуром дані можна брати в аналітику та звітність без попередньої ручної підготовки.
Формати збору: парсинг CoinGecko, офіційний API, вебхуки
Вибір джерела визначає, наскільки стійко дані доїдуть до вітрин.
Тут немає універсального варіанта: офіційний API дає стабільну схему відповіді та історію, розбір публічних сторінок — показники, яких немає в тарифному доступі, потокові повідомлення — реакцію без опитування за розкладом.
Помилка на цьому кроці спливає пізніше: ліміти на запити ламають нічне завантаження, а зміна розмітки зупиняє збір на кілька днів.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Офіційний API CoinGecko і CoinMarketCap | Потрібні історія, метадані монет і передбачувана схема відповіді | Ключ, ліміт запитів за хвилину, глибина історії залежить від тарифу |
| Розбір публічних сторінок | Показники поза тарифним доступом, рідкісні монети, свіжі лістинги | Залежить від розмітки та захисту від ботів, потрібні ротація адрес і перевірка на аномалії |
| Вебхуки та потокові повідомлення | Реакція на зміну ціни без опитування за розкладом | Потрібен свій приймач, обробка повторів і розривів з'єднання |
| Проміжне сховище | Поверх будь-якого з джерел вище | Не джерело даних: потрібні політика оновлення, термін зберігання та очищення |
Проміжне сховище замикає схему: пишемо відповіді у свою базу, а вітрини читають із неї, а не із зовнішнього сервісу. Тоді відповідь із помилкою або обрив зв'язку не залишають дір у графіках, повтор запиту йде в чергу, а дублі відсікаються за парою «джерело + мітка часу».
Практика показує: розходження між вітринами виникають саме там, де частина запитів іде напряму в API, а частина — зі сторінок. Єдиний шар збору з журналом звернень знімає цей клас розходжень і робить збій джерела відновлюваним.
Етапи впровадження: від аудиту джерел до регламентів
Парсинг CoinGecko і CoinMarketCap починається з аудиту джерел: інвентаризуємо точки доступу, ліміти на частоту запитів, охоплення активів і бірж, глибину історії. Без цього не зрозуміти реальний обсяг збору — схема, зібрана на око, ламається на першому сплеску навантаження.
- Інвентаризація. Фіксуємо перелік точок доступу, обмеження за частотою, доступні рівні та глибину історії за кожним активом.
- Схема даних. Зводимо поля до єдиного контракту: актив, торговельна пара, ціна, обсяг, капіталізація, мітка часу, джерело. Типи та валютні пари приводимо так, щоб записи двох джерел склеювалися без ручних правок.
- Налаштування збору. Розклад обходу, розділення масових і точкових запитів, повтори при відмовах, черга замість шквалу одночасних викликів.
- Правила кешування. Час життя запису за типом даних: котирування — хвилини, історичні зрізи — доба. Ключ кешу за парою та джерелом, примусове скидання при розходженні.
- Перевірка повноти. Звіряємо пропуски за часом, дублі та розходження між джерелами, рахуємо контрольну суму на кожен зріз.
- Регламенти та передача. Віддаємо схему, права доступу, сценарії реакції на збій і порядок правок конфігурації.
На кожному етапі заздалегідь фіксуємо, що вважаємо правильним результатом: пропуск у ряду має бути видно, а не замаскований останнім успішним значенням.
Що передаємо: конфігурації, схеми даних і документація
Завдання розділу — не віддати «працюючий збирач», а передати комплект, за яким дані збираються й живуть далі без нас. Усе, що визначає поведінку системи, фіксуємо письмово: налаштування, схему руху даних, права доступу, порядок дій при збоях. Нижче — що саме залишається в команди замовника.
- Конфігурації збору — список монет і майданчиків, розклад обходів, ліміти частоти звернень до CoinGecko і CoinMarketCap, правила повторів і поведінка при недоступності джерела.
- Схема потоків даних — шлях від запиту до запису в сховище: де поля приводяться до єдиного вигляду, де спрацьовує кеш, як розв'язуються розходження між джерелами.
- Опис полів — довідник за кожним атрибутом: тип, одиниця виміру, джерело, періодичність оновлення, правила обробки пропусків і викидів.
- Політики доступу до ключів — де зберігаються облікові дані, хто читає, хто змінює, як проходить ротація; ключів немає в коді, логах і листуванні.
- Схема кешування — терміни життя записів за кожним типом даних, умови їх скидання, поведінка системи при частковій недоступності джерел.
- Регламент експлуатації — запуск і зупинка збирача, перевірка стану, порядок дій при збої, правила оновлення налаштувань.
- Контроль якості даних — перевірки на дублі, пропуски та аномалії цін, звіт про повноту зібраного масиву за період.
- Журнал змін і матриця відповідальності — хто і що змінює, як фіксуються правки, до кого йти з питанням.
Комплект збирається по ходу робіт, а не в кінці: на прийманні звіряємо документи з фактичною поведінкою системи.
Кейс: як агрегатор котирувань перестав втрачати історію цін
Де втрачалася історія
Парсинг CoinGecko, CoinMarketCap і ще двох біржових стрічок ішов самописними скриптами за розкладом.
Вивантаження працювали «як вийде»: частина запитів відвалювалася на лімітах, частина повертала порожню відповідь, а результат писався в таблицю без ключа — повторний запуск плодив дублі замість дозапису пропущеного.
За квартал накопичилося близько 6% інтервалів без котирувань і 4% задвоєних свічок, розходження між джерелами не рахував ніхто.
Що змінили
Збір перевели на запис із ключем «джерело + інструмент + мітка часу»: повторний прогін за той самий період оновлює рядок, а не створює копію.
Пропущені інтервали закриває окремий прохід довантаження — він спочатку визначає, чого не вистачає, і тільки потім звертається до CoinGecko.
Відповіді кешуються з терміном життя, що залежить від таймфрейму: короткі свічки оновлюються часто, денні живуть у кеші довше, тому ліміти джерел перестали бути вузьким місцем.
Метрики до і після
Частка пропущених інтервалів упала з 6% до 0,1%, дублі вичищені повністю — неперервна історія цін перевіряється автоматично, від першої свічки інструмента до останньої.
Звірка джерел дає регулярний звіт про якість даних: скільки розходжень за ціною відкриття та обсягом, де лаг оновлення вищий за норму.
Час підготовки добового зрізу скоротився з 40 хвилин до 4, а відновлення після збою одного джерела займає один цикл довантаження замість ручного перезапуску та ручної звірки.
Чим CoinMarketCap відрізняється від біржового агрегатора
CoinMarketCap — агрегатор ринку, а не біржа: котирування не народжується у власному стакані, а зводиться за даними десятків майданчиків з вагами та фільтрами відбору пар. Біржовий агрегатор рахує ціну за своїм ордербуком — для конкретного майданчика він першоджерело. Розходження між ними тому не збій, а наслідок різних методик зведення.
Різниця осідає в двох параметрах — наборі полів і частоті оновлення. Агрегатор віддає снапшот раз на кілька хвилин: ціна, обсяг за добу, капіталізація, список бірж-джерел. Біржовий канал оновлюється на порядок частіше, але показує тільки свій майданчик.
| Критерій | Агрегатор ринку | Біржовий агрегатор |
|---|---|---|
| Джерело ціни | Зведення з десятків бірж за вагами | Власний стакан |
| Частота | Снапшот раз на 1–5 хвилин | Потік, частки секунди |
| Поля | Ціна, обсяг за добу, капіталізація, біржі-джерела | Ціна, глибина, стрічка угод |
| Обмеження | Запізнення, фільтр пар, склейка майданчиків | Немає своєї пари — немає даних |
Звірка котирувань починається не з ціни, а з контексту снапшота: час зняття, пара, майданчик з найбільшою вагою. Збігся обсяг, а ціна розійшлася — справа у фільтрі пар або в запізненні кешу. Стійкий розрив говорить про іншу методику зведення, разовий — про різницю моменту оновлення.
На боці збору даних це означає: не змішувати дві шкали в одному полі та зберігати час із джерелом кожного запису. Тоді розходження залишається пояснюваним, і на графіках воно не перетворюється на хибну аномалію.
Технічні сумніви: ліміти, блокування, розходження
Парсинг CoinGecko та інших агрегаторів — це публічні точки доступу без авторизації, але з обмеженням темпу запитів: при його перевищенні надходять затримки або відмови замість даних.
Обмежувач ставимо на боці збирача — черга звернень, пауза між ними, повтор із наростаючим інтервалом: збір іде повільніше, зате блокування джерел не рвуть історію.
Розходження цін між джерелами — не помилка, а різні методики: один рахує середньозважене за майданчиками за вікно, другий бере останню угоду, і час фіксації в них не збігається.
Зберігаємо обидва значення з мітками джерела та моменту знімка, а розходження понад заданий поріг заводимо в журнал для розбору.
Джерело почало віддавати відмови замість даних — що далі?
Збирач не падає: спрацьовує повтор із паузою, при повторній відмові підключається резервне джерело, а пропущений інтервал позначається й довантажується пізніше. В історії залишається неперервний ряд.
Чому ціни в двох джерел відрізняються на частки відсотка?
Різні методики розрахунку та різний час знімка. Для рішень важлива не «істинна» ціна, а узгодженість: рахуємо відхилення й фіксуємо його динаміку за кожним інструментом.
Що буде, якщо джерело змінить формат відповіді?
Розбір відповіді винесено в окремий шар: поля читаються за описом, а не за жорсткими позиціями. При зміні структури правиться опис — години роботи замість переписування збирача.
Чи можна перерахувати історію за минулий період?
Так. Сирі відповіді зберігаємо окремо від агрегатів, тому перерахунок іде за вихідними даними без повторних звернень до джерела — у тому числі після уточнення методики.
Обговоримо задачу: з чого почнемо збір ваших даних
Щоб повернутися з оцінкою робіт, а не з вилкою «як вийде», потрібен мінімум ввідних.
Він же стає основою плану збору даних: від нього залежить, чи звертаємося ми до програмного інтерфейсу джерела чи розбираємо сторінки, як часто опитуємо котирування і скільки історії тримаємо в сховищі. Опишіть за пунктами:
- Джерела — CoinGecko, CoinMarketCap або обидва одразу; чи потрібен резервний канал на випадок помилок і обмежень за кількістю звернень.
- Перелік активів і пар — тикери, ідентифікатори, торговельні пари та загальна кількість сутностей, які потрібно покрити.
- Глибина історії — на скільки назад потрібні котирування та метрики, чи є вже вивантажений архів у файлах або базі.
- Частота оновлення — раз на хвилину, годину чи добу; чи потрібні внутрішньоденні свічки і яка затримка допустима при збої.
- Доступи — тариф джерела, ключі, ліміти звернень і правила їх зберігання в конфігурації.
- Приймач даних — реляційна база, колонкове сховище або файли; потрібна точність і одиниці цін.
Після цього ми готуємо схему обміну даними, налаштування кешу та політику оновлення, розмічаємо етапи й надсилаємо оцінку робіт. Обговоримо задачу — чим конкретніший список, тим менше переробок на впровадженні.
