Разработка и развертывание зависимостей между разными хранилищами

Из этой статьи вы узнаете, как моделировать и развертывать зависимости между хранилищами с помощью проектов базы данных SQL в Visual Studio Code. Вы начинаете с двух существующих проектов хранилища и настраиваете односторонние зависимости между ними, используя ссылки на базы данных и при необходимости скрипты предразвертывания и послеразвертывания.

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

Предпосылки

Прежде чем начать, убедитесь, что вы:

• Создайте два хранилища Fabric в одной рабочей области.
  • Сведения о создании нового образца хранилища см. в статье "Создание примера хранилища в Microsoft Fabric".
• Создайте или извлеките проект базы данных для каждого хранилища в Visual Studio Code.
  • Чтобы создать проект базы данных для существующего хранилища или нового хранилища, см. статью "Разработка проектов хранилища" в Visual Studio Code.
• Установите Visual Studio Code на рабочей станции.
• Установите пакет SDK для .NET для создания и публикации проектов базы данных.
• Установите два расширения Visual Studio Code: проекты базы данных SQL и SQL Server (mssql).
  • Необходимые расширения можно установить непосредственно в Visual Studio Code Marketplace, выполнив поиск по запросу "Проекты базы данных SQL" или "SQL Server (mssql)".
• Проекты хранилища проходят валидацию, сборку и могут быть опубликованы в Visual Studio Code.

Замечание

В этой статье рассматриваются проекты хранилища в Visual Studio Code и их версия в Git в виде обычных проектов кода. Интеграция Git Fabric для рабочих областей и элементов хранилища рассматривается отдельно в системе контроля версий с помощью хранилища данных Fabric и документации по интеграции с Git. В этой статье предполагается, что рабочая область Fabric — это целевой объект развертывания, а схема T-SQL находится в одном или нескольких проектах Visual Studio Code, исходный код которых управляется с помощью Git.

В этой статье не рассматриваются межсайтовые разработки для конечной точки аналитики SQL Lakehouse. Таблицы Lakehouse и объекты конечных точек SQL не отслеживаются в системе контроля версий так же, как проекты хранилища. Используйте элементы хранилища с проектами базы данных для полной интеграции и развертывания Git в собственных интерфейсах Fabric и клиентских средствах.

Сценарий: кросс-доменные хранилища Zava Analytics

Zava Analytics использует два бизнес-домена:

• Продажи — заказы клиентов, доходы и метрики конвейера.
• Маркетинг — кампании, каналы и метрики взаимодействия.

Каждый домен имеет:

• Хранилище Fabric в той же рабочей области:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Проект базы данных в Visual Studio Code:

  • Zava.Sales.Warehouse
  • Zava.Marketing.Warehouse

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

• Sales нуждается в маркетинговом взаимодействии с клиентом.
• Marketing необходима информация о производительности продаж по каждой кампании.

Вам нужно:

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

Убедитесь, что зависимости между хранилищами являются односторонними

Для каждой пары хранилищ выберите направление для логической зависимости:

Пример:

• Sales зависит от Marketing для данных о взаимодействии.
• Marketing не зависит от Sales в отношении объектов, необходимых во время развертывания.

На практике:

Zava.Sales.Warehouse имеет ссылку на базу данныхZava.Marketing.Warehouse.

• T-SQL в Sales хранилище может использовать трехчастные имена, например:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouse не ссылается на Sales объекты, которые могут вызвать цикл зависимостей во время развертывания.

Подсказка

Для каждой пары складов нарисуйте простую схему со стрелками (Sales → Marketing). Если стрелки находятся в обоих направлениях для одного типа объекта, вероятно, потребуется рефакторинг или переместить некоторую логику в скрипты перед развертыванием и после развертывания.

Избегайте циклических зависимостей

Циклическая зависимость происходит, когда хранилище A и хранилище B зависят друг от друга таким образом, что движок не может разрешить это в одном развертывании.

Пример проблемы (не делай это):

• ZavaSalesWarehouse.dbo.CustomerRollup вид:

  CREATE VIEW dbo.CustomerRollup AS
  SELECT  c.CustomerId,
          c.TotalRevenue,
          m.LastCampaignId
  FROM    dbo.CustomerRevenue AS c
  LEFT OUTER JOIN   
          ZavaMarketingWarehouse.dbo.CustomerEngagement AS m
          ON c.CustomerId = m.CustomerId;
  

• ZavaMarketingWarehouse.dbo.CampaignAttribution вид:

  CREATE VIEW dbo.CampaignAttribution AS
  SELECT  m.CampaignId,
          SUM(s.TotalRevenue) AS RevenueAttributed
  FROM    dbo.Campaigns AS m
  LEFT OUTER JOIN    
          ZavaSalesWarehouse.dbo.CustomerRollup AS s
          ON m.CampaignId = s.LastCampaignId
  GROUP BY m.CampaignId;
  

