[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[[["\u003cp\u003eDatastream's data hierarchy consists of streams, which encompass a data source and destination, objects which represent portions of a stream like a table, and events which are the individual changes made to an object, such as a database insert.\u003c/p\u003e\n"],["\u003cp\u003eEach event in Datastream contains event data, which is the row that was modified; generic metadata, which is consistent across all events; and source-specific metadata, which varies depending on the data source.\u003c/p\u003e\n"],["\u003cp\u003eGeneric metadata fields included in every event provide information such as the stream name, the read method (e.g. CDC or backfill), the object name, the schema key, a unique event identifier, read and source timestamps, and sort keys.\u003c/p\u003e\n"],["\u003cp\u003eSource-specific metadata fields vary by source database (MySQL, Oracle, etc.) and can include details like log file, log position, transaction ID, or table name.\u003c/p\u003e\n"],["\u003cp\u003eWhile Datastream doesn't guarantee strict event ordering, each event contains a full data row and timestamps, and ordering can be inferred using various field combinations like \u003ccode\u003elog_file\u003c/code\u003e and \u003ccode\u003elog_position\u003c/code\u003e for MySQL, or \u003ccode\u003ers_id\u003c/code\u003e and \u003ccode\u003essn\u003c/code\u003e for Oracle.\u003c/p\u003e\n"]]],[],null,["# Events and streams\n\nThe data hierarchy in Datastream is:\n\n- A **stream**, which is comprised of a data source and a destination.\n- An **object**, which is a portion of a stream, such as a table from a specific database.\n- An **event**, which is a single change generated by a specific object, such as a database insert.\n\nStreams, objects, and events have data and metadata associated with them. This data and metadata can be used for different purposes.\n\nAbout events\n------------\n\nEach event consists of three types of data:\n\n- **Event data**: This represents the change to the data itself from the object originating from the stream source. Every event contains the entirety of the row that changed.\n- **Generic metadata**: This metadata appears on every event generated by Datastream which is used for actions, such as removing duplicate data in the destination.\n- **Source-specific metadata**: This metadata appears on every event generated by a specific stream source. This metadata varies by source.\n\n### Event data\n\nEvent data is the payload of every change from a given object originating from a stream source.\n\nEvents are in either the Avro or JSON format.\n\nWhen working with the Avro format, for each column, the event contains the column index and value. Using the column index, the column name and unified type can be retrieved from the schema in the Avro header.\n| **Note:** When Datastream converts data to the Avro format, special characters in column names are replaced with underscores. This can lead to duplicate column names and result in your streams failing. For more information about naming conventions in Avro, see the [Apache Avro documentation](https://avro.apache.org/docs/1.11.1/specification/#names).\n\nWhen working with the JSON format, for each column, the event contains the column name and value.\n\nEvent metadata can be used to collect information about the event's origin, as well as to remove duplicate data in the destination and order events by the downstream consumer.\n\nThe following tables list and describe the fields and data types for generic and source-specific event metadata.\n\n### Generic metadata\n\nThis metadata is consistent across streams of all types.\n\n### Source-specific metadata\n\nThis metadata is associated with CDC and backfill events from a source database. To view this metadata, select a source from the drop-down menu that follows. \nAll sources MySQL Oracle PostgreSQL SQL Server Salesforce MongoDB \n\n### Example of an event flow\n\nThis flow illustrates the events generated by three consecutive operations:\n`INSERT`, `UPDATE`, and `DELETE`, on a single row in a `SAMPLE` table for a source database.\n| **Note:** This sample event flow is for an Oracle database, but it's similar for a MySQL or PostgreSQL database.\n\n#### INSERT (T0)\n\nThe message payload consists of the entirety of the new row. \n\n {\n \"stream_name\": \"projects/myProj/locations/myLoc/streams/Oracle-to-Source\",\n \"read_method\": \"oracle-cdc-logminer\",\n \"object\": \"SAMPLE.TBL\",\n \"uuid\": \"d7989206-380f-0e81-8056-240501101100\",\n \"read_timestamp\": \"2019-11-07T07:37:16.808Z\",\n \"source_timestamp\": \"2019-11-07T02:15:39\", \n \"source_metadata\": {\n \"log_file\": \"\"\n \"scn\": 15869116216871,\n \"row_id\": \"AAAPwRAALAAMzMBABD\",\n \"is_deleted\": false,\n \"database\": \"DB1\",\n \"schema\": \"ROOT\",\n \"table\": \"SAMPLE\"\n \"change_type\": \"INSERT\",\n \"tx_id\": \n \"rs_id\": \"0x0073c9.000a4e4c.01d0\",\n \"ssn\": 67,\n },\n \"payload\": {\n \"THIS_IS_MY_PK\": \"1231535353\",\n \"FIELD1\": \"foo\",\n \"FIELD2\": \"TLV\",\n }\n }\n\n#### UPDATE (T1)\n\nThe message payload consists of the entirety of the new row. It doesn't include previous values. \n\n {\n \"stream_name\": \"projects/myProj/locations/myLoc/streams/Oracle-to-Source\",\n \"read_method\": \"oracle-cdc-logminer\",\n \"object\": \"SAMPLE.TBL\",\n \"uuid\": \"e6067366-1efc-0a10-a084-0d8701101101\",\n \"read_timestamp\": \"2019-11-07T07:37:18.808Z\",\n \"source_timestamp\": \"2019-11-07T02:17:39\", \n \"source_metadata\": {\n \"log_file\": \n \"scn\": 15869150473224,\n \"row_id\": \"AAAGYPAATAAPIC5AAB\",\n \"is_deleted\": false,\n \"database\":\n \"schema\": \"ROOT\",\n \"table\": \"SAMPLE\"\n \"change_type\": \"UPDATE\",\n \"tx_id\":\n \"rs_id\": \"0x006cf4.00056b26.0010\",\n \"ssn\": 0,\n },\n \"payload\": {\n \"THIS_IS_MY_PK\": \"1231535353\",\n \"FIELD1\": null,\n \"FIELD2\": \"TLV\",\n }\n }\n\n#### DELETE (T2)\n\nThe message payload consists of the entirety of the new row. \n\n {\n \"stream_name\": \"projects/myProj/locations/myLoc/streams/Oracle-to-Source\",\n \"read_method\": \"oracle-cdc-logminer\",\n \"object\": \"SAMPLE.TBL\",\n \"uuid\": \"c504f4bc-0ffc-4a1a-84df-6aba382fa651\",\n \"read_timestamp\": \"2019-11-07T07:37:20.808Z\",\n \"source_timestamp\": \"2019-11-07T02:19:39\",\n \"source_metadata\": {\n \"log_file\": \n \"scn\": 158691504732555,\n \"row_id\": \"AAAGYPAATAAPIC5AAC\",\n \"is_deleted\": true,\n \"database\":\n \"schema\": \"ROOT\",\n \"table\": \"SAMPLE\"\n \"change_type\": \"DELETE\",\n \"tx_id\":\n \"rs_id\": \"0x006cf4.00056b26.0011\",\n \"ssn\": 0,\n },\n \"payload\": {\n \"THIS_IS_MY_PK\": \"1231535353\",\n \"FIELD1\": null,\n \"FIELD2\": \"TLV\",\n }\n }\n\nOrdering and consistency\n------------------------\n\nThis section covers how Datastream handles ordering and consistency.\n\n### Ordering\n\nDatastream doesn't guarantee ordering, but each event contains the full row of data and the timestamp of when the data was written to the source. In BigQuery, out-of-order events are merged in the correct sequence automatically. BigQuery uses the event metadata and an internal change sequence number (CSN) to apply the events to the table in the correct order. In Cloud Storage, events from the same time can span more than one file.\n\nEvents that are generated out of order happen by design when events are backfilled for the initial backfill of data that's created when the stream is initiated.\n\nOrdering can be inferred on a source-by-source basis.\n\n\u003cbr /\u003e\n\n### Consistency\n\nDatastream ensures that the data from the source database is delivered to the destination at least once. No event is missed, but there's a possibility of duplicate events in the stream. The window for duplicate events should be on the order of minutes, and the universally unique identifier (UUID) of the event in the [event metadata](#genericmetadata) can be used to detect duplicates.\n\nWhen database log files contain uncommitted transactions, if any transactions are rolled back, then the database reflects this in the log files as \"reverse\" data manipulation language (DML) operations. For example, a rolled-back `INSERT` operation will have a corresponding `DELETE` operation. Datastream reads these operations from the log files.\n\nAbout streams\n-------------\n\nEvery stream has metadata that describes both the stream and the source from which it pulls data. This metadata includes information such as the stream name, the source and destination connection profiles.\n\nTo view the complete definition of the Stream object, see the [API Reference](/datastream/docs/reference/rest/v1/projects.locations.streams) documentation.\n\n### Stream state and status\n\nA stream can be in one of the following states:\n\n- `Not started`\n- `Starting`\n- `Running`\n- `Draining`\n- `Paused`\n- `Failed`\n- `Failed permanently`\n\n| For more information about these states, including how they're used in the lifecycle of a stream, see [Stream lifecycle](/datastream/docs/stream-states-and-actions).\n\nYou can use the logs to find additional status information, such as the tables\nbackfilling or number of rows processed. You can also use the\n[`FetchStreamErrors`](/datastream/docs/manage-streams#fetchstreamerrors) API to\nretrieve errors.\n\nObject metadata available using the discover API\n------------------------------------------------\n\nThe discover API returns objects which represent the structure of the objects\ndefined in the data source or destination that's represented by the connection\nprofile. Each object has metadata on the object itself, as well as for every\nfield of data that it pulls. This metadata is available using the [discover\nAPI](/datastream/docs/reference/rest/v1/projects.locations.connectionProfiles/discover).\n\nWhat's next\n-----------\n\n- To learn more about streams, see [Stream lifecycle](/datastream/docs/stream-states-and-actions).\n- To learn how to create a stream, see [Create a stream](/datastream/docs/create-a-stream)."]]