Быстрый старт с Azure Synapse на dbt Cloud

В dbt Labs мы всегда стремились поддерживать аналитиков там, где они находятся. Поэтому мы рады сообщить, что теперь аналитики в экосистеме Microsoft могут использовать dbt Cloud не только с Microsoft Fabric, но и с Azure Synapse Analytics Dedicated SQL Pools (ASADSP).

С самого начала dbt люди проявляли интерес к платформам данных MSFT. Огромная благодарность Mikael Ene и Jacob Mastel за их усилия в 2019 году по созданию оригинальных адаптеров SQL Server (dbt-sqlserver и dbt-mssql, соответственно).

Путь адаптера dbt для Azure Synapse, dbt-synapse, тесно связан с моим путем в dbt. Я был тем, кто форкнул dbt-sqlserver в dbt-synapse в апреле 2020 года. Я узнал о dbt всего за месяц до этого и сразу понял, что моей команде нужен этот инструмент. С большой помощью от Джереми и экспертов из Microsoft моя команда и я запустили его и начали использовать. Когда я покинул свою команду в Avanade в начале 2022 года, чтобы присоединиться к dbt Labs, я пошутил, что на самом деле не покидаю команду; я просто временно встраиваюсь в dbt Labs, чтобы ускорить внедрение dbt Labs в Cloud. Два года спустя я могу сказать своей команде, что миссия выполнена! Спасибо всем, кто внес вклад в адаптеры TSQL, как напрямую в GitHub, так и в каналах Slack сообщества. Интеграция не существовала бы без вас!

Лучшие практики для Fabric

С введением поддержки dbt Cloud для Microsoft Fabric и Azure Synapse Analytics Dedicated SQL Pools мы открываем новые возможности для аналитиков в экосистеме Microsoft.

Цель этого блога — обеспечить отличный опыт как для

• конечных пользователей-аналитиков данных, которые полагаются на продукты данных, созданные с помощью dbt, так и
• аналитиков, которые должны в основном тратить время на создание и поддержку продуктов данных, а не на поддержку и развертывание инфраструктуры
• инженеров данных, которые сосредоточены на перемещении и загрузке данных в Synapse

Для достижения этой цели в этом посте будут рассмотрены четыре основные области:

• Microsoft Fabric: будущее хранения данных в стеке Microsoft/Azure
• стратегические рекомендации по созданию среды Synapse
• моделирование данных в dbt: стиль Synapse
• соображения для верхнего и нижнего уровня проекта dbt на базе Synapse

С этим давайте начнем!

Fabric — это будущее

Многие команды данных в настоящее время используют выделенные пулы Azure Synapse. Однако Fabric Synapse Data Warehouse — это будущее хранения данных в экосистеме Microsoft. Azure Synapse Analytics останется доступным еще несколько лет, но основное внимание Microsoft сосредоточено на Fabric, как мы можем видеть в их дорожной карте и запусках.

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

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

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

Fabric предлагает неоспоримый потенциал благодаря:

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

Эти два аспекта значительно упрощают раздел ниже о предоставлении ресурсов.

Для получения дополнительной информации см.:

• официальный гид: Миграция: выделенные SQL-пулы Azure Synapse Analytics в Fabric.
• этот блог о будущем Azure Synapse Analytics

Предоставление ресурсов

Вот некоторые соображения, если вы настраиваете среду с нуля. Если инфраструктура нескольких выделенных SQL-пулов Synapse и репозиторий Git уже существуют, вы можете перейти к следующему разделу, хотя не помешает освежить в памяти приведенное ниже.

минимизация пулов; максимизация DWU

определения

• выделенные SQL-пулы: фактически одно хранилище данных
• Единицы хранилища данных (DWU): размер кластера

количество пулов

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

Если у вас есть только одна команда аналитиков, у вас должно быть два SQL-пула: один для разработки и один для производства. Если у вас есть несколько отдельных команд, которые будут моделировать данные в Synapse с использованием dbt, рассмотрите возможность использования парадигмы Mesh в dbt Cloud для обеспечения совместной работы между командами.

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

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

DWU

Начальный уровень — DW100c, который стоит $1.20/час и имеет ограничения, такие как разрешение только 4 одновременных запросов. Чтобы добавить 4 одновременных запроса, вы должны увеличить уровень DWH. За каждое увеличение на 100 c вы получаете дополнительные 4 одновременных запроса.

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

• спроектировать инфраструктуру для перемещения данных из Synapse в базу данных Azure SQL или в другое место
• увеличить уровень оплачиваемой услуги (т.е. увеличить DWU)

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

Ресурсы для развертывания

В экосистеме Microsoft развертывание хранилищ данных чаще всего осуществляется с помощью Azure Data Factory, а не конвейеров Azure DevOps или GitHub Actions. Мы рекомендуем отделить развертывания проектов dbt от любых конвейеров загрузки, определенных в ADF.

