Dune Analytics API: де ламається вивантаження даних у продукт
Dune Analytics API вбудовують, коли продукту потрібні on-chain метрики без власного індексатора: баланси гаманців, обсяги за пулами, активність контрактів. Зовнішній сервіс уже зібрав дані й розклав по вітринах, запит віддає готовий результат, продукт малює його в інтерфейсі.
Простота оманлива — далі починається експлуатація чужої вітрини з її власним розкладом перезбирання.
Перша типова відмова — застаріла вітрина. Матеріалізовані представлення оновлюються за розкладом, і між перезбираннями сервіс віддає зріз за минулий період. Запит при цьому формально успішний, а користувач бачить затримку даних в інтерфейсі й трактує її як збій продукту.
Друга — розбіжність балансів. Облікова сума у вітрині майже завжди відрізняється від фактичного стану мережі: частина переказів ще не потрапила в перезбирання, частина чекає на підтвердження.
На екрані гаманця або у звіті це читається як помилка, хоча джерело віддало рівно те, що в нього було на момент вивантаження.
Третя — ліміти на запити. Пул звернень спільний, сплеск навантаження віддає відмову, і оновлення падає мовчки: інтерфейс спокійно продовжує показувати вчорашні числа, бо помилку ніхто не підняв.
Розбираємо, як це закривається — контроль свіжості, звірка зі станом мережі, повтори й явна деградація замість порожнього або хибного екрана.
Що дає продукту вбудований доступ до блокчейн-даних
Вбудований доступ до Dune Analytics прибирає прошарок, через який звітність у продукті завжди відстає від мережі: запити йдуть до даних напряму, і клієнт бачить баланс, історію транзакцій або активність гаманця в тому самому зрізі, що й аналітик.
Свіжість вимірюється хвилинами підтвердження блоку, а не добами вивантаження, при цьому частоту оновлення налаштовують — гарячі метрики оновлюються частіше, історичні за розкладом, щоб не впиратися в ліміти зовнішнього сервісу.
Єдине джерело правди змінює не картинку, а процес. Метрики в інтерфейсі, вивантаження для фінансів і внутрішні панелі рахуються одним і тим самим запитом, тому розбіжності не накопичуються між системами.
Ручні звірки скорочуються до вибіркових перевірок: невідповідність ловить сам запит, а не людина через тиждень після відвантаження.
Окремо закривається клас відмов «дані не довантажилися». Черга запитів із повторами й зростаючою паузою, кеш останньої успішної відповіді та явна позначка застарілих значень не дають інтерфейсу показати порожній баланс замість реального.
Якщо зовнішнє джерело недоступне, продукт продовжує працювати на останньому знімку й довантажує пропущене сам — час відновлення після збою вимірюється хвилинами, а не годинами очікування відповіді підтримки.
Формати інтеграції: власний індексатор, готовий API, вивантаження
Формат доступу до on-chain даних обирають за трьома параметрами: глибина історії запитів, допустима затримка між подією в мережі та рядком у вашій базі, критичність цих даних для логіки продукту.
Помилка тут коштує дорожче за саму інтеграцію — шар даних переписують разом зі звітністю та нарахуваннями.
Нижче — чотири схеми, між якими реально обирають команди, і межі застосовності кожної. Найчастіше перемагає гібрид: історичні зрізи беруть із готового сервісу даних, свіжі події рахують локально.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власний індексатор | Власні правила розбору блоків, приватні метрики, дані поза публічними наборами | Історія лише з моменту запуску; відкати, переіндексацію та зміну контрактів обслуговуєте самі |
| Готовий сервіс даних (Dune Analytics API) | Потрібна історія з перших блоків і розбір популярних протоколів без власної інфраструктури | Залежність від чужого розкладу оновлення та лімітів; рідкісні контракти бувають не розмічені |
| Регулярні вивантаження | Звітність і аналітика, де дані потрібні раз на годину або рідше | Затримка до появи у вашій базі; при збої вивантаження вікно губиться, потрібен контроль пропусків |
| Гібридна схема | Потрібні і глибока історія, і свіжі події з малою затримкою | Дорожче в супроводі: джерела звіряють, стежать за розбіжністю метрик |
Глибина історії запитів
Це і є вирішальний критерій. Якщо продукт працює на подіях останніх днів, власний індексатор окупається швидше й не створює зовнішніх залежностей.
Якщо потрібні зрізи за роки та розбір чужих протоколів — готова вітрина закриває завдання відразу, а локальний шар залишають лише під свіжий потік.
Порядок робіт: від аудиту запитів до передачі схем
Роботу починаємо не з коду, а з інвентаризації: у кожного запиту має бути зрозумілий споживач і власник. Далі фіксуємо схему потоків і лише потім чіпаємо доступи й формати — так правка одного запиту не ламає панель або вітрину, які про неї не знають.
- Аудит запитів і споживачів. Збираємо перелік запитів у Dune, відзначаємо, хто читає результат: панель моніторингу, вітрина, сервіс або регулярне вивантаження. Помічаємо дублі, занедбані запити та ті, де немає відповідального.
- Схема потоків даних. Малюємо шлях від запиту до споживача, з точкою проміжного зберігання, місцем перетворення та допустимою затримкою оновлення. Фіксуємо контракт: імена й типи полів, правила округлення, поведінку при порожній відповіді.
- Ключі та права доступу. Окремий ключ на кожне середовище й сервіс, мінімально необхідні права, зберігання в секрет-сховищі та ротація. Описуємо поведінку при вичерпанні ліміту звернень до зовнішнього сервісу.
- Приведення даних до єдиного вигляду. Єдині ідентифікатори мереж і токенів, нормалізація адрес і десяткових значень, обробка реорганізацій ланцюга. Метрика перестає залежати від того, яким запитом її отримали.
- Перевірка збіжності. Звіряємо підсумки з незалежним джерелом на контрольній вибірці періодів, зіставляємо суми та кількість унікальних адрес між собою. Розбіжності розбираємо до причини, а не до прийнятної вилки.
- Передача та навчання. Документація по кожному запиту, схема потоків, регламент дій при розбіжності та відмові зовнішнього сервісу, розбір з командою.
На виході команда сама править запити, додає метрики й бачить, де саме розійшлися числа.
Схеми запитів, ключі доступу та регламенти оновлення
Робота з Dune Analytics API не закінчується тим, що запити почали повертати дані. Якщо описи живуть у голові розробника, перша зміна контракту ламає звітність — тому передаємо пакет, за яким команда замовника працює самостійно.
Нижче — обов’язковий склад такого пакета. Кожен пункт перевіряємо на прийманні: без нього робота не вважається закритою.
- Схеми запитів — призначення, поля та зв’язки між таблицями, фільтри за адресами й періодами, приклад очікуваного результату для звірки.
- Конфігурації підключення — ключі доступу, ліміти звернень, змінні середовища, роздільні налаштування для розробки та промислового контуру.
- Політики доступу за ролями — хто бачить сирі дані, хто лише агрегати, хто має право змінювати запити; строк життя ключів і журнал їх видачі.
- Регламент оновлення — що робити при зміні адрес контрактів, правці описів інтерфейсів або перезбиранні блоків, хто відповідає за звірку і з якою періодичністю.
- Інструкції для команди — як підняти середовище, виконати запит, перевірити свіжість даних і куди дивитися при розбіжності.
- Версії та відкат — журнал правок із датою й причиною, можливість повернути попередню версію запиту без зупинки звітності.
- Контрольні перевірки — точки, за якими звіряємо дані до й після будь-яких змін у контрактах.
Кейс: затримка даних скоротилася з годин до хвилин
Замовник — продукт з аналітикою по блокчейн-мережах: дашборди показували активність адрес, обсяги в пулах і рух коштів. Дані забиралися пакетними вивантаженнями за розкладом, тому вітрина оновлювалася раз на кілька годин, а розбіжності з джерелом розбирали вручну. На звірку йшло до половини робочого часу аналітика.
Що змінили
Перевели забір даних на запити до Dune Analytics API в момент відкриття дашборда, додали кеш із різним строком життя для «гарячих» та історичних метрик.
Запити пішли в чергу з обмеженням паралелізму й повторами при тимчасових помилках — джерело перестало отримувати пікові сплески. Схему відповіді зафіксували контрактом, тому зміни на боці сервісу більше не ламали вітрину.
Що вийшло
Свіжість даних зросла з годин до 1-3 хвилин, частка ручних звірок упала майже до нуля — розбіжності тепер ловить автоматична перевірка контрольних значень.
Закрили клас відмов «застарілий знімок»: раніше користувач бачив цифри на момент попереднього вивантаження й ухвалював рішення за ними. Час відгуку вітрини не зріс, бо важкі запити рахуються заздалегідь, а не в момент показу.
Впровадження зайняло кілька тижнів: перенесення логіки, перевірка на історичних даних, поступове вмикання розділів по одному. Навантаження на продукт залишилося незмінним — зросла частота звернень, але обсяг переданих даних скоротився за рахунок вибірки лише потрібних полів.
Чим готовий сервіс даних відрізняється від власної індексації
Готовий сервіс на кшталт Dune Analytics віддає дані запитом до API поверх уже зібраного індексу.
Поки завдання вкладається в типові контракти й стандартні події — токени, перекази, угоди на великих біржах — старт займає дні: не потрібно піднімати вузол, писати парсери й чекати, поки ланцюг проіндексується до потрібного блоку.
Розвилка починається там, де потрібна повнота даних. Зовнішній індекс містить лише те, що вирішили збирати його автори: власний контракт із нестандартною логікою подій, рідкісна мережа або логи до певного блоку у вибірку не потраплять. Доповнити її ззовні нічим — залишається індексувати самому.
Точність — другий обмежувач. Перерахунок заднім числом змінює минулі агрегати, а момент фінальності блоку нам не підконтрольний: сервіс вирішує сам, коли цифра усталилася.
Якщо продукт рахує баланси, ліміти або виплати, розбіжність в один блок перетворюється на інцидент із розбором.
Приватність закриває питання для частини сценаріїв. Адреси клієнтів, внутрішня розмітка гаманців і комерційні обсяги не повинні покидати периметр — такий індекс будується лише у себе, і зовнішній сервіс тут не підходить у принципі.
Трудовитрати на підтримку — ціна незалежності: архівний вузол, переіндексація при оновленні контрактів, контроль лагу, обробка реорганізацій, міграція схем.
Тому вибір роблять не за принципом «або-або»: типові метрики беруть у готового сервісу, а унікальну логіку й приватні дані збирають у власну вітрину.
Часті технічні сумніви перед стартом інтеграції
Найчастіше перед стартом запитують не про можливості, а про стикування з тим, що вже працює: чи збігатимуться цифри з власною аналітикою, хто відповідає за зміну запитів і як розмежувати доступ.
Ці сумніви вирішуються на етапі проєктування, і дешевше закрити їх до першого рядка коду продукту. Нижче — розбір умов застосовності, які визначають обсяг робіт.
Дані розійдуться з нашою поточною звітністю?
Ончейн-шар підключається як окреме джерело й не переписує наявне сховище. Зіставлення йде за стійкими ключами — адреса, хеш транзакції, номер блоку: на історичних зрізах звіряємо агрегати, і розбіжності усуваємо до виведення метрик в інтерфейс. Залишкову різницю в одиницях і часових поясах фіксуємо в описі полів, щоб цифри читалися однаково.
Що буде, якщо зовнішні запити зміняться або зламаються?
Запити зберігаються в репозиторії та версіонуються, а не живуть у чиємусь особистому кабінеті. Поверх ставимо перевірки на аномалії: порожній результат, стрибок метрики до нуля, пропуск інтервалу — вони піднімають сповіщення до того, як дані підуть у продукт. При зміні зовнішньої схеми правимо шар запитів, логіку продукту не чіпаємо.
Як обмежити доступ і коли інтеграція взагалі не потрібна?
Ключі виносимо в секрет-сховище, розводимо за ролями й областями читання, звернення логуємо. Якщо завдання — одна метрика раз на добу, достатньо планового вивантаження.
Власний шар доступу виправданий, коли потрібні історичні зрізи, похідні розрахунки й метрика всередині користувацького сценарію.
Обговоримо задачу: які дані потрібні для точної оцінки
Щоб оцінка була точною, а не «плюс-мінус», нам потрібні ввідні — не загальний опис, а конкретика по даних. Список мереж і адрес контрактів, які вас цікавлять, задає обсяг вибірок і те, як будується індексація. Дані можна надіслати в будь-якому вигляді: таблиця, список адрес, скриншоти поточних панелей.
Корисно отримати від вас:
- перелік мереж і контрактів, за якими потрібні метрики;
- список споживачів даних: дашборд, внутрішній сервіс, звітність для партнерів;
- поточні способи вивантаження — ручний експорт, запити до вузлів, готові панелі, звернення до Dune Analytics API;
- вимоги до свіжості: реальний час, раз на годину або раз на добу — від цього залежить схема оновлення;
- ролі та доступи: хто бачить сирі дані, хто лише агрегати;
- очікуваний формат видачі — таблиця, подія, показник в інтерфейсі;
- обмеження за навантаженням і відмовостійкістю, якщо сервіс уже працює під навантаженням.
За цими ввідними ми опишемо план робіт: які контракти обходимо, яка модель зберігання потрібна, де ставимо кеш і як обробляємо пропуски в блоках.
Критерії приймання фіксуємо до старту — звірка агрегатів із незалежним джерелом, поведінка при переіндексації, повнота історичних даних за потрібний період.
Опишіть задачу — повернемося з оцінкою, планом робіт і строками за етапами.
