Migrazione da Oracle a BigQuery

Questo documento fornisce indicazioni di alto livello su come eseguire la migrazione da Oracle in BigQuery. Descrive le fasi fondamentali differenze architetturali e suggerendo modi per la migrazione dai data warehouse e data mart eseguiti su Oracle RDBMS (incluso Exadata) in 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 di successo, inizia a pianificare la strategia di migrazione all'inizio della sequenza temporale del progetto. Per informazioni su come pianificare in modo sistematico il lavoro di migrazione, Che cosa e come eseguire la migrazione: framework per la migrazione.

Pianificazione della capacità di BigQuery

Di base, la velocità effettiva dell'analisi in BigQuery viene misurata in slot machine. 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 eseguite. Per ulteriori informazioni su come BigQuery determina le dimensioni dei dati, consulta Calcolo delle dimensioni dei dati. Poiché gli slot determinano di calcolo della capacità di calcolo sottostante, puoi pagare a seconda del numero di slot necessari (invece dei byte elaborati). Per impostazione predefinita, i progetti Google Cloud sono limitati a un massimo di 2000 slot.

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

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. Per un 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 inizialmente prenoti 4000 slot BigQuery eseguire contemporaneamente 100 query a complessità media. Se noti un'attesa elevata volte nei piani di esecuzione delle query e le tue dashboard mostrano di utilizzo, ciò potrebbe indicare che hai bisogno di Slot BigQuery per il supporto dei tuoi carichi di lavoro. Se vuoi acquistare slot autonomamente con impegni annuali o triennali, inizia 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 figlio di 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 offre i seguenti tipi di ruoli:

  • I ruoli predefiniti hanno lo scopo di supportare i casi d'uso comuni e gli schemi 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 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. Implementando la sicurezza a livello di riga, ottieni un controllo dell'accesso granulare.

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

Crittografia completa del disco

Oracle offre 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 viene 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 saperne di più 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 mascheramento dinamico dei dati a livello di colonna livello. Puoi utilizzare il mascheramento dei dati per oscurare selettivamente i dati delle colonne per gruppi di utenti, pur consentendo 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 Queste informazioni in evidenza ti aiutano a identificare gli ostacoli alla migrazione e a pianificare per ottenere 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 le Gerarchia dello spazio di archiviazione di BigQuery.

Gerarchia dello spazio di archiviazione di BigQuery

Conoscenza dell'architettura di archiviazione e di elaborazione delle query sottostante, come la separazione tra archiviazione (Colossus) ed esecuzione di query (Dremel) e Google Cloud alloca le risorse (Borg) può essere utile per comprendere il comportamento le differenze e l'ottimizzazione delle prestazioni delle query e della convenienza economica. Per vedi le architetture del sistema di riferimento per BigQuery, Oracle ed Exadata.

Architettura di dati e archiviazione

La struttura dei dati e di archiviazione è una parte importante di qualsiasi sistema di analisi dei dati perché influenza le prestazioni, i costi, la scalabilità e l'efficienza delle query.

BigQuery disaccoppia l'archiviazione dei dati e il computing e archivia i dati in Colossus, in cui i dati vengono compressi e archiviati a colonne denominato Capacitor.

BigQuery opera direttamente sui dati compressi senza decomprimerli utilizzando Capacitor. BigQuery fornisce set di dati come l'astrazione di massimo livello per organizzare l'accesso alle tabelle come mostrato nel diagramma precedente. Schemi ed etichette per organizzare ulteriormente le 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, multitenant viene utilizzato per creare database collegabili all'interno di un'istanza di database per e l'isolamento dei dati. 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 ibrida a colonne (HCC) per consentire agli utenti di comprimere tabelle e partizioni.

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

Esecuzione e prestazioni delle query

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

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

Oracle fornisce statistica dei dati la raccolta dei lavori. Lo ottimizzatore del database utilizza le statistiche per fornire piani di esecuzione ottimali. Indici per ricerche rapide di righe e operazioni di join. Oracle fornisce inoltre un archivio a 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. Cluster di applicazioni reali (RAC) può essere utilizzata per ottenere database con disponibilità elevata e scalabilità del server Applicazioni ad alta intensità di CPU che utilizzano lo stesso spazio di archiviazione di base.

