Среда разработки данных с CI/CD
DataEngineering — это наука и искусство получения качественных и своевременных данных. Его цель — доставлять пользователям данные даже в большей мере, чем приложения. Существуют отличные методы и инструменты, которые помогают доставлять приложения с неизменно высоким качеством. А какие методы и инструменты помогают нам предоставлять высококачественные данные?
В этой статье я возьму три следующие концепции: среды разработки, непрерывную интеграцию и непрерывное развертывание и покажу, как они должны выглядеть в мире доставки данных. Я также приведу примеры инструментов, которые помогут вам создать основу для вашего приложения для работы с данными.
Что такое среда разработки для данных?
При разработке приложений, интенсивно использующих данные, нам нужно экспериментировать с новым кодом, новыми наборами данных, изменениями в коде или изменениями данных в инструментах анализа данных — например, новый ETL, изменения формата или схемы, новый алгоритм сжатия, точность, обновление версии Spark/Presto и так далее.
Хотя типы экспериментов отличаются, потребность остается неизменной: мы должны иметь возможность проводить изолированные эксперименты с конвейерами данных в среде, похожей на нашу производственную среду, не опасаясь ее компрометации.
Давайте предположим, что у нас есть возможность управлять нашим Data Lake так же, как мы управляем нашим репозиторием кода. Управление версиями данных позволяет выполнять операции, подобные Git, над репозиториями больших данных, а также обеспечивает ветвление, коммиты, слияния и перехваты. Важно убедиться, что эти операции выполняются экономично и нет лишнего копирования данных. Все Git-подобные действия должны быть операциями с метаданными и, следовательно, максимально быстрыми и атомарными.
Создать среду разработки несложно, и она может предотвратить дорогостоящие ошибки в производстве. Создавая ветку наших производственных данных, мы получаем изолированную среду данных, представляющую собой скриншот нашего репозитория. Изменения, внесенные в основную ветку после ее создания, не видны внутри ветки, если только мы не объединим их явным образом.
Пока мы работаем над нашей веткой изолированно, наши изменения не видны всем другим пользователям, работающим над главной веткой репозитория. Подводя итог, мы можем сказать, что ветка предоставляет нам собственное частное Data Lake для экспериментов.
Рассмотрим эксперимент по обновлению версии Apache Spark. Для этого мы создаем ветку, которая будет использоваться только для тестирования обновления Spark и отбрасывается позже. Задания могут выполняться без сбоев (теоретическая возможность все же существует!), а могут завершаться с ошибкой на полпути, оставляя нам некоторые промежуточные разделы, данные и метаданные. В этом случае мы можем просто вернуть ветку в исходное состояние, не беспокоясь о промежуточных результатах нашего последнего эксперимента, и выполнить еще один (надеюсь, успешный) тест на изолированной ветке. Предполагая, что действия по возврату являются атомарными и немедленными, ручной очистки не требуется.
После завершения тестирования и достижения желаемого результата мы можем удалить эту экспериментальную ветку, и все наши изменения данных исчезнут.
Что такое непрерывная интеграция данных?
При введении новых наборов в Data Lake мы должны убедиться, что они соответствуют ожидаемым нами инженерным требованиям и требованиям к качеству, таким как формат, схема, диапазон данных, управление PII и т. д. В приложениях, где потребление новых данных является стандартной задачей, интеграция постоянного добавления новых данных в наше Data Lake является основной потребностью, подобно тому, как мы интегрируем новый код в нашу базу кода. Непрерывная интеграция данных — это автоматический и безопасный прием данных в наше Data Lake, при котором мы обеспечиваем соблюдение требований к качеству данных.
Помимо операций, подобных Git, у нас также есть среды тестирования данных, которые позволяют нам легко проводить проверки метаданных и тесты качества данных. Тесты могут включать лучшие инженерные практики, такие как схема или формат, или сложные тесты на основе машинного обучения, чтобы найти аномалии в наблюдаемом поведении данных.
Хорошей практикой было бы загружать данные в изолированную ветку так, чтобы ваши пользователи не знали об этом.
Теперь перед слиянием мы определяем набор обработчиков, которые запускают наши тесты проверки данных. Только после того, как тесты пройдены, данные будут объединяться с основной веткой озера и будут представлены пользователям. Если тест не пройден, мы уведомляем автора об ошибке соответствующего проверочного теста. Таким образом, мы достигаем высококачественного приема данных с атомарными операциями, подобными Git, освобождая себя от проблем с дальнейшей очисткой.
Что такое непрерывное развертывание данных?
В средах, которые производят данные у вас есть потоковая передача данных, а также выполняются организованные задания на основе времени, а существующие наборы данных обновляются самыми свежими данными. Даже когда код и среда не меняются, данные динамичны и меняются постоянно. Новые данные подпитывают приложение и позволяют предоставлять актуальную информацию. Данные постоянно развертываются в рабочей среде, поэтому непрерывное развертывание данных в рабочей среде — это процесс, который позволяет проверять данные и обеспечивать качество перед развертыванием данных в рабочей среде, где они используются внутренними или внешними клиентами.
Предположим, помимо Git-подобных операций и фреймворков для тестирования данных, у нас есть инструменты оркестровки, которые позволяют нам автоматизировать выполнение сложных операций с данными, требующими выполнения небольших заданий по анализу данных. Это ключ к непрерывному развертыванию данных в рабочей среде. Посмотрите, как работают Apache Airflow, Luigi, Dagster, и Prefect.
Теперь запустить непрерывное развертывание для данных будет очень просто:
- Мгновенное откатывание изменения данных. Если некачественные данные становятся доступны нашим пользователям, мы можем мгновенно вернуться к прежней, согласованной и правильной копии нашего озера данных. Делая историю коммитов доступной для настройки продолжительности, мы можем мгновенно откатить озеро к предыдущей версии одним атомарным действием.
-
Предотвращаем проблемы с качеством данных, включая:
- Тестирование производственных данных в изолированной ветке перед их доставкой пользователям/потребителям с использованием перехватчиков в системе оркестровки, которая запускает свой конвейер в изолированной ветке.
- Тестирование промежуточных результатов изолированно в нашем DAG’e, чтобы избежать каскадных проблем с качеством и легко управлять хранением таких промежуточных результатов с помощью логики хранения ветвления.
- Обеспечение согласованности между коллекциями: предоставьте потребителям несколько наборов данных, которые должны быть синхронизированы в одном атомарном обратимом действии. Используя ветки, авторы могут обеспечить гарантии согласованности между различными логическими коллекциями — слияние с основной ветвью выполняется только после успешного создания всех соответствующих наборов данных.
Вывод
У нас есть все необходимые инструменты, чтобы сделать нашу среду больших данных устойчивой и управлять новыми данными и повседневными производственными данными, обеспечивая при этом высокое качество доставки. Мы должны быть открыты для новых методологий и технологий и создавать современную инфраструктуру данных мирового класса.
