Modelagem de Dados, Catálogo Glue e Evolução de Schema

Duas tarefas do Domínio 2 do DEA-C01 se encontram nesta lição. Tarefa 2.2, entender sistemas de catalogação de dados, pede que você construa e referencie um catálogo técnico de dados (AWS Glue Data Catalog, Apache Hive metastore), descubra schemas com crawlers, sincronize partições e crie conexões de origem/destino. Tarefa 2.4, projetar modelos de dados e evolução de schema, pede que você designe schemas para Amazon Redshift, DynamoDB e Lake Formation, trate mudanças nas características dos dados e descreva boas práticas de indexação, estratégias de particionamento e compactação. O exame trata as duas como uma história só: um modelo só é tão bom quanto o catálogo que o descreve, e um catálogo só é seguro se você puder mudar o que ele descreve sem quebrar todo consumidor.

Nesta lição você vai:

• ler o modelo de objetos do Glue Data Catalog, catálogo, database, tabela, StorageDescriptor, PartitionKeys, classification, e as cotas que o esculpem;
• rodar um crawler na sua cabeça: classificadores personalizados em ordem, primeiro sucesso vence, embutidos só se nenhum casou, heurísticas de pasta e SchemaChangePolicy;
• separar indexação de partição, pruning e partition projection, incluindo as duas configurações que o Athena precisa para usar um índice;
• operar versionamento de tabela: o que o UpdateTable arquiva, como você compara duas versões e como uma troca azul/verde de tabela é montada a partir de blocos verificados;
• ligar resource links para compartilhamento entre contas e entre Regiões, com a regra do duplo grant;
• escolher estrela versus floco de neve, fixar a granularidade, identificar fatos, dimensões e chaves substitutas, e desnormalizar para a distribuição do Redshift;
• implementar SCD Tipo 1 versus Tipo 2 (e por que o Tipo 2 é o clássico do exame) com um merge trabalhado;
• classificar uma mudança proposta de schema como aditiva ou quebradora em tabelas no estilo Hive, Parquet/JSON/Avro e Iceberg, incluindo evolução de partição;
• projetar um modelo de tabela única do DynamoDB a partir de padrões de acesso, chaves e GSIs;
• empilhar particionamento, bucketing, ordenação, compactação e tamanho de arquivo numa única escada de eliminação de varredura;
• estudar três estudos de caso de clientes da AWS (BMW Group, GoDaddy e Integral Ad Science) e uma caixa de atualizações de outubro de 2026 com fonte;
• praticar com 14 questões no estilo do exame mais quatro verificações interativas.

---

1. O modelo de objetos do Glue Data Catalog

1.1 A árvore, e a frase que importa

O Data Catalog é uma hierarquia de metadados: conta/Região → catálogo → database → tabela → partições, mais functions. A documentação de crawlers da AWS enuncia o fato sobre o qual toda questão de catálogo se apoia: "As tabelas no Data Catalog não contêm dados." Uma linha de tabela aponta para dados (Location do S3, InputFormat, OutputFormat, SerdeInfo); ela nunca os guarda. É por isso que apagar uma tabela do catálogo não apaga os objetos, e por que dois catálogos podem apontar para os mesmos prefixos.

Uma única camada de metadados alimenta Athena, Redshift Spectrum, EMR, Glue ETL e SageMaker AI: que é o ponto inteiro: crawlee uma vez, consulte de vários motores. Catálogos também podem ser federados, então um catálogo federado ao Redshift (ou um catálogo com resource links para bancos do Redshift em outra conta ou Região) aparece na mesma árvore.

1.2 A tabela de cotas (em outubro de 2026)

• 📚 Você sabia? O próprio Data Catalog tem uma camada gratuita: os primeiros 1.000.000 objetos de metadados e 2.000.000 requisições de metadados são gratuitos (preços do AWS Glue, acesso em outubro de 2026). Crawling e ETL são cobrados separadamente a $0,44 por DPU-hora, então uma equipe pode rodar um catálogo movimentado de graça e ainda receber uma conta surpresa dos seus crawlers: as duas linhas da conta respondem perguntas diferentes.

---

2. Crawlers e classificadores: como um schema é descoberto

2.1 A ordem de execução, o fato de crawler mais testado

