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

1. Задача современного стека данных блокчейна

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

  • Огромные объемы данных. По мере увеличения объема данных в блокчейне индекс данных необходимо будет масштабировать, чтобы справиться с возросшей нагрузкой и обеспечить эффективный доступ к данным. Следовательно, это приводит к более высоким затратам на хранение, медленному расчету метрик и увеличению нагрузки на сервер базы данных.
  • Сложный конвейер обработки данных. Технология блокчейн сложна, и для создания комплексного и надежного индекса данных требуется глубокое понимание базовых структур данных и алгоритмов. Разнообразие реализаций блокчейна наследует его. Учитывая конкретные примеры, NFT в Ethereum обычно создаются в рамках смарт-контрактов в соответствии с форматами ERC721 и ERC1155. Напротив, реализация тех, что реализованы в Polkadot, например, обычно строится непосредственно в среде выполнения блокчейна. Их следует рассматривать как NFT и сохранять как таковые.
  • Возможности интеграции. Чтобы обеспечить максимальную ценность для пользователей, решению индексации блокчейна может потребоваться интегрировать свой индекс данных с другими системами, такими как аналитические платформы или API. Это сложно и требует значительных усилий, вложенных в архитектурный дизайн.

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

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

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

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

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

2. Архитектура 1.0 BigQuery

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

Однако у Bigquery также есть несколько проблем.

  • Данные не сжимаются, что приводит к высоким затратам, особенно при хранении необработанных данных более чем 22 блокчейнов Footprint Analytics.
  • Недостаточный параллелизм: Bigquery поддерживает только 100 одновременных запросов, что не подходит для сценариев с высоким параллелизмом для Footprint Analytics при обслуживании многих аналитиков и пользователей.
  • Зафиксируйтесь с помощью Google Bigquery, продукта с закрытым исходным кодом。

Поэтому мы решили изучить другие альтернативные архитектуры.

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

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

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

  • Такие типы данных, как Array или JSON, пока не поддерживаются (ноябрь 2022 г.). Массивы являются распространенным типом данных в некоторых блокчейнах. Например, поле темы в логах евм. Невозможность вычислений в массиве напрямую влияет на нашу способность вычислять многие бизнес-показатели.
  • Ограниченная поддержка DBT и операторов слияния. Это общие требования к инженерам данных для сценариев ETL/ELT, где нам необходимо обновить некоторые недавно проиндексированные данные.

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

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

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

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

Добро пожаловать в архитектуру 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 решал проблемы хранения и вычислений, нам пришлось подумать о выборе механизма запросов. Вариантов не так много. Альтернативы, которые мы рассматривали, были

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

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

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

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

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

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

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

случай 1: присоединиться к большому набору данных

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

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

Тестовый sql: выберите отдельный (адрес) из группы таблиц по дням

Комбинация 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 дало своим пользователям новый опыт, позволяющий пользователям из разных слоев общества получать информацию о более разнообразных способах использования и приложениях:

  • Построенный с помощью инструмента Metabase BI, Footprint помогает аналитикам получать доступ к декодированным данным в сети, исследовать с полной свободой выбора инструментов (без кода или с жесткой связью), запрашивать всю историю и перекрестно исследовать наборы данных, чтобы получить представление о нет времени.
  • Интегрируйте данные как в сети, так и вне сети для анализа через веб2 + веб3;
  • Создавая/запрашивая метрики поверх бизнес-абстракции Footprint, аналитики или разработчики экономят время на 80 % повторяющейся работы по обработке данных и сосредотачиваются на значимых метриках, исследованиях и продуктовых решениях, основанных на их бизнесе.
  • Беспроблемный опыт от Footprint Web до вызовов REST API, все на основе SQL
  • Оповещения в режиме реального времени и действенные уведомления о ключевых сигналах для поддержки инвестиционных решений

Источник: https://cryptoslate.com/iceberg-spark-trino-a-modern-open-source-data-stack-for-blockchain/