Устранение проблем с производительностью операций копирования

ПРИМЕНИМО К: Фабрика данных Azure Azure Synapse Analytics

В этой статье описывается, как провести устранение неполадок производительности операции копирования в Фабрика данных Azure.

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

Советы по настройке производительности

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

Для справки: в настоящее время советы по настройке производительности предоставляют рекомендации в следующих случаях.

Сведения о выполнении действия копирования

Сведения о выполнении и длительности в нижней части представления мониторинга действия копирования описывают ключевые этапы, которые проходит действие копирования (см. пример в начале этой статьи), что особенно полезно для устранения проблем с производительностью копирования. Узким местом вашего процесса копирования является тот процесс, который занимает больше всего времени. Ознакомьтесь со следующей таблицей, чтобы понять определение каждого этапа, и узнайте, как устранять проблемы копирования данных в Azure IR и Self-hosted IR с использованием этой информации.

Устранение неполадок с операцией копирования в Azure IR

Выполните шаги по настройке производительности, чтобы спланировать и провести тест производительности для своего сценария.

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

• "Скрипт предварительного копирования" выполняется слишком долго: это означает, что скрипт предварительного копирования, выполняемый в базе данных приемника, занимает много времени на выполнение. Настройте указанную логику скрипта предварительного копирования, чтобы повысить производительность. Если вам нужна дополнительная помощь по улучшению сценария, обратитесь к команде, занимающейся базами данных.

• "Передача — время на первый байт" превышена длительность обработки: исходный запрос занимает много времени для возвращения данных. Это может означать, что запрос занимает много времени для обработки в источнике, так как источник занят другими задачами, или запрос не является оптимальным, или данные хранятся таким образом, чтобы он занимал много времени для получения. Рассмотрите, выполняются ли другие запросы в этом источнике одновременно, или если в запросе есть какие-либо обновления, чтобы получить данные быстрее. Если у вас есть команда, управляющая источником данных, обратитесь к ним, чтобы изменить запрос или проверить производительность источника.

• Длительное выполнение этапа "Перенос — вывод источника": означает, что перечисление исходных файлов или секций данных базы данных-источника выполняется медленно.

  • Если при копировании данных из файлового источника вы используете фильтр с подстановочным знаком для пути к папке или имени файла (wildcardFolderPath или wildcardFileName) или фильтр по времени последнего изменения файла (modifiedDatetimeStart или modifiedDatetimeEnd), обратите внимание, что такой фильтр приведет к тому, что копирование сначала перечислит все файлы в указанной папке на стороне клиента, а затем применит фильтр. Такое перечисление файлов может стать узким местом, особенно в том случае, если только небольшой набор файлов удовлетворяет правилу фильтра.

    • Проверьте, можно ли копировать файлы на основе пути или имени файла с секционированием по дате и времени. Такой способ не создает нагрузки на стороне списка источников.

    • Проверьте, можно ли вместо этого использовать собственный фильтр хранилища данных, а именно "prefix" для хранилища Amazon S3, хранилища BLOB-объектов Azure и Файлы Azure, а также "listAfter/listBefore" для хранилища Azure Data Lake Storage (ADLS) первого поколения. Эти фильтры являются серверным фильтром хранилища данных и имеют более высокую производительность.

    • Рассмотрите возможность разбиения одного большого набора данных на несколько меньших и одновременного выполнения заданий копирования, каждое из которых обрабатывает только часть данных. Это можно сделать с помощью команд Lookup/GetMetadata + ForEach + Copy. См. шаблоны решений Копирование файлов из нескольких контейнеров или Перенос данных из Amazon S3 в ADLS 2-го поколения в качестве общих примеров.

  • Проверьте, сообщает ли служба об ошибке регулирования в источнике, а также находится ли хранилище данных в состоянии высокой загрузки. Если это так, либо сократите рабочие нагрузки в хранилище данных, либо попробуйте обратиться к администратору хранилища данных, чтобы увеличить предел регулирования или объем доступных ресурсов.

  • Используйте Azure IR в том же или близком к региону хранилища исходных данных.

