Миграция данных, ETL и загрузка для миграции Netezza

Эта статья представляет собой вторую из семи статей, посвященных рекомендациям по переходу от Netezza к Azure Synapse Analytics. Эта статья посвящена рекомендациям по переносу процессов ETL и нагрузки.

Рекомендации по переносу данных

Первоначальные решения по переносу данных из Netezza

При переносе хранилища данных Netezza необходимо задать некоторые основные вопросы, связанные с данными. Пример:

• Следует ли переносить неиспользуемые структуры таблиц?

• Каков оптимальный подход к миграции для минимизации рисков и воздействия на пользователей?

• При переносе киосков данных они должны оставаться физическими или виртуальными?

В следующих разделах эти моменты рассматриваются в контексте миграции из Netezza.

Переносить неиспользуемые таблицы?

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

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

Ниже приведен пример запроса, который ищет использование определенной таблицы в течение заданного периода времени:

SELECT FORMAT_TABLE_ACCESS (usage),
  hq.submittime
FROM "$v_hist_queries" hq
  INNER JOIN "$hist_table_access_3" hta USING
(NPSID, NPSINSTANCEID, OPID, SESSIONID)
WHERE hq.dbname = 'PROD'
AND hta.schemaname = 'ADMIN'
AND hta.tablename = 'TEST_1'
AND hq.SUBMITTIME > '01-01-2015'
AND hq.SUBMITTIME <= '08-06-2015'
AND
(
  instr(FORMAT_TABLE_ACCESS(usage),'ins') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'upd') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
)
AND status=0;

| FORMAT_TABLE_ACCESS | SUBMITTIME
----------------------+---------------------------
ins                   | 2015-06-16 18:32:25.728042
ins                   | 2015-06-16 17:46:14.337105
ins                   | 2015-06-16 17:47:14.430995
(3 rows)

Этот запрос использует вспомогательную функцию FORMAT_TABLE_ACCESS и цифру в конце $v_hist_table_access_3 для сопоставления установленной версии журнала запросов.

Каков оптимальный подход к миграции для минимизации рисков и воздействия на пользователей?

Этот вопрос возникает часто, так как компании хотят снизить влияние изменений на модель данных хранилища данных для повышения гибкости. Компании часто видят возможность дальнейшей модернизации или преобразования данных во время миграции ETL. Такой подход сопряжен с более высоким риском, поскольку он изменяет несколько факторов одновременно, что затрудняет сравнение результатов старой и новой систем. Внесение изменений в модель данных также может повлиять на задания ETL для других, вышестоящих или нижестоящих, систем. Из-за этого риска лучше изменить масштаб после переноса хранилища данных.

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

При миграции из Netezza часто существующая модель данных уже подходит для переноса «как есть» в Azure Synapse.

При переносе киосков данных они должны оставаться физическими или становиться виртуальными?

В устаревших средах хранилища данных Netezza рекомендуется создавать несколько киосков данных, структурированных для обеспечения хорошей производительности для нерегламентированных запросов самообслуживания и отчетов для определенного отдела или бизнес-функции в организации. Таким образом, киоск данных обычно состоит из подмножества хранилища данных и содержит агрегированные версии данных в форме, которая позволяет пользователям легко запрашивать эти данные и быстро получать ответ с помощью удобных средств выполнения запросов, таких как Microsoft Power BI, Tableau или MicroStrategy. Эта форма обычно является многомерной моделью данных. Помимо прочего, киоски данных предоставляют данные в пригодной для использования форме, даже если базовая модель данных отличается, например имеет вид хранилища ("сейфа") данных.

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

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

С появлением относительно недорогих масштабируемых архитектур MPP, таких как Azure Synapse, и присущих таким архитектурам характеристик производительности, возможно, вы сможете обеспечить функциональность киоска данных, не создавая экземпляр киоска в виде набора физических таблиц. Это достигается путем эффективной виртуализации киосков данных с помощью представлений SQL в основном хранилище данных или с помощью слоя виртуализации с использованием таких функций, как представления в Azure или продукты визуализации партнеров Майкрософт. Такой подход уменьшает или исключает необходимость в дополнительном хранилище и статистической обработке и сокращает общее количество переносимых объектов базы данных.

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

Основные факторы для выбора в пользу реализации виртуального киоска данных вместо физического:

• Гибкость — виртуальный киоск данных изменить легче, чем физические таблицы и связанные с ним процессы извлечения, преобразования и загрузки.

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

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

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

Перенос данных из Netezza

Анализ данных

Частью планирования миграции является детальное понимание объема данных, которые необходимо перенести, так как это может повлиять на решение о подходе к переносу. Для определения физического пространства, занимаемого необработанными данными в таблицах для переноса, используйте системные метаданные. В этом контексте термин "необработанные данные" означает объем пространства, используемого строками данных в таблице, за исключением издержек, таких как индексы и сжатие. Это особенно актуально для самых больших по объему таблиц фактов, так как они обычно составляют более 95 % данных.

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

Сопоставление типов данных Netezza

Большинство типов данных Netezza имеют прямой эквивалент в Azure Synapse. В таблице ниже представлены эти типы данных вместе с рекомендованными способами работы.

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

• _V_USER: представление пользователя предоставляет сведения о пользователях в системе Netezza.

• _V_TABLE: представление таблицы содержит список таблиц, созданных в системе производительности Netezza.

• _V_RELATION_COLUMN: представление системного каталога реляционных столбцов содержит столбцы, доступные в таблице.

• _V_OBJECTS: в представлении объектов перечислены различные объекты, такие как таблицы, представления, функции и т. д., доступные в Netezza.

Например, этот запрос Netezza SQL показывает столбцы и типы столбцов:

SELECT
tablename,
  attname AS COL_NAME,
  b.FORMAT_TYPE AS COL_TYPE,
  attnum AS COL_NUM
FROM _v_table a
  JOIN _v_relation_column b
  ON a.objid = b.objid
WHERE a.tablename = 'ATT_TEST'
AND a.schema = 'ADMIN'
ORDER BY attnum;

TABLENAME | COL_NAME    | COL_TYPE             | COL_NUM
----------+-------------+----------------------+--------
ATT_TEST  | COL_INT     | INTEGER              | 1
ATT_TEST  | COL_NUMERIC | NUMERIC(10,2)        | 2
ATT_TEST  | COL_VARCHAR | CHARACTER VARYING(5) | 3
ATT_TEST  | COL_DATE    | DATE                 | 4
(4 rows)

Запрос можно изменить для поиска во всех таблицах любых вхождений неподдерживаемых типов данных.

Фабрику данных Azure можно использовать для перемещения данных из устаревшей среды Netezza. Дополнительные сведения см. в статье Соединитель IBM Netezza.

Сторонние поставщики предлагают средства и службы для автоматизации миграции, включая сопоставление типов данных, как описано выше. Также, сторонние инструменты извлечения, преобразования и загрузки, такие как Informatica или Talend, которые уже используется в среде IBM Netezza, могут реализовать все необходимые преобразования данных. В следующем разделе рассматривается миграция существующих сторонних процессов извлечения, преобразования и загрузки.

Рекомендации по миграции ETL

Первоначальные решения по миграции Netezza ETL

Для обработки ETL/ELT устаревшие хранилища данных Netezza могут использовать пользовательские скрипты с помощью служебных программ Netezza, таких как nzsql и nzload, или сторонние средства ETL, такие как Informatica или Ab Initio. Иногда хранилища данных Netezza используют сочетание подходов ETL и ELT, которые развивались с течением времени. При планировании миграции на Azure Synapse необходимо определить оптимальный способ реализации необходимой обработки ETL/ELT в новой среде, минимизируя затраты и риски. Дополнительные сведения об обработке ETL и ELT см. в статье Подход к проектированию: ELT и ETL.

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

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

В предыдущей блок-схеме решение 1 относится к решению высокого уровня о том, следует ли полностью переходить на собственную среду Azure. Если вы переходите на собственную среду Azure, рекомендуется перепроектировать обработку ETL с помощью конвейеров и действий в Фабрике данных Azure или Azure Synapse Pipelines. Если вы не переходите на собственную среду Azure, то решение 2 заключается в том, используется ли уже существующее стороннее средство ETL.

