DataOps: данные в стиле Agile

Впервые термин DataOps (от Data Operations) прозвучал в 2015 году в блоге Энди Палмера, сооснователя компании Tamr, примечательной тем, что другим ее сооснователем был Майкл Стоунбрейкер. В марте 2017 года на конференции Strata+Hadoop World, организуемой O'Reilly, о DataOps заговорили снова, а затем термин был зафиксирован в книге [1], авторы которой четыре года проработали в команде Facebook Data Service Team над проектом Apache Hive. Движение SQL для Hadoop, начатое Hive, было главным образом нацелено на предоставление аналитикам удобных средств демократизации больших данных. Несмотря на то что на рынке уже имеется пул инструментов обработки больших данных, Hadoop был и до сих пор остается трудным даже для инженеров по данным, не говоря уже о бизнесе, который не желает тратить время на его освоение, а в результате в цепочке «потоки гетерогенных данных — инженеры по данным — конечные пользователи» образуется «бутылочное горло». Однако одного только средства доступа к данным еще недостаточно для устранения узкого места — требуется обеспечить сбор и подготовку данных, управлять эксплуатацией и своевременно реагировать на рост и падение нагрузок и объемов. В конце концов, нужно снабжать аналитиков «свежими» данными, а разработчиков — «живыми задачами», в короткие сроки приводящими к ощутимым для бизнеса результатам.

В отличие от многих модных терминов, расшифровывать «DataOps» не приходится — тем, кто впервые его услышал, понятно, что речь идет об интеграции аналитики, разработки и эксплуатации в условиях больших данных, или «DevOps для Big Data» (хотя нюансы в интерпретации деталей неизбежны). Компаниям, бизнес которых строится на больших данных, приходится чуть ли не ежедневно вводить в эксплуатацию новые сервисы на основе данных. Подобные практики вполне естественны и применялись еще до того, как этот акроним появился в эфире. Однако в числе первых состояние «нирваны» при общении с данными благодаря DataOps прочувствовали eBay, Twitter, Netflix, LinkedIn и Uber, которые на примере Facebook увидели, что данные — это власть, если уметь работать с ними, опираясь не только на технологии, а меняя всю культуру, как это и предусматривает концепция DataOps. В связи с этим даже удивительно, что термин появился относительно поздно. Лишь в конце 2017 года он прочно вошел в лексикон специалистов по данным, а аналитики Gartner «узаконили» понятие в своем ИТ-глоссарии, заключив: «DataOps — центр сбора и распространения данных с мандатом на контролируемый доступ к детальным корпоративным данным при обеспечении их конфиденциальности, ограничений на использование и соблюдения их целостности».

С принятием концепции и пониманием ее полезности проблем не было, но, как и с DevOps [2], история повторилась. Команды по данным столкнулись с теми же сложностями, что и разработчики приложений, с той лишь разницей, что вместо стены между программистом и бизнесом обнаружилась стена между исследователями данных (data scientists), создающими аналитические модели для извлечения полезных сведений из больших массивов данных, бизнес-аналитиками и лицами, принимающими решения. Если в случае с DevOps во власти ИТ оставались приложения, то для DataOps это уже относится к данным. Но дело в том, что независимо от «умности» и квалификации исследователей данных они ничем не смогут помочь бизнесу, если не добудут нужные данные и вовремя не передадут результаты их обработки лицам, принимающим решение. Не стоит забывать, что данные нестатичны и одних технологий их обработки недостаточно — от всей организации требуются маневренность и воля к изменению согласованности поступлений потоков данных, позволяющей исключить «застой воды» в озере корпоративных данных.

Рис. 1. Информационный круговорот на предприятии, управляемом данными

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

Рис. 2. Непрерывная аналитика

