Migrazione da Oracle a BigQuery

Questo documento fornisce indicazioni generali su come eseguire la migrazione da Oracle a BigQuery. Descrive le differenze architettoniche fondamentali e suggerisce modalità di 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 enterprise architect, database, sviluppatori di applicazioni e professionisti della sicurezza IT che vogliono eseguire la migrazione da Oracle a BigQuery e risolvere le sfide tecniche del processo di migrazione.

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

Pre-migrazione

Per garantire una migrazione del data warehouse senza problemi, inizia a pianificare la tua strategia di migrazione all'inizio della sequenza temporale del progetto. Per informazioni su come pianificare in modo sistematico il lavoro di migrazione, vedi Cosa e come eseguire la migrazione: il framework di migrazione.

Pianificazione della capacità BigQuery

In background, la velocità effettiva di analisi in BigQuery viene misurata in slot. Uno slot BigQuery è l'unità di capacità di calcolo di proprietà di Google necessaria per eseguire le query SQL.

BigQuery calcola continuamente il numero di slot richiesti dalle query durante l'esecuzione, ma assegna gli slot alle query in base a una fisca pianificazione.

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

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

• Prezzi basati sulla capacità: con i prezzi basati sulla capacità, acquisti prenotazioni di slot BigQuery (minimo 100) invece di pagare per i byte elaborati dalle query che esegui. Consigliamo i prezzi basati sulla capacità per i carichi di lavoro di data warehouse aziendali, che di solito eseguono molte query di reporting in contemporanea ed estrazione di trasformazione del carico (ELT) con un consumo prevedibile.

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

Il monitoraggio e l'analisi regolari dell'utilizzo degli slot ti aiutano a stimare il numero di slot totali di cui la tua organizzazione ha bisogno durante la crescita su Google Cloud.

Ad esempio, supponi di prenotare inizialmente 4000 slot BigQuery per eseguire contemporaneamente 100 query a media complessità. Se noti tempi di attesa elevati nei piani di esecuzione delle query e le tue dashboard mostrano un utilizzo elevato degli slot, è possibile che siano necessari ulteriori slot BigQuery per supportare i carichi di lavoro. Se vuoi acquistare autonomamente slot 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 seguenti sezioni descrivono i controlli di sicurezza più comuni di Oracle e come puoi 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 degli accessi 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 utente, un gruppo o un account di servizio. I ruoli di organizzazione e di progetto influiscono sulla capacità di eseguire job o gestire il progetto, mentre i ruoli dei set di dati influiscono sulla possibilità di accedere o modificare i dati all'interno di un progetto.

IAM fornisce 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 un accesso granulare a un servizio specifico e sono gestiti da Google Cloud.

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

  Attenzione: i ruoli di base a livello di set di dati di BigQuery esistevano prima dell'introduzione di IAM. Ti consigliamo di ridurre al minimo l'uso dei ruoli di base. In ambienti di produzione, non concedere ruoli di base a meno che non ci siano alternative. Utilizza invece i ruoli IAM predefiniti.

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

Quando assegni a un utente ruoli sia predefiniti sia di base, le autorizzazioni concesse rappresentano l'unione delle autorizzazioni di ogni singolo ruolo.

Sicurezza a livello di riga

Oracle Label Security (OLS) consente la limitazione dell'accesso ai dati per riga. Un caso d'uso tipico per la sicurezza a livello di riga limita l'accesso di un venditore agli account che gestisce. Con l'implementazione della sicurezza a livello di riga, ottieni controllo dell'accesso granulare.

Per garantire la sicurezza a livello di riga in BigQuery, puoi utilizzare le viste 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 dell'intero disco

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

BigQuery cripta tutti i dati at-rest e in transizione 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 nell'oscuramento dei dati, che ti 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, pur consentendo 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 aiutano a identificare gli ostacoli alla migrazione e a pianificare le modifiche necessarie.

Architettura di sistema

