Комментарии 16
Как мне кажется простой data warehouse, 1 простой ETL и пара SQL запросов могли бы резво и надежно подсчитать все это (на любых размерах данных).
алгоритм примерно такой:
1. вытаскиваем 1 день данных из OLTP базы в OLAP staging table в DWH используя SSIS
2. проставляем transaction_id согласно установленным правилам -> сначала для строк с законченной транзакцией, затем для выпавших на шаге N-1 и проставляем сразу статус транзакции
3. считаем аггрегации по измерениям и кладем их в куб
4. визуализируем куб в Qlik/PowerBI/Tableau
какие выгоды от этого процесса для компании:
1. ETL работает как часы по установленному графику и работает быстро т.к. использует ресурсы сервера
2. сам процесс может быть разбит на несколько частей (etl, sql, visualization) и распределен на нескольких людей для командной работы/масштабирования процесса
3. используются более старые и проверенные в ентерпрайзе технологии SQL, SSIS, DWH которые изобрел еще дядюшка Кимбалл в мохнатые 80-ые
4. специалисты по SQL дешевле чем спецы в R
в целом конечно соглашусь, такие подходы тоже используются.
Кстати, в случае с анализом событий все несколько хуже. И данные неструктурированные (сплошной поток сознания) и события в совершенно разных базисах и не одним OLAP приходится довольствоваться. Конкретно здесь за кадром еще есть и потоковый препроцессинг и очереди и бэкенды и хадупы и прочий обвес.
Я просто из большого комплекса одну частную задачку выдернул, интересную саму по себе. Неряшливость и неразборчивость в применяемых пакетах, функциях и алгоритмах на малых данных выходит боком на уже на данных среднего размера. Что можно очень хорошо продемонстрировать и предложить обратить внимание на data.table, например. И поговорить про способы оптимизации и трюки, которые я указал в конце.
Насчет хардкорности согласиться будет сложнее. Тут реально кода по анализу и восстановлению десяток строчек. Больше на судоку похоже, чем на квантовую механику. Навык эффективно использовать железо весьма полезен и для разработчиков и для аналитиков.
Сам же приведенный блок также используется в генерации Rmarkdown отчетов, в которых есть и картинки и таблички и масса различных алгоритмов по анализу данных и загрузка из других источников и выгрузка наружу (side-effect). Это несколько больше чем визуализация куба. Причем $0 за лицензии.
Я сознательно сфокусировался на одном малом шаге, потому как он хорош и для обучающих целей.
P.S. Кстати, а что значит "на любых размерах"? И сколько это стоит? И сколько будет исполняться.
Конкретно в таких задачах мы остановились на Clickhouse в качестве аналитического бэкенда. $0 за лицензии, несколько терабайт в хранилище (пока) при сжатии ~85% на грамотный запрос дают от долей секунд до сотен (уж что написать...).
А за развернутый комментарий отдельное спасибо.
1. Как раз в вашем случае, когда разные базисы и полный зоопарк технологий и следует использовать Data Warehouse, как единый источник для аналитики. Именно в этом warehouse данные из сотен разных систем причесываются и приводятся к одному базису и проставляются внешние ключи к общим справочникам по всему ентерпрайзу (например бухгалтерия, учет кадров, производство, продажи и т.д.)
2. Почитайте любую книгу Ralph Kimball, это он патриарх и идейный лидер такого понятия как DWH и BI, там он затрагивает вопросы архитектуры — как в типичной огромной американской корпорации поставить на поток процесс анализа данных из зоопарка разных систем. Также он затрагивает вопросы контроля качества данных, когда данные нужно отбрасывать и возвращать отвественным людям на исправление, когда пропускать с пометкой, и т.д. — потому что любой анализ хорошо настолько, насколько точны и качественны данные. И тут важен не сам факт, что справились ли вы как аналитик с анализом и соединили точки воедино, а то, что должен быть выстроен процесс по контролю качества данных и улучшени. бизнес-процессов которые генерируют эти данные.
3. В ентерпрайзе обычно стоимость софта особого значения не имеет, и опенсорс не имеет преимуществ перед коммерческим софтом, зачастую наоборот. Потому, что в ентерпрайзе важно чтобы решение работало сразу из коробки, и сразу был доступ на основе Active Directory и интеграция с ITSM системой. Я например использую большой кластер Tableau Server, который стоит миллионы долларов, но зато там авторизация на основе Active Directory, движок данных Hyper который разработали PhD-шники из Стенфорда, готовый экспорт данных в PNG для презентации большим боссам и работу из iPad-а который у шефа который везде летает на корпоративном самолете и нету времени на встречу — вся коммуникация через комплекс дешбордов и мониторинг выставленных ключевых метрик по организации с 60+ тыс человек.
>> P.S. Кстати, а что значит «на любых размерах»? И сколько это стоит? И сколько будет исполняться.
бекенд обычный SQL Server 2008 на обычном сервере. Можно обойтись postgres при желании.
Под любыми размерами я имел в виду то, что терабайтные массивы данных аггрегируются в мегабайты аггрегаций.
Базовый принцип — давать человеку, принимающему решения, ровно столько данных, сколько нужно для принятия решения. Размер данных аггрегаций достаточных чтобы построить график изчисляется мегабайтами, и тут больше вопрос в качестве данных, нежели в технологии. Лучше потратить неделю на общение с бизнесом и с человеком, который будет смотреть на аналитику и принимать решения, чтобы итеративно построить то, что ему нужно — чем лопатить терабайты данных и забросать данными пользователя, чтобы у того голова вообще перестала работать от информационного шума.
Понятно, наболело, видимо.
Но это все немного в стороне от исходной темы публикации, а именно, business process mining на R и трюки по сильной оптимизации. Это именно аналитическая задачка имеющая широкий спектр применения. Не было ни слова ни про саму глобальную задачу, DWH и ETL вообще не затрагивались и не обсуждались. Повторюсь, это всего-лишь маленький фрагмент из большого пазла. Кулисы я не планировал отдергивать.
В публикациях интересно делиться маленькими полезностями, чем бесконечными рассказами о том, как лопатами вагоны данных разгружали.
У меня тоже имеется ряд наблюдений.
- Далеко не все жители России живут на Рублевке и ездят на Майбахах. Равно как далеко не все компании могут позволить себе Tableau Server за миллионы долларов (кстати, есть подозрение, что Looker ныне будет поперспективнее Tableau).
- Большой enterprise настолько неповоротлив и бюрократизирован, что за время, пока что-то там соберут в корпоративном контуре на правильных решениях по требования функционального заказчика, стек DS позволяет прокрутить и сделать прототипы таких и подобных задач десятками раз и отклонить 90% исходных требований, как бесполезные. Как правило ФТ пишутся, но мало кто думает о том, а нужны ли они реально и как потом с реализацией работать. Но это все лирическое отступление.
А что касается Process mining в реале, то DWH — это лишь один из возможных вариантов. Я вот в сторону Data Lake поглядываю.
- как то все говорят "суровый" энтерпрайз, "кровавый" энтерпрайз.
Можно примеры компаний? Просто многие компании можно даже охарактеризовать "жизнь не обнаружена". - А нужен ли он в реале? Не так, что "нужен-нужен, дайте 2", а "нужен для того, чтобы ...."
2. Нужен для того, чтобы иметь нужную информацию оперативно, а не по состоянию, в лучшем случае, на вчера. Ошибки загрузки данных в DWH — типовая проблема, например, в одном крупном ритейлере.
Кроме того, можно хранить данные «на всякий случай», когда не знаешь, какие из них могут понадобиться. На них можно проверять гипотезы, гибко (по сравнению с DWH) строить отчетность, дашборды и т.п.
ага, SAP = "суровый, кровавый" :)
странно, но каждый в комментариях пишет о своем, мало соотносящимся к исходному тексту и исходному посылу. наверно, я что-то не так написал.
между business process mining (это аналитическая работа, включая генерацию последующих бизнес инсайтов и рекомендаций) и ошибками загрузки данных в dwh (классический инфраструктурный мониторинг, "zabbix"!) нет никакой связи. вообще никакой.
А так, конечно да. Для DS группы надо иметь оперативную помойку на 1-2 месяца для того, чтобы гипотезы проверять. Никакой dwh тут близко не подойдет. Помойка она есть помойка, структуры там почти 0.
Как демонстратор технологии предмет статьи неплох. Но не более. Можно даже попробовать что-то реализовать, чтобы показать бизнесу. Правда, не DS подразделение этим будет заниматься.
Но когда в системном ландшафте несколько десятков систем — ERP, CRM, SRM, MES, MDM, PDM и т.п., и процесс OrderToCash размазан между ними, нужно уже искать промышленные решения за много денег.
Утверждение сильное, но ничем не подкреплено.
- Для постоянного мониторинга исполнения процессов вообще есть отдельная область — BPM платформы. (Pega, Lombardi и пр.)
- Полный кейс, выдержку из которого я включил в публикацию, практически идентичен исходным условиям, что Вы описываете. И работает именно DS команда, а аналитики много-много лет вкусно, но безрезультатно совещаются.
- При четкой постановке задачи (имеющей бизнес-актуальность), вся эта ИТ сложность может быть сильно редуцирована. В частности, приближенные вычисления с точностью 95% за $X и M месяцев всегда ближе бизнес-заказчику чем 100% за $1000X и 100M.
Культура работы с погрешностями и приближенными вычислениями утеряна. Все хотят точность 10 знаков после запятой, а сами исходные данные идут с точность 1 знак.
Можно освежить память хорошими древними учебниками, ну, например, "Справочник по элементарной математике. Выгодский М.Я."
Кстати, а никого не травмирует, что в ML почти везде используется sampling?
2. Ну бывает. Однако по моему опыту, лучшие результаты получаются, когда DS и аналитик это один и тот же человек. Также, по своему опыту, встретить DS, который бы хоть как-то в процессах управления данными разбирался, и видел картину в целом, еще ни разу не удавалось. Хотя видел я их очень много.
То, что культура работы с погрешностями утеряна, полностью согласен. Также отмечу, что культуры работы с данными в общем-то и не было никогда.
Celonis красив на презентациях, еще лучше он в интеграции с ServiceNow (у вас его случаем нет?). В реальности бесплатная версия поддерживает до 500 мб excel файл (могу чуть ошибиться в числах). Но запустить его как-то не получилось, чихал долго.
Собственно говоря публикация получилась после одновременного драйв теста Celonis и ручной сборки на R. До финиша доехал только один, таймер остановили и второго отложили в сторону, ибо концептуально задача была решена, а работать с западными вендорами стало трудно и дорого у нас. Особенно с облачными.
А еще ServiceNow в районе 2014 года прикупили хорошую контору по мониторингу бизнес приложений (микс discovery, AppPerf, busines-process monitoring, app CMDB), Neebula и переосмыслили ее. Тоже штука.
А на минипроект с Celonis деньги найдутся, его как раз обосновать — не проблема.
Во, круг замкнулся. Он у Вас почти такой же, что пришлось видеть в кейсе (Celonis тоже маячил в фантазиях). Мы его разорвали путем экспресс-анализа средствами DS (Clickhouse в бэкенде ничуть не хуже Vertica). Дешево и сердито. Зато теперь у бизнеса фокус совершенно изменился. И болит не там, где казалось, и вскрылось масса чего интересного и непонятного, и обнаружились причины хронических проблем…
Бизнес-процессы в enterprise компаниях: домыслы и реальность. Проливаем свет с помощью R