What is ad hoc analysis?

Что нужно помнить при выборе аналитической платформы

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

Стадия четвертая. избавление ит от ad-hoc или рождение olap. начало проекта bi.

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

Или же этот человек имел опыт с некой BI-системой. Поскольку сейчас речь скорее не о самых крупных компаниях, то людей, предлагающих что-то из SAP Business Objects, IBM Cognos, Oracle BI перестанут слушать, когда увидят ценник. В крупных же компаниях уже давно что-нибудь да есть, как минимум Microsoft BI (SQL Analysis Services и Reporting Services).

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

Что такое отчет и что такое анализ

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

Отчет показывает, что произошло: в четверг в 10:03 на сайте наблюдалось максимальное число посетителей – 63 000 человек. Он дает конкретные цифры.Анализ показывает, почему это произошло: в 10:01 о компании упомянули в ТВ шоу 60 Minutes, – и рекомендует, что компании следует делать, чтобы оставаться примерно на этом же уровне.

Отчеты ретроспективны, анализ дает рекомендации.
В следующей таблице суммированы отличия между этими понятиями. Теперь должно быть очевидно, почему анализ и управление на основе данных – настолько важный компонент ведения бизнеса. Это факторы, способные дать компании новые направления развития или вывести ее на новый уровень эффективности.
Гипотетические основные вопросы, на которые отвечает аналитика, по Дэвенпорту. Пункт D представляет собой ценную аналитику, пункты E и F обеспечивают управление на основе данных, если эта информация стимулирует конкретные действия (подробнее об этом ниже).
Гипотетические основные вопросы, на которые отвечает аналитика, по Дэвенпорту. Пункт D представляет собой ценную аналитику, пункты E и F обеспечивают управление на основе данных, если эта информация стимулирует конкретные действия (подробнее об этом ниже).

В нижнем ряду таблицы отражены действия, приводящие к выводам. Составление отчетов (А) и оповещение (В) – не управление на основе данных: они отмечают, что уже произошло или что необычное или нежелательное происходит сейчас, но при этом не дают объяснений, почему это произошло или происходит, и не дают рекомендаций по улучшению ситуации.

Предвестником управления на основе данных служит дальнейшее изучение причинно следственных связей с помощью моделей или экспериментов (D). Только понимая причины произошедшего, можно сформулировать план действий или рекомендации (Е). Пункты E и F обеспечивают управление на основе данных, но только если полученная информация стимулирует конкретные действия.

Пункт С представляет собой опасную зону, поскольку слишком велик соблазн распространить существующий тренд на будущее: в Excel выберите «Диаграмма» (Chart), нажмите «Добавить линию тренда» (Add trendline) – и вот вы уже экстраполировали текущие данные на другие ячейки и делаете необоснованные прогнозы.

Почему облачная аналитика стала одним из главных трендов

Для многих компаний безопасность становится барьером для миграции или переноса отдельных ИТ-систем в облако. Однако на практике есть кейсы, когда строгие требования ИБ как раз являются причиной использования облачных технологий.

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

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

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

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

Облачную аналитику также используют для ускорения time-to-market, быстрой проверки гипотез и аналитики ad hoc

p13=”#unknown”>Ad hoc в переводе с латыни — «для этого», то есть для определенного случая.. Можно быстро прототипировать решение, развивать его итеративно, постепенно наращивая ресурсы и подключая дополнительные источники.

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

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

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

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

Несмотря на то, что мы видим достаточно много специфических «облачных» сценариев для аналитики, многие компании строят также и классический регламентированный BI с отчетами-дашбордами именно в облаке — из-за простоты, надежности, безопасности и экономики решения.

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

Data architecture

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

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

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

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

Data mapping

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

• • преобразование данных (Data Transformation) между источником (Data Source) и местом назначения (Target, Data Destination);
• • идентификацию связей данных как часть анализа происхождения данных;
• • обнаружение скрытых зависимостей между элементами данных;
• • консолидацию нескольких баз данных в единственную базу данных с выяснением избыточных столбцов данных для устранения или объединения.

Data Mapping Software может показывать связи между:

• • различными источниками и приемниками данных;
• • системами, которые собирают, манипулируют и хранят данные;
• • отчетами, информационными панелями и другими артефактами, которые потребляют данные.

Data mart

Витрина данных – проблемно-ориентированное подмножество данных из хранилища (или оперативной системы), проектируемое для удовлетворения потребностей определенной группы пользователей, работающих с определенным кругом задач, и требований безопасности доступа к данным.

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

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

Eav   (entity attribute value)

