問題タブ [azure-data-flow]

データ フローを作成できるように MongoDB データセットを使用して JSON ファイルを取得しようとしていますが、MongoDB オプションがグレー表示されています。

ただし、これはパイプラインを作成するときに機能します。

MongoDB データセットを使用してデータ フローを作成できない理由について、説明が見つからないようです。

どんな助けでも大歓迎です。

ADF に、int 配列パラメーターを受け入れる DataFlow があります。

そして、フロー アクティビティの 1 つでそれを使用します。

しかし、パイプラインからそのデータフローを呼び出そうとすると、まったく満足していないようです:(

これまでに3つの異なるバージョンを試しました：

• ハードコーディングされた式として定義された空の配列を渡します: imageLink
• ハードコーディングされた式として定義された値を持つ配列を渡します: imageLink
• パイプラインから配列変数を渡します: (ValuationDateIds上記のリンクされた画像でどのように渡したかを参照してください)

どちらの方法を試しても、パラメーターが見つからないという同じエラーがデータフローから発生します。

ただし、データフロー呼び出しログには、パラメーターが渡されたことが示されています。

私は何を間違っていますか？

編集: 別のことを試しました: DF にデフォルトのパラメーターを設定し、値をハードコードしてから、DF 呼び出しを再作成しました。これらのデフォルトでパラメーターを自動入力し、正常に実行されました。しかし、呼び出しを別の数字のペアに変更すると (数字を変更しただけなので、構文的には同じです)、入力が無視され、デフォルト値を使用し続けていることがわかりました。

はい、TTL については知っています。はい、設定しています。いいえ、それは私がここで尋ねていることではありません。

• Dataflowの初期クラスタのスピンアップには約5 分かかります。

• 既存の「ウォーム」クラスター (つまり、TTL を使用して「アライブ」のままになっているクラスター)からコンピューティングの取得を開始すると、新しいデータフローにはまだ1 ～ 2 分かかるようです。

これらは、特に複数ステップの ETL プロセスがあり、パイプラインを分割して懸念事項を分離している場合 (または、データフローをループで実行している場合、ソース日ごとにデータを処理する場合) は非常に多くなります。

TTL を制御すると、これら 2 つの可能性のどちらをトリガーするかをある程度制御できますが、2 分でもかなりのオーバーヘッドになる可能性があります。(実行時間の半分が 1 ～ 2 分間の「Acquire Compute」の起動を待機しているパイプラインがあります)

それぞれの場合に起動にかかる時間を制御できますか? 起動を高速化するためにできること、または事態をさらに悪化させないようにするために避けるべきことはありますか?