Виклики сучасного стеку даних блокчейну
Сучасні стартапи з індексації блокчейну стикаються з низкою викликів, зокрема:
- Величезний обсяг даних. Зі зростанням кількості даних у блокчейні індекс даних має масштабуватися для обробки підвищеного навантаження та забезпечення ефективного доступу до інформації. Це призводить до зростання витрат на зберігання, уповільнення розрахунку метрик і збільшення навантаження на сервер бази даних.
- Складний конвеєр обробки даних. Технологія блокчейну є складною, а побудова комплексного й надійного індексу даних вимагає глибокого розуміння структур даних та алгоритмів. Це зумовлено різноманіттям реалізацій блокчейну. Наприклад, NFT в Ethereum зазвичай створюються у смартконтрактах за стандартами ERC721 та ERC1155, тоді як у Polkadot такі NFT часто реалізуються безпосередньо у виконуваному середовищі блокчейну. У підсумку, ці об’єкти мають розглядатися як NFT і зберігатися відповідно.
- Інтеграційні можливості. Щоб забезпечити максимальну цінність користувачам, рішення для індексації блокчейну може потребувати інтеграції індексу даних з іншими системами, такими як аналітичні платформи чи API. Це є складним завданням і потребує значних зусиль під час проєктування архітектури.
З розширенням використання блокчейн-технологій обсяг збережених у блокчейні даних зростає. Це пов’язано зі збільшенням кількості користувачів, і кожна транзакція додає нові дані. Крім того, використання блокчейн-технології еволюціонувало від простих грошових переказів, як у Bitcoin, до складніших застосувань із бізнес-логікою у смартконтрактах. Такі смартконтракти можуть генерувати великі обсяги даних, що призводить до ускладнення та збільшення розміру блокчейну. З часом це формує більший і складніший блокчейн.
У цьому матеріалі ми розглянемо поетапну еволюцію технологічної архітектури Footprint Analytics на прикладі, щоб показати, як стек Iceberg-Trino вирішує задачі роботи з ончейн-даними.
Footprint Analytics проіндексувала дані близько 22 публічних блокчейнів, 17 NFT-маркетплейсів, 1900 GameFi-проєктів і понад 100 000 NFT-колекцій у семантичний шар абстракції даних. Це найповніше рішення для сховища даних блокчейну у світі.
Блокчейн-дані, що містять понад 20 мільярдів рядків фінансових транзакцій і часто використовуються аналітиками даних, відрізняються від логів надходження у традиційних сховищах даних.
Протягом кількох останніх місяців ми здійснили три великі оновлення, щоб відповідати зростаючим бізнес-вимогам:
Архітектура 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-журналах. Неможливість обробляти масиви напряму обмежує наші можливості у розрахунку багатьох бізнес-метрик.
- Обмежена підтримка DBT та операторів merge. Це поширені вимоги для інженерів даних у сценаріях ETL/ELT, коли потрібно оновлювати нові проіндексовані дані.
Отже, ми не могли використовувати Doris для всього конвеєра даних у продакшені, тому вирішили застосовувати Doris як OLAP-базу для вирішення частини завдань у виробничому конвеєрі даних, використовуючи її як рушій запитів із високою швидкістю та паралельністю.
На жаль, повністю замінити Bigquery на Doris не вдалося, тому довелося періодично синхронізувати дані з Bigquery у Doris, використовуючи останню лише як рушій запитів. Процес синхронізації мав низку проблем, зокрема накопичення оновлюваних записів, коли OLAP-рушій був зайнятий обслуговуванням запитів фронтенду. Відповідно, швидкість запису знижувалася, а синхронізація займала значно більше часу, а іноді її неможливо було завершити.
Ми усвідомили, що OLAP вирішує частину проблем, але не є універсальним рішенням для Footprint Analytics, особливо щодо конвеєра обробки даних. Наше завдання масштабніше та складніше, і OLAP як самостійний рушій запитів нам не підходить.
Архітектура 3.0 Iceberg + Trino
Архітектура Footprint Analytics 3.0 — це повна перебудова базової структури. Ми повністю переробили архітектуру, розділивши зберігання, обчислення та запити даних на три окремі частини. Враховано досвід попередніх архітектур Footprint Analytics і найкращі практики великих проєктів, таких як Uber, Netflix та Databricks.
Вступ до data lake
Спершу ми звернули увагу на data lake — новий тип сховища для структурованих і неструктурованих даних. Data lake ідеально підходить для зберігання ончейн-даних, оскільки їхні формати варіюються від неструктурованих сирих до структурованих абстракцій, якими відома Footprint Analytics. Ми очікували, що data lake вирішить проблему зберігання даних і буде сумісним із популярними обчислювальними рушіями, такими як Spark і Flink, щоб інтеграція з різними типами рушіїв обробки не створювала складнощів у міру розвитку Footprint Analytics.
Iceberg добре інтегрується зі Spark, Flink, Trino та іншими обчислювальними рушіями, і ми можемо обирати найкращий рушій для кожної метрики. Наприклад:
- Для складних обчислень — Spark.
- Для обробки в реальному часі — Flink.
- Для простих ETL-завдань на SQL — Trino.
Рушій запитів
Після того, як Iceberg вирішив питання зберігання та обчислень, ми зосередилися на виборі рушія запитів. Варіантів було небагато, серед альтернатив розглядали:
- Trino: SQL Query Engine
- Presto: SQL Query Engine
- Kyuubi: Serverless Spark SQL
Найважливішим критерієм була сумісність майбутнього рушія запитів із нашою поточною архітектурою.
- Підтримка Bigquery як джерела даних
- Підтримка DBT, на якому базується створення багатьох метрик
- Підтримка BI-інструменту Metabase
Виходячи з цього, ми обрали Trino, який має чудову інтеграцію з Iceberg, а команда реагує дуже швидко: після повідомлення про баг його виправили наступного дня і випустили у новій версії вже за тиждень. Це був найкращий вибір для команди Footprint, яка цінує оперативність впровадження.
Тестування продуктивності
Після визначення напряму ми провели тестування продуктивності комбінації Trino + Iceberg, щоб переконатися, що вона відповідає нашим вимогам, і були приємно вражені швидкістю виконання запитів.
З огляду на те, що Presto + Hive довгий час вважалися найгіршим поєднанням серед OLAP-рішень, комбінація Trino + Iceberg повністю змінила наші очікування.
Ось результати наших тестів.
Випадок 1: об’єднання великих наборів даних
Таблиця 1 розміром 800 ГБ об’єднується з таблицею 2 розміром 50 ГБ і виконує складні бізнес-розрахунки
Випадок 2: distinct-запит у великій таблиці
Тестовий SQL: select distinct(address) from table group by day
Комбінація Trino+Iceberg приблизно втричі швидша за Doris за однакових умов.
Ще одна перевага: Iceberg підтримує формати даних Parquet, ORC тощо, які стискають і зберігають дані. Зберігання таблиць в Iceberg займає лише близько 1/5 простору порівняно з іншими сховищами даних. Розмір зберігання тієї ж таблиці у трьох базах даних наведено нижче:
Примітка: наведені вище тести — це окремі приклади з нашої реальної практики й наведені лише для довідки.
・Ефект оновлення
Звіти про тестування продуктивності підтвердили наш вибір, і команді знадобилося близько 2 місяців для повної міграції. Нижче наведено схему архітектури після оновлення.
- Кілька обчислювальних рушіїв відповідають різним потребам.
- Trino підтримує DBT і може напряму працювати з Iceberg, тому синхронізація даних більше не потрібна.
- Висока продуктивність Trino + Iceberg дозволяє нам відкривати всі Bronze-дані (сирі дані) для користувачів.
Підсумки
З моменту запуску у серпні 2021 року команда Footprint Analytics здійснила три архітектурних оновлення менш ніж за півтора року, завдяки наполегливості й рішучості впроваджувати найкращі технології баз даних для користувачів крипторинку та якісному впровадженню й модернізації інфраструктури.
Оновлення архітектури Footprint Analytics 3.0 принесло новий досвід користувачам, дозволяючи фахівцям із різних галузей отримувати інсайти у ширшому спектрі застосувань:
- Завдяки BI-інструменту Metabase Footprint аналітики отримують доступ до декодованих ончейн-даних, можуть вільно обирати інструменти (no-code або hardcode), робити запити до всієї історії, крос-аналізувати набори даних і швидко отримувати інсайти.
- Інтеграція ончейн- та офчейн-даних для аналізу у web2 + web3;
- Створюючи або виконуючи запити метрик на базі бізнес-абстракції Footprint, аналітики чи розробники економлять до 80% часу на рутинній обробці даних і можуть зосередитися на важливих метриках, дослідженнях і продуктових рішеннях.
- Безшовний досвід від Footprint Web до REST API-запитів — усе на основі SQL
- Оповіщення в реальному часі та дієві повідомлення про ключові сигнали для підтримки інвестиційних рішень