В этом антипаттерне:

• CustomerRollup в продажах зависит от CustomerEngagement в маркетинге.
• CampaignAttribution в Маркетинг зависит от CustomerRollupПродажи.

Этот антишаблон создает цикл: вид "Продажи" → вид "Маркетинг" → снова вид "Продажи".

Руководство.

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

• Скрипт после развертывания или
• Нисходящая семантическая модель или отчет, объединяющие два хранилища во время запроса.

Использование скриптов предразвертывания и постразвертывания для логики развертывания с учетом чувствительности к среде между хранилищами.

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

Если хранилище A и Warehouse B оба нуждаются в объектах, которые зависят друг от друга:

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

Примеры шаблонов:

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

Шаблон 1. Прямые ссылки между хранилищами с помощью ссылок на базы данных

В этом шаблоне можно моделировать односторонних зависимостей непосредственно в проектах базы данных с помощью ссылок на базы данных.

Шаг 1. Начало работы с двух существующих проектов склада

У вас уже должно быть следующее:

• Zava.Sales.Warehouse → развернуто в ZavaSalesWarehouse
• Zava.Marketing.Warehouse → развернуто в ZavaMarketingWarehouse

Каждый проект был создан или извлечен с помощью шагов, описанных в разделе "Разработка проектов хранилища" в Visual Studio Code.

Шаг 2. Добавление ссылки на базу данных из sales to Marketing

• В Visual Studio Code откройте представление "Проекты баз данных ".
• Щелкните правой кнопкой мыши на проекте Zava.Sales.Warehouse.
• Выберите "Добавить ссылку на базу данных...".
• Выберите один из следующих вариантов:
  • Проект базы данных в текущей рабочей области (на который имеется ссылка таким образом, также должен быть открыт в Visual Studio Code) или
  • Приложение уровня данных (.dacpac) (предполагается, что оно построено, если у вас есть построенный .dacpac для Marketing хранилища).
• Задайте параметры ссылки:
  • Ссылочный тип: Один и тот же сервер, другая база данных.
  • Имя базы данных или переменная: Например [$(MarketingWarehouseName)], используйте переменную SQLCMD.
• Сохраните и перестроите проект Sales.

В файле .sqlproj вы должны увидеть запись, аналогичную следующей:

<ItemGroup>
  <ArtifactReference Include="..\Zava.Marketing.Warehouse\bin\Debug\Zava.Marketing.Warehouse.dacpac">
    <DatabaseVariableLiteralValue>$(MarketingWarehouseName)</DatabaseVariableLiteralValue>
  </ArtifactReference>
</ItemGroup>
<ItemGroup>
  <SqlCmdVariable Include="MarketingWarehouseName">
    <DefaultValue>ZavaMarketingWarehouse</DefaultValue>
  </SqlCmdVariable>
</ItemGroup>

Подсказка

Использование переменной SQLCMD для имени удаленного хранилища позволяет повторно использовать один и тот же проект во всех средах, например Dev/Test/Prod, где имена хранилища могут отличаться.

Шаг 3. Создание межскладского представления в системе Sales

В проекте Sales добавьте представление, которое читает данные из Marketing хранилища.

-- schema/Views/dbo.CustomerEngagementFact.sql
CREATE VIEW [dbo].[CustomerEngagementFact] AS
SELECT
    s.CustomerId,
    s.TotalRevenue,
    m.LatestChannel,
    m.LastEngagementDate
FROM dbo.CustomerRevenue AS s
JOIN [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] AS m
    ON s.CustomerId = m.CustomerId;

Основные моменты:

• Трехкомпонентное имя [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] соответствует шаблону T-SQL, используемому для запросов между хранилищами в редакторе SQL Fabric.
• DacFx обрабатывает внешнюю базу данных через ссылку на базу данных.

Создайте проект, чтобы гарантировать отсутствие SQL71501 неразрешенных ошибок ссылок .

Шаг 4: Опубликуйте модуль Маркетинга, а затем Продаж

Чтобы избежать проблем с развертыванием:

• Сначала сборка и публикацияZava.Marketing.Warehouse:
  • Щелкните правой кнопкой мыши проект → Сборка.
  • Щелкните правой кнопкой мыши по проекту → Публиковать → выберите ZavaMarketingWarehouse.
• После Marketing успешного развертывания выполните сборку и публикациюZava.Sales.Warehouse:
  • Щелкните правой кнопкой мыши проект → Сборка.
  • Щелкните правой кнопкой мыши проект → публикация → выберите ZavaSalesWarehouse.

Результирующий поток развертывания:

Zava.Marketing.Warehouse (без внешних зависимостей) → Zava.Sales.Warehouse (зависит от Marketing)

