Nota do editor: este é o segundo blog de uma série com três partes que examina o histórico interno da Google que levou ao Dataflow, como o Dataflow funciona como um serviço do Google Cloud e quais são suas similaridades e diferenças em relação a outros produtos do mercado. Confira a parte 1: Os bastidores do Dataflow: a história sobre a origem.
Na primeira postagem desta série, exploramos as origens do Dataflow dentro da Google e falamos sobre suas similaridades com as arquiteturas Lambda. Agora, vamos analisar mais detalhadamente alguns dos sistemas-chave que capacitam o Dataflow. Como mencionamos na primeira postagem, utilizamos algumas tecnologias que já havíamos criado para sistemas anteriores e também desenvolvemos algumas técnicas novas.
As origens de nosso sistema de timer remontam ao sistema MillWheel original, que dava aos usuários acesso direto à configuração de timers para acionar a lógica de processamento. Conceitualmente falando, eles são semelhantes a outros sistemas de agendamento, nos quais os usuários definem um número arbitrário de alarmes e o sistema é responsável por acionar esses alarmes no momento apropriado. Para fins de durabilidade, registramos esses timers em um armazenamento de apoio (como o banco de dados Cloud Bigtable) e armazenamos em cache, na memória, um subconjunto deles, de forma que todos os timers futuros fiquem na memória e o cache possa ser atualizado de forma assíncrona, sem leituras do armazenamento no caminho.
Uma das sutilezas dos timers está na necessidade de dar suporte a timers de eventos, que dependem da integridade dos dados dos cenários anteriores para serem acionados. Chamamos esses marcadores de conclusão de marcas d’água, e eles são gerenciados por meio de um componente separado, que se comunica com todos os nós responsáveis por processar um cenário específico a fim de determinar o valor atual da marca d’água. Esse componente de marca d’água, então, publica esses valores para todos os cálculos de downstream relevantes, que podem utilizar a marca d’água para acionar os timers de eventos. Para ajudar a ilustrar a importância disso, vamos considerar um caso de uso clássico da Internet das Coisas (IoT na sigla em inglês): uma linha de fabricação na qual os equipamentos são instrumentados com sensores. Esses sensores emitem uma grande quantidade de dados, e as marcas d’água associadas aos dados ajudam a agrupá-los por horário, ou talvez por rodada de fabricação, e a garantir que nenhum dado seja perdido em nossa análise simplesmente por ter chegado mais tarde ou fora da ordem.
Noções básicas sobre o gerenciamento de estados
O gerenciamento de estados no Dataflow se beneficia de vários conceitos similares ao de timers. O estado é registrado em um armazenamento durável e armazenado em cache para fins de velocidade e eficiência. Uma das coisas que aprendemos na experiência com o MillWheel foi a necessidade de fornecer abstrações úteis para que os usuários interajam com o estado, já que alguns aplicativos leem e gravam todo o estado armazenado de cada registro recebido, enquanto outros leem apenas um subconjunto ou anexam a uma lista que é acessada por completo apenas ocasionalmente. No Dataflow, trabalhamos duro para fornecer abstrações de estado relevantes que são integradas às estratégias certas de persistência e armazenamento em cache, para que o sistema seja eficiente e rápido sem a necessidade de configurações adicionais. Também descobrimos que é importante confirmar as modificações de estado em uma operação atômica com processamento de registros. Muitos outros sistemas adotam a abordagem de instruir os usuários a utilizarem um sistema de estados externo, mas é muito difícil fazer com que isso funcione corretamente. Voltando ao caso de uso da IoT que acabamos de mencionar, os recursos de gerenciamento de estados do Dataflow facilitariam (considerando-se quantidades triviais de código de usuário envolvidas) tarefas como agregar e contar as RPMs dos equipamentos, calcular a temperatura média de um sensor em um determinado período ou determinar o desvio médio de um processo de corte ou moldagem sem uma lógica complicada de tentativas para interação com um sistema secundário.
Um dos principais motivos da popularidade da arquitetura Lambda está relacionado aos desafios de se fornecer precisamente um único processamento em sistemas de processamento de streaming (veja mais detalhes nesta série de blogs). O Dataflow fornece precisamente um único processamento de registros ao armazenar uma impressão digital de cada registro que entra em determinado cenário e usa isso para desduplicar novas tentativas desse registro. É claro que uma estratégia simplista para isso seria criar um número ilimitado de impressões digitais a serem verificadas. Por isso, utilizamos o agregador de marcas d’água para determinar quando podemos fazer a coleta de lixo das impressões digitais dos registros que fizeram a travessia completa do sistema. Esse sistema também utiliza amplamente o armazenamento em cache, além de algumas outras otimizações, incluindo o uso de filtros de Bloom rotativos.
Um dos aspectos finais do Dataflow que abordaremos é a capacidade dele de dar suporte ao escalonamento automático dos recursos de canais. Ele é capaz de dar suporte ao escalonamento dinâmico (para cima e para baixo) dos canais de streaming e de lote porque pode realocar dinamicamente as atribuições de trabalho subjacentes que alimentam o sistema. No caso dos canais de streaming, isso corresponde a um conjunto de intervalos-chave para cada cenário de computação que podem ser dinamicamente deslocados, divididos e mesclados entre os workers para equilibrar a carga. O sistema responde a alterações de utilização aumentando ou reduzindo o número geral de nós disponíveis, além de poder escaloná-los de forma independente do armazenamento desagregado de timers e do estado. Voltando pela última vez ao nosso exemplo da IoT, com esses recursos de escalonamento automático, a adição de sensores ou o aumento da frequência de sinal deles não exigiria mais os longos ciclos de operações e provisionamento do passado.
Não deixe de conferir também o terceiro e último blog desta série, cujo objetivo é comparar e contrastar o Dataflow com algumas das outras tecnologias disponíveis no mercado.
Nenhum comentário :
Postar um comentário