Поиграем в DataOps (давай вечером)

Все нижеизложенное есть моя авторская «интертрепация» содержимого книги «The DataOps CookBook», написанная исключительно с целью дать начальное понимание концепции непосвященным. Для полноценного погружения в тему рекомендуется обратиться к оригиналу.

Ключевая сложность мира больших данных, да и вообще всего IT, заключается в многообразии терминов, для людей, незнакомых с ними, напоминающих заклинания из произведений/фильмов о Гарри Поттере. Иногда мне кажется, что их специально выдумывают, чтобы закрыть доступ для «маглов», создавая искусственное впечатление «тайны за семью печатями». Мне же, напротив, нравится объяснять сложные понятия простыми словами, насколько это в моих силах, следуя при этом заветам автора бессмертного суперхита про «детства чистые глазенки» (счастливым обладателем первого за 13 лет альбома коего я недавно стал, хэштег - #немогумолчать), заставляя мозг читателя «немножко как бы работать».

Сегодня я хочу поговорить про одно из них: DataOps. Звучит зловеще, как по мне, что-то вроде «Imperius» или «Cruciatus», но «в действительности все не так, как на самом деле».

Начну с определения: «DataOps - автоматизированный, процессно-ориентированный подход, независимый от технологий, используемый аналитическими и дата-командами для улучшения качества и сокращения времени цикла аналитики данных».

«Если этого достаточно для понимания, то дальше можно не читать».

Если же нет, перейдем к описанию вызовов, с которыми ежедневно сталкиваются среднестатистические дата-команды и на которые DataOps был призван ответить.

Вызов первый. «У этой сказки нет конца, ты не изменишь ничего…»

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

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

Вызов второй. «Для никого, только для нас…»

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

Вызов третий. «Накрась ресницы губной помадой, а губы лаком для волос…»

Данные часто содержат ошибки. Придется столкнуться с такими артефактами как: тестовые данные, ошибки ввода, результаты багов и т. д. Кажется, что качество данных в источнике — забота команды источника, но расстроенные некорректными данными пользователи отчетов придут первым делом к дата-команде. Фразы типа «это все источник виноват», не вызовут у них сочувствия, даже не пытайтесь. Скорее наоборот, подобные попытки приведут к потере доверия.

Вызов четвертый. «Тоска без начала, тоска без конца…»

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

Вызов пятый. «Можешь разорвать меня на части…»

Все вышеперечисленное порождает еще одно: дата-команда живет в режиме «тушения пожаров», где каждый «потушенный пожар» порождает несколько новых. Такой вот рекурсивный common table expression без условия для прекращения.

Очевидно, что в подобном случае дата-команда должна состоять из супергероев, «спешащих на помощь» и появляющихся «только свистни». Однако «чудеса на виражах» случаются только в диснеевских мультфильмах. Жизнь же больше напоминает легенду о Данко Максима Горького. И вот уже очередной супергерой «обнаруживает себя уличным художником в Амстердаме».

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

«Давайте все сойдем с ума…»

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

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

«Нам нужно больше людей!» - вторит ему другой, не менее эффективный (в общем-то, многие современные управленческие подходы сводят п.2 к п.1, но моя религия не позволяет относиться к людям как к ресурсам). Подбор ведется бессистемно, часто по принципу «возьмем всех лучших с рынка или кого сможем взять». Встраиванием новичков в команду никто не занимается, так как все заняты “тушением пожаров”. Часто даже задачи поставить некому. В результате получается, что часть сотрудников сильно перегружена, часть страдает от безделья.

«Вольно, самое крутое впереди…»

А теперь переходим непосредственно к реализации DataOps. Суть сводится к семи простым шагам, которые, как мне кажется, даже в комментариях не нуждаются, тем более, что до таланта Василия Уткина мне далеко.

Проверяйте качество данных на каждом шаге потока данных.
Используйте системы контроля версий
Всю разработку ведите в отдельных ветках системы контроля версий и сливайте в основную после ревью, тестов и т. д.
Используйте различные среды для разработки, тестирования и всего остального.
Для каждого шага потока данных создавайте типизированные решения, которые могут быть затем переиспользованы в похожих случаях. Используйте контейнеры. Код, помещенный в контейнер проще переносить между различными средами, кроме того, нет необходимости разбираться с набором инструментов внутри контейнера, достаточно научиться работать с контейнерами.
Параметризируйте свой поток данных, чтобы была возможность запускать поток в различных средах, для различных источников данных, наборов данных и т.д.
Никогда не останавливайтесь, даже если ваш поток данных идеален, постоянно смотрите вокруг себя, вдруг на горизонте возникнет что-то новое. Но не спешите падать в «омут прогрессивных технологий на свою беду» подобно лирическому герою суперхита Сергея Жукова. Сочетайте оба подхода: текущий и тот, который вероятно в недалеком будущем займет его место.

«Я оптимист, я оптимист…»

Самое время подвести итоги.

DataOps является очень важным инструментом в управлении данными и должен внедряться на самых ранних стадиях проекта. «Правильные вещи нужно делать как можно раньше».
На мой взгляд, DataOps — это не отдельная профессия, а еще один инструмент в арсенале инженера данных.
Понимание DataOps — очень важно для начинающих инженеров. Тут как с плаванием - переучивать, говорят, гораздо сложнее, чем учиться с нуля. А значит, возникает необходимость изучения систем контроля версий и контейнеризации (Git и Docker) на самом старте карьеры.
Ограничение DataOps заключается в том, что это односторонний подход, основанный на минимизации рисков, направленный только на одного участника жизненного цикла данных — дата-команду. DataOps позволяет ей спать относительно спокойно, зная, что в зоне ее ответственности все под контролем, но не спасает от очень плохих данных в источниках и неадекватных потребителей. Здесь нужно «кое-что абсолютно другое».

Такая вот получается «с’est la vie», - как пел товарищ Lake (не Data) из известного британского вокально-инструментального трио на моем любимом их альбоме.