Migrazione da Oracle a BigQuery

Questo documento fornisce indicazioni di alto livello su come eseguire la migrazione da Oracle a BigQuery. Descrive le differenze architetturali fondamentali e suggerisce modi per eseguire la migrazione da data warehouse e data mart in esecuzione su Oracle RDBMS (incluso Exadata) a BigQuery. Questo documento fornisce dettagli applicabili anche a Exadata, ExaCC e Oracle Autonomous Data Warehouse, in quanto utilizzano software Oracle compatibile.

Questo documento è rivolto ad architetti aziendali, database, sviluppatori di applicazioni e professionisti della sicurezza IT che vogliono eseguire la migrazione da Oracle a BigQuery e risolvere le sfide tecniche nel processo di migrazione.

Puoi anche utilizzare la traduzione SQL batch per eseguire la migrazione in blocco degli script SQL oppure la traduzione SQL interattiva per tradurre query ad hoc. Oracle SQL, PL/SQL ed Exadata sono supportati da entrambi gli strumenti in anteprima.

Pre-migrazione

Per garantire la corretta migrazione del data warehouse, inizia a pianificare la strategia di migrazione fin dalle prime fasi del progetto. Per informazioni su come pianificare in modo sistematico il lavoro di migrazione, vedi Che cosa e come eseguire la migrazione: framework di migrazione.

Pianificazione della capacità di BigQuery

Di base, la velocità effettiva dell'analisi in BigQuery viene misurata in slot. Uno slot BigQuery è l'unità di capacità di calcolo di proprietà di Google richiesta per eseguire query SQL.

BigQuery calcola continuamente quanti slot sono richiesti dalle query durante l'esecuzione, ma alloca gli slot alle query in base a un fair scheduler.

Puoi scegliere tra i seguenti modelli di prezzi durante la pianificazione della capacità per gli slot BigQuery:

  • Prezzi on demand: nel modello con prezzi on demand, BigQuery addebita il numero di byte elaborati (dimensioni dei dati), quindi paghi solo per le query eseguite. Per ulteriori informazioni su come BigQuery determina le dimensioni dei dati, consulta Calcolo delle dimensioni dei dati. Poiché gli slot determinano la capacità di calcolo sottostante, puoi pagare l'utilizzo di BigQuery a seconda del numero di slot necessari (anziché i byte elaborati). Per impostazione predefinita, i progetti Google Cloud sono limitati a un massimo di 2000 slot.

  • Prezzi basati sulla capacità: con i prezzi basati sulla capacità, acquisti prenotazioni di slot BigQuery (almeno 100) anziché pagare per i byte elaborati dalle query che esegui. Consigliamo prezzi basati sulla capacità per i carichi di lavoro dei data warehouse aziendali, che di solito prevedono molte query simultanee di reporting ed estrazione, trasformazione del carico e trasformazioni del carico (ELT) con un consumo prevedibile.

Per facilitare la stima degli slot, consigliamo di configurare il monitoraggio di BigQuery mediante Cloud Monitoring e di analizzare gli audit log utilizzando BigQuery. Molti clienti utilizzano Looker Studio (ad esempio, vedi un esempio open source di una dashboard di Looker Studio), Looker o Tableau come frontend per visualizzare i dati del log di controllo di BigQuery, in particolare per l'utilizzo degli slot in query e progetti. Puoi anche sfruttare i dati delle tabelle di sistema BigQuery per monitorare l'utilizzo degli slot in job e prenotazioni. Per un esempio, vedi un esempio open source di una dashboard di Looker Studio.

Il monitoraggio e l'analisi regolari dell'utilizzo degli slot consentono di stimare il numero totale di slot necessari alla tua organizzazione man mano che cresci su Google Cloud.

Ad esempio, supponiamo che inizialmente tu prenoti 4000 slot BigQuery per eseguire contemporaneamente 100 query a complessità media. Se noti tempi di attesa elevati nei piani di esecuzione delle tue query e le tue dashboard mostrano un elevato utilizzo degli slot, questo potrebbe indicare la necessità di ulteriori slot BigQuery per supportare i tuoi carichi di lavoro. Se vuoi acquistare slot autonomamente con impegni annuali o triennali, puoi iniziare a utilizzare le prenotazioni BigQuery utilizzando la console Google Cloud o lo strumento a riga di comando bq.

Per qualsiasi domanda relativa al tuo piano attuale e alle opzioni precedenti, contatta il tuo rappresentante di vendita.

Security in Google Cloud Platform

Le sezioni seguenti descrivono i controlli di sicurezza comuni di Oracle e come garantire che il tuo data warehouse rimanga protetto in un ambiente Google Cloud.

Identity and Access Management (IAM)

Oracle fornisce utenti, privilegi, ruoli e profili per gestire l'accesso alle risorse.

BigQuery utilizza IAM per gestire l'accesso alle risorse e fornisce una gestione dell'accesso centralizzata a risorse e azioni. I tipi di risorse disponibili in BigQuery includono organizzazioni, progetti, set di dati, tabelle e viste. Nella gerarchia dei criteri IAM, i set di dati sono risorse figlio dei progetti. Una tabella eredita le autorizzazioni dal set di dati che la contiene.

Per concedere l'accesso a una risorsa, assegna uno o più ruoli a un account utente, gruppo o di servizio. I ruoli di organizzazione e progetto influiscono sulla capacità di eseguire job o gestire il progetto, mentre i ruoli del set di dati influiscono sulla possibilità di accedere o modificare i dati all'interno di un progetto.

IAM offre i seguenti tipi di ruoli:

  • I ruoli predefiniti sono pensati per supportare casi d'uso comuni e pattern di controllo dell'accesso. I ruoli predefiniti forniscono accesso granulare a un servizio specifico e sono gestiti da Google Cloud.

  • I ruoli di base includono i ruoli Proprietario, Editor e Visualizzatore.

  • I ruoli personalizzati forniscono un accesso granulare in base all'elenco di autorizzazioni specificate dall'utente.

Quando assegni a un utente ruoli sia predefiniti che di base, le autorizzazioni concesse corrispondono a quelle di ogni singolo ruolo.

Sicurezza a livello di riga

Oracle Label Security (OLS) consente di limitare l'accesso ai dati riga per riga. Un caso d'uso tipico per la sicurezza a livello di riga è limitare l'accesso di un commerciale agli account che gestisce. Implementando la sicurezza a livello di riga, otterrai controllo dell'accesso granulare.

Per ottenere la sicurezza a livello di riga in BigQuery, puoi utilizzare le visualizzazioni autorizzate e i criteri di accesso a livello di riga. Per ulteriori informazioni su come progettare e implementare questi criteri, consulta Introduzione alla sicurezza a livello di riga di BigQuery.

Crittografia completa del disco

Oracle offre la crittografia Transparent Data Encryption (TDE) e la crittografia di rete per la crittografia dei dati at-rest e in transito. TDE richiede l'opzione Advanced Security, che viene concessa in licenza separatamente.

BigQuery cripta tutti i dati at-rest e in in transito per impostazione predefinita, indipendentemente dall'origine o da qualsiasi altra condizione, e questa impostazione non può essere disattivata. BigQuery supporta anche le chiavi di crittografia gestite dal cliente (CMEK) per gli utenti che vogliono controllare e gestire le chiavi di crittografia delle chiavi in Cloud Key Management Service. Per ulteriori informazioni sulla crittografia in Google Cloud, consulta Crittografia at-rest predefinita e Crittografia dei dati in transito.

Mascheramento e oscuramento dei dati

Oracle utilizza il mascheramento dei dati in Real Application Testing e l'oscuramento dei dati, che consente di mascherare (oscurare) i dati restituiti dalle query emesse dalle applicazioni.

BigQuery supporta il mascheramento dinamico dei dati a livello di colonna. Puoi utilizzare il mascheramento dei dati per oscurare selettivamente i dati della colonna per gruppi di utenti, consentendo comunque l'accesso alla colonna.

