В этой статье описывается, как вымышленный отдел городского планирования мог бы использовать это решение. Решение предоставляет полный конвейер данных, соответствующий архитектурному шаблону MDW, наряду с соответствующими процессами DevOps и DataOps для оценки использования парковки и принятия более обоснованных бизнес-решений.
Архитектура
На следующей схеме показана общая архитектура решения.
Скачайте файл Visio для этой архитектуры.
Поток данных
Фабрика данных Azure (ADF) оркестрирует, а Azure Data Lake Storage (ADLS) 2-го поколения хранит данные:
API веб-службы городской парковки Contoso доступен для передачи данных с парковочных мест.
Существует задание копирования ADF, которое передает данные в схему Landing.
Затем Azure Databricks очищает и стандартизирует данные. Необработанные данные принимаются и обрабатываются, чтобы специалисты по анализу и обработке данных могли их использовать.
Если проверка выявит какие-либо неправильные данные, они будут переданы в схему Malformed.
Внимание
Пользователи интересовались, почему данные не проверяются перед сохранением в ADLS. Причина заключается в том, что проверка может привести к возникновению ошибки, которая может повредить набор данных. Если на этом этапе возникнет ошибка, вы сможете исправить ее и воспроизвести конвейер. Если неправильные данные будут переданы до того, как вы добавили их в ADLS, поврежденные данные будут бесполезными, так как вы не сможете воспроизвести свой конвейер.
Существует второй этап преобразования Azure Databricks, когда данные преобразуются в формат, поддерживаемый хранилищем данных.
Наконец, конвейер обслуживает данные двумя разными способами:
Databricks делает данные доступными для специалистов по обработке и анализу данных, чтобы они могли обучать модели.
Polybase перемещает данные из озера данных в Azure Synapse Analytics, а Power BI получает доступ к данным и представляет их бизнес-пользователю.
Компоненты
В решении используются приведенные ниже компоненты.
Подробности сценария
Современное хранилище данных (MDW) позволяет легко объединять все данные в любом масштабе. И неважно, какие это данные, — структурированные, неструктурированные или частично структурированные. Вы можете получить представление о MDW с помощью аналитических панелей мониторинга, оперативных отчетов или расширенной аналитики для всех ваших пользователей.
Настроить среду MDW как для среды разработки (dev), так и для рабочей среды (prod) непросто. Автоматизация процесса является ключевой задачей. Это помогает повысить производительность, сводя к минимуму риск возникновения ошибок.
В этой статье описывается, как вымышленный отдел городского планирования мог бы использовать это решение. Решение предоставляет полный конвейер данных, соответствующий архитектурному шаблону MDW, наряду с соответствующими процессами DevOps и DataOps для оценки использования парковки и принятия более обоснованных бизнес-решений.
Требования к решению
Возможность сбора данных из разных источников или систем.
Инфраструктура как код: автоматизация развертывания новых сред разработки и промежуточной обработки (stg).
Автоматическое развертывание изменений приложений в разных средах:
реализация конвейеров непрерывной интеграции и непрерывной поставки (CI/CD);
использование шлюзов развертывания для утверждения вручную.
Конвейер как код: размещение определений конвейера CI/CD находятся в системе управления версиями.
Выполнение интеграционных тестов для изменений с помощью примера набора данных.
Запуск конвейеров по расписанию.
Поддержка гибкой разработки в будущем, включая добавление рабочих нагрузок обработки и анализа данных.
Поддержка безопасности на уровне строк и объектов:
компонент безопасности доступен в Базе данных SQL;
он также доступен в Azure Synapse Analytics, Azure Analysis Services (AAS) и Power BI.
Поддержка 10 одновременных пользователей панели управления и 20 одновременных опытных пользователей.
Конвейер данных должен выполнять проверку данных и отфильтровывать неправильные записи в указанное хранилище.
Поддержка мониторинга.
Централизованная конфигурация в безопасном хранилище, например Azure Key Vault.
Потенциальные варианты использования
В этой статье для описания сценария используется вымышленный город Contoso. В сценарии Contoso владеет и управляет городскими датчиками парковки, а также API, которые подключаются к датчикам и получают данные от них. При этом требуется платформа, которая будет собирать данные из множества разных источников. Затем данные должны быть проверены, очищены и преобразованы в известную схему. После этого градостроители Contoso могут изучать и оценивать данные отчетов об использовании парковок с помощью инструментов визуализации данных, таких как Power BI, чтобы определить, нужны ли им дополнительные парковки или связанные ресурсы.
Рекомендации
В следующем списке приведены основные сведения об обучении и рекомендациях, демонстрируемых этим решением:
Примечание.
Каждый элемент в приведенном ниже списке ведет к соответствующему разделу с ключевыми выводами в документации по примеру решения для датчиков парковки в GitHub.
Развертывание этого сценария
В следующем списке перечислены обобщенные шаги, необходимые для настройки решения датчиков парковки с соответствующими конвейерами сборки и выпуска. Подробные инструкции по настройке и необходимые условия см. в этом репозитории примеров Azure.
Установка и развертывание
Первоначальная настройка. Установите все необходимые компоненты, импортируйте репозиторий примеров Azure в GitHub в свой собственный репозиторий и задайте необходимые переменные среды.
Развертывание ресурсов Azure. Решение поставляется со скриптом автоматического развертывания. Он развертывает все необходимые ресурсы Azure и субъекты-службы Microsoft Entra для каждой среды. Сценарий также развертывает Azure Pipelines, группы переменных и подключения служб.
Настройка интеграции Git с Фабрикой данных для разработки. Настройте интеграцию Git для работы с импортированным репозиторием GitHub.
Выполните первоначальную сборку и выпуск. Создайте пример изменения в Фабрике данных, например включите триггер по расписанию, а затем наблюдайте, как изменение автоматически развертывается в разных средах.
Развертываемые ресурсы
Если развертывание будет выполнено успешно, в Azure должны быть три группы ресурсов, представляющие три среды: dev, stg и prod. В Azure DevOps также должны быть полные конвейеры сборки и выпуска, которые могут автоматически развертывать изменения в этих трех средах.
Подробный список всех ресурсов см. в разделе с описанием развернутых ресурсов в файле README демонстрации датчиков парковки (DataOps).
Непрерывные интеграция и доставка
На приведенной ниже схеме показан процесс и последовательность CI/CD для конвейеров сборки и выпуска.
Скачайте файл Visio для этой архитектуры.
Разработчики выполняют разработку в собственных изолированных средах в группе ресурсов dev и фиксируют изменения в краткосрочных ветвях Git. Например,
<developer_name>/<branch_name>.Когда внесение изменений завершается, разработчики отправляют запрос на извлечение (PR) в главную ветвь для проверки. Это автоматически запускает конвейер проверки PR, который запускает модульные тесты, анализ кода и сборку пакета приложений уровня данных (DACPAC).
По завершении проверки PR фиксация в главной ветви запускает конвейер сборки, который публикует все необходимые артефакты сборки.
Успешное завершение конвейера сборки активирует первый этап конвейера выпуска. При этом артефакты сборки публикации развертываются в среде dev, за исключением ADF.
Разработчики вручную выполняют публикацию в ADF dev из ветви совместной работы (главной). Публикация вручную обновляет шаблоны Azure Resource Manager (ARM) в ветви
adf_publish.Успешное завершение первого этапа запускает шлюз утверждения вручную.
После утверждения конвейер выпуска переходит ко второму этапу развертывания изменений в среде stg.
Запустите интеграционные тесты, чтобы протестировать изменения в среде stg.
После успешного завершения второго этапа конвейер активирует второй шлюз утверждения вручную.
После утверждения конвейер выпуска переходит к третьему этапу развертывания изменений в среде prod.
Дополнительные сведения см. в разделе с описанием конвейера сборки и выпуска в файле README.
Тестирование
Решение включает поддержку как модульного, так и интеграционного тестирования. При этом используется pytest-adf и Nutter Testing Framework. Дополнительные сведения см. в разделе с описанием способов тестирования в файле README.
Наблюдаемость и мониторинг
Решение поддерживает возможность наблюдения и мониторинга для Databricks и Фабрики данных. Дополнительные сведения см. в разделе с описанием возможностей наблюдения и мониторинга в файле README.
Следующие шаги
Если вы хотите развернуть решение, выполните действия, описанные в разделе с инструкциями по использованию пример в файле README для демонстрации датчиков парковки (DataOps).
Примеры кода решения в GitHub
Наблюдаемость и мониторинг
Azure Databricks
- Мониторинг Azure Databricks с помощью Azure Monitor
- Мониторинг заданий Azure Databricks с помощью Application Insights
Фабрика данных
- Мониторинг Фабрики данных Azure с помощью Azure Monitor
- Создание оповещений для упреждающего мониторинга конвейеров фабрики данных
Synapse Analytics
- Мониторинг использования ресурсов и выполнения запросов в Azure Synapse Analytics
- Мониторинг рабочей нагрузки пула SQL Azure Synapse Analytics с помощью динамических административных представлений
Хранилище Azure
Устойчивость и аварийное восстановление
Azure Databricks
Фабрика данных
Synapse Analytics
- Геоизбыточное резервное копирование и аварийное восстановление
- Геоизбыточное восстановление для пула SQL
Хранилище Azure
- Аварийное восстановление и отработка отказа учетной записи хранения
- Рекомендации по использованию Azure Data Lake Storage 2-го поколения — обеспечение высокой доступности и аварийного восстановления
- Избыточность хранилища Azure
Подробное пошаговое руководство
Для ознакомления с решением и ключевыми понятиями просмотрите видеозапись, посвященную использованию DataDevOps для современного хранилища данных в Microsoft Azure.