O desafio da pilha de dados de blockchain moderna

Há vários desafios que uma startup moderna de indexação de blockchain pode enfrentar, incluindo:

• Quantidades massivas de dados. À medida que a quantidade de dados na blockchain aumenta, o índice de dados precisará aumentar a escala para lidar com o aumento da carga e proporcionar acesso eficiente aos dados. Consequentemente, leva aos custos de armazenamento mais altos; cálculo de métricas lentas e aumenta a carga no servidor de banco de dados.

• Gasoduto complexo de processamento de dados. A tecnologia blockchain é complexa e construir um índice de dados abrangente e fiável exige uma compreensão profunda das estruturas de dados e algoritmos subjacentes. É herdado pela diversidade das implementações de blockchain. Dados a exemplos específicos, as NFT no Ethereum são normalmente criadas dentro de contratos inteligentes que seguem os formatos ERC721 e ERC1155, enquanto a implementação dessas no Polkadot, por exemplo, geralmente é construída diretamente dentro do tempo de execução da blockchain. No fim do dia, esses devem ser considerados como NFT e devem ser salvos como esses.

• Capacidades de integração. Para proporcionar o valor máximo aos utilizadores, uma solução de indexação de blockchain pode precisar de integrar o seu índice de dados com outros sistemas, como plataformas de análise ou APIs. Isto é um desafio e exige um esforço significativo no design da arquitetura.
  À medida que o uso da tecnologia blockchain se generalizou, a quantidade de dados armazenados na blockchain aumentou. Isto porque há mais pessoas a usar a tecnologia, e cada transação adiciona novos dados à blockchain. Além disso, o uso da tecnologia blockchain evoluiu de aplicações simples de transferência de dinheiro, como as que envolvem o uso de Bitcoin, para aplicações mais complexas que envolvem a implementação de lógica de negócios dentro de contratos inteligentes. Estes contratos inteligentes podem gerar grandes quantidades de dados, o que contribuiu para o aumento da complexidade e tamanho da blockchain. Com o tempo, isso levou a uma blockchain maior e mais complexa.

Neste artigo, revemos a evolução da arquitetura tecnológica da Footprint Analytics por etapas como um estudo de caso para explorar como a pilha tecnológica Iceberg-Trino resolve os desafios dos dados em cadeia.

O Footprint Analytics indexou cerca de 22 dados públicos de blockchain e 17 NFT marketplace, 1900 projeto GameFi e mais de 100.000 coleções NFT numa camada de dados de abstração semântica. É a solução de armazém de dados blockchain mais abrangente do mundo.

Independentemente dos dados da blockchain, que inclui mais de 20 bilhões de linhas de registos de transações financeiras, o que é frequentemente consultado por analistas de dados. é diferente dos registos de entrada nos data warehouses tradicionais.

Passámos por 3 grandes upgrades nos últimos meses para satisfazer as crescentes exigências dos negócios:

Arquitetura 1.0 Bigquery

No início do Footprint Analytics, usamos o Google Bigquery como nosso motor de armazenamento e consulta; o Bigquery é um ótimo produto. É extraordinariamente rápido, fácil de usar e fornece um poder aritmético dinâmico e uma sintaxe UDF flexível que nos ajuda rapidamente a fazer o trabalho.

No entanto, o Bigquery também tem uma série de problemas.

• Os dados não são compactados, o que resulta em elevados custos de armazenamento, especialmente quando se trata de armazenar dados brutos de mais de 22 blockchains do Footprint Analytics.

• Concorrência insuficiente: O Bigquery só suporta 100 consultas simultâneas, o que não é adequado para cenários de alta concorrência para o Footprint Analytics, ao servir um grande número de analistas e utilizadores.

• Fechar com o Google Bigquery, que é um produto de origem fechada
  Então decidimos explorar outras arquiteturas alternativas.

Arquitetura 2.0 OLAP

