@clickzetta/cz-cli-darwin-arm64 0.3.94 → 0.3.96

package/bin/skills/lakehouse-doc-en/references/data_sharing_between_accounts_guide.md

@@ -0,0 +1,331 @@
+# Lakehouse Data Share — Cross-Account Data Sharing Getting Started Guide
+
+## 1. Solution Overview
+
+### 1.1 What is Data Share
+
+Data Share is a **zero-copy data sharing feature** provided by Lakehouse, enabling **cross-account or cross-service-instance** data authorization and usage within the same service region. Unlike traditional data replication or import solutions, Data Share does not require manually building data sync links between enterprises. Instead, it directly provides read-only access to source data through "authorization," with real-time updates.
+
+### 1.2 Core Advantages
+
+* **Zero-Copy, Low Latency**: No need for duplicate storage or periodic syncing between enterprises; data changes can be propagated to consumers in real time.
+* **Secure and Controllable**: Data is shared only in "read-only" form, and shared objects can be removed through permission control at any time.
+* **Easy to Scale**: Use Views to flexibly filter data columns or rows, achieving fine-grained sharing control.
+* **Reduced Costs**: Consumers do not need to pay for the storage of shared data; they only need to use their own compute resources to process the data.
+
+### 1.3 Use Cases
+
+* **Real-Time Sharing**: Company A shares transaction logs, user behavior data, etc., in real time with Company B, allowing Company B to query in real time without data sync.
+* **Multi-Party Collaborative Analysis**: Multiple partners analyze based on the same real-time data, reducing duplicate storage and transfer costs.
+* **Data Provider-Consumer Model**: Data providers open partial data to partners, while consumers obtain read-only data without bearing storage costs.
+
+## 2. How It Works
+
+The core working principle of Data Share is:
+
+1. **Data Remains with the Provider**: Data is always stored in the data provider's account.
+2. **Share Metadata**: Metadata and access permissions are shared with the consumer.
+3. **Access Control**: Consumers query data through controlled read-only access permissions.
+4. **Real-Time Updates**: After the provider's data is updated, consumers can immediately access the latest data.
+
+**Data Sharing Flow**:
+
+:-: ![](.topwrite/assets/image_1747735731291.png =322)
+
+The data provider retains full control and can update or remove shared data at any time. When source data is updated, the consumer immediately obtains the latest data without additional data sync operations.
+
+## 3. Prerequisites
+
+* Both the data provider and the data consumer must have Lakehouse instances.
+* Both parties must be within the same service region.
+* The data provider must have the "Instance Admin" (instance_admin) role permission.
+* Data sharing operations require the consumer to provide their service instance name.
+
+## 4. Hands-On Guide: Data Provider
+
+### 4.1 Creating a Share Object
+
+The data provider (data owner) needs to execute the following steps to create and configure a share object:
+
+#### 4.1.1 SQL Approach
+
+```sql
+-- Step 1: Create a Share object
+CREATE SHARE taxi_data_share;
+
+-- Step 2: Add a table to the Share object
+GRANT SELECT, READ METADATA ON TABLE demo_schema.taxi_zone_lookup TO SHARE taxi_data_share;
+
+-- Step 3: Specify the receiving instance
+ALTER SHARE taxi_data_share ADD INSTANCE target_instance_name;
+```
+
+#### 4.1.2 Web UI Approach
+
+1. Log in to the Lakehouse console with an account that has the "Instance Admin" role.
+2. In the left navigation, select **Data Management** -> **Data Share**, and click **+ New Share**.
+3. Fill in the share name (e.g., taxi_data_share) and select the workspace.
+4. Click **Add** to select the data object to share (e.g., taxi_zone_lookup table).
+5. Under **Receiving Instances**, click **Add** and enter the consumer's service instance name.
+6. Click **Confirm** to complete creation.
+
+:-: ![](.topwrite/assets/image_1747742254855.png =699)
+
+#### 4.1.3 Creating a View for Partial Data Sharing
+
+If you only need to share part of a table's data, you can first create a view and then share the view:
+
+```sql
+-- Create a dedicated schema for managing shared views
+CREATE SCHEMA share_views;
+
+-- Create a view with filtered data
+CREATE VIEW share_views.filtered_taxi_zones AS 
+SELECT * FROM demo_schema.taxi_zone_lookup 
+WHERE borough = 'Manhattan';
+
+-- Share the view
+GRANT SELECT, READ METADATA ON VIEW share_views.filtered_taxi_zones TO SHARE taxi_data_share;
+```
+
+### 4.2 Verifying the Share Configuration
+
+After creation and configuration, you can verify that the share is correctly configured using the following commands:
+
+```sql
+-- View all Share objects
+SHOW SHARES;
+
+-- View details of a specific Share
+DESC SHARE taxi_data_share;
+```
+
+Example output:
+
+```
+share_name       provider     provider_instance    provider_workspace  scope    to_instance        kind
+---------------------------------------------------------------------------------------------
+taxi_data_share  provider_instance_name  source_instance_name   source_workspace    PRIVATE  target_instance_name OUTBOUND
+```
+
+## 5. Hands-On Guide: Data Consumer
+
+The data consumer (receiver) needs to execute the following steps to access shared data:
+
+### 5.1 Viewing Available Shares
+
+#### 5.1.1 SQL Approach
+
+```sql
+-- View all visible Shares
+SHOW SHARES;
+```
+
+Example output (viewed from the consumer instance):
+
+```
+share_name       provider     provider_instance    provider_workspace  scope    to_instance  kind
+---------------------------------------------------------------------------------
+taxi_data_share  provider_instance_name  source_instance_name   source_workspace    PRIVATE             INBOUND
+```
+
+```sql
+-- View the data objects included in a Share
+DESC SHARE source_instance_name.taxi_data_share;
+```
+
+#### 5.1.2 Web UI Approach
+
+1. Log in to the data consumer's Lakehouse console.
+2. In the left navigation, select **Data Management** -> **Data Share**.
+3. Switch to the **Shared with Me** tab to see all received shares.
+
+:-: ![](.topwrite/assets/image_1747742432405.png =757)
+
+### 5.2 Creating a Local Schema Linked to Shared Data
+
+#### 5.2.1 SQL Approach
+
+```sql
+-- Create a local schema mapping to the shared data
+CREATE SCHEMA shared_taxi_data FROM SHARE source_instance_name.taxi_data_share.source_schema;
+```
+
+Where:
+
+* `shared_taxi_data`: The schema name created locally (customizable).
+* `source_instance_name`: The provider's instance name.
+* `taxi_data_share`: The share object name.
+* `source_schema`: The provider's source schema name.
+
+#### 5.2.2 Web UI Approach
+
+1. Find the target share object in the **Shared with Me** tab.
+2. Click the **Extract** button.
+3. In the popup, select the **Source Schema** and specify the schema name to be created locally.
+4. Click **Confirm** to complete the extraction.
+
+:-: ![](.topwrite/assets/image_1747742473685.png =373)
+
+### 5.3 Using Shared Data
+
+After creating the schema, the shared data appears in the local schema in read-only mode:
+
+```sql
+-- Query shared table data
+SELECT * FROM shared_taxi_data.taxi_zone_lookup LIMIT 5;
+
+-- Create an analysis view
+CREATE VIEW my_analysis AS
+SELECT borough, COUNT(*) as zone_count
+FROM shared_taxi_data.taxi_zone_lookup
+GROUP BY borough;
+
+-- Join with local data for analysis
+SELECT t.*, z.borough, z.zone
+FROM my_local_table t
+JOIN shared_taxi_data.taxi_zone_lookup z ON t.location_id = z.locationid;
+```
+
+## 6. Complete Example: Cross-Account Sharing of Taxi Zone Data
+
+### 6.1 Background Scenario
+
+Company A operates New York City taxi services and maintains the `taxi_zone_lookup` table, containing all zone information. Company B is an analytics company that needs access to this zone data for analysis but does not need to copy the data.
+
+### 6.2 Implementation Steps
+
+#### 6.2.1 View Source Table Data
+
+First, Company A views the structure of the table to be shared:
+
+```sql
+DESC TABLE EXTENDED demo_schema.taxi_zone_lookup;
+```
+
+The result shows the table structure as follows:
+
+```
+column_name  data_type  comment
+----------------------------------
+locationid   bigint     PULocationID or DOLocationID
+borough      string     
+zone         string     
+service_zone string     
+```
+
+The table contains 265 rows of data, recording NYC taxi zone information.
+
+#### 6.2.2 Create the Share Object
+
+Company A creates and configures the share object:
+
+```sql
+-- Create the Share object
+CREATE SHARE taxi_data_share;
+
+-- Add the table to the Share
+GRANT SELECT, READ METADATA ON TABLE demo_schema.taxi_zone_lookup TO SHARE taxi_data_share;
+
+-- Specify Company B's instance as the receiver
+ALTER SHARE taxi_data_share ADD INSTANCE target_instance_name;
+```
+
+#### 6.2.3 Verify the Share Configuration
+
+Company A verifies that the share configuration is correct:
+
+```sql
+DESC SHARE taxi_data_share;
+```
+
+The output result shows:
+
+```
+kind      name                                shared_on
+-------------------------------------------------------
+WORKSPACE <WS>                                2025-05-15 20:37:58.13
+SCHEMA    <WS>.demo_schema                    2025-05-15 20:38:02.018
+TABLE     <WS>.demo_schema.taxi_zone_lookup   2025-05-15 20:38:02.018
+```
+
+```sql
+SHOW SHARES;
+```
+
+The output includes the newly created share:
+
+```
+share_name       provider     provider_instance    provider_workspace  scope    to_instance        kind
+--------------------------------------------------------------------------------------
+taxi_data_share  provider_instance_name  source_instance_name   source_workspace    PRIVATE  target_instance_name OUTBOUND
+```
+
+#### 6.2.4 Company B Accesses the Shared Data
+
+Company B (instance target_instance_name) performs the following operations to use the shared data:
+
+```sql
+-- View available shares
+SHOW SHARES;
+
+-- View share contents
+DESC SHARE source_instance_name.taxi_data_share;
+
+-- Create a local schema
+CREATE SCHEMA taxi_data FROM SHARE source_instance_name.taxi_data_share.demo_schema;
+
+-- Query data
+SELECT borough, COUNT(*) as zone_count 
+FROM taxi_data.taxi_zone_lookup 
+GROUP BY borough 
+ORDER BY zone_count DESC;
+```
+
+Company B can query results and create reports without copying data. When Company A updates the original table data, Company B immediately sees the latest data.
+
+## 7. Best Practices
+
+### 7.1 Security Best Practices
+
+* **Use Views to Restrict Sensitive Data**: Filter rows or columns through views to ensure that only necessary data is shared.
+* **Regularly Audit Share Objects**: Use the `SHOW SHARES` and `DESC SHARE` commands to regularly check share contents.
+* **Principle of Least Privilege**: Grant only the necessary permissions (SELECT and READ METADATA).
+* **Do Not Share Credentials**: Strictly prohibit sharing administrator accounts; use Data Share for secure data sharing.
+
+### 7.2 Performance and Cost Optimization
+
+* **Use Filtered Views**: Limit data volume through views to improve query performance.
+* **Pay Attention to Timezone Settings**: Ensure that the provider and consumer use the same timezone settings to avoid time-related query issues.
+
+## 8. FAQ and Troubleshooting
+
+### Issue 1: Unable to See Shared Data
+
+**Possible Causes**:
+* Incorrect permission configuration, such as not granting the `READ METADATA` permission.
+* Incorrect instance name entry.
+
+**Solutions**:
+* The provider should use the `SHOW GRANTS TO SHARE` command to check whether the objects in the share have been granted both `SELECT` and `READ METADATA` permissions.
+* Verify that the instance name is correct.
+
+### Issue 2: Unable to Query Shared Data
+
+**Possible Causes**:
+* Missing SELECT permission.
+
+**Solutions**:
+
+```sql
+GRANT SELECT ON TABLE <table_name> TO SHARE <share_name>;
+```
+
+## 9. Reference Information
+
+* [Data Sharing](datasharing.md)
+* [Cross-Enterprise Real-Time Data Sharing](quickstart_datashare_between_companies.md)
+* [CREATE SHARE Syntax](create-share.md)
+* [CREATE SCHEMA FROM SHARE Syntax](create-schema-from-share.md)
+
+^

