DataOps для современного хранилища данных

В этой статье описывается, как вымышленный отдел городского планирования мог бы использовать это решение. Решение предоставляет полный конвейер данных, соответствующий архитектурному шаблону MDW, наряду с соответствующими процессами DevOps и DataOps для оценки использования парковки и принятия более обоснованных бизнес-решений.

Architecture

На следующей схеме показана общая архитектура решения.

Скачайте файл в формате Visio этой архитектуры.

Dataflow

Фабрика данных Azure координирует, а Azure Data Lake Storage 2-го поколения сохраняет данные.

1. API веб-службы городской парковки Contoso доступен для передачи данных с парковочных мест.

2. Существует задание копирования фабрики данных, которое передает данные в схему приземления.

3. Затем Azure Databricks очищает и стандартизирует данные. Полученные необработанные данные обрабатываются, чтобы специалисты по данным могли их использовать.

4. Если проверка выявит какие-либо неправильные данные, они будут переданы в схему Malformed.

   Important

   Люди спрашивают, почему данные не проверяются, прежде чем они хранятся в Data Lake Storage. Причина заключается в том, что проверка может привести к возникновению ошибки, которая может повредить набор данных. Если вы внесете ошибку на этом этапе, вы сможете исправить ее и заново запустить свой конвейер. Если вы сбросили плохие данные, прежде чем добавили их в Data Lake Storage, то поврежденные данные бесполезны, так как вы не сможете повторно запустить конвейер.

5. Существует второй этап преобразования Azure Databricks, который преобразует данные в формат, который можно хранить в хранилище данных.

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

   1. Databricks делает данные доступными для специалистов по обработке и анализу данных, чтобы они могли обучать модели.

   2. Polybase перемещает данные из озера данных в Azure Synapse Analytics, а Power BI считывает эти данные и предоставляет их бизнес-пользователю.

Components

• Фабрика данных Azure — это облачная служба интеграции данных, которая обеспечивает перемещение и оркестрацию данных. В этой архитектуре конвейер инициируется путем копирования данных из API веб-службы парковки города Contoso в целевую зону озера данных.

• Azure Data Lake Storage 2-го поколения — это масштабируемое и безопасное озеро данных, созданное на основе Хранилище BLOB-объектов Azure, поддерживающей многоуровневое хранилище и воспроизводимые конвейеры. В этой архитектуре он служит центральным репозиторием для необработанных и обработанных данных в зонах приземления, деформированных данных и проверенных данных.

• Azure Databricks — это платформа аналитики на основе Apache Spark, предназначенная для больших данных и машинного обучения. В этой архитектуре выполняется два критически важных шага преобразования. Во-первых, она очищает и стандартизирует необработанные данные при фильтрации неправильно сформированных записей в отдельную схему. Затем он преобразует проверенные данные в формат, подходящий для хранилища данных, и делает обработанные данные доступными для специалистов по обработке и анализу данных для обучения модели.

• Azure Key Vault — это безопасная облачная служба для управления секретами, ключами и сертификатами. В этой архитектуре хранятся конфиденциальные параметры конфигурации и учетные данные, используемые во всем конвейере, обеспечивая централизованное и безопасное управление конфигурацией.

• Azure Synapse Analytics — это интегрированная служба аналитики, которая объединяет возможности хранения больших данных и данных. В этой архитектуре он служит хранилищем данных, которое получает преобразованные данные из Data Lake Storage через PolyBase для запроса и создания отчетов.

• Power BI — это средство бизнес-аналитики, которое предоставляет интерактивные визуализации и панели мониторинга. В этой архитектуре он подключается к Azure Synapse Analytics, чтобы представить аналитические сведения об использовании парковки для городских планировщиков для принятия обоснованных решений.

Сведения о сценарии

