BarclayМы являемся одним из этой сотни заказчиков. И честно сказать, при первой возможности переводим репортинг/дашбординг на SAP BI/ PowerBi в связке с SSAS tabular. Много важных отчетов было сделано в свое время на клике, и просто так, в один миг, от них, к сожалению не отказаться. Первая, но не основная причина, это стоимость решений/лицензий на клике(очень высоко в сравнении). Вторая - целостность данных - это важно, а с ассоциативной моделью клика на выходе в отчете получаются очень большие погрешности. И наконец, когда данных очень много, клику всё-таки требуется хранилище, как бы не расписывали ваши продажники, что можно работать без хранилища на клике, а это уже другие косты, так не проще ли сразу строить нормальный BI backend?
BI отдел был переучен на PowerBI, Lumira в прошлом году. И хочу сказать, что пошло как по маслу, к клику больше ни ногой.

Barclay, а не могли бы Вы чуть подробней по пунктам описать где конкретно плохо:

1. Стоимость решений/лицензий на клике(очень высоко в сравнении).
Если речь о решениях - какие именно решения на клике дороги (ETL, DWH, морда) и в сравнении с чем?
Если о лицензиях - с какими продуктами сравнивали, скажем, можете сравнить стоимость PowerBI и Qlik?

2. Целостность данных - можете дать пример конкретной проблемы с ассоциативной моделью и описание решения другим инструментарием (каким?) ?

3. "Когда данных очень много, клику всё-таки требуется хранилище." На каких объёмах пришли к выводу что кликовского решения ХД недостаточно?
Какие альтернативы решили проблему и каков порядок костов (лицензии, человекочасы)?

4. "BI отдел был переучен на PowerBI, Lumira в прошлом году. И хочу сказать, что пошло как по маслу".
Так PowerBI или Lumira?
А ETL, DWH на чём?
Что значит "пошло как по маслу"? Лицензии_дешевле_&_время_разработки_короче_&_с_ целостностью_данных_вообще_нет проблем_&_etc ? Или как-то иначе?

Заранее спасибо.

P.S. Мой интерес не праздный.
Возможно, благодаря Вашим ответам удастся убедить моё начальство протестировать у нас другие продукты.

