共有エンジンと専有エンジンの違いは何ですか？
|
共有エンジン | 現在の地域のすべてのユーザーが共同で使用するエンジン | 従量課金：スキャン量に応じて課金され、使用しない場合は一切費用が発生しません | 1. 設定不要で使用可能 2. データ量が少なく、一時的なデータ計算シナリオに適しています。 |
専有エンジン | ユーザー専有のエンジンリソース | 従量課金：CU量に応じて課金され、タスクがない場合はクラスターを一時停止でき、一時停止中は一切の費用が発生しません | 1. リソース専有、リソース規模の設定をサポートし、弾力的にスケーリング可能 2. 一定のタスク量があるが、タスク周期が不規則なデータ計算シナリオに適しています。 |
|
| 年決め・月決め課金：CU量に応じて課金され、クラスターは待機時間なしでいつでも利用可能。弾力的な部分は従量課金。 | 1. リソース専有、リソース規模の設定をサポートし、弾力的にスケーリング可能 2. タスク量が多く安定したデータ計算シナリオに適しています。 |
1つのクラスタで、どのくらいのタスクを並行してサポートできますか？調整可能ですか？
1つのクラスターで、タスクの並列数は5です。調整が必要な場合は、データエンジン機能で変更するエンジンを選択し、仕様設定をクリックして調整できます。 なぜタスクの実際の使用CUコア数がエンジンのクラスター規模で指定されたCUコア数よりも少なくなるのですか？
以下の状況は、実際に使用されるCUコア数がエンジンのクラスター規模で指定されたCU数よりも少なくなる可能性があります：
1. クラスター内で他のタスクが実行中です。
2. バッチジョブクラスタに指定されたドライバリソースとエグゼキュータリソースの合計がクラスタ規模より小さいです。
3. 従量課金クラスターは、使用時にのみリソースの申請が行われ、CUコア数が多い場合、申請したCU数を完全に満たすリソースが確保できない場合があります。
4. バッチ処理ジョブは、他のVPCネットワークと接続するために拡張型ネットワーク構成を指定していますが、他のVPCネットワークのIP数がすべてのexecutorを起動するのに十分ではありません。
DLCクラスターは同じリージョンの他のVPCのIP/サービスにアクセスできますか？また、外部ネットワークにアクセスできますか？
DLCエンジンは同じリージョン内の他のVPCにアクセスできますが、データエンジン > ネットワーク構成でネットワーク構成を作成し、ターゲットVPCと接続する必要があります。また、バッチ処理ジョブでそのネットワーク構成を使用するように指定する必要があります。DLCエンジンはデフォルトでは外部ネットワークにアクセスできません。ただし、拡張型ネットワーク構成を使用し、かつターゲットVPCが外部ネットワークにアクセスできるルールを設定している場合、DLCは拡張型ネットワーク構成を介して外部ネットワークにアクセスできます。 クラスターの自動起動・停止時間を変更する方法は？
データエンジン機能で、エンジンリストから変更したいエンジン名をクリックし、編集ページに移動して起動・停止ポリシー設定をクリックして変更します。
タスク実行中にクラスターの構成変更を行った場合、タスクは失敗しますか？
以下のエンジンタイプにおいて、タスク実行中に構成変更を行った場合のタスクへの影響をまとめましたので、ご参照ください：
|
SuperSQL-Sparkジョブ | 従量課金 | タスクは影響を受けません |
| 年決め・月決め課金 | クラスタ仕様の変更を開始すると クラスタの拡張はタスクに影響しません クラスタの縮小では、プロセス中にpodの実行が終了するのを待ってから、縮小対象のマシンを隔離/破棄します。タスクの実行時間が長い場合、プロセスが停滞してタスクが再起動される可能性があります。 |
SuperSQL-SparkSQL | 従量課金 | クラスタ仕様の変更を開始すると、タスクが再起動されます |
| 年決め・月決め課金 | クラスタ仕様の変更またはクラスタ数の削減を開始すると、タスクが再起動されます |
SuperSQL-Presto | 従量課金 | クラスタ仕様の変更を開始すると、タスクが再起動されます |
| 年決め・月決め課金 | クラスタ仕様の変更またはクラスタ数の削減を開始すると、タスクが再起動されます |
標準エンジンで実行中のタスクが長時間正常に実行されない原因をどのように調査しますか？
タスクが長時間「初期化中」、「起動中」、または「待機中」の状態にある場合、タスクが正常に実行されない可能性があります。以下の手順とタスクタイプに従って、問題の原因を段階的に調査し、迅速に問題を特定して解決するのに役立ててください。
1. サブタスクタイプを区別する
手順：履歴タスクインスタンス > 履歴タスクリスト > タスクタイプ、リソースグループ名、タスクタイプとリソースグループ名に値があるかどうかでサブタスクタイプを区別します。
|
SQL タスク | SQL | リソースグループ名に値があります |
インタラクティブSQLタスク | SQL | リソースグループ名に値がありません（--） |
Spark バッチストリームタスク | ジョブ | リソースグループ名に値がありません（--） |
2. SQL タスクのトラブルシューティング手順
2.1 エンジンとゲートウェイの状態を判断する
1. エンジンリストに入り、エンジンの状態が「実行中」または「準備完了」であることを確認してください。
2. 管理ページでゲートウェイの状態を確認し、ゲートウェイが「実行中」かどうかを確認します。
3. エンジンまたはゲートウェイの状態が異常な場合、他のプロセスが実行中であることを示しています。プロセスが終了するまでお待ちください。
4. 状態が10分以上回復しない場合は、チケットを提出して技術サポートに連絡してください。 2.2 計算リソースがコールドスタート状態にあるかどうかを判断する
1. タスクが保留状態のリソースグループに送信された場合、リソースグループが起動中である可能性があり、通常3～5分かかります。
2. リソースグループページに移動し、リソースグループのステータスが「起動中」かどうかを確認してください。
3. 5分以上経っても起動しない場合は、他の原因を引き続き調査してください。
4. リソースグループのステータスが「実行中」または「起動中」でない場合、リソースグループが他の操作を実行中であることを示します。しばらくお待ちください。10分以上経っても回復しない場合は、チケットを提出してください。 2.3 リソースグループに十分なリソースが割り当てられているかどうか
1. リソースグループの起動が10分以上経っても成功しない場合、エンジンリソースが占有されている可能性があり、リソースグループに十分なリソースが割り当てられないことがあります。
2. リソースグループリストでリソース要件（CU数など）を確認し、リソースグループの最低必要リソースを確認します。
3. エンジンリストでエンジン名をクリックし、「クラスタ監視」でリソース使用状況を確認します。
4. 「使用済みクラスタ仕様」が総仕様に達した場合、残りリソースが不足し、リソースグループを起動できません。
5. 解決策：他のリソースを解放します（他のリソースグループまたはバッチ/ストリームジョブタスクを一時停止またはキャンセルします）。
2.4 依存タスクの完了を待ちますか
1. DLCはデフォルトで一度に送信された複数のSQLタスクを逐次実行し、前のタスクが完了していない場合、後続のタスクは初期化状態になります。
2. 依存タスクが未完了でキューイングされているかどうかを確認してください。
2.5 リソースグループのタスク同時実行数の上限に達しているかどうか
1. リソースグループのデフォルトのタスク同時実行数の上限は5です。
2. 同時実行数を超えたタスクはキューイング状態になります。
3. リソースグループの詳細ページで同時実行数の設定を確認し、必要に応じて調整できます。
4. 履歴タスクインスタンスページで現在実行中のタスク数を確認し、上限に達しているかどうかを確認します。
3. インタラクティブ SQL タスク（BatchSQL タスク）のトラブルシューティング手順
3.1 エンジンとゲートウェイの状態を判断する
3.2 リソースが十分かどうかを判断する
1. エンジンリストの「クラスタモニタリング」でリソース使用状況を確認できます。
2. リソースが不足している場合、タスクは起動できません。
3. SQLタスクと同様の解決策で、他のリソースの占有を解放します。
3.3 コールドスタート時間
インタラクティブSQLタスクは毎回の提出で新しいリソースを起動する必要があり、コールドスタート時間は通常3～5分です。
5分以上経っても起動しない場合は、異常がないか調査してください。
4. Spark バッチストリームジョブの調査手順
4.1 エンジンとゲートウェイの状態を判断する
2. リソースの起動には通常3～5分かかります。待機後も実行されない場合は、引き続き調査を行ってください。
4.2 エンジンリソースが十分かどうかを判断する
1. 履歴タスクインスタンスページでタスクに必要なリソース（DriverおよびExecutorのCU数）を確認します。
2. エンジンリストの「クラスタモニタリング」でリソース使用状況を確認できます。
3. リソースが不足している場合、バッチストリームジョブを起動できません。
4. SQLタスクと同様の解決策で、他のリソースの占有を解放します。