L'ottimizzazione delle prestazioni delle query con Oracle richiede un'attenta considerazione di queste opzioni e dei parametri del database. Oracle offre diversi strumenti come Active Session History (ASH), Automatic Database Diagnostic Monitor (ADDM), Report sul Repository dei carichi di lavoro automatici (AWR), monitoraggio SQL e Consulente per l'ottimizzazione e le opzioni di annullamento e di ottimizzazione della memoria per i consulenti.

Dati agili

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

Disponibilità elevata, backup e ripristino di emergenza

Oracle fornisce Data Guard come soluzione di ripristino di emergenza e replica del database. Real Application Cluster (RAC) può essere configurato 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. Il database Flashback caratteristica può essere utilizzata per i flashback del database allo scopo di riavvolgere il database in una in un determinato momento. Lo spazio tabella Annulla contiene gli snapshot delle tabelle. È possibile eseguire query vecchi snapshot con la query di flashback e "a partire da" in base al modello DML/DDL operazioni eseguite in precedenza e 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é la coerenza forte è 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 in Oracle non è necessario il recupero point-in-time.

BigQuery è completamente gestito e si differenzia dai sistemi di database tradizionali per la sua funzionalità di backup completa. Non devi considerare i server, guasti dello spazio di archiviazione, bug di sistema e danni fisici dei dati. BigQuery replica i dati in diversi data center a seconda della località del set di dati per massimizzare l'affidabilità e la disponibilità. La funzionalità multiregione di BigQuery replica i dati tra regioni diverse 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 il viaggio nel tempo. Puoi copiare una tabella eliminata (nell'ordine per ripristinarla) utilizzando lo snapshot (dataset.table@timestamp). Puoi esportare dati da: Tabelle BigQuery per esigenze di backup aggiuntive, ad esempio il ripristino da operazioni accidentali degli utenti. 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 i costi del backup, puoi Archivia i file di esportazione in Cloud Storage Nearline Storage o Coldline Storage. e definire un criterio di ciclo di vita per eliminare i file dopo un certo periodo di tempo, a seconda dei requisiti di conservazione dei dati.

Memorizzazione nella cache

BigQuery offre cache per utente, Se i dati non cambiano, i risultati delle query vengono memorizzati nella cache per circa 24 nell'orario lavorativo locale del TAM. Se i risultati vengono recuperati dalla cache, la query non costa nulla.

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

Connessioni

BigQuery gestisce la gestione delle connessioni e non richiede la tua autorizzazione per eseguire qualsiasi configurazione lato server. BigQuery fornisce driver JDBC e ODBC. Puoi utilizzare lo Console Google Cloud o bq command-line tool per la modalità interattiva l'esecuzione di query. 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, esistono strumenti gratuiti come DBeaver.

Oracle fornisce listener, servizi, gestori di servizi, diversi parametri di configurazione e ottimizzazione e server condivisi e dedicati per gestire le connessioni al database. Oracle fornisce driver JDBC, JDBC Thin, ODBC, Oracle Client e 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 una licenza e le tariffe di assistenza basate sui conteggi dei core per le versioni di Database e Database opzioni come RAC, multitenant, Active Data Guard, partizionamento, in memoria, Real Application Testing, GoldenGate e Spazio e grafico.

BigQuery offre opzioni di prezzi flessibili in base all'utilizzo di archiviazione, query e inserimento di flussi. BigQuery offre ai clienti prezzi basati sulla capacità che necessitano di costi e capacità di slot prevedibili in regioni specifiche. Slot machine utilizzate per gli inserimenti e i caricamenti di flussi di dati non vengono conteggiati sulla capacità degli slot di 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 BigQuery possono essere etichettato con coppie chiave/valore. Le etichette possono essere utilizzate per distinguere i costi di archiviazione e i riaccreditamenti interni.

Monitoraggio e audit logging

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 servizi aziendali Gestore per il monitoraggio dei 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 dati i log di accesso sono disponibili per 30 giorni, mentre gli altri eventi di sistema e i log delle attività 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 l'integrazione con uno strumento di monitoraggio degli incidenti esistente, Per le esportazioni si può usare Pub/Sub, mentre lo sviluppo personalizzato sullo strumento esistente per leggere i log da Pub/Sub.