Una delle principali differenze tra Oracle e BigQuery è che BigQuery è un ambiente EDW cloud serverless con livelli separati di archiviazione e calcolo in grado di scalare in base alle esigenze della query. Data la natura dell'offerta serverless di BigQuery, non sei limitato dalle decisioni hardware. Puoi richiedere più risorse per le tue query e i tuoi 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, inclusi scalabilità e disponibilità elevata. BigQuery si occupa di scalabilità, gestione e operazioni amministrative. Il seguente diagramma illustra la gerarchia di archiviazione di BigQuery.

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

Architettura di dati e archiviazione

La struttura dei dati e dell'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 l'elaborazione dei dati 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 i dati usando Capacitor. BigQuery fornisce i set di dati come astrazione di livello più alto per organizzare l'accesso alle tabelle, come mostrato nel diagramma precedente. Schemi ed etichette possono essere utilizzati per un'ulteriore organizzazione delle tabelle. BigQuery offre il partizionamento per migliorare le prestazioni e i costi delle query, nonché per gestire il ciclo di vita delle informazioni. Le risorse di archiviazione vengono allocate man mano che le utilizzi e distribuite man mano che rimuovi i dati o elimini tabelle.

Oracle archivia i dati in formato riga utilizzando il formato di blocco Oracle organizzato in segmenti. Gli schemi (di proprietà degli utenti) vengono utilizzati per organizzare le tabelle e altri oggetti del database. A partire da Oracle 12c, multitenant viene utilizzato per creare database modulari all'interno di un'istanza di database per un ulteriore isolamento. 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 fornisce un'infrastruttura di archiviazione ottimizzata nei server di 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 attento dimensionamento 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 per il costo. BigQuery utilizza molte ottimizzazioni, ad esempio:

• Esecuzione di query in memoria
• Architettura ad albero multilivello basata sul motore di esecuzione Dremel
• Ottimizzazione automatica dello spazio di archiviazione all'interno di Capacitor
• 1 petabit al secondo larghezza di banda di bisezione totale con Jupiter
• Gestione delle risorse con scalabilità automatica per eseguire query rapide nell'ordine dei petabyte

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

Oracle fornisce job per le statistiche di dati. L'ottimizzatore del database utilizza statistiche per fornire piani di esecuzione ottimali. Potrebbero essere necessari indici per ricerche rapide nelle righe e operazioni di join. Oracle offre inoltre un archivio di colonne in memoria per le analisi in memoria. Exadata offre diversi miglioramenti delle prestazioni, ad esempio Cell Smart Scan, indici di archiviazione, cache flash e connessioni InfiniBand tra server di archiviazione e server di database. Puoi utilizzare Real Application Clusters (RAC) per ottenere un'alta disponibilità del server e scalare le applicazioni con utilizzo intensivo di CPU del database utilizzando lo stesso spazio di archiviazione sottostante.

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

Analisi agili

In BigQuery puoi consentire a diversi progetti, utenti e gruppi di 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 degli slot ed eseguendo query sulla fatturazione degli altri progetti e dei progetti che ospitano i set di dati.

Alta disponibilità, backup e ripristino di emergenza

Oracle fornisce Data Guard come soluzione di ripristino di emergenza e replica dei database. I cluster di applicazioni reali (RAC) possono essere configurati per la disponibilità del server. I backup di Recovery Manager (RMAN) possono essere configurati per i backup di database e Archivelog e possono essere utilizzati anche per operazioni di ripristino e ripristino. La funzionalità Database Flashback può essere utilizzata per i flashback del database per riavvolgere il database fino a un momento specifico. Annulla l'archiviazione a fini legali degli snapshot delle tabelle. È possibile eseguire query su snapshot precedenti con la query flashback e le clausole di query "data di", a seconda delle operazioni DML/DDL eseguite in precedenza e delle impostazioni di conservazione degli annullamenti. In Oracle, l'intera integrità del database deve essere gestita all'interno di spazi tabella che dipendono dai metadati di sistema, dall'annullamento e dagli spazi di tabella corrispondenti, poiché l'elevata coerenza è importante per il backup Oracle e le procedure di ripristino dovrebbero includere dati primari completi. Puoi pianificare le esportazioni a livello di schema di tabella se il recupero point-in-time non è necessario in Oracle.

BigQuery è completamente gestito ed è diverso dai sistemi di database tradizionali per la sua funzionalità di backup completa. Non è necessario considerare errori di server, 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à di una singola regione di BigQuery replica i dati in diverse zone all'interno della stessa regione.

