私はAzure Data Factoryを使用して、Azure Data Lake StoreのデータをCosmos DBのコレクションにコピーしています。私たちはデータレイクに数千のJSONファイルを持ち、各JSONファイルは約です。 3 GB。私はデータファクトリのコピーアクティビティを使用しています。最初の実行では、1つのファイルがコレクションをロードするのに10000 RU /秒に設定され、データファクトリはデフォルト設定を使用してロードされました。今私はそれを50000 RU/sにスケールアップし、cloudDataMovementUnitsを32に設定し、writeBatchSizeを10に設定してスピードを向上させるかどうかを確認し、同じファイルを読み込むのに2.5時間かかるようになりました。それでも何千ものファイルを読み込む時間が長くかかるでしょう。Azure Data LakeからCosmos DBへのコピーを高速化する方法
もっと良い方法でこれを行うにはいくつかの方法がありますか？
結論は何百万のJsonファイルをコピーしようとすると時間がかかることです。 GBのデータが整理されていれば、より短時間のバッチ転送ではなく、数百万の異なるファイルではなくなります。
このタイプのファイルをData Lakeから頻繁に転送する予定があるのかどうかわかりませんが、そのために専用のアプリケーションを作成するのが良い方法です。 Microsoft.Azure.DocumentDB Client Libraryを使用すると、転送を管理するC＃Webアプリケーションを簡単に作成できます。
このようにして、これらの転送を自動化し、調整したり、スケジューリングしたりすることができます。また、このアプリをVMやアプリサービスでホストすることもできます。
私たちはこのデータの予定された、毎日の負荷をさらに引き上げるつもりですが、私はこのためにデータ工場を使うことを考えていました。アプリケーションを実装する方がより複雑に見え、より多くのメンテナンスが必要になります。データ・ファクトリと比較してどのような利点がありますか？ –
データファクトリーは素晴らしい選択肢です。カスタムアプリにも同様の柔軟性をもたらします。しかし、私が作ろうとしている主なポイントは、これがあなたがやろうとしているまったく些細な作業ではなく、正しく設計され、考察されなければならないということです。 –
あなたは3Gbバッチファイルごとにjsonドキュメントを「何百万」も挿入していると言います。このような精度の欠如は、このタイプの質問をするときには役に立ちません。
ファイルごとに1,000万のドキュメントの数を実行しましょう。
これは、各CosmosDbの挿入にインデックスを付けるドキュメントごとに非常に多くのフィールドを意味するjson docあたり300バイトを示します。
各インサートのコストが10RUの場合、予算単位の10,000RU /秒の場合、ドキュメントの挿入速度は1000x3600（時間あたりの秒数）= 360万ドックインサート/時間となります。
想定される1,000万のドキュメントを表す3 Gbのデータを挿入するための3.5時間の観察は、購入したCosmosDbのスループットと非常に一致しています。
このドキュメントhttps://docs.microsoft.com/en-us/azure/data-factory/data-factory-copy-activity-performanceはDataLake CosmosDbへのクラウドシンクは、他のオプションに比べてパフォーマンスが低下していることを示しています。パフォーマンスの低下はデフォルトのインデックスに起因すると考えられます.CosmosDbのすべてのポリシー。
アプリケーションですべてのインデックスが必要ですか？ CommosDbクラウドシンクは、一括挿入を実行する際に、より厳密ではない最終整合性を利用しますか？
あなたはもっと良い方法はありますか？リンクされたMS文書のパフォーマンス表は、データレイクからポリベースAzureデータウェアハウスへのパフォーマンスが20,000倍向上していることを示しています。
最終的な考えです。あなたの2番目のテストトリガCosmosDbトリガの同時実行性が向上しましたか？ MSパフォーマンス文書は、これらのイベントの監視について警告します。
各ファイルに5〜1000万件のドキュメントがあるため、見積もりは非常に良好でした。私はインデックスの量を減らそうとしましたが、パフォーマンスの向上は得られなかったので、Cosmos DBがボトルネックではないと思います。私たちは最終的な整合性も使用しています。いいえ、並行性を向上させるときには抑制がありませんでした。 –
@Magnus：面白い更新です。 50,00 RUでの2番目のテストは、パーティションキーを宣言したことを示していますが、キーパーティショニングについては言及していません。 10kから50k RUの間のパフォーマンスの制限が限られているため、ソースデータファイルでパーティションキーの値がどのように均等に分散されているか疑問に思っています。他のCosmosDbセットアップの制限から、10k RUは物理パーティションあたりの妥当な最大クエリスループットであると推測できます。したがって、入力データのパーティションキーの順序が不良な場合は、単一の物理パーティションを最大限に活用できます。 – camelCase
しかし、私が単一のパーティションを最大限に活用していたとしても、少しの調整は見られませんか？私はしません。私が使用するパーティションキーには6000の異なる値があり、データはこれらのキー値に均等に分散する必要があります。 –
サイズがGBのコスモスに1つのドキュメントを読み込もうとしていますか？コスモスの文書の最大サイズは2MBです –
いいえ、私が不明な場合は申し訳ありません。各ファイルには数百万のJSON文書が含まれています。JSON文書には位置情報が含まれているため、空間計算を行う必要があります。そのため、Cosmos DBを選択しました。 –