Модуль 4. Описание требований к данным и архитектуре

Цель модуля

Научить участников структурированно и проверяемо описывать в ТЗ:

Источники данных (что именно забираем, как, с какой частотой, какими протоколами, в каких объёмах, кто владелец, какие риски).
Требования к загрузкам/обновлениям (batch/stream, CDC, SLA/Latency, ретраи, контроль целостности).
Историчность и версионирование (SCD1/2/3, bitemporal, time-travel, Delta/Iceberg).
Целевую архитектуру и слои (Staging/ODS/DWH/DM или Bronze/Silver/Gold, инструменты оркестрации, форматы хранения, движки вычислений).
Витрины данных, semantic layer и правила расчётов KPI.
Data Lineage и метаданные — откуда что берётся, как трансформируется, куда уходит и кто отвечает.
Чек-листы качества для всех вышеуказанных частей.

Вступление (контекст и позиционирование в структуре ТЗ)

В Модуле 3 мы зафиксировали полную структуру ТЗ. В этом модуле мы детализируем два её самых «тяжёлых» раздела:

«Требования к данным» — всё про источники, загрузки, историчность, качество, владельцев и правила.
«Требования к архитектуре» — целевая архитектура (слои, технологии, форматы, оркестрация), правила версионирования/хранения, точки интеграции, semantic layer и витрины.

Одна из главных ошибок ТЗ по данным — описать «что-то очень общее» и не зафиксировать проверяемые (измеримые, однозначно трактуемые) требования. Этот модуль — про то, как таких ошибок избежать.

Каталог источников данных (Data Sources Inventory)

Минимальный шаблон на каждый источник

Скопируйте шаблон и заполняйте на каждый источник, без исключений. Не допускайте общих фраз «данные из 1С» — какие именно объекты, таблицы, поля, версии API, кодировки и т. д.

Таблица 1. Шаблон описания источника

Поле	Что фиксируем	Пример
Название источника	Системное и «человеческое» имя	1С:УПП 8.3 (Prod), SAP ERP ECC 6.0, CRM Dynamics, Kafka topic crm.events
Тип подключения	JDBC/ODBC, REST/GraphQL, S3/HDFS/SFTP, CDC/лог-репликация	JDBC, REST v2, Debezium CDC, S3 (parquet), SFTP (csv)
Объекты/таблицы/эндпоинты	Конкретный перечень + краткий смысл	Sales, Orders, Customers (клиенты и их статусы)
Поля и ключи	Обязательные поля; бизнес-/тех. ключи	OrderId (PK), CustomerId (BK), LoadDttm
Периодичность загрузок	Batch/stream, расписание, триггеры	batch, 1 раз в сутки к 07:00 МСК; stream — задержка ≤ 5 мин
Механизм инкремента	По дате изменения, CDC, snapshot+merge	CDC (LSN), watermark по ModifiedAt
Историчность	SCD1/2/3, time-travel, bitemporal	SCD2 (по ключу CustomerId), ValidFrom/ValidTo
Объёмы	Стартовый объём, ежедневный прирост	800 млн строк стартово, +4 млн строк/сутки
V-реквизиты (VOLUME/VARIETY/VELOCITY)	При необходимости указать «3V»	Высокая скорость изменений (Velocity), умеренный прирост
Форматы, кодировки, TZ	CSV/Parquet/JSON/Avro; UTF-8/Windows-1251; TZ	Parquet, Snappy, UTC
Владелец (data owner/steward)	ФИО/роль/контакты	Ирина Иванова, Head of CRM, i.ivanova@corp.com
Регламенты/ограничения	Лицензии, ИБ, GDPR/152-ФЗ, SLA API	Лимит API 60 запросов/мин, GDPR, 152-ФЗ
Риски/комментарии	Широкие VARCHAR, нестабильное API	Возможны изменения схемы (schema drift)

Пример (фрагмент) для BI-проекта розничной сети

