Настройка аналитики блокчейна в Dune: SQL, дашборды, API

Настройка Dune Analytics: где ломается ручной сбор данных

Ручной сбор метрик из сети держится, пока речь идёт об одном кошельке и одном отчётном периоде. Как только в отчётность попадают десятки контрактов, несколько сетей и ежедневные срезы, ручная работа перестаёт масштабироваться: выгрузки делаются в разное время, с разной глубиной истории и с разными допущениями о том, что вообще считать транзакцией. Дальше начинается не аналитика, а разбор того, почему у двух отделов цифры за один месяц не совпадают.

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

Второе — расхождения в отчётности. Два среза по одному периоду не сходятся, потому что в одном учтены неуспешные транзакции, в другом только подтверждённые; в одном переводы между своими адресами посчитаны дважды, в другом вырезаны. Метрика обрастает исключениями, которые живут в чьей-то таблице, и спор идёт уже не о стратегии, а о методике подсчёта.

Настройка Dune Analytics закрывает именно эту часть: запросы на SQL выполняются поверх уже проиндексированных данных блокчейна, поэтому метрика считается один раз и по одному определению. Сеть обновилась — обновился и результат запроса, без ручных выгрузок и сверок. Дашборд и API отдают те же числа, что видят инженеры, и расхождения остаются только там, где действительно разошлись ожидания по методике, а не там, где разошлись даты выгрузки.

Что меняется после внедрения: измеримый эффект

Эффект от Dune измеряется на уровне процесса, а не «стало удобнее». До внедрения новый вопрос к блокчейн-данным — это отдельная выгрузка, ручная сверка и день-два ожидания; после — запрос поверх уже проиндексированных контрактов, который отвечает за минуты. Аналитик перестаёт быть узким местом, и очередь запросов от продукта больше не копится.

Доля ручных операций падает предсказуемо. Обновление витрин переводится на расписание, пересчёт метрик идёт по одному и тому же запросу, и человек не «докручивает» цифры в таблице перед встречей. Освободившееся время уходит на формулировку метрик, а не на их сбор.

Сходимость цифр — отдельный класс отказов, который закрывается архитектурно. Когда дашборды и API читают из одной модели данных, расхождение между отчётом для инвесторов и внутренним срезом исчезает по построению: обе стороны считают одну величину из одного источника. Правка вносится в одном месте, а не в пяти таблицах.

Скорость получения метрик становится свойством системы, а не героизма конкретного инженера. Новый дашборд по проиндексированным данным собирается за часы, а API отдаёт те же агрегаты, что и визуальный слой, — без второй реализации логики. Это и есть проверяемый результат: меньше ручных шагов, быстрее ответ, одна версия правды.

Подходы к сбору метрик: сравнение вариантов

Три уровня сбора отличаются не удобством, а тем, кто отвечает за корректность цифр и как быстро правка доходит до отчёта: готовые публичные запросы, собственные запросы на внешней платформе и полностью свой сбор данных.

Готовые запросы дают быстрый старт: схему контрактов не нужно описывать вручную. Но логика фильтров задана автором — список адресов, пороги, окно агрегации вы не контролируете. При изменении контракта такой дашборд молча показывает неполную картину, и заметить это можно только по расхождению с независимым источником.

Три варианта и их границы

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

Этапы настройки: от аудита источников до передачи

Начинаем с аудита источников: сверяем контракты и пулы с тем, что уже проиндексировано в Dune, и определяем, где хватит готовых таблиц, а где нужна декодировка журналов событий. Уже на этом шаге видно, какие метрики реально собрать, а какие придётся считать приближённо.