Успех DevOps — это интеграция подразделений разработки и операционной деятельности, в условиях традиционных ИТ функционировавших отдельно. Согласно канонам DevOps, развертывание и эксплуатация продукта проходят быстро: объединенные команды оперативно локализуют и исправляют проблемы по мере их обнаружения. DataOps заимствует эту идею, применяя ее на всем протяжении жизненного цикла данных: непрерывная интеграция, доставка и обработка применяются в деятельности исследователей данных, команды которых используют средства управления версиями, такие как GitHub, для отслеживания и изменения кода и технологии типа Docker и Kubernetes для создания сред анализа и развертывания моделей. Иногда такой стиль работы называют непрерывной аналитикой (рис. 2). Например, в Facebook образована централизованная команда по данным, а в каждой продуктовой команде имеется аналитик — все они на центральном форуме обмениваются своими идеями, что позволяет знаниям перетекать по всей компании (рис. 3).

Рис. 3. Команда по данным в структуре компании

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

В общем случае в команду работы с данными должны входить:

• аналитик данных (Data Analyst) — специалист по данным, работающий в каждом линейном бизнес- или операционном подразделении компании;
• инженер данных (Data Engineer) — специалист, отвечающий за поставку данных в платформу, из которой их черпают исследователи данных и аналитики;
• исследователь данных (Data Scientist) — специалист по статистике и машинному обучению, предлагающий модели для изучения данных в соответствии с целями бизнеса;
• директор по данным (Chief Data Officer) — человек, контролирующий работу команды по данным, непосредственно подчиняющийся генеральному или техническому директору компании.

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

Рис. 4. Навыки исследователя данных: сверхчеловек, «универсальный солдат»

Вслед за диаграммами Венна, на которых DevOps-инженер изображался как человек, объединяющий в себе навыки программиста, системного администратора и тестировщика, и внешне похожей на них известной трехлепестковой диаграммой Дрю Конвея, с появлением DataOps возникло аналогичное представление об исследователе данных как о неком «сверхчеловеке» (рис. 4).

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

На пути к компании, управляемой данными

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

Любая организация, планирующая стать компанией, управляемой данными, должна:

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

Рис. 5. Конвейер данных

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

Конвейер данных DataOps

Если представить цифровое предприятие в виде конвейера (рис. 5), то DataOps — это сбалансированный план обеспечения всех его операций необходимыми комплектующими и инструментами, исключающий как остановку конвейера, так и затоваривание «склада готовой продукции». Поставщиками «комплектующих» в виде данных для такого конвейера могут быть различные «смежники», предлагающие либо собственно данные, либо сервисы их обработки. Такие компании, как Informatica, Teradata, SAP и Microsoft, предлагают функционально полный стек решений, платформы или сервисы по доставке данных для корпоративного конвейера. Однако, несмотря на слова отдельных поставщиков о достижении гегемонии данных, в действительности большинство крупных предприятий имеют дело с сильно раздробленными средами работы с данными, а это означает риски неоднородности и недостоверности данных и, как следствие, риск принятия несбалансированных управленческих решений.

Поставщики поменьше не стремятся заполонить собой весь конвейер, а стараются предложить лучшие технологические решения, сфокусированные на отдельных операциях, в частности: Trifacta — подготовка данных, Tamr — унификация данных, Alation — каталогизация, Tableau — аналитическая визуализация с самообслуживанием. Наблюдается тенденция к объединению решений для поставки на конвейер «крупных узлов» — например, компания Alation анонсировала альянсы с Teradata и Trifacta, а компании Nexla, Composable Analytics, DataKitchen и Switchboard Software объединили свои усилия на бизнесе DataOps as a Service. Строители дистрибутивов Hadoop также отошли от идеологии «все в одном комплекте» и выпустили специализированные инструменты для отдельных участков DataOps: Hortonworks Data Steward Studio — инструмент для работы с политиками доступа к данным, Cloudera Analytics Workbench и Arenadata Analytic Workspace — рабочие места для исследователей данных, объединяющие всевозможные «блокноты», шлюзы к разнообразным источникам и программные ресурсы для обработки данных. Однако платой за составление конвейера из «лучших в своем классе» продуктов становятся дополнительные затраты на интеграцию различных технологий в корпоративную инфраструктуру. Как бы то ни было, инфраструктура для поддержания бесперебойной работы конвейера данных цифрового предприятия должна обеспечивать выполнение операций нескольких категорий.