SpellBuilderslovnet[какие именно решения на клике дороги (ETL, DWH,
Не удержался. И опять 25, кто то что сделал и с чего вдруг у Qlik появилось ETL, DWH. Навскидку у людей зоопарк, показалось дорого за матерели, поняли как правильно, пришло понимание, решили от дорого избавиться и сделать как правильно с DWH. Георгий писал, что после Qlik понимание о необходимых срезах и показателях. Одну зверушку убираем, парочку добавляем. Развитие по спирали. Ну не бывает в крупных копаниях, одной зверушки.
Будем считать что и я не удержался. И опять 25.
Как по-Вашему называется когда с помощью программного продукта сводится информация из нескольких источников?
А потом очищается, фильтруется, нормализируется?
А когда потом из этого строится модель типа звезда/снежинка - это как называется?

Где я писал что должна быть обязательно "одна зверушка"?

Где у Barclay написано что компания именно крупная?
И вообще, причём здесь величина компании? Это очень косвенный показатель, я вот интересуюсь у Barclay объёмами данных, конкретными проблемами.

Почему Вы решили что знаете "как правильно" во всех ситуациях не зная ничего о конкретном случае?

Я, в отличии от Вас, не рассказываю "как правильно", а интересуюсь, что именно показалось дорого, пришло понимание чего именно, какие проблемы были, как и чем решили.
"Развитие по спирали" - слишком общее понятие. Мне интересны как раз стыки этой самой спирали, где они проходят.
У меня тоже своё развитие по своей спирали, и интересно послушать опыт коллег.

SpellBuilderslovnet,

Ну вот Вам и ответ, компетенции, нежелание восстанавливать и погружаться в другое, прокачка своих скилов и обоснование удешевление и все плохо. Наша классика.
Браво!
Хотя насчёт цен за лицензии/облака может они и правы.
Если 100-200 юзеров, может выгодней MSSQL+PBI.

Дедушкамы уже довольно далеко ушли от темы ТСа :)

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

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

Да, всё так.

Дедушка- да, реализация стейджа через промежуточные qvd файлы

Можете объяснить чем это плохо? Добавляет пресловутой костыльности?
Дедушка- да, метаданные нужно вести руками и делать это очень аккуратно

Можете описать как в классических системах метаданные ведутся не руками?
В клике это действительно очень кропотливая работа, легко упустить из виду "мелочи".
Дедушка- да, ETL скрипты "статичны" (нет переиспользования кода)

Это проблема, иногда большая. Особенно когда пишешь очень громоздкие формулы с сет аналисис для пересчёта "на лету", и эти громоздкие конструкции распиханы в ГУИ по разными местам, и нельзя, условно, "написать и вызывать функцию". Хотя в QS есть MasterItems, с ним надо ещё поиграться.
Если же говорить о "повторном использовании кода" на уровне загрузки, то в клике уместно говорить о "повторном использовании QVD файлов". То есть могу уже почищенную, вылизаную, сведенную дату сложить в QVD-шку и обращаться к ней из разных мест.
Дедушка- да, весь процесс, скажем так, немного "костылен" по сравнению с другими BI системами

Согласен. Очевидно, как раз из-за упомянутых Вами проблем.
Дедушка- да, это файловое ХД доступно только Qlik-у и больше никому

Это, видимо, один из главных недостатков.
В принципе, на уровне костылей, можно выгружать в CSV вместо QVD и тянуть из них наружу.
Дедушкано тем не менее... при желании и достаточном уровне знаний построить достаточно адекватную BI экосистему можно.

Да, и тут вопрос костов очень важен. Если данных немного, то с большой вероятностью имеет смысл.
Проблема только, что когда объёмы растут, можно столкнутся с полной перестройкой ETL/DWH на другие технологии.

BarclayBarclay, а не могли бы Вы чуть подробней по пунктам описать где конкретно плохо:

1. Стоимость решений/лицензий на клике(очень высоко в сравнении).
Если речь о решениях - какие именно решения на клике дороги (ETL, DWH, морда) и в сравнении с чем?
Если о лицензиях - с какими продуктами сравнивали, скажем, можете сравнить стоимость PowerBI и Qlik?

2. Целостность данных - можете дать пример конкретной проблемы с ассоциативной моделью и описание решения другим инструментарием (каким?) ?

3. "Когда данных очень много, клику всё-таки требуется хранилище." На каких объёмах пришли к выводу что кликовского решения ХД недостаточно?
Какие альтернативы решили проблему и каков порядок костов (лицензии, человекочасы)?

4. "BI отдел был переучен на PowerBI, Lumira в прошлом году. И хочу сказать, что пошло как по маслу".
Так PowerBI или Lumira?
А ETL, DWH на чём?
Что значит "пошло как по маслу"? Лицензии_дешевле_&_время_разработки_короче_&_с_ целостностью_данных_вообще_нет проблем_&_etc ? Или как-то иначе?

Заранее спасибо.

P.S. Мой интерес не праздный.
Возможно, благодаря Вашим ответам удастся убедить моё начальство протестировать у нас другие продукты.

1. Стоимость решений ~ Среда разработки 64 gb + продуктив 384 gb = в ЦОДе стоИт (дорого стОит). + лицензии (около 40 тыс$/год) точную сумму я не буду писать.

В сравнении с SQL Server Software Assurance + Pro cloud, около 20 тыс $/год

2. Конкретные примеры? Есть множество QVD с непонятной недокументированной логикой от предыдущей команды, и гора инцидентов, при разборе которых выяснялось, что в полях, где должны быть буквы оказались цифры. На этой негативной ноте всё и "порешилось" в сторону PBI, Lumira. Естественно, что не в один день.
А я как-то не горю желанием доказывать руководству, обратное, что клик - он хороший, просто нужно провести трудоемкую ревизию месяцев на 6 с разбором всей логики, расчетов и пр. Тогда как сам я занимаюсь Microsoft'ом, SAP'ом.

3. Около 100 gb ежемесячно

4. Lumira для 5 юзеров контроллинга с отчетами напрямую из CDS view (SAP FI/CO),
PowerBi для всех остальных юзеров(sales) (SQLServer DWH+SSIS+SSAS+PowerBI report server). с целостностью данных нет проблемы, вы правы, этот вопрос решается при загрузке в DWH.

Насчёт цен за лицензии/облака возможно Вы правы.
Судя по Вашему описанию у вас 100-200 юзеров.
Возможно выгодней MSSQL+PBI.
Хотя конечно надо считать конкретно.

Насчёт всего остального вот SpellBuilder хорошо написал:
SpellBuilderНу вот Вам и ответ, компетенции, нежелание восстанавливать и погружаться в другое, прокачка своих скилов и обоснование удешевление и все плохо. Наша классика.

То есть очень распространённая ситуация - ругают инструмент, топы верят, вбухивают кучу денег в замену, а копнёшь чуть - дело в исполнителях, или в их отсутствии.