docs: polish query demos

Author: BohuTANG

docs/cn/guides/54-query/00-sql-analytics.md

@@ -2,7 +2,7 @@
 title: SQL 分析
 ---
 
-> **场景：** CityDrive 将所有行车记录暂存到共享的关系型表中。这样分析师就可以针对同一批 `video_id` / `frame_id` 数据进行过滤、关联和聚合，并供所有下游业务复用。
+> **场景：** CityDrive 将所有行车记录暂存到统一的关系型表中。这些关系型数据（如视频元信息、事件标签）均由后台处理流程从原始行车视频的关键帧中提取而来。这样分析师就可以针对同一批 `video_id` / `frame_id` 数据进行过滤、关联和聚合，并供所有下游业务复用。
 
 本指南将对该目录的关系型数据部分进行建模，并重点介绍实用的 SQL 构建模块。这里用到的示例 ID 也会在后续的 JSON、向量、地理空间和 ETL 指南中反复出现。
 

docs/cn/guides/54-query/01-json-search.md

@@ -2,7 +2,7 @@
 title: JSON 与搜索
 ---
 
-> **场景：** CityDrive 会为每个提取的视频帧关联一份 JSON 元数据。我们需要直接在 Databend 中使用类似 Elasticsearch 的语法对这些 JSON 进行检索，避免将数据复制到外部系统。
+> **场景：** CityDrive 会为每个提取的视频帧关联一份 JSON 元数据。这些 JSON 数据由后台工具从视频关键帧中提取，包含了场景识别、物体检测等丰富的非结构化信息。我们需要直接在 Databend 中使用类似 Elasticsearch 的语法对这些 JSON 进行检索，避免将数据复制到外部系统。
 
 Databend 将这些多模态信号统一存储在一个数仓中。通过倒排索引，我们可以在 VARIANT 列上实现 ES 风格的搜索；利用位图索引（Bitmap）加速标签筛选；使用向量索引处理相似度查询；同时借助原生的 GEOMETRY 列支持地理空间过滤。
 

docs/cn/guides/54-query/02-vector-db.md

@@ -2,7 +2,7 @@
 title: 向量搜索
 ---
 
-> **场景：** CityDrive 将每一帧的向量嵌入（Embeddings）直接存储在 Databend 中。这样一来，语义相似度搜索（即“查找与此画面相似的帧”）就可以与传统的 SQL 分析任务并行运行，而无需部署额外的向量数据库服务。
+> **场景：** CityDrive 将每一帧的向量嵌入（Embeddings）直接存储在 Databend 中。这些向量数据是 AI 模型对视频关键帧进行推理的结果，用于捕捉画面的视觉语义特征。这样一来，语义相似度搜索（即“查找与此画面相似的帧”）就可以与传统的 SQL 分析任务并行运行，而无需部署额外的向量数据库服务。
 
 `frame_embeddings` 表与 `frame_events`、`frame_metadata_catalog` 以及 `frame_geo_points` 表共用同一套 `frame_id` 主键，这使得语义搜索能够与经典 SQL 查询紧密结合，无缝衔接。
 

docs/cn/guides/54-query/03-geo-analytics.md

@@ -2,7 +2,7 @@
 title: 地理分析
 ---
 
-> **场景：** CityDrive 为每个标记帧记录了精确的 GPS 定位以及与交通信号灯的距离。运营团队可以完全通过 SQL 来回答“事件发生在哪里？”这类问题。
+> **场景：** CityDrive 为每个标记帧记录了精确的 GPS 定位以及与交通信号灯的距离。这些地理空间数据源于行车记录仪的 GPS 模块，并已与视频关键帧的时间戳精准对齐。运营团队可以完全通过 SQL 来回答“事件发生在哪里？”这类问题。
 
 `frame_geo_points` 和 `signal_contact_points` 表与本指南其他部分一样，共用 `video_id`/`frame_id` 键。这意味着您无需复制数据，即可将分析视角从 SQL 指标切换到地图视图。
 

docs/cn/guides/54-query/04-lakehouse-etl.md

@@ -2,7 +2,7 @@
 title: Lakehouse ETL
 ---
 
-> **场景：** CityDrive 的数据工程团队将每一批行车记录仪数据导出为 Parquet 格式（包含视频、帧事件、元数据 JSON、向量嵌入、GPS 轨迹、交通信号灯距离），并希望通过一条 COPY 管道将这些数据更新到 Databend 的共享表中。
+> **场景：** CityDrive 的数据工程团队将每一批行车记录仪数据导出为 Parquet 格式（包含视频、帧事件、元数据 JSON、向量嵌入、GPS 轨迹、交通信号灯距离）。这些文件汇聚了从原始视频流中提取的所有多模态信号，构成了数仓的数据基础。团队希望通过一条 COPY 管道将这些数据更新到 Databend 的表中。
 
 加载流程非常直观：
 
@@ -62,8 +62,8 @@ Databend 会根据 Stage 定义自动推断格式，因此此处无需指定额
 
 ---
 
-## 3. COPY INTO 统一表
-每个导出文件对应指南中使用的共享表之一。使用内联转换（Inline Casts）可以保持 Schema 的一致性，即使上游字段顺序发生变化也不受影响。
+## 3. COPY INTO 目标表
+每个导出文件对应指南中使用的表之一。使用内联转换（Inline Casts）可以保持 Schema 的一致性，即使上游字段顺序发生变化也不受影响。
 
 ### `citydrive_videos`
 ```sql

docs/cn/guides/54-query/index.md

@@ -12,6 +12,6 @@ CityDrive Intelligence 记录每一次行车过程的视频。通过后台处理
 | [JSON 与搜索](./01-json-search.md) | 加载 `frame_metadata_catalog`，执行 Elasticsearch 风格的 `QUERY()`，并关联位图标签 |
 | [向量搜索](./02-vector-db.md) | 存储向量嵌入，运行余弦相似度搜索，并关联风险指标 |
 | [地理空间分析](./03-geo-analytics.md) | 利用 `GEOMETRY` 类型，进行距离/多边形过滤及红绿灯关联查询 |
-| [Lakehouse ETL](./04-lakehouse-etl.md) | 一次暂存 (Stage)，通过 `COPY INTO` 写入共享表，并添加流/任务 (Streams/Tasks) |
+| [Lakehouse ETL](./04-lakehouse-etl.md) | 一次暂存 (Stage)，通过 `COPY INTO` 写入目标表，并添加流/任务 (Streams/Tasks) |
 
 建议按顺序阅读，体验同一套标识符如何贯穿经典 SQL、文本搜索、向量分析、地理空间分析和 ETL 流程——所有这一切都基于同一个 CityDrive 业务场景。

docs/en/guides/54-query/00-sql-analytics.md

@@ -2,7 +2,7 @@
 title: SQL Analytics
 ---
 
-> **Scenario:** CityDrive stages every dash-cam run into shared relational tables so analysts can filter, join, and aggregate the same `video_id` / `frame_id` pairs for all downstream workloads.
+> **Scenario:** CityDrive stages all dash-cam records into shared relational tables. This relational data (e.g., video metadata, event tags) is extracted by background processing pipelines from keyframes of the raw dash-cam video. Analysts can then filter, join, and aggregate on the same `video_id` / `frame_id` pairs used by all downstream workloads.
 
 This walkthrough models the relational side of that catalog and highlights practical SQL building blocks. The sample IDs here appear again in the JSON, vector, geo, and ETL guides.
 

docs/en/guides/54-query/01-json-search.md

@@ -2,7 +2,7 @@
 title: JSON & Search
 ---
 
-> **Scenario:** CityDrive attaches a metadata JSON payload to every extracted frame and needs Elasticsearch-style filtering on that JSON without copying it out of Databend.
+> **Scenario:** CityDrive attaches a metadata JSON payload to every extracted frame. This JSON data is extracted from video keyframes by background tools, containing rich unstructured information like scene recognition and object detection. We need to filter this JSON in Databend with Elasticsearch-style syntax without replicating it to an external system. JSON without copying it out of Databend.
 
 Databend keeps these heterogeneous signals in one warehouse. Inverted indexes power Elasticsearch-style search on VARIANT columns, bitmap tables summarize label coverage, vector indexes answer similarity lookups, and native GEOMETRY columns support spatial filters.
 

docs/en/guides/54-query/02-vector-db.md

@@ -2,7 +2,7 @@
 title: Vector Search
 ---
 
-> **Scenario:** CityDrive keeps per-frame embeddings in Databend so semantic similarity search (“find frames that look like this”) runs alongside traditional SQL analytics—no extra vector service required.
+> **Scenario:** CityDrive keeps embeddings for every frame directly in Databend. These vector embeddings are the result of AI models inferencing on video keyframes to capture visual semantic features. Semantic similarity search ("find frames that look like this") can run alongside traditional SQL analytics—no separate vector service required.
 
 The `frame_embeddings` table shares the same `frame_id` keys as `frame_events`, `frame_metadata_catalog`, and `frame_geo_points`, which keeps semantic search and classic SQL glued together.
 

docs/en/guides/54-query/03-geo-analytics.md

@@ -2,7 +2,7 @@
 title: Geo Analytics
 ---
 
-> **Scenario:** CityDrive records precise GPS fixes and traffic-signal distances for each flagged frame so operations teams can answer “where did this happen?” entirely in SQL.
+> **Scenario:** CityDrive records precise GPS positioning and distance-to-signal for every flagged frame. This geospatial data originates from the dash-cam's GPS module and is precisely aligned with the timestamps of video keyframes. Ops teams can answer "where did this happen?" purely in SQL.
 
 `frame_geo_points` and `signal_contact_points` share the same `video_id`/`frame_id` keys as the rest of the guide, so you can move from SQL metrics to maps without copying data.