Роман с Data Science. Как монетизировать большие данные

• Количество заказов (уникальность здесь обеспечена тем, что одна строка – это заказ, дублей заказов нет).

• Количество уникальных клиентов (нужно считать число уникальных ID, так как один клиент может сделать несколько заказов, и его посчитают несколько раз).

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

Аналитик определяет для каждого столбца, являются ли данные в нем измерениями или показателями, а также какие статистики по показателям ему нужны. Подготовительные работы закончены, теперь время сформулировать гипотезы и для каждой из них определить один или несколько срезов, которые подтвердят гипотезу или опровергнут. Понятие среза происходит из многомерной природы сводных таблиц. Представьте себе трехмерный предмет, имеющий следующие измерения: длину, ширину и высоту. Пусть это будет кусок сливочного масла. Вы берете нож, разрезаете его и получаете срез, причем плоскость среза перпендикулярна оси, которую вы фиксируете. То же самое вы проделываете, когда работаете со сводной таблицей – делаете срез многомерных данных. Осей может быть много, это число равно числу измерений – вот откуда берется многомерность. Место на оси (измерение), перпендикулярно которой режете, попадет в фильтр отчета как значение. Вы фиксируете его. Измерения, которые будут лежать в плоскости среза, будут столбцами и строками нашей таблицы. Если фильтр отчета не используется, то все данные будут спроецированы на наш срез при помощи операции агрегации, которая для каждого показателя выбирается индивидуально (суммы, средние, количество).

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

• Изменение поведения вызвано одним из типов клиента. Для этой гипотезы одно из измерений – тип клиента.

• Изменение поведения вызвано одной из групп лояльности. Для этой гипотезы одно из измерений – статус лояльности клиента.

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

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

Если бы не было электронных таблиц и средств визуального анализа на сводных таблицах, то скорость подобного типа анализа была бы в десятки раз ниже. Аналитику пришлось бы программировать каждый срез, например, через оператор GROUP BY в SQL или pivot в питоновской библиотеке pandas. Со сводными таблицами аналитик работает со скоростью своей мысли.

OLAP-кубы

Сводные таблицы бывают не только в электронных таблицах. Большие объемы данных туда не поместить – они будут очень медленно работать, если вообще туда поместятся. А мы ведь хотим, чтобы все работало со скоростью мысли, не правда ли? Для этого производители софта идут на всякие ухищрения, например, размещают данные в колоночной базе данных прямо на компьютере пользователя (о преимуществах колоночных баз данных уже написано в главе про хранилища). Второй способ – делать все вычисления на серверах, а пользователю предоставить туда доступ через интерфейс (толстый или тонкий клиент). Именно так были придуманы кубы OLAP (On-Line Analytical Processing – интерактивный анализ данных).

История их появления очень интересна как минимум тем, что к этому приложил руку наш бывший соотечественник – Михаил (Моша) Пасуманский. Михаил переехал в Израиль из Санкт-Петербурга в 1990 году. Там он написал аналитическое приложение «Панорама». В 1995 году они выпустили первую версию. В 1996 году компанию купила Microsoft, которой нужно было подобное решение для новой версии SQL Server. После интеграции системы в софт Microsoft появился язык программирования для работы с OLAP-кубами, который называется MDX (Multidimensional Expressions), чьим автором является Михаил Пасуманский. Этот язык является стандартом для работы с OLAP-кубами, и его поддерживают очень многие вендоры. Сервис OLAP-кубов теперь называется Analysis Services.