Игнатий Колесниченко: «У бактерии денег не попросишь»
Представляем второй выпуск подкаста о технологиях, процессах, инфраструктуре и людях в IT-компаниях. Сегодня в гостях у «CTOcast» — Игнатий Колесниченко, технический директор компании iBinom (анализ генома человека).Слушать подкаст
1-ая часть текстовой версии подкаста
Текстовая версия подкаста (2-ая часть)О ТЕХНОЛОГИЯХ Павел Павлов: Об алгоритмах можно спрашивать многое, но начнем с самого очевидного вопроса. В первое время, наверняка, вы использовали существующие алгоритмы, то есть речь шла об их адаптации. Была ли возможность создать что-то свое? Каким образом строился именно ваш сервис и подход?
Игнатий Колесниченко: Я бы сказал, что где-то половина у нас используется существующего as is. Но нужно понимать, что существующее также необходимо настроить. К примеру, бывают секвенаторы с разными данными, немного в разных форматах и длинах, и алгоритмы на таких данных работают с отличиями по качеству. Нужно было разобраться на каких данных применять те или иные алгоритмы, какие будут результаты.
Ну, и сам алгоритм выравнивания. Конечно, в какой-то момент у нас была идея, и мы даже пробовали, написать свой, но задача оказалась сложной и не очень подъемной для стартапа. Потому что если посмотреть на какой-нибудь известный алгоритм выравнивания, там 30 000 строк кода на плюсах, оптимизированных, которые развиваются, допустим, последние 4 года силой двух-трех человек. Очевидно, что мы такое повторить сходу не можем.
Павел Павлов: Какой критерий при выборе алгоритмов был основным для вас? Производительность? Степень достоверности?
Игнатий Колесниченко: Критерий был компромиссным, чтобы нас устраивало и чтобы мы действительно могли сделать все за заявленный час. Как раз большинство алгоритмов не подходят именно по этому параметру — они очень медленные. Может быть, чем-то другим хороши, но не скоростью. И вообще они для анализа генома человека, скорее всего, не очень подходят. Просто все эти алгоритмы используются не только для генома человека. Ученые точно также бактерий анализируют, растения. У бактерий геномы, конечно, не 3 миллиарда, а 10 миллионов, к примеру. Там задача существенно проще за счет этого.
Александр Астапенко: Но бактерии — это не очень платежеспособный клиент, насколько я понимаю, да?
Игнатий Колесниченко: Естественно. У бактерии денег не попросишь.
Павел Павлов: К сожалению!
Игнатий Колесниченко: Про наши алгоритмы… Естественно, первая стадия самая сложная и у нас используется один из имеющихся алгоритмов. Дальше идет стадия коллинга, нужно понять какая мутация произошла. Здесь мы используем как свой алгоритм, так и уже имеющийся. Пока окончательно не выбрали. А дальше есть еще одна интересная стадия: произошла, к примеру, мутация и нужно понять с какой вероятностью она приведет к тому, что белок в кодировании которого это мутация участвует, сломается. Что мы сделали? Есть уже много разных алгоритмов, которые говорят: «Эта мутация приводит к поломке такого-то белка, с такой-то вероятностью». Мы такие алгоритмы собрали, использовали их результаты как фичи и построили свое машобучение на этих фичах. То есть здесь свой алгоритм работает.
Павел Павлов: А что было сложнее? Поиск реализации этих алгоритмов или, к примеру, построение платформы, которая осуществляла бы весь расчет, анализ, именно инфраструктурно?
Игнатий Колесниченко: Это немного разные задачи, но мне кажется, что инфраструктурная часть была немного сложнее. В анализе алгоритмов сложность в том, чтобы сделать это корректно, также требуется много вычислительных ресурсов. Но в целом, конечно, задача проще. А построить инфраструктуру, которая будет запускать все в Амазоне, которая будет позволять заливать данные и которая продолжает заливку, встроить так, чтобы все вместе собралось в один сервис и работало как часы — не так просто.
Павел Павлов: Получается, что обе проблемы решал, в первую очередь, именно ты как главный технический специалист в компании?
Игнатий Колесниченко: Да, решал и те, и другие проблемы. Но на самом деле, когда мы только начинали, я сказал: «Ну, слушайте, ребята, есть 20 часов в неделю, которые я могу на вас тратить. Но, очевидно, что на 20 часов в неделю мы далеко не уедем». Поэтому первым делом мы пошли искать CTO, который всем заведовал бы. Я ему тоже помогал, естественно, но больше с точки зрения продумывания архитектуры. Реализовывалось это без меня. А я, собственно, занимался экспериментами и исследованиями, выбирал какой алгоритм и как мы будем использовать. Ну, и вся та часть, которая касается запуска и хранения на Амазоне, тоже была моей задачей.
Павел Павлов: Наверное, имеет смысл пройти весь workflow по порядку. Начнем с того момента, когда пользователи пытаются загрузить свои 2--20 Гбайт в ваше S3-хранилище. Как этот процесс происходит? Какие сервисы вы используете?
Игнатий Колесниченко: Никаких особых секретов нет. Пользователь заливает данные, они проксируются и попадают в S3. На back-end, естественно, все сделано аккуратно, упрощена заливка, есть возможность продолжить заливку, если вдруг оборвался коннекшн. Для обработки данных после заливки запускается MapReduce задача, которая все эти данные выравнивает, анализирует, и на выходе мы имеем список мутаций.
Поскольку мутаций уже не так много (для экзома человека получается около 50 тысяч), то можно анализировать локально, что мы и делаем. У нас установлены различные базы, с помощью которых мы смотрим на мутации и понимаем, где они вообще находятся, кодируют они белки или нет. Из этих баз также выкачиваем ссылки на статьи, публикации про мутации. И затем строим PDF-отчет, в который выписываем 50 самых значимых мутаций. В этом же отчете по ходу работы всех алгоритмов мы собираем много дополнительной информации, например, сколько мутаций таких, таких и таких. Пользователю показываем так, чтобы он мог представить, что с его данными происходило, как мы все это обрабатывали.
Еще есть личный кабинет, где пользователь может зарегистрироваться, свои данные, собственно, он хранит у нас. Он может также изменять настройки и выбирать, что ему в отчете показывать, а что нет.
Павел Павлов: И в большинстве случаев пользователь, то есть медицинский специалист, в состоянии разобраться с этими настройками и получить нужный для него результат?
Игнатий Колесниченко: Сложный вопрос. Кажется, что никто, на самом деле, настройки толком не крутит, то есть люди скорее получают отчет и дальше на него смотрят. Дефолтные настройки как подходят, так и не подходят на данный момент. Теперь у нас уже есть понимание, что просто выдать мутации недостаточно. Поэтому мы доделываем систему, которая будет интерактивной: вот мутации, которые мы уже нашли, а есть еще симптомы заболеваний. Врач укажет симптомы и какие болезни ему интересны, а мы поймем как это соотносится с мутациями.
Павел Павлов: И это ожидание основано на каком-то фидбэке?
Игнатий Колесниченко: Да, честно говоря, каждый второй пользователь говорил, что он получает наши мутации, а дальше ему все равно приходится проделывать работу, чтобы сделать какой-нибудь вывод. Мы поняли, что нужно всю эту информацию агрегировать и помочь пользователю решить его задачу в одном месте как можно быстрее и проще.
Павел Павлов: Вернусь все-таки к Амазону. Для решения задач, связанных с MapReduce, Hadoop, есть отдельные специализирующиеся стартапы, облачные сервисы, которые решают проблему более эффективно, и, в какие-то моменты, даже более дешево. По большому счету, если нужен только MapReduce и S3-хранилище, то явно не на полную мощность используется сервис.
Игнатий Колесниченко: Нет, естественно, не на полную мощность. Насколько мне известно, все остальные, кто специализируется на разворачивании Hadoop и поднятии стека, они скорее подходят для, к примеру, банков, у которых уже есть свои собственные 10 машин, 10 серверов. Им нужно просто его развернуть, настроить, помочь им выстроить процессы. А у нас же не так, то есть мы не можем держать 10 машин все время поднятыми, потому что это будет очень дорого для нас сейчас.
У нас поток — несколько анализов в день, поэтому нам проще несколько раз разворачивать кластер из 5--10 машин, на нем все анализировать за час и сворачивать. Это на текущий момент дешевле. Наверное, в какой-то момент, если мы вырастем, будет выгоднее держать свой собственный кластер, просто из 10 машин, и тогда осмысленно уже обращаться к специализированным сервисам.
Павел Павлов: А удалось достичь каких-то изменений, серьезного улучшения в производительности и, тем самым, сократить время расчета и сэкономить деньги?
Игнатий Колесниченко: Да, в Амазоне есть такая приятная фича, как спотовые инстансы, которые позволяют сократить количество денег и почти ничего не потерять. То есть они свои остаточные мощности продают по цене в 10 раз меньше, чем у них обычно стоит машина.
А так, на самом деле, мы крутили, экспериментировали, но в целом не скажу, что мы что-то существенное выиграли, процентов 10--15. Основные проблемы в Амазоне с тем, что у них все это запускается из коробки, которая, по большому счету, рассчитана на запуск java-кода, а у нас весь код написан на плюсах и были некоторые проблемы с бинарной совместимостью.
Павел Павлов: А можешь немного подробнее рассказать про несовместимость? Просто мне не приходилось раньше сталкиваться.
Игнатий Колесниченко: В Амазоне есть Elastic MapReduce, то есть уже готовый образ Hadoop, но ты управлять образом никак не можешь. Ну, собственно говоря, потому что Амазон отвечает за то, чтобы он был рабочим, поэтому он его один раз настроил в соответствующем образе и выдал тебе. И есть возможность поднять только похожие виртуалки. Ты поднимаешь похожую виртуалку, на ней что-нибудь настраиваешь, посылаешь туда собранный бинарник, а он в libc неожиданно падает, когда какой-нибудь трек новый создает. Ну, и проблема!
Павел Павлов: Ну, фактически, процесс можно автоматизировать, чтобы отслеживать ошибки? Я так понимаю, что случается это все довольно регулярно?
Игнатий Колесниченко: Нет, скорее разово. Проблема случается, когда мы на машине что-нибудь обновляем. Выходит обновление, а машина, скажем, была достаточно старая, ты обновляешь и вместе с этим обновляется libc, из-за чего неожиданно все ломается.
Вот такая техническая проблема, но она решаемая. В автоматизировании здесь смысла особого нет, потому что мы запускаем все время одно и то же. Мы же не публичный сервис, пользователь сам не собирает бинарники и к нам не присылает. У нас, не знаю, 5 бинарников и нужно просто сделать так, чтобы они запускались успешно и отрабатывали.
Я, к своему сожалению, узнал, что Hadoop, кажется, не очень приспособлен для запуска такого бинарного кода. Он все-таки сильно заточен на то, чтобы было удобно для java, а для тех людей, кто пытается запускать сторонний код — все не очень удобно. С интерфейсом были некоторые проблемы, с тем, как там правильно параметры настройки указать. Потому что в новом Hadoop сейчас все это в контейнерах отдельно запускается, еще есть java-прослойка, которой нужно столько-то памяти выделить. То есть вся твоя задача запускается под java-машиной как child. Есть контейнер, в нем живет java-машина, в java-машине живет твоя программа, а еще эта java буферизирует данные, которые она читает и пишет. И нужно все это правильно учесть, чтобы максимально эффективно использовать ту память на машине, которая есть, чтобы ничего не падало, за память не вылазило.
Павел Павлов: Ну, и опять же получается, что если бы у вас было статическое облако, какая-то стабильная конфигурация, то проблем было бы значительно меньше?
Игнатий Колесниченко: Да, это правда. Но пока мы не можем себе позволить статический кластер.
Павел Павлов: А сколько примерно типичный расчет — от загрузки до получения конечного PDF-файла — по времени занимает?
Игнатий Колесниченко: Зависит от объема данных, но в целом час. Когда данных 2 Гбайта, постпроцессинг, который ищет по разным базам, он занимает минуту, а когда данных 30 Гбайт — уже 10--15. И, к сожалению, этот процесс очень тяжело распараллелить, его на MapReduce так легко уже не положишь, поскольку все базы, в которых нужно искать, они занимают десятки гигабайт. И раз облако не статическое, то эти десятки гигабайт мы не можем просто разослать на все машины, потому что все начнет в сеть упираться. У нас и так минут 5 в запуске кластера занимает тот факт, что нам нужно наш эталонный геном, который весит 3 Гбайта, да еще всякие индексы с ним, то есть около 10 Гбайт, посылать на все машины.
Павел Павлов: На Амазоне? Но там же довольно серьезный канал, то есть, как минимум, 1 Гбит?
Игнатий Колесниченко: Получается не 5, а по большому счету меньше, потому что S3 живет где-то в одном месте, а кластер поднимается немного в другом. То есть все в одном лице, конечно, но там явно не бесконечная сеть и выкачать 10 Гбайт минут 5 занимает. К сожалению, нет там такого, что вот чистый гигабит, мы 10 Гбайт делим на 100 МБ/с и получаем 100 секунд. Так не происходит, все получается гораздо медленнее.
Павел Павлов: А позволяет Амазон сейчас как-то оптимизировать такие инфраструктурные моменты, связанные с сетевой топологией и издержками?
Игнатий Колесниченко: Я пытался общаться с суппортом и, кажется, что не особо позволяет.
Павел Павлов: То есть даже, если выбираешь один и тот же дата-центр, зону доступности, то все равно может гонять через кучу роутеров?
Игнатий Колесниченко: Сложно понять через сколько там роутеров гоняется. У них внутренняя сеть поднята и очень все это непонятно. Снаружи торчат одни айпишники, а внутри — другие. То есть внутри совершенно своя сеть и понять, что там происходит в точности, невозможно. Бывает, что машины разные поднимаются. Вроде бы это никак не сказывается, просто такой интересный факт.
Павел Павлов: Ну, они все равно же пытаются выравнивать как-то вычислительную мощность юнитов своих?
Игнатий Колесниченко: Да. Я не могу сказать, что одна машина оказалось хуже, чем другие, тормозит.
Павел Павлов: Входные данные, которые загружает пользователь, это какой-то стандартизированный формат? Зависит ли он от секвенатора или от чего-то другого?
Игнатий Колесниченко: Скорее разные стандарты. Есть, например, в какой-то области программирования 20 стандартов. А давайте мы напишем 21-й, который все эти 20 объединит! Ну, и потом оказывается, что теперь 21 стандарт просто-напросто. Тут зачастую происходит точно так же. Какая-нибудь новая компания, лаборатория или производитель секвенаторов говорит: «Слушайте, я тут подумал-подумал и понял, что старый формат так себе. Вот у него есть такие-то проблемы. Возьму-ка я и сделаю новый формат». И действительно такие проблемы у старого формата есть. Но другие компании продолжают делать по-старому и в итоге форматов становится на 1 больше. Но все на самом деле не так плохо с форматами входных данных.
Александр Астапенко: Игнат, а есть ли уже сейчас какие-то сервисы, которые хранят эти данные в клауде, чтобы пользователю не нужно было их через web-интерфейс загружать?
Игнатий Колесниченко: Да, есть такая задача. Сейчас тенденция заключается в том, что провайдеры секвенаторов говорят своим клиентам: «Давайте вы к секвенатору будете не жесткий диск подключать, а проводок вот этот зеленый воткнете, и мы все сразу будем в свое облако лить». Та же Illumina, у нее есть свое облако, куда она все данные автоматически заливает. И когда врач делает анализ, они ему присылают ссылку. Все, и не надо там никаких ходов.
О КОМАНДЕ iBinom Александр Астапенко: Какие люди сейчас есть в вашей команде? Кого собираетесь нанимать и в каком направлении двигаться?
Игнатий Колесниченко: Сейчас у нас из-за отсутствия денег команда уменьшилась, но изначально она делилась на 2 части. Первая часть — построение сервиса, web-интерфейс, его разработка и т.д. И там, собственно, был наш CTO, который уже с нами не работает, а также еще один отличный web-разработчик. Кроме того, у нас был и есть один младший разработчик.
Александр Астапенко: А можешь назвать технологии, чтобы было более-менее понятно?
Игнатий Колесниченко: Вэб, back-end и front-end, у нас на Node.js, плюс Jade, CSS. В back-end есть еще немного Python, Bash, но это все, что касается построения отчета, запуска на Амазоне.
Это одна часть команды. Вторая часть команды, которая у нас была и есть до сих пор — исследования. Идея всего стартапа принадлежит нашему биологу Валерию, который также когда-то занимался «Генотек». В исследовательской части команды нас было в разные моменты времени 4--5 человек. Мы пробовали алгоритмы, изучали новые задачи.
Например, следующая задача: есть проанализированный геном мамы, папы и ребенка и требуется более точно ответить на вопрос про мутации ребенка, понять какие мутации у него новые, которых нет у родителей.
Еще есть одна интересная задача, которая касается системы мать-плод: берем у беременной женщины анализ крови, а в этой крови плавают кусочки ДНК ее ребенка. И можно попробовать их оттуда выделить и проанализировать. То есть когда мы будет анализировать, мы будем видеть прочтение ДНК и мамы, и ребенка. Таким образом можно попытаться понять мутации у ребенка заранее. Очень перспективная область, но пока, к сожалению, в этом вопросе показатели качества довольно низкие.
Александр Астапенко: Если мы говорим о back-end, то вас было трое?
Игнатий Колесниченко: Не считая меня.
Александр Астапенко: То есть всего четыре человека, да?
Игнатий Колесниченко: Да, но сейчас остался я и один разработчик. То есть теперь у нас цель — сделать какой-то новый кусочек сервиса, доделать что-то. Он готов, работает, не падает, но так как у нас нет денег, мы не можем прямо сейчас это существенно куда-то развивать, переделывать.
Александр Астапенко: Ты, получается, официальный CTO в команде, компании?
Игнатий Колесниченко: Официально у меня такой роли, может быть, и нет. Как я говорил, CTO мы нашли в июне и до тех пор, пока у нас не закончились деньги, он, собственно, и руководил всей back-end разработкой.
Александр Астапенко: А теперь эту должность дали тебе?
Игнатий Колесниченко: Да. Бету я уже запускал более-менее сам, все доделки тоже делал сам. Формально я, может, не являюсь CTO, но по факту исполняю его функции.
Александр Астапенко: А как ты себе представляешь CTO в вашей компании? Какую роль он должен играть в проекте такого типа?
Игнатий Колесниченко: Обязанность СТО — думать про архитектуру, про будущее системы. От него требуется хорошее понимание того, как устроен back-end, как это все запускается на MapReduce — какие там есть проблемы, сложности. Нашему СТО должно быть интересно разбираться в биотехнологии, алгоритмах. Ему также необходимо руководить этими исследованиями, в какой-то степени. СТО должен обязательно понимать, как это все работает на Амазоне, управлять разработкой back-end и front-end.
Павел Павлов: Получается, что в твоем понимании СТО сфокусирован на технических моментах, над которыми работает команда и проект, но должен ли он выходить за пределы компании и видеть, что происходит вокруг, как-то ориентироваться в индустрии?
Игнатий Колесниченко: Должен, конечно, должен. Но тут нужно понимать, что тяжело чисто технически, по времени даже тяжело, все это в себе объять. Тут есть разные варианты, насколько мне видится, должно быть 2 или 3 человека, которые вместе общаются и каждый имеет свою зону ответственности. По моему мнению, зона ответственности СТО — разработка, безусловно, архитектура системы, понимание того, как она работает, куда она будет двигаться, какие есть технические трудности. Также он, естественно, должен смотреть на мир вокруг, но это все-таки не главная его обязанность.
Павел Павлов: Существует же такое понятие, как архитектор, ведущий разработчик, тим-лид и т.д. И в тоже время есть СТО, то есть не пересекаются ли у тебя как-то эти понятия, нет ли подмены?
Игнатий Колесниченко: Наверное, есть. Многое зависит еще и от масштаба компании. Пока компания маленькая (меньше 10 человек) и рук не хватает, то, в моем понимании, СТО должен даже программировать что-то, какие-то сложные вещи. Как минимум, он должен читать и ревьюить весь код.
Когда компания растет, естественно, происходит расслоение, СТО перестает читать код и начинает скорее думать об архитектуре, продукте и его техническом развитии. Появляются тим-лиды, старшие разработчики, которые берут прежние обязанности СТО на себя.
Точно так же и в научной области, которая начинает распределяться на группы. Вырастает в компании большая группа, которая занимается продажами. Просто тут необходимо масштабирование и в текущем состоянии нужен СТО, который умеет все по чуть-чуть.
О КОНКУРЕНТАХ Александр Астапенко: Есть ли конкуренты? В России? Мировые конкуренты?
Игнатий Колесниченко: Конкуренты есть, один из основных конкурентов — это, наверное, десктопная программа CLCBio, которой уже лет 8. Она, в принципе, те же самые задачи решает. Какие у нее есть недостатки? Во-первых, анализ делается достаточно долго, проанализировать полный геном человека у нее занимает 12 часов. А второй недостаток — она достаточно сложная и решает миллион задач сразу и разных, поэтому биологи тратят много времени, чтобы просто научиться с ней работать. Но в остальном, конечно, всю нужную информацию она умеет выдавать. Одна из самых богатых фирм в этой области на сегодняшний день.
Александр Астапенко: А какие-то сервисные модели?
Игнатий Колесниченко: Есть и сервисные модели. Как я уже говорил, разные компании строят облачные платформы для биоинформатических вычислений. У подобного рода сервисов проблема в том, что они совершенно не заточены под биоинформатику, под ученых, врачей. У них нет цели исследовать именно наследственные заболевания человека. Их цель — покрыть сегмент от серых данных до мутаций. Дальше они, чаще всего, не идут.
Есть еще конкуренты, которые делают то же, что и мы, но скорее в ручном режиме. Клиент получил мутации, послал их компании, которая, скажем, неделю--две анализирует эти данные и присылает отчет с подробным описанием мутаций, оценкой их значения. Такие компании покрывают вторую область: как из мутации понять ее связь с наследственными заболеваниями. Тут нам еще очень далеко можно развиваться. И у меня нет полной уверенности, что мы можем автоматически повторить все, что они делают руками, но мы будем к этому стремиться, естественно.
Александр Астапенко: А компании-секвенаторы?
Игнатий Колесниченко: Они тоже думают на тему облачных платформ, что-то строят, но в каком виде — не очень понятно.
Александр Астапенко: Предположим, что iBinom удается получить серьезные инвестиции и на тебя падает роль определить технологически будущее компании. Можешь как-то обрисовать, куда ты должен двигаться с iBinom?
Игнатий Колесниченко: У нас есть большое новое направление — анализ транскриптомов и решение задачи определения типа рака. Существуют сотни или даже тысячи разных типов раковых опухолей, для которых нужно применять разные лекарства. И это очень сложная именно научная задача, то есть люди ее умеют решать в каких-то конкретных случаях, но с точки зрения алгоритмов уже все сложнее.
Первый этап такой же: нужно взять данные, их просеквенировать и получить мутации, а затем углубляться в область того, на что эти мутации влияют. То есть тут понадобится мое взаимодействие с биологом. Мне, на самом деле, очень интересно работать именно с ученым, который на каких-то уже имеющихся инструментах может что-то подобное проделать. А моя задача — разобраться как он это делает, как инструменты работают и собрать из них нечто единое и работающее.
Александр Астапенко: А что для потребителя? Как планируете развиваться?
Игнатий Колесниченко: У нас есть идея переделать web-интерфейс, сделать его более удобным. Но это такая техническая задача, то есть в ней нет интересных вызовов с точки зрения инфраструктуры и программирования.
Была идея сделать так, чтобы не было разрыва, когда пользователь заливает данные, а потом анализирует. И так как мы делаем, по сути, один анализ, можно было бы во время заливки сразу все это дело анализировать. Нетривиальная задача на будущее.