Puoi utilizzare Sensitive Data Protection per identificare e oscurare le informazioni sensibili che consentono l'identificazione personale (PII) su BigQuery.

Confronto tra BigQuery e Oracle

Questa sezione descrive le principali differenze tra BigQuery e Oracle. Questi punti salienti ti aiutano a identificare gli ostacoli alla migrazione e a pianificare i cambiamenti richiesti.

Architettura di sistema

Una delle principali differenze tra Oracle e BigQuery è che BigQuery è un EDW su cloud serverless con livelli di archiviazione e calcolo separati che possono scalare in base alle esigenze della query. Data la natura dell'offerta serverless di BigQuery, le decisioni hardware non ti limitano, ma puoi richiedere più risorse per le query e gli utenti tramite le prenotazioni. Inoltre, BigQuery non richiede la configurazione del software e dell'infrastruttura sottostanti, come il sistema operativo, i sistemi di rete e i sistemi di archiviazione, compresi scalabilità e alta disponibilità. BigQuery si occupa delle operazioni di scalabilità, gestione e amministrazione. Il seguente diagramma illustra la gerarchia dell'archiviazione di BigQuery.

Gerarchia dello spazio di archiviazione di BigQuery

Conoscere l'architettura sottostante di archiviazione ed elaborazione delle query, come la separazione tra archiviazione (Colossus) ed esecuzione delle query (Dremel), e il modo in cui Google Cloud alloca le risorse (Borg) può essere utile per comprendere le differenze di comportamento e ottimizzare le prestazioni delle query e l'efficienza in termini di costi. Per maggiori dettagli, vedi le architetture dei sistemi di riferimento per BigQuery, Oracle ed Exadata.

Architettura di dati e archiviazione

La struttura dei dati e di archiviazione è una parte importante di qualsiasi sistema di analisi dei dati perché influisce su prestazioni, costi, scalabilità ed efficienza delle query.

BigQuery disaccoppia l'archiviazione e il computing e archivia i dati in Colossus, dove i dati vengono compressi e archiviati in un formato a colonne chiamato Condensatore.

BigQuery opera direttamente su dati compressi senza decomprimere con Capacitor. BigQuery fornisce un set di dati come l'astrazione di massimo livello per organizzare l'accesso alle tabelle come mostrato nel diagramma precedente. Per un'ulteriore organizzazione delle tabelle puoi utilizzare schemi ed etichette. BigQuery offre il partizionamento per migliorare le prestazioni e i costi delle query e per gestire il ciclo di vita delle informazioni. Le risorse di archiviazione vengono allocate man mano che le consumi e distribuite man mano che rimuovi dati o elimini tabelle.

Oracle archivia i dati in formato riga utilizzando il formato a blocchi Oracle organizzato in segmenti. Gli schemi (di proprietà degli utenti) vengono usati per organizzare le tabelle e altri oggetti di database. A partire da Oracle 12c, il multitenant viene utilizzato per creare database collegabili all'interno di un'istanza di database per isolare ulteriormente il problema. Il partizionamento può essere utilizzato per migliorare le prestazioni delle query e le operazioni del ciclo di vita delle informazioni. Oracle offre diverse opzioni di archiviazione per database autonomi e RAC (Real Application Clusters) come ASM, un file system del sistema operativo e un file system di cluster.

Exadata offre un'infrastruttura di archiviazione ottimizzata nei server a celle di archiviazione e consente ai server Oracle di accedere a questi dati in modo trasparente utilizzando ASM. Exadata offre opzioni di compressione ibrida a colonne (HCC) per consentire agli utenti di comprimere tabelle e partizioni.

Oracle richiede capacità di archiviazione di cui è stato eseguito il pre-provisioning, un dimensionamento accurato e configurazioni di incremento automatico su segmenti, file di dati e spazi delle tabelle.

Esecuzione e prestazioni delle query

BigQuery gestisce le prestazioni e scala a livello di query per massimizzare le prestazioni a fronte del costo. BigQuery utilizza molte ottimizzazioni, ad esempio:

BigQuery raccoglie le statistiche delle colonne durante il caricamento dei dati e include informazioni diagnostiche relative a piano di query e tempistiche. Le risorse per le query vengono allocate in base al tipo e alla complessità della query. Ogni query utilizza un certo numero di slot, che sono unità di calcolo che includono una certa quantità di CPU e RAM.

Oracle offre offerte di lavoro per la raccolta di statistica dei dati. Lo ottimizzatore del database utilizza le statistiche per fornire piani di esecuzione ottimali. Gli indici potrebbero essere necessari per ricerche rapide di righe e operazioni di join. Oracle fornisce inoltre un archivio di colonne in memoria per l'analisi in memoria. Exadata offre diversi miglioramenti delle prestazioni, come la scansione intelligente delle celle, gli indici di archiviazione, la cache flash e le connessioni InfiniBand tra i server di archiviazione e i server di database. È possibile utilizzare Real Application Clusters (RAC) per ottenere l'alta disponibilità del server e scalare le applicazioni del database che richiedono un uso intensivo della CPU utilizzando lo stesso spazio di archiviazione sottostante.

L'ottimizzazione delle prestazioni delle query con Oracle richiede un'attenta valutazione di queste opzioni e parametri del database. Oracle fornisce diversi strumenti come Active Session History (ASH), Automatic Database Diagnostic Monitor (ADDM), report Automatic Workload Repository (AWR), monitoraggio SQL e Tuning Advisor e Advisors di annullamento e ottimizzazione della memoria per l'ottimizzazione delle prestazioni.

Analisi agile

In BigQuery puoi abilitare progetti, utenti e gruppi diversi per eseguire query su set di dati in progetti diversi. La separazione dell'esecuzione delle query consente ai team autonomi di lavorare all'interno dei propri progetti senza influire su altri utenti e progetti, separando le quote per gli slot ed eseguendo query sulla fatturazione da altri progetti e dai progetti che ospitano i set di dati.

Disponibilità elevata, backup e ripristino di emergenza

Oracle fornisce Data Guard come soluzione per il ripristino di emergenza e la replica dei database. È possibile configurare Real Application Cluster (RAC) per la disponibilità del server. I backup Recovery Manager (RMAN) possono essere configurati per i backup di database e archivi di log e utilizzati anche per le operazioni di ripristino e ripristino. È possibile utilizzare la funzionalità Database Flashback per i flashback del database al fine di riavvolgere il database fino a un momento specifico. Annulla tablespace contiene snapshot delle tabelle. È possibile eseguire query su snapshot precedenti con la query di flashback e le clausole di query "as of" a seconda delle operazioni DML/DDL eseguite in precedenza e delle impostazioni di annullamento della conservazione. In Oracle, l'intera integrità del database deve essere gestita all'interno di spazi delle tabelle che dipendono dai metadati di sistema, dall'annullamento e dagli spazi delle tabelle corrispondenti, poiché per il backup Oracle è importante un'elevata coerenza e le procedure di ripristino devono includere dati primari completi. Puoi pianificare le esportazioni a livello di schema della tabella se non è necessario il recupero point-in-time in Oracle.

BigQuery è completamente gestito e si differenzia dai sistemi di database tradizionali per quanto riguarda le sue funzionalità di backup. Non devi considerare server, errori di archiviazione, bug di sistema e danni fisici dei dati. BigQuery replica i dati in diversi data center a seconda della località del set di dati per massimizzare l'affidabilità e la disponibilità. La funzionalità multiregionale di BigQuery replica i dati in diverse regioni e protegge dall'indisponibilità di una singola zona all'interno della regione. La funzionalità BigQuery a regione singola replica i dati in zone diverse della stessa regione.

BigQuery consente di eseguire query sugli snapshot storici delle tabelle per un massimo di sette giorni e di ripristinare le tabelle eliminate entro due giorni utilizzando il viaggio nel tempo. Puoi copiare una tabella eliminata (per ripristinarla) utilizzando la snapshot sintassi (dataset.table@timestamp). Puoi esportare dati dalle tabelle BigQuery per ulteriori esigenze di backup, come il ripristino da operazioni utente accidentali. Per i backup si possono usare strategie e pianificazioni di backup comprovate per sistemi di data warehouse (DWH) esistenti.

