Processamento de Big Data

Projetamos plataformas de dados em camadas, com interfaces explícitas entre elas. Uma camada de bronze captura os dados da fonte fielmente; uma camada de prata limpa, conforma e une; uma camada de ouro expõe as entidades e métricas consumidas por analistas, cientistas de dados e aplicações. Cada camada tem os seus próprios proprietários, as suas próprias expectativas de qualidade e as suas próprias regras de evolução. A disciplina é pouco glamorosa e a recompensa é substancial: um conjunto de dados que se comporta mal pode ser localizado, explicado e corrigido rapidamente.

Dentro de cada camada, usamos os formatos de armazenamento e os motores de consulta mais adequados à carga de trabalho. Os formatos Lakehouse — Apache Iceberg, Delta Lake, Apache Hudi — permitem-nos cada vez mais executar análises tipo warehouse em armazenamento com economia de lake, preservando as propriedades de engenharia (escritas ACID, viagem no tempo, evolução de esquema) que o trabalho de produção exige. Onde for necessária uma verdadeira performance de warehouse na camada de ouro, teremos todo o gosto em colocar os marts curados em Snowflake, BigQuery, Redshift ou Synapse.

O streaming é tratado como um modo de entrega de primeira classe, e não como uma reflexão tardia. Usamos Kafka, Kinesis ou Pub/Sub para transporte, Flink, Spark Structured Streaming ou Beam para processamento, e Iceberg ou Delta para armazenamento — com os mesmos controlos de qualidade e governança que os pipelines em lote. Arquiteturas estilo Lambda com caminhos de lote e stream paralelos são algo que agora ativamente evitamos; o custo operacional raramente se justifica.

• Design em camadas de bronze / prata / ouro
• Formatos de tabela abertos (Iceberg, Delta, Hudi)
• Ingestão focada em streaming quando compensa
• Armazenamento nativo da cloud com políticas de ciclo de vida
• Transformações reutilizáveis em dbt ou Spark
• Reverse ETL para sistemas operacionais

A qualidade não é um atributo de um conjunto de dados; é um atributo do pipeline que o produz. Instrumentamos cada transformação com expectativas explícitas — esquema, intervalos de valores, integridade referencial, frescura — e tratamos as violações como incidentes de primeira classe com os seus próprios manuais de operação. Ferramentas como Great Expectations, testes dbt e Monte Carlo encontram um lugar regular nas nossas implementações, mas a ferramenta importa menos do que o compromisso cultural de corrigir o produtor em vez de pedir desculpa ao consumidor.

Prestamos especial atenção à linhagem. Cada tabela importante tem um diagrama de linhagem gerado que mostra as fontes a montante, as transformações aplicadas e os consumidores a jusante. Quando um dashboard se move inesperadamente, o analista pode rastreá-lo até uma execução de trabalho específica, em vez de esperar que a equipa de dados investigue. Esta única capacidade remove uma parte significativa da carga de suporte ad-hoc das equipas de dados.

Os controlos de privacidade coexistem com os controlos de qualidade. Os dados pessoais são identificados na ingestão, classificados e protegidos de acordo com a política que os governa. O mascaramento, a tokenização e a agregação são aplicados à medida que os dados atravessam os limites das camadas, para que os dados brutos sensíveis nunca atinjam uma superfície de consulta que não precise deles. Esta é a forma arquitetónica da privacidade por design, e é muito mais barata do que adaptar os controlos posteriormente.

Pipelines de dados que parecem elegantes no desenvolvimento e frágeis na produção geralmente partilham a mesma causa raiz: nunca foram projetados para serem operados. Projetamos pipelines para serem idempotentes, reproduzíveis a partir de qualquer ponto e instrumentados de forma a facilitar o diagnóstico de incidentes. As falhas são esperadas e absorvidas; a recuperação não exige um engenheiro heróico às três da manhã.

A orquestração é centralizada — tipicamente em Airflow, Dagster ou Prefect — com convenções partilhadas para nomenclatura, retentativas, alertas e SLAs. Onde apropriado, adicionamos objetivos de nível de serviço ao nível do produto de dados, para que os compromissos de frescura e disponibilidade virados para o consumidor sejam explícitos e medidos, em vez de aspiracionais.

Tratamos o custo como uma propriedade da plataforma, não como algo notado no final do mês. A computação e o armazenamento são continuamente perfilados por trabalho, por equipa e por produto de dados, e a visibilidade resultante tende a autofinanciar-se num trimestre. Cortámos repetidamente os gastos com dados na cloud em vinte a quarenta por cento, sem sacrificar o desempenho, simplesmente substituindo padrões ineficientes que a equipa tinha herdado e nunca medido.

“Um pipeline que não pode ser operado é um passivo, não um ativo. A operabilidade faz parte do design, não um passo de polimento.”

Uma parte significativa do nosso trabalho envolve a transferência de organizações de plataformas ETL legadas — Informatica, Ab Initio, scripts shell escritos à mão, patrimónios SSIS desatualizados — para stacks modernos, nativos da cloud. Estas migrações são geralmente limitadas pelo facto de que a plataforma existente, por mais desajeitada que seja, está a operar o negócio; o tempo de inatividade e as regressões silenciosas não são aceitáveis.

Abordamos a migração legada como um programa de engenharia, não como um lift-and-shift. Catalogamos o que é realmente usado (tipicamente muito menos do que o que é construído), identificamos os consumidores, redesenhamos em vez de traduzir, e executamos os sistemas novos e antigos em paralelo até que a paridade virada para o consumidor tenha sido verificada independentemente. A tentação de reconstruir tudo é resistida; o objetivo é migrar valor, não linhas de código.

Quando aplicável, incorporamos a migração numa modernização mais ampla: introduzir uma camada semântica, consolidar a lógica duplicada, passar da segurança ao nível da linha para a segurança ao nível da coluna e desativar a inevitável acumulação de relatórios fantasma. O resultado raramente é mais barato de executar no primeiro dia, mas é consistentemente mais barato de alterar, que é onde a maioria dos gastos com dados realmente se encontra.

Os compromissos variam desde intervenções focadas — um caso de uso de streaming para entregar, um programa de custos para executar, uma migração para avaliar — até parcerias de plataforma de vários anos. Sentimo-nos igualmente confortáveis em integrar uma pequena equipa no seu grupo de plataforma e em ser responsáveis por uma entrega discreta de ponta a ponta, e adaptamos a estrutura do contrato (T&M, marcos de preço fixo, serviço gerido) ao modelo que melhor se adapta ao trabalho.

Não vendemos plataformas ou lugares, e não temos preferência entre fornecedores de cloud para além do que se adequa ao seu ambiente. Os engenheiros que implementamos são os engenheiros que conhece. Onde identificamos lacunas que não podemos preencher, dizemos e ajudamo-lo a procurar noutro lugar.