Data mesh в действии

Предисловие
Введение
Благодарности
О научном редакторе русского издания
От издательства
О книге
Для кого эта книга
Структура книги
Часть 1. Введение
Часть 2. Четыре принципа на практике
Часть 3 . Инфраструктура и системная архитектура
Как пользоваться этой книгой
Пример: компания "Messflix"
Форум liveBook
Об авторах
Иллюстрация на обложке
Часть 1
Введение
Глава 1. Что такое сетка данных и зачем она
нужна
1.1. Основы сетки данных
1.2. Зачем нужна сетка данных
1.2.1. Альтернативные модели
1. 2.2. Хранилища и озера данных внутри сетки
данных
1. 2.3 . Преимущества сетки данных
1. 3 . Случай из практики: снегоуборочный бизнес
1.4. Принципы сетки данных
1.4.1. Доменно-ориентированная
децентрализация владения
данными и архитектуры
1.4.2. Данные как продукт
1.4.3. Федеративное вычислительное
управление
1.4.4. Самообслуживаемая инфраструктура
данных
как платформа
1.5. Возвращаясь к уборке снега
1.6. Социотехническая архитектура
1.6.1. Закон Конвея
1.6.2. Топологии команд
1.6.3. Когнитивная нагрузка
1.7. Трудности внедрения сетки данных
1.7.1. Технические трудности
1.7.2. Трудности управления данными
1.7.3. Организационные проблемы
Итоги
Глава 2. Подходит ли вам сетка данных?
2.1. Факторы принятия решения о реализации
сетки данных
2.1.1. Факторы бизнеса
2.1.2..Организационные.факторы
2.1.3. Факторы доменных данных
2.1.4. Второстепенные организационные
факторы
2.1.5 . Подходит ли вам сетка данных?
2.2. Альтернативные и дополнительные
решения для сетки данных
2.2.1. Корпоративное хранилище данных
2.2.2. Озеро данных
2.2.3. Озеро-хранилище данных
2.2.4. Ткань данных
2.2.5 . Сетка данных в сравнении с остальными
архитектурами . . . .
2.3 . Оценка усилий по реализации сетки
данных
2.3.1. Цикл разработки сетки данных
2.3.2. Цикл разработки на примере
снегоуборочного бизнеса
2.3.3. Организация координационной команды
2.3.4. Цикл разработки в деталях
Итоги
Глава 3. Как запустить минимально
жизнеспособный продукт сетки данных в течение
месяца
3.1. Общее представление о ситуации
3 .1.1. Диаграмма системного ландшафта
компании
3.1.2. Анализ заинтересованных сторон
3.2. Как набрать людей в команду реализации
MVP
3.2.1. Выбор команды разработчиков
3.2.2. Как выбрать модель сотрудничества
3.2.3. Подбор команды по управлению данными
3.3. Как наладить управление MVP
3.3 .1. Заявление о ценностях для сетки
данных
3.3.2. Как определить политики управления
данными
3.3.3. Федерализация управления данными
3.4. Как разработать минимальные продукты
данных
3.4.1. Как обнаружить домено-ориентированные
наборы данных
3.4.2. Как выбрать владельцев продуктов
данных
3.4.3. Как описать минимально жизнеспособный
продукт данных
3.4.4 . Как разработать простейшие инструменты,
с помощью
которых.можно.предоставлять.ваши.данные
3.5. Как настроить минимальную платформу
3.5 .1. Как обеспечить управление,
регулируемое платформой
3.5.2. Как обеспечить безопасность платформы
Итоги
Часть 2
Четыре принципа на практике
Глава 4. Владение доменами
4 .1. Как фиксировать и анализировать
домены
4.1.1. Основы доменно-ориентированного
дизайна
4.1.2. Как привлечь нужных людей
4 .1. 3 . Как выбрать правильную методику
проведения воркшопа. . . .
4.2. Как назначить владельцев с помощью
декомпозиции домена
4.2.1. Домен, поддомен и бизнес-возможности
4.2.2. Декомпозиция доменов с помощью
моделирования
бизнес-возможностей
4.2.3 . Как домены и бизнес-возможности
связаны с данными
4.2.4 . Зоны ответственности команды,
которая владеет
продуктом.данных
4.2.5 . Как выбрать правильную команду в
качестве
владельца.данных
4.3 . Как назначать владельцев с помощью
сценариев использования данных
4.3 .1. Сценарии использования данных
4.3.2. Модель и ограниченный контекст
4.3.3 . Как устанавливать границы продуктов
данных, ориентированных на конкретные сценарии
использования
4.3.4 . Как выбрать правильную команду в
качестве владельца данных
4.4 . Как назначать владельцев с помощью
эвристических методов проектирования
4.4 .1. Что такое эвристический метод
4.4.2. Эвристические методы проектирования
4.4.3 . Разработка эвристических методов и
возможные границы. . . .
4.5 . Окончательный ландшафт: сетка
взаимосвязанных
продуктов.данных
4.5.1. Сетка данных компании "Messflix"
4.5.2. Продукты данных образуют сетку
4.5.3. Действительно ли это сетка данных?
Итоги
Глава 5. Данные как продукт
5.1. Как примененять продуктовое мышление
5 .1.1. Анализ в рамках продуктового
мышления
5.1.2. Канва продукта данных
5.2. Что такое продукт данных
5.2.1. Определение продукта данных
5.2.2. Продукт, а не проект
5.2.3 . Из чего можно сделать продукт данных
5.3. Владение продуктом данных
5.3.1. Владелец продукта данных
5.3.2. Зоны ответственности владельца
продукта данных
5.3.3 . Agile DevOps-команда как основа
команды разработчиков
продукта.данных
5.3.4 . Владелец продукта данных и владелец
продукта
5.4 . Концептуальная архитектура продукта
данных
5.4 .1. Внешнее представление архитектуры
5.4.2. Внутреннее представление архитектуры
5.5. Основные характеристики продукта
данных
5.5.1. Самоописываемый продукт данных
5.5.2. Введение в метаданные
5.5.3. Метаданные как код
5.5.4. Метаданные продукта данных
5.5.5. Метаданные доменного набора данных
5.5.6. Другие виды метаданных
5.6 . Дополнительные характеристики
продуктов данных: FAIR
и неизменяемость
5.6.1. Находимость
5.6.2. Доступность
5.6.3. Совместимость
5.6.4. Возможность повторного использования
5.6.5. Неизменяемость
5.7 . Контракты данных и соглашения о
совместном использовании
данных.внутри.сетки.данных
5.7 .1. Контракты данных и соглашения о
совместном использовании.данных
5.7.2. Внедрение контрактов данных и
соглашений о совместном использовании данных
Итоги
Глава 6. Федеративное вычислительное
управление
6 .1. Кратко об управлении данными
6.2. Преимущества управления данными
6.2.1. С точки зрения бизнес-ценности
6.2.2. С точки зрения удобства использования
данных
6.2.3 . С точки зрения контроля данных
6.3 . Как планировать результаты внедрения
управления данными
6.3 .1. Иерархия результатов управления
данными
6.3.2. Результаты на стратегическом уровне
6.3.3. Результаты на тактическом уровне
6.3.4. Результаты на уровне внедрения
6.4. Федерализация управления данными
6.4.1. Управление данными и модель
"ползунков"
6.4.2. Предельные случаи моделей руководства
данными
6.4.3. Модель федеративного управления
данными
6.4.4. Как организовать работу команды
управления
6.5. Как сделать управление данными
вычислительным
6.5.1. Как сделать политики вычислительными
6.5.2. Как автоматизировать контроль за
соблюдением политик. . .
Итоги
Глава 7. Самообслуживаемая платформа данных
7.1. Платформа MVP
7.1.1. Что такое платформа
7.1.2. Платформенное мышление
7.2. Улучшения с помощью принципа "X как
услуга"
7.2.1. Что такое "X как услуга"
7.2.2. "X как услуга" на практике
7.3 . Усовершенствования с помощью
платформенной архитектуры
7.3 .1. Что такое архитектура платформы
7.3.2. Как применить платформенную
архитектуру
7.4 . Улучшения для производителей данных
Итоги
Часть 3
Инфраструктура и системная архитектура
Глава 8. Сравнение самообслуживаемых платформ
данных
8 .1. Сетка данных на основе Google Cloud Platform
(GCP)
8 .1.1. Архитектура самообслуживаемой
платформы данных
8.1.2.. Компоненты.платформы
8.1.3. Компоненты продуктов данных
8.1.4. Рабочие процессы
8.1.5. Возможные варианты
8 .1.6 . Связь с концепцией сетки данных
8.1.7. Сводка архитектуры GCP
8.2. Сетка данных на платформе AWS
8.2.1. Архитектура самообслуживаемой
платформы данных
8.2.2. Компоненты платформы
8.2.3. Компоненты продуктов данных
8.2.4. Рабочие процессы
8.2.5 . Связь с концепцией сетки данных
8.2.6. Возможные варианты
8.2.7. Сводка архитектуры AWS
8.3. Сетка данных на платформе Databricks
8.3.1. Архитектура самообслуживаемой
платформы данных
8.3.2. Компоненты платформы
8.3.3. Компоненты продуктов данных
8.3.4 . Соображения по поводу рабочих
процессов
8.3.5. Возможные варианты
8.3.6. Сводка архитектуры Databricks
8.4. Сетка данных на основе Kafka
8.4.1. Архитектура самообслуживаемой
платформы данных
8.4.2. Компоненты
8.4.3. Некоторые соображения
8.4.4. Сводка архитектуры Kafka
Итоги
Глава 9. Разработка архитектуры решения
9 .1. Как собирать информацию и оценивать
текущее состояние
9 .1.1. Что такое архитектура программного
обеспечения
9 .1.2. Как документировать архитектуру: модель
C4
9.2. От каких архитектурных факторов
зависит проектирование продукта.данных
9.2.1. Архитектурные факторы
9.2.2. Как выявить архитектурные факторы для
проектирования
продукта.данных
9.3 . Проектирование будущей архитектуры
продукта данных и связанных с ним систем
9.3 .1. Дизайн-сессия
9.3.2. Продукт данных на основе файлов:
электронная таблица
9.3.3 . От монолита и микросервиса к продукту
данных
9.3.4 . Как предоставлять данные для
потоковой
и пакетной обработки
Итоги
Приложение А
Приложение B
Приложение C
Приложение D
D .1. Тончайшие жизнеспособные платформы
D . 2. Постепенный вывод интерфейсов из
эксплуатации