Проблемы с производительностью Vertica при копировании файлов паркета из S3 - PullRequest
0 голосов
/ 24 октября 2019

У меня 66 паркетных файлов со сжатием GZIP, состоящих из 2 миллиардов записей в S3, я использую команду копирования Vertica для копирования данных из s3 в Vertica, как показано ниже.

COPY schema.table ( col1, col2, col3, col4, col5, col6 ) FROM 's3://test_path/*' PARQUET ABORT ON ERROR DIRECT NO COMMIT 

У нас есть 4 узла Vertica,Чтобы скопировать эти 2 миллиарда строк, требуется более 45 минут. В документации Vertica сказано, что загрузка файлов из S3 по умолчанию выполняется в многопоточном режиме на нескольких узлах. Наш DBA сказал мне, что для достижения максимальной производительности параллельно выполняется 66 запросов (1 запрос на файл), таким образом, каждый запрос будет выполняться на другом узле, а каждый запрос будет загружать свой файл.

Команда Vertica Copy вызывается программно из Java, я не хочу запускать команду копирования для файлов, это затрудняет поддержание транзакции, а также, файлы могут увеличиться до 1000+ во время пиковой загрузки.

Я хочу сократить время выполнения, используя только одну команду COPY, любые указатели и помощь будут действительно оценены.

Спасибо

1 Ответ

1 голос
/ 25 октября 2019

Попробуйте это:

COPY schema.table ( col1, col2, col3, col4, col5, col6 ) 
FROM 's3://test_path/*' ON ANY NODE PARQUET
ABORT ON ERROR DIRECT;

Я не имею ни малейшего представления, как ваш администратор баз данных понял, что вы должны запускать по одной команде на файл ... Команда, приведенная выше, будет включать каждый из 4 узлов вфаза разбора, обычно даже с несколькими параллельными парсерами на узел. И как только фаза синтаксического анализа будет завершена, данные будут сегментированы в соответствии со схемой сегментации проекций таблицы по узлам, каждый узел будет сортировать и кодировать свои собственные данные и, наконец, записывать их на диск - и будет выполнять фиксацию в конце. Просто запомните директиву ON ANY NODE после строки глобуса файла.

С несколькими 1000 вместо ваших 60 файлов вы можете в конечном итоге достичь точки, где производительность ухудшается (например, с данными в несколько терабайт)(в зависимости от размера ОЗУ ваших узлов) - и тогда вы можете разделить его на несколько команд, используя обычный метод «разделяй и властвуй». Просто попробуйте для начала ...

...