Глоссарий

Централизованное хранилище данных для аналитики и отчётности. Содержит данные из множества источников (АБС, CRM, процессинг), организованные по слоям (staging→ODS→mart). В банках: 100-5000 таблиц, 10TB-500TB данных.

Платформа для поиска, документирования и управления метаданными DWH: таблицы, lineage, DQ-метрики, владельцы. Инструменты: DataHub, Amundsen, Apache Atlas, Collibra.

Реестр всех таблиц и полей DWH: имя, тип, описание, источник, владелец, SLA, пример значения. Без data dictionary: онбординг = 2 недели. С ним: 3 дня.

Полный путь каждого поля от источника до отчёта, включая все трансформации. Без lineage: расследование расхождения = 3-5 дней. С lineage: 30 минут. Инструменты: DataHub, dbt lineage, Atlas, ручной Excel.

Методология моделирования: Hub (бизнес-ключ), Link (связь), Satellite (атрибуты + история). Преимущества: полная историчность, параллельная загрузка, audit trail. Недостаток: сложные запросы к витринам, кривая обучения.

Подход к проектированию DWH: dimensional modeling (star schema), bottom-up (начинать с витрин). Преимущества: простые запросы, быстрая разработка. Используется для аналитических витрин.

Агрегированные данные для конкретного потребителя: финансы, риски, BI, ЦБ. Star schema, оптимизирована для чтения. Обычно 10-50 витрин в банке. Каждая — отдельный SQL с бизнес-логикой.

Второй слой: очищенные, типизированные, дедуплицированные данные в 3NF. Единая модель для всех источников. Содержит историю (SCD Type 2). Основа для построения витрин и отчётности.

Разбиение большой таблицы на физические части (обычно по дате: monthly/daily). 500M строк без партиций = full scan на каждый запрос. С партициями: сканируется только нужный период. Эффект: 10-50x.

Методы хранения исторических изменений: Type 1 (перезапись, без истории), Type 2 (новая строка + effective_from/to, полная история), Type 3 (доп. колонка prev_value), Type 6 (гибрид). В банках обычно Type 2 для клиентов и Type 1 для справочников.

Первый слой DWH: данные «как есть» из источников без трансформаций. Цель — изоляция источника и возможность перезагрузки. Обычно хранится 30-90 дней. Все поля — varchar, без бизнес-логики.

В MPP-системах (Greenplum, Redshift): определяет, как строки распределяются по нодам. Неоптимальный ключ = data skew = 1 нод загружен на 100%, остальные простаивают. Выбор: по PK или по FK для JOIN.

Мёртвые строки после UPDATE/DELETE в PostgreSQL. Autovacuum не успевает → таблица в 2-3 раза больше, чем нужно. Диагностика: pg_stat_user_tables.n_dead_tup. Лечение: VACUUM FULL (downtime).

Единые правила именования объектов DWH: таблицы (stg_, ods_, mart_), поля (snake_case), индексы (idx_), views (vw_). Без стандарта: 3 стиля в одном слое, невозможно найти таблицу.

Модель данных Kimball: центральная fact-таблица (транзакции, события) окружена dimension-таблицами (клиент, продукт, дата, филиал). Простые JOIN, понятная бизнесу. Основа mart-слоя.

Платформа оркестрации ETL: DAG (Python) определяет зависимости, scheduler запускает по расписанию, UI показывает статус. Альтернативы: Prefect, Dagster, Luigi, cron.

Захват изменений в source-системе в реальном времени: INSERT/UPDATE/DELETE → stream. Инструменты: Debezium (PostgreSQL WAL), Oracle GoldenGate, Kafka Connect. Для near-real-time DWH.

Автоматический цикл: push code → lint (sqlfluff) → test (dbt test) → deploy. Без CI/CD: ручной copy-paste через pgAdmin → ошибки в production. С CI/CD: откат за 5 минут.

Граф зависимостей ETL-задач: загрузка → очистка → агрегация → витрина. Управляется Airflow, Luigi, cron. Проблемы: circular dependencies, отсутствие алертов, retry без idempotency.

Современная альтернатива ETL: сырые данные загружаются в DWH «как есть», трансформации выполняются внутри хранилища (SQL/dbt). Преимущество: переиспользование вычислительных мощностей DWH, version control SQL.

Классический процесс: данные извлекаются из источника, трансформируются (очистка, агрегация, обогащение) снаружи DWH, загружаются в хранилище. Инструменты: Informatica, Talend, Apache NiFi, SSIS.

Свойство ETL: повторный запуск даёт тот же результат. TRUNCATE + INSERT = идемпотентно. INSERT без проверки = дубликаты при retry. Критично для надёжных пайплайнов.

Линтер и форматтер SQL. Проверяет стиль (naming, aliasing, whitespace), находит антипаттерны (SELECT *, implicit JOIN). Интегрируется в CI/CD. Аналог ESLint для SQL.

Время с момента последнего обновления витрины. SLA: T+1 (обновляется на следующий день), T+0 (в тот же день), near-real-time (<1 час). dbt source freshness проверяет автоматически.

Загрузка только новых/изменённых данных (vs full load). Методы: по timestamp (updated_at), по CDC (Change Data Capture), по watermark. В dbt: is_incremental() + merge.

TRUNCATE + INSERT всех данных из источника при каждом запуске. Простой, идемпотентный, но медленный для больших таблиц. Подходит для справочников (<1M строк). Для фактов — incremental.

Оперативная система, из которой данные поступают в DWH: АБС (Diasoft, Colvir), CRM, процессинг карт, казначейство, HR. Банк может иметь 5-20 источников.

Качество данных — 6 измерений: Completeness (полнота), Accuracy (точность), Consistency (согласованность), Timeliness (актуальность), Uniqueness (уникальность), Validity (допустимость). Низкое DQ = недоверие бизнеса.

Автоматическая проверка качества: not_null (поле заполнено), unique (нет дублей), accepted_values (значение из списка), relationships (FK exists), custom SQL (бизнес-правило). 5 правил на таблицу = минимум.

Обнаруженная проблема. Структура: описание + severity (Critical/High/Medium/Low) + SQL-доказательство + impact (₽ или риск) + рекомендация + effort. Типичный аудит: 30-100 findings.

Python-фреймворк для DQ: expectations (правила), validation (проверки), profiling (авто-анализ). 300+ встроенных правил. Интегрируется с Airflow, dbt, Spark. Альтернативы: Soda, dbt tests, Monte Carlo.

Улучшение с минимальными затратами (0-2 нед., 0 бюджет) и заметным эффектом. Примеры: NOT NULL constraints, удалить SELECT *, индексы на top-10 slow queries, включить pgaudit, freshness alert.

Систематическая проверка согласованности между слоями/системами: source↔staging (полнота загрузки), staging↔ODS (трансформации), ODS↔mart (агрегации), mart↔report (фильтры). Каждая пара — отдельная сверка.

Фреймворк для SQL-трансформаций: models (SELECT), tests (not_null, unique, accepted_values, relationships), docs (автогенерация), lineage (граф зависимостей). Стандарт де-факто для ELT. Бесплатный (Core) или платный (Cloud).

Автоматическое выявление нетипичных значений: резкий рост/падение метрики, выбросы, изменение распределения. Методы: Z-score, IQR, ML (Isolation Forest). Для мониторинга DQ в production.

Уровни зрелости DQ: Level 1 (нет проверок), Level 2 (ручные проверки), Level 3 (автоматические тесты), Level 4 (DQ-дашборд + алерты), Level 5 (AI anomaly detection). Большинство банков: Level 1-2.

Статистический анализ данных: NULL%, дубли, min/max/avg, распределения, outliers, паттерны. Первый шаг любого DQ-аудита. Инструменты: Great Expectations, ydata-profiling, SQL.

Сумма под риском на момент дефолта. Для срочных кредитов ≈ остаток долга. Для кредитных линий: outstanding + CCF × (limit - outstanding). CCF = Credit Conversion Factor.

Ожидаемые кредитные убытки = PD × LGD × EAD для каждого инструмента. Stage 1: 12-мес. ECL. Stage 2/3: lifetime ECL. В банке: миллиарды ₽ резервов. Ошибка в ECL = материальное искажение отчётности.

Трансфертное ценообразование: внутренняя стоимость фондирования для каждого бизнес-подразделения. Методы: matched maturity (по сроку), pool rate (средневзвешенная), hybrid. Ошибка → искажение маржи.

Стандарт учёта финансовых инструментов. Три блока: классификация и оценка (amortized cost / FVOCI / FVTPL), обесценение (ECL), хеджирование. Заменил IAS 39 в 2018. Ключевое изменение: expected loss вместо incurred loss.

Доля потерь при дефолте = 1 - Recovery Rate. Зависит от обеспечения, типа кредита, юрисдикции. Ипотека: 20-30%. Необеспеченные потребы: 60-80%. Корпораты: 40-60%.

Вероятность дефолта заёмщика. Through-the-cycle (средняя за цикл) или point-in-time (текущая с учётом макро). Калибруется на исторических данных (5+ лет). Диапазон: 0.01% (AAA) — 30%+ (near-default).

Stage 1: performing, 12-мес. ECL. Stage 2: SICR (Significant Increase in Credit Risk), lifetime ECL, interest на gross. Stage 3: credit-impaired, lifetime ECL, interest на net. Критерии стейджинга — основной предмет аудита.

