Tulip: Modernizando a plataforma de dados da Meta

As migrações são difíceis. Além disso, eles se tornam muito mais difíceis no Meta por causa de:

Antes de entrarmos nos detalhes da história da migração, gostaríamos de dar um passo atrás e tentar explicar a motivação e a lógica desta migração.

Com o tempo, a plataforma de dados assumiu várias formas à medida que as necessidades da empresa cresciam. O que era uma plataforma de dados modesta no início tornou-se uma plataforma na escala de exabytes. Alguns sistemas que servem uma escala menor começaram a mostrar sinais de serem insuficientes para as crescentes exigências que lhes eram impostas. Mais notavelmente, encontramos alguns problemas concretos de confiabilidade e eficiência relacionados à (des)serialização de dados, o que nos fez repensar a maneira como registramos os dados e revisitar as ideias dos primeiros princípios para resolver essas questões urgentes.

O Logger está no centro da plataforma de dados. O sistema é usado para registrar dados analíticos e operacionais no Scuba, Hive e pipelines de processamento de fluxo via Scribe. Cada equipe de produto e plataforma de dados interage com o registro. O formato de dados para registro em log era Hive Text Delimited ou JSON, por motivos herdados. As limitações desses formatos estão descritas em nosso artigo anterior sobre Tulip.

Para resolver essas limitações, o formato de serialização Tulip foi desenvolvido para substituir os formatos legados de serialização específicos do destino.

Os gráficos abaixo retratam graficamente a jornada de migração para a conversão do formato de serialização para Tulip para mostrar o progresso em vários estágios e marcos.

Podemos ver que, embora o número de esquemas de log tenha permanecido praticamente o mesmo (ou tenha apresentado algum crescimento orgânico), os bytes registrados tiveram uma diminuição significativa devido à mudança no formato de serialização. Os detalhes relacionados à economia de bytes específicos do formato são tabulados na seção abaixo.

Nota: Os números no Gráfico 2 são extrapolados (para o tráfego geral) com base nas economias reais observadas para os cinco maiores esquemas de registro (em volume).

Gostaríamos de apresentar a nossa jornada de migração como duas fases distintas com perspectivas próprias.

Projetar o sistema tendo a migração em mente ajuda a torná-la muito mais fácil. As soluções de engenharia a seguir foram desenvolvidas para garantir que a equipe estivesse equipada com as ferramentas e o suporte de infraestrutura necessários para mudar o formato do fio com segurança e para depurar problemas que possam surgir durante a fase de migração de maneira escalonável.

As soluções caíram aproximadamente nos seguintes grupos:

Desafio: Como facilitar a migração e reduzir os riscos ao não exigir que o(s) produtor(es) e consumidor(es) de dados alternem atomicamente os formatos de serialização?

Solução: ao inverter um único esquema de registro para usar o novo protocolo de serialização Tulip para gravar cargas úteis, era necessário oferecer suporte a cargas úteis de modo misto em um único fluxo de escriba, pois seria impossível alternar “atomicamente” todos os produtores de dados para usar o novo formato . Isso também permitiu que a equipe limitasse a taxa de implementação do novo formato de serialização.

O formato de fio de modo misto foi importante para apoiar o conceito de shadow loggers, que foram amplamente usados ​​para testes de aceitação ponta a ponta antes de uma implementação em larga escala.

O principal desafio para o formato de ligação de modo misto era não ser capaz de alterar a serialização existente de cargas úteis no formato Hive Text ou JSON. Para contornar essa limitação, cada carga serializada do Tulip é prefixada com a sequência de 2 bytes 0x80 0x00, que é uma sequência utf-8 inválida.

Desafio: Em alguns sistemas, o formato de serialização Hive Text (ou JSON) se infiltrou no código do aplicativo que acabou contando com esse formato para consumir cargas úteis. Isso é resultado da ruptura dos consumidores com a abstração do formato de serialização.

Solução: Duas soluções abordaram esse desafio.

Reader (contraparte do logger para desserialização de dados)

Reader é uma biblioteca que converte uma carga serializada em um objeto estruturado. O leitor (como o logger) vem em dois sabores, (a) código gerado e (b) genérico. Um objeto leitor consome dados em qualquer um dos três formatos – Tulip, Hive Text ou JSON – e produz um objeto estruturado. Isso permitiu que a equipe transferisse os consumidores para usar leitores antes do início da migração. O código do aplicativo teve que ser atualizado para consumir esse objeto estruturado em vez de uma linha serializada bruta. Isso abstraiu o formato da ligação dos consumidores dos dados.