Spis treści
1. Wyzwanie dla nowoczesnego stosu danych blockchain
Istnieje kilka wyzwań, przed którymi może stanąć nowoczesny start-up indeksujący blockchain, w tym:
- Ogromne ilości danych. Wraz ze wzrostem ilości danych w łańcuchu bloków indeks danych będzie musiał skalować się w górę, aby obsłużyć zwiększone obciążenie i zapewnić efektywny dostęp do danych. W konsekwencji prowadzi to do wyższych kosztów przechowywania, powolnego obliczania metryk i zwiększonego obciążenia serwera bazy danych.
- Złożony potok przetwarzania danych. Technologia Blockchain jest złożona, a zbudowanie kompleksowego i niezawodnego indeksu danych wymaga głębokiego zrozumienia podstawowych struktur danych i algorytmów. Dziedziczy to różnorodność implementacji blockchain. Biorąc pod uwagę konkretne przykłady, NFT w Ethereum są zwykle tworzone w ramach inteligentnych kontraktów zgodnie z formatami ERC721 i ERC1155. W przeciwieństwie do tego, na przykład implementacja tych w Polkadot jest zwykle budowana bezpośrednio w środowisku uruchomieniowym łańcucha bloków. Te powinny być uważane za NFT i powinny być zapisane jako te.
- Możliwości integracji. Aby zapewnić użytkownikom maksymalną wartość, rozwiązanie do indeksowania blockchain może wymagać integracji swojego indeksu danych z innymi systemami, takimi jak platformy analityczne lub interfejsy API. Jest to trudne i wymaga znacznego wysiłku włożonego w projekt architektury.
Ponieważ technologia blockchain stała się bardziej powszechna, ilość danych przechowywanych w blockchain wzrosła. Dzieje się tak, ponieważ coraz więcej osób korzysta z tej technologii, a każda transakcja dodaje nowe dane do łańcucha bloków. Ponadto technologia blockchain ewoluowała od prostych aplikacji do przesyłania pieniędzy, takich jak te z wykorzystaniem Bitcoin, do bardziej złożonych aplikacji obejmujących implementację logiki biznesowej w ramach inteligentnych kontraktów. Te inteligentne kontrakty mogą generować duże ilości danych, przyczyniając się do zwiększonej złożoności i rozmiaru łańcucha bloków. Z biegiem czasu doprowadziło to do powstania większego i bardziej złożonego łańcucha bloków.
W tym artykule dokonujemy przeglądu ewolucji architektury technologii Footprint Analytics etapami jako studium przypadku, aby zbadać, w jaki sposób stos technologii Iceberg-Trino radzi sobie z wyzwaniami związanymi z danymi w łańcuchu.
Footprint Analytics zindeksował około 22 publicznych danych blockchain i 17 rynków NFT, 1900 projektów GameFi i ponad 100 000 kolekcji NFT w semantycznej warstwie danych abstrakcji. Jest to najbardziej wszechstronne rozwiązanie hurtowni danych typu blockchain na świecie.
Niezależnie od danych blockchain, które obejmują ponad 20 miliardów wierszy rekordów transakcji finansowych, które analitycy danych często przeszukują. różni się od dzienników wejść w tradycyjnych hurtowniach danych.
W ciągu ostatnich kilku miesięcy doświadczyliśmy 3 głównych aktualizacji, aby sprostać rosnącym wymaganiom biznesowym:
2. Architektura 1.0 BigQuery
Na początku Footprint Analytics używaliśmy BigQuery Google jako nasz mechanizm przechowywania i wysyłania zapytań; BigQuery to świetny produkt. Jest niesamowicie szybki, łatwy w użyciu i zapewnia dynamiczną moc arytmetyczną oraz elastyczną składnię UDF, która pomaga nam szybko wykonać zadanie.
Jednak Bigquery ma również kilka problemów.
- Dane nie są kompresowane, co wiąże się z wysokimi kosztami, zwłaszcza przy przechowywaniu nieprzetworzonych danych z ponad 22 łańcuchów bloków Footprint Analytics.
- Niewystarczająca współbieżność: Bigquery obsługuje tylko 100 jednoczesnych zapytań, co jest nieodpowiednie w przypadku scenariuszy o dużej współbieżności w Footprint Analytics, gdy obsługuje wielu analityków i użytkowników.
- Zablokuj się dzięki Google Bigquery, która jest produktem o zamkniętym źródle。
Postanowiliśmy więc zbadać inne alternatywne architektury.
3. Architektura 2.0 OLAP
Byliśmy bardzo zainteresowani niektórymi produktami OLAP, które stały się bardzo popularne. Najbardziej atrakcyjną zaletą OLAP jest czas odpowiedzi na zapytanie, który zwykle zajmuje mniej niż kilka sekund, aby zwrócić wyniki zapytania dla ogromnych ilości danych, a także może obsługiwać tysiące jednoczesnych zapytań.
Wybraliśmy jedną z najlepszych baz danych OLAP, Doris, spróbować. Ten silnik dobrze się sprawuje. Jednak w pewnym momencie szybko napotkaliśmy inne problemy:
- Typy danych, takie jak Array lub JSON, nie są jeszcze obsługiwane (listopad 2022 r.). Tablice są powszechnym typem danych w niektórych łańcuchach bloków. Na przykład pole tematyczne w dziennikach evm. Niemożność obliczenia na tablicy ma bezpośredni wpływ na naszą zdolność do obliczenia wielu wskaźników biznesowych.
- Ograniczona obsługa DBT i instrukcji scalania. Są to typowe wymagania dla inżynierów danych dla scenariuszy ETL/ELT, w których musimy zaktualizować niektóre nowo zindeksowane dane.
To powiedziawszy, nie mogliśmy użyć Doris do całego naszego potoku danych w produkcji, więc spróbowaliśmy użyć Doris jako bazy danych OLAP, aby rozwiązać część naszego problemu w potoku produkcji danych, działając jako silnik zapytań i zapewniając szybkie i wysoce możliwości zapytań równoległych.
Niestety nie mogliśmy zastąpić Bigquery Doris, więc musieliśmy okresowo synchronizować dane z Bigquery do Doris, używając go jako silnika zapytań. Z tym procesem synchronizacji wiązało się kilka problemów, z których jednym było szybkie spiętrzanie zapisów aktualizacji, gdy silnik OLAP był zajęty obsługą zapytań do klientów front-end. Następnie wpłynęło to na szybkość procesu pisania, a synchronizacja trwała znacznie dłużej, a czasem nawet stawała się niemożliwa do ukończenia.
Zdaliśmy sobie sprawę, że OLAP może rozwiązać kilka problemów, przed którymi stoimy, i nie może stać się gotowym rozwiązaniem Footprint Analytics, zwłaszcza w przypadku potoku przetwarzania danych. Nasz problem jest większy i bardziej złożony i można powiedzieć, że sam OLAP jako silnik zapytań nie był dla nas wystarczający.
4. Architektura 3.0 Góra lodowa + Trino
Witamy w architekturze Footprint Analytics 3.0, która całkowicie przebudowała podstawową architekturę. Przeprojektowaliśmy całą architekturę od podstaw, aby rozdzielić przechowywanie, obliczenia i zapytania danych na trzy różne części. Wyciągając wnioski z dwóch wcześniejszych architektur Footprint Analytics i korzystając z doświadczeń innych udanych projektów big data, takich jak Uber, Netflix i Databricks.
4.1. Wprowadzenie jeziora danych
Najpierw zwróciliśmy uwagę na jezioro danych, nowy typ przechowywania danych zarówno dla danych ustrukturyzowanych, jak i nieustrukturyzowanych. Jezioro danych jest idealne do przechowywania danych w łańcuchu, ponieważ formaty danych w łańcuchu obejmują szeroki zakres, od nieustrukturyzowanych surowych danych po ustrukturyzowane dane abstrakcji, z których Footprint Analytics jest dobrze znany. Spodziewaliśmy się, że wykorzystamy jezioro danych do rozwiązania problemu przechowywania danych, a najlepiej byłoby, gdyby obsługiwało ono również główne silniki obliczeniowe, takie jak Spark i Flink, tak aby integracja z różnymi typami silników przetwarzania nie była trudna w miarę ewolucji Footprint Analytics .
Iceberg bardzo dobrze integruje się ze Spark, Flink, Trino i innymi silnikami obliczeniowymi, dzięki czemu możemy wybrać najbardziej odpowiednie obliczenia dla każdej z naszych metryk. Na przykład:
- Dla tych, którzy wymagają złożonej logiki obliczeniowej, najlepszym wyborem będzie Spark.
- Flink do obliczeń w czasie rzeczywistym.
- Do prostych zadań ETL, które można wykonać za pomocą SQL, używamy Trino.
4.2. Silnik zapytań
Ponieważ firma Iceberg rozwiązała problemy związane z pamięcią masową i obliczeniami, musieliśmy pomyśleć o wyborze silnika zapytań. Nie ma wielu dostępnych opcji. Rozważaliśmy alternatywy
Najważniejszą rzeczą, którą rozważyliśmy przed zagłębieniem się, było to, że przyszły mechanizm zapytań musiał być zgodny z naszą obecną architekturą.
- Aby wspierać BigQuery jako źródło danych
- Aby wspierać DBT, na którym polegamy przy tworzeniu wielu wskaźników
- Do obsługi metabazy narzędzi BI
W oparciu o powyższe wybraliśmy Trino, które ma bardzo dobre wsparcie dla Iceberga, a zespół był tak responsywny, że zgłosiliśmy błąd, który został naprawiony następnego dnia i udostępniony do najnowszej wersji w następnym tygodniu. To był najlepszy wybór dla zespołu Footprint, który również wymaga dużej responsywności wdrożenia.
4.3. Test wydajności
Kiedy już zdecydowaliśmy się na nasz kierunek, przeprowadziliśmy test wydajności kombinacji Trino + Iceberg, aby sprawdzić, czy spełni ona nasze potrzeby i ku naszemu zaskoczeniu zapytania były niesamowicie szybkie.
Wiedząc, że Presto + Hive od lat jest najgorszym komparatorem w całym szumie dotyczącym OLAP, połączenie Trino + Iceberg całkowicie rozwaliło nasze umysły.
Oto wyniki naszych testów.
przypadek 1: dołącz do dużego zbioru danych
Tabela o pojemności 800 GB1 łączy się z inną tabelą o pojemności 50 GB2 i wykonuje złożone obliczenia biznesowe
przypadek 2: użyj dużej pojedynczej tabeli, aby wykonać odrębne zapytanie
Test sql: wybierz odrębny (adres) z grupy tabel według dnia
Połączenie Trino + Iceberg jest około 3 razy szybsze niż Doris w tej samej konfiguracji.
Ponadto jest jeszcze jedna niespodzianka, ponieważ Iceberg może używać formatów danych, takich jak Parquet, ORC itp., Które będą kompresować i przechowywać dane. Przechowywanie tabel Iceberg zajmuje tylko około 1/5 miejsca innych hurtowni danych Rozmiar przechowywania tej samej tabeli w trzech bazach danych jest następujący:
Uwaga: Powyższe testy są przykładami, które napotkaliśmy w rzeczywistej produkcji i służą wyłącznie jako odniesienie.
4.4. Efekt ulepszenia
Raporty z testów wydajności dały nam wystarczającą wydajność, że ukończenie migracji zajęło naszemu zespołowi około 2 miesięcy, a to jest schemat naszej architektury po aktualizacji.
- Wiele silników komputerowych odpowiada naszym różnym potrzebom.
- Trino obsługuje DBT i może bezpośrednio wysyłać zapytania do Iceberg, więc nie musimy już zajmować się synchronizacją danych.
- Niesamowita wydajność Trino + Iceberg pozwala nam otworzyć wszystkie dane Bronze (surowe dane) dla naszych użytkowników.
5. Podsumowanie
Od momentu uruchomienia w sierpniu 2021 r. zespół Footprint Analytics dokonał trzech aktualizacji architektury w mniej niż półtora roku, dzięki silnemu pragnieniu i determinacji, aby zapewnić korzyści płynące z najlepszej technologii baz danych swoim kryptoużytkownikom oraz solidnemu wykonaniu we wdrażaniu i modernizację podstawowej infrastruktury i architektury.
Aktualizacja architektury Footprint Analytics do wersji 3.0 zapewniła użytkownikom nowe wrażenia, umożliwiając użytkownikom z różnych środowisk uzyskanie wglądu w bardziej zróżnicowane wykorzystanie i aplikacje:
- Zbudowany za pomocą narzędzia Metabase BI, Footprint ułatwia analitykom uzyskanie dostępu do zdekodowanych danych w łańcuchu, eksplorację z pełną swobodą wyboru narzędzi (bez kodu lub twardego kabla), przeszukiwanie całej historii i krzyżowe badanie zestawów danych w celu uzyskania wglądu w brak czasu.
- Zintegruj dane zarówno on-chain, jak i off-chain do analizy w web2 + web3;
- Tworząc metryki / zapytania na podstawie abstrakcji biznesowej Footprint, analitycy lub programiści oszczędzają czas na 80% powtarzalnej pracy związanej z przetwarzaniem danych i koncentrują się na znaczących metrykach, badaniach i rozwiązaniach produktowych opartych na ich działalności.
- Bezproblemowe środowisko od Footprint Web do wywołań API REST, wszystkie oparte na języku SQL
- Alerty w czasie rzeczywistym i przydatne powiadomienia dotyczące kluczowych sygnałów, które wspierają decyzje inwestycyjne
