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

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

R образца 2020 года очень сильно отличается от R даже 2018 года. В самом базовом коде были внесены достаточно значимые изменения для повышения эффективности и стабильности работы (скорость и потребление памяти). Но более динамичная часть экосистемы — это пакеты. Их коллекцию полезно периодически пересматривать с тем, чтобы перейти на более удобные и производительные реализации. С момента прошлой публикации «Джентельменский набор пакетов R для автоматизации бизнес-задач» и сами пакеты претерпели серьезные модернизации и спектр их достаточно сильно расширился и лидеры многократно менялись местами.

Не секрет, что мейнстрим не означает максимальную эффективность и универсальность. Придерживаясь рамок мейнстрима очень легко пропустить пакеты, которые являются жемчужинами. Особенно удобно открывать их на R конференциях UseR!, Rconf, eRum, и т.д.

Ниже приведен список пакетов общего применения, который оказывается весьма полезным при решении повседневных задач (x пакетов из >10K на CRAN). Часто оказывается так, что многие новинки оказываются неизвестны собеседникам. Для сводного ознакомления по срезу на июль 2020 публикую в виде подборки. Ссылки, в большинстве случаев, ведут на страницу с подборкой функций. Уверен, что каждый найдет для себя что-то полезное.

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

Достаточно часто встречается ситуация, когда размер и содержание отчетной формы будет зависеть от состава переданных на вход данных. Речь идет именно о story-telling отчете, а не о простом выводе таблицы. В этом случае, в зависимости от содержания входных данных, могут появляться или исчезать отдельные пункты, графики, таблицы, текст.

Что будет делать классический Excel-Word аналитик? Под каждый новый запрос делать кастомный отчет и сохранять его в отдельный файл. Но можно заглянуть немного под капот и заставить компьютер делать все самостоятельно.

R Markdown позволяет все это выполнить в элегантной форме. Некоторые технические детали ниже.

Публикация носит характер описания тропинки, выводящей к эффективной алгоритмизации методов вычисления доверительного интервала (Confidence Interval = CI) для

• медианы распределения;
• разницы медиан двух распределений.

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

Выборки по объему большие, 10^5 — 10^7 записей, ощутимо ассимметричные, с длинными хвостами, могут иметь несколько мод. В этом случае медианы более устойчивы к выбросам.

Применение классической статистики, например, критерия Уилкоксона-Манна-Уитни, для оценки разницы медиан на таких объемах не проходит. Да и очень много чего читать надо под звездочками, чтобы правильно применять эти критерии. Ведь этот критерий проверяет отнюдь не равенство медиан, да и для медиан он работает только при одинаковых формах распределений двух выборок. И т.д. и т.п.

Хвататься за молоток бутстрапа можно, но и с ним надо думать + на симуляцию требуется время и память.

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

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

Сейчас ИТ может прийти к бизнесу и потребовать десятки и сотни миллионов на внедрение или разработку модных онлайн-систем. Однако окажется ли это все оправданным? Без построения полноценного управления оттоком клиентов (то что в телекоме называлось 'customer churn prediction') эффективность затраченных средств окажется под большим вопросом и вот почему.

В тематике CRM существует два широко употребляемых маркетинговых тезиса:

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

Периодически встречаются задачи, даже в обыденной жизни, когда разрядной точности float64/int64 оказывается недостаточной для того, чтобы получить ответ с требуемой точностью. Метаться в поисках другого инструмента? Тоже вариант.

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

Библиотека хороша и заслуживает того, чтобы на нее обращали внимание, хотя бы в рамках расширения кругозора. По R к ней есть обертка Rmpfr. Ниже приведу простенький пример на задачках для школьников (ну не трогать же проектные данные под NDA) и затрону ряд классических граблей, на которые наступают почти сразу же.

Является продолжением предыдущих публикаций.

На первый взгляд, это два непересекающихся мира. Но на практике, это не так.

Ниже дан краткий локальный комментарий к хорошей статье «Не спать! Как мы научились тиражировать релизы на 12000 касс за ночь» в части системы мониторинга качества обновления ПО и применению R в этой задаче.

Является продолжением предыдущих публикаций.

Достаточно часто возникает потребность проведения периодических вычислений и подготовки консолидированного отчета по самодостаточным данным. Т.е. по данным, которые хранятся в виде файлов. Это могут быть данные, набранные из открытых источников, различные документы и excel таблицы, выгрузки из корпоративных систем. Данные в сыром виде могут занимать как несколько мегабайт, так и несколько гигабайт. Данные могут быть обезличенными, либо содержать конфиденциальную информацию. В том случае, когда код вычислений помещается в репозиторий, а работа ведется более чем одним человеком более чем на одном компьютере, возникает проблема сохранения консистентности кода и данных. При этом необходимо еще обеспечить соблюдение разных прав доступа к коду и данным. Что делать?

Является продолжением предыдущих публикаций.

Закончились новогодние праздники, можно подвести итоги.
Важный комментарий: Это не реклама, это печальный опыт.

В этом году решили посмотреть на альтернативные елочные концепции и сходили на 'Семейное IT-приключение — Код «Новый год» 2020' от Алгоритмики. Описания и рассказы менеджеров были очень интересными, вроде как намечался увлекательный квест. Хороший повод поддержать детский интерес к алгоритмизации и программированию.

