Ninguém registra um ticket dizendo “nossa arquitetura tem um problema de abstração”. Eles arquivam tickets dizendo que os dados estão errados, ausentes ou atrasados. Assim, a engenharia passa duas semanas perseguindo um problema de qualidade de dados que não existe, não corrige nada, e o mesmo ticket volta no trimestre seguinte com uma aparência um pouco diferente.
Éramos nós. A coisa mais útil que aprendi com todo o esforço é que o bug nunca esteve nos dados. Estava no que estávamos pedindo que os dados fossem.
Tínhamos uma instância native do MongoDB servindo como fonte dourada registrada para dados de referência corporativos. Códigos, classificações, pesquisas de identidade, os nada glamorosos dados compartilhados que sustentam silenciosamente a integração do cliente, relatórios regulatórios e uma dúzia de outras coisas que as pessoas só percebem quando quebram. Period bem conservado, confiável, a fonte única e genuína da verdade. A equipe proprietária estava orgulhosa disso. Por todas as medidas razoáveis, o sistema estava saudável.
E, no entanto, sempre que uma equipe de análise ou um grupo de produtos downstream precisava de algo, a experiência period péssima. Eles fizeram engenharia reversa do esquema operacional. Eles escreveram consultas únicas em JSON aninhado que entendiam apenas parcialmente. Eles rastrearam quem ainda carregava a memória institucional da estrutura da coleção, esperaram e repetiram todo o ritual três meses depois, quando a exigência mudou um centímetro.
O diagnóstico demorou mais do que deveria
Eu assisti isso acontecer por meses antes de dar certo. Os dados estavam bons. Estávamos pedindo a uma loja operacional que funcionasse como plataforma analítica, e foi ruim no segundo trabalho. Não por qualquer falha própria. Simplesmente nunca foi construído para isso.
As lojas operacionais otimizam a correção e o gerenciamento do ciclo de vida. As equipes de análise precisam de algo totalmente diferente: formas estáveis, campos realmente documentados, uma cadência de atualização que você possa prever e uma maneira de julgar se um conjunto de dados é adequado ao propósito sem fazer engenharia reversa do esquema de outra pessoa. Esses não são os mesmos requisitos, e combiná-los é exatamente como você acaba com um sistema que é tecnicamente perfeito e praticamente inútil. Tempo de atividade saudável, consumidores infelizes.
Portanto, paramos de pedir às pessoas que consumissem dados de referência diretamente do MongoDB. Começamos a tratar cada conjunto de dados como um produto de dados: algo com um proprietário nomeado, uma definição, portas de qualidade, acesso controlado e um caminho actual para publicação. O pipeline técnico, MongoDB através do Kafka Join nas camadas Touchdown, Bronze e Silver como tabelas Iceberg no S3, Athena no topo, publicação através do Information Market, seguiu essa decisão em vez de impulsioná-la. Vinte e um produtos de dados de referência foram enviados por esse caminho único.
Figura 1: O pipeline completo. MongoDB como fonte de ouro autorizada, eventos fluindo através do Kafka para as camadas Touchdown, Bronze e Silver como tabelas Iceberg no S3, Athena fornecendo a superfície de consulta e o Enterprise Information Market como o endpoint de publicação. O Airflow orquestra tudo; A UI do DPPS oferece visibilidade operacional.
Qual “produto de dados” realmente nos forçou a decidir
“Produto de dados” é uma daquelas frases que pode significar quase tudo, o que geralmente significa que não significa nada. Portanto, fizemos com que significasse algo específico e inegociável: um conjunto de dados não poderia ser publicado até que tivesse um proprietário nomeado, um dicionário de dados, metadados comerciais e técnicos, expectativas de auditoria documentadas, portas de qualidade e uma rota governada para o Market. A conformidade com todos os padrões ativos no momento da implantação period obrigatória, aplicada na publicação e não solicitada em uma reunião de revisão.
Esse enquadramento imediatamente trouxe à tona questões que deveriam ter sido respondidas anos antes. Qual é o limite actual deste produto? Quais atributos são importantes para os consumidores e quais são os encanamentos operacionais com os quais ninguém fora da equipe proprietária se importa? O que significa “atual” para este conjunto de dados e como um consumidor saberia se ele ficou obsoleto? Como alguém descobre isso sem preencher um tíquete e esperar que um humano indique o caminho S3 correto?
Nada disso foi uma sobrecarga de governança exibida para exibição. Respondendo a essas perguntas estava a arquitetura. Os conectores Kafka e as tabelas Iceberg foram quase a parte mais fácil em comparação.
As três decisões que moldaram todo o resto
A primeira decisão foi manter o MongoDB como fonte de ouro. Sem rasgar e substituir. A autoridade permaneceu onde pertencia, com a equipe que entendia o ciclo de vida dos dados e os mantinha corretamente há anos. O requisito comercial period explícito: nenhuma transformação da lógica empresarial, um mapeamento particular person da origem ao destino, preservação fiel em vez de enriquecimento. A tentação de coroar um sistema novinho em folha como a fonte da verdade espreita em todos os projectos de modernização, e é quase sempre errada. O MongoDB fez bem o seu trabalho. Estávamos construindo uma camada de entrega, não substituindo uma base, e confundindo os dois é como as boas migrações se transformam em desastres de dezoito meses.
A segunda period construir um modelo de entrega em vez de tolerar quatro. Antes deste trabalho, pelo menos quatro equipes haviam extraído de forma independente aproximadamente os mesmos dados de referência, cada um com sua própria lógica de atualização, sua própria leitura da semântica do campo e sua própria definição explicit de “atual”. A palavra diplomática para essa situação é “descentralizada”. A palavra honesta é caos. Eventos fluindo do MongoDB através do Kafka Join para o pipeline, Airflow orquestrando um lote mensal no dia 5 às 07:00 UTC sem dependência de dias úteis ou calendários de feriados, validação de esquema disparando antes que qualquer coisa tocasse no S3, substituíram todos os quatro impérios privados por um único caminho que qualquer um poderia raciocinar.
O custo desses quatro pipelines nunca foi a computação ou o armazenamento, o que period trivial. Period o imposto de reconciliação. Sempre que duas cópias discordavam, e isso acontecia, alguém mais experiente e ocupado tinha que decidir em qual delas acreditar. Multiplique uma investigação de meio dia por cada trimestre e cada equipe consumidora e você chegará a um hábito genuinamente caro que nunca apareceu em nenhuma linha do orçamento, porque estava escondido no trabalho comum de todos. Reunir quatro pipelines em um não apenas simplificou o diagrama. Ele excluiu toda uma categoria recorrente de argumento.
A terceira period tratar a publicação como um verdadeiro estágio de pipeline, em vez de uma reflexão tardia. Os dados que alcançaram a Prata foram publicados no Information Market com metadados, um índice de qualidade Kitemark, documentação e comportamento de assinatura já anexados. O consumo aconteceu exclusivamente pelo modelo de assinatura do Market, nunca entregando a alguém um caminho S3. Os consumidores podiam encontrar um produto, julgar se ele se encaixava e assiná-lo sem precisar saber sobre qual segmento perguntar ou em qual canal do Slack começar. A publicação significava que o produto seria lançado. Isso não significava que um arquivo apareceu silenciosamente no armazenamento e que alguém esperava que as pessoas certas notassem.
As coisas chatas acabaram se tornando as coisas difíceis
Fiquei esperando que os problemas difíceis aparecessem no próprio pipeline. Configuração do conector Kafka, manutenção da tabela Iceberg, ajuste da partição Athena, tudo isso precisava de atenção e tudo foi resolvido no devido tempo. Mas a lacuna entre “um pipeline que funciona” e “uma plataforma em que as pessoas confiam” veio das coisas que eu costumava descartar como tarefas domésticas. Convenções de nomenclatura. Padrões de coluna de auditoria. Modelos de documentação que alguém realmente abriria. Propriedade que period actual e não nominal.
A nomeação é um bom exemplo de como isso se torna nada glamoroso e decisivo. Um consumidor que pesquisa o catálogo precisa encontrar um conjunto de dados usando a terminologia padrão empresarial, e não a abreviação interna que fazia sentido para a equipe que o construiu. O mapeamento da estrutura de metadados para o padrão empresarial é um trabalho tedioso que não aparece em nenhuma demonstração. É também toda a diferença entre um catálogo que as pessoas podem navegar e uma lista de nomes de tabelas enigmáticos que apenas os autores entendem.
Aqui está a parte desconfortável que não gostei de abordar: dados corporativos compartilhados tendem a falhar socialmente antes de falharem tecnicamente. O conector Kafka ficará bem. O que corrói é a compreensão partilhada do que “autoritário” significa na prática, quer um determinado conjunto de dados seja actual ou uma cópia que alguém fez há dezoito meses e se esqueceu de descontinuar. Nenhuma quantidade de otimização do Iceberg atinge isso. Você corrige isso na camada onde os consumidores decidem se confiam em um conjunto de dados, que é a camada do produto, e em nenhum outro lugar.
Um exemplo concreto de como isso se torna social. No início, duas equipes discordaram sobre qual conjunto de dados de código de moeda estava correto. Ambos eram internamente consistentes. Ambos estavam “certos” em algum momento. A diferença se resumiu a uma atualização que uma equipe havia parado silenciosamente de executar um ano antes, e nenhuma das equipes conseguiu provar qual cópia refletia a fonte ao vivo, porque nada em nenhum dos conjuntos de dados registrava de onde ou quando ela veio. Não corrigimos isso com um conector melhor. Corrigimos isso tornando a proveniência uma coluna de primeira classe. Cada registro Silver agora carrega SOURCE_SYSTEM, JOB_RUN_ID, VALID_FROM e VALID_TO, então a pergunta “este é o actual e é atual?” tem uma resposta documentada em vez de um debate de corredor.
Armazenamento não é o produto
Observei equipes obterem dados no S3, declararem vitória no autoatendimento e depois passarem seis meses perplexas porque ninguém os estava usando. A resposta é quase sempre a mesma. “Os dados estão no S3” não é um produto. É um native. As pessoas precisam saber que os dados existem, descobrir o que eles significam, julgar se atendem ao seu propósito e descobrir quem contatar quando algo parecer errado. Um caminho não lhes dá nada disso.
O Market abordou isso mais do que qualquer componente particular person do pipeline. Ele transformou um conjunto disperso de caminhos S3 em um catálogo controlado de produtos subscritos, cada um com documentação, índice de qualidade e propriedade clara. Essa é a diferença entre entregar a alguém um endereço de depósito e entregar-lhe uma loja. E como a assinatura é a única rota autorizada para os dados, o catálogo continua sendo a única porta de entrada, em vez de uma opção entre vários canais secundários privados.
Verdade, transporte e consumo separados
Se eu tivesse cinco minutos com alguém iniciando este trabalho, gastaria tudo em uma ideia. Separe verdade, transporte e consumo e trate-os como três preocupações diferentes pertencentes a três partes diferentes do sistema. O MongoDB mantém a verdade e permanece confiável. O pipeline, Touchdown by Bronze to Silver, transfere essa verdade de maneira confiável e prova que ela chegou intacta com reconciliação de soma de verificação e verificações de contagem de registros entre camadas. A camada de produto, tabelas Silver, Athena e Market, tornam a verdade consumível por pessoas que não sabem e nunca deveriam precisar saber como o MongoDB organiza suas coleções.
Figura 2: Os mesmos dados, três planos separados. A verdade permanece na fonte dourada operacional; o transporte o movimenta e prova que chegou intacto; o consumo os expõe como produtos governados e subscritos. Separar as três preocupações, cada uma com o seu dono, é o que elimina o atrito entre produtores e consumidores.
Quando esses três estão genuinamente separados, uma enorme quantidade de atrito organizacional simplesmente evapora. Os produtores param de ser arrastados para reportagens advert hoc. Os consumidores param de fazer engenharia reversa na intenção operacional. A equipe de operações pode evoluir o esquema do MongoDB sem destruir seis trabalhos posteriores. E uma nova equipe que precisa de códigos de países ou classificações de moedas pode encontrá-los no Market, ler a documentação e terminar em uma tarde, em vez de um trimestre.
Os dados sempre estiveram bem. O que realmente construímos foi o limite que permitiu que todos parassem de discutir sobre isso.