# Fontes de dados compatíveis para crawling
<a name="crawler-data-stores"></a>

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 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/glue/latest/dg/crawler-data-stores.html)  | 
| JDBC | Amazon Redshift<br />Snowflake<br />No Amazon Relational Database Service (Amazon RDS) ou externo ao Amazon RDS:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/glue/latest/dg/crawler-data-stores.html) | 
| Cliente MongoDB |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/glue/latest/dg/crawler-data-stores.html)  | 

**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 obter mais informações, consulte [Conectar a dados](glue-connections.md).

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](https://docs.aws.amazon.com/athena/latest/ug/delta-lake-tables.html).
+ **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.
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.