а кстати как такие стрелки от пожписей делать? это от geom_text или от annotation?

у автора так:
https://ggplot2.tidyverse.org/reference/geom_segment.html

конкретно про вышеприведенную картинку — это очень старая история.
можно посмотреть все детали реализации в блоге автора:
https://www.cedricscherer.com/2019/05/17/the-evolution-of-a-ggplot-ep.-1/#polish

ТоваRищи, вот такой вопрос:

Получил "Warning message: system call failed: Cannot allocate memory " и возник вопрос, а можно ли заранее оценить место, необходимое для объекта и сравнить его с оставшимися ресурсами машины?

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

Какая есть практика в данном направлении?

честно?

там все сильно нелинейно. в т.ч. за счет stringpool.

Можно вытащить сэмпл и взвесить. Внутри и поглядеть в ОС съеденную память.

Взвесить поколоночно можно такой функцией, например:

weightDF <- function(df){
  # сводка по объемам данных в печатном виде

  as_tibble(df) %>%
    map(pryr::object_size) %>% 
    unlist() %>% 
    enframe() %>% 
    arrange(desc(value)) %>%
    add_row(name = "TOTAL", value = sum(.$value)) %>%
    mutate(ratio = formattable::percent(value / (0.5 * sum(value)), 2)) %>%
    mutate(across("value", ~as.character(fs::as_fs_bytes(.x))))
}

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

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

я бы для начала сравнил гистограммы распределения сумм платежа одного клиента

Насчет много мелких и много крупных - через распределение можно посмотреть

в целом коллеги уже ответили. немного структурирую.
1. Определяемся с гранулярностью по временнЫм ячейкам. Для двух лет 1 месяц является хорошим периодом. имеем 24 шага по времени.
2. Считаем для каждого пользователя ARPU по месяцу (average revenue per user).
3. Вводим интересующие нас корзинки по ARPU, факторизуем непрерывную величину.
3. смотрим за динамикой количественного наполнения корзинок по временнОму агрегату (можно linechart, тепловая карта, alluvial и пр...)

+ табличка в дополнение.

Все нюансы ловятся на раз-два. Потом формируются адресные гипотезы и делается уточненная проверка.

У меня вчера похожий вопрос возник от удивления: не мог понять, как 1 колонка из 10 млн. телефонов заняла 130 мегабайт в csv.

>Вводим интересующие нас корзинки по ARPU
это ключевой вопрос, как их делаем? теоретической модели, какие могут быть бины, нет
остальное очевидно

пример строчки из csv?

Длина номера составляет в среднем 10 символов. Должно быть как-то так:

fs::as_fs_bytes(10^6 * 10)
# 9.54M

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

Предметная область и изучение распределения дадут все необходимые подсказки

в среднем получается по 13 байт на номер. Примерно столько и будет весить, если там доп. символы есть и номер в текстовом виде. Даже если номер в виде числовой переменной хранится в базе, то все равно не меньше 80 мб будет в csv выгрузке

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

тут работает метод "пристального взгляда", а когда найдено решение, под него придумывается обоснование и модель. как при 3D печати. сделали подпорки на этапе печати, а потом их срезали.

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

А кластеризация временных рядов тогда не идет?

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