こんにちは、データアナリティクス事業本部ビジネスソリューション部SAチームの渡部です。
InformaticaのCloud Data Integration(以降、CDI)のマッピングで、こんな悩みにぶちあたったことはありませんか？
- 処理時間が長すぎる
- キャッシュファイルが大量に生成されてサーバーのストレージを使い切って停止してしまう
- ベストプラクティスは知っているけど、なぜこの設定をしているのかわからない
もし上記のお悩みが一つでもあてはまれば、本記事が参考になるかもしれません。
今回はCDIの推奨設定について、実践的なものを4つピックアップしてご紹介いたします。
ご紹介する設定4選
- JoinerにおけるDetailとMaster
- Sorted Input
- SQL ELT Optimization
- 使用しないフィールドの削除
設定の解説
JoinerにおけるDetailとMaster
まずは1つ目。
JoinerトランスフォーメーションにおけるDetailとMasterの繋ぎ方についてです。
よく考えずに上流（ソース側）から繋げている方もいるかと思うのですが、こちらの繋ぎ方でパフォーマンスが変わります。
その理由は、Masterに繋げた側のレコードがキャッシュとして作成され、キャッシュベースでDetail側のレコードと比較するからです。
Joinerトランスフォーメーションの動きとしては、Master側の全レコードがキャッシュされ、キャッシュレコードのキーをベースにDetail側のレコードと比較する、というものです。
したがってMaster側のレコードで結合キーの一意な数が少なければ、その分比較数も減り処理時間が減るというわけです。
またキャッシュが作成されすぎてしまう場合にも、上記のDetailとMasterのリンクを確認してみてください。
結論、以下になります。
- 結合したいテーブルのレコード数を見て、少ない方をMaster側、多い方をDetail側にリンクする
なおCDIの前身のPowerCenterでは、未ソートとソート済みのレコード同士の結合でのDetail側とMaster側の繋ぎ方について、より詳細な情報が公式ドキュメントに記載があります。
CDIもPowerCenterと同様の動きなのかはCDIの公式ドキュメントに記載がないため紹介しませんが、ご参考にして頂けたらと思います。
Sorted Input
次に2つ目。
JoinerやAggregater、Lookupで設定ができるSorted Inputについてです。
結合キーや集約キーがソート済みである場合に設定する設定で、大規模なデータセットの際に設定するとパフォーマンスが向上します。
その理由は結合にしろ、集約にしろ、ソートされていないと全行比較をしてしまうからです。
例えば集約であれば、集約キーが未ソートであれば全行スキャンするまで集約計算することができません。
最終行を見るまで集約グループが揃っているかわからないからです。
対してソート済みであれば、集約キーが変わったところで集約計算を実施できるのでスキャン量が変わります。
結果として処理時間が削減されるということです。
注意点としてはSorted Inputを設定するのに事前にソートが必要になるのですが、処理行数が少ないとソートトランスフォーメーションを配置する方が処理が遅くなってしまう場合があることです。
そのためソーストランスフォーメーションでソートを行ったり、Sorted InputのオンオフでIFの想定処理行数を用いた処理時間比較を実施するとよいでしょう。
外部環境でも変わるので明確には言えませんが、数十万行ほどであれば使用を考えるといいかと思います。
結論、以下になります。
- 大規模データセットの場合は、Sorted Inputを使用する
SQL ELT Optimization
折り返しの3つ目。
データベースに処理を任せるSQL ELT Optimizationです。
聞き慣れない名前かもしれませんが、2023年の11月にPushdown Optimizationから名称変更されました。
マッピングタスクで設定することができます。
こちらの設定は上記で記載の通り、SecureAgentに処理をさせる代わりにデータベースに処理をさせる設定です。
ネットワークトラフィックの軽減や、データベースで演算をさせることで処理の高速化が望めます。
複雑な処理や設定の場合は、データベース側に処理を渡すことが不可能な場合や逆に遅くなる場合もありますが、大抵の場合は処理が高速化するのでおすすめです。
注意点としてはSQL ELT Optimizationは100万行の処理あたり0.048IPUを消費するということです（2023年10月時点）。
IPUとはInformaticaで処理をさせた分消費する事前購入のプリペイド単位のことです。
CDIの処理では1時間あたり0.16IPU消費するため、SQL ELT Optimizationを使用するとその分IPUを追加で消費する必要があります。
そのためSQL ELT Optimizationを使用する場合は、処理時間を短縮したい要件がある場合などで損益分岐点を意識して設定すればいいかと思います。
結論、以下になります。
- 処理時間を短縮したい場合にSQL ELT Optimizationを設定する（IPU消費に注意）
使用していないフィールドの削除
最後の4つ目。
ターゲットや途中処理で使用していない項目は、フィールドを削除しましょうということです。
SQLでは当たり前のように使用する項目だけのSELECTができているのですが、
対してInformaticaでは全項目SELECTが当たり前となっているケースが多いです。
複雑な処理や結合がある場合に全項目全行を持つというのは非常にメモリ・キャッシュを使用します。
ソーストランスフォーメーションでフィールド削除で処理のダイエットをさせましょう。
ただし実際は全IFでフィールドを削除するのは何気に大変です。
開発スピードを意識するのであれば、複雑な結合を使用していたり、想定処理行数が多かったり、実際に運用中であれば処理時間が多くかかっていたりするIFにのみに対して実施してみるのも良いかなと思います。
フィールド削除の手順は、
ソーストランスフォーメーションでリンクパスを確認して、IFで使用していないフィールドを削除するでいいでしょう。
結論、以下になります。
- 使用していないフィールドは削除する
まとめ
4つパフォーマンス良化の設定についてご紹介いたしました。
まだまだパフォーマンス良化の方法はあるので、もしご興味があればこちらのInformaticaナレッジベースをご参考ください。
以上です、ありがとうございました！
2
