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

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

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

Моделирование данных, при котором рисуются диаграммы структур данных, бизнес-правил и связей между элементами данных, тесно связано с архитектурой данных. Однако существуют два разных подхода к управлению данными. По словам руководителя компании Knowledge Integrity Inc. генеральный директор Дэвид Лошин, моделирование данных фокусируется на отдельных активах данных, в то время как архитектура данных рассматривается с высоты 30 000 футов.

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

Как развивались структуры данных?

Раньше архитектуры данных были намного проще, чем сегодня. Большая часть информации представляла собой реляционную базу данных, в которой хранились структурированные данные из tps. Для интеграции данных использовались традиционные методы извлечения, преобразования и загрузки (ETL), а данные транзакций обрабатывались для анализа в пакетных задачах. Аналитическая инфраструктура включала:

• Центральное хранилище данных.
• Оперативное хранилище данных для данных в процессе работы.

Дополнительные карты данных, предназначенные для конкретных отделов

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

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

Принципы архитектуры данных

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

Вводимые данные должны быть проверены

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

Всегда стремитесь к единообразию

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

Необходимость тщательного документирования

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

Не следует перемещать или дублировать данные

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

Неадекватный доступ к данным не может служить пользователям

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

Крайне важно иметь надлежащие средства безопасности и контроля доступа

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

Роль cтандартов данных

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

Схемы данных

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

Разработка структуры данных может помочь вам соответствовать этим нормам. В схеме данных мы указываем следующее:

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

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

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

Действительно, именно поэтому версионность так важна. Нумерация версий схемы данных – это инструмент стандартизации, потому что:

• Где что находится?
• Возможность запросить, где и когда была найдена та или иная часть данных.

Защита персональной информации

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

Ниже приведены примеры протоколов безопасности

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

Переход на новую архитектуру

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

Вот краткая версия этих 6 изменений:

1. Переход между локальными и облачными системами данных
2. Переход от пакетной обработки данных к обработке в режиме реального времени
3. От готовых бизнес-решений к масштабируемым, настраиваемым структурам
4. От прямой связи к независимому получению данных
5. Изменения в архитектуре: от хранилища данных к хранилищу на основе доменов
6. Переход от негибких моделей данных к масштабируемым структурам данных

Рассматривайте архитектуру данных, когда вы думаете обо всем, что связанно с данными.

Как бы вы определили черты и элементы, составляющие архитектуру данных?

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

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

В дополнение к этим характеристикам, хорошо продуманные структуры данных также обладают следующими характеристиками:

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

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

Ниже приведены несколько примеров таких частей (или артефактов):

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

Какая опасность от неправильного проектирования архитектуры данных?

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

Еще одним препятствием является достижение консенсуса по определенным определениям, форматам и стандартам данных. Без этого трудно разработать хорошую архитектуру данных. То же самое касается применения бизнес-логики к данным. Айкен сказал на вебинаре Dataversity, что эффективная архитектура данных “фиксирует бизнес-план данных, необходимых для управления предприятием”. Однако если этот шаг пропустить, между архитектурой и стратегическими потребностями в данных, может образоваться пропасть.