Используя Azure Data Factory 2, я не могу копировать контейнеры с большим количеством больших двоичных объектов - PullRequest
0 голосов
/ 29 мая 2018

У меня проблема с Azure Data Factory V2, где контейнеры с большим количеством больших двоичных объектов не копируются.Один трубопровод проходил почти за 75 часов до того, как он окончательно провалился с ошибкой.

Activity Copy1 failed: ErrorCode=FailedStorageOperation,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=A storage operation failed with the following error
 'Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.'.,Source=,''Type=Microsoft.WindowsAzure.Storage.StorageException,Message=Unable to read data from the transport connection:
 An existing connection was forcibly closed by the remote host.,Source=Microsoft.WindowsAzure.Storage,''Type=System.IO.IOException,Message=Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.,Source=System,''Type=System.Net.Sockets.SocketException,Message=An
 existing connection was forcibly closed by the remote host,Source=System,'

Дополнительные сведения

  • 5 Конвейеры, каждая с 1 операцией копирования (3 успешно, 2 с ошибкой).
    • Использование автоматического для параллельного копирования и DMU
    • пропуск несовместимых строк
    • без подготовки
  • В исходном наборе данных используется ключ SAS дляучетная запись хранилища Azure.
    • Учетная запись хранения настроена для RA-GRS, и я пытаюсь читать из вторичного (доступ для чтения) местоположения.
    • Использование рекурсивных и двоичных файловых опций.
  • В наборе данных назначения используется ключ SAS для учетной записи хранения Azure.
    • Учетная запись хранения находится в том же центре обработки данных, что и исходный набор данных (вторичный сервер RA учетной записи хранения).
    • Использование опции сохранения иерархии
  • Источник и пункт назначения - США Южный Центральный

Я пробовал 5 различных контейнеров источника, 3 былиуспешно, пока 2 не удалось.Похоже, что между двумя неудачниками было количество капель в контейнерах.В одном контейнере содержится более 30 миллионов капель в корне.Я не знаю числа в другом контейнере, но это более 1 ТБ, состоящий из небольших файлов (по 15 КБ каждый), организованных в подпапки глубиной 2 уровня.Я попытался воспроизвести структуру папок, как мог.

  • Контейнер 1 (успех)
    • {Guid-Folder-Name} /Blob.jpg
    • 65 ГБ, скопировано 63 555 файлов
  • Контейнер 2 (Успех)
    • Имя папки / guid-файла
    • 209 ГБ, скопировано 2 724 023 файла
  • Контейнер 3 (Успех)
    • Папка / {Папка} /blob.txt
    • отфильтрована в * .txt
    • 606 МБ, скопировано 687 559 файлов
  • Контейнер4 (Ошибка)
    • Папка / {IntId-FolderName} / blob
    • , отфильтрованные в * .json
    • , более 62 500 000 файлов, отфильтрованных в * .json, будут 10% от этого
  • Контейнер 5 (не удалось)
    • Имя папки / guid-file
    • более 30 миллионов BLOB-объектов

С контейнером 4 я попробовал источник с фильтром и без, и ни один не работал.Затем я изменил источник на более конкретный путь (папка / 1234), в котором было ~ 100 000 блобов, и он скопировался очень хорошо с указанным фильтром.Поскольку у меня была успешная копия с использованием как отфильтрованных, так и нефильтрованных источников, а также с различными структурами пути (контейнеры 1-3), кажется, что проблема заключается в количестве больших двоичных объектов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...