Кадр из мультфильма «Смешарики: 132 серия (Пылесос)»

При проведении различной ad-hoc аналитики или же создания интеграций между DS решением и внешними системами очень часто приходится использовать REST API для получения данных. Ситуация, когда все помещается в один запрос — идеальна, но редка как единорог. Как правило, приходится тянуть большие объемы, тянуть по частям и в режиме многоходовок, возможно, с использованием курсоров. Внешняя система может лечь при большой нагрузке или же там включатся механизмы пропуска запросов (троттлинг). Вопросы «почему у меня не работает» и «как мне сделать, чтобы работало» возникают с завидной регулярностью.

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

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

Кадр из мультфильма «Over the Garden Wall» (2014)

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

Однако, изначально просто счёт относился к computer science, а data science было более широким и междисциплинарным понятием. В классическом понимании data scientist — «T-shape» специалист, который оцифровывает и увязывает административные и предметные вертикали/горизонтали компаний через математические модели.

Далее немного иллюстрирующих примеров.

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

Продакт-менеджерам посвящается...

Заступая на территорию proccess mining, каждый участник рано или поздно будет нуждаться в наборе логов событий, отражающих те или иные специфические моменты в процессах. Эти логи нужны как на этапе демонстрации решения, подсвечивания определенных вопросов, так и для отработки алгоритмов или же тестов на производительность. Оба рекомендуемых сценария «взять с продуктивных систем» или «взять из интернета» терпят фиаско. Как правило, это очень
малые датасеты, слабо удовлетворяющие потребностям как по наполнению, так и по объему.

Остается вариант — написать генератор правдоподобных логов самостоятельно. Тут тоже есть два варианта.

• Вариант первый — превратить эту задачу в универсальный монстроподобный продукт, содержащий визуальный конструктор в нотации BPMN 2.0, всевозможные визуальные конструкторы формул и атрибутов, полноценную имитационную машину под капотом. Годы работы, миллионы на ветер, на выходе — файл с логами. КПД близок к нулю.
• Вариант второй — отнестись к этой задаче как к вспомогательной и создать инструментами data science стека упрощенный генератор в 100 строк кода.

Остановимся далее на втором варианте.

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

Кадр из фильма «Индиана Джонс: В поисках утраченного ковчега» (1981)

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

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

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

Можно выделить ряд алгоритмов, которые являются базовыми и лежат в основе практически каждой строчки программ, написанных на языках высокого уровня. Хорошо иметь под руками классический многотомный труд Дональда Кнута "The Art of Computer Programming", там детально разобраны многие базовые алгоритмы. Но прочесть и усвоить все — задача, требующая много усилий и времени, которая должна как-то быть мотивирована.

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

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

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

В ходе обсуждений возникла «маленькая» задачка — построить динамику структуры кредитного портфеля (динамика кредитной карты, например). Есть важная специфика — необходимо применять метод FIFO для погашения займов. Т.е. при погашении первыми должны гаситься самые ранние займы. Это накладывает определенные требования на расчет статуса каждого отдельного займа и определения его даты погашения. Задачу решаем честно.

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

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

Проблематика

Когда говорят про отчеты к данным (неважно, какая тема) все хотят гибкие дашборды, МНОГО дашбордов, играют конкурсы про BI, выдумывают разные сложные требования и кейсы, отсматривают массу вендоров и решений, разбиваются на непримиримые лагеря и на 100% уверены, что это то, без чего жизнь на работе тяжела, уныла и печальна.

Так ли это? По описанию очень сомнительно (похоже на серебряную пулю), а практика дает подтверждение «отнюдь не так».

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

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

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

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

Даты и время являются весьма непростыми объектами:

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

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

Совсем краткое резюме для смартфоночиталей: на больших объемах данных используем только POSIXct с дробными долями секунд. Будет хорошо, понятно, быстро.

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

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