Le operazioni in batch e la tecnica di creazione di snapshot consentono diverse strategie di backup per BigQuery, quindi non è necessario esportare spesso tabelle e partizioni non modificate. È sufficiente un backup di esportazione della partizione o della tabella al termine dell'operazione di caricamento o ETL. Per ridurre i costi del backup, puoi archiviare i file di esportazione in Cloud Storage Nearline Storage o Coldline Storage e definire un criterio di ciclo di vita per eliminare i file dopo un determinato periodo di tempo, a seconda dei requisiti di conservazione dei dati.

Memorizzazione nella cache

BigQuery offre una cache per utente e, se i dati non cambiano, i risultati delle query vengono memorizzati nella cache per circa 24 ore. Se i risultati vengono recuperati dalla cache, la query non costa nulla.

Oracle offre diverse cache per i dati e i risultati di query come la cache del buffer, la cache dei risultati, la cache Flash Exadata e l'archivio di colonne in memoria.

Connessioni

BigQuery gestisce la gestione delle connessioni e non richiede la configurazione lato server. BigQuery fornisce i driver JDBC e ODBC. Puoi utilizzare la console Google Cloud o la bq command-line tool per query interattive. Puoi utilizzare API REST e librerie client per interagire in modo programmatico con BigQuery. Puoi collegare Fogli Google direttamente a BigQuery e utilizzare driver ODBC e JDBC per connetterti a Excel. Se cerchi un client desktop, esistono strumenti gratuiti come DBeaver.

Oracle fornisce listener, servizi, gestori di servizi, diversi parametri di configurazione e ottimizzazione e server condivisi e dedicati per gestire le connessioni dei database. Oracle fornisce driver JDBC, JDBC Thin, ODBC, Oracle Client e TNS. Per le configurazioni RAC sono necessari listener di scansione, indirizzi IP di scansione e nome di scansione.

Prezzi e licenze

Oracle richiede tariffe per licenze e assistenza in base al numero di core per le versioni di Database e le opzioni di database come RAC, multitenant, Active Data Guard, partizionamento, in memoria, Real Application Testing, GoldenGate e Spatial and Graph.

BigQuery offre opzioni di pricing flessibili in base all'utilizzo di archiviazione, query e inserimento di flussi di dati. BigQuery offre prezzi basati sulla capacità ai clienti che hanno bisogno di costi e capacità di slot prevedibili in regioni specifiche. Gli slot utilizzati per gli inserimenti e i caricamenti di flussi di dati non vengono conteggiati nella capacità degli slot di progetto. Per decidere quanti slot vuoi acquistare per il tuo data warehouse, consulta la pagina sulla pianificazione della capacità di BigQuery.

Inoltre, BigQuery dimezza automaticamente i costi di archiviazione dei dati non modificati archiviati per più di 90 giorni.

Etichettatura

I set di dati, le tabelle e le viste di BigQuery possono essere etichettati con coppie chiave-valore. Le etichette possono essere utilizzate per differenziare i costi di archiviazione e gli storni di addebito interni.

Monitoraggio e audit logging

Oracle offre diversi livelli e tipi di opzioni di auditing del database e funzionalità firewall di audit vault e firewall del database, che sono concessi in licenza separatamente. Oracle fornisce Enterprise Manager per il monitoraggio dei database.

Per BigQuery, Cloud Audit Logs viene utilizzato sia per i log degli accessi ai dati sia per gli audit log, che sono abilitati per impostazione predefinita. I log di accesso ai dati sono disponibili per 30 giorni, mentre gli altri log degli eventi di sistema e delle attività di amministrazione sono disponibili per 400 giorni. Se hai bisogno di un periodo di conservazione più lungo, puoi esportare i log in BigQuery, Cloud Storage o Pub/Sub come descritto in Analisi dei log di sicurezza in Google Cloud. Se è necessaria l'integrazione con uno strumento esistente di monitoraggio degli incidenti, è possibile utilizzare Pub/Sub per le esportazioni e si deve eseguire uno sviluppo personalizzato sullo strumento esistente per leggere i log da Pub/Sub.

Gli audit log includono tutte le chiamate API, le istruzioni per le query e gli stati dei job. Puoi utilizzare Cloud Monitoring per monitorare l'allocazione degli slot, i byte analizzati nelle query e archiviati e altre metrics BigQuery. Puoi utilizzare il piano di query e la sequenza temporale di BigQuery per analizzare le fasi e le prestazioni della query.

Il piano di query.

Per risolvere gli errori relativi a job di query e API, puoi utilizzare la tabella dei messaggi di errore. Per distinguere le allocazioni degli slot per query o job, puoi utilizzare questa utilità, utile per i clienti che utilizzano prezzi basati sulla capacità e hanno molti progetti distribuiti tra diversi team.

Manutenzione, upgrade e versioni

BigQuery è un servizio completamente gestito e non richiede interventi di manutenzione o upgrade. BigQuery non offre versioni diverse. Gli upgrade sono continui e non richiedono tempi di inattività né ostacolano le prestazioni del sistema. Per ulteriori informazioni, vedi Note di rilascio.

Oracle ed Exadata richiedono l'applicazione di patch, upgrade e manutenzione del database e dell'infrastruttura sottostante. Esistono molte versioni di Oracle e ogni anno è prevista il rilascio di una nuova versione principale. Anche se le nuove versioni sono compatibili con le versioni precedenti, le prestazioni, il contesto e le funzionalità delle query possono cambiare.

Possono esserci applicazioni che richiedono versioni specifiche, ad esempio 10g, 11g o 12c. Per i principali upgrade dei database sono necessarie attività di pianificazione e test accurate. La migrazione da versioni diverse può includere esigenze tecniche di conversione diverse su clausole di query e oggetti di database.

Carichi di lavoro

Oracle Exadata supporta carichi di lavoro misti, inclusi quelli OLTP. BigQuery è progettato per l'analisi e non per gestire carichi di lavoro OLTP. I carichi di lavoro OLTP che utilizzano lo stesso Oracle devono essere migrati in Cloud SQL, Spanner o Firestore in Google Cloud. Oracle offre opzioni aggiuntive come Advanced Analytics e Spatial e Graph. Potrebbe essere necessario riscrivere i carichi di lavoro per la migrazione a BigQuery. Per ulteriori informazioni, vedi Migrazione delle opzioni Oracle.

Parametri e impostazioni

Oracle offre e richiede molti parametri per la configurazione e l'ottimizzazione a livello di sistema operativo, database, RAC, ASM e Listener per diversi carichi di lavoro e applicazioni. BigQuery è un servizio completamente gestito e non richiede la configurazione di parametri di inizializzazione.

Limiti e quote

Oracle ha limiti rigidi e flessibili basati su infrastruttura, capacità hardware, parametri, versioni software e licenze. BigQuery ha quote e limiti per azioni e oggetti specifici.

Provisioning di BigQuery

BigQuery è una soluzione Platform as a Service (PaaS) e un data warehouse Cloud con elaborazione massicciamente parallela. La sua capacità consente lo scale up e lo scale down senza alcun intervento da parte dell'utente mentre Google gestisce il backend. Di conseguenza, a differenza di molti sistemi RDBMS, BigQuery non richiede il provisioning delle risorse prima dell'uso. BigQuery alloca le risorse per l'archiviazione e le query in modo dinamico, in base ai pattern di utilizzo. Le risorse di archiviazione vengono allocate man mano che le consumi e distribuite man mano che rimuovi dati o elimini tabelle. Le risorse di query sono allocate in base al tipo di query e alla complessità. Ogni query utilizza gli slot. Viene utilizzato uno scheduler per l'equità finale, quindi potrebbero esserci brevi periodi in cui alcune query ottengono una quota maggiore di slot, ma lo scheduler alla fine corregge il problema.

