Migrazione da Oracle a BigQuery

Questo documento fornisce indicazioni generali su come eseguire la migrazione da Oracle a BigQuery. Descrive le differenze di architettura fondamentali e suggerisce metodi di migrazione dai data warehouse e dai data mart in esecuzione su Oracle RDBMS (incluso Exadata) a BigQuery. Questo documento fornisce dettagli che possono essere applicati anche a Exadata, ExaCC e Oracle Autonomous Data Warehouse, in quanto utilizzano software Oracle compatibile.

Questo documento è rivolto ad architetti aziendali, DBA, 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 batch per eseguire la migrazione collettiva degli script SQL o 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 una migrazione del data warehouse efficace, inizia a pianificare la strategia di migrazione all'inizio della sequenza temporale del progetto. Per informazioni su come pianificare sistematicamente il lavoro di migrazione, consulta Che cosa e come eseguire la migrazione: il framework di migrazione.

Pianificazione della capacità di BigQuery

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

BigQuery calcola continuamente il numero di slot richiesti dalle query durante l'esecuzione, ma li assegna in base a uno scheduler equo.

Quando pianifichi la capacità per gli slot di BigQuery, puoi scegliere tra i seguenti modelli di determinazione dei prezzi:

  • Prezzi on demand: con i prezzi on demand, BigQuery addebita i costi in base al numero di byte elaborati (dimensioni dei dati), quindi paghi solo per le query che esegui. 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 in base al numero di slot di cui hai bisogno (anziché in base ai byte elaborate). 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 (un minimo di 100) anziché pagare per i byte elaborati dalle query che esegui. Consigliamo i prezzi basati sulla capacità per i carichi di lavoro dei data warehouse aziendali, che in genere presentano molte query ELT (estrazione, caricamento e trasformazione) e di generazione di report concorrenti con un consumo prevedibile.

Per facilitare la stima degli slot, ti consigliamo di configurare il monitoraggio di BigQuery tramite Cloud Monitoring e di analizzare gli 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 dei log di controllo di BigQuery, in particolare per l'utilizzo degli slot tra query e progetti. Puoi anche utilizzare i dati delle tabelle di sistema di BigQuery per monitorare l'utilizzo degli slot tra job e prenotazioni. Come esempio, consulta un esempio open source di una dashboard di Looker Studio.

Monitorare e analizzare regolarmente l'utilizzo degli slot ti aiuta a stimare quanti slot totali sono necessari per la tua organizzazione man mano che cresce su Google Cloud.

Ad esempio, supponiamo che tu prenoti inizialmente 4000 slot BigQuery per eseguire contemporaneamente 100 query di media complessità. Se noti tempi di attesa elevati nei piani di esecuzione delle query e le tue dashboard mostrano un utilizzo elevato degli slot, potrebbe indicare che hai bisogno di altri slot BigQuery per supportare i tuoi carichi di lavoro. Se vuoi acquistare personalmente gli slot con impegni annuali o trienni, 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 Oracle comuni e come puoi assicurarti 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 alle risorse e alle 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 secondarie 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, a un gruppo o a un account di servizio. I ruoli dell'organizzazione e del progetto influiscono sulla possibilità 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 i casi d'uso comuni e i pattern di controllo dell'accesso. I ruoli predefiniti forniscono accesso granulare per 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 a un elenco di autorizzazioni specificato dall'utente.

Quando assegni a un utente sia i ruoli di base che quelli predefiniti, le autorizzazioni concesse sono l'unione delle autorizzazioni di ciascun ruolo individuale.

Sicurezza a livello di riga

Oracle Label Security (OLS) consente di limitare l'accesso ai dati su base riga per riga. Un caso d'uso tipico per la sicurezza a livello di riga è limitare l'accesso di un agente di vendita agli account che gestisce. Se implementi la sicurezza a livello di riga, ottieni controllo dell'accesso granulare dell'accesso.

Per ottenere la sicurezza a livello di riga in BigQuery, puoi utilizzare viste autorizzate e criteri di accesso a livello di riga. Per maggiori informazioni su come progettare e implementare questi criteri, consulta la sezione Introduzione alla sicurezza a livello di riga di BigQuery.

Crittografia completa del disco

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

BigQuery cripta per impostazione predefinita tutti i dati at-rest e in transito, indipendentemente dall'origine o da qualsiasi altra condizione e questa opzione 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 ti consente di mascherare (oscurare) i dati restituiti dalle query emesse dalle applicazioni.

