Не знаю какой у вас кейс 🙂 Но если уж вы не собираетесь делать Hadoop инсталляцию (и даже если собираетесь), ELK - сейчас один из стандартов в части анализа логов.

Для реалтайма, если вдруг такое будет (например, анализировать метрики хранилища), взгляните на Grafana

Возвращайтесь к этой теме, если что. С удовольствием аргументирую свою позицию. Но сразу оговорю — мое мнение не авторитетно, я не знатный клико-вод. Я прошел обучение Клику и очень пристрастно пытал их специалистов с позиции "докажите что вы как настоящее хранилище", им почти удалось.

Ну это фантастика. Клик - инструмент для визуализации. То что он под себя ещё и своё хранилище требует, для меня скорее минус, чем плюс. Я не верю, что по скорости кликовские файлы выиграют у MPP базы. Вообще ни разу. А если нет - то чем клик лучше хадупа с хранением в паркете (настроенном)? А как насчёт кластеризации (есть установка на несколько машин, но это не распределённая система)? А что обеспечивает доступность этих данных при выключении ноды?
Много вопросов.

Есть ещё такой продукт - SAS. Мощная очень среда, тоже свои файлики. Тут тебе и инструменты анализа, и high-end стат-анализ, и даже интеграции с Hadoop, и in-memory для некоторых баз. И конечно визуализация, BI и т.п.

Но всё равно все сейчас с этого съезжают - очень дорого сопровождать. Как легко на рынке найти хорошего ETLщика, знающего именно клик/sas? А такого же, на работающего просто хадупом без привязки к технологии? Как вы думаете, какой рынок шире?

В итоге, конечно, Qlik - не полный отстой (как Oracle BI), и не умер ещё окончательно. Но использовать его надо крайне осторожно, с пониманием того, какие ограничения для вашего бизнеса появятся.

Я там выше говорил про Data Vault (2.0) и Anchor Modeling - это моделирование данных, которое никак бизнес не ограничивает. Наоборот, делай что хочешь, а данные всё-равно можно будет интегрировать в хранилище и потом использовать. Но эти модели накладывают ограничения на технологии хранения. Сложно сказать, но мне кажется делать это в клике - странный выбор.

И чтоб подытожить. Хранилище - это вообще дорого. Капец как дорого. И инфраструктура, и специалисты, и разработка. Даже (точнее особенно), на opensource решениях. Если задачу можно решить просто кликом, и все ограничения для вас понятны - нефиг платить за хранилище. Берите клик.

спасибо)

Нечего возразить, все так 👍👍👍

По клику - столкнулся с многотерабайтным хранилищем на клик файлах. Визуализация была путем создания в генераторах фейковых таблиц в регяционку, ручное прокалывание связей в dbschema. С этим разобрались. Далее - все это бегает на сервере, но так как на сервер задачу поставить весьма бюрократично - все просто насоздавали минихранилищ у себя на десктопах. Клик очень хорош для пилотов по монетизации данных, помимо визуализаций - скрутить и посмотреть в различных разрезах - функций больше чем в клике. Но оно в таком виде и переходит в продуктив. И самый большой минус клика - почти нереально использовать данные ничем, кроме клика.

Разматывать происхождение данных и анализ влияния - то ещё удовольствие в клике, хотя есть платный красивый плагин, но хорошее исполнение видел только в оракл метадата менеджере

И табло уже по части функционала с дата препом догоняет клик

Если для мониторинга, то подойдёт elk, splunk. Если из логов надо бизнес инфу выбирать в основное хранилище, то с elastic забирать данные, насколько помню, придется с ручной реализации цикла забора данных небольшими порциями. Можно кликхаус рассмотреть еще

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

Wat???

Табло дата преп - это конкурент trifacta, а не клика. Это вообще про другое. И это не табло догоняет клик, а клик табло. У клика data wrangling утилиты нет вооьще.

Кроме табло на рынке сейчас нет инструментов с честным live connect к базе :) но тут надо оговориться, что речь идет про кликсенс, потому что сравнивать табло с кликвью странно - это теплое и мягкое.

Да, я не конкретно дата преп имел ввиду, это к слову пришлось, а вектор, с которым развивается табло. Я говорил именно про кликвью, который честно стоит посередине между классическим bi и selfbi. И табло активно развивает функционал в тот же сегмент, в части подготовки данных и визуализаций на всех стадиях. По сенсу хз, внятно преимущества сказать не могут перед кликом, несколько раз пробовал выяснить. Насчёт честного коннекта, сам не пробовал, но у клика есть direct connect, и они его активно рекламируют

Ну и по факту, ввиду особенности работы с данными в табло и клике - этот коннект работает только с простыми наборами данных. Если что-то посложнее закрутить в дашбордах, такой SQL нагенерит что страшно становится)

Исправляю только незамеченные ранее ошибки автозамены или собственные грамматические

Может direct discovery? Direct query - это тоже есть, это оператор для direct discovery.

https://help.qlik.com/ru-RU/qlikview/November2017/Subsystems/Client/Content/DirectDiscovery/direct-discovery-introduction.htm

Если да, то это опять не совсем то. В принципе ТАКОЙ директ можно использовать и без клика, достаточно на стороне субд сделать вьюхи.

Плюс там сильные ограничения на синтаксис запроса (см. Уже direct query)

Про клик не скажу, табло начиная с 10.3 кажется очень хорошо работает со сложными запросами. Мы тестили над Vertic’ой - лучше чем custom sql писать.
А сейчас они вообще представили параллельный движок, и скорость стала запредельной (как и ценник 😁).

Кстати, еще важный момент. У табло движки коннектов к многим субд более продвинутые, чем интерфейсы ole db или odbc.
Vertica, teradata, sap - у них у всех умные коннекторы. С вертикой, например, табло пробрасывает в базу временные таблицы с группировками и всё вычисление ложится на MPP.  Oledb так не умеет.

Этим мне табло всегда больше нравилась. А насчёт SQL - работает то круто, но когда на один датасет несколько дашбордов, потом составной дашборд из них, тогда у меня начинались проблемы. Сохранял экстракт, тогда быстро.