Если стороннее средство ETL уже используется и особенно если имеется большой объем вложений в приобретение навыков либо несколько существующих рабочих процессов и расписаний используют это средство, тогда решение 3 будет заключаться в том, сможет ли это средство эффективно поддерживать Azure Synapse в качестве целевой среды. В идеале это средство будет включать в себя встроенные соединители, которые могут использовать такие средства Azure, как PolyBase или COPY INTO, для наиболее эффективной загрузки данных. Существует способ вызова внешнего процесса, например PolyBase или COPY INTO, и передачи соответствующих параметров. В этом случае используйте существующие навыки и рабочие процессы с Azure Synapse в качестве новой целевой среды.

Если вы решите сохранить существующее средство ETL стороннего производителя, возможно, будет целесообразно запустить это средство в среде Azure (а не на существующем локальном сервере ETL), а Фабрика данных Azure будет выполнять общую оркестрацию существующих рабочих процессов. Одним из конкретных преимуществ является то, что загружать из Azure, обрабатывать и затем загружать обратно в Azure необходимо меньшее количество данных. Таким образом, решение 4 заключается в том, следует ли оставить существующее средство запущенным как есть или переместить его в среду Azure для получения преимуществ, касающихся стоимости, производительности и масштабируемости.

Перепроектируйте существующие скрипты Netezza

Если некоторые или все существующие операции обработки ETL/ELT хранилища Netezza обрабатываются пользовательскими скриптами, которые используют служебные программы Netezza, такие как nzsql или nzload, эти скрипты необходимо перекодировать для новой среды Azure Synapse. Аналогичным образом, если процессы ETL были реализованы с помощью хранимых процедур в Netezza, их также придется перекодировать.

Некоторые элементы процесса ETL переносятся легко, например путем простой массовой загрузки данных в промежуточную таблицу из внешнего файла. Возможно, даже можно автоматизировать эти части процесса, например, с помощью PolyBase вместо nzload. Другие части процесса, которые содержат произвольные сложные SQL и (или) хранимые процедуры, потребуют больше времени для повторной перепроектировки.

Один из способов тестирования Netezza SQL для обеспечения совместимости с Azure Synapse заключается в сборе некоторых репрезентативных SQL инструкций из журнала запросов Netezza, а затем добавить префикс к запросам с помощью EXPLAIN, и (при условии, что модель данных похожа на подобные переносимые данные в Azure Synapse), выполнить эти инструкции EXPLAIN в Azure Synapse. Любая несовместимость SQL вызовет ошибку, а сведения об ошибке могут определить масштаб задачи перекодировки.

Партнеры Майкрософт предлагают средства и службы для переноса Netezza SQL и хранимых процедур в Azure Synapse.

Использование сторонних средств извлечения, преобразования и загрузки

Как описано в предыдущем разделе, во многих случаях существующая устаревшая система хранилища данных уже заполняется и поддерживается сторонними продуктами ETL. Список партнеров Майкрософт по интеграции данных для Azure Synapse см. в разделе Партнеры по интеграции данных.

Загрузка данных из Netezza

Доступные варианты при загрузке данных из Netezza

При переносе данных из хранилища данных Netezza существуют некоторые основные вопросы, связанные с загрузкой данных, которые необходимо устранить. Вам потребуется решить, как данные будут физически перемещены из существующей локальной среды Netezza в Azure Synapse в облаке, а также какие средства будут использоваться для выполнения передачи и загрузки. Обратите внимание на перечисленные ниже вопросы, которые описаны в следующих разделах.

• Вы будете извлекать данные в файлы или перемещать их непосредственно через сетевое подключение?

• Оркестрация процесса будет выполняться из исходной системы или из целевой среды Azure?

• Какие средства будут использоваться для автоматизации и контроля процесса?

Передача данных должна осуществляться через файлы или сетевое подключение?

После создания таблиц базы данных, которые будут перенесены в Azure Synapse, можно переместить данные для заполнения этих таблиц из устаревшей системы Netezza в новую среду. Существует два основных подхода:

