Comments 4
Спасибо за статью. Не могу ни минусовать, ни плюсовать. Поэтому - коментарием.
Для реализации этой задачи данные должны лежать в отдельном хранилище, а не в системе бизнес-аналитики.
До сих пор пытаюсь понять, как такое вообще в голову придти может, данные и датамарты не в "нормальных" системах хранить, а другие только как фронденды использовать? И эти проблемы не в системе как Qlik или Tableau, а именно в головах архитекторов. Каждый день с этим сталкиваюсь, что вся агрегатионанная логика в Tableau спрятана и только с помощью скачивания "xls-файлов" можно какие-нибудь kpi для оперативных процессов получить. В Qlik такая-же байда, но там хоть рассылка по е-майлу есть. Но какая это дигитализация, если для работы с данными их человек должен где-нибудь ручками выбрать, скачать, открыть, странсформировать, и только после этого - использовать. Для чего? Ну не знаю - оперативная работа с данными не только в дешбордах происходит, а в оперативных процессах, где наличие данных - неотьёмная состовляющая.
И к сотням других вещей вишенка на торте - в Tableau например нельзя замаркировать какую-нибудь циферку и с Cntrl+C & Cntrl+V где-нибудь использовать.
это не от хороршей жизни. Просто раньше был один ! аналитик рисовавший графики в экселе. Потом он освоил клик - и перенес свои эксельки туда. Никакого хранилища с блекджеком и ETL-ом он в одиночку конечно делать не будет. А денег на проект DWH с командой и архитектором никто не даст, если задачу можно решить прямо сейчас одним кликом (простите за каламбур). Ну а дальше уже идут истории описанные в статье.
Мы создали базу в MySQL, с помощью Python вынесли туда ETL, обработку, QVD-файлы и всю их цепочку преобразования – слой выгрузки, хранения и конечные витрины для каждого приложения, сделав отдельные SQL схемы под каждое приложение.
Но почему mySQL ???
Чтобы не осталась без работы команда которая потом еще раз смигрирует все в snowflake?
Мигрируем с Qlik: как создать надежное хранилище для ваших данных