Yuri Abeleпричем бежать все будет в оперативной памяти и в сети без сброса во временные хранилища.
И с визуальным мониторингом всех узлов и экземаляров что в дизайнере, что через Web на самих кластерах

вот картинка, как оно до старта выглядит:
говорит, что первый шаг выполняется локально, а второй, третий и 4хй на кластере из двух узлов, при третий и четвертый с партиционированием:


А это уже в RunTime показывает что происходит на конкретном кластерном узле:

Картинки отсюда: www.ibridge.be/?p=62

По поводу шедулера и его заданий. Тут (как я выше в сравнении писал) SSIS (все редакции) и PDI (community edition) одинаковы - у них нет встроенного планироващика заданий (Scheduler).
У MS SQL Server Agent есть, ну так SSIS пакеты в нем с коммандной строки запускаются (через dtsexec.exe).
Dataflows и Workflows (Transformations & Jobs соответсвенно) в PDI тоже могут запускаться с коммандной строки, а значит тоже могут быть добавлени заданиями планировшику заданий.
И тот и другой могут поэтому и планировщиком операционной системы запускаться.

У PDI в enterprise edition есть свой планировщик.
Ну а помня, что PDI и на Linux бегать может, так можно его и там или встроенным crone или, к примеру, купленным UC4 запускать.

Yuri AbeleУ PDI в enterprise edition есть свой планировщик.
Я об этом: Schedule Jobs

Ivan DurakYuri AbeleFree/Commerce
SSIS
- коммерческий продукт

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

Ivan DurakЧто у этого PDI с Push Down Optimization??? может трансформации на субд выполнять?
Это Вы с "информатикой" сравниваете? Нет, в автоматизмированном виде нет. Есть отдельные компоненты типа Database Lookup или ряд автоматических SCD (slowly changed dimension) компонент, которые чего-то там на стороне БД колдуют. Но глабально для всех компонентов - нет, нету.

Ivan DurakPush Down Optimization
Вообще это классный ответ на вечный спор где оптимальнее - в СУБД или ETL Tool

Yuri AbeleIvan DurakЧто у этого PDI с Push Down Optimization??? может трансформации на субд выполнять?
Это Вы с "информатикой" сравниваете?
PowerCenter 8 Standard Edition 32-bit Single-core (1-3) per CPU-core Multi-OS Production License - $28,802.26.
Охренеть, простите за мой французский. И это только конфигурация железа по минимуму ...

Критик,

спасибо за отзыв (а то молчат все, даже обидно :-) )!
SSISDB для меня вообще чем-то новым оказалось.
В моём сравнении я про репозитори в MSDB говорил.
Пойду разбираться.

Критик,

SSISDB - а там через GUI можно что-то делать, или всё через скрипты?

Yuri AbeleКритик,

SSISDB - а там через GUI можно что-то делать, или всё через скрипты?
Можно

Ivan DurakYuri Abeleпропущено...
Вообще это классный ответ на вечный спор где оптимальнее - в СУБД или ETL Tool
оптимальнее иметь выбор. И плохо когда его нет.
Как это связано с возможностью разрешить визуальному инструменту ETL, по-возможности "погрузить" ETL-логику на уровень базы данных. (Это я про Pushdown Optimisation - вы гляньте что это, я впечатлился)

Ivan DurakВ современном варехаусостроительстве например, с ростом популярности MPP субд, растет и востребованность PDO !!!
Вы под PDO что имеете в виду?

Ivan DurakВ сегмете bi например MOLAP окончательно и бесповоротно проиграл войну ROLAPу.
( Т.е. востребованнее переложить нагрузку на субд).
Честно и без обид - бред №1
Всё зависит от задач и объемов данных. Мы проводили исследование/сравнение всех ималементаций persistence модели SSAS (MS Analysis Services) - от MOLAP то Tabular в кобинации с Direct Query и Column Store Indexes.
Так вот, если куб загружен в MOLAP модели, то все остальные после прогрева куба в лучшем случае не хуже по производительности. Даже in-memory тоже самое, что и прогретый MOLAP куб.
В чем экономия, так это во времени разработки на простых, но хорошо сдизайненых DWH базах.

