Поделиться через

Миграция: выделенные пулы SQL Azure Synapse Analytics в Fabric

  • Статья

Область применения:✅ хранилище в Microsoft Fabric

В этой статье описана стратегия, рекомендации и методы миграции хранилища данных в выделенных пулах SQL Azure Synapse Analytics в хранилище Microsoft Fabric.

Введение в миграцию

Как корпорация Майкрософт представила Microsoft Fabric, решение для аналитики SaaS для предприятий, которое предлагает полный набор служб, включая фабрику данных, Инжиниринг данных, Хранилище данных, Обработка и анализ данных, аналитику в режиме реального времени и Power BI.

В этой статье рассматриваются параметры миграции схемы (DDL), миграции кода базы данных (DML) и миграции данных. Корпорация Майкрософт предлагает несколько вариантов, и здесь мы подробно обсудим каждый вариант и укажите рекомендации по каким из этих вариантов следует рассмотреть для вашего сценария. В этой статье используется эталонный показатель отрасли TPC-DS для иллюстрации и тестирования производительности. Фактический результат может отличаться в зависимости от многих факторов, включая тип данных, типы данных, ширину таблиц, задержку источника данных и т. д.

Подготовка к переносу

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

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

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

Схема жизненного цикла миграции.

Модуль Runbook для миграции

Рассмотрим следующие действия в качестве модуля runbook планирования для миграции из выделенных пулов SQL Synapse в хранилище Fabric.

  1. Оценка и оценка
    1. Определите цели и мотивы. Определите четкие нужные результаты.
    2. Обнаружение, оценка и базовый план существующей архитектуры.
    3. Определите ключевых заинтересованных лиц и спонсоров.
    4. Определите область переноса.
      1. Начните с малого и простого, подготовьтесь к нескольким небольшим миграциям.
      2. Начните отслеживать и документировать все этапы процесса.
      3. Составьте список данных и процессов для миграции.
      4. Определите изменения модели данных (при их наличии).
      5. Настройте рабочую область Fabric.
    5. Что такое набор навыков или предпочтения?
      1. Автоматизируйте все, что возможно.
      2. Используйте встроенные средства и функции Azure для уменьшения усилий по миграции.
    6. Сразу же проведите обучение персонала на новой платформе.
      1. Определите потребности и учебные ресурсы, включая Microsoft Learn.
  2. Планирование и проектирование
    1. Определите нужную архитектуру.
    2. Выберите метод или инструменты для миграции, чтобы выполнить следующие задачи:
      1. Извлечение данных из источника.
      2. Преобразование схемы (DDL), включая метаданные для таблиц и представлений
      3. Прием данных, включая исторические данные.
        1. При необходимости повторно спроектировать модель данных с помощью новой платформы производительности и масштабируемости.
      4. Миграция кода базы данных (DML).
        1. Произведите миграцию или рефакторинг хранимых процедур и бизнес-процессов.
    3. Инвентаризация и извлечение функций безопасности и разрешений объектов из источника.
    4. Проектирование и планирование замены и изменения существующих процессов ETL/ELT для добавочной нагрузки.
      1. Создайте параллельные процессы ETL/ELT в новой среде.
    5. Подготовьте подробный план миграции.
      1. Сопоставляйте текущее состояние с новым требуемым состоянием.
  3. анализа
    1. Выполнение схемы, данных, миграции кода.
      1. Извлечение данных из источника.
      2. Преобразование схемы (DDL)
      3. Прием данных
      4. Миграция кода базы данных (DML).
    2. При необходимости масштабируйте выделенные ресурсы пула SQL временно, чтобы ускорить миграцию.
    3. Применение безопасности и разрешений.
    4. Перенос существующих процессов ETL/ELT для добавочной нагрузки.
      1. Произведите миграцию или рефакторинг процессов добавочной загрузки в рамках извлечения, преобразования и загрузки или извлечения, загрузки и преобразования.
      2. Тестирование и сравнение параллельных процессов добавочной нагрузки.
    5. При необходимости адаптируйте план миграции подробных сведений.
  4. Мониторинг и управление
    1. Параллельно выполните сравнение с исходной средой.
      1. Тестирование приложений, платформ бизнес-аналитики и средств запросов.
      2. Протестируйте и оптимизируйте производительность запросов.
      3. Отслеживайте затраты, безопасность и производительность и управляйте ими.
    2. Контрольный показатель управления и оценка.
  5. Оптимизация и модернизация
    1. Когда бизнес удобнее, переход приложений и основных платформ отчетов в Fabric.
      1. Масштабирование ресурсов вверх и вниз по мере перемещения рабочих нагрузок из Azure Synapse Analytics в Microsoft Fabric.
      2. Создайте повторяемый шаблон из опыта, полученного для будущих миграций. Повторять.
      3. Определение возможностей оптимизации затрат, безопасности, масштабируемости и эффективности эксплуатации
      4. Определите возможности модернизации ресурсов данных с помощью новейших функций Fabric.

