SAP BW/4HANAのパフォーマンスチューニング実践ガイド：クエリとデータロードを高速化する方法

01SAP BW/4HANAの性能問題を切り分ける

SAP BW/4HANAの性能改善は、クエリ、データロード、データモデル、基盤リソースを分けて測定することから始めます。利用者から「遅い」という報告を受けたら、対象のクエリ名、実行時刻、選択条件、処理時間、同時実行数を記録します。ロード処理の場合は、開始・終了時刻、データ量、パッケージ数、エラーや再実行の有無を確認します。

最初に確認するのは、遅延が常に発生するのか、特定の時間帯だけ発生するのかです。特定の時間帯に集中する場合は、プロセスチェーン、データロード、クエリ、集計処理の重複をタイムラインに並べます。単一の処理だけを見ず、同時実行の関係を確認すると、CPUやメモリの競合を見つけやすくなります。

SAP BW/4HANAの全体像や主要オブジェクトを先に整理する場合は、SAP BW/4HANAの概要を参照してください。

02測定データをそろえる

改善前後を比較できるように、同じ選択条件と同じデータ状態で測定します。クエリでは、初回実行と2回目以降の実行を分けて記録し、ナビゲーション、データ取得、フロントエンド表示のどこに時間がかかっているかを確認します。ロードでは、抽出、変換、書き込み、後処理を分けて測定します。

測定結果には、処理時間だけでなく、レコード数、パッケージ数、並列度、対象データ期間、デルタ処理の有無も含めます。データ量が増えた結果として時間が延びたのか、同じデータ量で処理効率が落ちたのかを分離するためです。

運用監視では、SAP BW/4HANA側のプロセスチェーン履歴と、SAP HANA側のCPU、メモリ、ディスクI/O、SQL実行状況を同じ時刻で比較します。アプリケーション処理だけでなく、データベースの負荷とOSのリソース状況を合わせて見ることが重要です。

03ADSOのデータ構造を確認する

ADSOは、データを受け入れる層、履歴を保持する層、レポートに提供する層で役割を分けます。ひとつのADSOに大量の履歴、頻繁な更新、クエリ提供のすべてを集中させると、ロードと参照が互いに影響しやすくなります。

ADSOの設計では、キー項目、粒度、更新方式、データ保持期間を確認します。キーが実際の業務粒度と一致していない場合、更新処理や重複排除の負荷が増加します。不要な項目を広く保持すると、ロード時の書き込み量とクエリ時の読み取り量も増えます。

ADSOの構造、更新、データフローを見直すときは、SAP BW/4HANAのAdvanced DSOも合わせて確認します。データを受け入れるADSOと、レポート用に参照されるADSOを分けると、ロード時間とクエリ応答時間を個別に改善しやすくなります。

04CompositeProviderとクエリを軽量化する

CompositeProviderは複数のプロバイダーを統合できる一方、不要な結合や広いデータ範囲の読み取りを発生させることがあります。利用していないプロバイダーや項目を確認し、モデル上必要な接続だけを残します。複数のプロバイダーが同じデータを重複して提供していないかも確認します。

クエリの高速化では、最初に選択条件を見直します。期間、会社コード、地域、製品など、データ量を大きく絞れる条件を適切に設計し、初期表示で不要な明細を取得しないようにします。広い範囲のドリルダウンや大量の自由特性を初期表示に置くと、利用者が意図しないデータ取得が発生します。

計算項目、例外集計、条件、階層展開は、クエリ応答時間に影響します。複雑な計算を何度も実行する設計では、可能な処理をデータフロー側へ移し、クエリでは参照に集中させます。集計レベルと利用パターンが合っているかを、実際のクエリ実行履歴で判断します。

統合モデルの結合やプロバイダー構成を見直す場合は、SAP BW/4HANA CompositeProviderの設計を参照してください。クエリの改善では、利用者が必要とする分析粒度を保ちながら、読み取るデータ量を減らすことが基本です。

05データロードを高速化する

データロードの性能は、抽出元、転送、変換、ADSOへの書き込み、後処理の合計で決まります。各段階の所要時間を分けて測定し、最も長い段階から改善します。変換処理が短くても、抽出元の応答やターゲットへの書き込みが遅ければ、全体の処理時間は短くなりません。

デルタロードでは、毎回取得するデータ量を適切に制御します。変更されていないデータを繰り返し転送すると、ネットワーク、変換、書き込みのすべてに余分な負荷がかかります。フルロードを実行する場合は、業務時間帯との重複、後続チェーン、対象期間を事前に確認します。

パッケージ分割は、ひとつの処理が長時間ロックされる状況や、失敗時の再実行範囲を小さくするのに役立ちます。ただし、パッケージ数を増やしすぎると、管理処理や並列実行のオーバーヘッドが増えます。実行時間とリソース使用率を測定し、処理量に合う分割を選びます。

変換で複雑なルックアップや行単位の処理が多い場合は、処理をデータベース側で実行できる設計へ整理します。変換ロジックの見直しには、SAP BW/4HANAのTransformationを参照してください。

06パーティション戦略を見直す

大規模な時系列データでは、期間を軸にしたパーティションが有効です。クエリが特定期間だけを参照する場合、対象パーティションを絞りやすくなり、読み取り量を削減できます。業務上の検索条件とパーティションキーが一致しているかを確認します。

パーティションは数を増やせばよいものではありません。小さすぎるパーティションが大量に存在すると、管理やメタデータ処理の負荷が増えます。反対に、ひとつのパーティションが大きすぎると、データ削除、ロード、メンテナンスの単位が大きくなります。年間、月、会計期間などの候補を、データ量とアクセスパターンで比較します。

現在のデータ分布、期間ごとのレコード数、ロード頻度、保持期間を確認してから設計を変更します。変更後は、代表的なクエリとロードを同じ条件で再測定し、応答時間だけでなく、CPU、メモリ、I/Oの変化も記録します。

07プロセスチェーンの実行を整理する

プロセスチェーンは、依存関係を保ちながら不要な直列実行を減らします。独立して実行できる処理を同時化すると、全体の完了時刻を短縮できる場合があります。ただし、同じADSOや同じ抽出元へ同時にアクセスする処理は、競合によって遅くなることがあります。

チェーンでは、ロード、アクティベーション、データ削除、インデックスや集計に関係する後処理の順序を確認します。各ステップの開始・終了時刻を比較し、毎回時間がかかるステップと、特定条件でだけ遅いステップを分けます。

失敗時にチェーン全体を最初から再実行する設計は、重複処理とリソース消費を招きます。再実行可能な単位を明確にし、成功済みのステップを繰り返さない運用にします。チェーン履歴を定期的に確認する場合は、SAP BW/4HANAのプロセスチェーン運用を参照してください。

08改善変更を安全に検証する

性能改善では、一度に複数の設計を変更せず、変更対象を限定します。たとえば、クエリの選択条件、CompositeProviderの構成、ADSOのデータ保持、パーティション設計を別々に検証します。変更と結果の対応が明確になり、問題が発生した場合の切り戻しも容易になります。

検証用の基準値には、平均時間だけでなく、最長時間、同時実行時の時間、ロード完了時刻、失敗率を含めます。キャッシュの影響を分けるため、初回実行と反復実行を記録します。少量データだけで改善を判断せず、本番に近いデータ量と選択条件で確認します。

改善後も、クエリ処理時間、プロセスチェーンの完了時間、データ量、エラー件数を継続的に監視します。データ量や利用パターンが変わると、現在有効な設計も再評価が必要になります。性能管理を定例作業に組み込み、問題が利用者へ広がる前に傾向を把握します。