Многопользовательская интеграция Pentaho Data Integration

Question

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

У меня есть следующие таблицы, определенные в 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.

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

Answer 1

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

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

Answer 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.