Как стать автором
Обновить

Комментарии 58

Честно говоря, зная реалии отечественного бизнеса, очень странно, что вас не уволили со всеми волчьими билетами за срыв откатов по поставке огромного BI-решения (а тем более нескольких.) Ну и надо признать, что их функционал гораздо больше и ширше, нежели R, пусть даже с графическими пакетами.
Ну зачем же сразу откаты, бывает и без них, в стандартных BI и так достаточно преимуществ по сравнению с альтернативными решениями.
Комментарий комплексный, отвечу по частям.
  1. BI решения бывают разные, про огромный размер я не говорил и даже не думал с подобными решениями соревноваться. Задачи перед большими BI системами совершенно другие ставятся. Но даже «маленькое» BI решение в виде SQL базы + pie chart & line graph на Flash с суммой 15-20 млн руб. на круг и сроками реализации ~ 1 год находится за гранью добра и зла при текущем уровне развития open-source и высокоуровневых языков программирования. Тем более, что руководству необходим десяток графиков (сумма\среднее) и «светофоры», что-либо иное на этапе выбора очень трудно сформулировать.
  2. Идея 30-ти серебрянников идет красной нитью через человеческую историю. Но за последние 3-4 года, по-крайне мере, в Москве, появились и другие мотиваторы.

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

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

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

    Конкретно в нашем случае, руководитель был очень доволен, наверх отрапортовали об отличных результатах (повышение прозрачности + экономия ресурсов). Инженер получил +2 LevelUp.
  3. R очень активно, я бы сказал, экспоненциально, развивается. Пакеты и подходы, которые есть в 2016 году кардинально отличаются от возможностей даже 2014 года. Да и приобретение Microsoft-ом коммерческой версии R и встраивание его в свои продукты (SQL, Azure, PowerBI) многократно расширило потенциальную аудиторию пользователей и сценарии применения. А насчет широкого функционала тезис очень спорный. Как правило, пользователи используют 20-30% от возможностей сложных продуктов. Широта функционала важна не для конкретной задачи, а для ковровой бомбардировки продавцами вендора потенциальных покупателей. Пакетов (бесплатных!) в R столько, что ни одной BI системе не снилось, но для закрытия типовых бизнес-потребностей в части переработки информации 30-40 пакетов более чем достаточно. Если интересно, то могу привести списком те, которые находятся у меня в постоянном использовании.
п. 3 Если вас не затруднит, список пакетов. Очень вкусная статья!
Хорошо, я сделаю отдельным постом, чтобы в кучу не мешать.
Честно говоря (если второй пункт правда) — мне остается только вам завидовать. Неоднократно предлагал (и наблюдал как предлагают другие) разнообразному руководству сделать своими силами «быстро, хорошо и дешево» взамен «медленно, плохо и дорого», ответ всегда был один — «не высовывайся», а после пары таких ответов — LevelDown и увольнение. Вы же пишете о первом в моей жизни наблюдаемом исключении из этого правила, что вызывает вполне определённый и обоснованный скепсис.

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


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

Всё правда. Название компании, к сожалению назвать не могу, но вы о ней точно слышали ;)
Также несколько преувеличена лично моя роль. Помимо Ильи, который нам помогал, мы всё делали вдвоём с коллегой. Потом к нам ещё третий подключился.
zxweed если есть интерес обмена опытом — мы только за. Можно вступить в переписку — тимвьювер — личную встречу.
На самом деле это всех касается. :)
Интересно, спасибо!
Подскажите, нет ли у вас примеров кода такого компонента в открытом доступе?
Климент, добрый день.

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

Не могли бы вы показать какие-то стандартные отчёты (с обфусцироваными данными, конечно)?
Желательно с описанием процедур дата-флоу, где-что-как рендериться и т.д.
То есть, если можно, больше конкретики.
Картинку с рабочего портала постараемся приложить чуть позже, надо вытереть якорные поля. Сама система обслуживает несколько миллионов людей, это к вопросу о масштабе.
А вот и пара скриншотов:
image

