Migration von Oracle zu BigQuery
Dieses Dokument bietet eine allgemeine Anleitung zur Migration von Oracle zu BigQuery. Es werden die grundlegenden Architekturunterschiede beschrieben und Möglichkeiten für die Migration zu BigQuery von Data Warehouses und Data-Marts vorgeschlagen, die auf Oracle RDBMS (einschließlich Exadata) ausgeführt werden. Dieses Dokument enthält Details, die auch auf Exadata, ExaCC und Oracle Autonomous Data Warehouse angewendet werden können, da sie kompatible Oracle-Software verwenden.
Dieses Dokument richtet sich an Unternehmensarchitekten, Datenbankadministratoren, Anwendungsentwickler und IT-Sicherheitsexperten, die von Oracle zu BigQuery migrieren und technische Herausforderungen im Migrationsprozess lösen möchten.
Verwenden Sie die Batch-SQL-Übersetzung, um Ihre SQL-Skripts im Bulk zu migrieren, oder die interaktive SQL-Übersetzung, um Ad-hoc-Abfragen zu übersetzen. Oracle SQL, PL/SQL und Exadata werden von beiden Tools in der Vorschau unterstützt.
Vor der Migration
Um eine erfolgreiche Data Warehouse-Migration zu gewährleisten, sollten Sie Ihre Migrationsstrategie frühzeitig im Zeitplan Ihres Projekts planen. Weitere Informationen zur systematischen Planung Ihrer Migration finden Sie unter Was und wie migrieren: der Migrations-Framework.
BigQuery-Kapazitätsplanung
Intern wird der Analysedurchsatz in BigQuery in Slots gemessen. Ein BigQuery-Slot ist die proprietäre Rechenkapazität von Google, die zum Ausführen von SQL-Abfragen erforderlich ist.
BigQuery berechnet kontinuierlich, wie viele Slots von den Abfragen benötigt werden, während es Abfragen ausführt. Es ordnet aber basierend auf einem fairen Planer Slots zu.
Bei der Kapazitätsplanung für BigQuery-Slots können Sie zwischen den folgenden Preismodellen wählen:
On-Demand-Preis: Bei On-Demand-Preisen berechnet BigQuery die Anzahl der verarbeiteten Byte (Datengröße), sodass Sie nur für die ausgeführten Abfragen zahlen. Weitere Informationen dazu, wie BigQuery die Datengröße bestimmt, finden Sie unter Datengrößenberechnung. Da Slots die zugrunde liegende Rechenkapazität bestimmen, können Sie für die BigQuery-Nutzung abhängig von der Anzahl der benötigten Slots (statt der verarbeiteten Byte) bezahlen. Standardmäßig sind Google Cloud-Projekte auf maximal 2.000 Slots beschränkt.
Kapazitätsbasierte Preise: Bei kapazitätsbasierten Preisen erwerben Sie BigQuery-Slot-Reservierungen (mindestens 100), anstatt für die Byte zu bezahlen, die von ausgeführten Abfragen verarbeitet werden. Wir empfehlen kapazitätsbasierte für Data Warehouse-Arbeitslasten in Unternehmen, bei denen häufig viele Abfragen für gleichzeitige Berichterstellung und ELT (Extract-Load-Transform) vorliegen, die vorhersehbar sind.
Um die Slot-Schätzung zu unterstützen, empfehlen wir die Einrichtung von BigQuery-Monitoring mit Cloud Monitoring und die Analyse Ihrer Audit-Logs mit BigQuery. Viele Kunden nutzen Looker Studio (sehen Sie sich etwa ein Open Source-Beispiel eines Looker Studio-Dashboards an), Looker oder Tableau als Front-Ends zur Visualisierung von BigQuery-Audit-Logdaten, insbesondere für die Slot-Nutzung über Abfragen und Projekte hinweg. Außerdem können Sie die Systemtabellendaten von BigQuery verwenden, um die Slot-Auslastung für Jobs und Reservierungen zu überwachen. Sehen Sie sich zur Verdeutlichung ein Open Source-Beispiel eines Looker Studio-Dashboards an.
Durch regelmäßiges Monitoring und regelmäßige Analysen der Slot-Auslastung können Sie abschätzen, wie viele Slots Ihr Unternehmen benötigt, während Sie in Google Cloud wachsen.
Beispiel: Sie reservieren zuerst 4.000 BigQuery-Slots, um 100 Abfragen mit mittlerer Komplexität gleichzeitig auszuführen. Wenn Sie in den Ausführungsplänen Ihrer Abfragen hohe Wartezeiten feststellen und Ihre Dashboards eine hohe Slot-Auslastung zeigen, kann dies darauf hindeuten, dass Sie zusätzliche BigQuery-Slots benötigen, um Ihre Arbeitslasten zu unterstützen. Wenn Sie Slots selbst über jährliche oder dreijährige Zusicherungen erwerben möchten, können Sie mit den BigQuery-Reservierungen in der Google Cloud Console oder dem bq-Befehlszeilentool beginnen.
Wenden Sie sich bei Fragen zu Ihrem aktuellen Tarif und den vorherigen Optionen an Ihren Vertriebsmitarbeiter.
Sicherheit in Google Cloud
In den folgenden Abschnitten werden allgemeine Oracle-Sicherheitskontrollen beschrieben und wie Sie dafür sorgen können, dass Ihr Data Warehouse in einer Google Cloud-Umgebung geschützt ist.
Identitäts- und Zugriffsverwaltung (IAM)
Oracle bietet Nutzer, Berechtigungen, Rollen und Profile zur Verwaltung des Zugriffs auf Ressourcen.
BigQuery verwendet IAM zur Verwaltung des Zugriffs auf Ressourcen und bietet eine zentrale Zugriffsverwaltung für Ressourcen und Aktionen. In BigQuery stehen folgende Ressourcentypen zur Verfügung: Organisationen, Projekte, Datasets, Tabellen und Ansichten. In der Richtlinienhierarchie von IAM sind die Datasets die untergeordneten Ressourcen von Projekten. Eine Tabelle übernimmt die Berechtigungen des Datasets, das sie enthält.
Wenn Sie Zugriff auf eine Ressource gewähren möchten, weisen Sie einem Nutzer, einer Gruppe oder einem Dienstkonto eine oder mehrere Rollen zu. Die Rollen "Organisation" und "Projekt" wirken sich auf die Fähigkeit zum Ausführen von Jobs oder Verwalten des Projekts aus. Die Rolle "Dataset" wiederum wirkt sich auf die Fähigkeit aus, auf die Daten in einem Projekt zuzugreifen oder sie zu bearbeiten.
IAM bietet folgende Rollentypen:
- Vordefinierte Rollen sollen allgemeine Anwendungsfälle und Zugriffskontrollmuster unterstützen. Vordefinierte Rollen ermöglichen einen genau definierten Zugriff auf einen bestimmten Dienst und werden von Google Cloud verwaltet.
Zu einfachen Rollen gehören die Rollen „Inhaber“, „Bearbeiter“ und „Betrachter“.
Benutzerdefinierte Rollen ermöglichen einen genau definierten Zugriff gemäß einer vom Nutzer angegebenen Liste von Berechtigungen.
Wenn Sie einem Nutzer sowohl vordefinierte als auch einfache Rollen zuweisen, werden ihm die Berechtigungen beider Rollen gewährt.
Sicherheit auf Zeilenebene
Mit Oracle Label Security (OLS) können Sie den Datenzugriff Zeile für Zeile einschränken. Ein typischer Anwendungsfall für die Sicherheit auf Zeilenebene ist die Beschränkung des Zugriffs eines Vertriebsmitarbeiters auf die von ihm verwalteten Konten. Die Implementierung der Sicherheit auf Zeilenebene ermöglicht eine differenzierte Zugriffssteuerung.
Um die Sicherheit auf Zeilenebene in BigQuery zu erlangen, können Sie autorisierte Ansichten und Zugriffsrichtlinien auf Zeilenebene verwenden. Weitere Informationen zum Entwerfen und Implementieren dieser Richtlinien finden Sie unter Einführung in die BigQuery-Sicherheit auf Zeilenebene.
Festplattenverschlüsselung
Oracle bietet Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) und Netzwerkverschlüsselung für die Verschlüsselung ruhender Daten und Daten während der Übertragung. TDE erfordert die Option "Advanced Security", die separat lizenziert ist.
BigQuery verschlüsselt standardmäßig alle ruhenden Daten und Daten während der Übertragung unabhängig von der Quelle oder einer anderen Bedingung. Dies kann nicht deaktiviert werden. BigQuery unterstützt auch vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) für Nutzer, die Schlüsselverschlüsselungsschlüssel im Cloud Key Management Service steuern und verwalten möchten. Weitere Informationen zur Verschlüsselung in Google Cloud finden Sie unter Standardverschlüsselung ruhender Daten und Verschlüsselung während der Übertragung.
Datenmaskierung und -entfernung
Oracle verwendet die Datenmaskierung in Real Application Testing sowie die Datenentfernung, mit der Sie Daten maskieren (entfernen) können, die von Abfragen zurückgegeben werden, die von Anwendungen ausgegeben werden.
BigQuery unterstützt die dynamische Datenmaskierung auf Spaltenebene. Sie können die Datenmaskierung nutzen, um Spaltendaten für Nutzergruppen selektiv zu verdecken und dennoch Zugriff auf die Spalte zuzulassen.
Mit Sensitive Data Protection können Sie vertrauliche personenidentifizierbare Informationen (PII) in BigQuery identifizieren und entfernen.
BigQuery und Oracle im Vergleich
In diesem Abschnitt werden die wichtigsten Unterschiede zwischen BigQuery und Oracle beschrieben. Diese Hervorhebungen helfen Ihnen, Hürden bei der Migration zu identifizieren und die erforderlichen Änderungen einzuplanen.
Systemarchitektur
Einer der Hauptunterschiede zwischen Oracle und BigQuery liegt darin, dass BigQuery ein serverloses Cloud-EDW mit separaten Speicher- und Computing-Ebenen ist, die basierend auf den Anforderungen der Abfrage skaliert werden können. Aufgrund der Beschaffenheit des serverlosen BigQuery-Angebots sind Sie nicht durch Hardwareentscheidungen eingeschränkt. Stattdessen können Sie über Reservierungen mehr Ressourcen für Ihre Abfragen und Nutzer anfordern. BigQuery erfordert auch keine Konfiguration der zugrunde liegenden Software und Infrastruktur wie dem Betriebssystem, den Netzwerksystemen und Speichersystemen, einschließlich Skalierung und Hochverfügbarkeit. BigQuery kümmert sich um Skalierbarkeit, Verwaltung und administrative Vorgänge. Das folgende Diagramm veranschaulicht die BigQuery-Speicherhierarchie.
Kenntnisse über die zugrunde liegende Speicher- und Abfrageverarbeitungs-Architektur wie die Trennung zwischen Speicher (Colossus) und Abfrageausführung (Dremel) und die Art der Zuordnung von Ressourcen (Borg) in Google Cloud können gut zum Verständnis von Verhaltensunterschieden und zur Optimierung der Abfrageleistung und Kosteneffizienz beitragen. Weitere Informationen finden Sie in den Referenzsystemarchitekturen für BigQuery, Oracle und Exadata.
Daten- und Speicherarchitektur
Die Daten- und Speicherstruktur ist ein wichtiger Bestandteil eines jeden Datenanalysesystems, da sie die Abfrageleistung, Kosten, Skalierbarkeit und Effizienz beeinflusst.
BigQuery entkoppelt Datenspeicher und Computing und speichert Daten in Colossus, wo Daten komprimiert und in einem Spaltenformat namens Capacitor gespeichert werden.
BigQuery arbeitet direkt mit komprimierten Daten, ohne sie mithilfe von Capacitor zu dekomprimieren. BigQuery stellt Datasets als Abstraktion auf höchster Ebene bereit, um den Zugriff auf Tabellen zu organisieren, wie im vorherigen Diagramm dargestellt. Schemas und Labels können zur weiteren Organisation von Tabellen verwendet werden. BigQuery bietet eine Partitionierung, um die Abfrageleistung und die Kosten zu verbessern und den Informationslebenszyklus zu verwalten. Speicherressourcen werden nach Ihrem Verbrauch zugeordnet und wieder entfernt, wenn Sie Daten löschen oder Tabellen verwerfen.
Oracle speichert Daten im Zeilenformat mit dem Oracle-Blockformat, das in Segmenten organisiert ist. Schemas (die Nutzern gehören) werden zum Organisieren von Tabellen und anderen Datenbankobjekten verwendet. Ab Oracle 12c wird Mehrinstanzenfähigkeit verwendet, um modulare Datenbanken innerhalb einer Datenbankinstanz zur weiteren Isolierung zu erstellen. Mit der Partitionierung können die Abfrageleistung und die Informationslebenszyklus-Vorgänge verbessert werden. Oracle bietet mehrere Speicheroptionen für eigenständige Datenbanken und Real Application Clusters (RAC)-Datenbanken wie ASM, ein Dateisystem des Betriebssystems, und ein Clusterdateisystem.
Exadata bietet eine optimierte Speicherinfrastruktur in Speicherzellenservern und ermöglicht Oracle-Servern den transparenten Zugriff auf diese Daten mithilfe von ASM. Exadata bietet HCC-Optionen (Hybrid Columnar Compression), mit denen Nutzer Tabellen und Partitionen komprimieren können.
Oracle erfordert im Voraus bereitgestellte Speicherkapazität, sorgfältige Größenanpassung und Konfigurationen für automatische Inkrementierung von Segmenten, Datendateien und Tablespaces.
Abfrageausführung und -leistung
BigQuery verwaltet die Leistung und skaliert auf Abfrageebene, um die Leistung für die Kosten zu maximieren. BigQuery verwendet viele Optimierungen. Zum Beispiel:
- In-Memory-Abfrageausführung
- Mehrstufige Baumarchitektur basierend auf der Dremel-Ausführungs-Engine
- Automatische Speicheroptimierung in Capacitor
- Insgesamt 1 Petabit pro Sekunde an geteilter Bandbreite mit Jupiter
- Automatische Skalierung der Ressourcenverwaltung, um schnelle Abfragen im Petabyte-Bereich zu ermöglichen
BigQuery sammelt beim Laden der Daten Spaltenstatistiken und enthält Diagnoseinformationen zu Abfrageplänen und zeitlichen Abläufen. Abfrageressourcen werden nach Abfragetyp und Komplexität zugeordnet. Jede Abfrage verwendet eine bestimmte Anzahl an Slots, bei denen es sich um Berechnungseinheiten handelt, die eine gewisse CPU- und RAM-Größe umfassen.
Oracle bietet Jobs zum Erfassen von Daten-Statistiken. Der Datenbank-Optimierer verwendet Statistiken, um optimale Ausführungspläne bereitzustellen. Indexe sind möglicherweise für schnelle Zeilensuchvorgänge und Join-Vorgänge erforderlich. Oracle bietet auch einen In-Memory-Spaltenspeicher für In-Memory-Analysen. Exadata bietet mehrere Leistungsverbesserungen, z. B. Smart Scan von Zellen, Speicherindexe, Flash-Cache und InfiniBand-Verbindungen zwischen Speicherservern und Datenbankservern. Real Application Clusters (RAC) können verwendet werden, um Hochverfügbarkeit von Servern zu erreichen und CPU-intensive Datenbankanwendungen mit demselben zugrunde liegenden Speicher zu skalieren.
Für die Optimierung der Abfrageleistung mit Oracle müssen diese Optionen und Datenbankparameter sorgfältig berücksichtigt werden. Oracle bietet mehrere Tools, darunter Active Session History (ASH), Automatic Database Diagnostic Monitor (ADDM), AWR-Berichte (Automatic Workload Repository), der Advisor für SQL-Monitoring und -Optimierung sowie Advisors für das Rückgängigmachen und die Arbeitsspeicheroptimierung zur Leistungsoptimierung.
Agile Analytik
In BigQuery können Sie verschiedene Projekte, Nutzer und Gruppen aktivieren, um Datasets in verschiedenen Projekten abzufragen. Durch die Trennung der Abfrageausführung können autonome Teams in ihren Projekten arbeiten, ohne dass sich dies auf andere Nutzer und Projekte auswirkt, indem Slot-Kontingente getrennt und die Abrechnung von anderen Projekten und den Projekten, die die Datasets hosten, abgefragt wird.
Hochverfügbarkeit, Sicherungen und Notfallwiederherstellung
Oracle bietet Data Guard als Lösung zur Notfallwiederherstellung und Datenbankreplikation an. Real Application Clusters (RAC) können für die Serververfügbarkeit konfiguriert werden. Recovery Manager (RMAN)-Sicherungen können für Datenbank- und Archivelog-Sicherungen konfiguriert und auch für Wiederherstellungsvorgänge verwendet werden. Das Flashback-Datenbankfeature kann für Datenbank-Flashbacks verwendet werden, um die Datenbank auf einen bestimmten Zeitpunkt zurückzusetzen. Der Rückgängigmachen-Tablespace enthält Tabellen-Snapshots. Es ist möglich, alte Snapshots mit der Flashback-Abfrage und den "as of"-Abfrageklauseln abzufragen. Dies hängt von den zuvor ausgeführten DML-/DDL-Vorgängen und den Einstellungen zur Rückgängigmachen-Aufbewahrung ab. In Oracle sollte die gesamte Integrität der Datenbank in Tablespaces verwaltet werden, die von den Systemmetadaten, dem Rückgängigmachen und den entsprechenden Tablespaces abhängen, da strikte Konsistenz für Oracle-Sicherungen wichtig ist und Wiederherstellungsverfahren die vollständigen Primärdaten enthalten sollten. Sie können Exporte auf Tabellenschema-Ebene planen, wenn in Oracle keine Wiederherstellung zu einem bestimmten Zeitpunkt erforderlich ist.
BigQuery ist vollständig verwaltet und unterscheidet sich in seinen vollständigen Sicherungsfunktionen von herkömmlichen Datenbanksystemen. Sie müssen keine Server- und Speicherfehler, Systemfehler und physischen Datenfehler berücksichtigen. BigQuery repliziert Daten über verschiedene Rechenzentren hinweg, je nach Dataset-Standort, um die Zuverlässigkeit und Verfügbarkeit zu maximieren. Die multiregionale Funktion von BigQuery repliziert Daten in verschiedenen Regionen und schützt vor Nichtverfügbarkeit einer einzelnen Zone innerhalb der Region. Die BigQuery-Funktionalität mit einer einzelnen Region repliziert Daten über verschiedene Zonen hinweg innerhalb derselben Region.
Mit BigQuery können Sie mithilfe von Zeitreisen Verlaufs-Snapshots von Tabellen bis zu sieben Tage lang abfragen und gelöschte Tabellen innerhalb von zwei Tagen wiederherstellen.
Sie können eine gelöschte Tabelle (zur Wiederherstellung) kopieren. Verwenden Sie dazu die Snapshot-Syntax (dataset.table@timestamp). Sie können Daten aus BigQuery-Tabellen für zusätzliche Sicherungsanforderungen exportieren, z. B. zur Wiederherstellung nach versehentlichen Nutzervorgängen. Eine bewährte Sicherungsstrategie und Zeitpläne, die für vorhandene Data Warehouse-Systeme (DWH) genutzt werden, können für Sicherungen verwendet werden.
Batchvorgänge und die Snapshot-Erstellung ermöglichen unterschiedliche Sicherungsstrategien für BigQuery, sodass Sie unveränderte Tabellen und Partitionen nicht häufig exportieren müssen. Nach dem Abschluss des Lade- oder ETL-Vorgangs ist eine einzelne Exportsicherung der Partition oder Tabelle ausreichend. Um die Sicherungskosten zu senken, können Sie Exportdateien in Nearline Storage oder Coldline Storage von Cloud Storage speichern und eine Lebenszyklusrichtlinie definieren, um Dateien nach einer bestimmten Zeit zu löschen, abhängig von den Anforderungen an die Datenaufbewahrung.
Caching
BigQuery bietet einen Cache pro Nutzer. Wenn sich die Daten nicht ändern, werden die Ergebnisse von Abfragen etwa 24 Stunden lang im Cache gespeichert. Wenn die Ergebnisse aus dem Cache abgerufen werden, kostet die Abfrage nichts.
Oracle bietet mehrere Caches für Daten und Abfrageergebnisse an, wie den Zwischenspeichercache, den Ergebniscache, den Exadata Flash Cache und den In-Memory-Spaltenspeicher.
Verbindungen
BigQuery übernimmt die Verbindungsverwaltung und erfordert von Ihnen keine serverseitige Konfiguration. BigQuery bietet JDBC- und ODBC-Treiber. Sie können die Google Cloud Console oder das bq command-line tool für interaktive Abfragen verwenden. Sie können REST-APIs und Clientbibliotheken verwenden, um programmatisch mit BigQuery zu interagieren. Sie können Google Sheets direkt mit BigQuery verbinden und ODBC- und JDBC-Treiber verwenden, um mit Excel zu verbinden. Wenn Sie einen Desktopclient benötigen, können Sie kostenlose Tools wie DBeaver nutzen.
Oracle bietet Listener, Dienste, Dienst-Handler, mehrere Konfigurations- und Feinabstimmungs-Parameter sowie freigegebene und dedizierte Server für die Verarbeitung von Datenbank-Verbindungen. Oracle bietet JDBC, JDBC Thin, ODBC-Treiber, Oracle Client und TNS-Verbindungen. Scan-Listener, Scan-IP-Adressen und scan-name sind für RAC-Konfigurationen erforderlich.
Preise und Lizenzierung
Oracle erfordert Lizenz- und Supportgebühren auf der Grundlage der Anzahl der Kerne für Datenbankversionen und Datenbankoptionen wie RAC, Mehrinstanzenfähigkeit, Active Data Guard, Partitionierung, In-Memory, Real Application Testing, GoldenGate sowie Spatial und Graph.
BigQuery bietet flexible Preismodelle basierend auf der Nutzung von Speicher, Abfragen und Streaming-Insert-Anweisungen. BigQuery bietet kapazitätsbasierte Preise für Kunden, die in bestimmten Regionen vorhersehbare Kosten benötigen. Slots, die zum Streamen von Insert- und Ladevorgängen verwendet werden, werden nicht auf die Slot-Kapazität des Projekts angerechnet. Mehr Informationen, die Ihnen bei der Entscheidung helfen, wie viele Slots Sie für Ihr Data Warehouse erwerben sollten, finden Sie unter BigQuery-Kapazitätsplanung.
BigQuery verringert auch automatisch die Speicherkosten für unveränderte Daten um die Hälfte, wenn diese mehr als 90 Tage gespeichert sind.
Labeling
BigQuery-Datasets, -Tabellen und -Ansichten können mithilfe von Schlüssel/Wert-Paaren mit Labels versehen werden. Labels können zur Unterscheidung der Speicherkosten und internen Rückbuchungen verwendet werden.
Monitoring und Audit-Logging
Oracle bietet verschiedene Ebenen und Arten vonDatenbankprüfungs-Optionen undAudit Vault und Datenbankfirewall-Features, die separat lizenziert sind. Oracle bietet Enterprise Manager für das Datenbank-Monitoring.
Bei BigQuery werden Cloud-Audit-Logs sowohl für Datenzugriffslogs als auch für Audit-Logs verwendet, die standardmäßig aktiviert sind. Die Datenzugriffslogs sind 30 Tage lang verfügbar, die anderen Systemereignis- und Administratoraktivitätslogs sind 400 Tage lang verfügbar. Wenn Sie eine längere Aufbewahrung benötigen, können Sie Logs nach BigQuery, Cloud Storage oder Pub/Sub exportieren, wie unter Sicherheitsloganalysen in Google Cloud beschrieben. Wenn eine Integration in ein vorhandenes Tool zur Überwachung von Vorfällen erforderlich ist, kann Pub/Sub für Exporte verwendet werden und benutzerdefinierte Entwicklungen sollten mit dem vorhandenen Tool durchgeführt werden, damit Logs aus Pub/Sub gelesen werden.
Audit-Logs enthalten alle API-Aufrufe, Abfrageanweisungen und Jobstatus. Mit Cloud Monitoring können Sie die Slotzuweisung, die in Abfragen gescannten und gespeicherten Byte sowie andere BigQuery-Messwerte überwachen. Mit Abfrageplänen und Zeitachsen von BigQuery können Analysephasen und Leistung analysiert werden.
Sie können die Tabelle mit Fehlermeldungen zur Fehlerbehebung bei Abfragejob- und API-Fehlern verwenden. Um die Slot-Zuweisungen pro Abfrage oder Job zu unterscheiden, können Sie dieses Dienstprogramm verwenden. Es ist nützlich für Kunden, die kapazitätsbasierte Preise verwenden und über viele Projekte verfügen, die auf mehrere Teams verteilt sind.
Wartung, Upgrades und Versionen
BigQuery ist ein vollständig verwalteter Dienst und erfordert keine Wartung oder Upgrades von Ihnen. BigQuery bietet keine unterschiedlichen Versionen. Upgrades sind kontinuierlich, erfordern keine Ausfallzeiten und beeinträchtigen nicht die Systemleistung. Weitere Informationen finden Sie in den Versionshinweisen.
Oracle und Exadata erfordern, dass Sie Patches, Upgrades und Wartungen auf Ebene der Datenbank und der zugrunde liegenden Infrastruktur ausführen. Es gibt viele Versionen von Oracle und die Veröffentlichung einer neuen Hauptversion ist für jedes Jahr geplant. Obwohl neue Versionen abwärtskompatibel sind, können sich Abfrageleistung, Kontext und Features ändern.
Möglicherweise gibt es Anwendungen, die bestimmte Versionen wie 10g, 11g oder 12c erfordern. Bei größeren Datenbankupgrades sind sorgfältige Planung und Tests erforderlich. Die Migration von verschiedenen Versionen kann unterschiedliche technische Konvertierungsanforderungen für Abfrageklauseln und Datenbankobjekte haben.
Arbeitslasten
Oracle Exadata unterstützt gemischte Arbeitslasten, einschließlich OLTP-Arbeitslasten. BigQuery ist für Analysen vorgesehen und nicht für die Verarbeitung von OLTP-Arbeitslasten ausgelegt. OLTP-Arbeitslasten, die dasselbe Oracle verwenden, sollten zu Cloud SQL, Spanner oder Firestore in Google Cloud migriert werden. Oracle bietet zusätzliche Optionen wie Advanced Analytics und Spatial and Graph. Diese Arbeitslasten müssen für die Migration zu BigQuery möglicherweise neu geschrieben werden. Weitere Informationen finden Sie unter Oracle-Optionen migrieren.
Parameter und Einstellungen
Oracle bietet und erfordert viele Parameter, die auf der Betriebssystem-, Datenbank-, RAC-, ASM- und Listener-Ebene für verschiedene Arbeitslasten und Anwendungen konfiguriert und abgestimmt werden müssen. BigQuery ist ein vollständig verwalteter Dienst und erfordert von Ihnen keine Konfiguration von Initialisierungsparametern.
Limits und Kontingente
Oracle hat basierend auf Infrastruktur, Hardwarekapazität, Parametern, Softwareversionen und Lizenzierung harte und weiche Limits. In BigQuery gelten Kontingente und Limits für bestimmte Aktionen und Objekte.
BigQuery-Bereitstellung
BigQuery ist ein PaaS-Dienst (Platform as a Service) und ein Data Warehouse zur massiv parallelen Datenverarbeitung in der Cloud. Seine Kapazität wird ohne Eingreifen des Nutzers hoch- und herunterskaliert, da Google das Backend verwaltet. Daher ist es im Gegensatz zu vielen RDBMS-Systemen nicht erforderlich, dass Sie bei BigQuery Ressourcen bereitstellen, bevor Sie es verwenden können. BigQuery weist Speicher- und Abfrageressourcen basierend auf Ihren Nutzungsmustern dynamisch zu. Speicherressourcen werden nach Ihrem Verbrauch zugeordnet und wieder entfernt, wenn Sie Daten löschen oder Tabellen verwerfen. Abfrageressourcen werden nach Abfragetyp und Komplexität zugeordnet Jede Abfrage verwendet Slots. Es wird ein Planer für finale Gleichmäßigkeit verwendet. Daher kann es zu kurzen Zeiträumen kommen, in denen einige Abfragen einen höheren Anteil an Slots erhalten, aber der Planer korrigiert dies im Endeffekt.
In der herkömmlichen VM-Begrifflichkeit deckt BigQuery beide Aspekte ab:
- Sekundengenaue Abrechnung
- Sekundenschnelle Skalierung
Um diese Aufgabe zu erledigen, tut BigQuery Folgendes:
- Umfangreiche Ressourcen werden bereitgestellt, um nicht schnell skalieren zu müssen.
- Mehrinstanzenfähige Ressourcen werden verwendet, um große Blöcke sofort für jeweils wenige Sekunden zuzuweisen.
- Ressourcen werden effizient für alle Nutzer mit Skaleneffekten zugewiesen.
- Ihnen werden nur die von Ihnen ausgeführten Jobs und nicht die bereitgestellten Ressourcen in Rechnung gestellt, sodass Sie nur für die von Ihnen verwendeten Ressourcen zahlen.
Weitere Informationen zu den Preisen finden Sie unter Kenntnis der schnellen Skalierung und einfachen Preise von BigQuery.
Schema-Migration
Für die Migration von Daten von Oracle zu BigQuery müssen Sie die Oracle-Datentypen und BigQuery-Zuordnungen kennen.
Oracle-Datentypen und BigQuery-Zuordnungen
Oracle-Datentypen unterscheiden sich von BigQuery-Datentypen. Weitere Informationen zu BigQuery-Datentypen finden Sie in der offiziellen Dokumentation.
Einen detaillierten Vergleich der Datentypen von Oracle und BigQuery finden Sie im Übersetzungsleitfaden für Oracle SQL.
Indexe
Bei vielen analytischen Arbeitslasten werden anstelle von Zeilenspeichern Spaltentabellen verwendet. Dadurch werden die spaltenbasierten Vorgänge erheblich erhöht und die Verwendung von Indexen für Batchanalysen vermieden. BigQuery speichert Daten auch in einem Spaltenformat, sodass in BigQuery keine Indexe benötigt werden. Wenn für die Analysearbeitslast ein einzelner, kleiner zeilenbasierter Zugriffssatz erforderlich ist, ist Bigtable möglicherweise die bessere Alternative. Wenn für eine Arbeitslast eine Transaktionsverarbeitung mit strikten relationalen Konsistenzen erforderlich ist, sind Spanner oder Cloud SQL möglicherweise die besseren Alternativen.
Zusammenfassend lässt sich sagen, dass für Batchanalysen in BigQuery keine Indexe erforderlich sind und angeboten werden. Dazu können Partitionierung oder Clustering verwendet werden. Weitere Informationen zur Feinabstimmung und Verbesserung der Abfrageleistung in BigQuery finden Sie unter Einführung in die Optimierung der Abfrageleistung.
Aufrufe
Ähnlich wie Oracle können in BigQuery benutzerdefinierte Ansichten erstellt werden. Ansichten in BigQuery unterstützen jedoch keine DML-Anweisungen.
Materialisierte Ansichten
Materialisierte Ansichten werden häufig verwendet, um die Berichts-Renderingzeit in Bericht- und Workloadarten mit einem Schreib- und vielen Lesezugriffen zu verbessern.
Materialisierte Ansichten werden in Oracle angeboten, um die Ansichtsleistung zu erhöhen, indem einfach eine Tabelle für das Abfrageergebnis-Dataset erstellt und verwaltet wird. Es gibt zwei Möglichkeiten, materialisierte Ansichten in Oracle zu aktualisieren: on-commit und on-demand.
Funktionen von materialisierten Ansichten sind auch in BigQuery verfügbar. BigQuery nutzt vorausberechnete Ergebnisse aus materialisierten Ansichten und liest nach Möglichkeit nur Deltaänderungen aus der Basistabelle, um aktuelle Ergebnisse zu berechnen.
Caching-Funktionen in Looker Studio oder anderen modernen BI-Tools können auch die Leistung verbessern und die Ausführung derselben Abfrage überflüssig machen. Dies spart Kosten.
Tabellenpartitionierung
Die Tabellenpartitionierung wird in Oracle-Data Warehouses häufig verwendet. Im Gegensatz zu Oracle unterstützt BigQuery keine hierarchische Partitionierung.
BigQuery implementiert drei Arten der Tabellenpartitionierungen, mit denen Abfragen Prädikatfilter basierend auf der Partitionierungsspalte angeben können, um die Menge der gescannten Daten zu verringern.
- Nach Aufnahmezeit partitionierte Tabellen: Tabellen werden basierend auf der Aufnahmezeit der Daten partitioniert.
- Nach Spalte partitionierte Tabellen: Tabellen werden basierend auf der Spalte
TIMESTAMPoderDATEpartitioniert. - Nach Ganzzahlbereich partitionierte Tabellen: Tabellen werden nach einer Spalte mit Ganzzahlen partitioniert.
Weitere Informationen zu Limits und Kontingenten für partitionierte Tabellen in BigQuery finden Sie unter Einführung in partitionierte Tabellen.
Wenn die BigQuery-Einschränkungen die Funktionalität der migrierten Datenbank beeinträchtigen, sollten Sie anstelle der Partitionierung eine Fragmentierung erwägen.
Darüber hinaus unterstützt BigQuery weder EXCHANGE PARTITION, SPLIT PARTITION noch die Konvertierung einer nicht partitionierten Tabelle in eine partitionierte Tabelle.
Clustering
Clustering hilft beim effizienten Organisieren und Abrufen von Daten, die in mehreren Spalten gespeichert sind, auf die häufig zusammen zugegriffen wird. Für Oracle und BigQuery sind es jedoch jeweils unterschiedliche Umstände, unter denen das Clustering am besten funktioniert. Wenn eine Tabelle in BigQuery häufig gefiltert und mit bestimmten Spalten aggregiert wird, verwenden Sie Clustering. Clustering kann für die Migration von über Listen partitionierten oder über Indexe organisierten Tabellen von Oracle in Betracht gezogen werden.
Temporäre Tabellen
Temporäre Tabellen werden häufig in Oracle-ETL-Pipelines verwendet. Eine temporäre Tabelle enthält Daten während einer Nutzersitzung. Diese Daten werden am Ende der Sitzung automatisch gelöscht.
BigQuery verwendet temporäre Tabellen, um Abfrageergebnisse im Cache zu speichern, die nicht in eine permanente Tabelle geschrieben wurden. Nachdem eine Abfrage abgeschlossen ist, sind die temporären Tabellen bis zu 24 Stunden vorhanden. Die Tabellen werden in einem speziellen Dataset erstellt und nach dem Zufallsprinzip benannt. Sie können auch temporäre Tabellen zur eigenen Verwendung erstellen. Weitere Informationen finden Sie unter Temporäre Tabellen.
Externe Tabellen
Ähnlich wie Oracle können Sie mit BigQuery externe Datenquellen abfragen. BigQuery unterstützt das direkte Abfragen von Daten aus den externen Datenquellen, einschließlich:
- Amazon Simple Storage Service (Amazon S3)
- Azure Blob Storage
- Bigtable
- Spanner
- Cloud SQL
- Cloud Storage
- Google Drive
Datenmodellierung
Stern- oder Schneeflocken-Datenmodelle können für die Analysespeicherung effizient sein und werden häufig für Data Warehouses in Oracle Exadata verwendet.
Denormalisierte Tabellen eliminieren teure Join-Vorgänge und bieten in den meisten Fällen eine bessere Leistung für Analysen in BigQuery. Stern- und Schneeflocken-Datenmodelle werden auch von BigQuery unterstützt. Weitere Details zum Data Warehouse-Design zu BigQuery finden Sie unter Schema entwerfen.
Zeilenformat versus Spaltenformat und Serverlimits versus Serverlos
Oracle verwendet ein Zeilenformat, in dem die Tabellenzeile in Datenblöcken gespeichert wird. So werden nicht benötigte Spalten innerhalb des Blocks für die analytischen Abfragen anhand der Filterung und Aggregation bestimmter Spalten abgerufen.
Oracle hat eine Shared-Everything-Architektur, bei der feste Hardware-Ressourcenabhängigkeiten, wie Arbeitsspeicher und Speicherplatz, dem Server zugewiesen sind. Dies sind die beiden Hauptfaktoren, die den meisten Datenmodellierungstechniken zugrunde liegen, mit denen sich die Effizienz der Speicherung und Leistung von Analyseabfragen verbessert hat. Stern- und Schneeflocken-Schemas sowie Data Vault-Modellierungen gehören dazu.
BigQuery verwendet zum Speichern von Daten ein Spaltenformat und hat keine festen Speicherplatz- und Arbeitsspeicherlimits. Mit dieser Architektur können Sie Schemas basierend auf Lesevorgängen und Geschäftsanforderungen weiter denormalisieren und entwerfen, wodurch die Komplexität verringert und die Flexibilität, Skalierbarkeit und Leistung verbessert wird.
Denormalisierung
Eines der Hauptziele der Normalisierung relationaler Datenbanken ist die Reduzierung der Datenredundanz. Dieses Modell eignet sich am besten für eine relationale Datenbank, die ein Zeilenformat verwendet. Für spaltenorientierte Datenbanken ist jedoch die Daten-Denormalisierung zu bevorzugen. Weitere Informationen zu den Vorteilen der Daten-Denormalisierung und anderen Strategien zur Abfrageoptimierung in BigQuery finden Sie unter Denormalisierung.
Techniken zum Vereinfachen Ihres vorhandenen Schemas
Die BigQuery-Technologie nutzt eine Kombination aus spaltenorientiertem Datenzugriff, spaltenorientierter Datenverarbeitung, In-Memory-Speicher und verteilter Verarbeitung, um eine hochwertige Abfrageleistung zu gewährleisten.
Beim Entwerfen eines BigQuery-DWH-Schemas ist die Erstellung einer Faktentabelle in einer flachen Tabellenstruktur (bei der alle Dimensionstabellen in einem einzigen Datensatz in der Faktentabelle konsolidiert werden) besser für die Speicherauslastung geeignet als die Verwendung mehrerer DWH-Dimensionstabellen. Neben einer geringeren Speicherauslastung führt eine flache Tabelle in BigQuery zu einer geringeren JOIN-Nutzung. Das folgende Diagramm zeigt ein Beispiel für die Vereinfachung Ihres Schemas.
Beispiel für die Vereinfachung eines Sternschemas
Abbildung 1 zeigt eine fiktive Vertriebsmanagement-Datenbank, die vier Tabellen enthält:
- Tabelle zu Bestellungen/Verkäufen (Faktentabelle)
- Mitarbeitertabelle
- Standorttabelle
- Kundentabelle
Der Primärschlüssel für die Verkaufstabelle ist OrderNum, das auch Fremdschlüssel für die anderen drei Tabellen enthält.
Abbildung 1: Beispiel für Verkaufsdaten in einem Sternschema
Beispieldaten
Inhalt der Bestellungs-/Faktentabelle
| OrderNum | CustomerID | SalesPersonID | Menge | Standort |
| 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 |
Inhalt der Mitarbeitertabelle
| SalesPersonID | FName | LName | Titel |
| 1 | Alex | Smith | Sales Associate |
| 4 | Lisa | Mustermann | Sales Associate |
| 12 | John | Mustermann | Sales Associate |
Inhalt der Kundentabelle
| CustomerID | FName | LName |
| 1234 | Amanda | Lee |
| 4567 | Matt | Ryan |
Inhalt der Standorttabelle
| Standort | Ort | Ort | Ort |
| 18 | Bronx | NY | 10452 |
| 26 | Mountain View | CA | 90210 |
| 27 | Chicago | IL | 60613 |
Abfrage zur Vereinfachung der Daten mit 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
Ausgabe der vereinfachten Daten
| OrderNum | CustomerID | FName | LName | SalesPersonID | FName | LName | Menge | Standort | Ort | state | Postleitzahl |
| O-1 | 1234 | Amanda | Lee | 12 | John | Doe | 234.22 | 18 | Bronx | NY | 10452 |
| O-2 | 4567 | Matt | Ryan | 1 | Alex | Sowa | 192.10 | 27 | Chicago | IL | 60613 |
| O-3 | 12 | John | Doe | 14.66 | 18 | Bronx | NY | 10452 | |||
| O-4 | 4567 | Matt | Ryan | 4 | Lisa | Doe | 182.00 | 26 | Berg
Ansehen |
CA | 90210 |
Verschachtelte und wiederkehrende Felder
In BigQuery werden die Funktionen für verschachtelte und wiederkehrende Felder vorgestellt, um ein DWH-Schema aus einem relationalen Schema zu entwerfen und zu erstellen (z. B. Stern- und Schneeflocken-Schemas mit Dimensions- und Faktentabellen). Daher können Beziehungen auf ähnliche Weise beibehalten werden wie bei einem relationalen (oder teilweise normalisiertes) DWH-Schema, ohne dass dies Auswirkungen auf die Leistung hat. Weitere Informationen finden Sie unter Best Practices für die Leistung.
Sehen Sie sich ein einfaches relationales Schema einer CUSTOMERS-Tabelle und einer ORDER/SALES-Tabelle an, um die Implementierung verschachtelter und wiederkehrender Felder besser zu verstehen. Es gibt zwei verschiedene Tabellen, eine für jede Entität, und die Beziehungen werden während der Abfrage mit JOINs mithilfe eines Schlüssels, etwa eines Primärschlüssels, und eines Fremdschlüssels als Verknüpfung zwischen den Tabellen definiert. Mit verschachtelten und wiederkehrenden BigQuery-Feldern können Sie die gleiche Beziehung zwischen den Entitäten in einer einzigen Tabelle beibehalten. Dies kann implementiert werden, indem alle Kundendaten verfügbar sind, während die Bestelldaten für jeden Kunden verschachtelt sind. Weitere Informationen finden Sie unter Verschachtelte und wiederkehrende Spalten angeben.
Um die flache Struktur in ein verschachteltes oder wiederkehrendes Schema zu konvertieren, verschachteln Sie die Felder so:
CustomerID,FName,LNameverschachtelt in einem neuen Feld namensCustomer.SalesPersonID,FName,LNameverschachtelt in einem neuen Feld namensSalesperson.LocationID,city,state,zip codeverschachtelt in einem neuen Feld namensLocation.
Die Felder OrderNum und amount sind nicht verschachtelt, da sie eindeutige Elemente darstellen.
Sorgen Sie dafür, dass Sie das Schema flexibel genug machen, damit jede Bestellung mehr als einen Kunden haben kann: einen primären und einen sekundären. Das Kundenfeld ist als wiederholt markiert. Das resultierende Schema ist in Abbildung 2 dargestellt, in der verschachtelte und wiederkehrende Felder veranschaulicht werden.
Abbildung 2: Logische Darstellung einer verschachtelten Struktur
In einigen Fällen führt die Denormalisierung mit verschachtelten und wiederkehrenden Feldern nicht zu Leistungsverbesserungen. Weitere Informationen zu Limitierungen und Einschränkungen von verschachtelten und wiederkehrenden Feldern finden Sie unter Denormalisierte, verschachtelte und wiederkehrende Daten laden.
Ersatzschlüssel
Es ist gängig, Zeilen mit eindeutigen Schlüsseln in den Tabellen zu identifizieren. Sequenzen werden häufig bei Oracle zum Erstellen dieser Schlüssel verwendet. In BigQuery können Sie mit den Funktionen row_number und partition by Ersatzschlüssel erstellen. Weitere Informationen finden Sie unter BigQuery- und Ersatzschlüssel: ein praktischer Ansatz.
Änderungen und Verlauf im Blick behalten
Berücksichtigen Sie bei der Planung einer BigQuery-DWH-Migration das Konzept der sich langsam ändernden Dimensionen (slowly changing dimensions, SCD). Im Allgemeinen beschreibt der Begriff SCD den Prozess, Änderungen (DML-Vorgänge) in den Dimensionstabellen vorzunehmen.
Aus unterschiedlichen Gründen verwenden herkömmliche Data Warehouses unterschiedliche Typen für den Umgang mit Datenänderungen und die Speicherung von Verlaufsdaten in sich langsam ändernden Dimensionen. Diese Typennutzungen werden von den zuvor beschriebenen Hardwarebeschränkungen und Effizienzanforderungen benötigt. Da der Speicher viel günstiger als Computing und unendlich skalierbar ist, wird die Datenredundanz und -duplizierung empfohlen, wenn dies zu schnelleren Abfragen in BigQuery führt. Sie können Daten-Snapshots-Techniken verwenden, bei denen die gesamten Daten in neue tägliche Partitionen geladen werden.
Rollen- und nutzerspezifische Ansichten
Verwenden Sie rollen- und nutzerspezifische Ansichten, wenn Nutzer verschiedenen Teams angehören und nur die Datensätze und Ergebnisse sehen sollten, die sie benötigen.
BigQuery unterstützt column- und Zeilenebene. Die Sicherheit auf Spaltenebene bietet mithilfe von Richtlinien-Tags oder typbasierter Klassifizierung von Daten einen detailgenauen Zugriff auf vertrauliche Spalten. Mit der Sicherheit auf Zeilenebene können Sie Daten filtern und den Zugriff auf bestimmte Zeilen in einer Tabelle anhand bestimmter Nutzerbedingungen ermöglichen.
Datenmigration
Dieser Abschnitt enthält Informationen zur Datenmigration von Oracle zu BigQuery, einschließlich anfänglichen Ladevorgängen, Change Data Capture (CDC) und ETL/ELT-Tools und -Ansätzen.
Migrationsaktivitäten
Es wird empfohlen, die Migration in Phasen durchzuführen, indem Sie geeignete Anwendungsfälle für die Migration ermitteln. Für die Migration von Daten von Oracle zu Google Cloud stehen mehrere Tools und Dienste zur Verfügung. Diese Liste ist nicht vollständig. Sie bietet aber einen Einblick in die Größe und den Umfang des Migrationsvorgangs.
Daten aus Oracle exportieren: Weitere Informationen finden Sie unter Anfänglicher Ladevorgang und CDC und Streamingaufnahme von Oracle zu BigQuery. ETL-Tools können für den anfänglichen Ladevorgang verwendet werden.
Data Staging (in Cloud Storage): Cloud Storage ist der empfohlene Landebereich (Staging-Bereich) für aus Oracle exportierte Daten. Cloud Storage wurde für die schnelle, flexible Aufnahme strukturierter oder unstrukturierter Daten entwickelt.
ETL-Prozess: Weitere Informationen finden Sie unter ETL-/ELT-Migration.
Daten direkt in BigQuery laden: Sie können Daten direkt aus Cloud Storage laden, durch Dataflow oder durch Echtzeitstreaming. Verwenden Sie Dataflow, wenn eine Datentransformation erforderlich ist.
Anfänglicher Ladevorgang
Die Migration der anfänglichen Daten vom vorhandenen Oracle-Data Warehouse zu BigQuery kann je nach Datengröße und Netzwerkbandbreite von den inkrementellen ETL-/ELT-Pipelines abweichen. Dieselben ETL-/ELT-Pipelines können verwendet werden, wenn die Datengröße einige Terabyte beträgt.
Wenn die Daten bis zu einigen Terabyte groß sind, kann das Auslesen der Daten und die Verwendung von gsutil für die Übertragung viel effizienter sein als die JdbcIO-ähnliche programmatische Methode der Extraktion von Datenbanken, da bei programmatischen Ansätzen möglicherweise eine viel detailliertere Leistungsoptimierung erforderlich ist. Wenn die Datengröße mehr als einige Terabyte beträgt und die Daten in Cloud- oder Onlinespeichern (z. B. Amazon Simple Storage Service (Amazon S3)) gespeichert sind, ziehen Sie in Betracht, den BigQuery Data Transfer Service zu verwenden Für umfangreiche Übertragungen (insbesondere Übertragungen mit begrenzter Netzwerkbandbreite) ist Transfer Appliance eine nützliche Option.
Einschränkungen beim anfänglichen Ladevorgang
Berücksichtigen Sie bei der Planung der Datenmigration Folgendes:
- Oracle-DWH-Datengröße: Die Quellgröße Ihres Schemas ist für die Auswahl der Datenübertragungsmethode von entscheidender Bedeutung, insbesondere wenn die Datengröße umfangreich ist (Terabyte und darüber). Wenn die Datengröße relativ klein ist, kann der Prozess der Datenübertragung in weniger Schritten abgeschlossen werden. Der Umgang mit umfangreichen Datengrößen führt zu einem komplexeren Gesamtprozess.
Ausfallzeit: Die Entscheidung, ob Ausfallzeiten für Ihre Migration zu BigQuery eine Option darstellen, ist wichtig. Zur Reduzierung der Ausfallzeiten können Sie die stabilen Verlaufsdaten im Bulk laden und eine CDC-Lösung einsetzen, um mit Änderungen gleichzuziehen, die während des Übertragungsprozesses eintreten.
Preise: In einigen Szenarien benötigen Sie möglicherweise Tools zur Integration von Drittanbietern (z. B. ETL- oder Replikationstools), die zusätzliche Lizenzen erfordern.
Anfängliche Datenübertragung (Batch)
Die Datenübertragung mithilfe einer Batchmethode gibt an, dass der Datenexport konsistent in einem einzigen Prozess passieren würden (z. B. das Exportieren der Oracle-DWH-Schemadaten in CSV-, Avro- oder Parquet-Dateien oder der Import in Cloud Storage, um Datasets in BigQuery zu erstellen). Alle unter ETL-/ELT-Migration erläuterten ETL-Tools und -Konzepte können für den anfänglichen Ladevorgang verwendet werden.
Wenn Sie kein ETL/ELT-Tool für den anfänglichen Ladevorgang verwenden möchten, können Sie benutzerdefinierte Skripts schreiben, um Daten in Dateien (CSV, Avro oder Parquet) zu exportieren und diese in Cloud Storage mithilfe von gsutil, BigQuery Data Transfer Service oder Transfer Appliance hochzuladen. Weitere Informationen zur Leistungsoptimierung für große Übertragungen und Übertragungsoptionen finden Sie unter Große Datasets übertragen. Laden Sie dann Daten aus Cloud Storage in BigQuery.
Cloud Storage eignet sich ideal, um die anfängliche Landung von Daten zu verarbeiten. Cloud Storage ist ein hochverfügbarer und langlebiger Objektspeicherdienst ohne Einschränkungen für die Anzahl von Dateien. Außerdem bezahlen Sie nur für den Speicher, den Sie verwenden. Der Dienst ist für die Arbeit mit anderen Google Cloud-Diensten wie BigQuery und Dataflow optimiert.
CDC und Streamingaufnahme von Oracle zu BigQuery
Es gibt mehrere Möglichkeiten, die geänderten Daten aus Oracle zu erfassen. Jede Option hat Vor- und Nachteile, vor allem hinsichtlich der Auswirkungen auf die Leistung des Quellsystems, Entwicklungs- und Konfigurationsanforderungen sowie der Preise und Lizenzierung.
Logbasiertes CDC
Oracle GoldenGate ist das empfohlene Tool von Oracle zum Extrahieren von Redo-Logs. Sie können GoldenGate for Big Data zum Streamen von Logs in BigQuery verwenden. GoldenGate erfordert eine CPU-Lizenzierung. Informationen zum Preis finden Sie in der globalen Preisliste zu Oracle-Technologie. Wenn Oracle GoldenGate for Big Data verfügbar ist (wenn Lizenzen bereits erworben wurden), kann die Verwendung von GoldenGate eine gute Wahl sein, um Datenpipelines zur Übertragung von Daten (anfänglicher Ladevorgang) zu erstellen und dann alle Datenänderungen zu synchronisieren.
Oracle XStream
Oracle speichert jeden Commit in Redo-Logdateien. Diese Redo-Dateien können für CDC verwendet werden. Oracle XStream Out basiert auf LogMiner und wird von Drittanbietertools wie Debezium (ab Version 0.8) oder kommerziell bei der Verwendung von Tools wie Alooma oder Striim bereitgestellt. Für die Verwendung von XStream APIs ist der Kauf einer Lizenz für Oracle GoldenGate erforderlich, auch wenn GoldenGate nicht installiert ist und verwendet wird. Mit XStream können Sie Streams-Nachrichten effizient zwischen Oracle und anderer Software weitergeben.
Oracle LogMiner
Für LogMiner ist keine spezielle Lizenz erforderlich. Sie können die LogMiner-Option im Community-Connector von Debezium verwenden. Sie ist auch kommerziell über die Verwendung von Tools wie Attunity, Striim oder StreamSets verfügbar. LogMiner kann sich auf die Leistung einer sehr aktiven Quelldatenbank auswirken und sollte mit Bedacht verwendet werden, wenn das Volumen der Änderungen (die Redo-Größe) mehr als 10 GB pro Stunde beträgt, je nach CPU, Arbeitsspeicher und E/A-Kapazität und -Auslastung des Servers.
SQL-basiertes CDC
Dies ist der inkrementelle ETL-Ansatz, bei dem SQL-Abfragen die Quelltabellen kontinuierlich nach Änderungen abfragen, die von einem kontinuierlich steigenden Schlüssel und einer Zeitstempelspalte abhängig sind, die das Datum der letzten Änderung oder Einfügung enthält. Wenn kein kontinuierlich ansteigender Schlüssel vorhanden ist, kann die Verwendung der Zeitstempelspalte (geändertes Datum) mit einer geringen Genauigkeit (Sekunden) zu doppelten Datensätzen oder fehlenden Daten führen, je nach Volumen und Vergleichsoperator, wie z. B. > oder >=.
Zur Lösung solcher Probleme können Sie eine höhere Genauigkeit in Zeitstempelspalten verwenden, z. B. sechs Nachkommastellen (Mikrosekunden – die maximal unterstützte Genauigkeit in BigQuery), oder Sie können Deduplizierungsaufgaben in Ihren ETL-/ELT-Code aufnehmen, je nach Geschäftsschlüssel und Dateneigenschaften.
Die Schlüssel- oder Zeitstempelspalte sollte einen Index enthalten, um die Extrahierleistung zu verbessern und die Auswirkungen auf die Quelldatenbank zu reduzieren. Löschvorgänge stellen eine Herausforderung für diese Methode dar, da sie in der Quellanwendung im Sinne eines vorläufigen Löschens verarbeitet werden sollten, z. B. durch Einsatz eines gelöschten Flags und Aktualisieren des last_modified_date. Eine alternative Lösung kann das Logging dieser Vorgänge mithilfe eines Triggers in einer anderen Tabelle sein.
Trigger
Datenbanktrigger können für Quelltabellen erstellt werden, um Änderungen in Schatten-Journaltabellen zu protokollieren. Journaltabellen können ganze Zeilen enthalten, um alle Spaltenänderungen zu verfolgen, oder sie können nur den Primärschlüssel mit dem Vorgangstyp (Einfügen, Aktualisieren oder Löschen) behalten. Anschließend können geänderte Daten mit einem SQL-basierten Ansatz erfasst werden, der unter SQL-basiertes CDC beschrieben wird. Die Verwendung von Triggern kann sich auf die Transaktionsleistung auswirken und die Latenz eines einzeiligen DML-Vorgangs verdoppeln, wenn eine vollständige Zeile gespeichert wird. Wenn nur der Primärschlüssel gespeichert wird, kann dieser Mehraufwand reduziert werden. In diesem Fall ist jedoch in der SQL-basierten Extraktion ein JOIN-Vorgang mit der ursprünglichen Tabelle erforderlich, bei dem die Zwischenänderung nicht erfasst wird.
ETL-/ELT-Migration
Es gibt viele Möglichkeiten, ETL/ELT in Google Cloud zu verarbeiten. Technische Anleitungen zu bestimmten ETL-Arbeitslast-Konvertierungen werden in diesem Dokument nicht behandelt. Sie können einen Lift-and-Shift-Ansatz in Betracht ziehen oder Ihre Datenintegrationsplattform umgestalten, abhängig von Einschränkungen wie Kosten und Zeit. Weitere Informationen zum Migrieren Ihrer Datenpipelines zu Google Cloud und zu vielen anderen Migrationskonzepten finden Sie unter Datenpipelines migrieren.
Lift-and-Shift-Ansatz
Wenn Ihre vorhandene Plattform BigQuery unterstützt und Sie weiterhin Ihr vorhandenes Datenintegrationstool verwenden möchten:
- Sie können die ETL-/ELT-Plattform unverändert lassen und die erforderlichen Speicherphasen mit BigQuery in Ihren ETL-/ELT-Jobs ändern.
- Wenn Sie auch die ETL-/ELT-Plattform zu Google Cloud migrieren möchten, können Sie Ihren Anbieter fragen, ob sein Tool in Google Cloud lizenziert ist. Wenn dies der Fall ist, können Sie es in Compute Engine installieren oder den Google Cloud Marketplace prüfen.
Informationen zu den Anbietern von Datenintegrationslösungen finden Sie unter BigQuery-Partner.
ETL-/ELT-Plattform umgestalten
Wenn Sie Ihre Datenpipelines umgestalten möchten, empfehlen wir Ihnen dringend, Google Cloud-Dienste zu verwenden.
Cloud Data Fusion
Cloud Data Fusion ist ein verwaltetes CDAP in Google Cloud, das eine visuelle Benutzeroberfläche mit vielen Plug-ins für Aufgaben wie Drag-and-drop und Pipelineentwicklungen bietet. Cloud Data Fusion kann zum Erfassen von Daten aus vielen verschiedenen Arten von Quellsystemen verwendet werden und bietet Batch- und Streaming-Replikationsfunktionen. Mit Cloud Data Fusion- oder Oracle-Plug-ins können Daten aus einem Oracle erfasst werden. Mit einem BigQuery-Plug-in können die Daten in BigQuery geladen und Schemaaktualisierungen verarbeitet werden.
Sowohl für Quell- als auch für Senken-Plug-ins ist kein Ausgabeschema definiert. Außerdem wird im Quell-Plug-in auch select * from verwendet, um neue Spalten zu replizieren.
Sie können das Cloud Data Fusion Wrangle-Feature für die Datenbereinigung und -vorbereitung verwenden.
Dataflow
Dataflow ist eine serverlose Datenverarbeitungsplattform, die Autoscaling sowie Batch- und Streaming-Datenverarbeitung ausführen kann. Dataflow kann eine gute Wahl für Python- und Java-Entwickler sein, die ihre Datenpipelines codieren und denselben Code für Streaming- und Batch-Arbeitslasten verwenden möchten. Verwenden Sie die Vorlage "JDBC zu BigQuery", um Daten aus Ihren Oracle- oder anderen relationalen Datenbanken zu extrahieren und in BigQuery zu laden.
Cloud Composer
Cloud Composer ist ein vollständig verwalteter auf Apache Airflow basierender Dienst für die Workflow-Orchestrierung von Google Cloud. Sie können damit Pipelines erstellen, planen und überwachen, die sich über Cloudumgebungen und lokale Rechenzentren erstrecken. Cloud Composer bietet Operatoren und Beiträge, mit denen Multi-Cloud-Technologien für solche Anwendungsfälle ausgeführt werden können wie Extrahieren und Laden, Transformationen von ELT und REST API-Aufrufe.
Cloud Composer verwendet gerichtete azyklische Graphen (Directed Acyclic Graphs, DAGs) für die Planung und Orchestrierung von Workflows. Informationen zu den allgemeinen Airflow-Konzepten finden Sie unter Apache-Konzepte von Airflow. Weitere Informationen zu DAGs finden Sie unter DAGs (Workflows) schreiben. Beispiele für ETL-Best-Practices mit Apache Airflow finden Sie unter Dokumentationswebsite für ETL-Best-Practices mit Airflow. Sie können den Hive-Operator in diesem Beispiel durch den BigQuery-Operator ersetzen und es wären die gleichen Konzepte anwendbar.
Der folgende Beispielcode ist ein grober Teil eines Beispiel-DAG für das obige Diagramm:
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)
Der vorherige Code dient zu Demonstrationszwecken und kann nicht unverändert verwendet werden.
Dataprep by Trifacta
Dataprep ist ein Datendienst zur visuellen Erkundung, Bereinigung und Vorbereitung von strukturierten und unstrukturierten Daten für Analysen, Berichte und maschinelles Lernen. Sie exportieren die Quelldaten in JSON- oder CSV-Dateien, transformieren die Daten mit Dataprep und laden sie mit Dataflow. Ein Beispiel finden Sie unter Oracle-Daten (ETL) für BigQuery mit Dataflow und Dataprep.
Dataproc
Dataproc ist ein von Google verwalteter Hadoop-Dienst. Sie können Sqoop verwenden, um Daten aus Oracle und vielen relationalen Datenbanken als Avro-Dateien in Cloud Storage zu exportieren, und dann können Sie Avro-Dateien mit bq tool in BigQuery laden. Es ist sehr verbreitet, ETL-Tools wie CDAP on Hadoop zu installieren, die JDBC zum Extrahieren von Daten und Apache Spark oder MapReduce für die Transformationen der Daten verwenden.
Partnertools für die Datenmigration
Im ETL-Bereich (Extraktion, Transformation und Laden) gibt es mehrere Anbieter. ETL-Marktführer wie Informatica, Talend, Matillion, Alooma, Infoworks, Stitch, Fivetran und Striim sind tief in BigQuery und Oracle eingebunden und können dabei helfen, Daten zu extrahieren, zu transformieren und zu laden sowie Verarbeitungsworkflows zu verwalten.
ETL-Tools gibt es schon seit vielen Jahren. Für einige Organisationen ist es möglicherweise praktisch, eine vorhandene Investition in vertrauenswürdige ETL-Skripts zu nutzen. Einige unserer wichtigsten Partnerlösungen finden Sie auf der BigQuery-Partnerwebsite. Die Entscheidung, wann Partnertools gegenüber den Dienstprogrammen von Google Cloud vorgezogen werden, hängt von Ihrer aktuellen Infrastruktur und den Kenntnissen Ihres IT-Teams bei der Entwicklung von Datenpipelines in Java- oder Python-Code ab.
Migration des Business Intelligence-Tools (BI)
BigQuery unterstützt eine flexible Suite von Business Intelligence-Lösungen (BI) für die Berichterstellung und Analyse, die Sie nutzen können. Weitere Informationen zur Migration des BI-Tools und zur BigQuery-Einbindung finden Sie unter Übersicht über BigQuery-Analysen.
Abfrageübersetzung (SQL)
GoogleSQL von BigQuery ist mit dem SQL 2011-Standard kompatibel und bietet Erweiterungen, die die Abfrage verschachtelter und wiederholter Daten unterstützen. Alle ANSI-konformen SQL-Funktionen und -Operatoren können mit minimalen Änderungen verwendet werden. Einen detaillierten Vergleich zwischen der Syntax und den Funktionen von Oracle und BigQuery SQL finden Sie in der Referenz zur Übersetzung von Oracle zu BigQuery SQL.
Verwenden Sie die Batch-SQL-Übersetzung, um Ihren SQL-Code im Bulk zu migrieren, oder die interaktive SQL-Übersetzung, um Ad-hoc-Abfragen zu übersetzen.
Oracle-Optionen migrieren
In diesem Abschnitt werden Architekturempfehlungen und Referenzen zu Konvertierungen von Anwendungen vorgestellt, die Oracle Data Mining-, R- sowie Spatial and Graph-Funktionen verwenden.
Oracle Advanced Analytics-Option
Oracle bietet erweiterte Analyseoptionen für Data Mining, grundlegende Algorithmen für maschinelles Lernen und R-Nutzung. Für die Advanced Analytics-Option ist eine Lizenzierung erforderlich. Sie können aus einer umfassenden Liste von Google AI-/ML-Produkten wählen, abhängig von Ihren Anforderungen von der Entwicklung bis zur Produktion in großem Umfang.
Oracle R Enterprise
Oracle R Enterprise (ORE), eine Komponente der Oracle Advanced Analytics-Option, ermöglicht die Einbindung der statistischen Open-Source-Programmiersprache R in die Oracle-Datenbank. In Standard-ORE-Bereitstellungen ist R auf einem Oracle-Server installiert.
Für sehr große Datenmengen oder Ansätze für den Warehousing ist die Integration von R in BigQuery die ideale Wahl. Mit der Open-Source-R-Bibliothek bigrquery können Sie R in BigQuery einbinden.
Google arbeitet mit RStudio zusammen, um die hochmodernen Tools des Gebiets für Nutzer verfügbar zu machen. RStudio kann für den Zugriff auf Terabyte an Daten in BigQuery-geeigneten Modellen in TensorFlow verwendet werden und mit AI Platform Modelle für maschinelles Lernen in großem Maßstab ausführen. In Google Cloud kann R umfassend in Compute Engine installiert werden.
Oracle Data Mining
Mit Oracle Data Mining (ODM), einer Komponente der Oracle Advanced Analytics-Option, können Entwickler ML-Modelle mit Oracle PL/SQL Developer auf Oracle erstellen.
Mit BigQuery ML können Entwickler viele verschiedene Arten von Modellen ausführen, z. B. lineare Regression, binäre logistische Regression, mehrklassige logistische Regression, k-Means-Clustering und TensorFlow-Modellimporte. Weitere Informationen finden Sie unter Einführung in BigQuery ML.
Für die Konvertierung von ODM-Jobs muss der Code möglicherweise neu geschrieben werden. Sie können zwischen umfassenden Google KI-Produkten wie BigQuery ML, AI APIs (Speech-to-Text,Text-to-Speech, Dialogflow, Cloud Translation, Cloud Natural Language API, Cloud Vision, Timeseries Insights API und mehr) und Vertex AI wählen.
Vertex AI Workbench kann als Entwicklungsumgebung für Data Scientists verwendet werden und Vertex AI Training kann zum Ausführen von Trainings- und Bewertungsarbeitslasten in großem Maßstab verwendet werden.
Spatial and Graph-Option
Oracle bietet die Spatial and Graph-Option zum Abfragen von Geometrien und Grafiken und erfordert eine Lizenzierung für diese Option. Sie können die Geometriefunktionen in BigQuery ohne zusätzliche Kosten oder Lizenzen nutzen und andere Grafikdatenbanken in Google Cloud nutzen.
Räumlich
BigQuery bietet raumbezogene Analysefunktionen und Datentypen. Weitere Informationen finden Sie unter Mit raumbezogenen Analysedaten arbeiten. Oracle Spatial-Datentypen und -Funktionen können in geografische Funktionen in BigQuery-Standard-SQL konvertiert werden. Durch geografische Funktionen werden keine Kosten zusätzlich zu den BigQuery-Standardpreisen verursacht.
Grafik
JanusGraph ist eine Open-Source-Graphdatenbank-Lösung, die Bigtable als Speicher-Backend verwenden kann. Weitere Informationen finden Sie unter JanusGraph auf GKE mit Bigtable ausführen.
Neo4j ist eine weitere Graphdatenbank-Lösung, die als Google Cloud-Dienst in Google Kubernetes Engine (GKE) bereitgestellt wird.
Oracle Application Express
Oracle Application Express-Anwendungen (APEX) sind eigene Anwendungen von Oracle und müssen neu geschrieben werden. Funktionen zur Berichterstellung und Datenvisualisierung können mit Looker Studio oder BI-Engine entwickelt werden. Funktionen auf Anwendungsebene wie das Erstellen und Bearbeiten von Zeilen können hingegen ohne Codierung in AppSheet unter Verwendung von Cloud SQL entwickelt werden.
Nächste Schritte
- Erfahren Sie, wie Sie Arbeitslasten optimieren, um die Gesamtleistung zu optimieren und Kosten zu reduzieren.
- Erfahren Sie, wie Sie Speicher in BigQuery optimieren.
- Informationen zu BigQuery-Updates finden Sie in den Versionshinweisen.
- Lesen Sie den Oracle SQL-Übersetzungsleitfaden.