Free/Commerce
SSIS
- коммерческий продукт
PDI
- тот редкий случай open source, когда бесплатная communty edition самодостаточна и на вынуждает покупать enterprise edition

Runtime
SSIS
- .NET (managed C++)
- только на Windows
PDI
- Java
- Различные операционные системы

Файлы
SSIS
- Всё может размещено в одном или нескольких файлах
- Начиная с версии 2012 файлы могут быть не только самостоятельными, но и частью SSIS проекта
PDI
- каждый Workflow или Transformation размещаются в отдельных файлах

Разделение Workflow и Dataflow, Layout
SSIS
- Формат файлов - XML
- Файл (пакет) - один Workflow множеством компонент ("Tasks")
- Компоненты ("Tasks") могут быть вложенными (Secuence Containers)
- Dataflows являются самостоятельными Tasks в Workflow
- (2012) В варианте проекта могут быть использованы общие соединения (Data Connections), при этом они должны находиться внутри папки проекта.
PDI
- Формат файлов - XML, при этом намного проще и читабельнее, чем у SSIS
- Workflow - Job-файлы
- Dataflows - Transformation-файлы
- Job и Transformation файлы содержат множество компонентов ("Steps")

Сохранение, версионирование
SSIS
- В файловой системе - можно применить MS-TFS, SVN, GIT и т.д.
- В центральном репозитори, но только последняя версия (номер версии можно запросить через T-SQL)
- Начиная с 2012 возможен хоть и убогий, но какой-никакой Diff/Merge
PDI
- В файловой системе - можно применить MS-TFS (на Windows), SVN, GIT и т.д.
- В центральном репозитори, с сохранением версий
- Встроенного Diff/Merge нет

Допустимые именования компонент (те, что дает пользователь этих инструментов)
SSIS
- Некоторые символы запрещены, например /\ : [ ]
PDI
- Ограничений на именование практически нет


продолжение следует: ==>>

Источники и получатели данных
SSIS
Data sources
- XML файлы
- Excel файлы
- Текстовые файлы (CSV)
- ADO.NET соединения
- OLEDB соединения
- ODBC возможны через OLEDB-2-ODBC Bridge
- Raw-файлы (бинарные сериализованные потоки данных)
- решения третих фирм (например для Apache Hadoop)
Data targets
- те же, что и в data sources
- "прямой" native client для MSSQL (если на том же компьютере, где и сам сервер БД)
- сохранение в переменную (Recordset)
- MS SSAS (OLAP)
- начаиная с 2012 некоторые сторонние (Oracle, Terradata, SAP)
- Big Data - от сторонних производителей
PDI
Data sources
- JSON файлы с возможностью декомпрессии из ZIP
- XML файлы с возможностью декомпрессии из ZIP
- Excel файлы с возможностью декомпрессии из ZIP
- Текстовые файлы (CSV) с возможностью декомпрессии из ZIP
- JDBC
- NoSQL (например mongoDB)
- Аналитические базы данных (например Mondrian)
- SAP
- Google Analytics
- Big Data (Apache Hadoop и другие)
Data targets
- те же, что и в data sources
- текстовые форматы можно выводить в Servlet и получать фактически REST-WebService (см. ниже про кластеры)
- для MSSQL есть свой JDBC и есть JDBC поставляемый Microsoft. Свой быстрее, но от Microsoft поддерживает интегрированную аутентификацию, но от Microsoft храмает режим preview.


продолжение следует ===>>

a_voroninSSIS
- .NET (managed C++)
PDI


Не смешите меня. C# / VB.NET там


Вы не дотерпели и сказали не о том. Я вёл речь о том не чем написано. О скриптовых расширениях я ещё буду говорить. Дайте дописать!

a_voroninSSIS
- (2012) В варианте проекта могут быть использованы общие соединения (Data Connections), при этом они должны находиться внутри папки проекта.
Плохо выучили матчасть.
Спасибо за поправку, какраз тут я не был уверен.

P.S. Дайте дописать! Пожааааааааааааалста!