In termini di VM tradizionali, BigQuery offre l'equivalente di entrambi:

  • Fatturazione al secondo
  • Scalabilità al secondo

Per eseguire questa operazione, BigQuery esegue le seguenti operazioni:

  • Mantiene il deployment di vaste risorse per evitare di dover scalare rapidamente.
  • Utilizza risorse multitenant per allocare istantaneamente blocchi di grandi dimensioni per secondi.
  • Allocazione efficiente delle risorse tra gli utenti mediante economie di scala.
  • Addebita solo i job che esegui, anziché le risorse di cui hai eseguito il deployment, quindi paghi per le risorse utilizzate.

Per ulteriori informazioni sui prezzi, consulta Comprendere la scalabilità rapida e i prezzi semplici di BigQuery.

Migrazione di schemi

Per eseguire la migrazione dei dati da Oracle a BigQuery, devi conoscere i tipi di dati Oracle e le mappature BigQuery.

Tipi di dati Oracle e mappature BigQuery

I tipi di dati Oracle sono diversi da quelli di BigQuery. Per ulteriori informazioni sui tipi di dati di BigQuery, consulta la documentazione ufficiale.

Per un confronto dettagliato tra i tipi di dati Oracle e BigQuery, consulta la guida alla traduzione di Oracle SQL.

Indici

In molti carichi di lavoro analitici, vengono utilizzate le tabelle a colonne al posto degli archivi di righe. Ciò aumenta notevolmente le operazioni basate su colonne ed elimina l'uso di indici per l'analisi in batch. BigQuery archivia i dati anche in formato a colonne, perciò gli indici non sono necessari in BigQuery. Se il carico di lavoro di analisi richiede un unico piccolo insieme di accesso basato su righe, Bigtable può essere un'alternativa migliore. Se un carico di lavoro richiede l'elaborazione delle transazioni con elevata coerenza relazionale, Spanner o Cloud SQL possono essere alternative migliori.

Ricapitolando, non sono necessari indici e vengono offerti in BigQuery per l'analisi in batch. È possibile utilizzare il partizionamento o il clustering. Per ulteriori informazioni su come ottimizzare e migliorare le prestazioni delle query in BigQuery, consulta Introduzione all'ottimizzazione delle prestazioni delle query.

Viste

Analogamente a Oracle, BigQuery consente di creare viste personalizzate. Tuttavia, le viste in BigQuery non supportano le istruzioni DML.

Viste materializzate

Le viste materializzate sono comunemente utilizzate per migliorare i tempi di rendering dei report nei tipi di report e carichi di lavoro di scrittura una volta sola.

Le viste materializzate sono disponibili in Oracle per aumentare le prestazioni delle viste semplicemente creando e gestendo una tabella in cui inserire il set di dati dei risultati della query. Esistono due modi per aggiornare le viste materializzate in Oracle: on-commit e on demand.

In BigQuery è disponibile anche la funzionalità vista materializzata. BigQuery sfrutta i risultati precalcolati delle viste materializzate e, ove possibile, legge solo le modifiche delta dalla tabella di base per calcolare i risultati aggiornati.

Anche le funzionalità di memorizzazione nella cache in Looker Studio o in altri strumenti BI moderni possono migliorare le prestazioni ed eliminare la necessità di eseguire nuovamente la stessa query, risparmiando sui costi.

Partizionamento delle tabelle

Il partizionamento delle tabelle è ampiamente utilizzato nei data warehouse Oracle. A differenza di Oracle, BigQuery non supporta il partizionamento gerarchico.

BigQuery implementa tre tipi di partizionamento delle tabelle che consentono alle query di specificare i filtri dei predicati in base alla colonna di partizionamento per ridurre la quantità di dati analizzati.

Per ulteriori informazioni su limiti e quote applicati alle tabelle partizionate in BigQuery, consulta Introduzione alle tabelle partizionate.

Se le restrizioni di BigQuery influiscono sulla funzionalità del database migrato, valuta l'utilizzo dello sharding anziché del partizionamento.

Inoltre, BigQuery non supporta EXCHANGE PARTITION e SPLIT PARTITION né la conversione di una tabella non partizionata in una tabella partizionata.

Clustering

Il clustering consente di organizzare e recuperare in modo efficiente i dati archiviati in più colonne a cui si accede spesso contemporaneamente. Tuttavia, Oracle e BigQuery hanno circostanze diverse in cui il clustering funziona meglio. In BigQuery, se una tabella viene comunemente filtrata e aggregata con colonne specifiche, utilizza il clustering. Il clustering può essere preso in considerazione per la migrazione di tabelle partizionate in elenco o organizzate per indice da Oracle.

Tabelle temporanee

Le tabelle temporanee vengono spesso utilizzate nelle pipeline ETL Oracle. Una tabella temporanea contiene i dati durante una sessione utente. Questi dati vengono automaticamente eliminati al termine della sessione.

BigQuery utilizza tabelle temporanee per memorizzare nella cache i risultati delle query che non sono stati scritti in una tabella permanente. Al termine della query, le tabelle temporanee rimangono per un massimo di 24 ore. Le tabelle vengono create in un set di dati speciale e denominate in modo casuale. Puoi anche creare tabelle temporanee per uso personale. Per maggiori informazioni, vedi Tabelle temporanee.

Tabelle esterne

Analogamente a Oracle, BigQuery consente di eseguire query su origini dati esterne. BigQuery supporta l'esecuzione di query su dati direttamente da origini dati esterne, tra cui:

  • Amazon Simple Storage Service (Amazon S3)
  • Archiviazione blob Azure
  • Bigtable
  • Spanner
  • Cloud SQL
  • Cloud Storage
  • Google Drive

Modellazione dei dati

I modelli di dati a stella o a fiocco di neve possono essere efficienti per l'archiviazione analitica e sono comunemente utilizzati per i data warehouse su Oracle Exadata.

Le tabelle denormalizzate eliminano le costose operazioni di join e nella maggior parte dei casi offrono prestazioni migliori per l'analisi in BigQuery. BigQuery supporta anche i modelli di dati Star e Snowflake. Per ulteriori dettagli sulla progettazione del data warehouse su BigQuery, consulta Progettazione dello schema.

Confronto tra formato riga e formato colonna e limiti del server rispetto al serverless

Oracle utilizza un formato di riga in cui la riga della tabella è archiviata in blocchi di dati, in modo che le colonne non necessarie vengano recuperate all'interno del blocco per le query di analisi, in base al filtro e all'aggregazione di colonne specifiche.

Oracle dispone di un'architettura condivisa, con dipendenze delle risorse hardware fisse, come memoria e spazio di archiviazione, assegnate al server. Queste sono le due forze principali alla base di molte tecniche di modellazione dei dati che si sono evolute per migliorare l'efficienza dell'archiviazione e le prestazioni delle query analitiche. Gli schemi a stella e a fiocco di neve e la modellazione di Data vault sono alcuni di questi.

BigQuery utilizza un formato a colonne per archiviare i dati e non ha limiti fissi di archiviazione e memoria. Questa architettura consente di denormalizzare e progettare ulteriormente gli schemi in base alle letture e alle esigenze aziendali, riducendo la complessità e migliorando flessibilità, scalabilità e prestazioni.

Denormalizzazione

Uno dei principali obiettivi della normalizzazione dei database relazionali è ridurre la ridondanza dei dati. Sebbene questo modello sia più adatto a un database relazionale che utilizza un formato riga, la denormalizzazione dei dati è preferibile per i database a colonne. Per ulteriori informazioni sui vantaggi della denormalizzazione dei dati e di altre strategie di ottimizzazione delle query in BigQuery, consulta Denormalizzazione.

Tecniche per rendere più uniforme lo schema esistente

La tecnologia BigQuery sfrutta una combinazione di accesso ed elaborazione dei dati a colonne, archiviazione in memoria ed elaborazione distribuita per fornire prestazioni di query di qualità.

