BI-системы: ограничения или возможности?

Недавно наткнулся в соц. сети на мнение (к слову весьма расхожее в последнее время), что:

• Python - это основной инструмент аналитика и что
• Аналитические системы - это негибкие инструменты

На мой взгляд, чтобы разобраться в этих вопросах их стоит детализировать. 

Python - основной инструмент аналитика?

Python (как и R) это язык программирования. В нем есть набор функций, которые идут с дистрибутивом и есть механизм пакетов, который позволяет элегантно расширять возможности такого языка. 

С этой точки зрения Python, R или любой другой язык программирования будет всегда давать больше возможностей, он априори будет более универсален. 

Но, универсальность всегда имеет свою цену... 

Конечный результат

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

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

• в каком формате заказчик ожидает получить результаты исследования?
• куда дальше направятся эти цифры и какие преобразования с ними случатся по пути?
• потребуется ли регулярное обращение к таким цифрам в будущем?

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

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

Очень редко заказчик хочет получить изолированную метрику. Помимо целевой метрики важно посмотреть на взаимосвязи с некоторыми существующими метриками, которые уже определены, посчитаны и лежат в BI-системе (например в Tableau или в Power BI - двух самых распространённых BI-системах).

Если вы не разрабатывали существующие метрики, вам нужно будет пойти и изучить как сами метрики, так и исходные данные на которых они строятся. Фактически вам нужно будет воспроизвести часть ETL и логику расчетов некоторых существующих метрик. 

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

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

Это даст вам ряд преимуществ:

1. вы сможете происпользовать существующие просчитанные метрики
2. вы сможете делать drill-down используя готовые и стандартные для компании dimensions
3. вы сможете сразу сделать то, что заказчик часто просит вас на второй итерации - сделать дополнительный ресерч и поискать какие группы ведут себя отлично от среднего вашей целевой метрики
   

куда дальше направятся эти цифры и какие преобразования с ними случатся по пути?

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

Не важно на чем вы написали исследование (скрипт на .py или ноутбук .ipynb). Чтобы достать из него результаты, заказчику нужно разбираться с тем, как устроен ваш код: какие его части делают промежуточные расчеты, а где находится финальная таблица и/или графики. 

Кроме того, у заказчика должен быть доступ к среде, где выполнение вашего кода вообще возможно: стоит интерпретатор Py/R, установлены необходимые пакеты, есть доступы к БД и т.д.

потребуется ли регулярное обращение к таким цифрам в будущем?

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

Кроме этого хочется также отметить 2 важных инженерных фактора.

Открытость

Все мы так или иначе ходим за данными в Базы Данных. И часто в БД или даже в DWH данные лежат НЕ в том виде, в котором нам было бы удобно сделать анализ.

Конечно, можно написать выгрузку и препроцессинг на Py, но результат этой работы будет локальным для вашего исследования. Если кому-то нужно будет повторить обработку, ему придется искать и повторять логику вашего кода.

Используя подход SQL View и сославшись на него в своем исследовании, вы получите:

1. доступность вашей обработки
2. открытость для быстрого внесения изменений 
3. возможность повторного использования другими аналитиками

Скорость

Чем больше масштаб бизнеса, тем больше данных хранится в БД. Для обработки данных за большие периоды вам потребуется выгрузить данные локально и затем обработать. 

Для ряда задач это может быть не быстро. В ряде случаев такой подход вообще не осуществим - у вас просто не хватит ОЗУ для того, чтобы выгрузить данные локально и затем обработать их.

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

Аналитические системы - негибкие инструменты? 

Disclaimer: мой опыт работы с BI-системами это Power BI (Power Query/M и Power Pivot/DAX). Поэтому дальнейшие выкладки будут касаться работы с этими технологиями.

Чтобы ответить на вопрос (не)гибкости BI-систем, я предлагаю разбить процесс подготовки исследования на этапы:

• ETL
• дизайн аналитического среза (модель данных)
• написание метрик
• построение визуализаций
• интеграция с существующими срезами/метриками
  

ETL

Большинство BI-систем идут из коробки с набором коннекторов. Обычно это коннекторы к широко распространенным БД (MySQL, PostgreSQL, и т.д.). Если нативного коннектора нет, часто можно воспользоваться ODBC-коннектором.

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

