Se você ainda não leu a primeira parte sobre os fundamentos da computação de alto desempenho (HPC), confira agora!
Princípios Fundamentais de um Data Lakehouse Soberano
O Data Lakehouse aberto: Uma PaaS simples para engenheiros
Embora o software tradicional de simulação de engenharia seja excelente para auxiliar engenheiros mecânicos na preparação, execução e análise de trabalhos de simulação, ele carece de design nativo para gerenciar fluxos de trabalho e pipelines de dados modernos de aprendizado de máquina (ML). Um data lakehouse aberto pode preencher essa lacuna, oferecendo aos engenheiros de P&D recursos robustos e contemporâneos em uma plataforma com a qual o departamento de TI provavelmente já está familiarizado.
Os principais casos de uso e benefícios de uma lakehouse de dados abertos são:
Arquivamento de dados econômico e controlado: Oferece armazenamento praticamente ilimitado e de baixo custo para arquivar anos de instantâneos de simulação (os conjuntos de dados gerados pelas sessões do solucionador). Esse armazenamento é gerenciado e controlado de forma consistente em todas as organizações ou equipes de engenharia e TI. De forma crítica, metadados e linhagem essenciais são preservados para cada conjunto de dados, transformando de arquivo opaco em um ativo confiável que pode ser facilmente reutilizado além de seu criador original.
Acesso simplificado a recursos computacionais: Os engenheiros podem implantar notebooks compartilhados e clusters Apache Spark ou Python Ray com facilidade e rapidez. Esses clusters frequentemente compartilham os mesmos recursos de GPU dedicados utilizados pelo cluster HPC principal.
Proteção por meio de padrões abertos: Um data lakehouse aberto prioriza padrões abertos como Apache Iceberg, Parquet e Python em detrimento de formatos de engenharia proprietários. Isso é crucial para salvaguardar a Propriedade Intelectual (PI) de uma empresa, garantindo que os dados de simulação permaneçam acessíveis e utilizáveis por qualquer ferramenta, agora e no futuro, independentemente da evolução da infraestrutura de TI da empresa ou da estratégia de fornecedores.
Uma experiência de PaaS semelhante à nuvem: data lakehouses estruturados como stacks de plataforma como serviço (PaaS) de autoatendimento e fáceis de usar simplificam o uso de ferramentas complexas de engenharia de dados e MLOps, fechando efetivamente a lacuna de conhecimento entre usuários com formações técnicas variadas e promovendo a troca produtiva de competências.
O risco da nuvem pública na proteção da propriedade intelectual de P&D
Embora um data lakehouse ofereça muitas vantagens, ele não é, por si só, uma solução completa para setores altamente regulados (como aeroespacial, defesa, energia e automotivo), onde a soberania é um requisito inegociável. Simplificando: nem todo data lakehouse pode ser implantado e operado em conformidade com os mandatos de soberania de dados, e depender da nuvem pública acarreta riscos significativos para manter o controle mais rigoroso sobre a propriedade intelectual.
Por exemplo, um único snapshot de um trabalho de dinâmica dos fluidos computacional (CFD), como o projeto de um novo motor, representa na prática o blueprint completo de seu desempenho e design industrial; esse conjunto de dados é o verdadeiro ativo mais valioso da empresa. Portanto é fundamental determinar quais capacidades não funcionais essenciais de um data lakehouse podem oferecer a garantia jurídica absoluta de soberania operacional necessária para armazenar esses ativos estratégicos. Isso nos leva diretamente ao cerne do debate entre residência e soberania.
Residência de dados vs. soberania de dados
A definição tradicional de soberania como a operação no país de origem de uma empresa é uma noção ultrapassada, um resquício da era pré-nuvem. Anteriormente, a infraestrutura de data centers era normalmente gerenciada por equipes locais, ficando por natureza sujeita à jurisdição e às obrigações legais da própria empresa. No entanto, o crescimento das ofertas comerciais de nuvem e a necessidade de os provedores garantirem objetivos de nível de serviço extremamente altos 24 horas por dia, 7 dias por semana, viabilizaram plenamente operações remotas e globais em nuvem. Esse avanço torna impossível garantir, pelo menos nas regiões padrão comerciais, a residência da equipe de gestão, rompendo assim o vínculo entre “residência de dados” e a verdadeira “soberania”.
Consequentemente, a arquitetura mais confiável para lidar e processar dados críticos de engenharia é um data lakehouse soberano: um data lakehouse aberto, nativamente híbrido e independente de nuvem.
Essa abordagem oferece a velocidade e a facilidade de uma experiência PaaS semelhante à da nuvem combinada com a conformidade integrada, possibilitando que uma empresa atenda a políticas nacionais ou de outras jurisdições que exijam a operação inteiramente dentro de um ambiente (e pessoal) soberano, privado e controlado.
Vigência |
Explicação |
Impacto nos Negócios |
Residência de Dados |
Os dados estão fisicamente armazenados em hardware dentro das fronteiras geopolíticas de um país específico. |
Atende aos requisitos básicos de conformidade local, não necessariamente relacionados à segurança, mas principalmente à latência entre os próprios dados e as soluções de TI que consomem esse conjunto de dados específico. |
Soberania Operacional |
Garante que as pessoas que gerenciam a infraestrutura de nuvem (Cloud Ops) e a estrutura legal que rege o provedor também sejam locais e estejam sob a governança soberana adequada. |
Impede o risco de solicitações de acesso por parte de governos estrangeiros que poderiam obrigar legalmente o provedor a entregar propriedade intelectual sensível sem o consentimento da empresa. |
Economia da IA: alcançando a previsibilidade de custos para modelos de IA
Além da segurança e da conformidade legal, uma arquitetura de data lake soberana oferece outra vantagem crucial: gerenciamento de custos previsível para a implementação de fluxos de trabalho de IA.
O modelo financeiro de execução de serviços de IA na nuvem pública é inerentemente variável e baseado no consumo, vinculando os custos diretamente às métricas de uso (como horas de GPU, tokens processados, volume operacional e dados analisados). À medida que mais equipes, projetos e aplicativos utilizam a infraestrutura em nuvem, os custos crescem exponencialmente. Esse modelo é particularmente difícil para cargas de alta demanda, como o treinamento de modelos complexos de IA generativa (GenAI) ou autoencoders de grande porte, que exigem uso dedicado, contínuo e massivo de GPUs, algo que muitas vezes é difícil de compartilhar de forma eficiente.
A transição para um data lakehouse soberano implantado em um data center privado ou de colocation com custo fixo leva a organização a um modelo de gastos previsível:
Estabelecendo investimento em ativos fixos: as organizações investem em infraestrutura fixa e compartilhável. Essa configuração possibilita que várias equipes e projetos utilizem os mesmos recursos, reduzindo efetivamente o custo marginal de iniciar novos experimentos de P&D a quase zero.
Eliminando "surpresas na fatura": essa arquitetura remove completamente qualquer risco financeiro associado a despesas inesperadas e massivas, como as causadas por inferência de alto volume, ciclos contínuos e iterativos de treinamento em P&D ou taxas proibitivas de transferência de dados comuns em nuvens públicas.
Para saber mais, continue lendo a Parte Três!
