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

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

не нужно, когда есть кафка
С трудом представляю себе руководителя, который анализирует данные ежесекундно. Скорее человек подождет, когда день закроется, встанет с утра, выпьет кофе, доедет до работы и уж тогда посмотрит на итоги дня. В общем, лаг часов 12. А стало быть заморачиваться с транзакционностью смысла нет (а делов с ней куча). Даже особого смысла в агрегатах нет. Потому что оперативный анализ не подразумевает больших объёмов.
Другое дело бизнес аналитик. К слову, у таких лаг еще больше, т.к. это анализ тенденций, а для него нужны большие и закрытые периоды. А еще им надо «крутить» данные, чего реляционная БД не умеет.
Конечно, не у всех есть бизнес аналитики, и некоторым надо, чтобы то решение, за которое они платят, выдавало им статистику, пусть и без особых вариантов слайсинга. Таким Excel подошел бы больше. Был бы набор данных. Кстати, Excel очень резко отличается от статичного набора отчетов в лучшую сторону.
Что же касается технологий. Я все-таки за ETL(или ELT). Почему? Row-by-row не применяют в аналитике. Там применяют специальные структуры данных оптимизированные для быстрого чтения больших объёмов.

Эти паттерны агрегации могут понадобиться не в репортинге, а как раз в oltp приложении. Где нужно в интерфейсе отобразить общее количество страниц, остаток по счету с учётом транзакций текущего периода, и тп.
Там где считать на лету долго и дорого, а показать надо уже сейчас.

'Стоит ли'?
СтОит конечно. Есть очень жесткие инструменты на эту тему: олапкубы, кликтех/поверби/табл, колоночные бд, кодеки в кликхаус…
Движение — жизнь, недвижение — голод.))

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

Информация

Дата основания
Местоположение
Россия
Сайт
sbis.ru
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре