docs: backport concepts and positioning to 1.2 and 1.1

i18n/zh/docusaurus-plugin-content-docs/version-1.1.json

@@ -7,6 +7,10 @@
     "message": "核心函数",
     "description": "The ZH label for Core Functions"
   },
+  "sidebar.docs.doc.Observability 2.0 and wide events": {
+    "message": "Observability 2.0 与宽事件",
+    "description": "The ZH label for Observability 2.0 and wide events"
+  },
   "sidebar.docs.doc.Migrate from Loki": {
     "message": "从 Loki 迁移",
     "description": "The ZH label for Migrate from Loki"

i18n/zh/docusaurus-plugin-content-docs/version-1.1/contributor-guide/datanode/data-persistence-indexing.md

@@ -48,7 +48,7 @@ GreptimeDB 会将多种索引结构作为 Blob 存储在 Puffin 文件中，包
 
 在 v0.7 版本中，GreptimeDB 引入了倒排索引（Inverted Index）来加速查询。
 
-倒排索引是一种常见的用于全文搜索的索引结构，它将文档中的每个单词映射到包含该单词的文档列表，GreptimeDB 把这项源自于搜索引擎的技术应用到了时间序列数据库中。
+倒排索引是全文搜索中常见的索引结构，它将文档中的每个单词映射到包含该单词的文档列表。GreptimeDB 将这项搜索引擎技术用于时序数据索引。
 
 搜索引擎和时间序列数据库虽然运行在不同的领域，但是应用的倒排索引技术背后的原理是相似的。这种相似性需要一些概念上的调整：
 1. 单词：在 GreptimeDB 中，指时间线的列值。

i18n/zh/docusaurus-plugin-content-docs/version-1.1/enterprise/overview.md

@@ -1,15 +1,13 @@
 ---
-keywords: [企业版, 时序数据库, BYOC, 全托管云, 边云一体]
-description: GreptimeDB Enterprise 是为企业设计的时序数据库解决方案，提供了 BYOC、全托管云、边云一体等部署方式，并包含高级功能如双活互备的 DR 解决方案、LDAP 身份验证和审计日志。
+keywords: [企业版, 可观测性数据库, 时序数据库, BYOC, 全托管云, 边云一体]
+description: GreptimeDB Enterprise 概述，包括 BYOC、全托管独立云和边云一体等部署方案，以及安全、可用性和运维能力。
 ---
 
 # 企业版
 
-GreptimeDB Enterprise 是专为满足企业特定需求而设计的强大时序数据库解决方案。
-除了开源版 GreptimeDB 中提供的所有功能外，
-Enterprise 版还提供更多增强功能，帮助企业优化数据效率并显著降低成本，使企业能够使用时序数据做出更智能、更快速的决策。
+GreptimeDB Enterprise 在开源可观测性数据库的基础上，增加面向企业部署的安全、可用性、运维和负载管理能力。
 
-解决方案包括：
+可选的部署方式与解决方案包括：
 
 - **将数据库部署在你的云中 - Bring Your Own Cloud（BYOC**: 利用你自己的云基础设施来托管 GreptimeDB，提供广泛的定制和灵活性以满足你的业务需求。此服务包括对你的云资源的全面管理和强大的安全措施，以保护你的基础设施。
 - **全托管的独立云**: Greptime 团队提供完全托管的专用云环境，确保最佳性能、增强的安全性和卓越的可靠性，以满足你的企业需求。

i18n/zh/docusaurus-plugin-content-docs/version-1.1/reference/glossary.md

@@ -1,11 +1,11 @@
 ---
 keywords: [云原生, 可观测, 开源, 时序数据库, 车联网, 物联网, 日志, 指标, 事件, Rust]
-description: 本文档提供与云原生开源时序数据库 GreptimeDB 相关的核心术语与概念的清晰定义和解析，涵盖指标、日志及事件处理领域。通过探索术语库，深入了解支撑 GreptimeDB 的创新功能与技术架构。
+description: 本文档解释 GreptimeDB 在可观测数据、存储、查询和运维中的常用术语。
 ---
 
 # Glossary（术语表）
 
-欢迎访问 GreptimeDB 技术术语库！本资源系统阐释了云原生开源时序数据库 GreptimeDB 的核心概念与关键技术术语，涵盖指标、日志及事件处理领域。通过本术语库，您将深入理解支撑 GreptimeDB 的创新架构与技术实现。
+本文档解释 GreptimeDB 在可观测数据、存储、查询和运维中的常用术语。
 
 > 注：该排名顺序按照英文词汇首字母正序排列。
 
@@ -194,7 +194,7 @@ GreptimeDB 数据模型中用于唯一标识时序数据的列类型。具有相
 GreptimeDB 表中的特殊时间戳列，作为时序数据的主要时间维度。每个 GreptimeDB 表都需要一个 Time Index 列来按时间顺序组织数据，实现基于时间的查询，支持高效的时序操作，如降采样和时间窗口聚合。
 
 ### Time Series Database (时序数据库)
-专为时间戳索引数据设计的数据库类型。GreptimeDB 作为云原生时序数据库，深度优化了对指标、日志及事件的分析查询性能。
+专为时间戳索引数据设计的数据库类型。GreptimeDB 的可观测数据模型支持 metrics、logs、traces 和事件数据，时序 workload 是其中一类。
 
 ### Table Sharding (表分片)
 将一张大表拆分为多个更小分区的技术。在 GreptimeDB 中，表分片有助于将负载分散到多个 region 上，并提升热点表或大表的吞吐能力。

i18n/zh/docusaurus-plugin-content-docs/version-1.1/user-guide/concepts/architecture.md

@@ -1,47 +1,51 @@
 ---
-keywords: [架构, 计算存储分离, Metasrv, Frontend, Datanodes, Flownode, 对象存储, WAL, 数据库集群]
-description: GreptimeDB 架构概览，包括核心组件、用于持续聚合的可选 Flownode，以及分布式部署中的请求与数据路径。
+keywords: [架构, 计算存储分离, Metasrv, Frontend, Datanode, Flownode, 对象存储, WAL]
+description: GreptimeDB 单机与分布式架构概览，包括组件职责，以及写入、查询和 Flow 路径。
 ---
 
 # 架构
 
-GreptimeDB 采用计算存储分离架构，持久化数据保存在对象存储中，计算节点可以独立扩展。
-相比以本地磁盘作为主存储的架构，这种方式更容易实现弹性扩展，也更有利于降低运维成本。
+GreptimeDB 可以作为一个 standalone 进程运行，也可以组成分布式集群。Standalone 使用配置的本地存储或对象存储；分布式部署可以使用共享对象存储，把持久化数据文件与计算节点分离，分别调整计算和存储容量。
+
+对象存储不是系统中唯一的状态。WAL 记录已接收的写入，Metasrv 管理集群 metadata 和 Region 路由，本地磁盘可以缓存远端数据。可用性和 failover 取决于 WAL 模式、Metasrv 部署、Region 放置、共享存储和可用 Datanode 等配置。
+
+关于实时监控与历史分析为什么可以共用这套存储和查询基础，参见[为什么选择 GreptimeDB](./why-greptimedb.md#实时监控与历史分析共用一套系统)。
 
 ## 高层架构
 
-![GreptimeDB 高层架构](/architecture-4.png)
+![GreptimeDB 分布式架构，包括数据路径、控制路径和各类存储的职责。](/greptimedb-distributed-architecture.zh.svg)
 
 ## 组件
 
-GreptimeDB 在分布式模式下有三个核心组件，以及一个用于持续聚合的可选组件：
+分布式模式包含三个核心组件，以及一个可选的 Flow 运行时：
 
-- [**Metasrv**](/contributor-guide/metasrv/overview.md)：元数据与路由控制平面。负责管理 catalog、schema、table、region 等元数据，协调调度，并为其他节点提供路由信息。
-- [**Frontend**](/contributor-guide/frontend/overview.md)：无状态接入层。接收客户端协议请求、执行鉴权、规划和分发查询，并根据 Metasrv 的元数据完成读写路由。
-- [**Datanode**](/contributor-guide/datanode/overview.md)：存储与执行层。负责存储表的 region，处理读写请求，持久化 WAL，并将数据文件刷入对象存储。
-- [**Flownode（可选）**](/contributor-guide/flownode/overview.md)：[Flow 计算](/user-guide/flow-computation/overview.md)的持续聚合运行时。Flow 聚合 workload 使用 batching mode；原始的 streaming mode 已经废弃。
+- [**Metasrv**](/contributor-guide/metasrv/overview.md)：管理 catalog、schema、table、Region 路由、procedure 和调度 metadata。
+- [**Frontend**](/contributor-guide/frontend/overview.md)：接收客户端协议请求，执行鉴权和分布式查询规划，并根据 Metasrv metadata 转发读写请求。
+- [**Datanode**](/contributor-guide/datanode/overview.md)：承载 Region，执行读写，记录 WAL，运行 compaction，并把数据文件持久化到配置的本地或对象存储后端。
+- [**Flownode（可选）**](/contributor-guide/flownode/overview.md)：运行 [Flow](/user-guide/flow-computation/overview.md)任务，持续计算并把派生数据物化到 sink table。
 
-在 standalone 模式下，你运行的是一个 GreptimeDB 进程，而不是分别管理这些独立服务。
+Standalone 模式由一个 GreptimeDB 进程提供这些数据库能力，不需要分别部署各组件。
 
 ## 工作方式
 
+下面描述分布式模式的处理路径。Standalone 在同一个进程中完成相应的数据库操作。
+
 ### 写入路径
 
-1. 客户端通过支持的协议向 Frontend 发起写请求。
-2. Frontend 从 Metasrv 的元数据中解析表和 region 的路由信息，并在需要时刷新本地缓存。
-3. Frontend 将请求拆分并转发到目标 Datanode。
-4. Datanode 先将数据写入内存和 [WAL](/user-guide/deployments-administration/wal/overview.md)，随后把不可变数据文件刷入[对象存储](./storage-location.md)。
+1. 客户端通过支持的写入协议发送数据。
+2. Frontend 从 Metasrv metadata 中解析 table 和 Region 路由。
+3. Frontend 拆分请求，把数据行转发到承载目标 Region 的 Datanode。
+4. Datanode 写入内存和配置的 [WAL](/user-guide/deployments-administration/wal/overview.md)，之后在达到 flush 条件时，最终将不可变数据文件写入表指定的[存储后端](./storage-location.md)。
 
 ### 查询路径
 
-1. 客户端通过 Frontend 发起 SQL、PromQL、日志或链路追踪查询。
-2. Frontend 生成分布式执行计划，并将子查询下发到相关的 Datanode。
-3. Datanode 在各自负责的 region 上执行子查询并返回部分结果。
-4. Frontend 汇总结果并返回给客户端。
+1. 客户端提交 SQL、PromQL，或明确支持的查询 API，例如 Jaeger 兼容接口。
+2. Frontend 规划查询，并把任务下发到承载相关 Region 的 Datanode。
+3. Datanode 读取内存数据和持久化文件，在适用时使用本地 cache 加速，并通过数据裁剪和索引执行查询，返回部分结果。
+4. Frontend 合并结果并返回客户端。
 
 ### Flow 路径（可选）
 
-启用流计算后，Flownode 会持续读取源表的变化，并将计算结果写入目标表。
-详细说明请参阅[流计算](/user-guide/flow-computation/overview.md)。
+启用 Flow 后，数据路径由 Frontend 中转。Streaming mode 下，Frontend 把写入镜像给 Flownode；batching mode 下，Flownode 通过 Frontend 查询源表，并把物化结果写入 sink table。源表和 sink table 分别使用自己的 schema、TTL、索引和存储设置。详见 [Flow 计算](/user-guide/flow-computation/overview.md)。
 
-如果你想了解实现层细节，请参阅 [Contributor Guide](/contributor-guide/overview.md)。
+各类存储的职责参见[存储位置](./storage-location.md)，实现细节参见 [Contributor Guide](/contributor-guide/overview.md)。