Современное хранилище данных (MDW) позволяет легко объединять все данные в любом масштабе. И неважно, какие это данные, — структурированные, неструктурированные или частично структурированные. Вы можете получить представление о MDW с помощью аналитических панелей мониторинга, оперативных отчетов или расширенной аналитики для всех ваших пользователей.

Настроить среду MDW как для среды разработки (dev), так и для рабочей среды (prod) непросто. Автоматизация процесса является ключевой задачей. Это помогает повысить производительность, сводя к минимуму риск возникновения ошибок.

В этой статье описывается, как вымышленный отдел городского планирования мог бы использовать это решение. Решение предоставляет полный конвейер данных, соответствующий архитектурному шаблону MDW, наряду с соответствующими процессами DevOps и DataOps для оценки использования парковки и принятия более обоснованных бизнес-решений.

Требования к решению

• Возможность сбора данных из разных источников или систем.

• Инфраструктура как код: автоматизация развертывания новых сред разработки и промежуточной обработки (stg).

• Автоматическое развертывание изменений приложений в разных средах:

  • Реализуйте конвейеры непрерывной интеграции и непрерывной доставки (CI/CD).

  • Использовать шлюзы развертывания для ручного утверждения.

• Конвейер в виде кода: обеспечьте, чтобы определения конвейера CI/CD были помещены в систему управления версиями.

• Выполнение интеграционных тестов для изменений с помощью примера набора данных.

• Запуск конвейеров по расписанию.

• Поддержка гибкой разработки в будущем, включая добавление рабочих нагрузок обработки и анализа данных.

• Поддержка безопасности на уровне строк и объектов:

  • компонент безопасности доступен в Базе данных SQL;

  • Его также можно найти в Azure Synapse Analytics, Azure Analysis Services и Power BI.

• Поддержка 10 одновременных пользователей панели управления и 20 одновременных опытных пользователей.

• Конвейер данных должен выполнять проверку данных и отфильтровывать неправильные записи в указанное хранилище.

• Поддержка мониторинга.

Потенциальные варианты использования

В этой статье для описания сценария используется вымышленный город Contoso. В сценарии Contoso владеет и управляет городскими датчиками парковки, Она также владеет API, которые подключаются к датчикам и получают данные от них. При этом требуется платформа, которая будет собирать данные из множества разных источников. Затем данные должны быть проверены, очищены и преобразованы в известную схему. Градостроители в Contoso могут просматривать и оценивать данные отчетов о парковке с помощью инструментов визуализации данных, таких как Power BI, чтобы определить, требуется ли больше парковочных мест или связанных ресурсов.

Considerations

Эти рекомендации реализуют основы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в разделе Microsoft Azure Well-Architected Framework.

Изложенные в этом разделе соображения обобщают ключевые выводы и лучшие практики, представленные этим решением.

• Использовать уровневое хранение данных в Озеро данных.

• Сделайте конвейеры данных воспроизводимыми и идемпотентными.

Security

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

• Обеспечьте безопасность и централизуйте конфигурацию.

Операционное превосходство

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

• Проверяйте данные на раннем этапе вашего конвейера.

• Убедитесь, что код преобразования данных можно тестировать.

• Хаве конвейер CI/CD.

• Контролируйте инфраструктуру, конвейеры и данные.

Развертывание этого сценария

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

Установка и развертывание

1. Initial setup: установите необходимые компоненты, импортируйте репозиторий GitHub Azure samples в собственный репозиторий и задайте необходимые переменные среды.

2. Развертывание ресурсов Azure: решение поставляется со скриптом для автоматизированного развертывания. Он развертывает все необходимые ресурсы Azure, а также учетные записи служб Microsoft Entra для каждой среды. Скрипт также развертывает Azure Pipelines, группы переменных и подключения служб.

3. Set up Git integration in dev Data Factory. Настройка интеграции Git для работы с импортированным репозиторием GitHub.

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

Развернутые ресурсы

