PLINK

[Anode]

Да, я честно говоря, думал что plink может делать подобную фильтрацию, а оказывается - нет (посидел я с ним пару часов, изучил маны).

т.е. нужный Вам фильтр надо написать.

Сразу возникают вопросы:
1) В Raw Data файле - строки отфильтрованы всегда в порядке возрастания локусов, или не обязательно?
2) Нужно ли показывать в PED и те аллели - которых нет в Raw Data, заполняя их нулями, или же предполагается - что "те строки, что читаем из инпута - кладём в колонки в аутпут, как есть"? (в этом случае фильр можно сделать экстремально быстрым, не кушающим память и не использующим внешних временных хранилищ).
А если файл для одного человека имеет снип, которого нет в другом файле? (если это возможно, то надо поддерживать список/мэп в отдельном файле для тех аллелей, которые показываются в выходном PED, даже если они нули. Где взять такой полный список снипов?)
3) Нужны ли другие маппинги, типа возможность поменять что-то на что-то (как позволяет plink)?
4) Каким образом загружать FAM файлы, т.е. сообщать - к какой группе, индивиду итд (первые 6 колонок) относится данный 23andme файл? Для этого, например, можно использовать TFAM формат из документации plink'а, но добавить 7ю колонку - имя файла со снипами. Или если в файле снипы для многих людей - надо вводить и ID для линковки. Как удобнее (это зависит от приходящих данных - каких больше всего?)? Иными словами - что предполагается в будущем - один RAW файл на человека, или RAW файл на группу людей?

[Anode]

В исходном же формате 23andme, нет вообще никаких пробеловто есть генотип записывается в столбик без пробела между аллелями, например АА, AC и т.д.Неужели придется разделять аллели пробелом вручную. В случае выборки из 500 кб снип*100 человек, эта просто нереально.

не понял, по одной биаллели на строку, или же комма-делимитед, как в:
rs123456  7  12345678  АА, AC
?

[I2a1a]

Нет. Поясню на своем же примере. Тут речь о другом.Допустим два человека тестировались в 23ия.Соответствующая пара на rs123456 (на 7 хромосоме)у них выглядит следущим образому первого s123456  7  12345678  АА(пробела нет)у второгоrs123456  7  12345678  AC(пробела нет)Перед нами стоит задача записать это в формате PLINK1 1 0 0 1 1 A A (между аллелями пробел)2 1 0 0 1 2 A C (между аллелями пробел)Добавим еще один абстрактный снип на той же хромосоме.Пусть  у первого тестанта будет rs123000  7  12345679  АА(пробела нет) а у второго тестанта rs123000  7  12345679  AG(пробела нет)Тогда PLINK будет выглядеть в упрощенном виде следущим образом1 1 0 0 1 1 A A (между аллелями пробел)(табуляция или в Экселе -следущая колонка)A A(между аллелями пробел)2 1 0 0 1 2 A C (между аллелями пробел) (табуляция или в Экселе -следущая колонка)A G(между аллелями пробел)Т.е. в конечном виде выглядит так1 1 0 0 1 1 A A    A A2 1 0 0 1 2 A C    A GА теперь повторите это упражнение по 500кб снипам *100 тестантов.

[Anode]

насчёт формата одной строки в 23andme понял.
Добавить/убрать символы - пустяк. Там же дело в масштабируемости - чтобы написать так - чтобы можно было запускать данные любого объёма. Вопросы касаются изначального представления данных. Теперь - что представляют собой много данных в целом?
В любом случае, давайте продолжать дискуссию - для про-/вы-яснения "бизнес-требований" - в терминах определения программистской задачи.

Итак, пожалуйста попробуйте ответить на 4 вопроса выше (от них зависит - насколько сложная будет программа внутри: несколько часов работы или больше) и если мне не понятно - буду спрашивать ещё.

[I2a1a]

Да, я честно говоря, думал что plink может делать подобную фильтрацию, а оказывается - нет (посидел я с ним пару часов, изучил маны).

т.е. нужный Вам фильтр надо написать.

