Fontes de dados compatíveis para crawling - AWS Glue

Fontes de dados compatíveis para crawling

Os crawlers podem rastrear os seguintes armazenamentos de dados baseados em arquivos e baseados em tabelas.

Tipo de acesso que o crawler usa Armazenamentos de dados
Cliente nativo

  • Amazon Simple Storage Service (Amazon S3)

  • Amazon DynamoDB

  • Lago Delta 2.0.x

  • Apache Iceberg 1.5

  • Apache Hudi 0.14
JDBC

Amazon Redshift

Snowflake

No Amazon Relational Database Service (Amazon RDS) ou externo ao Amazon RDS:

  • Amazon Aurora

  • MariaDB

  • Microsoft SQL Server

  • MySQL

  • Oracle

  • PostgreSQL
Cliente MongoDB

  • MongoDB

  • MongoDB Atlas

  • Amazon DocumentDB (compatível com MongoDB)
nota

Atualmente, o AWS Glue não é compatível com crawlers para streams de dados.

Para armazenamentos de dados JDBC, MongoDB, MongoDB Atlas e Amazon DocumentDB (compatível com MongoDB), você deve especificar uma conexão do AWS Glue que o crawler possa usar para se conectar ao datastore. Para o Amazon S3, você pode especificar opcionalmente uma conexão do tipo Network (Rede). Uma conexão é um objeto do Data Catalog que armazena informações de conexão, como credenciais, URL, informações da Amazon Virtual Private Cloud e muito mais. Para ter mais informações, consulte Conectar a dados.

As seguintes versões de drivers são compatíveis com o crawler:

Produto Driver compatível com crawler
PostgreSQL 42.2.1
Amazon Aurora O mesmo que os drivers de crawler nativos
MariaDB 8.0.13
Microsoft SQL Server 6.1.0
MySQL 8.0.13
Oracle 11.2.2
Amazon Redshift 4.1
Snowflake 3.13.20
MongoDB 4.7.2
MongoDB Atlas 4.7.2

Veja a seguir observações sobre os vários armazenamentos de dados.

Amazon S3

Você pode escolher rastrear um caminho na sua conta ou em outra. Se todos os arquivos do Amazon S3 em uma pasta tiverem o mesmo esquema, o crawler criará uma tabela. Além disso, se o objeto do Amazon S3 for particionado, apenas uma tabela de metadados será criada e as informações da partição serão adicionadas ao Data Catalog para essa tabela.

Amazon S3 e Amazon DynamoDB

Os crawlers usam uma função do AWS Identity and Access Management (IAM) para conceder permissão de acesso aos armazenamentos de dados. A função que você transmite ao crawler precisa ter permissão para acessar os caminhos do Amazon S3 e as tabelas do Amazon DynamoDB que serão rastreados.

Amazon DynamoDB

Ao definir um crawler usando o console do AWS Glue, você especifica uma tabela do DynamoDB. Se você estiver usando a API do AWS Glue, pode especificar uma lista de tabelas. Você pode optar por rastrear apenas uma pequena amostra dos dados, para reduzir os tempos de execução do crawler.

Delta Lake

Para cada datastore Delta Lake, é necessário especificar como criar tabelas do Delta:

  • Criar tabelas nativas: permite a integração com mecanismos de consulta compatíveis com consultas diretas ao log de transações do Delta. Para obter mais informações, consulte Consultar tabelas do Delta Lake.

  • Criar tabelas de link simbólico: crie uma pasta _symlink_manifest com arquivos de manifesto particionados pelas chaves de partição com base nos parâmetros de configuração especificados.

Iceberg

Para cada datastore do Iceberg, você especifica um caminho do Amazon S3 que contém os metadados para as tabelas do Iceberg. Se o crawler descobrir metadados da tabela do Iceberg, ele os registrará no catálogo de dados. Você pode definir uma agenda para que o crawler mantenha as tabelas atualizadas.

Você pode definir esses parâmetros para o datastore:

  • Exclusões: permite que você pule determinadas pastas.

  • Profundidade máxima de travessia: define o limite de profundidade que o crawler pode percorrer no bucket do Amazon S3. A profundidade de travessia máxima padrão é 10 e a profundidade máxima que você pode definir é 20.

Hudi

