Основные концепции и доступные инструменты для создания конвейера данных, о котором вы мечтаете

Итак, я понимаю, что немного опоздал с этим, поскольку концепция DataOps существует примерно столько же, сколько я занимаюсь технологиями, но я недавно наткнулся на это и, прочитав об этом, я подумал, что могут быть другие люди, такие как я. чей разум будет взорван этим. Есть много хороших идей, которые можно реализовать по отдельности, постепенно, и даже если вы не доберетесь до решения «одна кнопка делает все сразу», многое можно выиграть, следуя принципам фреймворка. Более того, наличие фреймворка буквально объединяет множество отдельных концепций в один пакет, что делает отдельные концепции более понятными и дает вам идеальную цель, к которой нужно стремиться.

Что такое DataOps и почему это так похоже на DevOps?

DevOps – это сочетание принципов работы внутри организации, лучших практик и инструментов, которые помогают компаниям быстро разрабатывать и поставлять программное обеспечение. Цель состоит в том, чтобы максимально автоматизировать жизненный цикл продукта (сборка, тестирование, развертывание и т. д.). Ключевые слова здесь — непрерывная интеграция (CI) и непрерывная поставка (CD) программного обеспечения с использованием по требованию ИТ-ресурсов (инфраструктура как код), отсюда и название — DEVelopment + OPerationS/IT. Это своего рода практическая сторона или реализация, делающая возможной методологию Agile.

DataOps вкратце описывается как DevOps, применяемый к данным, что является хорошим обобщением, но мало что говорит. Каждый, кто когда-либо работал с более сложной системой, знает, что существует больше переменных, влияющих на получение ценности от продукта данных, чем от продукта программного обеспечения. Итак, давайте копнем немного глубже. Да, цель та же — быстрое предоставление ценности предсказуемым и надежным способом. Тем не менее, DataOps стремится решить проблему не только доставки ваших заданий по приему и преобразованию данных, моделей и аналитики в виде версионного кода, но и самих данных. Он пытается сбалансировать гибкость с управлением — одно ускоряет доставку, а другое гарантирует безопасность, качество и возможность доставки ваших данных.

С точки зрения изменения взглядов на различные компоненты конвейера данных, есть несколько основных моментов, которые я заметил во время чтения:

  • Извлечение, загрузка, преобразование (ELT) — данные должны загружаться в необработанном виде, без каких-либо ненужных преобразований в хранилище данных или озеро. Преимущество этого заключается в сокращении времени загрузки и сложности ваших заданий приема. Цель также состоит в том, чтобы не отбрасывать ничего, что может потенциально принести пользу позже, сохраняя все в исходной форме вместе с вашими преобразованными и готовыми к аналитике данными. В некоторых случаях по юридическим причинам требуется некоторая трансформация, и ее нельзя избежать, тогда вы увидите эту аббревиатуру — EtLT. В том же духе никакие данные не удаляются... никогда. Просто предполагается, что он может быть заархивирован в более дешевых решениях для хранения данных.
  • CI/CD — для тех, кто знаком с DevOps, новой концепцией здесь является концепция объектов базы данных жизненного цикла. Современные платформы данных, такие как Snowflake, предлагают некоторые расширенные функции, такие как путешествия во времени и клонирование с нулевым копированием. Кроме того, существуют решения для управления версиями и расширения вашего озера данных, например lakeFS.
  • Дизайн кода и удобство сопровождения — все дело в небольших повторно используемых фрагментах кода в форме компонентов, модулей, библиотек или чего-то еще, что используемые фреймворки предлагают в виде атомарных объектов кода. Естественно, каждая компания создавала свой собственный репозиторий этих данных и превращала их в стандарт для всех внутренних проектов. Должно быть очевидно, что код должен следовать лучшим практикам, иметь стандартный стиль и форматирование. Хорошая документация также имеет решающее значение.
  • Управление средой.Возможность создавать и эффективно поддерживать как долгоживущие, так и кратковременные среды из филиалов крайне важна для DataOps.

В манифесте DataOps перечислены 18 общих принципов, и они действительно очень похожи на смесь принципов Agile и DevOps, подробнее о них можно прочитать на официальной странице. Вот существенный сдвиг в сознании, который должен произойти, чтобы применить все это к конвейеру данных — вам нужно начать думать о своих данных как о продукте.

Чем отличается «Продукт данных»?

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

  • проект управляется и разрабатывается командой на протяжении всего срока его реализации и имеет дату окончания, когда он сдан. У продукта, с другой стороны, есть команда владельцев, поддерживающая его, и к нему не привязана дата окончания.
  • у проекта есть объем и цель, и он может быть выпущен несколько раз, пока не достигнет этой цели, но как только это будет сделано, проект также будет считаться выполненным. С другой стороны, продукт — это то, во что люди инвестируют, он развивается, обновляется, пересматривается и постоянно улучшается (в Agile-способе).
  • тестирование проекта ограничено определенным и утвержденным объемом. Продукт, с другой стороны, имеет автоматизированные модульные, регрессионные и интеграционные тесты как часть процесса выпуска.

