Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Quali datastore posso sottoporre a crawling?
Un crawler può eseguire il crawling dei seguentgli archivi dati basati su file e su tabelle.
| Tipo di accesso utilizzato dal crawler | Archivi dati |
|---|---|
| Client nativo |
|
| JDBC |
Amazon Redshift Snowflake All'interno di Amazon Relational Database Service (Amazon RDS) o esterno ad Amazon RDS:
|
| Client MongoDB |
|
Nota
Attualmente AWS Glue non supporta i crawler per i flussi di dati.
Per gli archivi dati JDBC, MongoDB e Amazon DocumentDB (compatibile con MongoDB), è necessario specificare una connessione AWS Glue che il crawler può utilizzare per connettersi all'archivio dati. Per Amazon S3, puoi facoltativamente specificare una connessione di tipo Rete. Una connessione è un oggetto del catalogo dati che memorizza informazioni di connessione, ad esempio credenziali, URL, informazioni su Amazon Virtual Private Cloud e altro ancora. Per ulteriori informazioni, consulta Connessione ai dati.
Di seguito sono elencate le versioni dei driver supportate dal crawler:
| Product | Driver supportato da Crawler |
|---|---|
| PostgreSQL | 42.2.1 |
| Amazon Aurora | Uguali ai driver crawler nativi |
| 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 |
Di seguito sono elencate le note sui vargli archivi dati.
- Amazon S3
-
Puoi scegliere di eseguire il crawling di un percorso nel tuo account o in un altro account. Se tutti i file Amazon S3 in una cartella hanno lo stesso schema, il crawler crea una tabella. Inoltre, se l'oggetto Amazon S3 è partizionato, viene creata solo una tabella di metadati e le informazioni di partizionamento vengono aggiunte al catalogo dati per tale tabella.
- Amazon S3 e Amazon DynamoDB
-
I crawler utilizzano un ruolo AWS Identity and Access Management (IAM) per l'autorizzazione ad accedere ai tuoi archivi di dati. Il ruolo passato al crawler deve avere l'autorizzazione per accedere ai percorsi Amazon S3 e alle tabelle Amazon DynamoDB di cui viene eseguito il crawling.
- Amazon DynamoDB
-
Quando definisci un crawler usando la console AWS Glue, devi specificare una tabella DynamoDB. Se usi l'API di AWS Glue, puoi specificare un elenco di tabelle. È possibile scegliere di eseguire il crawling solo di un piccolo campione di dati per ridurre i tempi di esecuzione del crawler.
- Delta Lake
-
Per ogni archivio dati Delta Lake, specifichi la modalità di creazione delle tabelle Delta:
Creazione di tabelle native: consente l'integrazione con i motori di query che supportano l'interrogazione diretta del log delle transazioni Delta. Per ulteriori informazioni, consulta Interrogare le tabelle Delta Lake.
Creazione di tabelle Symlink: crea una cartella
_symlink_manifestcon file manifesti partizionati con chiavi di partizioni in base ai parametri di configurazione specificati.
- Iceberg
-
Per ogni datastore Iceberg, specifichi un percorso Amazon S3 che contiene i metadati per le tabelle Iceberg. Se il crawler rileva i metadati della tabella Iceberg, li registra in Catalogo dati. È possibile impostare una pianificazione per il crawler per mantenere aggiornate le tabelle.
È possibile definire questi parametri per il datastore:
Esclusioni: consente di ignorare determinate cartelle.
Profondità di attraversamento massima: imposta il limite di profondità che il crawler può esplorare nel bucket Amazon S3. La profondità di attraversamento massima predefinita è 10, mentre la profondità massima che puoi impostare è 20.
- Hudi
-
Per ogni datastore Iceberg, specifichi un percorso Amazon S3 che contiene i metadati per le tabelle Hudi. Se il crawler rileva i metadati della tabella Hudi, li registra in Catalogo dati. È possibile impostare una pianificazione per il crawler per mantenere aggiornate le tabelle.
È possibile definire questi parametri per il datastore:
Esclusioni: consente di ignorare determinate cartelle.
Profondità di attraversamento massima: imposta il limite di profondità che il crawler può esplorare nel bucket Amazon S3. La profondità di attraversamento massima predefinita è 10, mentre la profondità massima che puoi impostare è 20.
Nota
Le colonne di timestamp con tipi logici
millisverranno interpretate comebiginta causa di un'incompatibilità con Hudi 0.13.1 e i tipi di timestamp. Una risoluzione potrebbe essere fornita nella prossima versione di Hudi.Le tabelle Hudi sono classificate come segue, con implicazioni specifiche per ciascuna di esse:
Copia in scrittura (CoW): i dati vengono archiviati in un formato colonnare (Parquet) e ogni aggiornamento crea una nuova versione dei file durante una scrittura.
Unisci in lettura (MoW): i dati vengono archiviati utilizzando una combinazione di formati colonnare (Parquet) e basati su righe (Avro). Gli aggiornamenti vengono registrati nei file delta basati su righe e vengono compattati come necessario per creare nuove versioni dei file colonnari.
Con i set di dati CoW, ogni volta che c'è un aggiornamento a un record, il file che contiene il record viene riscritto con i valori aggiornati. Quando si lavora con un set di dati MoR, ogniqualvolta è disponibile un aggiornamento Hudi scrive solo la riga per il registro modificato. MoR è più adatto per carichi di lavoro pesanti in scrittura o modifiche con meno letture. CoW è più adatto per carichi di lavoro pesanti di lettura su dati che cambiano meno frequentemente.
Hudi fornisce tre tipi di query per accedere ai dati:
Query snapshot: query che visualizzano l'ultimo snapshot della tabella a partire da una determinata operazione di commit o compattazione. Per le tabelle MoR, le query snapshot espongono lo stato più recente della tabella unendo i file di base e delta della parte di file più recente al momento della query.
Query incrementali: le query vedono solo i nuovi dati scritti nella tabella dal momento di un determinato commit/compattazione. Questo fornisce in modo efficace flussi di modifica per abilitare pipeline di dati incrementali.
Query ottimizzate per la lettura (ReadOptimized): per le tabelle MoR, le query vedono i dati compattati più recenti. Per le tabelle CoW, le query vedono i dati più recenti impegnati.
Per le tabelle Copy-On-Write, i crawler creano una singola tabella nel Data Catalog con il serde. ReadOptimized
org.apache.hudi.hadoop.HoodieParquetInputFormatPer le tabelle Unisci in lettura, il crawler crea due tabelle in Catalogo dati per la stessa posizione della tabella:
Una tabella con suffisso che utilizza il serde.
_roReadOptimizedorg.apache.hudi.hadoop.HoodieParquetInputFormatUna tabella con suffisso
_rtche utilizza RealTime Serde che consente di eseguire query Snapshot:.org.apache.hudi.hadoop.realtime.HoodieParquetRealtimeInputFormat
- MongoDB e Amazon DocumentDB (compatibile con MongoDB)
-
Sono supportate le versioni 3.2 e successive di MongoDB. È possibile scegliere di eseguire il crawling solo di un piccolo campione di dati per ridurre i tempi di esecuzione del crawler.
- Database relazionale
-
L'autenticazione avviene con un nome utente e una password del database. A seconda del tipo di motore di database, è possibile scegliere quali oggetti sono sottoposti a crawling, ad esempio database, schemi e tabelle.
- Snowflake
-
Il crawler JDBC Snowflake supporta il crawling della tabella, della tabella esterna, della vista e della vista materializzata. La definizione della vista materializzata non verrà compilata.
Per le tabelle esterne Snowflake, il crawler eseguirà il crawling se punta a una posizione Amazon S3. Oltre allo schema della tabella, il crawler eseguirà il crawling anche della posizione di Amazon S3, del formato del file e dell'output come parametri di tabella nella tabella del catalogo di dati. Tenere presente che le informazioni sulla partizione della tabella esterna con partizioni non sono compilate.
ETL non è attualmente supportato per le tabelle del catalogo dati create utilizzando il crawler Snowflake.