package/bin/skills/lakehouse-doc-en/references/data_sharing_guide.md

@@ -0,0 +1,117 @@
+# Data Sharing
+
+Data Sharing is Lakehouse's zero-copy cross-instance data authorization feature — you define the tables or views to share, and the recipient instance reads your original data directly, with no copying and no sync delay. **Only supported between instances within the same cloud and service region; cross-cloud or cross-region sharing is not supported.**
+
+---
+
+## I Want to Share Data with Another Account
+
+Three steps: Create a Share → Grant data objects → Specify recipient instances. Both SQL and the Studio UI support the full workflow — choose whichever you prefer.
+
+| Scenario | Approach | Reference |
+|------|------|---------|
+| Share an entire table with another instance (SQL) | CREATE SHARE + GRANT SELECT + ALTER SHARE ADD INSTANCE | [Cross-Account Data Sharing Guide](data_sharing_between_accounts_guide.md) |
+| Share an entire table with another instance (UI) | Data Management → Data Sharing → + New Share | Via Studio |
+| Share only certain rows or columns from a table | Create a View to filter data first, then share the View | [Cross-Enterprise Real-Time Data Sharing](quickstart_datashare_between_companies.md) |
+| Share all tables under a Schema | GRANT SELECT ON ALL TABLES IN SCHEMA | [Data Sharing SQL Reference](data-sharing.md) |
+
+> ⚠️ Creating a Share requires the `instance_admin` role. Adding data objects to a Share requires the `workspace_admin` role, or both `SELECT` and `READ METADATA` on the table/view with `WITH GRANT OPTION`.
+
+> ⚠️ A single Share can contain at most 1000 table or view objects, and can only include data objects from the same workspace.
+
+---
+
+## I Want to Receive and Use Data Shared with Me
+
+The consumer needs to first view the received Share, then create a local read-only Schema mapped to the shared data.
+
+| Scenario | Approach | Reference |
+|------|------|---------|
+| View which shares I have received | `SHOW SHARES` (look for `INBOUND` type) or Studio "Shared with Me" tab | [Data Sharing](data-sharing.md) |
+| View which data objects are in a share | DESC SHARE <provider>.<share_name> | [DESC SHARE](desc-share.md) |
+| Create a local Schema to access shared data | CREATE SCHEMA ... FROM SHARE <provider>.<share>.<schema> | [Cross-Account Data Sharing Guide](data_sharing_between_accounts_guide.md) |
+| Extract data via Studio UI | Data Sharing → Shared with Me → Click "Extract" | [Data Sharing](data-sharing.md) |
+
+> ⚠️ Schemas created via Share are read-only — you cannot create tables, views, or other objects in them, and write operations on shared data are not allowed.
+
+> ⚠️ Re-sharing received data is prohibited. Consumers can copy data via `CREATE TABLE AS SELECT`; providers should carefully consider the scope of what they share.
+
+---
+
+## I Want to Use the Studio UI
+
+Studio provides a complete data sharing management interface, suitable for users unfamiliar with SQL or for routine management operations.
+
+| Operation | Path | Required Role |
+|------|------|---------|
+| Create a new share | Data Management → Data Sharing → + New Share | `instance_admin` |
+| View shares I have sent | Data Management → Data Sharing → My Shares | `instance_admin` or `workspace_admin` |
+| Add/remove shared data objects | Click share name → Edit | `workspace_admin` (workspace owning the share) |
+| Add/remove recipient instances | Click share name → Recipient Instances → Add/Remove | `instance_admin` |
+| View shares received | Data Management → Data Sharing → Shared with Me | `instance_admin` or `workspace_admin` |
+| Extract shared data (consumer) | Shared with Me → Click "Extract" | `workspace_admin` (target workspace) |
+
+> The consumer needs to provide their service instance name to the provider. The instance name can be found in the top-right corner of the homepage or in the service instance URL.
+
+---
+
+## I Want to Use SQL Commands
+
+The complete SQL workflow, suitable for automation scripts or scenarios requiring fine-grained control.
+
+| Operation | SQL Command | Reference |
+|------|---------|---------|
+| Create a Share | `CREATE SHARE <name>` | [CREATE SHARE](create-share.md) |
+| Grant a table to a Share | GRANT SELECT, READ METADATA ON TABLE &lt;t&gt; TO SHARE &lt;s&gt; | [GRANT TO SHARE](grant-to-share.md) |
+| Grant a view to a Share | GRANT SELECT, READ METADATA ON VIEW &lt;v&gt; TO SHARE &lt;s&gt; | [GRANT TO SHARE](grant-to-share.md) |
+| Grant all tables in a Schema | GRANT ... ON ALL TABLES IN SCHEMA &lt;s&gt; TO SHARE &lt;share&gt; | [GRANT TO SHARE](grant-to-share.md) |
+| Add a recipient instance | ALTER SHARE &lt;s&gt; ADD INSTANCE &lt;instance&gt; | [ALTER SHARE](alter-share.md) |
+| Remove a recipient instance | ALTER SHARE &lt;s&gt; REMOVE INSTANCE &lt;instance&gt; | [ALTER SHARE](alter-share.md) |
+| Revoke data object authorization | REVOKE SELECT, READ METADATA ON TABLE &lt;t&gt; FROM SHARE &lt;s&gt; | [REVOKE FROM SHARE](revoke-from-share.md) |
+| Consumer creates a read-only Schema | CREATE SCHEMA ... FROM SHARE &lt;provider&gt;.&lt;share&gt;.&lt;schema&gt; | [Data Sharing](data-sharing.md) |
+| Delete a Share | `DROP SHARE <name>` | [DROP SHARE](drop-share.md) |
+
+> ⚠️ `GRANT SELECT ON ALL TABLES IN SCHEMA` automatically includes tables **created in the future** under that Schema — use with caution.
+
+---
+
+## I Want to View and Manage Existing Shares
+
+| Scenario | SQL | Notes |
+|------|-----|------|
+| View all Shares (including received) | `SHOW SHARES` | `OUTBOUND` = shares I sent; `INBOUND` = shares I received |
+| View details of a specific Share | `DESC SHARE <name>` | Shows included data objects and recipient instances |
+| View authorization details of a Share | SHOW GRANTS TO SHARE &lt;name&gt; | Use when troubleshooting permission configuration |
+| Delete a Share | `DROP SHARE <name>` | Takes effect immediately; consumers lose access instantly and it cannot be undone |
+
+---
+
+## Not Sure How to Proceed?
+
+```
+What is my role?
+├── Data Provider (I have data and want to share it)
+│   ├── Share an entire table → CREATE SHARE + GRANT SELECT ON TABLE
+│   ├── Share partial data (row/column filter) → Create a View first, then GRANT SELECT ON VIEW
+│   └── Share an entire Schema → GRANT SELECT ON ALL TABLES IN SCHEMA (note: includes future tables)
+│
+└── Data Consumer (someone shared data with me)
+    ├── First confirm what was received → SHOW SHARES (look for INBOUND)
+    ├── View share contents → DESC SHARE <provider_instance>.<share_name>
+    └── Create a local access entry → CREATE SCHEMA FROM SHARE
+
+Preferred method?
+├── Have SQL access → Refer to the SQL command table above
+└── Prefer UI → Studio Data Management → Data Sharing
+```
+
+---
+
+## Related Documentation
+
+- [Data Sharing Concepts](data-sharing-concept.md) — Core principles, Share object structure, permission model
+- [Data Sharing Complete Reference](data-sharing.md) — Full operation steps and permission details
+- [Cross-Account Data Sharing Guide](data_sharing_between_accounts_guide.md) — End-to-end operation example
+- [Cross-Enterprise Real-Time Data Sharing](quickstart_datashare_between_companies.md) — Complete case with view filtering
+- [Data Sharing SQL Guide](sql_share_guide.md) — SQL command reference
+- [CREATE SHARE](create-share.md) · [ALTER SHARE](alter-share.md) · [GRANT TO SHARE](grant-to-share.md) · [REVOKE FROM SHARE](revoke-from-share.md) · [SHOW SHARES](show-shares.md) · [DESC SHARE](desc-share.md) · [DROP SHARE](drop-share.md)

