Как ускорить копирование из озера данных Azure в Cosmos DB

Я использую фабрику данных Azure для копирования данных из Azure Data Lake Store в коллекцию в Cosmos DB. У нас будет несколько тысяч файлов JSON в озере данных, и каждый файл JSON будет занимать прибл. 3 ГБ. Я использую операцию копирования фабрики данных, и при первоначальном запуске загрузка одного файла заняла 3,5 часа с набором сбора 10000 RU / с и фабрикой данных с настройками по умолчанию. Теперь я увеличил его до 50000 RU / с, установил cloudDataMovementUnits на 32 и writeBatchSize на 10, чтобы посмотреть, улучшилась ли скорость, и тот же файл теперь загружается за 2,5 часа. Тем не менее, загрузка тысяч файлов займет много времени.

Есть ли способ сделать это лучше?


azure azure-data-lake azure-data-factory azure-cosmosdb
person Magnus Johannesson    schedule 09.08.2017    source источник
comment
Вы хотите сказать, что пытаетесь загрузить в Cosmos отдельные документы размером в ГБ? Максимальный размер документа в Cosmos - 2 МБ.   -  person Jesse Carter    schedule 09.08.2017
comment
Нет, извините, если я не понял. Каждый файл содержит миллионы документов JSON. Документы JSON содержат данные о местоположении, и нам необходимо выполнять пространственные вычисления, поэтому мы выбрали Cosmos DB.   -  person Magnus Johannesson    schedule 09.08.2017

Ответы (2)


arrow_upward
2
arrow_downward

Вы говорите, что вставляете «миллионы» json-документов в пакетный файл 3 Гб. Такая неточность не помогает при постановке вопросов такого типа.

Давайте посчитаем 10 миллионов документов на файл.

  • Это указывает на 300 байт на документ json, что подразумевает довольно много полей на документ для индексации при каждой вставке CosmosDb.

  • Если каждая вставка стоит 10 RU, то при заложенных в бюджет 10 000 RU в секунду скорость вставки документов будет 1000 x 3600 (секунд в час) = 3,6 миллиона вставок документов в час.

  • Таким образом, ваши наблюдения за 3,5 часа для вставки 3 ГБ данных, представляющих предполагаемые 10 миллионов документов, полностью соответствуют вашей приобретенной пропускной способности CosmosDb.

Этот документ https://docs.microsoft.com/en-us/azure/data-factory/data-factory-copy-activity-performance показывает, что DataLake to CosmosDb Cloud Sink работает плохо по сравнению с другими вариантами. Я предполагаю, что низкая производительность может быть связана с политикой индексации всего по умолчанию CosmosDb.

Нужно ли вашему приложению все проиндексировать? Использует ли CommosDb Cloud Sink менее строгую согласованность при выполнении массовых вставок?

Вы спросите, есть ли способ лучше? Таблица производительности в связанном документе MS показывает, что от озера данных к хранилищу данных Polybase Azure производительность в 20 000 раз выше.

Последняя мысль. Вызывает ли повышенный уровень параллелизма вашего второго теста регулирование CosmosDb? Документ производительности MS предупреждает о мониторинге этих событий.

person camelCase    schedule 12.08.2017
comment
В каждом файле 5-10 миллионов документов, так что ваша оценка неплохая. Я попытался уменьшить объем индексации, но не добился улучшения производительности, поэтому не думаю, что Cosmos DB является узким местом. Мы также используем согласованность в конечном итоге. Нет, я не видел дросселирования при увеличении параллелизма. - person Magnus Johannesson; 14.08.2017
comment
@Magnus: Интересное обновление. Вы не упомянули о разделении ключей, хотя ваш второй тест на 50,00 RU показывает, что вы объявили ключ раздела. Ограниченный прирост производительности между 10k и 50k RU заставляет меня задаться вопросом, насколько равномерно распределенные значения ключей раздела упорядочены в ваших исходных файлах данных? Из других ограничений настройки CosmosDb мы можем сделать вывод, что 10 000 RU - это разумная максимальная пропускная способность запросов на физический раздел, и поэтому, если ваши входные данные плохо упорядочены по ключу раздела, вы можете максимально использовать один физический раздел. - person camelCase; 14.08.2017
comment
Но разве я не должен видеть некоторое троттлинг, если я максимизировал один раздел? Я не. Ключ раздела, который я использую, имеет 6000 различных значений, и данные должны быть довольно равномерно распределены по этим значениям ключа. - person Magnus Johannesson; 14.08.2017
comment
@Magnus: Я не уверен, это зависит от того, насколько сложна сигнализация дросселирования. Я думал, что это связано только с достижением общего предела подготовленных RU на уровне коллекции, но не с насыщением ввода-вывода на одном физическом разделе. Ваша интерпретация столь же разумна. Этот поток заслуживает некоторого участия инсайдеров Microsoft Azure, потому что ваш случай использования является исключительным и представляет собой именно тот тип задачи масштабирования, в котором CosmosDb должен преуспеть. - person camelCase; 14.08.2017

arrow_upward
0
arrow_downward

Суть в том, что попытка скопировать миллионы файлов Json потребует времени. Если бы это был организованный гигабайт данных, вы могли бы обойтись более короткими пакетными передачами, но не миллионами различных файлов.

Я не знаю, планируете ли вы часто переносить этот тип файла из озера данных, но хорошей стратегией может быть создание приложения, предназначенного для этого. Используя клиентскую библиотеку Microsoft.Azure.DocumentDB, вы можете легко создать веб-приложение на C #, которое будет управлять вашими передачами.

Таким образом, вы можете автоматизировать эти передачи, ограничивать их, планировать их и т. Д. Вы также можете разместить это приложение на виртуальной машине или в службе приложений, и вам никогда не придется об этом думать.

person Simon Bourdeau    schedule 11.08.2017
comment
Мы планируем запланировать ежедневную загрузку этих данных в дальнейшем, но я думал использовать для этого фабрику данных. Реализация приложения для него кажется более сложным и потребует большего обслуживания. В чем преимущество по сравнению с фабрикой данных? - person Magnus Johannesson; 14.08.2017
comment
Я бы сказал, что фабрика данных - отличный вариант. Обеспечивает гибкость, аналогичную настраиваемому приложению. Но опять же, главное, что я пытаюсь сделать, это то, что это не совсем тривиальная задача, которую вы пытаетесь решить, и ее следует правильно спроектировать и продумать. - person Simon Bourdeau; 14.08.2017