DataGrizzly

Проектирование отчетов, которые не придется переделывать

Необходимость контролировать свою работу подталкивает любую компанию к использованию накопленных данных. Так появляется система отчетности, а с ней – новые проблемы для менеджеров. Как сформулировать требования к отчетам (витринам данных)? Найти нужную информацию и написать техническое задание?

Цели проектирования

Ответы на эти вопросы, находятся в плоскости понимания того, что витрина данных это не только результирующий датасет или BI-отчет, на которые смотрит заказчик, но и система путей, по которым движется необходимая информация от систем источников. Недостаточно "утрясти" атрибутный состав целевого набора данных – нужно его наполнить и детально проработать траекторию движения данных от источников. Итак, цели проектирования :

Типичный подход

Любой сценарий проектирования витрины данных начинается с изучения аналитиком потребностей в информации и совместная с заказчиком работа по их уточнению. Помимо «шлифовки» исходного документа (БТ/BRD) аналитиком формируется набор своих собственных артефактов, отвечающих целям проектирования. Это могут быть скрипты сборки данных (прототипы) и аналитические запросы, схемы потоков и описания трансформаций данных, спецификации на наборы данных и модели данных, листы вопросов/ответов, а также другие. Следующим шагом этого процесса является подготовка технического задания для разработки витрины.

БТ - документ заказчика, аналитик может помочь его наполнить.

Артефакты аналитика могут быть как зависящими (тип 2), так и независящими от аналитической платформы (тип 1).

Техническое задание на разработку - документ установленный владельцами аналитической платформы.

Важно отметить, что в отличие от шаблонизированных БТ и ТЗ промежуточные артефакты аналитика, в подавляющем большинстве случаев, не имеют жесткой структуры и зависят от стиля и опыта исполнителя. Именно эти обстоятельства порождают связанные с проектированием проблемы.

Что делаем мы

Наш продукт это проект витрины или системы витрин - пакет аналитических документов с помощью которого можно поставить техническое задание разработчику любой аналитической платформы. В отличие от типичного подхода, перечень мероприятий направленных на реализацию целей проектирования статичен, а результирующие документы имеют жесткий формат, не зависят от особенностей аналитической платформы и  создаются до написания технического задания.

Результат работы аналитика - проект витрины, а не ТЗ, являющееся артефактом аналитической платформы.

Проект одновременно можно реализовать на нескольких платформах.

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

1. Отработанный набор действий и артефактов, позволяет выявить и детально проработать и уточнить требования заказчика, а также гарантировать сборку именно ожидаемой витрины.

2. Работа аналитика разделена на этапы, что позволяет легко его подменить

3. Проект витрины можно использовать в качестве консолидированного документа об алгоритмах сборки витрины, на языке максимально приближенному к бизнесу.

Правильно ли, что мы не работаем с "техникой" ? Вовсе нет, для достижения результата нам приходится пропускать через себя километры кода SQL запросов и процедур, писать свои, разбираться в структурах данных, особенностях репликаций, джобах ETL и прочих технических нюансах обработки информации.  Опыт нашей команды позволяет работать с любыми аналитическими платформами, построенными вокруг таких технологий как GreenPlum, Teradata, Vertica, PostgreSQL\Postgres Pro, Oracle DB, MS SQL, Hive\Impala\Spark и использующие такие ETL инструменты как Informatica, Pentaho, Talend, Airflow, Ni-Fi итп