Respostas>Saiba mais sobre o streaming de dados em blockchain>O que é o streaming de dados em blockchain?
O que é a transmissão de dados em blockchain?
// Tags
transmissão de dados da blockchaindados da blockchain em tempo real
Resumo: O streaming de dados da blockchain é uma abordagem baseada em push para aceder a dados da blockchain, em que novos blocos, transações e eventos são enviados automaticamente para a sua aplicação ou base de dados à medida que são produzidos na cadeia. Em vez de a sua aplicação perguntar repetidamente ao nó «há alguma novidade?» (polling), um serviço de streaming envia-lhe os dados assim que estes ficam disponíveis. O streaming reduz a latência, elimina a perda de eventos, simplifica a sua arquitetura de backend e escala de forma muito mais eficiente do que os padrões tradicionais de pedido-resposta.
A Explicação Simples
Existem duas formas fundamentais de obter dados de qualquer sistema: pode solicitá-los (pull) ou estes podem ser-lhe enviados (push). Durante a maior parte da história da blockchain, os programadores têm utilizado o modelo «pull». A sua aplicação envia um pedido RPC a um nó, o nó devolve uma resposta e a sua aplicação decide quando deve fazer um novo pedido. Este é o padrão de «polling». É simples de implementar, mas ineficiente, especialmente quando a sua aplicação precisa de se manter sincronizada com o estado mais recente da blockchain.
O streaming inverte este modelo. Em vez de a sua aplicação perguntar «o que aconteceu no último bloco?» milhares de vezes por dia, basta estabelecer um canal de dados uma única vez e o serviço de streaming envia os dados de cada novo bloco para a sua aplicação ou base de dados à medida que são produzidos. A sua aplicação passa a ser um consumidor de um fluxo contínuo de dados, em vez de um solicitante de instantâneos de dados discretos.
A analogia é a diferença entre atualizar um site de notícias a cada cinco minutos e subscrever uma notificação push que o alerta assim que uma notícia é publicada. Ambas as opções acabam por fornecer a mesma informação, mas o modelo de notificação push é mais rápido, menos dispendioso e mais fiável.
Como funciona a transmissão de dados em blockchain
Um serviço de streaming situa-se entre os nós da blockchain e a sua aplicação ou infraestrutura de dados. No que diz respeito à ingestão, o serviço liga-se aos nós nas redes suportadas e processa cada novo bloco à medida que este é finalizado. Extrai os dados brutos do bloco, incluindo cabeçalhos, transações, recibos de transação (com registos de eventos) e, opcionalmente, registos de execução. Estes dados brutos constituem o registo completo de tudo o que aconteceu nesse bloco.
No que diz respeito ao processamento, o serviço de streaming aplica quaisquer filtros ou transformações que tenha configurado. Talvez esteja interessado apenas nos eventos de transferência ERC-20 provenientes de um conjunto específico de contratos. Um filtro escrito em JavaScript ou noutra linguagem suportada é aplicado aos dados de cada bloco e deixa passar apenas os registos que correspondem aos seus critérios. Esta filtragem do lado do servidor é fundamental para a eficiência, pois significa que o seu destino recebe e armazena apenas os dados de que realmente necessita, e não o bloco na íntegra.
No que diz respeito à entrega, os dados filtrados são enviados para o destino que configurou. Este pode ser um URL de webhook que a sua aplicação monitoriza, uma base de dados PostgreSQL, um data warehouse Snowflake, um bucket do Amazon S3, o Azure Blob Storage ou outro ponto de extremidade suportado. O serviço de streaming trata das garantias de entrega, incluindo novas tentativas em caso de falha, deduplicação e ordenação correta, para que o seu destino receba um fluxo sequencial e sem lacunas de dados da blockchain.
Streaming vs. abordagens ETL tradicionais
Os pipelines tradicionais de ETL (Extract, Transform, Load) para blockchain exigem que os programadores criem e mantenham uma infraestrutura significativa. Uma configuração ETL personalizada típica envolve um processo de sondagem que chama pontos finais RPC de forma programada para obter novos blocos, uma camada de processamento que descodifica e transforma os dados brutos, um gravador de base de dados que insere registos, um gestor de erros que gere novas tentativas e falhas, um detetor de reorganização que identifica e reverte dados de bifurcações abandonadas e um sistema de monitorização para alertar quando algum destes componentes falha. Cada elemento acrescenta complexidade e cada um é um potencial ponto de falha.
Os serviços de streaming consolidam tudo isto num único fluxo gerido. A extração, a filtragem, a transformação, a entrega, a lógica de repetição de tentativas, a ordenação e o tratamento de reorganizações ocorrem todos na infraestrutura do fornecedor. A sua responsabilidade limita-se a configurar quais os dados que pretende, para onde pretende que sejam enviados e como pretende que sejam processados. Isto reduz drasticamente o esforço de engenharia necessário para construir e manter a infraestrutura de dados da blockchain.
A diferença de desempenho também é substancial. Um pipeline baseado em polling tem, por natureza, uma latência igual ao intervalo de polling. Se o seu worker verificar a existência de novos blocos a cada 5 segundos, poderá ficar até 5 segundos atrasado em relação à ponta da cadeia, mesmo quando tudo estiver a funcionar na perfeição. Os polling perdidos (devido a erros, limites de taxa ou reinícios do worker) aumentam esta diferença. O streaming elimina a latência da sondagem, uma vez que os dados são enviados assim que estão disponíveis. Em cadeias de elevado débito, onde os blocos são produzidos a cada poucas centenas de milissegundos, esta diferença é significativa para aplicações sensíveis à latência.
Principais características da transmissão em direto de produção
Várias características distinguem o streaming de nível de produção de uma simples subscrição WebSocket. A entrega garantida assegura que os dados de cada bloco cheguem ao seu destino exatamente uma vez, mesmo que a ligação seja interrompida temporariamente ou que o seu destino sofra uma breve interrupção de serviço. O serviço de streaming armazena em buffer e repete as tentativas até que a entrega seja confirmada, para que nunca haja lacunas nos seus dados.
A entrega por ordem de finalidade significa que os dados chegam na ordem que a blockchain considera canónica. Em cadeias com tempos de finalidade variáveis, o serviço de streaming aguarda até que um bloco esteja suficientemente confirmado antes de o entregar, impedindo que a sua aplicação processe dados que possam vir a ser invalidados por uma reorganização. Quando ocorrem reorganizações, o serviço deteta a bifurcação, identifica quais os blocos que já não são canónicos e envia cargas de correção para que o seu destino possa atualizar-se em conformidade.
O preenchimento histórico permite-lhe utilizar o mesmo pipeline de streaming para dados passados, e não apenas para novos blocos. Em vez de criar um processo ETL separado para dados históricos e outro diferente para dados em tempo real, configura-se um único fluxo com um bloco inicial no passado e deixa-se que este avance ao longo do histórico, passando depois, de forma contínua, para o tempo real assim que alcançar a ponta da cadeia. Este pipeline unificado simplifica a sua arquitetura e garante a consistência entre os dados históricos e os dados em tempo real.
A filtragem e a transformação do lado do servidor reduzem o volume de dados que chega ao seu destino, diminuindo os custos de largura de banda, os custos de armazenamento e a sobrecarga de processamento. Os filtros podem ser aplicados com base em endereços, assinaturas de eventos, seletores de funções, valores de transações ou qualquer outra propriedade dos dados em bloco. As transformações podem reformular cargas úteis, descodificar dados codificados em ABI, calcular valores derivados e gerar registos num esquema que corresponda às tabelas da sua base de dados.
Como o Quicknode Streams fornece transmissão de dados em blockchain
O Quicknode Streams é um serviço de streaming de dados de blockchain e ETL especificamente concebido para fornecer dados em tempo real e históricos em mais de 80 cadeias, com filtragem e transformação integradas e entrega garantida. O Streams suporta vários tipos de conjuntos de dados (blocos, transações, recibos, registos de eventos, rastreios) e vários destinos (webhooks, PostgreSQL, Snowflake, Amazon S3, Azure Storage e outros).
O Streams processa os dados por ordem de finalidade com garantias de entrega «exatamente uma vez», lida automaticamente com reorganizações da cadeia através do envio de cargas de correção e suporta o agrupamento em lotes e a compressão configuráveis para um débito ideal durante o preenchimento retroativo de dados históricos. Os filtros JavaScript são executados na infraestrutura da Quicknode, permitindo-lhe descodificar eventos, corresponder padrões, consultar armazenamentos externos de chave-valor e moldar as cargas de saída antes de os dados chegarem ao seu destino. Os modelos de preenchimento de dados com um clique fornecem pipelines pré-configurados para conjuntos de dados comuns em mais de 20 cadeias, com estimativas transparentes de custos e tempo de conclusão apresentadas antes de iniciar.
Para fluxos de trabalho ainda mais sofisticados, o Streams integra-se com o Quicknode Functions para permitir a automatização sem servidor com base em dados em fluxo contínuo. O Functions pode enriquecer registos com dados adicionais na cadeia de blocos, chamar APIs externas, acionar notificações ou executar lógica de negócio arbitrária em resposta a eventos em fluxo contínuo. Em conjunto, o Streams e o Functions proporcionam uma plataforma completa de dados de blockchain que substitui a infraestrutura ETL personalizada por uma solução gerida e escalável.
Qual é a diferença entre streaming e polling?
O polling e o streaming são as duas formas através das quais uma aplicação se mantém a par da atividade na cadeia de blocos, situando-se em extremos opostos de um espectro. O polling funciona com base no princípio «pull»: a sua aplicação pergunta repetidamente a um nó se existem novos dados. O streaming funciona com base no princípio «push»: um serviço envia-lhe novos dados no momento em que estes ficam disponíveis. A tabela abaixo compara ambas as abordagens nas dimensões mais importantes na hora de escolher uma delas.
Dimensão
Sondagem
Streaming
Fluxo de dados
A aplicação executa-se de acordo com um horário
O serviço envia as atualizações à medida que os dados são produzidos
Latência
Limitado pelo intervalo de sondagem
Quase em tempo real, sem atraso de intervalo
Risco de dados em falta
Lacunas caso uma sondagem falhe ou seja ignorada
Entrega garantida e sem interrupções
Gestão de reorganizações
És tu que o constróis
Incorporadas através de cargas úteis de correção
Carga operacional
És tu que geres e dimensionas os trabalhadores
Gerido pelo prestador
Para uma comparação mais aprofundada dos dois modelos de transmissão e para saber em que situações cada um deles é mais adequado, consulte «polling vs streaming».
Quais são os casos de utilização mais comuns da transmissão de dados em blockchain?
O streaming adapta-se a qualquer carga de trabalho que tenha de reagir rapidamente à atividade na cadeia de blocos ou manter uma base de dados continuamente sincronizada. Exemplos comuns incluem o acompanhamento em tempo real de carteiras e carteiras de investimentos, painéis de controlo de DeFi, bots de negociação e liquidação, monitorização da emissão e venda de NFT, alertas de fraude e conformidade, e armazéns de análise que importam todos os blocos. Cada um destes beneficia de baixa latência e de uma transmissão sem interrupções, em vez de instantâneos periódicos. Para um catálogo mais completo de padrões, consulte os casos de utilização do streaming de blockchain.
Como é que o streaming lida com dados em tempo real em comparação com dados históricos?
Um pipeline de streaming robusto trata os dados em tempo real e os dados históricos como uma única linha temporal contínua, em vez de dois sistemas separados. É possível iniciar um fluxo a partir de um bloco muito distante no passado, deixá-lo preencher retroativamente ao longo do histórico e, em seguida, fazer uma transição suave para os blocos em tempo real assim que alcançar a ponta da cadeia. Isto evita a necessidade de manter dois pipelines com dois percursos de código diferentes. Para compreender as vantagens e desvantagens entre dados recentes e arquivados, consulte «Dados de blockchain em tempo real vs. dados históricos» e, para estratégias de preenchimento retroativo, consulte «Como aceder a dados históricos da blockchain».
Como é que o streaming lida com as reorganizações da cadeia?
As reorganizações são a parte mais difícil da utilização de dados em tempo real da blockchain, porque um bloco que a sua aplicação já tenha processado pode ser substituído por um bloco concorrente. Os serviços de streaming em produção lidam com esta situação fornecendo os dados por ordem de finalidade e, quando ocorre uma reorganização, enviando cargas de correção que indicam ao destino quais os blocos que já não são canónicos, para que este possa reverter os registos afetados. Isto elimina uma das partes mais propensas a erros nos pipelines personalizados. Saiba mais sobre o que é uma reorganização da blockchain.
Em que é que o streaming difere da indexação?
O streaming e a indexação resolvem problemas relacionados, mas distintos. O streaming diz respeito à entrega: fazer com que os dados da cadeia de blocos cheguem ao seu destino à medida que são gerados. A indexação diz respeito à organização: estruturar esses dados numa base de dados pesquisável para que se possam executar consultas rápidas de dados históricos e agregados. Muitas equipas utilizam o streaming para alimentar um índice e, em seguida, consultam esse índice para fins de análise. Consulte os artigos «O que é a indexação da cadeia de blocos» e «Como consultar dados da cadeia de blocos» para perceber como as peças se encaixam.
Perguntas frequentes
A transmissão de dados em blockchain é o mesmo que uma subscrição WebSocket?
Não é bem assim. Uma subscrição WebSocket é uma ligação de baixo nível que envia eventos enquanto o socket permanece aberto, mas não oferece garantias de entrega e interrompe-se se a ligação for interrompida. O streaming em produção acrescenta, a esse modelo básico de envio, a entrega «exatamente uma vez», a ordenação definitiva, correções de reorganização, filtragem do lado do servidor e preenchimento histórico.
O streaming garante que não vou perder nenhum bloco?
Sim, com um serviço de produção. A entrega garantida significa que o fornecedor armazena os dados em buffer e volta a tentar até que os dados de cada bloco sejam confirmados no seu destino, para que receba um fluxo contínuo, mesmo que o seu terminal sofra uma breve interrupção. Os serviços de eventos baseados em push, como os Webhooks do Quicknode, aplicam os mesmos princípios de fiabilidade às notificações de eventos.
Posso filtrar os dados em fluxo antes de chegarem ao meu destino?
Sim. A filtragem do lado do servidor permite filtrar com base em endereços, assinaturas de eventos, seletores de funções, valores ou qualquer outra propriedade do bloco, para que apenas os registos que lhe interessam sejam entregues. Isto reduz os custos de largura de banda, armazenamento e processamento, uma vez que nunca recebe os dados de que não necessita.
O streaming pode substituir um pipeline ETL personalizado?
Para a maioria das equipas, sim. Um serviço de streaming gerido consolida a extração, a filtragem, a transformação, a entrega, as tentativas de reenvio, a ordenação e o tratamento de reorganizações num único pipeline, eliminando as inúmeras componentes móveis de uma pilha ETL desenvolvida internamente. Basta configurar quais os dados que pretende e para onde devem ser enviados, e o fornecedor trata do resto.
Para que destinos podem ser transmitidos os dados em streaming?
Os destinos mais comuns incluem URLs de webhooks, PostgreSQL, Snowflake, Amazon S3 e Azure Blob Storage, entre outros. Isto permite-lhe integrar dados em fluxo diretamente no backend da sua aplicação, no seu armazém de dados ou no seu armazenamento de objetos, sem ter de criar conectores personalizados para cada um deles.