Quando si progetta uno schema DWH di BigQuery, creare una tabella dei fatti in una struttura di tabella piatta (consolidando tutte le tabelle delle dimensioni in un unico record nella tabella dei fatti) è migliore per l'utilizzo dello spazio di archiviazione rispetto all'utilizzo di più tabelle di dimensioni DWH. Oltre a un minore utilizzo dello spazio di archiviazione, una tabella piatta in BigQuery riduce l'utilizzo di JOIN. Il seguente diagramma illustra un esempio di "appiattimento" dello schema.

Database gestione delle vendite

Esempio di appiattimento di uno schema a stella

La figura 1 mostra un database fittizio di gestione delle vendite che include quattro tabelle:

  • Tabella ordini/vendite (tabella dei fatti)
  • Tabella dei dipendenti
  • Tabella delle località
  • Tabella dei clienti

La chiave primaria per la tabella delle vendite è OrderNum, che contiene anche chiavi esterne per le altre tre tabelle.

Dati di vendita di esempio in uno schema a stella

Figura 1: dati di vendita di esempio in uno schema a stella

Dati di esempio

Contenuti della tabella ordini/dati

OrderNum CustomerID SalesPersonID quantità Località
O-1 1234 12 234,22 18
O-2 4567 1 192,10 27
O-3 12 14,66 18
O-4 4567 4 182,00 26

Contenuti della tabella dei dipendenti

SalesPersonID FName LName title
1 Alessandro Smith Socio alle vendite
4 Lisa Doe Socio alle vendite
12 Mario Doe Socio alle vendite

Contenuti della tabella dei clienti

CustomerID FName LName
1234 Amanda Verdi
4567 Matt Roberto

Contenuti della tabella delle località

Località city city city
18 Bronx NY 10452
26 Mountain View CA 90210
27 Chicago IL 60613

Query per suddividere i dati utilizzando LEFT OUTER JOIN

#standardSQL
INSERT INTO flattened
SELECT
  orders.ordernum,
  orders.customerID,
  customer.fname,
  customer.lname,
  orders.salespersonID,
  employee.fname,
  employee.lname,
  employee.title,
  orders.amount,
  orders.location,
  location.city,
  location.state,
  location.zipcode
FROM orders
LEFT OUTER JOIN customer
  ON customer.customerID = orders.customerID
LEFT OUTER JOIN employee
  ON employee.salespersonID = orders.salespersonID
LEFT OUTER JOIN location
  ON location.locationID = orders.locationID

Output dei dati suddivisi

OrderNum CustomerID FName LName SalesPersonID FName LName quantità Località city state codice postale
O-1 1234 Amanda Verdi 12 Mario Doe 234,22 18 Bronx NY 10452
O-2 4567 Matt Roberto 1 Alessandro Smith 192,10 27 Chicago IL 60613
O-3 12 Mario Doe 14,66 18 Bronx NY 10452
O-4 4567 Matt Roberto 4 Lisa Doe 182,00 26 Mountain

View

CA 90210

Campi nidificati e ripetuti

Per progettare e creare uno schema DWH da uno schema relazionale (ad esempio, schemi a stella e fiocco di neve che contengono tabelle di dimensioni e oggetti), BigQuery presenta la funzionalità dei campi nidificati e ripetuti. Pertanto, le relazioni possono essere conservate in modo simile a uno schema DWH relazionale normalizzato (o normalizzato parzialmente) senza influire sulle prestazioni. Per ulteriori informazioni, consulta le best practice per il rendimento.

Per comprendere meglio l'implementazione di campi nidificati e ripetuti, osserva un semplice schema relazionale di una tabella CUSTOMERS e una tabella ORDER/SALES. Sono due tabelle diverse, una per ogni entità, e le relazioni vengono definite utilizzando una chiave come una chiave primaria e una chiave esterna come collegamento tra le tabelle durante l'esecuzione di query utilizzando gli elementi JOIN. I campi nidificati e ripetuti di BigQuery consentono di mantenere la stessa relazione tra le entità in un'unica tabella. Questa operazione può essere implementata disponendo di tutti i dati dei clienti, mentre i dati degli ordini sono nidificati per ciascuno dei clienti. Per ulteriori informazioni, consulta la sezione Specifica delle colonne nidificate e ripetute.

Per convertire la struttura piatta in uno schema nidificato o ripetuto, nidifica i campi come segue:

  • CustomerID, FName, LName nidificati in un nuovo campo denominato Customer.
  • SalesPersonID, FName, LName nidificati in un nuovo campo denominato Salesperson.
  • LocationID, city, state, zip code nidificati in un nuovo campo chiamato Location.

I campi OrderNum e amount non sono nidificati perché rappresentano elementi univoci.

Vuoi rendere il tuo schema sufficientemente flessibile da consentire a ogni ordine di avere più di un cliente: uno principale e uno secondario. Il campo del cliente è contrassegnato come ripetuto. Lo schema risultante è mostrato nella Figura 2, che illustra i campi nidificati e ripetuti.

Struttura nidificata

Figura 2: rappresentazione logica di una struttura nidificata

In alcuni casi, la denormalizzazione mediante campi nidificati e ripetuti non porta a miglioramenti delle prestazioni. Per ulteriori informazioni sulle limitazioni e sulle restrizioni relative ai campi nidificati e ripetuti, consulta Caricamento di dati denormalizzati, nidificati e ripetuti.

Chiavi surrogate

È comune identificare righe con chiavi univoche all'interno delle tabelle. Le sequenze sono comunemente utilizzate in Oracle per creare queste chiavi. In BigQuery puoi creare chiavi surrogate utilizzando le funzioni row_number e partition by. Per ulteriori informazioni, consulta BigQuery e chiavi surrogate: un approccio pratico.

Tenere traccia delle modifiche e della cronologia

Quando pianifichi una migrazione DWH di BigQuery, considera il concetto di dimensioni a variazione lenta (SCD). In generale, il termine SCD descrive la procedura di modifica (operazioni DML) nelle tabelle delle dimensioni.

Per diversi motivi, i data warehouse tradizionali utilizzano tipi diversi per gestire le modifiche ai dati e conservare i dati storici in dimensioni che cambiano lentamente. Questi tipi di utilizzo sono necessari in base alle limitazioni e ai requisiti di efficienza hardware descritti in precedenza. Poiché l'archiviazione è molto più economica del calcolo e offre una scalabilità infinita, la ridondanza e la duplicazione dei dati sono incoraggiate se le query risulteranno più rapide in BigQuery. Puoi utilizzare tecniche di snapshot dei dati, che consentono di caricare tutti i dati in nuove partizioni giornaliere.

Viste specifiche per ruolo e utente

Utilizza viste specifiche per ruolo e per utente quando gli utenti appartengono a team diversi e devono vedere solo i record e i risultati di cui hanno bisogno.

BigQuery supporta la column- e riga. La sicurezza a livello di colonna fornisce un accesso granulare alle colonne sensibili utilizzando i tag di criteri o la classificazione dei dati basata sul tipo. Sicurezza a livello di riga, che consente di filtrare i dati e di accedere a righe specifiche di una tabella in base a condizioni di utente idonee.

Migrazione dei dati

Questa sezione fornisce informazioni sulla migrazione dei dati da Oracle a BigQuery, inclusi strumenti e approcci a caricamento iniziale, Change Data Capture (CDC) e ETL/ELT.

Attività di migrazione

