KS
Arrow это нормальный вариант для подобного сценария?
Size: a a a
2021 April 15
AZ
Arrow это нормальный вариант, но это не формат файла, а представление в памяти, файлы будут в parquet скорее всего
AZ
Ну декодер предполагает строчный формат, не хочу за отвечать за Алексея, но не всем такой подходит
AZ
Но я все равно рекомендую присмотреться к базам данных, они классные
ИК
Вообще, можно придумать, чтобы отрезать футер паркета, дописывать row group, снова записывать немного модифицированный футер. Давно видел такую идею, никогда не видел реализацию, даже попыток таких не знаю
KS
А как насчёт записи в кафку?
AZ
у вас какая-то архитектурная полиция требует модную технологию?)
KS
Нет конечно, просто подумал, что много маленьких файлов это по сути сообщения в очереди.
AZ
ну вы практически готовый архитектор)
KS
Запись из датафрейма в sqs в спарке не параллельна, поэтому тут всё равно боттлнек.
AZ
как мало у вас данных что вы готовы в SQS их писать?
KS
Их бывает много, до 7 млн записей в одном батче.
KS
То есть получаем паркет файлы, читаем в датафрейм, разбиваем на батчи равной величины, пишем в персистенс (S3, SQS, ElastiCache).
KS
Клиенты запускают кучу контейнеров со своим Go клиентом и читают параллельно из персистенса.
R
Тут советовали посмотреть сторону бд - это вам хорошо же должно подойти, не?
R
Например в redshift заливать пакеты, он, вроде бы, умеет их сам забирать с s3.
KS
Посмотрю в RDS, спасибо.
R
Посмотрите ещё в сторону redshift spectrum.