Оркестровка конвейера данных. Для формирования потоков данных требуется маршрутная карта с описанием всех источников данных, моделей их представления и интеграции, а также шагов процесса анализа. Для этого могут использоваться следующие инструменты: Apache Oozie — планировщик процессов заданий Apache Hadoop; BMC Control-M — решение по автоматизации пакетной обработки; DataKitchen — платформа DataOps поддержки всего цикла аналитической обработки, минимизирующая время на подготовку и доставку данных нужного качества; Reflow — система инкрементальной обработки данных в облаке с помощью произвольных программ, упакованных в контейнеры Docker.

Тестирование и обеспечение качества. В DataOps важно обеспечить автоматическую проверку качества данных, их очистку на всех этапах обработки. Возможные инструменты: ICEDQ — ПО для автоматизации тестирования при работе с хранилищами ETL и миграции данных; Naveego — облачная платформа для построения информационных панелей и витрин с целью мониторинга состояния данных и управления исключениями.

Автоматическое распределение. В DataOps осуществляется непрерывное перемещение кода и конфигураций между этапами разработки приложений, сбора данных, стадиями анализа и извлечения из данных полезных сведений. Типичным инструментом здесь может быть Jenkins, осуществляющий непрерывную доставку ПО с автоматическим контролем всех этапов жизненного цикла приложений от написания кода к сборке, автотестированию и развертыванию в эксплуатационных средах.

Развертывание моделей данных и управление «песочницами». Команды по данным, работающие в соответствии с DataOps, формируют воспроизводимые во всех подразделениях компании операционные среды. Инструменты: Domino — ускорение процессов разработки приложений работы с данными, доставка моделей, бесшовная интеграция; Open Data Group — программное решение по развертыванию систем аналитики на основе моделей; DSFlow — ускорение процессов извлечения данных для бизнеса.

Виртуализация данных и управление тестовыми данными. Инструменты: Delphix — платформа виртуализации, защиты и управления данными; Redgate — SQL-инструменты, помогающие внедрять DataOps, управлять производительностью баз и подключать новые базы.

Интеграция и унификация данных. Tamr — унифицированное решение для работы с корпоративными базами данных с привлечением методов машинного обучения; Switchboard Software — аутсорсинг и интеграция данных.

Управление производительностью и облачные платформы. Инструменты: SelectStar — мониторинг баз данных; Unravel — управление производительностью и работой с приложениями и платформами больших данных; MapR — конвергентная платформа работы с большими данными, объединяющая средства аналитики реального времени и операционные бизнес-приложения; Quobole — облачный сервис класса Вig Data as a Service для работы с разнородными структурированными и неструктурированными данными.

***

Главная задача программной инженерии — предоставить работающее ПО, а задача инженерии данных — предоставить предприятию работающие данные. Все остальное — вторично. Действительно, традиционная команда аналитиков данных работает медленно, затрачивая много усилий на обеспечение качества данных, а команда по данным, работающая согласно идеям DataOps, быстро производит новую аналитику, гибко реагируя на требования рынка. При этом сохраняется приемлемое качество данных, поставляемых из «свежего» озера, принадлежащего всему бизнесу, а не ИТ, специалистам по данным или аналитикам. Очень важно, чтобы все сотрудники цифрового предприятия были вооружены инструментами самообслуживания, позволяющими из единого источника получать все необходимые в рамках их компетенции данные, создавать собственные отчеты, визуализации и делиться своими открытиями с коллегами.

Литература

1. Ashish Thusoo, Joydeep Sen Sarma. Creating a Data-Driven Enterprise with DataOps. O'Reilly, 2017. ISBN 978–1–491–97783–5
2. Андрей Косыгин. Agile и DevOps на службе крупного бизнеса // Открытые системы.СУБД. — 2016. — № 2. — С. 28–29. URL: www.osp.ru/os/2016/02/13049287 (дата обращения: 18.05.2018).

Дмитрий Волков (vlk@keldysh.ru) — сотрудник, ИПМ им. М. В. Келдыша РАН, Андрей Николаенко (ANikolaenko@Ibs.ru) — архитектор, компания IBS (Москва).