Ссылки на данные перечисляют все большие двоичные объекты в хранилище больших двоичных объектов Azure

#python #azure #azure-blob-storage #azure-databricks

#python #azure #azure-blob-storage #azure-databricks

Вопрос:

Я подключил учетную запись хранилища больших двоичных объектов к Databricks и могу нормально к ней обращаться, поэтому я знаю, что это работает.

Однако я хочу перечислить имена всех файлов по заданному пути .. в настоящее время я делаю это с:

 list = dbutils.fs.ls('dbfs:/mnt/myName/Path/To/Files/2019/03/01')
df = spark.createDataFrame(list).select('name')
  

Проблема, с которой я сталкиваюсь, заключается в том, что это исключительно медленно .. из-за того, что в этом месте находится около 160 000 больших двоичных объектов (проводник хранилища показывает это как ~ 1016106592 байта, что составляет 1 ГБ!)

Это, конечно, не может привести к удалению всех этих данных, все, что мне нужно, — это имя файла..

Является ли хранилище больших двоичных объектов моим бутылочным горлышком, или я могу (как-то) заставить Databricks выполнять команду параллельно или что-то в этом роде?

Спасибо.

Ответ №1:

Согласно моему опыту и исходя из моего понимания хранилища больших двоичных объектов Azure, все операции в SDK или других в хранилище больших двоичных объектов Azure будут переведены в вызов REST API. Таким образом, ваш dbutils.fs.ls вызов фактически вызывает связанный REST API List Blobs в контейнере больших двоичных объектов.

Поэтому я уверен, что на производительность вашего кода действительно влияет передача данных о размере XML тела ответа списка больших двоичных объектов в хранилище больших двоичных объектов для извлечения имен больших двоичных объектов в list переменную, даже если там около 160 000 больших двоичных объектов.

Между тем, все имена больших двоичных объектов будут заключены во множество фрагментов XML-ответа, и для каждого фрагмента существует MaxResults ограничение, и получение следующего фрагмента зависит от NextMarker значения предыдущего фрагмента. Вышеуказанная причина заключается в том, что перечисление больших двоичных объектов происходит медленно, и это не может быть параллелизмом.

Мое предложение для повышения эффективности загрузки списка больших двоичных объектов заключается в том, чтобы заранее кэшировать результат для больших двоичных объектов списка, например, для создания большого двоичного объекта для записи списка больших двоичных объектов построчно. Учитывая необходимость обновления в реальном времени, вы можете попробовать использовать функцию Azure с триггером больших двоичных объектов, чтобы добавить запись имени большого двоичного объекта в большой двоичный объект Append, когда произошло событие создания большого двоичного объекта.

Комментарии:

1. спасибо за хорошо аргументированный ответ, неплохая идея.. это придаст ему изюминку!

2. @m1nkeh Если это вам поможет, не могли бы вы отметить это? Спасибо.

3. в конце концов, я действительно использовал python blob storage SDK .. это было достаточно быстро для моего варианта использования: D