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

Введение

Почему одна организация находит нужные данные за минуты, а другая тратит недели? Разница — не в инструментах, а в архитектуре данных. Без продуманной архитектуры данные превращаются в хаотичный набор таблиц, файлов и пайплайнов, где каждый новый запрос требует «археологических раскопок». Архитектура данных — это фундамент, на котором строится вся программа Data Governance.

Что такое Data Architecture

Data Architecture (архитектура данных) — это область DMBOK2, отвечающая за проектирование целевой структуры данных организации. Архитектура определяет, как данные хранятся, интегрируются, перемещаются и используются для достижения бизнес-целей.

DAMA-DMBOK2 выделяет Data Architecture как одну из 11 ключевых областей Data Management. В иерархии она занимает второе место после Data Governance: именно архитектура переводит стратегические решения governance в конкретные технические стандарты.

TOGAF (The Open Group Architecture Framework) предлагает четырёхуровневую модель Enterprise Architecture, где Data Architecture — один из четырёх доменов:

Data Architecture (архитектура данных) связывает бизнес-потребности (Business Architecture) с технической реализацией (Technology Architecture) через определение моделей данных, стандартов интеграции и правил хранения.

Ключевые принципы архитектуры данных

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

1. Data as an Asset (данные как актив)

Актив данных (Data Asset) — набор данных, имеющий измеримую ценность для организации. Каждый актив имеет владельца, описание в каталоге, определённый жизненный цикл и метрики качества.

Принцип означает: данные — не побочный продукт систем, а стратегический ресурс, требующий управления наравне с финансовыми активами.

2. Single Source of Truth (единый источник правды)

Каждый бизнес-объект (клиент, продукт, транзакция) должен иметь одно авторитетное представление. Все потребители данных работают с одним Golden Record, а не с разрозненными копиями.

3. Minimal Redundancy (минимальная избыточность)

Дублирование данных создаёт расхождения, увеличивает стоимость хранения и усложняет governance. Архитектура должна минимизировать ненужное копирование, допуская его только в обоснованных случаях (кэширование, аналитические витрины).

4. Security by Design (безопасность по проектированию)

Требования безопасности и конфиденциальности закладываются на этапе проектирования, а не добавляются постфактум. Классификация данных определяет архитектурные решения: где хранить, как шифровать, кто имеет доступ.

5. Metadata-Driven (управление через метаданные)

Архитектура должна быть самоописывающейся. Каждый элемент (таблица, колонка, пайплайн) сопровождается метаданными: описание, владелец, классификация, lineage. Метаданные (Метаданные) — это данные о данных, обеспечивающие обнаружение, понимание и управление активами.

Архитектурные слои данных

Типичная архитектура данных организации состоит из нескольких слоёв, каждый из которых решает свою задачу:

Каждый слой имеет свои governance-требования: Source Layer требует контроля схемы, Staging — валидации, Integration — lineage-трекинга, Consumption — контроля доступа.

Сценарий: DataTech Solutions

Сценарий: DataTech Solutions (ДатаТех Солюшенз)

В DataTech архитектура данных сложилась стихийно:

• PostgreSQL (200+ таблиц) — основная БД без документированной схемы
• ClickHouse загружается через 45 Airflow DAG’ов — некоторые из них дублируют данные
• dbt-модели (120 штук) не имеют тестов и не документированы
• Metabase подключён напрямую к PostgreSQL и ClickHouse — непонятно, какой источник «правильный»

Data Engineer Алексей пытается добавить новый дашборд для отдела продаж. Он находит три разных таблицы с данными о клиентах: customers (PostgreSQL), stg_customers (ClickHouse), dim_customers (dbt-модель). Какая из них авторитетная — неизвестно. Числа во всех трёх расходятся.

Проблема DataTech — классический пример отсутствия архитектурных принципов. Нет Single Source of Truth для клиентских данных, нет чётких слоёв (Metabase читает из Source и Consumption одновременно), нет metadata-driven подхода (отсутствует каталог и документация).

Решение начинается с определения целевой архитектуры: какие данные откуда берутся, через какие слои проходят и где потребляются. Это задача Data Architect (архитектор данных) — специалиста, проектирующего целевую архитектуру и обеспечивающего техническое соответствие Data Strategy.

Итоги

• Data Architecture (архитектура данных) — область DMBOK2, определяющая как данные хранятся, интегрируются и используются
• Ключевые принципы: Data as an Asset, Single Source of Truth, Minimal Redundancy, Security by Design, Metadata-Driven
• Архитектура организована в слои: Source -> Staging -> Integration -> Consumption
• Каждый слой имеет свои governance-требования
• DataTech — пример организации без архитектуры: стихийные подключения, нет единого источника правды

В следующем уроке мы рассмотрим моделирование данных — ключевой инструмент Data Architect для формализации структуры данных на трёх уровнях: концептуальном, логическом и физическом.