Update terminology in BrokerLoad documentation

.github/workflows/ci-doc-translation-check.yml

@@ -31,7 +31,6 @@ jobs:
             docs/ja/**/*.md*
 
       # 3. Generate Checklist (Same logic as before)
-
       - name: Generate Checklist Body
         id: checklist
         uses: actions/github-script@v7
@@ -110,4 +109,4 @@ jobs:
               repo: context.repo.repo,
               issue_number: context.issue.number,
               labels: ['docs-maintainer']
-            });
+            });

docs/en/introduction/Architecture.md

@@ -5,7 +5,7 @@ import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx'
 
 # Architecture
 
-StarRocks has a simple architecture. The entire system consists of only two types of components; frontends and backends. The frontend nodes are called **FE**s. There are two types of backend nodes, **BE**s, and **CN**s (Compute Nodes). BEs are deployed when local storage for data is used, and CNs are deployed when data is stored on object storage or HDFS. StarRocks does not rely on any external components, simplifying deployment and maintenance. Nodes can be horizontally scaled without service downtime. In addition, StarRocks has a replica mechanism for metadata and service data, which increases data reliability and efficiently prevents single points of failure (SPOFs).
+StarRocks has a robust architecture. The entire system consists of only two types of components; frontends and backends. The frontend nodes are called **FE**s. There are two types of backend nodes, **BE**s, and **CN**s (Compute Nodes). BEs are deployed when local storage for data is used, and CNs are deployed when data is stored on object storage or HDFS. StarRocks does not rely on any external components, simplifying deployment and maintenance. Nodes can be horizontally scaled without service downtime. In addition, StarRocks has a replica mechanism for metadata and service data, which increases data reliability and efficiently prevents single points of failure (SPOFs).
 
 StarRocks is compatible with MySQL protocols and supports standard SQL. Users can easily connect to StarRocks from MySQL clients to gain instant and valuable insights.
 

docs/en/loading/BrokerLoad.md

@@ -2,15 +2,15 @@
 displayed_sidebar: docs
 ---
 
-# Load data from HDFS or cloud storage
+# Load data from object storage or HDFS
 
 import InsertPrivNote from '../_assets/commonMarkdown/insertPrivNote.mdx'
 
 StarRocks provides the loading method MySQL-based Broker Load to help you load a large amount of data from HDFS or cloud storage into StarRocks.
 
-Broker Load runs in asynchronous loading mode. After you submit a load job, StarRocks asynchronously runs the job. You need to use the [SHOW LOAD](../sql-reference/sql-statements/loading_unloading/SHOW_LOAD.md) statement or the `curl` command to check the result of the job.
+Broker Load runs in asynchronous loading mode. After you submit a load edit, StarRocks asynchronously runs the job. You need to use the [SHOW LOAD](../sql-reference/sql-statements/loading_unloading/SHOW_LOAD.md) statement or the `curl` command to check the result of the job.
 
-Broker Load supports single-table loads and multi-table loads. You can load one or multiple data files into one or multiple destination tables by running one Broker Load job. Broker Load ensures the transactional atomicity of each load job that is run to load multiple data files. Atomicity means that the loading of multiple data files in one load job must all succeed or fail. It never happens that the loading of some data files succeeds while the loading of the other files fails.
+Broker Load supports single-table loads and multi-table loads. You can load one or multiple data files into one or more destination tables by running one Broker Load job. Broker Load ensures the transactional atomicity of each load job that is run to load multiple data files. Atomicity means the loading of multiple data files in one load job must all succeed or fail. It never happens that the loading of some data files succeeds while the of the other files fails.
 
 Broker Load supports data transformation at data loading and supports data changes made by UPSERT and DELETE operations during data loading. For more information, see [Transform data at loading](../loading/Etl_in_loading.md) and [Change data through loading](../loading/Load_to_Primary_Key_tables.md).
 

docs/en/quick_start/shared-nothing.md

@@ -3,6 +3,7 @@ displayed_sidebar: docs
 sidebar_position: 1
 description: "StarRocks in Docker: Query real data with JOINs"
 ---
+
 import DDL from '../_assets/quick-start/_DDL.mdx'
 import Clients from '../_assets/quick-start/_clientsAllin1.mdx'
 import SQL from '../_assets/quick-start/_SQL.mdx'

docs/ja/introduction/Architecture.md