image

Это, отнюдь, далеко не все представления, а интеграционная и математическая механика под капотом. Как видно из скриншотов, все это происходило почти год назад. Сейчас мы бы использовали новые пакеты, например, flexdashboard. Но при отсутствии бизнес-драйвера (позиция руководства прагматична: все работает и устраивает, зачем переделывать?), нет смысла возвращаться в прошлое, а личное время лучше уделять семье и детям.
Спасибо, интересно!
Выглядит хорошо и презентабельно, что важно.
Кстати, по внешнему виду очень напоминает MS Power BI
В качестве интересного примера, приведу портал Министерства туризма Новой Зеландии, который построен на 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.
да, действительно интересно, спасибо!
Советую поменять заголовок и переписать первую половину статьи. Я с трудом понял о чем речь, а открыл только потому, что подумал: «Какая может быть связь между continious integration и data science? они что, ошибки в коде отлавливают методами машинного обучения?»

Когда прочитал статью до конца, очень понравилось, добавил в закладки и проч. Но по счетчику показов видно, что мало кто Вас здесь прочитал.

Поддерживаю предыдущий комментарий — хотелось бы увидеть примеры конкретной реализации.
Сергей, спасибо за комментарий.
Прежде чем поделиться своим опытом я проглядел хабр вдоль и поперек и не нашел ничего подобного. Пока была модерация в песочнице я подготовил еще один пост, в продолжение этого. Надеюсь, сегодня-завтра его смогу привести в порядок и опубликовать. Вопросы в комментариях, видимо, требуют еще одного поста в котором я кратко описал бы пакеты, которые использую для решения описываемых задач. Будучи по образованию физиком (если точнее, то физиком-экспериментатором), мне нравится использовать околонаучные вещи и подходы в бизнес-задачи. А почему бы нет? Опыт показывает, что это воздается сторицей. Как один из примеров — 15 лет назад перед нами стоял вопрос на чем запустить технологическую линию верстки в издательском процессе. Мы рискнули и отказались от классического варианта Word\FrameMaker и запустили на базе LaTeX. И не прогадали, автоматизация верстки была доведена до 80-90%, книги только текстом и картинками (худ. литература) вообще могли верстаться в автомате. Необходимо было только по диагонали проглядеть на предмет возможных висячих строк в сложных случаях и корректору поглядеть текст. На вход word файл, на выход — pdf для типографии.

Поэтому я решил поделиться опытом с R именно с теми, кто не равнодушен. Это не серебрянная пуля, но добротный набор инструментов.

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

… пить кофе из корпоративных кружек и делать красивые презентации.

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

Несколько аналогов 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 но выглядит неплохо.

С питоном мы имеем дело, начиная с 2006-года. Но, к сожалению, в части переработки, анализа и визуализации данных фреймворка со стройной структурой так и не удалось подобрать за разумное время. Поскольку решаем прагматичные задачи, то интересует лучший результат за кратчайший срок. Поэтому по состоянию на сентябрь 2016 года экосистема R нас полностью устраивает. Более того, мы понимаем, что ее потенциал раскрыт на 10-20%, не более и мы имеем возможность развития без резкой смены парадигмы.
Спасибо, как раз хотел спросить почему Р а не Питон.
Но опять, же, не могли бы вы добавить конкретики, что с чем сравнивалось при выборе?
Лично мне, например, связка Python+Django и на фронте JS визуализация D3 (C3 etc.) кажется 1) не имеющей потолка развития 2) очень хорошо поддерживается рынком труда, т.е. нет проблем со спецами
Тогда как с R ситуация не однозначная, по моему.
Только в прошлом году мы имели опыт разработки на таком фреймворке. За 2 недели сделали прототип на R, бизнес согласился, что это хорошо. Решили перетащить («продуктизировать») на Python + Django. В итоге 8 месяцев работы «по-правильному» были выкинуты в корзину. А все потому, что за это время бизнес приоритеты успели измениться, и потребность в этом решении отпала. Сейчас слишком быстро все меняется.

