Создавайте гибкие модели данных. Чтобы добиться большей гибкости при исследовании данных или поддержке цифровых сценариев использования, создавайте модели данных с меньшим количеством физических таблиц (часто это называют "схемно-легким" подходом). Такой подход облегчает изучение данных, обеспечивает большую гибкость при хранении данных и снижает сложность за счет упрощения запросов к данным.
Создайте высокомодульную и эволюционную архитектуру данных, использующую лучшие компоненты, которые при необходимости можно заменить новыми технологиями, не затрагивая другие части архитектуры данных. Сосредоточьтесь на интерфейсах, основанных на конвейере данных и API, чтобы упростить интеграцию между разрозненными инструментами и платформами. Создайте платформу управления API (часто называемую шлюзом API) для создания и публикации API, ориентированных на данные, внедрения политик использования, контроля доступа, измерения использования и производительности. Аналитические верстаки, такие как Amazon SageMaker и Kubeflow, упрощают создание комплексных решений в высокомодульной архитектуре данных.
Создайте семантический слой данных, согласованный с доменами бизнес-данных, как единый источник истины для данных и управляйте им как основополагающим продуктом данных. Такой подход позволяет повысить качество и надежность данных для всеобщего блага. Графовые базы данных идеально подходят для этой цели, в частности для цифровых приложений, требующих огромной масштабируемости и в реальном времени, а также для слоев данных, обслуживающих приложения искусственного интеллекта. Графовые базы данных позволяют мощно и гибко моделировать взаимосвязи внутри данных.
Примечания
Свен Блюмберг, Хорхе Мачадо, Хеннинг Соллер и Асин Таваколи, "Выход из тупика архитектуры данных для масштабирования ИИ", McKinsey
.com, 26 января 2021 г., https://www.mckinsey.com/capabilities/ mckinsey-digital/our-insights/breaking-through-data-architecture- gridlock-to-scale-ai; Antonio Castro, Jorge Machado, Matthias Roggendorf, and Henning Soller, "How to build a data architecture to drive innovation - today and tomorrow", McKinsey.com, June 3, 2020, https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ how-to-build-a-data-architecture-to-drive-innovation-today-and- tomorrow.
ACID обозначает свойства транзакций: атомарность, согласованность, изолированность и долговечность. Транзакции ACID обеспечивают наивысшую возможную надежность и целостность данных, гарантируя, что данные никогда не перейдут в противоречивое состояние из-за операции, которая завершилась лишь частично.
Глава 27. Сделайте сайт
, чтобы получить максимальную отдачу от данных.
Операционная модель данных - это общий подход к тому, как организация должна управлять данными. Она состоит из четырех основных компонентов: организация, таланты и культура, инструментарий и DataOps, а также управление и риски (см. Рисунок 27.1).
Некоторые компании опасаются, что создание таких возможностей может показаться развитием еще одной бюрократии или, возможно, актуально только для крупных банков. Но, по нашему опыту, правильная организация управления данными и операционной модели имеет решающее значение для превращения в предприятие, интенсивно использующее данные. Легко пренебречь наличием сильной операционной модели.
Если вы имеете дело с одним или двумя случаями использования данных, то часто можно обойтись без модели. Но получить отдачу от сотен, а то и тысяч вариантов использования данных просто невозможно без эффективной и хорошо организованной операционной модели. Добившись ясности в этих областях, компании смогут избежать конфликтов, путаницы и задержек, которые обычно мешают работе с данными.1
Компоненты эффективной модели работы с данными
Организация
Степень централизации
Структура руководства
1 2 Роли и карьерные пути
Талант и
культура, основанная на данных
Повышение квалификации (Академия данных)
Процессы управления
Управление и риски
Стандарты политики
4 3 Автоматизация процессов и расширение возможностей
DataOps
Передачи и точки интеграции
Организация