A AWS documenta um pipeline fixo: o crawler executa quaisquer classificadores personalizados que você escolher… na ordem que você especificar, e "The first custom classifier to successfully recognize the structure of your data is used to create a schema. Custom classifiers lower in the list are skipped." Só se nenhum classificador personalizado casar é que os classificadores embutidos tentam. Depois o crawler conecta, infere o schema e grava os metadados.

Duas consequências que os autores de questões adoram. Primeiro, um classificador é um reconhecedor de formato/schema (ele "verifica se um dado arquivo está num formato que o crawler consegue tratar" e emite um StructType); o crawler é o orquestrador que descobre, agrupa, versiona e grava. Segundo, prioridade é posicional: um classificador CSV com delimiter=; listado primeiro vence um classificador JSON listado em segundo, e tudo abaixo do vencedor é ignorado.

2.2 Alvos, agendamento e re-crawling

2.3 SchemaChangePolicy, e como congelar um schema curado

UpdateBehavior ∈ {LOG, UPDATE_IN_DATABASE}; DeleteBehavior ∈ {LOG, DELETE_FROM_DATABASE, DEPRECATE_IN_DATABASE (acrescenta um marcador DEPRECATED mais um timestamp)}. A armadilha crítica: a política "não afeta se nem como novas tabelas e partições são acrescentadas."

2.4 Exemplo trabalhado E1: um crawler que não pode destruir três colunas curadas à mão

Entrada: s3://acme-raw/orders/dt=2026-10-0*/, CSV delimitado por ponto e vírgula com campos entre aspas, timestamps atualmente inferidos como string, três colunas de catálogo editadas à mão por um analista que precisam sobreviver a todo crawl.

Checagem de custo em outubro de 2026: crawlers cobram $0,44 por DPU-hora, por segundo, com mínimo de 10 minutos por crawl (1 DPU = 4 vCPU + 16 GB). Um crawl noturno que roda duas DPUs pelo mínimo de dez minutos custa 2 × (10/60) × 0,44 ≈ $0,15 por noite ≈ $4,5 por mês, e isso é antes de qualquer fila ociosa: que é por que crawls incrementais dirigidos por evento são a recomendação padrão para tabelas que mudam uma vez por dia.

• 📚 Você sabia? A heurística de pasta é uma votação majoritária, não uma regra: "When the majority of schemas at a folder level are similar, the crawler creates partitions of a table instead of separate tables." Assim uma pasta de CSVs limpos mais dois arquivos JSON malformados produz uma tabela com partições e o ruído JSON é absorvido: enquanto forçar conjuntos de dados genuinamente diferentes a separar significa acrescentar cada raiz como um data store separado, não mexer num flag (documentação do crawler do AWS Glue, acesso em outubro de 2026).

---

3. Sincronizando partições: indexação, pruning e projection

3.1 Cinco mecanismos, um trabalho

O schema de partição existe no nível da tabela e por partição, e o Athena valida os dois: uma divergência falha rápido com HIVE_PARTITION_SCHEMA_MISMATCH em vez de ler dados errados em silêncio.

3.2 Índice versus pruning versus projection

• Pruning é o resultado: descartar partições que não correspondem antes de qualquer arquivo ser lido. O Athena poda para toda tabela particionada, as projetadas incluídas.
• Um índice de partição é um índice armazenado no Data Catalog sobre um subconjunto ordenado de chaves de partição, para que GetPartitions busque um subconjunto em vez de tudo. Regras: máx 3 por tabela; tipos de chave String/Numeric/Date; operadores =, >, >=, <, <=, BETWEEN e somente AND (LIKE, IN, OR, NOT são ignorados e aplicados depois); a primeira chave do índice precisa aparecer na expressão, ou o índice não é usado de forma alguma.
• Projection é o Athena calculando valores e localizações de partição em memória a partir das propriedades da tabela que você configura na tabela do Glue: "Enabling partition projection on a table causes Athena to ignore any partition metadata registered to the table in the AWS Glue Data Catalog or Hive metastore."

3.3 Exemplo trabalhado E2: 400.000 partições, um índice, quatro consultas

Índice: [country, category, year] em uma tabela com 400.000 partições.

Duas configurações, então dois consumidores diferentes:

• 📚 Você sabia? O Glue ETL dá duas alavancas de pushdown diferentes, e elas podam em lugares diferentes: push_down_predicate é Spark SQL aplicado do lado do cliente depois de listar todas as partições, enquanto catalogPartitionPredicate é JSQL aplicado do lado do servidor através do índice de partição: a que se alcança quando a tabela tem milhões de partições (boas práticas do AWS Glue, acesso em outubro de 2026).

