Object storage para data lake e IA

⏱ 9 min de leitura

Por trás de todo data lake e de todo pipeline de inteligência artificial existe uma camada fundamental que costuma receber menos atenção do que as GPUs e os modelos: o armazenamento dos dados. E essa camada, na arquitetura moderna, é quase sempre object storage com a API S3. Entender por que isso aconteceu é entender como os dados que alimentam a IA são guardados e acessados.

Este artigo explica por que o object storage S3 virou a camada de armazenamento dos data lakes e pipelines de IA, o conceito de separação entre storage e compute, o papel dos formatos e do data lakehouse, e por que o acesso aos dados, e não só a GPU, define a performance.

Object storage como camada de armazenamento

Object storage para data lake e IA O object storage com a API S3 se tornou a camada de armazenamento padrão dos data lakes modernos e dos pipelines de inteligência artificial. A razão central é a separação entre storage e compute: em vez de acoplar dados e processamento na mesma máquina, o object storage guarda os dados de forma centralizada e escalável, enquanto clusters de processamento (Spark, frameworks de ML) e GPUs acessam esses dados sob demanda, permitindo escalar armazenamento e processamento de forma independente. Sobre o object storage, surgiu o conceito de data lakehouse, com camadas como Delta Lake, Apache Iceberg e Apache Hudi, que adicionam transações e estrutura analítica, e os dados são guardados em formatos colunares como Parquet e ORC, otimizados para consultas. Para IA, o object storage é onde os datasets de treinamento vivem: frameworks como TensorFlow, PyTorch e Spark leem dados diretamente do S3. Um ponto crítico é que o gargalo do machine learning muitas vezes não é a GPU, mas o throughput de acesso aos dados. Para empresas brasileiras, a soberania dos dados de treino importa por LGPD e proteção de propriedade intelectual, o que torna object storage nacional compatível com S3 uma base estratégica para IA.

Um data lake é um repositório centralizado que armazena grandes volumes de dados estruturados, semiestruturados e não estruturados, no formato bruto, para análise e treinamento de modelos. Mas o data lake é um conceito, uma arquitetura. A pergunta prática é: em qual tecnologia de armazenamento esses dados realmente ficam? A resposta moderna é object storage. Para entender o conceito de data lake em profundidade, vale o conteúdo sobre data lake: tudo o que você precisa saber.

O object storage virou a fundação de storage do data lake porque oferece exatamente o que um data lake precisa: escala praticamente ilimitada para volumes na casa de terabytes ou petabytes, custo por GB baixo para reter tudo, capacidade de guardar qualquer tipo de dado (de logs a imagens a Parquet) e acesso via API S3 universal, que todas as ferramentas de dados entendem. O data lake é a ideia; o object storage S3 é onde ela se materializa.

A separação entre storage e compute

O conceito mais importante para entender por que object storage venceu no mundo de dados e IA é a separação entre storage e compute (armazenamento e processamento).

Nas arquiteturas antigas, dados e processamento ficavam acoplados: o mesmo servidor que guardava os dados os processava. Isso criava um problema, porque você era obrigado a escalar os dois juntos, mesmo quando precisava só de um. Mais dados exigiam mais máquinas (com CPU que talvez ficasse ociosa); mais processamento exigia mover dados.

Com object storage, os dois se desacoplam. Os dados ficam centralizados no object storage, e o processamento (clusters Spark, frameworks de ML, motores de query, GPUs) acessa esses dados quando precisa, escalando de forma independente. Você pode ter petabytes parados no object storage barato e subir um cluster de GPU potente só durante o treinamento, acessando os dados, e depois desligá-lo. Paga armazenamento o tempo todo (barato) e processamento só quando usa (caro, mas pontual).

Essa separação é o que torna a arquitetura de dados moderna eficiente em custo e flexível. E ela só é possível porque o object storage oferece um ponto de acesso central, escalável e compatível, do qual qualquer motor de processamento pode ler. Para entender a API que viabiliza esse acesso, vale o conteúdo sobre a API S3.

Data lakehouse e formatos colunares

Sobre a base de object storage, o ecossistema de dados construiu camadas que adicionam sofisticação. Vale conhecer dois conceitos:

Data lakehouse: uma evolução que combina a flexibilidade do data lake com recursos analíticos do data warehouse. Tecnologias como Delta Lake, Apache Iceberg e Apache Hudi funcionam como uma camada sobre o object storage, adicionando transações, versionamento de dados, schema e governança, mantendo os dados no object storage barato e escalável. O lakehouse traz organização ao data lake sem abrir mão da economia do object storage.

Formatos colunares: dentro do object storage, os dados analíticos são tipicamente guardados em formatos como Parquet e ORC. Esses formatos colunares são otimizados para consultas analíticas: em vez de ler linhas inteiras, leem apenas as colunas necessárias, reduzindo drasticamente o volume lido e acelerando as queries. Guardar dados em Parquet sobre object storage é o padrão de fato de data lakes analíticos modernos.

O ponto comum é que ambos pressupõem object storage como camada de base. O lakehouse organiza, os formatos otimizam, mas os bytes ficam no object storage. É a fundação sobre a qual todo o resto se apoia.

Object storage como fonte de dados para IA

Quando se fala em treinar modelos de inteligência artificial, a atenção vai toda para as GPUs. Mas os modelos aprendem a partir de dados, e esses dados precisam morar em algum lugar de onde possam ser lidos em grande volume e velocidade. Esse lugar é, tipicamente, o object storage.

Os datasets de treinamento (que podem ter milhões de imagens, bilhões de registros, terabytes de texto) ficam armazenados em buckets de object storage. Os frameworks de machine learning mais usados (TensorFlow, PyTorch) e os motores de processamento de dados (Spark) leem os dados diretamente do S3, alimentando o treinamento. O object storage é a despensa de onde a IA tira os ingredientes.

Isso se conecta à separação storage/compute: os datasets ficam no object storage barato permanentemente, e quando chega a hora de treinar, o cluster de GPU acessa esses dados. Para entender a infraestrutura de processamento que consome esses dados, vale o conteúdo sobre servidores com GPU e sobre IA aplicada à operação de TI.

O gargalo invisível: throughput de acesso

Aqui está uma das lições mais subestimadas em infraestrutura de IA: o gargalo do machine learning muitas vezes não é a GPU, é o acesso aos dados.

O raciocínio é direto. Uma GPU de altíssimo custo só entrega valor quando está processando. Se ela fica ociosa esperando os dados chegarem do storage (porque a leitura é lenta), você está pagando caro por uma GPU parada. À medida que datasets crescem, a necessidade de throughput (taxa de transferência de dados) aumenta, e um storage que não acompanha vira o gargalo de todo o pipeline. Para aprofundar, vale o conteúdo sobre machine learning e alta performance.

Por isso, o object storage que serve de base para IA não pode ser apenas barato e escalável, precisa também entregar throughput adequado para alimentar as GPUs sem que elas esperem. A arquitetura do storage (a forma como os dados são distribuídos e acessados) impacta diretamente a eficiência do treinamento. Storage de object com boa performance de leitura mantém as GPUs ocupadas e o investimento em processamento rendendo.

Soberania dos dados de treinamento

Há uma dimensão estratégica no armazenamento de dados para IA que vai além da técnica: a soberania. Os dados que treinam seus modelos são ativos valiosos, e muitas vezes sensíveis.

Dois pontos tornam isso crítico. Primeiro, a conformidade: se os dados de treinamento incluem dados pessoais de brasileiros, a LGPD se aplica, e mantê-los sob jurisdição nacional simplifica o compliance. Segundo, a propriedade intelectual: os datasets que você curou e os modelos que treinou são propriedade intelectual de alto valor. Mantê-los sob seu controle, em jurisdição nacional, protege esse ativo de exposição a jurisdições estrangeiras.

Para empresas brasileiras desenvolvendo IA, isso significa que a escolha de onde guardar os dados de treinamento não é só técnica ou de custo, é também de soberania. Object storage compatível com S3 em data centers nacionais permite construir pipelines de IA mantendo os dados sob jurisdição brasileira, sem abrir mão da compatibilidade com as ferramentas do mercado. Para aprofundar, vale o conteúdo sobre soberania de dados no Brasil.

O Object Storage S3 da EVEO para data e IA

O Object Storage S3 da EVEO oferece a camada de armazenamento que data lakes e pipelines de IA precisam, com a vantagem da soberania nacional. Como é compatível com a API S3, os frameworks e motores que o mercado usa (TensorFlow, PyTorch, Spark, e ferramentas de lakehouse) leem os dados diretamente, sem adaptação.

