StarRocks に関するよくある質問 - E-MapReduce - Alibaba Cloud ドキュメントセンター

ハードウェア要件

全体的なマシン構成

BE ノードには、少なくとも 16 CPU コアと 64 GB のメモリを推奨します。FE ノードには、少なくとも 8 CPU コアと 16 GB のメモリを推奨します。

本番環境では、FE ノードは通常、16 CPU コア、32 GB または 64 GB のメモリ、および 200 GB から 500 GB の NVMe ソリッドステートドライブ (SSD) を備えています。
ディスク
- ハードディスクドライブ (HDD) または SSD を使用できます。
- 3:1 の圧縮率と 70% から 75% の最大ディスク使用率を使用して、必要なディスク容量を見積もってください。
- Parquet または ORC 形式の Hive データを StarRocks にインポートする場合は、1:1 の圧縮率で見積もってください。
  
  たとえば、ソースの Hive データが 3 TB の場合、インポート後の StarRocks のデータサイズも 3 TB になります。
CPU
- CPU は Advanced Vector Extensions 2 (AVX2) 命令セットをサポートしている必要があります。サポート状況は cat /proc/cpuinfo | grep avx2 コマンドを実行して確認できます。
- ベクトル化実行エンジンは、互換性のある CPU 命令セットで最適に動作します。お使いのマシンの CPU が必要な命令セットをサポートしていない場合は、ハードウェアをアップグレードすることを推奨します。
ネットワーク

10 ギガビットイーサネットのネットワークインターフェースカード (NIC) とスイッチの使用を推奨します。

ソフトウェア構成要件

ソフトウェア構成の詳細については、「パラメーター設定」をご参照ください。

レプリカ構成

一般的な本番環境では、2 つまたは 3 つのレプリカで十分です。レプリカの数を 3 に設定することを推奨します。

テーブルのパーティション分割

適切なパーティション分割により、スキャンされるデータ量を効果的に削減できます。

通常、ビジネスでデータを管理する方法に基づいてパーティションキーを選択します。たとえば、時間や地域の列をパーティションキーとして使用できます。
パーティションを自動的に作成する必要がある場合は、動的パーティションを使用できます。

バケット化の使用

バケット間のデータスキューを防ぐために、高カーディナリティの列をバケット化キーとして選択します。
- 一意の ID が存在する場合、それをバケット化に使用することを推奨します。
- 深刻なデータスキューが発生した場合は、複数の列をバケット化キーとして使用できます。ただし、使用する列が多すぎないようにしてください。
総データ量と以下のガイドラインに基づいて、最適なタブレットサイズとバケットの総数を推定します。
- CSV 形式のデータなど、非圧縮の生データの場合、各タブレットの推奨サイズは 1 GB から 10 GB です。
- Parquet 形式のデータの場合、タブレットサイズは約 1 GB を推奨します。
少数のマシンでリソース使用率を最大化するには、数式 BE の数 * CPU コア数 / 2 を使用してバケット数を計算してください。

ソートキーの設計

クエリパターンに基づいてソートキーを設計します：

クエリを高速化するために、フィルター条件や GROUP BY 句で頻繁に使用される列をソートキーとして使用します。
ワークロードに多数のポイントルックアップが含まれる場合は、ルックアップに使用される ID 列をソートキーの最初の列に配置します。

たとえば、select sum(revenue) from lineorder where user_id='aaa100'; のような高並行クエリを頻繁に実行する場合は、user_id をソートキーの最初の列にすることを強く推奨します。
クエリが主に集計とスキャンである場合は、低カーディナリティの列をソートキーの最初に配置します。

たとえば、select region, nation, count(*) from lineorder_flat group by region, nation のようなクエリの場合、region を最初の列に、nation を 2 番目の列に設定する方が良いでしょう。

データ型の選択