@@ -0,0 +1,83 @@
+---
+displayed_sidebar: docs
+---
+import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx'
+
+# アーキテクチャ
+
+StarRocks は、堅牢なアーキテクチャを備えています。システム全体は、フロントエンドとバックエンドの 2 種類のコンポーネントのみで構成されています。フロントエンドノードは **FE** と呼ばれます。バックエンドノードには、**BE** と **CN** (コンピュートノード) の 2 種類があります。BE は、データのローカルストレージが使用される場合にデプロイされ、CN は、データがオブジェクトストレージまたは HDFS に保存される場合にデプロイされます。StarRocks は外部コンポーネントに依存しないため、デプロイとメンテナンスが簡素化されます。ノードは、サービスを停止することなく水平方向に拡張できます。さらに、StarRocks にはメタデータとサービスデータのレプリカメカニズムがあり、データの信頼性を高め、単一障害点 (SPOF) を効率的に防止します。
+
+StarRocks は MySQL プロトコルと互換性があり、標準 SQL をサポートしています。ユーザーは MySQL クライアントから StarRocks に簡単に接続して、即座に価値のある洞察を得ることができます。
+
+## アーキテクチャの選択
+
+StarRocks は、共有なし (各 BE はローカルストレージにデータの一部を保持) と共有データ (すべてのデータはオブジェクトストレージまたは HDFS 上にあり、各 CN はローカルストレージにキャッシュのみを保持) をサポートしています。ニーズに応じて、データの保存場所を決定できます。
+
+![Architecture choices](../_assets/architecture_choices.png)
+
+### 共有なし
+
+ローカルストレージは、リアルタイムクエリのクエリレイテンシを改善します。
+
+StarRocks は、典型的な超並列処理 (MPP) データベースとして、共有なしアーキテクチャをサポートしています。このアーキテクチャでは、BE はデータストレージと計算の両方を担当します。BE モードでローカルデータに直接アクセスすることで、ローカル計算が可能になり、データ転送とデータコピーを回避し、超高速なクエリと分析パフォーマンスを提供します。このアーキテクチャは、マルチレプリカデータストレージをサポートし、高同時実行クエリを処理するクラスタの能力を高め、データの信頼性を確保します。最適なクエリパフォーマンスを追求するシナリオに適しています。
+
+![shared-data-arch](../_assets/shared nothing.png)
+
+#### ノード
+
+共有なしアーキテクチャでは、StarRocks は FE と BE の 2 種類のノードで構成されています。
+
+- FE は、メタデータ管理と実行プランの構築を担当します。
+- BE は、クエリプランを実行し、データを保存します。BE は、ローカルストレージを利用してクエリを高速化し、マルチレプリカメカニズムを利用して高いデータ可用性を確保します。
+
+##### FE
+
+FE は、メタデータ管理、クライアント接続管理、クエリプラン、およびクエリスケジューリングを担当します。各 FE は BDB JE (Berkeley DB Java Edition) を使用して、メモリ内のメタデータの完全なコピーを保存および維持し、すべての FE で一貫したサービスを保証します。FE は、leader、follower、および observer として機能できます。leader ノードがクラッシュした場合、follower は Raft プロトコルに基づいて leader を選出します。
+
+| **FE Role** | **Metadata management**                                                                                                                                                                                                                                                                                                                                                                                                | **Leader election**                |
+| ----------- |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ---------------------------------- |
+| Leader      | leader FE はメタデータを読み書きします。follower および observer FE は、メタデータを読み取るだけです。メタデータの書き込みリクエストを leader FE にルーティングします。leader FE はメタデータを更新し、Raft プロトコルを使用してメタデータの変更を follower および observer FE に同期します。データの書き込みは、メタデータの変更が follower FE の半分以上に同期された後にのみ成功したと見なされます。 | 厳密に言うと、leader FE も follower ノードであり、follower FE から選出されます。leader 選出を実行するには、クラスタ内の follower FE の半分以上がアクティブである必要があります。leader FE が失敗すると、follower FE は別の leader 選出ラウンドを開始します。 |
+| Follower    | follower はメタデータを読み取るだけです。leader FE からログを同期して再生し、メタデータを更新します。                                                                                                                                                                                                                                                                                                              | follower は leader 選出に参加します。これには、クラスタ内の follower の半分以上がアクティブである必要があります。 |
+| Observer   | observer は leader FE からログを同期して再生し、メタデータを更新します。                                                                                                                                                                                                                                                                                                                                           | observer は主に、クラスタのクエリ同時実行性を高めるために使用されます。observer は leader 選出に参加しないため、クラスタに leader 選択のプレッシャーを追加しません。|
+
+##### BE
+
+BE は、データストレージと SQL 実行を担当します。
+
+- データストレージ: BE は同等のデータストレージ機能を備えています。FE は、事前定義されたルールに基づいてデータを BE に分散します。BE は、取り込まれたデータを変換し、必要な形式でデータを書き込み、データのインデックスを生成します。
+
+- SQL 実行: FE は、各 SQL クエリをクエリのセマンティクスに従って論理実行プランに解析し、次に論理プランを BE で実行できる物理実行プランに変換します。宛先データを保存する BE がクエリを実行します。これにより、データ伝送とコピーの必要がなくなり、高いクエリパフォーマンスが実現します。
+
+### 共有データ
+
+オブジェクトストレージと HDFS は、コスト、信頼性、およびスケーラビリティの利点を提供します。ストレージのスケーラビリティに加えて、ストレージとコンピュートが分離されているため、データをリバランスする必要なく CN ノードを追加および削除できます。
+
+共有データアーキテクチャでは、BE は「コンピュートノード (CN)」に置き換えられます。CN は、データコンピュートタスクとホットデータのキャッシュのみを担当します。データは、Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIO などの低コストで信頼性の高いリモートストレージシステムに保存されます。キャッシュがヒットすると、クエリパフォーマンスは共有なしアーキテクチャのパフォーマンスに匹敵します。CN ノードは、必要に応じて数秒以内に追加または削除できます。このアーキテクチャは、ストレージコストを削減し、より優れたリソース分離、高い弾力性とスケーラビリティを保証します。
+
+共有データアーキテクチャは、共有なしアーキテクチャと同様にシンプルなアーキテクチャを維持します。FE と CN の 2 種類のノードのみで構成されています。唯一の違いは、ユーザーがバックエンドオブジェクトストレージをプロビジョニングする必要があることです。
+
+![shared-data-arch](../_assets/shared-data.png)
+
+#### ノード
+
+共有データアーキテクチャのコーディネータノードは、共有なしアーキテクチャの FE と同じ機能を提供します。
+
+BE は CN (コンピュートノード) に置き換えられ、ストレージ機能はオブジェクトストレージまたは HDFS にオフロードされます。CN は、データの保存を除き、BE のすべての機能を実行するステートレスコンピュートノードです。
+
+#### ストレージ
+
+StarRocks 共有データクラスタは、オブジェクトストレージ (たとえば、AWS S3、Google GCS、Azure Blob Storage、または MinIO) と HDFS の 2 つのストレージソリューションをサポートしています。
+
+共有データクラスタでは、データファイル形式は、共有なしクラスタ (結合されたストレージとコンピュートを備えています) の形式と一貫しています。データはセグメントファイルに編成され、さまざまなインデックス作成テクノロジーがクラウドネイティブテーブルで再利用されます。クラウドネイティブテーブルは、共有データクラスタで特に使用されるテーブルです。
+
+#### キャッシュ
+
+StarRocks 共有データクラスタは、データストレージと計算を分離し、それぞれが独立してスケーリングできるようにすることで、コストを削減し、弾力性を高めます。ただし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。
+
+影響を軽減するために、StarRocks は、さまざまなビジネスニーズをより適切に満たすために、メモリ、ローカルディスク、およびリモートストレージを含む多層データアクセスシステムを確立します。
+
+ホットデータに対するクエリは、キャッシュを直接スキャンしてからローカルディスクをスキャンしますが、コールドデータは、後続のクエリを高速化するために、オブジェクトストレージからローカルキャッシュにロードする必要があります。ホットデータをコンピュートユニットの近くに保持することで、StarRocks は真に高性能な計算と費用対効果の高いストレージを実現します。さらに、コールドデータへのアクセスは、データプリフェッチ戦略で最適化されており、クエリのパフォーマンス制限を効果的に排除しています。
+
+キャッシュは、テーブルの作成時に有効にできます。キャッシュを有効にすると、データはローカルディスクとバックエンドオブジェクトストレージの両方に書き込まれます。クエリ中、CN ノードは最初にローカルディスクからデータを読み取ります。データが見つからない場合は、バックエンドオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。
+
+<QSOverview />