Share via

Использование Фабрики данных Azure для переноса данных из локального кластера Hadoop в хранилище Azure

  • Статья

Область применения:Фабрика данных Azure Azure Synapse Analytics

Совет

Попробуйте использовать фабрику данных в Microsoft Fabric, решение для аналитики с одним интерфейсом для предприятий. Microsoft Fabric охватывает все, от перемещения данных до обработки и анализа данных в режиме реального времени, бизнес-аналитики и отчетности. Узнайте, как бесплатно запустить новую пробную версию !

Фабрика данных Azure предоставляет производительный, надежный и экономичный механизм для масштабного переноса данных из локальной файловой системы HDFS в хранилище BLOB-объектов Azure или Azure Data Lake Storage 2-го поколения.

Фабрика данных предлагает два основных подхода к переносу данных из локальной файловой системы HDFS в Azure. Можно выбрать подход в соответствии со своим сценарием.

  • Режим DistCp Фабрики данных Azure (рекомендуется): в Фабрике данных Azure можно использовать DistCp (распределенное копирование) для копирования файлов как есть в хранилище BLOB-объектов Azure (включая поэтапное копирование) или Azure Data Lake Store 2-го поколения. Используйте фабрику данных, интегрированную с DistCp, чтобы воспользоваться преимуществами существующего мощного кластера для достижения максимальной пропускной способности копирования. Кроме того, вы получаете преимущества гибкого планирования и единого мониторинга в фабрике данных. В зависимости от конфигурации фабрики данных при выполнении копирования автоматически создается команда DistCp, данные отправляются в кластер Hadoop, а затем отслеживается состояние копирования. Мы рекомендуем использовать режим фабрики данных DistCp для переноса данных из локального кластера Hadoop в Azure.
  • Режим среды выполнения интеграции платформенной функциональности фабрики данных: DistCp подходит не для всех сценариев. Например, в среде виртуальных сетей Azure инструмент DistCp не поддерживает частный пиринг Azure ExpressRoute с конечной точкой виртуальной сети службы хранилища Azure. Кроме того, в некоторых случаях нежелательно использовать существующий кластер Hadoop в качестве подсистемы для переноса данных, чтобы не перегружать кластер, что может повлиять на производительность выполнения существующих заданий ETL. Вместо этого вы можете использовать встроенные возможности среды выполнения интеграции фабрики данных в качестве механизма, копирующего данные из локальной файловой системы HDFS в Azure.

В этой статье содержатся следующие сведения по обоим подходам.

  • Производительность
  • Устойчивость копирования
  • Сетевая безопасность
  • Общая архитектура решения
  • Рекомендации по реализации

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

В режиме фабрики данных DistCp пропускная способность такая же, как при автономном использовании инструмента DistCp. Режим фабрики данных DistCp позволяет максимально увеличить емкость существующего кластера Hadoop. Можно использовать DistCp для крупномасштабного межкластерного или внутрикластерного копирования.

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

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

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

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

Устойчивость

В режиме фабрики данных DistCp можно использовать разные параметры командной строки DistCp (например, -i, игнорировать сбои или -update, записывать данные, когда исходный файл и файл назначения различаются по размеру) для разных уровней устойчивости.

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

При выполнении двоичного копирования из локальной системы HDFS в хранилище BLOB-объектов и в Data Lake Store 2-го поколения фабрика данных автоматически проверяет контрольные точки для большего количества объектов. Если при выполнении операции копирования происходит сбой или истекает время ожидания, при последующей повторной попытке (убедитесь, что значение счетчика повторных попыток > 1) копирование возобновляется с последней точки сбоя, а не с начала.

Сетевая безопасность

По умолчанию фабрика данных передает данные из локальной системы HDFS в хранилище BLOB-объектов или Azure Data Lake Storage 2-го поколения с использованием зашифрованного соединения по протоколу HTTPS. HTTPS обеспечивает шифрование данных при передаче и предотвращает прослушивание трафика и атаки типа "злоумышленник в середине".

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

Архитектура решения

На этом рисунке показан перенос данных через общедоступный Интернет.