Estávamos muito interessados em alguns dos produtos OLAP que se tinham tornado muito populares. A vantagem mais atraente do OLAP é o tempo de resposta da consulta, que normalmente leva subsegundos para retornar os resultados da consulta para quantidades massivas de dados e também pode oferecer suporte a milhares de consultas simultâneas.

Escolhemos uma das melhores bases de dados OLAP, Doris, para experimentar. Este motor tem um bom desempenho. No entanto, a certa altura encontrámos alguns outros problemas em breve:

• Tipos de dados, como Array ou JSON, ainda não são suportados (Nov, 2022). As matrizes são um tipo de dados comum em algumas blockchains. Por exemplo, o campo de tópicos nos logs evm. Não é possível calcular no array afeta diretamente a nossa capacidade de calcular muitas métricas de negócios.

• Suporte limitado para DBT e para instruções de mesclagem. Estes são requisitos comuns para engenheiros de dados para cenários de ETL/ELT, onde precisamos atualizar alguns dados recentemente indexados.
  Dito isto, não podíamos usar a Doris para todo o nosso pipeline de dados sobre produção, então tentámos usar a Doris como base de dados OLAP para resolver parte do nosso problema no pipeline de produção de dados, agindo como um motor de consulta e fornecendo capacidades de consulta rápidas e altamente concorrentes.

Infelizmente, não podíamos substituir o Bigquery por Doris, então tivemos de sincronizar periodicamente os dados do Bigquery com a Doris usá-los apenas como um motor de consulta. Este processo de sincronização teve uma série de problemas, um dos quais era que as gravações das atualizações se acumulavam rapidamente quando o motor OLAP estava ocupado a prestar consultas aos clientes front-end. Posteriormente, a velocidade do processo de escrita foi afetada e a sincronização demorou muito mais e às vezes até se tornou impossível de terminar.

Percebemos que o OLAP podia resolver vários problemas que enfrentamos e não podíamos tornar-se a solução chave na mão do Footprint Analytics especialmente para o pipeline de processamento de dados. O nosso problema é maior e mais complexo, e podemos dizer que o OLAP como motor de consulta só não nos bastou.

Arquitetura 3.0 Iceberg + Trino

Bem-vindo à Footprint Analytics architecture 3.0, uma revisão completa da arquitetura subjacente. Redesenhámos toda a arquitetura desde o zero, para separar o armazenamento, a computação e a consulta dos dados em três partes diferentes. Tirar lições das duas arquiteturas anteriores do Footprint Analytics e aprender com a experiência de outros projetos de big data bem-sucedidos, como a Uber, Netflix e Databricks.

Introdução do data lake

Primeiro, voltámos a nossa atenção para o data lake, um novo tipo de armazenamento de dados para dados estruturados e não estruturados. O data lake é perfeito para armazenamento de dados em cadeia já que os formatos de dados em cadeia variam muito de dados brutos não estruturados a dados de abstração estruturados Footprint Analytics é bem conhecido. Esperávamos usar o data lake para resolver o problema do armazenamento de dados e, idealmente, também suportaria mecanismos de computação comuns, como o Spark e a Flink, para que não fosse uma dor integrar-se com diferentes tipos de mecanismos de processamento à medida que o Footprint Analytics evolui.

O Iceberg integra-se muito bem com Spark, Flink, Trino e outros motores computacionais, e podemos escolher o cálculo mais adequado para cada uma das nossas métricas. Por exemplo

• Para os que requerem uma lógica computacional complexa, a escolha será a escolha.

• Flink para computação em tempo real.

• Para tarefas de ETL simples que podem ser realizadas usando SQL, usamos Trino.

  Motor de consulta

Com o Iceberg a resolver os problemas de armazenamento e computação, tivemos de pensar em como escolher um motor de consulta. Não existem muitas opções disponíveis, as alternativas que considerámos foram

• Trino: Motor de Consultas SQL

• Presto: Motor de Consultas SQL

• Kyuubi: Spark SQL sem servidor
  A coisa mais importante que considerámos antes de aprofundar foi que o futuro motor de consulta tinha de ser compatível com a nossa arquitetura atual.