BigQuery supporta la mascheratura dei dati dinamici a livello di colonna. Puoi utilizzare il mascheramento dei dati per oscurare in modo selettivo i dati delle colonne per gruppi di utenti, continuando a consentire l'accesso alla colonna.

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

Confronto tra BigQuery e Oracle

Questa sezione descrive le principali differenze tra BigQuery e Oracle. Questi elementi in evidenza ti 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 EDW cloud serverless con livelli di archiviazione e calcolo separati che possono essere scalati in base alle esigenze della query. Data la natura dell'offerta serverless di BigQuery, non sei limitato dalle decisioni hardware; puoi invece 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 (OS), i sistemi di rete e i sistemi di archiviazione, incluso il ridimensionamento e l'alta disponibilità. BigQuery si occupa di scalabilità, gestione e operazioni amministrative. Il seguente diagramma illustra la gerarchia dello spazio di archiviazione BigQuery.

Gerarchia dello spazio di archiviazione BigQuery

La conoscenza dell'architettura di elaborazione delle query e dello spazio di archiviazione sottostante, ad esempio la separazione tra spazio di archiviazione (Colossus) ed esecuzione di 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'economicità. Per maggiori dettagli, consulta le architetture di sistema 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 sulle prestazioni delle query, sui costi, sulla scalabilità e sull'efficienza.

BigQuery scollega l'archiviazione dei dati e l'elaborazione e archivia i dati in Colossus, dove vengono compressi e archiviati in un formato colonnare chiamato Capacitor.

BigQuery opera direttamente sui dati compressi senza decomprimerli utilizzando Capacitor. BigQuery fornisce i set di dati come astrazione di primo livello per organizzare l'accesso alle tabelle, come mostrato nel diagramma precedente. Gli schemi e le etichette possono essere utilizzati per un'ulteriore organizzazione delle tabelle. 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 sono allocate man mano che le consumi e l'allocazione viene annullata quando rimuovi i dati o elimini le tabelle.

Oracle memorizza i dati in formato riga utilizzando il formato blocco Oracle organizzato in segmenti. Gli schemi (di proprietà degli utenti) vengono utilizzati per organizzare tabelle e altri oggetti del database. A partire da Oracle 12c, la funzionalità multi-tenant viene utilizzata per creare database collegabili 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 i database autonomi e Real Application Clusters (RAC), come ASM, un file system del sistema operativo e un file system del cluster.

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

Oracle richiede una capacità di archiviazione pre-provisionata, un dimensionamento attento e configurazioni di incremento automatico su segmenti, file di dati e spazi tabella.

Esecuzione delle query e rendimento

BigQuery gestisce le prestazioni e esegue la scalabilità a livello di query per massimizzare le prestazioni in base al costo. BigQuery utilizza molte ottimizzazioni, ad esempio:

BigQuery raccoglie le statistiche delle colonne durante il caricamento dei dati e include informazioni di diagnostica relative a piani di query e tempistiche. Le risorse di query sono 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 di raccolta di statistiche dei dati. L'ottimizzatore del database utilizza le statistiche per fornire piani di esecuzione ottimali. Gli indici potrebbero essere necessari per ricerche rapide delle 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. Real Application Clusters (RAC) possono essere utilizzati per ottenere l'alta disponibilità del server e scalare le applicazioni di database che richiedono un'elevata intensità di risorse CPU utilizzando la stessa archiviazione di base.

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

Dati agili

In BigQuery puoi consentire a progetti, utenti e gruppi diversi di eseguire query sui 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 di slot e le query di fatturazione da altri progetti e dai 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 del database. Real Application Clusters (RAC) possono essere configurati per la disponibilità del server. I backup di Recovery Manager (RMAN) possono essere configurati per i backup del database e degli archivi log e utilizzati anche per le operazioni di ripristino e recupero. La funzionalità Database flashback può essere utilizzata per i flashback del database per riavvolgere il database a un determinato punto nel tempo. Lo spazio tabella Annulla contiene gli snapshot delle tabelle. È possibile eseguire query su vecchi snapshot con la query flashback e le clausole di query "da", 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 degli spazi tabella che dipendono dai metadati di sistema, dall'annullamento e dagli spazi tabella corrispondenti, perché elevata coerenza è importante per il backup di Oracle e le procedure di recupero devono includere i dati principali completi. Puoi pianificare le esportazioni a livello di schema della tabella se il recupero point-in-time non è necessario in Oracle.

