Kiba は非常に小さなライブラリであり、その価値のほとんどは、小さな独立した変換のモジュラー アーキテクチャを適用することから得られると理解しています。
しかし、一連のシリアル変換のモデルは、私たちが直面している ETL の問題のほとんどに当てはまらないように思えます。この問題を説明するために、不自然な例を挙げましょう。
ソースは次の構造のハッシュを生成します
{ spend: 3, cost: 7, people: 8, hours: 2 ... }
私たちが好む出力はハッシュのリストで、値は異なるかもしれませんが、いくつかのキーはソースからのものと同じかもしれません
{ spend: 8, cost: 10, amount: 2 }
ここで、結果の支出を計算するには、一連の変換が必要です: ConvertCurrency, MultiplyByPeopleetc. etc. そして、コストの計算も同様です: ConvertCurrencyDifferently, MultiplyByOriginalSpend.. コストの計算は、元の (変換されていない) 支出値に依存することに注意してください。
最も自然なパターンは、2 つの独立したパイプラインで支出とコストを計算し、最終的な出力をマージすることです。必要に応じてマップ縮小パターン。パイプラインを並行して実行することによってもメリットが得られます。
ただし、私の場合、実際にはパフォーマンスの問題ではありません (変換が非常に高速であるため)。問題は、Kiba が一連の一連のステップとしてすべての変換を適用するため、費用の計算が費用の計算の影響を受け、間違った結果になってしまうことです。
木場はこの問題を解決する方法を持っていますか? 私が考えられる唯一のことは、宛先名がソース名と同じでないことを確認することです。たとえば、「originSpend」や「finalSpend」などです。ただし、支出計算パイプラインが、関連するキーを渡すだけでなく、各ステップのキーの完全なセットを確実に渡してから最後にコスト キーをマージする必要があることは、依然として気になります。あるいは、2 つの独立した kiba ジョブを定義し、マスター ジョブに 2 つを呼び出して、最終的にそれらの結果をマージさせることもできますか? これに対する最も木場的な解決策は何ですか?
ETL パイプラインを複数の並列パスに分割することは、ほとんどの ETL ツールの重要な機能のようですが、kiba がサポートしていないように見えることに驚いていますか?