Gli audit log includono tutte le chiamate API, le istruzioni per le query e gli stati dei job. Tu puoi utilizzare Cloud Monitoring per monitorare nell'allocazione dei dati, i byte analizzati nelle query e archiviati e altro Metriche di BigQuery: Piano di query e tempistiche di BigQuery possono essere utilizzate 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à né ostacolano il sistema delle prestazioni. Per ulteriori informazioni, consulta le note di rilascio.

Oracle ed Exadata richiedono la gestione del database e della l'applicazione di patch, aggiornamenti e manutenzione a livello di infrastruttura. Esistono molti di Oracle e una nuova versione principale è prevista ogni anno. Sebbene le nuove versioni siano compatibili con le versioni precedenti, contesto e caratteristiche 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. Migrazione da versioni diverse potrebbero includere esigenze tecniche di conversione diverse su clausole di query e oggetti di database.

Carichi di lavoro

Oracle Exadata supporta carichi di lavoro misti, inclusi i carichi di lavoro OLTP. BigQuery è progettato per l'analisi e non per gestire carichi di lavoro OLTP. I carichi di lavoro OLTP che utilizzano lo stesso Oracle è stata migrata in Cloud SQL, Spanner o Firestore in in Google Cloud. Oracle offre opzioni aggiuntive come Advanced Analytics, Spatial e Graph. Potrebbe essere necessario riscrivere questi carichi di lavoro 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 carichi di lavoro e applicazioni. BigQuery è un servizio completamente gestito e non richiede la configurazione di parametri di inizializzazione.

Limiti e quote

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

Provisioning di BigQuery

BigQuery è una soluzione Platform as a Service (PaaS) e una soluzione con elaborazione parallela. 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 vengono allocati man mano che li utilizzi e vengono distribuiti quando rimuovi dati o elimini tabelle. Le risorse di query sono allocate in base al tipo di query e alla complessità. Ogni query utilizzano gli slot. Viene utilizzato uno scheduler di equità finale, quindi potrebbero esserci brevi in cui alcune query ricevono una quota più alta di slot, ma lo scheduler alla fine lo corregge.

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 le risorse multitenant per allocare istantaneamente blocchi di grandi dimensioni per secondi in una volta.
  • Allocazione efficiente delle risorse tra gli utenti mediante economie di scala.
  • Addebita solo i job che esegui, anziché le risorse di cui è stato eseguito il deployment, quindi paghi per le risorse che usi.

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

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 maggiori informazioni sui tipi di dati BigQuery, consulta le documentazione.

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

Indici

In molti carichi di lavoro analitici, vengono utilizzate le tabelle a colonne al posto degli archivi di righe. Ciò aumenta notevolmente le operazioni basate su colonne ed elimina l'uso di per l'analisi in batch. BigQuery archivia inoltre i dati in un formato colonnare, pertanto gli indici non sono necessari in BigQuery. Se di analisi richiede un unico piccolo insieme di accesso basato su righe, Bigtable può essere una soluzione alternativa. Se un carico di lavoro richiede l'elaborazione delle transazioni consistenze relazionali, Spanner o Cloud SQL può essere un'alternativa migliore.

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

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

Viste materializzate

Le visualizzazioni con dati materiali 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 metodi modi per aggiornare le viste materializzate in Oracle: on-commit e on demand.

La funzionalità delle viste materializzate è disponibile anche in BigQuery. BigQuery sfrutta i risultati precalcolati delle viste materializzate e quando possibile legge solo le modifiche delta dalla tabella di base e i 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 convertire una tabella non partizionata in una partizionata.

Clustering

Il clustering consente di organizzare e recuperare in modo efficiente i dati archiviati in 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 comunemente filtrata e aggregata, 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 Oracle. Una tabella temporanea contiene 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 attive 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

Analogamente a Oracle, BigQuery consente di eseguire query su dati esterni di origine. BigQuery supporta eseguire query sui dati direttamente dalle origini dati esterne, tra cui:

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