可能な限り正確なデータ型を使用してください。たとえば、該当する場合は文字列型ではなく整数型を使用し、データ範囲が許す限り BIGINT よりも INT を優先します。正確なデータ型を使用することで、データベースのパフォーマンスが向上します。

Routine Load のパラメーターチューニング

パラメーターチューニング戦略

Routine Load でパフォーマンスの問題が発生した場合は、次のパラメーターのチューニングを検討してください：

タスクスケジューリングサイクル

データ消費を高速化するには、max_batch_interval パラメーターを変更してタスクスケジューリングサイクルを短縮してください。

重要
最小タスクスケジューリングサイクルは 5 秒です。
タスクの並列度

多数のパーティションと BE ノードがある場合、次のパラメーターの値を増やすことでタスクの実行を高速化できます。ただし、並列度を上げると CPU 消費量が増加する可能性があります。
- max_routine_load_task_concurrent_num
- desired_concurrent_number
StarRocks は、単一の Routine Load ジョブを Kafka トピックのパーティション数と利用可能な BE ノード数に基づいて複数のサブタスクに分割します。これらのサブタスクは、実行のために BE に分散されます。タスクの並列度は、ジョブが分割されるサブタスクの数です。
実際のタスクの並列度は、次の式を使用して計算されます。
```
concurrent_num = Min( Min( partition_num, Min( desired_concurrent_num, alive_be_num ) ), Config.max_routine_load_task_concurrent_num )
```
タスクのバッチサイズ
- routine_load_task_consume_second: 1 回の読み取り時間を長くすることで、データ消費を高速化できます。
- max_routine_load_batch_size: 1 回のバッチで読み取るデータ量を増やすことで、データ消費を高速化できます。
現在のバッチサイズパラメーターが低すぎるかどうかを判断するために、次のログを確認できます。通常、このログの left_bytes フィールドの値が 0 以上であれば、1 回のバッチで読み取ったデータ量が max_routine_load_batch_size の制限を超えていないことを示します。負の値は、max_routine_load_batch_size が小さすぎることを示します。
```
I0325 20:27:50.410579 15259 data_consumer_group.cpp:131] consumer group done:
41448fb1a0ca59ad-30e34dabfa7e47a0. consume time(ms)=3261, received rows=179190,
received bytes=9855450, eos: 1, left_time: -261, left_bytes: 514432550, blocking
get time(us): 3065086, blocking put time(us): 24855
1
```

Routine Load のパラメーター

パラメーター	タイプ	デフォルト値	説明
max_routine_load_job_num	fe.conf	100	NEED_SCHEDULE、RUNNING、または PAUSED 状態の Routine Load ジョブの最大数。
max_routine_load_task_concurrent_num	fe.conf	5	単一の Routine Load ジョブの最大並列度。
max_routine_load_task_num_per_be	fe.conf	5	単一の BE ノードでスケジュールできる Routine Load タスクの最大数。
max_routine_load_batch_size	fe.conf	500 MB	1 回のバッチで Kafka から読み取るデータの最大量。
routine_load_task_consume_second	fe.conf	3	1 回のバッチで Kafka からデータを読み取る最大時間。
routine_load_task_timeout_second	fe.conf	15	単一の Routine Load タスクのタイムアウト。
max_consumer_num_per_group	be.conf	3	コンシューマーグループあたりのコンシューマーの最大数。
desired_concurrent_number	properties	3	Routine Load ジョブに期待される並列度。実際の並列度は次の式に基づいて計算されます： `concurrent_num = Min( Min( partition_num, Min(desired_concurrent_number, alive_be_num ) ), Config.max_routine_load_task_concurrent_num )`。
max_batch_interval	properties	10s	Routine Load ジョブのスケジューリング間隔。
max_batch_rows	properties	200000	このパラメーターは、エラー検出ウィンドウのサイズを指定します。ウィンドウサイズは `10 * max_batch_rows` です。
max_error_number	properties	0	サンプリングウィンドウ内で許容されるエラー行の最大数。値は 0 以上である必要があります。デフォルトの 0 は、エラー行を許容しないことを意味します。重要 WHERE 句によってフィルタリングされた行は、エラー行としてカウントされません。
strict_mode	properties	true	strict モードを有効にするかどうかを指定します。デフォルトは true です。strict モードでは、非 NULL のソース列が NULL に変換された場合、行はフィルタリングされます。

