Apache Iceberg è un formato di tabella aperta per set di dati analitici molto grandi, che acquisisce informazioni sui metadati sullo stato dei set di dati man mano che si evolvono e cambiano nel tempo. Aggiunge tabelle ai motori di calcolo tra cui Spark, Trino, PrestoDB, Flink e Hive utilizzando un formato di tabella ad alte prestazioni che funziona proprio come una tabella SQL. Iceberg è diventato molto popolare per il suo supporto per le transazioni ACID nei data lake e per funzionalità come l'evoluzione di schemi e partizioni, viaggi nel tempo e rollback.
L'integrazione di Apache Iceberg è supportata dai servizi di analisi AWS, tra cui Amazon EMR, Amazzone Atenae Colla AWS. Amazon EMR può effettuare il provisioning di cluster con Spark, Hive, Trino e Flink che possono eseguire Iceberg. A partire dalla versione 6.5.0 di Amazon EMR, puoi farlo usa Iceberg con il tuo cluster EMR senza richiedere un'azione di bootstrap. All'inizio del 2022, AWS ha annunciato la disponibilità generale delle transazioni Athena ACID, alimentate da Apache Iceberg. Il recentemente rilasciato Motore di query Athena versione 3 fornisce una migliore integrazione con il formato della tabella Iceberg. AWS Glue 3.0 e versioni successive supporta il framework Apache Iceberg per i data lake.
In questo post, discutiamo di ciò che i clienti desiderano nei moderni data lake e di come Apache Iceberg aiuta a soddisfare le esigenze dei clienti. Quindi esaminiamo una soluzione su cui creare un data lake Iceberg ad alte prestazioni e in evoluzione Servizio di archiviazione semplice Amazon (Amazon S3) ed elaborare dati incrementali eseguendo istruzioni SQL di inserimento, aggiornamento ed eliminazione. Infine, ti mostriamo come ottimizzare le prestazioni del processo per migliorare le prestazioni di lettura e scrittura.
In che modo Apache Iceberg risponde a ciò che i clienti desiderano nei data lake moderni
Sempre più clienti stanno costruendo data lake, con dati strutturati e non strutturati, per supportare molti utenti, applicazioni e strumenti di analisi. È sempre più necessario che i data lake supportino funzionalità simili a database come transazioni ACID, aggiornamenti ed eliminazioni a livello di record, viaggi nel tempo e rollback. Apache Iceberg è progettato per supportare queste funzionalità su data lake convenienti nell'ordine dei petabyte su Amazon S3.
Apache Iceberg soddisfa le esigenze dei clienti acquisendo ricche informazioni di metadati sul set di dati nel momento in cui vengono creati i singoli file di dati. Esistono tre livelli nell'architettura di una tabella Iceberg: il catalogo Iceberg, il livello dei metadati e il livello dei dati, come illustrato nella figura seguente (source).
Il catalogo Iceberg memorizza il puntatore dei metadati al file di metadati della tabella corrente. Quando una query di selezione sta leggendo una tabella Iceberg, il motore di query passa prima al catalogo Iceberg, quindi recupera la posizione del file di metadati corrente. Ogni volta che c'è un aggiornamento alla tabella Iceberg, viene creato un nuovo snapshot della tabella e il puntatore dei metadati punta al file di metadati della tabella corrente.
Di seguito è riportato un catalogo Iceberg di esempio con l'implementazione di AWS Glue. È possibile visualizzare il nome del database, la posizione (percorso S3) della tabella Iceberg e la posizione dei metadati.
Il livello dei metadati ha tre tipi di file: il file dei metadati, l'elenco manifest e il file manifest in una gerarchia. Nella parte superiore della gerarchia si trova il file di metadati, che memorizza le informazioni sullo schema della tabella, le informazioni sulla partizione e gli snapshot. Lo snapshot punta all'elenco manifest. L'elenco manifest contiene le informazioni su ciascun file manifest che costituisce l'istantanea, come la posizione del file manifest, le partizioni a cui appartiene e i limiti inferiore e superiore per le colonne di partizione per i file di dati di cui tiene traccia. Il file manifest tiene traccia dei file di dati e di ulteriori dettagli su ciascun file, come il formato del file. Tutti e tre i file funzionano in una gerarchia per tenere traccia degli snapshot, dello schema, del partizionamento, delle proprietà e dei file di dati in una tabella Iceberg.
Il livello dati contiene i singoli file di dati della tabella Iceberg. Iceberg supporta un'ampia gamma di formati di file tra cui Parquet, ORC e Avro. Poiché la tabella Iceberg tiene traccia dei singoli file di dati invece di puntare solo alla posizione della partizione con i file di dati, isola le operazioni di scrittura dalle operazioni di lettura. È possibile scrivere i file di dati in qualsiasi momento, ma eseguire solo il commit esplicito della modifica, che crea una nuova versione dei file di snapshot e metadati.
Panoramica della soluzione
In questo post, ti guidiamo attraverso una soluzione per creare un data lake Apache Iceberg ad alte prestazioni su Amazon S3; elaborare dati incrementali con istruzioni SQL di inserimento, aggiornamento ed eliminazione; e ottimizzare la tabella Iceberg per migliorare le prestazioni di lettura e scrittura. Il diagramma seguente illustra l'architettura della soluzione.
Per dimostrare questa soluzione, usiamo il Commenti dei clienti Amazon set di dati in un bucket S3 (s3://amazon-reviews-pds/parquet/
). Nel caso d'uso reale, sarebbero dati grezzi archiviati nel tuo bucket S3. Possiamo controllare la dimensione dei dati con il seguente codice nel file Interfaccia della riga di comando di AWS (AWS CLI):
Il numero totale di oggetti è 430 e la dimensione totale è 47.4 GiB.
Per configurare e testare questa soluzione, completiamo i seguenti passaggi di alto livello:
- Configura un bucket S3 nella zona curata per archiviare i dati convertiti in formato tabella Iceberg.
- Avvia un cluster EMR con le configurazioni appropriate per Apache Iceberg.
- Crea un taccuino in EMR Studio.
- Configura la sessione Spark per Apache Iceberg.
- Converti i dati nel formato tabella Iceberg e sposta i dati nella zona curata.
- Esegui query di inserimento, aggiornamento ed eliminazione in Athena per elaborare dati incrementali.
- Eseguire l'ottimizzazione delle prestazioni.
Prerequisiti
Per seguire questa procedura dettagliata, è necessario disporre di un file Account AWS con Gestione dell'identità e dell'accesso di AWS (IAM) con accesso sufficiente per eseguire il provisioning delle risorse richieste.
Configura il bucket S3 per i dati Iceberg nella zona curata nel tuo data lake
Scegli la regione in cui desideri creare il bucket S3 e fornisci un nome univoco:
Avvia un cluster EMR per eseguire processi Iceberg utilizzando Spark
Puoi creare un cluster EMR dal file Console di gestione AWS, CLI di Amazon EMR o Kit di sviluppo cloud AWS (AWSCDK). In questo post, ti spieghiamo come creare un cluster EMR dalla console.
- Sulla console Amazon EMR, scegli Crea cluster.
- Scegli Opzioni avanzate.
- Nel Configurazione software, scegli l'ultima versione di Amazon EMR. A partire da gennaio 2023, l'ultima versione è la 6.9.0. Iceberg richiede la versione 6.5.0 e successive.
- Seleziona JupyterEnterpriseGateway ed Scintilla come il software da installare.
- Nel Modifica le impostazioni del software, selezionare Accedi alla configurazione ed entra
[{"classification":"iceberg-defaults","properties":{"iceberg.enabled":true}}]
. - Lascia le altre impostazioni come predefinite e scegli Avanti.
- Nel Hardware, utilizzare l'impostazione predefinita.
- Scegli Avanti.
- Nel Nome del cluster, inserisci un nome. Noi usiamo
iceberg-blog-cluster
. - Lascia invariate le restanti impostazioni e scegli Avanti.
- Scegli Crea cluster.
Crea un taccuino in EMR Studio
Ora ti mostriamo come creare un notebook in EMR Studio dalla console.
- Sulla console IAM, creare un ruolo di servizio EMR Studio.
- Sulla console Amazon EMR, scegli Studio EMR.
- Scegli Inizia.
I Inizia la pagina viene visualizzata in una nuova scheda.
- Scegli Crea Studio nella nuova scheda.
- Inserisci un nome. Usiamo iceberg-studio.
- Scegli lo stesso VPC e la stessa sottorete di quelli per il cluster EMR e il gruppo di sicurezza predefinito.
- Scegli AWS Identity and Access Management (IAM) per l'autenticazione e scegli il ruolo del servizio EMR Studio che hai appena creato.
- Scegli un percorso S3 per Backup delle aree di lavoro.
- Scegli Crea Studio.
- Dopo aver creato Studio, scegli l'URL di accesso a Studio.
- Nella dashboard di EMR Studio, scegli Crea spazio di lavoro.
- Inserisci un nome per il tuo spazio di lavoro. Noi usiamo
iceberg-workspace
. - Espandere Configurazione avanzata e scegli Collega Workspace a un cluster EMR.
- Scegli il cluster EMR che hai creato in precedenza.
- Scegli Crea spazio di lavoro.
- Scegli il nome dell'area di lavoro per aprire una nuova scheda.
Nel riquadro di navigazione è presente un notebook con lo stesso nome dell'area di lavoro. Nel nostro caso, è un'area di lavoro iceberg.
- Apri il taccuino.
- Quando ti viene chiesto di scegliere un kernel, scegli Scintilla.
Configura una sessione Spark per Apache Iceberg
Utilizza il seguente codice, fornendo il tuo nome bucket S3:
Questo imposta le seguenti configurazioni della sessione Spark:
- spark.sql.catalog.demo – Registra un catalogo Spark denominato demo, che utilizza il plug-in del catalogo Iceberg Spark.
- spark.sql.catalog.demo.catalog-impl – Il catalogo Spark demo utilizza AWS Glue come catalogo fisico per archiviare il database Iceberg e le informazioni sulla tabella.
- spark.sql.catalog.demo.warehouse – Il catalogo Spark demo archivia tutti i metadati e i file di dati Iceberg nel percorso root definito da questa proprietà:
s3://iceberg-curated-blog-data
. - spark.sql.extensions – Aggiunge il supporto alle estensioni Iceberg Spark SQL, che consente di eseguire le procedure Iceberg Spark e alcuni comandi SQL solo Iceberg (da utilizzare in un passaggio successivo).
- spark.sql.catalog.demo.io-impl – Iceberg consente agli utenti di scrivere dati su Amazon S3 tramite S3FileIO. Il catalogo dati di AWS Glue per impostazione predefinita utilizza questo FileIO e altri cataloghi possono caricare questo FileIO utilizzando la proprietà del catalogo io-impl.
Converti i dati in formato tabella Iceberg
Puoi utilizzare Spark su Amazon EMR o Athena per caricare la tabella Iceberg. Nella sessione Spark del notebook EMR Studio Workspace, esegui i seguenti comandi per caricare i dati:
Dopo aver eseguito il codice, dovresti trovare due prefissi creati nel percorso S3 del tuo data warehouse (s3://iceberg-curated-blog-data/reviews.db/all_reviews
): dati e metadati.
Elabora dati incrementali utilizzando istruzioni SQL di inserimento, aggiornamento ed eliminazione in Athena
Athena è un motore di query senza server che puoi usare per eseguire attività di lettura, scrittura, aggiornamento e ottimizzazione su tabelle Iceberg. Per dimostrare in che modo il formato del data lake Apache Iceberg supporta l'inserimento di dati incrementali, eseguiamo istruzioni SQL insert, update ed delete sul data lake.
Vai alla console di Athena e scegli Editor di query. Se è la prima volta che utilizzi l'editor di query Athena, devi farlo configurare la posizione dei risultati della query per essere il bucket S3 che hai creato in precedenza. Dovresti essere in grado di vedere che la tabella reviews.all_reviews è disponibile per l'interrogazione. Esegui la seguente query per verificare di aver caricato correttamente la tabella Iceberg:
Elabora dati incrementali eseguendo istruzioni SQL di inserimento, aggiornamento ed eliminazione:
Ottimizzazione delle prestazioni
In questa sezione, esaminiamo diversi modi per migliorare le prestazioni di lettura e scrittura di Apache Iceberg.
Configurare le proprietà della tabella Apache Iceberg
Apache Iceberg è un formato di tabella e supporta le proprietà della tabella per configurare il comportamento della tabella come lettura, scrittura e catalogazione. È possibile migliorare le prestazioni di lettura e scrittura sulle tabelle Iceberg regolando le proprietà della tabella.
Ad esempio, se si nota che si scrivono troppi file piccoli per una tabella Iceberg, è possibile configurare la dimensione del file di scrittura per scrivere meno file ma di dimensioni maggiori, per migliorare le prestazioni delle query.
Immobili | Predefinito | Descrizione |
write.target-file-size-bytes | 536870912 (512 MB) | Controlla la dimensione dei file generati per la destinazione su questo numero di byte |
Utilizzare il seguente codice per modificare il formato della tabella:
Partizionamento e ordinamento
Per velocizzare l'esecuzione di una query, meno dati vengono letti, meglio è. Iceberg sfrutta i ricchi metadati che acquisisce al momento della scrittura e facilita tecniche come la pianificazione della scansione, il partizionamento, l'eliminazione e le statistiche a livello di colonna come i valori min/max per ignorare i file di dati che non hanno record di corrispondenza. Ti spieghiamo come funzionano la pianificazione e il partizionamento della scansione delle query in Iceberg e come li usiamo per migliorare le prestazioni delle query.
Pianificazione della scansione delle query
Per una determinata query, il primo passaggio in un motore di query è la pianificazione della scansione, che è il processo per trovare i file in una tabella necessari per una query. La pianificazione in una tabella Iceberg è molto efficiente, perché i ricchi metadati di Iceberg possono essere usati per eliminare i file di metadati che non sono necessari, oltre a filtrare i file di dati che non contengono dati corrispondenti. Nei nostri test, abbiamo osservato che Athena ha scansionato il 50% o meno di dati per una determinata query su una tabella Iceberg rispetto ai dati originali prima della conversione in formato Iceberg.
Esistono due tipi di filtraggio:
- Filtraggio dei metadati – Iceberg utilizza due livelli di metadati per tenere traccia dei file in un'istantanea: l'elenco manifest e i file manifest. Utilizza innanzitutto l'elenco manifest, che funge da indice dei file manifest. Durante la pianificazione, Iceberg filtra i manifest utilizzando l'intervallo di valori della partizione nell'elenco manifest senza leggere tutti i file manifest. Quindi utilizza i file manifest selezionati per ottenere i file di dati.
- Filtraggio dei dati – Dopo aver selezionato l'elenco dei file manifest, Iceberg utilizza i dati della partizione e le statistiche a livello di colonna per ciascun file di dati archiviato nei file manifest per filtrare i file di dati. Durante la pianificazione, i predicati di query vengono convertiti in predicati sui dati della partizione e applicati prima per filtrare i file di dati. Quindi, le statistiche di colonna come i conteggi dei valori a livello di colonna, i conteggi null, i limiti inferiori e i limiti superiori vengono utilizzati per filtrare i file di dati che non possono corrispondere al predicato della query. Utilizzando i limiti superiore e inferiore per filtrare i file di dati in fase di pianificazione, Iceberg migliora notevolmente le prestazioni delle query.
Partizionamento e ordinamento
Il partizionamento è un modo per raggruppare i record con gli stessi valori di colonna chiave per iscritto. Il vantaggio del partizionamento consiste in query più veloci che accedono solo a una parte dei dati, come spiegato in precedenza in Pianificazione della scansione delle query: filtraggio dei dati. Iceberg semplifica il partizionamento supportando il partizionamento nascosto, nel modo in cui Iceberg produce valori di partizione prendendo un valore di colonna e opzionalmente trasformandolo.
Nel nostro caso d'uso, eseguiamo prima la seguente query sulla tabella Iceberg non partizionata. Quindi partizioniamo la tabella Iceberg in base alla categoria delle recensioni, che verrà utilizzata nella condizione WHERE della query per filtrare i record. Con il partizionamento, la query potrebbe eseguire la scansione di molti meno dati. Vedere il seguente codice:
Esegui la seguente istruzione select sulla tabella all_reviews non partizionata rispetto alla tabella partizionata per vedere la differenza di prestazioni:
La tabella seguente mostra il miglioramento delle prestazioni del partizionamento dei dati, con circa il 50% di miglioramento delle prestazioni e il 70% in meno di dati analizzati.
Nome set di dati | Set di dati non partizionato | Set di dati partizionato |
Autonomia (secondi) | 8.20 | 4.25 |
Dati scansionati (MB) | 131.55 | 33.79 |
Si noti che il runtime è il runtime medio con più esecuzioni nel nostro test.
Abbiamo visto un buon miglioramento delle prestazioni dopo il partizionamento. Tuttavia, questo può essere ulteriormente migliorato utilizzando le statistiche a livello di colonna dai file manifest di Iceberg. Per utilizzare in modo efficace le statistiche a livello di colonna, è necessario ordinare ulteriormente i record in base ai modelli di query. L'ordinamento dell'intero set di dati utilizzando le colonne che vengono spesso utilizzate nelle query riordinerà i dati in modo tale che ogni file di dati finisca con un intervallo di valori univoco per le colonne specifiche. Se queste colonne vengono utilizzate nella condizione di query, consente ai motori di query di ignorare ulteriormente i file di dati, consentendo in tal modo query ancora più veloci.
Copia su scrittura vs. lettura su unione
Quando si implementa l'aggiornamento e l'eliminazione sulle tabelle Iceberg nel data lake, esistono due approcci definiti dalle proprietà della tabella Iceberg:
- Copia su scrittura – Con questo approccio, quando vengono apportate modifiche alla tabella Iceberg, aggiornamenti o eliminazioni, i file di dati associati ai record interessati verranno duplicati e aggiornati. I record verranno aggiornati o eliminati dai file di dati duplicati. Verrà creato un nuovo snapshot della tabella Iceberg che punta alla versione più recente dei file di dati. Ciò rende le scritture complessive più lente. Potrebbero esserci situazioni in cui sono necessarie scritture simultanee con conflitti, quindi è necessario riprovare, il che aumenta ulteriormente il tempo di scrittura. D'altra parte, durante la lettura dei dati, non è necessario alcun processo aggiuntivo. La query recupererà i dati dall'ultima versione dei file di dati.
- Unisci in lettura – Con questo approccio, quando ci sono aggiornamenti o cancellazioni sulla tabella Iceberg, i file di dati esistenti non verranno riscritti; verranno invece creati nuovi file di eliminazione per tenere traccia delle modifiche. Per le eliminazioni, verrà creato un nuovo file di eliminazione con i record eliminati. Durante la lettura della tabella Iceberg, il file di eliminazione verrà applicato ai dati recuperati per filtrare i record di eliminazione. Per gli aggiornamenti, verrà creato un nuovo file di eliminazione per contrassegnare i record aggiornati come eliminati. Quindi verrà creato un nuovo file per quei record ma con valori aggiornati. Durante la lettura della tabella Iceberg, sia l'eliminazione che il nuovo file verranno applicati ai dati recuperati per riflettere le modifiche più recenti e produrre i risultati corretti. Pertanto, per tutte le query successive, si verificherà un ulteriore passaggio per unire i file di dati con l'eliminazione e i nuovi file, il che di solito aumenterà il tempo di query. D'altra parte, le scritture potrebbero essere più veloci perché non è necessario riscrivere i file di dati esistenti.
Per testare l'impatto dei due approcci, puoi eseguire il codice seguente per impostare le proprietà della tabella Iceberg:
Esegui l'aggiornamento, elimina e seleziona le istruzioni SQL in Athena per mostrare la differenza di runtime per copia su scrittura e unione su lettura:
La tabella seguente riepiloga i tempi di esecuzione delle query.
domanda | Copia su scrittura | Unisci in lettura | ||||
AGGIORNAMENTO | DELETE | SELEZIONA | AGGIORNAMENTO | DELETE | SELEZIONA | |
Autonomia (secondi) | 66.251 | 116.174 | 97.75 | 10.788 | 54.941 | 113.44 |
Dati scansionati (MB) | 494.06 | 3.07 | 137.16 | 494.06 | 3.07 | 137.16 |
Si noti che il runtime è il runtime medio con più esecuzioni nel nostro test.
Come mostrano i risultati dei nostri test, ci sono sempre dei compromessi nei due approcci. L'approccio da utilizzare dipende dai casi d'uso. In sintesi, le considerazioni si riducono alla latenza sulla lettura rispetto alla scrittura. Puoi fare riferimento alla tabella seguente e fare la scelta giusta.
. | Copia su scrittura | Unisci in lettura |
Vantaggi | Letture più veloci | Scritture più veloci |
Svantaggi | Scritture costose | Maggiore latenza nelle letture |
Quando usare | Buono per letture frequenti, aggiornamenti ed eliminazioni poco frequenti o aggiornamenti batch di grandi dimensioni | Buono per le tabelle con frequenti aggiornamenti ed eliminazioni |
Compattazione dei dati
Se la dimensione del tuo file di dati è piccola, potresti ritrovarti con migliaia o milioni di file in una tabella Iceberg. Ciò aumenta notevolmente l'operazione di I/O e rallenta le query. Inoltre, Iceberg tiene traccia di ogni file di dati in un set di dati. Più file di dati portano a più metadati. Ciò a sua volta aumenta l'overhead e l'operazione di I/O durante la lettura dei file di metadati. Per migliorare le prestazioni delle query, si consiglia di compattare piccoli file di dati in file di dati più grandi.
Durante l'aggiornamento e l'eliminazione dei record nella tabella Iceberg, se viene utilizzato l'approccio read-on-merge, potresti finire con molte piccole eliminazioni o nuovi file di dati. L'esecuzione della compattazione combinerà tutti questi file e creerà una versione più recente del file di dati. Ciò elimina la necessità di riconciliarli durante le letture. Si consiglia di eseguire lavori di compattazione regolari per influire il meno possibile sulle letture pur mantenendo una velocità di scrittura più elevata.
Eseguire il seguente comando di compattazione dei dati, quindi eseguire la query di selezione da Athena:
La tabella seguente confronta il tempo di esecuzione prima e dopo la compattazione dei dati. Puoi vedere un miglioramento delle prestazioni di circa il 40%.
domanda | Prima della compattazione dei dati | Dopo la compattazione dei dati |
Autonomia (secondi) | 97.75 | 32.676 secondi |
Dati scansionati (MB) | 137.16 M | 189.19 M |
Si noti che le query selezionate sono state eseguite su all_reviews
tabella dopo le operazioni di aggiornamento e cancellazione, prima e dopo la compattazione dei dati. Il runtime è il runtime medio con più esecuzioni nel nostro test.
ripulire
Dopo aver seguito la procedura dettagliata della soluzione per eseguire i casi d'uso, completare i seguenti passaggi per ripulire le risorse ed evitare ulteriori costi:
- Rilascia le tabelle e il database di AWS Glue da Athena o esegui il seguente codice nel tuo notebook:
- Nella console EMR Studio, scegli Aree di lavoro nel pannello di navigazione.
- Seleziona l'area di lavoro che hai creato e scegli Elimina.
- Nella console EMR, vai a Studios .
- Seleziona lo Studio che hai creato e scegli Elimina.
- Nella console EMR, scegli Cluster nel pannello di navigazione.
- Seleziona il cluster e scegli Terminare.
- Elimina il bucket S3 e qualsiasi altra risorsa che hai creato come parte dei prerequisiti per questo post.
Conclusione
In questo post, abbiamo presentato il framework Apache Iceberg e come aiuta a risolvere alcune delle sfide che abbiamo in un moderno data lake. Quindi ti abbiamo mostrato una soluzione per elaborare dati incrementali in un data lake utilizzando Apache Iceberg. Infine, abbiamo approfondito l'ottimizzazione delle prestazioni per migliorare le prestazioni di lettura e scrittura per i nostri casi d'uso.
Ci auguriamo che questo post fornisca alcune informazioni utili per decidere se si desidera adottare Apache Iceberg nella propria soluzione di data lake.
Informazioni sugli autori
Flora Wu è Sr. Resident Architect presso AWS Data Lab. Aiuta i clienti aziendali a creare strategie di analisi dei dati e creare soluzioni per accelerare i risultati aziendali. Nel tempo libero le piace giocare a tennis, ballare la salsa e viaggiare.
Daniel Li è Senior Solutions Architect presso Amazon Web Services. Si concentra sull'aiutare i clienti a sviluppare, adottare e implementare servizi e strategie cloud. Quando non lavora, gli piace passare il tempo all'aria aperta con la sua famiglia.
- Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
- Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. Accedi qui.
- Fonte: https://aws.amazon.com/blogs/big-data/use-apache-iceberg-in-a-data-lake-to-support-incremental-data-processing/
- 10
- 100
- 11
- 2022
- 2023
- 7
- 9
- a
- capace
- Chi siamo
- sopra
- accelerare
- accesso
- gestione degli accessi
- Action
- atti
- aggiunta
- aggiuntivo
- indirizzo
- indirizzi
- Aggiunge
- adottare
- Vantaggio
- Dopo shavasana, sedersi in silenzio; saluti;
- contro
- Tutti
- consente
- sempre
- Amazon
- Amazon EMR
- Amazon Web Services
- Analitico
- analitica
- ed
- ha annunciato
- Apache
- applicazioni
- applicato
- approccio
- approcci
- opportuno
- architettura
- associato
- Autenticazione
- disponibilità
- disponibile
- media
- evitare
- AWS
- Colla AWS
- basato
- perché
- diventare
- prima
- beneficio
- Meglio
- fra
- maggiore
- bootstrap
- costruire
- Costruzione
- aziende
- cattura
- Catturare
- Custodie
- casi
- catalogo
- cataloghi
- Categoria
- sfide
- il cambiamento
- Modifiche
- dai un'occhiata
- scegliere
- Scegli
- classificazione
- Cloud
- servizi cloud
- Cluster
- codice
- Colonna
- colonne
- combinare
- Venire
- commettere
- rispetto
- completamento di una
- Calcolare
- concorrente
- condizione
- configurazioni
- Considerazioni
- consolle
- Conversione
- convertito
- costo effettivo
- Costi
- potuto
- creare
- creato
- crea
- a cura
- Corrente
- cliente
- Clienti
- Danza
- cruscotto
- dati
- Dati Analytics
- Lago di dati
- elaborazione dati
- data warehouse
- Banca Dati
- dataset
- deep
- profonda immersione
- Predefinito
- definito
- Dimo
- dimostrare
- dipende
- progettato
- dettagli
- sviluppare
- Mercato
- differenza
- diverso
- discutere
- Dont
- giù
- drammaticamente
- Cadere
- durante
- ogni
- In precedenza
- Presto
- editore
- in maniera efficace
- efficiente
- o
- elimina
- abilitato
- consentendo
- finisce
- motore
- Motori
- entrare
- Impresa
- clienti aziendali
- Etere (ETH)
- Anche
- evoluzione
- evolvere
- evoluzione
- esempio
- esistente
- esiste
- ha spiegato
- estensioni
- extra
- facilita
- famiglia
- FAST
- più veloce
- Caratteristiche
- figura
- Compila il
- File
- filtro
- filtraggio
- filtri
- Infine
- Trovare
- Nome
- prima volta
- si concentra
- seguire
- i seguenti
- formato
- Contesto
- frequente
- da
- ulteriormente
- Inoltre
- Generale
- generato
- ottenere
- dato
- va
- buono
- molto
- Gruppo
- cura
- accadere
- Aiuto
- aiutare
- aiuta
- nascosto
- gerarchia
- alto livello
- Alte prestazioni
- ad alte prestazioni
- Alveare
- speranza
- Come
- Tutorial
- Tuttavia
- HTML
- HTTPS
- IAM
- Identità
- identità e gestione degli accessi
- Impact
- impattato
- realizzare
- implementazione
- Implementazione
- competenze
- migliorata
- miglioramento
- migliora
- in
- Compreso
- Aumento
- è aumentato
- Aumenta
- Index
- individuale
- informazioni
- install
- invece
- integrazione
- introdotto
- Gli isolati
- IT
- Gennaio
- Offerte di lavoro
- Le
- laboratorio
- lago
- grandi
- superiore, se assunto singolarmente.
- Latenza
- con i più recenti
- ultima uscita
- strato
- galline ovaiole
- portare
- livelli
- LIMITE
- linea
- Lista
- piccolo
- caricare
- località
- make
- FA
- gestione
- molti
- marchio
- mercato
- partita
- corrispondenza
- Unire
- Metadati
- forza
- milioni
- moderno
- Scopri di più
- cambiano
- multiplo
- Nome
- Detto
- Navigare
- Navigazione
- Bisogno
- di applicazione
- esigenze
- New
- taccuino
- oggetto
- aprire
- operazione
- Operazioni
- ottimizzazione
- OTTIMIZZA
- minimo
- i
- Altro
- all'aperto
- complessivo
- proprio
- vetro
- parte
- sentiero
- modelli
- eseguire
- performance
- Fisico
- pianificazione
- Platone
- Platone Data Intelligence
- PlatoneDati
- gioco
- plug-in
- punti
- Popolare
- possibile
- Post
- alimentato
- prerequisiti
- procedure
- processi
- lavorazione
- produrre
- proprietà
- proprietà
- fornire
- fornisce
- fornitura
- fornitura
- gamma
- Crudo
- dati grezzi
- Leggi
- Lettura
- di rose
- recentemente
- raccomandato
- record
- riflettere
- regione
- registri
- Basic
- rilasciare
- rilasciato
- rimanente
- necessario
- richiede
- Risorse
- colpevole
- Risultati
- Recensioni
- Ricco
- Ruolo
- radice
- Correre
- running
- stesso
- scansione
- secondo
- Sezione
- problemi di
- selezionato
- Selezione
- serverless
- servizio
- Servizi
- Sessione
- set
- Set
- regolazione
- impostazioni
- dovrebbero
- mostrare attraverso le sue creazioni
- Spettacoli
- Un'espansione
- situazioni
- Taglia
- rallenta
- piccole
- Istantanea
- So
- Software
- soluzione
- Soluzioni
- alcuni
- Scintilla
- specifico
- velocità
- Spendere
- SQL
- Di partenza
- Regione / Stato
- dichiarazione
- dichiarazioni
- stats
- step
- Passi
- Ancora
- conservazione
- Tornare al suo account
- memorizzati
- negozi
- strategie
- Strategia
- strutturato
- dati strutturati e non strutturati
- studio
- sottorete
- successivo
- Con successo
- tale
- sufficiente
- SOMMARIO
- supporto
- supportato
- Supporto
- supporti
- tavolo
- prende
- presa
- Target
- task
- tecniche
- tennis
- test
- Testing
- test
- I
- le informazioni
- Lo Stato
- loro
- in tal modo
- migliaia
- tre
- Attraverso
- tempo
- tempo di percorrenza
- a
- insieme
- pure
- strumenti
- top
- Totale
- pista
- Le transazioni
- trasformazione
- viaggiare
- Di viaggio
- TURNO
- Tipi di
- per
- unico
- Aggiornanento
- aggiornato
- Aggiornamenti
- aggiornamento
- URL
- uso
- caso d'uso
- utenti
- generalmente
- VAL
- APPREZZIAMO
- Valori
- verificare
- versione
- camminava
- walkthrough
- Magazzino
- orologi
- modi
- sito web
- servizi web
- Che
- se
- quale
- while
- largo
- Vasta gamma
- volere
- senza
- Lavora
- lavoro
- lavori
- sarebbe
- scrivere
- scrittura
- Trasferimento da aeroporto a Sharm
- zefiro