Комментарии 45
к чему пришли в противостоянии GUI ETL и ETL as a code
А к чему пришли? В том же Airflow и стрелочки можно рисовать, и код писать. В в других инструментах (в большинстве по крайней мере) так же. Разве нет?
А попробуйте вручную, ETL as code, моделировать и поддерживать Ancor modelling или хотя бы Data Vault?
Когда изменение связи одного поля из источника в приемник влечет за собой корректировку множества запросов (заполнение хабов, линков, сателлитов)...
Тогда как в GUI просто протягиваешь линию от поля к полю и все.
Именно DataVault мы и пробовали:))
Вы правы, DV весьма сложно разрабатывать и поддерживать без специальной тулзы. Даже сами такую тулзу сделали.
А кто сказал, что DV - это самая правильная архитектура DW? DV плодит слишком много джойнов, в чистом виде он не пригоден для OLAP-запросов и требует костылей
DV - это не про выборки, это про архитектуру, про неразрушающее развитие DWH.
Результат двх - это как раз таки выборки, или вы считаете, что главное - это развитие в ущерб пригодности использованию? Датаволт требует дополнительных серверов в рамках платформы двх
Результат двх - это как раз все вместе: ETL, хранилище, отчетность. Сложность DWH при обычном проектировании растет экспоненциально.
Датаволт требует дополнительных серверов в рамках платформы двх
требует доп пространства для хранения, да. Но для бизнеса проще купить еще один SSD, чем тратить время разработчиков на поддержку и разработку спагетти-стайл.
Недавно услышал очень хорошую мысль про DV. DV не про анализ, а про хранение данных. Над DV обязательно должны быть отчетные витрины. Именно с ними работают аналитики.
Всё так, но аналитики сразу же начинают задавать вопрос про актуальность рассчитанных данных в отчётных витринах и получается, что нужно прокидывать метаданные запусков расчетов в отчётные витрины из слоя dv. Архитектуры зачем-то начинают в это моменте вставать в позу и говорить, что это не предусмотрено архитектурой, а вопрос-то очень простой и понятный - на какое состояние данных я смотрю сейчас? Как мне узнать, что данные в витрине обновились?
Realtime-загрузка или загрузка батчей спасут отца русской демократии ;)
Просто другая архитектура нужна - сейчас уже не в моде загрузка данных раз в сутки ночью. Надо менять подходы.
Как мне узнать, что данные в витрине обновились?
Как всегда, на любой вопрос существует простое, всем очевидное, неправильное решение
Можно показать время последнего апдейта витрины. Но что если витрина собирается из нескольких потоков? Один обновляется раз в час, другой - раз в три часа? А если кому-то из аналитиков интересен только "быстрый" поток и ему не важно, что "медленный" сегодня упал - он всё равно в него не смотрит?
Тут архитектор обычно закатывает глаза и вспоминает про согласованный SLA. А кто-то действительно прокидывает даты обновления по потокам - всё от потребности зависит. И я не вижу тут никакого криминала
Интересно. Но это всё-таки больше альтернатива Dash, чем замена Tableau.
Мне кажется, главная заслуга любого no-code - именно в том, что он скрывает "страшный-ужасный" код от глаз бизнес-аналитиков. Да, по сути, они набрасывают мышкой тот же SELECT, но визуально это более дружелюбно. Я не раз видел, как, например, люди впадают в ступор от упоминания оконных функций - но легко пользуются их аналогами из визуальных BI
Да, конечно, подобные решения, как streamlit, только для сотрудников с экспертизой в sql, как минимум.
Но, как я писал в статье, я особо не верю в Self-service аналитику. По крайней мере, я ее не встречал.
Сама концепция no-code порочна по своей сути, не получится всё множество требований реализовать по no-code подходу. А ресурс команды, которая может выполнять доработки no-code системы не бесконечный, в итоге растет бэклог с техдолгом с соответствующим влиянием на все остальное. В случае yes-code есть шанс хотя бы на то, что кто-то сделает прототип, со временем доказывающий свою полезность.
Раньше тоже на ассемблере все писали, было долго, дорого, но были максимальные возможности. Где сейчас ассемблер?
Остались только вставки.
No-code тоже должен разрешать в узких местах использовать SQL.
у нас no-code успешно работает: бизнес-аналитикам подготовили заранее спроектированные data source и они отлично теперь рисуют в BI нужные отчёты. Если бы их заставили вместо этого кодить в SQL и Python - я представляю какой бы стоял вой (без осуждения)
Да, это не панацея. Какие-то сложные штуки всё равно программируются на JS + SQL. Но, по ощущениям, процентов 80 отчётов ушли как раз в сторону no-code
нужно быстро для менеджмента реализовать дашборд
Элементарная установка в пару команд
Априори дружит с Git
Удачи в этом месте))
перенос нагрузки на машины пользователей
Ага, и каждый из них будет таскать одни и те же данные на свою машину, нагружая БД и сеть.
В целом Streamlit хорошая штука, но нишевая. Вряд ли она сильно подвинет обычные инструменты.
Удачи в этом месте))
А что не так?
Ага, и каждый из них будет таскать одни и те же данные на свою машину, нагружая БД и сеть.
Без кэширования на стороне стандартного BI тоже БД нагружается. Да и данные берутся часто из агрегированных витрин. А нагрузки на сеть в принципе нет. Вы же не строите дашборды над сотнями Гб
А что не так?
Вы в качестве средства распространения предлагаете обмениваться файлами. Полагаете, средний менеджер будет делать pip install streamlit? Скорее он напишет письмо HRу на предмет что там по части аналитиков на рынке.
Соответственно, дашборд надо деплоить куда-то. И либо вы это делаете сами, либо какой-нибудь девопс. И в том, и в другом случае - это дороже, чем человек, который может опубликовать дашборд в обычный BI сервис одной кнопкой. Возвращаемся к вопросу что там по части аналитиков на рынке.
Без кэширования на стороне стандартного BI тоже БД нагружается. Да и данные берутся часто из агрегированных витрин. А нагрузки на сеть в принципе нет. Вы же не строите дашборды над сотнями Гб
Стандартные BI в большинстве случаев работают с импортированными данными, а прямое подключение к БД там для крайних случаев.
Над сотнями Гб не строю. Но вот сотни юзеров - запросто. И часто эти юзеры хотят видеть широкие таблицы с максимальной гранулярностью.
Над сотнями Гб не строю. Но вот сотни юзеров - запросто. И часто эти юзеры хотят видеть широкие таблицы с максимальной гранулярностью.
Конечно, таблетку от всего не придумаешь. Но классический вариант следующий - делаем агрегированные витрины под конкретные показатели. Сотни пользователей посылают запросы к этим витринам. Еще лучше вариант (упоминал в статье) - используя DuckDB, чтобы СУБД не насиловать.
Касательно, менеджера и установки библиотек - не знаю, если честно, на мой взгляд установка элементарная, если инструкцию написать.
Deepseek давно бесплатный
Возьмем тот же SAP - менеджер пишет словами "покажи размер прибыли в разрезе отделов" - и у него появляется такой чарт. Этот чарт можно добавить в свой личный дашборд.
Чем плохи стандартные BI-инструменты? Посмею перечислить их недостатки:
сложное внедрение и обслуживание
минимальные возможности интеграции с Git (или вообще их отсутствие)
слабые возможности кастомизации (потребуется неслабая экспертиза)
высокая/очень высокая стоимость (если проприетарное ПО)
сложно разобраться и поддерживать (если open-source)
А времена эти, если и не прошли, то близятся к закату. Старые короли чахнут и умирают.
Не топлю за продукты MS. Какая стоимость? - все бесплатно. Тут только для On-Premise
Установка mssql-server-2022 на ubuntu 22.04, Debian 12 или Astra Linux 1.8
На бесплатный Hyper-V Server 2019 установка:
Microsoft SQL Server 2022 Reporting Services - 3/31/2025
Microsoft Power BI Desktop - 4/22/2025
17763.557.190612-0019.rs5_release_svc_refresh_SERVERHYPERCORE_OEM_x64FRE_en-us.ISO доступен с дозачкой и в Windows с Geoip-РФ
curl.exe --doh-url https://dns.comss.one/dns-query -OLC - https://software-download.microsoft.com/download/pr/17763.557.190612-0019.rs5_release_svc_refresh_SERVERHYPERCORE_OEM_x64FRE_en-us.ISOВсе даром, лишь попроси:))
Если серьезно, PBI Desktop и Pro все же разные вещи.
Что-то не увидел преимуществ, если честно. Графическое моделирование тупо удобнее, а с точки зрения серьезных корпоративных систем, тут конь не валялся. Ни полномочий, ни нормального доступа/интерфейса, ни адекватного ci/cd (можно я не буду считать таковым гит?). И это только верхушка айсберга. Вопросы производительности, переиспользования, кэширования, writeback, той же агрегации вообще не раскрыты, что навскидку в голову пришло.
Ну и прямо скажем, сделать простенький дашборд или отчет (кстати, что тут с таблицами?) времени занимает всё те же пару дней, что и написать код. Основная работа - моделирование хранилища, разработка методики и т.п., здесь получается чисто визуал. Ну так на рынке уже штук 25 отечественных bi. Запилите сравнение хотя бы с парой реальных систем, тогда будет понятен профит.
Подскажите, что такое адекватный ci-cd без гит, очень интересно?
При изменении объекта в SAP система пишет его в запрос на перенос. Потом его импортируем в тест-прод и... все.
Сравните с liquibase...
Можно я отвечу вопросом на вопрос. Как вы будете делать коммит в закрытый от интернета контур? Как вы для большого проекта управляете зависимостями между объектами? Как вы при массовых коммитах 10 разработчиков будете откатываться или точечно переносить изменения на тестовую среду?
З.ы. Очень многие bi системы позволяют управлять изменениями изнутри, а не просто фигачить файлы из репозитория. Хотя гит, конечно, тоже штука хорошая
Главное в современном быстроменяющемся мире - это скорость принятия решений, какая может быть скорость решений на вашем BI, если вы скриптами запросы пишите? В помойку ваш BI выбросить и больше о нём не вспоминать никогда. Дом пионеров, кружок умелые руки.
Не думаю, что все сводится к тому, чтобы быстро запилить что-то и принять на фоне этого решение.
А разработка скриптами не сильно дольше ваших любимых drag-n-drop-ов. Особенно если учитывать, что код можно переиспользовать
Сергей, не скажи! за фразу «sales manager получали очень неплохие премии за их внедрение» Павлу, который, кстати, в основном DataValut занимается, прям респект: я давно так не смеялся. Руководители Проектов, в свою очередь, получали бонусы с продажи лицензий👆😀
Кроме того, на уровне no-code tools мы можем видеть один объект, и переключать его свойства (например, поддержка выделения дельты для отправки далее), а на уровне БД это могут быть уже несколько десятков таблиц для реализации такого поведения.
Кодом замахаешься такое поддерживать.
А в чем проблема с GIT и CI/CD в визуальных ETL? Например, в Azure Data Factory всё это прекрасно реализовано.
На работе поддерживаю следующий зоопарк:
Пара дашбордов на суперсете
Дашборд на Dash / Plotly
Пара мелких дашбордов на стримлите
+ пока нет, но с высокой вероятностью возможно, что придется что-то на Shiny сделать
Итого по существу:
Суперсет за мои три года использования показал себя отличным парнем для 90% задач. До сложных самописных графиков на JS я не дошел, но вот взять имеющиеся и (при желании) раскрасить и немного почистить их в css - вопросов нет. Для себя выбираю его в случае, когда все графики утверждены, вьюхи сделаны, а дальше он все сам - и кэширует, и периодически обновляет. Ну Ок, Эирфлоу еще рядом работает - из распределенной БД в аналитическую данные носит. Этим ребятам в таком сочетании - цены нет. Из АБД пользовался и кликхаусом, и duckDB - все супер.
Дэш. Тут целевая история - закрыть то, что не закрывается суперсетом. Иногда нужны расчеты все-таки посложнее jinja-селектов. Получаем кастомность самописного решения и всю головную боль с тем, чтобы его нормально спроектировать (в случае сложных взаимосвязей)
Стримлит. Для себя я его выбираю в случае, когда надо выдать просто ссылку на одностраничную «мордочку», которая оборачивает ML-модель. Может, это слишком примитивное использование стримлита, но вот я не придумал ничего другого. Более серьезное - возвращаемся к Dash. А с задачами «поиграться с ML» - да, удобно, быстро, но история нишевая (как по мне)
Шайни пока для меня темный лес, но сами графики в ggplot навсегда в сердце. Вроде, ничего особенного (а в Плотли для сравнения они еще и интерактивные), но вот все равно тепло от них на душе как-то. Красивые. В общем, кто видел - поймёт сразу, о чем я.
Слова автора статьи о победе кода над «ноу-кодом» (особенно имея в примерах лишь один стримлит) воспринимаются с большим скепсисом. Кажется, что момент, когда все начнут хреначить «дашборды кодом» не наступит (и слава богу). Ну и да, «ноу-код» решения из коробки зачастую даже внешне сразу приятны. Можно, конечно, дать возможность настойки «шрифтом под себя», ок, но это пусть на уровне кода и останется. Большинству будет достаточно того, что есть и оно сразу будет хотя бы не вырвиглазно.
BI умер, да здравствует BI