У меня есть сценарий использования, в котором я передаю потоковые файлы (более 50 тыс. Столбцов), которые я хочу сжать для дальнейшего использования.
Я проверил, что после сжатия данных выполняется запрос к подмножествустолбцов и выполнение фильтров достаточно быстро, что свидетельствует о том, что паркет подходит для этой задачи.
Однако сжатие (spark.read.parquet -> df.coalesce (1) -> df.write.parquet) проблематичнодаже с небольшими данными.А именно, я получаю следующую ошибку Spark:
ОШИБКА SparkUncaughtExceptionHandler: необработанное исключение в потоке Thread [FileScanRDD-0,5, main] java.lang.OutOfMemoryError: прямая буферная память
Так как я хочу написать один паркет, я использую кластер с 1 исполнителем.
Я пробовал много вариантов памяти Spark и jvm из googling, но единственное, что, кажется, помогаетпросто используя узел с большей памятью и сохраняя настройки памяти по умолчанию.Однако для сжатия только 50 файлов паркета общим объемом 200 МБ уже требуется узел памяти объемом 600 ГБ и это занимает 2 часа.Я не смог сжать больше файлов за раз, так как я уже использую самый большой узел, к которому у меня есть доступ.Результаты довольно удивительны и заставили меня усомниться в пригодности паркета для этого варианта использования.
Кто-нибудь сумел сжать широкие файлы паркета с разумным количеством ресурсов или есть идеи по поводу проблем с памятью?
Я использую автономную версию 2.3.2 и хранилище BLOB-объектов Azure.