我正在使用Azure Data Factory将数据从Azure Data Lake Store复制到Cosmos DB中的集合 . 我们将在数据湖中有几千个JSON文件，每个JSON文件大约是 . 3 GB . 我正在使用数据工厂的复制活动，在初始运行中，一个文件需要3.5小时才能加载，集合设置为10000 RU / s，数据工厂使用默认设置 . 现在我将它扩展到50000 RU / s，将cloudDataMovementUnits设置为32并将writeBatchSize设置为10以查看它是否提高了速度，同一文件现在需要2.5小时才能加载 . 加载数千个文件的时间仍然需要很长时间 .
有没有办法以更好的方式做到这一点？
2 回答
你说你在每个3Gb批处理文件中插入“数百万”的json文档 . 在提出这类问题时，这种缺乏精确性是没有用的 .
让我们为每个文件运行1000万个文档的数字 .
这表示每个json doc有300个字节，这意味着每个文档上有很多字段要对每个CosmosDb插入进行索引 .
如果每个插入成本为10 RU，那么按预算计算每秒10,000 RU，文档插入率将为1000 x 3600（每小时秒数）=每小时360万次doc插入 .
因此，您观察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的默认索引 - 一切政策 .
您的应用程序是否需要索引所有内容在执行批量插入时，CommosDb Cloud Sink是否使用不太严格的最终一致性？
你问，有更好的方法吗？链接的MS文档中的性能表显示Data Lake到Polybase Azure数据仓库的性能要高出20,000倍 .
最后一个想法 . 第二次测试增加的并发性是否会触发CosmosDb限制？ MS性能文档警告监视这些事件 .
最重要的是，尝试复制数百万个Json文件需要时间 . 如果它是有组织的GB数据，您可以通过较短的时间批量传输而不是数百万个不同的文件 .
我不知道你是否打算经常从Data Lake转移这种类型的文件，但一个好的策略可能就是编写一个专门用来做这个的应用程序 . 使用Microsoft.Azure.DocumentDB Client Library，您可以轻松创建管理传输的C＃Web应用程序 .
通过这种方式，您可以自动执行这些传输，限制它们，安排它们等 . 您还可以在虚拟机或应用程序服务上托管此应用程序，而不必真正考虑它 .