Принципы архитектуры данных
Введение
Почему одна организация находит нужные данные за минуты, а другая тратит недели? Разница — не в инструментах, а в архитектуре данных. Без продуманной архитектуры данные превращаются в хаотичный набор таблиц, файлов и пайплайнов, где каждый новый запрос требует «археологических раскопок». Архитектура данных — это фундамент, на котором строится вся программа 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. Метаданные (Метаданные) — это данные о данных, обеспечивающие обнаружение, понимание и управление активами.
Архитектурные слои данных
Типичная архитектура данных организации состоит из нескольких слоёв, каждый из которых решает свою задачу:
| Слой | Назначение | Пример в DataTech |
|---|---|---|
| Source Layer | Исходные системы, генерирующие данные | PostgreSQL (200+ таблиц), MinIO (файлы) |
| Staging Layer | Сырые данные «как есть», без трансформаций | Airflow загружает raw-данные в ClickHouse |
| Integration Layer | Очистка, нормализация, обогащение | dbt-модели: staging -> intermediate -> marts |
| Consumption Layer | Готовые витрины для потребителей | Metabase дашборды, ML-модели, API |
Каждый слой имеет свои governance-требования: Source Layer требует контроля схемы, Staging — валидации, Integration — lineage-трекинга, Consumption — контроля доступа.
Table format evolution — Iceberg/Delta как фундамент Integration Layer Lakehouse architecture — реализация слоёв данных ClickHouse data modeling — Consumption Layer для OLAPСценарий: 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 для формализации структуры данных на трёх уровнях: концептуальном, логическом и физическом.