Поделиться через

Перенос сотен терабайт данных в Azure Cosmos DB

  • Статья

Область применения: NoSQL Mongodb Кассандра Гремлин Таблица

Azure Cosmos DB может хранить терабайты данных. Вы можете выполнить крупномасштабную миграцию данных, чтобы переместить рабочую нагрузку в Azure Cosmos DB. В этой статье описаны проблемы, связанные с крупномасштабным перемещением данных в Azure Cosmos DB, а также представлено средство, которое помогает устранять проблемы и переносить данные в Azure Cosmos DB. В этом примере клиент использовал API Azure Cosmos DB для NoSQL.

Перед переносом всей рабочей нагрузки в Azure Cosmos DB можно выполнить миграцию подмножества данных для проверки некоторых аспектов, например выбора ключа секции, производительности запросов и моделирования данных. После проверки подтверждения концепции можно переместить всю рабочую нагрузку в Azure Cosmos DB.

Средства для переноса данных

Стратегии миграции Azure Cosmos DB в настоящее время различаются в зависимости от выбора API и размера данных. Для переноса небольших наборов данных — для валидации моделирования данных, производительности запросов, выбора ключа раздела и прочего — можно использовать соединитель Azure Cosmos DB в Azure Data Factory. Если вы знакомы со Spark, можно также использовать соединитель Azure Cosmos DB Spark для переноса данных.

Трудности при крупномасштабных миграциях

Существующие средства для переноса данных в Azure Cosmos DB имеют некоторые ограничения, которые становятся особенно заметными при больших масштабах:

  • Ограниченные возможности горизонтального масштабирования: для максимально быстрого переноса терабайт данных в Azure Cosmos DB и для эффективного использования всей запланированной пропускной способности клиенты миграции должны иметь возможность неограниченного горизонтального масштабирования.

  • Отсутствие отслеживания хода выполнения и контрольных точек: важно контролировать прогресс миграции и использовать контрольные точки при переносе больших наборов данных. В противном случае любая ошибка, возникающая во время миграции, приведет к прерыванию миграции, и процесс придется начать с нуля. Было бы очень нерационально перезапускать весь процесс миграции, например, когда завершено уже 99 %.

  • Отсутствие очереди недоставленных сообщений: в больших наборах данных в некоторых случаях могут возникнуть проблемы с частями исходных данных. Кроме того, могут возникать временные проблемы с клиентом или сетью. Любой из этих случаев не должен приводить к сбою всей миграции. Хотя большинство средств миграции обладают надежными средствами осуществления повторных попыток, которые защищены от периодических проблем, этого не всегда достаточно. Например, если менее 0,01 % документов исходных данных имеет размер свыше 2 МБ, это приведет к сбою записи документа в Azure Cosmos DB. В идеале полезно, чтобы средство миграции сохраняло сбойные документы в отдельной очереди недоставленных сообщений, которая может быть обработана после миграции.

Многие из этих ограничений исправляются для таких средств, как Фабрика данных Azure, службы миграции данных Azure.

Пользовательский инструмент с библиотекой исполнителя массовых операций

Проблемы, описанные в приведенном выше разделе, можно решить с помощью пользовательского инструмента, который можно легко масштабировать между несколькими экземплярами, и этот инструмент является устойчивым ко временным сбоям. Кроме того, пользовательское средство может приостанавливать и возобновлять миграцию на различных контрольных точках. Azure Cosmos DB уже предоставляет библиотеку исполнителя массовых операций, в которой содержатся некоторые из этих функций. Например, библиотека массового выполнения уже содержит функции для обработки кратковременных ошибок и может масштабировать количество потоков на одном узле, чтобы использовать примерно 500 тыс. единиц запросов (RUs) на каждый узел. Библиотека исполнителя массовых операций также разделяет исходный набор данных на микропакеты, которые обрабатываются независимо в качестве формы контрольных точек.