Почему не Python? Потому что процессинг данных (а это основная механика решаемых задач) оказалась гораздо проще, приятнее и понятнее. Все благодаря труду Hadley Wickham, фактически, сформировавшего лицо современного R. А поддеркжа D3.JS в R есть. Ну и самим рисовать порталы с реактивными (reactive) элементами совершенно неинтересно. В экосистеме R эту задачу мы перекладываем на Shiny. Более того, мы знаем, что у R в части обработки данных есть огромный потенциал. Если вдруг не хватает бесплатных возможностей (у нас такого и близко не было), можно переехать на Enterprise edition (Microsoft) и получить поддержку и кластеров, и hadoop, и выхода за рамки оперативной памяти, и репозиторий снапшотов пакетов и пр…
Спасибо! Убедительно…

Я просто позавиловал Shiny и решил как бы сделать закладку на будущее.
А на Java не сталкивались с аналогом Shiny? (знаю про гугл, хочу мнение человека с опытом использования).

Спасибо за статью!
Являясь одним из тех, кто «просунул ногу в дверь руководству» могу подтвердить, что результаты, которые можно получить «на коленке» обладая средне-базовыми знаниями R и покопавшись в библиотеках визуализации (замечу, что есть врапперы почти для всех популярных js библиотек построения графиков), весьма впечатляют руководство и отлично решают «бытовые» задачи. Кто спрашивал примеры отчётов — рекомендую просто покопаться в примерах на оффсайтах разных библиотек для R. Ниже пара ссылок:
Костя, спасибо.
Если не трогать классический ggplot2, то в части интерактивных виджетов можно заглянуть еще сюда: "76 registered widgets available to explore"
Еще, хороший пример различных shiny приложений.
Конечно, большая часть из них, shiny-style, но если делать в shinydashboard(+css+JS опционально), то получится вполне неплохо.
это был некролог по BI-системам?
по консалтингу бизнес-процессов и совещаниям?
пришел великий и могучий RRRrrrrrr!!! и смел все эти непонятные и следовательно ненужные автору статьи активности на свалку истории.

чем хоть занимается компания, в которой произошла сия замечательная революция?

а что если движ продолжить — выкинуть на свалку истории и R с кучей поддерживающих технологий, а заодно и нескольких наверное избыточно дорого для фирмы оплачиваемых спецов, и залепить все в Excel с Power Pivot одним продвинутым и смелым студентом?
Vlad_fox: я бы не хотел, чтобы в комментариях началась эмоциональная переписка по далекой от изначальной мысли теме. Тем более, что мы с Вами не знакомы и у нас обоих нет никаких оснований полагать, что мы обладаем недостаточным опытом, чтобы принимать взвешенные решения. Консалтинг бизнес-процессов никто не отметает, когда-то я даже занимался этим и в Киеве. Но речь то совсем не об этом. Инструменты и подходы постоянно меняются, появляются очень интересные и красивые вещи, которые можно приземлять для решения практических бизнес задач. Додумывать что-либо сверх написанного можно, но это будет слабо относиться к тексту статьи.
только факты, уважаемый Ватсон, только факты:

Конечно, я немного утрирую, но даже время и деньги, потраченные на бесконечные групповые совещания при проработке решения, стоят десятки миллионов рублей в ФОТ (фонд оплаты труда), а многие инициаторы к окончанию проекта уже работают где-то в другом месте

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

Классический подход для автоматизации подобных задач — привлечение консультантов по бизнес-процессам; формирование предложений по переходу на единую платформу с глобальной интеграцией; анализ и выбор; RFI/RFP; тендеры; многолетнее внедрение; какой-то результат за огромные деньги на морально устаревшей за время внедрения платформе

