У меня есть требование обрабатывать плоские файлы, сгенерированные из нашей производственной системы oltp, с использованием pyspark (в Azure) и в конечном итоге записывать (после манипуляции) в хранилище данных Snowflake; коннектор pyspark в Snowflake поддерживает только API-интерфейс spark для данных.
Из-за размера этих плоских файлов, каждый из которых превышает 300 ГБ, мне пришлось сжать их. В настоящее время я сжимаю в gzip, но столкнулся с неизбежной проблемой искровой обработки однопоточного файла gzip.
Чтобы Spark распараллелил чтение, мне пришлось разделить файлы после их извлечения. Из-за того, что это текстовые файлы, мне пришлось разделить их на переводы строк - для этого я должен прочитать файл, заполнить буфер, а затем записать в файл заданного размера.
Необходимость считывания всего файла - сильно влияет на время, необходимое для доставки файлов в облачном хранилище (хранилище BLOB-объектов Azure).
По мере того, как в моей компании растет жажда данных - все больше и больше основных таблиц OLTP добавляются к миксу, и это продвигает время завершения все дальше и дальше. Принимая во внимание, что большая часть этого должна поступать в аналитику, которая должна быть доставлена к 9 утра каждый день - мне очень трудно обойти это.
Помня о том, что я не могу контролировать формат, в который попадают файлы - каков наилучший способ сжатия этих файлов таким образом, чтобы все не передавалось в один рабочий поток в Spark?
Я читал, что lz4, bz2 и snappy делятся на разделяемые - однако не нашли достаточной документации о том, как это сделать без использования контейнера, такого как tar - который опять-таки не поддерживает искру.
Суть проблемы заключается в отсутствии контроля над системой oltp, если бы она была под моим контролем - я бы просто получил ее для посадки паркетных файлов