Всех с Новым Годом!
Ищу единомышленников по данному продукту.

В России его очень мало используют, незаслуженно я считаю.
Внедрил его уже в 3 компаниях. Сейчас работаю еще над 2 компаниями.
В целом в jedox palo уже 1,5 года.
Да, GPU несомненно интересно использовать.
Отмечу вот какую интересную идею, которая меня посетила за все время работы в проектах:
сотрудники финансово-экономических служб в большинстве своем используют ms excel. Выглядит это следующим образом: есть множество папок с файлами, которые содержат листы со ссылками друга на друга.
Экономисты открывают учетную систему, которая используется в их организации, и копируют оттуда "сырые" данные в excel, которые потом при помощи функций excel обрабатывают и сохраняют результаты в очередном файле.
Учетные системы: 1С, биллинговые системы и т.д.
Так вот, используя palo можно все формулы ссылки из excel переложить в формулы palo (т.н. rules), а коллекции файлов и листов переложить в кубы. Т.о. получится переход от чистого excel в palo (как базу данных) + excel (как интерфейс).
Количество файлов сократится, формулы станут защищенными.
Что касается импорта данных, то данные отлично импортируются при помощи ETL конструктора.
Т.о. идея использовать palo не только как olap, а как расширение возможности excel.
Это и расширяет круг возможных задач, клиентов.
Кому интересно, могу рассказать о минусах \ плюсах, тонкостях продукта при внедрении.

Jurii,

Да, у меня такое тоже было. Выкручиваться приходилось достаточно банально: пишем макрос для преобразования в xml или csv исходных "сложных" excel файлов. Далее уже ETL'им.
Что касается бизнес-логики, то в этом то и интерес - избавиться от excel как держателя бизнес-логики и сделать держателем olap.
Тогда, к примеру можно и writeback нормально использовать.

Jurii2 sqlolap:
Вопрос в том, может ли финансист/экономист запускать макрос, потом закачивать эти данные в PALO, самостоятельно дорабатывать настройки/бизнес-правила PALO, или по этим вопросам он должен обращаться к ИТ-специалистам? И как PALO хранит данные - в одном кубе или в нескольких? Например, если у нас есть бюджет продаж, бюджет ФОТ, бюджет затрат и БДР - сколько у PALO будет кубов?


Вот ответ, почему я продолжил с palo, едва познакомившись с ним. Сперва переживал за то, что если продукт смогут освоит только ИТ специалисты, то меня ждет провал. Оказалось, что продукт достаточно прост и экономисты его успешно осваивают, конечно при должном первоначальном обучении. Кроме того, поняв его логику работы, далее они самостоятельно создают измерения, кубы и формулы. Причина успеха, имхо только простота интерфейса.
Из моей практики: экономисты макрос запускать смогут, настроить ETL по аналогии также смогут. Финансисты в чистом виде, скорее всего вряд ли. Они хорошо строят срезы, но формулы сами правят плохо. Тут причина скорее в том, что их профессия не подразумевает работу с формулами excel так как это умеют экономисты. Для финансиста необходимо достигнуть профицита на р\с балансировкой поступлений\кредитов и провести план-фактный анализ в pivot, drilldown'сь до необходимого уровня. У него расчетов как таковых мало.
К ИТ специалистам приходилось обращаться, когда необходим настроить ETL для импорта xml (xpath все таки), для csv - нет (все проще).
В скольких кубах palo хранит данные? Как зададите. Это может быть многомерный куб, а может быть несколько кубов связанных м\у собой формулами.
На Вашем примере. Я бы сделал 4 куба для простоты понимания: 1 для бюджета продаж, 1 для бюджета ФОТ и т.д.
БДР - куб, который агрегирует результаты. При этом ввел бы измерение версии бюджетов, и мог бы хранить историю бюджетов или возможность прикинуть риски в real-time.
А можно сделать один куб, чтобы при построении среза сразу было видно откуда что.

Jurii,

Palo на низком уровне хранит данные в памяти, периодически синхронизируя их со своими csv, log и archived файлами.
Palo - MOLAP и записи он в реляционной базе не хранит, только если дело касается drilltrough.
Для доступа извне имеется драйвер odbo\xmla, поддерживается mdx. К сожалению, тут у меня пока опыта нет, но в будущем планирую его расширить.
Далее по открытости и сразу о минусах, раз уж обещал. У palo открыт API, планирую сделать для palo расширенный редактор формул, ибо штатный не устраивает в плане полного перехода от excel:

1. при выборе элемента в измерении куба combobox содержит не все элементы. Приходиться названия элементов иногда прописывать руками.
2. при выборе элемента в измерении куба combobox нельзя пользоваться древовидной структурой( родитель-дети или агрегация-базовый элемент). Только выбор самого элемента (родительского или базового), а открыть родительский и посмотреть что там - нельзя.
3. при выборе элемента в измерении куба combobox нельзя пользоваться сортировкой.
4. отсутствует подкрашивание членов формулы, из-за чего текст "сливается" и тяжело формулу читать.
5. отсутствует автовычисление членов формулы, чтобы на этапе конструирования формулы можно было смотреть из каких значений складывается результат, там где это возможно.

Voyager_lan,

1. Интересует какого уровня сложности бизнес-логику (формулы) вы делали в бюджетной OLAP-модели PALO, в частности когда делали БДР? Какие были проблемы?

