📌 Аналитическая система с единорогами и пони

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

Почти всё я выбрал исключительно потому что нравится 🙂 Я не дата-инженер, поэтому что-то может быть не оптимально, но это мой комфортный стек работы со стороны ПА.

Получился вот такой наборчик:

🔵Данные с бэка, про платежи, регистрации, данные юзеров и вот это вот всё я бы хранил в Postgre. Потому что надёжная и неубиваемая система. Как та самая нокия. А для бэка это главный критерий, на мой взгляд, т.к. тут самые чувствительные данные.

🔵Фронтовый трекер для событий — вот тут хз, раньше был крутой опенсорсный Segment. Весил мало, загрузку не импрувил, user-based. Не умел ничего кроме трека ивентов, но с этой задачей справлялся прекрасно. Вот какой-то такой аналог бы. Может в сторону своей разработки бы смотрел. Ключевой параметр — легкость.

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

🔵Кликстрим по фронту складывал бы в колоночную бд, т.к. в запросе обычно нужно мало полей на много строк, а не наоборот. Тут бы зашёл Clickhouse или Vertica. Работал с кликстримом в строковых бд, запрос на >5 млн строк вообще не реально выгрузить. Но вроде как CH на масштабах проигрывает Вертике (но это не точно, слышал такое где-то).

🔵По BI тут два инструмента. В качестве основы для постоянных бордов Shiny (жестко, но стабильно, быстро и функционал ограничен только твоей фантазией). А для временных бордов и черновиков Redash (простой, быстрый, гибкости для времянок достаточно).

🔵Как working-area / хранилище артефактов, рисерчей, результатов экспериментов и т.д. для аналитиков поднял бы DataLore.

Интересно, насколько это вообще жизнеспособная схема со стороны инженерии, но работать аналитику в такой — одно удовольствие 🙂