Самый быстрый способ скопировать огромный набор данных на сервер в SAS

Пара мыслей.

Во-первых, предполагая, что это набор данных SAS, а не база данных SQL или что-то еще, options compress=binary; — хорошая идея, предполагающая, что это в основном числовое значение (и options compress=character;, если нет). Любой из них в большинстве случаев значительно уменьшит физический размер набора данных.

Во-вторых, 300 МБ — это не так уж и много. Моя сеть написала бы это менее чем за минуту. Условия вашей сети могут повлиять на ваш выбор; если единственная медленная точка, например, просто копирует данные через нее, то вам нужно выяснить, как уменьшить это за счет всего, что вы делаете.

Предполагая, что вы больше ничего не меняете, я бы рекомендовал писать have1 непосредственно в сеть как have, а затем добавлять к нему have2. IE, какой бы шаг ни создавал have1, пусть он напрямую записывает в сеть. Это включает sort шагов, примечание: поэтому, если вы создаете его, отсортируйте его, создайте локально и отсортируйте с помощью out= сетевой библиотеки. Это уменьшает общий объем выполняемой записи (поскольку вы не записываете бесполезную копию have1 на локальный диск). Это помогает, если локальная запись является релевантной стоимостью для вашего общего процесса, но не поможет, если это почти полностью перегружена сеть.

Копирование файлов с копией ОС почти всегда превосходит любой другой метод копирования, поэтому, если перегрузка сети является единственным фактором, который вас волнует, вы можете сделать это локально (в РАБОТЕ или в локальном, но постоянном каталоге, например C:\temp\ или аналогично), а затем последним шагом вашего процесса будет выполнение copy c:\temp\have.sas7bdat \\networklocation\whereitgoes\. Это обычно превосходит методы SAS для того же, поскольку может использовать преимущества эффективных методов.

PROC COPY — еще один способ обойти перегрузку сети; это, вероятно, быстрее, чем PROC APPEND (если локальная запись незначительна, как это было бы для меня для данных ‹1 ГБ), и имеет то преимущество, что это немного безопаснее, если что-то произойдет во время транспортировки. (Добавление также должно быть в порядке, но с COPY вы точно знаете, что ничего не изменилось по сравнению со вчерашним файлом.)

Наконец, вы можете захотеть найти какой-нибудь способ разрешить простое обновление целевого файла. В большинстве случаев это не так сложно сделать. Одним из примеров может быть сохранение копии вчерашнего файла, выполнение операции PROC COMPARE с сегодняшним файлом, а затем включение в файл обновления каждой записи, которая была изменена (независимо от характера изменения). Затем удалите все совпадающие старые записи из целевого файла и добавьте новые записи. Это очень быстро по сравнению с общим количеством записей, отправляемых по сети, поэтому в целом экономит много времени, если основной проблемой является перегрузка сети (но требуется больше процессорного времени для выполнения PROC COMPARE).

Вы можете использовать PROC APPEND для эффективного создания нового набора данных, а не просто добавления к существующему, поэтому вы можете использовать это, чтобы в основном объединить шаги 3 и 4 в это:

/* To fulfill requirement 4, delete existing Targetlib.HAVE */
PROC DELETE LIBRARY="Targetlib" DATA="HAVE"; 
RUN;

/* Targetlib.HAVE does not yet exist, the first APPEND will create it */
PROC APPEND BASE="Targetlib.HAVE" DATA="work.HAVE1";
RUN;

PROC APPEND BASE="Targetlib.HAVE" DATA="work.HAVE2";
RUN;

Это должно сэкономить по крайней мере некоторое время, но это все равно не решит всех ваших проблем... У меня есть несколько дополнительных вопросов, которые я задал в комментариях к вопросу, и я изменю этот ответ настолько, насколько смогу, основываясь на них.

Обновление 1

Вот способ выполнить левое соединение и конкатенацию за один шаг и сразу же записать результаты в targetlib. Я не могу гарантировать, что это будет быстрее, но стоит попробовать. Я использовал key и val в качестве имен полей, замените на свое усмотрение.

PROC SQL _METHOD;
    CREATE TABLE targetlib.HAVE
    AS
    SELECT
        a.key ,
        CASE WHEN MISSING (a.val) THEN b.val ELSE a.val END AS val  
    FROM
        Sourcelib.RAW1 AS a
    LEFT JOIN
        IMP AS b
        ON
            a.key = b.key
    UNION
    SELECT
        c.*
    FROM
        Sourcelib.RAW2 AS c
    ORDER BY
        key
;
QUIT;
RUN;

_METHOD — это малодокументированная функция SAS, которая распечатывает план запроса, см. эту ссылка. Это может дать вам больше информации. Кроме того, я предполагаю, что IMP уже был импортирован из Excel и находится в WORK. Поэкспериментируйте, чтобы увидеть, будет ли быстрее импортировать его в targetlib и заменить IMP as b на targetlib.IMP as b.

Поскольку вы работаете в Windows, поэкспериментируйте с опцией данных SGIO=YES после имен наборов данных: например. Sourcelib.RAW1 AS a становится Sourcelib.RAW1 (SGIO=YES) AS a. Дополнительные сведения о Windows SGIO и SAS см. по этой ссылке. и старый, но более полный.

Подход, который может быть более эффективным, состоит в том, чтобы избегать соединения и вместо этого использовать хэш-объект: хорошая документация по хэш-объекту можно найти здесь и хороший совет здесь. Неясно, будет ли это быстрее - imp имеет 6 млн записей, но при 50 байтах на запись это около 300 МБ, что умещается в вашей оперативной памяти. Производительность хеш-таблицы с таким количеством записей во многом будет зависеть от хеш-алгоритма SAS. Во всяком случае, вот код, использующий хеш-объект. В нем мы предполагаем, что в наборе данных IMP поле val было переименовано в val2.

DATA targetlib.HAVE (DROP = rc val2);
    LENGTH val2 8. ;

    IF (_N_ = 1) THEN DO;
        DECLARE HASH h (DATASET: "IMP") ;
        h.DEFINEKEY ('key');
        h.DEFINEDATA ('val2');
        h.DEFINEDONE ();
    END;

    SET 
        sourcelib.RAW1
        sourcelib.RAW2
    ;

    IF MISSING (val) THEN DO;
        rc = h.find();
        IF (rc = 0) THEN DO;
            val = val2;
        END;
    END;
RUN;
PROC SORT DATA = targetlib.HAVE ; BY KEY ; RUN ;

Попробуйте и посмотрите, будет ли это быстрее. Еще раз поэкспериментируйте с расположением IMP, используя SGIO и т. д. PROC SORT в конце может дорого обойтись; если единственная причина, по которой вы раньше сортировали, была из-за присоединения, то пропустите ее.

В общем, ваш подход к SAS должен заключаться в том, чтобы выполнять как можно меньше операций ввода-вывода и находить способы объединения нескольких действий в одну операцию записи из PROC или DATA шагов.