À medida que os volumes de dados crescem, a pergunta "onde estão esses dados e qual é a sua estrutura?" surge constantemente. Quando dezenas de milhares de arquivos estão espalhados pelo S3, abrir cada um manualmente é impossível. O AWS Glue Data Catalog resolve esse problema — é um armazenamento central de metadados que mantém um mapa de todos os seus dados sem copiá-los. As questões do exame DEA-C01 sobre este tópico perguntam como encontrar e gerenciar dados em escala.
O que é o Glue Data Catalog
Imagine uma biblioteca com dezenas de milhares de livros. Sem um sistema de fichas de índice, encontrar qualquer coisa levaria uma eternidade. Com fichas de índice, você sabe instantaneamente em qual prateleira está cada livro. O Glue Data Catalog é esse sistema de fichas de índice para seus dados.
O Glue Data Catalog não move nem copia seus arquivos de dados reais. Em vez disso, ele registra:
Onde os dados vivem (caminho S3, endpoint do RDS, etc.) Em qual formato estão (CSV, Parquet, JSON, etc.) Quais colunas existem e qual tipo cada coluna possui Como os dados estão particionados
Essas informações são chamadas de metadados. O catálogo armazena apenas metadados — seus arquivos de dados reais permanecem exatamente onde estão.
Bancos de dados e tabelas dentro do catálogo
A estrutura dentro do Glue Data Catalog parece familiar se você já trabalhou com qualquer banco de dados relacional.
Um banco de dados é um agrupamento lógico de tabelas relacionadas. Por exemplo, um banco de dados chamado "sales_db" pode conter tabelas chamadas "orders", "customers" e "products".
Uma tabela define o esquema (estrutura) e a localização dos dados reais. Cada definição de tabela inclui:
| Campo | Exemplo | Finalidade | |-------|---------|----------| | Localização | s3://my-bucket/orders/ | Onde estão os arquivos de dados | | Formato | Parquet | Tipo de arquivo | | Colunas | order_id (int), amount (double) | Nomes e tipos de colunas | | Chaves de partição | year, month | Como os dados são divididos |
Estas são tabelas virtuais — elas não armazenam linhas. São documentos de definição que dizem aos mecanismos de consulta onde procurar e como ler os dados.
Integração com Athena, Redshift Spectrum e EMR
A maior força do Glue Data Catalog é que múltiplos serviços compartilham os mesmos metadados. Registre uma tabela uma vez e cada serviço pode usá-la sem nenhuma configuração extra.
Imagine que você tem dados de pedidos armazenados no S3 e quer analisá-los:
Athena: Execute consultas SQL diretamente contra o S3 — serverless, sem configuração extra Redshift Spectrum: Consulte dados do S3 como tabela externa dentro do Redshift EMR: Processe os dados em escala massiva usando Spark ou Hive
Os três serviços consultam a mesma definição de tabela no Glue Data Catalog. Não é necessário registrar o mesmo conjunto de dados três vezes em três lugares diferentes.
Glue Crawlers — Descoberta automática de esquemas
Inserir metadados manualmente no catálogo é tedioso, especialmente quando arquivos são adicionados diariamente ou esquemas mudam com frequência. Os Glue Crawlers automatizam esse trabalho.
Um crawler é como um detetive automatizado. Você o aponta para uma fonte de dados (um bucket S3, um banco de dados RDS, uma tabela DynamoDB) e ele entra, descobre a estrutura e registra tudo no catálogo.
Principais capacidades do crawler:
Execuções agendadas: Agende crawlers para executar de hora em hora, diariamente ou semanalmente. Novos dados e mudanças de esquema são detectados automaticamente. Classificadores: O crawler examina cada arquivo e determina automaticamente seu formato (CSV, JSON, Parquet, ORC e mais) sem que você precise indicar. Para formatos incomuns, você pode escrever um classificador personalizado. Detecção de partições: Se suas pastas S3 seguem um padrão como year=2026/month=03/day=15, o crawler reconhece isso como particionamento e registra todas as partições no catálogo.
O fluxo de trabalho do crawler passo a passo:
Escanear o caminho S3 especificado (ou outra fonte) Identificar formatos de arquivo e estrutura usando classificadores Comparar com tabelas existentes no catálogo Criar novas tabelas ou atualizar esquemas existentes com mudanças detectadas Adicionar novas partições descobertas ao catálogo
Sincronização de partições — Três métodos
O particionamento significa armazenar dados divididos em pastas por um atributo específico. Por exemplo, armazenar dados de log em pastas diárias para poder ler apenas os dados de um intervalo de datas específico.
O problema: quando uma nova pasta de partição aparece no S3, o catálogo não sabe disso automaticamente. Alguém ou algo precisa dizer ao catálogo que uma nova pasta existe. Isso é a sincronização de partições.
Método 1 — Executar o Crawler novamente: A abordagem mais simples. Execute o crawler novamente e ele detecta novas partições e as adiciona ao catálogo. A desvantagem é que o crawler re-escaneia toda a fonte, o que leva tempo. Melhor quando novas partições são adicionadas com pouca frequência.
Método 2 — MSCK REPAIR TABLE: Um comando SQL que você executa no Athena:
Isso funciona quando suas pastas S3 seguem a nomenclatura compatível com Hive (formato key=value). Um único comando sincroniza todas as novas partições no catálogo. Mais rápido que executar novamente um crawler, mas só funciona com estruturas de pasta no formato Hive.
Método 3 — BatchCreatePartition API: Chamar diretamente a API do Glue em código, especificando exatamente quais partições adicionar. Este é o método mais rápido e lida com milhares de novas partições de uma vez. Ideal para ambientes de alta frequência onde novas partições aparecem a cada hora. Facilmente automatizável dentro de uma função Lambda ou um job do Glue.
| Método | Velocidade | Melhor para | |--------|-----------|------------| | Executar Crawler novamente | Lento | Adição infrequente de partições | | MSCK REPAIR TABLE | Médio | Formato Hive, sincronização manual | | BatchCreatePartition API | Rápido | Particionamento em grande escala e alta frequência |
Substituindo o Hive Metastore pelo Glue Catalog
O EMR (Elastic MapReduce) é o serviço gerenciado de big data da AWS baseado em Hadoop e Spark de código aberto. Tradicionalmente, clusters EMR usavam seu próprio Hive Metastore integrado para rastrear informações de esquema. O problema: quando você encerra o cluster, esse metastore desaparece com ele.
Ao substituir o Hive Metastore pelo Glue Data Catalog, você ganha:
Os metadados persistem mesmo após desligar o cluster EMR, Athena e Redshift Spectrum compartilham os mesmos metadados Não é necessário registrar tabelas separadamente em cada serviço
Para habilitar isso, simplesmente ative a opção "Usar Glue Data Catalog como metastore" ao criar um cluster EMR. Depois disso, qualquer tabela que você criar no Hive ou Spark SQL é automaticamente registrada no catálogo do Glue.
Pontos-chave do exame
"Armazenamento central de metadados" → Glue Data Catalog "Descobrir e registrar automaticamente esquemas de dados" → Glue Crawlers "Adicionar muitas novas partições S3 rapidamente em código" → BatchCreatePartition API "Sincronizar partições manualmente do Athena" → MSCK REPAIR TABLE "EMR e Athena compartilham os mesmos metadados" → Glue Data Catalog substituindo Hive Metastore "Detectar automaticamente formatos de arquivo" → Classificadores de Crawler O catálogo armazena apenas metadados, não os arquivos de dados reais