Ereignisse und Streams

In Bezug auf Complianceprogramme arbeitet Datastream derzeit daran, Parität mit den Google Cloud-Produkten zu erreichen, mit denen es zusammenarbeiten soll (z. B. Cloud Storage, BigQuery, Cloud SQL, Cloud Spanner usw.). Weitere Informationen finden Sie unter Google Cloud Platform-Dienste innerhalb des Complianceprogramms und im Center für Compliance-Ressourcen.

Übersicht

Die Datenhierarchie in Datastream besteht aus folgenden Elementen:

• Stream: setzt sich aus einer Datenquelle und einem Ziel-Bucket zusammen.
• Objekt: ein Teil eines Streams, z. B. eine Tabelle aus einer bestimmten Datenbank.
• Ereignis: eine einzelne Änderung, die von einem bestimmten Objekt generiert wird, z. B. eine Datenbankeinfügung.

Streams, Objekte und Ereignisse sind mit Daten und Metadaten verknüpft. Diese Daten und Metadaten können für verschiedene Zwecke verwendet werden.

Über Ereignisse

Jedes Ereignis besteht aus drei Datentypen:

• Ereignisdaten: Dies ist die Änderung der Daten selbst aus dem Objekt, das aus der Streamquelle stammt. Jedes Ereignis enthält die gesamte Zeile, die sich geändert hat.
• Allgemeine Metadaten: Diese Metadaten werden bei jedem von Datastream generierten Ereignis angezeigt, das für Aktionen verwendet wird, z. B. um doppelte Daten am Ziel zu entfernen.
• Quellspezifische Metadaten: Diese Metadaten werden bei jedem Ereignis angezeigt, das von einer bestimmten Streamquelle generiert wurde. Diese Metadaten variieren je nach Quelle.

Ereignisdaten

Ereignisdaten sind die Nutzlast jeder Änderung aus einem bestimmten Objekt, das aus einer Streamquelle stammt.

Ereignisse haben entweder das Avro- oder das JSON-Format. Beim Avro-Format enthält das Ereignis für jede Spalte den Spaltenindex und den Wert. Mithilfe des Spaltenindex können der Spaltenname und der einheitliche Typ aus dem Schema im Avro-Header abgerufen werden.

Bei Verwendung des JSON-Formats enthält das Ereignis für jede Spalte den Spaltennamen und -wert.

Ereignismetadaten können verwendet werden, um Informationen zum Ursprung des Ereignisses zu erfassen und doppelte Daten am Ziel zu entfernen und Ereignisse nach dem nachgelagerten Nutzer zu sortieren.

In den folgenden Tabellen werden die Felder und Datentypen für allgemeine und quellenspezifische Ereignismetadaten aufgelistet und beschrieben.

Allgemeine Metadaten

Diese Metadaten sind für alle Streamtypen konsistent.

Feld	Avro-Typ	JSON-Typ	Beschreibung
stream_name	String	String	Eindeutiger Streamname, wie beim Erstellen definiert.
read_method	String	String	Gibt an, ob die Daten aus der Quelle mit einer CDC-Methode (Change Data Capture) als Teil des verlaufsbezogenen Backfills oder als Teil einer Ergänzungsaufgabe gelesen wurden, die beim Rollback einer Transaktion während der CDC-Replikation erstellt wird. Zulässige Werte: oracle-cdc-logminer oracle-backfill oracle-supplementation mysql-cdc-binlog mysql-backfill-incremental mysql-backfill-fulldump
object	String	String	Der Name, mit dem verschiedene Ereignistypen gruppiert werden, in der Regel der Name der Tabelle oder des Objekts in der Quelle.
schema_key	String	String	Die eindeutige Kennung für das einheitliche Schema des Ereignisses.
uuid	String	String	Eine eindeutige Kennung für das von Datastream generierte Ereignis.
read_timestamp	timestamp-millis	String	Der Zeitstempel (UTC), wenn der Datensatz von Datastream gelesen wurde (der Epochenzeitstempel in Millisekunden).
source_timestamp	timestamp-millis	String	Der Zeitstempel (UTC), wenn sich der Eintrag in der Quelle geändert hat (der Epochenzeitstempel in Millisekunden).
sort_keys	{"type": "array", "items": ["string", "long"]}	array	Ein Array von Werten, mit denen die Ereignisse in der Reihenfolge sortiert werden können, in der sie aufgetreten sind.