BigQuery consente di eseguire query su snapshot storici di tabelle fino a sette giorni e di ripristinare le tabelle eliminate entro due giorni utilizzando il viaggio temporale. Puoi copiare una tabella eliminata (per ripristinarla) utilizzando la sintassi dello snapshot (dataset.table@timestamp). Puoi esportare i dati dalle tabelle BigQuery per ulteriori esigenze di backup, ad esempio per eseguire il ripristino in seguito a operazioni utente accidentali. Per i backup è possibile utilizzare una strategia di backup comprovata e pianificazioni utilizzate 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, perciò non devi esportare frequentemente tabelle e partizioni invariate. Un backup delle esportazioni della partizione o della tabella è sufficiente al termine del caricamento o dell'operazione ETL. Per ridurre i costi del backup, puoi archiviare i file delle esportazioni in Cloud Storage Nearline Storage o Coldline Storage e definire un criterio del 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 la cache per utente; inoltre, 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 dati e risultati delle query, ad esempio cache del buffer, cache dei risultati, cache flash di Exadata e archivi di colonne in memoria.

Connessioni

BigQuery gestisce la gestione delle connessioni e non richiede alcuna configurazione lato server. BigQuery fornisce driver JDBC e ODBC. Puoi utilizzare la console Google Cloud o la bq command-line tool per le query interattive. Puoi utilizzare le API REST e le librerie client per interagire a livello di programmazione con BigQuery. Puoi collegare Fogli Google direttamente a BigQuery ed è disponibile anche un connettore BigQuery per Excel. Se invece state cercando un client desktop, ci sono strumenti gratuiti come DBeaver.

Oracle fornisce ascoltatori, 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 i listener di scansione, gli indirizzi IP delle scansioni e il nome della scansione.

Prezzi e licenze

Oracle richiede tariffe per licenza e assistenza in base ai conteggi principali per le versioni di Database e opzioni di database come RAC, multitenant, Active Data Guard, partizionamento, in-memory, Real Application Testing, GoldenGate e Spatial e Graph.

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

Inoltre, BigQuery riduce automaticamente della metà i costi di archiviazione per i dati non modificati archiviati per più di 90 giorni.

Etichettatura

Set di dati, tabelle e viste 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 controllo del database, nonché audit vault e funzionalità firewall del database, che vengono concesse in licenza separatamente. Oracle fornisce Enterprise Manager per il monitoraggio dei database.

Per BigQuery, Audit log Cloud viene utilizzato per i log degli accessi ai dati e gli audit log, che sono abilitati per impostazione predefinita. I log degli accessi ai dati sono disponibili per 30 giorni, mentre gli altri eventi di sistema e i log delle attività di amministrazione sono disponibili per 400 giorni. Se hai bisogno di una conservazione più lunga, 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 di monitoraggio degli incidenti esistente, è possibile utilizzare Pub/Sub per le esportazioni ed eseguire uno sviluppo personalizzato nello strumento esistente per leggere i log da Pub/Sub.

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

Puoi utilizzare la tabella dei messaggi di errore per la risoluzione degli errori relativi a job di query e API. 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, consulta le note di rilascio.

Oracle ed Exadata richiedono di eseguire patch, upgrade e manutenzione dei database e di infrastruttura sottostanti a livello di infrastruttura. Esistono molte versioni di Oracle e ogni anno ne è prevista una nuova. Anche se le nuove versioni sono compatibili con le versioni precedenti, le prestazioni delle query, il contesto e le funzionalità possono cambiare.

Potrebbero esserci applicazioni che richiedono versioni specifiche come 10g, 11g o 12c. Per gli aggiornamenti più importanti del database, sono necessarie un'attenta pianificazione e test. La migrazione da versioni diverse potrebbe includere esigenze di conversione tecnica diverse per 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 i carichi di lavoro OLTP. È necessario eseguire la migrazione dei carichi di lavoro OLTP che utilizzano lo stesso Oracle in Cloud SQL, Spanner o Firestore in Google Cloud. Oracle offre opzioni aggiuntive come Advanced Analytics and Spatial and Graph. Questi carichi di lavoro potrebbero dover essere riscritti per la migrazione a BigQuery. Per ulteriori informazioni, consulta Opzioni di migrazione di 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 carichi di lavoro e applicazioni diversi. 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 prevede quote e limiti su azioni e oggetti specifici.