• Извлечение файла: извлеките данные из таблиц Netezza в неструктурированные файлы, обычно в формате CSV, с помощью nzsql с параметром -o или с помощью инструкции CREATE EXTERNAL TABLE. Используйте по возможности внешнюю таблицу, так как она наиболее эффективна с точки зрения пропускной способности данных. Следующей пример SQL создает CSV-файл через внешнюю таблицу:

  CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',')
  AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;
  

  При экспорте данных в подключенную файловую систему на локальном узле Netezza используйте внешнюю таблицу. Если вы экспортировали данные на удаленный компьютер, на котором установлен JDBC, ODBC или OLEDB, то параметр remotesource odbc будет предложением USING.

  Для этого подхода требуется место для размещения извлеченных файлов данных. Пространство может быть локальным для базы данных-источника Netezza (если доступно достаточное хранилище) или удаленным в Хранилище BLOB-объектов Azure. Оптимальная производительность достигается при локальной записи файла, так как это позволяет избежать сетевых издержек.

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

  После извлечения неструктурированные файлы можно переместить в Хранилище BLOB-объектов Azure (размещенном совместно с целевым экземпляром Azure Synapse) или загрузить непосредственно в Azure Synapse с помощью PolyBase или COPY INTO. Метод физического перемещения данных из локального хранилища в облачную среду Azure зависит от объема данных и доступной пропускной способности сети.

  Корпорация Майкрософт предоставляет различные возможности перемещения больших объемов данных, включая AzCopy для перемещения файлов по сети в службу хранилища Azure, Azure ExpressRoute для перемещения массовых данных через частное сетевое подключение и Azure Data Box для файлов, перемещаемых на физическое устройство хранения, которое затем отправляется в центр обработки данных Azure для загрузки. Дополнительные сведения см. в разделе Передача данных.

• Прямое извлечение и загрузка по сети: целевая среда Azure отправляет запрос на извлечение данных( обычно с помощью команды SQL) в устаревшую систему Netezza для извлечения данных. Результаты отправляются по сети и загружаются непосредственно в Azure Synapse без необходимости помещать данные в промежуточные файлы. Ограничивающий фактор в этом сценарии обычно является пропускной способностью сетевого подключения между базой данных Netezza и средой Azure. Для очень больших объемов данных такой подход может оказаться нецелесообразным.

Существует также гибридный подход, при котором используются оба метода. Например, для небольших таблиц измерений и образцов больших таблиц фактов можно использовать метод непосредственного извлечения по сети, чтобы быстро предоставить тестовую среду в Azure Synapse. Для таблиц исторических фактов большого объема можно использовать метод извлечения и передачи файлов с помощью Azure Data Box.

Оркестрация осуществляется из Netezza или Azure?

Рекомендуемый подход при переходе на Azure Synapse заключается в оркестрации извлечения и загрузки данных из среды Azure с помощью Azure Synapse Pipelines или Фабрики данных Azure, а также связанных служебных программ, таких как PolyBase или COPY INTO, для максимально эффективной загрузки данных. Этот подход использует возможности Azure и предоставляет простой метод для создания конвейеров загрузки повторно используемых данных.

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

Какие средства можно использовать?

Задача преобразования и перемещения данных является основной функцией всех продуктов извлечения, преобразования и загрузки. Если один из этих продуктов уже используется в существующей среде Netezza, использование существующего средства ETL может упростить перенос данных из Netezza в Azure Synapse. Этот подход предполагает, что средство ETL поддерживает Azure Synapse в качестве целевой среды. Дополнительные сведения о средствах, поддерживающих Azure Synapse, см. в статье Партнеры по интеграции данных.

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

Сводка

Ниже приведены рекомендации по переносу данных и связанных процессов ETL из Netezza в Azure Synapse:

• Планируйте заранее, чтобы обеспечить успешную миграцию.

• Как можно скорее создайте подробный список данных и процессов, которые необходимо перенести.

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

• Определите объем данных, которые необходимо перенести, и пропускную способность сети между локальным центром обработки данных и облачными средами Azure.

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

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

• Используйте такие средства Azure, как Azure Synapse Pipelines или Фабрика данных Azure, для оркестрации и автоматизации процесса миграции, минимизируя влияние на систему Netezza.

Дальнейшие действия

Дополнительные сведения об операциях доступа к безопасности см. в следующей статье этой серии: Безопасность, доступ и операции для миграций Netezza.