Приветики, хочу спойлернуть вам мини проект, который, планирую релизнуть на выходных. С кодом на гитхабе, с описанием на хабре, вот это вот всё.

Кароч, 3Д-экшон суть такова как-то у меня был проект рабочий, где нужно было выпилить часть фичей из продукта, которые не выгодно обслуживать. Какие — не уточнялось, но что-нибудь надо снести. Чтобы вычислить аутсайдеров, логично сравнить все фичи между собой. Это понятно. Не понятно как сравнить и по каким критериям. Потому что начиная в этом всём копаться, осознаёшь что у каждой части свои приколы и как будто стандартизировать шкалу оценок нельзя. И так то оно так, но немножко, всё таки, можно.

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

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

Сейчас я уже вывел набор из 5-ти параметров-метрик, которые относительно равномерно ложатся в большинство интерфейсных фичей и глобально покрывают и UX и экономику. Закончил тесты на разные типы фичей, чтобы убедиться что всё ложится равномерненько. Пока не придумал как оптимизировать структуру данных на вход, чтобы это была не таблица на 146 млн строк, но и чтобы запрос был не на 5 листов формата а4, и чтобы всё это было применимо к разным проектам, естественно.

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

📌 Про DataLore и DataSpell

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

Как-то кто-то мне с воодушевлением рассказывал про новый продукт JetBrains, который DataSpell, я послушал, покивал и благополучно забил. А на днях у меня появилось желание завести Jupyter в облаке под R. С юпитером я не работал толком, когда-то давно под это дело ставил Anaconda, потом немножко смотрел на блокноты через VSCode и PyCharm, но мне не понравилось.

А тут ради интереса пошёл посмотреть на DataSpell. Там я конечно вообще не понял как работать с блокнотами в R, но это и не важно стало потом 🙂

Когда я его ставил, JB любезно предложили мне попробовать ещё их облачный сервис DataLore. И вот это уже оказалось офигенно. Это простое корпоративное облако, к которому можно затянуть предустановленные коннекторы к базам данных (выбор по джетбрейновски огромный) или накидать файлами в проекты. Проект там это блокнот Jupyter с поддержкой R в том числе, все базовые приколы типа обновлений по расписанию и репортов — в наличии. А ещё блокнот можно компилировать в отчёт для не-аналитиков, скрыв код. За это отвечает отдельный интерфейс а-ля конструктор отчётов.

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

Как инструмент синхронизации аналитических артефактов — пока видится мне единственным завершённым на рынке, с удобным хранением скриптов R/Python/SQL и документации, например к тестам. Единственный минус для меня — не умеет запускать реактивные приложения Shiny. Но это было бы уже совсем круто 🙂

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

А DataSpell, с которого всё началось, в целом выглядит как удобная комбинация DataGrip + PyCharm + R Studio + DBT. Всё в одном месте, всё удобно и красиво. Но я пока не готов переходить на него, R Studio всё-таки имеет много мелких приколов, от которых я не готов отказаться пока.

#инструменты

Интересно, зайдут тут SQL-сниппеты, или не нужны никому, потестим 🙂

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

Я это делаю через подсчёт строк и отбора топ-1 по каждому юзеру. Для примера, нужно найти самый популярный девайс юзера:

select user_id,
       device as most_used_device
from (select user_id,
             device,
             row_number() as over(partition by user_id order by user_id, count(*) desc) as rn
      from database
      group by 1, 2) as t1
where rn = 1

Логика простая, сначала выстраиваем поюзерный список девайсов с сортировкой по бОльшему количеству чего-нибудь, нумеруем строки, а потом отрезаем все строки, что не 1.

Тут весь прикол в count(*), сюда засовывать нужно то, что логически подойдёт, если это ивенты, то лучше их на дни попилить, чтобы мы не девайсы по количеству ивентов тащили 🙂

#сниппеты

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

Какие только костыли не выдумывали 😀

select if(length(slack_string) > 0, slack_string, 'OK') as slack_string
from (select arrayStringConcat(
                     arrayMap(x - > toString(x),
                              groupArray(if(to_alert = 'y', '<@user>\n', '') ||
                                         'Campaign: ' || campaignName || '\n' ||
                                         'Current cost: $' || toString(daily_cost) || '\n' ||
                                         'Daily cap: $' || toString(daily_cap)
                                  )),
                     '\n\n') as slack_string
      from (select campaignName,
                   round(sum(daily_cost), 2) as daily_cost,
                   round(daily_cap, 2)       as daily_cap,
                   case
                       when daily_cost >= toFloat64(daily_cap)
                           then 'y'
                       else 'n' end          as to_alert
            from (select campaign,
                         spot,
                         spot_id,
                         name       as spot_name,
                         daily_cost as daily_cost,
                         daily_cap  as daily_cap
                  from (select *
                        from (select campaign,
                                     spot,
                                     sum(cost) as daily_cost
                              from client.actions
                              where date = today()
                                and owner = '5fbb4d4b61d6e257153928a1'
                              group by 1, 2)

                             left join (select id as campaign,
                                               daily_cap
                                        from client.campaings
                                        where owner_id = '5fbb4d4b61d6e257153928a1') using campaign)

                       left join (select spot_id,
                                         spot_aid as spot,
                                         name
                                  from client.dictionary_spot
                                  where name like '%opunder%') using spot
                  where name like '%_%')

                 left join (select campaignId as campaign,
                                   campaignName
                            from client.dictionary_campaigns) using campaign
            group by 1, 3)
      where to_alert = 'y')

В твиттере на очередной круг вышла дискуссия о том, чем бы занимались айтишники, если бы за любую работу платили одинаково и выбирать можно то, к чему душа лежит. Я не могу выбрать между выращиванием оливок / крафтом масла или всё таки производством виски 🙂 и там и там тишина, покой, природа)

Кто куда после айтишечки двинет?

📌 Несмещённая дисперсия, степени свободы и почему же n-1 (2/2)

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

Когда мы используем n-1, мы никак не увеличиваем или не уменьшаем количество независимых наблюдений, но мы начинаем корректно учитывать тот факт, что последнее всегда зависимо. Таким образом мы расширяем степень вариативности, и закладываем идею о том, что мы точно не знаем какой разброс в ГС, т.е. математически признаём этот факт.

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

Использование n-1 в расчёте дисперсии является частным проявлением этого принципа.

P.S. Если прям совсем грубо, то у нас есть требование к анализу, что там всё должно быть независимо. А тут блин, последнее число зависит от остальных. Надо его выпилить и всё будет ок 🙂 но фактически мы не знаем что есть последнее, зависит от того, с какой стороны считать, поэтому как будто в формуле задаём это автоматическое выпиливание. Но эт если совсем условно 🙂

#собесы