1.Задача современного стека данных для блокчейна
Существует несколько проблем, с которыми может столкнуться современный стартап по индексированию блокчейна, включая:
- Массивные объемы данных. По мере увеличения объема данных на блокчейне индекс данных должен будет масштабироваться, чтобы справиться с возросшей нагрузкой и обеспечить эффективный доступ к данным. Следовательно, это приводит к увеличению затрат на хранение данных, медленному расчету метрик и увеличению нагрузки на сервер базы данных.
- Сложный конвейер обработки данных. Технология блокчейн является сложной, и создание всеобъемлющего и надежного индекса данных требует глубокого понимания лежащих в основе структур данных и алгоритмов. Разнообразие реализаций блокчейна наследует это. Если привести конкретные примеры, то NFT в Ethereum обычно создаются в рамках смарт-контрактов, следующих форматам ERC721 и ERC1155. В отличие от этого, их реализация, например, на Polkadot, обычно строится непосредственно в блокчейн runtime. Их следует считать НМТ и сохранять в таком виде.
- Возможности интеграции. Чтобы обеспечить максимальную ценность для пользователей, решение для индексирования блокчейна может потребовать интеграции своего индекса данных с другими системами, такими как аналитические платформы или API. Это непросто и требует значительных усилий при проектировании архитектуры.
По мере распространения технологии блокчейн увеличивается объем данных, хранящихся в блокчейне. Это происходит потому, что все больше людей используют эту технологию, и каждая транзакция добавляет новые данные в блокчейн. Кроме того, технология блокчейн эволюционировала от простых приложений для перевода денег, таких как использование биткойна, к более сложным приложениям, включающим реализацию бизнес-логики в смарт-контрактах. Эти смарт-контракты могут генерировать большие объемы данных, способствуя увеличению сложности и размера блокчейна. Со временем это привело к появлению более крупного и сложного блокчейна.
В этой статье мы поэтапно рассматриваем эволюцию технологической архитектуры Footprint Analytics в качестве примера, чтобы изучить, как технологический стек Iceberg-Trino решает проблемы, связанные с данными на блокчейне.
Footprint Analytics проиндексировала около 22 публичных блокчейн-данных, а также 17 рынков NFT, 1900 проектов GameFi и более 100 000 коллекций NFT в слой данных семантической абстракции. Это самое комплексное решение для хранения данных блокчейна в мире.
Независимо от данных блокчейна, которые включают более 20 миллиардов строк записей финансовых транзакций, которые аналитики данных часто запрашивают. это отличается от журналов ингрессии в традиционных хранилищах данных.
За последние несколько месяцев мы пережили 3 крупных обновления, чтобы соответствовать растущим требованиям бизнеса:
2. Архитектура 1.0 Bigquery
В начале работы Footprint Analytics мы использовали Google Bigquery в качестве хранилища и механизма запросов; Bigquery — отличный продукт. Он молниеносно быстр, прост в использовании, предоставляет динамические арифметические возможности и гибкий синтаксис UDF, что помогает нам быстро выполнять работу.
Однако у Bigquery есть и несколько проблем.
- Данные не сжимаются, что приводит к высоким затратам, особенно при хранении необработанных данных более 22 блокчейнов Footprint Analytics.
- Недостаточный параллелизм: Bigquery поддерживает только 100 одновременных запросов, что не подходит для сценариев с высоким параллелизмом для Footprint Analytics при обслуживании многих аналитиков и пользователей.
- Блокировка с Google Bigquery, который является продуктом с закрытым исходным кодом。
Поэтому мы решили изучить другие альтернативные архитектуры.
3. Архитектура 2.0 OLAP
Мы были очень заинтересованы в некоторых продуктах OLAP, которые стали очень популярными. Наиболее привлекательным преимуществом OLAP является время отклика на запрос, которое обычно занимает субсекунды для возврата результатов запроса для огромных объемов данных, а также может поддерживать тысячи одновременных запросов.
Мы выбрали одну из лучших OLAP баз данных, Doris, чтобы попробовать ее. Этот механизм работает хорошо. Однако в какой-то момент мы столкнулись с некоторыми другими проблемами:
- Типы данных, такие как Array или JSON, пока не поддерживаются (ноябрь, 2022). Массивы — распространенный тип данных в некоторых блокчейнах. Например, поле topic в журналах evm. Невозможность вычислений на массивах напрямую влияет на нашу способность вычислять многие бизнес-метрики.
- Ограниченная поддержка DBT и операторов слияния. Это обычные требования инженеров по обработке данных для сценариев ETL/ELT, когда нам нужно обновить некоторые новые индексированные данные.
Так как мы не могли использовать Doris для всего конвейера данных на производстве, мы попытались использовать Doris в качестве OLAP-базы данных для решения части наших проблем в конвейере данных, действуя как механизм запросов и обеспечивая быстрые и высококонкурентные возможности запросов.
К сожалению, мы не могли заменить Bigquery на Doris, поэтому нам пришлось периодически синхронизировать данные из Bigquery с Doris, используя его в качестве механизма запросов. Этот процесс синхронизации имел несколько проблем, одна из которых заключалась в том, что записи обновлений быстро накапливались, когда OLAP-движок был занят обслуживанием запросов для внешних клиентов. Впоследствии это сказывалось на скорости процесса записи, и синхронизация занимала гораздо больше времени, а иногда даже становилась невозможной.
Мы поняли, что OLAP может решить несколько стоящих перед нами проблем и не может стать готовым решением Footprint Analytics, особенно для конвейера обработки данных. Наша проблема больше и сложнее, и мы можем сказать, что OLAP как механизм запросов сам по себе был недостаточен для нас.
4. Архитектура 3.0 Iceberg + Trino
Добро пожаловать в архитектуру Footprint Analytics 3.0, которая представляет собой полный пересмотр базовой архитектуры. Мы переработали всю архитектуру с нуля, чтобы разделить хранение, вычисления и запросы данных на три разные части. Мы учли опыт двух предыдущих архитектур Footprint Analytics и опыт других успешных проектов больших данных, таких как Uber, Netflix и Databricks.
4.1. Внедрение озера данных
Сначала мы обратили внимание на озеро данных, новый тип хранилища данных как структурированных, так и неструктурированных. Озеро данных идеально подходит для хранения данных в сети, поскольку форматы данных в сети широко варьируются от неструктурированных сырых данных до структурированных абстрактных данных, которыми славится Footprint Analytics. Мы рассчитывали использовать озеро данных для решения проблемы хранения данных, а в идеале оно также должно поддерживать основные вычислительные движки, такие как Spark и Flink, чтобы интеграция с различными типами вычислительных движков по мере развития Footprint Analytics не доставляла хлопот.
Iceberg очень хорошо интегрируется со Spark, Flink, Trino и другими вычислительными движками, и мы можем выбирать наиболее подходящие вычисления для каждой из наших метрик. Например：
- Для тех, кому требуется сложная вычислительная логика, подойдет Spark.
- Flink для вычислений в реальном времени.
- Для простых ETL-задач, которые можно выполнить с помощью SQL, мы используем Trino.
4.2. Механизм запросов
После того, как Iceberg решил проблемы хранения и вычислений, нам пришлось задуматься о выборе движка для запросов. Вариантов не так много. Мы рассматривали следующие альтернативы:
- Trino: механизм запросов SQL
- Presto: SQL Query Engine
- Kyuubi: Бессерверный Spark SQL
Самое важное, что мы учли, прежде чем углубиться, — будущий механизм запросов должен быть совместим с нашей текущей архитектурой
- Для поддержки Bigquery в качестве источника данных.
- Для поддержки DBT, на которую мы полагаемся для получения многих метрик.
- Для поддержки метабазы BI инструмента
На основании вышеизложенного мы выбрали Trino, который имеет очень хорошую поддержку Iceberg, и команда была настолько отзывчива, что мы обнаружили ошибку, которая была исправлена на следующий день и выпущена в последней версии на следующей неделе. Это был лучший выбор для команды Footprint, которой также требуется высокая оперативность реализации.
4.3. Тестирование производительности
После того, как мы определились с направлением, мы провели тест производительности на комбинации Trino + Iceberg, чтобы проверить, сможет ли она удовлетворить наши потребности, и, к нашему удивлению, запросы выполнялись невероятно быстро.
Зная, что Presto + Hive был худшим компаратором в течение многих лет во всей этой OLAP-шумихе, комбинация Trino + Iceberg совершенно поразила нас.
Вот результаты наших тестов.
случай 1: объединение большого набора данных
Таблица1 размером 800 ГБ присоединяется к другой таблице2 размером 50 ГБ и выполняет сложные бизнес-вычисления
случай 2: использование большой отдельной таблицы для выполнения запроса на различение
Тестовый sql: select distinct(address) from the table group by day
Комбинация Trino+Iceberg примерно в 3 раза быстрее, чем Doris в той же конфигурации.
Кроме того, есть еще один сюрприз, поскольку Iceberg может использовать такие форматы данных, как Parquet, ORC и т.д., которые будут сжимать и хранить данные. Хранилище таблиц Iceberg занимает лишь около 1/5 пространства других хранилищ данных Размер хранения одной и той же таблицы в трех базах данных выглядит следующим образом:
Примечание: Приведенные выше тесты являются примерами, с которыми мы столкнулись в реальном производстве, и приведены только для справки.
4.4. Эффект обновления
Отчеты тестов производительности дали нам достаточно производительности, чтобы нашей команде потребовалось около 2 месяцев для завершения миграции, а это диаграмма нашей архитектуры после обновления.
- Многочисленные компьютерные двигатели соответствуют нашим различным потребностям.
- Trino поддерживает DBT и может напрямую запрашивать Iceberg, поэтому нам больше не нужно заниматься синхронизацией данных.
- Удивительная производительность Trino + Iceberg позволяет нам открыть все данные Bronze (необработанные данные) для наших пользователей.
5. Резюме
С момента своего запуска в августе 2021 года команда Footprint Analytics завершила три обновления архитектуры менее чем за полтора года, благодаря своему сильному желанию и решимости принести преимущества лучшей технологии баз данных своим пользователям криптовалют и твердому исполнению по внедрению и обновлению базовой инфраструктуры и архитектуры.
Обновление архитектуры Footprint Analytics 3.0 принесло новый опыт пользователям, позволяя пользователям из разных слоев общества получать информацию в более разнообразных сферах использования и применения:
- Созданный на базе BI-инструмента Metabase, Footprint позволяет аналитикам получить доступ к декодированным цепочечным данным, исследовать их с полной свободой выбора инструментов (no-code или hardcord), запрашивать всю историю и проводить перекрестный анализ наборов данных, чтобы получить глубокие знания в кратчайшие сроки.
- Интегрируйте данные из цепочки и вне цепочки для анализа через web2 + web3;
- Создавая метрики / запросы поверх бизнес-абстракции Footprint, аналитики или разработчики экономят время на 80% повторяющейся работы по обработке данных и сосредотачиваются на значимых метриках, исследованиях и продуктовых решениях, основанных на их бизнесе.
- Бесшовный опыт от Footprint Web до вызовов REST API, все на основе SQL
Оповещения в режиме реального времени и оперативные уведомления о ключевых сигналах для поддержки инвестиционных решений