1. вы можете сделать SQL View, в которой подготовите данные для себя и других членов аналитической команды
2. вы можете написать SQL-запрос, в котором выберите только нужные вам колонки и/или сделаете дополнительные расчеты "на лету"
3. если вы слабо знаете SQL, вы можете сделать это через UI редактор в Power Query. В Power Query вы можете подключиться к разным источникам данных, выбрать нужные вам таблицы/колонки, сделать преобразования или дополнительные расчеты и... Power Query сформирует для вас скрипт на языке M, который вы легко можете перенести в любой другой BI-отчет.
4. если функционала UI редактора Power Query вам не хватит, вы можете написать нужный кусок кода непосредственно на языке M
5. если языка M вам не хватит, вы можете встроить обработку данных на Py/R

Как мы видим, у вас есть целая палитра возможностей, чтобы забрать данные и сделать их препроцессинг (от программирования на М, до использования UI, до вставки 3-х языков).

Следующий момент. В Power BI любая модель данных это файл, в котором содержится:

• информация об источниках данных и M-код, который (при необходимости) эти данные препроцессит
• собственно выгруженные данные
• связи между таблицами
• код метрик
• набор таблиц, графиков, слайсеров/фильтров

Что это даёт?

Во-первых: вся необходимая информация для понимания откуда данные и как построено исследование у вас под рукой, в одном файле. Это удобно и для вас (автора модели) и для других аналитиков, которые получают полное представление о data pipeline отчета.

Во-вторых: если вы сейчас оффлайн или у вас нет доступа к корпоративным источникам данным, вы все равно можете продолжать работать над моделью данных.

Кейс #1

Я очень часто возвращаюсь к существующим моделям, чтобы проверить новые гипотезы. 

Я не завишу от доступа к данным, когда мне нужно проверить смежную гипотезу. Я просто открываю модель и сразу начинаю строить новые расчеты на своей копии данных. Актуальность данных обычно не так важна, как проверка работоспособности подхода в целом.

дизайн аналитического среза (модель данных)

Обычно нужные вам данные хранятся в нескольких таблицах (или вообще в разных источниках данных). Чтобы забрать их у вас есть две опции:

1. сделать JOIN нужных таблиц и в одну большую flat таблицу, выгрузить ее и делать все расчеты на её основе
2. выгрузить нужные вам таблицы отдельно и связать их в модели данных

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

Выгрузка данных в виде отдельных таблиц дает вам гибкость:

1. вы можете забирать и связывать очень разные источники данных (таблицы из разных БД, .csv файлы, API-данные и т.д.) 
2. вы можете работать с каждой таблицей (сущностью) отдельно
3. вы можете дообогащать модель данных, добавляя новые таблицы и не переживать, что модель данных "поедет", как это часто случается с flat таблицами
4. вы можете из коробки строить many-to-many связи 

написание метрик

На мой взгляд это самый критичный момент. Хорошо, когда задачу можно решить простыми аггрегатами, но на практике такая ситуация встречается редко. И причин тому две:

1. необходимость работать с большими объемами данных
2. необходимость гибкого и краткого описания логики расчетов

Что касается работы с большими объемами данных. 

Когда вы работаете с данными в Py - вы работаете с данными как есть. 

Когда вы загружаете данные в Power Pivot (а это колоночная БД), то вы работаете с данными в сжатом виде. Данные сжимаются в среднем в 7-10 раз (это зависит от распределения данных). 

Более того, т.к. Power Pivot это колоночная БД, то у вас появляются два преимущества: 

• работать с сильно большим объемом данных на вашем компьютере и 
• получать очень высокую скорость их обсчета по сравнению с row based БД

Что касается гибкости логики расчетов (на примере поведенческой аналитики).

Пример логики расчета может выглядеть вот так:

• взять клиентов вернувшихся в продукт за период с 1-го по 7-й день после регистрации
• разбить их на группы по какому-то признаку
• для каждой группы посмотреть, кто из них вернулся с 28-го по 35-й день после регистрации
• дополнительно посчитать для каждой группы (как начальной так и той, что вернулась) некую метрику, например доход за 90 дней.

Одно дело писать элементарные агрегации (SUM, AVG), а другое - сделать более сложный расчет на подобие того, что я привел выше. Большинство аналитиков, которых я встречал, затрудняются быстро запрограммировать такой расчет и на то есть причины: 

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