Это был инвестиционный холдинг, который инвестировал в различные отрасли: от недвижимости до лесопромышленности.
15 компаний.
Порядка 200 базовых статей.
Особых проблем то не было.
В БДР вот какого рода проблему встретил. Если БДР собирается не одной итерацией, то возникает множественные вычисления одних и тех же ячеек. Например, переменные расходы идут как удельник Х программа продаж. При этом программа продаж также не просто задается, а вычисляется. Получается, что при каждом обращении в ячейки БДР, происходят одни и те же итерации. Понятно, что есть кэш. Но если бюджет уже утвержден, то некоторое "подвисание" (на 10-20 сек.) существует, все таки бюджетов масса и доля переменных расходов большая -> много вычислений. Его я убрал методом переноса результата промежуточных расчетов в ячейки, т.е. просто записывал числа в ячейки. Реализовал через ETL.
Проблемы были в БДДС для исключения внутренних оборотов для агрегаций компаний (элемента Холдинг).
Приходилось прописывать формулы для зануления.
Ну и пришла в голову идея создания своего редактора, чтобы облегчить жизнь пользователей palo (см пост-ответ 2 Jurii).

2. WorkFlow и комментарии, - как выкручивались?

С этим в palo проблемы. В новой версии 3.3 есть возможность документирования графами ETL процессов. А вот workflow для бизнес-логики как связи м\у кубами - такого инструмента пока нет.
В своем редакторе формул планирую это момент учесть.
Комментарии создавать можно. Можно создавать атрибуты (текстовые) у элементов измерений и через них документировать, но руками. Зато, всегда документация при базе и нет необходимости тащить doc, vsd и прочее.
Вот какая идея есть: известно, что ETL может извлекать правила. Если их трансформировать в текст, то можно записывать результат в текстовый куб. Если создать регулярный job, то документация будет автообновляться с изменением правил в кубе.
Я возможно неверно вопрос понял, уточните, пожалуйста, что понималось под workflow. Может, Вы имели ввиду возможность выгрузки в шарепойнт какой-нибудь...

Jurii2 sqlolap:
И можно ли в PALO пользователю налету создавать новые версии данных, или нужно работать в заранее заданных версиях?

Из минусов palo: если куб уже создан, то добавлять в него измерение нельзя. Придется создать новый куб и через ETL перенести значения из старого куба.
Если мы говорим о добавлении\удалении элементов внутри измерения - то это можно налету в дизайнере моделей. Это может делать обычный пользователь (если права есть).

Voyager_lan,

Можно реализовать при помощи измерения, назовем его шаг согласования.
Пусть есть куб Согласования.
Права в palo настроить для 3 учетных записей, чтобы каждая учетная запись имело право W только в свой элемент измерения шаг согласования.
В кубе БДР прописать правило, что фактические значения = значение Х значение куба Согласования (!Год,!Месяц, !День, "Финансовый директор"). Если финдир согласовал (значение 1 в кубе Согласования), то результирующий БДР ненулевой.

Voyager_lan,

Инфа по формулам - а что конкретно не получается?
Проекты делал в 3.1, 3.2, сейчас буду делать в 3.3.
Как платные так и бесплатные версии.
Сервер сам не лицензируется.
Цена на октябрь 2011 для Suite: ~ 62 круб. за бессрочную concurent лицензию.
Проблема в том, что производитель их бандлами по 10 шт продает.
С конкурентами не сравнивал, но имхо дешевле чем у гигантов с учетом того, что в suite входит.
GPU дорогой имхо - 120 круб лицензия на одну видеокарту.

Voyager_lan,

Как я понял из переписки с Jedox, минимальная сумма для закупки 620 тыс. руб.
Т.е. 10 купите независимо от того, сколько будете использовать реально :-(
Я думаю, что имеет смысл сначала бесплатную использовать, различия несущественные.

ps привожу переписку
"...We sell Palo for Excel and Palo Suite premium as a concurrent user license. There are no limits on named users, only the number of simultaneous (concurrent) users at a time.
The minimum number of concurrent users for a license is 10.
The price for Palo for Excel premium is 894 Euros per concurrent user
The price for Palo Suite premium is 1490 Euros per concurrent user..."

товарищъ,
Чего нет в бесплатной версии:
Отсутствие Report Manager в web palo. Это собсно никуда не влияет, отчеты сами доступны в File manager.
Отсутствие script в ETL. Сложную логику вызова множества job' ов не реализовать
Отсутствие экспорта в pdf. Экспорт в excel нормально будет работать, как снапшоты, так и со ссылками PALO.DATA(..)
Отсутствие DrillThrough. Drilldown есенно нормально будет работать.
Отсутствие использования многоядерности проца. Зависит от того, насколько тяжелые отчеты будете делать. Подсказка: для быстрого вывода отчетов нужно использовать Paste View и тип выбирать DATAV.
Отсутствие odbc. Pivot сторонними средствами не построить. Не особо и нужно, встроенного Palo analyzer хватает.
Отсутствие пункта Palo (Ribbon) в главном меню Ms Excel. Все возможности Palo доступны в пункте главного меню Настройки.

evgeny080481,

Да, можно дать право #_GROUP_CELL_DATA<Название куба> W - это запись в ячейку.
Включаете в группу необходимых людей и строите проекцию с этой группой.
Подразделения и договора - это разные измерения.
Если говорить про детализацию в pivot (грануляцию): статья расходов -> подразделение -> договор
Файлы не могу - nda. Сделаю тестовую базу и сброшу пару отчетов, давайте email.
По документации Товарищъ уже ответил.
Родная дока на английском вполне достойная.