Источник: 1С:Управление торговлей 11.4 (Prod)

Подключение: JDBC (native), batch.
Объекты: Документ.РеализацияТоваровУслуг, Справочник.Номенклатура, Справочник.Контрагенты.
Поля и ключи: Документ.Номер, Документ.Дата, Контрагент.Код (BK), surrogate ключ будет создан в DWH.
Частота и SLA: ежедневный batch, «к 08:00 МСК витрины продаж в BI обновлены».
Инкремент: where ModifiedAt > :last_successful_load_at + контроль количества строк и хэш-сумм по ключевым полям.
Историчность: SCD2 для справочников (контрагенты, номенклатура); факты — по транзакциям (история хранится естественно).
Объёмы: старт — 150 млн строк (факты за 5 лет), +250 тыс./сут.
Владелец: Финансовая служба (бизнес), ИТ 1С-команда (технически).
Ограничения: возможны ночные регламентные операции, окно загрузки — 00:30–03:30 МСК (нельзя грузить в этот период).

Чек-лист качества описания источников

Указаны конкретные объекты/таблицы/эндпоинты.
Зафиксирован механизм инкремента (дата, LSN, CDC, snapshot+merge).
Есть оценка объёмов и приростов (для sizing’а и SLA).
Ясно, кто владелец/стeward и как с ним коммуницировать.
Описана историчность (или отсутствие таковой) и требования к SCD.
Учтены ограничения ИБ/юридические (152-ФЗ, GDPR, лицензионные лимиты API).
Прописаны риски (нестабильное API, schema drift, широкие varchars, timezone/locale баги и т. п.).

Требования к загрузкам и обновлению (Batch, Streaming, CDC)

Что должно быть в ТЗ

Режимы загрузки: batch/stream, ETL/ELT.
Частота и расписание: cron-выражения, окна, зависимости (Job B после успешного Job A).
SLA и Latency: «До 08:00 МСК данные доступны бизнес-пользователям. Максимальная задержка — 30 минут после завершения исходной системы».
Механизм инкремента:
- По дате/времени изменения: ModifiedAt > :last_load_ts.
- CDC: Debezium/GoldenGate/pglogical и др.
- Snapshot + Merge (idempotent upsert).
Контроль целостности и качества: сверки количеств, контроль сумм, хэширование, дубли, NULL-поля, reference integrity.
Ретраи, откаты, алерты: сколько попыток, куда логируем, как уведомляем, как возвращаемся на последнюю консистентную точку.
Разделение сред и миграции: dev/test/stage/prod, управление схемами (Liquibase/Flyway/dbt).
Номенклатура пайплайнов (имена, версионирование, owner, ответственные группы).

Пример формулировки SLA/Latency

«Все витрины блока Sales должны быть обновлены к 08:00 МСК ежедневно. При этом временной лаг между поступлением новых транзакций в OLTP и появлением их в витрине не должен превышать 2 часа. Для событийного канала crm.events задержка обработки не должна превышать 5 минут (P95). В случае превышения SLA формируется алерт в Slack-канал #data-alerts и письмо ответственному за домен продаж.»

Пример для CDC

«Для таблиц orders, order_lines, customers используется CDC (Debezium). Инкремент — по LSN. Изменения применяются в DWH (ODS слой) как UPSERT. Отсутствие пришедших за период delete-событий проверяется через контрольные суммы по ключам. Раз в сутки выполняется reconcile-процедура: сверка количества записей и контрольных сумм источника и ODS. В случае расхождения — принудительный snapshot + merge.»

Историчность и версионирование

Что важно зафиксировать

Какой тип историчности нужен:
- SCD1 — перезатираем значения;
- SCD2 — версия с ValidFrom/ValidTo;
- SCD3 — сохраняем только предыдущие значения;
- Bitemporal — одновременно бизнес-время и системное время;
- Time-travel (ACID-таблицы с версиями, Delta/Iceberg/Hudi).
Где хранится история: ODS/DWH/факт/витрины/семантический слой.
Как «вычисляется история»: инструмент/библиотека/SQL-паттерны, merge-логика.
Как тестируется и проверяется: unit-тесты трансформаций (dbt tests), reconcile-тесты.
Как документируется в lineage и каталоге данных.