Provisioning di BigQuery

BigQuery è una soluzione PaaS (Platform as a Service) e un data warehouse con elaborazione massicciamente parallela del cloud. È possibile fare 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 di archiviazione e di query in modo dinamico in base ai tuoi modelli di utilizzo. Le risorse di archiviazione vengono allocate man mano che le utilizzi e distribuite man mano che rimuovi dati o elimini tabelle. Le risorse di query vengono 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 verificarsi periodi brevi in cui alcune query ottengono una quota maggiore di slot, ma lo scheduler alla fine corregge questo problema.

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

• Fatturazione al secondo
• Scalabilità al secondo

Per eseguire questa operazione, BigQuery esegue queste operazioni:

• Esegui il deployment di vaste risorse per evitare di dover scalare rapidamente.
• Utilizza risorse multitenant per allocare istantaneamente blocchi di grandi dimensioni per secondi alla volta.
• Alloca le risorse in modo efficiente tra gli utenti grazie alle economie di scala.
• Addebita solo i job eseguiti, anziché le risorse di cui è stato eseguito il deployment, quindi paghi per le risorse utilizzate.

Per ulteriori informazioni sui prezzi, consulta Informazioni sulla scalabilità rapida e sui prezzi semplici di BigQuery.

Migrazione schema

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

Tipi di dati Oracle e mappature BigQuery

I tipi di dati Oracle sono diversi da quelli di BigQuery. Per saperne di più 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 anziché gli archivi di righe. Questo aumenta notevolmente le operazioni basate su colonne ed elimina l'uso di indici per l'analisi batch. BigQuery archivia inoltre i dati in formato a colonne, pertanto gli indici non sono necessari in BigQuery. Se il carico di lavoro di analisi richiede un singolo e piccolo set di accesso basato su righe, Bigtable può essere un'alternativa migliore. Se un carico di lavoro richiede l'elaborazione delle transazioni con solide coerenza relazionali, Spanner o Cloud SQL possono essere alternative migliori.

Per riepilogare, non sono necessari indici e vengono offerti in BigQuery per l'analisi batch. È possibile usare 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 vengono comunemente utilizzate per migliorare i tempi di rendering dei report nei tipi di report e carichi di lavoro write-once, read-many.

Le viste materializzate vengono offerte in Oracle per aumentare le prestazioni delle visualizzazioni 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.

La funzionalità Vista materializzata è disponibile anche in BigQuery. BigQuery sfrutta i risultati precalcolati da viste materializzate e, ove possibile, legge solo le modifiche delta dalla tabella di base per calcolare risultati aggiornati.

Le funzionalità di memorizzazione nella cache in Looker Studio o in altri strumenti BI moderni possono inoltre migliorare le prestazioni ed eliminare la necessità di eseguire nuovamente la stessa query, con un conseguente risparmio 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 filtri dei predicati in base alla colonna di partizionamento, in modo da ridurre la quantità di dati scansionati.

• Tabelle partizionate per data e ora di importazione: le tabelle sono partizionate in base alla data e ora di importazione dei dati.
• Tabelle partizionate per colonna: le tabelle sono partizionate in base a una colonna TIMESTAMP o DATE.
• Tabelle partizionate per intervallo di numeri interi: le tabelle sono partizionate in base a una colonna di numeri interi.

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

Se le limitazioni di BigQuery influiscono sulla funzionalità del database di cui è stata eseguita la migrazione, valuta la possibilità di utilizzare lo sharding anziché il partizionamento.

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

Clustering

Il clustering consente di organizzare e recuperare in modo efficiente i dati archiviati in più colonne spesso accessibili insieme. Tuttavia, Oracle e BigQuery hanno circostanze diverse in cui il clustering funziona meglio. In BigQuery, se una tabella viene generalmente 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 su indice da Oracle.

Tabelle temporanee

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