O que o torna uma base sólida para data e IA:

• Escala para data lake: buckets de até 5 PB, acompanhando volumes de data lake na casa dos petabytes.
• Throughput com Fiber Channel: arquitetura Fiber Channel que entrega performance de leitura para alimentar processamento e GPUs sem gargalo.
• Sem egress fee: acessar e mover os datasets de treinamento não gera custo de saída, o que importa quando se lê grandes volumes repetidamente no treinamento.
• Sem cobrança por API: os milhões de operações de leitura de um pipeline de dados não pesam na fatura.
• Soberania dos dados de treino: dados em data centers Tier III no Brasil (Cotia/SP, Osasco/SP, Curitiba/PR, Fortaleza/CE) mais Miami/FL, protegendo conformidade LGPD e propriedade intelectual.
• Custo previsível: R$ 0,05 por GB para guardar datasets permanentemente, com suporte em português 24/7.

Para empresas que constroem data lakes e treinam modelos de IA com dados brasileiros, a EVEO combina a base de object storage compatível com S3, o throughput necessário e a soberania nacional, com economia que pode chegar a 80% em relação à nuvem global.

No fim, por trás de cada modelo de IA e de cada análise de data lake existe uma camada de armazenamento fazendo o trabalho silencioso de guardar e servir os dados. O object storage com S3 venceu esse papel por unir escala, custo, compatibilidade e a separação entre storage e compute que torna a arquitetura moderna eficiente. Para quem desenvolve IA no Brasil, somar a isso a soberania nacional transforma a camada de storage de mero detalhe técnico em vantagem estratégica. Os modelos brilham no palco, mas é o object storage que guarda os bastidores.

Perguntas frequentes sobre object storage para data lake e IA

Por que object storage é usado em data lakes?

Porque oferece o que um data lake precisa: escala praticamente ilimitada para volumes de terabytes ou petabytes, custo por GB baixo para reter tudo, capacidade de guardar qualquer tipo de dado (estruturado, semiestruturado, não estruturado) e acesso via API S3 universal que todas as ferramentas de dados entendem. O data lake é o conceito arquitetural; o object storage com S3 é a tecnologia de armazenamento onde os dados de fato ficam, sendo sua fundação padrão.

O que é separação entre storage e compute?

É desacoplar o armazenamento dos dados do processamento. Em vez do mesmo servidor guardar e processar (forçando escalar os dois juntos), o object storage centraliza os dados e os clusters de processamento (Spark, frameworks de ML, GPUs) os acessam sob demanda. Isso permite escalar armazenamento e processamento de forma independente: petabytes parados no object storage barato, e processamento potente subindo só quando necessário. É o que torna a arquitetura de dados moderna eficiente em custo.

Frameworks de IA leem dados direto do S3?

Sim. Frameworks de machine learning como TensorFlow e PyTorch, e motores de processamento como Spark, leem dados diretamente de object storage compatível com S3. Os datasets de treinamento ficam armazenados em buckets, e o pipeline de treinamento acessa esses dados via API S3. Como a API é padrão, isso funciona com qualquer object storage compatível, não só com a AWS, permitindo manter os dados em provedores nacionais.

O gargalo de IA é a GPU ou o armazenamento?

Muitas vezes é o armazenamento, não a GPU. Uma GPU cara só entrega valor quando processa; se fica ociosa esperando dados chegarem de um storage lento, o investimento é desperdiçado. À medida que datasets crescem, a necessidade de throughput (taxa de transferência) aumenta, e um storage que não acompanha vira o gargalo do pipeline. Por isso, o object storage que serve IA precisa entregar throughput adequado, não basta ser barato e escalável, para manter as GPUs ocupadas.

Por que a soberania dos dados de treinamento importa?

Por dois motivos. Primeiro, conformidade: se os dados de treino incluem dados pessoais de brasileiros, a LGPD se aplica, e mantê-los sob jurisdição nacional simplifica o compliance. Segundo, propriedade intelectual: datasets curados e modelos treinados são ativos de alto valor, e mantê-los em jurisdição nacional os protege de exposição a jurisdições estrangeiras. Para empresas brasileiras desenvolvendo IA, onde guardar os dados de treinamento é decisão de soberania, não só técnica.