Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Потребность эффективно хранить большие объемы данных и обращаться к ним стала одной из ключевых потребностей любого бизнеса. Сетка данных (data mesh) — это новый способ децентрализовать управление данными, радикально повышая их безопасность и доступность. Хорошо спроектированная сетка данных позволяет потреблять данные в режиме самообслуживания и помогает избавляться от узких мест, которые свойственны монолитным архитектурам данных. Пора разобраться с тем как на практике децентрализовать данные и организовать их в эффективную сетку. Сперва вы создадите простейший жизнеспособный продукт данных, а потом, продвигаясь от главы к главе, преобразуете его в самообслуживаемую платформу данных. Вам наверняка понравятся предложенные в книге «ползунки», с помощью которых можно будет настроить сетку под ваши потребности. Книга предназначена для профессионалов в области данных и не привязана к конкретным программным стекам или платформам данных.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 433
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Переводчик Н. Григорьева
Яцек Майхжак, Свен Балноян, Мариан Сивяк
Data mesh в действии. — СПб.: Питер, 2024.
ISBN 978-5-4461-2122-9
© ООО Издательство "Питер", 2024
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Оглавление
Предисловие
Сетка данных (data mesh) играет такую же роль для данных, как Agile-технологии для разработки программного обеспечения или как микросервисы для архитектурных шаблонов. Она станет важнейшим компонентом вашей будущей стратегии работы с данными. В книге «Data mesh в действии» рассматривается как техническое устройство сетки данных, так и методология, с помощью которой ее можно внедрить в вашей организации.
Эта книга переносит вас в кресло главного архитектора проекта по реализации сетки данных. Авторы проведут вас через весьма непредсказуемый процесс создания вашего первого продукта данных. По мере того как вы будете осваивать все новые и новые компоненты, ваша сетка будет выстраиваться сама собой, и коллективный опыт авторов поможет этому. Вам останется только выбрать подходящие составляющие и адаптировать эту структуру к своим нуждам и своей организации.
Сетка данных основана на четырех принципах: владение доменом, данные как продукт, федеративное вычислительное управление и самообслуживаемая платформа данных. В книге обстоятельно описывается, как эти принципы влияют на организацию и как реализовать их технически. По отдельности все они хорошо известны инженерам и архитекторам; настоящее эволюционное (или революционное?) значение сетки данных заключается в том, что она способна объединить эти принципы и обеспечить глобальный подход к построению современных платформ данных.
За более чем 15-летний опыт создания гибридных платформ данных мне всегда чего-то не хватало. Будь то строгий подход к загрузке данных в хранилище или отсутствие управления в озере данных — это две наиболее популярные модели, — все время казалось, что «это не сработает». Сетка данных — совсем другое дело. Она не фокусируется исключительно на технологиях, а ставит во главу угла управление и качество и дает контроль реальному владельцу данных, а не какой-то центральной группе, которая отдает приказы и предъявляет требования. В результате, если обеспечить надлежащие инструменты самообслуживания, сетка данных высвободит силы для инноваций в вашей организации. И именно в этом вам поможет книга «Data mesh в действии».
Жан-Жорж Перрен (Jean-Georges Perrin), руководитель направления интеллектуальных платформ в PayPal, президент и соучредитель AIDAUG, пожизненный обладатель звания «IBM Champion»
Введение
Каждый из нас, авторов, в разное время и в разных компаниях сталкивался со старым способом так называемой работы с данными, при котором обычно создавались централизованные озера и хранилища данных и выделялись центральные рабочие команды в рамках аналитических подразделений. В основном этот старый способ выглядел так:
1. У нескольких децентрализованных команд разработчиков есть данные, которые доступны через такие системы хранения, как общий диск, децентрализованная база данных, REST API или любой другой интерфейс.
2. Перед одной или несколькими централизованными рабочими группами ставится задача собрать эти данные в единый монолитный банк — либо озеро, либо хранилище данных.
3. Этим же командам поручается преобразовывать эти данные в нечто полезное.
4. Многочисленные децентрализованные команды по аналитике, разработке или машинному обучению черпают эти преобразованные данные и извлекают из них ценность в виде отчетов, систем рекомендаций или еще чего угодно, что может прийти в голову.
Мы на собственном горьком опыте убедились, что у этой концепции есть ограничения, из-за которых возникают узкие места как с точки зрения технологии, так и с точки зрения возможностей команд. Мы не раз наблюдали, как компаниям было трудно наладить эффективную конверсию данных в ценность, пока на горизонте не появилась сетка данных и идеи, на которые она опирается.
Сетка данных (data mesh) — это парадигма децентрализации. Она децентрализует владение данными, их преобразование в информацию и их обслуживание. Она предназначена для того, чтобы эффективнее извлекать ценность из данных, устраняя узкие места этой процедуры.
Понятие сетки данных появилось в 2019 году и с тех пор буквально произвело фурор не только в индустрии работы с данными, но и во всем мире технологий. Сетка отвергает традиционное представление, при котором данные рассматриваются как побочный продукт программных компонентов. Новый подход фокусируется на производителях данных и возлагает на них ответственность за то, чтобы обращаться с данными так же, как они обращались бы со своим программным обеспечением.
При этом сетка данных проходит тот же путь, что и программные компоненты: она использует микросервисную архитектуру и методы DevOps. Это тот же путь, по которому сейчас идут фронтенды, задействуя микрофронтенды. И так же как и в этих примерах, мы считаем, что сетка данных — это правильный подход для того, чтобы наконец-то обрести гибкость, которая позволит масштабировать извлечение ценности из наших данных в бизнес-аналитике, машинном обучении или любых других отраслях, которые приходят на ум.
Часто говорят, что понятие сетки данных меняет социотехническую парадигму: суть предмета заключается не в технологиях, а в том, чтобы согласовать деятельность людей, процессы и организационные структуры. Сложности, которые при этом возникают, и послужили поводом написать эту книгу. Однако мы не просто излагаем накопленные теоретические знания, а сосредоточиваемся на тех аспектах сетки данных, которые, по нашему опыту, критически важны, чтобы успешно ее внедрить. Мы объединили этот материал в удобное руководство, которое поможет вам опробовать сетку данных в действии.
Чтобы это лучше вам удалось, мы подготовили практические примеры с большим количеством набросков архитектуры из различных областей: IT, методы проведения семинаров, формы организации команд и т.д. Прочитав эту книгу, вы овладеете такими умениями:
• оценивать, соответствует ли сетка данных бизнес-потребностям вашей организации;
• подготавливать основу для разработки сетки данных;
• разрабатывать минимальную сетку данных на начальном этапе;
• итеративно развивать и расширять сетку данных.
Вы не встретите в этой книге много кода, за исключением небольшого количества сценариев на JSON. Это потому, что мы искренне верим: основа успеха — не в технологиях, а в людях, процессах и организации. Но конечно же, здесь вы найдете немало технической информации в виде подробных набросков архитектуры, которые относятся к разным технологиям и облачным провайдерам, а также пояснений и схем, которые опираются на многочисленные примеры из реальной жизни.
Как бы то ни было, мы не верим, будто идею сетки данных можно воплотить «единственно правильным» образом. Наша книга поможет вам адаптировать эту идею к реалиям вашей компании, предлагая множество степеней свободы, готовых рецептов и толику здорового прагматизма.
Чтобы сформировать целостный опыт, мы будем рассматривать воображаемую компанию «Messflix», которая проявляет многие качества, характерные для реальной индустрии данных. Внедрение сетки данных будет обсуждаться в основном на примере этой компании. Впрочем, поскольку мы уделяем много внимания тому, как адаптировать сетку данных к компаниям разных типов, в книге встретятся и другие примеры. Ниже в этой вступительной части мы кратко познакомим вас с компанией «Messflix» и с тем, какой беспорядок с данными в ней царит.
Благодарности
Прежде всего, мы хотели бы выразить благодарность сообществу профессионалов, которые разрабатывают сетки данных. Их готовность открыто обсуждать насущные проблемы и затруднения помогла нам расширить свои представления и облечь наш личный опыт в обобщенную структуру, которую вы найдете в этой книге.
Мы глубоко признательны замечательным людям из издательства Manning, благодаря которым эта книга увидела свет: издателю Марьяну Баце (Marjan Bace), ведущему редактору Иэну Хафу (Ian Hough) и, наконец, шеф-редактору Эндрю Уолдрону (Andrew Waldron). Если бы не их терпеливое отношение к нашим постоянно меняющимся представлениям о сетке данных и умение заставить нас связать эти представления в целостную картину, мы никогда бы не закончили книгу в том виде, в каком представляем ее вашему вниманию. Мы хотели бы также поблагодарить маркетинговую, редакционную и выпускающую команды, без которых эта книга пылилась бы на полке в издательстве Manning.
Сердечное спасибо Майклу Йенсену (Michael Jensen) и Элу Кринкеру (Al Krinker) за технические рецензии, которые позволили нам лучше очертить и уточнить понятие сетки данных.
Мы также хотели бы поблагодарить всех рецензентов, которые доверились нам и потратили свое время на прочтение книги даже тогда, когда еще никто не был уверен, что она дойдет до публикации. Ален Куньо (Alain Couniot), Арно Кастельторт (Arnaud Castelltort), Арно Эстев (Arnaud Estève), Жан-Жорж Перрен (Jean-Georges Perrin), Хуан Габриэль Гусман Герра (Juan Gabriel Guzmán Guerra), Мэри Энн Тюгесен (Mary Anne Thygesen), доктор Массимо (Massimo dr), Маттиас Буш (Matthias Busch), Майк Фаулер (Mike Fowler), Милан Шаренац (Milan Sarenac), Натан Б. Крокер (Nathan B. Crocker), Прадип Бхаттипролу (Pradeep Bhattiprolu), Рахул Джайн (Rahul Jain), Ричард Вон (Richard Vaughan), Салил Аталье (Salil Athalye), Сампат Чапарала (Sampath Chaparala), Широшика Кулатилаке (Shiroshica Kulatilake), Симон Чёке (Simon Tschöke), Стефано Онгарелло (Stefano Ongarello), Сумих Дамодаран (Sumih Damodaran), Суриянто Бонгсо (Suriyanto Bongso) и И Вэй (Yi Wei) — ваши предложения помогли улучшить эту книгу.
О научном редакторе русского издания
Майнхардт Кирилл Владимирович — эксперт компании КРОК, занимается проектированием, модернизацией и созданием IT-инфраструктур предприятий. Реализует проекты для крупных российских компаний разных отраслей, в том числе консалтинговых, финансовых, нефтегазовых, транспортных, ритейл и др. Имеет опыт локализации подразделений международных компаний в российских центрах обработки данных и облачных платформах. Его деятельность включает аудит и оптимизацию бизнес-процессов компании на основе оптимально подобранных вычислительных и программных решений, позволяющих эффективно использовать, хранить и защищать корпоративные данные.
От издательства
Мы выражаем огромную благодарность компании КРОК за помощь в работе над русскоязычным изданием книги и ее вклад в повышение качества переводной литературы.
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
О книге
Эта книга преследует две цели. Во-первых, в ней систематизированы и представлены знания о новой социотехнической парадигме сетки данных. Во-вторых, она поможет вам внедрить сетку данных. Книга предоставляет все необходимые инструменты для того, чтобы стать вашим наставником на пути внедрения: вы узнаете, как определить, подходит ли сетка данных для вашей организации, заложить ее основы, разработать минимальный жизнеспособный продукт (MVP) и реализовать принципы сетки данных.
Для кого эта книга
В самом общем виде наши читатели — это те, кто извлекает ценность из данных. Однако, поскольку в современной экономике это относится практически ко всем, мы уточним, какую пользу книга принесет различным целевым группам.
Первая группа — это специалисты, которые участвуют в создании и использовании данных, а также в управлении данными в компаниях, где доминируют такие факторы:
• высокая социотехническая сложность (например, крупные корпорации);
• сложные сценарии использования данных;
• многочисленные и разнообразные источники данных.
К таким специалистам относятся, в частности, архитекторы и инженеры данных, архитекторы программного обеспечения, технические руководители и ведущие разработчики.
Чем больше эти факторы применимы к вашему бизнесу, тем вероятнее, что вам может пригодиться сетка данных. Книга поможет вам разобраться в принципах сетки данных, в том числе понять, с кем нужно наладить сотрудничество и какие шаги следует предпринять как с организационной, так и с технической стороны, чтобы перейти от беспорядочных данных к сетке.
Кроме того, поскольку внедрение сетки данных — это процесс трансформации в масштабах всей компании, содержание книги будет полезно руководителям высшего звена, включая технических директоров и менеджеров, корпоративных архитекторов, главных и ведущих архитекторов, а также владельцев решений и программ. Эта книга поможет решить, в какой степени и с какой приоритетностью следует переводить среду данных компании в русло сетки данных, а также пригодится для того, чтобы спланировать управление изменениями.
Структура книги
Хотя книга предназначена для того, чтобы читать ее последовательно, она разбита на три основные части и позволяет пропускать разделы. Первая часть представляет собой быстрое практическое введение, вторая подробно объясняет четыре принципа сетки данных, а третья детально рассматривает техническую сторону вопроса и описывает весь процесс внедрения сетки данных на предприятии.
Часть 1. Введение
Цель первой части книги — как можно быстрее познакомить вас с парадигмой сетки данных. Для этого мы сначала рассмотрим основы сетки, а затем на практике в течение месяца создадим свою первую сетку данных.
Глава 1. Что такое сетка данных и зачем она нужна
В этой главе дается обзор понятий, которые необходимы, чтобы осмыслить остальную часть книги в правильном контексте: в частности, здесь рассказывается, почему вам стоит задуматься о переходе к сетке данных, а также кратко разъясняются четыре ключевых принципа, которые подробно рассмотрены в части 2.
Глава 2. Подходит ли вам сетка данных?
В этой главе вы узнаете о специфике внедрения сетки данных и о том, какие факторы влияют на решение об этом внедрении. Этот материал поможет вам понять, стоит ли начинать такие преобразования прямо сейчас, а также определить свое место на шкале зрелости данных. Благодаря этому вам будет проще приспособить процесс реализации сетки данных к вашей конкретной ситуации.
Глава 3. Как запустить минимально жизнеспособный продукт сетки данных в течение месяца
Эта глава дает практический пример создания минимально жизнеспособного продукта (MVP). Для компании «Messflix» он в значительной степени сосредоточен на организационных проблемах и мало затрагивает технологическую сторону вопроса, что обычно характерно для MVP. Технические подробности мы рассмотрим позже. В этой главе представлены такие инструменты, как анализ заинтересованных сторон и принципы FAIR (findability, accessibility, interoperability, reusability — находимость, доступность, совместимость, переиспользование), которые помогут вам начать работу.
Часть 2. Четыре принципа на практике
Цель второй части книги — предоставить инструменты, с помощью которых вы сможете воплотить четыре принципа сетки данных, чтобы развивать ее после первого месяца.
Глава 4. Владение доменами
Эта глава посвящена доменам и возможностям бизнеса, а также тому, как определить подходящих владельцев данных внутри компании. Здесь вы найдете множество методик проведения семинаров, включая доменный сторителлинг.
Глава 5. Данные как продукт
К данным часто относятся как к побочному продукту. Эта глава посвящена тому, как переключиться на продуктовое мышление и освоить принцип «данные как продукт». В главе приведены примеры продуктов данных компании «Messflix» и подробно объясняются такие понятия, как канва продукта данных и порты данных.
Глава 6. Федеративное вычислительное управление
В этой главе рассматривается управление данными в контексте сетки данных. Внутри сеток такое управление называется федеративным вычислительным управлением, потому что в нем достигается баланс централизованного и распределенного управления, а ряд операций выполняется автоматически, что позволяет полнее раскрыть возможности сетки данных. Здесь сопоставляются централизованные и децентрализованные аспекты, приводятся практические примеры для «Messflix», а также дается практическое руководство по тому, как создать команду управления.
Глава 7. Самообслуживаемая платформа данных
В последней главе, посвященной принципам сетки данных, рассматривается платформа — технология, которая обеспечивает работу сетки. Здесь описаны три итерации нашей платформы данных для «Messflix», а наряду с этими примерами объясняются такие важные понятия, как платформенное мышление.
Часть 3. Инфраструктура и системная архитектура
Третья часть посвящена техническим вопросам. В ней мы отвлечемся от примера «Messflix», чтобы рассмотреть различные архитектуры, а также обсудить несколько вариантов перехода от вашей существующей структуры к сетке данных.
Глава 8. Сравнение самообслуживаемых платформ данных
В этой главе описываются схемы платформ для сеток данных, которые подходят для различных облачных провайдеров, а также для компаний разного размера.
Глава 9. Разработка архитектуры решения
В этой главе мы сосредоточимся на переходе от существующей системы к различным видам архитектур, продвигаясь шаг за шагом и компонент за компонентом. Мы поговорим об озерах данных, хранилищах данных, REST API и многом другом.
Как пользоваться этой книгой
Наша цель не в том, чтобы представить очередную теорию сетки данных. Эта книга — скорее структурированный, коллективный регламент действий, которые приводят к разработке сетки данных в различных средах. Ключевые слова здесь — «действия, которые приводят». Мы пришли к сетке данных после долгих и зачастую болезненных экспериментов со многими другими решениями. На протяжении многих лет мы тестировали, исследовали, обсуждали и, что не менее важно, часто терпели неудачи в этих начинаниях. В этой книге мы делимся краткой сводкой идей типа «Жаль, что мы не знали этого раньше». Мы надеемся, что вы сможете сразу же применить полученную информацию в действии.
В зависимости от того, какую цель вы преследуете, при чтении книги можно сосредоточиться на тех или иных основных моментах. Если ваш интерес чисто информационный, а ваша цель — уметь объяснить понятия сетки данных своей команде, руководству или целой компании, то мы рекомендуем уделить больше внимания главам 1 и 2, в которых дается краткий обзор, а также описанию MVP из главы 4. Кроме того, если вы прочтете главу 9, чтобы глубже понять причины смены парадигмы, и поверхностно ознакомитесь с частью 2, вы будете хорошо подготовлены к тому, чтобы объяснять принципы сетки данных другим людям.
Если же вы хотите запустить более масштабную инициативу в своей компании, то вам понадобится быть убедительными. В этом случае мы рекомендуем глубоко погрузиться в главу 9 и обратить пристальное внимание на главу 3, где рассматривается вопрос о том, стоит ли вообще начинать эту активность. Глава 4, в которой представлена полномасштабная разработка MVP сетки данных, и глава 2, где обзорно рассматривается упрощенное применение принципов сетки, позволят вам составить сбалансированную общую картину с учетом того, что требуется быстро внедрить продукт и быстро получить результаты. В итоге у вас будет достаточно убедительного материала, чтобы заручиться поддержкой высшего руководства.
Если вас интересует техническая сторона вопроса, например автоматизированное управление и самообслуживаемая платформа, то в главах 5–8 вы найдете много интересной информации.
Если вы входите в команду разработчиков, мы особенно рекомендуем обратить внимание на главу 4. В ней подробно объясняется, в чем конкретно состоят проблемы с текущим образом мышления, и этот материал поможет вам усовершенствовать свои методы работы, даже не касаясь понятия сетки данных. Кроме того, мы рекомендуем изучить главу 8, потому что в ней описываются возможные альтернативные варианты архитектуры обслуживания данных с точки зрения разработчиков.
Если вы хотите усовершенствовать методы работы внутри вашей команды по работе с данными, можно сосредоточиться на главах 3 и 4, чтобы глубже понять источник текущих проблем. Также стоит уделить внимание главе 6, чтобы понять, что такое платформенное мышление в контексте данных. Эти фрагменты книги способны помочь вам усовершенствовать свои методы работы, даже не внедряя внутри компании полноценную сетку данных.
Мы уверены, что существует еще множество причин открыть эту книгу; здесь мы представили лишь несколько возможных вариантов того, как из нее можно извлечь пользу.
Пример: компания «Messflix»
Чтобы помочь вам разобраться, как сетка данных работает на практике, мы обобщили наш опыт и собрали его в единый пример компании «Messflix».
«Messflix», платформа для потоковой трансляции фильмов и телепередач, столкнулась с непреодолимой преградой. Эта преграда — данные. У компании есть все данные мира, но оказывается, что при этом ей даже не удается создать нормальную систему рекомендаций для своих фильмов и шоу. А тем временем конкуренты, похоже, справляются с этой задачей; фактически они известны именно тем, что являются первопроходцами во многих технологических областях.
Создается впечатление, что и другие компании, которые функционируют в не менее сложных отраслях, тоже заставляют свои данные работать. Казалось бы, и «Messflix» работает с данными, а аналитики извлекают из них определенную информацию, но у руководителей нет ощущения, что компанию можно в полной мере назвать ориентированной на данные.
Экспериментальные проекты в области data science, похоже, заканчиваются тем, что создаются «красивые прототипы» без явной ценности для бизнеса. Специалисты по data science говорят своим руководителям, что это происходит потому, что «команда разработки продукта данных просто не хочет развивать эти замечательные прототипы», или, например, «потому, что данные из источника слишком беспорядочны и противоречивы».
Одним словом, «Messflix» похож на типичную компанию, которой по каким-то причинам не удается направить подходящий поток данных к правильным сценариям использования. Индустрия данных, как и сфера технологий, органично развивалась с течением времени и стала довольно сложной.
Два ключевых технических компонента системы «Messflix» — это стриминговая платформа Messflix и «Hitchcock Movie Maker» (киностудия Хичкока). Стриминговая платформа позволяет подписчикам смотреть фильмы и шоу. «Hitchcock Movie Maker» — это набор инструментов, который помогает создателям фильмов выбирать хорошие темы, сюжеты и контент.
Кроме того, у «Messflix» есть озеро данных, а на его базе работает аналитическая платформа, которая принимает данные отовсюду. Этими компонентами управляют несколько команд. Оранжевая и Белая команды совместно координируют несколько инструментов «Hitchcock Movie Maker». Зеленая команда занимается подписками, процедурой входа в систему и т.д., а Желтая команда отвечает за показ фильмов в рамках стриминговой платформы. На рис. 1 мы представили примерную архитектуру некоторых из этих компонентов, а затем обсудим, как «Messflix» сейчас работает с данными.
Данные, которыми занимается команда по работе с данными, поступают в хранилище из нескольких различных мест, например, отчеты о затратах из «Hitchcock Movie Maker» и подписки из службы подписки. Команда также получает данные о трансляциях и профили подписок из озера данных.
Затем команда по работе с данными перерабатывает данные, чтобы преобразовать их в информацию, на основе которой можно выявлять мошенничество и принимать бизнес-решения.
Наконец, децентрализованные подразделения используют эту информацию для своих бизнес-решений и других целей. В настоящее время этот рабочий процесс централизован, и команда по работе с данными находится в его центре.
Независимо от того, откуда и куда вы хотите прийти, вы обязательно окажетесь где-то на пути, по которому следует «Messflix». Поэтому давайте еще раз взглянем на то, как он устроен.
Данные никогда не следуют по однозначному прямому маршруту. Поэтому и развитие системы «Messflix» не будет похоже на простую линейную последовательность шагов. В последующих главах вы увидите различные подходы и способы адаптировать сетку данных к вашей компании, хотя случай «Messflix» останется «каноническим» примером, на который можно ориентироваться.
Вы можете следовать этому примеру на протяжении всех глав со 2-й по 6-ю и главы 9. В табл. 1 дается обзорное представление об этапах развития компании, причем на пути к сетке данных мы выделяем два измерения. Первое из них — это количество затронутых организационных подразделений и команд, а второе — степень децентрализации разных видов ответственности компании.
Рис. 1. Основные компоненты программного обеспечения «Messflix». Команда по работе с данными обрабатывает множество разнообразных источников данных и выполняет разные обязанности
Согласно парадигме сетки данных, суть изменений заключается в том, чтобы децентрализовать ответственность за данные. Однако сегодня ответственность за данные на практике разделяется на несколько видов, каждый из которых нужно децентрализовать. Поэтому в табл. 1 мы выделяем все четыре вида ответственности за данные, каждый из которых соответствует одному из принципов сетки данных, представленных в части 2.
Таблица 1. Трансформация «Messflix»
Глава 4
Глава 5
Глава 6
Глава 7
Глава 8
Затронутые команды
2
(Две команды, которые производят данные) Небольшое количество совместно работающих сотрудников
2+
2+
2+
3–10
(Специальная команда по работе с платформой и большее количество команд по производству и потреблению)
Виды ответственности за данные
Всего понемногу
Истинное владение, для которого потребуетсяузнать реальные домены данных
Ответственность за обслуживание потребителей данных
Ответственность за безопасность, управление и т.д.; иными словами, за потребности всей компании
Ответственность за инфраструктуру и техническую составляющую
Форум liveBook
Приобретая книгу «Data mesh в действии», вы получаете бесплатный доступ к веб-форуму издательства Manning (на английском языке), на котором можно оставлять комментарии о книге, задавать технические вопросы и получать помощь от авторов и других пользователей. Чтобы получить доступ к форуму, откройте страницу https://livebook.manning.com/book/data-mesh-in-action/discussion. Информация о форумах Manning и правилах поведения на них размещена на https://livebook.manning.com/discussion.
В рамках своих обязательств перед читателями издательство Manning предоставляет ресурс для содержательного общения читателей и авторов. Эти обязательства не подразумевают конкретную степень участия автора, которое остается добровольным (и неоплачиваемым). Задавайте авторам хорошие вопросы, чтобы они не потеряли интереса к происходящему! Форум и архивы обсуждений доступны на веб-сайте издательства, пока книга продолжает издаваться.
Об авторах
ЯЦЕК МАЙХЖАК (JACEK MAJCHRZAK) — ведущий архитектор; он реализует проект на основе сетки данных в области разработки лекарственных препаратов. Также Яцек координирует семинары, имея опыт модерирования на основе различных принципов, включая событийный штурм, доменный сторителлинг, моделирование бизнес-возможностей и канву ограниченного контекста. Он также разработал собственную методику (так называемый базар данных), которая помогает обнаружить и определить продукты данных доменно-ориентированным способом. Яцек использует все эти механизмы, чтобы помочь людям принимать наилучшие решения относительно технологий и стратегии. В сферу его компетенции входят доменно-ориентированный дизайн, событийно-ориентированная архитектура, архитектура решений, проектирование социотехнических систем, а также управление и стратегия архитектуры. Он считает, что понимать бизнес-домены и потребности бизнеса критически важно для того, чтобы разрабатывать успешную архитектуру. Он ведет блог на сайте https://jacekmajchrzak.com. Яцек — муж и отец двоих детей, а также мотоциклист, помешанный на спорте, особенно на водном.
СВЕН БАЛНОЯН (DR. SVEN BALNOJAN) — технолог данных и разработчик продуктов; он стремится помочь миру извлечь больше пользы из экспоненциально растущего объема данных. Он увлечен всем, что касается данных, машинного обучения, искусственного интеллекта, бизнес-аналитики и многих других смежных областей. Он управляет внутренними командами по работе с данными и занимается трансформацией команд из сервис-ориентированных в платформенно-ориентированные, а также выступает в качестве разработчика данных в области машинного обучения, инженерии данных и DevOps в сфере данных. Свен — PhD в математике, защитивший диссертацию в области теории сингулярности. Он является автором амбициозного информационного бюллетеня «Three Data Point Thursday» («Четверг по трем точкам данных»). Кроме того, он ведет блог на сайте https://datacisions.com и время от времени выступает с докладами в интернете.
МАРИАН СИВЯК (DR. MARIAN SIWIAK) — мастер на все руки во всех сферах работы с данными и специалист по их интеграции с бизнес-операциями. В качестве главного специалиста по data science компании «Cognition Shared Solutions» он выступает как консультант по использованию данных стратегического уровня и разработчик фреймворка «Трехуровневый анализ бизнес-процессов» (Trilayer Business Process Analysis), который объединяет выполнение процессов, среды данных и управление рисками. У него богатый опыт реализации научных, технических и IT-проектов с бюджетом в миллионы долларов в различных сферах — от биологических наук до робототехники. Он читал лекции по управлению данными в разных бизнес-университетах. Его команда первой опубликовала модель глобального распространения вируса COVID-19. Мариан — муж, отец троих детей, увлекается лыжами, ходит под парусом и пишет фантастическую прозу.
Иллюстрация на обложке
Иллюстрация, помещенная на обложку книги и озаглавленная «Homme de Brabant» («Человек из Брабанта», Брабант — провинция на севере Бельгии), взята из вышедшего в 1797 году каталога национальных костюмов Жака Грассе де Сен-Совёра (Jacques Grasset de Saint-Sauveur). Каждая иллюстрация этого каталога тщательно прорисована и раскрашена вручную.
В прежние времена по одежде человека было легко определить, где он живет и чем занимается. Издательство Manning приветствует изобретательность и инициативность — качества, присущие индустрии IT, — и в знак этого размещает на обложках изображения, которые демонстрируют богатое разнообразие народов и культур мира, запечатленное на старинных иллюстрациях.
Часть 1. Введение
Первая часть книги познакомит вас с парадигмой сетки данных. Мы обзорно рассмотрим теорию сетки данных и ее принципы, а также разберемся, какие движущие силы необходимо учитывать, принимая решение о том, чтобы ее внедрить.
Вы сможете оценить, в какой точке на шкале зрелости данных вы находитесь, и осознанно решить, стоит ли вам приступать к трансформации.
Затем мы рассмотрим практический пример того, как в течение месяца создать минимальную сетку данных. Это упражнение сосредоточено на организационных проблемах, а с технической точки зрения следует философии минимально жизнеспособного продукта (MVP).
1. Что такое сетка данных и зачем она нужна
В этой главе
• Даем определение сетки данных
• Знакомимся с ключевыми понятиями, которые относятся к сетке данных
• Разбираемся, почему сетка данных — это смена социотехнической парадигмы
• Перечисляем преимущества сетки данных
• Выявляем возможные проблемы при внедрении сетки данных
Сетка данных — это парадигма децентрализации. В ней децентрализованы владение данными, их преобразование в информацию и обслуживание. Эти меры направлены на то, чтобы извлекать из данных максимальную ценность, устраняя узкие места этой процедуры.
Концепция сетки данных разрушает пространство данных. Крупные и мелкие компании во всех уголках интернета наперегонки пытаются продемонстрировать свои наработки, похожие на сетку данных. Это становится новой тенденцией; ее стремится подхватить каждая организация, которая хочет извлекать больше пользы из своих данных. Эта книга описывает парадигму сетки данных как социотехническую архитектуру с упором на социальнуюсоставляющую. Основное внимание уделяется не технологиям, а людям, процессам и организациям. Сетки данных можно (хотя и не обязательно) реализовывать с помощью тех же технологий, на которых функционирует большинство современных систем работы с данными.
Но поскольку сетка данных остается предметом постоянных дискуссий, а образцовые методики и стандарты развиваются медленно, мы пришли к выводу, что стоит написать обстоятельную книгу, которая охватывает не только ключевые принципы работы сеток данных, но и примеры с разными вариантами того, как адаптировать их к любой компании. Эта книга предназначена именно для того, чтобы помочь вам приступить к работе со своей собственной сеткой данных.
Книга не претендует на роль всеобъемлющего теоретического исследования, зато предлагает практические рекомендации, которые необходимы, чтобы начать работу.
Сперва мы узнаем, на какие основные идеи опирается понятие сетки данных, а также какие преимущества и проблемы с ней связаны. Мы также дадим свое определение сетки данных, которое сформулировано с точки зрения конечных результатов и практичности.
1.1. Основы сетки данных
Парадигма сетки данных заключается в первую очередь в том, чтобы децентрализовать ответственность. Например, команда, которая разрабатывает компонент для регистрации клиентов компании, также создает набор данных, с помощью которого можно анализировать зарегистрированных клиентов. При этом команда заботится о том, чтобы этот набор был в удобном формате: она преобразует данные (например, в файл CSV) и предоставляет их так, как нужно потребителям данных (например, через центральную систему обмена файлами).
Но это простое с виду описание связано с далеко идущими последствиями, потому что в большинстве компаний данные рассматриваются как побочный продукт. Обычно они приобретают ценность только после того, как в качестве побочного продукта размещаются в хранилище, затем силами централизованной команды по работе с данными попадают в центральный узел системы, а затем их снова получают децентрализованные субъекты. Таким субъектом может быть аналитик в отделе маркетинга, или рекомендательная система, которая используется в маркетинговой кампании, или служба вывода в веб-интерфейс. На рис. 1.1 изображена общая форма архитектуры данных — как с организационной, так и с технической точки зрения. Мы также постарались показать все ее подводные камни.
Здесь просматриваются два уровня централизации:
• Централизованная технология в виде хранилища данных и обычного инструментария в области инженерии и анализа данных.
• Организационная централизация команды по работе с данными.
Рис. 1.1. Децентрализованная выработка данных и их централизованное преобразование создают проблемы для пользователей, например, из-за нечеткого понимания, кому принадлежат те или иные данные и кто отвечает за их качество
Поскольку разработчики рассматривают данные как побочный продукт, владение данными неявно приписывается команде по работе с ними. Но такие центральные команды обычно не могут быть в курсе бизнес-знаний, специфичных для разных областей деятельности. Разработчик, который отвечает за регистрацию клиентов, должен знать только язык программирования, на котором написан компонент, а также ориентироваться в обновлениях самого́ этого компонента и бизнес-процессов, которые с ним связаны. Но центральной команде по работе с данными потребуется также хорошо разбираться в предметной области (домене) для каждого из задействованных доменов.
При такой чрезмерной нагрузке маловероятно, что центральная команда освоит хотя бы один домен в такой же степени, как это делает специализированная группа разработчиков. В результате команда по работе с данными не может сказать, верны ли данные, что они на самом деле означают или в чем смысл тех или иных показателей.
Смена парадигмы на сетку данных требует децентрализовать ответственность за данные, рассматривая их как реальный продукт. Ситуацию, которая представлена на рис. 1.1, можно трансформировать в сетку данных, если, например, команда разработчиков начнет предоставлять продукт данных напрямую аналитикам через стандартизированный порт данных. Этот продукт может быть довольно простым, например обычным файлом CSV, который размещен в подходящем облачном хранилище так, чтобы у аналитиков был удобный доступ к нему. Такую трансформацию иллюстрирует рис. 1.2.
Рис. 1.2. Децентрализованные данные лучше отвечают потребностям потребителей, предлагая простой доступ к четко описанным данным
Тут могла бы помочь команда платформы, которая предоставит простую технологию как услугу, чтобы с ее помощью разработчики быстро развертывали подобные продукты данных, включая порты данных. Производители данных сосредоточиваются на том, чтобы создавать продукты данных, которые вместе с потребителями данных начинают образовывать связи и формируют сеть. Мы называем такую сеть сеткой, где отдельные узлы — это продукты данных и потребители.
Даже в этом небольшом примере мы наблюдаем значительное операционное изменение в парадигме. К нему относится как перенос ответственности за владение данными (от центральной команды по работе с данными к разработчикам), так и техническая задача — обеспечить работоспособность новой структуры.
Изменения действующей парадигмы вызовут последствия в самых различных областях вашего бизнеса. Чтобы эти последствия не привели к полному хаосу, необходимы некие руководящие принципы. Мы кратко представим их далее в этой главе и подробно рассмотрим в главах 4–7. Но перед этим следует определить наше понятие сетки данных и обозначить ее нетехнические аспекты. Жамак Дехгани (Zhamak Dehghani) приложила невероятные усилия, чтобы сформировать идею сетки данных в 2019 году (см. «Как перейти от монолитного озера данных к распределенной сетке данных», http://mng.bz/nNaK). Она описала все важнейшие элементы сетки и представила структурированный подход к смене парадигмы, которая обсуждалась ранее.
С тех пор как Дехгани предложила свою концепцию сетки данных, появилось множество примеров, вдохновленных этой концепцией, — как в бизнесе, так и в теоретических разработках. Не все в этих разработках идеально вписывается в первоначальное понятие сетки данных. Похоже, что большинство компаний даже не могут с уверенностью сказать, что именно соответствует определению сетки данных, а что нет.
В нашей деятельности, как и в этой книге, мы предпочитаем решения, которые в первую очередь применимы на практике (отсюда и название — «Data mesh (сетка данных) в действии»). Поэтому мы постарались сформулировать такое определение сетки данных, которое было бы емким и функциональным и делало бы акцент на мерах по децентрализации, которые позволяют максимизировать ценность, извлекаемую из данных.
ОПРЕДЕЛЕНИЕ Сетка данных — это парадигма децентрализации. В ней децентрализуется владение данными, их преобразование в информацию, а также их обслуживание. Ее цель — повысить извлечение ценности из данных, устранив узкие места в потоке конверсии данных в ценность. Понятие сетки данных опирается на четыре принципа (описанные в разделе 1.4 и в главах с 4-й по 7-ю), которые помогают эффективно масштабировать работу с данными: владение доменом, представление данных как продукта, федеративное вычислительное управление и самообслуживаемая платформа данных. Реализации сетки данных могут различаться по объему и степени использования каждого принципа.
Цель внедрения сетки данных — извлечь наибольшую ценность из активов данных компании. Именно в свете этой цели мы стремились к тому, чтобы определение оставалось простым и позволяло в каждом конкретном случае решать, в какой степени следовать тому или иному принципу. Надеемся, что следующий доступно изложенный пример использования сетки данных объяснит, что мы имеем в виду.
1.2. Зачем нужна сетка данных
Мы видим три основные причины, по которым индустрия данных нуждается в децентрализации в виде сетки данных:
• По мере того как количество источников и потребителей данных увеличивается, центральная команда по их обработке создает организационное узкое место.
• Когда существует много технических систем, которые вырабатывают и потребляют данные, центральное монолитное хранилище этих данных создает техническое узкое место, в результате чего больша́я часть информации теряется на этом промежуточном этапе.
• Как качество данных, так и владение ими регламентированы неявно, из-за чего возникает путаница и теряется контроль над тем и другим.
За последние 30 лет большинство архитектур данных разрабатывались так, чтобы интегрировать множественные источники данных: центральные команды по работе с данными объединяли данные, которые поступали из разнообразных источников, и предоставляли «причесанные» наборы данных пользователям, которые, в свою очередь, пытались применять их с пользой для бизнеса. Однако уже более 10 лет проблема «похмельного синдрома» от увлечения большими данными отравляет жизнь компаниям любого масштаба. Эти среды данных страдают от того, что решения плохо масштабируются, информация оказывается неполной, возникают проблемы доступности и т.п. Наверняка и вашей компании нелегко извлекать ценность из данных, верно?
Похоже, что некоторые подходы просто не работают. Десятки отчетов и дашбордов кажутся бесполезными по сравнению с затратами на их создание и поддержку. Многие проекты в области data science застревают на стадии прототипа, а действующие приложения, в которых интенсивно используются данные, по-видимому, испытывают с ними массу проблем. По крайней мере, такое впечатление возникает, если учитывать, сколько усилий необходимо приложить, чтобы заставить программный компонент работать.
Одна из причин проблемы с масштабируемостью состоит в том, что количество источников и потребителей данных быстро увеличивается. Очевидное узкое место возникает, когда одна центральная команда по работе с данными владеет и управляет данными на всех этапах: когда данные поступают, преобразуются и приводятся в порядок, а также когда они предоставляются потенциальным пользователям. Если распределить команду по разным участкам конвейера данных, это тоже мало помогает. Когда специалисты, которые отвечают за поступление данных, что-то меняют, они должны сообщить об этом группе, которая занимается их преобразованием, иначе следующие участки конвейера могут дать сбой или, что еще хуже, неправильно обработать данные. Необходимость тесного сотрудничества между специалистами приводит к жесткому сцеплению (coupling) всех систем, которые относятся к обработке данных.
Другая проблема возникает из-за монолитной природы платформ данных, таких как хранилища и озера. Им часто не хватает разнообразия, чтобы отразить реальность, представленную в данных, которые поступают из источников и структур, определяемых доменом. Более того, когда структуры данных принудительно приводятся к стандартному формату, становится сложнее извлекать ценную информацию из собранных сведений, потому что на централизованных платформах теряются важные знания, специфичные для домена.
Подобная проблема наблюдалась в одном из проектов, над которым мы работали. Компания по производству автозапчастей покупала сведения о неисправностях различных деталей. Хотя поставщик обладал информацией о происхождении деталей (в какой модели автомобиля они были установлены), у покупателя не было моделей данных, которые позволяли бы хранить эту информацию. В результате компоненты анализировались по отдельности, что мешало специалистам по НИОКР лучше понять общую картину.
Еще два взаимосвязанных фактора усугубляют описанные ранее проблемы. Один из них — нечеткая структура владения данными, а другой — ответственность за качество данных. По мере того как данные проходят через специализированные команды, они утрачивают связь со своим бизнес-назначением. Разработчики централизованных систем обработки данных и приложений не могут и не будут полностью понимать смысл данных, а качество данных невозможно оценивать в отрыве от их смысла.
Похожие проблемы были обнаружены и в других областях разработки ПО, в результате чего появились (и завоевали успех!) предметно-ориентированное проектирование и микросервисы. Когда аналогичное мышление (с акцентом на владение данными и общий инструментарий) стало применяться в области инженерии данных, в итоге удалось сформулировать понятие сетки данных.
1.2.1. Альтернативные модели
Вместо того чтобы децентрализовать ответственность за данные, как предлагает сетка данных, гипотетически можно рассмотреть две альтернативные модели. Мы обсудим их подробнее в главе 6, а здесь дадим краткое описание.
Первый вариант — централизовать как сотрудников, так и технические решения. С такого построения начинает любой стартап, и это вполне приемлемая архитектура по умолчанию — так же, как монолитная архитектура приемлема по умолчанию для программных компонентов. На начальном этапе затраты на децентрализацию перевешивают ее преимущества, а работа значительно упрощается потому, что у нас есть единая команда по работе с данными и единое техническое решение.
ВАЖНО Централизация — это разумный стандартный вариант работы с данными как с организационной, так и с технической стороны. Децентрализация сопряжена с издержками, а централизация может их снизить. Однако этот вариант подразумевает, что из централизованных данных мы получаем примерно такую же ценность, как из децентрализованных.
Вторая альтернатива — разделять работу не по бизнес-доменам, как предлагает сетка данных, а по техническим решениям. Обычно это приводит к тому, что одна главная команда инженеров данных отвечает в основном за то, чтобы принимать данные и предоставлять инфраструктуру для их хранения, а несколько других команд (например, аналитики и специалисты по data science) отбирают необработанные данные, чтобы затем превратить их в нечто значимое. Можно сначала централизовать систему данных, а потом использовать эту схему, чтобы увеличить поток.
В этих двух подходах нет ничего плохого. Они могут быть приемлемыми вариантами по умолчанию, однако ни тот ни другой не помогают создавать ценность, которая тесно связана с бизнес-доменами. Ни один из вариантов не справится с ситуацией, когда в каком-то одном домене что-нибудь внезапно меняется. Как и в случае с микросервисами, которые позволяют быстро извлекать ценность из одного конкретного сервиса, масштабируя его в отдельности, сетка данных способна масштабировать извлечение ценности даже в одном домене. Альтернативные варианты требуют масштабировать всю систему, чтобы удавалось извлекать больше ценности всего в одном домене.
Так или иначе оба этих варианта в какой-то момент исчерпают свои возможности: окажется, что добавить очередной источник данных или проект data science окажется чрезвычайно сложно и дорого по сравнению с предыдущими добавлениями. Именно в этот момент имеет смысл перейти на сетку данных.
1.2.2. Хранилища и озера данных внутри сетки данных
С сеткой данных связано распространенное заблуждение: иногда ее воспринимают как единственную альтернативу центральному озеру или хранилищу данных. Но это не отражает самой сути сетки данных, в которой сочетаются две составляющие — технология и организация. Сетка данных — это альтернатива ситуации, когда одно централизованное подразделение занимается данными в рамках одного центрального хранилища данных.
Сетка данных позволяет по-прежнему поддерживать центральное хранилище данных, однако обрабатывать данные и владеть ими будут децентрализованные подразделения. Такая реализация распространена в компаниях, которым не нужна максимальная гибкость на стороне производителей данных. Этот подход также часто применяется, чтобы сохранять озера и хранилища данных в рамках групп бизнес-аналитики (BI) или data science. В этом случае озера и хранилища данных становятся узлами в сетке данных (рис. 1.3).
Рис. 1.3. Сетки данных могут по-прежнему использовать озера данных: например, команда data science, которая создает продукты данных, задействует озера данных в качестве узлов внутри сетки
Сетки данных активно используют как озера данных, так и хранилища данных в различных форматах. Как правило, сетки данных не пытаются привязываться к какой-либо конкретной технологии. Мы подробнее обсудим эту дихотомию в разделе 1.6, а пока давайте взбодримся и сосредоточимся на преимуществах сетки данных.
1.2.3. Преимущества сетки данных
Давайте проанализируем потенциал внедрения сетки данных с точки зрения лиц, которые принимают бизнес-решения, а также с точки зрения технолога.
С точки зрения бизнеса
С точки зрения бизнеса данные сами по себе не представляют особой ценности, более того, они означают издержки! Похоже на ересь? Чтобы понять это утверждение и при необходимости донести его до своих бизнес-партнеров, необходимо представлять себе, на каких уровнях люди могут осознавать реальность.
Хорошей иллюстрацией этого феномена служит пирамида DIKW, которая опирается на пьесу Т.С. Элиота «Камень», написаную в 1934 году. Эта модель представляет данные, информацию, знания и мудрость (DIKW, Data — Information — Knowledge — Wisdom) в виде иерархической структуры, где каждый следующий элемент является производным от предыдущего. (См. «Раскрываем тайны данных: модель DIKW» Энтони Фигероа (Anthony Figueroa), http://mng.bz/v60M.)
Данные в этом контексте — это просто набор значений (хранение которых стоит денег!). Чтобы извлечь из них пользу, нужно выстроить контекст, который позволит принимать обоснованные решения. Благодаря сетке данных вся пирамида становится надежнее.
Как мы уже упоминали, сырые данные не представляют ценности для тех, кто принимает решения. Можно возразить, что эти люди могут загрузить данные на свои рабочие станции и проанализировать самостоятельно. Это так, однако этот вариант базируется на двух основных допущениях:
• Чтобы скачать данные, они должны быть доступны.
• Чтобы анализ приносил пользу, данные должны быть как можно более полными.
Что касается первого допущения: мы уже говорили и повторим еще раз, что сетка данных в значительной степени ориентирована на то, чтобы сделать данные доступными. (А также чтобы их было легко находить, интегрировать и переиспользовать.) Эта доступность заложена в одном из четырех принципов сетки данных: принцип «данные как продукт» посвящен тому, чтобы данные были готовы к использованию.
Полнота данных — это еще одно качество, в котором сетка данных проявляет себя с лучшей стороны. В отличие от большинства архитектур хранилищ или озер данных, продукты данных и соответствующие модели данных — это не то, что IT-специалисты разрабатывают в отрыве от бизнеса. Разработка становится плодом совместных усилий, в результате чего данных, которые представлены за пределами домена, оказывается достаточно для обоснованных выводов.
Сетка данных также помогает повысить ценность компонентов, расположенных выше в иерархии. Команды, которые преобразуют данные в информацию, знания и мудрость (бизнес предпочитает называть ее инсайтом), получают мгновенный доступ к многочисленным источникам данных с высокой совместимостью.
Конечно, для озера данных теоретически тоже можно обеспечить такой немедленный доступ. Однако в реальности, по нашему опыту, это обычно неосуществимо в условиях, когда одна команда управляет техническими аспектами среды, а также правами доступа и передачи данных. А если нужные фрагменты данных хранятся в двух разных озерах (или в четырех, что встречается не так уж редко), заставить их работать вместе практически нереально. Одним словом, если налажен доступ к продуктам данных, которые оптимизированы для чтения, это позволяет быстро прототипировать новые аналитические методы и открывает путь для динамичного развития новых бизнес-возможностей.
С точки зрения технологии
Основное преимущество сетки данных с технической точки зрения заключается в том, что, как мы упоминали ранее, она позволяет сохранять темпы разработки по мере роста организации, а это необходимо, чтобы данные продолжали приносить коммерческую выгоду. Сетка данных устраняет недостатки других архитектур, таких как хранилища или озера данных, благодаря тому, что она децентрализует производство данных и управление ими. Для других архитектур характерно узкое место — центральная команда, которая отвечает за то, чтобы приводить в порядок все данные для целой компании и готовить их к использованию. Такую единственную команду нельзя масштабировать, чтобы удовлетворить разнообразные потребности растущей организации, связанные с данными. И технические решения, и знания команды быстро превращаются в препятствия для масштабирования. В итоге все больше времени тратится на то, чтобы сопровождать имеющиеся решения, а новые проекты все чаще откладываются.
Еще одно преимущество сетки данных — четко определенное владение данными непосредственно с момента их создания. Этот подход упрощает структуру управления данными, оставляя лишь тонкий слой команды федеративного управления, причем ее деятельность ограничивается тем, чтобы согласовывать стандарты в рамках автономных доменов.
Разработка ускоряется также из-за того, что расширяются возможности команд внедрения. Поскольку они теперь отвечают за то, чтобы создавать и поддерживать продукты данных, скорость изменений больше не ограничивается пулом задач одной центральной команды по интеграции. Поэтому продукт данных быстрее развивается и избавляется от недостатков — особенно это касается исправления ошибок и простоев. Кроме того, команда, которая владеет продуктом данных, способна быстрее реагировать на изменения, потому что ей не требуется переключать контекст, как единой центральной команде.
Еще один фактор, о котором стоит упомянуть, — это стабильность среды данных. Поскольку продукты данных предоставляют доступ к сокращенным версиям своих наборов данных, построенные на их основе конвейеры оказываются намного надежнее и требуют гораздо меньше усилий по сопровождению.
1.3. Случай из практики: снегоуборочный бизнес
Кэндис управляет предприятием по уборке снега. Эта бизнес-леди начала собственное дело с того, что каждую зиму сама убирала снег. Через пару лет она расширила свое предприятие. Она сосредоточилась на логистике, бухгалтерии и ценообразовании и наняла трех сотрудников: Адама, который чистит дома в Сосновом проезде, Еву, которая обслуживает Дубовую улицу, и Боба, который заказывает новые лопаты, потому что они постоянно ломаются.
Задача Адама и Евы — не только убирать снег, но и привлекать новых клиентов на своих улицах. В конце концов, они проводят довольно много времени среди местных жителей, каждую зиму расчищая снег! Но Кэндис недовольна. На рис. 1.4 показано, как Кэндис поначалу управляла бизнесом.
Рис. 1.4. В снегоуборочном бизнесе Кэндис, Адам и Ева выполняют свою работу, а Боб обеспечивает запас инвентаря, замораживая капитал
В прошлом году Кэндис попросила Адама и Еву записывать время работы и количество обслуженных домов. Она поместила эти данные в импровизированный файл Microsoft Excel, чтобы произвести некоторые расчеты и установить цены. Соответствующий поток данных показан на рис. 1.5.
Рис. 1.5. Централизованный поток данных от Адама и Евы к Кэндис для принятия решений
Таким образом, можно сказать, что Кэндис превратила данные, полученные от Адама и Евы, в информацию в своем файле Excel, а затем преобразовала ее в решения, благодаря которым появилась бизнес-ценность. Кроме того, она попросила Адама и Еву приблизительно оценить, сколько лопат им понадобится. На рис. 1.6 показан поток данных, направленный к Бобу.
Рис. 1.6. Централизованный поток данных от Адама и Евы через Кэндис к Бобу
Можно сказать, что Адам и Ева предоставили Кэндис необработанные данные, а она агрегировала их в информацию, которую передала Бобу, чтобы тот превратил данные в решения и бизнес-ценность. Обратите внимание, что здесь мы снова видим конвейер — последовательность шагов, которые превращают данные в ценность. В этом конвейере есть два этапа, на которых устанавливаются цены (Адам и Ева собирают данные в своих табелях, а Кэндис агрегирует эти данные и принимает решения на их основе), и три этапа, относящиеся к закупке Бобом лопат (Адам и Ева производят данные с помощью своих прогнозов расхода лопат, Кэндис агрегирует эти данные, а Боб принимает решения на их основе).
Но как мы уже отмечали, Кэндис недовольна сложившейся ситуацией. Прибыль не очень высока, а лопаты, похоже, закупаются неэффективно: иногда накапливается слишком много инвентаря, который не используется, а иногда Адаму и Еве приходится откладывать свою работу, потому что у них заканчиваются лопаты.
В этом году, прочитав книгу «Data mesh в действии», Кэндис решила провести эксперимент. Она собирается создать основу для сетки данных, как описано в главе 3 этой книги. Знания из главы 4 помогают Кэндис определить границы доменов и передать владение данными основным владельцам домена уборки снега, то есть Адаму и Еве. Это означает следующее:
• Кэндис прекращает вести учет времени и вместо этого поручает Адаму и Еве записывать время самостоятельно любым удобным для них способом.
• Адам и Ева будут устанавливать цены на своих улицах.
Затем происходит нечто любопытное: Ева решает повысить цены на Дубовой улице, а Адам снижает цены в Сосновом проезде. Оказывается, они просто знают о своих районах больше, чем Кэндис. На Дубовой улице к домам ведут длинные подъездные дорожки, поэтому Еве имеет смысл брать больше за уборку снега. А в Сосновом проезде местный паренек убирает снег дешевле, поэтому, чтобы оставаться конкурентоспособным, Адам вынужден снизить свои расценки. На рис. 1.7 показан децентрализованный поток данных на текущий момент времени.
Рис. 1.7. Децентрализованный поток данных внутри доменов Адама и Евы
Если теперь посмотреть на поток данных, то можно убедиться, что он полностью остается у Адама и Евы: от данных к информации и, наконец, к решению — к модели ценообразования. По мере того как растет прибыль, Кэндис решает пойти еще дальше и на второй год эксперимента берется за проблему закупок. Чтобы ее решить, она поручает Адаму и Еве напрямую сообщать Бобу о том, сколько лопат им, скорее всего, понадобится.
Чтобы избежать путаницы и лишней переписки, Адам и Ева создали электронную таблицу. Они регулярно ее обновляют, поэтому если из-за текущих погодных условий или метеорологических прогнозов их оценки меняются, то информация все равно остается актуальной. На рис. 1.8 показан поток данных, которые передаются Бобу.
Рис. 1.8. Данные децентрализованно предоставляются в доменах Адама и Евы и передаются Бобу для принятия решений
В рамках теперешнего потока данных Адам и Ева хранят и данные, и информацию в своих доменах. Они пытаются предоставить Бобу правильную информацию, а не просто необработанные данные, которые им поручили собрать. В результате Боб может сам принимать решения о закупках и выглядит довольным. Когда Кэндис интересуется, с чем это связано, он отвечает: Ева догадалась, что ему также стоит знать, как часто ломаются лопаты. У Евы они ломаются чаще, потому что подъездные дорожки длиннее.
Сокращение потока данных приводит к неожиданной коммерческой выгоде. Раньше Адам и Ева предоставляли Кэндис пессимистичные оценки, потому что не хотели остаться без лопат. Однако иногда они боялись рассердить ее слишком большим количеством сломанных лопат, поэтому, надеясь на лучшее, давали оптимистичные оценки. Кэндис обычно добавляла к этому резервный запас, прежде чем поручить Бобу закупки, но иногда беспокоилась о расходах и рисковала, занижая оценку.
Боб догадывался, что полученные цифры ненадежны, и часто пытался скорректировать заказ, опираясь на собственную интуицию (и докладывая Кэндис, например, что нужного количества лопат не было в продаже). Чтобы поддерживать работу компании, ему приходилось создавать запас лопат, а это снижало финансовую ликвидность предприятия: капитал замораживался, а складские расходы увеличивались. Теперь, когда Боб получил доступ напрямую к прогнозам Адама и Евы, ему удается закупать столько лопат, сколько нужно. К концу года у него почти не остается лишнего инвентаря, но при этом не ощущается и недостатка в лопатах.
В результате Кэндис получает неплохую прибыль из-за того, что на второй год снизились затраты, а кроме того, у нее теперь есть три довольных сотрудника. Обратите внимание, что источником всех проблем был именно конвейер — поток данных от одного подразделения (в данном случае от Адама и Евы) к Кэндис и далее к Бобу. Все, что сделала Кэндис, — разбила этот конвейер и упаковала его в один или, самое большее, в два сегмента. Вот как работает децентрализация.
Это действительно все, что нужно было сделать. Разбивая конвейер в конкретных ситуациях, вы в итоге получите лучшие результаты, потому что децентрализованные сегменты (в нашем случае Адам и Ева) попросту могут преобразовывать данные в ценность лучше, чем это сделал бы общий конвейер.
Возможно, в следующем году Кэндис соберется наладить какую-то форму управления. Например, она может ввести правила по частоте обновлений или обеспечить защиту электронных таблиц, чтобы паренек из Соснового проезда не попортил данные. Может быть, она наймет кого-то, чтобы создать сайт, с помощью которого люди смогут заказывать услуги онлайн, — для этого ей придется разработать продукты данных, которые отражают рабочее время Адама и Евы, и связать их с новой системой, частично используя платформу. Не правда ли, будущее кажется весьма перспективным, когда у вас есть операционная прибыль?
Далее мы рассмотрим четыре принципа сетки данных, которые считаем краеугольным камнем при ее внедрении. Но как мы уже говорили, наше определение сетки данных является довольно широким и ориентируется на бизнес-ценность. Поэтому вам необходимо самостоятельно расставить приоритеты и определить, в какой степени вам стоит следовать этим принципам, чтобы достичь своих бизнес-целей. Как и Кэндис, вам имеет смысл использовать описанные ниже принципы как ориентиры, которые помогут успешно внедрить сетку данных.
1.4. Принципы сетки данных
Дехгани впервые описала современное представление о сетке данных в виде набора из четырех принципов. В этой книге мы сосредоточимся на особенностях их реализации. Ниже приводится обзор этих четырех краеугольных камней сетки данных.
1.4.1. Доменно-ориентированная децентрализация владения данными и архитектуры
Первый принцип заключается в том, что данными и их соответствующими компонентами должны владеть те, кто ближе всего к ним; эти же люди должны сопровождать и разрабатывать данные — имеются в виду люди внутри домена данных. Этот принцип предписывает применить понятия доменов и ограниченных контекстов к сфере данных. Из него также следует, что потребуется децентрализовать владение и архитектуру.
Суть здесь в том, что, как и в предыдущем примере, специалисты внутри домена разрабатывают интерфейсы данных, которые позволяют использовать данные домена другим людям — специалистам по data science, пользователям самообслуживаемой BI, инженерам данных или разработчикам систем. Предполагается, что специалисты по каждому продукту данных должны быть экспертами в соответствующей области, что сводит к минимуму проблемы коммуникации и неправильного толкования данных.
Владение данными должно быть четко определено, и его не следует централизовать на уровне организации. Ответственность за данные нужно передать в руки тех, кто ближе всего к ним. Если набор данных ориентирован на источник, то владельцем данных может быть команда домена, а когда из нескольких наборов данных создаются новые наборы, отвечать за них может команда по работе с данными, группа инженеров-аналитиков или специалисты по data science. Если же набор данных существенно ориентирован на потребителей, то владеть им может то подразделение организации, которое использует данные.
Домен — это область или часть нашего бизнеса. Домены позволяют фрагментировать и декомпозировать компанию. Довольно часто организационная структура компании воспроизводит бизнес-домены. Например, в компании «Messflix» можно найти домены, которые относятся к распространению контента, производству контента, развитию рынка и бренда (рис. 1.9).
Рис. 1.9. Упрощенная схема бизнес-доменов «Messflix»
Принцип владения доменом гласит, что каждая команда или подразделение, которые владеют доменом, должны также владеть данными, которые создаются в этом домене. Таким образом, если команда разрабатывает программное обеспечение, с помощью которого производится контент, то она же отвечает и за данные, которые относятся к производству контента. Но что означает отвечать за данные?