• Длительное выполнение этапа "Перенос — чтение из источника":

  • Выполните рекомендации по загрузке данных для конкретного соединителя, если применимо. Например, при копировании данных из Amazon RedShift настройте использование REDSHIFT UNLOAD.

  • Проверьте, сообщает ли служба об ошибке регулирования в источнике, а также находится ли хранилище данных в состоянии высокой загрузки. Если это так, либо сократите рабочие нагрузки в хранилище данных, либо попробуйте обратиться к администратору хранилища данных, чтобы увеличить предел регулирования или объем доступных ресурсов.

  • Проверьте шаблон источника и приемника данных:

    • Если ваш шаблон копирования поддерживает более четырех единиц интеграции данных (DIU) — см. этот раздел для получения подробной информации — вы можете попробовать увеличить количество DIU, чтобы повысить производительность.

    • В противном случае рассмотрите возможность разбиения одного большого набора данных на несколько меньших и одновременного выполнения заданий копирования, каждое из которых обрабатывает только часть данных. Это можно сделать с помощью команд Lookup/GetMetadata + ForEach + Copy. См. шаблоны решений Копирование файлов из нескольких контейнеров, Перенос данных из Amazon S3 в ADLS 2-го поколения или Массовое копирование с помощью таблицы управления в качестве общих примеров.

  • Используйте Azure IR в том же или близком к региону хранилища исходных данных.

• "Перенос — запись в приемник" характеризуется длительным временем работы

  • Выполните рекомендации по загрузке данных для конкретного соединителя, если применимо. Например, при копировании данных в Azure Synapse Analytics используйте инструкцию PolyBase или COPY.

  • Проверьте, сообщает ли служба об ошибке регулирования в приемнике, а также находится ли хранилище данных в состоянии высокой загрузки. Если это так, либо сократите рабочие нагрузки в хранилище данных, либо попробуйте обратиться к администратору хранилища данных, чтобы увеличить предел регулирования или объем доступных ресурсов.

  • Проверьте шаблон источника и приемника данных:

    • Если ваш шаблон копирования поддерживает более четырех единиц интеграции данных (DIU) — см. этот раздел для получения подробной информации — вы можете попробовать увеличить количество DIU, чтобы повысить производительность.

    • В противном случае постепенно настраивайте параллельные копии. Слишком много параллельных копий может даже повредить производительности.

  • Используйте Azure IR в том же регионе или вблизи региона вашего целевого хранилища данных.

Устранение проблем с процессом копирования на локально размещенном IR

Выполните шаги по настройке производительности, чтобы спланировать и провести тест производительности для своего сценария.

Если производительность копирования не соответствует вашим ожиданиям, и вы устраняете неполадки с отдельной операцией копирования, запущенной на Azure Integration Runtime, и видите советы по настройке производительности, отображаемые в представлении мониторинга копирования, примените предложенные рекомендации и попытайтесь снова. В противном случае ознакомьтесь со сведениями о выполнении действия копирования, выясните, какой этап занимает наибольшее время, и выполните приведенные ниже инструкции для повышения производительности копирования.

• Длительное время нахождения в "Очереди": это означает, что действие копирования долго ожидает в очереди на выполнение до тех пор, пока не будет предоставлен ресурс для выполнения на Self-hosted IR. Проверьте емкость и потребление IR и масштабируйте вверх или вширь в соответствии с рабочей нагрузкой.

• Длительное выполнение этапа "Перенос — время до первого байта": означает, что на возврат данных исходным запросом уходит много времени. Проверьте и оптимизируйте запрос или сервер. Если вам нужна дополнительная помощь, обратитесь к команде, занимающейся хранилищем данных.

