Как настроить доступ к данным в распределенном учебном задании (TF Job) для API обнаружения объектов на Azure

Question

Я некоторое время пытался настроить распределенное обучение для TensorFlow Object Detection API на Azure. Я немного запутался в том, как именно ввести мои данные в задание.

Раньше я довольно легко делал эту работу на gcloud с помощью AI-Platform. Все, что мне требовалось, это:

gcloud ai-platform jobs submit training $JOB_NAME \
    --runtime-version $VERSION \
    --job-dir=$JOB_DIR \
    --packages $OBJ_DET,$SLIM,$PYCOCOTOOLS \
    --module-name object_detection.model_main \
    --region us-central1 \
    --config $CONF/config.yaml \
    -- \
    --model_dir=$MODEL_DIR \
    --pipeline_config_path=$PIPELINE_PATH

Где config.yaml содержал конфигурацию кластера, а JOB_DIR, MODEL_DIR, PIPELINE_PATH все указывали на соответствующие места хранения ведра (gs: // *). Мои данные для обучения также хранились в корзине, и расположение было указано в моем pipeline.config.

Теперь, на Azure, похоже, нет прямого способа запустить распределенная обучающая работа. Я развернул кластер Kubernetes с ускорением на GPU с AKS, а затем установил драйверы NVIDIA. Я также развернул Kubeflow и закрепил API обнаружения объектов.

Мои данные в форме tfrecords находятся в контейнере хранилища BLOB-объектов Azure. Примеры / документация Kubeflow, которые я просматриваю ( TFJob , AzureEndtoEnd ), выделяет постоянные тома, что кажется отличным, но я не понимаю, как мой код работы / обучения будет получать доступ my tfrecords.

(Мне было интересно, могу ли я что-то сделать в части предварительной обработки в Azure End to End конвейере; там я мог бы написать несколько строк python код для загрузки данных с использованием библиотеки azure-storage-blob python. Это все еще предположение, я еще не пробовал это.)

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

• https://medium.com/@sozercan / tensorflow-object-detection-on- azure -part-2-using- kubernetes-to-run -formed-tensorflow-ced5b9a6184a

  Это казалось хорошим примером, но некоторые его части устарели. tf / k8s больше не существует и был перемещен в kubeflow; следовательно, диаграмма рулевого управления также недоступна.

• https://github.com/kubeflow/examples/tree/master/object_detection

  Это прямой пример из репозитория Kubeflow, но он тоже кажется устаревшим. Похоже, он полагается на kso nnet, производство которого прекращено.

Answer 1

Ладно, в итоге я понял это сам. Оказывается, вы можете определить persistent volume claim поверх storage class. Класс хранилища может быть указан как Azure File Share, что делает все намного удобнее.

s c .yaml:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: <NAME>
provisioner: kubernetes.io/azure-file
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict
parameters:
  storageAccount: <STORAGE_ACC_NAME>

pv c .yaml :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: <NAME>
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: <NAME>
  resources:
    requests:
      storage: 20Gi

Постоянный том может быть создан и востребован:

kubectl apply -f sc.yaml
kubectl apply -f pvc.yaml

После этого общий ресурс появится в указанной учетной записи хранения, и вы можете просто использовать Azure системы общего доступа к файлам для беспрепятственной загрузки в него данных (например, использование azcopy для перемещения данных с вашего локального компьютера или существующего общего ресурса / контейнера).