Сущность-Атрибут-Значение – вертикальная модель базы данных – модель данных для описания сущностей, где количество атрибутов (параметров), которые могут быть использованы для описания сущностей, потенциально огромно, но в действительности применительно к конкретной сущности
используется (заполняется) значительно меньше атрибутов.

В математике эта модель известна как разреженная матрица (Sparse Matrix).
Основная цель EAV – дать конечным пользователям возможность расширения модели без программирования. Концептуально EAV можно представить в виде таблицы из 3-х полей:

“Сущность”, “Атрибут”, “Значение атрибута”. Таблица содержит по одной строке на каждую тройку Сущность-Атрибут-Значение. На практике, для содержания индексации и правил проверки, поле “Значение атрибута” предпочитают разделять на отдельные поля по основным типам данных: строка, вещественное и целое числа, дата, большой двоичный объект (BLOB).

Gigo   (garbage in garbage out)

«Мусор на входе – мусор на выходе» – принцип, означающий, что при неверных входящих данных будут получены неверные результаты, несмотря на то, что сам по себе алгоритм правилен. Построение OLAP-куба на таких данных возводит бардак в степень 3.

По мнению компании DIS Group:
“Отсутствие корпоративной культуры управления данными и сильных специалистов – верный способ провалить аналитику данных. Аналитика данных занимает узловые позиции любого результативного процесса в промышленности, становясь одним из самых важных различий технологий управления данными.

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

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

Knowledge management system

Система управления знаниями – информация и данные, доступные всем членам организации через специальные порталы и системы управления контентом (Content Management Systems).
Система управления контентом — это наиболее очевидная и оперативная составляющая системы управления знаниями, но есть и следующие составляющие:

• • В базе извлеченных уроков (Lessons Learned) фиксируются и находятся в общем доступе те знания и опыт, которые были получены в ходе операционной деятельности, но не подлежат документированию в рамках стандартных процедур. В контексте управления знаниями упор обычно делается на сбор данных лично от участников деятельности, то есть превращение неявных знаний в явные.
• • Определение местонахождения компетенций (Expertise Location) – поиск сотрудников организации, которые обладают знаниями в той или иной области. Такие системы раньше называли системами “желтых страниц”.
• • Сообщества специалистов-практиков (Communities of Practice) – это группы людей со схожими интересами, которые собираются лично или виртуально вместе, чтобы поделиться опытом, обсудить проблемы и возможности, поговорить о лучших практиках и извлеченных уроках.

Mdm   (master data management)

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

MDM система предоставляет целостный взгляд на все составляющие бизнеса, в том числе на источники данных, авторство, качество, полноту и на потенциальное использование данных. Под нормативно-справочной информацией (НСИ) понимается условно-постоянная информация, представляющая собой совокупность взаимосвязанных справочников и классификаторов, а также нормативных документов, используемых в бизнес-процессах компании.

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

Для реализации концепции MDM существует специальный класс программных продуктов.

Olap   (online analytical processing)

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

Термин OLAP был введен в 1993 году Эдвардом Коддом (Кодд – так же автор реляционной модели данных), сформулировавшим основные требования к функциональности программных продуктов, реализующих эти технологии. Технология (а также класс соответствующих программных продуктов), реализующая концепцию анализа данных, представленных в виде многомерного пространства.

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

Эти формы, полученные на основании первичных данных, позволяют пользователю сформировать полноценное представление о деятельности предприятия. Функциональность OLAP заключается в динамическом многомерном анализе консолидированных данных предприятия, направленном на поддержание следующих аналитических и навигационных видов деятельности пользователя:

• • вычисления и моделирование, примененные к измерениям и/или их конкретным элементам, использующие информацию об иерархиях, анализ временных тенденций показателей (анализ трендов);
• • формирование срезов многомерного представления для просмотра на экране;
• • переход к более глубоким уровням детализации;
• • доступ к исходным данным – “вращение” многомерных представлений: перемещение измерений с целью формирования различных форм представления данных на экране компьютера.

Клиент-серверная архитектура OLAP-продуктов обеспечивает одновременный доступ большого числа пользователей (многопользовательский режим работы). При этом анализ должен производиться одинаково быстро по всем аспектам информации (приемлемое время отклика – 5 с или менее) независимо от размера и сложности структуры базы данных.

OLAP предоставляет удобные быстродействующие средства доступа, просмотра и анализа деловой информации. Пользователь получает интуитивно понятную модель данных, организуя их в виде многомерных кубов. Это позволяет ему проводить как сравнительный анализ показателей, так анализ различных сценариев по принципу “что-если”, построенных на основе прогнозных и статистических данных компании.

Виды OLAP:

Olap client

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

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

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

Workflow monitoring

