Pentaho Kettle のアーキテクチャはどこですか?

Question

Pentaho Kettle のアーキテクチャはどこで見つかりますか?私は、物事がどのように機能するかについての概要を説明するための短い Wiki、設計ドキュメント、ブログ投稿などを探しています。この質問は、特定の「ハウツー」の開始ガイドを目的としたものではなく、テクノロジーと 建築.

具体的な質問は次のとおりです。

1. データはステップ間でどのように流れるのでしょうか?すべてがメモリ内にあるように思えますが、これは正しいでしょうか?
2. 上記はさまざまな変換にも当てはまりますか?
3. 調子はどうですか 集める 実装された手順は？
4. それを使用する際の具体的なパフォーマンスのガイドラインはありますか?
5. FTP タスクは信頼性とパフォーマンスに優れていますか?
6. 他に「やってはいけないこと」はありますか？

Answer 1

を参照してください。このPDF でます。

Answer 2

1. データはステップ間でどのように流れるのでしょうか?すべてがうまくいっているようだ。 記憶 - これは正しいのだろうか？

データ フローは行ベースです。変換では、各ステップで「タプル」またはフィールドを含む行が生成されます。すべてのフィールドはデータとメタデータのペアです。すべてのステップには入力と出力があります。ステップは入力から行を取得し、行を変更して、行を出力に送信します。ほとんどの場合、すべての情報はメモリ内にあります。しかし。Steps はストリーミング形式 (jdbc など) でデータを読み取ります。そのため、通常はストリームからのデータの一部のみがメモリ内にあります。

2. 上記はさまざまな変換にも当てはまりますか?

「ジョブ」の概念と「変革」の概念があります。上に書いたことはすべて、変換に関してほぼ当てはまります。ほとんどの場合、変換には非常に異なるステップが含まれる可能性があり、収集ステップなどの一部のステップでは、ストリームからすべてのデータを収集しようとする可能性があります。ジョブ - 成功時に電子メールを送信する、ネットからいくつかのファイルをロードする、異なる変換を 1 つずつ実行するなど、「ストリーミング」の概念に従わないいくつかのアクションを実行する方法です。

3. 収集ステップはどのように実装されますか?

それは特定のステップにのみ依存します。通常、上で述べたように、収集ステップはストリームからすべてのデータを収集しようとする可能性があり、これが OutOfMemory 例外の原因となる可能性があります。データが大きすぎる場合は、「収集」ステップを別のデータ処理アプローチに置き換えることを検討してください (たとえば、すべてのデータを収集しないステップを使用するなど)。

4. それを使用する際の具体的なパフォーマンスのガイドラインはありますか?

たくさんの。変換の構成手順、使用されるデータ ソースによって異なります。一般的なガイドラインではなく、正確なシナリオに基づいて話したいと思います。

5. FTP タスクは信頼性とパフォーマンスに優れていますか?

私が覚えている限り、ftp は EdtFTP 実装によってサポートされており、その手順でいくつかの問題が発生する可能性があります。たとえば、一部のパラメーターが保存されない、http-ftp プロキシが機能しないなどです。Kettle は一般的に信頼性が高く、パフォーマンスが高いと思いますが、一般的に使用されない一部のシナリオでは、そうでない場合もあります。

6. 他に「やってはいけないこと」はありますか？

やるべきことは、ツールを集中的に使用し始める前にツールを理解することです。このディスカッションで述べたように、Kettle/Pentaho データ統合に関する文献がいくつかあります。特定のサイトで検索してみてください。

Pentaho Data Integration/Kettle の利点の 1 つは、特定の側面について質問できる比較的大きなコミュニティです。

http://forums.pentaho.com/

https://help.pentaho.com/Documentation