Quellspezifische Metadaten

Diese Metadaten sind CDC- und Backfill-Ereignissen aus einer Quelldatenbank zugeordnet. Wählen Sie im Drop-down-Menü unten eine Quelle aus, um diese Metadaten aufzurufen.

Alle Quellen MySQL Oracle

Quelle	Feld	Avro-Typ	JSON-Typ	Beschreibung
MySQL	log_file	String	String	Die Logdatei, aus der Datastream Ereignisse bei der CDC-Replikation abruft.
MySQL	log_position	long	long	Die Logposition (Offset) im binären MySQL-Log.
MySQL	primary_keys	String-Array	String-Array	Die Liste mit einem oder mehreren Spaltennamen, aus denen der Primärschlüssel der Tabellen besteht. Wenn die Tabelle keinen Primärschlüssel hat, ist dieses Feld leer.
MySQL	is_deleted	Boolesch	Boolesch	Der Wert true gibt an, dass die Zeile in der Quelle gelöscht wurde. Der Wert false gibt an, dass die Zeile nicht gelöscht wurde.
MySQL	database	String	String	Die dem Ereignis zugeordnete Datenbank.
MySQL	table	String	String	Die dem Ereignis zugeordnete Tabelle.
MySQL	change_type	String	String	Die Art der Änderung (INSERT, UPDATE-INSERT, UPDATE-DELETE und DELETE), die das Ereignis darstellt. Bei der zeilenbasierten MySQL-Replikation enthält jedes Ereignis für eine Zeile mit einer Primärschlüsseländerung zwei Images: ein "Vorher"-Image, dessen Spalten bei der Suche nach der zu aktualisierenden Zeile abgegelichen werden, und ein "Nachher"-Image, das die Änderungen enthält. Bei der UPDATE-DELETE-Änderung ist beispielsweise UPDATE-DELETE das "Vorher"-Image und UPDATE-INSERT das "Nachher"-Image. Weitere Informationen finden Sie unter Zeilenbasierte MySQL-Replikation.
Oracle	log_file	String	String	Die Logdatei, aus der Datastream Ereignisse bei der CDC-Replikation abruft.
Oracle	scn	long	long	Die Logposition (Offset) im Oracle-Transaktionslog.
Oracle	rowid	String	String	Zeilen-ID von Oracle.
Oracle	is_deleted	Boolesch	Boolesch	Der Wert true gibt an, dass die Zeile in der Quelle gelöscht wurde. Der Wert false gibt an, dass die Zeile nicht gelöscht wurde.
Oracle	database	String	String	Die dem Ereignis zugeordnete Datenbank.
Oracle	schema	String	String	Das Schema, das der Tabelle aus dem Ereignis zugeordnet ist.
Oracle	table	String	String	Die dem Ereignis zugeordnete Tabelle.
Oracle	change_type	String	String	Die Art der Änderung (INSERT, UPDATE-INSERT, UPDATE-DELETE und DELETE), die das Ereignis darstellt. Bei der zeilenbasierten Oracle-Replikation enthält jedes Ereignis für eine Zeile mit einer Primärschlüsseländerung zwei Images: ein "Vorher"-Image, dessen Spalten bei der Suche nach der zu aktualisierenden Zeile abgeglichen werden, und ein "Nachher"-Image, das die Änderungen enthält. Bei der UPDATE-DELETE-Änderung ist beispielsweise UPDATE-DELETE das "Vorher"-Image und UPDATE-INSERT das "Nachher"-Image. Weitere Informationen zur zeilenbasierten Oracle-Replikation
Oracle	tx_id	String	String	Die Transaktions-ID, zu der das Ereignis gehört.
Oracle	rs_id	String	String	Die Datensatz-ID. Die Kopplung aus rs_id und ssn identifiziert eine Zeile in V$LOGMNR_CONTENTS eindeutig. rs_id identifiziert den Redo-Eintrag, der die Zeile generiert hat, eindeutig.
Oracle	ssn	long	long	Eine SQL-Sequenznummer. Diese Zahl wird mit rs_id verwendet und identifiziert eine Zeile in V$LOGMNR_CONTENTS eindeutig.

