From 4ccbc1d29d65fc444eb137942a08429c704141eb Mon Sep 17 00:00:00 2001 From: DanRoscigno Date: Thu, 12 Feb 2026 19:02:29 -0500 Subject: [PATCH 1/5] trigger Signed-off-by: DanRoscigno --- docs/en/loading/SparkLoad.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/loading/SparkLoad.md b/docs/en/loading/SparkLoad.md index 8794ce34..e2909515 100644 --- a/docs/en/loading/SparkLoad.md +++ b/docs/en/loading/SparkLoad.md @@ -4,7 +4,7 @@ displayed_sidebar: docs # Load data in bulk using Spark Load -This load uses external Apache Spark™ resources to pre-process imported data, which improves import performance and saves compute resources. It is mainly used for **initial migration** and **large data import** into StarRocks (data volume up to TB level). +Spark load uses external Apache Spark™ resources to pre-process imported data, which improves import performance and saves compute resources. It is mainly used for **initial migration** and **large data import** into StarRocks (data volume up to TB level). Spark load is an **asynchronous** import method that requires users to create Spark-type import jobs via the MySQL protocol and view the import results using `SHOW LOAD`. From 999f704aaf742b3f9ff329fd85e615b0ce9f7488 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Fri, 13 Feb 2026 00:06:41 +0000 Subject: [PATCH 2/5] chore: add automated translations Generated by markdown-translator Triggered by: @DanRoscigno --- docs/ja/loading/SparkLoad.md | 532 +++++++++++++++++++++++++++++++++++ docs/zh/loading/SparkLoad.md | 285 ++++++++++--------- 2 files changed, 674 insertions(+), 143 deletions(-) create mode 100644 docs/ja/loading/SparkLoad.md diff --git a/docs/ja/loading/SparkLoad.md b/docs/ja/loading/SparkLoad.md new file mode 100644 index 00000000..0c8236ea --- /dev/null +++ b/docs/ja/loading/SparkLoad.md @@ -0,0 +1,532 @@ +displayed_sidebar: docs + +# Spark Load を使用して大量のデータをロードする + +Spark Load は、外部の Apache Spark™ リソースを使用してインポートされるデータを前処理します。これにより、インポートパフォーマンスが向上し、コンピュートリソースを節約できます。主に StarRocks への**初期移行**や**大量のデータインポート** (データ量は TB レベルまで) に使用されます。 + +Spark Load は**非同期**のインポート方式であり、ユーザーは MySQL プロトコルを介して Spark タイプインポートジョブを作成し、`SHOW LOAD` を使用してインポート結果を確認する必要があります。 + +> **注意** +> +> - StarRocks テーブルに INSERT 権限を持つユーザーのみがこのテーブルにデータをロードできます。必要な権限を付与するには、[GRANT](../sql-reference/sql-statements/account-management/GRANT.md) で提供されている指示に従ってください。 +> - Spark Load は 主キーテーブル にデータをロードするために使用することはできません。 + +## 用語解説 + +- **Spark ETL**: 主にインポート処理におけるデータの ETL を担当します。これには、グローバル辞書構築 (BITMAP タイプ)、パーティション化、ソート、集計などが含まれます。 +- **Broker**: Broker は独立したステートレスなプロセスです。ファイルシステムインターフェースをカプセル化し、StarRocks にリモートストレージシステムからファイルを読み取る機能を提供します。 +- **グローバル辞書**: 元の値からエンコードされた値へのデータをマッピングするデータ構造を保存します。元の値は任意のデータ型にできますが、エンコードされた値は整数です。グローバル辞書は主に、正確な重複排除カウントが事前計算されるシナリオで主に使用されます。 + +## 基本原理 + +ユーザーは MySQL クライアントを介して Spark タイプインポートジョブを送信します。FE はメタデータを記録し、送信結果を返します。 + +Spark Load タスクの実行は、以下の主要なフェーズに分かれています。 + +1. ユーザーは Spark Load ジョブを FE に送信します。 +2. FE は ETL タスクの実行を Apache Spark™ クラスターにスケジュールします。 +3. Apache Spark™ クラスターは、グローバル辞書構築 (BITMAP タイプ)、パーティション化、ソート、集計などを含む ETL タスクを実行します。 +4. ETL タスクが完了した後、FE は前処理された各スライスのデータパスを取得し、関連する BE に Push タスクを実行するようスケジュールします。 +5. BE は Broker プロセスを介して HDFS からデータを読み込み、StarRocks ストレージ形式に変換します。 + > Broker プロセスを使用しない場合、BE は HDFS から直接データを読み込みます。 +6. FE は有効なバージョンをスケジュールし、インポートジョブを完了します。 + +次の図は、Spark Load の主要な流れを示しています。 + +![Spark Load](../_assets/4.3.2-1.png) + +--- + +## グローバル辞書 + +### 適用シナリオ + +現在、StarRocks の BITMAP 列は Roaringbitmap を使用して実装されており、入力データ型として整数のみを扱います。そのため、インポート処理で BITMAP 列の事前計算を実装する場合、入力データ型を整数に変換する必要があります。 + +StarRocks の既存のインポート処理では、グローバル辞書のデータ構造は Hive テーブルに基づいて実装されており、元の値からエンコードされた値へのマッピングを保存します。 + +### 構築プロセス + +1. アップストリームのデータソースからデータを読み込み、`hive-table` という名前の一時的な Hive テーブルを生成します。 +2. `hive-table` の重複排除されたフィールドの値を抽出し、`distinct-value-table` という名前の新しい Hive テーブルを生成します。 +3. 元の値用の列とエンコードされた値用の列を 1 つずつ持つ、`dict-table` という名前の新しいグローバル辞書テーブルを作成します。 +4. `distinct-value-table` と `dict-table` を左ジョインし、その後、ウィンドウ関数を使用してこのセットをエンコードします。最後に、重複排除された列の元の値とエンコードされた値の両方が `dict-table` に書き戻されます。 +5. `dict-table` と `hive-table` をジョインして、`hive-table` 内の元の値を整数エンコードされた値に置き換える作業を完了します。 +6. `hive-table` は次回のデータ前処理で読み込まれ、計算後、StarRocks にインポートされます。 + +## データ前処理 + +データ前処理の基本的なプロセスは以下の通りです。 + +1. アップストリームのデータソース (HDFS ファイルまたは Hive テーブル) からデータを読み込みます。 +2. 読み込んだデータのフィールドマッピングと計算を完了し、その後、パーティション情報に基づいて `bucket-id` を生成します。 +3. StarRocks テーブルの Rollup メタデータに基づいて RollupTree を生成します。 +4. RollupTree を反復処理し、階層的な集計操作を実行します。次の階層の Rollup は、前の階層の Rollup から計算できます。 +5. 集計計算が完了するたびに、データは `bucket-id` に従ってバケッティングされ、その後 HDFS に書き込まれます。 +6. その後の Broker プロセスは HDFS からファイルをプルし、StarRocks BE ノードにインポートします。 + +## 基本操作 + +### ETL クラスターの構成 + +StarRocks では、ETL 作業に Apache Spark™ が外部の計算リソースとして使用されます。クエリ用の Spark/GPU、外部ストレージ用の HDFS/S3、ETL 用の MapReduce など、他の外部リソースが StarRocks に追加される場合もあります。そのため、StarRocks で使用されるこれらの外部リソースを管理するために `Resource Management` を導入しています。 + +Apache Spark™ インポートジョブを送信する前に、ETL タスクを実行するための Apache Spark™ クラスターを構成します。操作の構文は以下の通りです。 + +~~~sql +-- create Apache Spark™ resource +CREATE EXTERNAL RESOURCE resource_name +PROPERTIES +( + type = spark, + spark_conf_key = spark_conf_value, + working_dir = path, + broker = broker_name, + broker.property_key = property_value +); + +-- drop Apache Spark™ resource +DROP RESOURCE resource_name; + +-- show resources +SHOW RESOURCES +SHOW PROC "/resources"; + +-- privileges +GRANT USAGE_PRIV ON RESOURCE resource_name TO user_identityGRANT USAGE_PRIV ON RESOURCE resource_name TO ROLE role_name; +REVOKE USAGE_PRIV ON RESOURCE resource_name FROM user_identityREVOKE USAGE_PRIV ON RESOURCE resource_name FROM ROLE role_name; +~~~ + +- リソースの作成 + +**例**: + +~~~sql +-- yarn cluster mode +CREATE EXTERNAL RESOURCE "spark0" +PROPERTIES +( + "type" = "spark", + "spark.master" = "yarn", + "spark.submit.deployMode" = "cluster", + "spark.jars" = "xxx.jar,yyy.jar", + "spark.files" = "/tmp/aaa,/tmp/bbb", + "spark.executor.memory" = "1g", + "spark.yarn.queue" = "queue0", + "spark.hadoop.yarn.resourcemanager.address" = "127.0.0.1:9999", + "spark.hadoop.fs.defaultFS" = "hdfs://127.0.0.1:10000", + "working_dir" = "hdfs://127.0.0.1:10000/tmp/starrocks", + "broker" = "broker0", + "broker.username" = "user0", + "broker.password" = "password0" +); + +-- yarn HA cluster mode +CREATE EXTERNAL RESOURCE "spark1" +PROPERTIES +( + "type" = "spark", + "spark.master" = "yarn", + "spark.submit.deployMode" = "cluster", + "spark.hadoop.yarn.resourcemanager.ha.enabled" = "true", + "spark.hadoop.yarn.resourcemanager.ha.rm-ids" = "rm1,rm2", + "spark.hadoop.yarn.resourcemanager.hostname.rm1" = "host1", + "spark.hadoop.yarn.resourcemanager.hostname.rm2" = "host2", + "spark.hadoop.fs.defaultFS" = "hdfs://127.0.0.1:10000", + "working_dir" = "hdfs://127.0.0.1:10000/tmp/starrocks", + "broker" = "broker1" +); +~~~ + +`resource-name` は、StarRocks で構成された Apache Spark™ リソースの名前です。 + +`PROPERTIES` には、Apache Spark™ リソースに関連する以下のパラメータが含まれます。 +> **注意** +> +> Apache Spark™ リソースの PROPERTIES の詳細については、[CREATE RESOURCE](../sql-reference/sql-statements/Resource/CREATE_RESOURCE.md) を参照してください。 + +- Spark 関連パラメータ: + - `type`: リソースタイプ、必須、現在は `spark` のみをサポートします。 + - `spark.master`: 必須、現在は `yarn` のみをサポートします。 + - `spark.submit.deployMode`: Apache Spark™ プログラムのデプロイモード、必須、現在は `cluster` と `client` の両方をサポートします。 + - `spark.hadoop.fs.defaultFS`: `master` が `yarn` の場合、必須です。 + - yarn リソースマネージャーに関連するパラメータ、必須。 + - 単一ノード上の 1 つの ResourceManager + `spark.hadoop.yarn.resourcemanager.address`: シングルポイントリソースマネージャーのアドレス。 + - ResourceManager HA + > ResourceManager のホスト名またはアドレスを指定できます。 + - `spark.hadoop.yarn.resourcemanager.ha.enabled`: リソースマネージャーの HA を有効にするには、`true` に設定します。 + - `spark.hadoop.yarn.resourcemanager.ha.rm-ids`: リソースマネージャーの論理 ID のリスト。 + - `spark.hadoop.yarn.resourcemanager.hostname.rm-id`: 各 rm-id について、リソースマネージャーに対応するホスト名を指定します。 + - `spark.hadoop.yarn.resourcemanager.address.rm-id`: 各 rm-id について、クライアントがジョブを送信するための `host:port` を指定します。 + +- `*working_dir`: ETL が使用するディレクトリ。Apache Spark™ が ETL リソースとして使用される場合、必須です。例: `hdfs://host:port/tmp/starrocks`。 + +- Broker 関連パラメータ: + - `broker`: Broker 名。Apache Spark™ が ETL リソースとして使用される場合、必須です。事前に `ALTER SYSTEM ADD BROKER` コマンドを使用して設定を完了する必要があります。 + - `broker.property_key`: Broker プロセスが ETL によって生成された中間ファイルを読み取る際に指定する情報 (例: 認証情報)。 + +**注意事項**: + +上記は Broker プロセスを介したロードのパラメータの説明です。Broker プロセスなしでデータをロードする場合、以下に注意してください。 + +- `broker` を指定する必要はありません。 +- ユーザー認証と NameNode ノードの HA を構成する必要がある場合、HDFS クラスターの hdfs-site.xml ファイルでパラメータを構成する必要があります。パラメータの説明については [broker_properties](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#hdfs) を参照してください。また、**hdfs-site.xml** ファイルを各 FE の **$FE_HOME/conf** および各 BE の **$BE_HOME/conf** の下に移動する必要があります。 + +> 注意 +> +> HDFS ファイルが特定のユーザーのみによってアクセスできる場合でも、`broker.name` に HDFS ユーザー名、`broker.password` にユーザーパスワードを指定する必要があります。 + +- リソースの表示 + +通常のユーザーアカウントは、`USAGE-PRIV` アクセス権を持つリソースのみを表示できます。root および admin アカウントはすべてのリソースを表示できます。 + +- リソース権限 + +リソース権限は `GRANT REVOKE` を介して管理され、現在は `USAGE-PRIV` 権限のみをサポートしています。`USAGE-PRIV` 権限をユーザーまたはロールに付与できます。 + +~~~sql +-- Grant access to spark0 resources to user0 +GRANT USAGE_PRIV ON RESOURCE "spark0" TO "user0"@"%"; + +-- Grant access to spark0 resources to role0 +GRANT USAGE_PRIV ON RESOURCE "spark0" TO ROLE "role0"; + +-- Grant access to all resources to user0 +GRANT USAGE_PRIV ON RESOURCE* TO "user0"@"%"; + +-- Grant access to all resources to role0 +GRANT USAGE_PRIV ON RESOURCE* TO ROLE "role0"; + +-- Revoke the use privileges of spark0 resources from user user0 +REVOKE USAGE_PRIV ON RESOURCE "spark0" FROM "user0"@"%"; +~~~ + +### Spark クライアントの構成 + +FE の Spark クライアントを構成し、FE が `spark-submit` コマンドを実行して Spark タスクを送信できるようにします。Spark2 2.4.5 以降の公式バージョンを使用することをお勧めします [spark ダウンロードアドレス](https://archive.apache.org/dist/spark/)。ダウンロード後、以下の手順で構成を完了してください。 + +- `SPARK-HOME` の構成 + +Spark クライアントを FE と同じマシンのディレクトリに配置し、FE 構成ファイルで `spark_home_default_dir` をこのディレクトリに構成します。これはデフォルトで FE ルートディレクトリ内の `lib/spark2x` パスであり、空にすることはできません。 + +- **Spark 依存パッケージの構成** + +依存パッケージを構成するには、Spark クライアント下の jars フォルダーにあるすべての jar ファイルを zip 圧縮してアーカイブし、FE 構成の `spark_resource_path` 項目をこの zip ファイルに構成します。この構成が空の場合、FE は FE ルートディレクトリ内の `lib/spark2x/jars/spark-2x.zip` ファイルを検索しようとします。FE がそれを見つけられない場合、エラーを報告します。 + +Spark Load ジョブが送信されると、アーカイブされた依存ファイルはリモートリポジトリにアップロードされます。デフォルトのリポジトリパスは、`working_dir/{cluster_id}` ディレクトリの下に `--spark-repository--{resource-name}` という名前で作成されます。これは、クラスター内のリソースがリモートリポジトリに対応することを意味します。ディレクトリ構造は次のとおりです。 + +~~~bash +---spark-repository--spark0/ + + |---archive-1.0.0/ + + | |\---lib-990325d2c0d1d5e45bf675e54e44fb16-spark-dpp-1.0.0\-jar-with-dependencies.jar + + | |\---lib-7670c29daf535efe3c9b923f778f61fc-spark-2x.zip + + |---archive-1.1.0/ + + | |\---lib-64d5696f99c379af2bee28c1c84271d5-spark-dpp-1.1.0\-jar-with-dependencies.jar + + | |\---lib-1bbb74bb6b264a270bc7fca3e964160f-spark-2x.zip + + |---archive-1.2.0/ + + | |-... + +~~~ + +Spark 依存関係 (デフォルトで `spark-2x.zip` という名前) に加えて、FE は DPP 依存関係もリモートリポジトリにアップロードします。Spark Load によって送信されたすべての依存関係がリモートリポジトリにすでに存在する場合、依存関係を再度アップロードする必要はありません。これにより、毎回大量のファイルを繰り返しアップロードする時間を節約できます。 + +### YARN クライアントの構成 + +FE の yarn クライアントを構成し、FE が yarn コマンドを実行して、実行中のアプリケーションのステータスを取得したり、それを強制終了したりできるようにします。Hadoop2 2.5.2 以降の公式バージョンを使用することをお勧めします ([hadoop ダウンロードアドレス](https://archive.apache.org/dist/hadoop/common/))。ダウンロード後、以下の手順で構成を完了してください。 + +- **YARN 実行可能パスの構成** + +ダウンロードした yarn クライアントを FE と同じマシンのディレクトリに配置し、FE 構成ファイルの `yarn_client_path` 項目を yarn のバイナリ実行可能ファイルに構成します。これはデフォルトで FE ルートディレクトリ内の `lib/yarn-client/hadoop/bin/yarn` パスです。 + +- **YARN を生成するために必要な構成ファイルのパスの構成 (オプション)** + +FE が yarn クライアントを介してアプリケーションのステータスを取得したり、アプリケーションを強制終了したりする場合、デフォルトでは StarRocks は FE ルートディレクトリの `lib/yarn-config` パスに yarn コマンドの実行に必要な構成ファイルを生成します。このパスは、FE 構成ファイル内の `yarn_config_dir` エントリを構成することで変更できます。現在、これには `core-site.xml` と `yarn-site.xml` が含まれます。 + +### インポートジョブの作成 + +**構文:** + +~~~sql +LOAD LABEL load_label + (data_desc, ...) +WITH RESOURCE resource_name +[resource_properties] +[PROPERTIES (key1=value1, ... )] + +* load_label: + db_name.label_name + +* data_desc: + DATA INFILE ('file_path', ...) + [NEGATIVE] + INTO TABLE tbl_name + [PARTITION (p1, p2)] + [COLUMNS TERMINATED BY separator ] + [(col1, ...)] + [COLUMNS FROM PATH AS (col2, ...)] + [SET (k1=f1(xx), k2=f2(xx))] + [WHERE predicate] + + DATA FROM TABLE hive_external_tbl + [NEGATIVE] + INTO TABLE tbl_name + [PARTITION (p1, p2)] + [SET (k1=f1(xx), k2=f2(xx))] + [WHERE predicate] + +* resource_properties: + (key2=value2, ...) +~~~ + +**例 1**: アップストリームのデータソースが HDFS の場合 + +~~~sql +LOAD LABEL db1.label1 +( + DATA INFILE("hdfs://abc.com:8888/user/starrocks/test/ml/file1") + INTO TABLE tbl1 + COLUMNS TERMINATED BY "," + (tmp_c1,tmp_c2) + SET + ( + id=tmp_c2, + name=tmp_c1 + ), + DATA INFILE("hdfs://abc.com:8888/user/starrocks/test/ml/file2") + INTO TABLE tbl2 + COLUMNS TERMINATED BY "," + (col1, col2) + where col1 > 1 +) +WITH RESOURCE 'spark0' +( + "spark.executor.memory" = "2g", + "spark.shuffle.compress" = "true" +) +PROPERTIES +( + "timeout" = "3600" +); +~~~ + +**例 2**: アップストリームのデータソースが Hive の場合。 + +- ステップ 1: 新しい Hive リソースを作成します + +~~~sql +CREATE EXTERNAL RESOURCE hive0 +PROPERTIES +( + "type" = "hive", + "hive.metastore.uris" = "thrift://xx.xx.xx.xx:8080" +); +~~~ + +- ステップ 2: 新しい Hive 外部テーブルを作成します + +~~~sql +CREATE EXTERNAL TABLE hive_t1 +( + k1 INT, + K2 SMALLINT, + k3 varchar(50), + uuid varchar(100) +) +ENGINE=hive +PROPERTIES +( + "resource" = "hive0", + "database" = "tmp", + "table" = "t1" +); +~~~ + +- ステップ 3: ロードコマンドを送信します。インポートされる StarRocks テーブルの列が Hive 外部テーブルに存在する必要があります。 + +~~~sql +LOAD LABEL db1.label1 +( + DATA FROM TABLE hive_t1 + INTO TABLE tbl1 + SET + ( + uuid=bitmap_dict(uuid) + ) +) +WITH RESOURCE 'spark0' +( + "spark.executor.memory" = "2g", + "spark.shuffle.compress" = "true" +) +PROPERTIES +( + "timeout" = "3600" +); +~~~ + +Spark Load のパラメータの紹介: + +- **Label** + +インポートジョブの Label です。各インポートジョブには、Broker Load と同じルールに従って、データベース内で一意の Label があります。 + +- **データ記述クラスのパラメータ** + +現在、サポートされているデータソースは CSV および Hive テーブルです。その他のルールは Broker Load と同じです。 + +- **インポートジョブのパラメータ** + +インポートジョブのパラメータは、インポートステートメントの `opt_properties` セクションに属するパラメータを指します。これらのパラメータはインポートジョブ全体に適用されます。ルールは Broker Load と同じです。 + +- **Spark リソースのパラメータ** + +Spark リソースは事前に StarRocks に構成し、ユーザーは Spark Load にリソースを適用する前に USAGE-PRIV 権限を与えられる必要があります。Spark リソースのパラメータは、ユーザーが一時的な必要性がある場合 (例えば、ジョブにリソースを追加したり、Spark 構成を変更したりする場合) に設定できます。この設定はこのジョブにのみ有効であり、StarRocks クラスター内の既存の構成には影響しません。 + +~~~sql +WITH RESOURCE 'spark0' +( + "spark.driver.memory" = "1g", + "spark.executor.memory" = "3g" +) +~~~ + +- **データソースが Hive の場合のインポート** + +現在、インポート処理で Hive テーブルを使用するには、`Hive` タイプの外部テーブルを作成し、その後、インポートコマンドを送信する際にその名前を指定する必要があります。 + +- **グローバル辞書を構築するためのインポートプロセス** + +ロードコマンドでは、グローバル辞書を構築するために必要なフィールドを以下の形式で指定できます: `StarRocks フィールド名=bitmap_dict(Hive テーブルフィールド名)`。現在、**グローバル辞書はアップストリームのデータソースが Hive テーブルの場合にのみサポートされる**ことに注意してください。 + +- **バイナリ型データのロード** + +v2.5.17 以降、Spark Load はバイナリデータをビットマップデータに変換できる bitmap_from_binary 関数をサポートしています。Hive テーブルまたは HDFS ファイルの列タイプがバイナリであり、StarRocks テーブル内の対応する列がビットマップ型の集計列である場合、ロードコマンドでフィールドを以下の形式で指定できます: `StarRocks フィールド名=bitmap_from_binary(Hive テーブルフィールド名)`。これにより、グローバル辞書を構築する必要がなくなります。 + +## インポートジョブの表示 + +Spark Load のインポートは Broker Load と同様に非同期です。ユーザーはインポートジョブの Label を記録し、`SHOW LOAD` コマンドで使用してインポート結果を確認する必要があります。インポートを表示するコマンドはすべてのインポート方法に共通です。例は以下の通りです。 + +返されるパラメータの詳細については、Broker Load を参照してください。違いは以下の通りです。 + +~~~sql +mysql> show load order by createtime desc limit 1\G +*************************** 1. row *************************** + JobId: 76391 + Label: label1 + State: FINISHED + Progress: ETL:100%; LOAD:100% + Type: SPARK + EtlInfo: unselected.rows=4; dpp.abnorm.ALL=15; dpp.norm.ALL=28133376 + TaskInfo: cluster:cluster0; timeout(s):10800; max_filter_ratio:5.0E-5 + ErrorMsg: N/A + CreateTime: 2019-07-27 11:46:42 + EtlStartTime: 2019-07-27 11:46:44 + EtlFinishTime: 2019-07-27 11:49:44 + LoadStartTime: 2019-07-27 11:49:44 +LoadFinishTime: 2019-07-27 11:50:16 + URL: http://1.1.1.1:8089/proxy/application_1586619723848_0035/ + JobDetails: {"ScannedRows":28133395,"TaskNumber":1,"FileNumber":1,"FileSize":200000} +~~~ + +- **State** + +インポートされたジョブの現在の段階です。 +PENDING: ジョブがコミットされました。 +ETL: Spark ETL がコミットされました。 +LOADING: FE は BE にプッシュ操作を実行するようスケジュールします。 +FINISHED: プッシュが完了し、バージョンが有効になりました。 + +インポートジョブには `CANCELLED` と `FINISHED` の 2 つの最終段階があり、どちらもロードジョブが完了したことを示します。`CANCELLED` はインポートの失敗を示し、`FINISHED` はインポートの成功を示します。 + +- **Progress** + +インポートジョブの進行状況の説明です。進行状況には ETL と LOAD の 2 種類があり、これらはインポート処理の 2 つのフェーズである ETL と LOADING に対応します。 + +- LOAD の進行状況の範囲は 0～100% です。 + +`LOAD progress = すべてのレプリケーションインポートの現在完了した tablet の数 / このインポートジョブの tablet の総数 * 100%`。 + +- すべてのテーブルがインポートされている場合、LOAD の進行状況は 99% であり、インポートが最終検証フェーズに入ると 100% に変わります。 + +- インポートの進行状況は線形ではありません。一定期間進行状況に変化がない場合でも、インポートが実行されていないことを意味するものではありません。 + +- **Type** + +インポートジョブのタイプ。Spark Load の場合は SPARK。 + +- **CreateTime/EtlStartTime/EtlFinishTime/LoadStartTime/LoadFinishTime** + +これらの値は、インポートが作成された時刻、ETL フェーズが開始された時刻、ETL フェーズが完了した時刻、LOADING フェーズが開始された時刻、およびインポートジョブ全体が完了した時刻を表します。 + +- **JobDetails** + +ジョブの詳細な実行ステータスを表示します。これには、インポートされたファイルの数、合計サイズ (バイト単位)、サブタスクの数、処理中の元の行の数などが含まれます。例: + +~~~json + {"ScannedRows":139264,"TaskNumber":1,"FileNumber":1,"FileSize":940754064} +~~~ + +- **URL** + +入力をブラウザにコピーして、対応するアプリケーションのウェブインターフェースにアクセスできます。 + +### Apache Spark™ Launcher コミットログの表示 + +ユーザーは Apache Spark™ ジョブコミット中に生成された詳細なログを表示する必要がある場合があります。デフォルトでは、ログは FE ルートディレクトリの `log/spark_launcher_log` パスに `spark-launcher-{load-job-id}-{label}.log` という名前で保存されます。ログはこのディレクトリに一定期間保存され、FE メタデータのインポート情報がクリーンアップされると消去されます。デフォルトの保持期間は 3 日間です。 + +### インポートのキャンセル + +Spark Load ジョブのステータスが `CANCELLED` または `FINISHED` でない場合、ユーザーはインポートジョブの Label を指定することで手動でキャンセルできます。 + +--- + +## 関連するシステム構成 + +**FE 構成:** 以下の構成は Spark Load のシステムレベルの構成であり、すべての Spark Load インポートジョブに適用されます。構成値は主に `fe.conf` を変更することで調整できます。 + +- `enable-spark-load`: Spark Load とリソースの作成を有効にします。デフォルト値は false です。 +- `spark-load-default-timeout-second`: ジョブのデフォルトのタイムアウトは 259200 秒 (3 日間) です。 +- `spark-home-default-dir`: Spark クライアントパス (`fe/lib/spark2x`)。 +- `spark-resource-path`: パッケージ化された Spark 依存関係ファイルへのパス (デフォルトでは空)。 +- `spark-launcher-log-dir`: Spark クライアントのコミットログが保存されるディレクトリ (`fe/log/spark-launcher-log`)。 +- `yarn-client-path`: yarn のバイナリ実行可能ファイルへのパス (`fe/lib/yarn-client/hadoop/bin/yarn`)。 +- `yarn-config-dir`: Yarn の構成ファイルパス (`fe/lib/yarn-config`)。 + +--- + +## ベストプラクティス + +Spark Load を使用するのに最も適したシナリオは、生データがファイルシステム (HDFS) にあり、データ量が数十 GB から TB レベルの場合です。データ量が少ない場合は Stream Load または Broker Load を使用してください。 + +Spark Load のインポートの完全な例については、GitHub のデモを参照してください: [https://github.com/StarRocks/demo/blob/master/docs/03_sparkLoad2StarRocks.md](https://github.com/StarRocks/demo/blob/master/docs/03_sparkLoad2StarRocks.md) + +## FAQ + +- `Error: When running with master 'yarn' either HADOOP-CONF-DIR or YARN-CONF-DIR must be set in the environment.` + +Spark クライアントの `spark-env.sh` で `HADOOP-CONF-DIR` 環境変数を構成せずに Spark Load を使用しています。 + +- `Error: Cannot run program "xxx/bin/spark-submit": error=2, No such file or directory` + +Spark Load を使用している際に、`spark_home_default_dir` 構成項目が Spark クライアントのルートディレクトリを指定していません。 + +- `Error: File xxx/jars/spark-2x.zip does not exist.` + +Spark Load を使用している際に、`spark-resource-path` 構成項目がパックされた zip ファイルを指していません。 + +- `Error: yarn client does not exist in path: xxx/yarn-client/hadoop/bin/yarn` + +Spark Load を使用している際に、`yarn-client-path` 構成項目が yarn 実行可能ファイルを指定していません。 + +- `ERROR: Cannot execute hadoop-yarn/bin/... /libexec/yarn-config.sh` + +CDH で Hadoop を使用する場合、`HADOOP_LIBEXEC_DIR` 環境変数を構成する必要があります。`hadoop-yarn` と `hadoop` ディレクトリが異なるため、デフォルトの `libexec` ディレクトリは `hadoop-yarn/bin/... /libexec` を検索しますが、`libexec` は `hadoop` ディレクトリにあります。`yarn application status` コマンドで Spark タスクのステータスを取得する際にエラーが報告され、インポートジョブが失敗しました。 diff --git a/docs/zh/loading/SparkLoad.md b/docs/zh/loading/SparkLoad.md index ca661d1c..8916398b 100644 --- a/docs/zh/loading/SparkLoad.md +++ b/docs/zh/loading/SparkLoad.md @@ -1,79 +1,76 @@ ---- displayed_sidebar: docs ---- - -# 使用 Spark Load 批量导入数据 +# 使用 Spark Load 大批量导入数据 -Spark Load 使用外部 Apache Spark™ 资源来预处理导入的数据，从而提高导入性能并节省计算资源。它主要用于 **初始迁移** 和将 **大量数据导入** 到 StarRocks 中（数据量高达 TB 级别）。 +Spark Load 使用外部 Apache Spark™ 资源对导入数据进行预处理，这提高了导入性能并节省了计算资源。它主要用于 StarRocks 的**初始数据迁移**和**大数据量导入**（数据量可达 TB 级别）。 -Spark Load 是一种**异步**导入方法，用户需要通过 MySQL 协议创建 Spark 类型的导入作业，并使用 `SHOW LOAD` 查看导入结果。 +Spark Load 是一个**异步**导入方法，用户需要通过 MySQL 协议创建 Spark 类型导入作业，并使用 `SHOW LOAD` 查看导入结果。 -> **注意** +> **NOTICE** > -> - 只有对 StarRocks 表具有 INSERT 权限的用户才能将数据导入到该表中。您可以按照 [GRANT](../sql-reference/sql-statements/account-management/GRANT.md) 中提供的说明授予所需的权限。 -> - Spark Load 不能用于将数据导入到主键表。 +> - 只有对 StarRocks 表拥有 INSERT 权限的用户才能向该表导入数据。您可以按照 [GRANT](../sql-reference/sql-statements/account-management/GRANT.md) 中提供的说明授予所需权限。 +> - Spark Load 不能用于向主键表导入数据。 ## 术语解释 -- **Spark ETL**：主要负责导入过程中的数据 ETL，包括全局字典构建（BITMAP 类型）、分区、排序、聚合等。 -- **Broker**：Broker 是一个独立的无状态进程。它封装了文件系统接口，并为 StarRocks 提供了从远端存储系统读取文件的能力。 -- **Global Dictionary**：保存将数据从原始值映射到编码值的数据结构。原始值可以是任何数据类型，而编码值是整数。全局字典主要用于预计算精确去重的场景。 +- **Spark ETL**: 主要负责导入过程中的数据 ETL，包括全局字典构建 (BITMAP 类型)、分区、排序、聚合等。 +- **Broker**: Broker 是一个独立的无状态进程。它封装了文件系统接口，并为 StarRocks 提供从远端存储系统读取文件的能力。 +- **全局字典**: 保存将原始值映射到编码值的数据结构。原始值可以是任意数据类型，而编码值是整数。全局字典主要用于预计算精准去重值的场景。 -## 原理 +## 基本原理 -用户通过 MySQL 客户端提交 Spark 类型的导入作业；FE 记录元数据并返回提交结果。 +用户通过 MySQL 客户端提交 Spark 类型导入作业；FE 记录元数据并返回提交结果。 -spark load 任务的执行分为以下几个主要阶段。 +Spark Load 任务的执行分为以下主要阶段。 -1. 用户将 spark load 作业提交给 FE。 -2. FE 调度提交 ETL 任务到 Apache Spark™ 集群执行。 -3. Apache Spark™ 集群执行 ETL 任务，包括全局字典构建（BITMAP 类型）、分区、排序、聚合等。 -4. ETL 任务完成后，FE 获取每个预处理切片的数据路径，并调度相关的 BE 执行 Push 任务。 +1. 用户向 FE 提交 Spark Load 作业。 +2. FE 调度将 ETL 任务提交到 Apache Spark™ 集群进行执行。 +3. Apache Spark™ 集群执行 ETL 任务，该任务包括全局字典构建 (BITMAP 类型)、分区、排序、聚合等。 +4. ETL 任务完成后，FE 获取每个预处理数据分片的数据路径，并调度相关 BE 执行 Push 任务。 5. BE 通过 Broker 进程从 HDFS 读取数据，并将其转换为 StarRocks 存储格式。 - > 如果您选择不使用 Broker 进程，BE 将直接从 HDFS 读取数据。 -6. FE 调度生效版本并完成导入作业。 + > 如果选择不使用 Broker 进程，BE 直接从 HDFS 读取数据。 +6. FE 调度使版本生效，并完成导入作业。 -下图说明了 spark load 的主要流程。 +下图展示了 Spark Load 的主要流程。 ![Spark load](../_assets/4.3.2-1.png) --- -## Global Dictionary +## 全局字典 ### 适用场景 -目前，StarRocks 中的 BITMAP 列是使用 Roaringbitmap 实现的，它只接受整数作为输入数据类型。因此，如果您想在导入过程中为 BITMAP 列实现预计算，则需要将输入数据类型转换为整数。 +目前，StarRocks 中的 BITMAP 列使用 Roaringbitmap 实现，它只接受整数作为输入数据类型。因此，如果要在导入过程中对 BITMAP 列实现预计算，则需要将输入数据类型转换为整数。 -在 StarRocks 现有的导入过程中，全局字典的数据结构是基于 Hive 表实现的，它保存了从原始值到编码值的映射。 +在 StarRocks 现有的导入流程中，全局字典的数据结构是基于 Hive 表实现的，它保存了从原始值到编码值的映射。 -### 构建过程 +### 构建流程 1. 从上游数据源读取数据，并生成一个临时 Hive 表，命名为 `hive-table`。 -2. 提取 `hive-table` 的非强调字段的值，以生成一个新的 Hive 表，命名为 `distinct-value-table`。 -3. 创建一个新的全局字典表，命名为 `dict-table`，其中一列用于原始值，一列用于编码值。 -4. 在 `distinct-value-table` 和 `dict-table` 之间进行左连接，然后使用窗口函数对该集合进行编码。最后，将去重列的原始值和编码值都写回 `dict-table`。 -5. 在 `dict-table` 和 `hive-table` 之间进行连接，以完成将 `hive-table` 中的原始值替换为整数编码值的工作。 -6. `hive-table` 将被下次数据预处理读取，然后在计算后导入到 StarRocks 中。 +2. 提取 `hive-table` 中去重字段的值，生成一个新的 Hive 表，命名为 `distinct-value-table`。 +3. 创建一个新的全局字典表，命名为 `dict-table`，该表包含一个用于原始值的列和一个用于编码值的列。 +4. 对 `distinct-value-table` 和 `dict-table` 进行左连接，然后使用窗口函数对该集合进行编码。最后，去重列的原始值和编码值都被写回 `dict-table`。 +5. 对 `dict-table` 和 `hive-table` 进行连接，完成将 `hive-table` 中的原始值替换为整数编码值的工作。 +6. `hive-table` 将在下一次数据预处理时被读取，并在计算后导入 StarRocks。 ## 数据预处理 -数据预处理的基本过程如下： +数据预处理的基本流程如下： -1. 从上游数据源（HDFS 文件或 Hive 表）读取数据。 -2. 完成读取数据的字段映射和计算，然后基于分区信息生成 `bucket-id`。 -3. 基于 StarRocks 表的 Rollup 元数据生成 RollupTree。 -4. 迭代 RollupTree 并执行分层聚合操作。下一层级的 Rollup 可以从上一层级的 Rollup 计算得出。 -5. 每次完成聚合计算后，数据将根据 `bucket-id` 进行分桶，然后写入 HDFS。 -6. 后续的 Broker 进程将从 HDFS 拉取文件并将其导入到 StarRocks BE 节点。 +1. 从上游数据源读取数据 (HDFS 文件或 Hive 表)。 +2. 对读取到的数据进行字段映射和计算，然后根据分区信息生成 `bucket-id`。 +3. 根据 StarRocks 表的 Rollup 元数据生成 RollupTree。 +4. 遍历 RollupTree，并执行分层聚合操作。下一层次的 Rollup 可以从上一层次的 Rollup 计算得出。 +5. 每次聚合计算完成后，数据根据 `bucket-id` 进行分桶，然后写入 HDFS。 +6. 随后的 Broker 进程将从 HDFS 拉取文件，并将它们导入到 StarRocks BE 节点。 ## 基本操作 ### 配置 ETL 集群 -Apache Spark™ 在 StarRocks 中用作外部计算资源，用于 ETL 工作。可能还有其他外部资源添加到 StarRocks 中，例如用于查询的 Spark/GPU、用于外部存储的 HDFS/S3、用于 ETL 的 MapReduce 等。因此，我们引入了 `Resource Management` 来管理 StarRocks 使用的这些外部资源。 +Apache Spark™ 在 StarRocks 中被用作 ETL 工作的外部计算资源。StarRocks 中可能还会添加其他外部资源，例如用于查询的 Spark/GPU、用于外部存储的 HDFS/S3、用于 ETL 的 MapReduce 等。因此，我们引入了 `Resource Management` 来管理 StarRocks 使用的这些外部资源。 -在提交 Apache Spark™ 导入作业之前，请配置 Apache Spark™ 集群以执行 ETL 任务。操作语法如下： +在提交 Apache Spark™ 导入作业之前，请配置用于执行 ETL 任务的 Apache Spark™ 集群。操作语法如下： ~~~sql -- 创建 Apache Spark™ 资源 @@ -95,8 +92,10 @@ SHOW RESOURCES SHOW PROC "/resources"; -- 权限 -GRANT USAGE_PRIV ON RESOURCE resource_name TO user_identityGRANT USAGE_PRIV ON RESOURCE resource_name TO ROLE role_name; -REVOKE USAGE_PRIV ON RESOURCE resource_name FROM user_identityREVOKE USAGE_PRIV ON RESOURCE resource_name FROM ROLE role_name; +GRANT USAGE_PRIV ON RESOURCE resource_name TO user_identity; +GRANT USAGE_PRIV ON RESOURCE resource_name TO ROLE role_name; +REVOKE USAGE_PRIV ON RESOURCE resource_name FROM user_identity; +REVOKE USAGE_PRIV ON RESOURCE resource_name FROM ROLE role_name; ~~~ - 创建资源 @@ -104,7 +103,7 @@ REVOKE USAGE_PRIV ON RESOURCE resource_name FROM user_identityREVOKE USAGE_PRIV **例如**： ~~~sql --- yarn 集群模式 +-- Yarn 集群模式 CREATE EXTERNAL RESOURCE "spark0" PROPERTIES ( @@ -123,7 +122,7 @@ PROPERTIES "broker.password" = "password0" ); --- yarn HA 集群模式 +-- Yarn HA 集群模式 CREATE EXTERNAL RESOURCE "spark1" PROPERTIES ( @@ -142,46 +141,46 @@ PROPERTIES `resource-name` 是在 StarRocks 中配置的 Apache Spark™ 资源的名称。 -`PROPERTIES` 包括与 Apache Spark™ 资源相关的参数，如下所示： -> **注意** +`PROPERTIES` 包含与 Apache Spark™ 资源相关的参数，如下： +> **Note** > -> 有关 Apache Spark™ 资源 PROPERTIES 的详细说明，请参见 [CREATE RESOURCE](../sql-reference/sql-statements/Resource/CREATE_RESOURCE.md)。 +> 有关 Apache Spark™ 资源 PROPERTIES 的详细说明，请参阅 [CREATE RESOURCE](../sql-reference/sql-statements/Resource/CREATE_RESOURCE.md)。 - Spark 相关参数： - - `type`：资源类型，必需，目前仅支持 `spark`。 - - `spark.master`：必需，目前仅支持 `yarn`。 - - `spark.submit.deployMode`：Apache Spark™ 程序的部署模式，必需，目前支持 `cluster` 和 `client`。 - - `spark.hadoop.fs.defaultFS`：如果 master 是 yarn，则为必需。 - - 与 yarn 资源管理器相关的参数，必需。 - - 单个节点上的一个 ResourceManager - `spark.hadoop.yarn.resourcemanager.address`：单点资源管理器的地址。 - - ResourceManager HA + - `type`: 资源类型，必填，目前仅支持 `spark`。 + - `spark.master`: 必填，目前仅支持 `yarn`。 + - `spark.submit.deployMode`: Apache Spark™ 程序的部署模式，必填，目前支持 `cluster` 和 `client`。 + - `spark.hadoop.fs.defaultFS`: 如果 master 为 yarn，则必填。 + - 与 yarn 资源管理器相关的参数，必填。 + - 单节点上的单个 ResourceManager + `spark.hadoop.yarn.resourcemanager.address`: 单点资源管理器的地址。 + - ResourceManager 高可用 (HA) > 您可以选择指定 ResourceManager 的主机名或地址。 - - `spark.hadoop.yarn.resourcemanager.ha.enabled`：启用资源管理器 HA，设置为 `true`。 - - `spark.hadoop.yarn.resourcemanager.ha.rm-ids`：资源管理器逻辑 ID 列表。 - - `spark.hadoop.yarn.resourcemanager.hostname.rm-id`：对于每个 rm-id，指定与资源管理器对应的主机名。 - - `spark.hadoop.yarn.resourcemanager.address.rm-id`：对于每个 rm-id，指定客户端提交作业的 `host:port`。 + - `spark.hadoop.yarn.resourcemanager.ha.enabled`: 启用资源管理器 HA，设置为 `true`。 + - `spark.hadoop.yarn.resourcemanager.ha.rm-ids`: 资源管理器逻辑 ID 列表。 + - `spark.hadoop.yarn.resourcemanager.hostname.rm-id`: 对于每个 rm-id，指定与资源管理器对应的主机名。 + - `spark.hadoop.yarn.resourcemanager.address.rm-id`: 对于每个 rm-id，指定客户端提交作业的 `host:port`。 -- `*working_dir`：ETL 使用的目录。如果 Apache Spark™ 用作 ETL 资源，则为必需。例如：`hdfs://host:port/tmp/starrocks`。 +- `*working_dir`: ETL 使用的工作目录。如果 Apache Spark™ 用作 ETL 资源，则必填。例如：`hdfs://host:port/tmp/starrocks`。 - Broker 相关参数： - - `broker`：Broker 名称。如果 Apache Spark™ 用作 ETL 资源，则为必需。您需要提前使用 `ALTER SYSTEM ADD BROKER` 命令完成配置。 - - `broker.property_key`：Broker 进程读取 ETL 生成的中间文件时要指定的信息（例如，身份验证信息）。 + - `broker`: Broker 名称。如果 Apache Spark™ 用作 ETL 资源，则必填。您需要提前使用 `ALTER SYSTEM ADD BROKER` 命令完成配置。 + - `broker.property_key`: Broker 进程读取 ETL 生成的中间文件时需要指定的信息（例如，认证信息）。 -**注意**： +**注意事项**： -以上是通过 Broker 进程加载的参数说明。如果您打算在没有 Broker 进程的情况下加载数据，则应注意以下事项。 +以上是关于通过 Broker 进程导入数据的参数说明。如果您打算不通过 Broker 进程导入数据，则应注意以下事项。 -- 您无需指定 `broker`。 -- 如果您需要配置用户身份验证和 NameNode 节点的 HA，则需要在 HDFS 集群中的 hdfs-site.xml 文件中配置参数，有关参数的说明，请参见 [broker_properties](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#hdfs)。并且您需要将 **hdfs-site.xml** 文件移动到每个 FE 的 **$FE_HOME/conf** 下和每个 BE 的 **$BE_HOME/conf** 下。 +- 您不需要指定 `broker`。 +- 如果您需要配置用户认证和 NameNode 节点的高可用 (HA)，您需要在 HDFS 集群的 hdfs-site.xml 文件中配置参数，有关参数的说明，请参阅 [broker_properties](../sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md#hdfs)。并且您需要将 **hdfs-site.xml** 文件移动到每个 FE 的 **$FE_HOME/conf** 和每个 BE 的 **$BE_HOME/conf** 目录下。 -> 注意 +> Note > > 如果 HDFS 文件只能由特定用户访问，您仍然需要在 `broker.name` 中指定 HDFS 用户名，并在 `broker.password` 中指定用户密码。 - 查看资源 -常规帐户只能查看他们具有 `USAGE-PRIV` 访问权限的资源。root 和 admin 帐户可以查看所有资源。 +普通账户只能查看其具有 `USAGE-PRIV` 访问权限的资源。root 和 admin 账户可以查看所有资源。 - 资源权限 @@ -200,23 +199,23 @@ GRANT USAGE_PRIV ON RESOURCE* TO "user0"@"%"; -- 授予 role0 访问所有资源的权限 GRANT USAGE_PRIV ON RESOURCE* TO ROLE "role0"; --- 撤销 user0 对 spark0 资源的使用权限 +-- 撤销用户 user0 访问 spark0 资源的权限 REVOKE USAGE_PRIV ON RESOURCE "spark0" FROM "user0"@"%"; ~~~ -### 配置 Spark Client +### 配置 Spark 客户端 -为 FE 配置 Spark 客户端，以便后者可以通过执行 `spark-submit` 命令来提交 Spark 任务。建议使用官方版本的 Spark2 2.4.5 或更高版本 [spark download address](https://archive.apache.org/dist/spark/)。下载后，请按照以下步骤完成配置。 +为 FE 配置 Spark 客户端，以便 FE 可以通过执行 `spark-submit` 命令提交 Spark 任务。建议使用 Spark2 2.4.5 或更高版本的官方版本 [Spark 下载地址](https://archive.apache.org/dist/spark/)。下载后，请按照以下步骤完成配置。 - 配置 `SPARK-HOME` -将 Spark 客户端放置在与 FE 相同的机器上的目录中，并在 FE 配置文件中将 `spark_home_default_dir` 配置为此目录，默认情况下，该目录是 FE 根目录中的 `lib/spark2x` 路径，并且不能为空。 +将 Spark 客户端放置在与 FE 相同的机器上的一个目录中，并在 FE 配置文件中将 `spark_home_default_dir` 配置为该目录，该目录默认是 FE 根目录下的 `lib/spark2x` 路径，且不能为空。 -- **配置 SPARK 依赖包** +- **配置 Spark 依赖包** -要配置依赖包，请压缩并归档 Spark 客户端下 jars 文件夹中的所有 jar 文件，并将 FE 配置中的 `spark_resource_path` 项配置为此 zip 文件。如果此配置为空，FE 将尝试在 FE 根目录中查找 `lib/spark2x/jars/spark-2x.zip` 文件。如果 FE 无法找到它，它将报告错误。 +要配置依赖包，请将 Spark 客户端 `jars` 文件夹下的所有 jar 文件打包成 zip，并在 FE 配置中将 `spark_resource_path` 项配置为该 zip 文件。如果此配置为空，FE 将尝试在 FE 根目录下查找 `lib/spark2x/jars/spark-2x.zip` 文件。如果 FE 找不到该文件，则会报错。 -提交 spark load 作业时，归档的依赖文件将上传到远程存储库。默认存储库路径位于 `working_dir/{cluster_id}` 目录下，并以 `--spark-repository--{resource-name}` 命名，这意味着集群中的一个资源对应于一个远程存储库。目录结构引用如下： +提交 Spark Load 作业时，打包的依赖文件将被上传到远端仓库。默认仓库路径在 `working_dir/{cluster_id}` 目录下，以 `--spark-repository--{resource-name}` 命名，这意味着集群中的一个资源对应一个远端仓库。目录结构示例如下： ~~~bash ---spark-repository--spark0/ @@ -239,19 +238,19 @@ REVOKE USAGE_PRIV ON RESOURCE "spark0" FROM "user0"@"%"; ~~~ -除了 spark 依赖项（默认情况下命名为 `spark-2x.zip`）之外，FE 还会将 DPP 依赖项上传到远程存储库。如果 spark load 提交的所有依赖项已经存在于远程存储库中，则无需再次上传依赖项，从而节省了每次重复上传大量文件的时间。 +除了 Spark 依赖（默认命名为 `spark-2x.zip`）之外，FE 还会将 DPP 依赖上传到远端仓库。如果 Spark Load 提交的所有依赖都已存在于远端仓库中，则无需再次上传依赖，节省了每次重复上传大量文件的时间。 -### 配置 YARN Client +### 配置 YARN 客户端 -为 FE 配置 yarn 客户端，以便 FE 可以执行 yarn 命令来获取正在运行的应用程序的状态或终止它。建议使用官方版本的 Hadoop2 2.5.2 或更高版本 ([hadoop download address](https://archive.apache.org/dist/hadoop/common/))。下载后，请按照以下步骤完成配置： +为 FE 配置 Yarn 客户端，以便 FE 可以执行 Yarn 命令来获取运行中应用程序的状态或将其杀死。建议使用 Hadoop2 2.5.2 或更高版本的官方版本 ([Hadoop 下载地址](https://archive.apache.org/dist/hadoop/common/))。下载后，请按照以下步骤完成配置： -- **配置 YARN 可执行路径** +- **配置 Yarn 可执行文件路径** -将下载的 yarn 客户端放置在与 FE 相同的机器上的目录中，并在 FE 配置文件中将 `yarn_client_path` 项配置为 yarn 的二进制可执行文件，默认情况下，该文件是 FE 根目录中的 `lib/yarn-client/hadoop/bin/yarn` 路径。 +将下载的 Yarn 客户端放置在与 FE 相同的机器上的一个目录中，并在 FE 配置文件中将 `yarn_client_path` 项配置为 Yarn 的二进制可执行文件，该文件默认是 FE 根目录下的 `lib/yarn-client/hadoop/bin/yarn` 路径。 -- **配置生成 YARN 所需的配置文件的路径（可选）** +- **配置生成 YARN 所需配置文件的路径（可选）** -当 FE 通过 yarn 客户端获取应用程序的状态或终止应用程序时，默认情况下，StarRocks 会在 FE 根目录的 `lib/yarn-config` 路径中生成执行 yarn 命令所需的配置文件。可以通过配置 FE 配置文件中的 `yarn_config_dir` 条目来修改此路径，该条目当前包括 `core-site.xml` 和 `yarn-site.xml`。 +当 FE 通过 Yarn 客户端获取应用程序状态或杀死应用程序时，StarRocks 默认在 FE 根目录下的 `lib/yarn-config` 路径中生成执行 Yarn 命令所需的配置文件。该路径可以通过配置 FE 配置文件中的 `yarn_config_dir` 项进行修改，目前包括 `core-site.xml` 和 `yarn-site.xml`。 ### 创建导入作业 @@ -289,7 +288,7 @@ WITH RESOURCE resource_name (key2=value2, ...) ~~~ -**示例 1**：上游数据源为 HDFS 的情况 +**示例 1**: 上游数据源为 HDFS 的情况 ~~~sql LOAD LABEL db1.label1 @@ -320,9 +319,9 @@ PROPERTIES ); ~~~ -**示例 2**：上游数据源为 Hive 的情况。 +**示例 2**: 上游数据源为 Hive 的情况。 -- 步骤 1：创建一个新的 Hive 资源 +- 步骤 1：创建新的 Hive 资源 ~~~sql CREATE EXTERNAL RESOURCE hive0 @@ -333,7 +332,7 @@ PROPERTIES ); ~~~ -- 步骤 2：创建一个新的 Hive 外部表 +- 步骤 2：创建新的 Hive 外表 ~~~sql CREATE EXTERNAL TABLE hive_t1 @@ -352,7 +351,7 @@ PROPERTIES ); ~~~ -- 步骤 3：提交 load 命令，要求导入的 StarRocks 表中的列存在于 Hive 外部表中。 +- 步骤 3：提交导入命令，要求导入的 StarRocks 表中的列在 Hive 外部表中存在。 ~~~sql LOAD LABEL db1.label1 @@ -375,24 +374,24 @@ PROPERTIES ); ~~~ -Spark load 中参数的介绍： +Spark Load 中参数介绍： -- **Label** +- Label -导入作业的 Label。每个导入作业都有一个 Label，该 Label 在数据库中是唯一的，遵循与 broker load 相同的规则。 +导入作业的 Label。每个导入作业都有一个在数据库中唯一的 Label，遵循与 Broker Load 相同的规则。 -- **数据描述类参数** +- 数据描述类参数 -目前，支持的数据源是 CSV 和 Hive 表。其他规则与 broker load 相同。 +目前支持的数据源是 CSV 和 Hive 表。其他规则与 Broker Load 相同。 -- **导入作业参数** +- 导入作业参数 -导入作业参数是指属于导入语句的 `opt_properties` 部分的参数。这些参数适用于整个导入作业。规则与 broker load 相同。 +导入作业参数是指导入语句 `opt_properties` 部分的参数。这些参数适用于整个导入作业。规则与 Broker Load 相同。 -- **Spark 资源参数** +- Spark 资源参数 -Spark 资源需要提前配置到 StarRocks 中，并且用户需要被授予 USAGE-PRIV 权限，然后才能将资源应用于 Spark load。 -当用户有临时需求时，可以设置 Spark 资源参数，例如为作业添加资源和修改 Spark 配置。该设置仅对该作业生效，不影响 StarRocks 集群中的现有配置。 +Spark 资源需要提前在 StarRocks 中配置，并且用户需要被授予 USAGE-PRIV 权限，然后才能将资源应用于 Spark Load。 +当用户有临时需求时可以设置 Spark 资源参数，例如为作业添加资源和修改 Spark 配置。该设置仅对当前作业生效，不会影响 StarRocks 集群中已有的配置。 ~~~sql WITH RESOURCE 'spark0' @@ -402,23 +401,23 @@ WITH RESOURCE 'spark0' ) ~~~ -- **当数据源为 Hive 时导入** +- 数据源为 Hive 时导入 目前，要在导入过程中使用 Hive 表，您需要创建 `Hive` 类型的外部表，然后在提交导入命令时指定其名称。 -- **导入过程以构建全局字典** +- 导入过程构建全局字典 -在 load 命令中，您可以按以下格式指定构建全局字典所需的字段：`StarRocks 字段名称=bitmap_dict(hive 表字段名称)` 请注意，目前**仅当上游数据源是 Hive 表时才支持全局字典**。 +在导入命令中，您可以按以下格式指定构建全局字典所需的字段：`StarRocks 字段名=bitmap_dict(Hive 表字段名)`。请注意，目前**仅当上游数据源为 Hive 表时才支持全局字典**。 -- **加载二进制类型数据** +- 导入二进制类型数据 -从 v2.5.17 开始，Spark Load 支持 bitmap_from_binary 函数，该函数可以将二进制数据转换为 bitmap 数据。如果 Hive 表或 HDFS 文件的列类型为二进制，并且 StarRocks 表中对应的列是 bitmap 类型的聚合列，则可以在 load 命令中按以下格式指定字段，`StarRocks 字段名称=bitmap_from_binary(Hive 表字段名称)`。这样就不需要构建全局字典。 +从 v2.5.17 版本开始，Spark Load 支持 `bitmap_from_binary` 函数，该函数可以将二进制数据转换为 Bitmap 数据。如果 Hive 表或 HDFS 文件的列类型是二进制，并且 StarRocks 表中对应的列是 Bitmap 类型的聚合列，您可以在导入命令中按以下格式指定字段：`StarRocks 字段名=bitmap_from_binary(Hive 表字段名)`。这消除了构建全局字典的需要。 ## 查看导入作业 -Spark load 导入是异步的，broker load 也是如此。用户必须记录导入作业的 label，并在 `SHOW LOAD` 命令中使用它来查看导入结果。查看导入的命令对于所有导入方法都是通用的。示例如下。 +Spark Load 导入是异步的，与 Broker Load 相同。用户必须记录导入作业的 Label，并在 `SHOW LOAD` 命令中使用它来查看导入结果。查看导入的命令适用于所有导入方法。示例如下。 -有关返回参数的详细说明，请参阅 Broker Load。不同之处如下。 +有关返回参数的详细说明，请参阅 Broker Load。差异如下。 ~~~sql mysql> show load order by createtime desc limit 1\G @@ -440,98 +439,98 @@ LoadFinishTime: 2019-07-27 11:50:16 JobDetails: {"ScannedRows":28133395,"TaskNumber":1,"FileNumber":1,"FileSize":200000} ~~~ -- **State** +- 状态 导入作业的当前阶段。 -PENDING：已提交作业。 -ETL：已提交 Spark ETL。 -LOADING：FE 调度 BE 执行 push 操作。 -FINISHED：push 已完成，版本已生效。 +PENDING: 作业已提交。 +ETL: Spark ETL 已提交。 +LOADING: FE 调度 BE 执行 Push 操作。 +FINISHED: Push 完成且版本生效。 -导入作业有两个最终阶段 – `CANCELLED` 和 `FINISHED`，都表示 load 作业已完成。`CANCELLED` 表示导入失败，`FINISHED` 表示导入成功。 +导入作业有两个最终阶段 – `CANCELLED` 和 `FINISHED`，都表示导入作业已完成。`CANCELLED` 表示导入失败，`FINISHED` 表示导入成功。 -- **Progress** +- 进度 -导入作业进度的描述。有两种类型的进度 – ETL 和 LOAD，它们对应于导入过程的两个阶段，ETL 和 LOADING。 +导入作业进度的描述。进度有两种类型 – ETL 和 LOAD，它们对应于导入过程的两个阶段：ETL 和 LOADING。 - LOAD 的进度范围为 0~100%。 -`LOAD 进度 = 当前已完成的所有副本导入的 tablet 数量 / 此导入作业的 tablet 总数 * 100%`。 +`LOAD progress = 所有副本导入已完成 tablet 数量 / 本次导入作业 tablet 总数 * 100%`。 -- 如果所有表都已导入，则 LOAD 进度为 99%，当导入进入最终验证阶段时，将更改为 100%。 +- 如果所有表都已导入，LOAD 进度为 99%，并在导入进入最终验证阶段时变为 100%。 -- 导入进度不是线性的。如果在一段时间内进度没有变化，并不意味着导入没有执行。 +- 导入进度不是线性的。如果一段时间内进度没有变化，这并不意味着导入没有执行。 -- **Type** +- 类型 - 导入作业的类型。SPARK 表示 spark load。 + 导入作业的类型。SPARK 表示 Spark Load。 -- **CreateTime/EtlStartTime/EtlFinishTime/LoadStartTime/LoadFinishTime** +- CreateTime/EtlStartTime/EtlFinishTime/LoadStartTime/LoadFinishTime -这些值表示创建导入的时间、ETL 阶段开始的时间、ETL 阶段完成的时间、LOADING 阶段开始的时间以及整个导入作业完成的时间。 +这些值表示导入创建的时间、ETL 阶段开始的时间、ETL 阶段完成的时间、LOADING 阶段开始的时间以及整个导入作业完成的时间。 -- **JobDetails** +- JobDetails -显示作业的详细运行状态，包括导入的文件数、总大小（以字节为单位）、子任务数、正在处理的原始行数等。例如： +显示作业的详细运行状态，包括导入文件数量、总大小（字节）、子任务数量、正在处理的原始行数等。例如： ~~~json {"ScannedRows":139264,"TaskNumber":1,"FileNumber":1,"FileSize":940754064} ~~~ -- **URL** +- URL -您可以将输入复制到浏览器以访问相应应用程序的 Web 界面。 +您可以将输入复制到浏览器中，以访问相应应用程序的 Web 界面。 ### 查看 Apache Spark™ Launcher 提交日志 -有时，用户需要查看在 Apache Spark™ 作业提交期间生成的详细日志。默认情况下，日志保存在 FE 根目录中的 `log/spark_launcher_log` 路径中，命名为 `spark-launcher-{load-job-id}-{label}.log`。日志在此目录中保存一段时间，并在 FE 元数据中的导入信息被清除时删除。默认保留时间为 3 天。 +有时用户需要查看 Apache Spark™ 作业提交期间生成的详细日志。默认情况下，日志保存在 FE 根目录下的 `log/spark_launcher_log` 路径中，命名为 `spark-launcher-{load-job-id}-{label}.log`。日志在此目录中保存一段时间，并在 FE 元数据中的导入信息被清理时被清除。默认保留时间为 3 天。 ### 取消导入 -当 Spark load 作业状态不是 `CANCELLED` 或 `FINISHED` 时，用户可以通过指定导入作业的 Label 手动取消它。 +当 Spark Load 作业状态不是 `CANCELLED` 或 `FINISHED` 时，用户可以通过指定导入作业的 Label 手动取消。 --- ## 相关系统配置 -**FE 配置：** 以下配置是 Spark load 的系统级配置，适用于所有 Spark load 导入作业。可以通过修改 `fe.conf` 来调整配置值。 +FE 配置：以下配置是 Spark Load 的系统级配置，适用于所有 Spark Load 导入作业。配置值主要通过修改 `fe.conf` 进行调整。 -- enable-spark-load：启用 Spark load 和资源创建，默认值为 false。 -- spark-load-default-timeout-second：作业的默认超时时间为 259200 秒（3 天）。 -- spark-home-default-dir：Spark 客户端路径 (`fe/lib/spark2x`)。 -- spark-resource-path：打包的 S park 依赖项文件的路径（默认为空）。 -- spark-launcher-log-dir：Spark 客户端的提交日志存储的目录 (`fe/log/spark-launcher-log`)。 -- yarn-client-path：yarn 二进制可执行文件的路径 (`fe/lib/yarn-client/hadoop/bin/yarn`)。 -- yarn-config-dir：Yarn 的配置文件路径 (`fe/lib/yarn-config`)。 +- `enable-spark-load`: 启用 Spark Load 和资源创建，默认值为 false。 +- `spark-load-default-timeout-second`: 作业的默认超时时间为 259200 秒（3 天）。 +- `spark-home-default-dir`: Spark 客户端路径 (`fe/lib/spark2x`)。 +- `spark-resource-path`: 打包的 Spark 依赖文件的路径（默认为空）。 +- `spark-launcher-log-dir`: Spark 客户端提交日志的存储目录 (`fe/log/spark-launcher-log`)。 +- `yarn-client-path`: Yarn 二进制可执行文件的路径 (`fe/lib/yarn-client/hadoop/bin/yarn`)。 +- `yarn-config-dir`: Yarn 的配置文件路径 (`fe/lib/yarn-config`)。 --- ## 最佳实践 -使用 Spark load 最合适的场景是原始数据位于文件系统 (HDFS) 中，并且数据量在数十 GB 到 TB 级别。对于较小的数据量，请使用 Stream Load 或 Broker Load。 +最适合使用 Spark Load 的场景是当原始数据在文件系统 (HDFS) 中，且数据量在几十 GB 到 TB 级别时。对于较小的数据量，请使用 Stream Load 或 Broker Load。 -有关完整的 spark load 导入示例，请参阅 github 上的演示：[https://github.com/StarRocks/demo/blob/master/docs/03_sparkLoad2StarRocks.md](https://github.com/StarRocks/demo/blob/master/docs/03_sparkLoad2StarRocks.md) +有关完整的 Spark Load 导入示例，请参考 GitHub 上的演示：[https://github.com/StarRocks/demo/blob/master/docs/03_sparkLoad2StarRocks.md](https://github.com/StarRocks/demo/blob/master/docs/03_sparkLoad2StarRocks.md) -## 常见问题解答 +## 常见问题 - `Error: When running with master 'yarn' either HADOOP-CONF-DIR or YARN-CONF-DIR must be set in the environment.` - 使用 Spark Load 时，未在 Spark 客户端的 `spark-env.sh` 中配置 `HADOOP-CONF-DIR` 环境变量。 + 在使用 Spark Load 时，未在 Spark 客户端的 `spark-env.sh` 中配置 `HADOOP-CONF-DIR` 环境变量。 - `Error: Cannot run program "xxx/bin/spark-submit": error=2, No such file or directory` - 使用 Spark Load 时，`spark_home_default_dir` 配置项未指定 Spark 客户端根目录。 + 在使用 Spark Load 时，`spark_home_default_dir` 配置项未指定 Spark 客户端根目录。 - `Error: File xxx/jars/spark-2x.zip does not exist.` - 使用 Spark load 时，`spark-resource-path` 配置项未指向打包的 zip 文件。 + 在使用 Spark Load 时，`spark-resource-path` 配置项未指向打包的 zip 文件。 - `Error: yarn client does not exist in path: xxx/yarn-client/hadoop/bin/yarn` - 使用 Spark load 时，yarn-client-path 配置项未指定 yarn 可执行文件。 + 在使用 Spark Load 时，`yarn-client-path` 配置项未指定 Yarn 可执行文件。 - `ERROR: Cannot execute hadoop-yarn/bin/... /libexec/yarn-config.sh` - 将 Hadoop 与 CDH 结合使用时，需要配置 `HADOOP_LIBEXEC_DIR` 环境变量。 - 由于 `hadoop-yarn` 和 hadoop 目录不同，因此默认的 `libexec` 目录将查找 `hadoop-yarn/bin/... /libexec`，而 `libexec` 位于 hadoop 目录中。 - ```yarn application status`` 命令获取 Spark 任务状态报告错误，导致导入作业失败。 \ No newline at end of file + 当使用 CDH 版本的 Hadoop 时，您需要配置 `HADOOP_LIBEXEC_DIR` 环境变量。 + 由于 `hadoop-yarn` 和 hadoop 目录不同，默认的 `libexec` 目录会查找 `hadoop-yarn/bin/... /libexec`，而 `libexec` 位于 hadoop 目录中。 + ```yarn application status`` 命令获取 Spark 任务状态时报错，导致导入作业失败。 From 0b596783795c045bdc8aea187ea40878a9d129f8 Mon Sep 17 00:00:00 2001 From: DanRoscigno Date: Thu, 12 Feb 2026 19:07:28 -0500 Subject: [PATCH 3/5] trigger Signed-off-by: DanRoscigno --- docs/zh/introduction/Architecture.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/zh/introduction/Architecture.md b/docs/zh/introduction/Architecture.md index 34b93c3d..d9a15f06 100644 --- a/docs/zh/introduction/Architecture.md +++ b/docs/zh/introduction/Architecture.md @@ -4,7 +4,6 @@ import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx' # 架构 - StarRocks 具有强大的架构。整个系统仅由两种类型的组件组成："前端" 和 "后端"。前端节点被称为 **FE**。后端节点分为两种类型：**BE** 和 **CN**（计算节点）。当数据使用本地存储时，部署 BE；当数据存储在对象存储或 HDFS 上时，部署 CN。StarRocks 不依赖任何外部组件，从而简化了部署和维护。节点可以水平扩展而无需停机。此外，StarRocks 具有元数据和服务数据的副本机制，这提高了数据可靠性并有效防止了单点故障 (SPOFs)。 StarRocks 兼容 MySQL 通信协议并支持标准 SQL。用户可以通过 MySQL 客户端连接到 StarRocks，以获取即时且有价值的洞察。 From 123e1439d1e61db617c00b4fd3692cd5f1a3d184 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Fri, 13 Feb 2026 00:08:49 +0000 Subject: [PATCH 4/5] chore: add automated translations Generated by markdown-translator Triggered by: @DanRoscigno --- docs/en/introduction/Architecture.md | 63 ++++++++++++++-------------- 1 file changed, 32 insertions(+), 31 deletions(-) diff --git a/docs/en/introduction/Architecture.md b/docs/en/introduction/Architecture.md index e111ac9a..f3065169 100644 --- a/docs/en/introduction/Architecture.md +++ b/docs/en/introduction/Architecture.md @@ -1,83 +1,84 @@ +```md displayed_sidebar: docs import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx' # Architecture -OK +StarRocks features a powerful architecture. The entire system consists of only two types of components: "frontend" and "backend". Frontend nodes are called **FE**s. Backend nodes are divided into two types: **BE**s and **CN**s (compute nodes). BEs are deployed when data uses local storage; CNs are deployed when data is stored on object storage or HDFS. StarRocks does not rely on any external components, which simplifies deployment and maintenance. Nodes can be horizontally scaled without downtime. In addition, StarRocks has a replica mechanism for metadata and service data, which improves data reliability and effectively prevents single points of failure (SPOFs). -StarRocks has a powerful architecture. The entire system consists of only two types of components: "frontends" and "backends". Frontend nodes are called **FE**. Backend nodes are divided into two types: **BE** and **CN** (compute node). When data uses local storage, BEs are deployed; when data is stored on object storage or HDFS, CNs are deployed. StarRocks does not rely on any external components, which simplifies deployment and maintenance. Nodes can be scaled horizontally without downtime. In addition, StarRocks has a replica mechanism for metadata and service data, which improves data reliability and effectively prevents single points of failure (SPOFs). +StarRocks is compatible with the MySQL communication protocol and supports standard SQL. Users can connect to StarRocks via MySQL clients to gain immediate and valuable insights. -StarRocks is compatible with the MySQL communication protocol and supports standard SQL. Users can connect to StarRocks via a MySQL client to gain instant and valuable insights. +## Architectural Choices -## Architecture Choices +StarRocks supports the shared-nothing mode (where each BE owns a portion of the data on its local storage) and the shared-data mode (where all data is stored on object storage or HDFS, and each CN only has a cache on its local storage). You can decide where to store data based on your requirements. -StarRocks supports the shared-nothing mode (where each BE owns a portion of the data on its local storage) and the shared-data mode (where all data is stored on object storage or HDFS, and each CN only has a cache on its local storage). You can decide where to store your data based on your needs. +![Architectural Choices](../_assets/architecture_choices.png) -![架构选择](../_assets/architecture_choices.png) - -### Shared-nothing Mode +### Shared-nothing mode Local storage provides better query latency for real-time queries. -As a typical Massively Parallel Processing (MPP) database, StarRocks supports the shared-nothing architecture. In this architecture, BEs are responsible for data storage and compute. Directly accessing local data on BE nodes enables local compute, avoiding data transfer and data copying, and providing ultra-fast query and data analytics performance. This architecture supports multi-replica data storage, enhancing the cluster's ability to handle high-concurrency queries and ensuring data reliability. It is ideal for scenarios that require optimal query performance. +As a typical Massively Parallel Processing (MPP) database, StarRocks supports a shared-nothing architecture. In this architecture, BEs are responsible for data storage and compute. Directly accessing local data on BEs allows for local computation, avoiding data transfer and copying, and providing ultra-fast query and data analytics performance. This architecture supports multi-replica data storage, enhancing the cluster's ability to handle high-concurrency queries and ensuring data reliability. It is ideal for scenarios that demand optimal query performance. -![存算一体架构](../_assets/shared-nothing.png) +![Shared-nothing Architecture](../_assets/shared-nothing.png) #### Nodes +In a shared-nothing architecture, StarRocks consists of two types of nodes: FEs and BEs. -In the shared-nothing architecture, StarRocks consists of two types of nodes: FE and BE. +- FEs are responsible for metadata management and building execution plans. +- BEs execute query plans and store data. BEs utilize local storage to accelerate queries and use a multi-replica mechanism to ensure data high availability. -- FE is responsible for metadata management and building execution plans. -- BE executes query plans and stores data. BEs leverage local storage to accelerate queries and use a multi-replica mechanism to ensure data high availability. ##### FE -FE is responsible for metadata management, client connection management, query planning, and query scheduling. Each FE uses BDB JE (Berkeley DB Java Edition) to store and maintain a complete replica of metadata in its memory, ensuring service consistency among all FEs. FEs can operate as Leader, Follower, and Observer. If the Leader node crashes, Followers will elect a Leader based on the Raft protocol. +FEs are responsible for metadata management, client connection management, query planning, and query scheduling. Each FE uses BDB JE (Berkeley DB Java Edition) to store and maintain a complete replica of metadata in its memory, ensuring service consistency among all FEs. FEs can operate as a Leader, Follower, and Observer. If the Leader node crashes, Follower FEs will elect a Leader according to the Raft protocol. | **FE Role** | **Metadata Management** | **Leader Election** | | ----------- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ---------------------------------- | -| Leader | The Leader FE reads and writes metadata. Follower and Observer FEs can only read metadata. They route metadata write requests to the Leader FE. The Leader FE updates metadata, then uses the Raft protocol to synchronize metadata changes to Follower and Observer FEs. Data writes are considered successful only after metadata changes are synchronized to more than half of the Follower FEs. | The Leader FE is, technically, also a Follower node, elected by Follower FEs. To perform Leader election, more than half of the Follower FEs in the cluster must be active. When the Leader FE fails, Follower FEs will initiate a new round of Leader election. | -| Follower | Followers can only read metadata. They synchronize and replay logs from the Leader FE to update metadata. | Followers participate in Leader election, which requires more than half of the Followers in the cluster to be active. | -| Observer | Synchronizes and replays logs from the Leader FE to update metadata. | Observers are mainly used to improve the query concurrency of the cluster. Observers do not participate in Leader election and therefore do not increase the Leader election pressure on the cluster. | +| Leader | Leader FEs read and write metadata. Follower and Observer FEs can only read metadata. They route metadata write requests to the Leader FE. The Leader FE updates metadata, and then uses the Raft protocol to synchronize metadata changes to Follower and Observer FEs. Data writes are considered successful only after metadata changes are synchronized to more than half of the Follower FEs. | The Leader FE is, technically speaking, also a Follower node, elected by Follower FEs. To perform a Leader election, more than half of the Follower FEs in the cluster must be active. When a Leader FE fails, Follower FEs will initiate a new round of Leader election. | +| Follower | Follower FEs can only read metadata. They synchronize and replay logs from the Leader FE to update metadata. | Follower FEs participate in Leader elections, which requires more than half of the Follower FEs in the cluster to be active. | +| Observer | Synchronize and replay logs from the Leader FE to update metadata. | Observer FEs are mainly used to improve the query concurrency of the cluster. Observer FEs do not participate in Leader elections, thus they do not increase the pressure on the cluster's Leader election process. | ##### BE BEs are responsible for data storage and SQL execution. -- Data Storage: BEs have equivalent data storage capabilities. FE distributes data to BEs according to predefined rules. BEs transform ingested data, write data in the required format, and generate indexes for the data. +- Data Storage: BEs have equivalent data storage capabilities. FEs distribute data to BEs according to predefined rules. BEs transform ingested data, write data into the required format, and generate indexes for the data. + +- SQL Execution: FEs parse each SQL query into a logical execution plan based on the query's semantics, then convert the logical plan into a physical execution plan that can be executed on BEs. BEs storing the target data execute the query. This eliminates the need for data transfer and copying, thus achieving high query performance. -- SQL Execution: FE parses each SQL query into a logical execution plan based on the query's semantics, and then converts the logical plan into a physical execution plan that can be executed on BEs. The BEs storing the target data execute the query. This eliminates the need for data transfer and copying, thereby achieving high query performance. -### Shared-data Mode +### Shared-data mode -Object storage and HDFS offer advantages in terms of cost, reliability, and scalability. In addition to storage scalability, due to the separation of storage and compute, CN nodes can be added and removed on demand without re-balancing data. +Object storage and HDFS offer advantages in terms of cost, reliability, and scalability. In addition to storage scalability, CN nodes can be added and removed on demand without data re-distribution, thanks to the separation of storage and compute. -In the shared-data architecture, BEs are replaced by "compute nodes (CNs)", which are only responsible for data compute tasks and caching hot data. Data is stored in low-cost, reliable remote storage systems, such as Amazon S3, Google Cloud Storage, Azure Blob Storage, MinIO, etc. When the cache hits, query performance is comparable to the shared-nothing architecture. CN nodes can be added or removed on demand within seconds. This architecture reduces storage costs, ensures better resource isolation, and offers high elasticity and scalability. +In a shared-data architecture, BEs are replaced by "compute nodes (CNs)," which are solely responsible for data compute tasks and caching hot data. Data is stored in low-cost, reliable remote storage systems, such as Amazon S3, Google Cloud Storage, Azure Blob Storage, MinIO, etc. When the cache is hit, query performance is comparable to that of a shared-nothing architecture. CN nodes can be added or removed on demand within seconds. This architecture reduces storage costs, ensures better resource isolation, and offers high elasticity and scalability. -The shared-data architecture, like the shared-nothing architecture, maintains a simple design. It consists of only two types of nodes: FE and CN. The only difference is that users need to provision a backend object storage. +The shared-data architecture, like the shared-nothing architecture, maintains a simple structure. It consists of only two types of nodes: FEs and CNs. The only difference is that users need to provision backend object storage. -![存算分离架构](../_assets/shared-data.png) +![Shared-data Architecture](../_assets/shared-data.png) #### Nodes -The coordinator nodes in a shared-data architecture provide the same functionality as the FEs in a shared-nothing architecture. +The coordination nodes in a shared-data architecture provide the same functionality as FEs in a shared-nothing architecture. -BEs are replaced by CNs (compute nodes), and storage functionality is offloaded to object storage or HDFS. CNs are stateless compute nodes that perform all BE functions except data storage. +BEs are replaced by CNs (compute nodes), and storage functionality is offloaded to object storage or HDFS. CNs are stateless compute nodes that perform all functions of BEs, except for data storage. #### Storage StarRocks shared-data clusters support two storage solutions: object storage (such as AWS S3, Google GCS, Azure Blob Storage, or MinIO) and HDFS. -In shared-data clusters, the data file format remains consistent with shared-nothing clusters (which feature coupled storage and compute). Data is organized into segment files, and various indexing technologies are reused in Cloud-native tables, which are tables specifically used in shared-data clusters. +In a shared-data cluster, the data file format remains consistent with that of a shared-nothing cluster (which features coupled storage and compute). Data is organized into segment files, and various indexing techniques are reused in shared-data tables, which are tables specifically used in shared-data clusters. #### Cache -StarRocks shared-data clusters decouple data storage and compute, allowing them to scale independently, thereby reducing costs and enhancing elasticity. However, this architecture may affect query performance. +StarRocks shared-data clusters decouple data storage and compute, allowing them to scale independently, which reduces costs and enhances elasticity. However, this architecture might affect query performance. -To mitigate the impact, StarRocks has established a multi-tiered data access system covering memory, local disk, and remote storage to better meet various business needs. +To mitigate this impact, StarRocks has established a multi-tiered data access system covering memory, local disk, and remote storage to better meet various business needs. -Hot data queries directly scan the cache, then scan the local disk; while cold data needs to be loaded from object storage into the local cache to accelerate subsequent queries. By keeping hot data close to the compute unit, StarRocks achieves truly high-performance compute and cost-effective storage. In addition, cold data access has been optimized through data prefetching strategies, effectively eliminating query performance limitations. +Hot data queries directly scan the cache, then scan the local disk; while cold data needs to be loaded from object storage into the local cache to accelerate subsequent queries. By keeping hot data close to the compute units, StarRocks achieves truly high-performance compute and cost-effective storage. Additionally, cold data access has been optimized through data prefetching strategies, effectively eliminating query performance limitations. -Caching can be enabled when creating a table. If caching is enabled, data will be written simultaneously to both local disk and the backend object storage. During queries, CN nodes first read data from the local disk. If data is not found, it will be retrieved from the backend object storage and simultaneously cached to the local disk. +Caching can be enabled when creating a table. If caching is enabled, data will be written simultaneously to local disk and backend object storage. During a query, the CN node first reads data from the local disk. If the data is not found, it retrieves it from backend object storage and simultaneously caches it to the local disk. +``` From acff4275e30a6d989df8b60b1a48b4df97b4f395 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Fri, 13 Feb 2026 00:13:15 +0000 Subject: [PATCH 5/5] chore: add automated translations Generated by markdown-translator Triggered by: @DanRoscigno --- docs/ja/introduction/Architecture.md | 82 +++++++++++++--------------- 1 file changed, 37 insertions(+), 45 deletions(-) diff --git a/docs/ja/introduction/Architecture.md b/docs/ja/introduction/Architecture.md index 1b857e9b..b3d368b3 100644 --- a/docs/ja/introduction/Architecture.md +++ b/docs/ja/introduction/Architecture.md @@ -1,87 +1,79 @@ -```md ---- -displayed_sidebar: docs ---- - import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx' -# Architecture - -StarRocks は堅牢なアーキテクチャを備えています。システム全体は「フロントエンド」と「バックエンド」の2種類のコンポーネントのみで構成されています。フロントエンドノードは **FE** と呼ばれます。バックエンドノードには **BE** と **CN** (コンピュートノード) の2種類があります。データにローカルストレージを使用する場合に BE がデプロイされ、データがオブジェクトストレージまたは HDFS に保存される場合に CN がデプロイされます。StarRocks は外部コンポーネントに依存せず、デプロイとメンテナンスを簡素化します。ノードはサービス停止なしで水平にスケールできます。さらに、StarRocks はメタデータとサービスデータのレプリカメカニズムを備えており、データ信頼性を高め、単一障害点 (SPOF) を効率的に防止します。 - -StarRocks は MySQL 通信プロトコルと互換性があり、標準 SQL をサポートしています。ユーザーは MySQL クライアントから StarRocks に接続し、瞬時に貴重なインサイトを得ることができます。 +# アーキテクチャ -## Architecture choices +StarRocks は強力なアーキテクチャを特徴としています。システム全体は「フロントエンド」と「バックエンド」の2種類のコンポーネントのみで構成されています。フロントエンドノードは **FE** と呼ばれます。バックエンドノードは **BE** と **CN** (コンピュートノード) の2種類に分かれます。BE はデータがローカルストレージを使用する場合にデプロイされ、CN はデータがオブジェクトストレージまたは HDFS に保存される場合にデプロイされます。StarRocks は外部コンポーネントに依存しないため、デプロイとメンテナンスが簡素化されます。ノードはダウンタイムなしで水平方向にスケーリングできます。さらに、StarRocks はメタデータとサービスデータのレプリカメカニズムを備えており、データ信頼性を向上させ、単一障害点（SPOF）を効果的に防止します。 -StarRocks は、shared-nothing (各 BE がローカルストレージにデータの一部を保持する) と shared-data (すべてのデータがオブジェクトストレージまたは HDFS にあり、各 CN がローカルストレージにキャッシュのみを保持する) をサポートします。データの保存場所は、ニーズに基づいて決定します。 +StarRocks は MySQL 通信プロトコルと互換性があり、標準 SQL をサポートしています。ユーザーは MySQL クライアントを介して StarRocks に接続し、即座に貴重な洞察を得ることができます。 -![Architecture choices](../_assets/architecture_choices.png) +## アーキテクチャの選択肢 +StarRocks は、共有なしモード（各 BE がローカルストレージにデータの一部を所有する）と共有データモード（すべてのデータがオブジェクトストレージまたは HDFS に保存され、各 CN がローカルストレージにキャッシュのみを持つ）をサポートしています。要件に基づいてデータをどこに保存するかを決定できます。 -### Shared-nothing +![アーキテクチャの選択肢](../_assets/architecture_choices.png) -ローカルストレージは、リアルタイムクエリのクエリレイテンシを向上させます。 +### 共有なしモード +ローカルストレージは、リアルタイムクエリに対してより優れたクエリレイテンシーを提供します。 -典型的な大規模並列処理 (MPP) データベースとして、StarRocks は共有なしアーキテクチャをサポートします。このアーキテクチャでは、BE はデータストレージとコンピュートの両方を担当します。BE モードでローカルデータに直接アクセスすることで、ローカルコンピュートが可能になり、データ転送やデータコピーを回避し、超高速なクエリおよびデータ分析パフォーマンスを提供します。このアーキテクチャはマルチレプリカデータストレージをサポートし、クラスタの高い同時実行性クエリ処理能力を高め、データ信頼性を確保します。最適なクエリパフォーマンスを追求するシナリオに適しています。 +一般的な Massively Parallel Processing (MPP) データベースとして、StarRocks は共有なしアーキテクチャをサポートしています。このアーキテクチャでは、BE はデータストレージとコンピュートを担当します。BE 上のローカルデータに直接アクセスすることで、ローカルでの計算が可能になり、データ転送とコピーが回避され、超高速なクエリパフォーマンスとデータ分析性能が提供されます。このアーキテクチャはマルチレプリカデータストレージをサポートし、クラスターの高い同時実行性クエリを処理する能力を高め、データ信頼性を保証します。最適なクエリパフォーマンスを求めるシナリオに最適です。 -![shared-data-arch](../_assets/shared-nothing.png) +![共有なしアーキテクチャ](../_assets/shared-nothing.png) -#### The nodes +#### ノード -共有なしアーキテクチャにおいて、StarRocks は FE と BE の2種類のノードで構成されます。 +共有なしアーキテクチャでは、StarRocks は FE と BE の2種類のノードで構成されます。 - FE はメタデータ管理と実行プランの構築を担当します。 -- BE はクエリプランを実行し、データを保存します。BE はローカルストレージを利用してクエリを高速化し、マルチレプリカメカニズムによって高いデータ可用性を確保します。 +- BE はクエリプランを実行し、データを保存します。BE はローカルストレージを利用してクエリを高速化し、マルチレプリカメカニズムを使用してデータの高可用性を保証します。 ##### FE -FE は、メタデータ管理、クライアント接続管理、クエリプランニング、およびクエリスケジューリングを担当します。各 FE は BDB JE (Berkeley DB Java Edition) を使用して、メタデータの完全なコピーをメモリに保存および維持し、すべての FE 間で一貫したサービスを保証します。FE は Leader、Follower、および Observer として機能できます。Leader ノードがクラッシュした場合、Follower は Raft プロトコルに基づいて Leader を選出します。 +FE はメタデータ管理、クライアント接続管理、クエリプランニング、クエリスケジューリングを担当します。各 FE は BDB JE (Berkeley DB Java Edition) を使用して、メタデータの完全なレプリカをメモリ内に保存および維持し、すべての FE 間でサービスの一貫性を保証します。FE は Leader、Follower、Observer として機能できます。Leader ノードがクラッシュした場合、Follower FE は Raft プロトコルに従って Leader を選出します。 -| **FE ロール** | **メタデータ管理** | **Leader 選出** | -| :---------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Leader | Leader FE はメタデータを読み書きします。Follower FE と Observer FE はメタデータを読み取ることしかできません。これらはメタデータ書き込みリクエストを Leader FE にルーティングします。Leader FE はメタデータを更新し、Raft プロトコルを使用してメタデータの変更を Follower FE と 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 | Leader FE からログを同期およびリプレイしてメタデータを更新します。 | Observer は主にクラスタのクエリ同時実行性を高めるために使用されます。Observer は Leader 選出に参加しないため、クラスタに Leader 選出のプレッシャーを追加することはありません。| +| **FE の役割** | **メタデータ管理** | **Leader 選出** | +| :---------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Leader | Leader FE はメタデータを読み書きします。Follower FE と Observer FE はメタデータを読み取ることしかできません。これらはメタデータの書き込みリクエストを Leader FE にルーティングします。Leader FE はメタデータを更新し、Raft プロトコルを使用してメタデータの変更を Follower FE と Observer FE に同期します。データ書き込みは、メタデータの変更が Follower FE の半数以上に同期された後にのみ成功と見なされます。 | Leader FE は、技術的には Follower ノードでもあり、Follower FE によって選出されます。Leader 選出を実行するには、クラスター内の Follower FE の半数以上がアクティブである必要があります。Leader FE が失敗した場合、Follower FE は新しい Leader 選出を開始します。 | +| Follower | Follower FE はメタデータを読み取ることしかできません。これらは Leader FE からログを同期およびリプレイしてメタデータを更新します。 | Follower FE は Leader 選出に参加し、クラスター内の Follower FE の半数以上がアクティブである必要があります。 | +| Observer | Leader FE からログを同期およびリプレイしてメタデータを更新します。 | Observer FE は、主にクラスターのクエリ同時実行性を向上させるために使用されます。Observer FE は Leader 選出に参加しないため、クラスターの Leader 選出プロセスへの負荷を増やしません。 | ##### BE BE はデータストレージと SQL 実行を担当します。 -- データストレージ: BE は同等のデータストレージ機能を持ちます。FE は事前に定義されたルールに基づいてデータを BE に分散します。BE は取り込まれたデータを変換し、必要なフォーマットでデータを書き込み、データ用のインデックスを生成します。 +- データストレージ: BE は同等のデータストレージ機能を持ちます。FE は事前に定義されたルールに従って BE にデータを分散します。BE は取り込まれたデータを変換し、必要な形式でデータを書き込み、データにインデックスを生成します。 -- SQL 実行: FE は各 SQL クエリをそのクエリのセマンティクスに従って論理実行プランに解析し、その論理プランを BE で実行できる物理実行プランに変換します。宛先データを保存する BE がクエリを実行します。これにより、データ転送やコピーの必要がなくなり、高いクエリパフォーマンスを実現します。 +- SQL 実行: FE は各 SQL クエリをクエリのセマンティクスに基づいて論理実行プランに解析し、その論理プランを BE 上で実行可能な物理実行プランに変換します。ターゲットデータを保存している BE がクエリを実行します。これにより、データ転送やコピーの必要がなくなり、高いクエリパフォーマンスを実現します。 -### Shared-data +### 共有データモード -オブジェクトストレージと HDFS は、コスト、信頼性、および拡張性のメリットを提供します。ストレージの拡張性に加えて、ストレージとコンピュートが分離されているため、データのリバランスなしで CN ノードを追加および削除できます。 +オブジェクトストレージと HDFS は、コスト、信頼性、およびスケーラビリティの面で利点を提供します。ストレージのスケーラビリティに加えて、ストレージとコンピュートの分離により、データ再配布なしで CN ノードをオンデマンドで追加および削除できます。 -共有データアーキテクチャでは、BE は「コンピュートノード (CN)」に置き換えられ、データコンピュートタスクとホットデータのキャッシュのみを担当します。データは、Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIO などの低コストで信頼性の高いリモートストレージシステムに保存されます。キャッシュがヒットした場合、クエリパフォーマンスは共有なしアーキテクチャのそれに匹敵します。CN ノードは数秒でオンデマンドに追加または削除できます。このアーキテクチャは、ストレージコストを削減し、より優れたリソース分離、高い柔軟性と拡張性を保証します。 +共有データアーキテクチャでは、BE は「コンピュートノード (CN)」に置き換えられ、データコンピュートタスクとホットデータのキャッシュのみを担当します。データは、Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIO などの低コストで信頼性の高いリモートストレージシステムに保存されます。キャッシュがヒットした場合、クエリパフォーマンスは共有なしアーキテクチャのそれに匹敵します。CN ノードは数秒以内にオンデマンドで追加または削除できます。このアーキテクチャはストレージコストを削減し、より良いリソース分離を保証し、高い弾力性と高拡張性を提供します。 -共有データアーキテクチャは、共有なしアーキテクチャと同様にシンプルなアーキテクチャを維持します。FE と CN の2種類のノードのみで構成されます。唯一の違いは、ユーザーがバックエンドオブジェクトストレージをプロビジョニングする必要があることです。 +共有データアーキテクチャは、共有なしアーキテクチャと同様に、シンプルな構造を維持します。FE と CN の2種類のノードのみで構成されています。唯一の違いは、ユーザーがバックエンドのオブジェクトストレージをプロビジョニングする必要があることです。 -![shared-data-arch](../_assets/shared-data.png) +![共有データアーキテクチャ](../_assets/shared-data.png) -#### Nodes +#### ノード -共有データアーキテクチャにおけるコーディネーターノードは、共有なしアーキテクチャにおける FE と同じ機能を提供します。 +共有データアーキテクチャにおける調整ノードは、共有なしアーキテクチャにおける FE と同じ機能を提供します。 -BE は CN (コンピュートノード) に置き換えられ、ストレージ機能はオブジェクトストレージまたは HDFS にオフロードされます。CN はステートレスなコンピュートノードであり、データの保存を除く BE のすべての機能を実行します。 +BE は CN (コンピュートノード) に置き換えられ、ストレージ機能はオブジェクトストレージまたは HDFS にオフロードされます。CN は、データストレージを除く BE のすべての機能を実行するステートレスなコンピュートノードです。 -#### Storage +#### ストレージ -StarRocks 共有データクラスタは、オブジェクトストレージ (例: AWS S3、Google GCS、Azure Blob Storage、MinIO) および HDFS の2つのストレージソリューションをサポートします。 +StarRocks 共有データクラスタは、オブジェクトストレージ（AWS S3、Google GCS、Azure Blob Storage、MinIO など）と HDFS の2つのストレージソリューションをサポートしています。 -共有データクラスタでは、データファイル形式は共有なしクラスタ (結合されたストレージとコンピュートを特徴とする) のものと一貫しています。データはセグメントファイルに整理され、さまざまなインデックス技術は、共有データクラスタで特別に使用されるクラウドネイティブテーブルで再利用されます。 +共有データクラスタでは、データファイル形式は共有なしクラスタ（ストレージとコンピュートが結合されている）のそれと一貫しています。データはセグメントファイルに編成され、さまざまなインデックス技術が共有データテーブル（共有データクラスタで特別に使用されるテーブル）で再利用されます。 -#### Cache +#### キャッシュ -StarRocks 共有データクラスタは、データストレージとコンピュートを分離し、それぞれを独立してスケーリングできるようにすることで、コストを削減し、柔軟性を高めます。しかし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。 +StarRocks 共有データクラスタはデータストレージとコンピュートを分離し、これらを独立してスケーリングできるようにすることで、コストを削減し、弾力性を高めます。しかし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。 -この影響を軽減するために、StarRocks はメモリ、ローカルディスク、およびリモートストレージを含む多層データアクセスシステムを確立し、さまざまなビジネスニーズに効率的に対応します。 +この影響を軽減するため、StarRocks はメモリ、ローカルディスク、およびリモートストレージをカバーする多層データアクセスシステムを確立し、さまざまなビジネスニーズにより良く対応しています。 -ホットデータに対するクエリは、直接キャッシュをスキャンし、次にローカルディスクをスキャンします。一方、コールドデータはオブジェクトストレージからローカルキャッシュにロードして、その後のクエリを高速化する必要があります。ホットデータをコンピュートユニットの近くに保持することで、StarRocks は真に高性能なコンピュートと費用対効果の高いストレージを実現します。さらに、コールドデータへのアクセスはデータプリフェッチ戦略で最適化され、クエリのパフォーマンス制限を効果的に排除します。 +ホットデータクエリは直接キャッシュをスキャンし、次にローカルディスクをスキャンします。一方、コールドデータはオブジェクトストレージからローカルキャッシュにロードして、その後のクエリを高速化する必要があります。ホットデータをコンピュートユニットの近くに保持することで、StarRocks は真に高性能なコンピュートと費用対効果の高いストレージを実現します。さらに、コールドデータアクセスはデータプリフェッチ戦略によって最適化され、クエリパフォーマンスの制限を効果的に排除しています。 -キャッシングはテーブル作成時に有効にできます。キャッシングが有効な場合、データはローカルディスクとバックエンドオブジェクトストレージの両方に書き込まれます。クエリ中、CN ノードはまずローカルディスクからデータを読み取ります。データが見つからない場合、バックエンドオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。 +テーブル作成時にキャッシュを有効にすることができます。キャッシュが有効な場合、データはローカルディスクとバックエンドのオブジェクトストレージに同時に書き込まれます。クエリ中、CN ノードは最初にローカルディスクからデータを読み取ります。データが見つからない場合、バックエンドのオブジェクトストレージから取得し、同時にローカルディスクにキャッシュします。 -```