BigQuery è completamente gestito e si differenzia dai sistemi di database tradizionali per la sua funzionalità di backup completa. Non devi considerare errori del server, errori di archiviazione, bug di sistema e danneggiamenti dei dati fisici. 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à multiregione di BigQuery replica i dati in più regioni e protegge dalla mancata disponibilità di una singola zona all'interno della regione. La funzionalità BigQuery a singola regione replica i dati in diverse zone all'interno della stessa regione.

BigQuery ti consente di eseguire query sugli snapshot storici delle tabelle fino a sette giorni e di ripristinare le tabelle eliminate entro due giorni utilizzando la viaggio nel tempo. Puoi copiare una tabella eliminata (per recuperarla) utilizzando la sintassi degli istantanei (dataset.table@timestamp). Puoi esportare i dati dalle tabelle BigQuery per ulteriori esigenze di backup, ad esempio per recuperare da operazioni utente accidentali. Per i backup è possibile utilizzare la strategia e le pianificazioni di backup collaudate utilizzate per i sistemi di data warehouse (DWH) esistenti.

Le operazioni batch e la tecnica di snapshot consentono strategie di backup diverse per BigQuery, quindi non è necessario esportare frequentemente tabelle e partizioni invariate. È sufficiente un backup dell'esportazione della partizione o della tabella al termine dell'operazione di caricamento o ETL. Per ridurre il costo del backup, puoi memorizzare i file di esportazione in Nearline Storage o Coldline Storage di Cloud 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 ha costi.

Oracle offre diverse cache per i dati e i risultati delle query, ad esempio cache buffer, cache dei risultati, Exadata Flash Cache e in-memory column store.

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 bq command-line tool per eseguire query interactive. Puoi utilizzare le API REST e le librerie client per interagire in modo programmatico con BigQuery. Puoi collegare Fogli Google direttamente a BigQuery e utilizzare i driver ODBC e JDBC per connetterti a Excel. Se cerchi un client desktop, sono disponibili 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 al database. Oracle fornisce driver JDBC, JDBC Thin, ODBC, Oracle Client e connessioni TNS. Gli ascoltatori di scansione, gli indirizzi IP di scansione e il nome della scansione sono necessari per le configurazioni RAC.

Prezzi e licenze

Oracle richiede tariffe di licenza e di assistenza in base al numero di core per le versioni del database e le opzioni del database come RAC, multitenant, Active Data Guard, partizionamento, in-memory, Real Application Testing, GoldenGate, nonché Spatial e Graph.

BigQuery offre opzioni di prezzi flessibili basate sull'utilizzo di spazio di archiviazione, query e inserimenti di streaming. BigQuery offre un sistema di determinazione dei prezzi in base alla capacità per i clienti che hanno bisogno di costi e capacità di slot prevedibili in regioni specifiche. Gli slot utilizzati per gli inserimenti e i caricamenti di streaming non vengono conteggiati nella capacità degli slot del progetto. Per decidere quanti slot acquistare per il tuo data warehouse, consulta Pianificazione della capacità di BigQuery.

BigQuery inoltre dimezza automaticamente i costi di archiviazione per i 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 distinguere i costi di archiviazione e i riaccreditamenti interni.

Monitoraggio e log di controllo

Oracle fornisce diversi livelli e tipi di opzioni di controllo del database, nonché vault di controllo e funzionalità di firewall del database, che sono concesse in licenza separatamente. Oracle fornisce Enterprise Manager per il monitoraggio del database.

Per BigQuery, Cloud Audit Logs viene utilizzato sia per i log di accesso 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à amministrative 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, Pub/Sub può essere utilizzato per le esportazioni e deve essere eseguito lo sviluppo personalizzato sullo strumento esistente per leggere i log da Pub/Sub.

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

Il piano di query.

Puoi utilizzare la tabella dei messaggi di errore per risolvere i problemi relativi ai job di query e agli errori dell'API. Per distinguere le allocazioni degli slot per query o job, puoi utilizzare questa utility, che è utile per i clienti che utilizzano i prezzi basati sulla capacità e hanno molti progetti distribuiti tra diversi team.

Manutenzione, upgrade e versioni

BigQuery è un servizio completamente gestito e non richiede alcuna manutenzione o upgrade. BigQuery non offre versioni diverse. Gli upgrade sono continui e non richiedono tempi di inattività o compromettono le prestazioni del sistema. Per ulteriori informazioni, consulta le note di rilascio.

