Спасибо! Да, для Spark 3 реализация планируется. Уже ведется разработка, добавили поддержку каталогов. Основные сложности в том, что изменилось API Datasource v2.
Для тестирования использовался следующий стенд в Я.облаке:
Spark:
10 серверов x 24 CPU, 144GB RAM, 500 GB HDD
Greenplum:
10 серверов x 24 CPU, 96GB RAM, 500 GB SSD - 8 сегментов на каждый
1 сервер 4 CPU , 16GB RAM, 50GB HDD - мастер
На виртуалках с GP установлен MTU 9000 + включен режим SuperFlow Я.облака (он позволяет увеличить лимит на количество TCP и UDP соединений выше 50к).
Пробовали различные настройки разбиения на партиции (по segment_id, по целочисленным ренджам, хеш-функциям).
Основная проблема прокачки большой таблицы в размере распакованных данных из GP, которые попадают в 1 партицию спарка и вызывают OOM.
Особенно это заметно в Java 8, так как там UTF-16 строчки и нет оптимизации из Java 9 (https://openjdk.java.net/jeps/254), плюс при больших размерах хипа еще и увеличивается память, занимаемая указателем (64-битный указатель при размере больше 32Gb).
Тут сложно предложить универсальный рецепт, нужно знать свои данные и выбрать метод партиционирования, который отвечает конкретной задаче.
Спасибо! Да, для Spark 3 реализация планируется. Уже ведется разработка, добавили поддержку каталогов. Основные сложности в том, что изменилось API Datasource v2.
Для тестирования использовался следующий стенд в Я.облаке:
Spark:
10 серверов x 24 CPU, 144GB RAM, 500 GB HDD
Greenplum:
10 серверов x 24 CPU, 96GB RAM, 500 GB SSD - 8 сегментов на каждый
1 сервер 4 CPU , 16GB RAM, 50GB HDD - мастер
На виртуалках с GP установлен MTU 9000 + включен режим SuperFlow Я.облака (он позволяет увеличить лимит на количество TCP и UDP соединений выше 50к).
Были сгенерированы тестовые данные TPC-DS(http://www.tpc.org/tpcds/) размером 2.5 ТБ с помощью данной утилиты(https://github.com/RunningJon/TPC-DS).
Тестировали прокачку таблицы из GP в HDFS.
Пробовали различные настройки разбиения на партиции (по segment_id, по целочисленным ренджам, хеш-функциям).
Основная проблема прокачки большой таблицы в размере распакованных данных из GP, которые попадают в 1 партицию спарка и вызывают OOM.
Особенно это заметно в Java 8, так как там UTF-16 строчки и нет оптимизации из Java 9 (https://openjdk.java.net/jeps/254), плюс при больших размерах хипа еще и увеличивается память, занимаемая указателем (64-битный указатель при размере больше 32Gb).
Тут сложно предложить универсальный рецепт, нужно знать свои данные и выбрать метод партиционирования, который отвечает конкретной задаче.