"Лифт и смена" или модернизация?

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

Методика lift-and-shift

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

Миграция lift-and-shift подходит для следующих сценариев:

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

В итоге этот подход хорошо подходит для этих рабочих нагрузок, оптимизированных для текущей среды выделенных пулов SQL Synapse, поэтому не требует значительных изменений в Fabric.

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

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

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

Различия в проектировании: выделенные пулы SQL Synapse и хранилище Fabric

Рассмотрим следующие различия в хранилище данных Azure Synapse и Microsoft Fabric, сравнивая выделенные пулы SQL с хранилищем Fabric.

Рекомендации по таблице

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

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

Рекомендации по T-SQL

Существует несколько различий синтаксиса языка обработки данных (DML). Обратитесь к области поверхности T-SQL в Microsoft Fabric. Рассмотрите также оценку кода при выборе методов миграции для кода базы данных (DML).

В зависимости от различий четности во время миграции может потребоваться переписать части кода DML T-SQL.

Различия в сопоставлении типов данных

В хранилище Fabric существует несколько различий типов данных. Дополнительные сведения см. в разделе "Типы данных" в Microsoft Fabric.

В следующей таблице представлено сопоставление поддерживаемых типов данных из выделенных пулов SQL Synapse с хранилищем Fabric.

Выделенные пулы SQL Synapse Хранилище Fabric
money decimal(19,4)
smallmoney decimal(10,4)
smalldatetime datetime2
datetime datetime2
nchar char
nvarchar varchar
tinyint smallint
binary varbinary
datetimeoffset* datetime2

* Datetime2 не сохраняет дополнительные сведения о смещения часовом поясе, хранящиеся в. Так как тип данных datetimeoffset в настоящее время не поддерживается в хранилище Fabric, данные смещения часового пояса должны быть извлечены в отдельный столбец.

Методы миграции схем, кода и данных

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

В этой таблице приведены сведения о схемах данных (DDL), коде базы данных (DML) и методах миграции данных. Далее мы рассмотрим каждый сценарий в этой статье, связанный в столбце Option .

Номер параметра Вариант Что он делает Навыки и предпочтения Сценарий
1 Фабрика данных Преобразование схемы (DDL)
Извлечение данных
Прием данных		 ADF/Pipeline Упрощено все в одной схеме (DDL) и миграции данных. Рекомендуется для таблиц измерений.
2 Фабрика данных с разделом Преобразование схемы (DDL)
Извлечение данных
Прием данных		 ADF/Pipeline Использование параметров секционирования для увеличения параллелизма чтения и записи, обеспечивающего пропускную способность 10x и вариант 1, рекомендуется для таблиц фактов.
3 Фабрика данных с ускоренным кодом Преобразование схемы (DDL) ADF/Pipeline Сначала преобразуйте и перенесите схему (DDL), а затем используйте CETAS для извлечения и копирования и фабрики данных для приема данных для оптимальной общей производительности приема.
4 Ускоренный код хранимых процедур Преобразование схемы (DDL)
Извлечение данных
Оценка кода		 T-SQL Пользователь SQL с помощью интегрированной среды разработки с более подробным контролем над задачами, над которыми они хотят работать. Используйте copy/Data Factory для приема данных.
5 расширение project База данных SQL для Azure Data Studio Преобразование схемы (DDL)
Извлечение данных
Оценка кода		 Проект SQL База данных SQL Project для развертывания с интеграцией варианта 4. Используйте COPY или Фабрику данных для приема данных.
6 CREATE EXTERNAL TABLE AS SELECT (CETAS) Извлечение данных T-SQL Экономичное и высокопроизводительные извлечение данных в Azure Data Lake Storage (ADLS) 2-го поколения. Используйте copy/Data Factory для приема данных.
7 Миграция с помощью dbt Преобразование схемы (DDL)
Преобразование кода базы данных (DML)		 dbt Существующие пользователи dbt могут использовать адаптер dbt Fabric для преобразования DDL и DML. Затем необходимо перенести данные с помощью других параметров в этой таблице.