Однако, если вы должны использовать ADF в качестве конвейера развертывания, возможно использование API dbt Cloud. Запуск dbt Core в Azure Data Factory может быть сложной задачей, так как нет простого способа установить и вызвать dbt Core, потому что нет простого способа установить и запустить Python. Обходные пути не идеальны, например: Настройка вызовов dbt через Azure Serverless Functions и их вызов из ADF.

контроль доступа

разрешения для аналитиков

предупреждение

⚠️ Аутентификация на основе пользователей Azure Active Directory пока не поддерживается в dbt Cloud. В качестве обходного пути рассмотрите возможность создания Сервисного принципала для каждого аналитика, участвующего в dbt Cloud.

В хранилище разработки каждый пользователь должен иметь следующие привилегии: EXECUTE, SELECT, INSERT, UPDATE и DELETE.

разрешения сервисного принципала

Кроме того, требуется сервисный принципал для dbt Cloud, чтобы напрямую взаимодействовать как с хранилищем, так и с вашим поставщиком услуг Git (например, GitHub или Azure DevOps).

Только Сервисный принципал, отвечающий за развертывание, имеет вышеуказанные разрешения в производственной среде. Конечные пользователи имеют только доступ SELECT к этой среде.

Соображения по моделированию

Магия начинается, когда среды настроены и dbt Cloud подключен.

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

С dbt Cloud все еще более упрощено. CLI dbt Cloud позволяет разработчикам строить только те модели, которые им нужны для PR, ссылаясь на производственную среду для зависимостей. Также есть dbt Explorer, который теперь имеет родословную на уровне столбцов.

Хотя уже существуют платформенно-агностичные руководства по лучшим практикам, которые все еще применимы для Synapse, есть некоторые дополнительные факторы, связанные с распределением данных и индексированием.

распределения и индексы

Работая в ASADSP, важно помнить, что вы работаете в архитектуре Массово-параллельной обработки (MPP).

Это означает, что для каждого табличного модуля необходимо настроить index и distribution. В dbt-synapse по умолчанию используются:

• индекс: CLUSTERED COLUMNSTORE INDEX
• распределение: ROUND_ROBIN

Если вы хотите что-то другое, вы можете определить это, как показано ниже. Для получения дополнительной информации см. документацию dbt: конфигурации для Azure Synapse DWH: Индексы и распределения.

{{
    config(
        index='HEAP',
        dist='ROUND_ROBIN'
        )
}}
SELECT * FROM {{ ref('some_model') }}

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

1. обеспечивает равномерное распределение данных по узлам кластера, и
2. минимизирует межузловое перемещение данных.

Например, представьте, что вы запрашиваете таблицу с 100 строками в нисходящей модели. Использование distribution=ROUND_ROBIN инструктирует пул равномерно распределять строки между 60 узлами, что эквивалентно наличию только одной или двух строк в каждом узле. Это SELECT-ирование всех этих операций, которые затрагивают все 60 узлов. В результате запрос будет выполняться намного медленнее, чем вы могли бы ожидать.

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

дополнительная информация

• Руководство по проектированию распределенных таблиц с использованием выделенного SQL-пула в Azure Synapse Analytics
• исходный код для макроса synapse__create_table_as()

Развертывания и экосистема

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

Верхний уровень

В dbt мы предполагаем, что данные уже загружены в хранилище в необработанном виде. Это следует более широкой парадигме, известной как Extract-Load-Transform (ELT). То же самое касается dbt с Azure Synapse. Цель должна состоять в том, чтобы данные загружались в Synapse как можно более "нетронутыми" с момента их поступления из вышестоящей системы источника. Часто команды данных, использующие Azure Data Factory, продолжают применять парадигму ETL, где данные преобразуются еще до того, как они попадают в хранилище. Мы не рекомендуем это, так как это приводит к тому, что критические преобразования данных находятся за пределами проекта dbt и, следовательно, не документированы.

Если вы еще этого не сделали, свяжитесь с центральной/вышестоящей командой инженеров данных, чтобы разработать план интеграции извлечения и перемещения данных в таких инструментах, как SSIS и Azure Data Factory, с преобразованием, выполняемым через dbt Cloud.

Потребители нижнего уровня (Power BI)

В экосистеме данных MSFT крайне распространено, что значительные объемы моделирования данных находятся в отчетах и/или наборах данных Power BI. Это допустимо до определенного момента.

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

Должны быть постоянные усилия по переносу кода Power Query, написанного в PBI, в код преобразования и его переносу в хранилище данных, где моделирование может быть протестировано, задокументировано, повторно использовано другими и развернуто с уверенностью.

Заключение

Сегодня в dbt Cloud есть отличные возможности для команд данных, использующих Azure Synapse. Хотя Fabric — это будущее, есть значимые соображения, касающиеся предоставления ресурсов, проектирования моделей и развертываний в более широкой экосистеме.

Смотря вперед, мы с нетерпением ждем возможностей, которые Microsoft Fabric предлагает для будущего аналитики данных. С dbt Cloud и Azure Synapse аналитики могут с уверенностью распространять знания в своей организации.