ルックアップを処理
tMap内で異なるデータソースの間に結合([Inner Join] (内部結合)と[Left Outer Join] (左外部結合)を含む)を実装する時は、常にメインフローが1つだけあり、tMapに接続された1つ(または複数)のルックアップフローがあります。ルックアップフローのレコードはすべて、メインフローの各レコードを処理する前にロードする必要があります。ビジネス要件とパフォーマンスニーズに合わせて、[Load once] (一括ロード)、[Reload at each row] (行ごとにリロード)、[Reload at each row (cache)] (行ごとにリロード - キャッシュ)という3種類のルックアップロードモデルが提供されています。
- [Load once] (一括ロード): [Store temp data] (一時データ格納)オプションがTrueに設定されている場合、メインフローの各レコードを処理する前に、メモリ内またはローカルファイル内のルックアップフローから、すべてのレコードを1回で(1回限り)ロードします。これがデフォルト設定です。ルックアップフローへの結合を使用して処理するメインフローの中に大きなレコードのセットがある場合には、これが優先オプションとなります。
[Reload at each row] (行ごとにリロード): メインフローのレコードごとにルックアップフローの全レコードをロードします。各メインフローレコードに対してルックアップフローが繰り返しロードされるため、一般にこのオプションではジョブ実行時間が長くなります。ただし、このオプションは以下の状況では優先されます。
- ルックアップデータフローが絶えずアップデートされる状況にあり、メインフローの各レコードのために最新のルックアップデータをロードして、結合実行後に最新のデータを取得したい。
- ルックアップフロー内のデータベーステーブルからのデータが大量である一方で、メインフローからのデータは非常に少ない。この場合、[Load once] (一括ロード)オプションを使用するとOutOfMemory例外が発生するおそれがあります。このオプションを使うと、Where句などの動的変数設定を使用して、メインフローの結合処理前にルックアップフローをロードしオンザフライでアップデートできます。例については、[Reload at each row] (行ごとにリロード)をご覧ください。
Spark Streamingジョブでの[Reload at each row] (行ごとにリロード)は、ルックアップ入力コンポーネント(tMongoDBLookupInputなど)でのみサポートされています。
[Reload at each row (cache)] (行ごとにリロード - キャッシュ): [Reload at each row] (行ごとにリロード)モデルと同じように機能し、ルックアップフローのすべてのレコードはメインフローの各レコードのためにロードされます。ただし、このモデルは[Store temp data on disk] (一時データをディスクへ保管)オプションには使用できません。ルックアップデータはメモリにキャッシュされており、新たなロードが発生すると、キャッシュにまだ入っていないレコードのみがロードされます。これは、同じレコードを2度ロードすることを避けるためです。このオプションは処理時間を最適化し、tMapコンポーネントの処理パフォーマンスを改善するのに役立ちます。[Reload at each row (cache)] (行ごとにリロード - キャッシュ)と[Store temp data] (一時データの格納)を同時に使用することはできません。
Spark Streamingジョブでの[Reload at each row (cache)] (行(キャッシュ)ごとにリロード)は、ルックアップ入力コンポーネント(tMongoDBLookupInputなど)でのみサポートされています。
データベーステーブルのルックアップの場合、ジョブデザインの開始時にデータベース接続を開いておくことがパフォーマンス最適化のためのベストプラクティスとなります。