非常に大きなデータを安価かつ迅速に移動、アップロード、統合するにはどうすればよいでしょうか? プッシュダウンの最適化とは何ですか?

ビッグデータの操作には大量のコンピューティング能力が必要です。 データベースから Hadoop へのデータの通常の移動には数週間かかることもあれば、飛行機の翼と同じくらいの費用がかかることもあります。 待ってお金を使いたくないですか？ さまざまなプラットフォーム間で負荷のバランスをとります。 XNUMX つの方法はプッシュダウンの最適化です。

Informatica 製品の開発と管理を担当するロシアの第一人者トレーナーである Alexey Ananyev に、Informatica Big Data Management (BDM) のプッシュダウン最適化機能について話を聞いてみました。 Informatica 製品の使い方を学んだことがありますか? おそらく、PowerCenter の基本を説明し、マッピングの構築方法を説明したのは Alexey だったでしょう。

アレクセイ・アナニエフ氏、DISグループトレーニング責任者

プッシュダウンとは何ですか？

Informatica Big Data Management (BDM) については、すでにご存知の方も多いと思います。 この製品は、さまざまなソースからのビッグ データを統合し、異なるシステム間でビッグ データを移動し、簡単にアクセスし、プロファイリングを行うことができます。
適切な使い方をすれば、BDM は驚異的な効果を発揮します。タスクは最小限のコンピューティング リソースで迅速に完了します。

あなたもそれが欲しいですか？ BDM のプッシュダウン機能を使用して、さまざまなプラットフォーム間でコンピューティング負荷を分散する方法を学びます。 プッシュダウン テクノロジーを使用すると、マッピングをスクリプトに変換し、このスクリプトが実行される環境を選択できます。 この選択により、さまざまなプラットフォームの長所を組み合わせて、最大のパフォーマンスを実現できます。

スクリプト実行環境を設定するには、プッシュダウンタイプを選択する必要があります。 スクリプトは、Hadoop 上で完全に実行することも、ソースとシンクの間で部分的に分散することもできます。 可能なプッシュダウン タイプは 4 つあります。 マッピングをスクリプト (ネイティブ) に変換する必要はありません。 マッピングは、可能な限りソース上で実行することも (ソース)、完全にソース上で実行することもできます (フル)。 マッピングを Hadoop スクリプトに変換することもできます (なし)。

プッシュダウンの最適化

リストされた 4 つのタイプはさまざまな方法で組み合わせることができ、システムの特定のニーズに合わせてプッシュダウンを最適化できます。 たとえば、多くの場合、独自の機能を使用してデータベースからデータを抽出する方が適切です。 また、データベース自体に過負荷がかからないように、データは Hadoop を使用して変換されます。

ソースと宛先の両方がデータベース内にあり、変換実行プラットフォームを選択できる場合を考えてみましょう。設定に応じて、Informatica、データベース サーバー、または Hadoop になります。 このような例により、このメカニズムの動作の技術的側面を最も正確に理解することができます。 当然のことながら、現実にはこのような状況は起こりませんが、機能を実証するのに最適です。

単一の Oracle データベース内の XNUMX つのテーブルを読み取るマッピングを考えてみましょう。 そして、読み取り結果を同じデータベース内のテーブルに記録させます。 マッピングスキームは次のようになります。

Informatica BDM 10.2.1 でのマッピングの形式は次のようになります。

プッシュダウンタイプ – ネイティブ

プッシュダウンネイティブタイプを選択すると、マッピングは Informatica サーバー上で実行されます。 データは Oracle サーバーから読み取られ、Informatica サーバーに転送され、そこで変換されて Hadoop に転送されます。 つまり、通常の ETL プロセスが得られます。

プッシュダウンタイプ - ソース

ソース タイプを選択すると、データベース サーバー (DB) と Hadoop の間でプロセスを分散する機会が得られます。 この設定でプロセスが実行されると、テーブルからデータを取得するリクエストがデータベースに送信されます。 残りは Hadoop 上のステップの形で実行されます。
実行図は次のようになります。

以下に実行環境のセットアップ例を示します。

この場合、マッピングは XNUMX つのステップで実行されます。 その設定では、ソースに送信されるスクリプトに変わっていることがわかります。 さらに、テーブルの結合とデータの変換は、ソース上でオーバーライドされたクエリの形式で実行されます。
下の図では、BDM 上の最適化されたマッピングと、ソース上の再定義されたクエリが示されています。

この構成における Hadoop の役割は、データ フローの管理、つまりデータのオーケストレーションに縮小されます。 クエリの結果は Hadoop に送信されます。 読み取りが完了すると、Hadoop からのファイルがシンクに書き込まれます。

プッシュダウンタイプ – フル

完全なタイプを選択すると、マッピングは完全にデータベース クエリに変わります。 そして、リクエストの結果は Hadoop に送信されます。 このようなプロセスの図を以下に示します。

設定例を以下に示します。

その結果、前のものと同様の最適化されたマッピングが得られます。 唯一の違いは、すべてのロジックが挿入をオーバーライドする形で受信機に転送されることです。 最適化されたマッピングの例を以下に示します。

ここでも、前のケースと同様に、Hadoop がコンダクターの役割を果たします。 ただし、ここではソース全体が読み取られ、データ処理ロジックが受信機レベルで実行されます。

プッシュダウンタイプがnullです

最後のオプションはプッシュダウン タイプで、マッピングが Hadoop スクリプトに変わります。

最適化されたマッピングは次のようになります。

ここでは、ソース ファイルのデータがまず Hadoop で読み取られます。 次に、独自の手段を使用して、これら XNUMX つのファイルを結合します。 この後、データは変換され、データベースにアップロードされます。

プッシュダウン最適化の原理を理解することで、ビッグ データを扱うための多くのプロセスを非常に効果的に編成できます。 そのため、つい最近、ある大企業が、数年間にわたって収集していたビッグデータをストレージから Hadoop にダウンロードしました。

出所： habr.com