Oracle ed Exadata richiedono l'esecuzione di patch, upgrade e manutenzione a livello di database e infrastruttura sottostante. Esistono molte versioni di Oracle e ogni anno è prevista la release di una nuova versione principale. Sebbene le nuove versioni siano compatibili con le versioni precedenti, le prestazioni delle query, il contesto e le funzionalità possono cambiare.

Esistono applicazioni che richiedono versioni specifiche, come 10g, 11g o 12c. Per gli upgrade principali del database sono necessari pianificazione e test accurati. La migrazione da versioni diverse potrebbe includere esigenze di conversione tecnica diverse per clausole di query e oggetti database.

Carichi di lavoro

Oracle Exadata supporta carichi di lavoro misti, inclusi i carichi di lavoro OLTP. BigQuery è progettato per l'analisi e non per gestire i carichi di lavoro OLTP. I carichi di lavoro OLTP che utilizzano lo stesso Oracle devono essere sottoposti a migrazione in Cloud SQL, Spanner o Firestore in Google Cloud. Oracle offre opzioni aggiuntive come Advanced Analytics, Spatial e Graph. Questi carichi di lavoro potrebbero dover essere riscritti per la migrazione a BigQuery. Per saperne di più, consulta la sezione Opzioni di migrazione di Oracle.

Parametri e impostazioni

Oracle offre e richiede la configurazione e l'ottimizzazione di molti parametri a livello di OS, Database, RAC, ASM e Listener per diversi workload 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 in base a infrastruttura, capacità hardware, parametri, versioni software e licenze. BigQuery ha quote e limiti per azioni e oggetti specifici.

Provisioning di BigQuery

BigQuery è una piattaforma PaaS (Platform as a Service) e un data warehouse cloud con elaborazione parallela su larga scala. La sua capacità aumenta e diminuisce senza alcun intervento da parte dell'utente, poiché Google gestisce il backend. Di conseguenza, a differenza di molti sistemi RDBMS, BigQuery non richiede il provisioning delle risorse prima dell'uso. BigQuery alloca in modo dinamico le risorse di archiviazione e query in base ai tuoi pattern di utilizzo. Le risorse di archiviazione sono allocate man mano che le consumi e l'allocazione viene annullata quando rimuovi i dati o elimini le tabelle. Le risorse di query sono allocate in base al tipo di query e alla complessità. Ogni query utilizza slot. Viene utilizzato un eventuale programmatore di equità, pertanto potrebbero esserci brevi periodi in cui alcune query ricevono una quota maggiore di slot, ma lo scheduler alla fine corregge questo 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 dispiegate risorse ampie per evitare di dover eseguire rapidamente la scalabilità.
  • Utilizza risorse multitenant per allocare istantaneamente grandi blocchi per alcuni secondi alla volta.
  • Consente di allocare in modo efficiente le risorse tra gli utenti con economie di scala.
  • Ti vengono addebitati solo i job che esegui, anziché le risorse di cui hai eseguito il deployment, quindi paghi solo per le risorse che utilizzi.

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

Migrazione dello 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 ulteriori informazioni sui tipi di dati di BigQuery, consulta la documentazione ufficiale.

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

Indici

In molti carichi di lavoro di analisi, vengono utilizzate tabelle colonnari anziché insiemi di righe. Ciò aumenta notevolmente le operazioni basate su colonne ed elimina l'utilizzo degli indici per l'analisi batch. BigQuery archivia inoltre i dati in un formato colonnare, pertanto gli indici non sono necessari in BigQuery. Se il carico di lavoro di analisi richiede un singolo piccolo insieme di accessi basati su riga, Bigtable può essere un'alternativa migliore. Se un carico di lavoro richiede l'elaborazione delle transazioni con coerenze relazionali rigorose, Spanner o Cloud SQL possono essere alternative migliori.

In sintesi, in BigQuery non sono necessari e non sono offerti indici per l'analisi 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.

Visualizzazioni

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

Viste materializzate

Le visualizzazioni con memorizzazione nella cache vengono utilizzate di frequente per migliorare i tempi di rendering dei report in tipi di report e carichi di lavoro di tipo scrivi una volta, leggi molti.

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

La funzionalità delle viste materializzate è disponibile anche in BigQuery. BigQuery sfrutta i risultati precalcolati dalle viste materializzate e ogni volta che è 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 anche migliorare il rendimento 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 filtri di predicati in base alla colonna di partizione per ridurre la quantità di dati sottoposti a scansione.

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

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

