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. Il presente documento fornisce dettagli applicabili a Exadata, ExaCC e Oracle Autonomous Data Warehouse anche, in quanto utilizzano Software Oracle.

Questo documento è rivolto a enterprise architect, DBA, sviluppatori di applicazioni e IT dei professionisti della sicurezza che vogliono eseguire la migrazione a BigQuery e risolvere le sfide tecniche nel processo di migrazione.

Puoi anche utilizzare traduzione SQL batch eseguire la migrazione collettiva degli script SQL 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 senza problemi, inizia a pianificare la migrazione la tua strategia 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 è l'unità di proprietà di Google necessaria per eseguire query SQL.

BigQuery calcola continuamente il numero di slot richiesti durante l'esecuzione, ma alloca gli slot alle query in base a una scheduler.

Puoi scegliere tra i seguenti modelli di prezzi quando pianifichi la capacità per Slot BigQuery:

  • Prezzi on demand: under 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 informazioni su come BigQuery determina la dimensione dei dati, vedi 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 slot BigQuery prenotazioni (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 BigQuery il monitoraggio con Cloud Monitoring e analizzare gli audit log utilizzando BigQuery. Molti clienti utilizzano Looker Studio (ad esempio, puoi vedere un esempio open source di una dashboard di Looker Studio), Looker o Tableau come frontend per visualizzare Dati dell'audit log di BigQuery, in particolare per l'utilizzo degli slot in query e progetti. Puoi anche sfruttare il sistema BigQuery e tabelle di dati per monitorare l'utilizzo degli slot tra job e prenotazioni. Per un esempio, consulta un esempio open source di una dashboard di Looker Studio.

Il monitoraggio e l'analisi regolari dell'utilizzo degli slot consentono di stimare il modo gli slot totali di cui la tua organizzazione ha bisogno man mano che la tua organizzazione 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 seguenti sezioni descrivono i controlli di sicurezza più comuni di Oracle e il modo in cui può garantire che il tuo data warehouse rimanga protetto in un Google Cloud completamente gestito di 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 alle risorse e offre una gestione degli accessi centralizzata a risorse e azioni. I tipi di risorse disponibili in BigQuery include organizzazioni, progetti, set di dati, tabelle visualizzazioni. 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, un gruppo o l'account di servizio. I ruoli di organizzazione e progetto influiscono sulla capacità di eseguire job o gestire il progetto, mentre i ruoli del set di dati influiscono sulla possibilità di accedere 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 un 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 ruoli sia predefiniti che di base, le autorizzazioni sono le autorizzazioni di ciascun ruolo individuale.

Sicurezza a livello di riga

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

Per ottenere la sicurezza a livello di riga in BigQuery, puoi utilizzare visualizzazioni 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'Advanced Security , che viene concessa in licenza separatamente.

BigQuery cripta tutti i dati at-rest e in transito per impostazione predefinita, indipendentemente dal sorgente o di qualsiasi altra condizione e questa impostazione non può essere disattivata. BigQuery supporta anche la crittografia gestita 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 oscuramento dei dati, che consentono di mascherare (oscurare) i dati restituiti dalle query emessi dalle richieste.

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 i dati sensibili che consentono l'identificazione personale (PII) 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 archiviazione separata e i livelli di calcolo scalabili in base alle esigenze della query. Dato il dell'offerta serverless BigQuery, non devi limitarti decisioni relative all'hardware; ma puoi richiedere più risorse per le tue query e utenti tramite prenotazioni. Inoltre, BigQuery non richiede del software e dell'infrastruttura sottostanti, come la gestione sistemi operativi diversi, sistemi di rete e sistemi di archiviazione, tra cui scalabilità e alta disponibilità. BigQuery si occupa della scalabilità, della gestione 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 dei sistemi di riferimento per BigQuery, Oracle ed Exadata.

Architettura di dati e archiviazione

La struttura dei dati e di archiviazione è una parte importante di qualsiasi sistema di analisi dei dati perché 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 su dati compressi senza decompressione usando 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 partizionamento per migliorare le prestazioni delle query e costi aggiuntivi, nonché per gestire il ciclo di vita delle informazioni. Le risorse di archiviazione sono allocate in base al consumo e all'implementazione man mano che rimuovi dati o elimini tabelle.

Oracle archivia i dati in formato riga utilizzando il formato a blocchi Oracle organizzato in segmenti. Gli schemi (di proprietà degli utenti) vengono utilizzati per organizzare tabelle e altri oggetti di 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 il ciclo di vita delle informazioni operations. Oracle offre diverse opzioni di archiviazione per database autonomi e RAC (Real Application Clusters) come ASM, un file system del sistema operativo e un nel file system di un cluster Kubernetes.

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

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

Esecuzione e prestazioni delle query

BigQuery gestisce le prestazioni e scala a livello di query per massimizzare il rendimento in rapporto 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 sui 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 come scansione intelligente delle celle, indici di archiviazione, cache flash e 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 valutazione di queste opzioni e 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.

Analisi agile

In BigQuery puoi abilitare progetti, utenti e gruppi diversi per eseguire query su set di dati in progetti diversi. La separazione dell'esecuzione delle query consente ai team autonomi di lavorare all'interno dei 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 dei database. Real Application Cluster (RAC) può essere configurato per la disponibilità del server. Responsabile del recupero crediti (RMAN) i backup possono essere configurati per i backup di database e archivi di log e utilizzati anche per e le operazioni di ripristino e ripristino. Il database Flashback caratteristica può essere utilizzata per i flashback del database al fine di riavvolgere il database in una in un determinato momento. Annulla tablespace contiene 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 di spazi delle tabelle che dipendono dai metadati di sistema, tablespace, perché un'elevata coerenza è importante per il backup Oracle le procedure di ripristino devono includere dati primari 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 diverso dal database tradizionale sistemi nella sua completa funzionalità di backup. Non devi considerare i server, guasti dello spazio di archiviazione, bug di sistema e danni fisici dei dati. BigQuery replica i dati tra diversi data center a seconda nella posizione del set di dati per massimizzare l'affidabilità la disponibilità del servizio. La funzionalità multiregionale di BigQuery replica i dati in diverse regioni e protegge dall'indisponibilità di una singola zona all'interno della regione. La funzionalità di BigQuery a regione singola replica i dati in zone diverse all'interno della stessa regione.

BigQuery consente di eseguire query su snapshot storici di tabelle fino a 7 giorni e ripristina le tabelle eliminate entro due giorni utilizzando 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. Pianificazione e strategia di backup comprovate per l'utilizzo per i backup possono essere usati sistemi di data warehouse (DWH) esistenti.

Le operazioni batch e la tecnica di creazione di snapshot consentono strategie per BigQuery, quindi non è necessario esportare i dati di tabelle e partizioni. Un backup dell'esportazione della partizione o della tabella è una quantità sufficiente al termine del caricamento o dell'operazione 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 offre JDBC e Driver ODBC. Puoi utilizzare lo Console Google Cloud o bq command-line tool per la modalità interattiva l'esecuzione di query. Puoi usare le API REST e il client librerie per interagire a livello di programmazione con BigQuery. Puoi connetterti Fogli Google direttamente con BigQuery e usare driver ODBC e JDBC per connetterti a Excel. Se cerchi un client desktop, puoi utilizzare gratuitamente come DBeaver.

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

Prezzi e licenze

Oracle richiede 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 in base alla 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 data warehouse, consulta Pianificazione della capacità di BigQuery.

BigQuery anche automaticamente tagli i costi di archiviazione della metà 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 da utilizzare per differenziare i costi di archiviazione e gli storni di addebito interni.

Monitoraggio e audit logging

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

Per BigQuery, si utilizza Cloud Audit Logs sia i log di accesso ai dati sia 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 un periodo di conservazione più lungo, puoi esportare i log in BigQuery, Cloud Storage o Pub/Sub come descritto in Analisi dei log di sicurezza in Google Cloud. Se 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 la risoluzione degli errori relativi a job di query e API. Per distinguere le allocazioni degli slot per una query o un job, puoi usare questa utilità, utile per che utilizzano prezzi basati sulla capacità e hanno molti progetti distribuiti diversi team.

Manutenzione, upgrade e versioni

BigQuery è un servizio completamente gestito e non richiede eseguire operazioni di manutenzione o upgrade. BigQuery non offre diverse versions. Gli upgrade sono continui e non richiedono tempi di inattività né ostacolano il sistema delle prestazioni. Per ulteriori informazioni, vedi 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.

Possono esserci applicazioni che richiedono versioni specifiche, ad esempio 10g, 11g, o 12c. Per i principali upgrade dei database sono necessarie attività di pianificazione e test accurate. 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 quelli OLTP. BigQuery è progettato per l'analisi e non per gestire carichi di lavoro OLTP. I carichi di lavoro OLTP che utilizzano lo stesso Oracle è stata migrata in Cloud SQL, Spanner o Firestore in in Google Cloud. Oracle offre opzioni aggiuntive come Advanced Analisi, spazio e grafico. Potrebbe essere necessario riscrivere questi carichi di lavoro migrazione a BigQuery. Per ulteriori informazioni, consulta Migrazione Opzioni Oracle.

Parametri e impostazioni

Oracle offre e richiede molti parametri per la configurazione e l'ottimizzazione in Sistema operativo, Database, RAC ASM e Listener diversi per carichi di lavoro e applicazioni differenti. BigQuery è una un servizio completamente gestito e non richiede la configurazione di alcuna inizializzazione parametri.

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. Offre lo scale up e lo scale down della capacità da parte dell'utente mentre Google gestisce il backend. Di conseguenza, a differenza di molti sistemi RDBMS, BigQuery non richiede il provisioning delle risorse prima dell'uso. BigQuery alloca spazio di archiviazione e query le risorse in modo dinamico, 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 il deployment di vaste risorse per evitare di dover gestire rapidamente su larga scala.
  • 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 di schemi

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

Tipi di dati Oracle e mappature BigQuery

I tipi di dati Oracle sono diversi da quelli di BigQuery. Per ulteriori informazioni sui tipi di dati 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 i dati anche in a colonne, perciò 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.

Per riepilogare, non sono necessari indici: in BigQuery inoltre sono disponibili e analisi in batch. Partizionamento o è possibile utilizzare il clustering. Per ulteriori informazioni su come ottimizzare migliorare le prestazioni delle query in BigQuery, vedi Introduzione all'ottimizzazione delle prestazioni delle query.

Visualizzazioni

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

Viste materializzate

Le viste materializzate sono di solito utilizzate per migliorare il tempo di rendering dei report i tipi di report e carichi di lavoro che richiedono la scrittura una sola volta.

Le viste materializzate sono disponibili in Oracle per aumentare le prestazioni delle visualizzazioni semplicemente la creazione e la gestione di una tabella che contiene 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à della vista materializzata è 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 di BI moderni migliorare le prestazioni ed eliminare la necessità di eseguire nuovamente la stessa query, costi aggiuntivi.

Partizionamento delle tabelle

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

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

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

Se le restrizioni di BigQuery influiscono sulla funzionalità il database migrato, valuta la possibilità di utilizzare lo sharding anziché eseguire 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 In BigQuery il clustering funziona in circostanze diverse migliori. In BigQuery, se una tabella viene comunemente filtrata e aggregata, con colonne specifiche, utilizza il clustering. Il clustering può essere presi in considerazione per la migrazione list-partitioned o organizzato in base all'indice di Oracle.

Tabelle temporanee

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

BigQuery utilizza tabelle temporanee per memorizzare nella cache i risultati delle query che non sono vengono scritte in una tabella permanente. Al termine di una query, le tabelle temporanee esistono per un massimo di 24 ore. Le tabelle vengono create in un set di dati speciale e denominate in modo casuale. Puoi anche creare tabelle temporanee per uso personale. Per ulteriori informazioni informazioni, consulta 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 dei dati a stella o a fiocco di neve possono essere efficienti per l'archiviazione analitica e sono comunemente utilizzata 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. Aggiungi a Speciali e I modelli dei dati a fiocco di neve sono supportati anche da BigQuery. Per ulteriori informazioni i dettagli di progettazione del data warehouse su BigQuery, consulta la sezione Progettazione dello schema.

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

Oracle utilizza un formato di riga in cui la riga della tabella è archiviata in blocchi di dati, le colonne non necessarie vengono recuperate all'interno del blocco per le query analitiche, in base filtri e 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 dell'archiviazione e le prestazioni delle query di analisi. Stella e fiocco di neve schemi e la modellazione di Data vault sono alcuni di questi.

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

Denormalizzazione

Uno dei principali obiettivi della normalizzazione dei database relazionali è ridurre ridondanza. 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 ulteriori informazioni Informazioni sui vantaggi della denormalizzazione dei dati e di altre ottimizzazioni delle query strategie in BigQuery, consulta Denormalizzazione.

Tecniche per rendere più uniforme lo schema esistente

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

Quando si progetta uno schema DWH di BigQuery, si crea una tabella dei fatti in un struttura della tabella piatta (che consolida tutte le tabelle delle dimensioni in un'unica record nella tabella dei fatti) è migliore per l'utilizzo dello spazio di archiviazione rispetto all'uso di più Tabelle delle dimensioni DWH. Oltre a ridurre l'utilizzo dello spazio di archiviazione, avere una tabella piatta in BigQuery riduce l'utilizzo di JOIN. Il seguente diagramma illustra un esempio di appiattimento dello schema.

Database gestione delle vendite

Esempio di appiattimento di uno schema a stella

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

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

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

Dati di vendita di esempio in uno schema a stella

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

Dati di esempio

Contenuti della tabella ordini/dati

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

Contenuti della tabella dei dipendenti

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

Contenuti della tabella dei clienti

CustomerID FName LName
1234 Amanda Lee
4567 Matt Roberto

Contenuti della tabella delle località

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

Query per suddividere i dati utilizzando LEFT OUTER JOIN

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

Output dei dati suddivisi

OrderNum CustomerID FName LName SalesPersonID FName LName quantità Località city state codice postale
O-1 1234 Amanda Lee 12 Mario Rossi 234,22 18 Bronx NY 10452
O-2 4567 Matt Roberto 1 Alessandro Rossi 192,10 27 Chicago IL 60613
O-3 12 Mario Rossi 14,66 18 Bronx NY 10452
O-4 4567 Matt Roberto 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 di campi nidificati e ripetuti, consulta un schema relazionale semplice di una tabella CUSTOMERS e una tabella ORDER/SALES. Loro sono due tabelle diverse, una per ogni entità, e le relazioni sono definite utilizzando una chiave primaria, ad esempio una chiave primaria e una chiave esterna come collegamento durante l'esecuzione di query utilizzando JOINs. BigQuery nidificato e ripetuto consentono di mantenere la stessa relazione tra le entità in una singola . Questa operazione può essere implementata inserendo tutti i dati dei clienti, mentre gli ordini sono nidificati per ciascuno dei clienti. Per ulteriori informazioni, consulta la sezione 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 relativo al cliente è contrassegnati come ripetuti. 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 portino a miglioramenti delle prestazioni. Per ulteriori informazioni sulle limitazioni e limitazioni di campi nidificati e ripetuti, consulta Caricamento denormalizzato, nidificato e dati ripetuti.

Chiavi surrogate

È comune identificare righe con chiavi univoche all'interno delle tabelle. Le sequenze sono comunemente utilizzata in Oracle per creare queste chiavi. Nel In BigQuery puoi creare chiavi surrogate utilizzando row_number e Funzioni di partition by. Per ulteriori informazioni, consulta BigQuery e chiavi surrogate: un pratico dell'IA.

Tenere traccia delle modifiche e della cronologia

Quando pianifichi una migrazione DWH di BigQuery, considera il concetto di modificare lentamente le dimensioni (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 lo snapshot dei dati tecniche in cui tutti i dati vengono caricati in nuove partizioni giornaliere.

Viste specifiche per ruolo e utente

Utilizza viste specifiche per ruolo e per utente a cui gli utenti appartengono team diversi e dovrebbero vedere 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 conditions.

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

È consigliabile eseguire la migrazione in fasi identificando un uso appropriato 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, dà un'idea delle dimensioni e dell'ambito dell'operazione di migrazione.

  • Esportazione di dati da Oracle:per ulteriori informazioni, consulta caricamento, CDC e importazione di flussi di dati da Oracle a BigQuery. ETL di caricamento possono essere usati per il caricamento iniziale.

  • Staging dei dati (in Cloud Storage): Cloud Storage è la luogo di destinazione consigliato (area temporanea) per i dati esportati da Oracle. Cloud Storage è progettato per un'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

Migrazione dei dati iniziali dal data warehouse Oracle esistente a BigQuery potrebbe essere diverso dall'ETL/ELT incrementale a seconda delle dimensioni dei dati e della larghezza di banda della rete. Lo stesso ETL/ELT pipeline, può essere utilizzato se la dimensione dei dati è di un paio di terabyte.

Se i dati raggiungono diversi terabyte, puoi eseguire il dump dei dati e usare gsutil 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 trasferimenti su larga scala (in particolare i trasferimenti con larghezza di banda di rete limitata), Trasferisci Appliance è un'opzione utile.

Vincoli 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: per decidere se il tempo di riposo è un'opzione per la migrazione BigQuery è importante. 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 gsutil, 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 la gestione dell'arrivo iniziale dei dati. Cloud Storage è un servizio di archiviazione di oggetti durevole e a disponibilità elevata senza limitazioni al numero di file e paghi solo per lo spazio di archiviazione che per gli utilizzi odierni. Il servizio è ottimizzato per funzionare con altri servizi Google Cloud come BigQuery e Dataflow.

CDC e importazione di flussi di dati da Oracle a BigQuery

Esistono diversi modi per acquisire i dati modificati da Oracle. 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 di Oracle per estrarre i log di ripetizione. puoi utilizzare GoldenGate per i big data per inserimento di flussi di log in BigQuery. GoldenGate richiede licenze per CPU. Per informazioni sul prezzo, vedi Oracle Technology Global Price List. Se Oracle GoldenGate per Big Data è disponibile (nel caso in cui le licenze siano già dell'IA), 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 dei dati.

Oracle XStream

Oracle archivia ogni commit nei file di log di ripetizione, per la CDC. Oracle XStream Out si basa su LogMiner e viene fornito da strumenti di terze parti come Debezium (a partire dalla versione 0.8) o 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 né 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. È anche disponibile in commercio usando strumenti come Attunity, Striim, o StreamSets. LogMiner potrebbe avere un impatto sulle prestazioni su un'origine molto attiva ed essere usato con cautela nei casi in cui il volume delle modifiche (il di ripetizione) è superiore a 10 GB all'ora, a seconda della CPU del server, memoria, nonché capacità e utilizzo di I/O.

CDC basata su SQL

Questo è l'approccio ETL incrementale in cui le query SQL eseguono il polling continuo tabelle di origine per eventuali modifiche in base a una chiave che aumenta monotonicamente e a colonna timestamp contenente la data dell'ultima modifica o inserita. 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 dati mancanti, a seconda sull'operatore di volume e confronto, come > o >=.

Per risolvere questi problemi, puoi utilizzare una precisione maggiore nelle colonne del timestamp, ad esempio come sei cifre frazionarie (microsecondi, la massima precisione supportata in BigQuery oppure puoi aggiungere attività di deduplicazione nel tuo ETL/ELT della pipeline in base alle chiavi aziendali e alle 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 il logging di queste operazioni in un'altra tabella utilizzando un trigger.

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). Quindi, i dati modificati possono essere acquisiti con un descritto nella sezione CDC basata su SQL. L'uso dei trigger può influisce sulle prestazioni delle transazioni e raddoppiare l'operazione DML su riga singola e latenza molto alta se è archiviata una riga intera. L'archiviazione solo della chiave primaria può ridurre questo in generale, ma in questo caso viene eseguita un'operazione JOIN con la tabella originale richiesta nell'estrazione basata su SQL, che non osserva la modifica intermedia.

Migrazione ETL/ELT

Esistono molte possibilità per gestire ETL/ELT su Google Cloud. Aspetto tecnico indicazioni sulle conversioni specifiche dei carichi di lavoro ETL non rientrano nell'ambito di questa documento. Puoi prendere in considerazione un approccio lift and shift o riprogettare i tuoi dati di integrazione in base a vincoli come costi e tempi. Per ulteriori informazioni informazioni su come eseguire la migrazione delle pipeline di dati in Google Cloud e molti per 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 la piattaforma ETL/ELT così com'è e modificare lo spazio di archiviazione necessario in 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 BigQuery.

Riprogettazione della piattaforma ETL/ELT

Se vuoi riprogettare le pipeline di dati, ti consigliamo vivamente di prendi in considerazione 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. Cloud Data Fusion o Oracle per acquisire dati da un Oracle. R Il plug-in BigQuery può essere utilizzato per caricare i dati a BigQuery e a gestire gli aggiornamenti dello schema.

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

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

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 vuole programmare le proprie pipeline di dati e usare lo stesso codice sia per i flussi di dati carichi di lavoro batch. Utilizzare JDBC per BigQuery modello in estrarre dati da Oracle o da 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 esempio Best practice per ETL con Apache Airflow, consulta Best practice per ETL con la documentazione di Airflow¶. Puoi sostituire Hive dell'esempio in questione con l'operatore BigQuery operatore, e gli stessi concetti sarebbero 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ò così com'è.

Dataprep di Trifacta

Dataprep è un servizio dati per il esplorazione, pulizia e preparazione di 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. Tu può utilizzare Sqoop per esportare i dati da Oracle e da molti database relazionali in Cloud Storage come file Avro, quindi potrai caricare i file BigQuery utilizzando bq tool. it è molto comune installare strumenti ETL come CDAP su Hadoop che utilizzano JDBC per estrarre 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, Transform 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 esistono da molti anni. Alcune organizzazioni potrebbero trovarlo è conveniente 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 rispetto Le utilità integrate di Google Cloud dipendono dall'infrastruttura attuale La familiarità del team IT nello sviluppo di pipeline di dati in codice Java o Python.

Migrazione degli strumenti di business intelligence (BI)

BigQuery supporta una suite flessibile di soluzioni di business intelligence (BI) per i report e le analisi che puoi sfruttare. Per ulteriori informazioni sulla BI per la migrazione degli strumenti e l'integrazione di BigQuery, consulta Panoramica 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 del codice SQL in blocco traduzione SQL interattiva per tradurre query ad hoc.

Migrazione delle opzioni Oracle

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

Opzione Oracle Advanced Analytics

Oracle offre opzioni di analisi avanzate per il data mining, le applicazioni algoritmi 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'istanza o server web.

Per scale di dati molto grandi o approcci al warehousing, l'integrazione di R BigQuery è la scelta ideale. Puoi usare l'open source bigrquery libreria R 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 la regressione lineare, la logistica binaria regressione logistica, regressione logistica multiclasse, clustering K-means importando 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 dell'ambiente di sviluppo per data scientist Vertex AI Training può essere usato per eseguire e valutazione dei carichi di lavoro su larga scala.

Opzione spaziale e grafico

Oracle offre l'opzione Spazio e grafico per eseguire query su geometria e grafici e richiede una licenza 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 ulteriori informazioni informazioni, vedi Utilizzo dati di analisi geospaziale. Tipi di dati spaziali Oracle 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 può usare Bigtable come spazio di archiviazione backend. 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 specifiche di Oracle e devono essere riscritti. 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