Pipeline

[zmactep]

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

[zmactep]

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

[Feodorov]

Мысли вслух про реализацию, прокомментируй, пожалуйста.
Мета-Актер - унифицированные команды. (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]

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

[zmactep]

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

[Feodorov]

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

• Храним для каждой модели (которая есть описание параметров тула) мета-таблицу со списком имен выходных файлов (типа "result_pic.txt", "output.kabat").
• Добавляем эти файлы во входной список файлов для последующих утилит.
• Убираем параметры outdir, а вместо него будем использовать обязятельный параметр group (=prefix, =outdir_name, =tag). Все имена файлов будут генерироваться автоматически, и класться в папку storage_root/group/unix_timestamp/filename.txt
• Unix timestamp нужен на случай, если пользователь совершает повторный запуск в рамках одной задачи (например, тренирует модель с разными параметрами) и предотвращает замену файлов
• Очевидный плюс - пользователь вообще не работает с путями. Входные файлы он выбирает из списка, для выходных файлов он задает только group (или даже, логичнее, назвать это tag) - по которому строится выходной путь, а имена файлов берутся из мета-таблицы с описанием тулов. И, благодаря такой системе, мы всегда можем знать имена и пути для выходных файлов и показывать их в интерфейсе при выборе входных файлов для следующего тула
• После отработки каждой задачи в рамках списка команд актор запускает скрипт scan_dir (Issue Загрузка данных #16), который сканирует только директорию storage_root/group/unix_timestamp/ и добавляет все файлы в таблицу storage_item. unix_timestamp - это таймстемп запуска задачи, а не создания отдельных файлов, так как в подобном случае у нас был бы не единый таймстемп, а диапазон, что не удобно. В качестве доп. параметров для scan_dir я введу дополнительно timestamp и group. Скрипт запишет в таблицу storage_item basename в качестве ID файла, group и таймстемп из параметров запуска, и абсолютный путь.
• Еще нужно будет модифицировать выбор входных файлов в выпадающем списке в интерфейсе - к ID файла добавить group и timestamp - так как я сомневаюсь, что кто-то будет переименовывать ID файла в уникальное значение (а не basename по-умолчанию) после запуска задачи. ID файла не уникален (уникальна тройка - ID файла, таймстемп и группа), поэтому в интерфейсе нужно отразить это соответствующим образом - добавить оставшиеся 2 аттрибута.

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

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

[zmactep]

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

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

[Feodorov]

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

{
    "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]

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

[Feodorov]

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

[Feodorov]

Внизу, рядом с кнопкой Start появились две кнопки и выпадающее меню. Через меню выбирается тул, затем, по нажатию Add Selected добавляется новая форма. Например, после нажатия Add Selected добавляется форма:

Самое интересное - это раздел "Файл с моделью" во второй форме и "Входной KABAT файл" в третьей - это еще не существующие файлы с предыдущего шага.
Пока что поддерживается только Train и Predict, но поддержку я добавлю быстро, ибо трудно создать только первые формы.

[Feodorov]

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