• Длительное выполнение этапа "Перенос — вывод источника": означает, что перечисление исходных файлов или секций данных базы данных-источника выполняется медленно.

  • Проверьте, имеет ли компьютер с самостоятельно управляемой средой выполнения (Self-hosted IR) низкую задержку при подключении к источнику данных. Если источник находится в Azure, можно использовать этот инструмент для проверки задержки от самохостинга IR до региона Azure: чем меньше задержка, тем лучше.

  • Если при копировании данных из файлового источника вы используете фильтр с подстановочным знаком для пути к папке или имени файла (wildcardFolderPath или wildcardFileName) или фильтр по времени последнего изменения файла (modifiedDatetimeStart или modifiedDatetimeEnd), обратите внимание, что такой фильтр приведет к тому, что копирование сначала перечислит все файлы в указанной папке на стороне клиента, а затем применит фильтр. Такое перечисление файлов может стать узким местом, особенно в том случае, если только небольшой набор файлов удовлетворяет правилу фильтра.

    • Проверьте, можно ли копировать файлы на основе пути или имени файла с секционированием по дате и времени. Такой способ не создает нагрузки на стороне списка источников.

    • Проверьте, можно ли вместо этого использовать собственный фильтр хранилища данных, а именно "prefix" для хранилища Amazon S3, хранилища BLOB-объектов Azure и Файлы Azure, а также "listAfter/listBefore" для хранилища Azure Data Lake Storage (ADLS) первого поколения. Эти фильтры являются серверным фильтром хранилища данных и имеют более высокую производительность.

    • Рассмотрите возможность разбиения одного большого набора данных на несколько меньших и одновременного выполнения заданий копирования, каждое из которых обрабатывает только часть данных. Это можно сделать с помощью команд Lookup/GetMetadata + ForEach + Copy. См. шаблоны решений Копирование файлов из нескольких контейнеров или Перенос данных из Amazon S3 в ADLS 2-го поколения в качестве общих примеров.

  • Проверьте, сообщает ли служба об ошибке регулирования в источнике, а также находится ли хранилище данных в состоянии высокой загрузки. Если это так, либо сократите рабочие нагрузки в хранилище данных, либо попробуйте обратиться к администратору хранилища данных, чтобы увеличить предел регулирования или объем доступных ресурсов.

• Длительное выполнение этапа "Перенос — чтение из источника":

  • Проверьте, имеет ли компьютер с самостоятельно управляемой средой выполнения (Self-hosted IR) низкую задержку при подключении к источнику данных. Если источник находится в Azure, можно использовать это средство для проверки задержки от локального сервера IR к регионам Azure: чем меньше - тем лучше.

  • Убедитесь, что входная пропускная способность компьютера локально размещаемой IR достаточно велика для эффективного чтения и передачи данных. Если исходное хранилище данных находится в Azure, можно использовать средство this для проверки скорости скачивания.

  • Проверьте тенденцию использования ЦП и памяти локальной среды IR на портале Azure -> вашей фабрике данных или рабочей области Synapse -> обзорной странице. Рассмотрите возможность масштабирования IR вверх/наружу, если использование ЦП велико или доступная память мала.

  • Рекомендуется использовать рекомендации по загрузке данных для конкретного соединителя, если это применимо. Например:

    • При копировании данных из Oracle, Netezza, Teradata, SAP HANA, SAP Table и SAP Open Hub включите параметры разделения данных, чтобы копировать данные параллельно.

    • При копировании данных из HDFS настройте использование DistCp.

    • При копировании данных из Amazon Redshift настройте использование Redshift UNLOAD.

  • Проверьте, сообщает ли служба об ошибке регулирования в источнике, а также находится ли хранилище данных в состоянии высокой загрузки. Если это так, либо сократите рабочие нагрузки в хранилище данных, либо попробуйте обратиться к администратору хранилища данных, чтобы увеличить предел регулирования или объем доступных ресурсов.

  • Проверьте шаблон источника и приемника данных:

    • Если вы копируете данные из хранилищ данных с поддержкой секционирования, рассмотрите возможность постепенной настройки параллельных копий. Слишком много параллельных копий может даже повредить производительности.

    • В противном случае рассмотрите возможность разбиения одного большого набора данных на несколько меньших и одновременного выполнения заданий копирования, каждое из которых обрабатывает только часть данных. Это можно сделать с помощью команд Lookup/GetMetadata + ForEach + Copy. См. шаблоны решений Копирование файлов из нескольких контейнеров, Перенос данных из Amazon S3 в ADLS 2-го поколения или Массовое копирование с помощью таблицы управления в качестве общих примеров.