Beispiel für einen Ereignisablauf

Dieser Ablauf veranschaulicht die Ereignisse, die von drei aufeinanderfolgenden Vorgängen generiert werden: INSERT, UPDATE und DELETE in einer einzelnen Zeile in einer SAMPLE-Tabelle für eine Quelldatenbank.

Hinweis: Dieser Beispielereignisablauf bezieht sich auf eine Oracle-Datenbank, ähnelt jedoch einer MySQL-Datenbank.

TIME	THIS_IS_MY_PK (int)	FIELD1 (nchar, Nullwerte zulässig)	FIELD2 (nchar, keine Nullwerte)>
0	1231535353	foo	TLV
1	1231535353	NULL	TLV

INSERT (T0)

Die Nachrichtennutzlast besteht aus der gesamten neuen Zeile.

{
  "stream_name": "projects/myProj/locations/myLoc/streams/Oracle-to-Source",
  "read_method": "oracle-cdc-logminer",
  "object": "SAMPLE.TBL",
  "uuid": "d7989206-380f-0e81-8056-240501101100",
  "read_timestamp": "2019-11-07T07:37:16.808Z",
  "source_timestamp": "2019-11-07T02:15:39",
  "source_metadata": {
    "log_file": ""
    "scn": 15869116216871,
    "row_id": "AAAPwRAALAAMzMBABD",
    "is_deleted": false,
    "database": "DB1",
    "schema": "ROOT",
    "table": "SAMPLE"
    "change_type": "INSERT",
    "tx_id":
    "rs_id": "0x0073c9.000a4e4c.01d0",
    "ssn": 67,
  },
  "payload": {
    "THIS_IS_MY_PK": "1231535353",
    "FIELD1": "foo",
    "FIELD2": "TLV",
  }
}

UPDATE (T1)

Die Nachrichtennutzlast besteht aus der gesamten neuen Zeile. Sie enthält keine vorherigen Werte.

{
  "stream_name": "projects/myProj/locations/myLoc/streams/Oracle-to-Source",
  "read_method": "oracle-cdc-logminer",
  "object": "SAMPLE.TBL",
  "uuid": "e6067366-1efc-0a10-a084-0d8701101101",
  "read_timestamp": "2019-11-07T07:37:18.808Z",
  "source_timestamp": "2019-11-07T02:17:39",
  "source_metadata": {
    "log_file":
    "scn": 15869150473224,
    "row_id": "AAAGYPAATAAPIC5AAB",
    "is_deleted": false,
    "database":
    "schema": "ROOT",
    "table": "SAMPLE"
    "change_type": "UPDATE",
    "tx_id":
    "rs_id": "0x006cf4.00056b26.0010",
    "ssn": 0,
  },
  "payload": {
    "THIS_IS_MY_PK": "1231535353",
    "FIELD1": null,
    "FIELD2": "TLV",
  }
}

DELETE (T2)

Die Nachrichtennutzlast besteht aus der gesamten neuen Zeile.

{
  "stream_name": "projects/myProj/locations/myLoc/streams/Oracle-to-Source",
  "read_method": "oracle-cdc-logminer",
  "object": "SAMPLE.TBL",
  "uuid": "c504f4bc-0ffc-4a1a-84df-6aba382fa651",
  "read_timestamp": "2019-11-07T07:37:20.808Z",
  "source_timestamp": "2019-11-07T02:19:39",
  "source_metadata": {
    "log_file":
    "scn": 158691504732555,
    "row_id": "AAAGYPAATAAPIC5AAC",
    "is_deleted": true,
    "database":
    "schema": "ROOT",
    "table": "SAMPLE"
    "change_type": "DELETE",
    "tx_id":
    "rs_id": "0x006cf4.00056b26.0011",
    "ssn": 0,
  },
  "payload": {
    "THIS_IS_MY_PK": "1231535353",
    "FIELD1": null,
    "FIELD2": "TLV",
  }
}

Sortierung und Konsistenz

In diesem Abschnitt wird erläutert, wie Datastream die Sortierung und Konsistenz verarbeitet.

Bestellung

Datastream garantiert keine Reihenfolge. Datastream generiert Ereignisse zwar in der richtigen Reihenfolge, doch können Ereignisse aus demselben Objekt mehrere Dateien in Cloud Storage umfassen.