Мониторинг технологического процесса, рабочего потока ETL с целью выявления узких мест и улучшения производительности процесса. Мониторинг процесса не что-то, что выполняется администратором 1-2 раза, а затем он занимается чем-то другим.

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

Временная метка. немного трюков

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

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

tic("straightforward as.POSIXct")
dt[, timestamp := as.POSIXct(paste(date, time), 
                                  format = "%Y%m%d %H%M%S")]
toc()

Но не будем на этом останавливаться. Вдруг данных будет немного больше (это же IoT по постановке задачи). 50М или 500М? Поменяем библиотеку с пониманием того, как она устроена внутри и как устроен POSIXct.

Получаем 3.5 секунды на нашем датасете.

tic("straightforward lubridate")
dt[, timestamp := lubridate::ymd_hms(paste(date, time))]
toc()

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

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

> uniqueN(dt, by = c("date", "time")) # почти в 100 раз меньше!
[1] 53424
> uniqueN(dt, by = "date")
[1] 1113
> uniqueN(dt, by = "time")
[1] 48

Используем этот подход меняем библиотеку.Вариант через групповую обработку — получаем 2.9 сек.

tic("anytime")
# не забываем следить про таймзону
dt[, timestamp := anytime::anytime(stri_c(.BY[[1]], .BY[[2]], sep = " ")), 
   by = .(date, time)]
toc()

Для потоковых преобразований ограниченных подмножеств наилучшим подходом является предварительное создание словаря “входное значение — преобразованное значение”. Тогда вся трансформация будет сводится выборке из этого словаря. Вариант через слияние по ссылкам со словарем дает чуть лучший результат 1.3 сек:

tic("inverse dictionary")
time_dict <- unique(dt[, .(date, time)]) %>%
  .[, timestamp := anytime::anytime(stri_c(date, time, sep = " "))]

dt[time_dict, on = .(date, time), timestamp := i.timestamp]
toc()

Это все? Потенциально, если расщепить словари даты и времени, то можно сократить объем преобразований еще примерно в 10 раз (1113 48 против 53K). Таймзоны в исходных данных не наблюдаются, городов тоже, значит все условно можно считать в UTC.

В таком варианте получаем примерно 0.7 сек.

tic("split   anytime")
dt[, secs := {
  tm <- as.integer(.BY[[1]]);
  (tm %% 100L)   ((tm %/% 100L) %% 100L) * 60L   (tm %/% 10000L) * 3600L}, 
  by = time] %>%
  .[, timestamp := anytime::anytime(.BY[[1]])   secs, by = date]
toc()

Итого, путем краткого исследования исходной задачи и незначительных манипуляций получаем ускорение со 130 сек (которые многие аналитики сочли приемлемым) до 0.7 сек. (~ 180 раз) в базовом варианте, или с 3.5 сек до 0.7 сек (~ 5 раз) в варианте с lubridate. Можно, конечно, разбрасываться ресурсами, но если это делать на каждом шагу, то ресурсов и времени может легко не хватить.

Глоссарий интернет-маркетинга

Оптимизация

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

Представленные идеи формируют график из книги Дэвенпорта и Харриса Competing on Analytics (2006).

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

Если забьете в поисковую строку Google ключевые слова «analytics maturity», то поймете, что я имею в виду. Многочисленные специалисты представляют этот график как набор последовательных шагов для достижения цели, где односторонние стрелки указывают переход на новый уровень.

Рон Шевлин рационально отмечает:

С точки зрения возможностей нет причин, почему компания не может прогнозировать, например, объем продаж («уровень» 6), не зная, в чем конкретно «проблема» с продажами («уровень» 3)… Но как я, будучи руководителем, должен отвечать на вопрос «Какие действия нужно предпринять немедленно?» без понимания «Что будет, если этот тренд продолжится?» и «Что произойдет дальше?» («уровни» 6 и 7)?

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

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

Можно предположить, что более сложная аналитика по умолчанию лучше и что она способна сделать компанию более конкурентоспособной. Так ли это на самом деле? В интереснейшем исследовании , проведенном MIT Sloan Management Review совместно с IBM Institute for Business Value, были опрошены 3 тыс. руководителей и специалистов по работе с данными в 30 отраслях: как они используют аналитическую работу и что думают о ее ценности?

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

1. значительно лучше, чем у других компаний отрасли;
2. несколько лучше, чем у других компаний отрасли;
3. наравне с другими компаниями;
4. несколько или значительно хуже, чем у других компаний отрасли.

Компании, выбравшие первый и четвертый варианты ответов, считались лидерами и аутсайдерами отрасли соответственно. Что интересно, от аутсайдеров компании лидеры отличались следующим:

• в пять раз чаще использовали аналитику;
• в три раза чаще использовали продвинутую аналитику;
• в два раза чаще использовали аналитику для управления своей операционной деятельностью;
• в два раза чаще использовали аналитику для составления стратегий будущего развития.

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

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

Таблица «Уровни аналитических возможностей: желательный, опытный, преобразованный»

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

• в четыре раза выше вероятность качественного отбора информации;
• в девять раз выше вероятность качественной обработки информации;
• в восемь раз выше вероятность качественного анализа;в десять раз выше вероятность качественного распространения информации;
• на 63 % чаще используют централизованные аналитические отделы в качестве основного источника аналитических данных.

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

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

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

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

Ошибка вторая. dwh или его отсутствие.

Бывает, что перед внедрением собственно системы подготовки автоматизированной отчетности, никто не озаботился тем, что все-таки было бы неплохо иметь хранилище данных (DWH). В результате, это приводит к тому, что OLAP или отчеты обращаются к большому числу источников данных, различным витринам, которые сформировались на 3-ей стадии.

Выбору системы для DWH тоже нужно уделить отдельное время, но зачастую это та же СУБД, на которой работает учетная система (УС). Такой подход вполне оправдан, так как в компании уже есть специалисты по продукту и может получиться экономия на лицензиях.

Конечно, это не относится к случаю, когда в УС копится очень много данных (большое количество транзакций и СУБД выбиралась именно для этого) и лучше поискать другую СУБД, более подходящую для задач аналитики (есть механизмы колоночного хранения, размещение таблиц в оперативной памяти и т.п.).

Еще возможен вариант интеграции учетной системы с неким BI инструментом (видел предложения 1С QlikView, от некоторых интеграторов), но тут я не совсем в курсе как всё устроено. Буду рад, если кто-то напишет об этом в комментариях или в личку.

Ошибка первая. спонтанный выбор системы.

Как это бывает? Поскольку тем самым человеком может быть либо лицо высокопоставленное, либо весьма про-активный специалист от ИТ, отдающий предпочтение некому продукту, на выбор системы не отводится никакого времени, а просто покупается то, что пролоббировали эти люди.

Думаю, что перед выбором следуют ответить хотя бы на следующие несколько вопросов (подробнее я писал об этом в

Хотел бы еще добавить сюда добавить вопрос, о котором умолчал ранее:

Поясню суть вопроса. В некоторых системах можно довольно просто поделить функции следующим образом: ИТ отвечает за разработку моделей данных, а уже аналитики занимаются dashboard’ами, отчетными формами — тем, что видят конечные бизнес-пользователи. Зачем это?

до которой не всегда есть дело

на которую не хватает времени у ИТ, их дело — чтобы все это работало. Это особенно важно, если у вас хорошие разработчики с БОЛЬШОЙ зарплатой.

Дабы избежать проблему, терапию надо начинать своевременно. Хорошо, если на 2-ой-3-й стадиях ИТ систематизирует потребности, отвечая на первый вопрос и подталкивает бизнес к вопросу о внедрении BI. На этих стадиях заказчики полны энтузиазма и готовы обсуждать разные варианты, а главное — сформулировать свои требования, что, по моему мнению, является основной задачей бизнес-пользователей в этом проекте (опять же см. предыдущую статью).

Разделение задач

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

В зависимости от задач и объемов, преобразованные данные могут размещаться в локальные файлы, в БД, в облако — да куда угодно. Ключевое требование — минимальное время загрузки в RAM и возможность выборочной загрузки для больших объемов.

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

Работать с текстовыми данными в R достаточно удобно. Однако, утечка памяти, на которую могут жаловаться в случае процессинга текстовых данных, скорее всего бывает связана со спецификой архитектуры R — наличие global string pool.

Судя по анализу памяти, даже после удаления текстовой переменной и вызова gc(), сама строка остается в пуле — для внешнего наблюдателя «память течет». Это ни хорошо и ни плохо. Это архитектура среды, которую в задаче ETL можно обойти просто выполнения независимых блоков препроцессинга в отдельных процессах ОС, например, используя пакет callr.

Задача препроцессинга заканчивается генерацией чистых форматов. Сохранять данные можно разными способами. Если данных чуть больше чем много, то сохранять надо исключительно в бинаризированном виде (БД или файлы) и никаких CSV. При сохранении в БД надо учитывать еще большие накладные расходы на передачу по сети.

Ниже посмотрим, что можно сделать в отдельных случаях. Смотрим по умолчанию в контексте эпизодической ad-hoc аналитики, хотя большинство решений может быть применено и в потоковом продуктивном контуре.

Создание гибкого отчета “ad-hoc report”

Код для загрузки данных:

Модель, которая получается после загрузки данных:

Таблицы [Перечень измерений] и [Перечень метрик] являются Data Island, т.е. таблицами, у которых отсутствуют взаимосвязи с главной таблицей.Формируем лист “Add-hoc отчет”
Первоначально, нам необходимо создать обычную таблицу типа “Straight table”. На лист документа QlikView добавляем фильтры, с помощью List Box элементов.
Далее добавляем два List Box, в которых будут отображаться поля [Наименование измерения] и [Наименование метрики].
После этого формируем Straight Table, в которой выбираем 3 измерения и формируем 3 формульных выражения (НДС, Продажи, Среднее значение продаж).

Таблицы [Перечень измерений] и [Перечень метрик] являются Data Island, т.е. таблицами, у которых отсутствуют взаимосвязи с главной таблицей.Формируем лист “Add-hoc отчет”
Первоначально, нам необходимо создать обычную таблицу типа “Straight table”. На лист документа QlikView добавляем фильтры, с помощью List Box элементов.
Далее добавляем два List Box, в которых будут отображаться поля [Наименование измерения] и [Наименование метрики].
После этого формируем Straight Table, в которой выбираем 3 измерения и формируем 3 формульных выражения (НДС, Продажи, Среднее значение продаж).

На вкладке Expressions добавляем три выражения:
Label ‘НДС’:

Label ‘Продажи’:

Label ‘Среднее значение продаж’:

Для того, чтобы наша таблица вычислялась только тогда, когда пользователь выбрал измерение и метрики в List Boxes, нужно задать в поле Calculation Condition выражение:Данное выражение позволяет оптимизировать работу приложения (когда никаких выборок нет, таблица не будет занимать ресурсы сервера).

Для того, чтобы наша таблица вычислялась только тогда, когда пользователь выбрал измерение и метрики в List Boxes, нужно задать в поле Calculation Condition выражение:Данное выражение позволяет оптимизировать работу приложения (когда никаких выборок нет, таблица не будет занимать ресурсы сервера).

Далее переходим к формированию условий “Enable Conditional” на измерениях:

На листе Expressions добавляем условия по каждому выражению:

Демонстрация работы:

Создание и совершенствование новых методов аналитики с помощью ии

Технологии искусственного интеллекта и машинного обучения легли в основу многих перспективных аналитических инструментов в 2020 году. Расширенная аналитика позволяет оптимизировать существующие бизнес-процессы, а также генерировать новые инсайты, которые доступны уже не только специалистам по big data, но и руководителям компаний, смежным сотрудникам.

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

Стадия третья. зачатие (эмбрион).

После всех этих процессов в компании начинает образовываться направление, именуемое бизнесом «аналитики». Так, в компании может появиться SQL-разработчик (с этого я начал путь) и специалист/ты, владеющие Excel и прочими программами из пакета Office. Развитие на этой стадии может проходить по-разному.

Я лично видел, что со временем количество аналитиков может стать довольно большим (каждое подразделение обзаводится 1-2 специалистами или же в компании образуется отдельное подразделение). Я, кстати, мог оказаться и в этой роли, но мне повезло, что в университете меня не учили Excel’ю и на первом собеседовании тетенька из отдела HR сказала «ай-ай-ай».

Мои уверения её в том, что я быстро (за пару недель) освою сей продукт, скорее всего, породили в ней мысль: «Явно передо мной самоуверенный болван, ибо у нас тут другие тетеньки годами работают на компутере и все еще боятся этого зверя, а этот наглый шкет такое заявляет».

Числовые показатели. немного трюков

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

Насчет десятичного разделителя, увы, нет четкого стандарта. Рекомендуемые символы — . или ,, встретить можно и то и другое. В R точка является штатным разделителем, поэтому приводим к нему. Пропускаем базовые методы, берем пакет stringr и преобразуем подобным образом:

dt[, energy_num := as.numeric(stri_replace_all_fixed(energy, c("-", ","), c("", "."), vectorize_all = FALSE))]

На этом можно было бы остановится и большинство делают именно так. Но попробуем сделать еще пару шагов.

Шаг 1. Использование форматного сканера.

Большинство функций форматного ввода данных в различных языках берут начало от C-шной функции printf(), либо просто являются интерфейсом к ее реализации. Однако, в C существует и обратная функция scanf() — форматный ввод. Т.е. можно не заниматься модификацией исходной строки, а модифицировать настройки парсера.

Шаг 2. Смотрим по сторонам.

Итог.

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

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

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