• "Перенос — запись в приемник" характеризуется длительным временем работы

  • Выполните рекомендации по загрузке данных для конкретного соединителя, если применимо. Например, при копировании данных в Azure Synapse Analytics используйте инструкцию PolyBase или COPY.

  • Проверьте, имеет ли локально размещаемый компьютер Integration Runtime (IR) низкую задержку при подключении к хранилищу данных-приемнику. Если приемник находится в Azure, вы можете использовать средство /c0, чтобы проверить задержку от локального компьютера IR к региону Azure, чем лучше.

  • Убедитесь, что выходная пропускная способность компьютера локально размещаемой IR достаточно велика для эффективной передачи и записи данных. Если хранилище данных приемника находится в Azure, можно использовать средство this для проверки скорости отправки.

  • Проверьте, является ли тенденция использования ЦП и памяти локальной среды IR на портале Azure -> вашей фабрике данных или рабочей области Synapse -> обзорной странице. Рассмотрите возможность масштабирования IR вверх/наружу, если использование ЦП велико или доступная память мала.

  • Проверьте, сообщает ли служба об ошибке регулирования в приемнике, а также находится ли хранилище данных в состоянии высокой загрузки. Если это так, либо сократите рабочие нагрузки в хранилище данных, либо попробуйте обратиться к администратору хранилища данных, чтобы увеличить предел регулирования или объем доступных ресурсов.

  • Рассмотрите возможность постепенной настройки параллельных копий. Слишком много параллельных копий может даже повредить производительности.

Производительность соединителя и IR

В этом разделе рассматриваются некоторые инструкции по устранению проблем с производительностью для определенного типа соединителя или среды выполнения интеграции.

Время выполнения действий варьируется при использовании Azure IR и Azure виртуальной сети IR.

Время выполнения операции меняется, когда набор данных основывается на различных Integration Runtime.

• Симптомы: простое переключение раскрывающегося меню "Связанная служба" в наборе данных выполняет те же действия конвейера, однако показывает совершенно разные значения времени выполнения. Если набор данных основан на Managed виртуальная сеть Integration Runtime, это занимает больше времени по сравнению с работой на Default Integration Runtime.

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

Низкая производительность при загрузке данных в База данных SQL Azure

• Symptoms: копирование данных в База данных SQL Azure становится медленным.

• Cause: основная причина проблемы в основном вызвана узким местом База данных SQL Azure. Ниже представлены некоторые возможные причины.

  • уровень База данных SQL Azure недостаточно высокий.

  • Использование DTU в База данных SQL Azure приближается к 100%. Вы можете мониторить производительность и вам следует рассмотреть обновление уровня База данных SQL Azure.

  • Индексы не заданы должным образом. Удалите все индексы перед загрузкой данных и создайте их повторно после завершения загрузки.

  • WriteBatchSize недостаточно велик, чтобы соответствовать размеру строки схемы. Попробуйте увеличить свойство для решения этой проблемы.

  • Вместо массовой вставки используется хранимая процедура, которая, как ожидается, может ухудшить производительность.

Тайм-аут или низкая производительность при анализе большого файла Excel

• Симптомы

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

  • При использовании действия копирования для копирования данных из большого файла Excel (>= 100 МБ) в другое хранилище данных может возникнуть низкая производительность или проблема с OOM.