In der falschen Reihenfolge generierte Ereignisse erfolgen standardmäßig, wenn ein Backfill für den ersten Backfill der Daten durchgeführt wird, die beim Initiieren des Streams erstellt wurden.

Die Reihenfolge kann für jede Quelle abgeleitet werden. Wählen Sie im Drop-down-Menü unten eine Quelle aus.

Alle Quellen MySQL Oracle

Quelle	Beschreibung
MySQL	Ereignisse, die Teil des ersten Backfills sind, haben das Feld read_method, das mit mysql-backfill beginnt. Es gibt keine Auswirkungen auf die Reihenfolge, in der Ereignisse innerhalb des Backfills empfangen werden, da sie in beliebiger Reihenfolge verwendet werden können. Für Ereignisse, die Teil der laufenden Replikation sind, ist das Feld read_method auf mysql-cdc-binlog gesetzt. Die Reihenfolge kann durch die Kombination des Felds log_file und des Felds log_position abgeleitet werden, das von der Logdatei versetzt ist. Diese Kombination bietet eine eindeutige, inkrementell ansteigende Zahl, die die Reihenfolge des Vorgangs in der Datenbank angibt.
Oracle	Ereignisse, die Teil des ersten Backfills sind, haben das Feld read_method, das mit oracle-backfill beginnt. Es gibt keine Auswirkungen auf die Reihenfolge, in der Ereignisse innerhalb des Backfills empfangen werden, da sie in beliebiger Reihenfolge verwendet werden können. Für Ereignisse, die Teil der laufenden Replikation sind, ist das Feld read_method auf oracle-cdc-logminer gesetzt. Die Reihenfolge kann aus der Kombination aus dem Feld rs_id (der Datensatz-ID) und dem Feld ssn (SQL-Sequenznummer) abgeleitet werden. Diese Kombination bietet eine eindeutige, inkrementell ansteigende Zahl, die die Reihenfolge des Vorgangs in der Datenbank angibt.

Konsistenz

Datastream garantiert, dass die Daten aus der Quelldatenbank mindestens einmal an das Ziel gesendet werden. Es werden keine Ereignisse ausgelassen. Es ist aber möglich, dass im Stream doppelte Ereignisse vorliegen. Das Zeitfenster für doppelte Ereignisse sollte in der Größenordnung von Minuten angegeben werden und die UUID (Universally Unique Identifier) des Ereignisses in den Ereignismetadaten kann verwendet werden, um Duplikate zu erkennen.

Wenn Datenbank-Logdateien nicht festgeschriebene Transaktionen enthalten und Transaktionen rückgängig gemacht werden, wird dies von der Datenbank in den Logdateien als "umgekehrte" DML-Vorgänge (Data Manipulation Language, Datenbearbeitungssprache) angezeigt. Beispiel: Ein INSERT-Vorgang, für den ein Rollback durchgeführt wurde, hat einen entsprechenden DELETE-Vorgang. Datastream liest diese Vorgänge aus den Logdateien.

Über Streams

Jeder Stream hat Metadaten, die sowohl den Stream als auch die Quelle beschreiben, aus der Daten abgerufen werden. Diese Metadaten enthalten Informationen wie den Streamnamen, die Quell- und Zielverbindungsprofile usw.

Die vollständige Definition des Stream-Objekts finden Sie in der Dokumentation API-Referenz.

Streamzustand und -status

Ein Stream kann einen der folgenden Status haben:

• CREATED
• RUNNING
• PAUSED
• FAILED

In den Logs finden Sie zusätzliche Statusinformationen wie den Tabellen-Backfill, die Anzahl der verarbeiteten Zeilen usw. Sie können auch die FetchStreamErrors API zum Abrufen von Fehlern verwenden.

Mit der Discover API verfügbare Objektmetadaten

Die Discover API gibt Objekte zurück, die die Struktur der in der Datenquelle oder am Ziel definierten Objekte darstellen, die durch das Verbindungsprofil dargestellt werden. Jedes Objekt enthält Metadaten für das Objekt selbst sowie für jedes abgerufene Datenfeld. Diese Metadaten sind über die Discovery API verfügbar.