В моей предыдущей статье я объяснил, как вы можете построить и внедрить мониторинг качества данных в своем озере данных с помощью Great Expectations (GE) и Allure Serverless. Хотя процесс, который я описал, довольно прост и понятен, ручная реализация может потребовать много времени и ресурсов, поэтому я предлагаю более быстрый способ повысить качество данных в новой среде. В этой статье я обсуждаю ограничения предыдущего подхода и предлагаю способы их обойти.

Суть работы

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

Для этого мы отказываемся от использования Serverless Framework. Вместо этого мы будем применять сценарии Terraform и использовать Pandas Profiling для создания тестов данных на основе отчетов о профилировании. Все, что вам нужно сделать, это настроить переменные в конфиге и запустить скрипт. После развертывания запустите Step Functions Pipeline с файлами, которые вы хотите проверить на качество данных.

Имейте в виду, что ваши входные данные важны. Мы используем озеро данных в Amazon S3 с запланированными еженедельными проверками данных. Мы не используем исторические и фильтруемые данные, а только данные, которые обрабатываются в текущей DAG.

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

В нашей предыдущей реализации мы использовали Pandas Profiling для профилирования и Great Expectations для таких тестов:

Параллельно запускайте AWS Lambda с Pandas Profiling и GE Test Suite для каждого набора данных и храните/обслуживайте каждый из них как статический веб-сайт S3.

Вот как работают пошаговые функции:

Теперь мы разобьем профилирование и тестирование на отдельные этапы. Во-первых, давайте проверим набор данных профиля.

Далее нам нужно сгенерировать набор тестов на основе результатов профилирования. Поскольку Pandas Profiling по умолчанию сохраняет комплекты без несбывшихся ожиданий, мы не сможем настроить. Давайте переопределим класс Expectation, добавив:

После этого вы сможете настроить свои собственные предварительные ожидания для генератора тестов Fly:

Обязательно используйте новый обработчик ожиданий, чтобы пакет можно было сохранить на Amazon S3:

Запуск тестов контроля качества данных

Двигаясь вперед, давайте выясним, как начать выполнение тестов с помощью движка GE.

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

Чтобы запустить конвейер, вам нужно использовать этот шаблон: file_path и new_expectation логическое значение, по умолчанию «true» — он будет создавать новый набор ожиданий для каждого запуска. Вы также можете запустить его один раз и установить для него значение «false», чтобы начать использовать этот набор тестов.

Это просто общая концепция. Теперь давайте поговорим об использовании Terraform и развертывании нашего решения. Чтобы объяснить эту часть, я передаю эстафету Егору Городову, DevOps в Provectus.

Включение DevOps

Развертывание

Мы решили использовать AWS в качестве платформы для запуска нашего решения Fast Data QA. Он предоставляет нам все необходимые услуги для создания масштабируемой инфраструктуры и управления ею различными способами. Здесь у нас есть два варианта:

  1. CloudFormation
  2. Терраформ

В настоящее время мы используем Terraform в качестве основного инструмента для создания и управления воспроизводимой инфраструктурой. Конечно, есть плюсы и минусы его использования, но он идеально подходит для Fast Data QA.

Шаг 1 — А.К.А. «Портативный»

На данный момент у нас уже есть работающий FAST DATA QA MVP в образовательной учетной записи AWS. Мы должны иметь возможность воспроизвести его в нашей основной/отдельной учетной записи. Для этого мы проверим, какие части инфраструктуры нам нужно описать, используя Terraform. В нашем случае это:

  • Ведро конфигурации S3
  • Таблица DynamoDB
  • ECR (три репозитория, по одному на лямбду)
  • Лямбды (по одной на шаг, всего три)
  • ШагФункция
  • Хранилище параметров SSM​

Как только мы поймем, какие ресурсы нам нужно описать, пришло время создать новый проект Terraform. Перед обычной «инициализацией терраформирования» нам нужно добавить провайдера AWS.​

У каждого ресурса есть свой идентификатор в AWS. Это может быть «имя», «id», «arn» или любые подобные идентификаторы. У нас есть ключи идентификатора и сами идентификаторы; кроме того, нам нужен правильно названный «ресурс» в сценарии Terraform, чтобы мы могли дать команду: «Terraform, пожалуйста, импортируйте ресурс с именем «MyResource» в «terraform_resource.MyResource». После этого мы можем просто скопировать импортированное состояние в скрипт Terraform, — и вуаля! Этим ресурсом теперь управляет Terraform.

Шаг 2 — Параметризация​

После того, как мы импортировали ресурсы AWS и ими управляет Terraform, нам нужно настроить библиотеку GreatExpectation перед запуском. Обычный подход для GE заключается в хранении файлов конфигурации и плагинов под определенными ключами S3. Итак, давайте параметризируем и шаблонизируем их.

​

Во-первых, файл «great_expecations.yml». Здесь нам нужно шаблонизировать только один параметр — «bucket_name», вот так:

Кроме того, у нас есть набор файлов GreatExpectation, таких как «plugins» и «custom_styles». Мы должны копировать их как есть, но хранить в корзине S3 с жесткой структурой. Лучший способ сделать это — воспроизвести требуемую файловую структуру в каталоге Terraform, а затем использовать «aws_s3_bucket_object» с шаблонными путями ключей.

Шаг 3 — КИ​

Мы используем Git как систему контроля версий. Мы храним кодовую базу на собственном сервере GitLab.

Поскольку у нас есть три лямбда-выражения, и каждому из них нужен собственный образ докера, нам нужно место, где эти докеры можно создавать и отправлять в ECR. Для этого мы будем использовать Gitlab CI Runner. Существует несколько решений с открытым исходным кодом на основе Terraform, но все они предлагают функциональность, которая нам не нужна. Вместо этого мы решили создать простой «внутрипроектный» модуль Terraform, который состоит из:

  • Подробная информация о VPC и сети
  • Группа автоматического масштабирования AWS с «launch_template»
  • Пользователь CI и роль IAM, которые разрешают только операции ECR​

ВКД

Нам просто нужен базовый VPC с «aws_internet_gateway», общедоступной «aws_subnet», «aws_route_table», «aws_route», «aws_route_table_association» и группой безопасности с выходом.

Группа автоматического масштабирования AWS с «launch_template»

Поскольку мы не собираемся использовать такие инструменты подготовки, как Ansible, мы решили использовать «aws_launch_template» с «aws_autoscaling_group» и простой шаблон sh, созданный по шаблону Terraform и запускаемый при запуске. Этот скрипт устанавливает docker, docker-machine, двоичный файл gitlab-runner и запускает этот бин для регистрации бегунов на сервере Gitlab.

GitLab Runner​

  • Установите бегун
  • Зарегистрируйте бегуна

После применения модуля GitLab-CI мы видим зарегистрированного исполнителя в пользовательском интерфейсе GitLab и готовы создать файл «gitlab_ci.yml» с инструкциями по сборке образов докеров и отправке их в ECR. Кроме того, нам нужно передать дополнительные переменные env в конвейер CI, чтобы параметризовать каждый этап конвейера. Для этого используйте этот код Terraform:

Пользователь CI и роль IAM, которые разрешают только операции ECR

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

Шаг 4 — Подведение итогов

Теперь у нас есть:

  • CI-модуль Gitlab
  • Основной модуль с лямбда-выражениями и т. д.
  • Корневой модуль с двумя описанными выше модулями, удаленным состоянием управления и переменными для модулей и провайдеров.

Все вышеперечисленное позволяет нам выполнить следующий вариант использования:

  1. Добавьте элементы или измените набор тестов GreatExpectation.
  2. Слияние изменений с определенными ветками Git
  3. Gitlab CI запускает конвейер, который упаковывает новый образ Docker и отправляет его в AWS ECR.
  4. Изменить переменные docker_image в Terraform
  5. Применить Терраформ

Заключение

В итоге мы получаем скрипт Terraform One-Click, который легко настраивается для новых проектов. Как только мы запустим его, у нас будет готовый к работе конвейер качества данных на основе функций Lambda/Step, который можно использовать с любым инструментом BI Dashboard.

Чтобы узнать больше о практике обеспечения качества данных Provectus, посетите веб-страницу