Выбор рабочей нагрузки для начальной миграции

Если вы решите, где начать работу с выделенным пулом SQL Synapse в проект миграции хранилища Fabric, выберите рабочую нагрузку, в которой вы можете:

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

Совет

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

Объем перенесенных данных в начальной миграции должен быть достаточно большим, чтобы продемонстрировать возможности и преимущества среды хранилища Fabric, но не слишком большой, чтобы быстро продемонстрировать значение. Как правило, такой объем составляет от 1 до 10 терабайт.

Миграция с фабрикой данных Fabric

В этом разделе описаны варианты использования фабрики данных для пользователя с низким кодом или без кода, знакомых с Фабрика данных Azure и Конвейером Synapse. Этот параметр перетаскивания предоставляет простой шаг для преобразования DDL и переноса данных.

Фабрика данных Fabric может выполнять следующие задачи:

  • Преобразуйте схему (DDL) в синтаксис хранилища Fabric.
  • Создайте схему (DDL) в хранилище Fabric.
  • Перенос данных в хранилище Fabric.

Вариант 1. Миграция схемы и данных — мастер копирования и действие копирования forEach

Этот метод использует помощник по копированию фабрики данных для подключения к исходному выделенному пулу SQL, преобразования синтаксиса DDL выделенного пула SQL в Fabric и копирования данных в хранилище Fabric. Вы можете выбрать 1 или более целевых таблиц (для набора данных TPC-DS существует 22 таблицы). Он создает forEach для цикла по списку таблиц, выбранных в пользовательском интерфейсе, и вызывает 22 параллельных потоков действия копирования.

  • 22 запроса SELECT (по одному для каждой выбранной таблицы) были созданы и выполнены в выделенном пуле SQL.
  • Убедитесь, что у вас есть соответствующий dwU и класс ресурсов, чтобы разрешить выполнение запросов. В этом случае требуется не менее DWU1000, staticrc10 чтобы разрешить не более 32 запросов обрабатывать 22 отправленных запроса.
  • Для прямого копирования данных из выделенного пула SQL в хранилище Fabric требуется промежуточное копирование данных фабрики данных. Процесс приема состоит из двух этапов.
    • Первый этап состоит из извлечения данных из выделенного пула SQL в ADLS и называется промежуточным.
    • Второй этап состоит из приема данных из промежуточного хранения в хранилище Fabric. Большая часть времени приема данных находится на промежуточном этапе. В итоге промежуточное выполнение оказывает огромное влияние на производительность приема.

Использование мастера копирования для создания forEach предоставляет простой пользовательский интерфейс для преобразования DDL и приема выбранных таблиц из выделенного пула SQL в хранилище Fabric на одном шаге.

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

Вариант 2. Миграция данных или данных — конвейер данных с помощью параметра секции

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

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

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

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

  • В зависимости от диапазона секций он может использовать все слоты параллелизма, так как они могут создавать более 128 запросов в выделенном пуле SQL.
  • Необходимо масштабировать до минимума DWU6000, чтобы разрешить выполнение всех запросов.
  • Например, для таблицы TPC-DS web_sales 163 запросы были отправлены в выделенный пул SQL. В DWU6000 128 запросов выполнялись, а 35 запросов были помещены в очередь.
  • Динамическая секция автоматически выбирает секцию диапазона. В этом случае диапазон 11 дней для каждого запроса SELECT, отправленного в выделенный пул SQL. Например: 
    WHERE [ws_sold_date_sk] > '2451069' AND [ws_sold_date_sk] <= '2451080')
