はじめに
こんにちは、データアナリティクス事業本部の渡部です。
みなさんはインフォマティカのCloud Data Integration(以降、CDI)において、コスト最適な機能選択ができているでしょうか？
もしかするとCDIの機能、SQL ELT Optimizationを使用することでIPUを今以上に最適化できるかもしれません。
今回はSQL ELT Optimizationについて、IPU消費の観点からまとめてみました。
ちなみに私はSQL ELT OptimizationをELTモードと呼んでいます。
今回お話することを簡単に
SQL ELT Optimizationを有効/無効でIPU消費体系が異なります。
- ELT有効：書き込み行数でのIPU消費
- ELT無効：処理時間でのIPU消費
SQL ELT Optimizationって？
SQL ELT Optimizationは、一言でいうとデータ連携処理をデータベースに任せたデータ連携になります。
通常EC2で稼働しているSecureAgentにデータ連携処理をさせるところ、例えばDWHであるRedshiftやBigQuery、Snowflakeに処理を任せます。
SQL ELT Optimizationについては以前、DWHの強力な処理能力にデータ処理を任せることができ、パフォーマンスUPをさせることが可能とお話しました。
IPU消費体系
IPU消費体系の最新版はこちらをご覧ください。
今回のブログは2024/06/17時点の情報をもとに記載します。
基本的にすべてのサービスにおける、IPU消費の計算式は以下になります。
消費IPU = (Metric単位でのScaler使用量) * IPU Per Metric Unit
SQL ELT Optimizationがオフの場合
SQL ELT Optimizationがオフ、つまりSecure Agentでの処理によるIPU消費は以下のとおりです。
処理時間でのIPU消費となります。
- Scaler: Compute Units
- Metric: Per Hour
- IPU Per Metric Unit:
- 0.16 for the first 2,000 Hours
- 0.025 for > 2,000 Hours
簡易版のIPU消費の計算式は以下になります。
消費IPU = ジョブの処理時間(h) * IPU Per Metric Unit
例えばジョブが１０時間稼働したとしたら、1.6IPUを消費します。
詳細のCDIのIPU消費の計算式としては、こちらをご覧ください。
上記リンクには以下のとおり詳細な計算が記載されていますが、Max( # of cores used by the job / 4 , 1)は多くの場合1となります。そのため簡易版として上述の計算式を記載しています。
消費IPU = Job Execution Time * { Max( # of cores used by the job / 4 , 1) } * IPU Per Metric Unit
IPU Per Metric Unitには、2段階ありますが、上からTier1、Tier2と呼称します。
各Tierで定義された使用量を超過すると、割引されるというIPU消費体系となっています。
なおランタイム環境には、Serverless Runtimeもありますが、今回は触れません。
SQL ELT Optimizationがオンの場合
SQL ELT Optimizationをオンにした場合のIPU消費は以下のとおりです。
ターゲットへの書き込み行数でのIPU消費となります。
- Scaler: Rows Processed
- Metric: Per Million Rows
- IPU Per Metric Unit:
- 0.048 for the first 100M Rows
- 0.010 for 100M - 10B Rows
- 0.002 for > 10B Rows
こちらのIPU消費の計算式は以下になります。
消費IPU = ( 書き込み行数 / 100万行 ) * IPU Per Metric Unit
例えばRedshiftに50万行を書き込んだ際は、0.028IPUを消費します。
請求期間中にSQL ELT Optimizationで書き込んだ行数が1億行を超えた際は、Tier2のIPU Per Metric Unitが適用されるので、
同じく50万行を書き込んだ際は、0.005IPUの消費に変わります。
まとめる
SQL ELT Optimizationがオフ/オンの場合の、同じIPU消費量におけるScaler使用量をまとめました。
1レコード目が、SQL ELT Optimizationがオフ/Tier1で1時間稼働させたときに消費されるIPU(0.16IPU)あたりの、それぞれの設定における消費Scaler量を並べ、
2レコード目が、1IPUあたりのそれぞれの設定における消費Scaler量を並べています（単位が万行と億行で混ぜたのは、こちらの方がわかりやすいかなと思った次第です）。
この表を参考にしつつ、SQL ELT Optimizationを使用するかどうかを決めていくことで、コスト最適に繋がります。
具体的にはSQL ELT Optimizationを使うかどうかは、そのジョブ1日における合計処理時間と合計処理行数の比較をもって決めれば良いかと思いました。
例えば、普段1時間以上かかっている日次ジョブがあって、書き込み行数が数百万行の場合は、ELTモードの方がIPU・パフォーマンス観点で最適化されます。
対して、シンプルな日次データ連携ジョブがあって、毎回TruncateInsertで書き込み行数が全件数千万行の場合は、ELTモードをオフとすると、IPUが最適化されます。
ただSQL ELT Optimizationを有効化について、個人的に強力だと思うのは、書き込み行数が0の場合はIPUが発生しないということです。
これを活かすために、差分処理などを実装してデータ書き込み数を抑えることが重要です。
例えば日次より高頻度にデータ連携をしたい場合には、差分処理の作り込みをしてデータ書き込み行数を少なくすれば、必要最低限のIPU消費で済むというわけです。
さいごに
最後に簡単にSQL ELT Optimizationの使い所をまとめます。
- 単純にデータ連携行数が少ない場合
- 高頻度でデータ連携したく、かつ各回のデータ連携行数がそこまで多くない場合
- SecureAgentでの処理が長期化している場合（パフォーマンス観点も）
なお今回は触れませんでしたが、左から右のようなデータ加工がないデータ連携については、Mass Ingestionというサービスがあります。
こちらもSQL ELT Optimizationと同じく、データサイズによるIPU消費体系である部分が多いので、使用を検討すると良いと思います。
以上です。
どなたかの参考になれば幸いです。
注意点
さいごに、とまとめたのですが、注意点を思い出したので追加記載します。
それはCDIの関数とDWHなどの関数で挙動が違うものがあるので注意が必要であるということです。
例えばCONCAT関数なのですが、Nullと文字列を文字結合する場合は、CDIは文字列が出力されるのに対して、RedshiftはNullが出力されます。
そのため既存ジョブのSQL ELT Optimizationへの変更は、関数には要注意です。
11