Проверка модели на исторических данных: PD, которые были предсказаны год назад → совпали ли с фактическими дефолтами? Обязательное требование ЦБ и IFRS 9 для валидации моделей.

Подготовка групповой отчётности: сведение балансов дочерних компаний, элиминация внутригрупповых оборотов (ВГО), дивидендов, инвестиций. IFRS 10. В банковских группах: 5-20 дочерних компаний.

Национальные стандарты. Отличия от МСФО: историческая стоимость (vs fair value), РВПС вместо ECL, другие правила амортизации. Банки ведут оба учёта параллельно, трансформация РСБУ→МСФО: 30+ корректировок.

Цена выхода (exit price) в упорядоченной сделке. Уровни: Level 1 (биржевые котировки, наблюдаемые), Level 2 (аналогичные инструменты), Level 3 (модельная оценка, ненаблюдаемые inputs). IFRS 13.

Процесс перевода бухгалтерских данных из РСБУ в МСФО: корректировки на fair value, ECL, амортизацию, лизинг (IFRS 16), консолидацию. Обычно 30-50 трансформационных проводок.

Требования к обработке ПДн: определить перечень, обеспечить маскировку, вести журнал доступа, уведомить Роскомнадзор, назначить ответственного. Штраф с 2024: до 18M ₽.

Противодействие отмыванию (115-ФЗ): KYC (идентификация клиента), транзакционный мониторинг (пороги, сценарии), sanctions screening, SAR. DWH-витрины AML = часть регуляторного контура.

Процедура идентификации клиента: ФИО, документ, адрес, бенефициарный владелец, PEP-статус. Данные хранятся в DWH для AML-мониторинга и reporting.

XML-формат электронной отчётности для ЦБ РФ. Таксономия (схема элементов) + instance (данные). Маппинг SQL→XBRL — отдельная задача, требующая знания таксономии ЦБ.

Совокупность мер по обеспечению соответствия требованиям регуляторов: ЦБ, Роскомнадзор, PCI DSS. В контексте DWH: RBAC, маскировка PII, audit trail, retention policy.

Документ ЦБ, определяющий правила заполнения форм: Указания, Положения, Инструкции. Пример: Положение 579-П (план счетов), Указание 4927-У (формы отчётности). SQL в DWH должен соответствовать НПА.

Резервы по РСБУ (Положение 590-П): категории качества I-V (от 0% до 100%). Отличаются от ECL по IFRS 9: другие модели, другие параметры. Сверка РВПС vs ECL — предмет аудита.

Основная форма ЦБ: баланс банка по счетам 2-го порядка. Ежемесячная. 20+ строк × 12 столбцов = 240+ ячеек. Каждая ячейка = SQL-запрос из DWH. Расхождение с GL = замечание ЦБ.

Отчёт о финансовых результатах для ЦБ. Доходы, расходы, прибыль по символам. Ежеквартальная. Должна совпадать с управленческим ОПУ и МСФО ОПУ (с точностью до корректировок).

Расчёт резервов по кредитам (РВПС) для ЦБ. По категориям качества (I-V). Должна быть согласована с ECL по IFRS 9 (но методики разные — РВПС vs ECL).

Количество людей, уход которых парализует проект. Bus factor=1 = критический риск: один человек знает весь код. Решение: документация, code review, менторинг, парное программирование.

План восстановления после катастрофы: RPO (сколько данных потеряем), RTO (за сколько восстановимся). Тест DR: restore backup на standby-сервер, замерить RPO/RTO. Проводить: ежеквартально.

Персональные данные по 152-ФЗ: ФИО, паспорт, СНИЛС, ИНН, телефон, email, адрес, дата рождения, номер счёта, номер карты. Должны быть замаскированы в непроизводственных средах.

Управление доступом через роли: analyst (SELECT mart), developer (SELECT/INSERT staging+mart), admin (ALL). Проверяем: orphaned accounts, excessive privileges, role inheritance, row-level security.

RPO: максимально допустимая потеря данных (в часах). RTO: максимально допустимое время восстановления. Для DWH банка: RPO=4ч, RTO=8ч (типичное). Определяется SLA с бизнесом.

Ограничение видимости строк по роли: аналитик филиала видит только свой филиал. В PostgreSQL: CREATE POLICY. Альтернатива: отдельные view для каждого подразделения.

Логирование всех действий с данными: кто, когда, что сделал (SELECT/INSERT/UPDATE/DELETE). В PostgreSQL: pgaudit. Обязательно для compliance. Хранение: минимум 3 года.

Методы скрытия PII: hashing (SHA-256, необратимый), tokenization (замена на token, обратимый), masking (**** вместо цифр), encryption (AES, с ключом), anonymization (удаление связи с субъектом).

