Параллельное задание завершается сбоем на этапе поиска при достижении 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. Есть ли другие обходные пути для этого?


parallel-processing datastage
person Razvan    schedule 30.03.2014    source источник
comment
Хотя мне не удалось преодолеть ограничение в 4 ГБ, мне удалось решить проблему, изменив размер одного из входных столбцов с VARCHAR(762) на VARCHAR(20). Это, по-видимому, оказало большое влияние на размер файлов набора данных и продолжительность задания (продолжительность задания уменьшилась с 15 минут до 2 минут). Кроме того, кажется, что использование этапа «Join» вместо «Lookup» также может помочь (я протестировал его на меньшем объеме данных, и он работал нормально). Подробнее: tinyurl.com/omzm8ux   -  person Razvan    schedule 30.03.2014

Ответы (3)


arrow_upward
1
arrow_downward

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

person Random    schedule 31.03.2014

arrow_upward
0
arrow_downward

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

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

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

person the_rj    schedule 20.07.2014

arrow_upward
0
arrow_downward

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

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

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

person Angel Doza    schedule 08.09.2016