IB
То есть видимо на это надо натаскивать отдельного человека чтобы, так? Ибо объем затраченного времени будет большой
Нужны навыки администрирования и создания БД + минимум по программированию и форматам данных
Size: a a a
2021 March 05
IB
и хранилище единое никогда не будет единым - это утопия
IB
придется настраивать несколько бд для разных нужд
IB
так что Qlik очень выигрывает по сравнению с цепочкой ETL + БД
V
А разве движок клика и способ хранения данных в нем не приводят к ускорению этого самого etl?
V
Имеется ввиду, что пандас будет грузить в память не уникальные значения в тч, а клик же нет?
IB
и хранилище единое никогда не будет единым - это утопия
например Nifi грузит в Postgres сырье, а какая нибудь колоночная или инмемори ДБ рядом агрегаты считает. Короче это реальный геморрой по сравнению с Qlik ))
MD
если кто-то хочет вникать в автоматизацию ETL не силами клика, то рекомендую смотреть в сторону python. 70% результата получите при 30% освоенности. недельного курса людям хватает.
Ну вот знаю я его, использую. Но для ETL он решит скорее вопрос фильтрации данных и маппинга. Остальное будет кровавой баней на этапе поддержки. По мере роста данных в источниках и увеличении правил обработки.
А для рилтайма скорее всего не хватит перфоманса.
А для рилтайма скорее всего не хватит перфоманса.
MD
если кто-то хочет вникать в автоматизацию ETL не силами клика, то рекомендую смотреть в сторону python. 70% результата получите при 30% освоенности. недельного курса людям хватает.
Это мое имхо, готов выслушать и ваши доводы за, просто немного скепсиса есть по поводу питона в ETL
MC
Это мое имхо, готов выслушать и ваши доводы за, просто немного скепсиса есть по поводу питона в ETL
Airflow?
DS
это объявление переменных в скрипте, чтобы потом использовать в интерфейсе.
Причем тут это вообще?
Причем тут это вообще?
IB
Airflow?
тоже вариант
MC
тоже вариант
И посерьёзнее, чем nifi
IB
однако сам ETL-инструмент это только обеспечение процесса доставки и трансформации из одного места в другое
ИС
Ну вот знаю я его, использую. Но для ETL он решит скорее вопрос фильтрации данных и маппинга. Остальное будет кровавой баней на этапе поддержки. По мере роста данных в источниках и увеличении правил обработки.
А для рилтайма скорее всего не хватит перфоманса.
А для рилтайма скорее всего не хватит перфоманса.
ну, значит 70% результата уже есть)
запускайте контейнеры-workerы в очередях... вообще на всех компах домена, будут потреблять 1-2% у юзверя на заднем плане... получите на большую организацию - примерно тысячу постоянных воркеров. 😂
запускайте контейнеры-workerы в очередях... вообще на всех компах домена, будут потреблять 1-2% у юзверя на заднем плане... получите на большую организацию - примерно тысячу постоянных воркеров. 😂
IB
И посерьёзнее, чем nifi
мне больше Nifi нравится)
IB
но это потому что я на питоне не очень люблю
DS
Хранилище само по себе, конечно, потребует и усилий и вероятнее всего дополнительных людских ресурсов.
Но если данных много и потребность их использования сильно шире клика, то это неизбежный шаг, на мой взгляд
Но если данных много и потребность их использования сильно шире клика, то это неизбежный шаг, на мой взгляд
IB
Хранилище само по себе, конечно, потребует и усилий и вероятнее всего дополнительных людских ресурсов.
Но если данных много и потребность их использования сильно шире клика, то это неизбежный шаг, на мой взгляд
Но если данных много и потребность их использования сильно шире клика, то это неизбежный шаг, на мой взгляд
требует постоянных усилий, плюс оно не будет гибким как Qlik. Не сможет быстро удовлетворять запросам бизнеса некоторым
V
это объявление переменных в скрипте, чтобы потом использовать в интерфейсе.
Причем тут это вообще?
Причем тут это вообще?
Если ее объявить через лет, то она посчитается (в тч с учетом сет анализа). Создав цикл с let и load в таблицу можно рассчитывать с помощью сет анализа в скрипте и записывать результат в таблицу