Ivan DurakТо же самое де-факто уже и с ETL происходит. Он проигрывает ELT. Маштабировать MPP субд уже можно легко.
Честно и без обид - бред №2
В чём проигрывает? В производительсности всего процесса - так оно почти всегда так.
Приемущество ETL не в этом, хотя есть и тут много примеров, когда ETL быстрее.
Приемущество ETL в:
- самодокументированности - обыкновенный screenshot - половина документации
- визуальности процесса разработки
- смещения акцента разработки с деталей синтаксиса скриптов базы данных на детали бизнес логики
- централизации в одном месте всего ETL процесса
- смещение необходимого минимума знаний разработчика с глубин языка в детали процесса. У нас на фирме два доктора (я про степень) в Data Scientist - один в Big Data, другой в анализе неструктурированный текстов.
Что один, что другой владеют SQL, но в объеме ANSI 91, врядли больше. Также знают Java, но как язык и среду разработки - о J2EE имеют поверхностные знания. Но что они творят в Big Data проектах!... Кстати используют Pentaho PDI в роли ETL инструмента.

Ivan DurakМаштабировать MPP субд уже можно легко.
Никто и не спорит. Но в ETL проще (я про те, где эта поддержка встроена на на зачаточном уровне).

Ну и не будем забывать, что не только DBMS идут вперёд.
Разработки ETL продуктов тоже не стоят на месте и зачастую осуществляются теми же фирмами.

Yuri AbeleIvan DurakВ современном варехаусостроительстве например, с ростом популярности MPP субд, растет и востребованность PDO !!!
Вы под PDO что имеете в виду?
Или Вы про PDW (Parallel Data Warehouse)?

Ivan Durakдопущение "если куб загружен" сводит на нет все дальнейшее рассуждение.
По факту - изменение в модели - и все, куб протух. А перестройка молапа - это боль.
У Вас что real-time MDX/DAX запросы? В большинстве BI задач или работа идет по полным свершившимся дням, или даных не много (сравнительно) и R-ROLAP-а (ROLAP + proactive caching) достаточно.
Во втором варианте, к примеру, приложения планирования реализуются.
А там или две фазы планирования:
1. на высоком уровне грануляции - данных мало все отрабатывает за пару секунд максимум.
2. одноразовый splashing ("размазывание" по детям) и тут всё равно время задержки на запись.
Или обе фазы сразу и тут всё равно время задержки на агрегирование - и уже не важно кто его делает.
Ну а column store indexes можно благополучно и к R-ROLAP прикрутить.

Все остальные - уже не типичные решения. Можно пример из жизни , где MOLAP или R-ROLAP не помог?

Ivan DurakКогда перестройка всех молапов занимает часов 6-8.
И что, на таких объемах данных прямые запросы к базе данных ну прям летают? Сомневаюсь.
Мы тоже не 100 милионов строк одной таблыцы процессим.
А 6-8 часов на процессинг - IMHO дизайн OLAP баз страдает. Вы что, все в режиме Full Load грузите?
Как у вас там с партиционированием на уровне OLAP и RDBMS?
Настройку slice-ов тоже не забываем?
Грузим все параллельно, или последовательно?
И т.д. и т.д. Я не хочу ничего сказать, но 6-8 часов это даже для initial load многовато.

Ivan DurakYuri Abeleпропущено...
Вообще это классный ответ на вечный спор где оптимальнее - в СУБД или ETL Tool
оптимальнее иметь выбор. И плохо когда его нет.
Выходит 6.0 версия Pentaho Data Integration, в ней анонсирована Push Down оптимизация.
Но я пока этого не видел. Как увижи и поковыряюсь - отпишу сюда.