Задавив имевшийся скептицизм, полученный на предыдущих экспериментах с Алгоритмикой, решили дать еще шанс. Но горечь и полученное разочарование от этого мероприятия, которое можно было бы достойно номинировать на "самое провальное мероприятие 2019 года", вынуждают дать краткие комментарии по этому регулярному перформансу, чтобы дать колеблющимся информацию о том, как это было на самом деле, а не махать рекламными слайдами. Ну и где же поделиться впечатлениями от ИТ елки, как не на тематическом ресурсе? Все далее написанное рассматривать как ИМХО.

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

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

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

Каждый раз, когда начинается разговор об использовании различных БД в качестве источника данных, появляется тема идентификаторов записей, объектов или чего-либо иного. Иногда согласование протокола обмена может рассматриваться участниками несколько месяцев. int-bigint-guid, далее по кругу. Для объемных задач, с учетом того, что нативно в R нет поддержки bigint (емкость ~2^64) выбор правильного представления таких идентификаторов может оказаться критичным в части производительности. Есть ли очевидное и универсальное обходное решение? Ниже несколько практических соображений, которые могут применяться в проектах в качестве лакмусовой бумажки.

Как правило, идентификаторы будут использоваться для трех классов задач:

• группировка;
• фильтрация;
• объединение.

Исходя из этого и оценим различные подходы.

Является продолжением предыдущих публикаций.

Хороший инструмент + наличие навыков работы с ним, что достигается путем практики, позволяет легко и элегантно решать множество различных «как бы» нетипичных задач. Ниже пара подобных примеров. Уверен, что многие могут этот список расширить.

Является продолжением предыдущих публикаций.

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

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

Сразу отмечу, что тема будет интересна далеко не всем. Кому это неактуально — проходите мимо. У кого будут доп. идеи, было бы интересно тоже ознакомиться. Далее будет ряд задачек, которые были позаимствованы с курсов «Меташколы», математика 3-ий класс. Естественно, что сначала задача решается логическими рассуждениями, потом обсуждается способ решения с применением компьютера.

Важные дополнения по результатам обсуждений ниже:

1. Материал написан с позиции родителя, а не преподавателя. Здесь нет услуг и пиара. Здесь просто набор практических соображений.
2. В качестве инструмента использовался R потому что так было удобнее.

Является продолжением предыдущих публикаций.

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

Является продолжением предыдущих публикаций.

Краткая заметка по теме business process mining в контексте роста интереса к концепции "digital twin". В силу периодического выплывания этой темы считаю целесообразным поделиться подходами к решению.

Постановка задачи

Ситуация предельно проста.

• Есть компания X (Y, Z, ...).
• В компании есть бизнес-процессы, автоматизированные различными ИТ системами.
• Есть бизнес-аналитики, которые нарисовали bpmn диаграммы по этим процессам. Если говорить точнее, их собственное "bpmn представление" о том, как эти процессы должны были бы выглядеть.
• Бизнес пользователи хотят иметь какое-то представление (KPI) по этим процессам.

Как докопаться до истины и посчитать эти метрики?

Является продолжением предыдущих публикаций.

Как эффективно работать с json в R?

Является продолжением предыдущих публикаций.

Публикация по выступлению на секции R meetup @ Moscow Data Science Major (Spring 2019).
Вся презентация в pdf формате.

Почему этот вопрос актуален?

Бизнес-кейсы различны, техническая суть одинакова

• Аналитика работы колл-центра
• Аналитика продаж, включая прогнозы
• Антифрод системы
• Business process mining
• Различные аудиты (технические, финансовые)
• Складские и логистические задачи
• Activity-based costing
• Business-process monitoring
• Log-based аналитика
• Capacity management
• Текстовая аналитика (e-mail, service-desk)
• "Гибкие" дашборды и отчеты
• "интеллектуальные шины" между учетными системами (1С, СКУД, SAP, ...) и исполнительными
• ...

Является продолжением предыдущих публикаций.

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

Но рассуждать с бизнесом о нулевых гипотезах и значении p-value совершенно бесполезно и контрпродуктивно.

Как можно по состоянию на февраль 2019 года сделать это максимально просто и быстро имея под руками ноутбук «средней руки»? Заметка реферативная, формул нет.

Является продолжением предыдущих публикаций.

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

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

Разумной альтернативой является создания внутри компании команды data science (DS). Если не замахиваться на строительство египетских пирамид, то команда и 2-3 грамотных специалистов может сделать весьма и весьма много. Но тут возникает другой вопрос, как подготовить этих спецов. Ниже хочу поделиться набором успешно апробированных соображений по быстрой подготовке такого «спецназа» с R в качестве оружия.

Является продолжением предыдущих публикаций.

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

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

Является продолжением предыдущих публикаций.

Комментарии в последней публикации «Насколько open-source экосистема R хороша для решения бизнес-задач?» насчет выгрузок в Excel привели к мысли, что имеет смысл потратить время и описать один из апробированных возможных подходов, который можно реализовать не выходя из R.

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

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

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

Является продолжением предыдущих публикаций.