E-MapReduce:よくある質問

ハードウェア要件

• 全体的なマシン構成

  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 という式を使用してバケット数を計算します。

バケット数が少なすぎるテーブルの診断

テーブルのクエリまたはインポートのパフォーマンスが低い場合は、バケット数が少なすぎないかを確認します。information_schema.partitions_meta テーブルにクエリを実行して、各パーティションのバケット数を表示します：

SELECT buckets, count(*) FROM information_schema.partitions_meta WHERE buckets < 4 GROUP BY buckets;

このクエリは、バケット数が 4 未満のパーティションをバケット数でグループ化して返すため、バケット数が少なすぎるテーブルを特定できます。

既存テーブルのバケット数の調整

StarRocks は、既存のテーブルのバケット数を直接変更することはできません。バケット数を調整するには、目的のバケット数で新しいテーブルを作成し、古いテーブルから新しいテーブルにデータを移行します：

CREATE TABLE ... DISTRIBUTED BY HASH(...) BUCKETS 8;
INSERT INTO <new_table> SELECT * FROM <old_table>;

ソートキーの設計

データ型の選択

可能な限り最も正確なデータ型を使用してください。例えば、適用可能であれば文字列型の代わりに整数型を使用し、データ範囲が許す限り BIGINT よりも INT を優先します。正確なデータ型を使用すると、データベースのパフォーマンスが向上します。

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

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

Routine Load パラメータ

データモデルの選択

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

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 モデルでは、コンパクションが完了するまで述語プッシュダウンを適用できないため、低速クエリの原因となることがよくあります。

query_timeout パラメータの設定

query_timeout パラメータは、クエリのタイムアウト時間を秒単位で制御します。デフォルト値は 300 秒です。

• セッションレベルで設定するには、次のステートメントを実行してください。この設定は現在の接続にのみ適用され、切断すると失われます。ステートメントとクエリは同じセッションで実行してください。

  SET query_timeout = 1800;

• グローバルに設定するには、次のステートメントを実行してください。このステートメントには ADMIN 権限が必要です。新しいセッションはこの設定を継承しますが、既存のセッションは設定を有効にするために再接続する必要があります。

  SET GLOBAL query_timeout = 600;

設定が有効にならない場合のトラブルシューティング

1. SET ステートメントとクエリを同じ接続で実行していることを確認してください。セッションレベルの設定は現在の接続にのみ適用され、再接続後には再度設定する必要があります。

2. グローバル設定を変更した後は、新しいセッションを作成するか、再接続してください。既存のセッションは新しい設定を自動的に継承しません。

3. グローバル設定に対する ADMIN 権限があることを確認し、権限不足のために SET GLOBAL ステートメントが失敗していないかを確認してください。

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

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

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

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

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

データ復旧のためのクラスターのリセット

1. クラスターサービス (FE と BE) を停止してください。

2. FE メタデータディレクトリをクリアしてください。

   1. /opt/apps/STARROCKS/starrocks-current/fe/conf/ ディレクトリにある fe.conf ファイルを確認し、meta_dir に設定されているディレクトリを特定してください。

   2. 設定されたディレクトリから bdb フォルダーを削除してください。

   3. 設定されたディレクトリ内の image フォルダーを空にしてください。

3. BE のデータとメタデータをクリアしてください。

   1. /opt/apps/STARROCKS/starrocks-current/be/conf/ ディレクトリにある be.conf ファイルを確認し、storage_root_path に設定されているディレクトリを特定してください。

   2. 設定されたディレクトリから、data フォルダーと meta フォルダーを除くすべてのフォルダーとファイルを削除してください。

   3. 設定されたディレクトリ内の data フォルダーと meta フォルダーを空にしてください。

   説明

   設定には複数のパスが指定されている場合があります。各パスに対してこれらの操作を実行する必要があります。

4. クラスターサービス (FE と BE) を再起動してください。

ログの表示

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

現象

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

原因

コンピューティング・ストレージ統合アーキテクチャでは、StarRocks クラスター内の CN は、デフォルトで外部テーブルのクエリにのみ使用されます。内部テーブルのクエリは BE ノードで処理されるため、アプリケーションが主に内部テーブルのクエリで構成されている場合、新しく追加された CN は十分に活用されません。

ソリューション

クエリタスクを実行する前に、次の SQL コマンドを実行することで、タスク実行にCNが優先されるようになります。

SET GLOBAL prefer_compute_node=true;

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

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