この記事について
- この記事はIBMが提供する製品に関する情報やナレッジを共有する Advent Calendar 2024の12月12日分として記載しています。
実施概要
- 対象データベースはSnowflake（Azure/東京）の「SNOWFLAKE_SAMPLE_DATA」を使用します
- 「SF10」「SF100」各スキーマから、「REGION」「NATION」「CUSTOMER」「ORDERS」テーブルを引っこ抜いてJOINしてフィルタリングするフローをDatastageに実行させます
- どの程度のデータ量で、どの程度の処理時間がかかるのかを測ってみます
- Datastage は、IBMCloudの東京リージョン上のOpenshiftに建てたCloud Pak for Data v5.0.3 上のコンテナソフトウェアを使用しています
スキーマ「SF10」の場合
処理対象
-
スキーマ「SF10」
- 「REGION」:5行、4.0KB
- 「NATION」:25行、4.0KB
- 「CUSTOMER」:1.5M（150万）行、103.2MB
- 「ORDERS」:15M（1500万）行、425.8MB
-
最もレコード件数が多いテーブルが「ORDERS」
- 件数：1千500万行
- データサイズ：425.8MB
Snowflake側の設定
- Computeはデフォルトの「COMPUTE-WH」(X-Smallサイズ)を使用
Datastage側の設定
- ランタイムは、デフォルト（Small）設定
Snowflake の結果
-
最大で8秒足らずという感じでした
-
ORDERSテーブルの場合のSQLはこちら
Datastage の結果
フロー
ジョブ（時間）
- 最大1千500万行のデータを含めて、3分足らずで処理終了しました
スキーマ「SF100」の場合
処理対象
-
スキーマ「SF100」
- 「REGION」:5行、4.0KB
- 「NATION」:25行、4.0KB
- 「CUSTOMER」:15M（1500万）行、1.0GB
- 「ORDERS」:150M（1億5千万）行、4.3GB
-
最もレコード件数が多いテーブルが「ORDERS」
- 件数：1億5千万行
- データサイズ：4.3GB
Snowflake側の設定
- Computeはデフォルトの「COMPUTE-WH」(X-Smallサイズ)を使用
Datastage側の設定
- ランタイムは、デフォルト（Small）設定
Snowflake の結果
-
各テーブル、1秒もかからずという感じでした
- （この前にも数回試していたため、キャッシュが効いて早かったのかもしれません）
- （この前にも数回試していたため、キャッシュが効いて早かったのかもしれません）
-
ORDERSテーブルの場合のSQLはこちら
Datastage の結果
フロー
ジョブ（時間）
- 最大1億5千万行のデータを含めて、約25分程度で処理終了しました
スキーマ「SF1000」の場合
処理対象
-
スキーマ「SF10」
- 「REGION」:5行、4.0KB
- 「NATION」:25行、4.0KB
- 「CUSTOMER」:150M（1億5千万）行、10.1GB
- 「ORDERS」:1.5B（15億）行、48.6GB
-
最もレコード件数が多いテーブルが「ORDERS」
- 件数：1.5B（15億）行
- データサイズ：48.6GB
以下、実験中。。。結果はお待ち下さい！