— из статьи я так и не смог понять какой конкретно «некласический» поход взамен был предложен?
могу предположить — от консультантов отказались (чем заменили), от единой птатформы с единой версией истины отказались (если нет, то чем построение такой платформы на R легче, дешевле чем на BI), от анализа и выбора тоже отказались (много на этом съекономили денег и времени?), отказались от тендеров… вам разрешили обойти политику тендеров в компании для этого частного случая?
отказались от многолетнего внедрения BI системы (вообще-то это не обязательное условие — почитайте про саксесс стори внедрений той-же BI Qlikiew). Про морально устаревшую систему… разве на рынке представлены для выбора только морально устаревшие системы?
про огромные деньги… BI системы оценивают не по критерию «скоко стоит? скоко-скоко???!!», а по сроку окупаемости и положительному эффекту от внедрения. Но до этого понимания менеджменту компании надо еще дорасти…

ПС. прошу прощения за излишнюю эмоциональность, согласен, часто эмоции неуместны…
но мне действительно интересны ответы на вопросы
1. По поводу эффекта:
Эффект очень простой — снижение порога принятия решения до 0. Сейчас, когда без бюджетной статьи даже рулон туалетной бумаги не купишь, любая инициатива по приобретению ПО начинает рассматриваться в микроскоп. Чем больше бюджет, тем больше увеличение. Бюджетные комитеты, обоснования, совещания. Это может длиться не один год. Это и есть классический подход. Делается замануха в виде потенциального бюджета, приглашаются продавцы и консультанты от интеграторов и вендоров, которые бесплатно развлекают на этапе пресейла\пилота, дело доводится до закупок и тут… кризис, секвестор бюджета, смена руководства. Вообщем, начинай все заново.
При этом не стоит забывать, что в реальности к BI не было четких требований. «Нам вендоры должны рассказать, что надо хотеть». И есть пожелания по 5-10 отчетам, которые требовали на совещании у вышестоящего руководства. Все остальное — придумывайте сами. Интересует только РЕЗУЛЬТАТ, правда не всегда понятно, какой именно.

2. По поводу неклассического подхода.
Отказаться от многомесячной тендерной движухи в пользу решения конкретной задачи здесь и сейчас.

Для задач, не претендующих на всеобщность и не затрагивающую основной бизнес-функционал в явную, как, например, сайт в интернет-магазине, написать обоснование, даже с учетом горизонта окупаемости 3 года, очень тяжело. Слишком вероятностные и зыбкие статьи сокращения затрат.
R — бесплатен, поэтому не надо всей вышеупомянутой кутерьмы. Нет предмета закупки — нет тендера. Можем сделать сами — убедите на практике, дальше посмотрим. Мы убедили. Как я писал выше, средний срок «жизни» ИТ директора стремится к 1-2 годам. Поэтому всем надо, чтобы окупилось аж на следующий год.

Что касается Qlick\Tableau — это, в первую очередь, визуализаторы и инструменты для аналитика. С серьезной математикой там слабо, но есть коннекторы к R.
Они платные, см. выше. $2K тоже замучаешься обосновывать.
Не проще ли вместо круговерти обоснований сесть и сделать самому? Свое время сэкономить. Тем более, что все равно потом установки и требования поменяются и придется опять все адаптировать.
Как то незаслуженно охаяли Power Pivot якобы студенческой песочницей.
Очень серьезный инструмент между прочим по своей экосистеме и востребованности (прежде всего в пендостане и европах, у нас поменьше но тоже развивается)
DAX язык достаточно гибок (ссылка на мою старую статью где затронут всего 1% от заявленного функционала языка: 1; 2), алгоритмы сжатия VertiPac позволяют спокойно тащить в модель на клиенте сотни миллионов записей сжимая их эффективно, в случае связки Power Pivot + Power Query вообще становится доступен полноценный ETL с доступом к гетерогенным источникам данных.
По поводу централизованной публикации модели для корпоративного использования — c конференции Microsoft вспоминаются бизнес кейсы одной из крупной компаний которая обходится без OLAP/SSAS (хотя это конечно очень странно по многим причинам) просто публикую модели Power Pivot на SharePoint сервер и их это устраивает.
Так что про студентов — «за державу обидно»