...
WHERE [ws_sold_date_sk] > '2451333' AND [ws_sold_date_sk] <= '2451344')

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

Однако увеличение параллелизированных операций чтения требует масштабирования выделенного пула SQL до более высокого уровня DWU, чтобы разрешить выполнение запросов извлечения. Использование секционирования повышает скорость 10x без параметра секционирования. Вы можете увеличить dwU, чтобы получить дополнительную пропускную способность через вычислительные ресурсы, но выделенный пул SQL имеет не более 128 активных запросов.

Примечание.

Дополнительные сведения о сопоставлении Synapse DWU с Fabric см . в блоге: сопоставление выделенных пулов SQL Azure Synapse с вычислительными ресурсами хранилища данных Fabric.

Вариант 3. Миграция DDL — мастер копирования для действия копирования foreach

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

  1. Извлеките данные из выделенного пула SQL в ADLS, поэтому уменьшая затраты на производительность этапа.
  2. Используйте фабрику данных или команду COPY для приема данных в хранилище Fabric.

Вы можете продолжать использовать фабрику данных для преобразования схемы (DDL). С помощью мастера копирования можно выбрать определенную таблицу или все таблицы. При проектировании это переносит схему и данные на одном шаге, извлекая схему без строк, используя ложное условие в TOP 0 инструкции запроса.

В следующем примере кода рассматривается миграция схемы (DDL) с фабрикой данных.

Пример кода: миграция схемы (DDL) с фабрикой данных

Конвейеры данных Fabric можно использовать для легкой миграции по DDL (схемам) для объектов таблиц из любого исходного База данных SQL Azure или выделенного пула SQL. Этот конвейер данных переносится по схеме (DDL) для исходных выделенных таблиц пула SQL в хранилище Fabric.

Снимок экрана: фабрика данных Fabric с объектом подстановки, ведущим к каждому объекту. В каждом объекте есть действия для миграции DDL.

Конструктор конвейера: параметры

Этот конвейер данных принимает параметр SchemaName, который позволяет указать, какие схемы следует перенести. Схема dbo используется по умолчанию.

В поле "Значение по умолчанию" введите список с разделителями-запятыми таблицы, указывающий, какие схемы следует перенести: 'dbo','tpch' для предоставления двух схем dbo и tpch.

Снимок экрана: фабрика данных, на которой показана вкладка

Конструктор конвейера: действие подстановки

Создайте действие подстановки и задайте для подключения указатель на исходную базу данных.

На вкладке Параметры сделайте следующее:

  • Задайте для типахранилища данных значение External.

  • Подключение — это выделенный пул SQL Azure Synapse. Тип подключения — Azure Synapse Analytics.

  • Для запроса используется значение Query.

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

    Это выражение в действии LookUp создает инструкцию SQL для запроса системных представлений для получения списка схем и таблиц. Ссылается на параметр SchemaName, чтобы разрешить фильтрацию по схемам SQL. Результатом этого является массив схемы SQL и таблиц, которые будут использоваться в качестве входных данных в действие ForEach.

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

    @concat('
SELECT s.name AS SchemaName,
t.name  AS TableName
FROM sys.tables AS t
INNER JOIN sys.schemas AS s
ON t.type = ''U''
AND s.schema_id = t.schema_id
AND s.name in (',coalesce(pipeline().parameters.SchemaName, 'dbo'),')
')

Снимок экрана: фабрика данных, на которой показана вкладка

Проектирование конвейера: цикл ForEach

Для цикла ForEach настройте следующие параметры на вкладке "Параметры ".

  • Отключите последовательную итерацию , чтобы разрешить одновременно выполнять несколько итераций.
  • Задайте для числа50пакетных пакетов значение, ограничивающее максимальное число одновременных итерации.
  • Поле "Элементы" должно использовать динамическое содержимое для ссылки на выходные данные действия LookUp. Используйте следующий фрагмент кода: @activity('Get List of Source Objects').output.value

Снимок экрана: вкладка параметров действия цикла ForEach.

Конструктор конвейера: действие копирования внутри цикла ForEach

В действии ForEach добавьте действие копирования. Этот метод использует язык динамического выражения в конвейерах данных для сборки SELECT TOP 0 * FROM <TABLE> только схемы без данных в хранилище Fabric.

На вкладке "Источник":

  • Задайте для типахранилища данных значение External.
  • Подключение — это выделенный пул SQL Azure Synapse. Тип подключения — Azure Synapse Analytics.
  • Задайте для запроса запрос с помощью запроса.
  • В поле "Запрос" вставьте динамический запрос содержимого и используйте это выражение, которое возвращает нулевые строки, только схему таблицы:@concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)