データモデルの選択

StarRocks は 4 つのデータモデルを提供します。ユースケースに最も適したものを選択してください：

データモデル	シナリオ
Duplicate Key モデル	データの更新頻度が低い。クエリパターンが柔軟で、事前集計を伴わない。生データを保持する必要がある。
Aggregate Key モデル	データは追加のみで、更新はされない。ビジネスのクエリに MIN、MAX、SUM などの集計関数が含まれる。生の明細データをクエリする必要がない。
Unique Key モデル	頻繁に更新されるデータのリアルタイム分析に最適。
Primary Key モデル	頻繁に更新されるデータのリアルタイム分析に最適。部分的な列更新がある場合は、列の数を 200 未満に保つことを推奨します。

データモデルにおける COUNT 関数

StarRocks は、Duplicate Key モデル、Unique Key モデル、Aggregate Key モデル、Primary Key モデルの 4 つのデータモデルを提供します。COUNT 関数の動作は、これらのモデル間で大きく異なります。

Duplicate Key モデル：このモデルはマージ操作を必要としないため、COUNT 操作は高速です。
Unique Key モデルと Aggregate Key モデル：COUNT の実装には多版マージ操作が含まれるため、比較的低速です。

キーが文字列型の場合、COUNT 操作は理論上、さらに低速になります。
Primary Key モデル：データ読み取り時に、このモデルはインメモリインデックスと削除ベクトルを使用するため、マージ操作が不要です。その結果、COUNT 操作は Unique Key モデルや Aggregate Key モデルよりも高速です。

更新操作を含むワークロードには、このモデルを使用してください。

trash ディレクトリのディスク使用量の削減

/mnt/disk1/starrocks/storage/trash/ ディレクトリには、削除されたデータが格納されます。このディレクトリのディスク使用量を削減するには、be.conf ファイルの trash_file_expire_time_sec パラメーターの値を小さくして、trash ディレクトリの保持期間を短縮できます。デフォルト値は 259200 秒 (72 時間) です。

マテリアライズドビュー作成時のエラー

症状：マテリアライズドビューを作成しようとすると、次のエラーが発生します。

mysql> CREATE MATERIALIZED VIEW test_bl1_mvte AS select timed, event, count(userId) as PV from test_bl1 group by timed, event;
ERROR 1064 (HY000): table [test_bl1] is not stable. Some tablets of this table may not be healthy or are being scheduled. You need to repair the table first or stop cluster balance. See 'help admin;'.
mysql>

解決策：
1. コマンド show proc "/cluster_balance"; と show proc "/statistic"; を実行します。
2. タブレットがリバランス中かどうかを確認してください：
  - タブレットがリバランス中の場合は、プロセスが完了するまで待ちます。
  - そうでない場合は、コマンド set disable_balance=true を実行し、再度マテリアライズドビューの作成を試してください。

低速クエリのトラブルシューティング

以下のトラブルシューティング方法を推奨します：

プロファイルレポートを有効にし、StarRocks UI でプロファイル情報を表示してください。

プロファイルレポートを有効にするには、コマンド SET is_report_success = true; を実行します。
以下の基本的なトラブルシューティング手順に従います：
1. 並列度を調整します。
  - パイプライン
```
SET pipeline_dop = 8;
SET enable_pipeline_engine = true;
```
  - 非パイプラインエンジン
```
SET enable_pipeline_engine=false;
SET parallel_fragment_exec_instance_num=8;
```
2. タブレットの分散を確認します。
```
show data xxx;
```
  説明
  推奨されるタブレットサイズは 1 GB から 10 GB です。
