1

次の使用例に基づいて、ペンタホ ツールは動的な変換を実現するためにどの程度柔軟ですか?

  1. ユーザーは、カタログから最初の選択を行う必要があります。(Web インターフェイスを使用)

  2. 以前に選択したアイテムに基づいて、ユーザーは別のカタログから選択する必要があります (この 2 番目のカタログは、最初の選択に基づいてフィルター処理する必要があります)。

ステップ 1 と 2 は、場合によっては繰り返されることがあります (つまり、3 つ以上の動的パラメータと従属パラメータ)。

  1. ステップ 1 と 2 でユーザーが選択したものから、ETL はデータベースから情報を抽出する必要があります。データを選択するテーブルは、ユーザーが前の手順で何を選択したかによって異なります。ほとんどのテーブルの構造は似ていますが、選択したアイテムに基づいて名前が異なります。一部のテーブルは構造が異なり、ユーザーはステップ 1 の選択に基づいて、ステップ 2 でフィールドを選択できる必要があります。

  2. ユーザーが行ったすべての選択は保存できる必要があるため、ユーザーは将来選択を繰り返す必要はなく、プロセスを再実行して、事前に選択されたフィルターに基づいて更新された情報を取得するだけです。ただし、別のパラメーターが必要な場合は、別の選択を行い、それを保存して後で使用できるようにする必要があります。

ユーザーがこのすべての選択をベースにできるようにする Web ベースのツールはありますか? コンソールでプロセスを実行するときにすべてのパラメーターを渡す必要があるため、動的ではなくケトルを使用してプロセス全体を作成しました。問題は、エンド ユーザーは、表示して選択させない限り、すべてのパラメーター値を知ることはできず、一部のパラメーターは以前の選択に依存するということです。テスト時には、テスト ケース シナリオのパラメーターを使用できるので問題ありませんが、本番環境では、ユーザーがどの組み合わせを選択するかを事前に知る方法はありません。

同様の質問を見つけましたが、変換ステップ間でユーザー入力を必要としないようです。

前述のユース ケースを実現するための Pentaho ツールの機能についてコメントをいただければ幸いです。

4

2 に答える 2

1

ここでの他の答えには同意しません。CDE を使用すると、提案されたプロンプトを簡単に実行するフロント エンドを構築できます。CDE の優れた点は、CDA データ アクセス レイヤーを介して変換をネイティブ データ ソースにできることです。この環境では、ケトルはクエリを直接実行するよりもほとんど遅くなりません。

PDI パフォーマンスの重要な点は、JVM を何度も起動しないようにすることです。Web アプリで実行しているときは、既に実行しているため、パフォーマンスは良好です。

また; PDI5 の最新リリースには、基本的に PDI ジョブの SQL インターフェイスである「ライト jdbc」ドライバー (EE のお客様) が含まれます。つまり、最近の PDI は単なる「バッチ」etl プロセスではありません。

于 2013-08-10T17:47:54.397 に答える
0

これは、Kettle ユース ケースの領域外です。Kettle からの応答時間は、ユーザーが直面しているものに対して遅すぎます。その本当の強みは、バッチ ETL プロセスの実行にあります。

たとえば、典型的な Kettle の使用例については、このスライドショー(特にスライド 11) を参照してください。

于 2013-08-09T18:37:32.023 に答える