Снимок экрана: фабрика данных, на которой показана вкладка

На вкладке "Назначение ":

  • Задайте для типа хранилища данных значение"Рабочая область".
  • Тип хранилища данных рабочей области — хранилище данных, а хранилище данных — хранилище данных.
  • Схема целевой таблицы и имя таблицы определяются с помощью динамического содержимого.
    • Схема ссылается на поле текущей итерации, SchemaName с фрагментом кода: @item().SchemaName
    • Таблица ссылается на TableName с фрагментом кода: @item().TableName

Снимок экрана: фабрика данных, на которой показана вкладка

Конструктор конвейера: приемник

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

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

Миграция с помощью хранимых процедур в выделенном пуле SQL Synapse

Этот параметр использует хранимые процедуры для выполнения миграции Fabric.

Примеры кода можно получить на GitHub.com microsoft/fabric-migration. Этот код предоставляется как открытый код, поэтому вы можете внести свой вклад в совместную работу и помочь сообществу.

Какие хранимые процедуры миграции могут выполнять:

  1. Преобразуйте схему (DDL) в синтаксис хранилища Fabric.
  2. Создайте схему (DDL) в хранилище Fabric.
  3. Извлеките данные из выделенного пула SQL Synapse в ADLS.
  4. Помечайте синтаксис неподдерживаемой структуры для кодов T-SQL (хранимые процедуры, функции, представления).

Это отличный вариант для тех, кто:

  • Знакомы с T-SQL.
  • Хотите использовать интегрированную среду разработки, например SQL Server Management Studio (SSMS).
  • Требуется более детализированный контроль над задачами, над которыми они хотят работать.

Для преобразования схемы (DDL), извлечения данных или оценки кода T-SQL можно выполнить определенную хранимую процедуру.

Для миграции данных необходимо использовать COPY INTO или Фабрику данных для приема данных в хранилище Fabric.

Миграция с помощью проектов базы данных SQL

Хранилище данных Microsoft Fabric поддерживается в расширении проектов База данных SQL, доступном в Azure Data Studio и Visual Studio Code.

Это расширение доступно в Azure Data Studio и Visual Studio Code. Эта функция позволяет использовать возможности для управления версиями, тестирования базы данных и проверки схемы.

Дополнительные сведения об управлении версиями для хранилищ в Microsoft Fabric, включая конвейеры интеграции и развертывания Git, см. в статье "Управление версиями" с помощью хранилища.

Это отличный вариант для тех, кто предпочитает использовать База данных SQL Project для развертывания. Этот параметр по сути интегрирует хранимые процедуры миграции Fabric в проект База данных SQL для обеспечения простой миграции.

Проект База данных SQL может:

  1. Преобразуйте схему (DDL) в синтаксис хранилища Fabric.
  2. Создайте схему (DDL) в хранилище Fabric.
  3. Извлеките данные из выделенного пула SQL Synapse в ADLS.
  4. Пометка неподдерживаемого синтаксиса для кодов T-SQL (хранимые процедуры, функции, представления).

Для миграции данных вы будете использовать COPY INTO или Фабрику данных для приема данных в хранилище Fabric.