• Suporte para o Bigquery como Fonte de Dados

• Para apoiar a DBT, na qual dependemos para que muitas métricas sejam produzidas

• Para apoiar o calendário da ferramenta de BI
  Com base no acima, escolhemos o Trino, que tem muito bom apoio ao Iceberg e a equipa deu tanta resposta que levantámos um erro, que foi corrigido no dia seguinte e lançado para a última versão na semana seguinte. Esta foi definitivamente a melhor escolha para a equipa Pegada, que também exige elevada capacidade de resposta de implementação.

Testes de desempenho

Depois de decidirmos a nossa direção, fizemos um teste de desempenho na combinação Trino + Iceberg para ver se podia satisfazer as nossas necessidades e para nossa surpresa, as consultas foram incrivelmente rápidas.

Sabendo que o Presto + Colmeia é o pior comparador há anos em todos os hype OLAP, a combinação de Trino + Iceberg soou completamente a nossa mente.

Eis os resultados dos nossos testes.

• caso 1: junte-se a um conjunto de dados grande

  Uma tabela de 800 GB1 junta-se a outra tabela de 50 GB2 e faz cálculos de negócios complexos

• Caso 2: use uma tabela grande individual para fazer uma consulta distinta

  Testar sql: selecionar diferente (endereço) da tabela grupo por dia

A combinação Trino+Iceberg é 3 vezes mais rápida do que a Doris na mesma configuração.

Além disso, há outra surpresa, porque o Iceberg pode usar formatos de dados como Parquet, ORC, etc., o que vai comprimir os dados e armazená-los. O armazenamento de mesa do Iceberg demora apenas cerca de 1/5 do espaço de outros armazéns de dados O tamanho de armazenamento da mesma tabela nas três bases de dados é o seguinte:

Nota: Os testes acima são exemplos individuais que encontramos na produção real e são apenas para referência.

・Efeito de upgrade

Os relatórios dos testes de desempenho deram-nos um desempenho suficiente que a nossa equipa demorou cerca de 2 meses a concluir a migração e este é um diagrama da nossa arquitetura após o upgrade.

• Vários motores de computador correspondem às nossas várias necessidades.

• O Trino apoia a DBT, pode consultar o Iceberg diretamente, então não temos mais de lidar com a sincronização de dados.

• O incrível desempenho de Trino + Iceberg permite-nos abrir todos os dados do Bronze (dados brutos) aos nossos utilizadores.

  Resumo

Desde o seu lançamento em agosto de 2021, a equipe do Footprint Analytics concluiu três upgrades arquitetônicos em menos de um ano e meio, graças ao seu desejo e determinação em trazer os benefícios da melhor tecnologia de bases de dados aos seus usuários criptografados, e uma execução sólida na implementação e atualização da sua infraestrutura e arquitetura subjacentes.

O upgrade da arquitetura Footprint Analytics 3.0 comprou uma nova experiência aos seus utilizadores, permitindo que utilizadores de diferentes origens obtenham percepções sobre utilizações e aplicações mais diversas:

• Criado com a ferramenta Metabase BI, o Footprint facilita que os analistas tenham acesso a dados descodificados em cadeia, explorar com total liberdade de escolha de ferramentas (sem código ou hardcord), consultar o histórico inteiro, cruzar conjuntos de dados, para obter percepções num pouco tempo.

• Integrar dados em cadeia e fora da cadeia para análises na web2 + web3;

• Ao criar métricas de/consulta além da abstração de negócios da Pegada, os analistas ou desenvolvedores poupam tempo em 80% do trabalho repetitivo de processamento de dados e concentram-se em métricas significativas, pesquisa e soluções de produtos com base nos seus negócios.

• Experiência perfeita do Footprint Web às chamadas da API REST, todas baseadas em SQL

• Alertas em tempo real e notificações acionáveis nos sinais principais para apoiar decisões de investimento