È consigliabile eseguire la migrazione in fasi identificando i casi d'uso appropriati. Sono disponibili vari strumenti e servizi per la migrazione dei dati da Oracle a Google Cloud. Sebbene questo elenco non sia esaustivo, fornisce un'idea delle dimensioni e dell'ambito dell'attività di migrazione.

  • Esportazione di dati da Oracle:per ulteriori informazioni, consulta Caricamento iniziale e CDC e importazione di flussi di dati da Oracle a BigQuery. Per il caricamento iniziale è possibile utilizzare gli strumenti ETL.

  • Staging dei dati (in Cloud Storage): Cloud Storage è il luogo di destinazione consigliato (area di gestione temporanea) per i dati esportati da Oracle. Cloud Storage è progettato per l'importazione rapida e flessibile di dati strutturati e non strutturati.

  • Processo ETL: per ulteriori informazioni, consulta Migrazione ETL/ELT.

  • Caricamento dei dati direttamente in BigQuery: puoi caricare i dati in BigQuery direttamente da Cloud Storage, tramite Dataflow o tramite flussi di dati in tempo reale. Usa Dataflow quando è richiesta la trasformazione dei dati.

Caricamento iniziale

La migrazione dei dati iniziali dal data warehouse Oracle esistente a BigQuery potrebbe essere diversa dalle pipeline ETL/ELT incrementali, a seconda delle dimensioni dei dati e della larghezza di banda della rete. Se la dimensione dei dati è di un paio di terabyte, puoi utilizzare le stesse pipeline ETL/ELT.

Se i dati raggiungono fino a alcuni terabyte, il dump dei dati e l'utilizzo di gsutil per il trasferimento può essere molto più efficiente rispetto all'utilizzo di una metodologia di estrazione dei database programmatici simile a JdbcIO, perché gli approcci programmatici potrebbero richiedere un'ottimizzazione delle prestazioni molto più granulare. Se le dimensioni dei dati sono superiori a qualche terabyte e sono archiviati nello spazio di archiviazione sul cloud o online (ad esempio Amazon Simple Storage Service (Amazon S3)), prendi in considerazione l'utilizzo di BigQuery Data Transfer Service. Per trasferimenti su larga scala (in particolare quelli con larghezza di banda di rete limitata), Transfer Appliance è un'opzione utile.

Vincoli per il caricamento iniziale

Quando pianifichi la migrazione dei dati, considera quanto segue:

  • Dimensione dei dati Oracle DWH: la dimensione dell'origine dello schema ha un peso significativo sul metodo di trasferimento di dati scelto, soprattutto se la dimensione dei dati è grande (terabyte o più). Se la dimensione dei dati è relativamente ridotta, il processo di trasferimento dei dati può essere completato in meno passaggi. La gestione di dati di dimensioni su larga scala complica l'intero processo.

  • Tempo di inattività: decidere se il tempo di inattività è un'opzione per la migrazione a BigQuery è importante. Per ridurre i tempi di inattività, puoi eseguire il caricamento collettivo dei dati storici costanti e disporre di una soluzione CDC per stare al passo con le modifiche che si verificano durante il processo di trasferimento.

  • Prezzi: in alcuni scenari, potresti aver bisogno di strumenti di integrazione di terze parti (ad esempio, ETL o strumenti di replica) che richiedono licenze aggiuntive.

Trasferimento iniziale dei dati (batch)

Il trasferimento di dati con un metodo batch indica che i dati verranno esportati in modo coerente in un singolo processo (ad esempio, l'esportazione dei dati dello schema Oracle DWH in file CSV, Avro o Parquet o l'importazione in Cloud Storage per creare set di dati su BigQuery). Tutti gli strumenti e i concetti ETL spiegati nella migrazione ETL/ELT possono essere utilizzati per il caricamento iniziale.

Se non vuoi utilizzare uno strumento ETL/ELT per il caricamento iniziale, puoi scrivere script personalizzati per esportare i dati in file (CSV, Avro o Parquet) e caricarli in Cloud Storage utilizzando gsutil, BigQuery Data Transfer Service o Transfer Appliance. Per ulteriori informazioni sull'ottimizzazione delle prestazioni, per trasferimenti di dati di grandi dimensioni e per le opzioni di trasferimento, consulta la sezione Trasferimento di set di dati di grandi dimensioni. Quindi carica i dati da Cloud Storage in BigQuery.

Cloud Storage è ideale per la gestione dell'arrivo iniziale dei dati. Cloud Storage è un servizio di archiviazione di oggetti durevole e a disponibilità elevata senza limitazioni al numero di file. Paghi solo per lo spazio di archiviazione che utilizzi. Il servizio è ottimizzato per funzionare con altri servizi Google Cloud come BigQuery e Dataflow.

CDC e importazione di flussi di dati da Oracle a BigQuery

Esistono diversi modi per acquisire i dati modificati da Oracle. Ciascuna opzione presenta dei migliori compromessi, principalmente nell'impatto sulle prestazioni del sistema di origine, sui requisiti di sviluppo e configurazione, nonché sui prezzi e sulle licenze.

CDC basata su log

Oracle GoldenGate è lo strumento consigliato di Oracle per estrarre i log di ripetizione e puoi utilizzare GoldenGate per big data per trasmettere i flussi di log in BigQuery. GoldenGate richiede licenze per CPU. Per informazioni sul prezzo, vedi Oracle Technology Global Price List. Se Oracle GoldenGate per Big Data è disponibile (nel caso in cui le licenze siano già state acquisite), l'utilizzo di GoldenGate può essere una buona scelta per creare pipeline di dati per trasferire i dati (caricamento iniziale) e sincronizzare tutte le modifiche dei dati.

Oracle XStream

Oracle archivia ogni commit nei file di log di ripetizione e questi file possono essere utilizzati per CDC. Oracle XStream Out si basa su LogMiner e viene fornito da strumenti di terze parti come Debezium (a partire dalla versione 0.8) o utilizzando in modo commerciale strumenti come Alooma o Striim. Per utilizzare le API XStream, è necessario acquistare una licenza per Oracle GoldenGate anche se GoldenGate non è installato e utilizzato. XStream consente di propagare i messaggi di flussi di dati tra Oracle e altri software.

Oracle LogMiner

Non sono richieste licenze speciali per LogMiner. Puoi utilizzare l'opzione LogMiner nel connettore della community Debezium. È anche disponibile in commercio utilizzando strumenti come Attunity, Striim o StreamSets. LogMiner potrebbe avere un impatto sulle prestazioni di un database di origine molto attivo e deve essere utilizzato con cautela nei casi in cui il volume delle modifiche (la dimensione dell'operazione di ripetizione) sia superiore a 10 GB all'ora, a seconda della CPU, della memoria e della capacità di I/O e dell'utilizzo del server.

CDC basata su SQL

Questo è l'approccio ETL incrementale in cui le query SQL eseguono continuamente il polling delle tabelle di origine alla ricerca di eventuali modifiche, a seconda di una chiave in aumento monotonico e di una colonna di timestamp contenente l'ultima data di modifica o inserimento. Se la chiave non aumenta in modo monotonico, l'utilizzo della colonna timestamp (data modificata) con una piccola precisione (secondi) può causare record duplicati o dati mancanti a seconda dell'operatore di volume e confronto, ad esempio > o >=.

Per risolvere questi problemi, puoi utilizzare una precisione maggiore nelle colonne del timestamp, ad esempio sei cifre frazionarie (microsecondi, la massima precisione supportata in BigQuery) oppure puoi aggiungere attività di deduplicazione nella pipeline ETL/ELT, a seconda delle chiavi aziendali e delle caratteristiche dei dati.

Deve essere presente un indice nella colonna della chiave o del timestamp per migliorare le prestazioni di estrazione e ridurre l'impatto sul database di origine. Le operazioni di eliminazione rappresentano una sfida per questa metodologia perché devono essere gestite nell'applicazione di origine in modo di eliminazione temporanea, come il puttint di un flag eliminato e l'aggiornamento di last_modified_date. In alternativa, puoi registrare queste operazioni in un'altra tabella con un trigger.

Trigger