Modellazione dei dati

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

Le tabelle denormalizzate eliminano 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 del data warehouse in 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 dispone di un'architettura condivisa, con 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 e progettare ulteriormente gli schemi in base alle letture e le esigenze aziendali, riducendo la complessità e migliorando la flessibilità, la scalabilità delle prestazioni.

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 di riga, la denormalizzazione dei dati è preferibile per i database a colonne. Per maggiori informazioni Informazioni sui vantaggi della denormalizzazione dei dati e di altre ottimizzazioni delle query strategie 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 (consolida 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 dei fatti)
  • Tabella Dipendenti
  • Tabella delle località
  • Tabella dei 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 della tabella ordini/dati

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

Contenuti della tabella dei dipendenti

SalesPersonID FName LName titolo
1 Alessandro Smith Socio alle vendite
4 Lisa Rossi Socio alle vendite
12 Mario Rossi Addetto alle vendite

Contenuti della tabella dei clienti

CustomerID FName Cognome
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

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

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 a partire 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 schema DWH normalizzato (o parzialmente normalizzato) senza influire sulle prestazioni. Per ulteriori informazioni, 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. Loro sono due tabelle diverse, una per ogni entità, e le relazioni sono definite una chiave primaria e una chiave esterna come collegamento tra durante l'esecuzione di query utilizzando JOINs. BigQuery nidificato e ripetuto consentono di mantenere la stessa relazione tra le entità in una singola 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 chiamato Location.

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

Devi rendere il tuo schema sufficientemente flessibile da consentire a ogni ordine di avere più clienti: 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 dei campi nidificati e ripetuti, consulta Caricare 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. Nella In BigQuery puoi creare chiavi surrogate utilizzando row_number e Funzioni di 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 del DWH BigQuery, prendi in considerazione il concetto di dimensioni con variazioni lente (SCD). In generale, il termine SCD descrive processo di modifica (operazioni DML) nelle tabelle delle dimensioni.

Per diversi motivi, i data warehouse tradizionali utilizzano tipi di gestione cambiano e conservano i dati storici in dimensioni che cambiano lentamente. Questi sono richiesti in base alle limitazioni dell'hardware e ai requisiti di efficienza di cui abbiamo parlato in precedenza. Poiché l'archiviazione è molto più economica rispetto al calcolo scalabilità infinita, la ridondanza e la duplicazione dei dati sono incoraggiate se i risultati in query più veloci in BigQuery. Puoi utilizzare tecniche di snapshot dei dati in cui tutti i dati vengono caricati in nuove partizioni giornaliere.

Viste 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 column- e a livello di riga. A livello di colonna la sicurezza fornisce un accesso granulare alle colonne sensibili utilizzando i tag di criteri, o la classificazione dei dati basata sul tipo. Sicurezza a livello di riga per filtrare e consente l'accesso a righe specifiche di una tabella in base alle le condizioni di traffico.

Migrazione dei dati

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

Attività di migrazione

Ti consigliamo di eseguire la migrazione in fasi identificando i casi d'uso appropriati per la migrazione. Sono disponibili vari strumenti e servizi 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 necessario per la migrazione.

  • Esportazione di dati da Oracle:per ulteriori informazioni, consulta caricamento, CDC e importazione di flussi di dati 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.

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

  • Caricare i dati direttamente in BigQuery: puoi caricare i dati in BigQuery direttamente da Cloud Storage, Dataflow o tramite flussi di dati 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 raggiungono alcuni terabyte, esegui il dump dei dati e usi gcloud storage per il trasferimento può essere molto più efficiente rispetto all'uso di un database programmatico simile a JdbcIO di estrazione, perché gli approcci programmatici potrebbero richiedere un'ottimizzazione granulare delle prestazioni. Se la dimensione dei dati è superiore a qualche terabyte e sono archiviati nello spazio di archiviazione sul cloud o online (come Amazon Simple Storage Service (Amazon S3)), utilizzando 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, considera quanto segue:

  • Dimensione dei dati DWH Oracle: la dimensione dell'origine dello schema ha una dimensione significativa sul metodo di trasferimento di dati scelto, soprattutto quando la dimensione dei dati è grandi (terabyte e oltre). Quando la dimensione dei dati è relativamente piccola, Il processo di trasferimento dei dati può essere completato in meno passaggi. Gestione di e di dati su larga scala complicano l'intero processo.

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

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