Пример описания SCD2 (в ТЗ)

«Сущность Customers должна храниться с историчностью типа SCD2. Строка считается новой версией, если изменён набор полей: CustomerName, Status, Segment, City. Поля: ValidFrom, ValidTo, IsCurrent. Все версии должны быть доступны аналитикам через семантический слой; BI-представление по умолчанию возвращает только текущие версии (IsCurrent = true).»

Требования к архитектуре: слои, технологии, форматы, оркестрация

Минимум, который нужно описать

Слои и их назначение
- Staging/Bronze — «как есть», сырые данные, без очистки.
- ODS/Silver — нормализованные, очищенные, приведённые к общему формату.
- DWH/Gold — историзированные, согласованные, бизнес-модель.
- Data Marts/Semantic Layer — витрины под конкретные задачи BI/ML/оперативной аналитики.
- (При необходимости: MDM, DQ, Feature Store, Data Products по доменам).
Технологии хранения и вычислений
RDBMS (PostgreSQL/Greenplum/Vertica), Object Storage (S3/ADLS), форматы (Parquet/Delta/Iceberg/Hudi).
Вычислительные движки: Spark/Presto/Trino/ClickHouse/SQL DW/Databricks.
ACID-таблицы и версии: Delta Lake/Iceberg/Hudi.
Airflow/Prefect/Dagster/dbt/Modus ETL и др.
Политика версионирования пайплайнов, декларативные DAG’и, артефакты сборки.
Стек: Prometheus/Grafana/ELK/CloudWatch.
Что считаем метриками качества пайплайнов (время выполнения, лаги, количество ошибок, успешные/неуспешные задачи).
RPO/RTO, snapshots/checkpoints, multi-AZ/cluster, cold/warm backups.
Стратегии миграции данных между слоями/кластерами.
Оркестрация и CI/CD
Мониторинг и логирование
Надёжность и восстановление

Два архетипа архитектуры (для примеров и сопоставления)

(A) «Классический» DWH (Kimball/Inmon) + BI

OLTP → Staging (RDBMS) → ODS (нормализация) → DWH (история, консолидация) → DM/Semantic Layer → BI.
Оркестрация: Airflow.
DQ-процессы выполняются на ODS/DWH слоях.
Lineage: таблицы в DWH чётко мапятся к BI-витринам.

(B) Lakehouse (Bronze/Silver/Gold) + Trino/DBT + BI

Разделение storage (S3/ADLS) и compute (Spark/Trino).
ACID/версии, time-travel на Delta/Iceberg.
dbt как стандарт декларативной трансформации и тестирования.
BI подключается через semantic layer (dbt metrics / BI semantic model), без прямого доступа к Bronze/Silver.

Требования к качеству данных (DQ) в контексте архитектуры

Что фиксировать в ТЗ

Метрики качества: полнота, уникальность, непротиворечивость, точность, актуальность, согласованность справочников.
Где и как проверяются правила: на каком слое (Bronze/Silver/Gold/DM), какими инструментами (dbt tests, Great Expectations, встроенный DQ-модуль ETL-платформы).
Пороговые значения и реакции (SLO/SLA):
- Пример: доля пропусков по полю CustomerInn ≤ 1%.
- Дубли по CustomerId недопустимы; при обнаружении — ошибка критического уровня.
Каталог правил DQ (храним централизованно, версионируем).
Ответственные (владельцы правил, кто валидирует, кто инцидент-менеджер).
Витрины качества (DQ dashboards): как бизнес видит, что данные корректные.

Пример формулировки DQ-правил в ТЗ

