diff --git a/blog/27.md b/blog/27.md
index 0cba78575..f694dbf5f 100644
--- a/blog/27.md
+++ b/blog/27.md
@@ -3,7 +3,7 @@ title: "Stream4Graph: Incremental Computation on Dynamic Graphs"
date: "2025-3-11"
---
-
+
> Author: Zhang Qi
@@ -23,7 +23,7 @@ Stream graph computing engine [GeaFlow](https://github.com/TuGraph-family/tugrap
- Web pages：Nodes represent web pages, and edges represent hyperlinks.
- Transportation networks: Nodes represent cities, and edges represent roads or air routes.
-
+
Graphs inherently represent the connections between nodes, and based on these relationships, we can use nodes and edges to process, analyze, and mine information, helping us understand relationships and patterns in complex systems. The computational activities conducted on graphs are referred to as graph computing. Graph computing has many applications, such as identifying user connections and discovering community structures through social network analysis, calculating web page rankings by analyzing hyperlink relationships, and recommending relevant content and products by building relationship graphs based on user behavior and preferences.
@@ -31,7 +31,7 @@ Graphs inherently represent the connections between nodes, and based on these re
Let's take a simple social network analysis algorithm—Weakly Connected Components (WCC)—as an example. WCC helps us identify "friend circles" or "communities" among users. For instance, on a social platform, a group of users who interact through likes, comments, or follows forms a large weakly connected component, while some users may not be connected to this large component, forming smaller weakly connected components.
-
+
If we were to build a WCC algorithm based solely on the small graph above, it would be very simple—we could just construct a basic node-edge structure on a personal PC and perform graph traversal. However, if the graph scale expands to hundreds of billions or even trillions, we would need to use large-scale distributed graph computing engines to handle it.
@@ -80,7 +80,7 @@ How does Spark GraphX handle graph algorithms? GraphX extends Spark RDD by intro
In summary, users first need to convert raw tabular data from storage into node-edge data types in GraphX and then let Spark handle the processing. This is for offline processing of static graphs. However, in the real world, both the scale of graph data and the relationships between nodes are constantly changing, especially in the era of big data where changes occur rapidly. How to efficiently and real-time process dynamic graph data is a significant challenge.
-
+
## 3. Dynamic Graph Computing: Spark Streaming
@@ -112,7 +112,7 @@ Using the WCC algorithm as an example, for the connected components algorithm, i
The GeaFlow engine consists of three main parts: DSL, Framework, and State. It also provides users with Stream API, Static Graph API, and Dynamic Graph API. The DSL layer is responsible for parsing and optimizing graph query languages like SQL+ISO/GQL, as well as schema inference. It also supports various Connectors such as Hive, Hudi, Kafka, and ODPS. The Framework layer handles runtime scheduling, fault tolerance, shuffle, and coordination of components. The State layer is responsible for storing underlying graph data and persistence, as well as performance optimizations like indexing and predicate pushdown.
-
+
## 6. GeaFlow Performance Testing
diff --git a/blog/28.md b/blog/28.md
index 90d534682..b0ce2f55d 100644
--- a/blog/28.md
+++ b/blog/28.md
@@ -3,7 +3,7 @@ title: Principles and Applications of Incremental Match in Streaming Graph Compu
date: 2025-6-3
---
-
+
## Problem Background
In streaming computing, data rarely arrives all at once but is continuously input and processed. Similarly, in graph computing/graph querying scenarios, vertices and edges are constantly read from data sources to construct graphs incrementally. In incremental graph queries, the graph evolves continuously, leading to different query results across graph versions. When new vertices/edges form an updated graph version, recomputing through the entire graph incurs high overhead and duplicates historical computations. Since historical data has already been processed, ideally only the delta-affected portions should be computed/queried without full-graph re-execution.
diff --git a/blog/30.md b/blog/30.md
index 38df28be8..5e6f58ee2 100644
--- a/blog/30.md
+++ b/blog/30.md
@@ -3,7 +3,7 @@ title: "Join Performance Revolution: Graph Data Warehouse Makes SQL Analysis Fas
date: 2025-5-15
---
-
+
> Author: Lin Litao
@@ -28,7 +28,7 @@ date: 2025-5-15
**Innovation Constraint**: Business analysts often abandon graph technology stacks due to the need to learn GQL (Graph Query Language). The fragmented toolchain keeps graph analytics confined to technical departments, failing to empower front-line business teams.
-
+
**Figure 2: JOIN vs GQL Expression Examples**
@@ -64,7 +64,7 @@ The Graph Data Warehouse Schema Converter automatically transforms the ER model
-
+
**Figure 3: ER to Graph Schema Conversion Example Series**
diff --git a/blog/31.md b/blog/31.md
index 00dac2454..c8ba7bf62 100644
--- a/blog/31.md
+++ b/blog/31.md
@@ -3,7 +3,7 @@ title: "Graph4Stream: Accelerating Stream Computing with Graph-Based Approaches"
date: 2025-3-25
---
-
+
> Author: Kunyu; Reviewer: Dongshuo.
@@ -66,7 +66,7 @@ ON `e`.`dst` = `v`.`vid`;
The execution plan is shown below. It consists of operators such as Aggregate, Calc, and Join. Data flows through each operator to yield incremental results. The core operator, Join, is responsible for relationship lookups. Let's examine how the Join operator works.
-
+
Flink Execution Plan
@@ -74,7 +74,7 @@ As shown below, the Join operator has two input streams: LeftInput and RightInpu
The main performance bottleneck lies in scanning RightStateView. LeftStateView and RightStateView store the left and right tables of the join, respectively. As data continuously flows in, the size of StateViews grows, causing scan times to increase dramatically and severely degrading system performance.
-
+
Flink Join Operator Implementation
@@ -84,7 +84,7 @@ Flink Join Operator Implementation
Graph computing is a computational paradigm based on graph data structures. A graph G(V,E) consists of a set of vertices V and edges E, where edges represent relationships between data. Using the public dataset web-Google as an example, each line contains two numbers representing a hyperlink between two web pages. As shown below, the left side shows raw data, which is traditionally modeled as a two-column table. In contrast, graph modeling treats web pages as vertices and hyperlinks as edges, forming a web link graph. In the tabular model, relationship computation is done via joins, which require scanning tables. In graph computing, relationships are directly stored in edges, eliminating the need for scans.
-
+
Table Modeling vs. Graph Modeling
@@ -104,7 +104,7 @@ Taking k-Hop as an example, the incremental algorithm works as follows: In the f
The diagram below illustrates the two-hop case. In the first iteration, the edge B->C creates incoming and outgoing paths, sent to B and C, respectively. In the second iteration, B receives an incoming path, adds its own incoming edges, and forms a 2-hop incoming path, which it sends to itself. Similarly, C forms a 2-hop outgoing path and sends it to B. In the final iteration, B combines the incoming and outgoing paths to produce the new paths. Unlike Flink, which must scan all historical relationships, GeaFlow's computation is proportional to the incremental paths, not the historical data.
-
+
Two-Hop Incremental Path Computation
diff --git a/blog/32.md b/blog/32.md
index 7c9b3df08..9794c4eee 100644
--- a/blog/32.md
+++ b/blog/32.md
@@ -29,7 +29,7 @@ In this update, GeaFlow adds support for Paimon storage (currently **experimenta
- Configure the storage path via the parameter `geaflow.store.paimon.options.warehouse` (default: `"file:///tmp/paimon/"`).
The current GeaFlow storage architecture is shown below:
-
+
### 🍀 Graph Data Warehouse Capability Expansion: Supports Relational Access to Graph Entities
@@ -126,4 +126,4 @@ Key features introduced in v0.6.3 (building on v0.5.2) include:
## ✨ Acknowledgments
Thank you to all contributors for making this release possible!
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/community/en/community.md b/community/en/community.md
index a41329f7c..408131d7f 100644
--- a/community/en/community.md
+++ b/community/en/community.md
@@ -1,29 +1,26 @@
### Support
-A brief introduction to the project and contact information.
+Apache GeaFlow (Incubating): A Streaming Graph Computing Engine.
-### Team
-
-Team introduction. You can refer to [https://answer.apache.org/community/team](https://answer.apache.org/community/team).
-
-Anyone who has contributed to the project can be included.
+Contact us through the following mailing list.
+[dev@geaflow.apache.org](mailto:dev@geaflow.apache.org)
-### Security
+If you are interested in GeaFlow, please give our project a [⭐](https://github.com/apache/geaflow)
-Rules for handling security issues and publicly disclosed CVEs.
+### Team
-### How to Contribute
+Team introduction. You can refer to [https://github.com/apache/geaflow/graphs/contributors](https://github.com/apache/geaflow/graphs/contributors).
-Introduction on how to contribute.
+Anyone who has contributed to the project can be included.
### Feature Request
-Link to the GitHub issues page, making it easy for users to submit requests via GitHub issues (you can also create a page explaining how to submit via the mailing list).
+Link to the GitHub issues page. [https://github.com/apache/geaflow/issues](https://github.com/apache/geaflow/issues)
### Roadmap
-Link to the Roadmap file on GitHub, mainly explaining the future plans of the project.
+Link to the Roadmap file on GitHub. [https://github.com/apache/geaflow/issues/532](https://github.com/apache/geaflow/issues/532)
### Logos
-Provide downloadable project logos and other resources
+
diff --git a/community/zh/community.md b/community/zh/community.md
index 6dcd2104c..a1ffbc879 100644
--- a/community/zh/community.md
+++ b/community/zh/community.md
@@ -1,23 +1,25 @@
-### Support
-简单的项目方面的介绍，并提供联系方式
+### 支持
+Apache GeaFlow（孵化中）：一个流式图计算引擎。
-### Team
-团队介绍 可以参考 [https://answer.apache.org/community/team](https://answer.apache.org/community/team)
+通过以下邮件列表联系我们：
+[dev@geaflow.apache.org](mailto:dev@geaflow.apache.org)
-对项目有贡献的同学都可以加进来
+如果您对 GeaFlow 感兴趣，请为我们的项目点一个 [⭐](https://github.com/apache/geaflow)
-### Security
-针对安全方面的处理规则以及已经处理的公开的 CVE
+### 团队
-### How to Contribute
-介绍如何贡献
+团队介绍。您可参考 [https://github.com/apache/geaflow/graphs/contributors](https://github.com/apache/geaflow/graphs/contributors)。
-### Feature Request
-链接到 GitHub issues 页面，方便用户以 GitHub issues 的形式提交（也可以做个页面，说明通过加入邮件列表的形式提交）
+任何为项目作出过贡献的人均可列入。
-### Roadmap
-链接到 GitHub 页面的 Roadmap 文件，主要说明项目后续的路线图
+### 功能建议
-### Logos
-提供项目的 logo 等资源的下载，方便社区协作使用
+跳转到 GitHub 议题页面的链接：[https://github.com/apache/geaflow/issues](https://github.com/apache/geaflow/issues)
+### 路线图
+
+跳转到 GitHub 路线图文件的链接：[https://github.com/apache/geaflow/issues/532](https://github.com/apache/geaflow/issues/532)
+
+### 徽标（Logo）
+
+
\ No newline at end of file
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/1.md b/i18n/zh-CN/docusaurus-plugin-content-blog/1.md
similarity index 89%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/1.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/1.md
index 2b33bed4f..2bdcee5a5 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/1.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/1.md
@@ -9,17 +9,17 @@ date: 2023-06-11
-
+
去年 9 月，蚂蚁集团开源了 TuGraph 图计算平台中的图数据库 TuGraph DB。这次开源是 TuGraph 图计算平台的又一次开源升级，进一步加大了蚂蚁在图计算基础软件领域的开放力度，也是通过开放协同促进科技创新的实际行动。
-
+
图（Graph）是一种抽象的数据结构，由顶点和边构成。图计算是一种以图结构建模的算法模型，可对大规模数据进行关系挖掘和复杂计算，实现知识推理和事件溯源。图计算目前已广泛应用在金融、政务、医疗等领域，备受全球研发机构和顶尖科技公司关注。流式图计算是一种将流式计算和图计算结合的交叉创新，融合了流式计算的高度实效性和图计算的灵活性，攻坚难度极高。
据了解，蚂蚁从 2015 年开始探索图计算，布局了图数据库、流式图计算引擎、图学习等相关技术，打造了世界规模领先的图计算集群，于业界首创了工业级流式图计算引擎，多次问鼎图数据库行业权威测试 LDBC 世界冠军并保持世界纪录。此次开源的工业级流式图计算引擎是蚂蚁从 2017 年开始布局打造，经过五年多工业级应用大考，流式图计算做到了在千亿数据规模的“图”上秒级延迟计算，是蚂蚁风控的核心基础技术，成功解决了金融场景风险分析难、识别率低、时效性差等业界难题。
-
+
图计算是下一代人工智能关键核心技术。中国工程院院士郑纬民曾指出，“高性能图计算是当前全球人工智能竞争的战略性制高点，我们要加快攻克技术、突破产业瓶颈，防止在高性能图计算这一关键技术领域再被卡脖子”。而开源是共享科技成果，加速先进技术落地的最快路径。
@@ -37,6 +37,6 @@ date: 2023-06-11
## 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/10.md b/i18n/zh-CN/docusaurus-plugin-content-blog/10.md
similarity index 94%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/10.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/10.md
index 0f59ae375..3916bb15b 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/10.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/10.md
@@ -13,7 +13,7 @@ date: 2023-8-15
- Static Graph API：静态图计算 API，基于该类 API 可以进行全量的图计算或图遍历。
- Dynamic Graph API：动态图计算 API，GeaFlow 中 GraphView 是动态图的数据抽象，基于 GraphView 之上，可以进行动态图计算或图遍历。同时支持对 Graphview 生成 Snapshot 快照，基于 Snapshot 可以提供和 Static Graph API 一样的接口能力。
-
+
- Stream API：GeaFlow 提供了一套通用计算的编程接口，包括 source 构建、流批计算及 sink 输出。在 GeaFlow 中支持 Batch 和 Stream 两种类型。
- Batch API：批计算 API，基于该类 API 可以进行批量计算。
@@ -239,15 +239,15 @@ mvn clean install
在 GeaFlow Console 中新增图任务，任务类型选择“HLA”， 并上传 jar 包（或者选择已存在的 jar 包），其中**entryClass 为算法主函数所在的类**。 点击“提交”，创建任务。
-
+
### 提交作业
-
+
点击”发布”，可进入作业详情界面，点击“提交”即可提交作业。
-
+
### 查看运行结果
@@ -268,7 +268,7 @@ mvn clean install
可在作业详情中查看运行详情，
-
+
**至此，我们就成功使用 Geaflow 实现并运行 API 任务了！是不是超简单！快来试一试吧！**
@@ -282,6 +282,6 @@ mvn clean install
## 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/11.md b/i18n/zh-CN/docusaurus-plugin-content-blog/11.md
similarity index 96%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/11.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/11.md
index 21cf05453..89ac0e407 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/11.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/11.md
@@ -13,7 +13,7 @@ date: 2023-8-15
K-hop 算法是一种基于图论的算法，用于寻找一个起点通过 K 次以内跳跃能够到达的节点，也就是从起点出发，找出 K 层内与之关联的节点。K-hop 算法广泛应用于好友推荐、影响力预测和关系发现等场景。 K-hop 算法本质上是一种广度优先搜索（BFS）算法，通过从起点开始不断向外扩散的方式来计算每一个节点到起点的跳跃数。算法流程如下：
-
+
## GeaFlow 实现 K-hop 算法
@@ -124,7 +124,7 @@ public class KHop implements AlgorithmUserFunction {
### 将 UDGA 上传至 console 平台
-
+
### 注册 k-hop 函数，并在 DSL 中使用
@@ -243,6 +243,6 @@ RETURN vid, kValue
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/12.md b/i18n/zh-CN/docusaurus-plugin-content-blog/12.md
similarity index 95%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/12.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/12.md
index 312df3c23..2599a30a6 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/12.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/12.md
@@ -19,7 +19,7 @@ date: 2023-8-21
本文希望通过一张图描述清楚 TuGraph Analytics 的整体架构脉络和关键设计思路，以帮助大家快速对 TuGraph Analytics 项目的轮廓有个整体的认识。闲言少叙，直接上图。
-
+
TuGraph Analytics 开源技术架构一共分为五个部分：
@@ -33,7 +33,7 @@ date: 2023-8-21
DSL 层是一个典型的编译器技术架构，即语法分析、语义分析、中间代码生成(IR)、代码优化、目标代码生成（OBJ）的流程。
-
+
- **语言设计**：TuGraph Analytics 设计了 SQL+GQL 的融合语法，解决了图+表一体化分析的诉求。具体语法设计可以参考文章：[DSL 语法文档](https://github.com/TuGraph-family/tugraph-analytics/blob/master/docs/docs-en/application-development/dsl/overview.md)
- **语法分析**：通过扩展 Calcite 的 SqlNode 和 SqlOperator，实现 SQL+GQL 的语法解析器，生成统一的语法树信息。
@@ -48,7 +48,7 @@ date: 2023-8-21
Framework 层设计与 Flink/Spark 等同类大数据计算引擎有一定的相似性，即提供了类 FlumeJava（[FlumeJava: Easy, Efficient Data-Parallel Pipelines](https://pages.cs.wisc.edu/~akella/CS838/F12/838-CloudPapers/FlumeJava.pdf)）的统一高阶 API（简称 HLA），用户调用高阶 API 的过程会被转换为逻辑执行计划，逻辑执行计划执行一定的优化（如 ChainCombine、UnionPushUp 等）后，被转换为物理执行计划，物理执行计划会被调度器分发到分布式 Worker 上执行，最终 Worker 会回调用户传递的高阶 API 函数逻辑，实现整个分布式计算链路的执行。
-
+
- **高阶 API**：TuGraph Analytics 通过 Environment 接口适配异构的分布式执行环境（K8S、Ray、Local），使用 Pipeline 封装了用户的数据处理流程，使用 Window 抽象统一了流处理（无界 Window）和批处理（有界 Window）。Graph 接口提供了静态图和动态图（流图）上的计算 API，如 append/snapshot/compute/traversal 等，Stream 接口提供了统一流批处理 API，如 map/reduce/join/keyBy 等。
- **逻辑执行计划**：逻辑执行计划信息统一封装在 PipelineGraph 对象内，将高阶 API 对应的算子（Operator）组织在 DAG 中，算子一共分为 5 大类：SourceOperator 对应数据源加载、OneInputOperator/TwoInputOperator 对应传统的数据处理、IteratorOperator 对应静态/动态图计算。DAG 中的点（PipelineVertex）记录了算子（Operator）的关键信息，如类型、并发度、算子函数等信息，边（PipelineEdge）则记录了数据 shuffle 的关键信息，如 Partition 规则（forward/broadcast/key 等）、编解码器等。
@@ -60,7 +60,7 @@ date: 2023-8-21
State 层设计相比于传统的大数据计算引擎，除了提供面向表数据的 KV 存储抽象，也支持了面向图数据的 Graph 存储抽象，以更好地支持面向图模型的 IO 性能优化。
-
+
- **State API**：提供了面向 KV 存储 API，如 get/put/delete 等。以及面向图存储的 API，如 V/E/VE，以及点/边的 add/update/delete 等。
- **State 执行层**：通过 KeyGroup 的设计实现数据的 Sharding 和扩缩容能力，Accessor 提供了面向不同读写策略和数据模型的 IO 抽象，StateOperator 抽象了存储层 SPI，如 finish（刷盘）、archive（Checkpoint）、compact（压缩）、recover（恢复）等。另外，State 提供了多种 PushDown 优化以加速 IO 访问效率。通过自定义内存管理和面向属性的二级索引也会提供大量的存储访问优化手段。
@@ -71,7 +71,7 @@ date: 2023-8-21
Console 平台提供了一站式图研发、运维的平台能力，同时为引擎运行时提供元数据（Catalog）服务。
-
+
- **标准化 API**：平台提供了标准化的 RESTful API 和认证机制，同时支持了页面端和应用端的统一 API 服务能力。
- **任务研发**：平台支持“关系-实体-属性”的图数据建模。基于字段映射配置，可以定义图数据传输任务，包括数据集成（Import）和数据分发（Export）。基于图表模型的图数据加工任务支持多样化的计算场景，如 Traversal、Compute、Mining 等。基于数据加速器的图数据服务，提供了多协议的实时分析能力，支持 BI、可视化分析工具的接入集成。
@@ -84,7 +84,7 @@ date: 2023-8-21
TuGraph Analytics 支持多种异构环境执行，以常见的 K8S 部署环境为例，其物理部署架构如下：
-
+
在 TuGraph Analytics 作业的全生命周期过程中，涉及的关键数据流程有：
@@ -111,6 +111,6 @@ date: 2023-8-21
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/13.md b/i18n/zh-CN/docusaurus-plugin-content-blog/13.md
similarity index 97%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/13.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/13.md
index f389fdf14..c09b17fac 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/13.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/13.md
@@ -15,7 +15,7 @@ date: 2023-9-4
一张图的 K-Core 子图是指从图中反复去掉度（不考虑自环边）小于 k 的节点之后得到的子图。该计算过程是一个反复迭代剪枝的过程，在某一轮剪枝之前度大于等于 k 的节点，可能会在该轮剪枝后变为度小于 k。比如 3-core 子图的切分过程如图 1 所示：
-
+
3-core 子图切分过程
@@ -265,6 +265,6 @@ RETURN vid, value
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/14.md b/i18n/zh-CN/docusaurus-plugin-content-blog/14.md
similarity index 92%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/14.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/14.md
index 3a0114bae..62a00dd58 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/14.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/14.md
@@ -19,7 +19,7 @@ date: 2023-9-12
无论是在批或流的计算系统中，Join 操作都涉及大量 shuffle 和计算开销。同时，Join 产生的中间结果由于关联会放大多份，造成数据量指数级膨胀和冗余，存储消耗大。
-在下图的实验中，我们模拟了依次执行一跳、两跳和三跳关系运算的场景。足以见得，越是复杂的多跳关系计算，关系模型中 Join 的性能表现越差。在总时间对比中，利用图的 Match 计算能够节约超过 90%的耗时。
+在下图的实验中，我们模拟了依次执行一跳、两跳和三跳关系运算的场景。足以见得，越是复杂的多跳关系计算，关系模型中 Join 的性能表现越差。在总时间对比中，利用图的 Match 计算能够节约超过 90%的耗时。
图 1
@@ -39,7 +39,7 @@ date: 2023-9-12
相比宽表的关系物化方式，由于图结构本身的点边聚合性，构图表现得十分节约。 下图是 GeaFlow 中高性能构图的表现，可见构图操作本身极为迅速，且由于图可以分片的特性，具有十分良好的可扩展性。
-
+
图 2
@@ -51,7 +51,7 @@ date: 2023-9-12
GeaFlow 提供融合 GQL 和 SQL 样式的查询语言，这是一种图表一体的数据分析语言，继承自标准 SQL+ISO/GQL，可以方便进行图表分析。
-
+
图 3
@@ -65,7 +65,7 @@ date: 2023-9-12
TuGraph-Analytics 已经于 2023 年 6 月正式对外开源，开放其以图为数据模型的流批一体计算核心能力。相比传统的流式计算引擎，如 Flink、Storm 这些以表为模型的实时处理系统，GeaFlow 以自研图存储为底座，流批一体计算引擎为矛，融合 GQL/SQL DSL 语言为旗帜，在复杂多度的关系运算上具备极大的优势。
-
+
图 4
@@ -83,6 +83,6 @@ date: 2023-9-12
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/15.md b/i18n/zh-CN/docusaurus-plugin-content-blog/15.md
similarity index 91%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/15.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/15.md
index 0f0a8d67f..3d35bb7c8 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/15.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/15.md
@@ -17,13 +17,13 @@ date: 2023-9-13
### 计算模型抽象
-在深入解构了归因分析的细节之后，我们发现一个用户的行为可以通过用图的方式很自然的描述出来，将用户抽象成为一种类型的点，将产品上的埋点信息抽象成为另一种类型的点，而他们之间发生的行为事件信息就可以抽象成连接两种类型点的边。 这样，一个用户及其在产品上的所有行为就构建出了一张用户行为事实图，其中一个用户有多条指向埋点位置的边。其中一条边就是一次用户行为事件（页面访问、点击操作、浏览行为等等），这条边指向一个埋点位置，边上保存了后期分析需要的基础信息（埋点信息、时间信息等等）和扩展信息（活动信息、展位信息等等）。如此，用于描述用户的点、用于描述埋点位置的点以及连接用户和埋点位置之间的边，就形成了一个用户行为网络拓扑。整个拓扑图中包含所有用户及其相应的行为，而每个用户及其相关的行为是整个拓扑图中的一张子图，可以通过图算法对其进行分析。
+在深入解构了归因分析的细节之后，我们发现一个用户的行为可以通过用图的方式很自然的描述出来，将用户抽象成为一种类型的点，将产品上的埋点信息抽象成为另一种类型的点，而他们之间发生的行为事件信息就可以抽象成连接两种类型点的边。 这样，一个用户及其在产品上的所有行为就构建出了一张用户行为事实图，其中一个用户有多条指向埋点位置的边。其中一条边就是一次用户行为事件（页面访问、点击操作、浏览行为等等），这条边指向一个埋点位置，边上保存了后期分析需要的基础信息（埋点信息、时间信息等等）和扩展信息（活动信息、展位信息等等）。如此，用于描述用户的点、用于描述埋点位置的点以及连接用户和埋点位置之间的边，就形成了一个用户行为网络拓扑。整个拓扑图中包含所有用户及其相应的行为，而每个用户及其相关的行为是整个拓扑图中的一张子图，可以通过图算法对其进行分析。
接下来，基于这张用户行为事实拓扑图，我们可以在其上根据归因分析所要求的解析规则进行路径模式匹配，从而产出最终的用户行为路径，然后输出到下游存储系统供运营同学使用。
### 路径匹配规则
-路径模式匹配的规则描述的是如何根据用户的原始行为数据得到最终转化路径的过程，该口径直接决定了需要应用于拓扑图数据上的匹配算法。这个口径一般由业务场景决定，不同的业务类型的规则由需求方提供。 用户行为日志中的交易数据是关键点，它们会触发相关用户的子图归因路径匹配计算，计算结果为最终的归因路径。这里的成交数据不仅仅指用户的交易行为，还可以泛化推及到一切需要归因分析的场景，例如签约、订阅、关注、点击等等，在所有关心转化的场景下都能够发挥作用，创造价值。
+路径模式匹配的规则描述的是如何根据用户的原始行为数据得到最终转化路径的过程，该口径直接决定了需要应用于拓扑图数据上的匹配算法。这个口径一般由业务场景决定，不同的业务类型的规则由需求方提供。 用户行为日志中的交易数据是关键点，它们会触发相关用户的子图归因路径匹配计算，计算结果为最终的归因路径。这里的成交数据不仅仅指用户的交易行为，还可以泛化推及到一切需要归因分析的场景，例如签约、订阅、关注、点击等等，在所有关心转化的场景下都能够发挥作用，创造价值。
以上图中的 user1 为例，与其相关的行为埋点有 spm1、spm2、spm4、spm9，与其相关的交易埋点有 trade1 和 trade5，那么当系统接收到 trade1 这个埋点信息的时候，在 TuGraph Analytics 能够动态加载所有与 user1 相关的埋点信息，参与归因路径规则匹配计算。 需要说明的是，trade1 和 trade5 的计算是互不影响的，与 user1 相关的所有行为埋点信息都会分别参与两者的计算，得到各自的计算结果。
@@ -35,17 +35,17 @@ date: 2023-9-13
- 其次，在触发路径匹配计算交易数据实时到来之后，要能够立刻获取到与该交易行为相关的子拓扑图，其中包含了计算归因路径所需要的所有点边数据（用户节点、埋点位置节点以及两者之间的边），之后在这张子图上根据解析规则进行归因路径匹配，得到该交易的最终归因路径。
- 再次，在大量的交易数据涌入之后能够同时对所有的交易进行归因路径计算，保证输出的时效性。
-TuGraph Analytics 作为一个实时流图计算引擎，能够满足以上的所有需求。在动态数据到来的过程中触发计算，能够尽可能快的获取到用户的行为边参与路径分析。同时 TuGraph Analytics State 也能够很好的支持千亿甚至万亿级别的图状态存储，在归因分析的场景下绰绰有余。
+TuGraph Analytics 作为一个实时流图计算引擎，能够满足以上的所有需求。在动态数据到来的过程中触发计算，能够尽可能快的获取到用户的行为边参与路径分析。同时 TuGraph Analytics State 也能够很好的支持千亿甚至万亿级别的图状态存储，在归因分析的场景下绰绰有余。
## 计算流程
### 实时构图
-通过 TuGraph Analytics 自有的 IO 插件，可以接入多种外部数据源（静态或者动态）的数据，将二维数据转化成描述拓扑图的点边数据。 在归因分析的场景下，我们通过 SLS 插件（阿里云 SLS 日志服务）接入用户访问行为日志、用户点击行为日志以及最终达成交易的订单日志，将用户构建成一个点，与其相关的每个行为构建成从该用户指向埋点位置的一条边，同时把涉及到的的埋点信息保存下来供后续升维分析使用。
+通过 TuGraph Analytics 自有的 IO 插件，可以接入多种外部数据源（静态或者动态）的数据，将二维数据转化成描述拓扑图的点边数据。 在归因分析的场景下，我们通过 SLS 插件（阿里云 SLS 日志服务）接入用户访问行为日志、用户点击行为日志以及最终达成交易的订单日志，将用户构建成一个点，与其相关的每个行为构建成从该用户指向埋点位置的一条边，同时把涉及到的的埋点信息保存下来供后续升维分析使用。
### 路径计算
-在构建的用户行为事实图上，我们会抽取新到来的交易数据，对于这些数据涉及到的用户，提取他们的行为子图，之后在每个人的子图上基于归因路径匹配的规则进行匹配计算，得出该成交行为相应用户的归因路径，并输出到下游系统。
+在构建的用户行为事实图上，我们会抽取新到来的交易数据，对于这些数据涉及到的用户，提取他们的行为子图，之后在每个人的子图上基于归因路径匹配的规则进行匹配计算，得出该成交行为相应用户的归因路径，并输出到下游系统。
## 业务效果
@@ -69,6 +69,6 @@ date: 2023-9-13
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/16.md b/i18n/zh-CN/docusaurus-plugin-content-blog/16.md
similarity index 95%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/16.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/16.md
index 6690254c8..b8ac022ab 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/16.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/16.md
@@ -13,9 +13,9 @@ date: 2023-9-20
## 算法介绍
-对于图中一个给定节点，紧密性中心性是该节点到其他所有节点的最小距离和的倒数：
+对于图中一个给定节点，紧密性中心性是该节点到其他所有节点的最小距离和的倒数：
-其中，u 表示待计算紧密中心度的节点，d(u, v)表示节点 u 到节点 v 的最短路径距离；实际场景中，更多地使用归一化后的紧密中心度，即计算目标节点到其他节点的平均距离的倒数：
+其中，u 表示待计算紧密中心度的节点，d(u, v)表示节点 u 到节点 v 的最短路径距离；实际场景中，更多地使用归一化后的紧密中心度，即计算目标节点到其他节点的平均距离的倒数：
其中，n 表示图中节点数。
@@ -252,6 +252,6 @@ RETURN vid, ROUND(ccValue, 3)
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/17.md b/i18n/zh-CN/docusaurus-plugin-content-blog/17.md
similarity index 93%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/17.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/17.md
index 021a42813..9f8c3ee06 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/17.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/17.md
@@ -81,7 +81,7 @@ docker exec -it [container-id] bash
curl http://${your.host.name}:3306
```
-连接宿主机 MySQL 成功如图：
+连接宿主机 MySQL 成功如图：
```plain
# 查找geaflow-console java进程号
@@ -106,6 +106,6 @@ java -Xmx4096m -cp /opt/geaflow/boot/geaflow-console-bootstrap.jar:/opt/geaflow/
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/18.md b/i18n/zh-CN/docusaurus-plugin-content-blog/18.md
similarity index 97%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/18.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/18.md
index a0b2327ed..bf11c3002 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/18.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/18.md
@@ -21,7 +21,7 @@ date: 2023-10-16
弱联通分量图算法可以应用于许多实际问题，例如社交网络分析中的用户群体划分、网页链接分析中的网页群组划分等。它能够帮助我们理解图中不同分量之间的关系，从而更好地分析图的结构和特性。
-
+
## 在 TuGraph Analytics 上实现弱联通分量算法
@@ -169,6 +169,6 @@ public StructType getOutputType() {
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/19.md b/i18n/zh-CN/docusaurus-plugin-content-blog/19.md
similarity index 83%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/19.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/19.md
index 8ec4bcfdd..93a42b959 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/19.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/19.md
@@ -30,13 +30,13 @@ date: 2023-10-16
#### 点&边&图&表&函数
-
+
Geaflow 将所有研发资源进行了结构化的模型设计，从模型图中，可以看到 vertex，edge，table 都继承自 GeaflowStruct，GeaflowStruct 中包含一个 GeaflowField 列表，其中 GeaflowField 代表了字段，包含类型(Long，String，Boolean 等)和约束条件(点 id，属性，边源点 id，边目标点 id 等)。在图中，包含了点、边以及 Endpoint 的列表，描述了实体之间的关联信息。 图和表关联了 GeaflowPluginConfig，这是插件配置，表示图表的来源或输出配置，例如 odps，sls，oss 等。 函数中主要包含一个 jar 包对象和主类，以标识函数的入口。
#### 任务&作业
-
+
GeaflowJob 为所有任务类型的父类，其中的 structs、graphs、functions 字段记录了这个任务所使用的图、表、函数，方便用户了解作业关联的一些元信息。任务根据使用途径还可分为以下几种类型:
@@ -52,27 +52,27 @@ date: 2023-10-16
### 创建点
-在研发管理中新增点定义, 每个点有对应的字段列表，且必须有点 id 字段，如下例子中新增了 2 个点：person 和 software。
+在研发管理中新增点定义, 每个点有对应的字段列表，且必须有点 id 字段，如下例子中新增了 2 个点：person 和 software。
-
+
### 创建边
-在研发管理中新增边定义, 每条边需要有源点 id 和目标点 id 字段，如下例子中新增了 2 条边：knows 和 creates。
+在研发管理中新增边定义, 每条边需要有源点 id 和目标点 id 字段，如下例子中新增了 2 条边：knows 和 creates。
### 创建图
-在研发管理中新增图定义, 图可以关联之前定义的点和边，console 中通过选择框的方式进行关联。如下例子中，创建了名为 dy_modern 的图，其包含了 person 和 software 点、created 和 knows 边。同时，可以为图配置拓扑约束，限制此图上边的源点目标点的绑定关系，例如 create 边只能是 person->software, know 边只能是 person->person（Endpoint 具体作用将在后续文章中介绍）。
+在研发管理中新增图定义, 图可以关联之前定义的点和边，console 中通过选择框的方式进行关联。如下例子中，创建了名为 dy_modern 的图，其包含了 person 和 software 点、created 和 knows 边。同时，可以为图配置拓扑约束，限制此图上边的源点目标点的绑定关系，例如 create 边只能是 person->software, know 边只能是 person->person（Endpoint 具体作用将在后续文章中介绍）。
### 创建表
-在研发管理中新增表定义， 此例子中创建了一个输出表，为最终结果输出的载体，有 2 个字段 person 名字和 software 名字。其参数配置中的类型为 file，表示输出到本地文件目录(也可以选择其他类型，例如 kafka，hive)。
+在研发管理中新增表定义， 此例子中创建了一个输出表，为最终结果输出的载体，有 2 个字段 person 名字和 software 名字。其参数配置中的类型为 file，表示输出到本地文件目录(也可以选择其他类型，例如 kafka，hive)。
-
+
### 创建任务
-本示例中，构造如下关系图:
+本示例中，构造如下关系图:
任务 dsl 如下，先向图 dy_modern 中插入点边数据，然后执行 MATCH 遍历图，找到 id=1 的人（jim）认识的人（kate、tom）所创建的软件（software1、software2），最后将结果插入到 tbl_result 表（文件）中。
@@ -115,13 +115,13 @@ FROM (
)
```
-
+
-任务发布之后即可生成对应 task，进入作业详情界面，提交作业之后开始执行，最终运行完成。
+任务发布之后即可生成对应 task，进入作业详情界面，提交作业之后开始执行，最终运行完成。
-作业的参数配置如下, **注意 worker 数需要设置**:
+作业的参数配置如下, **注意 worker 数需要设置**:
-
+
在容器的/tmp/result 目录中找到结果文件。
@@ -151,6 +151,6 @@ tom, software2
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/2.md b/i18n/zh-CN/docusaurus-plugin-content-blog/2.md
similarity index 92%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/2.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/2.md
index dfc4502bf..bb3b3e5d5 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/2.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/2.md
@@ -15,7 +15,7 @@ date: 2023-06-16
-
+
现如今，免费的，蚂蚁集团图计算团队开源的超大规模流图处理系统——GeaFlow 正成为一款专注于图计算领域的开源数据处理工具。我们从一个简单的问题开始，让你体会 GeaFlow 的强大之处。
@@ -51,11 +51,11 @@ date: 2023-06-16
来看这个例子
-
+
图中有 7 个不同颜色的点代表交易账户，每个账户对应以太坊上的一个钱包地址。 一个账户转出到另一个账户的过程，表示为图中有方向的边，这个图中共有 8 笔交易构成一个交易网络。
-
+
将交易头尾相连，能够找到返回起点的循环，就可以视为循环交易。
@@ -63,7 +63,7 @@ date: 2023-06-16
可是，当一笔新的交易发生时——
-
+
可见，环路检测并不是一劳永逸的静态图算法。随着消息实时不断到来，交易网络图中的最新环路不断发生变化。 如果关心每一笔交易产生的交易环路，这将成为一个极其复杂的问题。
@@ -79,7 +79,7 @@ date: 2023-06-16
我们在 GeaFlow 新建一个图计算作业，只需大约 40 行代码，即可完成整个端到端流程。
-
+
代码描述如下，需要自取。
@@ -138,11 +138,11 @@ RETURN concat(CAST(v1.id as VARCHAR), '->', CAST(v2.id as VARCHAR),
打开一个 Kafka Producer，产生消息流，将交易不断发送给 Kafka，如左侧终端窗口所示。 平均 1 秒左右，最新的图中循环交易检出结果就打印在右侧的 Kafka Consumer 窗口中。
-
+
当添加一些新的交易日志时，右侧的 Kafka Consumer 窗口中也实时更新了新的循环交易检出结果，响应十分迅速。
-
+
以上便是开源图计算平台 GeaFlow 结合 Kafka，快速搭建的以太坊循环交易检出解决方案。 虽然这只是一个小小的 demo，但实机演示中强大的图计算语法和系统性能可见一斑，大大较低了我们普通人搭建图计算应用的难度和成本。
@@ -162,6 +162,6 @@ RETURN concat(CAST(v1.id as VARCHAR), '->', CAST(v2.id as VARCHAR),
### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/20.md b/i18n/zh-CN/docusaurus-plugin-content-blog/20.md
similarity index 87%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/20.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/20.md
index 1409b30fe..05005c2a9 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/20.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/20.md
@@ -38,7 +38,7 @@ date: 2023-10-23
这意味着下图中 GQL 和 SQL 两种描述都可以达到类似的效果，用户无需预先学习专业图查询语言，即可使用 SQL 驱动图计算。
-
+
GeaFlow DSL 引擎层支持了 SQL 中的 Join 自动转化为 GQL 执行，同时支持常用的 Project、Filter、Aggregate 等一系列 SQL 操作转为图计算执行。 用户可以自由混用 SQL 和 GQL 样式查询，同时做图匹配和表查询。
@@ -50,17 +50,17 @@ date: 2023-10-23
首先我们使用历史数据创建交易大图，命名为 ethereum_transaction_network。 接着把来自 Kafka 的实时交易流 table_new_trade 不断添加到命名为 ethereum_transaction_network 的图中。
-
+
每当有新的交易到达的时刻，系统都将触发一次 3 跳循环交易模式的检查， 把更新的结果存入位于 Kafka 的外部表 tbl_circular_trade，可以很方便地分发给下游组件。
打开一个 Kafka Producer，产生消息流，将交易不断发送给 Kafka，如左侧终端窗口所示。 最新的循环交易检出结果打印在右侧的 Kafka Consumer 窗口中。
-
+
当添加一些新的交易日志时，右侧的 Kafka Consumer 窗口中也实时更新了新的循环交易检出结果，响应十分迅速。
-
+
此案例中，GeaFlow 结合 Kafka 轻松搭建起交易听单->交易网络生成->实时循环交易检出->给下游发送消息完整的金融级实时解决方案。
@@ -70,21 +70,21 @@ date: 2023-10-23
在 GeaFlow Console 中新增图任务，任务类型选择“HLA”， 并上传 jar 包，其中 entryClass 为算法主函数所在的类。 点击“提交”，创建任务。
-
+
点击”发布”，可进入作业详情界面，点击“提交”即可提交作业。
-
+
运行的图查询均可在 Console 界面查看，方便回溯和管理，并且可在作业详情中查看运行详情，
-
+
### 使用案例四 自研图算法，嵌入 GQL 语言执行
用户可以基于 UDGA(User Defined Graph Algorithm)接口实现自定义图算法。 通过将 UDGA 上传至 console 平台，可以类似 SQL Function 的方式在 GQL 查询中调用。
-
+
用户可以在 GQL 图查询语句中嵌入图算法，使用方式如下所示：
@@ -111,13 +111,13 @@ Create funciton wcc as 'com.antgroup.geaflow.dsl.udf.graph.WeakConnectedComponen
- **Console 平台**：TuGraph Analytics 提供了一站式图研发平台，实现了图数据的建模、加工、分析能力，并提供了图作业的运维管控支持。
- **执行环境**：TuGraph Analytics 可以运行在多种异构执行环境，如 K8S、Ray 以及本地模式。
-
+
## Benchmark
我们模拟依次执行一跳、两跳和三跳关系运算的场景。足以见得，越是复杂的多跳关系计算，关系模型中 Join 的性能表现越差。在总时间对比中，利用图的 Match 计算能够节约超过 90%的耗时。
-
+
图 1
@@ -133,6 +133,6 @@ Create funciton wcc as 'com.antgroup.geaflow.dsl.udf.graph.WeakConnectedComponen
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/21.md b/i18n/zh-CN/docusaurus-plugin-content-blog/21.md
similarity index 91%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/21.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/21.md
index c840fe7bc..dcca9020e 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/21.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/21.md
@@ -17,7 +17,7 @@ date: 2023-11-16
### 插件模型设计
-
+
- GeaflowPlugin: 插件模型。
- GeaflowPluginType: 插件（数据源）类型（KAFKA、HIVE、JDBC、FILE 等)。
@@ -27,7 +27,7 @@ date: 2023-11-16
上文所述中，目前支持用户自定义 Connector 插件种类为 TABLE，即可在表配置中使用，作为表的输入或输出源，其插件类型为用户自定义。
-除此之外，在 GeaFlow Console 中，插件的概念更为广泛，还包含了一些系统级的插件，是 GeaFlow 作业运行所依赖的外部系统，例如运行时元信息插件(RUNTIME_META)、指标系统插件(METRIC)、外部文件系统插件(REMOTE_FILE)、外部图存储系统插件(DATA)，如下列表所示。由插件类型和插件种类可唯一确定一个插件，而插件类型和插件种类是多对多的关系，一个种类可能有多种类型，例如 REMOTE_FILE 种类的插件，其类型可以是 LOCAL、DFS、OSS，对应了不同的外部存储系统。
+除此之外，在 GeaFlow Console 中，插件的概念更为广泛，还包含了一些系统级的插件，是 GeaFlow 作业运行所依赖的外部系统，例如运行时元信息插件(RUNTIME_META)、指标系统插件(METRIC)、外部文件系统插件(REMOTE_FILE)、外部图存储系统插件(DATA)，如下列表所示。由插件类型和插件种类可唯一确定一个插件，而插件类型和插件种类是多对多的关系，一个种类可能有多种类型，例如 REMOTE_FILE 种类的插件，其类型可以是 LOCAL、DFS、OSS，对应了不同的外部存储系统。
### 插件引用解析
@@ -38,7 +38,7 @@ date: 2023-11-16
3. 获取引擎自带的插件列表。
4. 将 1 和 2 中的结果进行合并，过滤引擎自带的插件，得到最终 dsl 任务中用户使用的插件列表。
-
+
## Demo 演示
@@ -173,23 +173,23 @@ com.connector.myconnector.MyFileConnector
在 GeaFlow Console 页面，“插件管理”模块中新增插件，填写插件名称方便管理，上传 JAR 包。其中**“插件类型”字段需要和 JAR 包中自定义 Connector#getType 方法返回的值一致，并不能和已有插件重名。**
-
+
#### 创建表
创建 source 表，**在参数配置中，选择类型为自定义的插件类型，并填写相应的参数（如输入表数据路径，自定义的 suffix）**。
-
+
创建 sink 表：
-
+
#### 提交任务
创建 dsl 任务，直接在 dsl 中使用之前创建的 source 表和 sink 表。
-
+
```plain
insert into sinkTable select * from sourceTable;
@@ -218,6 +218,6 @@ test-source_4,"alice",21_test-sink
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/22.md b/i18n/zh-CN/docusaurus-plugin-content-blog/22.md
similarity index 92%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/22.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/22.md
index bb5db44a2..87e3cf851 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/22.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/22.md
@@ -27,11 +27,11 @@ $ ./build-operator.sh
$ helm install geaflow-kubernetes-operator helm/geaflow-kubernetes-operator
```
-
+
- 在 K8S Dashboard 中查看 pod 是否正常运行。
-
+
### 提交作业
@@ -163,9 +163,9 @@ spec:
$ kubectl get geaflowjob geaflow-example
```
-
+
-
+
若在提交过程中失败，则状态会变为 FAILED。若需定位原因，可通过以下命令查看。
@@ -177,7 +177,7 @@ $ kubectl get geaflowjobs geaflow-example -o yaml
Operator 自带一个前端页面，可以展示集群的基本信息、所有作业的状态、错误信息、以及完整的配置，并做了分类统计。可以通过访问 Operator 的 service 或者 pod 的 8089 端口来打开页面。
-
+
**备注**：
@@ -201,6 +201,6 @@ $kubectl port-forward ${operator-pod-name} 8089:8089
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/23.md b/i18n/zh-CN/docusaurus-plugin-content-blog/23.md
similarity index 93%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/23.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/23.md
index 117acef8c..75e1f8a47 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/23.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/23.md
@@ -7,7 +7,7 @@ date: 2023-12-11
-
+
LDBC 官方公布蚂蚁 LDBC SNB-BI 测评新纪录
@@ -29,6 +29,6 @@ _本次测试由 LDBC 官方审计完成
#### 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/24.md b/i18n/zh-CN/docusaurus-plugin-content-blog/24.md
similarity index 92%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/24.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/24.md
index 80bda2a95..5b4bb418d 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/24.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/24.md
@@ -15,7 +15,7 @@ _百艺通，不如一艺精_
在设计数据存储引擎时，需要考虑众多因素。例如，所应用的具体场景，是联机分析处理(OLAP)还是联机事务处理(OLTP)；再如，数据存储方式的选择，内存、本地硬盘或分布式存储；还有就是存储数据的格式，像是文档、JSON，宽表，对象，键值对等。图存储引擎是诸多数据存储引擎中的一种，它专门用于图数据的存储。从 DB-Engines 网站的统计来看，Graph DBMS 的热度从 2014 后一直领先其他类型数据库。
-
+
根据图数据存储方式的不同，现有的图存储引擎主要分为下面几大类：
@@ -32,13 +32,13 @@ _百艺通，不如一艺精_
点边数据进入到 CStore 之后，把点边起始点 ID 转化为从 0 开始的 ID，这个过程称之为 ID 化。由于用户定义的起始点 ID 格式不固定，蚂蚁内部使用的起始点通常大于 20bytes，转化为 4 个 bytes ID 后，可以极大减少索引内存消耗；另外规范化 ID 之后，CStore 使用 array 来做主键索引，array 的 index 为 ID，查询效率为 O(1)。
-
+
ID 化之后，点边数据被序列化为 PrimaryKey 和 GraphData，GraphData 由 SecondKey 和 Property 组成。PrimaryKey 记录点边 ID，SecondKey 记录图元数据，Property 记录点边属性数据。
SecondKey 编码格式如下，target id 大小不固定，其他部分消耗 20 bytes。write ts 字段记录数据写入时间，被用于数据淘汰，sequence id 记录了数据写入顺序，transaction 和 compaction 都会用到。graph info 记录是否是点，是否是入边，是否包含属性，标签，其他 meta, 点边时间属性等信息。
-
+
这样编码有两点好处：
@@ -61,11 +61,11 @@ _百艺通，不如一艺精_
1. 数据聚合。把相同的 src_id 的点边数据聚合到一起存储。
2. 排序。按照用户指定顺序把相同 src_id 的点边数据排序，用于构建二级索引。
-
+
GraphData Segment 到达阈值之后被刷入到磁盘，数据被刷入到磁盘之前，把具有相同类型，写入时间（通常以天为单位）的数据作为一个分区写入到连续的物理存储空间，每个分区之间数据互相独立。
-
+
再者根据点边数据属性大而元数据固定的特点，CStore 采用了属性分离的架构，把图属性和图元数据分离存储到不同的物理存储空间。一方面对于图元数据单独加索引能够加速图查询性能，另外一方面属性分离也能够减少数据 compaction 的读写放大开销。
@@ -75,23 +75,23 @@ _百艺通，不如一艺精_
CStore 具有高效的图数据检索能力，支持多维度索引，不仅提供针对图元数据的分区索引，主键索引和二级索引，还支持针对点边属性的全文索引，可以根据指定的条件快速定位和返回数据。
-
+
GraphData Segment 写入到磁盘之前，把相同起始点 ID 的 GraphData 根据用户指定的顺序排序，然后把排序好的 SecondKey 构建索引，把排序好的 Property 直接写入到属性文件（记为 vs 文件）。
CStore 的分区索引对应到磁盘中某个目录，不同的分区数据落在不同的目录。主键索引是稀疏索引，默认索引间隔为 2048，目前仅支持以起始点 ID 构建主键，主键索引常驻内存。通过主键索引，可以快速定位到属性存储的文件 id 和 offset。
-
+
二级索引包括 min max 索引，bloom filter 索引等，用于快速判断某个稀疏索引块是否包含某个主键。min max 索引记录某个索引块的上界和下界，bloom filter 记录索引块的主键。
对于热点数据，二级索引做了特殊支持，比如一个起始点 ID 对应了 10 亿条边，如果没有索引，需要把满足 min max 和 bloom filter 索引的所有边读到内存过滤一次，返回用户指定的数据。为了加速这种场景，CStore 对点边类型，指向，写入时间加了二级索引。比如用户只想要读取 label 为 student，dt 为 2023-10-1 数据，通过二级索引，首先过滤掉所有 label 非 student 的数据，然后过滤掉 dt 非 2023-10-1 的数据，可以极大减少数据读开销，提升用户查询性能。
-
+
构建完索引，数据写入到索引文件（记为 is 文件），is 文件按照 LSM-Tree 结构组织，key 为主键索引中的 index，value 为索引 block 压缩后的数据。is 文件内部对于 key 有序，第 0 层单个文件内部对于 key 有序，其他层文件间对于 key 有序。
-
+
为了加快 LSM-Tree compact 的性能，CStore 支持单层的多线程 compact。在示意图中，每一个单独的 compactor 都代表一个 compact 工作线程。不同的 compactor 线程和 compact 清理线程（负责清理被 compact 的文件)将会并行执行。
@@ -102,7 +102,7 @@ _百艺通，不如一艺精_
3. 将上述收集到的文件进行 compact 并生成新的文件；
4. 最后一步是将新的文件更新至 LSM-Tree 及内存索引中。
-
+
## 编译构建
@@ -179,6 +179,6 @@ Targets:
**微信群**
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/27.md b/i18n/zh-CN/docusaurus-plugin-content-blog/27.md
similarity index 93%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/27.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/27.md
index 3990f4846..8b0d9b919 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/27.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/27.md
@@ -3,7 +3,7 @@ title: "Stream4Graph：动态图上的增量计算"
date: "2025-3-11"
---
-
+
> 作者：张奇
@@ -23,7 +23,7 @@ date: "2025-3-11"
- 网页：节点代表网页，边代表超链接。
- 交通网络：节点代表城市，边代表道路或航线。
-
+
图本身代表了节点与节点之间的链接关系，而针对这些关系，我们可以利用图中的节点和边来进行信息处理、分析和挖掘，帮助我们理解复杂系统中的关系和模式。在图上开展的计算活动就是图计算。图计算有很多应用场景，比如通过社交网络分析可以识别用户之间的联系，发现社群结构；通过分析网页间的链接关系来计算网页排名；通过用户的行为和偏好构建关系图，推荐相关内容和产品。
@@ -31,7 +31,7 @@ date: "2025-3-11"
我们就以简单的社交网络分析算法，弱联通分量（Weakly Connected Components， WCC）为例。弱联通分量可以帮助我们识别用户之间的“朋友圈”或“社区”，比如某个社交平台上，一群用户通过点赞、评论或关注形成一个大的弱联通分量，而某些用户可能没有连接到这个大分量，形成更小的弱联通分量。
-
+
如果仅仅针对上面这张小图来构建弱联通分量算法，那么非常简单，我们只需要在个人 PC 上构建简单的点边结构然后走图遍历即可。但如果图的规模扩展的千亿甚至万亿，这时就需要用到大规模分布式图计算引擎来处理了。
@@ -80,13 +80,13 @@ date: "2025-3-11"
总的来说，用户首先需要将存储介质中原始的表结构数据转换为 GraphX 中的点边数据类型，然后交给 Spark 进行处理，这是针对静态图进行离线处理。但是我们知道，现实世界中，图数据的规模和数据内节点之间的关系都不是一成不变的，并且在大数据时代其变化非常快。如何实时高效的处理不断变化的图数据（动态图），是一个值得深思的问题。
-
+
## 3. 动态图计算：Spark Streaming
针对动态图的处理，常见的解决方案是 Spark Streaming 框架，它可以从很多数据源消费数据并对数据进行处理。它是是 Spark 核心 API 的一个扩展，可以实现高吞吐量的、具备容错机制的实时流数据的处理。
-
+
如上图所示是 Spark Streaming 对实时数据进行处理的流程。首先 Spark 中的每个 Receiver 接收到实时消息流后，对实时消息进行解析和切分，之后将生成的图数据存储在每个 Executor 中。每当数据累积到一定的批次，就会触发一次全量计算，最后将计算出的结果输出给用户，这也称之为基于快照的图计算方案。
@@ -106,13 +106,13 @@ date: "2025-3-11"
这里以 WCC 算法为例，对联通分量算法而言，在一个时间窗口内每条边对应的 src id 和 tar id 对应的顶点会被激活，第一次迭代需要将其 id 信息通知其邻居节点。如果邻居节点收到消息后，发现需要更新自己的信息，那么它需要继续将更新消息通知给它的邻居节点；如果说邻居节点不需要更新自己的信息，那么它就不需要通知其邻居节点，它对应的迭代终止。
-
+
## 5. GeaFlow 架构简析
GeaFlow 引擎主要由三大主要部分组成，DSL、Framework 和 State，同时向上为用户提供了 Stream API、静态图 API 和动态图 API。DSL 主要负责图查询语言 SQL+ISO/GQL 的解析和执行计划的优化，同时负责 schema 的推导，也向外部承接了多种 Connector，比如 hive、hudi、kafka、odps 等。Framework 层负责运行时的调度和容灾，shuffle 以及框架内各个组件的管理协调。State 层负责存储底层图数据和数据的持久化，同时也负责索引、下推等众多性能优化工作。
-
+
## 6. GeaFlow 性能测试
@@ -204,7 +204,7 @@ RETURN vid, component
下图是对两者进行联通分量算法实验时得到的实验结果。以 50w 条数据为一个窗口进行迭代计算，Spark 中存在大量的重复计算，因为其还要回溯全量的历史数据进行计算。而 GeaFlow 只会激活当前窗口中涉及到的点边进行增量计算，计算可在秒级别完成，每个窗口的计算时间基本稳定。随着数据量的不断增大，Spark 进行计算时所需要回溯的历史数据就越多，在其机器容量没有达到上限的情况下，其计算时延和数据量呈正相关分布。相同情况下 GeaFlow 的计算时间也会略微增大，但基本可以在秒级别完成。
-
+
## 7. 总结
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/28.md b/i18n/zh-CN/docusaurus-plugin-content-blog/28.md
similarity index 91%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/28.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/28.md
index 47d1d328a..86401fb1c 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/28.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/28.md
@@ -3,7 +3,7 @@ title: 流图计算之增量match原理与应用
date: 2025-6-3
---
-
+
## 问题背景
@@ -13,14 +13,14 @@ date: 2025-6-3
GQL（Graph Query Language）是国际标准化组织（ISO）为标准化图查询语言所制定的一个标准，用于在图上执行查询的语言。Geaflow 是蚂蚁图计算团队开源的流图计算引擎，专注于处理动态变化的图数据，支持大规模、高并发的实时图计算场景。本文将介绍在 Geaflow 引擎中，对增量图使用 GQL 进行增量 Match 的方法，目的尽可能地只对增量的数据进行查询，避免冗余的全量计算。
-
+
## 当前问题
Geaflow 引擎基于点中心框架（vertex center），通过迭代的方式，每一轮迭代中，每个点向其他点发送消息，并在下一轮收到消息时进行处理、分析。在 Geaflow 的框架中，GQL 的查询需要从前往后进行 Traversal 遍历走图，即从起始节点开始出发，进行扩散，依次进行点边匹配，直到匹配到所需要的查询 pattern。在动态图里场景，如果只使用当前批次新增的点边触发计算，增量的结果会有缺失，例如下面例子所示。
-
如上问题关键在于如果只考虑增量的部分，则点 A1 无法触发计算，但是点 A1 实际包含于增量结果中。所以需要设法让点 A1 参与计算，我们考虑一种从新增点扩充子图的方法，将 a 触发。将整个查询分为 2 个阶段，Evolve 扩展阶段和 Traversal 阶段。在 Evolve 阶段中，从起始点开始，向邻居发送 EvolveMessage，后续的 iteration 中，收到 EvolveMessage 的点加入到 EvolveVertices 集合中。而后的 Traversal 阶段则会使用 EvolveVertices 里的点触发遍历，即表示当前窗口的触发点。
@@ -28,7 +28,7 @@ date: 2025-6-3
整体流程示例图如下：
-
+
1. 首先得到 query 的计划的迭代次数 N，需向外扩充 N-1 度(maxEvolveIteration=N-1)，即可覆盖当前 query。框架的最大迭代数将设置为 N + maxEvolveIteration（N>2）
@@ -74,7 +74,7 @@ public void compute(Object vertexId, Iterator messageIterator) {
具体示例如下：
-
+
总结进行 Evolve 扩展的条件：
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/29.md b/i18n/zh-CN/docusaurus-plugin-content-blog/29.md
similarity index 99%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/29.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/29.md
index c311f5a62..aeb5ed770 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/29.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/29.md
@@ -114,7 +114,7 @@ date: 2025-6-25
假设某社交平台希望实现一个功能：实时追踪用户的“间接好友关系”，即分析用户 A 是否通过某个共同好友 B 认识了另一个用户 C，并确保这种认识关系的时间顺序是合理的（A 先认识 B，B 再认识 C）。这一功能可以帮助平台发现潜在的社交圈层，优化好友推荐算法，同时为风险控制提供数据支持。
-
+
具体需求
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/3.md b/i18n/zh-CN/docusaurus-plugin-content-blog/3.md
similarity index 93%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/3.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/3.md
index 358dfe0f4..5f4c9b3bc 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/3.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/3.md
@@ -13,7 +13,7 @@ date: 2023-06-21
-
+
图片注：GeaFlow 为蚂蚁流式图计算引擎 TuGraph Analytics 内部代号，本文将沿用论文中所用 “GeaFlow”，便于读者对应。 图片项目代码地址：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
@@ -33,7 +33,7 @@ date: 2023-06-21
不同于图数据库，Geaflow 解决的问题是高吞吐场景下复杂的图分析和计算问题，例如深度图遍历、子图匹配、全图分析等。Geaflow 使用流式事件驱动的方式进行计算和查询，同时利用查询优化技术进行查询合并和加速。下面我们来描述下 Geaflow 的运行场景。
-
+
（图 1）
@@ -45,7 +45,7 @@ date: 2023-06-21
为了支持以上的场景，Geaflow 做了如下的架构设计：
-
+
（图 2）
@@ -79,7 +79,7 @@ date: 2023-06-21
GeaFlow 针对典型流式图场景，对于基于通用路计算引擎基于 Join 来实现的方式，吞吐显著提升。
-
+
（图 3）
@@ -87,7 +87,7 @@ date: 2023-06-21
在图 4 中我们看到随着批次中并发的查询数据量增大，执行时间增加的并不会特别明显。可以发现融合 40 个 query 的时间只增加了 22.7%，达到 32.6 倍的提速效果。
-
+
（图 4）
@@ -111,6 +111,6 @@ date: 2023-06-21
## 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/30.md b/i18n/zh-CN/docusaurus-plugin-content-blog/30.md
similarity index 93%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/30.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/30.md
index 8c74cbba1..874a4b2a9 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/30.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/30.md
@@ -3,7 +3,7 @@ title: Join性能变革：图数仓让SQL分析快人一步
date: 2025-5-15
---
-
+
> 作者：林力韬
@@ -16,7 +16,7 @@ date: 2025-5-15
-
+
**图 1 SQL Join 与 GQL 图 hop 查询性能差异示例**
@@ -28,7 +28,7 @@ date: 2025-5-15
**创新枷锁**：业务分析师因需要学习 GQL（图查询语言）而放弃采用图技术栈。工具链的割裂导致图分析能力始终停留在技术部门，难以赋能业务前线。
-
+
**图 2 Join 与 GQL 表达示例**
@@ -62,9 +62,9 @@ date: 2025-5-15
**第三阶段，组装成图。**即将所有点合并在一起，绑定在起始点上的边自然合并，对端点可选地进行绑定。对两个有差异的转图方案方案，可以计算差异向量，即所有表映射到实体的变化情况。
-
+
-
+
**图 3 ER 图转图 Schema 示例组图**
@@ -78,7 +78,7 @@ date: 2025-5-15
数据通道能力面向主流大数据生态系统，可深度集成 ODPS/Hive/Paimon 等基础设施，通过三层架构实现全生命周期数据管理：在数据接入层，自动捕获表的变化，产出物化方案，同步表-图实体映射的增量部分，当前可管理 10TB 级别图数据；在转换引擎层，全自动化生成导数的 DSL 任务编排，调度到集群执行；在存储优化层，支持 CStore/GraphDB/RocksDB 等自研或开源图存储解决方案，实践中已经过万亿级超大业务图的检验。此外，查询热数据预加载可根据图的实际使用情况，在 TB 级数据规模下仍能维持秒级查询相应，真正实现从表数仓到图数仓的全栈切换，SQL 之下全为图。
-
+
**图 4 开源技术架构一张大图**
@@ -90,7 +90,7 @@ date: 2025-5-15
对比传统 SQL 查询，可能需通过 3 层表关联分析用户关联关系，响应时间在分钟级别。而图路径查询直接通过图的遍历语句实现，响应时间缩短至秒级。目前该引擎已在短视频分析、会员用增、客权服务等典型业务场景得到验证，未来将持续扩展对复杂子查询、复杂表达式运算的支持，让更多开发者无需跨越技术鸿沟即可解锁图计算的强大能力。
-
+
**图 5 SQL 抽象语法树 AST 翻译为 GQL 结构的差异示例**
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/31.md b/i18n/zh-CN/docusaurus-plugin-content-blog/31.md
similarity index 93%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/31.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/31.md
index 2d097d46b..2b7980b9e 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/31.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/31.md
@@ -3,7 +3,7 @@ title: Graph4Stream：基于图的流计算加速
date: 2025-3-25
---
-
+
> 作者：坤羽；审校：东朔。
@@ -27,7 +27,7 @@ date: 2025-3-25
Flink 是经典的基于表的流处理引擎，他将输入的数据流切分成微批，每次计算当前批次的数据。在计算过程中，Flink 将计算任务翻译成由 map、filter、join 等基础算子组成的有向图，每个算子都有他的上游输入和下游输出。增量数据经过所有算子的计算后输出当前批次的结果。
-
+
Flink 增量计算
@@ -76,7 +76,7 @@ ON `e`.`dst` = `v`.`vid`;
他的执行计划如下图所示，他由 Aggregate、Calc、Join 等算子组成，数据流经每个算子最终得到增量结果。核心算子 join 实现了关联关系的查找，我们来详细分析 Join 算子的实现方式。
-
+
Flink 执行计划
@@ -88,7 +88,7 @@ ON `e`.`dst` = `v`.`vid`;
join 计算主要的性能瓶颈就在遍历 RightStateView。LeftStateView 和 RightStateView 实际上存储 join 的左表和右表。随着数据不断输入，StateView 中的数据量持续膨胀，最终导致遍历的耗时急剧上升，严重影响系统性能。
-
+
Flink Join 算子实现
@@ -98,7 +98,7 @@ Flink Join 算子实现
图计算是一种基于图数据格式的计算范式，其中图 G(V,E)由点集合 V 和边集合 E 构成，边代表了数据之间的关联关系。以公开数据集 web-Google 为例，其中每一行数据由两个数字组成，代表了两个页面之间的跳转关系。如下图所示，左侧是原始数据，常规的数据建模方式是建立一张包含两列数据的表，而图的建模方式是将网页作为点，将页面的跳转关系作为边，构成一张跳转网络图。在表的建模方式中，关联关系的计算是通过表的 join 实现的，join 需要遍历左表或者右表。而在图计算中，关联关系被直接存储在边中，省去了遍历的过程。
-
+
表建模 vs. 图建模
@@ -110,7 +110,7 @@ Flink Join 算子实现
GeaFlow 引擎的计算流程分为流数据输入、分布式增量图计算、增量结果输出几个部分。和传统的流计算引擎一样，输入的实时数据按照窗口被切分成微批。对于当前批次的数据，先按照建模策略解析成点边构成增量图。增量图和之前数据构成的历史图一道组成完整的流图。计算框架在流图上应用增量图算法得到增量结果输出，最后把增量图添加到历史图中。
-
+
GeaFlow 增量计算
@@ -120,7 +120,7 @@ GeaFlow 引擎的计算流程分为流数据输入、分布式增量图计算、
下图是两跳场景的描述。在第一轮迭代，增量边 B->C 分别构建入向路径和出向路径，将他们分别发送给点 B 和点 C。在第二轮迭代，B 收到入向路径，并加上当前点的入边形成 2 跳入向路径，发送给点 B。同样点 C 也收到出向路径，加上当前的出边形成 2 跳出向路径，发送给点 B。最后一轮迭代在 B 点将收到的出向和入向路径整合成新增的路径。可以看到，和 Flink 中需要查找所有的历史关系不同，GeaFlow 采用基于流图的增量图算法，计算量和图中的增量路径成正比。
-
+
两跳增量路径计算
@@ -193,7 +193,7 @@ RETURN ret
实验结果如图所示，横坐标是分别是一跳关系、两跳关系、三跳关系、四跳关系，纵坐标是处理完所有数据的耗时，采用对数指标。可以看到在一跳、两跳场景中，Flink 的性能要好于 GeaFlow，这是因为在一跳、两跳场景中参与 join 计算的数据量比较小，join 需要遍历的左表和右表都很小，遍历本身耗时短，而且 Flink 的计算框架可以缓存 join 的历史计算结果。但是到了三跳、四跳场景时候，由于计算复杂度的上升，join 算子需要遍历的表迅速膨胀，带来计算性能的急剧下降，甚至四跳场景超过一天也无法完成计算。而 GeaFlow采用基于流图增量图算法，计算耗时只和增量路径相关，和历史的关联关系计算结果无关，所以性能明显优于 Flink。
-
+
k-Hop 计算性能对比
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/32.md b/i18n/zh-CN/docusaurus-plugin-content-blog/32.md
similarity index 95%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/32.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/32.md
index fc5575b53..8cb11555e 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/32.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/32.md
@@ -31,7 +31,7 @@ date: 2025-4-3
当前 GeaFlow 的存储架构图如下。
-
+
@@ -77,7 +77,7 @@ ORDER BY s.id, targetId
为了避免堆外内存浪费或者过度使用，GeaFlow 对各模块的堆外内存使用统一管理。内存主要分 3 个部分：shuffle、state 和 default。 Default 是预留空间，可动态被 shuffle 或者 state 模块占用。 如下图所示：
-
+
state 和 shuffle 默认独占 10%的堆外内存， default 则占用 80%。
@@ -127,7 +127,7 @@ LogicalProject(a_id=[$0.id], weight=[$1.weight], b_id=[$2.id])
- 支持增量匹配逻辑，通过反向传播来扩展每次 window 新增数据的触发起点。
-
+
- 通过在 dsl 或高阶代码中设置`geaflow.dsl.graph.enable.incr.traversal`参数为 true 开启增量计算逻辑。
@@ -162,4 +162,4 @@ QueryTester.build()
-
+
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/33.md b/i18n/zh-CN/docusaurus-plugin-content-blog/33.md
similarity index 95%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/33.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/33.md
index a668d4a5d..36f183724 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/33.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/33.md
@@ -12,7 +12,7 @@ date: 2024-5-24
在计算机科学中，图是一种表示实体（节点或顶点）以及实体之间关系（边）的数据结构。图模型可以天然地描述网络结构，能更清晰地表达复杂的数据关系和依赖，简化关联数据的理解和分析。在不同的场景下，图中点边具备不同的语义信息。比如在资金交易场景下，每个人可以抽象成一个点表示，人与人之间的转账关系可以抽象成一条边表示。如下图，通过图数据模型反映出各个实体之间的资金往来关系，让数据的关联分析更加直观和高效。
-
+
资金交易图谱示例
@@ -20,7 +20,7 @@ date: 2024-5-24
图迭代算法解决了经典的图计算问题，但随着业务需求的复杂度提升，基于迭代的图算法存在着表达能力不足、自适应性能力差、异质图处理难度大等缺点。近年来随着深度学习的研究和应用的发展，以图神经网络（Graph Neural Networks，GNNs）为代表的一类神经网络算法，被设计用来捕获图中实体（节点）和关系（边）间的复杂模式。图神经网络能够结合节点特征和图的结构来学习节点和边的表示，相比之下，传统的迭代图算法通常不会直接从原始特征中学习，而更多地专注于结构特征。依赖于深度学习的天然优势，GNNs 具有更强的表示学习能力，可以自动从数据中学习复杂的模式，这使得 GNNs 能够更好地处理多任务学习和迁移学习等问题。在社交网络分析、知识图谱、生物分子网络、推荐系统以及交通网络等领域，得到广泛应用。
-
+
GNN 算法示意
@@ -37,7 +37,7 @@ date: 2024-5-24
众所周知，在深度学习为代表的数据科学领域，Python 已经成为数据分析、模型训练和推理框架的主流开发语言，并提供了丰富的开发库和框架生态。而以 Hadoop 全家桶为代表的大数据计算引擎领域，基于 Java 语言开发的系统仍占据一席之地，当然 GeaFlow 也在其中。这种语言差异带来的“互操作性”成本，使得相当一部分大数据和 AI 生态组件无法轻松地融合，这也是 GeaFlow 支持图推理需要亟待解决的问题。
-
+
Java 与 Python 的生态融合
@@ -91,7 +91,7 @@ date: 2024-5-24
在 GeaFlow 模型推理系统的架构设计中，核心部分是通过 C++原生语言建立起来的一座桥梁，实现 Python 环境和 Java 虚拟机之间高效的数据交互和操作指令的传递。通过使用 C++作为媒介语言，我们不仅能够利用其接近硬件的执行效率，确保数据交互的性能，还能够保证在两个虚拟环境之间数据交换的计算精度和稳定性。基于共享内存的设计允许 Python 和 JVM 进程各自独立运行，既保证了运行环境的安全隔离，又能实现数据的高效共享。
-
+
GeaFlow 模型推理系统设计
@@ -101,7 +101,7 @@ date: 2024-5-24
如图所示，由流式数据源源不断的触发图迭代计算与模型推理工作。GeaFlow提供了 DeltaGraphCompute 计算接口，用户可自主定义增量图数据的处理逻辑，并更新历史的图存储(Graph Store)。通过 GeaFlow模型推理系统，增量图迭代的中间计算结果，经过推理前置数据处理接口，并基于共享内存的跨进程通信方式，将处理后的数据流输入到推理进程，完成推理工作后的结果参与后续图迭代计算逻辑。下文将详细介绍各个数据接口的使用。
-
+
流图推理工作流程
@@ -111,13 +111,13 @@ date: 2024-5-24
在每个 worker 工作节点下，按照不同的推理作业级别划分基础的虚拟环境，从而保证一个 wroker 节点也可以支持不同推理任务，支持标准的 requirements.txt 管理推理依赖库。
-
+
单机虚拟环境
在图迭代计算进程和推理进程之间通过数据队列实现双边数据的交互，通过在数据包的头文件中插入参数个数，长度等信息，推理进程在连续若干次收到空消息包后，将自动进入睡眠状态，释放 cpu 等资源。图迭代计算进程调用推理接口时，推理进程将快速退出睡眠状态，接收输入数据并完成推理流程。
-
+
跨进程数据交互格式
@@ -125,7 +125,7 @@ date: 2024-5-24
对于推理数据的交换部分，底层通过 C++开发共享内存管理模块，实现两个进程之间的数据交互。在推理初始化阶段，由 InferenceContext 对象开辟进程共享内存，Java 进程负责创建并初始化推理（Python）进程，通知推理进程共享内存的地址信息，并映射到相应的进程。如图，Java 进程和推理进程均采用 C++作为桥梁语言，实现共享内存中数据的流动操作。
-
+
跨进程数据通信架构
@@ -141,7 +141,7 @@ date: 2024-5-24
如图所示，我们对比了多种 Python 调用 C 链接库的方案，性能是第一要素，因此选择 Cython 作为推理进程和底层内存交互的工具。Cython 是一个编程语言，是 Python 语言的一个超集，它将/C++的静态类型系统融合在了 Python 中，允许开发者可以在 Python 代码中直接使用 C 语言的特性，从而提高程序的执行效率。Cython 将 Python 源代码翻译为 C 或 C++代码，然后将其编译为二进制代码，能够显著提高数值计算和循环场景的代码执行性能。
-
+
Python 调用 C 链接库方案性能对比
@@ -315,7 +315,7 @@ public static class PRVertexCentricComputeFunction implements
在 Console 作业管理平台创建一个 HLA 任务，上传图迭代计算 jar 包，模型文件和依赖管理文件。
-
+
创建图推理作业
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/34.md b/i18n/zh-CN/docusaurus-plugin-content-blog/34.md
similarity index 81%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/34.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/34.md
index dcdb2e0ba..2ce47d23f 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/34.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/34.md
@@ -10,7 +10,7 @@ date: 2024-1-4
## OLAP 架构
-
+
OLAP 架构
@@ -26,7 +26,7 @@ date: 2024-1-4
组件间执行流程如下：
-
+
OLAP 流程
@@ -36,7 +36,7 @@ date: 2024-1-4
以下图为例，图中有 2 种点 person 和 software，以及 2 种边 knows 和 creates。
-
+
图模型
@@ -106,7 +106,7 @@ SELECT 3,4,8;
图作业需要的 worker 数为 23，在作业界面将参数进行修改，之后提交作业运行。
-
+
Worker 数配置
@@ -114,7 +114,7 @@ SELECT 3,4,8;
创建图查询服务, 任务类型选择“图查询”，目标图选择刚才创建的图。
-
+
创建查询服务
@@ -124,13 +124,13 @@ SELECT 3,4,8;
图查询服务的作业变成 RUNNING 状态后，可在任务界面点击“查询”进入图查询界面
-
+
进入图查询
输入相应的 gql 查询语句，点击“执行”，即可得到查询结果。
-
+
执行图查询
@@ -138,13 +138,13 @@ SELECT 3,4,8;
点击某个点，可以查看点关联的具体信息和属性，以及关联的其他点边。
-
+
点边视图
除了可视化的方式，也可以 json 形式看到返回的结果。
-
+
JSON 视图
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/35.md b/i18n/zh-CN/docusaurus-plugin-content-blog/35.md
similarity index 80%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/35.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/35.md
index e65ba1eab..9523538a0 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/35.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/35.md
@@ -23,7 +23,7 @@ date: 2024-2-4
类似传统数据库表的 INSERT 操作，图数据集成则是向图的点边表插入数据。图中的点边也是一种表结构，每个点边都有相应的属性（对应表结构中的字段），并可以与数据源的表字段一一映射。所以可以通过给定外部输入表和目标点边的映射关系来描述图数据集成任务。
-
+
表图字段映射
@@ -75,7 +75,7 @@ from ${insert.tableName};
本示例中以下图为例，图中有 2 种点 person 和 software，以及 2 种边 knows 和 creates。
-
+
图模型
@@ -83,11 +83,11 @@ from ${insert.tableName};
在界面中创建 person 和 software 点的 schema。
-
+
创建 person 点
-
+
创建 software 点
@@ -95,11 +95,11 @@ from ${insert.tableName};
在界面中创建 creates 和 knows 边的 schema。
-
+
创建 creates 边
-
+
创建 knows 边
@@ -107,11 +107,11 @@ from ${insert.tableName};
界面中勾选图所需的点边，创建图的 schema， 类型设置为“ROCKSDB”。
-
+
创建图
-
+
配置图
@@ -119,11 +119,11 @@ from ${insert.tableName};
在界面中创建输入表 t_person、t_software、t_creates、t_knows，参数配置中填写对应的文件路径，以 t_person 为例：
-
+
创建输入表
-
+
配置输入表
@@ -154,19 +154,19 @@ from ${insert.tableName};
在新增图任务中，任务类型选择"集成"，并选择对应的目标图，即自动生成待插入的所有目标点边和字段项。（可根据需求删除不需要插入的目标点边或字段）
-
+
选择点边
只需在左侧选择每个点边对应的输入表，即可自动填充映射字段。
-
+
选择输入表
所有输入表选择完成后，所有表到目标点边的映射项都填充完成，点击"提交"即可创建集成任务。
-
+
配置字段映射
@@ -174,7 +174,7 @@ from ${insert.tableName};
任务发布为作业后，可在作业详情界面看到自动生成的构图 DSL 代码，点击提交执行图数据集成作业。
-
+
提交作业
@@ -182,7 +182,7 @@ from ${insert.tableName};
创建相应的图查询任务，详细见《GeaFlow 交互式图查询：让图所见即所得》[1]，运行后进入查询界面，即可查询到所构图的数据。
-
+
图查询
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/36.md b/i18n/zh-CN/docusaurus-plugin-content-blog/36.md
similarity index 79%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/36.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/36.md
index 32031846d..d940fbff1 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/36.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/36.md
@@ -26,7 +26,7 @@ date: 2024-1-8
页面的服务部署在 master 组件上，因此直接访问 master 组件的地址即可（默认端口 8090）。
-
+
访问 Dashboard
@@ -38,7 +38,7 @@ date: 2024-1-8
Overview 页面会展示整个作业的健康状态。你可以在这里查看 container 和 driver 是否都在正常运行。
-
+
概览
@@ -48,13 +48,13 @@ date: 2024-1-8
作业的执行计划可以由多个 Pipeline 表示，每个 Pipeline 内部又有多个 Cycle。可以通过侧边栏的 Pipeline 菜单进入页面。页面包括作业的每一项 Pipeline 的名称、开始时间和耗时。耗时为 0 表示该 Pipeline 已开始执行，但尚未完成。
-
+
执行计划-Pipeline
点击 Pipeline 名称可以进入二级菜单，查看当前 Pipeline 下所有的 Cycle 列表的各项信息。
-
+
执行计划-Cycle
@@ -62,13 +62,13 @@ date: 2024-1-8
可以查看作业的各个组件（包括 master、driver、container）的各项信息。可以通过侧边栏的菜单进行访问。其中 Driver 详情展示所有 driver 的基础信息。
-
+
Driver 信息
Container 详情展示所有 Container 的基础信息。
-
+
Container 信息
@@ -80,7 +80,7 @@ date: 2024-1-8
展示完整的容器进程指标。
-
+
进程
@@ -88,7 +88,7 @@ date: 2024-1-8
展示容器进程内的主要可见日志。根据日志的 log4j 配置，默认日志文件大小最大为 128G（此处测试简单起见设置为了 50KB），超过后会进行文件备份。例如 master.log.1 和 master.log.2 就是 master.log 的备份之一。
-
+
日志
@@ -99,7 +99,7 @@ date: 2024-1-8
点击任意一个日志可以进入日志详情页面。日志的获取进行了后端分页，可以在右下角选择每页的 KB 大小，并可以跳转到指定页数。
-
+
日志详情
@@ -110,17 +110,17 @@ date: 2024-1-8
- 火焰图类型：可选 CPU 或者 ALLOC（Memory）。
- 执行时间：分析时间，需介于 1~60 秒之间。
-
+
新建火焰图
火焰图的执行时间根据用户的选择可能较久，因此会在后台静默执行。需要等待执行结束后，手动点击“新建”按钮旁边的“刷新”标识，获取最新的火焰图历史。
-
+
火焰图
-
+
火焰图详情
@@ -128,13 +128,13 @@ date: 2024-1-8
展示主进程的 Thread Dump 结果，并可重新进行 Dump。保留最新一次 dump 的结果。
-
+
Thread Dump
点击“重新执行”，等待执行结束后，结果会自动刷新。
-
+
Thread Dump 详情
@@ -142,7 +142,7 @@ date: 2024-1-8
展示 master 的 java 主进程内的各项配置（仅 master 拥有此页面）。
-
+
进程配置
@@ -152,7 +152,7 @@ date: 2024-1-8
部分列表的列可以进行排序和查询。查询时，点击“搜索”标识，输入关键字，点击“搜索”按钮即可。重置时，点击“重置”按钮，列表会重新刷新。
-
+
列表
@@ -160,7 +160,7 @@ date: 2024-1-8
页面支持中英文切换，点击右上角的“文 A”图标，即可选择语言。
-
+
国际化
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/4.md b/i18n/zh-CN/docusaurus-plugin-content-blog/4.md
similarity index 96%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/4.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/4.md
index 8a7ed2aa6..0d5fd147f 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/4.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/4.md
@@ -15,7 +15,7 @@ date: 2023-06-27
-
+
## 实时图计算引擎-GeaFlow
@@ -27,7 +27,7 @@ date: 2023-06-27
GeaFlow 整体架构从上往下包含以下几层：
-
+
- GeaFlow DSL GeaFlow 对用户提供图表融合分析语言，采用 SQL + ISO/GQL 方式.用户可以通过类似 SQL 编程的方式编写实时图计算任务.
- GraphView API GeaFlow 以 GraphView 为核心定义的一套图计算的编程接口,包含图构建、图计算以及 Stream API 接口.
@@ -149,6 +149,6 @@ RETURN vid, distance
## 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/5.md b/i18n/zh-CN/docusaurus-plugin-content-blog/5.md
similarity index 95%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/5.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/5.md
index 1d360e490..e8673f886 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/5.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/5.md
@@ -108,13 +108,13 @@ hadoop org.apache.hadoop.conf.Configuration | grep 'fs.defaultFS'
在集群配置步骤中，配置 K8S 集群到 GeaFlow，填入 K8S 服务地址与前文提到的证书信息。
-
+
安装时会提示**当前为单机部署模式**，这表示 Console 平台使用默认单机部署。 图研发作业会被提交到配置的 K8S 集群，Console 平台提供作业编辑和运维能力，不受影响。
在数据存储配置步骤中，配置导入 GeaFlow 的图数据存储位置。
-
+
数据量较小可以配置为 LOCAL 模式，无需修改。 若数据量比较大，配置为 DFS 地址，Root 路径为存储数据在 DFS 中的根目录。
@@ -128,7 +128,7 @@ hadoop org.apache.hadoop.conf.Configuration | grep 'fs.defaultFS'
举例来说，我们创建实现商业智能应用的第一张图，命名为 bi。 创建图后， 将外部数据源的业务数据导入图中，使用对应的 Connector 完成数据导入。
-
+
图的 Schema 定义如下，图名称为 bi：
@@ -153,7 +153,7 @@ CREATE GRAPH IF NOT EXISTS bi (
即使在构图完成后，也可以向图中追加新的数据。 追加数据时，还可以流式触发增量查询，不断更新查询结果。
-
+
向图 bi 中单独追加 Person 和 knows 点边数据的 GQL：
@@ -200,7 +200,7 @@ ORDER BY personId, tagId LIMIT 100
通过管控平台 Console，分析人员可以提交一系列研究作业。 这些图查询作业会通过 GeaFlow 引擎自动提交到 K8S 集群中分布式地运行，大大太高了数据分析的能力和效率。
-
+
运行的图查询均可在 Console 界面查看，方便回溯和管理。
@@ -240,7 +240,7 @@ ORDER BY personId, personCentralityScore DESC LIMIT 100
更近一步地，分析人员可以定义这种中心性分数的一度传播，使其成为中介中心性分数的近似值。 我们设计的查询关系如下图，用户对某个 TAG 的中介中心性分数近似为与其具有 knows 关系用户的中心性分数之和。
-
+
表示为 GQL 查询如下：
@@ -300,6 +300,6 @@ ORDER BY personCentralityScore + friendScore DESC, personId LIMIT 100
## 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/6.md b/i18n/zh-CN/docusaurus-plugin-content-blog/6.md
similarity index 96%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/6.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/6.md
index a7d28baf4..1bb01a71a 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/6.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/6.md
@@ -11,7 +11,7 @@ date: 2023-7-7
-GeaFlow 整体架构如下所示：
+GeaFlow 整体架构如下所示：
- **GeaFlow DSL** GeaFlow 对用户提供图表融合分析语言，采用 SQL + ISO/GQL 方式.用户可以通过类似 SQL 编程的方式编写实时图计算任务.
- **GraphView API** GeaFlow 以 GraphView 为核心定义的一套图计算的编程接口,包含图构建、图计算以及 Stream API 接口.
@@ -28,7 +28,7 @@ date: 2023-7-7
实现 PageRank 算法的具体步骤包括：首先构建网页之间的链接关系图，然后对图进行迭代计算，直到收敛为止。在每一次迭代中，每个网页的得分都会被重新计算，并更新到下一次迭代中。最后，按照网页得分的大小对搜索结果进行排序，输出排名前几位的网页。如下有 4 个页面，A, B, C, D:
-
+
以 A 点为例，其每一轮的 PageRank 值计算方法如下：
@@ -193,6 +193,6 @@ Create funciton page_rank as 'com.antgroup.geaflow.dsl.udf.graph.PageRank';
## 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/7.md b/i18n/zh-CN/docusaurus-plugin-content-blog/7.md
similarity index 95%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/7.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/7.md
index a045c91f3..6912bf291 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/7.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/7.md
@@ -27,19 +27,19 @@ date: 2023-7-12
图是对关系的一种天然描述，图模型是一种以点和边作为基本单元定义的数据模型天然可以描述关联关系。在图模型里面以点代表实体，以边代表关系。比如在人际关系图里面，每一个人可以用一个点来表示，人和人之间的关系通过边来表示，人与人之间可以存在各种各样的复杂关系，这些关系都可以通过不同的边来表示。所以图模型里面天然就包含关系，是对关系最自然的表达。
-
+
### 图是关系的物化
图模型中本身包含点边关系的定义，在数据存储层面会按照点边关系存放数据，点和其邻边会存储在一起。所以图存储层面对关系做了物化，相比与表的 Join 方式，可以获取更好的关联计算性能。相比宽表的关系物化方式，由于图结构本身的点边聚合性，不会出现宽表展开导致的数据膨胀，其存储空间会更小，如下图所示。
-
+
### 图加速数据查询
利用图的关系物化的能力，可以加速关系运算的查询，如下例子： 学生、课程和教师三个实体表，实体之间存在选课(selectCourse)、考试(examination)和教学(teach)三种关系.这些实体之间的关系查询可以通过图查询来表示。
-
+
- 查询数学考试成绩前十的学生及其分数
@@ -89,7 +89,7 @@ Return tr.id, count(s.id) as cnt order by cnt desc limit 3
GeaFlow 支持和多种数据源集成，包括 Hudi。利用 GeaFlow 图计算的能力，可以对 Hudi 数据湖数据做关系物化，加速 DWD 层的查询性能和时效性，同时也可以基于图数据做更多复杂的图算法分析。
-
+
以下为 GeaFlow 使用 Hudi 构图，然后进行 4 度环路查找和 SSSP 算法计算的例子：
@@ -233,6 +233,6 @@ FROM (
## 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/8.md b/i18n/zh-CN/docusaurus-plugin-content-blog/8.md
similarity index 93%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/8.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/8.md
index 5f18d2868..4ca74338c 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/8.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/8.md
@@ -9,7 +9,7 @@ date: 2023-07-21
-
+
如何在 5 分钟内发现有哪些我们感兴趣好项目？
@@ -23,7 +23,7 @@ date: 2023-07-21
在 GitHub 开源项目仓库与话题组成的关系网络中，从仓库到话题再到仓库的关系边可以支持 SSSP 算法的运行。
-
+
如图，在关系网络局部，从起点出发，通过箭头的个数可以标记话题/仓库到源点的距离。例如仓库 FiraCode 与仓库 Font-Awesome 的距离为 2，通过 2 个箭头可到达，它们也是互相距离最近的关联仓库。
@@ -90,7 +90,7 @@ public class SSSP implements AlgorithmUserFunction {
图查询以提交作业的形式完成，作业可以运行在本地或 K8S 集群中，GeaFlow 提供控制台管理和回溯这些图研发作业。
-
+
## 在 GitHub 关系图上盲人摸象
@@ -139,6 +139,6 @@ free-programming-books,279431,55158
## 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/9.md b/i18n/zh-CN/docusaurus-plugin-content-blog/9.md
similarity index 93%
rename from i18n/zh-CN/docusaurus-plugin-content-blog/blog/9.md
rename to i18n/zh-CN/docusaurus-plugin-content-blog/9.md
index b2af8fe95..bb4133df5 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/blog/9.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/9.md
@@ -17,7 +17,7 @@ date: 2023-7-31
举例来说，在这个简单示例图中，如果要查找所有的’人创建软件’的模式，无论 DFS 还是 BFS 都需要实现复杂的计算逻辑，无法直观取得结果。
-
+
因此，基于图查询中的多元化走图需要，图查询语言自然产生。人们希望使用诸如 (:person)-[:created]->(:software) 的描述来达成需求。
@@ -48,7 +48,7 @@ RETURN a.id as a_id, e.weight as weight, b.id as b_id;
该描述非常直观，表示了查询两个人 a, b 之间类型为 knows 的边，要求 b 的 id 不能为 1，返回三个结果字段作为结果表。
-
+
由于查询并不复杂，其产生的执行计划也不复杂，只有 6 个步骤。
@@ -78,7 +78,7 @@ RETURN a.id as a_id, b.id as b_id;
该查询产生的执行计划如图。这个执行计划包含了一个嵌套关系，在步骤 14 进入子查询 1。子查询 1 在步骤 13 返回，根据返回结果我们才能继续执行步骤 15。
-
+
多么的复杂！我相信没有人愿意手工实现这个图算法的。
@@ -107,7 +107,7 @@ ORDER BY messageCount DESC, forumId LIMIT 20
在该查询中我们处理了一个循环’<-[:replyOf]-{0,}’，从而递归地获取博文 post 的所有回复。这对应着执行计划中的步骤 15 的 LoopUtil 算子。
-
+
### 全局标记
@@ -129,7 +129,7 @@ ORDER BY personCentralityScore + friendScore DESC, personId LIMIT 100
这在执行计划中体现为 StepMap 步骤，三个 StepMap 步骤分别完成三个 LET 语句的功能。可以数一数，这个执行计划总共需要多少轮迭代呢？
-
+
## 总结
@@ -145,6 +145,6 @@ ORDER BY personCentralityScore + friendScore DESC, personId LIMIT 100
## 微信群
-
+
请点击项目链接下方微信二维码添加微信用户群：[https://github.com/TuGraph-family/tugraph-analytics](https://github.com/TuGraph-family/tugraph-analytics)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-pages/download/index.md b/i18n/zh-CN/docusaurus-plugin-content-pages/download/index.md
index 2a1c7813f..a36555e0e 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-pages/download/index.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-pages/download/index.md
@@ -45,7 +45,7 @@ title: 下载
> 获取 GeaFlow 控制台镜像：geaflow/geaflow-console-arm:0.6
-## GeaFlow GeaFlow K8S 控制器
+## GeaFlow K8S 控制器
### geaflow-kubernetes-operator
diff --git a/src/pages/download/index.md b/src/pages/download/index.md
index edaa1535d..35e96e45a 100644
--- a/src/pages/download/index.md
+++ b/src/pages/download/index.md
@@ -44,8 +44,6 @@ title: "Downloads"
## GeaFlow Kubernetes Operator
-### geaflow-kubernetes-operator
-
[geaflow-kubernetes-operator-0.6-java8-x86](https://hub.docker.com/r/geaflow/geaflow-kubernetes-operator/tags)
> docker pull geaflow/geaflow-kubernetes-operator:0.6
diff --git a/static/img/wechat_group.png b/static/img/wechat_group.png
new file mode 100644
index 000000000..62762f0e9
Binary files /dev/null and b/static/img/wechat_group.png differ
diff --git a/versions/version-current/docs-en/source/contacts.md b/versions/version-current/docs-en/source/contacts.md
index 105c6d79a..f68b2e684 100644
--- a/versions/version-current/docs-en/source/contacts.md
+++ b/versions/version-current/docs-en/source/contacts.md
@@ -1,4 +1,8 @@
# Contacts
You can contact us through the following methods:
-
\ No newline at end of file
+
+
+Discord
+
+[https://discord.com/invite/apKdP3DXuH](https://discord.com/invite/apKdP3DXuH)
diff --git a/versions/version-current/static/img/contacts-en.png b/versions/version-current/static/img/contacts-en.png
deleted file mode 100644
index 47ac8b829..000000000
Binary files a/versions/version-current/static/img/contacts-en.png and /dev/null differ
diff --git a/versions/version-current/static/img/contacts.png b/versions/version-current/static/img/contacts.png
index 75c49540b..cc3549b5b 100644
Binary files a/versions/version-current/static/img/contacts.png and b/versions/version-current/static/img/contacts.png differ
diff --git a/versions/version-current/static/img/contacts_en.png b/versions/version-current/static/img/contacts_en.png
new file mode 100644
index 000000000..71c82e01b
Binary files /dev/null and b/versions/version-current/static/img/contacts_en.png differ