Сбой параллельного задания на этапе поиска при достижении 4 ГБ

Существует параллельное задание, которое состоит из одного набора данных, одного последовательного файла и этапа поиска, который объединяет их.

Последовательный файл содержит 15 811 строк. Это импортируется просто отлично (и я вижу это в журнале).

Проблема со стадией поиска - она ​​выдает следующую ошибку:

LOOKUP,0: Could not map table file "/var/opt/ascential/adm/DataSet1/lookuptable.20140330.spzjazc (size 4191844864 bytes)": Not enough space
Error finalizing / saving table /tmp/dynLUT18950c3139ce

Как я читал на сайте IBM и других форумах, возможное решение может заключаться в увеличении количества узлов. Поэтому я изменил свой файл APT с 1 узла на 6 узлов:

{
        node "node1"
        {
                fastname "xxx"
                pools ""
                resource disk "/var/opt/ascential/adm/DataSet1" {pools ""}
                resource scratchdisk "/var/opt/ascential/adm/Scratch1" {pools ""}
        }
        node "node2"
        {
                fastname "xxx"
                pools ""
                resource disk "/var/opt/ascential/adm/DataSet2" {pools ""}
                resource scratchdisk "/var/opt/ascential/adm/Scratch2" {pools ""}
        }
        node "node3"
        {
                fastname "xxx"
                pools ""
                resource disk "/var/opt/ascential/adm/DataSet3" {pools ""}
                resource scratchdisk "/var/opt/ascential/adm/Scratch3" {pools ""}
        }
        node "node4"
        {
                fastname "xxx"
                pools ""
                resource disk "/var/opt/ascential/adm/DataSet4" {pools ""}
                resource scratchdisk "/var/opt/ascential/adm/Scratch4" {pools ""}
        }
        node "node5"
        {
                fastname "xxx"
                pools ""
                resource disk "/var/opt/ascential/adm/DataSet5" {pools ""}
                resource scratchdisk "/var/opt/ascential/adm/Scratch5" {pools ""}
        }
        node "node6"
        {
                fastname "xxx"
                pools ""
                resource disk "/var/opt/ascential/adm/DataSet6" {pools ""}
                resource scratchdisk "/var/opt/ascential/adm/Scratch6" {pools ""}
        }
}

Тем не менее, я получаю ту же ошибку и заметил, что задание записывается только в первую папку DataSet (есть файл /var/opt/ascential/adm/DataSet1/lookuptable.20140330.spzjazc, размер которого увеличивается до достижения ~4 ГБ, то работа завершается сбоем и файл удаляется).

  1. Я предполагаю, что задание на самом деле не выполняется на нескольких узлах, поскольку имеется только 1 файл. Это правильно? Как заставить его работать на всех 6 узлах, чтобы преодолеть ограничение в 4 ГБ?

  2. Есть ли другие обходные пути для этого?

Источник

3 ответа

Этап поиска загружает все данные в память. Так что это совершенно нормально, что у вас здесь. Может быть, вы можете изменить его, чтобы объединить этап или присоединиться к этапу.

Источник

Случайное это правильно.

Если вы используете Datastage PX для моделирования левого соединения, а объем данных таблицы справа является большим или непредсказуемым, то вам нужно использовать этап соединения вместо этапа поиска.

Стадия слияния - это специализированное / оптимизированное соединение, которое большинству людей не нужно и не следует использовать.

Источник

Этап поиска должен использоваться для обработки небольшого количества данных: Join vs Lookup

Последовательный файл читается в последовательном режиме (используя только один узел). Не могли бы вы добавить задание, которое преобразует последовательный файл в файл набора данных? Файлы набора данных используют параллельный режим (много узлов).

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

Источник
Другие вопросы по тегам