Данным в BI-отчете верить?

ProКачество: Как формируется отчет в BI-системе? Откуда получают данные для него? 

Игорь Кузин: Важно сразу уточнить, что BI-системы не занимаются непосредственным сбором данных. Для этого существует ряд других инструментов, например, датчики телеметрии или счетчики посещаемости на сайте и другие системы аналитики. То есть BI-система «коннектится» к тем системам, где данные уже были собраны. Дальше происходит поочередно несколько процессов:

• получение данных из внешних систем;

• трансформация данных;

• хранение данных;

• формирование регулярной отчетности.

Чтобы лучше понимать, как в BI-системе происходит работа с данными, стоит немного раскрыть ее архитектуру. Предварительно при разработке BI-системы под каждый  отчет «кладется»   датасет . Затем датасеты раскладываются по каталогам, которые, в свою очередь, выстраиваются в стандартизированную систему.

Для подготовки датасетов BI-инженеры используют  SQL-запросы , которые направляют либо в собственные хранилища, либо во внешние. В первом случае датасеты выгружаются из  Data Warehouse или  Data Lake . Во втором – BI-инженер по SQL-запросам объединяет данные из разных внешних систем, формируя необходимый датасет.

Подробнее о том, что такое BI-система, читайте в нашей статье «В бизнес-аналитике на смену Excel пришли BI-системы».

Можно выделить две группы источников для формирования датасетов:

1. База данных и плоские таблицы;

2. Коннекторы к внешним источникам данных. 

О том, как данные получают из первого источника, сказано выше. А коннектор – это первичный этап настройки интеграции внешней базы данных. Так как во внешней базе может быть несколько таблиц, нужно конкретизировать, к какой именно обращаться. Чаще всего для этого используют  API , иногда приложения или специальные программы, которые собирают информацию  извне . Такой способ лучше всего подходит для работы со слабоструктурированными или неструктурированными данными. Когда, например, надо собрать аналитику об эмоциональной окраске комментариев в интернете. 

ProКачество: Наверняка данные из разных источников нуждаются в некой стандартизации. Как это отражается на работе BI-системы и точности получаемых отчетов? С какими трудностями может столкнуться компания в этой сфере? 

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

Бизнес-заказчиков аналитических систем больше всего интересует точность данных, обычно остальные аспекты отходят на второй план. И выбирая BI-систему под эту задачу, необходимо понимать, что она не задает стандарт данных, а только лишь стандарт их визуализации. 

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

Когда могут возникнуть неточности в отчетах:

• разные BI-инженеры в разное время работали над созданием датасетов, отправляли SQL-запросы в различные системы и хранилища, объединяли разные данные. Неточности в отчетах возникают потому, что источники разные и они могут читать одни и те же данные по-своему;

• у разных структурных подразделений компании разная логика подсчета метрик. И в итоге данные в отчетах «не бьются» не только между собой, но и с внешним источником. 

Существует еще ряд вызовов, с которыми сталкиваются и заказчики, и разработчики при внедрении BI-систем:

1. Стандартизация процедур обработки, трансформации и хранения данных. Идеальная ситуация для высокого качества данных – когда есть внешние источники данных, единый стандартизированный способ их трансформации, после чего они помещаются в единое хранилище с четкой логикой, откуда потом извлекаются для формирования отчета в BI-системе и только потом визуализируются. Такое встречается крайне редко. 

Чаще мы видим другую ситуацию – BI-система существует, а единого хранилища данных нет. Существует множество датасетов, но нет единого процесса обработки данных. 

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

2. Стандартизация метрик. Сложность этой задачи заключается в том, что выявить универсальную формулу метрики с ходу не всегда получается. Одни и те же показатели в одном случае могут считать одним способом, а в другом – иначе. И оба способа будут верны. А единая механика подсчета необходима.

Отсюда вытекает следующая проблема – правильно поставить  ТЗ  на метрику.  

Заказчик хоть и пользовался этой метрикой, но никогда не думал, как она должна работать. Например, метрики  Retention Rate  и  Customer Lifetime Value  – они обе считаются по когортам. То есть необходимо внедрять механику когортного анализа, которая влечет за собой ряд трудностей: 

• может не быть данных в модели данных;

• данные могут быть объединены или трансформированы некорректно. 

И на практике получается сложно сформировать единую логику подсчета таких метрик. 

3. Разработка коннекторов. Главная сложность заключается в том, что разработчики коннекторов сталкиваются с неактуальными внешними API. То есть разработчик берет API внешней системы, который заявлен на сайте. На его основе разрабатывается будущий коннектор – предварительно «прописывают» модели данных, запросы, процесс трансформации данных. После чего делается запрос во внешнюю систему, но оказывается, что API устарел, уже давно используют другой, например. Можно запросить новый API, и тогда весь процесс стартует заново. 

И подобных «узелков» на тернистом пути разработки коннекторов достаточно много. Например, бизнес-пользователь, со своей стороны, думает: «Раз я эти данные вижу, значит, они есть и их можно извлечь». Но часто это не так. Например, «Яндекс.Метрика» не дает глубоко извлекать данные по категории «пол» и «возраст», потому что это уже персональные данные, по которым можно слишком много идентифицировать. Такие данные можно получить только в большой грубой агрегации. 

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

Разработка коннекторов – длительный процесс с неизбежно большим числом итераций и «вечной битвой» за стабильность работы и качество данных.

4. Рост затрат на BI-систему. Этот фактор необходимо учитывать, потому что запросы бизнес-заказчика растут, растет и число поддерживаемых отчетов. Значит, в свою очередь, будет регулярно расти и штат поддержки, и, соответственно, бюджет на его содержание. 

ProКачество: Как управлять качеством данных в компании, чтобы они были точными?

Игорь Кузин: Вопрос доверия к данным в отчетах BI-системы у заказчиков встает часто. Потому что сама BI-система не может дать гарантии качества данных. Это полностью зависит от специалистов, вносящих данные в систему. 

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

1. Использовать готовые коннекторы. Сторонние коннекторы, как правило, это уже стабильные решения, имеющие промышленную апробацию и эксплуатацию.
   
   Кроме того, компании – разработчики коннекторов предлагают готовые решения для мониторинга точности их данных. Принцип работы сервиса: он отправляет запросы в источник данных и в хранилище на стороне компании и сравнивает их. Если сервис выявляет несоответствие, то он оповещает об этом пользователя;

2. Не изобретать велосипед. Не стоит пытаться разработать то, что делают отраслевые системы аналитики. Как показывает мировая практика, BI-системы и системы аналитики отлично соседствуют. Данные из систем аналитики поступают в корпоративные BI-системы и используются для формирования отчетности. Например, будет большой ошибкой пытаться разработать с нуля аналог «Яндекс.Метрики», если можно воспользоваться уже готовым решением;

3. Сразу строить Data Warehouse со стройной моделью данных. И потом, при формировании отчетов, стараться выгружать все датасеты из этого хранилища;

4. Сформировать единую логику подсчета метрик.