Inoltre, BigQuery non supporta EXCHANGE PARTITION, SPLIT PARTITION o 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 a cui si accede spesso insieme. Tuttavia, Oracle e BigQuery hanno circostanze diverse in cui il clustering funziona meglio. In BigQuery, se una tabella viene filtrata e aggregata comunemente con colonne specifiche, utilizza il clustering. Il clustering può essere preso in considerazione per la migrazione di tabelle partizionate per elenco o organizzate in base all'indice da Oracle.

Tabelle temporanee

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

BigQuery utilizza le tabelle temporanee per memorizzare nella cache i risultati delle query che non vengono scritti in una tabella permanente. Al termine di una query, le tabelle temporanee rimangono disponibili per un massimo di 24 ore. Le tabelle vengono create in un set di dati speciale e rinominate in modo randomico. Puoi anche creare tabelle temporanee per uso personale. Per ulteriori informazioni, consulta la sezione Tabelle temporanee.

Tabelle esterne

Come Oracle, BigQuery ti consente di eseguire query su origini dati esterne. BigQuery supporta l'esecuzione di query sui dati direttamente dalle origini dati esterne, tra cui:

  • Amazon Simple Storage Service (Amazon S3)
  • Azure Blob Storage
  • 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 di dati di 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 data warehouse su BigQuery, consulta Progettazione dello schema.

Formato riga e formato colonna e limiti del server rispetto a serverless

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

Oracle ha un'architettura condivisa, con dipendenze di 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 dello spazio di archiviazione e il rendimento delle query di analisi. Schema a stella e a forma di fiocco di neve e modellazione dei data vault sono alcuni di questi.

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

Denormalizzazione

Uno degli obiettivi principali 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 colonnari. Per ulteriori informazioni sui vantaggi della denormalizzazione dei dati e su altre strategie di ottimizzazione delle query in BigQuery, consulta Denormalizzazione.

Tecniche per appianare lo schema esistente

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

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

Database di gestione delle vendite

Esempio di appiattimento di uno schema a stella

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

  • Tabella ordini/vendite (tabella di fatto)
  • Tabella Dipendenti
  • Tabella delle località
  • Tabella Clienti

La chiave primaria della tabella delle vendite è OrderNum, che contiene anche le 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 delle tabelle ordini/di fatto

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 titolo
1 Alex Smith Addetto alle vendite
4 Lisa Rossi Addetto alle vendite
12 Mario Rossi Addetto alle vendite

Contenuti della tabella dei clienti

CustomerID FName LName
1234 Amanda Lee
4567 Matt Ryan

Contenuti della tabella Località

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

Query per appiattire 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 resi bidimensionali

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

Visualizza

CA 90210

Campi nidificati e ripetuti

Per progettare e creare uno schema DWH da uno schema relazionale (ad esempio schemi a stella e a fiocco di neve contenenti tabelle di dimensioni e fatti), BigQuery presenta la funzionalità dei campi nidificati e ripetuti. Pertanto, le relazioni possono essere conservate in modo simile a uno schema DWH normalizzato (o parzialmente normalizzato) relazionale 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, esamina un semplice schema relazionale di una tabella CUSTOMERS e una tabella ORDER/SALES. Si tratta di 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 utilizzando i JOIN. I campi nidificati e ripetuti di BigQuery ti consentono di mantenere la stessa relazione tra le entità in un'unica tabella. Questo può essere implementato disponendo di tutti i dati dei clienti, mentre i dati degli ordini sono nidificati per ciascun cliente. Per ulteriori informazioni, consulta Specificare 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 denominato Location.

I campi OrderNum e amount non sono nidificati, in quanto rappresentano elementi unici.

Lo schema deve essere sufficientemente flessibile da consentire a ogni ordine di avere più di un cliente: uno principale e uno secondario. Il campo 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 su limitazioni e vincoli, consulta Specificare colonne nidificate e ripetute negli schemi delle tabelle.

Chiavi surrogate

È comune identificare le 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.

Monitoraggio delle modifiche e della cronologia

