Верное замечаение.
Вообще правильнее решить задачу было бы с помощью tf.metrix.accuarcy, но в версии 1.4 статистику нельзя сбрасывать между эпохами, что не очень удобно.
Все верно. Но нету удобной функции, позволяющей удобно преобразовать именованные категории в one_hot. А значит функция преобразующая считвающая категорию из файла и представляющая ее в виде числа все равно нужна.
До перехода на Mesos примерно так и было. Но нужно самим разрабатывать и реализовывать учет свободных ресурсов, отслеживание статусов задач (которые кроме как запуститься и завершиться могут еще упасть и потеряться). Еще сложнее все становится, когда возникает задача честного распеределения ресурсов между разными очередями, или изоляции запускаемых задач. Mesos что-то из этого реализует, для части предоставляет удобный API.
Из изменений которые мы заметили, это введение обязательных параметров при запуске самого Mesos.
В частности это приводит к непонятому сообщению об ошибке при запуске mesos-local https://issues.apache.org/jira/browse/MESOS-5613
Которое чинится путем задания переменной окружения MESOS_WORK_DIR.
Если запустить удалось, то дальше примеры должны работать.
Я честно говоря не очень понял что надо сравнить с «Yarn + Airflow».
Можно сравнивать Mesos с Yarn, тут выбор сделан в пользу Mesos, потому что у него есть родной Python интерфейс и модель работы очень хорошо «мапится» на наши задачи.
Какую-то часть нашей системы можно сравнить с Airflow, но когда он стал публичным у нас уже был свой :)
Про планировщик ничего интересного рассказать не могу. Там никакого Rocket-Science пока нет.
Судя по всему мы решаем не совсем ту задачу, что у вас. Поэтому контейнеры мы не используем, все задачи работают в одной среде. И Service Discovery нам пока не нужен, вся конфигурация задана статически.
За ссылку спасибо.
Но в Ubuntu-Trusty из коробки не загружаются Python модули (похоже они устанавливаются в неправильное место).
Но это я понял только сейчас, а раньше думал что Python-модули просто не включены.
Верное замечаение.
Вообще правильнее решить задачу было бы с помощью
tf.metrix.accuarcy, но в версии 1.4 статистику нельзя сбрасывать между эпохами, что не очень удобно.Или сделать датасет из
До перехода на Mesos примерно так и было. Но нужно самим разрабатывать и реализовывать учет свободных ресурсов, отслеживание статусов задач (которые кроме как запуститься и завершиться могут еще упасть и потеряться). Еще сложнее все становится, когда возникает задача честного распеределения ресурсов между разными очередями, или изоляции запускаемых задач. Mesos что-то из этого реализует, для части предоставляет удобный API.
В частности это приводит к непонятому сообщению об ошибке при запуске mesos-local https://issues.apache.org/jira/browse/MESOS-5613
Которое чинится путем задания переменной окружения MESOS_WORK_DIR.
Если запустить удалось, то дальше примеры должны работать.
Можно и так сказать.
Я в каком-то виде ниже ответил.
Docker Swarm и Cubernetes это скорее аналоги Marathon, а мы опять же решали другую задачу.
Я честно говоря не очень понял что надо сравнить с «Yarn + Airflow».
Можно сравнивать Mesos с Yarn, тут выбор сделан в пользу Mesos, потому что у него есть родной Python интерфейс и модель работы очень хорошо «мапится» на наши задачи.
Какую-то часть нашей системы можно сравнить с Airflow, но когда он стал публичным у нас уже был свой :)
Про планировщик ничего интересного рассказать не могу. Там никакого Rocket-Science пока нет.
Но в Ubuntu-Trusty из коробки не загружаются Python модули (похоже они устанавливаются в неправильное место).
Но это я понял только сейчас, а раньше думал что Python-модули просто не включены.