O desafio para a pilha de dados blockchain moderna

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

• Enormes quantidades de dados. À medida que a quantidade de dados no blockchain aumenta, o índice de dados precisará ser dimensionado para lidar com o aumento da carga e fornecer acesso eficiente aos dados. Conseqüentemente, leva a maiores custos de armazenamento; cálculo lento de métricas e aumento de carga no servidor de banco de dados.

• Pipeline de processamento de dados complexos. A tecnologia Blockchain é complexa e a construção de um índice de dados abrangente e confiável requer uma compreensão profunda das estruturas e algoritmos de dados subjacentes. É herdado pela diversidade de implementações de blockchain. Dados exemplos específicos, os NFTs no Ethereum geralmente são criados dentro de contratos inteligentes que seguem o formato ERC721 e ERC1155, enquanto a implementação daqueles no Polkadot, por exemplo, geralmente é construída diretamente no tempo de execução do blockchain. No final do dia, esses devem ser considerados como NFTs e devem ser salvos como aqueles.

• Capacidades de integração. Para fornecer valor máximo aos usuários, uma solução de indexação blockchain pode precisar integrar seu índice de dados com outros sistemas, como plataformas analíticas ou APIs. Isso é desafiador e requer um esforço significativo para o design da arquitetura.
  À medida que o uso da tecnologia blockchain se tornou mais difundido, a quantidade de dados armazenados no blockchain aumentou. Isso ocorre porque mais pessoas estão usando a tecnologia e cada transação adiciona novos dados ao blockchain. Além disso, o uso da tecnologia blockchain evoluiu de aplicativos simples de transferência de dinheiro, como os que envolvem o uso de Bitcoin, para aplicativos mais complexos que envolvem a implementação de lógica de negócios em contratos inteligentes. Esses contratos inteligentes podem gerar grandes quantidades de dados, o que contribuiu para o aumento da complexidade e tamanho do blockchain. Com o tempo, isso levou a uma blockchain maior e mais complexa.

Neste artigo, revisamos a evolução da arquitetura de tecnologia da Footprint Analytics em etapas como um estudo de caso para explorar como a pilha de tecnologia Iceberg-Trino aborda os desafios dos dados on-chain.

A Footprint Analytics indexou cerca de 22 dados públicos de blockchain e 17 mercados NFT, 1900 projetos GameFi e mais de 100.000 coleções NFT em uma camada de dados de abstração semântica. É a solução de armazenamento de dados blockchain mais abrangente do mundo.

Independentemente dos dados do blockchain, que incluem mais de 20 bilhões de linhas de registros de transações financeiras, que são frequentemente consultados por analistas de dados. é diferente dos logs de entrada em data warehouses tradicionais.

Passamos por três grandes atualizações nos últimos meses para atender aos crescentes requisitos de negócios:

Arquitetura 1.0 BigQuery

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

No entanto, o Bigquery também tem vários problemas.

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

• Simultaneidade insuficiente: o Bigquery suporta apenas 100 consultas simultâneas, o que não é adequado para cenários de alta simultaneidade para Footprint Analytics, ao atender um grande número de analistas e usuários.

• Conecte-se com o Google Bigquery, que é um produto de código fechado。
  Então decidimos explorar outras arquiteturas alternativas.

Arquitetura 2.0 OLAP

Estávamos muito interessados em alguns dos produtos OLAP que se tornaram muito populares. A vantagem mais atraente do OLAP é seu tempo de resposta de consulta, que normalmente leva menos de segundos para retornar resultados de consulta para grandes quantidades de dados, e também pode suportar milhares de consultas simultâneas.

Escolhemos um dos melhores bancos de dados OLAP, Doris, para experimentá-lo. Este motor funciona bem. No entanto, em algum momento, logo nos deparamos com outros problemas:

• Tipos de dados como Array ou JSON ainda não são compatíveis (novembro de 2022). Arrays são um tipo comum de dados em alguns blockchains. Por exemplo, o campo de tópico em logs evm. A incapacidade de calcular no Array afeta diretamente nossa capacidade de calcular muitas métricas de negócios.

• Suporte limitado para DBT e para instruções de mesclagem. Esses são requisitos comuns para engenheiros de dados para cenários ETL/ELT, nos quais precisamos atualizar alguns dados recém-indexados.
  Dito isto, não poderíamos usar Doris para todo o nosso pipeline de dados na produção, então tentamos usar Doris como um banco de dados OLAP para resolver parte do nosso problema no pipeline de produção de dados, atuando como um mecanismo de consulta e fornecendo informações rápidas e altamente recursos de consulta simultânea.

Infelizmente, não pudemos substituir o Bigquery pelo Doris, então tivemos que sincronizar periodicamente os dados do Bigquery para o Doris usando-o apenas como um mecanismo de consulta. Esse processo de sincronização tinha vários problemas, um dos quais era que as gravações de atualização se acumulavam rapidamente quando o mecanismo OLAP estava ocupado atendendo consultas aos clientes front-end. Posteriormente, a velocidade do processo de gravação foi afetada e a sincronização demorou muito mais e às vezes até se tornou impossível de terminar.