BigQuery utilizza tabelle temporanee per memorizzare nella cache i risultati delle query non scritti in una tabella permanente. Al termine di una query, le tabelle temporanee esistono per un massimo di 24 ore. Le tabelle vengono create in un set di dati speciale e denominate casualmente. Puoi anche creare tabelle temporanee per il tuo utilizzo. Per ulteriori informazioni, consulta la sezione Tabelle temporanee.

Tabelle esterne

Analogamente a Oracle, BigQuery consente di eseguire query su origini dati esterne. BigQuery supporta l'esecuzione di query sui 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 Star o Snowflake possono essere efficienti per l'archiviazione delle analisi 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. I modelli di dati a stella e a fiocco di neve sono supportati anche da BigQuery. Per ulteriori dettagli sulla progettazione di un data warehouse su BigQuery, consulta Schema di progettazione.

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

Oracle utilizza un formato riga in cui la riga della tabella è archiviata in blocchi di dati, pertanto le colonne non necessarie vengono recuperate all'interno del blocco per le query analitiche, in base ai filtri e all'aggregazione di colonne specifiche.

Oracle ha un'architettura condivisa con tutto, con dipendenze delle risorse hardware fisse, come memoria e 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 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 per 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 suddividere 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à.

Durante la progettazione di uno schema DWH di BigQuery, la creazione di una tabella dei fatti in una struttura a tabella piatta (consolidando tutte le tabelle delle dimensioni in un singolo record nella tabella dei fatti) è più adatta per l'utilizzo dell'archiviazione rispetto all'utilizzo di più tabelle di dimensioni DWH. Oltre a un minore utilizzo dello spazio di archiviazione, avere una tabella piatta in BigQuery riduce l'utilizzo di JOIN. Il seguente diagramma illustra un esempio di suddivisione dello schema.

Esempio di suddivisione 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 della tabella delle vendite è OrderNum, che contiene anche chiavi esterne per le altre tre tabelle.

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

Dati di esempio

Contenuti della tabella degli ordini/dei fatti

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 delle tabelle dei dipendenti

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

Contenuti delle tabelle dei clienti

CustomerID	FName	LName
1234	Amanda	Federico
4567	Matt	Rino

Contenuti della tabella relativa alla località

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

Esegui una 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

Nota: BigQuery elabora JOIN da sinistra a destra (dall'alto verso il basso). L'inserimento di JOIN che riducono il numero di record il prima possibile nella catena aumenta l'efficienza delle query riducendo il tempo di risposta.

Output dei dati suddivisi

OrderNum	CustomerID	FName	LName	SalesPersonID	FName	LName	quantità	Località	città	state	CAP
O-1	1234	Amanda	Federico	12	Mario	Doe	234,22	18	Bronx	NY	10452
O-2	4567	Matt	Rino	1	Alessandro	Smith	192,10	27	Chicago	IL	60613
O-3				12	Mario	Doe	14,66	18	Bronx	NY	10452
O-4	4567	Matt	Rino	4	Lisa	Doe	182,00	26	Mountain Visualizza	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 fatti), BigQuery presenta la funzionalità dei campi nidificati e ripetuti. Pertanto, le relazioni possono essere conservate in modo simile a quello di uno schema DWH relazionale (o normalizzato parziale) senza influire sulle prestazioni. Per saperne di più, consulta le best practice per il rendimento.

Per comprendere meglio l'implementazione dei campi nidificati e ripetuti, guarda uno schema relazionale semplice 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, ad esempio una chiave primaria e una chiave esterna, come collegamento tra le tabelle durante l'esecuzione di query tramite JOIN. I campi nidificati e ripetuti di BigQuery consentono di mantenere la stessa relazione tra le entità in un'unica tabella. Questo può essere implementato utilizzando tutti i dati dei clienti, mentre i dati degli ordini sono nidificati per ciascuno dei clienti. Per ulteriori informazioni, consulta 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 nidificate in un nuovo campo chiamato Customer.
• SalesPersonID, FName, LName nidificate in un nuovo campo chiamato Salesperson.
• LocationID, city, state, zip code nidificate in un nuovo campo denominato Location.

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

Vuoi che lo schema sia 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.

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 dei 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 le chiavi surrogate: un approccio pratico.