• объема доступного железа;
• требований по производительности;
• стабильности;
• соблюдения требований ИБ;
• … (добавьте специи по вкусу).

Нынче в России такая фаза, что для задач data science язык python позиционируется как "серебряная пуля". Похоже, что такой тезис выдвинули те, кто продают курсы по DS на python. А дальше маховик пошел. В целом, это вполне нормально — почти все процессы в физическом мире являются колебательными.

Но, все-таки, в этом хайпе немного недоговаривают. Есть в python ряд досадных моментов, даже в базовых DS задачах, которые сильно усложняют его использование в продуктивном контуре.

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

Как ни парадоксально, но пока еще нередко в enterprise встречаются задачи, отличные от построения еще одного личного кабинета, еще одного мониторинга или еще одного документооборота. Если немного подумать, а не хвататься сразу кодировать или искать специализированное ПО, то можно написать компактное, весьма элегантное и быстрое решение, используя метод Монте-Карло .

Задачи в Enterprise достаточны компактны для перебора и не требует точности 100 знаков после запятой. Не ракеты или реакторы запускаем и не научную теорию всего строим.

Рассмотрим далее на примере одной из нестандартных задач.

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

Типичная ситуация в нынешнем образовательном процессе в школе. На часах 22:00, в электронном дневнике ребенка появляется новое задание. В лучшем случае на послезавтра, но обычно на завтра.

Вариантов реакции три:

• не делать вовсе;
• «не заметить» и отложить решение вопроса на потом;
• попробовать сделать.

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

Выбирая третий вариант, в отдельных случах даже задания по русскому языку можно попробовать решить с помощью R, принимая во внимание, что на все про все есть 15-20 минут максимум. 5 минут на «экстремальное программирование», 10-15 минут на чистовое оформление. Когда принципиально задача решена оформление можно уже и утром сделать

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

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

Ключевые слова: cmdb, multi-agent sumulation, monte-carlo, ml.

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

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

И да и нет. Если сознательно не вдаваться в теорию, железо и всякие подробности, то можно нарисовать «3 и 1/2» почти универсальных рецепта.

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

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

Решения на R хорошо закрывают нишу «средних данных», когда данных «чуть больше» чем влезает в excel или в ненастроенную реляционку и нужны сложные алгоритмы и процессинг, но когда разворачивать пусковой комплекс бигдаты еще более чем рано. Речь идет о десятках-сотнях террабайт в полном объеме, которые легко умещаются в бэкенд на Clcikhouse. Важный момент: все находится во внутреннем контуре, в подавляющем большинстве случаев ПОЛНОСТЬЮ отрезанном от интернета.

Является продолжением серии предыдущих публикаций, уточняет публикацию «Конструктивные элементы надежного enterprise R приложения».

Как-то так получилось, что в 2020 году возник всплеск интереса к тематике Process Mining. Не исключено, что новая реальность удаленного режима потребовала более пристальной оценки эффективности технологических и бизнес-процессов. Это же как с кривыми и косыми деревянными рамами. Сквозит из всех щелей, а счетчик накручивает мегаватты на обогрев.

В целом, видны несколько популярных запросов по применению технологии process mining:

• хочется что-то улучшить, но кроме модного слова больше ничего не слышали;
• получить или сэкономить «живые деньги» путем оптимизации классического процесса «order-to-cash» и ему подобных;
• системный аудит всего и вся собственной командой аудиторов;
• построение операционной аналитики и мониторинга на основе показателей процессов, а не ИТ метрик.

В 99% случаев начинают читать Gartner/Forrester и попадают на 4-ку вендоров (Celonis/Minit/Software AG/UiPath), которые как-то присутствуют в России. И до того, как начать получать какую-либо выгоду, тут же получают немаленький ценник за лицензии и последующую ежегодную поддержку. При этом экономическое обоснование шито белыми нитками.

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

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

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

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

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

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

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

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

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

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

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