Я пытаюсь перенести функцию AWS Lambda
, написанную на Python
, в CF,
На выходе получается> 2 ГБ, но немного меньше 3 ГБ, поэтому он подходит для Lambda
, просто.
Что ж, это кажется невозможным или более сложным для GCP
:
/tmp
- ограничен 2048 МБ на момент написания - поэтому Python Client lib upload_from_file
(или _filename
) не может использоватьсяboto
, библиотеке, изначально разработанной для AWS S3
, и довольно устаревшей, поскольку boto3
уже давно отсутствует. Нет подлинного метода GCP
для потоковой записи или чтенияcreateWriteStream()
- хорошая статья здесь, кстати, - но нет эквивалентного однострочника в PythonGCS
был локальной файловой системой. Это не ограничивается Cloud Functions
и отсутствующей функцией клиентской библиотеки Python, но более остро стоит в CF из-за ограничений ресурсов. Кстати, я был частью обсуждение, чтобы добавить записываемую функцию IOBase, но это не имело успеха.DataFlow
для поставленной задачи не может быть и речи.На мой взгляд, потоковое (или потоковое) чтение / запись из облачного хранилища должно быть даже включено в стандартную библиотеку Python.
Как рекомендовалось тогда, можно по-прежнему использовать GCSFS, который за кулисами фиксирует загрузку фрагментами для вас, пока вы записываете материал в FileObj.
Эта же команда написала s3fs
. Я не знаю, что касается Azure.
AFAIC, я буду придерживаться AWS Lambda
, так как вывод может уместиться в памяти - пока что - но многостраничная загрузка - это способ поддержать любой размер вывода с минимумом памяти.
Мысли или альтернативы?
К сожалению, для этого требуется, чтобы обработчик файлов был открыт в режиме только для чтения, а не в смешанном (чтение / запись). Другими словами, файл уже должен существовать целиком. Цель состоит в том, чтобы прочитать (записать GCS / S3) как вашу запись в обработчик в памяти.
Я запутался с загрузкой multipart
и resumable
. Последнее - то, что вам нужно для «потоковой передачи» - на самом деле это больше похоже на загрузку фрагментов буферизованного потока.
Загрузка Multipart
предназначена для одновременной загрузки данных и пользовательских метаданных в одном вызове API.
Хотя мне очень нравится GCSFS - Мартин, его основной участник очень отзывчивый - я недавно нашел альтернатива, который использует библиотеку google-resumable-media
.
GCSFS
построен на основном http API, тогда как решение Seth использует низкоуровневую библиотеку, поддерживаемую Google, более синхронизированную с изменениями API и включающую экспоненциальное резервное копирование. Последнее действительно необходимо для большого / длинного потока, так как соединение может обрываться даже внутри GCP
- мы столкнулись с проблемой с GCF
.
В заключение, я по-прежнему считаю, что Облачная библиотека Google - подходящее место для добавления потоковой функциональности с базовыми write
и read
. У него есть основной код уже.
Если вас тоже интересует эта функция в основной библиотеке, отметьте проблему здесь - предполагая, что на ней основан приоритет.
smart_open теперь поддерживает GCS, а также поддерживает распаковку на лету.
import lzma
from smart_open import open, register_compressor
def _handle_xz(file_obj, mode):
return lzma.LZMAFile(filename=file_obj, mode=mode, format=lzma.FORMAT_XZ)
register_compressor('.xz', _handle_xz)
# stream from GCS
with open('gs://my_bucket/my_file.txt.xz') as fin:
for line in fin:
print(line)
# stream content *into* GCS (write mode):
with open('gs://my_bucket/my_file.txt.xz', 'wb') as fout:
fout.write(b'hello world')
upload_from_file использует объект, похожий на файл, так что, может быть, вы можете использовать генератор для выполнения нужной работы?