プロダクト概要
製品の強み
適用シーン
Spark の計算コスト最適化プラクティス
spaコスト最適化は継続的なプロセスです。ビッグデータの動的かつ変化し続ける性質により、企業ユーザーのコスト最適化活動は継続的に行われるべきです。本記事では、データレイクコンピューティング（DLC）において、Spark計算リソースを基盤としたコスト最適化の関連プラクティスについてご紹介します。提供するユースケースを参考に、必要に応じて最適化をご利用いただけます。
適切な計算リソースの課金方法を選択する方法
データレイクコンピューティング DLC は、従量課金と年額/月額サブスクリプションの2つの支払いモードでエンジンを購入することをサポートしています。
リソース記述 | 従量課金計算リソース | 年間契約計算リソース | 弾力性計算リソース |
費用基準 | 0.35元/CU*時 1CUリソースを1時間使用すると0.35元の料金がかかります。実際に使用したリソースのCU量に応じて課金されます | 150元/CU*月 1CUリソース1か月の費用は150元と表示されます | 0.35元/CU*時 1CUリソースを1時間使用すると0.35元の料金がかかります。実際に使用したリソースのCU量に応じて課金されます |
支払方法 | 後払い | プリペイド | 後払い |
使用特徴 | 1. ユーザーはリソースの使用時間を柔軟に選択できます：従量課金リソースを使用しない場合、リソースをサスペンド（解放）することを選択でき、サスペンド後は課金が継続されません。 2. 従量課金リソースは、ユーザーがクラスタを起動してタスクを実行する際にのみユーザーに割り当てられ、割り当て成功後は当該ユーザーが独占的に利用します；ただし、リソースプールの影響により、リソース不足で従量課金リソースが割り当てられない場合があります。 | 1. リソースは購入後にユーザーに割り当てられ、独占的に利用されます。リソースが割り当てられない状況は発生しません。 2. いつでも利用可能。また、弾力性リソースの追加購入にも対応し、従量課金で利用できます。 | 1. 弾力性計算リソースは、Sparkの年額/月額クラスタを購入したことを基に、追加で従量課金リソースを開通します。 2. 弾力性リソースは、必要な時にタスクの実行速度を向上させ、システム全体の負荷を軽減することができます。また、タスクが少ない時には、弾力性リソースが自動的に解放され、それ以上の課金が発生せず、効果的にコストを削減します。 |
推奨シナリオ | 1. POC テストフェーズ 2. 毎月の使用時間は18日を超えないこと | 1. 本番環境 2. タスク量が多く安定したデータ計算シナリオに適しています 3. 1か月の総時間の60％を超えて使用する場合、年間/月額プランの方がお得です | 1. 本番環境 2. 購入した年額/月額計算リソースでタスクを実行すると、タスクの完了時間が期待通りになりません |
支払方法の切り替えに対応していますか | はい | いいえ | いいえ |
シナリオ：年額/月額計算リソースが不足しているため、タスクの完了時間が期待通りになりません
あるECプラットフォームは、600の分析タスクが当日に実行され結果が返されることを保証するために、128CUの年額/月額計算リソースを購入しました。
EC大促の到来に伴い、データ量が急増し、この期間におけるタスクの完了時間を保証できなくなっていることが判明しました。分析の結果、現在購入しているリソースが大促期間のデータ処理需要を満たせず、タスクが待機状態になり、進捗が遅れることが問題であるとわかりました。この状況に対し、企業は、短期的にタスクの期限通り完了を保証しつつ、コストを合理的な範囲内に抑えることができるソリューションを求めています。
推奨ソリューション：
大促期間中、128CUの年額/月額リソースに加えて、さらに128CUの弾力的な計算リソースを追加購入し、タスクの負荷状況に応じて、年額/月額の128CUがすべて使用されている場合に弾力リソースの実行をトリガーし、実行効率を向上させます。大促終了後、弾力機能をオフにすることで、コスト投入を効果的にコントロールします。
タスク量が少ない場合：従量課金の弾力リソースは自動的に解放され、それ以上の課金が発生せず、コストを効果的に削減します。
タスク量が多い場合：従量課金の弾力リソースは必要な時にタスクの実行速度を向上させ、使用した分だけ費用が発生します。
開通手順：
1. エンジンリストページに移動し、従量課金エンジンに弾力計算リソースを設定する必要があることを確認します。
2. 操作バーで「その他」をクリックし、仕様設定を選択します。
3. 弾力計算リソーススイッチをオンにし、弾力構成仕様を選択します。
注意：
弾力計算仕様のサイズは従量課金の仕様を超えることはできません。
4. 大規模プロモーション終了後、通常のタスク実行に戻り、仕様構成をクリックして弾力クラスター機能をオフにすることができます。
計算リソースの割り当てを合理的に計画する方法
方法1：複数のエンジンを通じて計算リソースを割り当てる
複数の計算リソースを購入し、異なるユーザーグループまたは機能シナリオに割り当てることで、各計算リソースが独立してタスクを実行できます。
強み | 異なるエンジン間のリソースは完全に分離されており、現在のユーザーグループが独占します。異なるユーザーグループ間の設定、管理、タスク、および障害は互いに影響しません。 |
適用シーン | 1. 複数の部門がプラットフォームを使用する必要がありますが、互いの間に業務の重複はなく、主に独立した業務分析シナリオです。 2. コスト監査やセキュリティ運用に高い要件を持つ企業。 |
制限事項 | リソースにはアイドル時間が発生する可能性があり、活用が最大化されない場合があります。例えば、ユーザーグループ01は主にSQL分析を行い、午前9時から午後5時までの間にリソースを使用し、それ以外の時間はリソースがアイドル状態になります。 解決方法：コンピューティングリソースを従量課金リソースに調整し、リソース割り当て方法を調整します。 |
方法2：1つのエンジンがリソースグループを通じてリソースを割り当てます
このモードでは、すべてのユーザーグループまたは機能シナリオが同じエンジンを使用しますが、各ユーザーは異なるリソースグループを設定してリソース割り当てを行います。
強み | 計算リソースの利用を最大化することができます。 |
適用シーン | 1. コスト管理に高い要件を持つ。 2. 設定する必要があるリソースグループの数は多くなく、主に線形起動タスクであり、同時実行タスクは少ないです。 3. 各タスクの実行時間はあまり重ならず、重なるタスクの計算リソース消費量もリソース総量を超えません。 |
制限事項 | 異なるリソースグループ間でリソース競合が発生する可能性があります。例えば、3人のユーザーが同時に利用している場合、ユーザー1が256CUのリソースを占有し、ユーザー2も256CUのリソースを占有すると、エンジンレベルで利用可能なすべてのリソースが占有されるため、ユーザー3にはリソースが割り当てられず、タスクを実行できなくなります。 解決方法：コンピューティングリソースを増やし、リソースグループの構成と割り当て方法を調整します。 |
シーン：タスクの時間分割実行を適切に計画することで、リソース利用を最大化します。
ある企業が現在、3つの部門に計算リソースを割り当てるために購入する必要があり、それぞれが対話型SQL分析とSparkバッチジョブタスクを実行する必要があります。企業には高いコスト管理の要件があるため、営業チームが合理的な購入プランの提案を行うことを希望しています。リソース利用を最大化することを前提に、3つの部門にリソースを適切に割り当てることができ、かつタスクが失敗する状況が発生しないようにする必要があります。
推奨ソリューション：
1. インタラクティブSQLタスクに対しては、毎日実行する必要があるタスクの数と複雑さに基づいて、インタラクティブリソースグループの実行時間、最小リソース量、および弾力性を評価する必要があります。
該部門は分析の結果、毎日9時から17時にインタラクティブSQLを実行し、SQLタスクの最大同時実行数とリソース要求量に基づいて、このリソースグループに必要な最大スペックは128CUであると判断しました。リソース使用量は4CU～128CUに設定可能です。なお、4CUはリソースグループの最小リソース値となります。
2. ジョブタスクに対しては、タスクの実行効率に基づいて必要なリソースを評価する必要があります。
例えば、この企業では、部門Bに毎時間1回実行されるスケジュールタスクがあります。現在の時間内に実行を完了させるには、少なくとも128CUのリソースを使用する必要がある場合、ジョブのリソースを4CU〜128CUに設定することができます。
部門Cにも毎日1回実行するタスクがあり、深夜に実行するだけでよいが、朝8時までに実行を完了する必要があり、256CUのリソースが必要です。
ここで発見：
部門AとBのタスク時間が重複しているため、エンジンの最大リソースは128 + 128 = 256CUに設定する必要があります。
部門Bと部門Cのタスク時間も重複しているため、タスクを時間通りに完了させるために、最大リソースを128 + 256 = 384CUに設定する必要があります。
販売は毎日の稼働時間の使用状況に基づいて確認し、「128CU年間/月額プラン + 128CU従量課金」のリソース購入提案を提示しました。
コスト追跡の方法
方法1：コストトラッキングを実現するための分割勘定
以下のように：エンジンに異なるタグを付けることで、タグAではエンジン1、2のコスト統計を確認でき、タグBではエンジン3のコストを確認でき、タグCではエンジン2、3のコスト統計を確認できます。
方法2：タスクのインサイト機能でコスト追跡を実現
説明：
1. CU消費*時：計算に使用されるSpark Executorの各コアのCPU実行時間の合計、単位は時間。
2. このリソース消費量は、タスクが実際に占有したリソースによって発生した消費量であり、リソースの起動やリソースグループのアイドル時間などの統計は含まれていません。そのため、この値はリソースグループの総消費量よりもはるかに小さく、課金側のデータと完全に一致することはありません。この消費量は、単一のタスクが実際に使用したリソース量を分析し、単一のタスクの最適化や使用量に基づくコスト分析などに使用することをお勧めします。
タスクガバナンスを通じてタスクの完了効率を向上させ、コスト最適化を達成する方法
データレイクコンピューティング DLC インサイト管理は、視覚的で直感的なインターフェースを提供し、現在のクエリパフォーマンスとパフォーマンスに影響を与える潜在的な要因を迅速に把握し、パフォーマンス最適化の提案を得るのに役立ちます。詳細については、タスクインサイトを参照してください。
適用シーン | 1. Sparkエンジンの全体的な稼働状況に関する洞察分析、例えば：エンジン下の各タスク実行時のリソース競合状況、エンジン内のリソース使用状況、エンジン実行時間、データスキャンサイズ、データシャッフルサイズなどが直感的に表示・分析されます。 2. 自己でタスクの実行状況を分析し、問題を特定できます。例えば、多くのタスクを所要時間でフィルタリングして並べ替え、問題のある大きなタスクをすばやく見つけることができます。Sparkタスクの実行が遅い、または失敗した原因（リソースの競合、shuffleの異常、ディスク不足など）を明確に特定できます。 |
重点指標 | 1. エンジン実行時間：Sparkエンジンが最初のタスクを実行した時間（つまり、タスクが初めてCPUを奪取し実行を開始した時間）。 2. エンジン内実行時間：Sparkタスクの最初のタスクの実行開始からタスク終了までの、実際の計算に要した時間を反映します。 3. キューイング時間：タスクが提出されてから最初のSparkタスクの実行が開始されるまでの時間。この時間には、エンジンの初回実行時のコールドスタート時間、タスクの同時実行数の上限設定によるキューイング時間、エンジン内でリソースが不足しているためexecutorリソースを待つ時間、リソースグループがリソースを割り当てられないことによるキューイング時間などが含まれる可能性があります。 4. CU * 時間の消費：計算に参加したSpark Executorの各コアのCPU実行時間の合計を統計し、単位はCU*時間です。 |
シナリオ1：タスクの問題を自動分析し、問題を迅速に特定し、タスクの実行効率を向上させます
タスクの品質にばらつきがあり、多数のタスクの運用が困難なため、クラスタリソースの利用率が低下しています。
タスクの実行が遅くなる主な要因は、データの偏り、シャッフルの並列性不足、テールタスクによる全体の実行時間の遅延などです。データレイクコンピューティングDLCのタスクインサイト機能を使用すると、タスク実行中に発生する問題の一部を分析し、最適化案を提案できます。時間が限られている場合は、まず大きなタスクに優先的に取り組むことで、より良い最適化効果を得られます。
1. 例えば、エンジンの実行時間でソート（または消費CU*時間でソート）して、問題のあるタスクをフィルタリングします。
2. 例えば、Sparkのshuffle段階はタスクの実行速度とクラスター全体の安定性に影響する重要な要素であり、大規模なshuffleデータ量を持つタスクに対して的を絞った最適化を行うと効果が顕著です。具体的な操作：タスクのshuffleサイズでソートし、shuffle異常タスクをフィルタリングできます（成功したタスク内でもshuffleの失敗と再試行が発生する場合があります）、または上位の大規模shuffleタスクを重点的に最適化することで、クラスター全体のリソース消費に対する効果も良好です。
以下の指標に重点的に注目できます：
洞察タイプ | アルゴリズムの説明（継続的に改善および新規アルゴリズムを追加中） |
リソースの占有 | sqlの実行を開始したタスクの遅延時間がステージの提出時間を1分超える場合、または遅延時間が総実行時間の20%を超える場合（異なる実行時間とデータ量のタスクに対して、閾値の計算式は動的に調整されます） |
シャッフル異常 | ステージ実行時にシャッフル関連のエラースタック情報が発生しました |
遅いタスク | ステージ内のタスクの所要時間 > ステージ内の他のタスクの平均所要時間の2倍（異なる実行時間とデータ量のタスクに対して、閾値の式は動的に調整されます） |
データの偏り | タスクシャッフルデータ > タスク平均シャッフルデータサイズの2倍（異なる実行時間とデータ量のタスクに対して、閾値式は動的に調整されます） |
ディスクまたはメモリ不足 | ステージ実行エラースタック情報にoomまたはディスク不足の情報、またはcos帯域幅制限エラーが含まれています |
多くの小ファイルを出力する | （この洞察タイプの収集には、Sparkエンジンカーネルを2024.11.16以降のバージョンにアップグレードする必要があります） 参照リストの指標「出力小ファイル数」は、以下のいずれかの条件を満たす場合「多くの小ファイルが出力されている」と判定されます： 1. パーティションテーブルで、あるパーティションに書き込まれた小ファイルが200個を超える場合 2. 非パーティションテーブルで、出力される小ファイルの総数が1000個を超える場合 3. パーティションまたは非パーティションテーブルで、書き出されるファイルが3000個を超え、平均ファイルサイズが4MB未満の場合 |
シナリオ2：エンジンの洞察を通じて、リソースの競合状況を迅速に分析し、タスクの実行数を適切に調整することで、タスクの実行効率を向上させます
実行が遅いことは、計算自体が遅いことを意味するわけではありません。クラスターリソースが限られている状況では、タスクが互いにリソースを奪い合う可能性があります。インサイト管理機能を活用し、エンジン内の実行時間と待機時間の2つの指標を参考に、互いに影響し合うタスクを特定した上で、タスクの待機スケジューリングを適切に調整することが重要です。
例えば以下の図のように、タスクを提出しても、エンジンが必ずしも実行を開始するとは限りません。タスクの提出から最初のSparkタスクの実行開始までの間には、エンジンの初回実行時のコールドスタート時間、タスクの同時実行上限設定による待ち時間、エンジン内でリソースが満杯になったことによるexecutorリソースの待ち時間、Spark実行プランの生成と最適化にかかる時間などが含まれる可能性があります。
クラスタリソースが不足している場合、このような初期のリソース待機時間がより顕著になります。
同時に、タスクインサイトはリソースの競合を自動的に検出する機能もサポートしており、以下の図の通りです。また、そのタスクと並行して実行されている他のタスクがリソースを奪い合っているかどうかを確認できます。
フィードバック