3. テーブル定義を確認します。
  1. プロファイルの iotime を確認します。高い場合は、過剰な数のビットマップインデックスなど、不要なインデックスを削除できます。
  2. テーブルのデータモデルを確認し、適切なものを選択してください。たとえば、Unique Key モデルでは、コンパクションが完了するまで述語プッシュダウンを適用できないため、しばしば低速クエリの原因となります。

ポート 8030 または 8040 でのアクセス失敗

load_url と webserver_port のデフォルトポートは、E-MapReduce (EMR) のバージョンによって異なります。EMR V5.8.0/V3.42.0 以前では、それぞれポート 8030 と 8040 を使用します。EMR V5.9.0/V3.43.0 以降では、ポート 18030 と 18040 を使用します。

説明

show frontends コマンドを実行して、実際に使用されているポートを確認できます。

EMR StarRocks のリージョン提供状況

EMR StarRocks はすべてのリージョンで利用可能です。

BE データディスクとデータ分散

デフォルトでは、4 つの拡張 SSD (ESSD) PL1 クラウドディスクがマウントされます。StarRocks は、負荷、バケット化、その他の要因に基づいて、すべてのノード間でデータを自動的に分散します。各タブレットのレプリカは、単一のディスクに完全に保存されます。

データリカバリのためのクラスターのリセット

重要

以下の操作は、クラスター内のすべてのデータを消去します。注意して進めてください。

クラスターサービス (FE と BE) を停止します。
FE のメタデータディレクトリをクリアします。
1. /opt/apps/STARROCKS/starrocks-current/fe/conf/ ディレクトリにある fe.conf ファイルで、meta_dir に設定されているディレクトリを確認します。
2. 設定されたディレクトリから bdb フォルダーを削除します。
3. 設定されたディレクトリ内の image フォルダーを空にします。
BE のデータとメタデータをクリアします。
1. /opt/apps/STARROCKS/starrocks-current/be/conf/ ディレクトリにある be.conf ファイルを確認し、storage_root_path に設定されているディレクトリを見つけます。
2. 設定されたディレクトリから data と meta フォルダーを除くすべてのフォルダーとファイルを削除します。
3. 設定されたディレクトリ内の data と meta フォルダーを空にします。
説明
設定で複数のパスが指定されている場合があります。各パスに対してこれらの操作を実行する必要があります。
クラスターサービス (FE と BE) を再起動します。

ログの表示

ログディレクトリは通常、以下のパスにあります：

FE
- /opt/apps/STARROCKS/starrocks-current/fe/log/
- /mnt/disk1/log/starrocks/
BE
- /opt/apps/STARROCKS/starrocks-current/be/log/
- /mnt/disk1/log/starrocks/

スケールアウトされたタスクノードが計算に使用されないケース

症状

3 つのタスクノードを追加して StarRocks クラスターをスケールアウトした後、新しいノードはコンピューティングノード (CN) として割り当てられますが、自動的に計算タスクを実行しません。既存の BE ノードは高負荷であるにもかかわらず、新しく追加されたタスクノードは十分に活用されず、モニタリングデータは一貫して低い負荷を示しています。

原因

ストレージとコンピューティングが統合されたアーキテクチャでは、StarRocks クラスターの CN は外部テーブルのクエリにのみ使用できます。したがって、アプリケーションが主に内部テーブルのクエリを伴う場合、BE ノードがこれらのタスクを処理し、新しい CN は十分に活用されません。

解決策

クエリタスクを実行する前に、以下の SQL コマンドを実行して、タスク実行のために CN を優先させてください。

SET GLOBAL prefer_compute_node=true;

StarRocks クラスターのパスワードの表示

StarRocks クラスターのパスワードは、クラスター作成時に root ユーザーに設定したものです。パスワードを忘れた場合は、リセットできます。詳細については、「クラスターのログオンパスワードをリセットするにはどうすればよいですか？」をご参照ください。