如何加快从 Azure Data Lake 到 Cosmos DB 的复制速度答案

【问题标题】：How to speed up copy from Azure Data Lake to Cosmos DB如何加快从 Azure Data Lake 到 Cosmos DB 的复制速度
【发布时间】：2018-01-17 11:35:02
【问题描述】：

我正在使用 Azure 数据工厂将数据从 Azure Data Lake Store 复制到 Cosmos DB 中的集合。我们将在数据湖中有几千个 JSON 文件，每个 JSON 文件大约为 . 3 GB。我正在使用数据工厂的复制活动，在初始运行中，加载一个文件需要 3.5 小时，其中集合设置为 10000 RU/s，数据工厂使用默认设置。现在我已将其扩展到 50000 RU/s，将 cloudDataMovementUnits 设置为 32 并将 writeBatchSize 设置为 10，看看它是否提高了速度，现在加载相同的文件需要 2.5 小时。加载数千个文件的时间仍然很长。

有没有更好的方法来做到这一点？

【问题讨论】：

您是说您正在尝试将单个文档加载到 GB 大小的 Cosmos 中吗？ Cosmos 中文档的最大大小为 2MB
不，如果我不清楚，对不起。每个文件包含数百万个 JSON 文档。 JSON 文档包含位置数据，我们需要进行空间计算，这就是我们选择 Cosmos DB 的原因。

标签： azure azure-cosmosdb azure-data-factory azure-data-lake

【解决方案1】：

底线是尝试复制数百万个 Json 文件需要时间。如果它是有组织的 GB 数据，您可以通过更短的时间批量传输而不是数百万个不同的文件。

我不知道您是否打算经常从 Data Lake 传输此类文件，但一个好的策略可能是编写一个专门用于执行此操作的应用程序。使用 Microsoft.Azure.DocumentDB 客户端库，您可以轻松创建管理传输的 C# Web 应用程序。

通过这种方式，您可以自动执行这些传输、限制传输、安排传输等。您还可以将此应用托管在虚拟机或应用服务上，而无需考虑。

【讨论】：

我们计划进一步每天加载这些数据，但我正在考虑为此使用数据工厂。为它实现一个应用程序似乎更复杂，需要更多的维护。与数据工厂相比有什么优势？
我会说数据工厂是一个不错的选择。为自定义应用程序提供类似的灵活性。但我要再次强调的主要观点是，这不是您要尝试完成的一项完全微不足道的任务，它应该经过适当的设计和深思熟虑。

【解决方案2】：

您说您要为每个 3Gb 批处理文件插入“数百万”个 json 文档。在问这种类型的问题时，这种缺乏精确性是没有帮助的。

让我们计算每个文件 1000 万个文档的数字。

这表示每个 json 文档 300 字节，这意味着每个文档有相当多的字段要在每个 CosmosDb 插入上建立索引。
如果每个插入成本为 10 RU，那么在您的预算为每秒 10,000 RU 时，文档插入速率将为 1000 x 3600（每小时秒）= 每小时 360 万个文档插入。
因此，您在 3.5 小时内插入代表假定 1000 万个文档的 3 Gb 数据的观察结果与您购买的 CosmosDb 吞吐量高度一致。

本文档https://docs.microsoft.com/en-us/azure/data-factory/data-factory-copy-activity-performance 说明了 DataLake 到 CosmosDb Cloud Sink 与其他选项相比表现不佳。我猜性能不佳可归因于 CosmosDb 的默认 index-everything 策略。

您的应用程序是否需要对所有内容进行索引？ CommosDb Cloud Sink 在执行批量插入时是否使用不太严格的最终一致性？

你问，有没有更好的方法？链接的 MS 文档中的性能表显示，Data Lake 到 Polybase Azure 数据仓库的性能提高了 20,000 倍。

最后一个想法。您的第二个测试增加的并发性是否会触发 CosmosDb 限制？ MS 性能文档警告要监视这些事件。

【讨论】：

每个文件有 5-1000 万个文档，所以您的估计相当不错。我尝试减少索引量，但没有得到任何性能提升，所以我不认为 Cosmos DB 是瓶颈。我们还使用最终一致性。不，我在增加并发性时没有看到任何限制。
@Magnus：一个有趣的更新。尽管您在 50,00 RU 处的第二次测试表明您已经声明了分区键，但您没有提到键分区。 10k 到 50k RU 之间的有限性能提升让我质疑您的分区键值在源数据文件中的排序是否均匀分布？我们可以从其他 CosmosDb 设置限制中推断出 10k RU 是每个物理分区的合理最大查询吞吐量，因此如果您的输入数据在分区键上的顺序不佳，您可能会最大化单个物理分区。
但是如果我最大化单个分区，我不应该看到一些限制吗？我不。我使用的分区键有 6000 个不同的值，数据应该非常均匀地分布在这些键值上。
@Magnus：我不确定，这取决于节流回退信号的复杂程度。我认为这仅与在集合级别达到整体预置 RU 上限有关，但与单个物理分区上的 I-O 饱和度无关。你的解释同样合理。该线程值得一些 Microsoft Azure 内部人员的贡献，因为您的用例是特殊的，并且正是 CosmosDb 应该擅长的横向扩展挑战类型。