Вызов для современного стека данных блокчейн

Существует несколько проблем, с которыми может столкнуться современный стартап по индексированию блокчейна, в том числе:

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

• Сложный конвейер обработки данных. Технология блокчейн сложна, и создание всеобъемлющего и надежного индекса данных требует глубокого понимания лежащих в основе структур данных и алгоритмов. Это наследуется разнообразием реализаций блокчейна. Если привести конкретные примеры, то NFT в Ethereum обычно создаются в рамках смарт-контрактов, которые следуют формату ERC721 и ERC1155, в то время как реализация таких контрактов на Polkadot, например, обычно строится непосредственно в runtime блокчейна. В конце концов, их следует рассматривать как НМТ и сохранять как таковые.

• Интеграционные возможности. Чтобы обеспечить максимальную ценность для пользователей, решение для индексирования блокчейна может потребовать интеграции своего индекса данных с другими системами, такими как аналитические платформы или API. Это непросто и требует значительных усилий при проектировании архитектуры.
  Поскольку использование технологии блокчейн стало более распространенным, объем данных, хранящихся в блокчейне, увеличился. Это происходит потому, что все больше людей используют эту технологию, и каждая транзакция добавляет новые данные в блокчейн. Кроме того, использование технологии блокчейн эволюционировало от простых приложений для перевода денег, например, с использованием Биткойна, до более сложных приложений, включающих реализацию бизнес-логики в рамках смарт-контрактов. Эти смарт-контракты могут генерировать большие объемы данных, что способствовало увеличению сложности и размера блокчейна. Со временем это привело к появлению более крупного и сложного блокчейна.

В этой статье мы поэтапно рассмотрим развитие технологической архитектуры Footprint Analytics в качестве примера, чтобы изучить, как технологический стек Iceberg-Trino решает проблемы, связанные с данными в сети.

Компания Footprint Analytics проиндексировала около 22 публичных блокчейн данных, а также 17 NFT marketplace, 1900 GameFi project, и более 100 000 NFT коллекций в семантический абстрактный слой данных. Это самое комплексное решение по хранению данных блокчейн в мире.

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

За последние несколько месяцев мы провели 3 крупных обновления, чтобы соответствовать растущим требованиям бизнеса:

Архитектура 1.0 Bigquery

В начале работы Footprint Analytics мы использовали Google Bigquery в качестве хранилища и механизма запросов; Bigquery - отличный продукт. Он молниеносно быстр, прост в использовании, предоставляет динамические арифметические возможности и гибкий синтаксис UDF, который помогает нам быстро выполнять работу.

Однако Bigquery также имеет ряд проблем.

• Данные не сжимаются, что приводит к высоким затратам на хранение, особенно когда речь идет о хранении необработанных данных более 22 блокчейнов Footprint Analytics.

• Недостаточный параллелизм: Bigquery поддерживает только 100 одновременных запросов, что не подходит для сценариев с высоким параллелизмом для Footprint Analytics, когда обслуживается большое количество аналитиков и пользователей.

• Блокировка с Google Bigquery, который является продуктом с закрытым исходным кодом。
  Поэтому мы решили изучить другие альтернативные архитектуры.

Архитектура 2.0 OLAP

Мы были очень заинтересованы в некоторых продуктах OLAP, которые стали очень популярными. Наиболее привлекательным преимуществом OLAP является время ответа на запрос, которое обычно занимает субсекунды для возврата результатов запроса для огромных объемов данных, а также может поддерживать тысячи одновременных запросов.

Мы выбрали одну из лучших OLAP баз данных, Doris, чтобы попробовать. Этот двигатель работает хорошо. Однако в какой-то момент мы столкнулись с другими проблемами:

• Такие типы данных, как Array или JSON, пока не поддерживаются (ноябрь, 2022). Массивы являются распространенным типом данных в некоторых блокчейнах. Например, поле topic в журналах evm. Невозможность вычислений на Array напрямую влияет на нашу способность вычислять многие бизнес-показатели.

• Ограниченная поддержка для ДБТ, а также для заявлений о слиянии. Это обычные требования инженеров по обработке данных для сценариев ETL/ELT, где нам нужно обновить некоторые новые индексированные данные.
  Учитывая это, мы не могли использовать Doris для всего нашего конвейера данных на производстве, поэтому мы попытались использовать Doris в качестве OLAP базы данных для решения части нашей проблемы в конвейере производства данных, действуя как механизм запросов и обеспечивая быстрые и высоко параллельные возможности запросов.

К сожалению, мы не могли заменить Bigquery на Doris, поэтому нам приходилось периодически синхронизировать данные из Bigquery в Doris, используя его только как механизм запросов. Этот процесс синхронизации имел ряд проблем, одна из которых заключалась в том, что записи обновлений быстро накапливались, когда OLAP-движок был занят обслуживанием запросов внешних клиентов. Впоследствии это сказалось на скорости процесса записи, и синхронизация заняла гораздо больше времени, а иногда даже стала невозможной для завершения.

Мы поняли, что OLAP может решить несколько проблем, с которыми мы столкнулись, но не может стать готовым решением Footprint Analytics, особенно для конвейера обработки данных. Наша проблема больше и сложнее, и мы можем сказать, что одного OLAP как механизма запросов нам недостаточно.