package/bin/skills/lakehouse-doc-en/references/data_sync.md

@@ -0,0 +1,6 @@
+* [Overview](data-integration-intro.md)
+* [Data Source Support Range](datasources.md)
+* [Configuring Data Source](config-datasource.md)
+* [Synchronization Task Development](batch_sync.md)
+
+^

package/bin/skills/lakehouse-doc-en/references/data_transfer_datalake.md

@@ -0,0 +1 @@
+# Data Migration to Data Lake

package/bin/skills/lakehouse-doc-en/references/data_visualization.md

@@ -0,0 +1,96 @@
+# Data Visualization
+
+This article explains how to use charts in Singdata to visualize SQL worksheet results. Charts help you communicate patterns in your data, spot anomalies, and make more informed decisions.
+
+Currently supported chart types:
+
+* Line chart
+* Bar chart
+
+## Creating a Chart
+
+You can generate a chart from query results while running queries in development.
+
+1. Click Development or Workspace, then create or select a SQL task.
+2. Run a SELECT query.
+3. In the query results area, click the "Chart" option under the Data tab.
+
+## Configuring a Chart
+
+After clicking "Chart" to visualize the worksheet results, you need to select the required fields based on the chart type before the visualization area will display a chart.
+
+Hover over the chart to view detailed information for each data point. For example, you can view results as a line chart:
+
+![](.topwrite/assets/image_1742200992399.png =757)
+
+^
+
+In the "Settings" panel on the right side of the visualization area, configure what to display:
+
+1. Chart type: Line chart or Bar chart.
+
+2. X-axis field: Defines the values shown along the trend axis.
+
+   Note: Aggregation by the selected X-axis field is not currently supported.
+
+3. Y-axis field:
+
+![](.topwrite/assets/image_1742201014009.png =347)
+
+The Y-axis supports aggregate functions to derive a single value from multiple data points. The available aggregation methods are:
+
+* Total: sum
+* Count: count
+* Average: average
+* Maximum: maximum
+* Minimum: minimum
+
+4. Add Y-axis fields or grouping.
+
+You can add up to 10 Y-axis fields for analysis in the same chart.
+
+Adding a group applies a GROUP BY operation to the Y-axis fields already added.
+
+Note: Grouping is only available when there is exactly one Y-axis field, and only one grouping field can be selected.
+
+## Known Limitations
+
+When there are many X-axis values and you need to view a specific data point on a trend, it is recommended to narrow the range on the chart to see accurate data points.
+
+For example, in the chart below, the accurate value is shown only when hovering over the visualization and the specific timestamp information appears.
+
+![](.topwrite/assets/image_1742201080540.png =387)
+
+^
+
+## Use Cases
+
+### Time-based Trend Charts
+
+**Scenario 1**: To preserve time span differences, the result data type should be a timestamp type. For example:
+
+* `order_date` is a timestamp type. The trend chart will automatically display data according to the actual time intervals, which more accurately reflects the "trend."
+
+```
+select order_date, count(*) as c from big_data_table group by order_date;
+```
+
+![](.topwrite/assets/20250317-190632.jpeg =617)
+
+^
+
+![](.topwrite/assets/20250317-190714.jpeg =607)
+
+^
+
+![](.topwrite/assets/20250317-190759.jpeg =608)
+
+^
+
+**Scenario 2**: To **ignore** time span differences and keep only the specific result data points, cast the result to a string (`order_date::string`):
+
+```
+select order_date::string, count(*) as c from big_data_table group by order_date;
+```
+
+![](.topwrite/assets/20250317-190854.jpeg =654)

package/bin/skills/lakehouse-doc-en/references/dataagent.md

@@ -0,0 +1,80 @@
+## What is Data Agent
+
+Data Agent is an AI-powered agent built on top of Singdata Lakehouse and Studio. It covers the full lifecycle of "development, operations, and governance" and implements intelligent platform upgrades through an Agentic AIOps philosophy — transforming data development from "people operating the platform" to "people directing the agent."
+
+Data Agent is not just a tool that makes data teams more productive. It is a **data intelligence collaboration system** that enables everyone in the company to work with data.
+
+## User Value
+
+* **Higher productivity: reclaim 80% of your time for what truly matters**
+
+From "3 days finding data, 2 days doing analysis" to "30 seconds to get data, 4 days of deep insight" — data engineers stop doing repetitive grunt work and focus on architecture design; data analysts stop pulling data and focus on business insights; business users go from waiting for reports to self-service analysis and real-time decision-making.
+
+* **Expanded capabilities: do what you always wanted but couldn't**
+
+Before: business users who wanted to analyze data had to depend on data engineers or analysts' schedules, waiting for data to be delivered before any analysis could begin. In exploratory analysis scenarios especially, the metrics and approach often shift constantly — by the time the data arrives, the metrics may already be obsolete.
+
+Now: business users can create tasks and analyze data just by saying what they need — operations staff without SQL knowledge can build daily report tasks themselves, product managers without coding skills can create user analysis workflows, sales teams without technical backgrounds can generate performance dashboards. The data platform shifts from "requires specialized skills to use effectively" to "basic familiarity is enough to get full value," lowering the technical barrier.
+
+* **Lower learning curve: get up to speed on a new data platform with ease**
+
+You only need to focus on your goal. There's no need to learn complex product operations or underlying concepts — just ask in natural language and the agent handles the rest.
+
+## How to Access
+
+Click "Data Agent" at the top of the menu bar to open the feature.
+
+Describe your needs directly to the agent in natural language and let it operate the platform for you.
+
+For example:
+
+* Show me what tables exist in the current schema
+* What tasks do I currently have running
+
+## Best Practice Scenarios
+
+### Scenario 1: ETL Development
+
+> **What engineers really say**: "I spend more time communicating and hunting down existing work than actually writing code."
+
+**Communication overhead** Business requirements are naturally vague. A single request often takes 3–5 rounds of back-and-forth to align on metric definitions, time ranges, and filter conditions — most of the time goes to communication, not development. The root cause: translating "business language" into "development specs" is entirely manual.
+
+**High cost of understanding standards** Each business domain has its own layering rules, naming conventions, and field standards, scattered across various documents. Engineers must "catch up" before taking on any new requirement, and even minor oversights get flagged in reviews, keeping rework costs high.
+
+> Example prompt:
+> I need to design a Medallion architecture data warehouse based on this metric requirements spec to support GMV analysis. I've already planned the tables for each layer: [Bronze layer] xxx [Silver layer] xxx [Gold layer] xxx. Based on this table list, please generate a data warehouse modeling standards document.
+
+![](/.topwrite/assets/image_1779715425568.png)
+
+### Scenario 2: Ad-hoc Data Retrieval
+
+**Everything waits in the queue** Exploratory analysis, market research, and other ad-hoc requests are naturally lower priority and get perpetually pushed aside by formal requests. By the time the data finally arrives, the decision window has often closed and the business has already fallen behind the market. The core problem: ad-hoc analysis has no self-service path — it must go through the data team, which simply doesn't have the bandwidth to continuously handle low-priority requests.
+
+> Example prompt:
+> Query brazilianecommerce.olist_orders and count orders by day.
+
+![](/.topwrite/assets/image_1779715858474.png)
+
+### Scenario 3: Day-to-day Operations
+
+Daily task operations are the most critical routine work on an enterprise data platform. Operations teams must continuously track the execution status of daily scheduled tasks and respond quickly when tasks fail or are delayed — rapidly identifying root causes, fixing tasks, and preventing failures from cascading down the dependency chain to affect business operations.
+
+**Hard to get a full picture of tasks** The platform currently lacks an operations dashboard, so operations staff can only manually filter through lists one dimension at a time. Even with a dashboard, flexible and varied reporting needs are hard to meet. For example:
+
+* Wanting to see "failure status of tasks containing a certain keyword" — the dashboard can't support this
+* Wanting to know "which task types had the highest failure rate in the past week" — requires manually exporting data and then analyzing it
+* Wanting to count "the number of unpublished SQL tasks under a specific owner" — multi-condition combinations can only be done by manually filtering one by one
+
+**No clear path when instances fail** After discovering a failed instance, the logs don't explain the root cause; once the root cause is understood, it's unclear how to fix it. You end up asking around, the fix cycle drags on, and the business impact continues.
+
+**Uncontrollable blast radius, chain reactions** When an upstream task fails, the chain reaction often spreads quickly, with large numbers of downstream tasks becoming blocked or failing. The platform provides a task lineage feature, but it's severely inefficient in urgent failure scenarios:
+
+* **Cumbersome path**: requires logging into Studio → locating the task → opening the lineage graph → manually expanding layer by layer — multiple steps just to see the full chain
+* **No quantification**: only a visual dependency graph, with no way to directly get key numbers like "how many downstream tasks were affected" or "how many levels were impacted"
+* **Poor timeliness**: during early-morning alerts and emergency fixes, the cumbersome query steps waste precious response time that's already in short supply
+
+> Example prompts:
+> Please help me analyze which instances failed in the past week.
+> For the task with instance ID xxx, what was the failure reason and which downstream tasks were affected?
+
+![](/.topwrite/assets/image_1779715663695.png)