Die Datenhierarchie in Datastream besteht aus folgenden Elementen:
- Stream: Setzt sich aus einer Datenquelle und einem Ziel 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 stellt die Änderung der Daten selbst aus dem Objekt dar, das aus der Streamquelle stammt. Jedes Ereignis enthält die gesamte geänderte Zeile.
- 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 wird. Diese Metadaten variieren je nach Quelle.
Ereignisdaten
Ereignisdaten sind die Nutzlast jeder Änderung aus einem bestimmten Objekt, das aus einer Streamquelle stammt.
Ereignisse sind entweder im Avro- oder im JSON-Format.
Bei Verwendung des Avro-Formats enthält das Ereignis für jede Spalte den Spaltenindex und -wert. Mit dem 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 Arten von Streams einheitlich.
Feld | Avro-Typ | JSON-Typ | Beschreibung |
---|---|---|---|
stream_name |
String | String | Der eindeutige Stream-Name, der bei der Erstellung definiert wurde. |
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:
|
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 Ereignis, die von Datastream generiert wird. |
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.
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 (der 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 |
|
MySQL | database |
String | String | Die mit dem Ereignis verknüpfte Datenbank. |
MySQL | table |
String | String | Die Tabelle, die dem Ereignis zugeordnet ist. |
MySQL | change_type |
String | String | Die Art der Änderung ( |
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 | row_id |
String | String | row_id von Oracle. |
Oracle | is_deleted |
Boolesch | Boolesch |
|
Oracle | database |
String | String | Die mit dem Ereignis verknüpfte Datenbank. |
Oracle | schema |
String | String | Das Schema, das der Tabelle aus dem Ereignis zugeordnet ist. |
Oracle | table |
String | String | Die Tabelle, die dem Ereignis zugeordnet ist. |
Oracle | change_type |
String | String | Die Art der Änderung ( |
Oracle | tx_id |
String | String | Die Transaktions-ID, zu der das Ereignis gehört. |
Oracle | rs_id |
String | String | Die ID des Datensatzes. Durch die Kombination von rs_id und ssn wird eine Zeile in V$LOGMNR_CONTENTS eindeutig identifiziert. rs_id identifiziert den Redo-Datensatz, aus dem die Zeile generiert wurde, eindeutig. |
Oracle | ssn |
long | long | Eine SQL-Sequenznummer. Diese Nummer wird mit rs_id verwendet und identifiziert eine Zeile in V$LOGMNR_CONTENTS eindeutig. |
PostgreSQL | schema |
String | String | Das Schema, das der Tabelle aus dem Ereignis zugeordnet ist. |
PostgreSQL | table |
String | String | Die Tabelle, die dem Ereignis zugeordnet ist. |
PostgreSQL | is_deleted |
boolean | Boolesch |
|
PostgreSQL | change_type |
String | String | Die Art der Änderung (INSERT , UPDATE , DELETE ), die das Ereignis darstellt.
|
PostgreSQL | tx_id |
String | String | Die Transaktions-ID, zu der das Ereignis gehört. |
PostgreSQL | lsn |
String | String | Die Logfolgenummer für den aktuellen Eintrag. |
PostgreSQL | 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. |
SQL Server | table |
String | String | Die Tabelle, die dem Ereignis zugeordnet ist. |
SQL Server | database |
long | long | Die mit dem Ereignis verknüpfte Datenbank. |
SQL Server | schema |
String-Array | String-Array | Das Schema, das der Tabelle aus dem Ereignis zugeordnet ist. |
SQL Server | is_deleted |
boolean | Boolesch |
|
SQL Server | lsn |
String | String | Die Logfolgenummer für das Ereignis. |
SQL Server | tx_id |
String | String | Die Transaktions-ID, zu der das Ereignis gehört. |
SQL Server | physical_location |
Ganzzahl-Array | Ganzzahl-Array | Der physische Speicherort des Logeintrags, der durch drei Ganzzahlen beschrieben wird: Datei-ID, Seiten-ID und Slot-ID des Eintrags. |
SQL Server | replication_index |
String-Array | String-Array | Die Liste der Spaltennamen eines Index, mit denen eine Zeile in der Tabelle eindeutig identifiziert werden kann. |
SQL Server | change_type |
String | String | Die Art der Änderung ( |
Salesforce | object_name |
String | String | Der Name des Salesforce-Objekts, das mit dem Ereignis verknüpft ist. |
Salesforce | domain |
String | String | Der Name der mit dem Ereignis verknüpften Domain. |
Salesforce | is_deleted |
boolean | Boolesch |
|
Salesforce | change_type |
String | String | Die Art der Änderung ( |
Salesforce | primary_keys |
String-Array | String-Array | Die Liste mit Spaltennamen, aus denen der Primärschlüssel der Tabelle besteht. Wenn die Tabelle keinen Primärschlüssel hat, ist dieses Feld leer. |
MongoDB | database |
String | String | Die mit dem Ereignis verknüpfte Datenbank. |
MongoDB | collection |
String | String | Die mit dem Ereignis verknüpfte Sammlung. Sammlungen sind analog zu Tabellen in relationalen Datenbanken. |
MongoDB | change_type |
String | String | Die Art der Änderung (CREATE , UPDATE und DELETE ), die das Ereignis darstellt. |
MongoDB | is_deleted |
boolean | Boolesch |
|
MongoDB | primary_keys |
String-Array | String-Array | Das Feld _id , das als Primärschlüssel für jedes Dokument in einer Sammlung dient. |
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.
UHRZEIT | 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 Nutzlast der Nachricht 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 Nutzlast der Nachricht besteht aus der gesamten neuen Zeile. Vorherige Werte werden nicht berücksichtigt.
{
"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 Nutzlast der Nachricht 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 kann zwar keine Reihenfolge garantieren, aber jedes Ereignis enthält die vollständige Datenzeile und den Zeitstempel, wann die Daten in die Quelle geschrieben wurden. In BigQuery werden Ereignisse, die nicht in der richtigen Reihenfolge eintreffen, automatisch in der richtigen Reihenfolge zusammengeführt. BigQuery verwendet die Ereignismetadaten und eine interne Änderungsfolgenummer (Change Sequence Number, CSN), um die Ereignisse in der richtigen Reihenfolge auf die Tabelle anzuwenden. In Cloud Storage können Ereignisse aus demselben Zeitraum mehrere Dateien 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 einzeln abgeleitet werden.
Quelle | Beschreibung |
---|---|
MySQL | Ereignisse, die Teil des ersten Backfills sind, haben das Feld Bei Ereignissen, die Teil der laufenden Replikation sind, ist das Feld Die Reihenfolge kann aus der Kombination des Felds |
Oracle | Ereignisse, die Teil des ersten Backfills sind, haben das Feld Bei Ereignissen, die Teil der laufenden Replikation sind, ist das Feld Die Reihenfolge kann aus der Kombination des Felds |
PostgreSQL | Ereignisse, die Teil des ersten Backfills sind, haben das Feld Bei Ereignissen, die Teil der laufenden Replikation sind, ist das Feld Die Reihenfolge kann aus der Kombination des Felds |
SQL Server |
Ereignisse, die Teil des ersten Backfills sind, haben das Feld Bei Ereignissen, die Teil der laufenden Replikation sind, ist das Feld Die Reihenfolge kann aus der Kombination des Felds |
Salesforce (Vorschau) |
Die Reihenfolge kann bestimmt werden, indem der |
MongoDB (Vorabversion) |
Die Reihenfolge kann anhand des Felds |
Konsistenz
Datastream sorgt dafür, 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 Datenbanklogdateien nicht festgeschriebene Transaktionen enthalten und Transaktionen zurückgesetzt werden, spiegelt die Datenbank dies in den Logdateien als „umgekehrte“ DML-Vorgänge (Datenbearbeitungssprache) wider. Ein Rollback-Vorgang INSERT
hat beispielsweise einen entsprechenden DELETE
-Vorgang. Datastream liest diese Vorgänge aus den Logdateien.
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.
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:
Not started
Starting
Running
Draining
Paused
Failed
Failed permanently
In den Logs finden Sie zusätzliche Statusinformationen, z. B. zum Backfilling von Tabellen oder zur Anzahl der verarbeiteten Zeilen. Sie können auch die FetchStreamErrors
API verwenden, um Fehler abzurufen.
Mit der Discover API verfügbare Objektmetadaten
Die Discover API gibt Objekte zurück, die die Struktur der Objekte darstellen, die in der Datenquelle oder dem Ziel definiert sind, die durch das Verbindungsprofil dargestellt werden. Jedes Objekt hat Metadaten zum Objekt selbst sowie für jedes Datenfeld, das abgerufen wird. Diese Metadaten sind über die Discover API verfügbar.
Nächste Schritte
- Weitere Informationen zu Streams finden Sie unter Stream-Lebenszyklus.
- Informationen zum Erstellen eines Streams finden Sie unter Stream erstellen.