Какая связь между рутиной и интеграционными задачами?
- На протяжении всего рабочего дня как обычных пользователей, так и руководителей разного ранга ИТ используется только как средство для принятия решения и исполнения набора в большинстве случаев ритуальных действий в бизнес-процессе.
- Пользователи окружены несколькими кусочно-интегрированными информационными системами и для принятия решений необходимо посмотреть в «десять» источников, немного «подточить» данные, что-то домыслить, и повозить мышкой в Excel сообразно своему уровню знакомства с MS Office и математикой.
- Для реакции, более сложной, чем «заполнить 5 экранов и прокликать Next-Next-Next» необходимо «нажать на капу», чтобы запустить мини-проект на недельку-другую, по внесению корректирующих действий.
Классический подход для автоматизации подобных задач — привлечение консультантов по бизнес-процессам; формирование предложений по переходу на единую платформу с глобальной интеграцией; анализ и выбор; RFI/RFP; тендеры; многолетнее внедрение; какой-то результат за огромные деньги на морально устаревшей за время внедрения платформе.
Конечно, я немного утрирую, но даже время и деньги, потраченные на бесконечные групповые совещания при проработке решения, стоят десятки миллионов рублей в ФОТ (фонд оплаты труда), а многие инициаторы к окончанию проекта уже работают где-то в другом месте.
Парадоксально то, что на самом деле для приемлемого удовлетворения исходных потребностей достаточно было всего лишь оперативно осуществить локальную «сшивку» данных, их обработку и доходчивую визуализацию. При этом, когда переходишь на язык аналогий реального мира и говоришь в терминах ремонта и строительства дома, то всем все очевидно и никто не предлагает из-за порванных котом обоев незамедлительно строить новый дом.
Поэтому мы решили воспользоваться для решения подобных задач теми инструментами, которые есть в сообществе Data Science. Минимальный набор, который нас полностью устроил — язык R, IDE – RStudio, интеграционный шлюз — DeployR, сервер клиентских веб-приложений — Shiny. Когда говорим о визуализации, то естественно, это никак не PieCharts, а современные эргономичные принципы подачи информации, включая интерактивные JS элементы.
Важно, что на первичном этапе все продукты используются в формате open-source или community edition. Если вдруг окажется, что задача решена суперуспешно и необходимо ее расширить и ускорить, то у каждого компонента есть коммерческая версия за очень низкую стоимость, устраняющую масштабные ограничения бесплатных продуктов.
Где же про Big Data?
Решая практические задачи, мы еще раз убедились, что мир Big Data крайне ограничен и востребован, в основном, большими ИТ или сетевыми компаниями. Изначальная трактовка термина Big Data, как объема данных, не вмещающихся в рамки оперативной памяти компьютера, с учетом развития вычислительных средств теряет свой смысл для рядовых задач. В ноутбук можно поставить 16 Gb, в сервер ~ 500 Gb, а в облаке можно вообще заказать сервер с 2Tb DDR4 оперативной памяти + 4 Tb SSD (Amazon EC2 X1).
Для удобства обозначения в рамках рабочих процессов таких данных, которые вроде и большие, но все равно меньше объема RAM вычислителя, мы приняли термин Compact Data.
Так вот, в реальных задачах обычных компаний Compact Data вполне достаточно для принятия решений с требуемой точностью и быстротой.
К сведению, коллеги из Google вообще переводят разговор с пространственных размерностей во временн`ые: «Для меня термин Большие Данные относится отнюдь не к размеру данных. Речь идет о трансформации часов упорной работы по анализу данных в непринужденную обработку в течении секунд», — Felipe Hoffa, Google software engineer.
R success stories
В качестве первой success-story мы вынесли за неделю очередную BI систему. Совершенно неожиданно выяснилось, что руководство недовольно отчетностью из систем, которая есть в настоящий момент. Поэтому на протяжении полугода проводился отсмотр, анализ и даже пилот BI системы из числа финалисток. Договор на поставку и внедрение лежал уже на столе у руководства. В последний момент мы просунули ногу в дверь и попросили 3-4 дня на то, чтобы сделать альтернативный стенд на базе инструментов R. За эти 5 дней вдвоем мы успели повторить вчерне весь скудный пилотный функционал BI (частично на синтетических данных сторонних ИС), добавить массу дополнительной аналитики на дашборды, выявить пару дыр в эффективности работы подразделения, прикрутить прогнозную аналитику. Соответственно, через неделю договор с BI лежал там, где ему и полагается (мусорная корзина), а мы получили карт-бланш на реализацию. Через полгода проект был заморожен в развитии, как достигший вершины желаний руководства и пользователей. Попутно при разработке мы тормознули еще один тендер по расширению существующей системы (а, на секунду, это почти ~$400k) и сделали все, что было нужно для бизнеса, сами.
Следующий Data Science кейс появился в контексте модной задачи «умного земледелия», а именно контроль полива растений. Простой вопрос «сколько литров лить?» поднимет целый ворох задач. Это калибровка и сбор данных с разнообразных датчиков, которые данные собирают нерегулярно и крайне неточно (например, для измерения влажности почвы по-другому не получается) и оптимизация георазмещения этих датчиков и построение взвешенного прогноза погоды по бесплатным куцым данным и сложная физико-математическая модель обмена водой растением в зависимости от текущих условий. А еще надо все понятно и доходчиво интерактивно все это отобразить на компьютере агронома. Примерно через 3 месяца работы прототип был собран. Причем все сделано на упомянутых выше инструментах R + bash.
Чем еще привлекателен R в отличии от различных мышевозилок?
- Это полноценный язык программирования. Последние пакеты Hadley Wickham подняли R по удобству работы с данными почти на космическую орбиту. Также активно расширяется поддержка функционального программирования.
- Широчайший спектр математических пакетов и алгоритмов.
- Элементарно встраиваем в devops. Исходники в git, есть механизм автотестов, возможность самодокументирования (R Markdown). Совместная работа и применение agile методологий.
- StackOverflow community.
- … и много других плюшек.
Выводы
Сейчас идет активная работа еще над парами задач, но полученный опыт в целом позволяет уверенно браться почти за любую задачу в задаче локальной «сшивки». Вообще, ощущение от возможностей R обычными пользователями можно описать такой картинкой:
Если обобщить опыт, то подобная «сшивка» востребована практически везде. Главное посмотреть свежим взглядом (читаем литературу про ТРИЗ и про изобретения, опоздавшие на сотню-другую лет), а руководству не побояться рискнуть. Принципиальный тезис при старте такой активности — продвижение малыми шажками.
В идеальном случае в результате работ появляется небольшой компонент, который:
- собирает данные из всех необходимых источников и проводит закулисную сложную обработку;
- выдает пользователю красивую интерактивную картинку (wow эффект желателен, но не самоцель);
- в дополнение к картинке выдает развернутый интерактивный отчет и рекомендации по выбору оптимального решения;
- по мере возможности самостоятельно выполняет требуемые изменения в других информационных системах (зачатки операционной аналитики).
Рамки работ сознательно ограничены 2 месяцами максимум. Итеративная и интерактивная разработка, как правило, позволяет за этот срок концептуально решить локальные проблемы в разрыве различных ИС. После завершения работ необходимо «погонять» полученный компонент в реальных бизнес-процессах, сопоставить полученный эффект с ожидавшимся. Если остались задачи или появились новые, то расставить приоритеты и приступить к новой итерации.
Важно то, что каждая итерация:
- основана на реальных бизнес-потребностях;
- приносит реальный эффект для бизнеса;
- закончена и самодостаточна.
При этом нет никаких накладных расходов на тяжеловесное проектное управление, задача обозрима по масштабу, документация создается только минимально необходимая.
Еще раз отмечу, что вряд ли речь будет идти Data Science, как сложных математических алгоритмах в применении Big Data. Реальные задачи бизнеса гораздо прозаичнее, но выгоды от их решения могут быть очень и очень большими. Инструменты R и подходы Data Science могут в этом замечательно помочь.
Самое замечательное, что интрига сохраняется до последнего. Вы никогда заранее не знаете, какой будет следующий шаг и следующий запрос после, а грамотные руки и светлая голова могут не только помочь исправить текущие недочеты, но и предложить новые бизнес-возможности.
Комментарии (58)
Klimmy
06.09.2016 07:27+1Интересно, спасибо!
Подскажите, нет ли у вас примеров кода такого компонента в открытом доступе?
i_shutov
08.09.2016 10:04Климент, добрый день.
Не совсем понял про какой компонент идет речь. Исходный код большинства пакетов можно посмотреть либо на github, либо в директории установки пакетов. Или интересует пример под какую-то конкретную задачу?
OlegUV
06.09.2016 09:22+1Не могли бы вы показать какие-то стандартные отчёты (с обфусцироваными данными, конечно)?
Желательно с описанием процедур дата-флоу, где-что-как рендериться и т.д.
То есть, если можно, больше конкретики.i_shutov
06.09.2016 12:30Картинку с рабочего портала постараемся приложить чуть позже, надо вытереть якорные поля. Сама система обслуживает несколько миллионов людей, это к вопросу о масштабе.
i_shutov
06.09.2016 17:50А вот и пара скриншотов:
Это, отнюдь, далеко не все представления, а интеграционная и математическая механика под капотом. Как видно из скриншотов, все это происходило почти год назад. Сейчас мы бы использовали новые пакеты, например, flexdashboard. Но при отсутствии бизнес-драйвера (позиция руководства прагматична: все работает и устраивает, зачем переделывать?), нет смысла возвращаться в прошлое, а личное время лучше уделять семье и детям.
i_shutov
06.09.2016 12:34+1В качестве интересного примера, приведу портал Министерства туризма Новой Зеландии, который построен на R Shiny. Дешево и сердито.
New Zealand Tourism Dashboard. The New Zealand Tourism Dashboard is a one-stop shop for all information about tourism. It brings together a range of tourism datasets produced by MBIE and Statistics New Zealand into one easy-to-use tool. Information is presented using dynamic graphs and data tables.
sergeypid
06.09.2016 09:27+2Советую поменять заголовок и переписать первую половину статьи. Я с трудом понял о чем речь, а открыл только потому, что подумал: «Какая может быть связь между continious integration и data science? они что, ошибки в коде отлавливают методами машинного обучения?»
Когда прочитал статью до конца, очень понравилось, добавил в закладки и проч. Но по счетчику показов видно, что мало кто Вас здесь прочитал.
Поддерживаю предыдущий комментарий — хотелось бы увидеть примеры конкретной реализации.i_shutov
06.09.2016 11:20+1Сергей, спасибо за комментарий.
Прежде чем поделиться своим опытом я проглядел хабр вдоль и поперек и не нашел ничего подобного. Пока была модерация в песочнице я подготовил еще один пост, в продолжение этого. Надеюсь, сегодня-завтра его смогу привести в порядок и опубликовать. Вопросы в комментариях, видимо, требуют еще одного поста в котором я кратко описал бы пакеты, которые использую для решения описываемых задач. Будучи по образованию физиком (если точнее, то физиком-экспериментатором), мне нравится использовать околонаучные вещи и подходы в бизнес-задачи. А почему бы нет? Опыт показывает, что это воздается сторицей. Как один из примеров — 15 лет назад перед нами стоял вопрос на чем запустить технологическую линию верстки в издательском процессе. Мы рискнули и отказались от классического варианта Word\FrameMaker и запустили на базе LaTeX. И не прогадали, автоматизация верстки была доведена до 80-90%, книги только текстом и картинками (худ. литература) вообще могли верстаться в автомате. Необходимо было только по диагонали проглядеть на предмет возможных висячих строк в сложных случаях и корректору поглядеть текст. На вход word файл, на выход — pdf для типографии.
Поэтому я решил поделиться опытом с R именно с теми, кто не равнодушен. Это не серебрянная пуля, но добротный набор инструментов.sergeypid
06.09.2016 12:19Респект за "околонаучный" подход. Этим вы сами создаете/развиваете технологию, в отличие от "профессионалов", которых обучают нажимать правильные кнопки в коммерческих программных продуктах, носить бейджики, водят на тимбилдинг…
i_shutov
06.09.2016 17:07Премодерация первой публикации заняла порядка двух недель. За это время подготовил продолжение. Тема оказалась воспринята, поэтому оперативно опубликовал. Там отчасти есть ответ на вопросы по реализации.
sergeypid
06.09.2016 09:40+1Несколько аналогов Shiny для Python:
Pyxley https://github.com/stitchfix/pyxley
The Pyxley python library makes use of the pyxleyJS React components to create Flask-based web applications.
Обзор
Spyre https://github.com/adamhajari/spyre
Spyre is a Web Application Framework for providing a simple user interface for Python data projects.
Plotly/Dash https://github.com/plotly/dash
Flask, JS, and CSS boilerplate for interactive, web-based visualization apps in Python
Выглядит симпатичнее других, но команда прекратила поддержку проекта.
Bokeh http://bokeh.pydata.org/en/latest/
Bokeh is a Python interactive visualization library that targets modern web browsers for presentation. Its goal is to provide elegant, concise construction of novel graphics in the style of D3.js, and to extend this capability with high-performance interactivity over very large or streaming datasets. Bokeh can help anyone who would like to quickly and easily create interactive plots, dashboards, and data applications.
Немного навязчивый PR но выглядит неплохо.i_shutov
06.09.2016 10:53С питоном мы имеем дело, начиная с 2006-года. Но, к сожалению, в части переработки, анализа и визуализации данных фреймворка со стройной структурой так и не удалось подобрать за разумное время. Поскольку решаем прагматичные задачи, то интересует лучший результат за кратчайший срок. Поэтому по состоянию на сентябрь 2016 года экосистема R нас полностью устраивает. Более того, мы понимаем, что ее потенциал раскрыт на 10-20%, не более и мы имеем возможность развития без резкой смены парадигмы.
OlegUV
06.09.2016 11:06Спасибо, как раз хотел спросить почему Р а не Питон.
Но опять, же, не могли бы вы добавить конкретики, что с чем сравнивалось при выборе?
Лично мне, например, связка Python+Django и на фронте JS визуализация D3 (C3 etc.) кажется 1) не имеющей потолка развития 2) очень хорошо поддерживается рынком труда, т.е. нет проблем со спецами
Тогда как с R ситуация не однозначная, по моему.i_shutov
06.09.2016 11:54Только в прошлом году мы имели опыт разработки на таком фреймворке. За 2 недели сделали прототип на R, бизнес согласился, что это хорошо. Решили перетащить («продуктизировать») на Python + Django. В итоге 8 месяцев работы «по-правильному» были выкинуты в корзину. А все потому, что за это время бизнес приоритеты успели измениться, и потребность в этом решении отпала. Сейчас слишком быстро все меняется.
Почему не Python? Потому что процессинг данных (а это основная механика решаемых задач) оказалась гораздо проще, приятнее и понятнее. Все благодаря труду Hadley Wickham, фактически, сформировавшего лицо современного R. А поддеркжа D3.JS в R есть. Ну и самим рисовать порталы с реактивными (reactive) элементами совершенно неинтересно. В экосистеме R эту задачу мы перекладываем на Shiny. Более того, мы знаем, что у R в части обработки данных есть огромный потенциал. Если вдруг не хватает бесплатных возможностей (у нас такого и близко не было), можно переехать на Enterprise edition (Microsoft) и получить поддержку и кластеров, и hadoop, и выхода за рамки оперативной памяти, и репозиторий снапшотов пакетов и пр…
sergeypid
06.09.2016 12:21Я просто позавиловал Shiny и решил как бы сделать закладку на будущее.
А на Java не сталкивались с аналогом Shiny? (знаю про гугл, хочу мнение человека с опытом использования).
AristarXXXX
06.09.2016 11:22Спасибо за статью!
Являясь одним из тех, кто «просунул ногу в дверь руководству» могу подтвердить, что результаты, которые можно получить «на коленке» обладая средне-базовыми знаниями R и покопавшись в библиотеках визуализации (замечу, что есть врапперы почти для всех популярных js библиотек построения графиков), весьма впечатляют руководство и отлично решают «бытовые» задачи. Кто спрашивал примеры отчётов — рекомендую просто покопаться в примерах на оффсайтах разных библиотек для R. Ниже пара ссылок:
i_shutov
06.09.2016 11:29Костя, спасибо.
Если не трогать классический ggplot2, то в части интерактивных виджетов можно заглянуть еще сюда: "76 registered widgets available to explore"
atikhonov
06.09.2016 13:42Еще, хороший пример различных shiny приложений.
Конечно, большая часть из них, shiny-style, но если делать в shinydashboard(+css+JS опционально), то получится вполне неплохо.
Vlad_fox
06.09.2016 12:02это был некролог по BI-системам?
по консалтингу бизнес-процессов и совещаниям?
пришел великий и могучий RRRrrrrrr!!! и смел все эти непонятные и следовательно ненужные автору статьи активности на свалку истории.
чем хоть занимается компания, в которой произошла сия замечательная революция?
а что если движ продолжить — выкинуть на свалку истории и R с кучей поддерживающих технологий, а заодно и нескольких наверное избыточно дорого для фирмы оплачиваемых спецов, и залепить все в Excel с Power Pivot одним продвинутым и смелым студентом?i_shutov
06.09.2016 12:22+1Vlad_fox: я бы не хотел, чтобы в комментариях началась эмоциональная переписка по далекой от изначальной мысли теме. Тем более, что мы с Вами не знакомы и у нас обоих нет никаких оснований полагать, что мы обладаем недостаточным опытом, чтобы принимать взвешенные решения. Консалтинг бизнес-процессов никто не отметает, когда-то я даже занимался этим и в Киеве. Но речь то совсем не об этом. Инструменты и подходы постоянно меняются, появляются очень интересные и красивые вещи, которые можно приземлять для решения практических бизнес задач. Додумывать что-либо сверх написанного можно, но это будет слабо относиться к тексту статьи.
Vlad_fox
06.09.2016 12:46-2только факты, уважаемый Ватсон, только факты:
Конечно, я немного утрирую, но даже время и деньги, потраченные на бесконечные групповые совещания при проработке решения, стоят десятки миллионов рублей в ФОТ (фонд оплаты труда), а многие инициаторы к окончанию проекта уже работают где-то в другом месте
— проясните, как именно выбор предложенного решения на базе R вместо BI решения позволил устранить вышеописанный негативный эффект.
Классический подход для автоматизации подобных задач — привлечение консультантов по бизнес-процессам; формирование предложений по переходу на единую платформу с глобальной интеграцией; анализ и выбор; RFI/RFP; тендеры; многолетнее внедрение; какой-то результат за огромные деньги на морально устаревшей за время внедрения платформе
— из статьи я так и не смог понять какой конкретно «некласический» поход взамен был предложен?
могу предположить — от консультантов отказались (чем заменили), от единой птатформы с единой версией истины отказались (если нет, то чем построение такой платформы на R легче, дешевле чем на BI), от анализа и выбора тоже отказались (много на этом съекономили денег и времени?), отказались от тендеров… вам разрешили обойти политику тендеров в компании для этого частного случая?
отказались от многолетнего внедрения BI системы (вообще-то это не обязательное условие — почитайте про саксесс стори внедрений той-же BI Qlikiew). Про морально устаревшую систему… разве на рынке представлены для выбора только морально устаревшие системы?
про огромные деньги… BI системы оценивают не по критерию «скоко стоит? скоко-скоко???!!», а по сроку окупаемости и положительному эффекту от внедрения. Но до этого понимания менеджменту компании надо еще дорасти…
ПС. прошу прощения за излишнюю эмоциональность, согласен, часто эмоции неуместны…
но мне действительно интересны ответы на вопросыi_shutov
06.09.2016 14:11+11. По поводу эффекта:
Эффект очень простой — снижение порога принятия решения до 0. Сейчас, когда без бюджетной статьи даже рулон туалетной бумаги не купишь, любая инициатива по приобретению ПО начинает рассматриваться в микроскоп. Чем больше бюджет, тем больше увеличение. Бюджетные комитеты, обоснования, совещания. Это может длиться не один год. Это и есть классический подход. Делается замануха в виде потенциального бюджета, приглашаются продавцы и консультанты от интеграторов и вендоров, которые бесплатно развлекают на этапе пресейла\пилота, дело доводится до закупок и тут… кризис, секвестор бюджета, смена руководства. Вообщем, начинай все заново.
При этом не стоит забывать, что в реальности к BI не было четких требований. «Нам вендоры должны рассказать, что надо хотеть». И есть пожелания по 5-10 отчетам, которые требовали на совещании у вышестоящего руководства. Все остальное — придумывайте сами. Интересует только РЕЗУЛЬТАТ, правда не всегда понятно, какой именно.
2. По поводу неклассического подхода.
Отказаться от многомесячной тендерной движухи в пользу решения конкретной задачи здесь и сейчас.
Для задач, не претендующих на всеобщность и не затрагивающую основной бизнес-функционал в явную, как, например, сайт в интернет-магазине, написать обоснование, даже с учетом горизонта окупаемости 3 года, очень тяжело. Слишком вероятностные и зыбкие статьи сокращения затрат.
R — бесплатен, поэтому не надо всей вышеупомянутой кутерьмы. Нет предмета закупки — нет тендера. Можем сделать сами — убедите на практике, дальше посмотрим. Мы убедили. Как я писал выше, средний срок «жизни» ИТ директора стремится к 1-2 годам. Поэтому всем надо, чтобы окупилось аж на следующий год.
Что касается Qlick\Tableau — это, в первую очередь, визуализаторы и инструменты для аналитика. С серьезной математикой там слабо, но есть коннекторы к R.
Они платные, см. выше. $2K тоже замучаешься обосновывать.
Не проще ли вместо круговерти обоснований сесть и сделать самому? Свое время сэкономить. Тем более, что все равно потом установки и требования поменяются и придется опять все адаптировать.
Ananiev_Genrih
06.09.2016 13:20Как то незаслуженно охаяли Power Pivot якобы студенческой песочницей.
Очень серьезный инструмент между прочим по своей экосистеме и востребованности (прежде всего в пендостане и европах, у нас поменьше но тоже развивается)
DAX язык достаточно гибок (ссылка на мою старую статью где затронут всего 1% от заявленного функционала языка: 1; 2), алгоритмы сжатия VertiPac позволяют спокойно тащить в модель на клиенте сотни миллионов записей сжимая их эффективно, в случае связки Power Pivot + Power Query вообще становится доступен полноценный ETL с доступом к гетерогенным источникам данных.
По поводу централизованной публикации модели для корпоративного использования — c конференции Microsoft вспоминаются бизнес кейсы одной из крупной компаний которая обходится без OLAP/SSAS (хотя это конечно очень странно по многим причинам) просто публикую модели Power Pivot на SharePoint сервер и их это устраивает.
Так что про студентов — «за державу обидно»
Ananiev_Genrih
06.09.2016 13:31Кстати в тему обиженной компании R /Power Pivot по части использования в BI (а так же
«почитайте про саксесс стори внедрений той-же BI Qlikiew»
) вспомнил интересную вещь:
Microsoft Power BI нативно поддерживает DAX язык от Power Pivot + «M» язык Power Query + R язык со всей своей шикарной экосистемой. Я думаю это неплохой ответ натолько факты, уважаемый Ватсон, только факты
Ananiev_Genrih
06.09.2016 13:36Так же на борту помимо дефолтных визуализаций есть и поддержка кастомной графики
Есть и бесплатная Power BI DesktopAristarXXXX
06.09.2016 22:18День добрый!
Имею небольшой опыт работы с Power BI. Впечатления двойственные.
Была задача подтягивать данные из 1С и сделать «чтобы всё было красиво». Инструмент удобный, функциональный и т.д., но с одним большим НО (по крайней мере на момент 2015 года). У него невозможно настроить автоматическую актуализацию данных. Т.е. возможно, но для этого поднимается платный (помимо подписки Microsoft) Gateway (кажется, так называется), который нужно ставить отдельно и через него цеплять данные. Плюс (опять же на момент 2015 года) были некоторые странности при экспорте из десктопной версии в облако (например, плыли выбранные вручную цвета для отдельных элементов). Также документация была слабовата, да написана по неактуальной версии (даже синтаксис отличался). Так что имейте в виду…
Однако я верю, что недостатки поправят (или уже поправили), а с приходом R к Microsoft там вообще всё очень хорошо (кстати, недавно узнал, что теперь можно из SQL Server 2016 дёргать сразу JSON данные, прямо праздник...).i_shutov
07.09.2016 09:48Насчет PowerBI не все однозначо. К текущей версии масса вопросов по возможностям, сложности внутреннего языка. Сам глядел только поверхностно + читал статьи и блоги. Коллеги пытались использовать, но результаты успешными не признали.
В ComputerWorld есть очень хорошая рубрика Sharon Machlis в которой ряд статей посвящен PowerBI, например How-To
Free data visualization with Microsoft Power BI: Your step-by-step guide, Microsoft ratchets up its R enthusiasm.
Слабоват пока продукт, но развивается очень быстро.
VStasevich
06.09.2016 16:01Это интересно. Альтернативный путь решения известных задач. А можно применить такие подходы не к аналитическим, а транзакционным системам? То есть использовать сшивки данных разных систем при проведении операций?
i_shutov
06.09.2016 16:08С такими задачами в «прошлой жизни» приходилось сталкиваться, например, в антифрод системах, если я правильно понял вопрос. Если не сложно, то можно более подробно описать задачу?
Вообще, это тоже отдельное интересное направление.
Ребята из Data Driven Security очень неплохо в этом продвинулись. Можно и их книжку почитать, есть на просторах интернета в pdf.
Или начать в качестве отправной точки с записи в их блоге: "Building [Security] Dashboards w/R & Shiny + shinydashboard"VStasevich
06.09.2016 21:26Сам подход интересен и рождает массу мыслей. Например, в средах с сотнями систем (аля банки) вместо того, чтобы строить новый светлый мир с одной централизованной АБС и выравненной моделью данных — делать процессоры, сшивающие данные из разных систем под конкретную задачу. То что мне близко — цифровые банковские продукты. Сбор данных и создание «единого правильного хранилища» решается не построением новой системы, а в realtime сбором-сшивкой-отображением. И самое интересное — в обратную сторону. Проведение операций/транзакций делается распространяя изменения в системах, несвязанных между собой, внося изменения на языке их моделей данных.
i_shutov
07.09.2016 09:39Это направление сейчас как раз интересует больше всего. Отчасти я упомянул один из решенных кейсов в следующей статье. По западной терминологии направление называется Operational Analytics.
Естественно, что в зависимости от объемов данных и скорости реакции должны использоваться различные подходы и платформы, но для не реал-тайм задач потенциала R (математика, фронтенд, сбор данных) + python\erlang (низкоуровневое взаимодействие с другими ИС\ парсинг нестандартных протоколов) мне пока более чем достаточно.
Data Lake и Agile Warehouse, если честно, воодушевляют только на словах. А внизу все равно много тяжелой и нудной работы.
vdmitriyev
07.09.2016 10:42Спасибо за то что поделились вашим опытом. У меня есть одна небольшая ремарка. В моем понимании BI специалист/консультант (или человек который отвечает за BI в компании) это не разработчик софта или BI решений, а больше очень продвинутый пользователь уже имеющегося ПО с отличным пониманием процессов анализа данных, статистики и бизнес-процессов в компании (тут по разному, и есть разница между внешним и внутренним BI консультантом). И очень часто подобный специалист не умеет или не хочет писать код своими руками. И это я не про скрипты по очистке данных, SQL запросы и т.д., а именно про функционирующие приложения на R, Python и т.д. для конечного пользователя (тут сложность выбранного пакета/языка зачастую не имеет значение, просто консультанты не хотят этим заниматься). Так что мне верится, что ваш опыт применим в таких компаниях, в которых уже есть достаточный штат сотрудников занятых разработкой ПО и опыт работы с разработкой ПО. Согласны ли вы со мной или я что-то не совсем правильно вижу?
i_shutov
07.09.2016 10:54Не совсем.
Data Science я упомянул неспроста. В текущем принятом понимании специалисты по Data Science должны иметь крайне широкий кругозор, включая математику, статистику, программирование, дизайн, а также обладать хорошими презентационными и коммуникационными навыками и глубоким знанием предметной области. И, самое главное, ему это должно быть интересно. Всегда есть 1000 и 1 способ объяснения, почему что-то не стоит делать, но пользы от этих объяснений нет никакой.
Поскольку объем решаемых задач не глобален (это 80% проблем в компаниях), двух-трех человек вполне достаточно для легковесного решения многих "проблемных" мест в бизнесе.
Не надо делать монументы там, где это мало оправдано, их все равно снесут. Сейчас век модульных конструкций, в т.ч. в строительстве, автомобилестроении, бытовом сегменте.vdmitriyev
07.09.2016 11:06Тут есть одно "но". Людей с таким набором навыков ("крайне широкий кругозор, включая математику, статистику, программирование, дизайн, а также обладать хорошими презентационными и коммуникационными навыками и глубоким знанием предметной области") и желанием заниматся именно анализом данных не очень много. В соответствии с этим получается и соответствующе высокие зарплаты (при понимании руководства что Data Science это именно-то что нужно, ваши 80% проблем в компании которые требуют не глобального решения). Так что иметь 2-3 человека в качестве сотрудников с подобными навыками это просто я бы сказал удача для компании.
Но вы все же вы согласны, что описанные вами методы (мне они очень по душе) не применяются (и скорее всего даже не будут) "классическим" BI консультантом?
i_shutov
07.09.2016 15:09С точки зрения навыков, тут не все однозначно. Можно начинать проект и с человеком, котрый не знает R, но имеет определенные навыки в смежных областях, обладает критическим мышлением и культурой командной работы. А еще должны глаза блестеть. Пара активностей у меня была построена именно таким образом.
У каждого человека, в том числе и BI консультанта есть выбор, что делать. Можно ходить по накатанной траектории. Можно проявлять любопытство, экспериментировать и, возможно, набивать шишки. Это уже относится не к знаниям, а к мировоззрению каждого отдельного человека.
knagaev
07.09.2016 11:21+1Огромное спасибо — кратко и ёмко написано.
Одна просьба — рука не поднимается написать «маленькая» :) — опишите, пожалуйста, (наверно скорее в новой статье) как вы построили процесс разработки, и главное что и как используете из инструментов.
Меня очень заинтриговала такая фраза
Последние пакеты Hadley Wickham подняли R по удобству работы с данными почти на космосическую арбиту.
Это о devtools или ещё что-то?
Чем они так помогают? Если можно на примерах.
Я давным-давно для собственного интереса разбирался с R, он мне с одной стороны понравился, но с другой стороны показался немного неудобным с точки зрения разработки (хотя, конечно же, это в подавляющей степени дело привычки).
Поэтому ушёл в экосистему python со всеми его пирогами, а особенно pandas, но ведь если вспомнить, то pandas была попыткой привнести в python немного R :)
А сейчас посмотрел на shiny и захотелось опять попробовать, но уже на другом уровне.
Поможете? :)
i_shutov
07.09.2016 15:15К R я подступался с 2011 года. Но вплоть до 2014 он не воодушевлял. Пока не произошла революция в подходах.
В части пакетов дал ответ в виде отдельной статьи: Джентельменский набор пакетов R для автоматизации бизнес-задач
Насчет помочь — предлагаю списаться через хабрапочту, а потом перейти на скайп. Я не знаю масштаба задачи, а свободное время — зверь, которого почти никогда не видишь.
knagaev
07.09.2016 15:23Под «поможете?» я подразумевал именно написание отдельной статьи с секретами практического использования R, то есть, совершенно неперсонализированный подход.
Поэтому отдельное спасибо за готовность списываться.
За джентльменский набор ещё одно спасибо — особенно хорошо, что с ссылками на статьи.
i_shutov
07.09.2016 15:44Приношу извинения за грубые орфографические ошибки (конечное же, космическую Орбиту). Текст исправил. Не ожидал, что прямо на фазе публикации придется много раз переписывать, остались обрывки предыдущих слов.
knagaev
07.09.2016 15:48Честно говоря, я это не воспринял как ошибку-опечатку — я думал, что это какое-то новообразованное слово, которое должно иметь смысл невероятных запредельных «закосмических» высот :)
Покрутил его и так, и так в голове, но потом решил, что не понял глубинной идеи и оставил как есть.
Мне кажется, что ошибки, которые не мешают понимать главную идею, можно не принимать в расчёт.
AristarXXXX
09.09.2016 17:01По пакетам Hadley Wickham — живой пример.
Только вчера делал. Надо было проанализировать 10 Гб Netflow статистики на предмет уникальных ip из определённой подсети (не спрашивайте, зачем, это другая песня). Лог надо было собрать из 170 заархивированных текстовых файлов. Файлы — обычный txt с разделителями пробелами. Причём не фиксированным количеством. В excel, как меня люди заверяли сходу вставить не получилось (да и объёмы не те).
Задача, в целом, банальная. Разархивировать, слить в общую кучу, найти уникальные. Можно хоть через grep и регулярные выражения написать (формат файлов одинаковый). Но файлы очень большие, разархивировать их долго, места они будут занимать много, да и вообще как-то не очень всё это…
В пакете readr есть функция read_table, которая может читать заархивированные файлы. Причём для них написан отдельный метод, так что даже не надо это отдельно указывать. Также она, в отличие от excel, с ходу определила какие колонки есть на основании первой 1000 записей (в мануале можно подробнее про механизм почитать), и, что самое классное, можно выдрать только данные той колонки, что нужны (и всё это из заархивированного файла).
Немного времени на написание кода и всяких "фантиков" типа сообщения количества оставшихся файлов и найденных уникальных объектов мы через минут 10 (за счёт промежуточного разархивирования файлов) имеем исходный список.
Кому интересно — код ниже:
Собственно кодlibrary(readr) library(magrittr) library(dplyr) # Смотрим все файлы. Файлы находятся в рабочей дирректории files_tmp <- list.files(path = getwd(), pattern = "*.gz") pattern <- "212.11" # пример пути к файлу # "netflow/212.11.128.0.2016.08.31.10.gz" # Выдёргиваем уникальные значения uniqueValues <- function(filePath, pattern){ # просто, чтобы инфа была в консоли cat(paste0("Чтение файла ", filePath, "\n")) # читаем файл, выдираем уникальные значение, убираем из них те, что не соответствуют фильтру tmp_all <- read_table(file = filePath, col_names = c("time", "src_ip", "dst_ip", "port1", "port2", "port3"), col_types = cols_only("src_ip" = col_character())) %>% unique() %>% filter(grepl(pattern, src_ip)) # просто для информации cat(paste0("Всего уникальных адресов соответствующих фильтру ", pattern, ": ", nrow(tmp_all), "\n")) # выводим результат return(tmp_all) } # Функция с циклом по всем объектам uniqueObj <- function(files, pattern){ # создаём пустой объект final_df <- NULL # количество файлов n <- length(files) # Просто для информации cat(paste0("Всего объектов: ", n, " . Ну, поехали!\n")) # запускаем цикл for (i in 1:n){ final_df <- bind_rows(final_df, uniqueValues(files[i], pattern) ) %>% unique() cat(paste0("Успешно слили данные из файла ", files[i], " в общую кучу\n")) cat(paste0("Уникальных значений: ", nrow(final_df), "\n")) # пишем промежуточный файл cat(paste0("Пишем промежуточный файл", "\n")) write_csv(x = final_df, path = "ip.csv") cat(paste0("Осталось прочитать файлов: ", (n - i), "\n")) } # конец цикла # Возвращаем значения return(final_df) }i_shutov
12.09.2016 11:31с учетом существующих пакетов возможны различные варианты для совершенства:
Вариант 1 (итераторы)
library(iterators) library(foreach) read_data <- function(n){ read_delim(... <<настройки функции-парсера>> ) } # пробегаемся по строчкам data.frame df <- foreach(it = iter(<<тут указываем список>>), .combine = rbind) %dopar% { # cat("----\n"); str(it); temp.df <- read_data(it) # читаем и сразу обрабатываем!! problems(temp.df) temp.df }
Вариант 2 (функциональный подход и pipes)
library(purrr) library(readr) dir() %>% map(read_csv) %>%
zxweed
Честно говоря, зная реалии отечественного бизнеса, очень странно, что вас не уволили со всеми волчьими билетами за срыв откатов по поставке огромного BI-решения (а тем более нескольких.) Ну и надо признать, что их функционал гораздо больше и ширше, нежели R, пусть даже с графическими пакетами.
OlegUV
Ну зачем же сразу откаты, бывает и без них, в стандартных BI и так достаточно преимуществ по сравнению с альтернативными решениями.
i_shutov
Комментарий комплексный, отвечу по частям.
Во-первых, изменение курса рубля вывело стоимость западных решений в «запредельный космос» и потребовало пересмотра классического подхода к выбору решений от крупных западных вендоров.
Во-вторых, бюджеты на ИТ достаточно сильно поджимаются. ИТ как драйвер для бизнеса так себя и не проявила, средний жизненный цикл ИТ директора составляет 1-1.5 года. В третьих, на уровне государства в жизнь активно внедряется система KPI. Посмотрите, что происходит в образовании, здравоохранении и гос. услугах. Во многих ИТ службах появился KPI, связанный с сокращением затрат (как на оборудование, так и на персонал) и повышением эффективности. Но при этом обязательно необходимо показывать «движуху» с результатами, понятными бизнес-зазказчику или общественности.
В-третьих, если поглядеть на порталы закупок, то можно отметить тренд по ревизии компаниями существующих у них ИТ систем и сокращению их количества. Западные системы, закупленные в спокойные времена, продолжают тянуть затраты в $ на поддержку, причем очень немалые. А польза от морально устаревающих решений со временем снижается.
Конкретно в нашем случае, руководитель был очень доволен, наверх отрапортовали об отличных результатах (повышение прозрачности + экономия ресурсов). Инженер получил +2 LevelUp.
ivanko
п. 3 Если вас не затруднит, список пакетов. Очень вкусная статья!
i_shutov
Хорошо, я сделаю отдельным постом, чтобы в кучу не мешать.
i_shutov
Ответил отдельным постом: Джентельменский набор пакетов R для автоматизации бизнес-задач
zxweed
Честно говоря (если второй пункт правда) — мне остается только вам завидовать. Неоднократно предлагал (и наблюдал как предлагают другие) разнообразному руководству сделать своими силами «быстро, хорошо и дешево» взамен «медленно, плохо и дорого», ответ всегда был один — «не высовывайся», а после пары таких ответов — LevelDown и увольнение. Вы же пишете о первом в моей жизни наблюдаемом исключении из этого правила, что вызывает вполне определённый и обоснованный скепсис.
i_shutov
Наверное, это один из самых сложных моментов проектной деятельности. Убедить Заказчика, пусть он и внутренний, но все равно Заказчик, что он этого хочет именно этого. Полная аналогия с воспитанием детей. Если ребенок чего-то не хочет, то силой добиться результата не получится. Только убеждение, спокойствие, терпение и, желательно, доказывать необходимость на собственном примере. А если не получается, то иногда проще отступиться.
Но в том, что я написал нет ни капли домысла, хоть это и может удивлять. Не исключаю, что бывший коллега Константин (AristarXXXX), который любезно откомментировал результаты нашей совместной работы, сможет организовать референс-визит, если это будет интересно и не будет возражений от его руководства. Почти все было сделано его руками, я больше обеспечивал консультативную помощь, определял вектор развития и помогал с тонкими моментами.
AristarXXXX
Всё правда. Название компании, к сожалению назвать не могу, но вы о ней точно слышали ;)
Также несколько преувеличена лично моя роль. Помимо Ильи, который нам помогал, мы всё делали вдвоём с коллегой. Потом к нам ещё третий подключился.
zxweed если есть интерес обмена опытом — мы только за. Можно вступить в переписку — тимвьювер — личную встречу.
На самом деле это всех касается. :)