DWH Audit Full Spec

Requirements

Must Have

• Провести аудит модели данных DDS и структуры DM слоя

• Проанализировать подходы к партиционированию, хранению, индексированию в Greenplum

• Провести аудит ETL/ELT процессов: gpfdist, pxf, SQL-скрипты, оркестрация

• Проверить реализацию best practices по DWH-архитектуре

• Аудит BI-интеграции (Qlik Sense, Mail&Deploy) с DWH

Should Have

• Анализ возможностей интеграции Kafka → Greenplum и Kafka → Hadoop → Greenplum

• Оценка стратегии хранения и доступности данных в Hadoop

• Сравнение способов построения ODS слоя (Greenplum vs Hadoop)

• Валидировать архитектурную схему интеграции с другими системами

Could Have

• Разработка рекомендаций по реорганизации таблиц, витрин и SQL-объектов

Won’t Have

• Полная реализация или миграция архитектуры в рамках аудита

Method

Архитектура хранилища данных (DWH)

Аудит охватывает текущую архитектуру хранилища данных, реализованного на Greenplum, с разделением на следующие логические слои:

• STG (Staging) — временное хранение данных, поступающих из источников.

• ODS (Operational Data Store) — слой для хранения актуальных данных.

• DDS (Detailed Data Store) — слой, оптимизированный под анализ.

• DM (Data Marts) — витрины данных, рассчитанные на конечных потребителей и BI-системы.

Анализ архитектуры включает:

• Проверку обоснованности разделения по слоям

• Аудит объема и назначения объектов DDS и DM

• Идентификацию дублирующей или избыточной логики между слоями

• Оценку соответствия концепции Layered Architecture в DWH

Анализ партиционирования и физического хранения

Особое внимание уделяется производительности и структурам хранения:

• Аудит стратегий партиционирования: по датам, по сущностям, смешанные подходы

• Наличие и типы индексов: bitmap, btree и пр.

• Использование сжатия и storage parameters в Greenplum

• Степень нормализации/денормализации в разных слоях

KPI:

• Кол-во партиционированных таблиц

• Эффективность запросов к витринам (Qlik)

• Распределение данных между сегментами Greenplum

ETL/ELT процессы

Аудит охватывает все этапы загрузки и трансформации данных в DWH, включая:

• Инструменты: Informatica PowerCenter 9.5 (legacy), SQL-скрипты, gpfdist, PXF

• Оркестрация: предположительно через встроенные механизмы (Informatica Scheduler, Bash, Airflow)

Фокус аудита:

• Анализ структуры и сложности ETL-джобов (DAG, вложенность, повторное использование)

• Оптимальность SQL-скриптов: многотабличные джойны, агрегаты, использование CTE/аналитических функций

• Использование gpfdist и PXF для загрузки внешних данных

• Идентификация узких мест в производительности (long-running jobs, high I/O, full scans)

KPI:

• Кол-во ETL-джобов

• Из них: % сложных (nested, >3 зависимостей)

• Кол-во SQL-скриптов и % с ручной поддержкой

• Среднее время выполнения критичных пайплайнов

BI-интеграция

Проверяется архитектура подключения BI-систем (Qlik Sense, Mail&Deploy) к витринам DM:

• Сценарии чтения: прямой SQL-доступ, промежуточные выгрузки, кэш

• Частота и объем выборок из DWH

• Конкуренция ресурсов между BI и ETL

Проверяется соответствие best practices:

• Разделение BI- и ETL-нагрузки по временным окнам

• Использование агрегированных витрин для BI

• Минимизация прямых джойнов с DDS

Интеграция с Hadoop и Kafka

Инфраструктура предполагает расширение DWH за счет Hadoop-кластера (Hive, HDFS) и стриминговой интеграции через Kafka.

Рассматриваются следующие сценарии:

• Потоки данных из Kafka напрямую в Greenplum

• Буферизация в Hadoop (HDFS, Hive) с последующим импортом в Greenplum

• Размещение ODS слоя на Hadoop

Анализ включает:

• Валидность схемы интеграции (latency, batch vs streaming)

• Возможность использования внешних таблиц через PXF

• Обоснованность выбора Hadoop как ODS (vs Greenplum)

KPI:

• Средняя задержка (latency) данных по каждому пути

• Кол-во raw-таблиц в Hadoop

• Статистика по Kafka: топики, объем, партиции

• Оценка загрузки Greenplum по стриминг-потокам

Аудит-матрица (объекты и критерии)

Компонент	Проверка	Метрика
DDS / DM	Обоснованность модели, уровень агрегации, связность	Кол-во таблиц, кол-во витрин, % дублирования
Таблицы	Партиционирование, индексы, параметры хранения	% таблиц с партиционированием, эффективность сканов
SQL-скрипты	Читаемость, повторное использование, производительность	% CTE/подзапросов, оценка времени выполнения
ETL-пайплайны	Кол-во шагов, сложность, глубина DAG	% сложных пайплайнов, время исполнения
BI-каналы	Сценарии подключения, нагрузка на DWH	Частота обновлений, среднее время выборки
Kafka / Hadoop	Сценарии интеграции, надежность, latency	Кол-во топиков, задержка, объем данных

