Skip to content

Forward Data to TiDB Cloud Lake


After selecting TiDB Cloud Lake as the forwarding destination, TrueWatch generates independent Parquet batches according to the forwarding rules, loads them via system-managed intermediate storage to the specified Database.TargetTable, and supports long-term SQL and business correlation analysis.

Prerequisites

Before you start configuring, confirm:

  • Lake DSN: Already obtained and contains a valid Database and Warehouse. If you don't have one, first Obtain a Lake DSN;
  • Forwarding rule: Already completed Rule name and filter condition setup;
  • SQL user permissions: Write permission is required if the target table already exists; if the target table does not exist, permission to create tables in the target Database is also required.
Permission Recommendations

It is recommended to use a dedicated SQL user for data forwarding and grant only the required write and table creation permissions for the target Database and target table. Do not use a personal account with full administrative privileges.

Configuration Steps

Step 1: Select the Forwarding Destination

In Select Forwarding Destination, choose TiDB Cloud Lake from the Analysis Platform group.

After selection, the following configurations are fixed by the system:

Configuration Item Fixed Value Description
Forwarding Destination Type Analysis Platform (AP) Loads observability data into TiDB Cloud Lake for long-term SQL and business correlation analysis
Storage Format Parquet Default storage format
Access Type SQL Connection Authentication Uses Lake DSN to authenticate identity and perform loading
Intermediate Storage System-managed No need to fill in Bucket, Region, object path, IAM Role, or Access Keys

Step 2: Fill in Connection Information

Configuration Item Required Description
Lake DSN Yes Paste the full DSN copied from the TiDB Cloud Lake Connect page
Database Auto Automatically parsed from the Lake DSN path; read-only display, no separate modification supported
Warehouse Auto Automatically parsed from the Lake DSN parameters; read-only display, no separate modification supported
Target Table Yes Enter only the table name; the actual load target is Database.TargetTable
Data Waiting Time Yes Optional: 15 minutes, 30 minutes, or 1 hour; default is 1 hour

After filling in the Lake DSN, first confirm that Database and Warehouse have been automatically parsed, then fill in the Target Table.

System-managed Storage

The system generates independent Parquet batches according to the current rule and loads them into Database.TargetTable. If the target table does not exist, it will be automatically created upon rule creation according to the system-managed schema of the current forwarded data type.

Step 3: Test the Connection

Click Test Connection. The system verifies:

  • The format and authentication information of the Lake DSN;
  • Whether Database and Warehouse are valid;
  • Whether the network is reachable;
  • Whether the target table exists;
  • If the target table exists, whether the SQL user has write permission and whether the table schema is compatible;
  • If the target table does not exist, whether the SQL user has permission to create tables in the target Database.

After the test, the page indicates the target table status, permission check results, and any issues that need resolution based on the check results.

Test Connection Does Not Create the Target Table

The test connection checks the existence of the target table, related permissions, and schema compatibility, but does not create the target table. When the target table does not exist, the system only reports the check result; the actual table creation is performed when the rule creation is completed.

Step 4: Set Data Viewing Permissions

Use the permission settings of the data forwarding rule:

  • No restriction: All workspace members can view the forwarded data;
  • Only specified members can view: Only specified roles or members can view.

Step 5: Complete Rule Creation

When completing rule creation, the system rechecks the connection information and target table status, and handles them as follows:

The system checks the SQL user write permission and table schema compatibility again. If the check fails, the rule is still created and enabled, but a 【!】 prompt appears in the rule list. Fix the write permission or table schema issue according to the prompt.

The system creates the target table according to the system-managed schema of the current forwarded data type. If the table creation permission is missing or creation fails, the rule is still created and enabled, but a 【!】 prompt appears in the rule list. Fix the permission or table creation issue according to the prompt.

After the rule is created and enabled, data matching the rule is buffered into Parquet batches according to the data waiting time, and then loaded into the target table.

Data Waiting Time

The data waiting time affects the file buffering and batch loading frequency:

Option Use Case
15 minutes New data is available for querying in Lake more quickly; acceptable for more frequent loading tasks
30 minutes Balances timeliness and loading frequency
1 hour Default value, suitable for long-term archiving and batch analysis

Data forwarding does not write records in real time one by one. After the rule is enabled, wait for the first batch to be buffered and loaded.

Verify in TiDB Cloud Lake

  1. Wait for at least one data waiting period;
  2. Open TiDB Cloud Lake;
  3. Execute a read-only query using the Database, Warehouse, and Target Table in the rule;
  4. Check whether data matching the forwarding conditions has appeared.

You can first verify with a row-limited query:

SELECT *
FROM database_name.target_table
LIMIT 10;

Replace the Database and Target Table in the example with the actual values.

Configuration Result

After successful configuration, the following should be satisfied:

  • The rule status is Enabled;
  • Database and Warehouse match the Lake DSN;
  • The target table exists and is writable;
  • At least one Parquet batch has been loaded successfully;
  • Data matching the rule can be queried in TiDB Cloud Lake.

Notes

  • Dataset is not a required field for TiDB Cloud Lake connection and is not separately filled in the forwarding destination configuration; the scope of forwarded data is determined by the data type and filter conditions of the rule.
  • Changing the Target Table only affects subsequent loads; it does not migrate data already written to the old table.
  • After changing the TiDB Cloud Lake SQL user password, re-obtain the Lake DSN and edit the rule.
  • If rule loading fails, the system retains the failure reason and retries; after fixing permissions, connection, or table schema, you can re-execute.

If the test connection, rule creation, or loading fails, see TiDB Cloud Lake FAQ.