DataStageにおけるELT実体化ポリシー

最終更新: 2025年3月12日

DataStageのELT実体化ポリシー

マテリアライズ・ポリシーは、ELT モードで DataStage フローを実行するときに中間データ用に作成されるデータベース成果物 (ビューまたは表) の数とタイプを定義します。選択されたポリシーは、実行パフォーマンスおよび中間データ・ボリュームに影響を与えます。 ELT モードでの実行では DBTが使用されるため、ELT マテリアライズ・ポリシーは DBT マテリアライズとオーバーラップします。フローの出力コネクターの設定を構成して、ターゲット・データ・セットの実体化を定義します。 table action = replace でターゲットデータセットが再作成されると、デフォルトの DBT マテリアライゼーションテーブルとしてマテリアライズされます。一方、table action = append では、挿入、更新、削除など、DataStage, でサポートされるさまざまな書き込みモードを実装するカスタム DBT マテリアライゼーションが使用されます。

ネストされた SQL の生成

「ネストされた SQL の生成」は、デフォルトのマテリアライズ・ポリシーです。これを選択すると、フローは出力表ごとに個別の SQL ステートメントを作成します。各ステートメントには、出力表のすべてのアップストリーム・ノードに対するネストされた SQL ステートメントが含まれています。このアプローチは、すべての最適化作業をデータベース・エンジンに委任します。

Nested Query マテリアライズ・ポリシーは、通常、中間データベース成果物の作成を回避します。これにより、クリーンアップが簡素化され、障害が発生した場合の実行後の残りの処理が回避されます。入力コネクターがカスタム SQL ステートメントを使用する場合、リレーショナル代数モデルを作成できないため、ネストはできません。この場合、中間ビューを生成するポリシーを選択する必要があります。そうしないと、中間データはマテリアライズされません。

場合によっては、このポリシーでフローのパフォーマンスが低下することがあります。多数の同じアップストリーム・ステージを共有する複数の出力コネクターがあるフローでは、各出力コネクターに対して生成される SQL ステートメントには、データベースによって複数回実行される同じロジックが含まれます。この反復実行を回避するために、 「拡張」 ポリシーをお勧めします。

拡張

「拡張」マテリアライズ・ポリシーは、出力データの作成時に反復計算を回避するために、データ・カーディナリティーまたはカーディナリティー・チェンジャーを変更する一連の接続ノードに対して単一の SQL ステートメントを作成します。以下の図は、これらのノードがどのように結合されるかを示しています。

計算の繰り返しを回避するために、接続されたノードのセットを結合する方法を示す例。 — 図1：拡張実体化の例

カーディナリティー・チェンジャーとして定義されたステージは、単一のデータベース成果物にグループ化されます。その成果物の SQL ステートメントには、カーディナリティー・チェンジャーとそのアップストリーム・ステージのステートメントが含まれています。フロー内の他のステージは、単純な SELECT ステートメントを使用し、グループ化されません。

このポリシーは、 「ネストされた SQL の生成」と同様に実行されますが、フローのステージ当たりのリンク数の平均が高い場合は、他のポリシーよりもパフォーマンスが優れています。

ビューとしてリンク

フローのすべてのリンクはビューとしてマテリアライズされ、実行後に中間データが削除されます。

表としてリンク

フローのすべてのリンクは表としてマテリアライズされ、中間データは実行後に削除されます。このポリシーは、 「ネストされた SQL の生成」 と同様に実行されます。これは、データベース・エンジンが出力表を作成するときに内部最適化アルゴリズムを適用するためです。中間データの照会のパフォーマンスへの影響は、 「ビューとしてリンク」の場合よりも少なくなります。