Теперь любой T-SQL запрос в ZavaSalesWarehouse может использовать представление dbo.CustomerEngagementFact, которое на внутреннем уровне считывает данные из Marketing хранилища, используя межскладский T-SQL.

Шаблон 2. Межскладские зависимости, управляемые с помощью сценариев предразвертывания и постразвертывания

В некоторых сценариях Zava Analytics оба домена могут потребовать агрегированных объектов, которые зависят друг от друга. Рассмотрим пример.

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

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

Вместо этого вы:

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

Шаг 1. Добавление ссылок на базу данных для проверки во время компиляции

Настройте ссылки, аналогичные шаблону 1, но для обоих проектов:

• Введите Zava.Sales.Warehouseссылку на маркетинг через [$(MarketingWarehouseName)].
• При Zava.Marketing.Warehouse, при необходимости добавьте ссылку на Sales с помощью [$(SalesWarehouseName)], если вы хотите проверки во время компиляции представлений между хранилищами, используемых в сценариях.

В файлах .sqlproj можно задать следующее:

<SqlCmdVariable Include="SalesWarehouseName">
  <DefaultValue>ZavaSalesWarehouse</DefaultValue>
</SqlCmdVariable>

Шаг 2. Создание основных объектов в качестве обычных объектов проекта

Пример:

• Sales проект:

  • Таблица dbo.CustomerRevenue
  • dbo.SalesByCampaign представление (только с использованием локальных таблиц)

• Marketing проект:

  • Таблица dbo.Campaigns
  • dbo.CampaignStats представление (только с использованием локальных таблиц)

Эти объекты не используют запросы между хранилищами. На следующем шаге мы внедрим перекрестные ссылки между складами.

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

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

• Sales В проекте: щелкните правой кнопкой мыши на проекте и выберите Добавить → Скрипт после развертывания.
• Присвойте скрипту PostDeployment_CrossWarehouse.sqlимя.
• В скрипте создайте или измените представления между хранилищами с помощью IF EXISTS / DROP / CREATE шаблонов, чтобы сохранить их идемпотентными.

Пример скрипта в Sales, который будет ссылаться на объекты хранилища Marketing.

-- PostDeployment_CrossWarehouse.sql

-- Ensure object can be recreated safely
IF OBJECT_ID('dbo.CampaignRevenueBridge', 'V') IS NOT NULL
    DROP VIEW [dbo].[CampaignRevenueBridge];
GO

CREATE VIEW [dbo].[CampaignRevenueBridge] AS
SELECT
    c.CampaignId,
    c.CampaignName,
    m.Channel,
    SUM(s.TotalRevenue) AS Revenue
FROM [$(MarketingWarehouseName)].[dbo].[Campaigns] AS c
JOIN [$(MarketingWarehouseName)].[dbo].[CampaignEngagement] AS m
    ON c.CampaignId = m.CampaignId
JOIN dbo.SalesByCampaign AS s
    ON s.CampaignId = c.CampaignId
GROUP BY
    c.CampaignId,
    c.CampaignName,
    m.Channel;
GO

Здесь:

• Основные проекты Sales и складские проекты Marketing остаются независимыми и могут развертываться самостоятельно.
• Вид моста создается после развертывания схемы с помощью постразверточного скрипта.
• Если развертывание выполняется несколько раз, это идемпотентно, так как скрипт безопасно удаляет и повторно создает представление.

Шаг 4. (Необязательно) Используйте скрипты предварительного развертывания для защиты хрупких зависимостей

В более сложных сценариях можно:

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

Это важно

Скрипты перед развертыванием и после развертывания выполняются в рамках плана развертывания и должны быть:

• Идемпотент, что означает, их можно безопасно выполнять несколько раз.
• Совместим с окончательной схемой , созданной DacFx.
• Без разрушительных изменений, которые конфликтуют с политикой BlockOnPossibleDataLoss.

Шаг 5: Опубликовать порядок для зависимостей, управляемых скриптом

Распространенный шаблон для Zava Analytics:

• Публикация базовых проектов:
  • Zava.Marketing.Warehouse (базовая схема)
  • Zava.Sales.Warehouse (базовая схема + скрипт после развертывания между хранилищами)
• Позвольте скрипту Sales после развертывания создать представления моста после развертывания собственной схемы и указанной Marketing схемы.

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

Продолжайте учиться

• Объедините эти шаблоны с инструкциями по управлению версиями и CI/CD, используя управление версиями с Fabric Data Warehouse и документацию по интеграции с Fabric git.
• Расширьте сценарий Zava Analytics, чтобы включить окружения Dev/Test/Prod, используя конвейеры развертывания или внешние CI/CD для оркестрации порядка публикации в нескольких хранилищах.

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

• Рабочие процессы разработки и развертывания