In diesem Dokument werden die Prinzipien und Techniken zur Implementierung eines wiederholbaren Workflows beschrieben, mit denen Sie Datenänderungen in Ihr BigQuery-basiertes Data Warehouse (DWH) einbinden können. Zu diesen Änderungen gehören möglicherweise neue Datasets, neue Datenquellen oder Aktualisierungen und Änderungen an vorhandenen Datasets. Das Dokument beschreibt auch eine Referenzarchitektur für diese Aufgabe.
Die Zielgruppe dieses Dokuments ist Software- und Datenarchitekten sowie Data Engineers, die BigQuery als DWH verwenden. In diesem Dokument wird davon ausgegangen, dass Sie mit grundlegenden Konzepten der CI/CD oder ähnlichen Verwaltungsvorgängen für den Anwendungslebenszyklus vertraut sind.
Einführung
Continuous Integration und Continuous Delivery (CI/CD) sind zu einer wesentlichen Technik im Lebenszyklus der Softwareentwicklung geworden. Wenn Sie die Prinzipien von CI/CD anwenden, können Teams bessere Software mit weniger Problemen bereitstellen als durch das Einbinden von Features und das manuelle Bereitstellen. CI/CD kann auch Teil einer Strategie für die Datenverwaltung sein, wenn Sie Ihren Data-Warehouse-Prozess modernisieren.
Wenn Sie jedoch mit einem DWH wie BigQuery arbeiten, gibt es Unterschiede bei der Implementierung von CI/CD im Vergleich zur Implementierung von CI/CD im Quellcode. Das liegt zum Teil daran, dass Data Warehouses ein inhärentes zustandsorientiertes System zum Verwalten der zugrunde liegenden Daten sind.
Dieses Dokument enthält die folgenden Informationen:
- Verfahren zur Implementierung einer Continuous Integration-Strategie (CI-Strategie) in BigQuery.
- Hinweise und Methoden, mit denen Sie Stolperfallen vermeiden können.
- Vorschläge für BigQuery-Features, die CI in BigQuery unterstützen
In diesem Dokument geht es um CI, da bei der Integration ein Data-Warehouse-Team spezifischere Daten berücksichtigt als die Continuous Delivery (CD).
Wann sollte CI für ein BigQuery-DWH verwendet werden?
In diesem Dokument ist die Datenintegration eine Aufgabe, die normalerweise vom DWH-Team ausgeführt wird. Dazu gehört das Einbinden neuer Daten in das DWH. Diese Aufgabe kann das Einbinden einer neuen Datenquelle in das DWH oder das Ändern der Struktur einer Tabelle umfassen, die sich bereits im DWH befindet.
Das Einbinden neuer Daten in das DWH ist eine Aufgabe, die ähnlich aussieht wie die Einbindung eines neuen Features in eine vorhandene Software. Er kann Programmfehler verursachen und sich negativ auf die Endnutzerumgebung auswirken. Wenn Sie Daten in BigQuery einbinden, können nachgelagerte Nutzer der Daten (z. B. Anwendungen, BI-Dashboards und einzelne Nutzer) Probleme aufgrund von Schemaabweichungen haben. Oder die Nutzer verwenden möglicherweise falsche Daten, die nicht die Daten aus der ursprünglichen Datenquelle widerspiegeln.
CI für DWH ist in folgenden Fällen nützlich:
- Wichtige Punkte in CI für ein DWH-System beschreiben
- CI-Strategie für Ihre BigQuery-Umgebung entwerfen und implementieren
- Erfahren Sie, wie Sie BigQuery-Features zur Implementierung von CI verwenden
In diesem Leitfaden wird nicht beschrieben, wie Sie CI für DWH-Produkte verwalten, einschließlich Datenprodukte wie Dataflow und Bigtable.
Beispielszenario
Beispielunternehmen ist ein großes Einzelhandelsunternehmen, das sein DWH in BigQuery verwaltet. Im nächsten Jahr möchte das Unternehmen neue Datenquellen in sein DWH von Unternehmen einbinden, die kürzlich von Example Company erworben wurden. Die neuen zu integrierenden Datenquellen haben unterschiedliche Schemas. Das DWH muss jedoch das vorhandene Schema beibehalten und eine hohe Datenkonsistenz und Vollständigkeit der Daten bereitstellen, damit die nachgelagerten Datennutzer nicht negativ betroffen sind.
Derzeit führt das DWH-Team von Example Company Datenintegrationen durch. Für die Einbindung müssen die vorhandenen Datenquellen in einem vordefinierten Schema vorhanden sein. Dieser Workflow umfasst Legacy-Datenimportprozesse, erworbene Datenbanken und Anwendungsdienste.
Damit die Datenintegrationsprozesse für die neuen Datenquellen aktualisiert werden können, muss das DWH-Team seinen Ansatz der Datenintegration neu gestalten, um die zuvor genannten Anforderungen zu erfüllen, z. B. strikte Datenkonsistenz. Das Team muss die Änderungen isoliert implementieren, damit die Datenänderungen getestet und gemessen werden können, bevor die Daten für nachgelagerte Nutzer verfügbar sind.
Nachdem das DWH-Team den neuen Workflow übernommen hat, hat das Team einen wiederholbaren Prozess. Jeder Entwickler kann eine isolierte Entwicklungsumgebung erstellen, die auf Produktionsdaten basiert. Mit diesen isolierten Umgebungen können Entwickler Änderungen vornehmen, testen, prüfen und die erforderlichen Änderungen an die Produktionsumgebung vornehmen. Wenn die Änderungen zu Fehlern oder unvorhergesehenen Problemen führen, können die Änderungen einfach rückgängig gemacht werden.
Was bedeutet Continuous Integration für ein DWH?
Continuous Integration (CI) besteht aus einer Reihe von Verfahren, mit denen Entwicklungsteams Entwicklungszyklen verkürzen und Probleme im Code schneller finden können als mit manuellen Systemen. Der Hauptvorteil der Einführung eines CI-Ansatzes ist die Möglichkeit, schnell zu entwickeln, wodurch das Risiko von Störungen zwischen Entwicklern reduziert wird. Dieses Ziel wird erreicht, indem sichergestellt wird, dass der Prozess wiederholbar ist, während jeder Entwickler isoliert von anderen Entwicklern arbeiten kann.
Diese Prinzipien gelten auch, wenn eine Organisation Daten mit einigen Unterschieden in ein DWH integrieren muss. Im Rahmen der typischen Softwareentwicklung isoliert CI Änderungen am Quellcode, die zustandslos sind. Im Kontext von CI in Daten integriert CI Daten in ein DWH-System. Daten sind jedoch definitionsgemäß zustandsorientiert. Dieser Unterschied hat Auswirkungen darauf, wie CI auf DWH-Szenarien angewendet wird, wie in diesem Dokument beschrieben.
Zusätzliche Szenarien, die in diesem Dokument nicht behandelt werden
Obwohl sich dieses Dokument auf die Isolierung von Entwicklungsänderungen aus der Produktionsumgebung konzentriert, werden die folgenden Aspekte der Datenintegration nicht behandelt:
- Datentests: Können Sie prüfen, ob die Daten Ihren Geschäftsanforderungen entsprechen? Sind die Daten zuverlässig als "Source of Truth"? Um das Konfidenzniveau der Daten, die Sie von Ihrem DWH bereitstellen, zu erhöhen, ist es wichtig, die Daten zu testen. Zum Testen können Sie eine Reihe von Abfragen ausführen und bestätigen, dass die Daten keine Werte fehlen oder bestätigen, dass sie "schlechte" Werte enthalten.
- Datenherkunft: Können Sie eine Tabelle in ihrem Kontext sehen? Können Sie beispielsweise sehen, woher die Daten erfasst wurden und welche Datasets zur Berechnung der Tabelle vorausberechnet wurden? In modernen DWH-Architekturen werden Daten in viele Systeme unterteilt, die unterschiedliche spezialisierte Datenstrukturen verwenden. Dazu gehören relationale Datenbanken, NoSQL-Datenbanken und externe Datenquellen. Damit Sie die vorhandenen Daten vollständig verstehen, müssen Sie diese verfolgen. Sie müssen außerdem wissen, wie die Daten generiert wurden und von wo sie generiert wurden.
Diese Themen werden in diesem Leitfaden nicht behandelt. Wenn Sie einen Workflow für Ihr Team entwerfen, wird es jedoch Ihre Datenstrategie nutzen, um diese Themen zu planen.
Typische Einrichtung von BigQuery als DWH
Das folgende Diagramm veranschaulicht ein typisches DWH-Design für BigQuery. Es zeigt, wie Daten aus externen Quellen in das DWH aufgenommen werden und wie Nutzer Daten vom DWH verbrauchen.
Die Daten beginnen bei den Datenquellen, wobei es sich um herkömmliche transaktionale oder Datenbanken mit niedriger Latenz handelt, wie OLTP-SQL-Datenbanken und NoSQL-Datenbanken. Bei einem geplanten Prozess werden die Daten in einen Staging-Bereich kopiert.
Die Daten werden vorübergehend im Staging-Bereich gespeichert. Bei Bedarf werden die Daten so transformiert, dass sie in ein Analysesystem passen, bevor sie in die DWH-Tabellen geladen werden. (In diesem Diagramm befindet sich der Staging-Bereich in Google Cloud, aber nicht.) Zu den Transformationen können Denormalisierung, Anreicherung bestimmter Datasets oder die Verarbeitung fehlerhafter Einträge gehören (z. B. Einträge mit fehlenden Werten).
Aus dem Staging-Bereich werden die neuen Daten in die DWH-Tabellen geladen. Die Tabellen sind je nach Design des DWHs möglicherweise unterschiedlich organisiert und werden normalerweise als Kerntabellen bezeichnet. Beispiele für Tabellendesignparadigmen sind das Sternschema, das denormalisierte Modell: Mehrstufige Aggregate.
Unabhängig vom Tabellendesign speichern diese Tabellen Daten im Laufe der Zeit. Die Tabellen müssen dem Schema entsprechen und es wird davon ausgegangen, dass sie für alle analytischen Zwecke die "Source of Truth" enthalten. Diese Rolle für die Tabellen bedeutet, dass die Daten in diesen Tabellen vollständig, konsistent und den vordefinierten Schemas entsprechen müssen.
Diese Tabellen stellen Daten nicht direkt für Nutzer bereit. Stattdessen werden die Daten über eine Zugriffsebene bereitgestellt, die zum Datenkapseln der Geschäftslogik konzipiert ist, die auf die zugrunde liegenden Daten angewendet werden muss. Beispiele für diese Art von Geschäftslogik sind die Berechnung eines Messwerts für jeden Datensatz oder die Filterung und Gruppierung der Daten.
Die Nutzer der Daten können eine Verbindung zu der DWH-Zugriffsebene herstellen und Daten daraus lesen. Dazu gehören unter anderem folgende Systeme:
- BI-Dashboards (Business Intelligence)
- Data-Science-Notebooks
- Betriebssysteme, die auf den im DWH berechneten Daten basieren
- Nutzer für Ad-hoc-Abfragen
Die Datennutzer verlassen sich stark auf das DWH, um konsistente Schemas bereitzustellen, und auf die Geschäftslogik, die das DWH kapselt. Diese Schemas und Geschäftslogik können als Service Level Agreements (SLAs) der DWH-Plattform betrachtet werden. Jede Änderung an der Geschäftslogik, am Schema oder an der Vollständigkeit von Daten kann nachgelagerte große Auswirkungen haben. Da sich moderne Datenplattformen ständig ändern, ist es möglicherweise erforderlich, dass das DWH-Team diese Änderungen vornimmt und gleichzeitig die SLAs einhält. Damit das Team diese SLAs erfüllen und das DWH auf dem neuesten Stand halten kann, benötigt es einen Workflow, der eine Datenintegration ermöglicht und gleichzeitig die Auswirkungen dieser Änderungen minimiert.
Assets für die kontinuierliche Einbindung in ein DWH
Wie bei jedem anderen Entwicklungs- oder IT-Team muss das DWH-Team Assets pflegen, die für ihre Aufgaben wichtig sind. Diese Assets können in die folgenden Kategorien unterteilt werden:
Die Codebasis für Datenpipelines: Diese Assets bestehen in der Regel aus Quellcode in einer allgemeinen Programmiersprache wie Python oder Java. Für diese Arten von Assets werden die CI-/CD-Prozesse mit Tools wie Git und Jenkins oder mit Google Cloud-Lösungen wie Cloud Source Repositories und Cloud Build erstellt.
SQL-Skripts: Diese Assets beschreiben die Struktur und die Geschäftslogik, die in dem DWH enthalten ist. Innerhalb dieser Kategorie können die Assets in die folgenden Unterkategorien unterteilt werden:
- Datendefinitionssprache (DDL): Diese Assets werden zum Definieren des Tabellen- und Ansichtsschemas verwendet.
- Datenbearbeitungssprache (DML): Diese Assets werden zum Bearbeiten von Daten in einer Tabelle verwendet. Außerdem werden DML-Befehle verwendet, um neue Tabellen auf der Grundlage vorhandener Tabellen zu erstellen.
- Datensteuerungssprache (DCL): Diese Assets werden zur Steuerung von Berechtigungen und für den Zugriff auf Tabellen verwendet. In BigQuery können Sie den Zugriff mithilfe von SQL und dem
bq-Befehlszeilentool oder mithilfe der BigQuery REST API steuern. Wir empfehlen jedoch, IAM zu verwenden.
Diese Assets und andere wie Terraform-Skripts, die zum Erstellen von Komponenten verwendet werden, werden in Code-Repositories verwaltet. Tools wie Dataform können Ihnen beim Erstellen einer CI/CD-Pipeline helfen, die Ihre SQL-Skripts und vordefinierte Validierungsregeln für Tabellen validiert, die von DDL-Skripts erstellt werden. Mit diesen Tools können Sie Kompilierungs- und Testprozesse für SQL anwenden, in denen in den meisten Kontexten keine natürliche Testumgebung vorhanden ist.
Zusätzlich zu den Assets, die mit Tools und Prozessen verknüpft sind, sind die Daten für das DWH-Team das Hauptasset. Daten können mit Asset-Tracking-Systemen wie Git, das entwickelt wurde, um Quellcode zu verfolgen, nicht verfolgt werden. In diesem Dokument werden die Probleme behandelt, die mit Tracking-Daten verbunden sind.
Probleme bei der Datenintegration
Aufgrund der potenziellen Komplexität von Tabellenbeziehungen in einem DWH (z. B. in einem der zuvor erwähnten Modellparadigmen) ist die Beibehaltung des Status der Produktionsdaten aus einer Testumgebung eine Herausforderung. Standardverfahren bei der Softwareentwicklung können nicht auf das Szenario der Datenintegration angewendet werden.
In der folgenden Tabelle sind die Unterschiede zwischen den Verfahren zum Einbinden von Code und dem Einbinden von Daten zusammengefasst.
| Code einbinden | Einbindung von Daten | |
|---|---|---|
| Lokale Entwicklung | Quellcode kann aufgrund der relativ kleinen Größe leicht geklont werden. Im Allgemeinen eignet sich der Code für die meisten Endnutzercomputer (mit Ausnahme von Monorepos, die andere Lösungen haben). | Die meisten Tabellen in einem DWH können aufgrund ihrer Größe nicht auf eine Entwicklungsmaschine passen. |
| Zentrale Tests | Verschiedene Status des Quellcodes werden in ein zentrales System (einen CI-Server) geklont, um automatisierte Tests durchzuführen. Wenn Sie unterschiedliche Codestatus haben, können Sie die Ergebnisse zwischen einer stabilen Version und einer Entwicklungsversion vergleichen. | Das Erstellen verschiedener Datenstatus in einer isolierten Umgebung ist nicht einfach. Das Verschieben von Daten außerhalb des DWH ist ein ressourcenintensiver und zeitaufwendiger Vorgang. Es ist nicht praktikabel, dies so oft wie nötig zum Testen zu tun. |
| Ältere Versionen | Während Sie neue Softwareversionen veröffentlichen, können Sie ältere Versionen verfolgen. Wenn Sie ein Problem in einer neuen Version erkennen, können Sie ein Rollback zu einer sicheren Version durchführen. | Das Erstellen von Sicherungen mithilfe von Tabellen innerhalb des DWHs ist eine Standardpraktik für den Fall, dass Sie ein Rollback durchführen müssen. Sie müssen jedoch darauf achten, dass alle betroffenen Tabellen auf denselben Zeitpunkt zurückgesetzt werden. Auf diese Weise sind verwandte Tabellen miteinander konsistent. |
Daten in BigQuery-Tabellen einbinden
BigQuery bietet zwei Funktionen, die Sie bei der Entwicklung eines Workflows für die Datenintegration unterstützen: Tabellen-Snapshots und Tabellenklone. Sie können diese Funktionen kombinieren, um einen Workflow zu erreichen, der Ihnen eine kostengünstige Entwicklungsumgebung bietet. Entwickler können die Daten und ihre Struktur isoliert von der Produktionsumgebung bearbeiten und bei Bedarf eine Änderung rückgängig machen.
Ein BigQuery-Tabellen-Snapshot ist eine schreibgeschützte Darstellung einer Tabelle (auch als Basistabelle bezeichnet) zu einem bestimmten Zeitpunkt. Ebenso ist ein BigQuery-Tabellenklon eine Lese-/Schreibdarstellung einer Tabelle zu einem bestimmten Zeitpunkt. In beiden Fällen werden die Speicherkosten minimiert, da nur die Unterschiede zur Basistabelle gespeichert werden. Für Tabellenklone fallen Kosten an, wenn sich die Basistabelle ändert oder wenn sich die Tabellenklone ändern. Da Tabellen-Snapshots schreibgeschützt sind, fallen nur dann Kosten an, wenn sich die Basistabelle ändert.
Weitere Informationen zu den Preisen von Tabellen-Snapshots und Tabellenklonen finden Sie unter Einführung in Tabellen-Snapshots und Einführung in Tabellenklone.
Sie können Tabellen-Snapshots und Tabellenklone mit der BigQuery-Funktion Zeitreisen erstellen (bis zu sieben Tage in der Vergangenheit). Mit dieser Funktion können Sie Snapshots und Klone mehrerer Tabellen gleichzeitig erfassen. Dadurch bleiben Ihre Arbeitsumgebung und die Snapshots konsistent. Diese Funktion kann hilfreich für Tabellen sein, die häufig aktualisiert werden.
Tabellenklone und Tabellen-Snapshots verwenden, um Isolation zu erlauben
Zur Veranschaulichung des Integrationsworkflows für CI in einem DWH stellen Sie sich das folgende Szenario vor. Sie haben die Aufgabe, ein neues Dataset in das DWH zu integrieren. Die Aufgabe kann darin bestehen, neue DWH-Tabellen zu erstellen, vorhandene Tabellen zu aktualisieren, die Struktur von Tabellen zu ändern oder eine Kombination dieser Aufgaben. Der Workflow sieht möglicherweise so aus:
- Sie identifizieren die Tabellen, die von den Änderungen betroffen sein könnten, und zusätzliche Tabellen, die Sie möglicherweise prüfen möchten.
- Sie erstellen ein neues BigQuery-Dataset, das die Assets für diese Änderung enthält. Dieses Dataset hilft Ihnen, die Änderungen zu isolieren und diese Aufgabe von anderen Aufgaben zu trennen, an denen andere Teammitglieder arbeiten. Das Dataset muss sich in derselben Region wie das Quell-Dataset befinden. Allerdings kann das Projekt von den Produktionsprojekten getrennt werden, um die Sicherheits- und Abrechnungsanforderungen Ihrer Organisation zu erfüllen.
Für jede Tabelle erstellen Sie im neuen Dataset sowohl einen Klon als auch einen Snapshot, möglicherweise rechtzeitig für denselben Punkt. Dieser Ansatz bietet folgende Vorteile:
- Der Tabellenklon kann als Arbeitskopie dienen, auf der Sie Änderungen frei vornehmen können, ohne dass sich dies auf die Produktionstabelle auswirkt. Sie können mehrere Tabellenklone derselben Basistabelle erstellen, um verschiedene Integrationspfade mit minimalem Aufwand gleichzeitig zu testen.
- Der Snapshot kann als Wiederherstellungs- und Referenzpunkt dienen, an dem die Daten bekanntermaßen funktioniert haben, bevor Änderungen vorgenommen wurden. Mit diesem Snapshot können Sie ein Rollback durchführen, falls später im Prozess ein Problem erkannt wird.
Sie verwenden die Tabellenklone, um die Änderungen zu implementieren, die für die Tabellen erforderlich sind. Dies führt zu einer aktualisierten Version der Tabellenklone, die Sie in einem isolierten Dataset testen können.
Optional können Sie am Ende der Implementierungsphase ein Dataset angeben, das für die folgenden Aufgaben verwendet werden kann:
- Einheitentest mit einem Validierungstool wie Dataform. Einheitentests sind eigenständig, d. h., das Asset wird isoliert getestet. In diesem Fall ist das Asset die Tabelle in BigQuery. Einheitentests können nach Nullwerten suchen, prüfen, ob alle Strings die Längenanforderungen erfüllen, und dafür sorgen, dass bestimmte Zusammenfassungen nützliche Ergebnisse liefern. Einheitentests können jeden Konfidenztest umfassen, der gewährleistet, dass die Tabelle die Geschäftsregeln der Organisation enthält.
- Integrationstests mit nachgeschalteten Nutzern.
- Begutachtung durch Kollegen.
Mit diesem Workflow können Sie mit Produktionsdaten testen, ohne die nachgelagerten Nutzer zu beeinträchtigen.
Bevor Sie die neuen Daten in BigQuery zusammenführen, können Sie einen weiteren Snapshot erstellen. Dieser Snapshot ist als weitere Rollback-Option nützlich, wenn sich die Daten in der Basistabelle geändert haben.
Der Zusammenführung der Änderungen hängt davon ab, welchen Prozess Ihre Organisation übernehmen möchte und welche Änderungen erforderlich sind. Bei einer Änderung der SQL-Skripts kann zum Beispiel das neue Dataset von einer Pull-Anfrage an die Standard-Codebasis begleitet werden. Wenn die Änderung auf eine Änderung der Daten in einer bestimmten Tabelle beschränkt ist, können Sie Daten einfach mit Standardmethoden von BigQuery kopieren.
Sie können ein Skript mit gespeicherten Prozeduren verwenden, um die Schritte zum Erstellen eines Datasets und zum Erstellen der Klone und Snapshots zu kapseln und zu automatisieren. Die Automatisierung dieser Aufgaben verringert das Risiko menschlicher Fehler. Ein Beispiel für ein Skript, das zur Automatisierung der Prozesse beitragen kann, finden Sie im GitHub-Repository des CI for Data in BigQuery-Befehlszeilendienstprogramms.
Vorteile von Tabellenklonen und Tabellen-Snapshots
Wenn Sie den im vorherigen Abschnitt beschriebenen Workflow verwenden, können Ihre Entwickler isoliert und parallel arbeiten, ohne ihre Kollegen zu beeinträchtigen. Entwickler können Änderungen testen und prüfen. Falls ein Problem auftritt, führen Sie ein Rollback der Änderungen durch. Da Sie mit Tabellen-Snapshots und nicht mit vollständigen Tabellen arbeiten, können Sie Kosten und Speicherplatz im Vergleich zu vollständigen Tabellen minimieren.
In diesem Abschnitt wird ausführlicher beschrieben, wie Entwickler mit diesem Snapshot und Tabellenklonen diesen Workflow erreichen. Das folgende Diagramm zeigt, wie Tabellen-Snapshots und Tabellenklone mit den Daten im Produktions-Dataset zusammenhängen.
Im Diagramm enthält das Produktions-Dataset alle Tabellen, die in der Produktion verwendet werden. Jeder Entwickler kann ein Dataset für seine eigene Entwicklungsumgebung erstellen. Das Diagramm zeigt zwei Entwickler-Datasets, die als Dev Dataset 1 und Dev Dataset 2 bezeichnet werden. Durch die Verwendung dieser Entwickler-Datasets können Entwickler gleichzeitig an denselben Tabellen arbeiten, ohne sich gegenseitig zu beeinträchtigen.
Nachdem Entwickler ein Dataset erstellt haben, können sie Klone und Snapshots der Tabellen erstellen, an denen sie arbeiten. Die Klone und Snapshots stellen die Daten zu einem bestimmten Zeitpunkt dar. An dieser Stelle können Entwickler die Tabellenklone ändern, da Änderungen in der Basistabelle nicht sichtbar sind.
Ein Entwickler kann die Tabellenklone prüfen, sie mit dem Snapshot vergleichen und sie auf Kompatibilität mit nachgelagerten Nutzern testen. Andere Entwickler können ohne Unterbrechung und mit anderen Klonen und Snapshots arbeiten, ohne zu viele ressourcenintensive Kopien der Basistabelle zu erstellen.
Entwickler können Änderungen in die Basistabelle zusammenführen und dabei bei Bedarf den Snapshot als Rollback-Option beibehalten. Dieser Vorgang kann auch für verschiedene Umgebungen wie Entwicklung, Test und Produktion wiederholt werden.
Alternativen zu Tabellenklonen und Tabellen-Snapshots
Es gibt Alternativen zur Verwendung von Tabellenklonen und Tabellen-Snapshots, mit denen Sie ein ähnliches Ergebnis erzielen können. Diese alternativen Methoden werden in der Regel anders verwendet als Klone und Snapshots. Es ist wichtig, die Unterschiede zwischen diesen Methoden zu verstehen und zu wissen, wo lieber eine Methode gegenüber der anderen bevorzugt werden sollte.
Gesamte Tabellen in ein anderes Dataset kopieren
Eine alternative Methode besteht darin, ein anderes Dataset zu verwenden und die Tabellen in dieses Dataset zu kopieren. Diese Methode ähnelt der Verwendung von Tabellenklonen und -Snapshots. Sie kopieren jedoch die gesamte Tabelle. Je nach Größe der zu kopierenden Daten können die Speicherkosten hoch sein. Einige Organisationen haben diese Methode verwendet, bevor Tabellenklone in BigQuery verfügbar wurden. Diese Methode bietet jedoch keine Vorteile gegenüber der Verwendung von Klonen und Snapshots.
Tabellen in Cloud Storage exportieren und importieren
Eine weitere alternative Methode besteht darin, die Daten über Cloud Storage zu verschieben. Diese Methode ähnelt auch der Verwendung von Tabellenklonen und Tabellen-Snapshots. Diese beinhaltet jedoch den zusätzlichen Schritt des Exports der Daten in einen Cloud Storage-Bucket. Ein Vorteil dieser Methode besteht darin, dass Sie eine zusätzliche Sicherung Ihrer Daten erhalten. Sie können diese Methode auswählen, wenn Sie eine Sicherung für die Notfallwiederherstellung oder Hybridlösungen wünschen.
Analytics Hub verwenden
Mit dem Analytics Hub können Sie Datasets sowohl außerhalb als auch innerhalb der Organisation auf sichere Weise freigeben. Es bietet viele Funktionen, mit denen Sie Datasets veröffentlichen können, um Abonnenten einen kontrollierten Lesezugriff auf diese Datasets zu gewähren. Sie können jedoch Analytics Hub verwenden, um Datasets zur Implementierung von Änderungen bereitzustellen. Ein Entwickler muss jedoch Tabellenklone erstellen, um mit den Tabellen arbeiten zu können.
Zusammenfassung der Optionen für die kontinuierliche Integration von DWH
In der folgenden Tabelle werden die Unterschiede, Vor- und Nachteile der Optionen für die Continuous Integration von DWH zusammengefasst. Analytics Hub bietet ein anderes Feature-Set und ist daher nicht mit den in der Tabelle aufgeführten Parametern messbar.
| Kosten | Rollbacks | Risiken | |
|---|---|---|---|
| Tabellen-Snapshots und Tabellenklone | Minimal. Sie zahlen nur für die Differenz zwischen dem Snapshot oder Klon und der Basistabelle. | Der Snapshot dient als Sicherung, um bei Bedarf ein Rollback durchzuführen. | Sie steuern die Risikomenge. Snapshots können für alle Tabellen zu einem bestimmten Zeitpunkt erstellt werden, wodurch Inkonsistenzen reduziert werden, auch wenn ein Rollback vorhanden ist. |
| Tabelle kopieren | Höhere Kosten als bei der Verwendung von Tabellen-Snapshots und Tabellenklonen. Die gesamten Daten werden dupliziert. Zur Unterstützung von Rollbacks benötigen Sie mehrere Kopien derselben Tabelle. | Es ist möglich, aber zwei Kopien der Tabelle sind erforderlich: eine Kopie als Sicherung und eine Kopie zur Verwendung und Änderungen. | Das Klonen ist für einen bestimmten Zeitpunkt schwieriger. Wenn ein Rollback erforderlich ist, werden nicht alle Tabellen von demselben Zeitpunkt übernommen. |
| Export und Import | Höhere Kosten als bei der Verwendung von Tabellen-Snapshots und Tabellenklonen. Die Daten wurden dupliziert. Zur Unterstützung des Rollbacks benötigen Sie mehrere Kopien derselben Tabelle. | Die exportierten Daten dienen als Sicherung. | Exportierte Daten sind kein Export zu einem bestimmten Zeitpunkt für mehrere Tabellen. |
Nächste Schritte
- Weitere Informationen zu BigQuery-Tabellen-Snapshots finden Sie unter Einführung in Tabellen-Snapshots.
- Weitere Informationen zur Continuous Integration für die Softwareentwicklung finden Sie unter DevOps-Technologie: Continuous Integration.
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.