1:1 Row-Level - Function that can be applied locally to a single row.
SSIS
- Character Map
- Copy Column
- Data Conversion
- Derived Column
- Script Component (C#, VB.NET)
- Execute SQL
- OLE DB Command
- Cache Transform
- Slowly Changing
Dimensions
- Other Filters (not null,
selections, etc)
- (2012) DQS Cleansing Transformation
PDI
- Add Checksum
- Add Constants
- Add Sequence
- Add Value fields changing sequence
- Add XML
- Calculator
- Number Range
- Replace in String
- Select Values
- Set field Value to a constant
- Split Fields
- String Operations
- Strings Cut
- Value Mapper
- If field Value is null
- Null if...
- ETL Metadata injection
- Filter Rows, Last Row, Java Filter,
Regex Evaluation
- Scripting, Java, JavaScript, SQL.

N:1 - Unary Grouper: Transform a set of rows to a single row.
SSIS
- Aggregate
- Pivot
PDI
- Row Flattener
- Unique Rows
- Unique Rows (HashSet)
- Analytic Query
- Group by
- Memory Group by
- Univariate Statistics

1:N - Unary Splitter: Split a single row to a set of rows.
SSIS
- Unpivot
- Fuzzy Grouping
PDI
- Row Normaliser
- Split Fields to Rows
- Clone Row

1:N - Unary Holistic: Perform a transformation to the entire dataset(blocking).
SSIS
- Sort
- Percentage Sampling
- Row Sampling
PDI
- Sort Rows
- XSL Transformation
- Change file encoding
- Sample Rows

Продолжение следует: ===>>

Binary or N-ary: Combine many inputs into one output.
SSIS
Join-like
- Merge Join
- Lookup
- Import Column
- Fuzzy Lookup
- Term Extraction
- Term Lookup
Union Like
- Union All
- Merge
PDI
Join-like
- Get ID from Slave Server
- Row Denormaliser
- Set Field Value
- Append streams
- Database Join
- Database Lookup
- HTTP Post, client, REST, Stream, SOAP Lookup.
- Sorted Merge
- Merge Join
- Merge Rows (diff)
Union Like
- Join Rows

Routers: Locally decide for each row, which of the many outputs it should be sent to.
SSIS
- Conditional Split
- Multicast
PDI
- Process Files
- Switch/Case
- Dynamic SQL Row
- Mapping (input, output, sub transformation)


Продолжение следует: ===>>

Производительность (замерялось в виртуальной машине: SSD, 4 CPU Cores, 4GB RAM)

CSV-to-CSV, 500.000 Rows R/W 540 MB файл
SSIS
- 16 секунд
PDI
- 51 секунда

MSSQL-to-MSSQL, 400.000 Rows R/W, 150 MB данных
SSIS
- BULK load - 11 секунд
- non-bulk load, Single inserts - 58 секунд
PDI
- MS JDBC, Batch Inserts - 21 секунда
(INSERT комманды собираются в пакет и потом разом отправляются на сервер)
- Open Source JDBC (JTDS), Batch Inserts - 15 секунд
(INSERT комманды собираются в пакет и потом разом отправляются на сервер)


Продолжение следует ===>>

Сложность разработки, время на разработку

Палитра компонент
SSIS
- намного меньше, чем в PDI
PDI
- намного больше, чем в SSIS

Расширяемость
SSIS
- .NET (при сохранении компилируется в IL-Code)
- C# Scripts
- VB.NET Scripts
- возможно разрабатывать свои расширения на .NET
PDI
- Java Code
- JavaScript
- возможно разрабатывать свои расширения на Java

Отладка
SSIS
- один Data-Flow может быть только полностью деактивирован или активирован
- Точки останова (breakpoints) можно ставить на любое из событий SSIS, и в момент остановки можно
а. активировать отладчик на внешних custom .NET расширениях
б. изменять значения переменных и доступных объектов .NET
- начиная с 2012 можно отлаживать скриптовые Tasks
- Вообще MS Debuger для .NET он не превзойденный, то, что может он, в таком объеме не может никто больше
PDI
- возможна пошаговая деактивация отдельных соединений между отдельными steps. Т.е. не сами компоненты деактивируются, а соединения между ними - т.е. как бы обрыв в Data- или Work-flow
- практически отсутствует возможность отладки Java или JavaScript компонент (steps)

Протоколирование
SSIS
- Возможно одновременное протоколирование в
а. Текстовые файлы
б. XML файлы
в. MSSQL базу данных
г. MSSQL Profiler
д. Windows Event Log
- можно явно указать какие конкретно события какому listener будут переданы
- во внешних протоколах, естесственно, отсутсвует цветовая подсветка событий (если Log-Reader-ы третих фирм, они могут больше), а в дизайнере цветом подствечивает, но обрезает тексты
- отсутствует понятие уровня детальности протоколирования, но, как я уже сказал есть возможность выбора отдельных событий
PDI
- возможно отдновременно протоколировать в файлы и в одну базу данных, но при этом все пишется не в одну таблицу, а есть уже определенныя нормализация данных. К тому же протокол из базы данных позволяет частично отображать в дизайнере историю прошлых загрузок
- гораздо больше чем в SSIS отдельных свойств для протоколирования (я про метаинформацию чего писать в log)
- нет понятия событий, но есть понятие уровня детальности (error, ..., basic, ..., row-level). На уровне row-level можно практически восстановить что именно писалось в базу


продолжение следует: ===>>

Динамическое конфигурирование

Аргументы, параметры, переменные, параметризированные вызовы файлов ETL
SSIS
- все переменные должны быть заранее продекларированы
- все переменные можно увидеть в одном списке
- за каждой переменной может прятаться выражение для её динамического вычисления
- переменные видны только на уровне того пакета, в котором они продекларированы, но можно передавать значения переменных дочерним пакетам
- у ETL файлов можно отдельно продекларировать входные именованные параметры. А при запуске с коммандной строки можно переписать default значения именованных параметров ETL файлов.
PDI
- переменные могут создаваться налету, с различными областями видимости от локальной до глобально на уровне JVM
- у ETL файлов можно отдельно продекларировать входные именованные параметры. А при запуске с коммандной строки можно переписать default значения именованных параметров ETL файлов.
- возможно с коммандной строки передать до 10 неименованных переметров (доступ к ним идет через индекс)

Передача данных между ETL файлами
SSIS
- сильно ограничена, практически только через внешние файлы или БД
PDI
- возможна, причем если один DataFlow передает данные другому, то можно настроить то примет ли он их все разом, или только первую строку или будет вызван итеративно для каждой строки

Совместное использование кода
SSIS
- в варианте проекта - совместное использование соединений
- только из Work Flows возможно вызывать другие work flows
- нет возможности meta data injection
PDI
- соединения данных и даже отдельные шаги можно сделать shared - мечта SSIS-програмиста: написать скрипт один раз и использовать его в куче мест. Причем так, что достаточно в одном месте что-то изменить, как изменения станут доступны всем пользователям. <Right Mouse Click>+<Share> и всё!
- Work Flows могут вызывать другие внешние Work Flow и Data Flow
- Data Flows могут вызывать другие внешние Work Flow и Data Flow (итеративно для каждой строки или разово передавая весь поток данных)
- возможна meta data injection, т.е. в момент вызова внешнего файла поменять настройки его компонентов


Продолжение следует ===>>

Deployment, различные настройки в различных окружениях (Dev, Test, Stage, Prod)

Deployment
SSIS
- File System
- Msdb Database
- SSIS Service
а. Package Deployment
б. (2012) Project Deployment
PDI
- File System
- Repository

Настройка окружения (Dev, Test, Stage, Prod)
SSIS
- XML
- Registry
- System Environment Variables
- Parent Package
- SQL Server Table
- (2012) Paket parameters – sind unabhängig von Objekt
- (2012) project.params Datei – sind unabhängig von Paket und Objekt
- (2012) SSIS Service Parameters (in Project Deployment Model)
PDI
- kettle.properties файл - по логике чем-то похоже на project.params, но намного проще в применении

Маппинг параметров на свойства объектов
SSIS
- возможен
PDI
- возможен, но намного проще


Продолжение следует: ===>>

pkarklinСуществует же специальный раздел форума для сравнения.
Да, вы правы, я не подумал. Это просто по просьбе в другой ветке. Давайте я уже допишу, а там перенесем.

Масштабируемость

Multythreading, параллельное выполнение
SSIS
- всё стартует одновременно и выполняется последовательно, если иное явно не указано
PDI
- в WorkFlow все шаги выполняются исключительно последовательно. Если от одного шага управление переходит к нескольким, то можно явно указать будут они одновременно или случайно последовательно выполняться
- в Dataflow все шаги стартуют одновременно и выполняются последовательно. последовательность старта не гарантирована

Множество экземпляров одного компонента во время выполнения
SSIS
- не возможно
PDI
- легко
- если в DataFlow данные от одного источника идут к нескольким покупателям (экземпляры в RunTime в т.ч.), то можно явно указать будут данные копироваться всем или расбрасываться по кругу (distribute - Round Robbin)

Партиционирование
SSIS
- в SSIS отсутствует (речь не о партиционирловании в базе данных, а в ETL)
PDI
- есть несколько вариантов:
а. полное копирование всем получателям
б. случайное расбрасывание по кругу
в. партиционирование сограсно Partition function. Например по остатку MODULO функции наложенной на целочисленное поле.

Clusters, Remote Exeсution
SSIS
- отсутствует
PDI
- на уровне кода ETL можно настроить что или целиком файл, или его отдельные шаги должны выполняться на кластере. При этом во время выполнения соответствующие потоки данных будут упакованы в HTTP пакеты, отправлены на кластер и после обработки ресультаты приходят обратно.
- затраты на настройку кластера, партиционирования по какому-то (в т.ч. строковому) полю, и указание того, что отдельные шаги должны отработать в кластере - ну не знаю, минут 15 наверное, может 30 (одноразово)

Масштабирование
SSIS
- только параллельная обработка независимых потоков данных на одном компьютере в одном многопоточном процессе
PDI
- совместное применение
а. возможности многих экземпляров (количество параметризируется в зависимости от окружения)
б. партиционирования
в. кластеров
дают практически неограниченные возможности масштабирования. А встроенная поддержка Big Data так и вообще

Если в целом, то у меня бывают попеременно проекты как на SSIS, так и на Pentaho Data Integration (PDI).
Если у меня есть выбор, то я выбираю PDI.


Всё, я закончил. Модераторы - помогите перенести все куда надо было бы сначала.

Модератор: Тема перенесена из форума "Microsoft SQL Server".

Winnipuh,

> 1. Так что получается: для PDI можно писать, скриптовать только на js, Java? Всяких там c# нет?
нет. Но через JavaScript и Java доступна полная объектная runtime модель

> 2. Ну и надо понимать никакого API для запуска из своего приложения нету
Если "своё приложение" написано на JAVA, то есть. А так коммандная строка с богатыми параметрами

> Download a 30-Day Trial for Free
Это Enterprise Edition. Community Edition бесплатен. Причем всех продуктов палитры. Вот к примеру ссылка на PDI: http://community.pentaho.com/projects/data-integration/]community.pentaho.com/projects/ data-integration/
А ты наверное в Business Analyst тыркнулся - это набор, у которого дополнительно присутствует Repository - вот он платный. Но все его features легко заменяемы бесплатными. И именно:
- шедулер
- версионирование
- права доступа к файлам

Yuri Abele,

я не возьмусь судить, как оно в России, но вот у немцев очень часто рабочие места под Windows, а серверы или поголовно или везьде где можно под Linux. Для PDI не страшно - разработкой занимаешся под Windows, а деплоишь на Linux.

Да, на счет версий - очень рекомендую начать с версии 5.3, не старше, а потом уже переходить на новые.
Дело в том, что разработчики поддавшись идиотской моде поуберали все цвета.
Т.к. еще в 5.3 все было так:



а стало так:


Мне лично новый layout не по душе

Кстати в нижней картинке справа идет запрос к вненшнему HTTP ресурсу - к Google за координатами.

Вот если OLAP продукты Microsoft и Pentaho сравнивать, тот тут всё сильно наоборот - большей каки, чем Mondrian (OLAP сервер от Pentaho) я не встречал. А Microsoft SSAS просто лучший, причем с большим отрывом.

a_voroninYuri AbeleМасштабирование
SSIS
- только параллельная обработка независимых потоков данных на одном компьютере в одном многопоточном процессе
PDI

Ни фига!! Не связанные друг с другом блоки
1) Вызывов других пакетов
2) Control Flow
3) Data Flow
вызываются параллельно и работают параллельно

