AnalyticDB for MySQL Data Lakehouse Edition (V3.0) では、SQLエディターまたはJava Database Connectivity (JDBC) を使用して、XIHE一括同期パラレル (BSP) SQLジョブを送信できます。 このトピックでは、XIHE BSP SQL開発の適用可能なシナリオ、送信方法、および構成パラメーターについて説明し、よくある質問に対する回答を提供します。
前提条件
ジョブのリソースグループがAnalyticDB for MySQL Data Lakehouse Edition (V3.0) クラスターに作成されます。 詳細については、「」をご参照ください。
AnalyticDB for MySQL Data Lakehouse Edition (V3.0) クラスター用にデータベースアカウントが作成されます。
Alibaba Cloudアカウントを使用する場合は、特権アカウントを作成する必要があります。 詳細については、「データベースアカウントの作成」トピックの「特権アカウントの作成」セクションをご参照ください。
RAM (Resource Access Management) ユーザーを使用する場合は、特権アカウントと標準アカウントの両方を作成し、標準アカウントをRAMユーザーに関連付ける必要があります。 詳細については、「データベースアカウントの作成」および「データベースアカウントの関連付けまたは関連付けの解除」をご参照ください。
シナリオ
XIHE BSP SQLジョブは、XIHE BSPエンジンを使用して実行されます。 XIHE BSP SQLの開発は、ETL (extract-transform-load) ジョブ、大規模クエリ、およびバースト低優先度クエリに適しています。 XIHE BSPエンジンの詳細については、関数と機能のトピックの「計算エンジン」セクションを参照してください。
ETLジョブ
次の図は、典型的なETLプロセスを示しています。
ほとんどの場合、データソースからアプリケーションデータサービス (ADS) 層へのETLプロセス中に実行されるデータクレンジングやデータ変換などの操作には、大量のデータが含まれ、完了するまでに長時間が必要になります。 ETLジョブの場合、応答速度は大きな問題ではありませんが、システムは信頼性を確保するために自動再試行などの機能を提供する必要があります。 XIHE BSPエンジンは、その高いスループット、信頼性、およびコスト効率のために理想的な選択肢です。
ETLジョブが完了すると、データアプリケーションはADSレイヤーからデータをクエリできます。これには、第2レベルまたはミリ秒レベルの応答時間が必要になる場合があります。 この場合、より高速なXIHE超並列処理 (MPP) エンジンの方が適しています。
大規模なクエリ
XIHE MPPモードでは、大きなクエリでメモリ不足 (OOM) エラーまたはクエリ例外が発生する可能性があります。 リソースのスケールアップはこれらの問題を解決できますが、費用対効果は高くありません。 この場合、XIHE BSPエンジンを使用して、ジョブリソースグループで大きなクエリを実行できます。 クエリの中間結果をディスクにキャッシュすることで信頼性が高くなり、オンデマンドのリソース要求と課金によるコスト効率が向上します。
低優先度クエリのバースト
優先度の低いクエリを高速で返す必要はありません。 しかしながら、低優先度クエリが突然大量に提出されると、システムは、クエリのための十分なリソースを有していない可能性がある。 その結果、他のクエリの実行が影響を受ける可能性がある。 これらの問題を解決するには、XIHE BSPエンジンを使用して、ジョブリソースグループでこれらのクエリを実行します。
制限事項
XIHE BSPモードでHudiテーブルを書き込むことはできません。
XIHE BSPモードでは、Deltaテーブルの読み書きはできません。
XIHE BSPジョブを開発する
次のいずれかの方法を使用して、XIHE BSPジョブを開発できます。
SQLエディターを使用してXIHE BSPジョブを送信する
JDBCまたはMySQLクライアントを使用してXIHE BSPジョブを同期的に送信する
JDBCまたはMySQLクライアントを使用してXIHE BSPジョブを非同期で送信する
XIHE BSPジョブの設定
リソースの量、タイムアウト期間、優先度など、XIHE BSPジョブのパラメーターを設定できます。
設定方法
BSPジョブ設定は、単一のジョブ、単一のジョブリソースグループ内のすべてのジョブ、またはクラスター内のすべてのジョブに対して有効になります。
単一の仕事のために有効
単一のジョブに対してBSPジョブ設定を有効にするには、/* + resource_group=<resource_group_name >,< config_name>*/ ヒントをSQL文に追加します。
ヒントで、resource_group_nameはリソースグループの名前を指定します。 config_nameの詳細については、このトピックの「設定パラメーター」セクションのパラメーター列を参照してください。
例: ジョブリソースグループbsptestで実行されるジョブに使用可能なリソースを最大20個のAnalyticDBコンピューティングユニット (ACU) で設定します。
/* + resource_group=bsptest,elastic_job_max_acu=20 */SELECT count(*) from test_db.ods_hudi;ジョブリソースグループ内で有効
ジョブリソースグループ内のすべてのジョブに対してBSPジョブ設定を有効にするには、SET adb_config <resource_group_name>.<config_name> ステートメントを実行します。
ヒントで、resource_group_nameはリソースグループの名前を指定します。 config_nameの詳細については、このトピックの「設定パラメーター」セクションのパラメーター列を参照してください。
例: ジョブリソースグループbsptestで実行されるジョブごとに、最大20 ACUの使用可能なリソースを設定します。
SET adb_config bsptest.elastic_job_max_acu=20;設定が有効かどうかの確認
リソースグループ内のすべてのジョブに対して設定が有効かどうかを確認するには、SHOW ADB_CONFIG KEY=<resource_group_name>.<config_name> ステートメントを実行します。
クラスター内で有効
クラスタ内のすべてのジョブに対してBSPジョブ設定を有効にするには、SET adb_config <config_name> ステートメントを実行します。 config_nameの詳細については、このトピックの「設定パラメーター」セクションのパラメーター列を参照してください。
例: クラスター内で実行されるジョブごとに、最大20 ACUの使用可能なリソースを設定します。
SET adb_config elastic_job_max_acu=20;設定が有効かどうかの確認
クラスター内のすべてのジョブに対して設定が有効かどうかを確認するには、SHOW ADB_CONFIG KEY=<config_name> ステートメントを実行します。
設定パラメーター
次の表に、XIHE BSPジョブ用に設定できるパラメーターを示します。
カテゴリ | パラメーター | 説明 | デフォルト値 |
Resources |
| AppMasterノードとコンピュートノードのXIHE BSPジョブごとに使用できるACUの最大数。 このパラメーターの値は、リソースグループの最大コンピューティングリソースに指定されているACUの数を超えることはできません。 説明 AppMasterノードは、クエリの解析、スケジューリング、および実行を担当します。 | 9 |
タイムアウト時間 |
| BSPジョブのタイムアウト期間。 単位:ミリ秒。 このパラメーターの値より長い期間BSPジョブが実行された場合、ジョブは自動的にキャンセルされます。 | 7200000 |
優先度 |
| BSPジョブの優先度。 有効な値: HIGH、NORMAL、LOW、LOWEST。 優先キューの詳細については、「ジョブリソースグループの優先キュー」をご参照ください。 | NORMAL |
よくある質問
BSPジョブのステータスを確認するにはどうすればよいですか?
SQLエディターを使用してBSPジョブを送信する場合は、 を選択し、実行レコード タブをクリックしてジョブのステータスを表示できます。
SQLエディターを使用せずにBSPジョブを送信する場合、次のステートメントを実行して、
information_schema.kepler_meta_elastic_job_listテーブルからジョブのステータスを照会できます。SELECTステータスFROM information_schema.kepler_meta_elastic_job_list WHERE process_id='<job_id>';説明information_schema.kepler_meta_elastic_job_listテーブルには、過去30日以内に送信された最大1,000のBSPジョブが格納されます。 テーブルに対してGROUP BY集計など、さらに統計と分析を実行できます。 次のサンプルステートメントは、各状態のBSPジョブ数を照会する方法を示しています。SELECTステータス, count(*) FROM information_schema.kepler_meta_elastic_job_list GROUP BYステータス;
BSPジョブを同期または非同期に送信するかどうかを判断するにはどうすればよいですか?
同期送信と非同期送信の唯一の違いは、クライアントがクエリの実行が完了するのを待つ必要があるかどうかです。
非同期送信には次の制限があります。
結果セットには、最大10,000行のデータを含めることができます。
システムは、CSVファイルのダウンロードURLを含む最大1,000の結果セットを最大30日間保持できます。
大量の計算能力を消費し、完了までに長時間を要するが、小さな結果セットを返すクエリに対しては、BSPジョブを非同期に送信することを推奨します。 例: INSERT INTO SELECT、INSERT OVERWRITE SELECT、およびCREATE TABLE AS SELECT。