«В таблице dm_sales поле Amount не может быть < 0. Допустимая доля NULL в поле CustomerId — не более 0,5%. В случае превышения порога правило должно поднять алерт в Slack-канал #data-quality и заблокировать публикацию витрины до исправления. Контроль выполняется ежедневно после завершения ETL-пайплайна sales_daily_load.»

Витрины, semantic layer и расчёт показателей

Что фиксировать по каждой витрине

Назначение и потребители (роли/департаменты).
Гранулярность (по строке чека, по заказу, по клиенту-дню и т. д.).
Ключи (естественные, суррогатные).
Состав полей и формулы расчёта KPI.
SLA обновления.
Связанные источники данных и lineage.
Версионирование правил (особенно KPI, премии, бонусы).
Ограничения по доступам (row-/column-level security).

Таблица 2. Шаблон описания витрины

Поле	Описание
Название витрины	dm_sales_daily
Назначение/потребители	Финансовая служба, коммерческий департамент
Гранулярность	По заказу в день
Ключи	OrderId, OrderDate, CustomerId
Поля и KPI	Revenue = Sum(Amount); GM = Revenue - COGS
Источники	ods_orders, ods_order_lines, ods_customers
SLA	До 08:00 МСК доступно в BI
Историчность	Факт исторический, snapshot_date
Ограничения	RLS по филиалам
Ответственные	Product Owner BI, Data Steward Sales

Пример формулы KPI

Gross Margin (GM) = Sum(Revenue) - Sum(COGS), где:

Revenue — из dm_sales_daily.Amount,
COGS — из dm_cost_of_goods_sold.Cost,
валюта — в рублях, на дату транзакции;
курсы валют — справочник mdm_fx_rates, метод пересчёта: по дате операции;
значения округляются до 2 знаков после запятой.

Data Lineage и метаданные

Что обязательно описать

Инструмент/формат описания lineage (встроенный каталог, OpenLineage/Marquez, Collibra, Atlan, DataHub и т. д.).
Глубину lineage: таблицы, поля, правила трансформации, пайплайны.
Как он поддерживается в актуальном состоянии: автоматическое построение (из ETL/dbt), ручные аннотации, ревью.
Как бизнес/аудит/ИБ удовлетворяют свои потребности (кто и как смотрит lineage, какие отчёты).
Согласованность терминов с глоссарием и semantic layer.

Мини-шаблон для фиксации lineage в ТЗ

Источники → Слои хранения → Модели/витрины → BI/ML/внешние выгрузки.
Для каждого шага указываем:
- объект(ы),
- правила трансформаций (по необходимости — ссылку на спецификацию),
- ответственных,
- тесты и проверки,
- SLA/Latency (если критично).

Диаграммы и нотации (как оформлять архитектурные разделы)

Рекомендуется определить обязательный набор диаграмм:

Архитектурная схема высокого уровня (C4: Context/Container) — где что живёт и как связано.
Data Flow Diagram (DFD) — как данные текут между слоями и системами.
Схема слоёв (Bronze/Silver/Gold / Staging/ODS/DWH/DM) — с указанием форматов, технологий, SLA.
Схема lineage для ключевых витрин — на уровне таблиц/полей.
BPMN/ArchiMate — если требуется согласование MDM/DQ процессов, роли, workflow.

Совет: приложите в ТЗ референс-нотацию (набор условных обозначений) и пример «как должно выглядеть», чтобы не спорить на этапе проектирования.

Антипаттерны (типовые ошибки в разделах данных и архитектуры)

«Подключимся напрямую BI к источникам, мы так быстрее запустим» — а потом начинаются проблемы с производительностью, историчностью и согласованностью.
Нет явного описания механизма инкремента — ETL делает «как привыкли», бизнес теряет веру в цифры.
Отсутствуют SLA/Latency и план ретраев/откатов — а потом «вчера не обновилось» и никто не понимает, что делать.
Нефиксированная историчность/SCD — каждая команда делает по-своему; в BI расчёты расходятся.
DQ «на словах» — нет метрик, нет порогов, нет алертов. Следствие — ухудшение доверия к данным.
Отсутствует lineage — невозможно понять, откуда взялся KPI, невозможно защищать цифры перед аудитом.
Смешение слоёв, отсутствуют чёткие границы — невозможно тиражировать решения и сопровождать архитектуру.
Semantic layer не описан — формулы KPI живут в голове одного разработчика BI.