Quando pianifichi una migrazione del DWH BigQuery, prendi in considerazione il concetto di dimensioni con variazioni lente (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 diversi tipi per gestire le modifiche dei dati e conservare i dati storici in dimensioni che cambiano lentamente. Questi tipi di utilizzo sono necessari per le limitazioni hardware e i requisiti di efficienza discussi in precedenza. Poiché lo spazio di archiviazione è molto più economico dell'elaborazione e infinitamente scalabile, la ridondanza e la duplicazione dei dati sono incoraggiate se si traducono in query più rapide in BigQuery. Puoi utilizzare le tecniche di snapshot dei dati in cui tutti i dati vengono caricati in nuove partizioni giornaliere.

Visualizzazioni specifiche per ruolo e utente

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

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

Migrazione dei dati

Questa sezione fornisce informazioni sulla migrazione dei dati da Oracle a BigQuery, tra cui il caricamento iniziale, il rilevamento dei dati modificati (CDC) e gli approcci e gli strumenti ETL/ELT.

Attività di migrazione

Ti consigliamo di eseguire la migrazione in fasi identificando i casi d'uso appropriati per la migrazione. Esistono diversi strumenti e servizi disponibili per eseguire la migrazione dei dati da Oracle a Google Cloud. Sebbene questo elenco non sia esaustivo, fornisce un'idea delle dimensioni e dell'ambito dell'impegno di migrazione.

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

  • Livello intermedio dei dati (in Cloud Storage): Cloud Storage è la destinazione consigliata (area di staging) per i dati esportati da Oracle. Cloud Storage è progettato per l'importazione rapida e flessibile di dati strutturati o non strutturati.

  • Procedura ETL: per ulteriori informazioni, consulta la migrazione ETL/ELT.

  • Caricare i dati direttamente in BigQuery:puoi caricare i dati in BigQuery direttamente da Cloud Storage, tramite Dataflow o tramite streaming in tempo reale. Utilizza Dataflow quando è necessaria 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 non superano qualche terabyte, il loro svuotamento e l'utilizzo di gcloud storage per il trasferimento può essere molto più efficiente rispetto all'utilizzo di una metodologia di estrazione di database programmatici come JdbcIO, in quanto gli approcci programmatici potrebbero richiedere una ottimizzazione del rendimento molto più granulare. Se le dimensioni dei dati sono superiori a qualche terabyte e i dati sono archiviati in cloud o in un'unità di archiviazione 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 quelli con larghezza di banda di rete limitata), Transfer Appliance è un'opzione utile.

Limitazioni per il caricamento iniziale

Quando pianifichi la migrazione dei dati, tieni presente quanto segue:

  • Dimensioni dei dati del DWH Oracle: le dimensioni dell'origine dello schema hanno un peso significativo sul metodo di trasferimento dei dati scelto, soprattutto quando le dimensioni dei dati sono elevate (terabyte e oltre). Quando le dimensioni dei dati sono relativamente ridotte, la procedura di trasferimento dei dati può essere completata in meno passaggi. Gestire dimensioni dei dati su larga scala rende il processo complessivo più complesso.

  • Tempo di riposo:è importante decidere se il tempo di riposo è un'opzione per la migrazione a BigQuery. Per ridurre i tempi di riposo, puoi caricare collettivamente i dati storici stabili e disporre di una soluzione CDC per recuperare 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 strumenti ETL o di replica) che richiedono licenze aggiuntive.

Trasferimento iniziale dei dati (batch)

Il trasferimento dei dati utilizzando un metodo batch indica che i dati verranno esportati in modo coerente in un'unica operazione (ad esempio, esportando i dati dello schema DWH di Oracle in file CSV, Avro o Parquet o importandoli in Cloud Storage per creare set di dati su BigQuery. Per il caricamento iniziale è possibile utilizzare tutti gli strumenti e i concetti ETL spiegati nella sezione Migrazione ETL/ELT.

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 su Cloud Storage utilizzando gcloud storage, BigQuery Data Transfer Service o Transfer Appliance. Per ulteriori informazioni sull'ottimizzazione delle prestazioni dei trasferimenti di dati di grandi dimensioni e sulle opzioni di trasferimento, consulta Trasferire set di dati di grandi dimensioni. Poi carica i dati da Cloud Storage in BigQuery.

Cloud Storage è ideale per gestire la destinazione iniziale dei dati. Cloud Storage è un servizio di archiviazione di oggetti ad alta disponibilità e duraturo senza limitazioni sul numero di file e 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 CDC e streaming da Oracle a BigQuery

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

CDC basato su log

Oracle GoldenGate è lo strumento consigliato da Oracle per l'estrazione dei log di ripristino e puoi utilizzare GoldenGate per Big Data per lo streaming dei 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), l'utilizzo di GoldenGate può essere una buona scelta per creare pipeline di dati per trasferire i dati (caricamento iniziale) e poi sincronizzare tutte le modifiche ai dati.

Oracle XStream

Oracle archivia ogni commit in file di log di ripetizione e questi file di ripetizione possono essere utilizzati per la CDC. Oracle XStream Out è basato su LogMiner e fornito da strumenti di terze parti come Debezium (a partire dalla versione 0.8) o commercialmente utilizzando strumenti 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 ti consente di propagare i messaggi Streams tra Oracle e altro software in modo efficiente.

Oracle LogMiner

Non è richiesta alcuna licenza speciale per LogMiner. Puoi utilizzare l'opzione LogMiner nel connettore della community Debezium. È disponibile anche a livello commerciale 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 (le dimensioni del riaggiornamento) è superiore a 10 GB all'ora, a seconda della CPU, della memoria e della capacità e dell'utilizzo I/O del server.

CDC basata su SQL

Si tratta dell'approccio ETL incrementale in cui le query SQL eseguono continuamente il polling delle tabelle di origine per rilevare eventuali modifiche in base a una chiave in aumento monotonica e a una colonna timestamp che contiene la data dell'ultima modifica o inserimento. Se non è presente una chiave con incremento monotono, l'utilizzo della colonna timestamp (data di modifica) con una precisazione ridotta (secondi) può causare record duplicati o dati mancanti a seconda del volume e dell'operatore di confronto, ad esempio > o >=.

Per superare questi problemi, puoi utilizzare una precisione maggiore nelle colonne timestamp, ad esempio sei cifre decimali (microsecondi, ovvero la precisione massima supportata in BigQuery) oppure puoi aggiungere attività di deduplica 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 dell'estrazione e ridurre l'impatto sul database di origine. Le operazioni di eliminazione rappresentano un problema per questa metodologia perché devono essere gestite nell'applicazione di origine con un'eliminazione temporanea, ad esempio inserendo un flag di eliminazione e aggiornandolast_modified_date. Una soluzione alternativa può essere registrare queste operazioni in un'altra tabella utilizzando un attivatore.

Trigger

È possibile creare trigger di database nelle tabelle di origine per registrare le modifiche nelle tabelle di log shadow. Le tabelle di log possono contenere intere righe per tenere traccia di ogni variazione di colonna oppure possono conservare solo la chiave primaria con il tipo di operazione (inserimento, aggiornamento o eliminazione). I dati modificati possono essere acquisiti con un approccio basato su SQL descritto in CDC basato su SQL. L'utilizzo degli attivatori può influire sul rendimento delle transazioni e raddoppiare la latenza dell'operazione DML con una riga se viene archiviata una riga completa. La memorizzazione 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 tiene conto della 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 prendere in considerazione un approccio lift and shift o riprogettare la tua piattaforma di integrazione dei dati in base a vincoli quali costi e tempi. Per ulteriori informazioni su come eseguire la migrazione delle pipeline di dati a Google Cloud e su molti altri concetti di migrazione, consulta Eseguire la migrazione delle 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 invariata la piattaforma ETL/ELT e modificare le fasi di archiviazione necessarie con BigQuery nei tuoi job ETL/ELT.
  • Se vuoi eseguire la migrazione anche della piattaforma ETL/ELT a Google Cloud, puoi chiedere al tuo fornitore se il suo strumento è concesso in licenza su Google Cloud. Se è così, puoi installarlo su Compute Engine o controllare Google Cloud Marketplace.

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

Nuova architettura della piattaforma ETL/ELT

Se vuoi riprogettare le tue pipeline di dati, ti consigliamo vivamente di utilizzare i servizi Google Cloud.

Cloud Data Fusion

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

Non è definito alcuno schema di output sia nei plug-in di origine che in quelli di destinazione e select * from viene utilizzato nel plug-in di origine anche per replicare le nuove colonne.

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

Dataflow

Dataflow è una piattaforma di elaborazione dei dati serverless che può eseguire l'autoscaling e l'elaborazione dei dati in batch e in streaming. 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 sia per i carichi di lavoro in streaming sia per quelli batch. Utilizza il modello JDBC to BigQuery per estrarre i dati da Oracle o altri database relazionali e caricarli in BigQuery.

Cloud Composer

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

Cloud Composer utilizza grafici aciclici diretti (DAG) per pianificare e orchestrare i flussi di lavoro. Per comprendere i concetti generali di Airflow, consulta Concetti di Apache Airflow. Per ulteriori informazioni sui DAG, consulta Scrittura di DAG (flussi di lavoro). Per esempi di best practice ETL con Apache Airflow, consulta il sito di documentazione delle best practice ETL con Airflow. Puoi sostituire l'operatore Hive in questo esempio con l'operatore BigQuery, e gli stessi concetti saranno applicabili.

DAG di esempio

Il seguente codice campione è una parte di alto livello 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 è fornito a scopo dimostrativo e non può essere utilizzato così com'è.

Dataprep di Trifacta

Dataprep è un servizio dati che consente di esplorare in modo visivo, pulire e preparare dati strutturati e non strutturati per l'analisi, il reporting e il machine learning. Esporti i dati di origine in file JSON o CSV, trasformali utilizzando Dataprep e caricali utilizzando Dataflow. Per un esempio, consulta Eseguire l'ETL dei dati Oracle in BigQuery utilizzando Dataflow e Dataprep.

Dataproc

Dataproc è un servizio Hadoop gestito da Google. Puoi utilizzare Sqoop per esportare i dati da Oracle e da molti database relazionali in Cloud Storage come file Avro e poi caricare i file Avro in BigQuery utilizzando bq tool. È molto comune installare strumenti ETL come CDAP su Hadoop 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 nel campo dell'estrazione, della trasformazione e del caricamento (ETL). I leader di mercato ETL come Informatica, Talend, Matillion, Alooma, Infoworks, Stitch, Fivetran e Striim sono profondamente integrati sia con BigQuery che con Oracle e possono aiutarti a estrarre, trasformare, caricare i dati e gestire i flussi di lavoro di elaborazione.

Gli strumenti ETL sono disponibili da molti anni. Per alcune organizzazioni potrebbe essere utile sfruttare un investimento esistente in script ETL attendibili. Alcune delle nostre soluzioni partner principali sono incluse nel sito web del partner BigQuery. Sapere quando scegliere gli strumenti di partner anziché le utilità integrate di Google Cloud dipende dalla tua infrastruttura attuale e dalla dimestichezza del tuo team IT con lo sviluppo di pipeline di dati in codice Java o Python.

Migrazione dello strumento 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 di BI e sull'integrazione di BigQuery, consulta la Panoramica dell'analisi di BigQuery.

Traduzione delle query (SQL)

GoogleSQL di BigQuery supporta la conformità allo standard SQL 2011 e dispone di estensioni che supportano le query sui dati nidificati e ripetuti. Tutti gli operatori e le funzioni SQL conformi allo standard ANSI possono essere utilizzati con modifiche minime. Per un confronto dettagliato tra la sintassi e le funzioni SQL di Oracle e BigQuery, consulta il riferimento per la traduzione da SQL Oracle a BigQuery.

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

Opzioni di migrazione di Oracle

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

Opzione Oracle Advanced Analytics

Oracle offre opzioni di analisi avanzata per il data mining, algoritmi di base di machine learning (ML) e utilizzo di R. L'opzione Dati avanzati richiede la licenza. Puoi scegliere tra un elenco completo di prodotti Google di IA/ML, in base alle tue esigenze, dallo sviluppo alla produzione su larga scala.

Oracle R Enterprise

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

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

Google ha stretto una partnership con RStudio per mettere a disposizione degli utenti gli strumenti più all'avanguardia del settore. RStudio può essere utilizzato per accedere a terabyte di dati in BigQuery, adattare i modelli in 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.

Oracle Data Mining

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 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 le offerte di prodotti di IA di Google, come BigQuery ML, le API di IA (Speech-to-Text, Text-to-Speech, Dialogflow, Cloud Translation, API Cloud Natural Language, Cloud Vision, API Timeseries Insights e altre ancora) o Vertex AI.

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 di calcolo del punteggio su larga scala.

Opzione Spaziale e grafico

Oracle offre l'opzione Spaziale e grafico per eseguire query su geometria e grafici e richiede l'ottenimento di licenze 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 per l'analisi geospaziale. Per ulteriori informazioni, consulta Utilizzare i dati di analisi geospaziali. I tipi di dati e le funzioni di Oracle Spatial possono essere convertiti in funzioni geografiche in SQL standard di BigQuery. Le funzioni geografiche non comportano costi aggiuntivi rispetto 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 Eseguire JanusGraph su GKE con Bigtable.

Neo4j è un'altra soluzione di database di grafo offerta come servizio Google Cloud ed eseguita su Google Kubernetes Engine (GKE).

Oracle Application Express

Le applicazioni Oracle Application Express (APEX) sono un'esclusiva 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 delle righe possono essere sviluppate senza scrivere codice su AppSheet utilizzando Cloud SQL.

Passaggi successivi