Архитектура 3.0 Айсберг + Трино

Добро пожаловать в архитектуру Footprint Analytics 3.0 - полный пересмотр базовой архитектуры. Мы переработали всю архитектуру с нуля, чтобы разделить хранение, вычисления и запросы данных на три разные части. Взяв уроки из двух предыдущих архитектур Footprint Analytics, и изучив опыт других успешных проектов по работе с большими данными, таких как Uber, Netflix и Databricks.

Внедрение озера данных

Сначала мы обратили внимание на озеро данных - новый тип хранения структурированных и неструктурированных данных. Озеро данных идеально подходит для хранения данных в сети, поскольку форматы данных в сети широко варьируются от неструктурированных сырых данных до структурированных абстрактных данных Footprint Analytics хорошо известны. Мы ожидали использовать озеро данных для решения проблемы хранения данных, и в идеале оно также должно поддерживать основные вычислительные механизмы, такие как Spark и Flink, чтобы интеграция с различными типами вычислительных механизмов по мере развития Footprint Analytics не была мучением.

Iceberg очень хорошо интегрируется со Spark, Flink, Trino и другими вычислительными движками, и мы можем выбирать наиболее подходящие вычисления для каждой из наших метрик. Например：

• Для тех, кому требуется сложная вычислительная логика, выбор будет сделан в пользу Spark.

• Flink для вычислений в реальном времени.

• Для простых задач ETL, которые можно выполнить с помощью SQL, мы используем Trino.

  Механизм запросов

Когда Iceberg решил проблемы хранения и вычислений, нам пришлось задуматься о том, как выбрать механизм запросов. Существует не так много вариантов, альтернативы, которые мы рассматривали, были следующими

• Trino: SQL Query Engine

• Presto: SQL Query Engine

• Kyuubi: Бессерверный Spark SQL
  Самым важным моментом, который мы учитывали, прежде чем углубиться, было то, что будущий механизм запросов должен быть совместим с нашей текущей архитектурой.

• Для поддержки Bigquery в качестве источника данных

• Для поддержки DBT, на которую мы полагаемся для получения многих показателей

• Для поддержки BI-инструмента metabase
  Исходя из вышесказанного, мы выбрали Trino, который имеет очень хорошую поддержку Iceberg, и команда была настолько отзывчива, что мы обнаружили ошибку, которая была исправлена на следующий день и выпущена в последней версии на следующей неделе. Это был определенно лучший выбор для команды Footprint, которой также требуется высокая оперативность внедрения.

Тестирование производительности

Как только мы определились с направлением, мы провели тест производительности комбинации Trino + Iceberg, чтобы проверить, сможет ли она удовлетворить наши потребности, и к нашему удивлению, запросы были невероятно быстрыми.

Зная, что Presto + Hive был худшим компаратором в течение многих лет во всей этой OLAP-шумихе, комбинация Trino + Iceberg полностью взорвала наши умы.

Вот результаты наших тестов.

• случай 1 : объединение большого набора данных

  Таблица1 объемом 800 ГБ присоединяется к другой таблице2 объемом 50 ГБ и выполняет сложные бизнес-вычисления

• случай2: использование большой отдельной таблицы для выполнения различительного запроса

  Test sql : select distinct(address) from table group by day

Комбинация Trino+Iceberg примерно в 3 раза быстрее, чем Doris в той же конфигурации.

В дополнение к этому, есть еще один сюрприз, потому что Iceberg может использовать форматы данных, такие как Parquet, ORC и т.д., которые будут сжимать данные и хранить их. Хранилище таблиц Iceberg занимает лишь около 1/5 пространства других хранилищ данных Размер хранения одной и той же таблицы в трех базах данных выглядит следующим образом:

Примечание: Приведенные выше тесты являются отдельными примерами, с которыми мы столкнулись в реальном производстве, и приведены только для справки.

・・Эффект обновления

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

• Несколько компьютерных двигателей соответствуют нашим различным потребностям.

• Trino поддерживает DBT, может запрашивать Iceberg напрямую, поэтому нам больше не нужно заниматься синхронизацией данных.

• Удивительная производительность Trino + Iceberg позволяет нам открыть все данные Bronze (необработанные данные) для наших пользователей.

  Краткая информация

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

Обновление архитектуры Footprint Analytics 3.0 подарило новый опыт пользователям, позволяя пользователям из разных слоев общества получать информацию в более разнообразных сферах использования и применения:

• Footprint, созданный на основе BI-инструмента Metabase, позволяет аналитикам получить доступ к декодированным данным о цепочке, исследовать их с полной свободой выбора инструментов (no-code или hardcord), запрашивать всю историю, перекрестно исследовать наборы данных, чтобы получить глубокие знания в кратчайшие сроки.

• Интегрируйте данные как в сети, так и вне сети для анализа в web2 + web3;

• Создавая метрики / запросы поверх бизнес-абстракции Footprint, аналитики или разработчики экономят время на 80% повторяющейся работы по обработке данных и сосредотачиваются на значимых метриках, исследованиях и продуктовых решениях, основанных на их бизнесе.

• Бесшовный опыт от Footprint Web до вызовов REST API, все на основе SQL

• Оповещения в реальном времени и действенные уведомления о ключевых сигналах для поддержки инвестиционных решений