1. Аудит источников. Перечень сетей, адресов и подтверждённых таблиц — опора для всех последующих запросов.
2. Схема данных и метрик. Договариваемся, что означает «активный адрес», «объём» и «когорта»: без единых определений цифры на панели не совпадут с внутренним учётом.
3. Написание запросов. SQL с параметрами по периодам и сетям; переиспользуемые расчёты выносим в отдельные представления, чтобы панели не дублировали логику.
4. Проверка сходимости. Сверяем выборки с независимым источником и разбираем расхождения до их устранения — только после этого цифрам можно доверять.
5. Сборка панелей. Дашборд под конкретные решения: динамика, распределение, крупные участники, а не графики ради графиков.
6. Передача доступов. Роли в рабочем пространстве, инструкция по запросам и метрикам, порядок правок без нашего участия.

Каждый этап закрывается артефактом: перечень источников, документ с определениями метрик, проверенный набор запросов, готовые панели. Передача не превращается в устный рассказ — результат можно поддерживать своими силами.

Артефакты: запросы, панели, регламенты, доступы

Аналитика держится не на графиках, а на обвязке вокруг них — коде запросов, описаниях полей и правах. Без этого через месяц никто не объяснит, откуда в отчёте взялась цифра, а любую доработку придётся начинать с нуля. Поэтому результат работы фиксируем в артефактах, которые остаются у вашей команды.

• Набор запросов — по одному на показатель, с разбивкой по контрактам, пулам и периодам. В шапке каждого указано, какие таблицы и фильтры используются и почему отсечены служебные операции.
• Панели и графики — сводная панель для руководства и детальные для аналитиков: объёмы, активные адреса, концентрация у крупных держателей. Периоды и определения едины, поэтому цифры на разных экранах сходятся.
• Справочник метрик — таблица «показатель → формула → источник данных → владелец». Снимает споры вида «у нас другой объём»: обе команды считают по одному определению.
• Политики доступа — роли на чтение, правку и публикацию, привязка к корпоративным учётным записям, отдельный контур для внешних подрядчиков.
• Регламент обновления — расписание пересчёта, список внешних зависимостей, порядок действий при сбое источника или изменении схемы, а также периодическая сверка ключевых цифр с независимым источником.
• Инструкция по сопровождению — как добавить новый показатель, где лежат версии запросов, кому сообщать о расхождении. Новый аналитик включается без переписки с нами.

Комплект передаём в рабочее пространство Dune и в репозиторий заказчика с историей правок: любую метрику можно откатить к прежней версии или показать, что именно в ней изменилось. Доступы оформляем на ваши учётные записи, чтобы аналитика не осталась привязана к нам.

Кейс: расхождения в отчётности сократили до нуля

Исходная картина: данные по нескольким контрактам собирались вручную — инженеры выгружали операции из обозревателя сети в таблицы, сводили в электронной таблице и уже оттуда собирали отчёт для руководства. В месяц выходило около 40 ручных выгрузок, на подготовку уходило двое суток, а расхождения между отчётом и данными сети доходили до 6–8% — часть транзакций терялась при копировании, часть учитывалась дважды после внутренних переводов.

Что изменили

Логику расчёта перенесли в Dune и разложили на слои. Сырые таблицы блоков, логов событий и вызовов контрактов нормализуются в промежуточных SQL-представлениях: приводим адреса к одному регистру, размечаем внутренние переводы флагом, отсекаем реверсированные транзакции. Поверх — материализованные агрегаты по адресам, токенам и пулам с пересчётом по номеру блока, поэтому любая цифра воспроизводится на любую дату, а не «на момент выгрузки». Дашборд и API отдают одни и те же агрегаты, то есть внутренняя отчётность и внешние запросы считаются по одному источнику.

Результат в метриках

Ручные выгрузки сократились с 40 до нуля — осталась только ежемесячная сверка двух контрольных сумм. Доля расхождений ушла в ноль и держится на протяжении всех проведённых сверок: расхождение теперь означает ошибку в модели, а не в ручной работе, и ловится тестом до публикации. Новый отчёт — по новой сети, токену или периоду — собирается за 2–4 часа вместо двух суток, потому что переиспользуются готовые представления, а не пересобирается цепочка выгрузок.

