Обичам да гледам аниме от дете и вероятно ще продължа да се наслаждавам на аниме до края на живота си. Въпреки това, докато разглеждам аниметата в моя списък TODO, става все по-трудно и по-трудно да намеря какво да гледам след това. Сигурен съм, че има много неоткрити скъпоценни камъни, които бих искал да гледам, но как да отида да ги открия?

Един ден прекарах около час в myanimelist.net в търсене на нещо за гледане. Гледайки колко време отнемаше за мен и вероятно за други, реших да създам система за препоръки за аниме, която да препоръча какво да гледаме следващо за възможно най-много потребители на myanimelist.net.

По това време се подготвях и за сертифицирането за професионално машинно обучение в Google Cloud, така че реших, че има смисъл да използвам възможно най-много различни GCP услуги за учебни цели. (Преминах сертифицирането BTW, благодаря ви, че попитахте :P).

Резултати

Можете да изпробвате системата за препоръки за аниме на тази връзка . Има препоръки за над 900 000 потребители на myanimelist.

Когато потребител влезе в уеб приложението, той ще бъде помолен да въведе своя myanimelist id

След като това стане, приложението ще покаже на потребителя 5 произволни анимета от 20-те най-добри анимета, които препоръчваме за този потребител.

Обходеният набор от данни, използван за този проект, може да бъде намерен на Kaggle тук. Наборът от данни съдържа:

  • аниме информация за 13 379 анимета
  • потребителска информация за 1 123 284 потребители на myanimelist
  • 214 271 взаимодействия между двойки аниме (препоръчани и сродни анимета)
  • 5 048 994 взаимодействия между потребителски двойки (приятелство)
  • 223 812 614 взаимодействия между потребители и анимета

Надявам се, че Kagglers, Data Scientists и феновете на анимето ще намерят набора от данни и ще създадат страхотна система за препоръки с него.

Пълният код за този проект може да бъде намерен в това Github repo.

Общ преглед на системната архитектура

Проектът се състои от 5 основни части:

  • Планировчик за обхождане: Задача, която при извикване ще извлече списък с URL адреси на аниме/профил от база данни и ще ги избута към опашка със съобщения. Планировчиците за обхождане са разгърнати като облачни функции, базата данни като база данни Postgres Cloud SQL и опашката за съобщения като Pub/Sub тема.
  • Работа: Задачи на Scrapy, които изтеглят URL адреси на съобщения от опашката със съобщения на планировчика и ги обхождат. Елементите с обходени данни се изпращат към опашка със съобщения за поглъщане на данни и заданията за обхождане също се свързват с базата данни на графика, за да я актуализират. Роботът е внедрен в Google Kubernetes Engine и опашката за приемане на данни е Pub/Sub тема.
  • Поглъщане на данни и ETL: Поточно задание на Apache Beam изтегля елементи с данни от опашката за приемане и ги изпраща към BigQuery в зона за кацане. Тръбопроводът на Apache Airflow се изпълнява за агрегиране, почистване и валидиране на обходените данни в добре структурирани набори от данни. Новите данни се записват в BigQuery и Storage. Заданието за поглъщане на лъч се внедрява като задание за поток от данни и конвейерът Apache Airflow ETL работи в среда на Cloud Composer.
  • Тръбопроводи за машинно обучение:Всеки канал обработва както стъпки за извличане, така и за класиране. За стъпката на извличане конвейерът започва с генериране на данни за влак/вал/тест за извличане, след това обучава модел за извличане и накрая изпълнява партиден извод за извличане и запазва резултатите. За стъпката на класиране конвейерът започва с генериране на данни за влак/вал/тест за класиране, след това тренира модел за класиране и накрая изпълнява партиден извод за класиране на извлечените резултати и запазва окончателните резултати. Тръбопроводите са Kubeflow тръбопроводи и работят на Google VertexAI тръбопроводи. Данните се извличат и записват както в BigQuery, така и в Storage.
  • Уеб приложение: Генерираните препоръки се въвеждат в база данни на Redis и малко уеб приложение на Flask извлича препоръките от Redis за всяка заявка за потребителска препоръка.

Номерираните стъпки в горната диаграма са:

  • 1: Cron задача на Cloud Scheduler задейства облачните функции на планировчика за обхождане
  • 2: Облачната функция за планиране на обхождане извлича URL адресите за планиране от базата данни Scheduler Cloud SQL.
  • 3: Облачната функция за планиране на обхождане натиска URL адресите за обхождане към опашката за график на PubSub.
  • 4: Работниците за обхождане, работещи на Google Kubernetes Engine, изтеглят URL адресите от опашката за график на PubSub.
  • 5: Служителите за обхождане обхождат URL адресите, актуализират базата данни на планировчика и изпращат обходените данни към опашката за приемане на данни PubSub.
  • 6: Заданието за приемане на Dataflow изтегля данните от опашката за приемане на данни.
  • 7: Заданието за приемане на Dataflow избутва данните към целевата зона на BigQuery.
  • 8: ETL тръбопроводът на Cloud Composer агрегира, слива, почиства и валидира данните от зоната за кацане.
  • 9: Конвейерът ETL на Cloud Composer записва почистените набори от данни в обработената зона на BigQuery.
  • 10: ML тръбопроводите на Vertex AI използват данните в обработената зона на BigQuery, за да обучават ML модели и да генерират пакетни препоръки.
  • 11: Пакетните препоръки се репликират в екземпляр на Cloud Memorystore Redis за достъп с ниска латентност.
  • 12: Уеб приложението осъществява достъп до екземпляра на Cloud Memorystore Redis, за да извлече препоръките за всеки потребител.
  • 13: Потребителят изпраща заявка до уеб приложението и знае кое аниме да гледа.

Благодарности

Бих искал да оценя MyAnimeList.net за страхотната платформа и JikanAPI за страхотния API за аниме, който предоставят.

Благодаря ви, че прочетохте. В следващите статии планирам да опиша подробно процеса на обхождане, използваните ETL тръбопроводи и ML тръбопроводи.

Приносът към репото е повече от добре дошъл.