Antecipando o lançamento de um novo fluxo à taxa Preparamos uma tradução de material interessante.
visão global
Falaremos sobre um padrão bastante popular pelo qual os aplicativos usam vários armazenamentos de dados, onde cada armazenamento é usado para seus próprios fins, por exemplo, para armazenar a forma canônica de dados (MySQL, etc.), fornecer recursos avançados de pesquisa (ElasticSearch, etc.), cache (Memcached, etc.) e outros. Normalmente, ao usar vários armazenamentos de dados, um deles atua como armazenamento primário e os outros como armazenamentos derivados. O único problema é como sincronizar esses armazenamentos de dados.
Analisamos vários padrões diferentes que tentavam resolver o problema de sincronização de múltiplas lojas, como gravações duplas, transações distribuídas, etc. No entanto, essas abordagens têm limitações significativas em termos de uso, confiabilidade e manutenção na vida real. Além da sincronização de dados, alguns aplicativos também precisam enriquecer os dados chamando serviços externos.
Delta foi desenvolvido para resolver esses problemas. Em última análise, a Delta fornece uma plataforma consistente e orientada a eventos para sincronização e enriquecimento de dados.
Soluções existentes
entrada dupla
Para manter dois armazenamentos de dados sincronizados, você pode usar gravação dupla, que grava em um armazenamento e, em seguida, grava no outro imediatamente. A primeira gravação pode ser repetida e a segunda pode ser abortada se a primeira falhar após o número de tentativas ter sido esgotado. No entanto, os dois armazenamentos de dados podem ficar fora de sincronia se a gravação no segundo armazenamento falhar. Este problema geralmente é resolvido criando um procedimento de recuperação que pode retransferir periodicamente os dados do primeiro armazenamento para o segundo, ou fazê-lo apenas se forem detectadas diferenças nos dados.
Problemas:
A execução de um procedimento de recuperação é uma tarefa específica que não pode ser reutilizada. Além disso, os dados entre locais de armazenamento permanecem fora de sincronia até que o procedimento de restauração seja realizado. A solução torna-se mais complexa se forem utilizados mais de dois armazenamentos de dados. Finalmente, o procedimento de restauração pode adicionar carga à fonte de dados original.
Alterar tabela de log
Quando ocorrem alterações em um conjunto de tabelas (como inserção, atualização e exclusão de um registro), os registros de alterações são adicionados à tabela de log como parte da mesma transação. Outro thread ou processo solicita constantemente eventos da tabela de log e os grava em um ou mais armazenamentos de dados, se necessário, removendo eventos da tabela de log após o registro ser confirmado por todos os armazenamentos.
Problemas:
Este padrão deve ser implementado como uma biblioteca e, idealmente, sem alterar o código da aplicação que o utiliza. Em um ambiente poliglota, uma implementação de tal biblioteca deve existir em qualquer linguagem necessária, mas é muito difícil garantir a consistência da funcionalidade e do comportamento entre as linguagens.
Outro problema reside na obtenção de alterações de esquema em sistemas que não suportam alterações de esquema transacional [1][2], como o MySQL. Portanto, o padrão de fazer uma alteração (por exemplo, uma alteração de esquema) e registrá-la transacionalmente na tabela de log de alterações nem sempre funcionará.
Transações Distribuídas
As transações distribuídas podem ser usadas para dividir uma transação entre vários armazenamentos de dados heterogêneos, de modo que a operação seja comprometida com todos os armazenamentos de dados usados ou não seja comprometida com nenhum deles.
Problemas:
As transações distribuídas são um grande problema para armazenamentos de dados heterogêneos. Pela sua natureza, só podem contar com o menor denominador comum dos sistemas envolvidos. Por exemplo, as transações XA bloqueiam a execução se o processo do aplicativo falhar durante a fase de preparação. Além disso, o XA não fornece detecção de deadlock nem suporta esquemas de controle de simultaneidade otimistas. Além disso, alguns sistemas como o ElasticSearch não suportam XA ou qualquer outro modelo de transação heterogêneo. Assim, garantir a atomicidade de gravação em diversas tecnologias de armazenamento de dados continua sendo uma tarefa muito desafiadora para as aplicações [3].
Delta
A Delta foi projetada para atender às limitações das soluções de sincronização de dados existentes e também permite o enriquecimento de dados em tempo real. Nosso objetivo era abstrair todas essas complexidades dos desenvolvedores de aplicativos para que eles pudessem se concentrar totalmente na implementação de funcionalidades de negócios. A seguir descreveremos "Movie Search", o caso de uso real do Delta da Netflix.
A Netflix usa amplamente uma arquitetura de microsserviços, e cada microsserviço normalmente atende um tipo de dados. As informações básicas sobre o filme estão contidas em um microsserviço chamado Movie Service, e os dados associados, como informações sobre produtores, atores, fornecedores e assim por diante, são gerenciados por vários outros microsserviços (nomeadamente Deal Service, Talent Service e Vendor Service).
Os usuários empresariais dos estúdios Netflix geralmente precisam pesquisar vários critérios de filmes, por isso é muito importante que eles possam pesquisar todos os dados relacionados a filmes.
Antes da Delta, a equipe de pesquisa de filmes precisava extrair dados de vários microsserviços antes de indexar os dados do filme. Além disso, a equipe teve que desenvolver um sistema que atualizasse periodicamente o índice de pesquisa, solicitando alterações de outros microsserviços, mesmo que não houvesse nenhuma alteração. Este sistema rapidamente se tornou complexo e difícil de manter.
Figura 1. Sistema de votação para Delta
Depois de usar o Delta, o sistema foi simplificado para um sistema orientado a eventos, conforme mostrado na figura a seguir. Os eventos CDC (Change-Data-Capture) são enviados para tópicos do Keystone Kafka usando Delta-Connector. Uma aplicação Delta construída usando o Delta Stream Processing Framework (baseado em Flink) recebe eventos CDC de um tópico, enriquece-os chamando outros microsserviços e, finalmente, passa os dados enriquecidos para um índice de pesquisa no Elasticsearch. Todo o processo ocorre quase em tempo real, ou seja, assim que as alterações são submetidas ao data warehouse, os índices de pesquisa são atualizados.
Figura 2. Pipeline de dados usando Delta
Nas seções a seguir, descreveremos a operação do Delta-Connector, que se conecta ao armazenamento e publica eventos CDC na camada de transporte, que é uma infraestrutura de transmissão de dados em tempo real que roteia eventos CDC para tópicos Kafka. E no final, falaremos sobre a estrutura de processamento de fluxo Delta, que os desenvolvedores de aplicativos podem usar para processamento de dados e lógica de enriquecimento.
CDC (Captura de Dados de Alteração)
Desenvolvemos um serviço CDC chamado Delta-Connector, que pode capturar alterações confirmadas do armazenamento de dados em tempo real e gravá-las em um fluxo. As alterações em tempo real são obtidas do log de transações e dos dumps de armazenamento. Dumps são usados porque os logs de transações geralmente não armazenam todo o histórico de alterações. As alterações normalmente são serializadas como eventos Delta, para que o destinatário não precise se preocupar com a origem da alteração.
Delta-Connector oferece suporte a vários recursos adicionais, como:
- Capacidade de gravar dados de saída personalizados além do Kafka.
- Capacidade de ativar dumps manuais a qualquer momento para todas as tabelas, uma tabela específica ou para chaves primárias específicas.
- Os dumps podem ser recuperados em partes, portanto não há necessidade de começar tudo de novo em caso de falha.
- Não há necessidade de colocar bloqueios nas tabelas, o que é muito importante para garantir que o tráfego de gravação do banco de dados nunca seja bloqueado pelo nosso serviço.
- Alta disponibilidade devido a instâncias redundantes em zonas de disponibilidade da AWS.
Atualmente oferecemos suporte a MySQL e Postgres, incluindo implantações em AWS RDS e Aurora. Também oferecemos suporte a Cassandra (multimestre). Você pode descobrir mais detalhes sobre o Delta-Connector aqui .
Kafka e a camada de transporte
A camada de transporte de eventos da Delta é construída no serviço de mensagens da plataforma .
Historicamente, a postagem na Netflix foi otimizada para acessibilidade e não para longevidade (veja abaixo). ). A compensação foi a potencial inconsistência dos dados do corretor em vários cenários de edge. Por exemplo, eleição de líder impuro é responsável pela possibilidade de o destinatário ter eventos duplicados ou perdidos.
Com a Delta, queríamos garantias de durabilidade mais fortes para garantir a entrega de eventos CDC em lojas derivadas. Para este propósito, propusemos um cluster Kafka especialmente projetado como um objeto de primeira classe. Você pode ver algumas configurações do corretor na tabela abaixo:
Em clusters Keystone Kafka, eleição de líder impuro geralmente incluído para garantir a acessibilidade do editor. Isto poderá resultar na perda de mensagens se uma réplica não sincronizada for eleita como líder. Para um novo cluster Kafka de alta disponibilidade, a opção eleição de líder impuro desligado para evitar perda de mensagens.
Também aumentamos fator de replicação de 2 a 3 e réplicas insincronizadas mínimas 1 a 2. Os editores que gravam neste cluster exigem confirmações de todos os outros, garantindo que 2 em cada 3 réplicas tenham as mensagens mais atuais enviadas pelo editor.
Quando uma instância do broker termina, uma nova instância substitui a antiga. No entanto, o novo corretor precisará acompanhar as réplicas não sincronizadas, o que pode levar várias horas. Para reduzir o tempo de recuperação neste cenário, começamos a usar armazenamento de dados em bloco (Amazon Elastic Block Store) em vez de discos de agente local. Quando uma nova instância substitui uma instância do agente encerrada, ela anexa o volume EBS que a instância encerrada tinha e começa a acompanhar as novas mensagens. Esse processo reduz o tempo de liberação do backlog de horas para minutos porque a nova instância não precisa mais ser replicada a partir de um estado vazio. No geral, os ciclos de vida separados do armazenamento e do corretor reduzem significativamente o impacto da troca de corretor.
Para aumentar ainda mais a garantia de entrega de dados, utilizamos para detectar qualquer perda de mensagem sob condições extremas (por exemplo, dessincronização do relógio no líder da partição).
Estrutura de processamento de fluxo
A camada de processamento da Delta é construída sobre a plataforma Netflix SPaaS, que fornece integração do Apache Flink com o ecossistema Netflix. A plataforma fornece uma interface de usuário que gerencia a implantação de trabalhos Flink e a orquestração de clusters Flink em nossa plataforma de gerenciamento de contêineres Titus. A interface também gerencia configurações de trabalhos e permite que os usuários façam alterações de configuração dinamicamente sem precisar recompilar trabalhos do Flink.
Delta fornece uma estrutura de processamento de fluxo baseada em Flink e SPaaS que usa baseado em anotação DSL (Domain Specific Language) para abstrair detalhes técnicos. Por exemplo, para definir a etapa em que os eventos serão enriquecidos pela chamada de serviços externos, os usuários precisam escrever a seguinte DSL, e o framework criará um modelo baseado nela, que será executado pelo Flink.
Figura 3. Exemplo de enriquecimento em DSL em Delta
A estrutura de processamento não apenas reduz a curva de aprendizado, mas também fornece recursos comuns de processamento de fluxo, como desduplicação, esquematização e flexibilidade e resiliência para resolver problemas operacionais comuns.
Delta Stream Processing Framework consiste em dois módulos principais, o módulo DSL e API e o módulo Runtime. O módulo DSL e API fornece APIs DSL e UDF (Função Definida pelo Usuário) para que os usuários possam escrever sua própria lógica de processamento (como filtragem ou transformações). O módulo Runtime fornece uma implementação de um analisador DSL que constrói uma representação interna das etapas de processamento em modelos DAG. O componente Execução interpreta modelos DAG para inicializar as instruções reais do Flink e, por fim, executar o aplicativo Flink. A arquitetura da estrutura é ilustrada na figura a seguir.
Figura 4. Arquitetura do Delta Stream Processing Framework
Esta abordagem tem várias vantagens:
- Os usuários podem se concentrar em sua lógica de negócios sem precisar se aprofundar nas especificidades do Flink ou na estrutura do SPaaS.
- A otimização pode ser feita de forma transparente para os usuários e os erros podem ser corrigidos sem exigir quaisquer alterações no código do usuário (UDF).
- A experiência do aplicativo Delta é simplificada para os usuários porque a plataforma oferece flexibilidade e resiliência prontas para uso e coleta uma variedade de métricas detalhadas que podem ser usadas para alertas.
Uso de produção
A Delta está em produção há mais de um ano e desempenha um papel fundamental em muitos aplicativos do Netflix Studio. Ela ajudou equipes a implementar casos de uso como indexação de pesquisa, armazenamento de dados e fluxos de trabalho orientados a eventos. Abaixo está uma visão geral da arquitetura de alto nível da plataforma Delta.
Figura 5. Arquitetura de alto nível da Delta.
Agradecimentos
Gostaríamos de agradecer às seguintes pessoas que estiveram envolvidas na criação e desenvolvimento da Delta na Netflix: Allen Wang, Charles Zhao, Jaebin Yoon, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang e Zhenzhong Xu.
fontes
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Processamento de eventos online. Comum. ACM 62(5): 43–49 (2019). DOI:
: “Ferramenta de criação de dados para armazenamento Amazon Redshift.”
Fonte: habr.com