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

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

@Sminex у вас там картинки с прозрачным фоном. Перезалёте что-ли.

Пофиксили. Спасибо

Очень интересно, ждем продолжения ))

Спасибо. Было интересно почитать

Хотелось бы больше технических деталей, сейчас много вопросов.

  1. Miner, Cleaner, Validator - какие-то самописные решения или готовые продукты? Почему решили именно так?

  2. Так и не понял архитектуру DWH. Сначала пишите что у вас MS SQL и Clickhouse, потом внезапно PostgreSQL с расширением Citus (почему не Clickhouse например), а потом отдельно Postgres? Почему так сильно разнесли данные, а не храните в одном DWH?

  3. Что используете для ETL/ELT? Как выбирали?

  4. Какое BI решение как интерфейс для пользователя? Судя по слову DAX предполагаю что PowerBI?

  1. BI‑решение как интерфейс для пользователя — Microsoft Power BI. Он был в стеке компании и, по крайней мере пока, решение об изменении софта в этой части не принималось. Переезд на другую BI‑систему само по себе очень сложное и долгое мероприятие, поэтому пока что оставили то, что есть и сосредоточились на данных.

  2. Miner, Cleaner, Validator — самописные модули на Python. Решили именно так, потому что требуется точечное управление различными элементами и настройками этих модулей, нет привязок к вендорам (в т.ч. иностранным), и в команде есть экспертиза и наработки по такого рода решениям. Такая же история с ETL/ELT: используем Apache Airflow и пишем самостоятельно «даги» на Python.

  3. Теперь про архитектуру:

    1. Сначала пишете, что у вас MS SQL и Clickhouse — да, это описание того, что есть

    2. Внезапно PostgreSQL с расширением Citus — это описание того, что решили ставить для DWH

    3. Почему не Clickhouse например — потому что Clickhouse, при всех его плюсах не подходит для построения якорной архитектуры, из‑за ограниченности его SQL и не лучшей работы джоинов, а в якорной модели их очень и очень много. Clickhouse оставили для хранения сырых данных и, возможно, в перспективе, будем его использовать для размещения витрин данных (вопрос требует некоего исследования, поэтому точного ответа пока нет)

    4. Почему так сильно разнесли данные — для их сохранности. Сырые данные находятся на одном сервере в Clickhouse, очищенные и обработанные на другом в PostgreSQL, а подготовленные витрины на третьем. В архитектуру изначально заложен максимум с точки зрения безопасности, целостности и сохранности данных, но если в процессе что‑то окажется избыточным, можно будет принять решение об отказе от этой части. В любом случае, отказаться от чего‑то легче, чем встраивать то, что изначально не запланировано. Об этом будут другие публикации

Зарегистрируйтесь на Хабре, чтобы оставить комментарий