Tenere traccia delle modifiche e della cronologia

Quando pianifichi una migrazione DWH di BigQuery, considera il concetto di dimensioni che cambiano lentamente (SCD). In generale, il termine SCD descrive il processo di apportare modifiche (operazioni DML) nelle tabelle delle dimensioni.

Per diversi motivi, i data warehouse tradizionali utilizzano tipi diversi per gestire le modifiche ai dati e mantenere i dati storici in dimensioni che cambiano lentamente. Questi utilizzi sono necessari a causa delle limitazioni dell'hardware e dei requisiti di efficienza discussi in precedenza. Poiché l'archiviazione è molto più economica del calcolo e altamente scalabile, la ridondanza e la duplicazione dei dati sono incoraggiate se si traduce in query più veloci in BigQuery. Puoi utilizzare tecniche di creazione di snapshot dei dati in cui tutti i dati vengono caricati in nuove partizioni giornaliere.

Viste specifiche per ruolo e utente

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

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

Migrazione dei dati

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

Attività di migrazione

Ti consigliamo di eseguire la migrazione per fasi, identificando i casi d'uso appropriati per la migrazione. Sono disponibili diversi 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 dello sforzo di migrazione.

• Esportazione di dati da Oracle:per ulteriori informazioni, consulta Caricamento iniziale e Importazione di flussi di dati e CD da Oracle a BigQuery. È possibile utilizzare gli strumenti ETL per il caricamento iniziale.

• Gestione temporanea dei dati (in Cloud Storage): Cloud Storage è il punto di destinazione consigliato (area temporanea) per i dati esportati da Oracle. Cloud Storage è progettato per l'importazione rapida e flessibile di dati strutturati o 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 mediante flussi in tempo reale. Utilizza 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. Le stesse pipeline ETL/ELT possono essere utilizzate se le dimensioni dei dati sono di un paio di terabyte.

