КэптенТот же ETL от Qlik - тема отдельной дискуссии
Ага :) НО! Свою задачу он решает отлично. Под конкретный дашборд с его помощью можно подготовить любые данные. Как только масштаб источников данных и дашбордов-потребителей начнет расти, нужно сказать "стоп" и перенести эту логику на уровень хранилища в полноценную среду ETL. "Перенести" -- это не обязательно переделать; если расчетные данные из скрипта Клика всех устраивают, то можно тупо встроить их вызов в общий ETL по типу внешней программы. Но до такого масштаба еще нужно компании дорасти, Клик должен завоевать умы и сердца в куче подразделений :)

На семинаре по Клику Георгий и его коллега рассказывали, что вендор предлагает отдельный инструмент для визуализации потоков преобразования данных. Но он почему-то совсем не пользуется спросом, ни у нас, ни на западе. Клиентов, получается, устраивает существующий "скриптовый ETL".

Георгий, можешь прокомментировать, как реальные клиенты справляются с накопленным багажом? Есть успешный опыт рефакторинга скриптов и отчетов Клика после N лет эксплуатации?

JuriiСравнение идет с 9 версией TM1, а версия 10, с визуальными средствами Performance Modeler, вышла более 4 лет назад
Сравнение Anaplan с TM1 опубликовано в январе 2013 года, соответственно материалы для сравнения подбиралсь еще в 2012 году.
В 2012 году основной стабильной версией была 9-я -- сужу по датам выхода релизов в материалах от IBM: http://www-01.ibm.com/software/support/lifecycleapp/PLCDetail.wss?synkey=W204762F30868K79&from=spf

Хватит рассказывать сказки про уникальные инструменты Default BI, подразумевая что только IBM развивает свои продукты все эти годы, а остальные ничего не делают, а только публикуют устаревшие сравнения.

JuriiМодели среднего и большого размера в Anaplan тормозят, из-за простой реляционной архитектуры.
<...>
Каждая пустая (!) ячейка в Anaplan занимает место (отсюда вывод, что под каждую ячейку генерится запись в реляционной таблице)
Источник про "простую реляционную архитектуру" предъявите, пожалуйста.
В каком месте архитектуры Anaplan пустая ячейка занимает место -- на диске? в памяти? в какой области памяти с точки зрения движка расчетов?
Между утверждением "пустая ячейка в Anaplan занимает место" и "под каждую ячейку генерится запись в реляционной таблице" вообще нет связи.

JuriiМногомерная архитектура (например, Hyperion Planning) работает получше. Но нормальная производительность достижима только при архитектуре, когда расчеты ведутся в оперативной памяти, например, как в ТМ1.
Исходные данные всех систем изначально лежат на диске, а расчеты всегда выполняются в памяти. Различия могут быть только в том, что движок делает с расчитанными данными:
1) сбрасывает после просмотра их пользователем сразу,
2) сохраняет на какое-то время в памяти или
3) сохраняет на диск чтобы в будущем их прочитать без повторного расчета.

TM1 работает по 1-му или 2-му сценарию, как я понимаю. Поправьте меня если я не прав.
Hyperion Planning/Essbase - по 3-му. При этом все данные кэшируются в памяти при ее наличии.

Кто лучше? В разных ситуация по-разному. И сильно зависит от кривизны рук внедренцев.

На правах адепта Oracle потролю TM1 -- мне рассказывали о приложениях TM1, запуск которых занимает 4-8 часов -- все это время движок выполняет расчеты на исходных данных, сохраняя результаты в памяти преждем чем дать доступ конечным пользователям.

JuriiУ Anaplan не было ресурсов для разработки серьезного по архитектуре решения.
Пожалуйста, хватит гнать пургу. Судя по рассуждениям, вы недостаточно понимаете преимущества облачной архитектуры для разработчика.

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

Чтобы сделать быстрый масштабируемый движок для жестко фиксированного системного окружения достаточно иметь несколько разработчиков с высоким интеллектом и хорошее понимание рынка у маркетологов и продат манагеров. Зацените пример -- Yandex ClickHouse ( http://clickhouse.yandex) -- это не облако, но пример качественной внутренней разработки в аналогичных условиях -- за несколько лет, начиная с 2010-2012 (2012-й начало пром эксплуатации в самом Yandex'е) года очень небольшой командой, за зарплату, был сделан движок который рвет по производительности большинство существующих много лет коммерческих тиражных решений.

JuriiНе думайте, что все облачные решения по определению работают с высокой производительностью. Модели среднего и большого размера в Anaplan тормозят, из-за простой реляционной архитектуры. Выход из этого - делать только простые модели.
Не проблема сделать быстрый многомерный калькулятор. Посмотри как работают продукты на рынке, вкури математику и повтори с небольшими вариациями чтобы обойти патент. Основатель и технический архитектор Anaplan, Michael Gould https://www.linkedin.com/in/migould был до этого 9 лет разработчиком Adaytum/Cognos Planning и он хорошо должен был изучить, как делать и как не делать аналитические приложения.

Проблема, как сделать быстрый калькулятор сразу для всех пользователей -- сотен, тысяч, десятков тысяч. На рынке нет такого опыта, по крайней мере в доступном виде. Для Oracle Essbase я слышал об инсталляциях в 10К пользователей, но это что-то "за гранью". Обычно требуется очень много железа, куча всяких ухищрений для балансировки и распараллеливания и борьбы с утечками памяти.

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

Облака пока не совершенны. Но у Anaplan'а есть растущая база пользователей, на которой можно обкатывать новые идеи по оптимизации. Так что производительность будет еще расти, а цена -- падать.