Чем отличается готовая панель от собственного сбора данных?

Готовая панель площадки Dune отвечает на типовые вопросы быстро: данные уже проиндексированы, метрики посчитаны, срез по объёмам и активным адресам виден в тот же день. Предел наступает там, где нужен свой разрез — доля кошельков с повторными операциями или стык активности с данными продукта. В чужой витрине такой разрез либо не появится, либо будет считаться по чужой логике.

Свой сбор данных — это собственный расчётный слой: свои определения метрик, своя глубина истории, свой график пересчёта. Команда сама отвечает за свежесть и полноту, за пересчёт при обновлении контрактов и за то, чтобы метрика не разошлась после смены схемы на стороне площадки. Взамен — контроль над данными и изменения в днях, а не в сроке чужого релиза.

Выбор сводится к трём режимам:

Практический критерий простой: если аналитика нужна для обзора рынка — хватает готовой панели. Если цифры уходят в отчётность, риск-модели или продуктовые решения, нужен свой слой, иначе расхождение в определении метрики всплывёт в момент спора о цифрах.

Частые технические сомнения перед стартом

Разбираем сомнения, которые чаще всего звучат до старта. Они касаются не самого Dune, а поведения данных в эксплуатации: скорости индексации, изменений логики контракта, достоверности цифр и разграничения доступов.

Контракт обновили — отчёты продолжат работать?

Смена логики ломает метрики молча: адрес тот же, а события и их параметры другие. Мы фиксируем адреса и сигнатуры в конфигурации, проверяем появление новых сигнатур и версионируем запросы — после обновления видно, какие панели поехали, вместо обнаружения расхождения в отчёте для руководства.

Как убедиться, что цифры верные?

Верификация цифр строится не на доверии к дашборду. Сверяем агрегаты с независимым источником, проверяем сходимость сумм по адресам и периодам, добавляем тесты на известные транзакции и контроль целостности — расхождение всплывает на этапе сборки, а не на защите бюджета.

Как выдавать данные наружу и не открыть лишнего?

Доступ через программный интерфейс отдаём отдельным ключам с ограниченным набором запросов, а не полными правами на рабочее пространство. Секреты храним в защищённом хранилище, разграничиваем роли на чтение и правку, ведём журнал обращений — при утечке ключа его отзывают без пересборки всей аналитики.

Обсудим задачу: что нужно от вас для старта

Для первого разговора не нужен готовый документ с требованиями — достаточно того, что уже есть под рукой. Ниже список, который закрывает почти все вопросы по настройке аналитики на Dune: с ним мы возвращаемся не с уточнениями, а с оценкой сроков, схемой слоёв данных и планом по этапам.

• Доступы к данным: адреса контрактов по сетям, список кошельков, пулов или токенов, права на чтение во внутренних системах — если часть расчёта идёт по вашим данным, а не только по сети.
• Перечень вопросов, на которые отчёт должен отвечать: распределение капитала, движение по адресам, отчёт для фонда или мониторинг рисков. От этого зависит набор метрик и детализация.
• Примеры отчётов: текущие выгрузки, таблицы, скриншоты старых панелей. Даже неудобный формат показывает, какие срезы и разрезы вам действительно нужны.
• План работ: как часто данные должны обновляться и кто их смотрит — ежедневный мониторинг и месячная сводка для инвесторов собираются разными слоями.
• Оценка сроков: дата, к которой нужен первый результат, и есть ли жёсткая привязка к событию — отчётности, сделке, запуску продукта.
• Ответственный на вашей стороне, кто подтвердит логику расчёта метрик и примет результат по завершении этапа.

Этого достаточно, чтобы стартовать: остальное добираем на разговоре. Опишите задачу — вернёмся с оценкой, схемой работ и планом, где первый рабочий отчёт вы увидите задолго до закрытия всей задачи.