Т.о. круто использовать язык программирования, когда вы глубоко понимаете его возможности и можете их использовать на 100%. Из моего опыта, аналитики - плохие кодеры. 

Хочу отметить, что в Power Pivot есть полноценный язык именно для анализа данных - DAX. И он задизайнен так, чтобы писать метрики можно было компактно и быстро. 

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

Кейс #2 

Заказчик попросил вас посмотреть на количество логинов в продукте по месяцам. Если это делать на уровне SQL или Ry/R, то в самом теле расчета вам нужно сделать группировку по месяцу. 

Посмотрев на данные стало понятно, что в прошлом месяце логинов стало несколько меньше. Нужно точнее понять, когда могло начаться проседание. 

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

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

Каждый раз вам нужно править SQL или Py/R код: делать группировку то по датам, то по каждому dimension, чтобы проверить каждую гипотезу отдельно.

Схема работы в BI-системе другая: вы изначально строите расчет на самом нижнем уровне гранулярности (масштабе) - в данном случае на уровне дня. 

Написав такую метрику ваша подготовка к анализу уже закончилась.

• если нужно посмотреть метрику по месяцам вы просто перетягиваете на визуал колонку месяца из календаря
• если нужно разбить месяц на недели, вы просто перетягиваете на визуал колонку недели как следующий уровень иерархии после месяца 
• если нужно разбить недели по устройствам, вы просто перетягиваете на визуал колонку устройств как следующий уровень иерархии после недели

Более того, если нужно посмотреть на данные под другим углом: понять распределение логинов по устройствам и уже внутри каждого устройства посмотреть отдельно на динамику логинов по месяцам, вы просто меняете порядок иерархии dimensions. 

В любом случае, ваша BI-метрика остается неизменной. Вы занимаетесь анализом, а не программированием. 

Единственная альтернатива в этом кейсе это написание кода, который в автоматическом режиме будет искать аномалии по ряду предопределенных dimensions. 

Правда в этом случае, у вас не будет вырабатываться насмотренность: вы НЕ научитесь понимать масштаб метрики и ее вариативность. 

построение визуализаций

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

Также хочу отметить, что крайне редко я вижу у аналитиков Conditional Formatting, особенно, если мы говорим про результаты данных в консоли или в Py/R-ноутбуке. А ведь это простая опция часто сильно сокращает время на нахождение закономерностей (и часто положительно воспринимается заказчиками).

Почему так происходит? Потому что в Py графику тоже нужно программировать... 

интеграция с существующими срезами/метриками

Я уже касался ситуации, когда при проведении исследования помимо анализа целевой метрики важно оценить поведение соседних метрик.

И мое предложение было встраивать свое исследование в существующую модель. В терминах Power BI это означает: вы качаете модель в .pbix файле и дальше дообогащаете ее своими данными и метриками. 

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

Но аналитические системы на стоят на месте. В Power BI в 2021 году появилась возможность строить composite models.

Кейс #3

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

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

Даже, если ваш коллега сделал первоклассную работу и сделал SQL View в БД, и вы можете потянуть их как есть в вашу модель, вам все равно нужно будет воспроизвести логику метрик платного привлечения.

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

И здесь на сцену выходит технология composite models. В будущем это очевидно станет deal breaker`ом при выборе BI-системы. 

Теперь я могу не тянуть таблицы из модели платного привлечения и не копировать метрики оттуда. Вместо этого я могу из своей модели анализа поведения клиентов просто подключиться к модели платного привлечения и воспользоваться данными и метриками оттуда. 

Что это означает на самом деле?

• Мне не нужно каждый раз тянуть данные из DWH в новую модель данных. Построив одну модель я повторно использую ее данные в облаке, не создавая нагрузки на DWH и ускоряю обновление экосистемы отчетов.
  
  
• Я имею One source of True на уровне модели данных: если в какой-то момент мы с маркетингом поменяем логику расчетов CAC или LTV, все остальные модели будут использовать последнюю, актуальную версию таких расчетов.
  
  
• Я могу строить модульную архитектуру бизнес-анализа любых направлений компании, а затем элегантно строить любую сводную отчётность и очень быстро генерировать инсайты на стыке разных моделей.

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

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