Implementation

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

Этап 1: Сбор и структурирование информации

• Получение схем DDL всех слоев (STG, ODS, DDS, DM) из Greenplum

• Получение метаданных ETL-процессов из Informatica (workflows, mapping)

• Сбор SQL-скриптов (вручную поддерживаемых)

• Инвентаризация BI-витрин (Qlik Sense, Mail&Deploy)

Этап 2: Аудит DWH и модели данных

• Анализ DDS/DM: агрегации, денормализация, связность

• Проверка партиционирования, индексов, storage-параметров

• Определение узких мест (CPU, I/O, сканы)

• Сравнение архитектуры с best practices (Kimball, Data Vault, hybrid)

Этап 3: Аудит ETL/ELT процессов

• Классификация ETL-джобов по сложности

• Анализ использования gpfdist, PXF

• Оценка повторного использования SQL/логики

• Идентификация узких мест и дублирования

Этап 4: Анализ BI-слоя

• Определение шаблонов доступа (прямой SQL, выгрузки)

• Выявление высоконагруженных BI-запросов

• Рекомендации по оптимизации витрин и разграничению нагрузки

Этап 5: Интеграция с Hadoop / Kafka

• Проверка потоков данных Kafka → Greenplum / Hadoop

• Оценка latency, надёжности, мониторинга

• Рекомендации по архитектуре ODS и стейджинга

Этап 6: Финальный отчёт и рекомендации

• Матрица соответствия best practices

• Перечень архитектурных узких мест и зон риска

• Рекомендации по реорганизации: ETL, BI, хранение, интеграция

• Отчёт по KPI и чеклист аудита

Milestones

Квартал	Цель и основные задачи
Q1	Подготовка к аудиту: получение доступа, сбор DDL, SQL-скриптов и ETL-метаданных. Первичный анализ DDS и DM. Выделение ключевых объектов анализа.
Q2	Аудит модели данных и физического хранения: партиционирование, индексы, стратегия хранения. Идентификация узких мест в DDS/DM.
Q3	Аудит ETL/ELT процессов: оркестрация, SQL-логика, использование gpfdist/pxf. Подготовка диаграмм потоков и оценки сложности пайплайнов.
Q4	Анализ BI-интеграции и источников нагрузки. Оценка SLA-нарушений, дублирующих запросов и неэффективных витрин.
Q5	Аудит архитектуры интеграции с Kafka и Hadoop. Сравнение схем стриминга, latency и загрузки. Рекомендации по архитектуре ODS.
Q6	Финализация аудита: формирование отчета, матрицы рисков, KPI и рекомендаций. Поддержка при внедрении предложений.

Gathering Results

Успешность аудита определяется полнотой охвата, качеством выводов и применимостью рекомендаций. Метрики оценки делятся на количественные и качественные.

Количественные метрики (KPI)

• Количество проанализированных объектов (таблиц, витрин, ETL-джобов, SQL-скриптов)

• Количество выявленных архитектурных узких мест

• Время выполнения ключевых ETL/BI-запросов (до/после)

• Количество рекомендаций, принятых в реализацию

Качественные метрики

• Соответствие архитектуры best practices (Kimball, ELT/DWH patterns)

• Выявление дублирующей логики и технического долга

• Рекоммендации по улучшению читаемости и переиспользуемости ETL-логики

• Снижение нагрузки на Greenplum в пиковые часы

Методы сбора результатов

• Финальный аудит-отчёт с анализом каждого слоя и компонента

• Оценка со стороны архитектурного совета (или техлида)

• Обратная связь от команд эксплуатации и BI

Инструменты сопровождения

• Confluence-документация с гиперссылками на артефакты

• Jira для трекинга рекомендаций и задач по доработке

• Таблицы сравнения “было–стало” по ключевым метрикам

Assumptions

Для эффективного и своевременного проведения архитектурного аудита делаются следующие допущения:

1. Доступ к артефактам
   Команда аудита получает полный доступ к необходимым объектам:

   • DDL всех слоёв Greenplum (STG, ODS, DDS, DM)

   • ETL-метаданные (Informatica workflows, SQL-джобы)

   • BI-конфигурации (Qlik Sense, Mail&Deploy)

   • Схемы потоков Kafka, топики и партиции

2. Участие ответственных инженеров и архитекторов
   Представители интегратора и внутренней команды готовы к:

   • Регулярным встречам для обсуждения технических деталей

   • Предоставлению контекста, недостающих схем и логики

   • Подтверждению/опровержению предположений

3. Своевременное предоставление информации
   Запрашиваемые материалы и ответы на уточняющие вопросы должны быть предоставлены в рамках заранее согласованного SLA (например, 2–3 рабочих дня), иначе сроки этапов могут быть пересмотрены.

4. Объективность оценки
   Аудит проводится независимо, с фокусом на соответствие техническим best practices, а не на текущие организационные ограничения. Выводы не корректируются в угоду действующим решениям.

5. Проект не включает реализацию рекомендаций
   Аудит ограничен анализом и формированием рекомендаций. Внедрение требует отдельного плана и ресурсов.