• Причина.

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

  • Действие копирования считывает весь файл Excel в память, затем определяет указанный лист и ячейки для чтения данных. Это поведение вызвано базовым пакетом SDK, используемым службой.

• Решение.

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

  • Для перечисления листа в раскрывающемся списке можно выбрать "Изменить" и ввести имя или индекс листа.

  • Чтобы скопировать большой файл Excel (>100 МБ) в другое хранилище, можно использовать источник Поток данных Excel, который поддерживает потоковое считывание и работает лучше.

Проблема OOM с чтением больших JSON/Excel/XML-файлов

• Симптомы: При чтении больших файлов JSON/Excel/XML возникает проблема с недостаточной памятью во время выполнения операции.

• Причина.

  • Для больших XML-файлов: проблема OOM при чтении больших XML-файлов является намеренной. Причина заключается в том, что весь XML-файл должен быть считан в память, так как он является одним объектом, затем схема выводится и извлекаются данные.
  • Для больших файлов Excel: проблема OOM при чтении больших файлов Excel является особенностью конструкции. Причина заключается в том, что пакет SDK (POI/NPOI) должен считывать весь файл excel в память, а затем выводить схему и получать данные.
  • Для больших JSON-файлов: проблема OOM при чтении больших JSON-файлов является преднамеренной особенностью дизайна, если JSON-файл представляет собой один объект.

• Рекомендация. Примените один из следующих вариантов для решения проблемы.

  • Вариант-1: Регистрация локальной интеграционной среды выполнения с мощным компьютером (высоким объемом ЦП и памяти) для чтения данных из большого файла с помощью операции копирования.
  • Вариант-2: Используйте оптимизированную память и кластер больших размеров (например, 48 ядер) для чтения данных из большого файла с помощью активности потоков данных сопоставления.
  • Вариант-3: Разделите большой файл на небольшие, затем используйте действие копирования или сопоставления потока данных для чтения папки.
  • Option-4. Если вы застряли или столкнулись с проблемой нехватки памяти (OOM) во время копирования папки XML/Excel/JSON, используйте действие foreach и действие потоков копирования/сопоставления данных в вашем конвейере для обработки каждого файла или вложенной папки.
  • Вариант-5: другие:
    • Для XML используйте действие Notebook с оптимизированным для памяти кластером для чтения данных из файлов, если каждый файл имеет одну и ту же схему. В настоящее время Spark имеет различные реализации для обработки XML.
    • Для JSON используйте различные формы документов (например, один документ, документ на строку и массив документов) в параметрах JSON в разделе сопоставления источника потока данных. Если содержимое JSON-файла является документом для каждой строки, оно потребляет мало памяти.

Прочие ссылки

Ниже приведены ссылки на мониторинг производительности и настройку некоторых поддерживаемых хранилищ данных:

• Azure хранилище BLOB-объектов: Показатели производительности и масштабируемости для хранилища BLOB-объектов и Контрольный список производительности и масштабируемости для хранилища BLOB-объектов.
• Azure хранилище таблиц: Масштабируемость и показатели производительности для хранилища таблиц и Контрольный список производительности и масштабируемости для хранилища таблиц.
• База данных SQL Azure: Вы можете контролировать производительность и проверить процент использования транзакционных единиц базы данных (DTU).
• Azure Synapse Analytics: его возможности измеряются в единицах хранилища данных (DWUs). См. раздел Управление вычислительными ресурсами в Azure Synapse Analytics (Обзор).
• Azure Cosmos DB: уровни производительности в Azure Cosmos DB.
• SQL Server: Мониторинг и настройка производительности.
• Локальный файловый сервер: настройка производительности для файловых серверов.

Связанный контент

См. другие статьи об операциях копирования:

• Обзор операции копирования
• Руководство по производительности и масштабируемости Действия копирования
• Функции оптимизации производительности для действия копирования
• Перенесите данные из озера данных или хранилища данных в Azure
• Переносите данные из Amazon S3 в служба хранилища Azure