Практическое задание

Исходные данные:
Каждый участник берёт свой проект (или предоставленный учебный кейс) и выполняет:

Каталог источников данных (минимум 3 источника) по шаблону из раздела 4.1.
Требования к загрузкам/обновлению для каждого источника:
- batch/stream, частота, SLA/Latency, механизм инкремента, контроль целостности, ретраи.
Архитектурная схема + описание слоёв (Staging/ODS/DWH/DM или Bronze/Silver/Gold) с указанием технологий и форматов.
Таблица витрин (минимум 2): назначение, гранулярность, ключи, поля/KPI, SLA, lineage, RLS/CLS (при необходимости).
Мини-lineage (текстом или диаграммой) от источника → слоя хранения → витрины.
Перечень DQ-правил (минимум 5), пороговые значения, алерты, владельцы.

Рубрика оценки (критерии с баллами)

Критерий	0 баллов	1 балл	2 балла	3 балла
Каталог источников	Нет или поверхностно	Описано 1–2 поля	Есть все ключевые поля, но без объёмов/инкремента	Полный шаблон + объёмы + риски + владельцы
Загрузки и SLA	Не описаны	Есть расписание, но без SLA и ретраев	SLA есть, но нет механики инкремента/контроля целостности	Полный набор: SLA, Latency, инкремент, контроль, ретраи
Историчность	Не указана	Указана только для 1 сущности	Указана, но без правил версионирования и тестов	Ясно описаны типы SCD, поля, тесты, доступ в BI
Архитектура и слои	Размыто	Есть текст без схем	Есть схема, но без технологий/форматов	Чёткая схема, технологии, форматы, оркестрация
Витрины и KPI	Не описаны	Только названия	Описаны поля и SLA	Есть все: поля, KPI (с формулами), SLA, lineage, RLS/CLS
DQ-правила	Нет	Есть, но без метрик и порогов	Есть метрики, нет алертов/ответственных	Полный набор: метрики, пороги, алерты, ответственные
Lineage	Нет	Кусочно/текстом	Есть по основным таблицам	Полный по ключевым цепочкам + инструмент/поддержка
Ясность и проверяемость	Формулировки невалидируемые	Частично измеримо	Большинство измеримо	Все требования измеримы и трассируемы

Как проверять и защищать раздел «данные и архитектура» в ТЗ

Peer-review: документ читает вторая команда/архитектор, который не участвовал в подготовке.
«Красная команда»: 30 минут атакующих вопросов («где SLA?», «как ретраи?», «у кого права?»).
Контроль на бизнес-язык: условный CFO/CMO должен понять, какие витрины и когда он увидит.
Трассируемость: каждый KPI/витрина/данные-источник должны ссылаться на цели/метрики из Модулей 1–2.
Автоматизируемость: можно ли по этому ТЗ написать код ETL/dbt-проекта без «дозваниваний» автору.

Что участник уносит после модуля

Готовый шаблон каталога источников данных.
Готовый шаблон описания витрин и KPI.
Структуру и шаблон SLA/Latency/инкрементов/ретраев.
Чек-лист по историчности и SCD.
Референс-архитектуру (DWH vs Lakehouse) и нотацию для диаграмм.
Рубрику оценки качества своей работы (для самопроверки и командной валидации).

← Предыдущая статья

Модуль 3. Структура технического задания: что включать и как формулировать

Следующая статья →

Модуль 5. Нефункциональные требования, интеграции, безопасность, мониторинг, эксплуатация, SLA/SLO, RPO/RTO