Se i dati raggiungono una quantità di pochi terabyte, il loro dump e l'utilizzo di gsutil per il trasferimento può essere molto più efficiente rispetto all'utilizzo della metodologia di estrazione dei database programmatici come 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 in uno spazio di archiviazione sul cloud o online (ad esempio Amazon Simple Storage Service (Amazon S3)), valuta la possibilità di utilizzare BigQuery Data Transfer Service. Per i trasferimenti su larga scala (in particolare i trasferimenti 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:

• Dimensioni dei dati DWH Oracle:la dimensione dell'origine dello schema pesa in modo significativo sul metodo di trasferimento dei dati scelto, soprattutto quando le dimensioni dei dati sono grandi (terabyte e oltre). Se le dimensioni dei dati sono relativamente piccole, il processo di trasferimento dei dati può essere completato in meno passaggi. La gestione di dimensioni dei dati su larga scala rende il processo complessivo più complesso.

• 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 avere una soluzione CDC per stare al passo con le modifiche apportate durante il processo di trasferimento.

• Prezzi:in alcuni scenari, potresti aver bisogno di strumenti di integrazione di terze parti (ad esempio, strumenti ETL o 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, esportazione dei dati dello schema Oracle DWH in file CSV, Avro o Parquet o importazione in Cloud Storage per creare set di dati su BigQuery). Tutti gli strumenti e i concetti ETL descritti 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 i trasferimenti di dati di grandi dimensioni e le opzioni di trasferimento, consulta Trasferimento di set di dati di grandi dimensioni. Quindi carica i dati da Cloud Storage a BigQuery.

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

Importazione di flussi di dati e CDC da Oracle a BigQuery

Esistono diversi modi per acquisire i dati modificati da Oracle. Ciascuna opzione presenta dei compromessi, principalmente in termini di impatto sulle prestazioni sul sistema di origine, requisiti di sviluppo e configurazione, prezzi e licenze.

CDC basata su log

Oracle GoldenGate è lo strumento consigliato da Oracle per l'estrazione di 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, consulta il Listino prezzi globale di Oracle Technology. Se Oracle GoldenGate per Big Data è disponibile (nel caso in cui le licenze siano già state acquisite), utilizzare GoldenGate può essere una buona scelta per creare pipeline di dati per trasferire i dati (caricamento iniziale) e quindi sincronizzare tutte le modifiche dei dati.

Oracle XStream

Oracle archivia tutti i commit in file di log di ripetizione e questi file possono essere utilizzati per CDC. Oracle XStream Out è basato su LogMiner e fornito da strumenti di terze parti come Debezium (a partire dalla versione 0.8) o utilizzando strumenti commerciali come Alooma o Striim. L'utilizzo delle API XStream richiede l'acquisto di una licenza per Oracle GoldenGate anche se GoldenGate non è installato e utilizzato. XStream consente di propagare in modo efficiente i messaggi di Streams tra Oracle e altri software.

LogMiner Oracle

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

CDC basato su SQL

Questo è l'approccio ETL incrementale in cui le query SQL eseguono il polling continuo delle tabelle di origine per rilevare eventuali modifiche a seconda di una chiave con aumento monotonico e una colonna di timestamp che contiene l'ultima data di modifica o inserita. In assenza di una chiave ad aumento monotonico, l'utilizzo della colonna del timestamp (data modificata) con una precisione ridotta (secondi) può causare record duplicati o dati mancanti, a seconda del volume e dell'operatore di confronto, come > o >=.

Per risolvere questi problemi, puoi utilizzare una precisione maggiore nelle colonne di timestamp, ad esempio sei cifre frazionarie (microsecondi, che è la precisione massima 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 sulla 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 con un metodo di eliminazione temporanea, ad esempio mettendo un flag eliminato e aggiornando last_modified_date. Una soluzione alternativa può essere il logging di queste operazioni in un'altra tabella utilizzando un trigger.

Trigger

I trigger di database possono essere creati nelle 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 alla colonna oppure possono mantenere solo la chiave primaria con il tipo di operazione (inserimento, aggiornamento o eliminazione). Successivamente, i dati modificati possono essere acquisiti con un approccio basato su SQL descritto in CDC basato su SQL. L'utilizzo dei trigger può influire sulle prestazioni delle transazioni e raddoppiare la latenza dell'operazione DML a riga singola se viene archiviata una riga intera. L'archiviazione solo della chiave primaria può ridurre questo overhead, ma in questo caso è necessaria un'operazione JOIN con la tabella originale nell'estrazione basata su SQL, che non comprende la modifica intermedia.

Migrazione ETL/ELT

Esistono molte possibilità per gestire ETL/ELT su Google Cloud. Le indicazioni tecniche su conversioni specifiche dei carichi di lavoro ETL non rientrano nell'ambito di questo documento. Puoi scegliere un approccio lift and shift o riprogettare la piattaforma di integrazione dei dati in base a vincoli come costi e tempo. Per ulteriori informazioni su come eseguire la migrazione delle pipeline di dati in Google Cloud e su molti altri concetti di migrazione, consulta Eseguire la migrazione di pipeline di dati.

Approccio lift and shift

Se la tua piattaforma esistente supporta BigQuery e vuoi continuare a utilizzare lo 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 in Google Cloud, puoi chiedere al tuo fornitore se il suo strumento è autorizzato 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 i partner BigQuery.

Riprogettare l'architettura 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 è una piattaforma CDAP gestita su Google Cloud che offre un'interfaccia visiva con molti plug-in per attività come 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 modalità batch e flusso. È possibile utilizzare i plug-in di Cloud Data Fusion o Oracle per acquisire i dati da un ambiente Oracle. È possibile utilizzare un plug-in di BigQuery 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 sul 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 di elaborazione dati serverless in grado di scalare automaticamente ed eseguire l'elaborazione dei dati in batch e in flussi. Dataflow può essere una buona scelta per gli sviluppatori Python e Java che vogliono codificare le loro pipeline di dati e utilizzare lo stesso codice per carichi di lavoro in modalità flusso e batch. Utilizza il modello da JDBC a BigQuery per estrarre i dati da Oracle o da altri database relazionali e caricarli in BigQuery. Per un esempio di caricamento di dati da un database relazionale in un set di dati BigQuery, consulta Esecuzione dell'ETL da un database relazionale in BigQuery utilizzando Dataflow.

Cloud Composer

Cloud Composer è il 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 ambienti cloud e nei data center on-premise. Cloud Composer fornisce operatori e contributi che possono 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, Directed Acyclic Graph) per la pianificazione e l'orchestrazione dei flussi di lavoro. Per comprendere i concetti generali di Airflow, consulta Concetti di Airflow Apache. Per maggiori informazioni sui DAG, consulta Scrittura di DAG (flussi di lavoro). Per esempi di best practice per l'ETL con Apache Airflow, consulta il sito delle best practice per l'ETL con il sito della documentazione di Airflow¶. Puoi sostituire l'operatore Hive in quell'esempio con l'operatore BigQuery e verranno applicati gli stessi concetti.

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': ['[e-mail]'],
     '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 è fornito a scopo dimostrativo e non può essere utilizzato così com'è.

Dataprep di Trifacta

Dataprep è un servizio dati che consente di esplorare visivamente, ripulire e preparare dati strutturati e non strutturati per l'analisi, il reporting e il machine learning. Esporta i dati di origine in file JSON o CSV, trasformerai i dati utilizzando Dataprep e li caricherai utilizzando Dataflow. Per un esempio, consulta Dati Oracle (ETL) in 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, per poi caricare i file Avro in BigQuery utilizzando l'bq tool. È pratica 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

Nello spazio di estrazione, trasformazione e caricamento (ETL) sono presenti diversi fornitori. I leader di mercato ETL come Informatica, Talend, Matillion, Alooma, Infoworks, Stitch, Fivetran e Striim si sono integrati profondamente con BigQuery e Oracle e possono aiutare a estrarre, trasformare, caricare dati e gestire i flussi di lavoro di elaborazione.

Gli strumenti ETL esistono da molti anni. Per alcune organizzazioni potrebbe essere pratico sfruttare un investimento esistente in script ETL attendibili. Alcune delle nostre principali soluzioni 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 dall'infrastruttura attuale e dalle competenze 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 che puoi sfruttare. Per ulteriori informazioni sulla migrazione degli strumenti BI e sull'integrazione di BigQuery, consulta la panoramica sull'analisi di BigQuery.

Traduzione di query (SQL)

GoogleSQL di BigQuery supporta la conformità allo standard SQL 2011 e include 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 per la traduzione da Oracle a BigQuery SQL.

Utilizza la traduzione SQL in gruppo per eseguire la migrazione collettiva del codice SQL oppure la traduzione SQL interattiva per tradurre le query ad hoc.

Opzioni di migrazione di Oracle

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

Opzione Oracle Advanced Analytics

Oracle offre opzioni di analisi avanzate per il data mining, algoritmi di machine learning di base (ML) e l'utilizzo di R. L'opzione Advanced Analytics richiede una 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 R open source R con Oracle Database. Nei deployment ORE standard, R è installato su un server Oracle.

Per dati o approcci al warehousing su larga scala, l'integrazione di R con BigQuery è la scelta ideale. Puoi utilizzare la libreria open source bigrquery R 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 adatti a TensorFlow ed 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, ad esempio regressione lineare, regressione logistica binaria, regressione logistica multiclasse, clustering K-means e importazioni 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 di IA (Speech-to-Text, Text-to-Speech, Dialogflow, Cloud Translation, API Cloud Natural Language, API Cloud Vision, API Cloud Vision e altre APITime18).

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

Opzione spaziale e grafico

Oracle offre l'opzione Spatial and Graph per eseguire query sulla geometria e sui grafici e richiede una licenza per questa opzione. Puoi utilizzare le funzioni geometriche 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, consulta Utilizzo dei dati di analisi geospaziale. Le funzioni e i tipi di dati spaziali di Oracle possono essere convertiti in funzioni geografica nello standard SQL di BigQuery. Le funzioni di geografia non aggiungono costi ai prezzi standard di BigQuery.

Grafico

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

Neo4j è un'altra soluzione per database a 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 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

• Scopri come ottimizzare i carichi di lavoro per l'ottimizzazione complessiva delle prestazioni e la riduzione dei costi.
• Scopri come ottimizzare lo spazio di archiviazione in BigQuery.
• Per gli aggiornamenti di BigQuery, consulta le note di rilascio.
• Consulta la guida alla traduzione SQL di Oracle.