Para cada datastore do Hudi, você especifica um caminho do Amazon S3 que contém os metadados para as tabelas do Hudi. Se o crawler descobrir metadados da tabela do Hudi, ele os registrará no catálogo de dados. Você pode definir uma agenda para que o crawler mantenha as tabelas atualizadas.

Você pode definir esses parâmetros para o datastore:

  • Exclusões: permite que você pule determinadas pastas.

  • Profundidade máxima de travessia: define o limite de profundidade que o crawler pode percorrer no bucket do Amazon S3. A profundidade de travessia máxima padrão é 10 e a profundidade máxima que você pode definir é 20.

nota

As colunas de timestamp tendo millis como tipos lógicos serão interpretadas como bigint, devido a uma incompatibilidade com o Hudi 0.13.1 e os tipos de timestamp. Uma resolução pode ser fornecida na próxima versão do Hudi.

As tabelas do Hudi são categorizadas da seguinte forma, com implicações específicas para cada uma delas:

  • Copy on Write (CoW): os dados são armazenados em um formato colunar (Parquet) e cada atualização cria uma nova versão dos arquivos durante uma gravação.

  • Merge on Read (MoR): os dados são armazenados usando uma combinação de formatos colunares (Parquet) e baseados em linha (Avro). As atualizações são registradas em arquivos delta baseados em linha e são compactadas conforme necessário para criar novas versões dos arquivos colunares.

Com conjuntos de dados CoW, sempre que há uma atualização para um registro, o arquivo que contém o registro é regravado com os valores atualizados. Com um conjunto de dados MoR, sempre que há uma atualização, o Hudi grava apenas a linha do registro alterado. MoR é mais adequado para cargas de trabalho com maior volume de gravações ou alterações e menor volume de leituras. O tipo CoW é mais adequado para workloads com maior volume de leituras em dados que mudam com menos frequência.

O Hudi oferece três tipos de consulta para acessar os dados:

  • Consultas de snapshot: consultas que veem o snapshot mais recente da tabela a partir de uma determinada ação de confirmação ou compactação. Para tabelas MoR, as consultas de snapshot expõem o estado mais recente da tabela mesclando os arquivos base e delta da fatia de arquivo mais recente no momento da consulta.

  • Consultas incrementais: as consultas veem somente os novos dados gravados na tabela, a partir de uma determinada confirmação/compactação. Desse modo, os streams de alteração são fornecidos para habilitar pipelines de dados incrementais.

  • Ler consultas otimizadas: para tabelas de MoR, as consultas veem os dados mais recentes compactados. Para tabelas CoW, as consultas veem os dados mais recentes confirmados.

Para tabelas Copy-On-Write, os crawlers criam uma única tabela no catálogo de dados com o serde ReadOptimized org.apache.hudi.hadoop.HoodieParquetInputFormat.

Para tabelas Merge-On-Read, o crawler cria duas tabelas no catálogo de dados para o mesmo local da tabela:

  • Uma tabela com sufixo _ro que usa o serde ReadOptimized org.apache.hudi.hadoop.HoodieParquetInputFormat.

  • Uma tabela com sufixo _rt que usa o serde RealTime permitindo consultas instantâneas: org.apache.hudi.hadoop.realtime.HoodieParquetRealtimeInputFormat.

MongoDB e Amazon DocumentDB (compatível com MongoDB)

O MongoDB versões 3.2 e posteriores são compatíveis. Você pode optar por rastrear apenas uma pequena amostra dos dados, para reduzir os tempos de execução do crawler.

Banco de dados relacional

A autenticação é realizada com um nome de usuário e senha do banco de dados. Dependendo do tipo de mecanismo de banco de dados, você pode escolher quais objetos são rastreados, como bancos de dados, esquemas e tabelas.

Snowflake

O crawler JDBC do Snowflake é compatível com crawling da tabela, da tabela externa, da visão e da visão materializada. A definição de visão materializada não será preenchida.

Em tabelas externas do Snowflake, o crawler só fará o rastreamento se apontar para um local do Amazon S3. Além do esquema da tabela, o crawler também rastreará o local, o formato do arquivo e a saída do Amazon S3 como parâmetros da tabela do Data Catalog. Observe que as informações de partição da tabela externa particionada não são preenchidas.

Atualmente, o ETL não é compatível com tabelas do Data Catalog criadas usando o crawler do Snowflake.