Puoi creare trigger di database sulle tabelle di origine per registrare le modifiche nelle tabelle del journal shadow. Le tabelle del journal possono contenere intere righe per tenere traccia di ogni modifica delle colonne oppure possono conservare solo la chiave primaria con il tipo di operazione (insert, update o delete). Quindi, i dati modificati possono essere acquisiti con un approccio basato su SQL descritto in CDC basata su SQL. L'uso dei trigger può influire sulle prestazioni delle transazioni e raddoppiare la latenza dell'operazione DML su riga singola se viene archiviata un'intera riga. L'archiviazione solo della chiave primaria può ridurre questo overhead, ma in questo caso è richiesta un'operazione JOIN con la tabella originale nell'estrazione basata su SQL, che ignora la modifica intermedia.

Migrazione ETL/ELT

Esistono molte possibilità per gestire ETL/ELT su Google Cloud. L'assistenza tecnica sulle conversioni specifiche dei carichi di lavoro ETL non rientra nell'ambito di questo documento. Puoi prendere in considerazione un approccio lift and shift o riprogettare la tua piattaforma di integrazione dei dati a seconda di vincoli come costi e tempi. Per ulteriori informazioni su come eseguire la migrazione delle pipeline di dati in Google Cloud e su molti altri concetti relativi alla migrazione, consulta Migrazione delle pipeline di dati.

Approccio lift and shift

Se la tua piattaforma esistente supporta BigQuery e vuoi continuare a utilizzare il tuo strumento di integrazione dei dati esistente:

  • Puoi mantenere la piattaforma ETL/ELT così com'è e modificare le fasi di archiviazione necessarie con BigQuery nei tuoi job ETL/ELT.
  • Se vuoi eseguire anche la migrazione della piattaforma ETL/ELT a Google Cloud, puoi chiedere al tuo fornitore se il suo strumento è in licenza su Google Cloud e, in caso affermativo, puoi installarlo su Compute Engine o controllare Google Cloud Marketplace.

Per informazioni sui fornitori di soluzioni di integrazione dei dati, consulta Partner BigQuery.

Riprogettazione della piattaforma ETL/ELT

Se vuoi riprogettare le tue pipeline di dati, ti consigliamo vivamente di considerare l'utilizzo dei servizi Google Cloud.

Cloud Data Fusion

Cloud Data Fusion è un servizio CDAP gestito su Google Cloud che offre un'interfaccia visiva con molti plug-in per attività quali il trascinamento e lo sviluppo di pipeline. Cloud Data Fusion può essere utilizzato per acquisire dati da molti tipi diversi di sistemi di origine e offre funzionalità di replica in batch e in flussi. I plug-in Cloud Data Fusion o Oracle possono essere usati per acquisire dati da un Oracle Un plug-in BigQuery può essere utilizzato per caricare i dati in BigQuery e gestire gli aggiornamenti dello schema.

Nessuno schema di output viene definito sia sui plug-in di origine che sui plug-in sink e select * from viene utilizzato anche nel plug-in di origine per replicare nuove colonne.

Puoi utilizzare la funzionalità Wrangle di Cloud Data Fusion per la pulizia e la preparazione dei dati.

Dataflow

Dataflow è una piattaforma serverless per l'elaborazione dei dati in grado di scalare automaticamente, nonché di eseguire l'elaborazione dei dati in modalità flusso e batch. Dataflow può essere una buona scelta per gli sviluppatori Python e Java che vogliono programmare le proprie pipeline di dati e utilizzare lo stesso codice per carichi di lavoro sia in modalità flusso che batch. Utilizza il modello da JDBC a BigQuery per estrarre i dati da Oracle o da altri database relazionali e caricarli in BigQuery.

Cloud Composer

Cloud Composer è un servizio di orchestrazione del flusso di lavoro completamente gestito di Google Cloud basato su Apache Airflow. Consente di creare, pianificare e monitorare le pipeline distribuite in diversi ambienti cloud e nei data center on-premise. Cloud Composer fornisce operatori e contributi in grado di eseguire tecnologie multi-cloud per casi d'uso, tra cui estrazione e caricamento, trasformazioni di ELT e chiamate API REST.

Cloud Composer utilizza grafi diretti aciclici (DAG) per la pianificazione e l'orchestrazione dei flussi di lavoro. Per comprendere i concetti generali di Airflow, consulta i concetti di Apache Airflow. Per ulteriori informazioni sui DAG, vedi Scrittura di DAG (flussi di lavoro). Per esempi di best practice ETL con Apache Airflow, consulta il sito delle best practice ETL con la documentazione di Airflow¶. Puoi sostituire l'operatore Hive nell'esempio con l'operatore BigQuery per applicare gli stessi concetti.

DAG di esempio

Il seguente codice campione è una parte generale di un DAG di esempio per il diagramma precedente:


    default_args = {
      'owner': 'airflow',
      'depends_on_past': False,
     'start_date': airflow.utils.dates.days_ago(2),
     'email': ['airflow@example.com'],
     'email_on_failure': False,
     'email_on_retry': False,
     'retries': 2,
     'retry_delay': timedelta(minutes=10),
    }
    schedule_interval = "00 01 * * *"
    dag = DAG('load_db1_db2',catchup=False, default_args=default_args,
    schedule_interval=schedule_interval)
    tables = {
      'DB1_TABLE1': {'database':'DB1', 'table_name':'TABLE1'},
      'DB1_TABLE2': {'database':'DB1', 'table_name':'TABLE2'},
      'DB1_TABLEN': {'database':'DB1', 'table_name':'TABLEN'},
      'DB2_TABLE1': {'database':'DB2', 'table_name':'TABLE1'},
      'DB2_TABLE2': {'database':'DB2', 'table_name':'TABLE2'},
      'DB2_TABLEN': {'database':'DB2', 'table_name':'TABLEN'},
    }
    start_db1_daily_incremental_load = DummyOperator(
       task_id='start_db1_daily_incremental_load', dag=dag)
    start_db2_daily_incremental_load = DummyOperator(
       task_id='start_db2_daily_incremental_load', dag=dag)

    load_denormalized_table1 = BigQueryOperator(
       task_id='load_denormalized_table1',
       use_legacy_sql=False,
       write_disposition='WRITE_TRUNCATE',
       allow_large_results=True,
       trigger_rule='all_done',
       bql='''
       #standardSQL
       select
           t1.*,tN.* except (ID)
           from `ingest-project.ingest_db1.TABLE1` as t1
           left join `ingest-project.ingest_db1.TABLEN` as tN on t1.ID = tN.ID
        ''',    destination_dataset_table='datamart-project.dm1.dt1', dag=dag)

        load_denormalized_table2 = BigQueryOperator(
           task_id='load_denormalized_table2',
           use_legacy_sql=False,
           write_disposition='WRITE_TRUNCATE',
           allow_large_results=True,
           trigger_rule='all_done',
        bql='''
        #standardSQL
        select
           t1.*,t2.* except (ID),tN.* except (ID)
           from `ingest-project.ingest_db1.TABLE1` as t1
           left join `ingest-project.ingest_db2.TABLE2` as t2 on t1.ID = t2.ID
           left join `ingest-project.ingest_db2.TABLEN` as tN on t2.ID = tN.ID
        ''',    destination_dataset_table='datamart-project.dm1.dt2', dag=dag)

        load_denormalized_table_all = BigQueryOperator(
           task_id='load_denormalized_table_all',
           use_legacy_sql=False,
           write_disposition='WRITE_TRUNCATE',
           allow_large_results=True,
          trigger_rule='all_done',
        bql='''
        #standardSQL
        select
           t1.*,t2.* except (ID),t3.* except (ID)
           from `datamart-project.dm1.dt1` as t1
           left join `ingest-project.ingest_db1.TABLE2` as t2 on t1.ID = t2.ID
           left join `datamart-project.dm1.dt2` as t3 on t2.ID = t3.ID
        ''',    destination_dataset_table='datamart-project.dm1.dt_all', dag=dag)

        def start_pipeline(database,table,...):
        #start initial or incremental load job here
        #you can write your custom operator to integrate ingestion tool
        #or you can use operators available in composer instead

        for table,table_attr in tables.items():
        tbl=table_attr['table_name']
        db=table_attr['database'])
        load_start = PythonOperator(
        task_id='start_load_{db}_{tbl}'.format(tbl=tbl,db=db),
        python_callable=start_pipeline,
        op_kwargs={'database': db,
        'table':tbl},
        dag=dag
        )

        load_monitor = HttpSensor(
          task_id='load_monitor_{db}_{tbl}'.format(tbl=tbl,db=db),
          http_conn_id='ingestion-tool',
          endpoint='restapi-endpoint/',
          request_params={},
          response_check=lambda response: """{"status":"STOPPED"}""" in
          response.text,
          poke_interval=1,
          dag=dag,
        )

        load_start.set_downstream(load_monitor)

        if table_attr['database']=='db1':
          load_start.set_upstream(start_db1_daily_incremental_load)
        else:
          load_start.set_upstream(start_db2_daily_incremental_load)

        if table_attr['database']=='db1':
          load_monitor.set_downstream(load_denormalized_table1)
        else:
          load_monitor.set_downstream(load_denormalized_table2)
          load_denormalized_table1.set_downstream(load_denormalized_table_all)
          load_denormalized_table2.set_downstream(load_denormalized_table_all)

