И еще момент: в Clickhouse нельзя предусмотреть оптимальные настройки для всех возможных моделей заранее. Поэтому в настройках генерации есть ряд настроек, которые можно подкрутить, чтобы добиться более производительной работы таблицы. Однако если вы этого не сделаете - произойдет автоопределение некоторых параметров, и при полном игноре вопросов оптимизации у вас всеравно будет в некоторой степени оптимизированная модель.

И более тонко донастроить это можно по мере потребностей

Доклад с натурных испытаний генерации BI-моделей данных в Clickhouse.

Как вы (возможно) помните, в предлагаемой мной архитектуре аналитического ландшафта результатом очистки данных становятся "эталонные" таблицы в аналитическом хранилище. Это таблицы фактов, справочники, а иногда факты, содержащие вшитые справочники (денормализованные структуры.

За счет соблюдения конвенции нейминга ключевых полей (все ключевые поля называются одинаково, для каждой таблицы определен первичный ключ (если он есть)), мы не озадачиваемся проработкой единой логики связи - она формируется сама по мере наполнения АХД.

Но даже в этом случае, АХД не является удобным источником для подключения BI. Прежде всего потому, что для полноценного построения модели данных из АХД нужно чтобы BI умел в реляционные модели (а это только Power BI). А для остальных BI, которые в качестве модели используют Звезду той или иной формы, нужен дополнительный процесс:

1) Сборки фактов и связей в центральную таблицу показателей и связей;

2) Для некоторых блоков показателей нужно восстанавливать связи, присоединяя ключи, чтобы добраться до таблиц, связанных не напрямую.

Например, сделки связаны с контактами, контакты с компаниями - в Звезде к сделкам нужно приджойнить связь с компаниями, чтобы показатели сделок можно было анализировать в разрезе компаний.

Поэтому мы также забираем на свою сторону процесс сборки моделей: пользователь может выбрать из каких таблиц/полей он хочет собрать модель, наш алгоритм сгенерит запрос для СУБД, и там появится плоская таблица/звезда, с учетом хитросплетений конкретно взятых таблиц. Обеспечивая одинаковый опыт работы с данными в любой аналитической системе или визуализаторе.

Но главный вызов был не в том, чтобы это продумать и реализовать, т.к. с 2019 года все было продумано и реализовано на Qlik

Мы уже вышли из яслей Qlik, где такой запрос имел достаточно простой вид и однозначную реализацию, и попали на поляну Clickhouse. Где важно не только что получается в итоге, но и как оно получается.

Первый прототип появился весной 2022 года, и строил модель на 150 000 строк примерно секунд 30. Это позволило подтвердить гипотезу о пригодности подхода, но совершенно очевидно, не могло быть продуктовым решением.

В эту пятницу была протестирована новая версия алгоритма, который разрабатывался при поддержке топового спеца по Clickhouse Сергея Платонова.

Модель данных в виде плоской таблицы, на основе 13 таблиц из АХД, 139 полей, 21,5 млн строк - формируется за 3 минуты. Что быстрее аналогичного процесса в Qlik примерно в 3 раза. И это еще не вся оптимизация реализована!

Для сравнения, предыдущая итерация этой же задачи на объеме данных в полтора раза меньше составила 20 минут.

В файлике приложен пример сгенерированного запроса сборки моделей. Это SQL-запрос на 800+строк, который нам не нужно:

0) Уметь писать;
1) Писать;
2) Поддерживать;
3) Обеспечивать единообразие с другими моделями.

И это не говоря о массе реализованных удобств, которые при работе с моделями и АХД позволяют избегать ситуация в духе "BI пытается прочитать данные из таблицы, которая находится в процессе перезаписи"

Отличный повод провести сегодняшний вечер с пользой - посетить сходку биайщиков в Лужниках

Мысль дня.

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

Считается, что такой подход помогает клиенту быстро получить первичный результат, т.к. опытная команда быстренько все сделает. А потом его ребята постепенно "войдут в струю" и продолжат развитие решения.

Вот что я могу сказать по этой практике.

Получается ли в итоге быстрее рабочее решение? Довольно спорно. Потому что после бодрого старта в 90% случаев начинаются нюансики с данными самого разного толка.
Урегулирование нюансиков через аутсорсную команду занимает в разы больше времени, с учетом всей коммуникации. Кроме того, часто ради обхода нюансиков приходится исполнять программирование прямо олимпиадного уровня. И полноценно поддерживать такое решение штатная команда не в состоянии.

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

Но разве можно переложить разработку аналитической инфраструктуры на совсем зеленых ребят (ЗР)? Я думаю, можно и нужно.

1. Для начала, нужно сформировать для ЗР очень локальную задачу. Не "Подключиться ко всем данным и портировать все отчеты". А реализовать очень узкую функциональность, которой не хватает вот прямо сейчас.

2. Пройдя базовое обучение, ЗР подступаются к задаче. Библиотеки компонентов направляют их по правильному пути, и дополнительно это полируется экспертным надзором.

3. Благодаря библиотекам компонентов, в ходе решения задачи строится кусочек инфраструктуры, который будет наращиваться в дальнейшем.

4. Нюансики с данными решаются внутри команды клиента, потому что им проще понять друг друга, и скорректироваться на лету. А не делять 10 итераций правок с перепиской и созвонами.

5. На выходе - готовая компетенция у команды заказчика, рабочее решение, высокий моральный дух. Плюс готовность к масштабированию, потому что инфраструктура заложена.

p.s. И еще момент: в отличие от матерых аутсорс-разработчиков, которые для трансформации данных из кривых экселей будет писать мега-скрипт ~~достойный кунст-камеры~~, штатный зеленый новичок может просто уломать местного 1С-ника, чтобы тот дал ему нормальные выгрузки)))

Спустя почти месяц, рапортую. Курс написан, демо режим внедрен. Ожидаем публикации на сайте Loginom (которая, с учетом графика загрузки медиа-отдела, скорее всего произойдет к концу июня) - это и будет моментом выхода в широкий доступ.

Помимо контента, довольно много времени заняло обеспечение полностью автономного процесса прохождения демо - просто зарегистрировался, получил инструкции, и сам все сделал, ~~как и любят все аналитики-затворники~~.

В демо-режиме можно будет сделать свой пилотный проект. Ограничений по времени нет. А также есть ряд компонентов, которые работают без привязки к демо/не демо. В частности, мои любимые узлы для работы с Clickhouse. Т.е. тем кто работает с этой СУБД, библиотека обязательна к ознакомлению ;)

P.s. Я понял, что название библиотеки "ETL для BI-систем" не отражает смысла того, ради чего ее нужно использовать. Поэтому по аналогии с другими расширениями Loginom в их каталоге, библиотека будет называться "Data Monetization Kit", или "Платформа монетизации данных". Это намного лучше объясняет роль решения, на мой взгляд.