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

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

@@ -0,0 +1,393 @@
+# Singdata Lakehouse MCP Server Use Case: Cost Anomaly Analysis and Troubleshooting
+
+## Core Q&A Process Demo
+
+### User Question Sequence
+
+```
+👤 User: "Analyze the data in sys.information_schema.instance_usage table, check the costs for September 4th and September 5th"
+
+🤖 MCP Server: [Auto analyze table structure] → [Generate intelligent query] → [Output cost report]
+   Found: September 4 cost ¥85.77, September 5 cost ¥66.65, mainly from GP compute cluster
+
+👤 User: "Why are the costs so high on these two days?"
+
+🤖 MCP Server: [Historical data comparison] → [Anomaly pattern recognition] → [Trend analysis]
+   Found: Normal daily cost ¥1-6, surged 15x during the anomaly period, GP cluster usage duration abnormal
+
+👤 User: "Check which instance and which workspace's cluster"
+
+🤖 MCP Server: [Multi-dimensional analysis] → [Responsible party identification] → [Job history tracking]
+   Found: Instance 270397's quick_start workspace, caused by frequent refresh of the mcp_test_daily_summary dynamic table
+```
+
+### Key Insights
+
+* **Issue location time**: <= '2025-09-08'
+   GROUP BY date(measurement_start)
+   ORDER BY usage_date
+   ```
+
+2. **Anomaly Pattern Recognition**
+
+**Historical Cost Trend Analysis**:
+
+| Time Period     | Average Daily Cost | Cost Range           | Status                    |
+| --------------- | ------------------ | -------------------- | ------------------------- |
+| Aug 25-Sep 2    | ¥1.8               | ¥0.99-¥6.06          | ✅ Normal baseline        |
+| Sep 3           | ¥25.13             | -                    | ⚠️ First anomaly         |
+| **Sep 4-5**     | **¥76.21**         | **¥66.65-¥85.77**    | 🚨 **Severe anomaly**     |
+| After Sep 6     | ¥0.73              | ¥0.53-¥1.05          | ✅ Returned to normal     |
+
+3. **Usage Pattern Change Analysis**
+
+   ```sql
+   SELECT 
+       date(measurement_start) as usage_date,
+       sku_name,
+       count(*) as record_count,
+       sum(measurements_consumption) as total_consumption_hours,
+       avg(measurements_consumption) as avg_consumption_per_record,
+       sum(total_after_discount) as total_cost
+   FROM sys.information_schema.instance_usage 
+   WHERE sku_category = 'compute'
+   GROUP BY date(measurement_start), sku_name
+   ```
+
+**GP Cluster Usage Pattern Comparison**:
+
+| Date         | Average Hourly Consumption | Record Count     | Total Consumption Duration | Per-Instance Cost |
+| ------------ | -------------------------- | ---------------- | -------------------------- | ----------------- |
+| Sep 1-2      | 0.03-0.04 hours            | 14-20 records    | 0.37-0.76 hours            | ¥1-3              |
+| **Sep 4**    | **0.57 hours**             | **42 records**   | **24.05 hours**            | **¥3.5**          |
+| **Sep 5**    | **0.58 hours**             | **32 records**   | **18.71 hours**            | **¥3.5**          |
+| After Sep 6  | 0.02 hours                 | 12 records       | 0.20 hours                 | ¥0.7              |
+
+**Key Findings**:
+
+* GP cluster changed from short query mode to long-running mode
+* Hourly consumption duration increased **15x** (0.04 → 0.57 hours)
+* Nearly full 1-hour billing, indicating the cluster was running continuously
+
+### Step 3: Precise Responsible Party Identification
+
+**User continues to ask**:
+
+```
+Check which instance and which workspace's cluster
+```
+
+**MCP Server Multi-Dimensional Analysis**:
+
+1. **Instance and Workspace Cost Distribution**
+
+   ```sql
+   SELECT 
+       instance_id,
+       workspace_name,
+       sku_name,
+       sum(total_after_discount) as total_cost
+   FROM sys.information_schema.instance_usage 
+   WHERE date(measurement_start) IN ('2025-09-04', '2025-09-05')
+     AND sku_category = 'compute'
+   GROUP BY instance_id, workspace_name, sku_name
+   ORDER BY total_cost DESC
+   ```
+
+**Responsible Party Analysis Results**:
+
+| Instance ID   | Workspace                       | Sep 4 Cost     | Sep 5 Cost     | Anomaly Severity               |
+| ------------- | ------------------------------- | -------------- | -------------- | ------------------------------ |
+| **270397**    | **quick\_start**                | **¥83.48**     | **¥64.77**     | 🚨 **Primary responsible party** |
+| 270397        | lakehouse\_quick\_experience    | ¥0.71          | ¥0.71          | ✅ Normal                      |
+| 270397        | ns227206                        | ¥0.17          | ¥0.17          | ✅ Normal                      |
+
+2. **Specific Cluster Usage Details**
+
+   ```sql
+   SELECT 
+       date(measurement_start) as usage_date,
+       hour(measurement_start) as usage_hour,
+       measurements_consumption,
+       amount
+   FROM sys.information_schema.instance_usage 
+   WHERE workspace_name = 'quick_start' 
+     AND sku_name = 'GP Compute Cluster'
+     AND amount >
+
+**GP Cluster Runtime Analysis**:
+
+**Sep 4 Anomaly Pattern**:
+
+* **00:00-23:59**: 24 hours continuous runtime
+* **Hourly consumption**: ~1.00 hours (nearly full hourly billing)
+* **Per-hour cost**: Around ¥3.5
+
+**Sep 5 Anomaly Pattern**:
+
+* **00:00-18:59**: 19 hours continuous runtime
+* **Cost pattern**: Similarly close to full hourly billing
+
+**Key Findings**:
+
+* Issue identified in the GP cluster of `quick_start` workspace
+* Cluster shows nearly 24-hour continuous runtime
+* **Not** a normal short query pattern
+
+### Step 4: Root Cause Tracking
+
+**MCP Server Auto Deep Investigation**:
+
+1. **Job History Analysis**
+
+   <= '2025-09-06 23:59:59'
+   ```
+
+**Normal Period Job Characteristics**:
+
+* Query execution time: seconds to minutes
+* Cluster auto-suspend: quick release after query completion
+* Cost pattern: billed by actual usage time
+
+## Root Cause Deep Analysis
+
+### Technical Analysis
+
+**1. Dynamic Table Configuration Error**
+
+```sql
+-- Problematic configuration (speculated)
+CREATE DYNAMIC TABLE mcp_test_daily_summary
+REFRESH_INTERVAL = '5 MINUTES'  -- ❌ Too frequent
+AS SELECT ...
+```
+
+**2. Cluster Resource Management Failure**
+
+* **Normal mode**: Query completes → Cluster idle → Auto-suspend (within minutes)
+* **Anomaly mode**: Query completes → New query after 5 minutes → Cluster stays active → Cannot suspend
+
+**3. Billing Calculation Logic**
+
+* **Hourly billing**: GP cluster billed by usage duration, ¥3.5/hour
+* **Minimum billing unit**: Even if used for minutes, the active state accumulates billing time
+* **Cumulative effect**: 5-minute refresh interval → Nearly full 24-hour billing
+
+### Business Impact Assessment
+
+**1. Direct Cost Loss**
+
+* **Anomaly period**: 2-day total cost ¥152.42
+* **Normal period**: 2-day expected cost ¥2-12
+* **Direct loss**: ¥140-150
+
+**2. Potential Risks**
+
+* **If not discovered in time**: Daily additional cost ¥80+
+* **Monthly impact**: Could generate ¥2400+ additional costs
+* **Resource waste**: Cluster resources not effectively utilized
+
+**3. Systemic Issues**
+
+* **Configuration management**: Dynamic table refresh policy lacks reasonableness checks
+* **Monitoring alerts**: Cost anomalies not discovered in time
+* **Resource optimization**: Cluster auto-management policy needs optimization
+
+## Solutions and Best Practices
+
+### Immediate Remediation Measures
+
+**1. Dynamic Table Configuration Correction**
+
+```sql
+-- Check current configuration
+DESC DYNAMIC TABLE mcp_test_daily_summary;
+
+-- Option 1: Adjust refresh interval (recommended)
+ALTER DYNAMIC TABLE mcp_test_daily_summary 
+SET REFRESH_INTERVAL = '1 HOUR';
+
+-- Option 2: Adjust based on business requirements
+ALTER DYNAMIC TABLE mcp_test_daily_summary 
+SET REFRESH_INTERVAL = '4 HOURS';  -- or other reasonable intervals
+
+-- Option 3: Suspend dynamic table (emergency)
+ALTER DYNAMIC TABLE mcp_test_daily_summary SUSPEND;
+```
+
+**2. Cluster Configuration Optimization**
+
+```sql
+-- Check cluster auto-suspend settings
+SHOW VIRTUAL_CLUSTERS;
+
+-- Ensure reasonable auto-suspend time
+ALTER VIRTUAL_CLUSTER your_gp_cluster 
+SET AUTO_SUSPEND_IN_SECOND = 300;  -- 5-minute auto-suspend
+```
+
+### Preventive Measures
+
+**1. Monitoring and Alerting**
+
+```sql
+-- Create cost monitoring view
+CREATE VIEW daily_cost_monitor AS
+SELECT 
+    date(measurement_start) as cost_date,
+    sum(total_after_discount) as daily_cost,
+    CASE 
+        WHEN sum(total_after_discount) >
+
+**2. Dynamic Table Best Practices**
+
+* **Refresh interval recommendation**: Set based on data update frequency, minimum no less than 30 minutes
+* **Resource consideration**: Evaluate refresh impact on compute resources
+* **Business alignment**: Refresh frequency should match actual business requirements
+
+**3. Resource Management Strategy**
+
+* **Cluster separation**: Separate scheduled tasks and interactive queries into different clusters
+* **Time window**: Execute resource-intensive tasks during off-peak hours
+* **Cost budget**: Set workspace-level cost budget and alerts
+
+## Case Value and Technical Highlights
+
+### 1. MCP Server Intelligent Analysis Capability
+
+**Natural Language Understanding**
+
+* No need for users to master complex SQL syntax
+* Intelligently understand analysis intent and convert to precise queries
+* Support multi-turn conversations, progressively dig deeper into issues
+
+**Automated Data Analysis**
+
+```
+User intent: "Analyze costs" → Auto table structure identification → Intelligent query generation → Multi-dimensional data correlation → Anomaly pattern recognition → Visualized result presentation
+```
+
+**Context Memory Capability**
+
+* Remember previous analysis results
+* Conduct deeper investigation based on existing findings
+* Maintain analytical logic continuity
+
+### 2. Systematic Approach to Troubleshooting
+
+**Hierarchical Analysis Framework**
+
+1. **Overview layer**: Overall cost trend identification
+2. **Decomposition layer**: Break down cost composition by dimensions
+3. **Localization layer**: Precisely identify responsible parties
+4. **Root cause layer**: Trace to specific technical causes
+
+**Multi-Dimensional Correlation Analysis**
+
+* Time dimension: Historical comparison, trend analysis
+* Spatial dimension: Instance, workspace, cluster
+* Business dimension: Job type, execution frequency
+* Technical dimension: Resource usage, configuration parameters
+
+### 3. Practical Value
+
+**Rapid Response Capability**
+
+* **Issue discovery to localization**: < 5 minutes
+* **Solution output**: Immediately executable SQL commands
+* **Effect verification**: Real-time review of fix results
+
+**Economic Value**
+
+* **Direct savings**: ¥80+/day cost savings
+* **Avoid losses**: Prevent ongoing losses from long-term configuration errors
+* **Efficiency improvement**: Significantly reduce manual investigation time
+
+**Knowledge Accumulation**
+
+* **Reusable process**: Analysis method applicable to other similar issues
+* **Best practices**: Form standardized troubleshooting processes
+* **Prevention guide**: Provide experience reference for other users
+
+## Result Verification and Effectiveness Evaluation
+
+### Resolution Effectiveness Confirmation
+
+**Cost Recovery Verification**
+
+```sql
+-- Create cost monitoring view
+CREATE VIEW daily_cost_monitor AS
+SELECT 
+    date(measurement_start) as cost_date,
+    sum(total_after_discount) as daily_cost,
+    CASE 
+        WHEN sum(total_after_discount) >
+
+**Results**:
+
+* Sep 6: ¥1.05 ✅ Returned to normal
+* Sep 7: ¥0.96 ✅ Continuously normal
+* Sep 8: ¥0.53 ✅ Further optimized
+
+**Cluster Usage Pattern Recovery**
+
+* Average usage duration per instance: 0.02 hours (returned to normal short query mode)
+* Per-instance cost: ¥0.02-0.7 (returned to reasonable range)
+* Cluster auto-suspend: Working normally
+
+### Lessons Learned
+
+**Technical Lessons**
+
+1. **Dynamic table design**: Refresh interval should balance business needs and cost considerations
+2. **Resource monitoring**: Establish multi-level cost and resource usage monitoring
+3. **Configuration management**: Important configuration changes should be evaluated and tested
+
+**Operations Lessons**
+
+1. **Timely discovery**: Establish automated anomaly detection mechanisms
+2. **Rapid localization**: Master systematic troubleshooting methods
+3. **Prevention first**: Avoid similar issues through best practices
+
+**Business Lessons**
+
+1. **Cost awareness**: Technical decisions should consider cost implications
+2. **Requirement assessment**: Balance between functional requirements and resource consumption
+3. **Continuous optimization**: Regularly review and optimize resource usage
+
+## Summary
+
+This real-world case perfectly demonstrates the core value of Singdata Lakehouse MCP Server in enterprise-level data platform operations:
+
+### 🚀 Technological Innovation
+
+* **AI-driven natural language analysis**: Making complex data analysis simple and intuitive
+* **Intelligent issue diagnosis**: Automatically identify anomaly patterns and root causes
+* **Multi-dimensional correlation analysis**: Quickly extract key information from massive data
+
+### 💰 Business Value
+
+* **Immediate cost savings**: Single case save ¥80+/day
+* **Significant operations efficiency improvement**: Troubleshooting time reduced from hours to minutes
+* **Risk prevention capability**: Avoid long-term losses from configuration errors
+
+### 🛠️ Practicality
+
+* **Zero barrier usage**: No SQL knowledge needed, natural language completes complex analysis
+* **Immediately executable solutions**: Not just diagnosing issues, but providing specific solutions
+* **Knowledge transfer**: Analysis processes and methods reusable for similar scenarios
+
+Through this case, we see the enormous potential of AI technology in data platform operations. Singdata Lakehouse MCP Server is not just a tool, but an intelligent operations partner, helping users quickly locate issues, optimize costs, and improve efficiency in complex data environments.
+
+***
+
+*This case is based on real user scenarios with anonymized data, demonstrating the practical value of Singdata Lakehouse MCP Server in cost management, troubleshooting, and operations optimization.*
+
+^
+
+## Reference
+
+[Instance-level Information Schema](instance-information_schema.md)
+
+[Dynamic Table](dynamic-table.md)

package/bin/skills/lakehouse-doc-en/references/chart-auto-refresh-guide.md

@@ -0,0 +1,30 @@
+^
+
+# Chart Auto-Refresh Settings
+
+## Feature Overview
+
+Charts in dashboards support setting an auto-refresh interval. The system will automatically update chart data at the set time interval, ensuring the dashboard always displays the latest information without requiring manual refresh by users.
+
+## Applicable Scenarios
+
+* Business daily report dashboards: Set to refresh every 24 hours, automatically updating yesterday's data each day
+
+* Real-time monitoring dashboards: Set a shorter refresh interval to reflect business changes promptly
+
+* Weekly/monthly report dashboards: Set a longer refresh interval to reduce unnecessary query overhead
+
+## How to Use
+
+| Step       | Description                                       | Screenshot                                             |
+| ---------- | ------------------------------------------------- | ------------------------------------------------------ |
+| Select chart settings | Click "Dashboard" and select the chart you want to configure | ![](/.topwrite/assets/image_1779185744966.png =237) |
+| Set refresh interval | Default refresh every 24 hours; adjustable based on business needs | ![](/.topwrite/assets/image_1779185773256.png =247) |
+
+## **Notes**
+
+1\. Auto-refresh is configured independently for each chart; different charts in the same dashboard can have different refresh intervals
+
+2\. During refresh, the system re-executes the query corresponding to that chart to retrieve the latest data
+
+3\. It is recommended to set refresh intervals reasonably based on data update frequency, avoiding excessively frequent refreshes that cause unnecessary resource consumption

package/bin/skills/lakehouse-doc-en/references/clickzetta-sample-data.md

@@ -0,0 +1,239 @@
+# Built-in Sample Datasets
+
+`clickzetta_sample_data` is a public dataset built into Singdata Lakehouse via the data sharing mechanism. It is available out of the box for every tenant — no application or import required, and it does not count against your storage quota.
+
+Query it directly in SQL using three-part naming:
+
+```sql
+SELECT * FROM clickzetta_sample_data.tpch_100g.orders LIMIT 10;
+```
+
+It contains 5 schemas covering performance benchmarking, business analytics practice, and AI vector retrieval:
+
+| Schema | Data Content | Scale |
+|--------|-------------|-------|
+| `tpch_100g` | TPC-H standard benchmark, supply-chain order data | 100 GB, 600 million rows in lineitem |
+| `tpcds_10tb` | TPC-DS standard benchmark, retail multi-channel sales data | 10 TB, 28.8 billion rows in store_sales |
+| `ecommerce_events_history` | E-commerce user behavior event stream | 110 million rows in history table, 370 million rows in live table |
+| `nyc_taxi_tripdata` | New York City ride-hailing trip records | 1.49 billion rows |
+| `clickzetta_doc_kb` | Singdata product documentation vector knowledge base | Contains 1024-dimensional embeddings |
+
+## tpch_100g
+
+**Data source**: [TPC-H](https://www.tpc.org/tpch/) is the industry-standard database benchmark, simulating a supply-chain scenario with 8 tables covering orders, parts, suppliers, customers, and more.
+
+**Scale**: 100 GB, 8 tables total.
+
+| Table | Row Count | Description |
+|-------|-----------|-------------|
+| `lineitem` | 600 million | Order line items, the largest table |
+| `orders` | 150 million | Order master table |
+| `customer` | 15 million | Customer information |
+| `supplier` | 1 million | Supplier information |
+| `part` | 2 million | Part information |
+| `partsupp` | 8 million | Part-supplier relationships |
+| `nation` | 25 | Country dimension |
+| `region` | 5 | Region dimension |
+
+**Use cases**:
+- Test SQL query performance and compare response times across different VCluster sizes
+- Learn multi-table JOIN, aggregation, window function, and other SQL syntax
+- Validate index effectiveness (Bloomfilter, inverted index)
+
+**Example query**: Calculate annual revenue by region (TPC-H Q5)
+
+```sql
+SELECT
+    n.n_name,
+    SUM(l.l_extendedprice * (1 - l.l_discount)) AS revenue
+FROM
+    clickzetta_sample_data.tpch_100g.customer c
+    JOIN clickzetta_sample_data.tpch_100g.orders o ON c.c_custkey = o.o_custkey
+    JOIN clickzetta_sample_data.tpch_100g.lineitem l ON o.o_orderkey = l.l_orderkey
+    JOIN clickzetta_sample_data.tpch_100g.supplier s ON l.l_suppkey = s.s_suppkey
+    JOIN clickzetta_sample_data.tpch_100g.nation n ON c.c_nationkey = n.n_nationkey
+    JOIN clickzetta_sample_data.tpch_100g.region r ON n.n_regionkey = r.r_regionkey
+WHERE
+    r.r_name = 'ASIA'
+    AND o.o_orderdate >= '1994-01-01'
+    AND o.o_orderdate < '1995-01-01'
+GROUP BY n.n_name
+ORDER BY revenue DESC;
+```
+
+## tpcds_10tb
+
+**Data source**: [TPC-DS](https://www.tpc.org/tpcds/) is a more complex retail benchmark than TPC-H, simulating multi-channel (store, catalog, web) sales scenarios with 24 tables and 99 standard queries.
+
+**Scale**: 10 TB, 24 tables total.
+
+| Table | Row Count | Description |
+|-------|-----------|-------------|
+| `store_sales` | 28.8 billion | Store sales line items |
+| `catalog_sales` | 14.4 billion | Catalog sales line items |
+| `web_sales` | 7.2 billion | Web sales line items |
+| `store_returns` | 2.88 billion | Store return records |
+| `inventory` | 1.31 billion | Inventory records |
+| `customer` | 65 million | Customer information |
+| `item` | 402,000 | Product information |
+| `date_dim` | 73,000 | Date dimension |
+| Other 16 tables | — | Dimension tables (store, promotion, address, etc.) |
+
+**Use cases**:
+- Large-scale stress testing to validate query performance at the 10 TB level
+- Test execution plans for complex multi-table JOINs and subqueries
+- Compare different VCluster sizes under heavy queries
+
+**Example query**: Calculate quarterly sales by store
+
+```sql
+SELECT
+    s.s_store_name,
+    d.d_year,
+    d.d_qoy,
+    SUM(ss.ss_net_paid) AS total_sales
+FROM
+    clickzetta_sample_data.tpcds_10tb.store_sales ss
+    JOIN clickzetta_sample_data.tpcds_10tb.store s ON ss.ss_store_sk = s.s_store_sk
+    JOIN clickzetta_sample_data.tpcds_10tb.date_dim d ON ss.ss_sold_date_sk = d.d_date_sk
+WHERE
+    d.d_year = 2001
+GROUP BY s.s_store_name, d.d_year, d.d_qoy
+ORDER BY d.d_qoy, total_sales DESC
+LIMIT 20;
+```
+
+> ⚠️ **Note**: The tpcds_10tb dataset is extremely large. It is recommended to use a Large or larger VCluster to avoid query timeouts.
+
+## ecommerce_events_history
+
+**Data source**: From a [Kaggle public dataset](https://www.kaggle.com/datasets/mkechinov/ecommerce-behavior-data-from-multi-category-store), recording user behavior events on a multi-category e-commerce platform, including browsing, adding to cart, and purchasing.
+
+**Scale**: 2 tables.
+
+| Table | Row Count | Description |
+|-------|-----------|-------------|
+| `ecommerce_events_multicategorystore` | 110 million | Historical event snapshot table |
+| `ecommerce_events_multicategorystore_live` | 370 million | Continuously updated live event table with `change_tracking` enabled; supports creating a Table Stream |
+
+**Field descriptions**:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `event_time` | varchar | Event occurrence time |
+| `event_timestamp` | timestamp_ltz | Event timestamp |
+| `event_type` | varchar | Event type: view / cart / purchase |
+| `product_id` | varchar | Product ID |
+| `category_id` | varchar | Category ID |
+| `category_code` | varchar | Category path, e.g. `electronics.smartphone` |
+| `brand` | varchar | Brand |
+| `price` | decimal(10,2) | Product price |
+| `user_id` | varchar | User ID |
+| `user_session` | varchar | Session ID |
+| `event_date` | date | Event date (partition key) |
+
+**Use cases**:
+- Funnel analysis (view → add to cart → purchase conversion rate)
+- User retention and repeat purchase analysis
+- Category and brand sales ranking
+- Incremental data processing practice based on Table Stream
+
+**Example query**: Calculate the conversion funnel by event type
+
+```sql
+SELECT
+    event_type,
+    COUNT(DISTINCT user_id) AS users,
+    COUNT(*) AS events
+FROM clickzetta_sample_data.ecommerce_events_history.ecommerce_events_multicategorystore
+GROUP BY event_type
+ORDER BY events DESC;
+```
+
+## nyc_taxi_tripdata
+
+**Data source**: Publicly released trip data from the [New York City Taxi and Limousine Commission (TLC)](https://www.nyc.gov/site/tlc/about/tlc-trip-record-data.page), covering ride-hailing trips from platforms such as Uber and Lyft (FHVHV: For-Hire Vehicle High Volume).
+
+**Scale**: 1 table, 1.49 billion rows.
+
+**Key fields**:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `hvfhs_license_num` | varchar | Platform license number (HV0003=Uber, HV0005=Lyft) |
+| `pickup_datetime` | timestamp_ltz | Pickup time |
+| `dropoff_datetime` | timestamp_ltz | Dropoff time |
+| `trip_miles` | double | Trip distance (miles) |
+| `trip_time` | bigint | Trip duration (seconds) |
+| `base_passenger_fare` | double | Base passenger fare |
+| `tips` | double | Tips |
+| `driver_pay` | double | Driver earnings |
+| `shared_request_flag` | varchar | Shared ride request (Y/N) |
+| `wav_request_flag` | varchar | Wheelchair-accessible vehicle request (Y/N) |
+
+**Use cases**:
+- Time-series aggregation analysis (trip volume by hour, by day of week)
+- Large-table aggregation performance testing
+- Platform comparison analysis (Uber vs Lyft)
+- Geospatial data analysis (combined with pickup/dropoff zone fields)
+
+**Example query**: Average trip distance and fare by platform
+
+```sql
+SELECT
+    hvfhs_license_num,
+    COUNT(*) AS trips,
+    ROUND(AVG(trip_miles), 2) AS avg_miles,
+    ROUND(AVG(trip_time) / 60, 1) AS avg_minutes,
+    ROUND(AVG(base_passenger_fare), 2) AS avg_fare
+FROM clickzetta_sample_data.nyc_taxi_tripdata.fhvhv_tripdata
+GROUP BY hvfhs_license_num
+ORDER BY trips DESC;
+```
+
+> ⚠️ **Note**: This table has 1.49 billion rows. Full table scans take a long time. It is recommended to add a time range filter in your query, or use a Large or larger VCluster.
+
+## clickzetta_doc_kb
+
+**Data content**: A vector knowledge base of Singdata Lakehouse product documentation. Document content is converted into 1024-dimensional vectors using Alibaba Cloud DashScope's text embedding model, for use in semantic retrieval and AI question answering.
+
+**Scale**: 1 table, `dashscope_clickzetta_elements`.
+
+**Key fields**:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `id` | string | Unique record ID |
+| `type` | string | Element type (Title / NarrativeText / Table, etc.) |
+| `filename` | string | Source document filename |
+| `text` | string | Raw text content |
+| `embeddings` | vector(float, 1024) | 1024-dimensional vector representation of the text |
+| `element_type` | string | Document element classification |
+| `documents_source` | string | Document source identifier |
+| `date_processed` | timestamp_ltz | Vector processing timestamp |
+
+**Use cases**:
+- Experience vector similarity retrieval (the `<=>` cosine distance operator)
+- Build a RAG (Retrieval-Augmented Generation) Q&A system based on product documentation
+- Learn how to use the `AI_EMBEDDING` function together with vector indexes
+
+**Example query**: Retrieve document fragments most relevant to "dynamic table" using vector similarity
+
+```sql
+SELECT
+    filename,
+    type,
+    text,
+    embeddings <=> AI_EMBEDDING('动态表是什么') AS distance
+FROM clickzetta_sample_data.clickzetta_doc_kb.dashscope_clickzetta_elements
+ORDER BY distance ASC
+LIMIT 5;
+```
+
+## Related Documentation
+
+- [Get Started with TPC-H Queries Using Sample Data](get-started-with-sample-data.md)
+- [TPC-H Performance Benchmark](tpch-benchmark.md)
+- [Table Stream](om-table-stream.md)
+- [Vector Index](om-inverted-index.md)
+- [AI_EMBEDDING Function](ai_embedding.md)