В дополнение к поддержке Microsoft Fabric в Azure Data Studio команда CAT Microsoft Fabric предоставила набор скриптов PowerShell для обработки извлечения, создания и развертывания схемы (DDL) и кода базы данных (DML) через проект База данных SQL. Пошаговое руководство по использованию проекта База данных SQL с полезными скриптами PowerShell см. в GitHub.com microsoft/fabric-migration on GitHub.com.

Дополнительные сведения о проектах База данных SQL см. в статье "Начало работы с расширением База данных SQL Проекты" и "Сборка и публикация проекта".

Перенос данных с помощью CETAS

Команда T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS) предоставляет наиболее экономичный и оптимальный способ извлечения данных из выделенных пулов SQL Synapse в Azure Data Lake Storage (ADLS) 2-го поколения.

Что может сделать CETAS:

  • Извлечение данных в ADLS.
    • Этот параметр требует, чтобы пользователи создавали схему (DDL) в хранилище Fabric перед приемом данных. Рассмотрим параметры, приведенные в этой статье, для переноса схемы (DDL).

Преимущества этого варианта:

  • Только один запрос на таблицу отправляется в исходный выделенный пул SQL Synapse. Это не будет использовать все слоты параллелизма, поэтому не будет блокировать одновременные рабочие ETL/запросы клиента.
  • Масштабирование до DWU6000 не требуется, так как для каждой таблицы используется только один слот параллелизма, поэтому клиенты могут использовать более низкие dwUs.
  • Извлечение выполняется параллельно во всех вычислительных узлах, и это ключ к улучшению производительности.

Используйте CETAS для извлечения данных в ADLS в качестве файлов Parquet. Файлы Parquet обеспечивают преимущество эффективного хранилища данных с сжатием столбцов, что приведет к снижению пропускной способности для перемещения по сети. Кроме того, так как Структура сохранила данные в формате Delta Parquet, прием данных будет быстрее 2,5x по сравнению с текстовым форматом файла, так как во время приема не выполняется преобразование в затраты на разностный формат.

Чтобы увеличить пропускную способность CETAS, выполните приведенные действия.

  • Добавьте параллельные операции CETAS, увеличивая использование слотов параллелизма, но обеспечивая большую пропускную способность.
  • Масштабирование DWU в выделенном пуле SQL Synapse.

Миграция с помощью dbt

В этом разделе мы обсудим параметр dbt для тех клиентов, которые уже используют dbt в текущей среде выделенного пула SQL Synapse.

Что может сделать dbt:

  1. Преобразуйте схему (DDL) в синтаксис хранилища Fabric.
  2. Создайте схему (DDL) в хранилище Fabric.
  3. Преобразуйте код базы данных (DML) в синтаксис Fabric.

Платформа dbt создает DDL и DML (скрипты SQL) на лету с каждым выполнением. При использовании файлов модели, выраженных в инструкциях SELECT, DDL/DML можно мгновенно перевести на любую целевую платформу, изменив профиль (строка подключения) и тип адаптера.

Платформа dbt — это подход к коду. Данные необходимо перенести с помощью параметров, перечисленных в этом документе, таких как CETAS или COPY/Data Factory.

Адаптер dbt для хранилища данных Microsoft Fabric позволяет перенести существующие проекты dbt, предназначенные для различных платформ, таких как выделенные пулы SQL Synapse, Snowflake, Databricks, Google Big Query или Amazon Redshift, которые будут перенесены в хранилище Fabric с простым изменением конфигурации.

Сведения о начале работы с проектом dbt, предназначенным для хранилища Fabric, см. в руководстве по настройке dbt для хранилища данных Fabric. В этом документе также перечислены варианты перемещения между различными хранилищами и платформами.

Прием данных в хранилище Fabric

Для приема в хранилище Fabric используйте copy INTO или Fabric Data Factory в зависимости от ваших предпочтений. Оба метода являются рекомендуемыми и оптимальными вариантами, так как они имеют эквивалентную пропускную способность производительности, учитывая предварительные требования, которые файлы уже извлекаются в Azure Data Lake Storage (ADLS) 2-го поколения.

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

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

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