Пользовательский инструмент использует библиотеку исполнителя массовых операций, поддерживает масштабирование на несколько клиентов и отслеживание ошибок в процессе приема данных. Для использования этого инструмента исходные данные должны быть разделены на отдельные файлы в Azure Data Lake Storage (ADLS), чтобы различные миграционные работники могли выбирать каждый файл и загружать их в Azure Cosmos DB. Пользовательский инструмент использует отдельную коллекцию, в которой хранятся метаданные о ходе миграции для каждого отдельного исходного файла в ADLS и отслеживаются все ошибки, связанные с ними.

На следующем изображении описан процесс миграции с помощью этого пользовательского инструмента. Средство выполняется на наборе виртуальных машин, и каждая виртуальная машина запрашивает сбор данных отслеживания в Azure Cosmos DB, чтобы получить аренду одной из секций с исходными данными. После этого исходный раздел данных считывается инструментом и принимается в Azure Cosmos DB с помощью библиотеки массовых операций. Далее обновляется коллекция отслеживания для записи хода приема данных и обнаруженных ошибок. После обработки секции данных средство пытается запросить следующую доступную исходную секцию. Обработка следующей исходной секции будет продолжена до тех пор, пока не будут перенесены все данные. Исходный код инструмента доступен в репозитории массового приема Azure Cosmos DB.

Настройка средства миграции

Коллекция отслеживания содержит документы, как показано в следующем примере. Вы увидите такие документы по одному для каждой секции в исходных данных. Каждый документ содержит метаданные для секции источника данных, например расположение, состояние миграции и ошибки (если они есть):

{ 
  "owner": "25812@bulkimporttest07", 
  "jsonStoreEntityImportResponse": { 
    "numberOfDocumentsReceived": 446688, 
    "isError": false, 
    "totalRequestUnitsConsumed": 3950252.2800000003, 
    "errorInfo": [], 
    "totalTimeTakenInSeconds": 188, 
    "numberOfDocumentsImported": 446688 
  }, 
  "storeType": "AZURE_BLOB", 
  "name": "sourceDataPartition", 
  "location": "sourceDataPartitionLocation", 
  "id": "sourceDataPartitionId", 
  "isInProgress": false, 
  "operation": "unpartitioned-writes", 
  "createDate": { 
    "seconds": 1561667225, 
    "nanos": 146000000 
  }, 
  "completeDate": { 
    "seconds": 1561667515, 
    "nanos": 180000000 
  }, 
  "isComplete": true 
}

Предварительные требования для миграции данных

Прежде чем начать перенос данных, необходимо выполнить несколько предварительных условий.

Оценка объема данных

Исходный размер данных может не в точности соответствовать размеру данных в Azure Cosmos DB. Чтобы проверить размер данных в Azure Cosmos DB, можно вставить несколько примеров документов из источника. В зависимости от размера образца документа можно оценить общий размер данных в Azure Cosmos DB после миграции.

Например, если каждый документ после миграции в Azure Cosmos DB имеет размер около 1 КБ и в исходном наборе данных имеется около 60 000 000 000 документов, это означает, что предполагаемый размер в Azure Cosmos DB будет близок к 60 ТБ.

Предварительно создайте контейнеры с достаточным количеством получателей:

Хотя Azure Cosmos DB масштабирует хранилище автоматически, не рекомендуется начинать с наименьшего размера контейнера. Контейнеры меньшего размера имеют меньшую доступность по пропускной способности, что означает, что миграция займет значительно больше времени. Вместо этого полезно создать контейнеры с окончательным размером данных (как показано на предыдущем шаге) и убедиться, что рабочая нагрузка миграции полностью потребляет подготовленную пропускную способность.

На предыдущем шаге. Так как размер данных приблизительно составляет около 60 ТБ, для размещения всего набора данных требуется контейнер по крайней мере 2,4 млн ЕЗ.

Оцените скорость миграции:

При условии, что рабочая нагрузка миграции может потреблять всю подготовленную пропускную способность, этот показатель позволит оценить скорости миграции. Продолжая предыдущий пример, для записи документа объемом 1 КБ в API Azure Cosmos DB для NoSQL требуется 5 RUs. 2,4 млн ЕЗ обеспечивает передачу 480 000 документов в секунду (или 480 Мбит/с). Это означает, что полная миграция 60 ТБ займет 125 000 секунд или около 34 часов.

Если требуется, чтобы миграция была выполнена в течение одного дня, необходимо увеличить выделенную пропускную способность до 5 000 000 ЕЗ.

Выключение индексации.

Так как миграция должна быть выполнена как можно скорее, рекомендуется минимизировать время и RUs, затрачиваемые на создание индексов для каждого загруженного документа. Azure Cosmos DB индексирует все свойства автоматически, поэтому стоит по меньшей мере выполнить индексирование до выбранных нескольких терминов или полностью отключить индексацию в процессе миграции. Вы можете отключить политику индексирования контейнера, установив режим индексирования ("indexingMode") на "none", как показано ниже.

  { 
        "indexingMode": "none" 
  }

После завершения миграции можно удалить экземпляр Azure Database Migration Service.

Процесс миграции

После завершения предварительных требований можно выполнить миграцию данных, выполнив следующие действия.

  1. Сначала импортируйте данные из источника в Хранилище BLOB-объектов Azure. Чтобы увеличить скорость миграции, рекомендуется обеспечить параллельное выполнение между различными исходными секциями. Перед началом миграции исходный набор данных должен быть разбит на файлы размером около 200 МБ.

  2. Библиотеку исполнителя массовых операций можно масштабировать, чтобы использовать 500 000 ЕЗ в одной клиентской виртуальной машине. Так как доступная пропускная способность составляет 5 миллионов единиц, 10 виртуальных машин Ubuntu 16.04 (Standard_D32_v3) должны быть подготовлены в том же регионе, где находится база данных Azure Cosmos DB. Необходимо подготовить эти виртуальные машины с помощью средства миграции и файла параметров.

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

  4. Затем выполните шаг импорта на всех клиентских виртуальных машинах. Каждый из клиентов может стать владельцем исходного раздела и загружать его данные в Azure Cosmos DB. После завершения работы и обновления состояния в коллекции отслеживания клиенты смогут запрашивать следующую доступную исходную секцию в коллекции отслеживания.

  5. Этот процесс будет продолжаться до тех пор, пока не будет получен весь набор исходных секций. После обработки всех исходных секций средство следует перезапустить в режиме исправления ошибок в той же коллекции отслеживания. Этот шаг необходим для обнаружения исходных секций, которые должны быть повторно обработаны из-за ошибок.

  6. Некоторые из этих ошибок могут быть вызваны неверными документами в исходных данных. Их необходимо идентифицировать и исправить. Затем следует повторно выполнить шаг импорта для разделов, на которых произошел сбой, чтобы повторно импортировать данные.

После завершения миграции можно проверить, что количество документов в Azure Cosmos DB совпадает с количеством документов в базе данных-источнике. В этом примере общий размер в Azure Cosmos DB оказался 65 ТБ. После миграции можно выборочно включить индексирование и уменьшить потребление RUs до уровня, необходимого для операций рабочей нагрузки.

Следующие шаги

  • Узнайте больше, попробовав примеры приложений, использующих библиотеку исполнения массовых операций в .NET и Java.
  • Библиотека исполнителя массовых операций интегрирована в соединитель Spark для Azure Cosmos DB. Чтобы узнать больше, см. статью Azure Cosmos DB Spark connector.
  • Обратитесь к группе разработчиков Azure Cosmos DB, открыв запрос в службу поддержки с типом проблемы "Общие рекомендации" и подтипом "Крупные (ТБ+) миграции" для получения дополнительной справки о крупномасштабных миграциях.
  • Занимаетесь планированием масштабирования для миграции в Azure Cosmos DB? Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.