Pentaho Data Integration Многостороннее объединение данных

Я хочу использовать шаг Multiway Merge Join в Pentaho? К сожалению, документации не хватает, и она не делает того, что я интуитивно предполагал.

У меня есть следующие таблицы, определенные в Oracle:

JOE1:
A   B   C
1   NY  3
2   NJ  1
3   NJ  3
4   CT  7

JOE2:
B   D
CT  Connecticut
NJ  New Jersey
NY  New York

JOE3:
C   E
1   one
3   three
7   seven

Вот метаданные из моего шага Multiway Merge Join в моем .ktr:

Step name:  Multiway Merge Join

Input Table1:  JOE1    Join Keys: B,C
Input Table2:  JOE2    Join Keys: B
Input Table3:  JOE3    Join Keys: C
Join Type:  INNER

Я ожидал, что мой .ktr выдаст что-то вроде этого:

A   B   C   B_1 D           C_1 E
1   NY  3   NY  New York    3   three
2   NJ  1   NJ  New Jersey  1   one
3   NJ  3   NJ  New Jersey  3   three
4   CT  7   CT  Connecticut 7   seven

Но вместо этого я получаю следующую ошибку:

**2018/10/12 14:44:25 - Multiway Merge Join.0 - Unexpected conversion error while converting value [B String(2)] to an Integer
2018/10/12 14:44:25 - Multiway Merge Join.0 - 
2018/10/12 14:44:25 - Multiway Merge Join.0 - B String(2) : couldn't convert String to Integer
2018/10/12 14:44:25 - Multiway Merge Join.0 - 
2018/10/12 14:44:25 - Multiway Merge Join.0 - B String(2) : couldn't convert String to number : non-numeric character found at position 1 for value [CT]**

Это признак того, что он не присоединяется к полю, которое я определил для присоединения в .ktr.

К сожалению, брандмауэр моей компании не позволяет мне отправлять ссылки на любые файлы или изображения. Я надеюсь, что предоставил достаточно информации, чтобы кто-то посоветовал мне сделать что-то не так или даже мои поведенческие ожидания верны.


person Joe Melillo    schedule 12.10.2018    source источник


Ответы (2)


Соединение с несколькими слиянием не похоже на соединение SQL. Это слияние, похожее на сортированное объединение SQL. Он берет два потока (Joe1 и Joe2) и помещает записи один за другим, занимая самую низкую запись. В частности, метаданные потока (имя столбца, тип и порядок) должны быть одинаковыми, о чем PDI должен был вас предупредить (если вы не нажали кнопку Больше не сообщать мне ранее).

Вы можете использовать Join row (cartesian product). Не волнуйтесь, это не декартово произведение, потому что вы можете указать это JOE1.B = JOE2.B (и многие другие). PDI запомнит, как вы сортировали входящие потоки раньше (если вы не нажали кнопку «Больше не сообщать мне»). Конечно, вам нужно сделать это дважды: один раз, чтобы соединить Joe1 с Joe2, и один раз, чтобы присоединиться к результирующему потоку к Joe3.

Однако в вашем случае вы не после присоединений, а после поиска. Для каждого Joe1.B вы ищите ровно один Joe2.B, а для каждого Joe1.C вы ищете ровно одного Joe3.C. Точно так же, как на прикрепленном изображении, на котором открыт первый поиск, так что вы можете видеть параметры. [Не забудьте указать тип возвращаемого столбца!]

Обратите внимание, что вы всегда можете поместить все это в SQL: SELECT * FROM joe1 JOIN joe2 ON joe2.B=joe1.B JOIN joe3 ON joe3.C=joe1.C. Но это будет труднее поддерживать, и если запрос сложный (много соединений и много связей между таблицами), он может быть медленнее, чем PDI.

введите описание изображения здесь

person AlainD    schedule 15.10.2018
comment
Большое спасибо за это. Я ПОЧТИ разобрался с этим самостоятельно, так что спасибо за подтверждение и за то, что помогли мне понять остальную часть моего понимания !! - person Joe Melillo; 16.10.2018
comment
Тогда, пожалуйста, подтвердите ответ. - person AlainD; 16.10.2018

Казалось бы, соединение должно выполняться в одном и том же поле (ах) для всех входных потоков. Он не обязательно должен иметь одно и то же имя (имена) полей, но концептуально должен иметь одинаковое содержимое данных.

Спасибо AlainD за проверку и подробное объяснение !!

person Joe Melillo    schedule 17.10.2018