Кстати в тему обиженной компании R /Power Pivot по части использования в BI (а так же
«почитайте про саксесс стори внедрений той-же BI Qlikiew»
) вспомнил интересную вещь:
Microsoft Power BI нативно поддерживает DAX язык от Power Pivot + «M» язык Power Query + R язык со всей своей шикарной экосистемой. Я думаю это неплохой ответ на
только факты, уважаемый Ватсон, только факты
Ну и не забываем, что теперь Enterprise R = Microsoft
День добрый!
Имею небольшой опыт работы с Power BI. Впечатления двойственные.
Была задача подтягивать данные из 1С и сделать «чтобы всё было красиво». Инструмент удобный, функциональный и т.д., но с одним большим НО (по крайней мере на момент 2015 года). У него невозможно настроить автоматическую актуализацию данных. Т.е. возможно, но для этого поднимается платный (помимо подписки Microsoft) Gateway (кажется, так называется), который нужно ставить отдельно и через него цеплять данные. Плюс (опять же на момент 2015 года) были некоторые странности при экспорте из десктопной версии в облако (например, плыли выбранные вручную цвета для отдельных элементов). Также документация была слабовата, да написана по неактуальной версии (даже синтаксис отличался). Так что имейте в виду…
Однако я верю, что недостатки поправят (или уже поправили), а с приходом R к Microsoft там вообще всё очень хорошо (кстати, недавно узнал, что теперь можно из SQL Server 2016 дёргать сразу JSON данные, прямо праздник...).

Насчет 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.


Слабоват пока продукт, но развивается очень быстро.

Это интересно. Альтернативный путь решения известных задач. А можно применить такие подходы не к аналитическим, а транзакционным системам? То есть использовать сшивки данных разных систем при проведении операций?
С такими задачами в «прошлой жизни» приходилось сталкиваться, например, в антифрод системах, если я правильно понял вопрос. Если не сложно, то можно более подробно описать задачу?

Вообще, это тоже отдельное интересное направление.
Ребята из Data Driven Security очень неплохо в этом продвинулись. Можно и их книжку почитать, есть на просторах интернета в pdf.
Или начать в качестве отправной точки с записи в их блоге: "Building [Security] Dashboards w/R & Shiny + shinydashboard"
Сам подход интересен и рождает массу мыслей. Например, в средах с сотнями систем (аля банки) вместо того, чтобы строить новый светлый мир с одной централизованной АБС и выравненной моделью данных — делать процессоры, сшивающие данные из разных систем под конкретную задачу. То что мне близко — цифровые банковские продукты. Сбор данных и создание «единого правильного хранилища» решается не построением новой системы, а в realtime сбором-сшивкой-отображением. И самое интересное — в обратную сторону. Проведение операций/транзакций делается распространяя изменения в системах, несвязанных между собой, внося изменения на языке их моделей данных.

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


Естественно, что в зависимости от объемов данных и скорости реакции должны использоваться различные подходы и платформы, но для не реал-тайм задач потенциала R (математика, фронтенд, сбор данных) + python\erlang (низкоуровневое взаимодействие с другими ИС\ парсинг нестандартных протоколов) мне пока более чем достаточно.


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

Спасибо за то что поделились вашим опытом. У меня есть одна небольшая ремарка. В моем понимании BI специалист/консультант (или человек который отвечает за BI в компании) это не разработчик софта или BI решений, а больше очень продвинутый пользователь уже имеющегося ПО с отличным пониманием процессов анализа данных, статистики и бизнес-процессов в компании (тут по разному, и есть разница между внешним и внутренним BI консультантом). И очень часто подобный специалист не умеет или не хочет писать код своими руками. И это я не про скрипты по очистке данных, SQL запросы и т.д., а именно про функционирующие приложения на R, Python и т.д. для конечного пользователя (тут сложность выбранного пакета/языка зачастую не имеет значение, просто консультанты не хотят этим заниматься). Так что мне верится, что ваш опыт применим в таких компаниях, в которых уже есть достаточный штат сотрудников занятых разработкой ПО и опыт работы с разработкой ПО. Согласны ли вы со мной или я что-то не совсем правильно вижу?