Diagram that shows the solution architecture for migrating data over a public network

  • В этой архитектуре данные передаются безопасно по протоколу HTTPS через общедоступный Интернет.
  • Рекомендуется использовать режим фабрики данных DistCp в общедоступной сетевой среде. Можно воспользоваться существующим мощным кластером для достижения максимальной пропускной способности при выполнении копирования. Кроме того, вы получаете преимущества гибкого планирования и единого мониторинга в фабрике данных.
  • Для этой архитектуры необходимо установить локальную среду выполнения интеграции фабрики данных на компьютере с ОС Windows, не используя корпоративный брандмауэр, чтобы отправить команду DistCp в кластер Hadoop и контролировать состояние копирования. Поскольку машина не является подсистемой, которая будет перемещать данные (только для целей управления), мощность машины не влияет на пропускную способность перемещения данных.
  • Поддерживаются существующие параметры команды DistCp.

На этом рисунке показан перенос данных по приватному каналу.

Diagram that shows the solution architecture for migrating data over a private network

  • В этой архитектуре данные переносятся с использованием частной пиринговой связи в Azure ExpressRoute. Данные никогда не проходят через общедоступный Интернет.
  • Инструмент DistCp не поддерживает частный пиринг ExpressRoute с конечной точкой виртуальной сети службы хранилища Azure. Рекомендуется использовать собственные возможности фабрики данных в среде выполнения интеграции для переноса данных.
  • Для этой архитектуры необходимо установить локальную среду выполнения интеграции фабрики данных на виртуальной машине Windows в виртуальной сети Azure. Можно вручную выполнить масштабирование до уровня виртуальной машины или нескольких виртуальных машин, чтобы полностью использовать операции ввода-вывода (в сек) или пропускную способность сети и хранилища.
  • Рекомендуемая исходная конфигурация для каждой виртуальной машины Azure (с установленной локальной средой выполнения интеграции фабрики данных) — Standard_D32s_v3 с 32 виртуальными ЦП и 128 Гбайт памяти. Можно отслеживать использование ЦП и памяти виртуальной машины во время переноса данных, чтобы узнать, нужно ли масштабировать виртуальную машину для повышения производительности или снижения затрат.
  • Также можно выполнить масштабирование, связав до четырех узлов виртуальных машин с одной локальной средой выполнения интеграции. При выполнении одного задания копирования в локальной среде выполнения интеграции соответствующий набор файлов автоматически разбивается и используются все узлы виртуальных машин для параллельного копирования файлов. Для обеспечения высокой доступности рекомендуется начать с двух узлов виртуальных машин, чтобы избежать сценария единой точки отказа во время переноса данных.
  • При использовании этой архитектуры доступен перенос данных исходного моментального снимка и перенос дельта-данных.

Рекомендации по реализации

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

Управление проверкой подлинности и учетными данными

Перенос исходных моментальных снимков

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

В режиме среды выполнения интеграции платформенной функциональности фабрики данных рекомендуется разделение данных, особенно при переносе данных объемом более 10 Тбайт. Чтобы разделить данные, используйте имена папок в HDFS. Далее при выполнении каждого задания копирования в фабрике данных может копироваться одновременно один раздел папки. Можно запускать несколько заданий копирования в фабрике данных одновременно для повышения пропускной способности.

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

Перенос разностных данных

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

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

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

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

Ориентировочная цена

Рассмотрим следующий конвейер для переноса данных из HDFS в хранилище BLOB-объектов Azure.

Diagram that shows the pricing pipeline

Предположим, что у вас есть следующая информация.

  • Общий объем данных составляет 1 Пбайт.
  • Выполняется перенос данных с использованием режима среды выполнения интеграции платформенной функциональности фабрики данных.
  • 1 Пбайт разделен на 1000 разделов, и каждая копия перемещает один раздел.
  • Каждая операция копирования настраивается с использованием одной локальной среды выполнения интеграции, связанной с четырьмя машинами и обеспечивающей пропускную способность 500 Мбайт/с.
  • Степень параллелизма ForEach имеет значение 4, а суммарная пропускная способность — 2 Гбайт/с.
  • В итоге для выполнения переноса потребуется 146 часов.

Ориентировочная цена, основанная на приведенной выше информации:

Table that shows pricing calculations

Примечание.

Это гипотетический пример цен. Реальная цена зависит от фактической пропускной способности в среде. Цена на виртуальную машину Windows Azure (с установленной локальной средой выполнения интеграции) не включена.

Дополнительная справка

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