如何從Azure的數據副本湖加快宇宙DB

我使用Azure的數據工廠從Azure的數據存儲湖的數據複製到宇宙DB的集合。我們將在數據湖中有幾千個JSON文件，每個JSON文件都是大約。 3 GB。我正在使用數據工廠的複製活動，並且在初始運行時，使用默認設置將一個文件加載到集羣設置爲10000 RU/s和數據工廠需要3.5小時。現在我已經將它擴展到50000 RU/s，將cloudDataMovementUnits設置爲32，並將writeBatchSize設置爲10以查看它是否提高了速度，並且同一文件現在需要2.5小時才能加載。加載成千上萬個文件的時間仍將長久存在。如何從Azure的數據副本湖加快宇宙DB

有沒有辦法以更好的方式做到這一點？

來源

2017-08-09 Magnus Johannesson

你是說你試圖將單個文檔加載到大小爲GB的Cosmos中？宇宙中文件的最大尺寸是2MB –

不，如果我不清楚，對不起。每個文件都包含數百萬個JSON文檔。JSON文檔包含位置數據，我們需要進行空間計算，這就是我們選擇Cosmos DB的原因。 –

的底線是，試圖複製數百萬的JSON檔案需要一定的時間。如果它是有組織的GB數據，你可以用更短的時間批量傳輸而不是數百萬個不同的文件。

我不知道，如果你打算從數據湖經常轉移這種類型的文件，但一個好的策略可以寫專門做一個應用程序。使用Microsoft.Azure.DocumentDB客戶端庫，您可以輕鬆創建一個管理您的傳輸的C＃Web應用程序。

這樣，您就可以自動這些轉讓，油門他們，安排它們，等你也可以託管在一個虛擬機或應用服務這個應用程序，從來沒有真的要想一想。

來源

2017-08-11 18:44:36

我們計劃進一步對這些數據進行計劃，日常加載，但是我正在考慮使用數據工廠進行此操作。實施它的應用程序似乎更復雜，並需要更多的維護。與數據工廠相比有什麼優勢？ –

我會說數據工廠是一個不錯的選擇。爲自定義應用提供類似的靈活性。但是，我試圖做的主要觀點是，這不是一個你想要做的小事，它應該被正確地設計和思考。 –

你說你要插入的3Gb每批處理文件JSON文件的「百千萬」。當問這種類型的問題時，這種精確度的缺失是沒有幫助的。

讓我們運行每個文件1000萬個文檔的數字。

該表示每JSON文檔，這意味着相當多的每文檔字段的索引在每個CosmosDb插入件300個字節。
如果每個插入成本爲10 RU，那麼在您的預算10,000 RU每秒插入速率爲1000 x 3600（每小時秒數）=每小時插入360萬個插件。
所以你3.5小時的觀察中插入代表假設千萬的文檔數據的3 Gb是您購買的CosmosDb吞吐量高度一致。

本文https://docs.microsoft.com/en-us/azure/data-factory/data-factory-copy-activity-performance說明了DataLake到CosmosDb雲水槽執行相對於其他選項不佳。我想這種糟糕的表現可以歸因於CosmosDb的默認索引 - 所有政策。

你的應用程序是否需要一切索引？在執行批量插入操作時，CommosDb Cloud Sink是否使用較不嚴格的最終一致性？

你問，有沒有更好的辦法？鏈接的MS文檔中的性能表顯示Data Lake到Polybase Azure數據倉庫的性能高出20,000倍。

最後一個想法。第二個測試增加的併發性是否會觸發CosmosDb限制？ MS性能文檔警告有關監視這些事件。

來源

2017-08-12 11:14:10 camelCase

每個文件中有5-10百萬個文件，所以你的估計是相當不錯的。我試過減少索引量，但沒有得到任何性能改進，所以我不認爲Cosmos DB是瓶頸。我們也在使用最終的一致性。不，我在增加併發時沒有看到任何限制。 –

@Magnus：一個有趣的更新。你沒有提到關鍵分區，儘管你在第二個測試時以50,00 RU表示你已經聲明瞭一個分區鍵。 10k和50k RU之間的有限性能增益會讓我質疑您的分區鍵值在您的源數據文件中是如何均勻分散的？我們可以從其他CosmosDb設置限制中推斷10k RU是每個物理分區的合理最大查詢吞吐量，因此如果您的輸入數據在分區密鑰上排序不佳，則可能會使單個物理分區最大化。 – camelCase

但是，如果我正在最大化一個分區，不應該看到一些限制嗎？我不。我使用的分區鍵具有6000個不同的值，數據應該均勻分佈在這些鍵值上。 –

如何從Azure的數據副本湖加快宇宙DB

回答

相關問題