Il codice precedente viene fornito a scopo dimostrativo e non può essere utilizzato così com'è.

Dataprep di Trifacta

Dataprep è un servizio dati per l'esplorazione visiva, la pulizia e la preparazione di dati strutturati e non strutturati per l'analisi, il reporting e il machine learning. Puoi esportare i dati di origine in file JSON o CSV, trasformarli con Dataprep e caricarli usando Dataflow. Per un esempio, vedi Dati Oracle (ETL) a BigQuery utilizzando Dataflow e Dataprep.

Dataproc

Dataproc è un servizio Hadoop gestito da Google. Puoi utilizzare Sqoop per esportare i dati da Oracle e molti database relazionali in Cloud Storage come file Avro, quindi puoi caricare i file Avro in BigQuery utilizzando bq tool. È molto comune installare su Hadoop strumenti ETL come CDAP che utilizzano JDBC per estrarre i dati e Apache Spark o MapReduce per le trasformazioni dei dati.

Strumenti dei partner per la migrazione dei dati

Esistono diversi fornitori nello spazio ETL (Extract, Transform, Load). Leader di mercato ETL come Informatica, Talend, Matillion, Alooma, Infoworks, Stitch, Fivetran e Striim hanno una profonda integrazione con BigQuery e Oracle e possono aiutare a estrarre, trasformare, caricare i dati e gestire i flussi di lavoro di elaborazione.

Gli strumenti ETL esistono da molti anni. Alcune organizzazioni potrebbero trovare conveniente sfruttare un investimento esistente in script ETL attendibili. Alcune delle nostre soluzioni principali dei partner sono incluse nel sito web dei partner BigQuery. Sapere quando scegliere gli strumenti dei partner rispetto alle utilità integrate di Google Cloud dipende dalla tua infrastruttura attuale e dalla dimestichezza del tuo team IT nello sviluppo di pipeline di dati in codice Java o Python.

Migrazione degli strumenti di business intelligence (BI)

BigQuery supporta una suite flessibile di soluzioni di business intelligence (BI) per la generazione di report e l'analisi utilizzabili. Per ulteriori informazioni sulla migrazione dello strumento BI e sull'integrazione di BigQuery, consulta Panoramica dell'analisi di BigQuery.

Traduzione di query (SQL)

GoogleSQL di BigQuery supporta la conformità allo standard SQL 2011 e dispone di estensioni che supportano l'esecuzione di query su dati nidificati e ripetuti. Tutte le funzioni e gli operatori SQL conformi ad ANSI possono essere utilizzati con modifiche minime. Per un confronto dettagliato tra la sintassi e le funzioni SQL di Oracle e BigQuery, consulta la documentazione di riferimento sulla traduzione SQL di Oracle a BigQuery.

Utilizza la traduzione SQL batch per eseguire la migrazione in blocco del codice SQL o la traduzione SQL interattiva per tradurre query ad hoc.

Migrazione delle opzioni Oracle

Questa sezione presenta suggerimenti e riferimenti sull'architettura per la conversione di applicazioni che utilizzano le funzionalità Oracle Data Mining, R e spaziale e grafico.

Opzione Oracle Advanced Analytics

Oracle offre opzioni di analisi avanzate per il data mining, gli algoritmi di machine learning di base (ML) e l'utilizzo di R. L'opzione Analisi avanzata richiede la concessione in licenza. Puoi scegliere da un elenco completo di prodotti IA/ML di Google a seconda delle tue esigenze, dallo sviluppo alla produzione su larga scala.

Oracle R Enterprise

Oracle R Enterprise (ORE), un componente dell'opzione Oracle Advanced Analytics, consente l'integrazione del linguaggio di programmazione statistica open source R con Oracle Database. Nei deployment ORE standard, R è installato su un server Oracle.

Per scale di dati o approcci al warehousing su larga scala, l'integrazione di R con BigQuery è la scelta ideale. Puoi utilizzare la libreria R open source bigrquery per integrare R con BigQuery.

Google ha collaborato con RStudio per mettere a disposizione degli utenti gli strumenti all'avanguardia del settore. RStudio può essere utilizzato per accedere a terabyte di dati nei modelli BigQuery Fit in TensorFlow e per eseguire modelli di machine learning su larga scala con AI Platform. In Google Cloud, R può essere installato su Compute Engine su larga scala.

Data mining Oracle

Oracle Data Mining (ODM), un componente dell'opzione Oracle Advanced Analytics, consente agli sviluppatori di creare modelli di machine learning utilizzando Oracle PL/SQL Developer su Oracle.

BigQuery ML consente agli sviluppatori di eseguire molti tipi diversi di modelli, come regressione lineare, regressione logistica binaria, regressione logistica multiclasse, clustering K-means e importazione di modelli TensorFlow. Per ulteriori informazioni, consulta Introduzione a BigQuery ML.

La conversione dei job ODM potrebbe richiedere la riscrittura del codice. Puoi scegliere tra offerte di prodotti IA di Google complete come BigQuery ML, API IA (Speech-to-Text, Text-to-Speech, Dialogflow, Cloud Translation, API Cloud Natural Language, Cloud Vision, API Timeseries Insights e altri17}17}171 APITimeseries eTimeseries.

Vertex AI Workbench può essere utilizzato come ambiente di sviluppo per i data scientist e Vertex AI Training può essere utilizzato per eseguire carichi di lavoro di addestramento e punteggio su larga scala.

Opzione spaziale e grafico

Oracle offre l'opzione Spaziale e grafico per eseguire query su geometria e grafici e richiede la licenza per questa opzione. Puoi utilizzare le funzioni di geometria in BigQuery senza costi o licenze aggiuntivi e utilizzare altri database di grafici in Google Cloud.

Spaziale

BigQuery offre funzioni e tipi di dati di analisi geospaziale. Per ulteriori informazioni, vedi Utilizzo dei dati di analisi geospaziale. I tipi di dati e le funzioni di Oracle Spatial possono essere convertiti in funzioni di area geografica nel linguaggio SQL standard di BigQuery. Le funzioni geografiche non aggiungono costi oltre ai prezzi standard di BigQuery.

Grafico

JanusGraph è una soluzione di database di grafici open source che può utilizzare Bigtable come backend di archiviazione. Per saperne di più, consulta Esecuzione di JanusGraph su GKE con Bigtable.

Neo4j è un'altra soluzione di database grafici fornita come servizio Google Cloud in esecuzione su Google Kubernetes Engine (GKE).

Oracle Application Express

Le applicazioni Oracle Application Express (APEX) sono specifiche di Oracle e devono essere riscritte. Le funzionalità di generazione di report e visualizzazione dei dati possono essere sviluppate utilizzando Looker Studio o BI Engine, mentre le funzionalità a livello di applicazione come la creazione e la modifica di righe possono essere sviluppate senza programmazione in AppSheet utilizzando Cloud SQL.

Passaggi successivi