Обзор

В моей предыдущей статье я говорил о создании Album2Vec, системы встраивания, которая позволяет пользователям визуализировать музыкальные рекомендации, соотнося расстояние со сходством.

Напомним, что преимущество такой визуализации рекомендаций заключается в том, что можно перемещаться по жанрам. Например, переходя от AstroWorld к Alfredo,мы встретимКендрика Ламара и Playboi Cartiальбомы — замечательный мост между двумя поджанрами рэпа.

Хотя алгоритм выполнил свою задачу, и я был очень доволен результатами, я знал, что мне нужно построить правильную инфраструктуру, которая позволит масштабировать идею. На момент моего последнего поста музыкальная карта могла поддерживать только 500 альбомов — это далеко от моей первоначальной цели — создать вектор для каждого альбома на Spotify.

Короче говоря: как мне масштабировать эту Музыкальную карту?

Еще немного технического контекста

Это может быть резюме из моей предыдущей статьи, но, тем не менее, это важно. Чтобы получить реальные функции, используемые в музыкальной карте, я сначала использовал API Spotify и Cyanite. Я использовал около 4 функций от Spotify и 128 функций от Cyanite. Естественно, эта задача была бы утомительной для любого ноутбука, поэтому мне нужно было найти способ не только масштабировать эту операцию, но и автоматизировать ее на несколько месяцев вперед (чтобы в конечном итоге я смог перейти ко всему каталогу Spotify). Кроме того, из-за большого количества вызовов API к Spotify я в конечном итоге оказался ограничен по скорости и не смог найти способ обойти это без значительного увеличения времени между вызовами. В результате я перестал использовать Spotify API и сосредоточился исключительно на Cyanite.

Масштабирование — S3

У AWS (Amazon Web Services) есть очень полезный инструмент под названием S3. По сути, S3 Bucket — это система хранения, размещенная на AWS. Вы можете взаимодействовать с этими сегментами, загружая и загружая в них информацию с помощью библиотек в вашем скрипте Python. В моем случае я использовал Boto3 для загрузки и скачивания информации из корзины S3.

Теперь сложнее было организовать мою корзину S3 таким образом, чтобы было очень легко загружать и выгружать информацию. Ниже представлена ​​фотография общей конструкции. Я подробно расскажу, что представляет собой каждый CSV и папка.

  • Feature_storage.csv — это огромная таблица, представляющая характеристики цианита каждого альбома. Итак, одна строка в альбоме.
  • Final_database.csv — это список альбомов, из которых мы будем собирать объекты для Feature_storage.csv.
  • Genre_storage.csv — это огромная таблица, представляющая жанр каждого альбома.

Чтобы обеспечить еще большую масштабируемость, большая таблица альбомов (Final_database.csv) была разделена на несколько меньших таблиц, и к этим меньшим таблицам были запрошены их функции. Итак, Recovery/ — это папка, содержащая множество небольших таблиц, содержащих характеристики конкретных альбомов. Аналогично the_csvs/ — это просто папка разделенных альбомов (без функций). Обратите внимание: это означает, что сумма всех строк таблиц в файле восстановления/ будет равна общему количеству строк в файле Feature_storage.csv. Ниже приведен рисунок, чтобы лучше понять, что происходит.

Еще раз обратите внимание: более крупный файл Final_database.csv разделен на файлы csv, которые хранятся в папке the_csvs/. Затем они используются для создания таблиц в папке восстановления/. В конечном итоге файлы в папке /recovery объединяются в наши Feature_storage.csv и Genre_storage.csv.

Подобная организация файловой структуры позволила мне создать систему с высокой степенью восстановления без слишком большого количества вызовов API к сервису AWS. Таким образом, мы можем сохранять данные каждые ~1000 строк, загружая эти строки как отдельную таблицу. Таким образом, мы используем вызов API только каждые 1000 строк. Альтернативой может быть загрузка каждой строки в корзину S3, что сразу же потребует в 1000 раз больше вызовов API. С другой стороны, если бы я сохранял строки только после того, как будут пройдены все альбомы, тогда потенциальный сбой программы потребовал бы полного перезапуска итерации, поскольку ничего не было бы сохранено. Таким образом, разделение данных также помогло здесь.

Автоматизация — EC2

Еще один чрезвычайно полезный подход — экземпляры AWS EC2. По сути, это виртуальные машины — эмуляция компьютера, позволяющая запускать программы асинхронно и с использованием большего объема памяти.

При этом экземпляр EC2 использовался для размещения сценария сбора функций. Это означало, что мне не нужно было держать свой ноутбук открытым, подключенным к Wi-Fi или заряженным, чтобы мой скрипт мог продолжать поиск функций различных альбомов. Кроме того, благодаря более высоким характеристикам EC2, чем у моего настоящего ноутбука, я смог выполнить очистку функций намного быстрее, чем если бы я запускал программу локально.

Кроме того, экземпляр EC2 использовался для получения исходного списка альбомов (который был выполнен путем поиска в ширину по различным исполнителям).

Масштабирование в будущем

Конечная цель — иметь возможность постоянно добавлять новые альбомы в нашу корзину S3, генерировать их характеристики, а затем проецировать их на музыкальную карту. В идеале нам хотелось бы добавлять новые альбомы каждую неделю — это можно сделать с помощью Airflow. С помощью Airflow я смогу запланировать свой сценарий (который собирает альбомы и их функции) раз в неделю, в дальнейшем добавляя его в базу данных и, кроме того, на карту.

Поток будет выглядеть примерно так:

  1. Запускайте сборщик альбомов раз в неделю, чтобы добавлять новые альбомы в базу данных. Делайте это с помощью Airflow.
  2. Запустите сборщик функций в конце этой недели — запланируйте использование Airflow, размещенного на EC2.
  3. Отобразите новую карту.
  4. Повторить.