Сразу возникают вопросы:
1) В Raw Data файле - строки отфильтрованы всегда в порядке возрастания локусов, или не обязательно?
2) Нужно ли показывать в PED и те аллели - которых нет в Raw Data, заполняя их нулями, или же предполагается - что "те строки, что читаем из инпута - кладём в колонки в аутпут, как есть"? (в этом случае фильр можно сделать экстремально быстрым, не кушающим память и не использующим внешних временных хранилищ).
А если файл для одного человека имеет снип, которого нет в другом файле? (если это возможно, то надо поддерживать список/мэп в отдельном файле для тех аллелей, которые показываются в выходном PED, даже если они нули. Где взять такой полный список снипов?)
3) Нужны ли другие маппинги, типа возможность поменять что-то на что-то (как позволяет plink)?
4) Каким образом загружать FAM файлы, т.е. сообщать - к какой группе, индивиду итд (первые 6 колонок) относится данный 23andme файл? Для этого, например, можно использовать TFAM формат из документации plink'а, но добавить 7ю колонку - имя файла со снипами. Или если в файле снипы для многих людей - надо вводить и ID для линковки. Как удобнее (это зависит от приходящих данных - каких больше всего?)? Иными словами - что предполагается в будущем - один RAW файл на человека, или RAW файл на группу людей?

Отвечаю по порядку.

1.В Raw Data файле строки-снипы отфильтрованы по порядковому номеру хромосомы (и в конце -мито), а внутри хромосомы по расположению на хромосоме.

2.У серьезных людей, работающих с форматом PЕD существует консенсус, как работать с пропущенными значениями аллелей. Эта проблема решается фазированием генотипе в программе PHASE, и именно благодаря фазированию значения пропущенных снипов заменяется наиболее вероятными. Впрочем в формате PHASE существует еще специальные знаки для пропущенных или неизвествных значений "-9", в формате Plink используется "0". Однако форматы PHASE и Plink сильно отличаются друго от друга, и вопрос об их совместимости пока для меня является открытым.  Думаю, что нужно действительно (как и написано в мануале) заполнять "void" значения нулями.Теперь насчет снипов. Насколько я понял (хотя могу ошибаться) список снипов стандартный (и он соответствует первой колонке Raw Data), в том случае если у человека этого снипа нет, тогда в строке стоит прочерк. Кстати еще обращаю внимание, что формат MAP практически тождествен формату Raw Data (если исключить последную колонку с генотипом). То есть с этим форматом  MAP вообще проблем быть не должно.


3. Другие "мэппинги" ненужны, так как Plink позволяет вносить изменения в формат с помощью встроенных параметров (т.е. там гибкая система, которая позволяет менять данных на уровне параметров программе, без предварительных изменений входных данных).


4. Я не видел в Plinke формата FAM. Если Вы имеете ввиду TFAM, то это просто транспонированый формат PED, который более удобен для больших объемов данных.  Первые шесть колонок в PED и TFAM -это так называемые индексы или индификаторы. Первый индекс - либо семья (это в случае исследования ассоциациий заболеваний со снипами) либо популяция (примечание -в формате TFAM этот индекс не должен повторятся, то есть должен быть уникальным); второй - индекс персоны внутри семьи/популяция; третий четвертый -индекс-ссылка на уникальный ID отца и матери в семье (их можно пропустить если неизвестны заменив "0"); пятая -половая принадлежность;шестая -фенотип> может быть двух типов: 1)affected status (в случае болезней 1- пораженный заболеванием 2-непораженный) и 2) при популяционном анализе можно использовать значения 1 и 2 для соответственно контрольной и тестовой группы.

[I2a1a]

насчёт формата одной строки в 23andme понял.
Добавить/убрать символы - пустяк. Там же дело в масштабируемости - чтобы написать так - чтобы можно было запускать данные любого объёма. Вопросы касаются изначального представления данных. Теперь - что представляют собой много данных в целом?
В любом случае, давайте продолжать дискуссию - для про-/вы-яснения "бизнес-требований" - в терминах определения программистской задачи.

Итак, пожалуйста попробуйте ответить на 4 вопроса выше (от них зависит - насколько сложная будет программа внутри: несколько часов работы или больше) и если мне не понятно - буду спрашивать ещё.

Спасибо за инициативу (+1), если необходимо -можем выделить эту дискуссию в отдельную ветку или объединить дискуссию с веткой Plink, которая уже имеется на форуме.

[Anode]

