Айзек Саколик

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

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

Бизнесу приходится иметь дело с множеством самых разных хранилищ данных: многочисленными корпоративными базами данных, небольшими информационными складами, ЦОДами, облаками, приложениями, инструментами бизнес-анализа, API, электронными таблицами и открытыми источниками данных.

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

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

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

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

Единый достоверный источник сведений об информационных активах организации

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

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

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

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

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

Продукты и сервисы каталогов данных

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

Приведем примеры продуктов для ведения каталогов данных.

• Azure Data Catalog и AWS Glue – сервисы каталогизации данных, встроенные в платформы публичного облака.
• Функции каталога данных поддерживают многие платформы для интеграции данных, в том числе Informatica Enterprise Data Catalog, Talend Data Catalog, SAP Data Hub и IBM Infosphere Information Governance Catalog.
• Некоторые каталоги данных предназначены для платформ больших данных и гибридных облаков. К ним относятся, в частности, Cloudera Data Platform и InfoWorks DataFoundry, поддерживающие операции с данными и их настройку.
• Существуют автономные платформы с функциями машинного обучения: Unifi Data Catalog, Alation Data Catalog, Collibra Catalog, Waterline Data и IBM Watson Knowledge Catalog.
• Инструменты для управления основными данными (например, Stibo Systems и Reltio), а также платформы клиентских данных (Arm Treasure Data) также могут использоваться в качестве каталогов данных.

Машинное обучение для лучшего понимания данных

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

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

Collibra использует машинное обучение, чтобы помочь администраторам классифицировать данные. Компонент Automatic Data Classification анализирует новые наборы данных и сопоставляет их с 40 уже имеющимися классификаторами – адресов, финансовой информации и идентификаторов продуктов.

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

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

Корпоративная система обработки и настройки данных InfoWorks Data Foundry непосредственно интегрирована с алгоритмами машинного обучения. Интерфейс визуального программирования, требующий написания минимального объема программного кода, позволяет конечным пользователям объединить данные с алгоритмами машинного обучения: кластеризацией k-means и классификацией по алгоритму случайных лесов.

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

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

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

Какие проблемы данных и архитектуры требуют внимания

Полезным будет разделить стандарты в области данных и архитектуры на две категории.

1. Стандарты архитектуры, например, модели данных, конвейеры данных, базовые технологии микросервисной архитектуры, стандартные конвейеры непрерывной интеграции и доставки программных решений (continuous integration/continuous delivery, CI/CD), проверки концепций для новых технологий. Внедрение таких стандартов требует подготовительной работы.
2. Стандарты для практик, в том числе соглашения об именовании, требования к тестированию, стандарты интерфейсов микросервисов и шаблоны удобства использования (usability) — все это будет служить для участников группы руководством при реализации функций и устранении технического долга. Кроме того, в данную категорию можно включить стандарты процессов, определяющие принципы расширения моделей данных, проверки усовершенствований конвейера CI/CD, составления документации по новым конечным точкам микросервисов и т. д.

Когда стандарт требует инженерной работы, ее лучше оформить в качестве ситуаций (epic), функций и историй (story) в журнале пожеланий и назначить соответствующей группе. Для этой группы другие команды разработки становятся клиентами, соответственно, она должна сформулировать условия приемки своей работы. Владельцем продукта при этом может быть архитектор данных, приложения или решения. Его задача — выпустить компонент, которым легко смогут воспользоваться agile-команды и который будет полезен бизнесу.

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

Agile-разработка требует систематического планирования

Многие agile-группы проводят совещания по планированию в начале каждого спринта. В ходе таких совещаний обсуждаются и выбираются для реализации пользовательские истории.

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

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

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

Разработка эталонных архитектур и моделей данных

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

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

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

— концептуальная модель данных, изображающая бизнес-объекты, связи и основные транзакции;

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

— модель интеграции данных, на которой показаны источники данных, операции преобразования и базы данных;

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

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

Составьте согласованные со стандартами условия приемки нового кода

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

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

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

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

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

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

Крупные организации с многочисленными командами исследователей инвестируют в платформы исследования данных (Alteryx Analytics, Databricks и Dataiku), представляющие собой набор инструментов для разработки, тестирования и развертывания аналитических моделей. Эти инструменты конкурируют друг с другом с точки зрения операций с данными, аналитических возможностей, средств интеграции, управления, инструментов для бизнес-пользователей и функций развертывания.

Отличия потребностей в DevOps у исследователей данных и разработчиков приложений

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

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

Работа в области науки о данных требует проведения дополнительных экспериментов с наборами данных, моделями и конфигурациями. Циклом планирования, сборки, тестирования и развертывания, характерным для разработки программного обеспечения, дело здесь, как правило, не ограничивается.

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

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

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

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

Поддержка исследователей данных требует понимания имеющихся отличий. Только после этого можно переходить к внедрению практик DevOps. Начать же следует вот с чего.

Формирование у исследователей данных необходимого опыта

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

Начать имеет смысл с инфраструктуры для исследователей данных. На каких языках они пишут программный код: на Python, R или чем-то еще? Какие инструменты (Jupyter, Tableau, Apache Kafka или NLTK) используются для анализа и моделирования? Какие базы данных и облака выступают в роли источников данных и служат для хранения данных, используемых в обучении, и для развертывания моделей?

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

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

Следует учитывать, что в некоторых сервисах SaaS и платформах корпоративных данных нет встроенной системы контроля версий и отсутствуют интерфейсы со средствами управления версиями, применяемыми при написании программного кода. У многих из этих платформ имеются API для проведения интеграции и развертывания или какие-то другие средства, позволяющие имитировать процесс непрерывной интеграции и развертывания (CI/CD).

Формирование конвейеров развертывания и настройка инфраструктуры

При стандартизации среды развертывания и непрерывной интеграции DevOps-консультантам следует обратить внимание и на другие аспекты тестирования автоматизации и построения производственных сред. Это можно сделать путем внедрения конвейеров развертывания с инструментами наподобие Jenkins и настройки инфраструктуры с использованием Chef, Puppet, Ansible или каких-то других инструментов.

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

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

Союз разработчиков, ИТ-администраторов и исследователей данных

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

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

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