Trasferimento iniziale dei dati (batch)

Un trasferimento di dati con metodo batch indica che i dati verranno esportati in modo coerente in un unico processo (ad esempio, esportare lo schema Oracle DWH in file CSV, Avro o Parquet oppure importarli in Cloud Storage e creare set di dati su BigQuery. Tutti gli strumenti ETL e è possibile utilizzare i concetti spiegati nella migrazione ETL/ELT al 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 gcloud storage, BigQuery Data Transfer Service oppure Transfer Appliance. Per saperne di più sull'ottimizzazione delle prestazioni di grandi quantità di dati trasferimenti e opzioni di trasferimento, consulta la sezione Trasferire dati di grandi dimensioni di grandi dimensioni. Quindi carica i dati da da Cloud Storage a 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 ha compromessi principalmente in termini di impatto sulle prestazioni sul sistema di origine, sviluppo requisiti di configurazione e configurazione, nonché prezzi e licenze.

CDC basata 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, vedi Oracle Technology Global Price List. Se Oracle GoldenGate per Big Data è disponibile (nel caso in cui le licenze siano già state acquisite), l'utilizzo di GoldenGate può essere una buona scelta per creare pipeline di dati per trasferire i dati (caricamento iniziale) e 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 consente di propagare i flussi i messaggi tra Oracle e altri software in modo efficiente.

Oracle LogMiner

Non sono richieste licenze speciali per LogMiner. Puoi Utilizza 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. In caso contrario, aumentando in modo monotonico la chiave, utilizzando la colonna timestamp (data modificata) con un una piccola precisione (secondi) può causare record duplicati o mancare dati, a seconda sull'operatore di volume e confronto, come > 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.

Per una migliore estrazione, deve essere presente un indice nella colonna della chiave o del timestamp delle prestazioni e un minore impatto sul database di origine. Le operazioni di eliminazione sono una per questa metodologia, perché dovrebbero essere gestiti nella fonte un'eliminazione temporanea, come il puttint con un flag eliminato e l'aggiornamento last_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 nell'ombra nelle tabelle del journal. Le tabelle del diario possono contenere intere righe per tenere traccia di ogni modifica di colonna oppure possono mantenere solo la chiave primaria con il tipo di operazione (inserisci, aggiorna o elimina). 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 anche la migrazione della piattaforma ETL/ELT a Google Cloud, chiedi al tuo fornitore se il suo strumento è autorizzato su Google Cloud e se puoi installarlo su Compute Engine o controllare Google Cloud Marketplace.

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

Riprogettazione della piattaforma ETL/ELT

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

Cloud Data Fusion

Cloud Data Fusion è un servizio CDAP gestito su Google Cloud che offre un'interfaccia visiva con numerosi plug-in per attività quali di trascinamento e sviluppo di pipeline. È possibile utilizzare Cloud Data Fusion per acquisire dati da molti tipi diversi di sistemi di origine e offre di replicazione dei flussi di dati. I plug-in Cloud Data Fusion o Oracle possono essere utilizzati per acquisire i dati da un database Oracle. R Il plug-in BigQuery può essere utilizzato per caricare i dati a BigQuery e a 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à Wrangle di Cloud Data Fusion per la pulizia dei dati per prepararsi.

Dataflow

Dataflow è una piattaforma serverless per l'elaborazione dei dati 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 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 è un flusso di lavoro completamente gestito di Google Cloud di orchestrazione basato su Apache Airflow. it consente di creare, pianificare e monitorare le pipeline distribuite nel cloud ambienti e data center on-premise. Cloud Composer fornisce operatori e contributi in grado di eseguire tecnologie multi-cloud per casi d'uso come estrazione e caricamento, trasformazioni di ELT e chiamate API REST.

Cloud Composer utilizza grafi diretti aciclici (DAG) per la pianificazione e per l'orchestrazione dei flussi di lavoro. Per comprendere il flusso d'aria generale vedi i concetti di Apache Airflow. Per ulteriori informazioni sui DAG, vedi Scrittura di DAG (flussi di lavoro). Per esempi di best practice ETL con Apache Airflow, consulta il sito 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 generale di un esempio DAG 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. Esporta i dati di origine in JSON o CSV trasformare i dati con Dataprep e caricarli usando Dataflow. Per Ad esempio, vedi Dati Oracle (ETL) a BigQuery utilizzando Dataflow e Dataprep.

Dataproc

Dataproc è un servizio Hadoop gestito da Google. Puoi utilizzare Sqoop per esportare i dati da Oracle e 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 per il settore ETL (Extraction, Transformation, and Load) spazio. leader di mercato ETL come Informatica, Talend, Matillion, Alooma, Infoworks, Stitch, Fivetran e Striim si sono profondamente integrati con BigQuery e Oracle e può aiutare a estrarre, trasformare, caricare e gestire 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. Alcuni di le principali soluzioni dei nostri partner sono incluse in BigQuery sito web partner. Sapere quando scegliere gli strumenti dei partner anziché le utilità integrate di Google Cloud dipende dalla tua infrastruttura attuale e dalla familiarità del tuo team IT con lo sviluppo di pipeline di dati in codice Java o Python.

Migrazione degli strumenti di business intelligence (BI)

BigQuery supporta una suite flessibile delle soluzioni di business intelligence (BI) per i report e le 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 di query (SQL)

GoogleSQL di BigQuery supporta la conformità allo standard SQL 2011 e include estensioni che supportano eseguire query su dati nidificati e ripetuti. Tutte le funzioni SQL conformi ad ANSI e possono essere utilizzati con modifiche minime. Per un confronto dettagliato tra la sintassi e le funzioni SQL di Oracle e BigQuery, consulta Traduzione SQL da Oracle a BigQuery riferimento.

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

Migrazione delle opzioni Oracle

Questa sezione presenta consigli e riferimenti di architettura per la conversione di applicazioni che utilizzano Oracle Data Mining, R e funzionalità di tipo spaziale e grafico.

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 Analisi avanzata richiede licenze. Puoi scegliere da un elenco completo di prodotti Google AI/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, rende il linguaggio di programmazione statistica open source R si integra con Oracle Database. Nei deployment ORE standard, R è installato su un server Oracle.

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

Google ha collaborato con RStudio per mettere a disposizione degli utenti strumenti all'avanguardia sul campo. È possibile usare RStudio per accedere a terabyte di dati in BigQuery, i modelli si adattano 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, come regressione lineare, regressione logistica binaria, regressione logistica multiclasse, clustering K-means e importazioni di modelli TensorFlow. Per ulteriori informazioni, consulta Introduzione in BigQuery ML.

La conversione dei job ODM potrebbe richiedere la riscrittura del codice. Puoi scegliere tra offerte di prodotti Google AI complete come BigQuery ML, API AI (Speech-to-Text, Sintesi vocale, Dialogflow, Cloud Translation, API Cloud Natural Language, Cloud Vision, API Timeseries Insights e altre) 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 geometriche in BigQuery senza costi o licenze aggiuntivi e utilizza un altro grafico in Google Cloud.

Spaziale

BigQuery offre funzioni e tipi di dati di analisi geospaziale. Per maggiori informazioni informazioni, vedi Utilizzo dati di analisi geospaziale. Tipi di dati Oracle Spatial e le funzioni possono essere convertite area geografica funzioni standard BigQuery SQL. Area geografica non aggiungono costi oltre ai prezzi standard di BigQuery.

Grafico

JanusGraph è un database di grafici open source soluzione che possa usare Bigtable come spazio di archiviazione di un backend cloud. Per saperne di più, consulta Esecuzione di JanusGraph su GKE con Bigtable.

Neo4j è un altro database di grafici fornita come servizio Google Cloud in esecuzione 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 sviluppati con Looker Studio o BI Engine, mentre le funzionalità a livello di applicazione come la creazione e la modifica delle righe può essere sviluppata senza programmazione AppSheet con Cloud SQL.

Passaggi successivi