Если вы посмотрите на DataOps, появится следующая диаграмма (или ее варианты). Он очень хорошо описывает бесконечный процесс планирования, разработки, тестирования и доставки кода. Это также намекает на необходимость сотрудничать с бизнесом (заинтересованными сторонами продукта) на разных этапах и получать действенную обратную связь, чтобы использовать ее в следующей итерации.

Осмысление моря инструментов, фреймворков и языков

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

В любом случае прямо или косвенно все инструменты и фреймворки генерируют какой-то код, по крайней мере, если соблюдаются все принципы и у вас есть версии для ваших конфигураций и все настроено так же, как и для любого другого программного проекта.

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

DataOps пытается упростить это с помощью концепции центрального репозитория, который служит единым источником правды для «любого кода и конфигурации» в вашей системе, обычно называемого «конвейером данных» (что немного двусмысленно, поскольку я обычно представляют себе прямую трубу от истока до раковины, примите во внимание предостережение выше). Если мы представим, что у нас есть всезнающий репозиторий с автоматизированной оркестровкой данных и процессов, обрабатывающих их, то релиз изменения осуществляется всего одним щелчком мыши. Более того, отслеживание того, кто что делает, и сотрудничество становятся намного проще, когда каждая команда может видеть изменения в разработке и те, которые происходят в любой момент. Это уменьшает количество потенциальных ошибок, вызванных недопониманием, и повышает качество конечного продукта данных.

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

Трубопроводы

Говоря о конвейерах в DataOps, мы можем иметь в виду два возможных типа:

  • Разработка и развертывание — это то, что знакомо по DevOps. Это конвейер CI/CD для создания, тестирования и выпуска контейнеров, API, библиотек и т. д. платформы данных.
  • Данные — это конвейер, управляющий всеми компонентами (будь то запланированные задания, постоянно работающие веб-службы и т. д.), которые фактически перемещают данные из местоположения А в местоположение Б и применяют всю необходимую обработку. Возможно и весьма вероятно, что у компании их будет немного.

Работа

Это часть с большинством переменных. Есть так много вариантов, чтобы:

  • какие технологии использует — Snowflake, Airflow, Python, HTTP..
  • что его запускает — запланировано ли оно, ждет ли выполнения условия, работает ли оно постоянно
  • где он работает — на локальном сервере, в частном облаке, в сторонней среде, о которой вы мало что знаете
  • как он обрабатывает ошибки
  • что определяет успех

Каталог данных

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

Существуют инструменты каталогизации данных, продвигающие расширенные каталоги машинного обучения, которые должны быть в состоянии обнаруживать данные, курировать их, выполнять тегирование, создавать семантические отношения и обеспечивать простой поиск по ключевым словам в метаданных. Машинное обучение может даже рекомендовать преобразования и автоматическое предоставление данных и спецификаций конвейера данных. Однако даже с ML любой каталог данных хорош настолько, насколько хороши данные и метаданные, с которыми он работает. Централизованно организованный конвейер DataOps «знает» все о том, откуда поступают данные, как они тестируются, преобразовываются и обрабатываются, куда они попадают и т. д.

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

Тестирование

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

Чего не хватает в приведенном выше потоке, так это того, что сложность этапа тестирования в DataOps также удвоена. Чтобы провести надлежащее регрессионное и интеграционное тестирование, вам необходимо выбрать репрезентативный набор данных (что само по себе нетривиальная задача) и обезличить его. Более того, часто возникают проблемы, которые на самом деле могут быть обнаружены гораздо дальше по течению вашего пайплайна. Поэтому для интеграционного теста вам нужна почти сквозная настройка. Это как техническая, так и финансовая задача — воспроизведение полного конвейера даже на мгновение может быть слишком дорогим и труднодостижимым. В мире, где DataOps реализован в чистом виде, это может быть возможно, но во многих случаях, особенно у небольших компаний, на самом деле нет ресурсов для этого. Цель состоит скорее в том, чтобы использовать эти принципы в качестве руководства при проектировании своей системы и пытаться внедрить те элементы, которые принесут вам наибольшую пользу и сэкономят вам больше всего времени, усилий и затрат… легко, верно?

Инструменты DataOps

Все это звучит хорошо в теории, но как хотя бы начать это реализовывать? Что ж, на рынке есть инструменты, которые утверждают, что работают в этой области и действительно следуют этим принципам, каждый в разной степени. Самые большие:

  • Unravel — предлагает мониторинг и управление на основе ИИ. Он проверяет код и дает представление о том, как улучшить тестирование и развертывание. Это для компаний, которые хотят сосредоточиться на оптимизации производительности своего конвейера.
  • DataKitchen — служит скорее дополнением к вашему существующему конвейеру и предоставляет типичные компоненты DevOps, такие как CI/CD, тестирование, оркестровка и мониторинг.
  • DataOps.live — в дополнение к компонентам DevOps, dataOps.live предоставляет некоторые элементы конвейера данных, такие как ELT/ETL, моделирование и управление. Если клиенты используют Snowflake, они также могут извлечь выгоду из возможностей управления версиями и ветвления базы данных.
  • Zaloni — в отличие от двух предыдущих, этот в значительной степени сосредоточен на конвейере данных и доставке всех его компонентов на одной платформе. Это не значит, что они не предлагают компоненты DevOps, они их предлагают. Это очень хорошо продуманный инструмент, который идеально подходит для компаний со строгими требованиями к управлению.