diff --git a/.github/workflows/ci-doc-translation-check.yml b/.github/workflows/ci-doc-translation-check.yml
index afa2c8af..24cabb8d 100644
--- a/.github/workflows/ci-doc-translation-check.yml
+++ b/.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']
- });
\ No newline at end of file
+ });
diff --git a/docs/en/introduction/Architecture.md b/docs/en/introduction/Architecture.md
index 2dd28b57..f43627c1 100644
--- a/docs/en/introduction/Architecture.md
+++ b/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.
diff --git a/docs/en/loading/BrokerLoad.md b/docs/en/loading/BrokerLoad.md
index 9d2c7603..d4a97b6e 100644
--- a/docs/en/loading/BrokerLoad.md
+++ b/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).
diff --git a/docs/en/quick_start/shared-nothing.md b/docs/en/quick_start/shared-nothing.md
index 5cb9486d..0dd6a440 100644
--- a/docs/en/quick_start/shared-nothing.md
+++ b/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'
diff --git a/docs/ja/introduction/Architecture.md b/docs/ja/introduction/Architecture.md
new file mode 100644
index 00000000..0975dc9b
--- /dev/null
+++ b/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 はローカルストレージにキャッシュのみを保持) をサポートしています。ニーズに応じて、データの保存場所を決定できます。
+
+
+
+### 共有なし
+
+ローカルストレージは、リアルタイムクエリのクエリレイテンシを改善します。
+
+StarRocks は、典型的な超並列処理 (MPP) データベースとして、共有なしアーキテクチャをサポートしています。このアーキテクチャでは、BE はデータストレージと計算の両方を担当します。BE モードでローカルデータに直接アクセスすることで、ローカル計算が可能になり、データ転送とデータコピーを回避し、超高速なクエリと分析パフォーマンスを提供します。このアーキテクチャは、マルチレプリカデータストレージをサポートし、高同時実行クエリを処理するクラスタの能力を高め、データの信頼性を確保します。最適なクエリパフォーマンスを追求するシナリオに適しています。
+
+
+
+#### ノード
+
+共有なしアーキテクチャでは、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 種類のノードのみで構成されています。唯一の違いは、ユーザーがバックエンドオブジェクトストレージをプロビジョニングする必要があることです。
+
+
+
+#### ノード
+
+共有データアーキテクチャのコーディネータノードは、共有なしアーキテクチャの FE と同じ機能を提供します。
+
+BE は CN (コンピュートノード) に置き換えられ、ストレージ機能はオブジェクトストレージまたは HDFS にオフロードされます。CN は、データの保存を除き、BE のすべての機能を実行するステートレスコンピュートノードです。
+
+#### ストレージ
+
+StarRocks 共有データクラスタは、オブジェクトストレージ (たとえば、AWS S3、Google GCS、Azure Blob Storage、または MinIO) と HDFS の 2 つのストレージソリューションをサポートしています。
+
+共有データクラスタでは、データファイル形式は、共有なしクラスタ (結合されたストレージとコンピュートを備えています) の形式と一貫しています。データはセグメントファイルに編成され、さまざまなインデックス作成テクノロジーがクラウドネイティブテーブルで再利用されます。クラウドネイティブテーブルは、共有データクラスタで特に使用されるテーブルです。
+
+#### キャッシュ
+
+StarRocks 共有データクラスタは、データストレージと計算を分離し、それぞれが独立してスケーリングできるようにすることで、コストを削減し、弾力性を高めます。ただし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。
+
+影響を軽減するために、StarRocks は、さまざまなビジネスニーズをより適切に満たすために、メモリ、ローカルディスク、およびリモートストレージを含む多層データアクセスシステムを確立します。
+
+ホットデータに対するクエリは、キャッシュを直接スキャンしてからローカルディスクをスキャンしますが、コールドデータは、後続のクエリを高速化するために、オブジェクトストレージからローカルキャッシュにロードする必要があります。ホットデータをコンピュートユニットの近くに保持することで、StarRocks は真に高性能な計算と費用対効果の高いストレージを実現します。さらに、コールドデータへのアクセスは、データプリフェッチ戦略で最適化されており、クエリのパフォーマンス制限を効果的に排除しています。
+
+キャッシュは、テーブルの作成時に有効にできます。キャッシュを有効にすると、データはローカルディスクとバックエンドオブジェクトストレージの両方に書き込まれます。クエリ中、CN ノードは最初にローカルディスクからデータを読み取ります。データが見つからない場合は、バックエンドオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。
+
+
\ No newline at end of file
diff --git a/docs/ja/quick_start/shared-nothing.md b/docs/ja/quick_start/shared-nothing.md
new file mode 100644
index 00000000..e918771e
--- /dev/null
+++ b/docs/ja/quick_start/shared-nothing.md
@@ -0,0 +1,246 @@
+displayed_sidebar: docs
+sidebar_position: 1
+description: "Docker での StarRocks: JOIN を使用した実際のデータのクエリ"
+```
+
+import DDL from '../_assets/quick-start/_DDL.mdx'
+import Clients from '../_assets/quick-start/_clientsAllin1.mdx'
+import SQL from '../_assets/quick-start/_SQL.mdx'
+import Curl from '../_assets/quick-start/_curl.mdx'
+
+# Docker を使用した StarRocks のデプロイ
+
+このチュートリアルでは、以下について説明します。
+
+- 単一の Docker コンテナでの StarRocks の実行
+- データの基本的な変換を含む、2 つの公開データセットのロード
+- SELECT と JOIN を使用したデータの分析
+- 基本的なデータ変換 (ETL の **T**)
+
+## 必要に応じて、ビデオをご覧ください
+
+
+
+使用されるデータは、NYC OpenData と米国国立環境情報センターによって提供されています。
+
+これらのデータセットはいずれも非常に大きいものですが、このチュートリアルは StarRocks の操作に慣れていただくことを目的としているため、過去 120 年間のデータをロードすることはありません。Docker イメージを実行して、Docker に割り当てられた 4 GB の RAM を持つマシンにこのデータをロードできます。より大規模なフォールトトレラントでスケーラブルなデプロイメントについては、他のドキュメントがあり、後で提供します。
+
+このドキュメントには多くの情報が含まれており、ステップごとのコンテンツが最初に提示され、技術的な詳細は最後に提示されます。これは、次の目的をこの順序で果たすために行われます。
+
+1. 読者が StarRocks にデータをロードし、そのデータを分析できるようにする。
+2. ロード中のデータ変換の基本を説明する。
+
+---
+
+## 前提条件
+
+### Docker
+
+- [Docker](https://docs.docker.com/engine/install/)
+- Docker に割り当てられた 4 GB の RAM
+- Docker に割り当てられた 10 GB の空きディスク容量
+
+### SQL クライアント
+
+Docker 環境で提供されている SQL クライアントを使用するか、システム上のクライアントを使用できます。多くの MySQL 互換クライアントが動作し、このガイドでは DBeaver と MySQL Workbench の構成について説明します。
+
+### curl
+
+`curl` は、StarRocks にデータロードジョブを発行したり、データセットをダウンロードしたりするために使用されます。OS プロンプトで `curl` または `curl.exe` を実行して、インストールされているかどうかを確認してください。curl がインストールされていない場合は、[こちらから curl を入手してください](https://curl.se/dlwiz/?type=bin)。
+
+---
+
+## 用語
+
+### FE
+
+FE (Frontend) ノードは、メタデータ管理、クライアント接続管理、クエリプラン、およびクエリスケジューリングを担当します。各 FE は、メモリ内にメタデータの完全なコピーを保存および保持します。これにより、FE 間で無差別のサービスが保証されます。
+
+### BE
+
+BE (Backend) ノードは、データストレージとクエリプランの実行の両方を担当します。
+
+---
+
+## StarRocks の起動
+
+```bash
+docker pull starrocks/allin1-ubuntu
+docker run -p 9030:9030 -p 8030:8030 -p 8040:8040 -itd \
+--name quickstart starrocks/allin1-ubuntu
+```
+
+---
+
+## SQL クライアント
+
+
+
+---
+
+## データのダウンロード
+
+これらの 2 つのデータセットをマシンにダウンロードします。Docker を実行しているホストマシンにダウンロードできます。コンテナ内にダウンロードする必要はありません。
+
+### ニューヨーク市の交通事故データ
+
+```bash
+curl -O https://raw.githubusercontent.com/StarRocks/demo/master/documentation-samples/quickstart/datasets/NYPD_Crash_Data.csv
+```
+
+### 天気データ
+
+```bash
+curl -O https://raw.githubusercontent.com/StarRocks/demo/master/documentation-samples/quickstart/datasets/72505394728.csv
+```
+
+---
+
+### SQL クライアントで StarRocks に接続する
+
+:::tip
+
+mysql CLI 以外のクライアントを使用している場合は、ここで開いてください。
+:::
+
+このコマンドは、Docker コンテナで `mysql` コマンドを実行します。
+
+```sql
+docker exec -it quickstart \
+mysql -P 9030 -h 127.0.0.1 -u root --prompt="StarRocks > "
+```
+
+---
+
+## テーブルの作成
+
+
+
+---
+
+## 2 つのデータセットのロード
+
+StarRocks にデータをロードする方法はたくさんあります。このチュートリアルでは、最も簡単な方法は curl と StarRocks Stream Load を使用することです。
+
+:::tip
+これらの curl コマンドはオペレーティングシステムのプロンプトで実行され、`mysql` クライアントでは実行されないため、新しいシェルを開きます。コマンドはダウンロードしたデータセットを参照するため、ファイルをダウンロードしたディレクトリから実行してください。
+
+パスワードを要求されます。MySQL `root` ユーザーにパスワードを割り当てていない可能性があるため、Enter キーを押してください。
+:::
+
+`curl` コマンドは複雑に見えますが、チュートリアルの最後に詳細に説明されています。今のところ、コマンドを実行し、いくつかの SQL を実行してデータを分析してから、最後にデータロードの詳細について読むことをお勧めします。
+
+### ニューヨーク市の衝突データ - 事故
+
+```bash
+curl --location-trusted -u root \
+ -T ./NYPD_Crash_Data.csv \
+ -H "label:crashdata-0" \
+ -H "column_separator:," \
+ -H "skip_header:1" \
+ -H "enclose:\"" \
+ -H "max_filter_ratio:1" \
+ -H "columns:tmp_CRASH_DATE, tmp_CRASH_TIME, CRASH_DATE=str_to_date(concat_ws(' ', tmp_CRASH_DATE, tmp_CRASH_TIME), '%m/%d/%Y %H:%i'),BOROUGH,ZIP_CODE,LATITUDE,LONGITUDE,LOCATION,ON_STREET_NAME,CROSS_STREET_NAME,OFF_STREET_NAME,NUMBER_OF_PERSONS_INJURED,NUMBER_OF_PERSONS_KILLED,NUMBER_OF_PEDESTRIANS_INJURED,NUMBER_OF_PEDESTRIANS_KILLED,NUMBER_OF_CYCLIST_INJURED,NUMBER_OF_CYCLIST_KILLED,NUMBER_OF_MOTORIST_INJURED,NUMBER_OF_MOTORIST_KILLED,CONTRIBUTING_FACTOR_VEHICLE_1,CONTRIBUTING_FACTOR_VEHICLE_2,CONTRIBUTING_FACTOR_VEHICLE_3,CONTRIBUTING_FACTOR_VEHICLE_4,CONTRIBUTING_FACTOR_VEHICLE_5,COLLISION_ID,VEHICLE_TYPE_CODE_1,VEHICLE_TYPE_CODE_2,VEHICLE_TYPE_CODE_3,VEHICLE_TYPE_CODE_4,VEHICLE_TYPE_CODE_5" \
+ -XPUT http://localhost:8030/api/quickstart/crashdata/_stream_load
+```
+
+これは、前のコマンドの出力です。最初に強調表示されているセクションは、表示されるはずのもの (OK と 1 行を除くすべての行が挿入された) を示しています。1 つの行がフィルタリングされたのは、正しい数の列が含まれていないためです。
+
+```bash
+Enter host password for user 'root':
+{
+ "TxnId": 2,
+ "Label": "crashdata-0",
+ "Status": "Success",
+ # highlight-start
+ "Message": "OK",
+ "NumberTotalRows": 423726,
+ "NumberLoadedRows": 423725,
+ # highlight-end
+ "NumberFilteredRows": 1,
+ "NumberUnselectedRows": 0,
+ "LoadBytes": 96227746,
+ "LoadTimeMs": 1013,
+ "BeginTxnTimeMs": 21,
+ "StreamLoadPlanTimeMs": 63,
+ "ReadDataTimeMs": 563,
+ "WriteDataTimeMs": 870,
+ "CommitAndPublishTimeMs": 57,
+ # highlight-start
+ "ErrorURL": "http://127.0.0.1:8040/api/_load_error_log?file=error_log_da41dd88276a7bfc_739087c94262ae9f"
+ # highlight-end
+}%
+```
+
+エラーが発生した場合、出力にはエラーメッセージを表示するための URL が表示されます。これをブラウザで開いて、何が起こったのかを確認してください。詳細を展開して、サンプルエラーメッセージを表示します。
+
+
+
+ブラウザでのエラーメッセージの読み取り
+
+```bash
+Error: Target column count: 29 doesn't match source value column count: 32. Column separator: ',', Row delimiter: '\n'. Row: 09/06/2015,14:15,,,40.6722269,-74.0110059,"(40.6722269, -74.0110059)",,,"R/O 1 BEARD ST. ( IKEA'S
+09/14/2015,5:30,BRONX,10473,40.814551,-73.8490955,"(40.814551, -73.8490955)",TORRY AVENUE ,NORTON AVENUE ,,0,0,0,0,0,0,0,0,Driver Inattention/Distraction,Unspecified,,,,3297457,PASSENGER VEHICLE,PASSENGER VEHICLE,,,
+```
+
+
+
+### 天気データ
+
+事故データと同じ方法で天気データセットをロードします。
+
+```bash
+curl --location-trusted -u root \
+ -T ./72505394728.csv \
+ -H "label:weather-0" \
+ -H "column_separator:," \
+ -H "skip_header:1" \
+ -H "enclose:\"" \
+ -H "max_filter_ratio:1" \
+ -H "columns: STATION, DATE, LATITUDE, LONGITUDE, ELEVATION, NAME, REPORT_TYPE, SOURCE, HourlyAltimeterSetting, HourlyDewPointTemperature, HourlyDryBulbTemperature, HourlyPrecipitation, HourlyPresentWeatherType, HourlyPressureChange, HourlyPressureTendency, HourlyRelativeHumidity, HourlySkyConditions, HourlySeaLevelPressure, HourlyStationPressure, HourlyVisibility, HourlyWetBulbTemperature, HourlyWindDirection, HourlyWindGustSpeed, HourlyWindSpeed, Sunrise, Sunset, DailyAverageDewPointTemperature, DailyAverageDryBulbTemperature, DailyAverageRelativeHumidity, DailyAverageSeaLevelPressure, DailyAverageStationPressure, DailyAverageWetBulbTemperature, DailyAverageWindSpeed, DailyCoolingDegreeDays, DailyDepartureFromNormalAverageTemperature, DailyHeatingDegreeDays, DailyMaximumDryBulbTemperature, DailyMinimumDryBulbTemperature, DailyPeakWindDirection, DailyPeakWindSpeed, DailyPrecipitation, DailySnowDepth, DailySnowfall, DailySustainedWindDirection, DailySustainedWindSpeed, DailyWeather, MonthlyAverageRH, MonthlyDaysWithGT001Precip, MonthlyDaysWithGT010Precip, MonthlyDaysWithGT32Temp, MonthlyDaysWithGT90Temp, MonthlyDaysWithLT0Temp, MonthlyDaysWithLT32Temp, MonthlyDepartureFromNormalAverageTemperature, MonthlyDepartureFromNormalCoolingDegreeDays, MonthlyDepartureFromNormalHeatingDegreeDays, MonthlyDepartureFromNormalMaximumTemperature, MonthlyDepartureFromNormalMinimumTemperature, MonthlyDepartureFromNormalPrecipitation, MonthlyDewpointTemperature, MonthlyGreatestPrecip, MonthlyGreatestPrecipDate, MonthlyGreatestSnowDepth, MonthlyGreatestSnowDepthDate, MonthlyGreatestSnowfall, MonthlyGreatestSnowfallDate, MonthlyMaxSeaLevelPressureValue, MonthlyMaxSeaLevelPressureValueDate, MonthlyMaxSeaLevelPressureValueTime, MonthlyMaximumTemperature, MonthlyMeanTemperature, MonthlyMinSeaLevelPressureValue, MonthlyMinSeaLevelPressureValueDate, MonthlyMinSeaLevelPressureValueTime, MonthlyMinimumTemperature, MonthlySeaLevelPressure, MonthlyStationPressure, MonthlyTotalLiquidPrecipitation, MonthlyTotalSnowfall, MonthlyWetBulb, AWND, CDSD, CLDD, DSNW, HDSD, HTDD, NormalsCoolingDegreeDay, NormalsHeatingDegreeDay, ShortDurationEndDate005, ShortDurationEndDate010, ShortDurationEndDate015, ShortDurationEndDate020, ShortDurationEndDate030, ShortDurationEndDate045, ShortDurationEndDate060, ShortDurationEndDate080, ShortDurationEndDate100, ShortDurationEndDate120, ShortDurationEndDate150, ShortDurationEndDate180, ShortDurationPrecipitationValue005, ShortDurationPrecipitationValue010, ShortDurationPrecipitationValue015, ShortDurationPrecipitationValue020, ShortDurationPrecipitationValue030, ShortDurationPrecipitationValue045, ShortDurationPrecipitationValue060, ShortDurationPrecipitationValue080, ShortDurationPrecipitationValue100, ShortDurationPrecipitationValue120, ShortDurationPrecipitationValue150, ShortDurationPrecipitationValue180, REM, BackupDirection, BackupDistance, BackupDistanceUnit, BackupElements, BackupElevation, BackupEquipment, BackupLatitude, BackupLongitude, BackupName, WindEquipmentChangeDate" \
+ -XPUT http://localhost:8030/api/quickstart/weatherdata/_stream_load
+```
+
+---
+
+## いくつかの質問に答える
+
+
+
+---
+
+## まとめ
+
+このチュートリアルでは、次のことを行いました。
+
+- Docker で StarRocks をデプロイしました
+- ニューヨーク市が提供する事故データと NOAA が提供する天気データをロードしました
+- SQL JOIN を使用してデータを分析し、視界が悪い場所や凍結した道路での運転は良くないことを発見しました
+
+学ぶことはもっとあります。Stream Load 中に行われたデータ変換については、意図的に簡単に説明しました。詳細については、以下の curl コマンドの注記を参照してください。
+
+---
+
+## curl コマンドに関する注記
+
+
+
+---
+
+## より詳しい情報
+
+[StarRocks テーブル設計](../table_design/StarRocks_table_design.md)
+
+[Stream Load](../sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md)
+
+[自動車衝突 - 事故](https://data.cityofnewyork.us/Public-Safety/Motor-Vehicle-Collisions-Crashes/h9gi-nx95) データセットは、ニューヨーク市によって提供されており、これらの [利用規約](https://www.nyc.gov/home/terms-of-use.page) および [プライバシーポリシー](https://www.nyc.gov/home/privacy-policy.page) に準拠します。
+
+[地方気象データ](https://www.ncdc.noaa.gov/cdo-web/datatools/lcd)(LCD) は、NOAA によって提供されており、この [免責事項](https://www.noaa.gov/disclaimer) およびこの [プライバシーポリシー](https://www.noaa.gov/protecting-your-privacy) が適用されます。
\ No newline at end of file
diff --git a/docs/zh/introduction/Architecture.md b/docs/zh/introduction/Architecture.md
deleted file mode 100644
index 14b7899f..00000000
--- a/docs/zh/introduction/Architecture.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-displayed_sidebar: docs
----
-import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx'
-
-# 架构
-
-StarRocks 具有简单的架构。整个系统仅由两种类型的组件组成：前端和后端。前端节点称为 **FE**。后端节点有两种类型，**BE** 和 **CN** (计算节点)。当使用数据的本地存储时，将部署 BE；当数据存储在对象存储或 HDFS 上时，将部署 CN。StarRocks 不依赖于任何外部组件，从而简化了部署和维护。节点可以水平扩展，而不会导致服务中断。此外，StarRocks 具有元数据和服务数据的副本机制，从而提高了数据可靠性，并有效地防止了单点故障 (SPOF)。
-
-StarRocks 兼容 MySQL 协议，并支持标准 SQL。用户可以轻松地从 MySQL 客户端连接到 StarRocks，以获得即时且有价值的见解。
-
-## 架构选择
-
-StarRocks 支持 shared-nothing (每个 BE 在其本地存储上都拥有一部分数据) 和 shared-data (所有数据都在对象存储或 HDFS 上，每个 CN 仅在本地存储上具有缓存)。您可以根据自己的需求决定数据的存储位置。
-
-
-
-### Shared-nothing
-
-本地存储为实时查询提供了更高的查询延迟。
-
-作为一种典型的海量并行处理 (MPP) 数据库，StarRocks 支持 shared-nothing 架构。在此架构中，BE 负责数据存储和计算。直接访问 BE 模式下的本地数据可以进行本地计算，避免了数据传输和数据复制，并提供了超快的查询和分析性能。此架构支持多副本数据存储，从而增强了集群处理高并发查询的能力并确保数据可靠性。它非常适合追求最佳查询性能的场景。
-
-
-
-#### 节点
-
-在 shared-nothing 架构中，StarRocks 由两种类型的节点组成：FE 和 BE。
-
-- FE 负责元数据管理和构建执行计划。
-- BE 执行查询计划并存储数据。BE 利用本地存储来加速查询，并利用多副本机制来确保高数据可用性。
-
-##### FE
-
-FE 负责元数据管理、客户端连接管理、查询规划和查询调度。每个 FE 使用 BDB JE (Berkeley DB Java Edition) 来存储和维护其内存中元数据的完整副本，从而确保所有 FE 之间的一致服务。FE 可以充当 leader、follower 和 observer。如果 leader 节点崩溃，则 follower 基于 Raft 协议选举 leader。
-
-| **FE 角色** | **元数据管理** | **Leader 选举** |
-| ----------- |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ---------------------------------- |
-| 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 执行查询。这样就无需数据传输和复制，从而实现高查询性能。
-
-### Shared-data
-
-对象存储和 HDFS 提供了成本、可靠性和可扩展性优势。除了存储的可扩展性之外，由于存储和计算是分开的，因此可以添加和删除 CN 节点，而无需重新平衡数据。
-
-在 shared-data 架构中，BE 被“计算节点 (CN)”取代，后者仅负责数据计算任务和缓存热数据。数据存储在低成本且可靠的远程存储系统中，例如 Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIO 等。当缓存命中时，查询性能与 shared-nothing 架构的查询性能相当。可以根据需要在几秒钟内添加或删除 CN 节点。此架构降低了存储成本，确保了更好的资源隔离以及高弹性和可扩展性。
-
-shared-data 架构与其 shared-nothing 架构一样，保持了简单的架构。它仅由两种类型的节点组成：FE 和 CN。唯一的区别是用户必须配置后端对象存储。
-
-
-
-#### 节点
-
-shared-data 架构中的 FE 提供与 shared-nothing 架构中相同的功能。
-
-BE 被 CN (计算节点) 取代，并且存储功能被卸载到对象存储或 HDFS。CN 是无状态计算节点，可执行 BE 的所有功能，但存储数据除外。
-
-#### 存储
-
-StarRocks shared-data 集群支持两种存储解决方案：对象存储 (例如，AWS S3、Google GCS、Azure Blob Storage 或 MinIO) 和 HDFS。
-
-在 shared-data 集群中，数据文件格式与 shared-nothing 集群 (具有耦合的存储和计算) 的数据文件格式保持一致。数据被组织成 Segment 文件，并且各种索引技术在云原生表中被重用，云原生表是专门在 shared-data 集群中使用的表。
-
-#### 缓存
-
-StarRocks shared-data 集群将数据存储和计算分离，从而允许每个组件独立扩展，从而降低了成本并提高了弹性。但是，此架构可能会影响查询性能。
-
-为了减轻这种影响，StarRocks 建立了一个多层数据访问系统，包括内存、本地磁盘和远程存储，以更好地满足各种业务需求。
-
-针对热数据的查询直接扫描缓存，然后扫描本地磁盘，而冷数据需要从对象存储加载到本地缓存中，以加速后续查询。通过使热数据靠近计算单元，StarRocks 实现了真正的高性能计算和经济高效的存储。此外，通过数据预取策略优化了对冷数据的访问，从而有效地消除了查询的性能限制。
-
-创建表时可以启用缓存。如果启用了缓存，则数据将被写入本地磁盘和后端对象存储。在查询期间，CN 节点首先从本地磁盘读取数据。如果未找到数据，则将从后端对象存储中检索数据，并同时缓存在本地磁盘上。
-
-
\ No newline at end of file
diff --git a/docs/zh/loading/BrokerLoad.md b/docs/zh/loading/BrokerLoad.md
index 0cab1796..205101c5 100644
--- a/docs/zh/loading/BrokerLoad.md
+++ b/docs/zh/loading/BrokerLoad.md
@@ -6,23 +6,23 @@ displayed_sidebar: docs
import InsertPrivNote from '../_assets/commonMarkdown/insertPrivNote.mdx'
-StarRocks 提供了基于 MySQL 的 Broker Load 导入方法，可帮助您将大量数据从 HDFS 或云存储导入到 StarRocks 中。
+StarRocks 提供了基于 MySQL 的 Broker Load 数据导入方法，可帮助您将大量数据从 HDFS 或云存储导入到 StarRocks 中。
-Broker Load 在异步导入模式下运行。提交导入作业后，StarRocks 会异步运行该作业。您需要使用 [SHOW LOAD](../sql-reference/sql-statements/loading_unloading/SHOW_LOAD.md) 语句或 `curl` 命令来检查作业结果。
+Broker Load 以异步导入模式运行。提交导入作业后，StarRocks 会异步运行该作业。您需要使用 [SHOW LOAD](../sql-reference/sql-statements/loading_unloading/SHOW_LOAD.md) 语句或 `curl` 命令来检查作业结果。
-Broker Load 支持单表导入和多表导入。您可以通过运行一个 Broker Load 作业将一个或多个数据文件导入到一个或多个目标表中。Broker Load 确保每个运行的导入作业在导入多个数据文件时的事务原子性。原子性意味着一个导入作业中多个数据文件的导入必须全部成功或全部失败。不会发生某些数据文件导入成功而其他文件导入失败的情况。
+Broker Load 支持单表导入和多表导入。您可以通过运行一个 Broker Load 作业将一个或多个数据文件导入到一个或多个目标表中。Broker Load 确保每个运行的导入作业在导入多个数据文件时的事务原子性。原子性意味着一个导入作业中多个数据文件的导入必须全部成功或全部失败。不会出现某些数据文件导入成功而其他文件导入失败的情况。
-Broker Load 支持在数据导入时进行数据转换，并支持在数据导入期间通过 UPSERT 和 DELETE 操作进行数据更改。有关详细信息，请参见 [在导入时转换数据](../loading/Etl_in_loading.md) 和 [通过导入更改数据](../loading/Load_to_Primary_Key_tables.md)。
+Broker Load 支持在数据导入时进行数据转换，并支持在数据导入期间通过 UPSERT 和 DELETE 操作进行数据更改。更多信息，请参见 [在导入时转换数据](../loading/Etl_in_loading.md) 和 [通过导入更改数据](../loading/Load_to_Primary_Key_tables.md)。
## 背景信息
-在 v2.4 及更早版本中，StarRocks 依赖 Broker 在 StarRocks 集群和外部存储系统之间建立连接，以运行 Broker Load 作业。因此，您需要在导入语句中输入 `WITH BROKER ""` 来指定要使用的 Broker。这被称为“基于 Broker 的导入”。Broker 是一种独立的无状态服务，与文件系统接口集成。借助 Broker，StarRocks 可以访问和读取存储在外部存储系统中的数据文件，并可以使用自己的计算资源来预处理和导入这些数据文件的数据。
+在 v2.4 及之前的版本中，StarRocks 依赖 Broker 在 StarRocks 集群和外部存储系统之间建立连接，以运行 Broker Load 作业。因此，您需要在导入语句中输入 `WITH BROKER ""` 来指定要使用的 Broker。这被称为“基于 Broker 的导入”。Broker 是一个独立的、无状态的服务，它与文件系统接口集成。通过 Broker，StarRocks 可以访问和读取存储在外部存储系统中的数据文件，并可以使用自己的计算资源来预处理和导入这些数据文件的数据。
-从 v2.5 开始，StarRocks 在运行 Broker Load 作业时，不再依赖 Broker 在 StarRocks 集群和外部存储系统之间建立连接。因此，您不再需要在导入语句中指定 Broker，但仍需要保留 `WITH BROKER` 关键字。这被称为“无 Broker 导入”。
+从 v2.5 开始，StarRocks 在运行 Broker Load 作业时，不再依赖 Broker 在 StarRocks 集群和外部存储系统之间建立连接。因此，您不再需要在导入语句中指定 Broker，但仍然需要保留 `WITH BROKER` 关键字。这被称为“无 Broker 导入”。
-当您的数据存储在 HDFS 中时，您可能会遇到无 Broker 导入不起作用的情况。当您的数据存储在多个 HDFS 集群中或您配置了多个 Kerberos 用户时，可能会发生这种情况。在这些情况下，您可以改为使用基于 Broker 的导入。要成功执行此操作，请确保至少部署了一个独立的 Broker 组。有关如何在这些情况下指定身份验证配置和 HA 配置的信息，请参见 [HDFS](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#hdfs)。
+当您的数据存储在 HDFS 中时，您可能会遇到无 Broker 导入不起作用的情况。当您的数据存储在多个 HDFS 集群中，或者您配置了多个 Kerberos 用户时，可能会发生这种情况。在这些情况下，您可以改为使用基于 Broker 的导入。要成功执行此操作，请确保至少部署了一个独立的 Broker 组。有关如何在这些情况下指定身份验证配置和 HA 配置的信息，请参见 [HDFS](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#hdfs)。
## 支持的数据文件格式
@@ -34,7 +34,7 @@ Broker Load 支持以下数据文件格式：
- ORC
-> **NOTE**
+> **注意**
>
> 对于 CSV 数据，请注意以下几点：
>
@@ -57,7 +57,7 @@ Broker Load 支持以下存储系统：
## 工作原理
-在您向 FE 提交导入作业后，FE 会生成一个查询计划，根据可用 BE 的数量和要导入的数据文件的大小将查询计划拆分为多个部分，然后将查询计划的每个部分分配给一个可用的 BE。在导入期间，每个涉及的 BE 从您的 HDFS 或云存储系统中提取数据文件的数据，预处理数据，然后将数据导入到您的 StarRocks 集群中。在所有 BE 完成其查询计划部分后，FE 确定导入作业是否成功。
+在您向 FE 提交一个导入作业后，FE 会生成一个查询计划，根据可用 BE 的数量和您要导入的数据文件的大小将查询计划拆分为多个部分，然后将查询计划的每个部分分配给一个可用的 BE。在导入期间，每个涉及的 BE 从您的 HDFS 或云存储系统中提取数据文件的数据，预处理数据，然后将数据导入到您的 StarRocks 集群中。在所有 BE 完成其查询计划的部分后，FE 确定导入作业是否成功。
下图显示了 Broker Load 作业的工作流程。
@@ -69,7 +69,7 @@ Broker Load 支持以下存储系统：
本主题以 CSV 为例，介绍如何将多个数据文件导入到多个表中。有关如何导入其他文件格式的数据以及 Broker Load 的语法和参数说明，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md)。
-请注意，在 StarRocks 中，某些字面量被 SQL 语言用作保留关键字。请勿在 SQL 语句中直接使用这些关键字。如果要在 SQL 语句中使用此类关键字，请将其括在一对反引号 (`) 中。请参见 [关键字](../sql-reference/sql-statements/keywords.md)。
+请注意，在 StarRocks 中，某些字面量被 SQL 语言用作保留关键字。不要在 SQL 语句中直接使用这些关键字。如果您想在 SQL 语句中使用这样的关键字，请将其用一对反引号 (`) 括起来。请参见 [关键字](../sql-reference/sql-statements/keywords.md)。
#### 数据示例
@@ -92,7 +92,7 @@ Broker Load 支持以下存储系统：
2. 在 StarRocks 数据库 `test_db` 中创建 StarRocks 表。
- > **NOTE**
+ > **注意**
>
> 从 v2.5.7 开始，StarRocks 可以在您创建表或添加分区时自动设置 bucket 数量 (BUCKETS)。您不再需要手动设置 bucket 数量。有关详细信息，请参见 [设置 bucket 数量](../table_design/data_distribution/Data_distribution.md#set-the-number-of-buckets)。
@@ -127,7 +127,7 @@ Broker Load 支持以下存储系统：
#### 从 HDFS 加载数据
-执行以下语句，将 `file1.csv` 和 `file2.csv` 从 HDFS 集群的 `/user/starrocks` 路径分别加载到 `table1` 和 `table2` 中：
+执行以下语句，将 HDFS 集群的 `/user/starrocks` 路径下的 `file1.csv` 和 `file2.csv` 分别加载到 `table1` 和 `table2` 中：
```SQL
LOAD LABEL test_db.label1
@@ -152,11 +152,11 @@ PROPERTIES
);
```
-在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关详细信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#hdfs)。
+在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关更多信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#hdfs)。
#### 从 AWS S3 加载数据
-执行以下语句，将 `file1.csv` 和 `file2.csv` 从 AWS S3 bucket `bucket_s3` 的 `input` 文件夹分别加载到 `table1` 和 `table2` 中：
+执行以下语句，将 AWS S3 bucket `bucket_s3` 的 `input` 文件夹下的 `file1.csv` 和 `file2.csv` 分别加载到 `table1` 和 `table2` 中：
```SQL
LOAD LABEL test_db.label2
@@ -177,17 +177,17 @@ WITH BROKER
);
```
-> **NOTE**
+> **注意**
>
-> Broker Load 仅支持根据 S3A 协议访问 AWS S3。因此，当您从 AWS S3 加载数据时，必须将您作为文件路径传递的 S3 URI 中的 `s3://` 替换为 `s3a://`。
+> Broker Load 仅支持根据 S3A 协议访问 AWS S3。因此，当您从 AWS S3 加载数据时，您必须将作为文件路径传递的 S3 URI 中的 `s3://` 替换为 `s3a://`。
-在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关详细信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#aws-s3)。
+在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关更多信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#aws-s3)。
-从 v3.1 开始，StarRocks 支持通过使用 INSERT 命令和 TABLE 关键字直接从 AWS S3 加载 Parquet 格式或 ORC 格式的文件数据，从而省去了首先创建外部表的麻烦。有关详细信息，请参见 [使用 INSERT 加载数据 > 使用 TABLE 关键字直接从外部源的文件中插入数据](../loading/InsertInto.md#insert-data-directly-from-files-in-an-external-source-using-files)。
+从 v3.1 开始，StarRocks 支持使用 INSERT 命令和 TABLE 关键字直接从 AWS S3 加载 Parquet 格式或 ORC 格式的文件数据，从而省去了先创建外部表的麻烦。有关更多信息，请参见 [使用 INSERT 加载数据 > 使用 TABLE 关键字直接从外部源的文件中插入数据](../loading/InsertInto.md#insert-data-directly-from-files-in-an-external-source-using-files)。
#### 从 Google GCS 加载数据
-执行以下语句，将 `file1.csv` 和 `file2.csv` 从 Google GCS bucket `bucket_gcs` 的 `input` 文件夹分别加载到 `table1` 和 `table2` 中：
+执行以下语句，将 Google GCS bucket `bucket_gcs` 的 `input` 文件夹下的 `file1.csv` 和 `file2.csv` 分别加载到 `table1` 和 `table2` 中：
```SQL
LOAD LABEL test_db.label3
@@ -208,15 +208,15 @@ WITH BROKER
);
```
-> **NOTE**
+> **注意**
>
-> Broker Load 仅支持根据 gs 协议访问 Google GCS。因此，当您从 Google GCS 加载数据时，必须在您作为文件路径传递的 GCS URI 中包含 `gs://` 作为前缀。
+> Broker Load 仅支持根据 gs 协议访问 Google GCS。因此，当您从 Google GCS 加载数据时，您必须在作为文件路径传递的 GCS URI 中包含 `gs://` 作为前缀。
-在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关详细信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#google-gcs)。
+在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关更多信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#google-gcs)。
#### 从其他 S3 兼容的存储系统加载数据
-以 MinIO 为例。您可以执行以下语句，将 `file1.csv` 和 `file2.csv` 从 MinIO bucket `bucket_minio` 的 `input` 文件夹分别加载到 `table1` 和 `table2` 中：
+以 MinIO 为例。您可以执行以下语句，将 MinIO bucket `bucket_minio` 的 `input` 文件夹下的 `file1.csv` 和 `file2.csv` 分别加载到 `table1` 和 `table2` 中：
```SQL
LOAD LABEL test_db.label7
@@ -237,11 +237,11 @@ WITH BROKER
);
```
-在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关详细信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#other-s3-compatible-storage-system)。
+在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关更多信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#other-s3-compatible-storage-system)。
#### 从 Microsoft Azure Storage 加载数据
-执行以下语句，将 `file1.csv` 和 `file2.csv` 从 Azure Storage 的指定路径加载：
+执行以下语句，从 Azure Storage 的指定路径加载 `file1.csv` 和 `file2.csv`：
```SQL
LOAD LABEL test_db.label8
@@ -262,23 +262,23 @@ WITH BROKER
);
```
-> **NOTICE**
+> **注意**
>
- > 从 Azure Storage 加载数据时，您需要根据您使用的访问协议和特定存储服务来确定要使用的前缀。以下示例使用 Blob Storage 作为示例。
+ > 当您从 Azure Storage 加载数据时，您需要根据您使用的访问协议和特定存储服务来确定要使用的前缀。前面的示例使用 Blob Storage 作为示例。
>
- > - 当您从 Blob Storage 加载数据时，您必须根据用于访问存储帐户的协议在文件路径中包含 `wasb://` 或 `wasbs://` 作为前缀：
+ > - 当您从 Blob Storage 加载数据时，您必须根据用于访问您的存储帐户的协议，在文件路径中包含 `wasb://` 或 `wasbs://` 作为前缀：
> - 如果您的 Blob Storage 仅允许通过 HTTP 进行访问，请使用 `wasb://` 作为前缀，例如 `wasb://@.blob.core.windows.net///*`。
> - 如果您的 Blob Storage 仅允许通过 HTTPS 进行访问，请使用 `wasbs://` 作为前缀，例如 `wasbs://@.blob.core.windows.net///*`
> - 当您从 Data Lake Storage Gen1 加载数据时，您必须在文件路径中包含 `adl://` 作为前缀，例如 `adl://.azuredatalakestore.net//`。
- > - 当您从 Data Lake Storage Gen2 加载数据时，您必须根据用于访问存储帐户的协议在文件路径中包含 `abfs://` 或 `abfss://` 作为前缀：
+ > - 当您从 Data Lake Storage Gen2 加载数据时，您必须根据用于访问您的存储帐户的协议，在文件路径中包含 `abfs://` 或 `abfss://` 作为前缀：
> - 如果您的 Data Lake Storage Gen2 仅允许通过 HTTP 进行访问，请使用 `abfs://` 作为前缀，例如 `abfs://@.dfs.core.windows.net/`。
> - 如果您的 Data Lake Storage Gen2 仅允许通过 HTTPS 进行访问，请使用 `abfss://` 作为前缀，例如 `abfss://@.dfs.core.windows.net/`。
-在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关详细信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#microsoft-azure-storage)。
+在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关更多信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#microsoft-azure-storage)。
#### 查询数据
-从 HDFS 集群、AWS S3 bucket 或 Google GCS bucket 加载数据完成后，您可以使用 SELECT 语句查询 StarRocks 表的数据，以验证加载是否成功。
+从您的 HDFS 集群、AWS S3 bucket 或 Google GCS bucket 加载数据完成后，您可以使用 SELECT 语句查询 StarRocks 表的数据，以验证加载是否成功。
1. 执行以下语句以查询 `table1` 的数据：
@@ -309,7 +309,7 @@ WITH BROKER
### 创建单表导入作业
-您还可以将单个数据文件或指定路径中的所有数据文件加载到单个目标表中。假设您的 AWS S3 bucket `bucket_s3` 包含一个名为 `input` 的文件夹。`input` 文件夹包含多个数据文件，其中一个名为 `file1.csv`。这些数据文件包含与 `table1` 相同的列数，并且来自每个数据文件的列可以按顺序一一映射到来自 `table1` 的列。
+您还可以将单个数据文件或指定路径中的所有数据文件加载到单个目标表中。假设您的 AWS S3 bucket `bucket_s3` 包含一个名为 `input` 的文件夹。`input` 文件夹包含多个数据文件，其中一个名为 `file1.csv`。这些数据文件包含与 `table1` 相同的列数，并且这些数据文件中的每一列都可以按顺序一一映射到 `table1` 中的列。
要将 `file1.csv` 加载到 `table1` 中，请执行以下语句：
@@ -343,15 +343,15 @@ WITH BROKER
);
```
-在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关详细信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#aws-s3)。
+在上面的示例中，`StorageCredentialParams` 表示一组身份验证参数，这些参数因您选择的身份验证方法而异。有关更多信息，请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#aws-s3)。
### 查看导入作业
-Broker Load 允许您使用 SHOW LOAD 语句或 `curl` 命令查看 lob 作业。
+Broker Load 允许您使用 SHOW LOAD 语句或 `curl` 命令来查看导入作业。
#### 使用 SHOW LOAD
-有关详细信息，请参见 [SHOW LOAD](../sql-reference/sql-statements/loading_unloading/SHOW_LOAD.md)。
+有关更多信息，请参见 [SHOW LOAD](../sql-reference/sql-statements/loading_unloading/SHOW_LOAD.md)。
#### 使用 curl
@@ -362,7 +362,7 @@ curl --location-trusted -u : \
'http://:/api//_load_info?label='
```
-> **NOTE**
+> **注意**
>
> 如果您使用的帐户未设置密码，则只需输入 `:`。
@@ -386,17 +386,17 @@ curl --location-trusted -u : \
| dbName | 要将数据加载到的数据库的名称。 |
| tblNames | 要将数据加载到的表的名称。 |
| label | 导入作业的标签。 |
-| state | 导入作业的状态。有效值：- `PENDING`：导入作业正在队列中等待调度。
- `QUEUEING`：导入作业正在队列中等待调度。
- `LOADING`：导入作业正在运行。
- `PREPARED`：事务已提交。
- `FINISHED`：导入作业成功。
- `CANCELLED`：导入作业失败。
有关详细信息，请参见 [导入概念](./loading_introduction/loading_concepts.md) 中的“异步导入”部分。 |
-| failMsg | 导入作业失败的原因。如果导入作业的 `state` 值为 `PENDING`、`LOADING` 或 `FINISHED`，则为 `failMsg` 参数返回 `NULL`。如果导入作业的 `state` 值为 `CANCELLED`，则为 `failMsg` 参数返回的值由两部分组成：`type` 和 `msg`。- `type` 部分可以是以下任何值：
- `USER_CANCEL`：导入作业已手动取消。
- `ETL_SUBMIT_FAIL`：导入作业未能提交。
- `ETL-QUALITY-UNSATISFIED`：导入作业失败，因为不合格数据的百分比超过了 `max-filter-ratio` 参数的值。
- `LOAD-RUN-FAIL`：导入作业在 `LOADING` 阶段失败。
- `TIMEOUT`：导入作业未在指定的超时时间内完成。
- `UNKNOWN`：导入作业因未知错误而失败。
- `msg` 部分提供了导入失败的详细原因。
|
-| trackingUrl | 用于访问在导入作业中检测到的不合格数据的 URL。您可以使用 `curl` 或 `wget` 命令访问该 URL 并获取不合格数据。如果未检测到不合格数据，则为 `trackingUrl` 参数返回 `NULL`。 |
-| status | 导入作业的 HTTP 请求的状态。有效值为：`OK` 和 `Fail`。 |
+| state | 导入作业的状态。有效值：- `PENDING`：导入作业正在队列中等待调度。
- `QUEUEING`：导入作业正在队列中等待调度。
- `LOADING`：导入作业正在运行。
- `PREPARED`：事务已提交。
- `FINISHED`：导入作业成功。
- `CANCELLED`：导入作业失败。
有关更多信息，请参见 [导入概念](./loading_introduction/loading_concepts.md) 中的“异步导入”部分。 |
+| failMsg | 导入作业失败的原因。如果导入作业的 `state` 值为 `PENDING`、`LOADING` 或 `FINISHED`，则为 `failMsg` 参数返回 `NULL`。如果导入作业的 `state` 值为 `CANCELLED`，则为 `failMsg` 参数返回的值由两部分组成：`type` 和 `msg`。- `type` 部分可以是以下任何值：
- `USER_CANCEL`：导入作业已手动取消。
- `ETL_SUBMIT_FAIL`：导入作业未能提交。
- `ETL-QUALITY-UNSATISFIED`：导入作业失败，因为不合格数据的百分比超过了 `max-filter-ratio` 参数的值。
- `LOAD-RUN-FAIL`：导入作业在 `LOADING` 阶段失败。
- `TIMEOUT`：导入作业未在指定的超时时间内完成。
- `UNKNOWN`：导入作业由于未知错误而失败。
- `msg` 部分提供了导入失败的详细原因。
|
+| trackingUrl | 用于访问在导入作业中检测到的不合格数据的 URL。您可以使用 `curl` 或 `wget` 命令来访问该 URL 并获取不合格数据。如果未检测到不合格数据，则为 `trackingUrl` 参数返回 `NULL`。 |
+| status | 导入作业的 HTTP 请求的状态。有效值：`OK` 和 `Fail`。 |
| msg | 导入作业的 HTTP 请求的错误信息。 |
### 取消导入作业
-当导入作业未处于 **CANCELLED** 或 **FINISHED** 阶段时，您可以使用 [CANCEL LOAD](../sql-reference/sql-statements/loading_unloading/CANCEL_LOAD.md) 语句取消该作业。
+当导入作业未处于 **CANCELLED** 或 **FINISHED** 阶段时，您可以使用 [CANCEL LOAD](../sql-reference/sql-statements/loading_unloading/CANCEL_LOAD.md) 语句来取消该作业。
-例如，您可以执行以下语句以取消数据库 `test_db` 中标签为 `label1` 的导入作业：
+例如，您可以执行以下语句来取消数据库 `test_db` 中标签为 `label1` 的导入作业：
```SQL
CANCEL LOAD
@@ -406,19 +406,19 @@ WHERE LABEL = "label";
## 作业拆分和并发运行
-一个 Broker Load 作业可以拆分为一个或多个并发运行的任务。一个导入作业中的所有任务都在一个事务中运行。它们必须全部成功或全部失败。StarRocks 根据您在 `LOAD` 语句中如何声明 `data_desc` 来拆分每个导入作业：
+一个 Broker Load 作业可以拆分为一个或多个并发运行的任务。一个导入作业中的任务在单个事务中运行。它们必须全部成功或全部失败。StarRocks 根据您在 `LOAD` 语句中如何声明 `data_desc` 来拆分每个导入作业：
- 如果您声明了多个 `data_desc` 参数，每个参数指定一个不同的表，则会生成一个任务来加载每个表的数据。
- 如果您声明了多个 `data_desc` 参数，每个参数指定同一表的不同分区，则会生成一个任务来加载每个分区的数据。
-此外，每个任务可以进一步拆分为一个或多个实例，这些实例均匀分布到 StarRocks 集群的 BE 上并并发运行。StarRocks 根据以下 [FE 配置](../administration/management/FE_configuration.md) 拆分每个任务：
+此外，每个任务可以进一步拆分为一个或多个实例，这些实例均匀分布并在 StarRocks 集群的 BE 上并发运行。StarRocks 根据以下 [FE 配置](../administration/management/FE_configuration.md) 拆分每个任务：
- `min_bytes_per_broker_scanner`：每个实例处理的最小数据量。默认量为 64 MB。
- `load_parallel_instance_num`：每个 BE 上每个导入作业中允许的并发实例数。默认数量为 1。
- 您可以使用以下公式计算单个任务中的实例数：
+ 您可以使用以下公式来计算单个任务中的实例数：
**单个任务中的实例数 = min(单个任务要加载的数据量/`min_bytes_per_broker_scanner`，`load_parallel_instance_num` x BE 数量)**
@@ -428,6 +428,6 @@ WHERE LABEL = "label";
[FE 配置项](../administration/management/FE_configuration.md) `max_broker_load_job_concurrency` 指定了 StarRocks 集群中可以并发运行的最大 Broker Load 作业数。
-在 StarRocks v2.4 及更早版本中，如果在特定时间段内提交的 Broker Load 作业总数超过最大数量，则会将过多的作业排队并根据其提交时间进行调度。
+在 StarRocks v2.4 及更早版本中，如果在特定时间段内提交的 Broker Load 作业总数超过最大数量，则会根据提交时间对过多的作业进行排队和调度。
-自 StarRocks v2.5 以来，如果在特定时间段内提交的 Broker Load 作业总数超过最大数量，则会将过多的作业排队并根据其优先级进行调度。您可以在创建作业时使用 `priority` 参数为作业指定优先级。请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#opt_properties)。您还可以使用 [ALTER LOAD](../sql-reference/sql-statements/loading_unloading/ALTER_LOAD.md) 修改处于 **QUEUEING** 或 **LOADING** 状态的现有作业的优先级。
\ No newline at end of file
+自 StarRocks v2.5 以来，如果在特定时间段内提交的 Broker Load 作业总数超过最大数量，则会根据优先级对过多的作业进行排队和调度。您可以在创建作业时使用 `priority` 参数为作业指定优先级。请参见 [BROKER LOAD](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#opt_properties)。您还可以使用 [ALTER LOAD](../sql-reference/sql-statements/loading_unloading/ALTER_LOAD.md) 来修改处于 **QUEUEING** 或 **LOADING** 状态的现有作业的优先级。
\ No newline at end of file
diff --git a/docs/zh/quick_start/shared-nothing.md b/docs/zh/quick_start/shared-nothing.md
new file mode 100644
index 00000000..9f262116
--- /dev/null
+++ b/docs/zh/quick_start/shared-nothing.md
@@ -0,0 +1,246 @@
+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'
+import Curl from '../_assets/quick-start/_curl.mdx'
+
+# 使用 Docker 部署 StarRocks
+
+本教程涵盖：
+
+- 在单个 Docker 容器中运行 StarRocks
+- 导入两个公共数据集，包括数据的基本转换
+- 使用 SELECT 和 JOIN 分析数据
+- 基本数据转换（ETL 中的 **T**）
+
+## 如果您愿意，可以观看视频
+
+
+
+所使用的数据由 NYC OpenData 和 National Centers for Environmental Information 提供。
+
+这两个数据集都非常大，并且由于本教程旨在帮助您了解如何使用 StarRocks，因此我们不会导入过去 120 年的数据。您可以在分配给 Docker 的 4 GB RAM 的机器上运行 Docker 镜像并导入此数据。对于更大、容错和可扩展的部署，我们有其他文档，稍后会提供。
+
+本文档包含大量信息，并且以逐步内容的形式在开头呈现，技术细节在结尾呈现。这样做是为了按以下顺序实现这些目的：
+
+1. 允许读者在 StarRocks 中导入数据并分析该数据。
+2. 解释导入期间数据转换的基础知识。
+
+---
+
+## 前提条件
+
+### Docker
+
+- [Docker](https://docs.docker.com/engine/install/)
+- 分配给 Docker 的 4 GB RAM
+- 分配给 Docker 的 10 GB 可用磁盘空间
+
+### SQL 客户端
+
+您可以使用 Docker 环境中提供的 SQL 客户端，也可以使用系统上的 SQL 客户端。许多与 MySQL 兼容的客户端都可以工作，本指南涵盖了 DBeaver 和 MySQL Workbench 的配置。
+
+### curl
+
+`curl` 用于向 StarRocks 发出数据导入作业，并下载数据集。通过在操作系统提示符下运行 `curl` 或 `curl.exe` 来检查是否已安装。如果未安装 curl，请[在此处获取 curl](https://curl.se/dlwiz/?type=bin)。
+
+---
+
+## 术语
+
+### FE
+
+FE 节点负责元数据管理、客户端连接管理、查询计划和查询调度。每个 FE 在其内存中存储和维护元数据的完整副本，这保证了 FE 之间的无差别服务。
+
+### BE
+
+BE 节点负责数据存储和执行查询计划。
+
+---
+
+## 启动 StarRocks
+
+```bash
+docker pull starrocks/allin1-ubuntu
+docker run -p 9030:9030 -p 8030:8030 -p 8040:8040 -itd \
+--name quickstart starrocks/allin1-ubuntu
+```
+
+---
+
+## SQL 客户端
+
+
+
+---
+
+## 下载数据
+
+将这两个数据集下载到您的机器。您可以将它们下载到运行 Docker 的主机上，不需要在容器内下载。
+
+### 纽约市碰撞数据
+
+```bash
+curl -O https://raw.githubusercontent.com/StarRocks/demo/master/documentation-samples/quickstart/datasets/NYPD_Crash_Data.csv
+```
+
+### 天气数据
+
+```bash
+curl -O https://raw.githubusercontent.com/StarRocks/demo/master/documentation-samples/quickstart/datasets/72505394728.csv
+```
+
+---
+
+### 使用 SQL 客户端连接到 StarRocks
+
+:::tip
+
+如果您使用的客户端不是 mysql CLI，请立即打开它。
+:::
+
+此命令将在 Docker 容器中运行 `mysql` 命令：
+
+```sql
+docker exec -it quickstart \
+mysql -P 9030 -h 127.0.0.1 -u root --prompt="StarRocks > "
+```
+
+---
+
+## 创建一些表
+
+
+
+---
+
+## 导入两个数据集
+
+有很多方法可以将数据导入到 StarRocks 中。对于本教程，最简单的方法是使用 curl 和 StarRocks Stream Load。
+
+:::tip
+打开一个新的 shell，因为这些 curl 命令是在操作系统提示符下运行的，而不是在 `mysql` 客户端中运行的。这些命令引用您下载的数据集，因此请从下载文件的目录中运行它们。
+
+系统将提示您输入密码。您可能尚未为 MySQL `root` 用户分配密码，因此只需按 Enter 键即可。
+:::
+
+`curl` 命令看起来很复杂，但本教程的最后会详细解释它们。现在，我们建议运行这些命令并运行一些 SQL 来分析数据，然后在最后阅读有关数据导入详细信息的说明。
+
+### 纽约市碰撞数据 - 碰撞事故
+
+```bash
+curl --location-trusted -u root \
+ -T ./NYPD_Crash_Data.csv \
+ -H "label:crashdata-0" \
+ -H "column_separator:," \
+ -H "skip_header:1" \
+ -H "enclose:\"" \
+ -H "max_filter_ratio:1" \
+ -H "columns:tmp_CRASH_DATE, tmp_CRASH_TIME, CRASH_DATE=str_to_date(concat_ws(' ', tmp_CRASH_DATE, tmp_CRASH_TIME), '%m/%d/%Y %H:%i'),BOROUGH,ZIP_CODE,LATITUDE,LONGITUDE,LOCATION,ON_STREET_NAME,CROSS_STREET_NAME,OFF_STREET_NAME,NUMBER_OF_PERSONS_INJURED,NUMBER_OF_PERSONS_KILLED,NUMBER_OF_PEDESTRIANS_INJURED,NUMBER_OF_PEDESTRIANS_KILLED,NUMBER_OF_CYCLIST_INJURED,NUMBER_OF_CYCLIST_KILLED,NUMBER_OF_MOTORIST_INJURED,NUMBER_OF_MOTORIST_KILLED,CONTRIBUTING_FACTOR_VEHICLE_1,CONTRIBUTING_FACTOR_VEHICLE_2,CONTRIBUTING_FACTOR_VEHICLE_3,CONTRIBUTING_FACTOR_VEHICLE_4,CONTRIBUTING_FACTOR_VEHICLE_5,COLLISION_ID,VEHICLE_TYPE_CODE_1,VEHICLE_TYPE_CODE_2,VEHICLE_TYPE_CODE_3,VEHICLE_TYPE_CODE_4,VEHICLE_TYPE_CODE_5" \
+ -XPUT http://localhost:8030/api/quickstart/crashdata/_stream_load
+```
+
+以下是上述命令的输出。第一个突出显示的部分显示了您应该看到的内容（OK 和除一行之外的所有行都已插入）。有一行被过滤掉，因为它不包含正确的列数。
+
+```bash
+Enter host password for user 'root':
+{
+ "TxnId": 2,
+ "Label": "crashdata-0",
+ "Status": "Success",
+ # highlight-start
+ "Message": "OK",
+ "NumberTotalRows": 423726,
+ "NumberLoadedRows": 423725,
+ # highlight-end
+ "NumberFilteredRows": 1,
+ "NumberUnselectedRows": 0,
+ "LoadBytes": 96227746,
+ "LoadTimeMs": 1013,
+ "BeginTxnTimeMs": 21,
+ "StreamLoadPlanTimeMs": 63,
+ "ReadDataTimeMs": 563,
+ "WriteDataTimeMs": 870,
+ "CommitAndPublishTimeMs": 57,
+ # highlight-start
+ "ErrorURL": "http://127.0.0.1:8040/api/_load_error_log?file=error_log_da41dd88276a7bfc_739087c94262ae9f"
+ # highlight-end
+}%
+```
+
+如果出现错误，输出会提供一个 URL 来查看错误消息。在浏览器中打开此 URL 以找出发生了什么。展开详细信息以查看示例错误消息：
+
+
+
+在浏览器中读取错误消息
+
+```bash
+Error: Target column count: 29 doesn't match source value column count: 32. Column separator: ',', Row delimiter: '\n'. Row: 09/06/2015,14:15,,,40.6722269,-74.0110059,"(40.6722269, -74.0110059)",,,"R/O 1 BEARD ST. ( IKEA'S
+09/14/2015,5:30,BRONX,10473,40.814551,-73.8490955,"(40.814551, -73.8490955)",TORRY AVENUE ,NORTON AVENUE ,,0,0,0,0,0,0,0,0,Driver Inattention/Distraction,Unspecified,,,,3297457,PASSENGER VEHICLE,PASSENGER VEHICLE,,,
+```
+
+
+
+### 天气数据
+
+以与导入碰撞数据相同的方式导入天气数据集。
+
+```bash
+curl --location-trusted -u root \
+ -T ./72505394728.csv \
+ -H "label:weather-0" \
+ -H "column_separator:," \
+ -H "skip_header:1" \
+ -H "enclose:\"" \
+ -H "max_filter_ratio:1" \
+ -H "columns: STATION, DATE, LATITUDE, LONGITUDE, ELEVATION, NAME, REPORT_TYPE, SOURCE, HourlyAltimeterSetting, HourlyDewPointTemperature, HourlyDryBulbTemperature, HourlyPrecipitation, HourlyPresentWeatherType, HourlyPressureChange, HourlyPressureTendency, HourlyRelativeHumidity, HourlySkyConditions, HourlySeaLevelPressure, HourlyStationPressure, HourlyVisibility, HourlyWetBulbTemperature, HourlyWindDirection, HourlyWindGustSpeed, HourlyWindSpeed, Sunrise, Sunset, DailyAverageDewPointTemperature, DailyAverageDryBulbTemperature, DailyAverageRelativeHumidity, DailyAverageSeaLevelPressure, DailyAverageStationPressure, DailyAverageWetBulbTemperature, DailyAverageWindSpeed, DailyCoolingDegreeDays, DailyDepartureFromNormalAverageTemperature, DailyHeatingDegreeDays, DailyMaximumDryBulbTemperature, DailyMinimumDryBulbTemperature, DailyPeakWindDirection, DailyPeakWindSpeed, DailyPrecipitation, DailySnowDepth, DailySnowfall, DailySustainedWindDirection, DailySustainedWindSpeed, DailyWeather, MonthlyAverageRH, MonthlyDaysWithGT001Precip, MonthlyDaysWithGT010Precip, MonthlyDaysWithGT32Temp, MonthlyDaysWithGT90Temp, MonthlyDaysWithLT0Temp, MonthlyDaysWithLT32Temp, MonthlyDepartureFromNormalAverageTemperature, MonthlyDepartureFromNormalCoolingDegreeDays, MonthlyDepartureFromNormalHeatingDegreeDays, MonthlyDepartureFromNormalMaximumTemperature, MonthlyDepartureFromNormalMinimumTemperature, MonthlyDepartureFromNormalPrecipitation, MonthlyDewpointTemperature, MonthlyGreatestPrecip, MonthlyGreatestPrecipDate, MonthlyGreatestSnowDepth, MonthlyGreatestSnowDepthDate, MonthlyGreatestSnowfall, MonthlyGreatestSnowfallDate, MonthlyMaxSeaLevelPressureValue, MonthlyMaxSeaLevelPressureValueDate, MonthlyMaxSeaLevelPressureValueTime, MonthlyMaximumTemperature, MonthlyMeanTemperature, MonthlyMinSeaLevelPressureValue, MonthlyMinSeaLevelPressureValueDate, MonthlyMinSeaLevelPressureValueTime, MonthlyMinimumTemperature, MonthlySeaLevelPressure, MonthlyStationPressure, MonthlyTotalLiquidPrecipitation, MonthlyTotalSnowfall, MonthlyWetBulb, AWND, CDSD, CLDD, DSNW, HDSD, HTDD, NormalsCoolingDegreeDay, NormalsHeatingDegreeDay, ShortDurationEndDate005, ShortDurationEndDate010, ShortDurationEndDate015, ShortDurationEndDate020, ShortDurationEndDate030, ShortDurationEndDate045, ShortDurationEndDate060, ShortDurationEndDate080, ShortDurationEndDate100, ShortDurationEndDate120, ShortDurationEndDate150, ShortDurationEndDate180, ShortDurationPrecipitationValue005, ShortDurationPrecipitationValue010, ShortDurationPrecipitationValue015, ShortDurationPrecipitationValue020, ShortDurationPrecipitationValue030, ShortDurationPrecipitationValue045, ShortDurationPrecipitationValue060, ShortDurationPrecipitationValue080, ShortDurationPrecipitationValue100, ShortDurationPrecipitationValue120, ShortDurationPrecipitationValue150, ShortDurationPrecipitationValue180, REM, BackupDirection, BackupDistance, BackupDistanceUnit, BackupElements, BackupElevation, BackupEquipment, BackupLatitude, BackupLongitude, BackupName, WindEquipmentChangeDate" \
+ -XPUT http://localhost:8030/api/quickstart/weatherdata/_stream_load
+```
+
+---
+
+## 回答一些问题
+
+
+
+---
+
+## 总结
+
+在本教程中，您：
+
+- 在 Docker 中部署了 StarRocks
+- 导入了纽约市提供的碰撞数据和 NOAA 提供的天气数据
+- 使用 SQL JOIN 分析了数据，发现低能见度或冰雪路面行车不是一个好主意
+
+还有更多内容需要学习；我们有意忽略了在 Stream Load 期间完成的数据转换。有关详细信息，请参见下面的 curl 命令注释。
+
+---
+
+## 关于 curl 命令的说明
+
+
+
+---
+
+## 更多信息
+
+[StarRocks 表设计 ](../table_design/StarRocks_table_design.md)
+
+[Stream Load ](../sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md)
+
+[机动车辆碰撞 - 碰撞事故](https://data.cityofnewyork.us/Public-Safety/Motor-Vehicle-Collisions-Crashes/h9gi-nx95) 数据集由纽约市提供，受以下 [使用条款](https://www.nyc.gov/home/terms-of-use.page) 和 [隐私政策](https://www.nyc.gov/home/privacy-policy.page) 的约束。
+
+[本地气候数据](https://www.ncdc.noaa.gov/cdo-web/datatools/lcd)(LCD) 由 NOAA 提供，带有此 [免责声明](https://www.noaa.gov/disclaimer) 和此 [隐私政策](https://www.noaa.gov/protecting-your-privacy)。
\ No newline at end of file