DevOps + Data: Синергия двух миров = DataOps
Дисклеймер:
Эта заметка будет полезна для людей незнакомых с направлением DataOps, для новичков, кто слышал об этом подходе и захотел узнать о чем это. Тут не будет глубоких технических подробностей, поэтому те, кто ждут хардкора, просьба пройти мимо этой статьи.
В этой заметке рассмотрим:
Почему появилась потребность в DataOps
Три простых идеи, на которых фокусируется DataOps
Работа с данными должна быть воспроизводимой
Аналитика как код
Кажется, что это логически вытекает из п.1., но не все так просто.Думайте о данных как о платформе
Что-то последнее время становится много Ops-ов: DevOps, MLOps, DataOps. Кто все эти люди ? Не спешите негодовать, это прежде всего подходы, методологии. Ops — сокращение от Operetional, ну, а первая часть это направление с кем эти operationals должны налаживать мосты и улучшать процессы.
А все началось с Патрика Дебуа на конференции DevOps Days в 2009 году в Генте (Бельгия). Патрик предложил объединить лучшие практики, подходы из двух сфер для достижения синергии в проекте, т.к. в конечном счете команды работают над одним проектом для достижения одной ценности. В DataOps история аналогичная.
Если кратко, то DataOps — это DevOps c контейнерами, CI/CD (Continuous Integration, Continuous Delivery) нацеленный на интеграцию и правильное конфигурирование узконаправленных тулов и подходов вроде MLflow, Kubeflow, Hadoop, оркестрация, metadata management, data quality, data integration, data discovery, data linage, BI….
А теперь рассмотрим подробнее зачем это и что это.
Так что же случится, если применить DevOps подходы, методологии к управлению большими данными?
Последнее время работа с большими данными становится все более доступной и распространенной, а самих данных становится все больше и растут они с огромной скоростью. Эти данные нужно как-то хранить, обрабатывать и работать с ними (ведь мы их для какого-то полезного действия сохранили). Инженерное мышление любит оптимизации, инженеры посмотрели на задачи стоящие в работе с большими данными и на DevOps и решили — зачем изобретать ещё 1 велосипед? Мы просто возьмем DevOps подходы.
DataOps — это новая парадигма, которая использует принципы, лучшие практики DevOps и применяет их к управлению данными.
Важно обратить внимание на то, чтобы не возникало бутылочных горлышек, так команда по обработке данных должна работать не менее эффективно, чем команда разработчиков, чтобы не блокировать работу друг-друга и в этом есть дополнительная польза DevOps принципов.
Как известно, дьявол кроется в деталях, рассмотрим ниже три простые мысли, на которых должен быть сфокусирован DataOps.
1. Работа с данными должна быть воспроизводимой
Огромный пласт сервисов ушел в облака и работа с данными не исключение. В облачных решениях мы привыкли, что новый сервис готов к работе после нажатие одной кнопки, ну максимум двух. В работе с большими данными не все так просто и прозрачно. Этот пункт является ответом на подобные вопросы: «Давайте не будем заново обрабатывать данные, а что если мы не сможем снова получить подобный результат ?» или еще лучше, «Мы понятия не имеем как\откуда мы получили эти данные».
Ваши пайплайны должны выстраиваться вокруг ваших внутрикомандных процессов доставки, подготовки, деплоя.
Делая работу с данными воспроизводимой вы закрываете риски о невозможности получения требуемых данных, избавляетесь от бутылочного горлышка, т.к. в любой момент времени вы можете любая команда (вы непрямую не зависите от одной команды при правильном построении пайплайна) может получить требуемые данные.
2. Аналитика как код
Для описания инфраструктурных ресурсов достаточно часто используется YAML формат описания или YAML подобные структуры. Это помогает в человекочитаемом виде отобразить то, что мы хотим увидеть в окружении, версионировать, улучшать ну и получать все преимущества подхода IaC (Infrastructure as code). Когда дело касается анализа данных мы часто полагаемся на внешний интерфейс специализированных тулов, и что делать в таком случае?
Аналитику можно рассматривать как код и конфигурацию, которые описывают действия с данными для получения обработанной информации.
Таким образом работа с данными будет воспроизводима и ее можно интегрировать в конвейер и быть более гибкими в процессе внесения изменений, обновления инфраструктуры.
Наличие надежного воспроизводимого пайплайна для обработки и получения данных позволяет создать процесс аналитики в виде кода.
3. Думайте о данных как о платформе
Третьим шагом после воспроизводимого конвейера данных и подхода аналитика как код является создание эффективных решений на основе полученной информации.
Эти решения должны быть легко масштабируемыми, предлагать данные в качестве платформы — это главная задача инженера. Эта методология позволяет разработчикам запускать свои среды для быстрого прототипирования, получать данные здесь и сейчас и на их основе уже создавать продукты.
Облачные решения достаточно гибкие, с каждым годом количество и качество облачных сервисов увеличивается, кроме этого они становятся более доступные не только большим компаниям, но простым стартам и даже одиночкам разработчикам.
Таким образом, DataOps становится парадигмой, наиболее подходящей для облачных продуктов, чему способствует развитие искусственного интеллекта и машинного обучения. Работа облачного инженера по налаживанию мостов внутри команды и оптимизации данных становится неотъемлемой частью этого подхода. Как следствие, фокус ориентированный на данные с каждым днем становится все более важным и востребованным.
В заключение хочу пригласить всех желающих на бесплатный вебинар по теме «Облака и on-premise решения в обработке данных», который проведет мой коллега Егор Матешук. На вебинаре будут рассмотрены основные технологические платформы для построения систем обработки данных. Какие варианты есть для развертывания on-premise? Какие инструменты предлагают облачные провайдеры? Какие тенденции появились в платформах в последние годы?. Запись на вебинар доступна по ссылке.
