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

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 як наш механізм зберігання та запитів; Bigquery — чудовий продукт. Він неймовірно швидкий, простий у використанні, забезпечує динамічну арифметичну потужність і гнучкий синтаксис UDF, який допомагає нам швидко виконувати роботу.

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

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

Тому ми вирішили вивчити інші альтернативні архітектури.

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

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

Ми вибрали одну з найкращих баз даних OLAP, Доріс, щоб спробувати. Цей двигун працює добре. Однак у якийсь момент ми незабаром зіткнулися з іншими проблемами:

• Такі типи даних, як Array або JSON, ще не підтримуються (листопад 2022 р.). Масиви є поширеним типом даних у деяких блокчейнах. Наприклад, тематичне поле в журналах 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 вирішував проблеми зберігання та обчислень, нам довелося подумати про вибір механізму запитів. Доступних варіантів небагато. Альтернативи, які ми розглядали, були

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

• Для підтримки Bigquery як джерела даних
• Для підтримки DBT, на який ми покладаємося для створення багатьох показників
• Для підтримки метабази інструментів BI

Виходячи з вищезазначеного, ми обрали Trino, який має дуже хорошу підтримку для Iceberg, і команда була настільки чуйною, що ми виявили помилку, яку було виправлено наступного дня та випущено до останньої версії наступного тижня. Це був найкращий вибір для команди Footprint, яка також вимагає високої швидкості впровадження.

4.3. Тестування продуктивності

Коли ми визначилися з нашим напрямком, ми провели тест продуктивності комбінації Trino + Iceberg, щоб перевірити, чи відповідає вона нашим потребам, і, на наш подив, запити надходили неймовірно швидко.

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

Ось результати наших тестів.

випадок 1: приєднання до великого набору даних

Таблиця800 на 1 ГБ приєднується до іншої таблиці50 на 2 ГБ і виконує складні бізнес-розрахунки

case2: використовуйте велику єдину таблицю для виконання окремого запиту

Перевірте sql: виберіть distinct(address) із групи таблиць за днями

Комбінація 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 допомагає аналітикам отримати доступ до декодованих даних у ланцюжку, досліджувати з повною свободою вибору інструментів (без коду чи жорсткого зв’язку), запитувати всю історію та перехресно перевіряти набори даних, щоб отримати уявлення про немає часу.
• Інтегруйте дані як у мережі, так і поза мережею для аналізу через web2 + web3;
• Створюючи метрики/запити на основі бізнес-абстракції Footprint, аналітики та розробники заощаджують час на 80% повторюваної роботи з обробки даних і зосереджуються на значущих показниках, дослідженнях і рішеннях для продуктів, що базуються на їх бізнесі.
• Бездоганний досвід від Footprint Web до REST API викликів, усе на основі SQL
• Сповіщення в режимі реального часу та актуальні сповіщення про ключові сигнали для підтримки інвестиційних рішень