Этим механизмом можно и косвенно партиционироваться.
Этут тему мне всегда на тренингах бывает трудно объяснить :-)
Речь о том, что PDI сам делает, а не то, как в SSIS это custom решить можно:

- в PDI я могу просто сказать сколько экземпляров запустить, причем количество экземпляров я могу параметризировать в зависимости от окружение (т.е. задать декларативно в config файле разное значение для Dev, Test, Stage, Prod).
В SSIS мне эти экземпляры явно создавать надо.

- в PDI партиционирование осуществляется автоматом на основе Partition Function. Количество партиций опять же параметризируется.
В SSIS мне придется явно высчитывать номер партиции и делить строки фильтром по различным получателям

- в PDI разорвать поток данных и сказать, что вот эти два шага должны бежать вон на том кластере - дело пары кликов.
В SSIS это просто никак. Только явно прерывать поток ==> останавливать выпонение пакета ==> давать комманду пакету на другой машине забрать данные из временного хранилища и положить обработанные в другое место ==> остановить выполнение на другом сервере ==> явно запустить другой пакет на изначальном сервере ==> прочитать из временного хранилища результаты обработки на другом сервере ==> продолжить обработку. Да это даже с RAW файлами такой геморой! Я этот текст писал раз в 10 дольше, чем настроить все на PDI, причем бежать все будет в оперативной памяти и в сети без сброса во временные хранилища.

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 оптимизация.
Но я пока этого не видел. Как увижи и поковыряюсь - отпишу сюда.