Книга: «Data mesh в действии»
Привет, Хаброжители!
Потребность эффективно хранить большие объемы данных и обращаться к ним стала одной из ключевых потребностей любого бизнеса. Сетка данных (data mesh) — это новый способ децентрализовать управление данными, радикально повышая их безопасность и доступность. Хорошо спроектированная сетка данных позволяет потреблять данные в режиме самообслуживания и помогает избавляться от узких мест, которые свойственны монолитным архитектурам данных.
Пора разобраться с тем, как на практике децентрализовать данные и организовать их в эффективную сетку. Сперва вы создадите простейший жизнеспособный продукт данных, а потом, продвигаясь от главы к главе, преобразуете его в самообслуживаемую платформу данных. Вам наверняка понравятся предложенные в книге «ползунки», с помощью которых можно будет настроить сетку под ваши потребности.
Книга предназначена для профессионалов в области данных и не привязана к конкретным программным стекам или платформам данных.
Первая группа — это специалисты, которые участвуют в создании и использовании данных, а также в управлении данными в компаниях, где доминируют такие факторы:
- высокая социотехническая сложность (например, крупные корпорации);
- сложные сценарии использования данных;
- многочисленные и разнообразные источники данных.
Чем больше эти факторы применимы к вашему бизнесу, тем вероятнее, что вам может пригодиться сетка данных. Книга поможет вам разобраться в принципах сетки данных, в том числе понять, с кем нужно наладить сотрудничество и какие шаги следует предпринять как с организационной, так и с технической стороны, чтобы перейти от беспорядочных данных к сетке.
Кроме того, поскольку внедрение сетки данных — это процесс трансформации в масштабах всей компании, содержание книги будет полезно руководителям высшего звена, включая технических директоров и менеджеров, корпоративных архитекторов, главных и ведущих архитекторов, а также владельцев решений и программ. Эта книга поможет решить, в какой степени и с какой приоритетностью следует переводить среду данных компании в русло сетки данных, а также пригодится для того, чтобы спланировать управление изменениями.
Часть 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 и многом другом.
Данные как продукт
В ЭТОЙ ГЛАВЕ
- Как с помощью дизайн-мышления обосновать выбор потенциального продукта данных
- Как определить, кто будет отвечать за его разработку
- Как сформировать команду, которая будет его разрабатывать
- Как определить интерфейсы продукта данных
- Как проектировать структурные элементы продукта данных
- Как дополнить сетку данных контрактами данных и соглашениями о совместном использовании
В предыдущей главе, обсуждая принцип владения доменами, мы привели примеры продуктов данных для бизнес-возможности «Производить контент». Мы использовали термин «продукт данных», не уточняя, что это такое и как его создавать. Пришло время разобраться, что значит рассматривать данные как продукт.
Рассуждая о данных, мы часто сосредоточиваемся на технических аспектах, таких как схема данных или их реляционные свойства. Однако необходимо помнить, что не менее важны и другие сопутствующие элементы, например описание схемы, описание домена, определение правил доступа, метрики и проверка качества. Часто этими элементами по отдельности занимаются разрозненные специализированные команды по работе с данными, и в результате оказывается, что эти нефункциональные аспекты данных не образуют с самими данными целостной сущности, которой было бы легко управлять.
С другой стороны, в организациях бывает множество наборов данных, которые было бы полезно иметь в удобной для использования форме. К сожалению, зачастую они труднодоступны, например, находятся на личном диске, не описаны и, как правило, не подготовлены к употреблению (не очищены и не стандартизированы).
Поэтому имеет смысл начать рассматривать данные как продукт — четко определенный артефакт, который адаптирован к потребностям пользователей.
В предыдущей главе мы с помощью моделирования бизнес-возможностей определили претендентов на создание продуктов данных из домена «Производить контент». Достаточно ли этого, чтобы утверждать, что это будут окончательные продукты данных? Пока нет: в рамках концепции сетки данных мы хотим рассматривать данные как продукт, поэтому нужно убедиться, что наборы данных обладают следующими характеристиками:
- имеют бизнес-ценность;
- легко находимы;
- доступны;
- способны работать совместно;
- могут использоваться в различных контекстах.
Нам нужно убедиться, что тот или иной набор данных заслуживает того, чтобы сделать из него продукт, который оправдает затраты на его создание. Кроме того, правильно проведенный анализ позволит расставить приоритеты в работе над продуктами данных. Для этого мы воспользуемся методикой, которая уже много лет применяется при разработке программного обеспечения, — продуктовым мышлением.
КАК ПРИМЕНЕНЯТЬ ПРОДУКТОВОЕ МЫШЛЕНИЕ
Продуктовое мышление — это методика решения проблем, которая ориентируется в первую очередь на то, чтобы определить, какую проблему хочет решить пользователь, прежде чем приступать к созданию продукта. Цель этой методики — свести к минимуму разрыв между потребностями пользователей и предлагаемым решением. У нее есть два основных принципа:
- Уделяйте больше внимания проблеме, а не ее решению. Прежде чем разрабатывать конкретные компоненты продукта, тщательно изучите, кто ваши пользователи и какую проблему вы пытаетесь решить.
- Думайте о продуктах, а не о функциональности. Очень соблазнительно сосредоточиться на том, чтобы добавлять новые функции и адаптировать отдельные элементы. Однако важно думать о данных как о продукте, который удовлетворяет потребности пользователей. Недостаточно просто предоставить существующие данные.
Конечный продукт должен эффективно соединять между собой пользователей, их потребности, команду, которая решает проблему, и технологию, которая служит средством решения проблемы. Поэтому, прежде чем вы начнете предоставлять набор данных в духе продуктового мышления, задайте себе и своим пользователям такие вопросы:
- Какую проблему вы хотите решить?
- Кто будет пользоваться продуктом?
- Зачем вы это делаете? В чем смысл?
- Какова ваша стратегия? Как вы будете это делать?
- В какие сроки нужно уложиться?
- Какие функции нужно включить?
Разумеется, в зависимости от контекста и сложности продукта данных масштабы анализа и ответы на эти вопросы будут различаться.
Анализ в рамках продуктового мышления
Применим продуктовое мышление к кандидатам в продукты данных из предыдущей главы: «Отчеты о затратах», «Сценарии», «Популярность фильмов», «Тренды киноиндустрии» и «Актерские составы».
Продукт данных «Отчеты о затратах»
Иногда самые простые случаи труднее всего описать. Довольно часто файлы, которые используются в организациях, заслуживают того, чтобы предоставить их более широкой аудитории.
В первом примере мы рассмотрим файл с детализацией производственных затрат компании «Messflix». Поскольку до сих пор не было комплексного решения этой задачи, сотрудники собирают и рассчитывают затраты в файле Excel, а затем вручную копируют и импортируют их в хранилище данных для финансовой и клиентской аналитики. Затем часть этих данных импортируется в систему планирования ресурсов предприятия (ERP). Текущая ситуация представлена на рис. 5.1.
В табл. 5.1 собраны ответы на несколько вопросов в духе продуктового мышления. Следует помнить, что в нашем случае набор данных уже существует и мы не создаем продукт данных полностью с нуля.
Рис. 5.1. Как используются данные отчетов о затратах до преобразования
в продукт данных
Таблица 5.1. Анализ набора данных «Отчеты о затратах» в рамках
продуктового мышления
Продукт данных «Сценарии»
Данные о сценариях фильмов входят в экосистему «Hitchcock» и сейчас представляют собой микросервис, который работает через пользовательский интерфейс. Однако эти данные не передаются за пределы системы, поэтому их трудно использовать для целей, которые не предусмотрены самой системой «Hitchcock». В настоящее время сценарии для производства отбираются полностью в ручном режиме, который требует напряженной работы специалистов. С помощью этих данных можно было бы создавать автоматизированные рекомендации, задействуя также информацию об актерских составах, трендах киноиндустрии и популярности фильмов. В табл. 5.2 представлен анализ соответствующего продукта данных с позиции продуктового мышления.
Таблица 5.2. Анализ набора данных «Сценарии» в рамках продуктового мышления
Продукт данных «Популярность фильмов»
В компании «Messflix» данные о популярности фильмов извлекаются из платной базы данных мирового кинематографа через специально разработанный пользовательский интерфейс в системе «Hitchcock», и с учетом этих данных принимаются решения о том, какие фильмы производить. Данные доступны через пользовательский интерфейс в формате, с которым можно работать только вручную. Аналогично сценариям, данные о популярности фильмов можно было бы использовать, чтобы автоматизировать процесс рекомендаций. В табл. 5.3 представлен анализ соответствующего продукта данных с позиции продуктового мышления.
Таблица 5.3. Анализ набора данных «Популярность фильмов» в рамках продуктового мышления
Представленный набор вопросов помогает убедиться в том, что продукт данных будет востребован. На следующем шаге стоит глубже проанализировать продукт данных, и именно здесь может пригодиться такой инструмент, как канва продукта данных. Она будет полезна, когда мы перейдем к более техническим аспектам разработки продукта данных, в частности, когда будем определять источники данных, конкретные данные, входящие в продукт, и тип продукта.
Эта информация поможет лучше понять суть продукта данных и принимать технические решения об окончательном варианте.
Мы рекомендуем использовать канву продукта данных как дополнительный инструмент анализа в рамках продуктового мышления. Мы применим его к двум последним продуктам данных — «Тренды киноиндустрии» и «Актерские составы».
Канва продукта данных
Канва продукта данных (data product canvas) — это инструмент, который позволяет структурировать анализ продукта данных. Он выглядит как наглядная таблица с отдельными разделами для разных аспектов, таких как название, описание, владелец продукта данных и выходные порты. Благодаря своей наглядности он позволяет проводить коллективные обсуждения в формате семинаров. С помощью этого инструмента мы проанализируем два следующих продукта данных.
Канва продукта данных «Актерские составы»
Информация о продукте данных «Актерские составы» представлена на рис. 5.2.
Рис. 5.2. Канва продукта данных «Актерские составы»
Как видно из этого примера, канва продукта данных состоит из таких разделов:
- Название продукта данных.
- Описание продукта данных.
- Владелец продукта данных.
- Бизнес-возможность / домен / ограниченный контекст. Область, к которой относится продукт данных.
- Система. Название системы или систем, с которыми связан продукт данных.
- Классификация. Характер предоставляемых данных.
- Привязка к источнику. Данные предоставляются непосредственно из системы-источника.
- Привязка к потребителям. Данные преобразовываются, чтобы удовлетворять нуждам потребителей; при этом данные часто извлекаются из нескольких источников.
- Общее ядро. Данные используются многими продуктами данных и/или потребителями.Виртуальные. Данные, которые предлагаются пользователям и вычисляются в момент использования
- Материализованные. Данные, которые изначально сохраняются в окончательной форме, а затем предоставляются пользователям.
- Классификация жизненного цикла. Стадия зрелости продукта данных
- Экспериментальный. Продукт находится в стадии разработки.
- Устоявшийся. Продукт готов к реальной эксплуатации.
- Входной интерфейс определяет, какие данные нужно получить из других источников. В реализации интерфейса используются другие системы или наборы данных, из которых поступают данные.
- Выходные порты. Форма, в которой данные предоставляются потребителям.
- Безопасность. Правила безопасности, которые применяются к использованию продукта данных.
- Входящий поток. Набор данных, который поступает в продукт данных.
- Исходящий поток. Наборы данных, которые исходят из продукта данных.
- Объем. Предполагаемый объем данных, которые входят в продукт.
- Наборы данных, из которых состоит продукт.
Канва продукта данных «Тренды киноиндустрии»
Информация о продукте данных «Тренды киноиндустрии» представлена на рис. 5.3.
Рис. 5.3. Канва продукта данных «Тренды киноиндустрии»
Результатом этого анализа в рамках продуктового мышления становится экосистема сетки данных, связанная с бизнес-возможностью «Производить контент», которая представлена на рис. 5.4.
Выполнив анализ с помощью продуктового мышления и канвы продуктов данных, мы определяем пять продуктов данных. Три из них основаны на данных «Hitchcock Movie Maker»: «Отчеты о производственных затратах», «Сценарии» и «Актерские составы». Продукт «Популярность фильмов» основан на API базы данных мирового кинематографа, а «Тренды киноиндустрии» — на данных «Movie Market Monitor».
Разные продукты используются разными системами. Система рекомендации сценариев использует такие продукты, как «Сценарии», «Актерские составы», «Популярность фильмов» и «Тренды киноиндустрии», чтобы автоматически генерировать рекомендации по сценариям, которые стоит отправить в производство. Продукт «Тренды киноиндустрии» используется маркетинговым BI-инструментом, чтобы принимать решения, связанные с инвестициями в продвижение фильмов, а также системой рекомендации контента, чтобы формировать тематические подборки предстоящих фильмов. «Отчеты о затратах» система финансового анализа использует для финансового анализа, а система планирования ресурсов предприятия — для того, чтобы отслеживать понесенные затраты.
Рис. 5.4. Экосистема продуктов данных
ЧТО ТАКОЕ ПРОДУКТ ДАННЫХ
До сих пор мы активно использовали термин «продукт данных», но не давали ему определения. Если понимать продукт как результат сознательного действия, то довольно просто определить, что не является продуктом данных. Им не являются данные, которые получились как побочный продукт в результате какой-то другой деятельности. Если сотрудник создал файл Excel, который находится в свободном доступе, этот файл — не продукт данных, потому что:
- Он не был выработан с намерением создать продукт данных, то есть никто не предпринимал никаких сознательных усилий, чтобы сделать его продуктом данных.
- Он не отвечает четко определенным потребностям пользователей.
Определение продукта данных
Мы определяем продукт данных таким образом:
Продукт данных — это автономный, оптимизированный для чтения, стандартизованный блок данных, который содержит как минимум один набор данных (доменный набор данных) и создается, чтобы удовлетворить потребности пользователей.
Рисунок 5.5 иллюстрирует это определение. На рисунке видно, что продукт данных — это автономная сущность, которая предоставляет доступ к своим данным с помощью выходных портов, через которые к данным могут обращаться другие системы транзакций, продукты данных или конечные пользователи
Рис. 5.5. Продукт данных и его контекст
ПРИМЕЧАНИЕ Чтобы избежать путаницы, стоит также отметить, что термин «продукт данных» уже существует в области обработки данных в другом значении, которое не относится к сетке данных. Там продукт данных определяется как «приложение или инструмент, который использует данные, чтобы помогать бизнесу совершенствовать свои решения и процессы». Согласно этому определению, к продуктам данных относятся любые инструменты, которые облегчают обработку данных, особенно их статистический анализ.
Рассмотрим продукты данных в домене «Производить контент», чтобы пояснить, что это определение означает на практике:
- Автономный блок данных (data unit). Каждый продукт данных — это самодостаточная система или набор данных, который можно рассматривать как независимую единицу. Например, «Популярность фильмов» — это отдельный компонент, выполненный в виде озера данных. Он самостоятельно извлекает данные из внешнего API, обрабатывает их, сохраняет и делает их доступными для своих потребителей. Этот компонент можно разработать, не затрагивая другие системы и данные «Messflix», как показано на рис. 5.6.
Рис. 5.6. Продукт данных «Популярность фильмов» — это автономный блок данных
- Блок данных, оптимизированный для чтения. Форма хранения данных оптимизирована для анализа. В продукте «Популярность фильмов» данные хранятся в виде файлов с рейтингом фильмов, который составляется каждую неделю. Инструменты обработки данных (например, библиотеки языка Python) позволяют легко выполнять более сложный анализ.
- Стандартизованный блок данных. Продукт данных должен быть организован надлежащим образом, он должен быть описан метаданными, использовать стандартные протоколы и порты для обмена данными, а также определенные словари и систему идентификаторов. Более подробные практические примеры на эту тему вы найдете далее в этой главе.
- Узел в сетке данных. Продукт данных органически становится частью более крупной экосистемы, в частности, благодаря тому, что публикует нужные метаданные каталога данных и позволяет использовать их в режиме самообслуживания.
- Содержит как минимум один доменный набор данных. Продукт должен содержать набор данных, который сам по себе имеет бизнес-ценность. Например, «Популярность фильмов» содержит набор данных о рейтинге фильмов за определенную неделю, «Сценарии» — набор метаданных о сценариях, а «Отчеты о затратах» — набор данных о затратах на производство фильмов.
- Удовлетворяет потребности пользователей. Продукт данных создается в рамках продуктового мышления и ориентирован на четко определенных пользователей. Например, в случае с «Отчетами о затратах» это бухгалтеры, которые осуществляют финансовый контроль производственных затрат.
Продукт, а не проект
Как вы уже знаете, термин «продукт» в контексте сетки данных используется не случайно. Подчеркнем его отличие от термина «проект», которым обычно обозначаются различного рода инициативы, реализуемые в организациях. Учтите, что создание продукта данных не следует рассматривать как проект. Проект — это ограниченная во времени деятельность, которая должна привести к определенной цели. Когда цель достигнута, проект завершается и не может быть продолжен.
В свою очередь, продуктовое мышление заставляет рассматривать продукт данных в долгосрочной перспективе, не ограничиваясь тем, чтобы просто предоставить к нему доступ. Такой подход предполагает, что в дальнейшем продукт будет развиваться и корректироваться на основе обратной связи от пользователей. Продуктовое мышление подразумевает, что мы будем непрерывно совершенствовать продукт и долгосрочно заботиться о его качестве в отличие от одноразового проекта.
Из чего можно сделать продукт данных
Какой объект может стать кандидатом на то, чтобы превратиться в продукт данных? В общем случае в этом качестве можно рассматривать любое представление данных, которое имеет ценность для пользователей. Вот некоторые примеры:
- Сырые неструктурированные файлы. Например, изображения, которые получены с помощью оборудования для отбора геологических проб, или видеоролики, которые загрузили пользователи видеопортала. Однако чтобы иметь ценность для конечных пользователей, эти файлы должны описываться достаточным количеством метаданных.
- Простые файлы. Например, результаты серии измерений на геологических образцах, отчеты в формате Excel или данные в формате CSV, экспортированные из приложения. В этом случае описание в виде метаданных тоже может быть критически важным для того, чтобы файлы можно было использовать.
- Набор данных внутри базы данных (или хранилища данных общего вида). Содержит данные из системы-источника (системы первичных данных) в формате, оптимизированном для чтения.
- Набор данных на основе данных, полученных из системы типа COTS (Commercial Off-The-Shelf — «готовые к использованию»). Например, информация о количестве продукции на складе.
- REST API. Данные, которые предоставляют приложения для чтения транзакционных данных. Данные оптимизированы для чтения и могут поддерживать ограничения HATEOAS, чтобы облегчить автоматизированное (машиночитаемое) потребление данных.
- Поток данных, который представляет историю изменений в приложении. Например, события, связанные с изменениями, которые вносились в учетной записи выставления счетов.
- Поток данных, который представляет моментальные снимки объектов данных из системы транзакций. Например, информация о пользователе системы.
- Витрина данных. Представление данных, которое позволяет проводить многомерный анализ результатов продаж.
- Денормализованная таблица. Содержит информацию, оптимизированную для поиска (например, о прокате определенного фильма).
- Графовая база данных. Отражает сложные взаимосвязи между данными (например, специализированная база для поиска рекомендаций по фильмам).
- Локальное озеро данных или часть более крупного озера данных. Позволяет построить представление, на основе которого анализируется статистика просмотров фильмов.
- База данных типа MDM («управление мастер-данными»). Содержит интегрированное представление о пользователях системы (персональную информацию, настройки просмотра, настройки времени просмотра, платежную информацию, сведения о рейтинге и т. д.).
Как видно из этого списка, вариантов много и все они — лишь примеры самих данных, которые образуют ядро продукта данных. Сетка данных не навязывает какую-то определенную форму представления данных или конкретную технологию.
СВЕН БАЛНОЯН (DR. SVEN BALNOJAN) — технолог данных и разработчик продуктов; он стремится помочь миру извлечь больше пользы из экспоненциально растущего объема данных. Он увлечен всем, что касается данных, машинного обучения, искусственного интеллекта, бизнес-аналитики и многих других смежных областей. Он управляет внутренними командами по работе с данными и занимается трансформацией команд из сервис ориентированных в платформенно-ориентированные, а также выступает в качестве разработчика данных в области машинного обучения, инженерии данных и DevOps в сфере данных. Свен — PhD в математике, защитивший диссертацию в области теории сингулярности. Он является автором амбициозного информационного бюллетеня «Three Data Point Thursday» («Четверг по трем точкам данных»). Кроме того, он ведет блог на сайте datacisions.com и время от времени выступает с докладами в интернете.
МАРИАН СИВЯК (DR. MARIAN SIWIAK) — мастер на все руки во всех сферах работы с данными и специалист по их интеграции с бизнес-операциями. В качестве главного специалиста по data science компании «Cognition Shared Solutions» он выступает как консультант по использованию данных стратегического уровня и разработчик фреймворка «Трехуровневый анализ бизнес-процессов» (Trilayer Business Process Analysis), который объединяет выполнение процессов, среды данных и управление рисками. У него богатый опыт реализации научных, технических и IT-проектов с бюджетом в миллионы долларов в различных сферах — от биологических наук до робототехники. Он читал лекции по управлению данными в разных бизнес-университетах. Его команда первой опубликовала модель глобального распространения вируса COVID-19. Мариан — муж, отец троих детей, увлекается лыжами, ходит под парусом и пишет фантастическую прозу.
Более подробно с книгой можно ознакомиться на сайте издательства:
» Оглавление
» Отрывок
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Data mesh
P.S Обращаем ваше внимание на то, что у нас на сайте проходит распродажа.
