Comments 10
Если ты начинающий аналитик, то вряд ли сможешь поднять и содержать что-то сложнее. А если данных много, то скорее всего, уже будет какая-то система под это. Тем временем, Postgres неплохо работает с довольно большими данными, до 10ТБ на нём можно ещё работать, если грамотно распределить данные.
Использование колоночных БД для аналитических запросов - обычная практика при объемах от сотни гигабайт данных. CitusDB, Greenplum, Redshift, Vertica, ClickHouse, Druid, QuestDB...
Ну как минимум для целей аналитики надо в PostgreSQL подключать расширение CitusDB. Так в моей статье для запроса по подсчету зданий это ускорило выполнение аналитического запроса в 10раз. Или устанавливать форк PostgreSQL - GreenPlum.
видно там данных на одну горстку.
А если на нормальных системах такие запросы гонять это смерть )
Хотя даже для "не девов" есть тот же metabase
Фишка в том, что в этой системе можно предподготовить данные, что занимает много времени и проходит раз в день. Потом в ходе работы или визуализации количество данных, с которыми работает аналитик, обычно сильно меньше входных.
Но согласен, в целом эта система - это прототип для того, чтобы можно было начать работать, а не production-ready решение.
Сколь прекрасно автор! Я доковылял до очень похожей системы, но читаю в основном файлы (источников файлов становится неприлично много) и класс инициализируется через эрзац-базу в Экселе, в эрзац-базе - список источников и приведение полей.
(По ленности, скудоумию и отсутствию более опытных коллег потратил на этот путь почти 2 года)
Как-то тема отказа от Docker/Airflow/K8s не раскрыта. Если поднимаем локальный Postgres, то почему бы не инсталлировать точно так же Docker и далее по мануалу на странице официального образа? До уровня "оно работает" как правило референсной страницы достаточно. Поскольку наш условный аналитик умеет в Python для написания пусть и не сложного управляющего процесса, у него не должно составить большого труда подключить это же в самый простой DAG в AirFlow (который может быть запущен также в контейнере) по Quick Start Guide. Но он получает гораздо больше вариантов мониторинга, перезапуска, управления датами из расписания, а не от today (а ведь 100% что-то будет падать периодически), визуализации зависимостей. При числе объектов больше 20 это будет несколько проще, чем просто голый код. Для T части в ETL на SQL как начальный вариант - dbt. Он имеет возможность строить модель, запускать обновление данных по зависимостям, визуализировать их из коробки.
Основная тема -- не отказ от других инструментов, а использование тех, которые уже знаешь. Когда нужно начать хоть как-то работать, освоение новых для тебя технологий занимает довольно много времени, даже если нужно просто пройтись по чеклисту. То не работает какая-то версия, то не хватает зависимостей, то у тебя виндовс, а не мак... В общем, проблем обычно везде хватает.
Безусловно, когда базовая потребность собирать и подготавливать самые основные данные закрыта, самое время разбираться с этими инструментами. Ну или если есть время сразу разбираться, то делать это можно и сразу.
Моя рекомендация любому аналитику, у которого нет норм инфры, купить себе средненький vps если компания не оплачивает и выстраивать там себе все ништяки. И не будет проблем с win и m1
Далее docker compose который поднимает все что нужно. Jupyter Airflow DB VPN. Даже без знания докера готовых сборок много и запускаются они одной командой
А там уже со временем разобраться надо ли ему ковырять airflow и другие инструменты или нет
Как построить MVP системы для удобной работы аналитика без Docker, Kubernetes и Airflow