Не совсем.
Data Science я упомянул неспроста. В текущем принятом понимании специалисты по Data Science должны иметь крайне широкий кругозор, включая математику, статистику, программирование, дизайн, а также обладать хорошими презентационными и коммуникационными навыками и глубоким знанием предметной области. И, самое главное, ему это должно быть интересно. Всегда есть 1000 и 1 способ объяснения, почему что-то не стоит делать, но пользы от этих объяснений нет никакой.


Поскольку объем решаемых задач не глобален (это 80% проблем в компаниях), двух-трех человек вполне достаточно для легковесного решения многих "проблемных" мест в бизнесе.
Не надо делать монументы там, где это мало оправдано, их все равно снесут. Сейчас век модульных конструкций, в т.ч. в строительстве, автомобилестроении, бытовом сегменте.

Тут есть одно "но". Людей с таким набором навыков ("крайне широкий кругозор, включая математику, статистику, программирование, дизайн, а также обладать хорошими презентационными и коммуникационными навыками и глубоким знанием предметной области") и желанием заниматся именно анализом данных не очень много. В соответствии с этим получается и соответствующе высокие зарплаты (при понимании руководства что Data Science это именно-то что нужно, ваши 80% проблем в компании которые требуют не глобального решения). Так что иметь 2-3 человека в качестве сотрудников с подобными навыками это просто я бы сказал удача для компании.


Но вы все же вы согласны, что описанные вами методы (мне они очень по душе) не применяются (и скорее всего даже не будут) "классическим" BI консультантом?

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

Я понял ваше мнение, спасибо за то что ответили на мой вопрос.

Огромное спасибо — кратко и ёмко написано.
Одна просьба — рука не поднимается написать «маленькая» :) — опишите, пожалуйста, (наверно скорее в новой статье) как вы построили процесс разработки, и главное что и как используете из инструментов.

Меня очень заинтриговала такая фраза
Последние пакеты Hadley Wickham подняли R по удобству работы с данными почти на космосическую арбиту.

Это о devtools или ещё что-то?
Чем они так помогают? Если можно на примерах.
Я давным-давно для собственного интереса разбирался с R, он мне с одной стороны понравился, но с другой стороны показался немного неудобным с точки зрения разработки (хотя, конечно же, это в подавляющей степени дело привычки).
Поэтому ушёл в экосистему python со всеми его пирогами, а особенно pandas, но ведь если вспомнить, то pandas была попыткой привнести в python немного R :)

А сейчас посмотрел на shiny и захотелось опять попробовать, но уже на другом уровне.
Поможете? :)

К R я подступался с 2011 года. Но вплоть до 2014 он не воодушевлял. Пока не произошла революция в подходах.


В части пакетов дал ответ в виде отдельной статьи: Джентельменский набор пакетов R для автоматизации бизнес-задач


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

Под «поможете?» я подразумевал именно написание отдельной статьи с секретами практического использования R, то есть, совершенно неперсонализированный подход.
Поэтому отдельное спасибо за готовность списываться.
За джентльменский набор ещё одно спасибо — особенно хорошо, что с ссылками на статьи.

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

Честно говоря, я это не воспринял как ошибку-опечатку — я думал, что это какое-то новообразованное слово, которое должно иметь смысл невероятных запредельных «закосмических» высот :)
Покрутил его и так, и так в голове, но потом решил, что не понял глубинной идеи и оставил как есть.
Мне кажется, что ошибки, которые не мешают понимать главную идею, можно не принимать в расчёт.

По пакетам 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)
              }

с учетом существующих пакетов возможны различные варианты для совершенства:


Вариант 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) %>%
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории