Чем инженерия данных отличается от разработки ПО, как организовать оркестрацию конвейеров обработки данных и внедрить лучшие практики CI/CD.
Почему дата-инженерия отличается от разработки ПО
При том, что между инженерией данных и разработкой программного обеспечения (ПО) очень много общего, эти ИТ-дисциплины довольно сильно отличаются. Хотя в обоих направлениях используется облачная инфраструктура, контейнеризация, CI/CD и GitOps, конвейеры данных — это не приложения, которые можно перезапустить в любой момент благодаря сохранению состояния в базе данных, работающей в отдельном процессе. Как и приложения, конвейеры данных представляют собой части ПО, сами по себе они не имеют ценности для конечного потребителя. В отличие от приложений, конвейер данных является инфраструктурой, средством доставки данных к конечному потребителю, для которого ценность представляют сами данные, а не инструменты их транспортировки. Подробнее о сложностях управления зависимостями между разными конвейерами и вариантах их проектирования читайте в нашей новой статье.
В отличие от информационной системы, которая имеет целый ряд вариантов использования, конвейер обработки данных имеет только одну функцию — предоставить запрошенный датасет потребителю. Таким образом, конвейер имеет точную точку завершения, несмотря на необходимость постоянного обслуживания из-за изменений в данных и требованиях пользователей. Конвейер управляет большим количеством состояний, выполняя преобразования данных из множества систем-источников, которые он не контролирует. Некоторые конвейеры создают наборы данных постепенно, добавляя изменения при каждом запуске и играя роль очень длительных процессов. Наконец, конвейер данных очень сильно зависит от источника, любое изменение которого может повлиять на стабильность и надежность инструмента транспортировки данных, а также потребителей.
Примечательно, что работы по построению конвейера данных не особо соответствуют популярной сегодня философии быстрой разработки (Agile) из-за транзакционного характера передачи информации. Конвейер данных не может приносить ценность инкрементально: он либо доставляет нужный набор данных для клиента либо нет. Это вызывает сложности при попытки постановки задач на разработку конвейера данных в бэклог спринта. Требование к созданию конвейера данных невозможно выразить в форме пользовательской истории, т.к. пользователю ценна не инфраструктура доставки данных, а сами данные. С точки зрения продуктовой разработки, создание конвейера данных больше похоже на спайку – задачу обеспечения, а не поставки инкремента. Таким образом, вместо пользовательских историй на скрам-доске появляются задачи, такие как создать коннектор API или логику приема данных, что больше соответствует водопадному стилю планирования.
Кроме того, частичный датасет обычно не несет никакой практической пользы: невозможно построить ML-модель, не имея значений обучающих метрик в достаточном количестве. Конвейер данных не состоит из независимых заданий, каждое из которых создает необходимый потребителю столбец в таблице. Поэтому время разработки конвейера не всегда коррелирует с размером набора данных из-за сложной логики их преобразования. Хорошо спроектированный конвейер способен обработать любое количество записей, но его производительность может зависеть от характера передачи (пакетная или потоковая), доступности источников и нагруженности ETL-сервисов, в частности, объемов данных, которые помещаются в оперативную память в конкретный момент времени.
Чем больше набор данных, тем больше времени требуется для его создания и обновления. Редактирование одной записи в огромной базе данных является тривиальным и быстрым процессом, но это нетипичный сценарий для аналитических наборов данных. Изменение набора аналитических данных обычно включает в себя обновление миллионов строк, добавление или изменение целых столбцов, что приводит к изменению всех записей. Хотя самый простой способ обновить набор данных — это перезаписать все записи, повторно запустив конвейер, это будет очень дорого с точки зрения вычислительных затрат и времени. Поэтому лучше сделать конвейер идемпотентным, о чем мы писали здесь, чтобы он правильно перезаписывал состояние предыдущих запусков без дублирования данных и вычислительных операций.
Аналитика больших данных для руководителей
Код курса
BDAM
Ближайшая дата курса
13 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Логика обновления набора данных также может быть закодирована в отдельном конвейере, который принимает прежний датасет на вход, чтобы вычислить изменение (дельту). Это эффективнее в плане стоимости и скорости вычислений, но сложнее в разработке. Дельта-конвейеры не являются идемпотентными и требуют отслеживания состояний, а также дополнительного времени выполнения определенных операций. При этом не избежать обновления прежнего конвейера данных, чтобы включить изменения в новые наборы. А из-за инерционного характера больших наборов данных, результаты видны не сразу. Поэтому внедрение всех принципов DevOps и Agile для разработки конвейера данных нецелесообразно, из-за бессмысленности частого развертывания и инерции данных.
В заключение следует отметить сложности в тестировании конвейеров обработки данных. В частности, интерфейсы связи между системами нельзя протестировать с помощью модульных тестов, т.к. они не могут выполняться изолированно. Не возможно точно сымитировать поведение внешней системы (источника или приемника данных), включая все варианты события сбоя: от недоступности сервиса из-за аппаратной аварии до изменения структуры и формата сообщений. Системы источники (продюсеры сообщений) очень часто нарушают контракты данных, изменяя структуры и форматы полезной нагрузки отправляемых пакетов.
Кроме того, модульные тесты для проверки ограниченной автономной логики преобразования в конвейере сложнее кода, поскольку требуют от разработчика создания репрезентативных тестовых и ожидаемых выходных данных. В функциях, которые преобразуют набор данных, аргумент может иметь множество параметров, генерация и проверка которых займут много времени. Интеграционные тесты конвейера данных требуют запуска в промышленной среде, т.е. необходимо полное развертывание.
Таким образом, конвейеры данных — это программное обеспечение, но не программные продукты. Это инфраструктура, необходимая для поставки ценности, оснастка, которая сама по себе не имеет смысла для конечного потребителя. Тем не менее, работы по ее организации требуют множества сил и времени из-за транзакционного характера этих инструментов передачи данных и необходимости развертывания в производственной среде. Как повысить эффективность этих процессов с помощью оркестрации конвейеров и внедрения некоторых практик CI/CD, мы рассмотрим далее.
Лучшие практики управления конвейерами данных
Важно правильно управлять конвейерами данных, поскольку это влияет на качество данных, скорость обработки и удовлетворенность потребителей. Прозрачность и наглядность управления конвейером делает его эффективным, когда все дата-инженеры знают, как именно преобразуются данные, откуда они берутся и где заканчивается процесс преобразования данных. Это реализуется через мониторинг происхождения данных (Data Lineage) и соответствует концепции DataOps, о лучших практиках которой мы писали здесь. А организовать надежную и управляемую оркестрацию конвейеров данных можно с помощью Apache AirFlow и подобных инструментов (Dagster, Luigi и пр.). Как в этом случае помогает обработка исключений, читайте в нашей новой статье.
Ускорить процессы развертывания помогут облачные инфраструктуры, включая контейнеризацию с Kubernetes и скрипты Terraform, которые позволяют безопасно и эффективно создавать, изменять и версионировать ИТ-инфраструктуру, от низкоуровневых компонентов, таких как вычислительные экземпляры, хранилище и сеть, а также высокоуровневых составляющих, таких как записи DNS и функции SaaS. Также целесообразно внедрить некоторые практики непрерывной интеграции и поставки (CI/CD), включая автоматизацию сборки, тестирования и развертывания изменений кода. Сюда относится система контроля версий, такая как Git, чтобы управлять изменениями в конфигурациях кода и конвейера данных, гарантируя их отслеживаемость и обратимость. Также необходима автоматизация тестирования, включая модульные, интеграционные и сквозные тесты. Автоматизация процесса сборки при каждом изменении ускоряет выявление и устранение проблем, а общий репозиторий артефактов улучшает управляемость пакетами. Технически реализовать это можно с помощью специализированных CI/CD инструментов, таких как Jenkins, GitLab CI/CD, CircleCI, Azure DevOps и Travis CI. Впрочем, несмотря на многообразие этих инструментов, попытка внедрить их идеи, например, в автоматизированную миграцию потоковых конвейеров обработки данных на Apache NiFi, оказывается довольно сложной, что мы разбираем в этом материале.
Для управления инфраструктурой как кодом, включая облачное хранилище данных и ресурсы обработки, подойдут такие инструменты, как Terraform и Kubernetes, а для ETL-процессов пригодятся dbt и Apache Beam. Наконец, для управления процессами моделирования данных можно использовать Dataform.
Узнайте больше подробностей по проектированию и поддержке современных дата-архитектур в проектах аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