Если развертывание выполнено успешно, в Azure должно быть три группы ресурсов: dev, stg и prod. В Azure DevOps также должны быть сквозные конвейеры сборки и выпуска, которые могут автоматически развертывать изменения в этих трех средах.

Подробный список всех ресурсов см. в разделе Deployed Resources раздела DataOps — демонстрация датчика парковки README.

Непрерывная интеграция и непрерывная поставка (CI/CD)

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

Скачайте файл в формате Visio этой архитектуры.

1. Разработчики разрабатывают в собственных средах-песочницах в группе ресурсов dev и коммитят изменения в собственные кратковременные ветви Git. Например: <developer_name>/<branch_name>.

2. Когда внесение изменений завершается, разработчики отправляют пулл-реквест (PR) в главную ветвь для проверки. Это автоматически запускает конвейер проверки PR, который выполняет модульные тесты, проверку стиля кода и сборку пакетов приложений уровня данных (DACPAC).

3. По завершении проверки PR коммит в главной ветви запускает конвейер сборки, который собирает и распространяет все необходимые артефакты сборки.

4. Успешное завершение конвейера сборки активирует первый этап конвейера выпуска. Это действие развертывает артефакты сборки, предназначенные для публикации, в среде разработки, за исключением Data Factory.

   Разработчики вручную выполняют публикацию в dev Data Factory из ветви совместной работы (main). Обновление шаблонов Azure Resource Manager в ветви adf_publish происходит вручную.

5. Успешное завершение первого этапа инициирует стадию ручного утверждения.

   После утверждения конвейер выпуска переходит ко второму этапу развертывания изменений в среде stg.

6. Запустите интеграционные тесты, чтобы протестировать изменения в среде stg.

7. После успешного завершения второго этапа конвейер активирует второй шлюз утверждения вручную.

   После утверждения конвейер выпуска переходит к третьему этапу развертывания изменений в среде prod.

Дополнительные сведения см. в разделе Build and Release Pipeline раздела README.

Testing

Решение включает поддержку как модульного, так и интеграционного тестирования. Он использует фабрику данных pytest-Data и платформу Nutter Testing Framework. Дополнительные сведения см. в разделе Testing в readME.

Наблюдаемость и мониторинг

Решение поддерживает возможность наблюдения и мониторинга для Databricks и Фабрики данных. Дополнительные сведения см. в разделе Observability/Monitoring раздела README.

Дальнейшие шаги

Если вы хотите развернуть решение, выполните действия, описанные в разделе Как использовать пример руководства DataOps - Parking Sensor Demo README.

Примеры кода решения на GitHub

• Визит страницу проекта на GitHub

Observability/monitoring

Azure Databricks

• Мониторинг заданий Azure Databricks с Application Insights

Data Factory

• Отслеживайте Фабрика данных Azure с помощью Azure Monitor
• Создание оповещений для упреждающего мониторинга конвейеров фабрики данных

Azure Synapse Analytics

• Мониторинг использования ресурсов и активности запросов в Azure Synapse Analytics
• Следите за рабочей нагрузкой пула SQL в Azure Synapse Analytics, используя динамические административные представления (DMVs)

служба хранилища Azure

• Monitor служба хранилища Azure

Устойчивость и аварийное восстановление

Azure Databricks

• Региональное аварийное восстановление для кластеров Azure Databricks

Data Factory

• Создание и настройка локальной среды выполнения интеграции — обеспечение высокого уровня доступности и масштабируемости

Azure Synapse Analytics

• Геоизбыточное резервное копирование и аварийное восстановление
• Геовосстановление для пула SQL

служба хранилища Azure

• Восстановление после сбоя и отказоустойчивость учетной записи хранилища
• наилучшие практики использования Azure Data Lake Storage 2-го поколения — высокая доступность и восстановление после аварий
• служба хранилища Azure избыточность

Подробный обзор

Подробные сведения о решении и ключевых понятиях см. в следующей записи видео: DataDevOps для современных Data Warehouse на Microsoft Azure