отлично, спасибо. Понял.

Итак, по вашему примеру к вам в приходят файлы в виде:
---------файл1----------
rs123456 7 12345678 АА
rs123000 7 12345678 АА
...
 много строк (500)
...
------------------------


---------файл2----------
rs123456 7 12345678 АC
rs123000 7 12345678 АG
...
 много строк (500)
...
------------------------

и мы делаем на выходе
---------файл3----------
1 1 0 0 1 1 А А   А А   ... много столбцов (500) ...
2 1 0 0 1 2 А C   А G   ... много столбцов (500) ...
------------------------

но где гарантия - что завтра не добавят ещё один снип и столбцов в старых файлах будет 502, а в новом - больше. А если бардак с разными версиями файлов (какие-то снипы убрали в будущем, какие-то - добавят) - то не будет однозначного соответствия: номер столбца - номер снипа. Откуда тогда будем знать - что точно лежит в столбце 498?
Этот стандарт надо либо зафиксировать (как выше - 500 и раз и навсегда) - что вряд-ли возможно, ввиду развития отрасли, либо сделать ещё один файл - где перечислены все снипы которые надо выводить, в нужном порядке
---------файл4----------
rs123456 rs123000 ... ещё 500 ...
------------------------
если 23andme начинает выдавать другой формат - просто добавляем или убираем из файла4 (т.е. управляем столбцами в выходном  PED.

Под FAM я имел в виду недостающий мне (ведь ваших файлов - 100 - по числу тестантов):
---------файл5----------
1 1 0 0 1 1 файл1
2 1 0 0 1 1 файл2
...
 много строк (500)
...
------------------------
который несёт в себе инфомацию, связывающую IDs с именами файлов ваших 100 тестантов.

хотя можно и по-другому организовать.

[Anode]

скажите что вам не нравится в вышеописанном или опишите идеальную организацию данных, пытаясь экстраполировать ситуацию через скажем 10 лет, когда будет гораздо большие объёмы. Скажем, вам дадут все файлы с 23andme и там будут _все_ снипы. Как к Вам придёт дата (и её linkage) с данными из моего файла5?

А может они добавят ещё одну колонку (первую) - с ID и пришлют все данные в одном большом файле + ещё один файл с информацией по каждому ID (для построения первых 6 колонок на выхлопе)?

[I2a1a]

Спасибо за ответ.
Вы правильно поняли мою мысль (про формат), но не до конца.
На самом деле в Raw Data не пятьсот строчек, а пятьсот тысяч.Я интуитивно предполагаю, что в научных исследованиях ограничиваются определенным набором снипов, например, 300, 500, 3500, 10000 снипов (в зависимости от поставленных задач - например 3500 "этно"-снипов и т.д.). Анализировать по всем 500000 снипов -это явный абсурдЕсли я правильно понял Вас, то Вы предполагаете организовать данные о снипах в виде отдельных файлов где будет содержатся информация об определенном наборе снипов, где файл FAM будет выступать своего рода хранилищем индексов доступа (что-то наподобие реляционных баз данных). Согласен, что это бы существенно уменьшило нагрузку при обработке данных, и позволило бы плавно переключаться с одного набора на другой. Однако, при прочтении мануала Plink, я не нашел описания этого формата (файла, где бы хранились имена ключи-имена файлов в качестве индекса доступа).На самом деле, формат Plink предполагает, что в ОДИН файл записываются ВСЕ данные (первые 6 идентификаторов и начиная с 7 позиции -генотип) по ВСЕМ (10,100,1000, 10 000) тестантам.

[I2a1a]

скажите что вам не нравится в вышеописанном или опишите идеальную организацию данных, пытаясь экстраполировать ситуацию через скажем 10 лет, когда будет гораздо большие объёмы. Скажем, вам дадут все файлы с 23andme и там будут _все_ снипы. Как к Вам придёт дата (и её linkage) с данными из моего файла5?

А может они добавят ещё одну колонку (первую) - с ID и пришлют все данные в одном большом файле + ещё один файл с информацией по каждому ID (для построения первых 6 колонок на выхлопе)?

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

[Anode]

> не пятьсот строчек, а пятьсот тысяч

ок, понял, я и не собирался ограничивать, я так и предполагал

>Если я правильно понял Вас, то Вы предполагаете организовать данные о снипах в виде отдельных файлов где будет содержатся информация об определенном наборе снипов

не совсем. Я понял - что вы _уже_ принимаете файлы в таком виде (1 файл - на 1 человека). И для 100 тестантов будет 100 файлов. Для всех людей на земле - будет 6 млрд файлов.

>где файл FAM будет выступать своего рода хранилищем индексов доступа (что-то наподобие реляционных баз данных)

да, правильно поняли.
Потому что я не знаю - откуда вы _изначально_ берёте IDs (т.е. в каком формате они к вам приходят. Может - как часть имени файла?)

>На самом деле, формат Plink предполагает, что в ОДИН файл записываются ВСЕ данные (первые 6 идентификаторов и начиная с 7 позиции -генотип) по ВСЕМ (10,100,1000, 10 000) тестантам.

это да, но это же уже в Plink'е, у нас на выходе. А на входе - вы имеете всего-лишь 4 колоночные файлы. В 4 колонки RAW файла нельзя впихнуть _всю_ информацию, т.е. где-то эта информация будет ещё. Вопрос - где. Как вы предполагаете _получать_ данные, скажем по 100000 тестантов? 

[I2a1a]

На выходе с 23ия имеем 1 файл= 1 человек (вернее та часть его генома, которая проанализирована. Соответственно, 100 человек = 100 файла. Наша задача -объединить эти 100 файлы в ОДИН файл. Поскаольку "мэппинг" у всех один, то нужно взять один файл Raw Data и убрать из него последную колонку с генотипом.
Насчет IDs - я не совсем понял. Если вы имеете ввиду ID SNP-ов, то их наименование взято из последней версии Human Genome Assemblage (36 версия, по-моему). Если речь идет о ID как идентификаторах индивидов, то обозначение надо придумывать самому.

[Anode]

Извините за плохую формулировку.
По-другому:
допустим вам дают данные по 10000 тестантам в RAW формате из 23andme. Что вам присылают в tgz, tar.gz или zip'е?
Один файл? Много? Сколько?
Где информация, связывающая какую-то строку RAW файла - с полом и конкретным человеком (по ID).
Я предвижу 2 варианта:
либо куча файлов (файл - на человека) и маппинг: IDs - строка в одном из вариантов (нормализованный вариант).
либо один файл но с добавленными колонками (денормализованный, но всё в одном файле).

Это всё аналогично реляционкам. На самом деле - различия мало. Файлы - как таблицы. И вообще - до реляционок как раз и пользовались тем, чем мы занимаемся (файлами). Я знавал человека, который любые запросы делал - над большими файлопомойками и выводил репорты в любом виде, как угодно организовано и отсортировано по столбцам, очень быстро. Те-же 3 оператора что и в реляционной алгебре: селект, проджект, произведение. В реляционке - таблицы, здесь - файлы. И так же можно нормализовывать-денормализовывать. Но это отступление, игнорируйте, плиз.

[Anode]

просто объединить нельзя, так как на входе - 100 файлов по 4 колонки каждый (4 разных типа информации + информация в имени файла), а на выходе - один файл с 7ю типами. Что подставляем в первую колонку (знаю, ID, но где его берём?)?
Ведь файлов много, мешать всё в кучу нельзя. Просто автоматически увеличивая ID - тогда не знаем - что ставить в пол и в родителей.
Короче, мне не хватает информации.

С одним файлом - потянет. Но вы же говорите - их будет 100, 10000.
Видимо - информация будет зашита в имени файла (стандартизованном), или же - в отдельном файле по типу моего FAM, приведённого выше.

Ну не ставить же нули в колонки 2 - 6? 

[napobo3]

...Михаил, а что Вы думаете по поводу таблицы профессора Мак Миллана

Я не Михаил, но тоже отвечу. Джим высчитывает скорее всего правильно и основательно, но представляет все в каких-то жутких Экселях. У меня от них в глазах темно. Но зато он умеет вычислять сантиморганы...
Мы считаем попроще, зато даем интерфейс простой, как хозяйственное мыло. Нам бы еще программиста на два часа в неделю и было бы все прекрасно. На мои крики никто не отозвался, поэтому будем улучшать сами. И сантиморганы освоим.