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

Эта статья является частью двух из семи частей серии, которая содержит рекомендации по миграции из Teradata в Azure Synapse Analytics. Эта статья посвящена лучшим практикам для ETL-процессов и миграции нагрузки.

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

Первоначальные решения по миграции данных из Teradata

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

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

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

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

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

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

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

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

Ниже приведен пример запроса, DBC.Tables который предоставляет дату последнего доступа и последнего изменения:

SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName,
LastAlterTimeStamp, AccessCount, LastAccessTimeStamp 
FROM DBC.Tables t
WHERE DataBaseName = 'databasename'

Если ведение журнала включено, а журнал журналов доступен, другие сведения, такие как текст SQL-запроса, доступны в таблице DBQLogTbl и связанных таблицах ведения журнала. Дополнительные сведения см. в истории журналов Teradata.

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

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

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

При миграции из Teradata рекомендуется создать среду Teradata на виртуальной машине в Azure в качестве пошагового камня в процессе миграции.

Использование экземпляра виртуальной машины Teradata в процессе миграции

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

Благодаря этому подходу стандартные служебные программы Teradata, такие как Teradata Parallel Data Transporter или сторонние средства репликации данных, такие как Attunity Replication, можно использовать для эффективного перемещения подмножества таблиц Teradata, которые необходимо перенести в экземпляр виртуальной машины. Затем все задачи миграции могут выполняться в среде Azure. Такой подход имеет несколько преимуществ.

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

• В среде Azure имеются знакомые интерфейсы Teradata, инструменты и служебные программы.

• Среда Azure обеспечивает доступность пропускной способности сети между локальной исходной системой и облачной целевой системой.

• Такие инструменты, как Фабрика данных Azure, могут эффективно вызывать служебные программы, такие как Teradata Parallel Transporter, чтобы быстро и легко перенести данные.

• Процесс миграции осуществляется полностью внутри среды Azure.

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

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

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

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

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

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

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

• Больше гибкости: виртуальную витрину данных изменить легче, чем физические таблицы и связанные с ними процессы извлечения, преобразования и загрузки (ETL).

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

• Устранение заданий ETL для упрощения архитектуры хранилища данных и миграции в виртуализированной среде.

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

Миграция данных из Teradata

Поймите свои данные

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

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

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

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

Для обработки ETL/ELT устаревшие хранилища данных Teradata могут использовать пользовательские скрипты с помощью служебных программ Teradata, таких как BTEQ и Teradata Parallel Transporter (TPT), или сторонние средства ETL, такие как Informatica или Ab Initio. Иногда хранилища данных Teradata используют сочетание подходов ETL и ELT, которые развиваются с течением времени. При планировании миграции в Azure Synapse необходимо определить оптимальный способ реализации требуемой обработки ETL/ELT в новой среде при минимизации затрат и рисков. Дополнительные сведения об обработке ETL и ELT см. в статье о подходе к проектированию ELT и ETL.

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

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

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

В среде Teradata некоторые или все операции обработки ETL могут выполняться пользовательскими скриптами с помощью служебных программ Teradata, таких как BTEQ и TPT. В этом случае ваш подход должен заключаться в переосмыслении с использованием Data Factory.

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

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

Перепроектировать существующие скрипты, конкретные для Teradata

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

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

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

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

Использование сторонних средств ETL

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

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

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

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

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

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

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

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

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

• Извлечение файла: извлеките данные из таблиц Teradata в неструктурированные файлы, обычно в формате CSV, с помощью BTEQ, быстрого экспорта или Teradata Parallel Transporter (TPT). Используйте TPT по возможности, так как это наиболее эффективно с точки зрения пропускной способности данных.

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

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

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

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

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

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

Оркестрация из Teradata или из Azure?

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

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

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

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

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

Сводка

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

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

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

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

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

• Рассмотрите возможность использования экземпляра Teradata на виртуальной машине Azure в качестве пошагового камня для разгрузки миграции из устаревшей среды Teradata.

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

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

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

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

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