Comments 6
Очень интересно, ждем продолжения ))
Спасибо. Было интересно почитать
Хотелось бы больше технических деталей, сейчас много вопросов.
Miner, Cleaner, Validator - какие-то самописные решения или готовые продукты? Почему решили именно так?
Так и не понял архитектуру DWH. Сначала пишите что у вас MS SQL и Clickhouse, потом внезапно PostgreSQL с расширением Citus (почему не Clickhouse например), а потом отдельно Postgres? Почему так сильно разнесли данные, а не храните в одном DWH?
Что используете для ETL/ELT? Как выбирали?
Какое BI решение как интерфейс для пользователя? Судя по слову DAX предполагаю что PowerBI?
BI‑решение как интерфейс для пользователя — Microsoft Power BI. Он был в стеке компании и, по крайней мере пока, решение об изменении софта в этой части не принималось. Переезд на другую BI‑систему само по себе очень сложное и долгое мероприятие, поэтому пока что оставили то, что есть и сосредоточились на данных.
Miner, Cleaner, Validator — самописные модули на Python. Решили именно так, потому что требуется точечное управление различными элементами и настройками этих модулей, нет привязок к вендорам (в т.ч. иностранным), и в команде есть экспертиза и наработки по такого рода решениям. Такая же история с ETL/ELT: используем Apache Airflow и пишем самостоятельно «даги» на Python.
Теперь про архитектуру:
Сначала пишете, что у вас MS SQL и Clickhouse — да, это описание того, что есть
Внезапно PostgreSQL с расширением Citus — это описание того, что решили ставить для DWH
Почему не Clickhouse например — потому что Clickhouse, при всех его плюсах не подходит для построения якорной архитектуры, из‑за ограниченности его SQL и не лучшей работы джоинов, а в якорной модели их очень и очень много. Clickhouse оставили для хранения сырых данных и, возможно, в перспективе, будем его использовать для размещения витрин данных (вопрос требует некоего исследования, поэтому точного ответа пока нет)
Почему так сильно разнесли данные — для их сохранности. Сырые данные находятся на одном сервере в Clickhouse, очищенные и обработанные на другом в PostgreSQL, а подготовленные витрины на третьем. В архитектуру изначально заложен максимум с точки зрения безопасности, целостности и сохранности данных, но если в процессе что‑то окажется избыточным, можно будет принять решение об отказе от этой части. В любом случае, отказаться от чего‑то легче, чем встраивать то, что изначально не запланировано. Об этом будут другие публикации
Бизнес-сериал: формируем BI-систему в строительстве почти в прямом эфире. Часть I