---

4. Versionamento de tabela, comparação e trocas azul/verde

4.1 Versionamento está sempre ligado

"By default, UpdateTable always creates an archived version of the table before updating it. However, if skipArchive is set to true, UpdateTable does not create the archived version." Todo crawl que muda um schema portanto incrementa VersionId em 1, contra um teto de 100.000 versões por tabela e 1.000.000 por conta (em outubro de 2026).

Não existe rollback de verdade: a versão atual não pode ser apagada, e restaurar significa publicar uma nova versão idêntica àquela que você quer de volta. (O Apache Iceberg consegue voltar para um snapshot id: um recurso diferente, não uma operação de versão de catálogo.)

4.2 Trocas azul/verde de tabela: um padrão, não um produto

A AWS não entrega nenhuma feature nomeada de "implantação azul/verde de tabela" para o Glue Data Catalog. O que está verificado são os blocos de construção, e a forma segura de responder no exame é como um padrão montado:

---

5. Resource links e compartilhamento entre contas

Um resource link é uma tabela local (ou database) cujo TargetTable é {CatalogId, DatabaseName, Name, Region}, então ele pode apontar para outra conta e para outra Região. Criar um exige CREATE_TABLE/CREATE_DATABASE do Lake Formation e glue:CreateTable/glue:CreateDatabase do IAM.

As regras que geram questões:

• "granting permissions on a resource link doesn't grant permissions on the target": você precisa de DESCRIBE no link mais um grant separado no alvo. Dois passos, sempre.

• Links aparecem em itálico no console; não existe checagem de existência na criação, então um link pode apontar para nada.

• Cadeias são inúteis: as APIs seguem apenas o primeiro resource link, então um link para um link não resolve.

• Existem duas pilhas de compartilhamento: Lake Formation (controle de acesso por recurso nomeado ou por tag, exigindo que a política de recurso da conta de origem permita glue:ShareResource para ram.amazonaws.com) ou permissões legadas do Glue só com IAM. Desligar "Usar somente controle de acesso por IAM para databases/tabelas novos" impede que objetos novos recebam Super para IAMAllowedPrincipals.

• LF-Tags são pares chave-valor como department=sales ou classification=restricted, e "Tables inherit LF-Tags from databases and columns inherit LF-Tags from tables": que é como a marcação de PII escala: grants contam como n(principais) + n(recursos) em vez de um produto.

• 📚 Você sabia? Ninguém no GoDaddy digitou aqueles resource links. O pipeline de provisionamento do mesh deles usou AWS Service Catalog e AWS Lambda para criar automaticamente os links do lado do consumidor, então um produto de dados novo aparecia numa conta consumidora já vinculado e ainda a exatamente um grant de distância de ser consultável. Automatizar o objeto de metadados, não a cópia de dados, é o que impede que "centenas de contas" se transformem em centenas de tickets manuais, e a regra de dois passos de DESCRIBE mais alvo continuou valendo para cada uma delas (AWS Big Data Blog, acesso em outubro de 2026).

---

6. Modelagem dimensional: granularidade, fatos, dimensões, estrela vs floco de neve

6.1 Granularidade primeiro: a decisão de onde todas as outras penduram

Granularidade é o que uma linha de uma tabela de fatos significa: "uma linha por item de pedido", não "uma linha por pedido", não "uma linha por dia por loja". Decida antes de escolher as chaves, porque ela determina quais eventos podem dividir uma tabela e de que tamanho é cada linha. (Os posts de modelagem do Redshift da AWS usam granularidade o tempo todo mas nunca publicam uma definição formal: a formulação de exame é o enquadramento da indústria/Kimball.)

O Redshift constrói chaves substitutas com IDENTITY, e você deve declarar chaves primárias/estrangeiras de qualquer jeito: "Redshift will not enforce them, but declaring them will help the optimizer arrive at optimal query plans." Mantenha uma dimensão de data: toda tabela de fatos precisa de um date_sk.

6.2 Estrela versus floco de neve

"Snowflake schemas extend the star concept by further normalizing the dimensions into multiple tables." A AWS escolhe a estrela onde ela "se alinha de perto com o processo de negócio", e a compactação colunar torna as chaves desnormalizadas "relatively inexpensive to store", então os joins extras de um floco de neve compram pouco e custam tempo de consulta.

Leia os dois diagramas como um trade: a estrela junta o fato a quatro dimensões planas em quatro saltos; o floco de neve normaliza city → country e subcategory → category, então um salto vira dois e cada join extra é trabalho que o motor precisa planejar. Neste exame, "o processo de negócio se alinha a um fato e a dimensões planas" ⇒ estrela; "o requisito é dimensões conformadas normalizadas e reutilizáveis" ⇒ floco de neve, com o custo de join nomeado.

6.3 Formas de tabela de fatos (reconhecimento)

---

7. Dimensões de mudança lenta: Tipo 1 versus Tipo 2

7.1 Os quatro tipos que você pode definir

7.2 Exemplo trabalhado E3: um merge de Tipo 2, instrução por instrução

O staging guarda o delta; a dimensão guarda o histórico. Combine pela chave de negócio com um left outer join, faça hash das colunas rastreadas para decidir update versus insert, e faça isso como operações em bloco, nunca cursores linha a linha:

Mecânica que vale a memória:

• Detecção de correspondência: left outer join staging ↔ dimensão pela chave de negócio; linhas casadas são candidatas a update/expiração, linhas não casadas são inserts.

• Detecção de mudança: sha2 entre fontes, FNV_HASH (64-bit) para dimensões grandes, CHECKSUM (32-bit) para as pequenas: hash mudado significa que a linha precisa versionar.

• Detecção de exclusão: extrações completas → compare versões anterior e atual; extrações só de mudança → use uma coluna de status.

• Distribuição: dê ao staging e ao alvo chaves de distribuição correspondentes para que o merge seja local ao nó no Redshift.

• Contrato: carregue dimensões primeiro, depois fatos: uma carga de dimensão que falha precisa bloquear a carga do fato.

• 📚 Você sabia? A convenção de data alta 2999-12-31 não é enfeito: ela deixa uma consulta encontrar "o endereço atual de cada cliente" com WHERE is_active = 1 ou com WHERE CURRENT_DATE BETWEEN rec_eff_dt AND rec_exp_dt, e deixa um fato histórico se juntar com f.order_date BETWEEN d.rec_eff_dt AND d.rec_exp_dt: que é exatamente como um esquema estrela responde "como era o pedido na época". O Tipo 1 não tem equivalente porque não existe intervalo sobre o qual juntar (orientação de SCD do Amazon Redshift, acesso em outubro de 2026).

---

8. Desnormalização e projeto físico no Redshift

As dimensões planas do esquema estrela são uma decisão de desnormalização, e o Redshift a recompensa fisicamente:

A desnormalização também responde fisicamente à questão do floco de neve: tabelas normalizadas a mais significam joins a mais, e num warehouse colunar esses joins custam bem mais do que o disco que economizam.

---

9. Evolução de schema: aditivo versus quebrador

9.1 A tabela de auditoria

Uma mudança é aditiva quando leitores antigos e arquivos antigos continuam funcionando; é quebradora quando um consumidor falha, coage silenciosamente, ou o layout de partição deixa de casar com a consulta.

Dois pontos de apoio: "Iceberg schema updates are metadata-only changes. No data files are changed when you perform a schema update", e a correção do Iceberg repousa em field IDs únicos: "Added columns never read existing values from another column". O Athena, em contraste, falha rápido em vez de ler errado: um schema de partição que diverge do schema da tabela levanta HIVE_PARTITION_SCHEMA_MISMATCH.

9.2 Evolução de partição é a armadilha dentro da armadilha

"Hive table partitioning cannot change so moving from a daily partition layout to an hourly partition layout requires a new table. And because queries are dependent on partitions, queries must be rewritten for the new table." Para o Iceberg: "Quando você evolui uma spec de partição, os dados antigos gravados com uma spec anterior permanecem inalterados. Dados novos são gravados usando a nova spec num novo layout… A evolução de partição é uma operação de metadados e não reescreve arquivos ansiosamente." As duas frases são examináveis e apontam em direções opostas: as chaves de partição no estilo Hive são as chaves de objeto do S3, então mudar o esquema é uma migração; as specs de partição do Iceberg são metadados, então layouts antigo e novo coexistem: ao custo de split planning extra.

9.3 Como Parquet, JSON e Avro cada um lida com a mudança

9.4 Exemplo trabalhado E5: classifique cinco pedidos antes de despachá-los

A regra de ordenação, aditivo antes do deploy de código, deletivo depois do deploy de código, é a frase mais reutilizável desta seção.

---

10. Design de tabela única do DynamoDB: padrões de acesso primeiro

"Single table design is a pattern that allows you to store multiple types (entities) of data in a single DynamoDB table." O fluxo documentado pela AWS roda caso de uso → relacionamento entre entidades → padrões de acesso (escritos como SQL) → schema → PK/SK por tabela e GSI → repita, e começa por consultas, não por entidades.

10.1 Exemplo trabalhado E6: quatro padrões de acesso para um design

Escolha tabela única quando as entidades são consultadas juntas com necessidades operacionais semelhantes; escolha tabelas separadas quando retenção, backup, chaves KMS por inquilino ou classe de tabela divergem. A AWS declara os dois lados; isto é uma questão de julgamento, não uma questão de "tabela única é sempre melhor".

---

11. Particionamento, bucketing, ordenação, compactação: a escada de eliminação

Cada camada remove trabalho antes da próxima rodar, da mais externa para a mais interna:

Escolha de codec (da tabela de codecs das boas práticas do AWS Glue): Snappy: rápido, razão moderada, padrão para Parquet; GZIP: razão alta, intensivo de CPU e não divisível, então só texto frio/arquivamento; Bzip2: razão muito alta, divisível, lento; ZLIB: padrão para ORC; Zstd: equilibrado. Compactação versus paralelismo é um trade real: Gzip em texto quente perde a divisibilidade.

11.1 Exemplo trabalhado E7: a escada de custo de varredura

CSV de 100 colunas, 4 TB sem compactação, uma consulta selecionando uma coluna para um dia de 365:

O Athena precifica o resultado: a $5,00 por TB escaneado com mínimo de 10 MB por consulta (preços do Athena, acesso em outubro de 2026), a varredura bruta fica em cerca de $20,00, a varredura com GZIP $5,00, a varredura de coluna única em Parquet $0,05, e a varredura particionada é medida em frações de centavo. Formato e layout são controles de custo, não apenas controles de desempenho.

• 📚 Você sabia? A ordenação ajuda apenas filtros na coluna de ordenação: as estatísticas de mínimo/máximo descrevem a chave de ordenação, então um predicado em qualquer outra coluna não pula nada. É por isso que "acrescentar um SORTKEY em customer_id" responde a uma consulta filtrada por cliente e não faz nada por uma filtrada por produto (orientação de desempenho do Amazon Athena, acesso em outubro de 2026).

A outra metade de uma conta do Athena é o mínimo de reserva em vez dos bytes escaneados, e esse mínimo ele próprio mudou em 2026. Pegue a mesma janela de lote noturno, 12 DPU rodando por 10 minutos, e leia-a em DPU-horas (DPU × horas) sob a regra antiga e a nova:

Lendo o gráfico: o trabalho nunca mudou, 12 DPU por 10 minutos de qualquer jeito, mas a quantidade cobrável caiu de 24 × 1 = 24 DPU-horas para 12 × (10/60) = 2 DPU-horas, um corte de 12× produzido puramente pela redução do mínimo do serviço de 24 DPU / 60 minutos para 4 DPU / 1 minuto (AWS Big Data Blog, 11 de fevereiro de 2026, acesso em outubro de 2026). O layout ainda decide quantos bytes você varre; a regra de reserva decide quantos daqueles minutos você é forçado a comprar.

Atualizações de 2026 (em outubro de 2026)

---

Casos Reais

Todo número abaixo é afirmação do cliente ou da AWS e não auditado, com a fonte nomeada para que você possa conferir. O ponto examinável é o padrão, qual objeto de catálogo foi compartilhado, qual contrato de schema foi aplicado, não o marketing.

Caso A, BMW Group: schemas no Glue, dados no S3

O padrão examinável: os dados nunca saíram do S3 enquanto a propriedade se dividia entre contas, o Glue guarda os schemas, Athena e SageMaker os consomem no lugar. Esse é exatamente o arranjo de resource link mais Lake Formation da Seção 5, e é por que "copiar os dados para a conta de cada equipe" é uma distractor: o compartilhamento pertence à camada de metadados.

Caso B, GoDaddy: um data mesh sobre um catálogo compartilhado

"Existem mais de 2.000 produtos de dados construídos sobre o data mesh da GoDaddy na AWS … Nosso data mesh gerencia vários petabytes de dados distribuídos por centenas de contas."

Leia o número corretamente: 2.000 produtos de dados é um problema de escala de catálogo, não de armazenamento. Resource links (que aparecem em itálico, precisam de DESCRIBE mais um grant no alvo, e resolvem apenas o primeiro link de uma cadeia) mais shares do AWS RAM são o que faz centenas de consultarem um database do Glue sem copiá-lo.

• 📚 Você sabia? Os três estudos de caso colocam o AWS Glue Data Catalog no meio e nenhum deles moveu dados para dar acesso a uma equipe: BMW para separação de produtor/consumidor, GoDaddy para compartilhamento em todo o mesh, IAS para acesso baseado em classificação. Essa repetição é a dica: no DEA-C01, "tornar os dados disponíveis para outra conta ou motor" na maioria das vezes se resolve numa resposta de catálogo ou permissão (resource link, grant do LF, share do RAM, view de catálogo), nunca numa resposta de cópia (COPY, export, snapshot) (estudo de caso da AWS e AWS Big Data Blog, acesso em outubro de 2026).

Caso C, Integral Ad Science: centenas de regras viram duas tags

"Com o controle de acesso por tag do Lake Formation, a IAS reduziu centenas de regras de permissão a exatamente duas regras."

Leia a aritmética, não o marketing: duas regras é um tipo diferente de grant, não uma lista mais curta. Uma política por tabela custa aproximadamente n(principais) × n(tabelas); um grant por tag custa n(principais) + n(valores de tag), e porque "Tables inherit LF-Tags from databases and columns inherit LF-Tags from tables" (Seção 5), etiquetar o database uma única vez puxa toda tabela e coluna futura para a mesma política sem ninguém editar regra. O grant é escrito contra classification=restricted, não contra um nome de tabela, e é por isso que o controle de PII em nível de coluna sobrevive a mil tabelas novas.

• 📚 Você sabia? A IAS separou quem pode consultar de quanto uma equipe pode rodar: o acesso a colunas individuais era decidido por tags do Lake Formation, enquanto cada unidade de negócio ganhava o seu próprio workgroup do Athena com limites de consulta e tags de alocação de custo. Dois planos de controle independentes, grants respondem "posso ler esta coluna?", workgroups respondem "até onde esta equipe pode ir e quem paga?", e as alternativas de exame adoram trocá-los (AWS Big Data Blog, acesso em outubro de 2026).

---

Perguntas de Prática (Practice Questions)

Veredito Comparativo: como este tópico se compara no dia do exame

• Verso outras nuvens: o guia do DEA-C01 testa apenas serviços da AWS: AWS Glue Data Catalog, AWS Lake Formation, Amazon Athena, Amazon Redshift, Amazon DynamoDB. Nada no guia compara a AWS com outro provedor, então qualquer alternativa que pivote para o metastore, catálogo ou formato de tabela de um concorrente está fora de escopo por construção; responda com um serviço da AWS no escopo ou com um princípio publicado pela AWS.
• Verso autogerenciado / on-premises (Hive metastore que você roda): você pode construir a mesma árvore no Hadoop, mas aí você é dono da disponibilidade do metastore, do seu IAM, da sua história entre contas e do seu scaling. A preferência do exame é a camada de metadados gerenciada e compartilhada, Glue mais grants do Lake Formation, com o Apache Hive metastore aparecendo como o conceito que o Data Catalog implementa (a Tarefa 2.2.2 nomeia os dois). Escolha a alternativa com menos trabalho operacional não diferenciado.
• Verso outro serviço da AWS na mesma camada: Glue Data Catalog é o armazenamento de metadados; Athena é o motor de consulta; Lake Formation é o plano de permissões; Amazon SageMaker Catalog é o catálogo de negócio/governança (habilidade 2.2.6); crawlers do Glue são o mecanismo de descoberta. Uma pergunta sobre "onde o schema é registrado" nunca responde "Athena", e uma sobre "quem pode ler esta coluna" nunca responde "Glue": grants do Lake Formation e LF-Tags fazem isso.
• Verso um processo manual e humano: os mais de 2.000 produtos de dados da GoDaddy e os 10 TB/dia da BMW (afirmações de clientes, acesso em outubro de 2026) são resultados de mecanismos, crawls, resource links, grants do LF, índices de partição, não de alguém mantendo uma planilha de localizações de tabelas. No exame, prefira a alternativa que automatiza registro, sincronização ou permissão sobre a que exige que um engenheiro se lembre.