Распределение общих затрат (IT, HR, аренда) на бизнес-подразделения по драйверам: headcount, площадь, транзакции. 20-50 правил аллокации. Ошибка → искажение cost/income по сегментам.

Ключевой KPI банка: операционные расходы / операционные доходы. Benchmark: 40-60%. Рассчитывается из управленческого ОПУ. Зависит от корректности аллокаций и FTP.

Сравнение бюджетных показателей с фактическими: отклонения, причины, тренды. В DWH: две витрины (budget_mart + fact_mart) с общим grain для корректного сравнения.

Разбиение портфеля/клиентов на сегменты: розница, МСБ, корпораты, VIP. Правила: по размеру выручки, по типу продукта, по отрасли. Один клиент = один сегмент (нет пересечений).

Отчёт о доходах и расходах по управленческим статьям: чистый процентный доход, комиссии, операционные расходы, резервы. Детализация по продуктам/сегментам/филиалам.

Баланс для внутреннего управления: может отличаться от РСБУ (другая классификация, другие группировки). Должен быть reconcileable с формой 101 ЦБ и МСФО балансом.

Чистая процентная маржа: (процентные доходы - процентные расходы) / средние активы. Benchmark: 3-5%. Зависит от FTP и ставок. Один из ключевых показателей для ЦБ и инвесторов.

Ключевой показатель эффективности. В банке: NIM, CIR, ROE, NPL ratio, Coverage ratio, LDR. Каждый KPI = формула + источник данных + периодичность + ответственный. Верификация KPI — модуль L5.

Многомерный анализ данных: dimensions (измерения), measures (показатели), hierarchies. Операции: slice, dice, drill-down, roll-up, pivot. Реализация: MOLAP (куб), ROLAP (SQL), HOLAP (гибрид).

Интерактивная визуализация данных: чарты, таблицы, фильтры, drill-down. Платформы: Superset, PowerBI, Tableau, QlikSense, Metabase. В банке: 30-150 дашбордов для разных подразделений.

Переход от агрегированного показателя к детализации: Банк → Филиал → Менеджер → Клиент → Сделка. Требует правильной иерархии в dimensional model.

Предвычисленная таблица с результатом тяжёлого запроса. REFRESH CONCURRENTLY — обновление без блокировки. Эффект: запрос из 45с → 0.5с. Используется для агрегаций в BI.

SQL-запрос или таблица, на которой строится дашборд. Один dataset может питать несколько чартов. Проблемы: SELECT *, отсутствие индексов, CROSS JOIN, nested subqueries.

Бизнес-пользователи сами создают отчёты/дашборды без помощи IT. Требует: semantic layer (единые определения), обученных пользователей, sandbox для экспериментов. Цель: 60%+ запросов без IT.

Слой бизнес-определений поверх DWH: метрики (revenue = SUM(amount) WHERE type='income'), dimensions (product, region, time). Единый источник истины для всех дашбордов. Инструменты: dbt metrics, Cube.js, LookML.

Open-source платформа для data catalog: метаданные, lineage, DQ-метрики, ownership, tags. Альтернативы: Amundsen (LinkedIn), Apache Atlas (Hadoop), Collibra (enterprise). Интеграция с dbt, Airflow.

Платформа визуализации метрик и алертинга. Для DWH: мониторинг ETL (freshness, row counts), DQ-дашборд, performance (query times). Интеграция: PostgreSQL, Prometheus, InfluxDB.

MPP (Massively Parallel Processing) СУБД на базе PostgreSQL. Распределённая: данные по нодам, параллельное выполнение. Используется для DWH банков в РФ (альтернатива Oracle, Teradata). 10-100TB.

Платформа потоковой передачи данных. Для DWH: CDC (Change Data Capture), near-real-time загрузка, event streaming. Kafka Connect: коннекторы к источникам без кода.

Открытая реляционная СУБД. Основа Greenplum. Для DWH: partitioning, parallel query, BRIN/GiST индексы, pg_stat_statements. Extensions: TimescaleDB, Citus, PostGIS.

Open-source BI-платформа: дашборды, чарты, SQL Lab, alerts. Альтернатива Tableau/PowerBI. В РФ банках — набирает популярность как замена Oracle BI.

Extension PostgreSQL для мониторинга запросов: total_time, calls, rows, shared_blks_hit/read. ТОП-20 slow queries — первый шаг оптимизации. Сброс: pg_stat_statements_reset().

Extension для PostgreSQL: логирование SQL-запросов в audit log. Настройка: по ролям, по типам операций (READ/WRITE/DDL). Обязательно для compliance (152-ФЗ, ЦБ). Без pgaudit — нет audit trail.