Percebemos que o OLAP poderia resolver vários problemas que enfrentamos e não poderia se tornar a solução chave na mão do Footprint Analytics, especialmente para o pipeline de processamento de dados. Nosso problema é maior e mais complexo, e podemos dizer que OLAP como um mecanismo de consulta sozinho não foi suficiente para nós.

Arquitetura 3.0 Iceberg + Trino

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

Introdução do data lake

Primeiro, voltamos 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 on-chain, pois os formatos de dados on-chain variam amplamente, desde dados brutos não estruturados até dados de abstração estruturados pelos quais a Footprint Analytics é bem conhecida. Esperávamos usar o data lake para resolver o problema de armazenamento de dados e, idealmente, também ofereceria suporte a mecanismos de computação convencionais, como Spark e Flink, para que não fosse difícil integrar-se a diferentes tipos de mecanismos de processamento à medida que o Footprint Analytics evolui .

O Iceberg se integra muito bem com Spark, Flink, Trino e outros motores computacionais, e podemos escolher a computação mais adequada para cada uma de nossas métricas. Por exemplo:

• Para aqueles que exigem lógica computacional complexa, o Spark será a escolha.

• Flink para computação em tempo real.

• Para tarefas ETL simples que podem ser executadas usando SQL, usamos o Trino.

  Motor de consulta

Com o Iceberg resolvendo os problemas de armazenamento e computação, tivemos que pensar em como escolher um mecanismo de consulta. Não há muitas opções disponíveis, as alternativas que consideramos foram

• Trino: mecanismo de consulta SQL

• Presto: mecanismo de consulta SQL

• Kyuubi: Spark SQL sem servidor
  A coisa mais importante que consideramos antes de nos aprofundarmos foi que o futuro mecanismo de consulta deveria ser compatível com nossa arquitetura atual.

• Para oferecer suporte ao Bigquery como fonte de dados

• Para dar suporte ao DBT, do qual dependemos para que muitas métricas sejam produzidas

• Para dar suporte à metabase de ferramentas de BI
  Com base no exposto, escolhemos o Trino, que tem um suporte muito bom para o Iceberg e a equipe foi tão receptiva que levantamos um bug, que foi corrigido no dia seguinte e lançado para a versão mais recente na semana seguinte. Esta foi definitivamente a melhor escolha para a equipe da Footprint, que também requer alta capacidade de resposta de implementação.

Teste de performance

Definido nosso rumo, fizemos um teste de performance da combinação Trino + Iceberg para ver se atendia nossas necessidades e para nossa surpresa, as consultas foram incrivelmente rápidas.

Sabendo que Presto + Hive tem sido o pior comparador por anos em todo o hype OLAP, a combinação de Trino + Iceberg nos surpreendeu completamente.

Aqui estão os resultados dos nossos testes.

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

  Uma tabela1 de 800 GB junta-se a outra tabela2 de 50 GB e faz cálculos de negócios complexos

• case2: use uma única tabela grande para fazer uma consulta distinta

  SQL de teste: selecione distinto (endereço) do grupo de tabelas por dia

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

Além disso, há outra surpresa, pois o Iceberg pode usar formatos de dados como Parquet, ORC, etc., que irão comprimir os dados e armazená-los. O armazenamento de tabelas do Iceberg ocupa apenas cerca de 1/5 do espaço de outros data warehouses. O tamanho de armazenamento da mesma tabela nos três bancos 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 atualização

Os relatórios de teste de desempenho nos deram desempenho suficiente para que nossa equipe levasse cerca de 2 meses para concluir a migração, e este é um diagrama de nossa arquitetura após a atualização.

• Múltiplos mecanismos de computador atendem às nossas diversas necessidades.

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

• O incrível desempenho do Trino + Iceberg nos permite abrir todos os dados Bronze (dados brutos) para nossos usuários.

  Resumo

Desde o seu lançamento em agosto de 2021, a equipe do Footprint Analytics concluiu três atualizações de arquitetura em menos de um ano e meio, graças ao seu desejo e determinação de trazer os benefícios da melhor tecnologia de banco de dados para seus usuários criptográficos e execução sólida na implementação e atualizando sua infraestrutura e arquitetura subjacentes.

A atualização da arquitetura Footprint Analytics 3.0 trouxe uma nova experiência para seus usuários, permitindo que usuários de diferentes origens obtenham insights em usos e aplicações mais diversos:

• Construído com a ferramenta Metabase BI, o Footprint facilita aos analistas o acesso a dados on-chain decodificados, exploram com total liberdade de escolha de ferramentas (sem código ou hardcord), consultam todo o histórico, examinam conjuntos de dados, para obter insights em nenhum tempo.

• Integre dados on-chain e off-chain para análise em web2 + web3;

• Ao construir/consultar métricas sobre a abstração de negócios da Footprint, os analistas ou desenvolvedores economizam tempo em 80% do trabalho repetitivo de processamento de dados e se concentram em métricas significativas, pesquisas e soluções de produtos com base em seus negócios.

• Experiência perfeita de Footprint Web para chamadas REST API, tudo baseado em SQL

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