search

zmactep / ig-pipeline

2 stars 0 forks source link

Pipeline #21

Closed zmactep closed 10 years ago

zmactep commented 10 years ago

Возможность накручивать на данные серию обработчиков (аналог pipe в Bash)

zmactep commented 10 years ago

Вдохновляться dnanexus.com

Feodorov commented 10 years ago

Мысли вслух про реализацию, прокомментируй, пожалуйста. Мета-Актер - унифицированные команды. (Issue #20) Существующий протокол легко переделывается в general-purpose задачи.

         {
             "commands":[
               {
                 "executable": "train.py",
                 "input": {
                     "params": [
                       {"name": "fasta", "value": "file1.fasta"},
                       {"name": "kabat", "value": "file1.kabat"},
                       {"name": "outdir", "value": "/tmp"},
                       {"name": "model_name", "value": "model.mdl"},
                       {"name": "ml_window_size", "value": "5"}
                     ],
                     "comment": "ig is really cool!",
                     "group": "all stars"
                 }
               },
               {
                  "executable": "predict.py",
                  "input": {
                      "params": [
                        {"name": "fasta", "value": "file2.fasta"},
                        {"name": "outdir", "value": "/tmp"},
                        {"name": "model_path", "value": "/tmp/model.mdl"},
                        {"name": "merge_threshold", "value": "1"},
                        {"name": "avg_window_size", "value": "10"},
                        {"name": "ml_window_size", "value": "5"}
                      ],
                      "comment": "ig is cool!",
                      "group": "all stars"
                  }
                }
             ]
          }

Backend ничего не знает про тулы. Он знает только корневую директорию с тулами. Из пришедшей команды он извлекает название exe-шника ("executable"), которое, в общем случае, включает в себя часть пути от tools_root. Params превращаются в аргументы (добавляется "--" и "=").

Feodorov commented 10 years ago

Все знание о тулах содержится в базе ig, которая доступна фронтэнду. Каждому тулу соответствует своя django-модель Удобно, что модель представляется в виде таблицы, в которой каждый столбец соответствует отдному параметру для тула. Дополнительное преимущество - из модели строится форма ввода параметров для пользователя, поэтому мы сразу убиваем двух зайцев.

zmactep commented 10 years ago

Очень хорошо, так оно и должно выглядеть как-то. Только стоит разделять параметры и входные-выходные файлы, наверное. Просто логически, чтоб быстро строить пайплайны на дефолтных параметрах. Да, и накручивать тулы на выходы других тулов будет проще. А унифицировать во всех наших консольных утилитах флаги входа-выхода - это дело 10 минут.

Feodorov commented 10 years ago

Остается незакрытый вопрос - как в pipeline пробросить файлы с вывода первой утилиты на вход второй. Сейчас выбор входных файлов осуществляется через dropdown list, данные для которого берутся из таблички Storage. Нужно научиться на стороне фронтэнда для второй утилиты во входные файлы добавлять файлы с вывода первой утилиты. Мне пока что пришло в голову следующее:

Из минусов - любое переименование выходных файлов в скрипте должно отражаться в базе.

Прокомментируй, пожалуйста. Вдруг у тебя есть более изящное и красивое решение.

zmactep commented 10 years ago

В общем-то, сейчас перечитал, у меня никаких возражений нет. Как я понимаю, оно ровно так и должно действовать.

  1. Каждая утилита у нас генерирует некоторый строго определенный набор данных, имеющий некоторые маски. Единственный случай, когда это слегка нарушается - всяческая кластеризация, где на каждый кластер может генерироваться собственный файлик. Но такие ситуации всегда можно просто разрешать, складывая из во внутренний каталог второго уровня, и имея некоторый описательный файлик, содержащий все названия кластеров. В связи с этим для каждого тула действительно имеет смысл хранить данные о выходных файлах. Другое дело, стоит ли это делать в DB, может имеет смысл просто некоторый манифест в директорию с каждым тулом положить, и дергать из него информацию при каждом ране. Тут же решается единственный минус.
  2. Для каждого тула также требуется определить возможные полезные выходы. Так, различные файлы визуализации регионов, файлы оценки качества и прочие никогда не могут стать входными для следующего этапа пайплайна. А вот для той же кластеризации, на следующем этапе может потребоваться наибольший кластер, может потребоваться fasta-файл с консенсусами всех кластеров и т.д. Соответственно, в тот же манифест или DB требуется добавлять такую информацию. Сюда же: некоторые тулы могут иметь еще и разные форматы входа, что логически не будет сильно менять их поведение, но при этом все равно будет что-то определять. Так, все для той же кластеризации, на вход могут быть переданы одиночные цепочки, а могут быть переданы пары тяжелая-легкая. Для исправления ошибок на вход может быть подана обычная FASTA, а может SFF (в таком случае можно будет смотреть еще и на качество и прочее). Так что такая информация тоже должна быть отражена в некотором манифесте.
  3. Все выходные параметры генерируются в автоматически создаваемый каталог (один каталог на один ран одного тула, чтоб не было смеси, как сейчас, когда мы тренируем модельку и в ту же директорию кладем prediction). Каталог стоит именовать с добавлением имени пользователя-инициатора обработки, названия обработчика и уникального id (может, вместо timestamp имеет смысл просто сквозную нумерацию запилить).
  4. При запуске pipeline добавлять в базу все таски, для каждого хранить в некотором поле id следующего таска, а также иметь поле sleep, чтобы делать отложенный запуск таска. По завершению этапа pipeline, следующему таску ставится требуемый входной файл (в этот момент сам файл существует, и значит его имя известно), снимается флаг sleep и инициируется его запуск.
Feodorov commented 10 years ago

Да, согласен. Нужно продумать формат манифеста. Видимо, это будет что-то вроде:

{
    "tool_name": "predict.py"
    "output": [
        {
             //Одиночный файл
             "name": "predict_result.kabat",
             "description": "output prediction in kabat",
             "type": "kabat",
             "is_input": true //Может ли подаваться на вход следующего тула?
             "mandatory": true
        },
        {
             //Группа файлов
             "name": "cluster_\d+.txt",
             "description": "clustered region",
             "type": "cluster",
             "is_input": true, 
             "mandatory": true,
             "max_occurs": "unbounded", //Может быть несколько файлов, соответствующих регулярке "name"
             "select_predicate": "max_size" //Если нужно выбрать лишь один из файлов для следующего этапа - выбираем файл наибольшего размера. Нужно продумать, как добавить другие варианты (максимальный score, что-то еще)
        },
    ]
}
zmactep commented 10 years ago

Да, как-то так. Ну, и иметь табличку типов где-то в базе. И табличку возможных предикатов. Аналогично input - отдельной графой. И params - отдельной графой. Хотя тут нужно еще подумать, потому что из моделей табличек БД действительно очень удобно потом на халяву иметь формочки в интерфейсе.

Feodorov commented 10 years ago

Нужна возможность сохранять собранный пайплайн под новым именем. Чтобы не собирать заново при следующем запуске.

Feodorov commented 10 years ago

2013-11-17 22 49 18 Внизу, рядом с кнопкой Start появились две кнопки и выпадающее меню. Через меню выбирается тул, затем, по нажатию Add Selected добавляется новая форма. Например, после нажатия Add Selected добавляется форма: 2013-11-17 22 52 17 Самое интересное - это раздел "Файл с моделью" во второй форме и "Входной KABAT файл" в третьей - это еще не существующие файлы с предыдущего шага.
Пока что поддерживается только Train и Predict, но поддержку я добавлю быстро, ибо трудно создать только первые формы.

Feodorov commented 10 years ago

Доделал поддержку пайплайна для всех форм. Обрати внимание, что нужно будет подправить таблицу ig.igbackend_tasks (в скрипте create_db.sql уже прописан правильный вариант).