Понимание проблемы

Биоинформатика - одна из самых интересных и сложных областей работы по масштабированию решений машинного обучения для больших данных. Эти проблемы включают не только размер и масштаб геномных данных (3 миллиарда букв ДНК на человека). Они также включают в себя потенциал для улучшения петель обратной связи для важных исследований в области здоровья человека, таких как понимание значимых вариантов в геномных данных для потенциальных исследований CRISPR-Cas9. Это исследование может иметь огромное влияние на такие заболевания, как рак.

VariantSpark - это специализированная библиотека машинного обучения для геномных данных, построенная на ядре Apache Spark в Scala. VariantSpark реализует широкий алгоритм RandomForest ML, который включает настраиваемые разбиения, что позволяет анализировать входные данные, которые могут включать до 100 миллионов функций. Команда (во главе с доктором Денисом Бауэром) из CSIRO Bioinformatics в Сиднее, Австралия, создала этот алгоритм. В этой статье более подробно рассказывается о происхождении VariantSpark.

Когда я присоединился к этому проекту в качестве удаленного консультанта по облаку, команда CSIRO хотела узнать, как лучше всего использовать общедоступное облако для масштабирования выполнения заданий VariantSpark. Цели проекта:

  • Скорость - для выполнения одного задания в текущем общем локальном кластере Hadoop / Spark необходимо дождаться доступности кластера. Кроме того, даже после того, как кластер станет доступен, выполнение одного задания анализа VariantSpark может занять до 500 вычислительных часов.
  • Предсказуемость - стоимость (для облачных сервисов) и скорость (время выполнения задания).
  • Простота - многие исследовательские группы в области биоинформатики состоят из одного или меньшего числа членов команды DevOps, поэтому необходима простая настройка, мониторинг и обслуживание.
  • Воспроизводимость - использование инструментов для записи конфигурации сервиса AWS в виде кода, чтобы можно было проверить и воспроизвести результаты исследования, также имеет решающее значение для этой области.

В этой серии блогов, состоящей из нескольких частей, я подробно расскажу о нашей работе по масштабированию заданий VariantSpark с помощью облака AWS. В этом первом посте я подробно расскажу обо всех действиях, которые мы предприняли для подготовки ДО, мы начали работу по масштабированию.

Цель 1: понять текущее состояние и цели проекта

Как и любой технический проект, мы начали с обзора существующей реализации. В настоящее время команда CSIRO использует общий управляемый локально кластер Hadoop / Spark. Когда они хотят выполнить анализ VariantSpark, они отправляют запрос на работу во внутреннюю ИТ-группу и ждут доступности в общем кластере. После того, как их работа намечена, они ждут результатов. Хотя размеры вводимых данных действительно различаются, для большого анализа фактическое время выполнения задания может составлять несколько сотен часов.

Общие сведения о входных данных

Выходные данные геномного секвенсора представлены для дальнейшей оценки в различных форматах данных. VariantSpark предназначен для работы со следующими типами данных: .csv, .txt, .vcf, .bgz, .bz2 и parquet. Размеры входных данных могут широко варьироваться для аналитических заданий, в настоящее время «типичные» размеры входных данных варьируются от 1 ГБ до 5 ТБ. VariantSpark использует два типа файлов - входной файл (файл большого размера для рабочей нагрузки) и файл функций (или метки). Ниже показана часть входного файла.

Есть также другие характеристики данных для рассмотрения. К ним относятся схема разделения (для данных паркета) и размер задания в памяти. Apache Spark работает наиболее эффективно, когда все входные данные могут поместиться в исполнители в памяти на каждой рабочей машине в кластере. Чтобы упростить тестирование, команда CSIRO создала набор образцов входных данных (которые мы называем «синтетическими данными»), чтобы отразить различные типы и размеры аналитических заданий.

Типы заданий - # строки (образцы) * # характеристики (столбцы) - ›общий размер данных

  1. Tiny - демонстрация - 2,5 тыс. образцов * 17 тыс. функций → 1 ГБ
  2. Маленький - частичный GWAS - 5 тыс. образцов * 2,5 млн функций → 5 ГБ
  3. Огромный 1 - большие образцы GWAS1–10 тыс. * 50 млн функций → 217 ГБ
  4. Огромный 2 - большие образцы GWAS2–5k * 100M функций → 221 ГБ

Почему так много функций? Геном человека насчитывает 3 миллиарда точек данных.

Общие сведения о вычислительных ресурсах

Вычислительная мощность, доступная команде (локальный общий кластер Hadoop / Spark), состоит из следующих характеристик:

  • 12 серверов, каждый с 16 процессорами и 96 ГБ ОЗУ
  • При тестировании самых крупных заданий VariantSpark для кэширования всех данных заданий потребовалось 10 из 12 доступных серверов. Этот размер кластера составляет 160 процессоров и ~ 1 ТБ ОЗУ. Spark также настроен на использование «исполнителей всего узла».

Проверка библиотеки OSS

Мы проверили состояние библиотеки VariantSpark OSS на GitHub и вместе с командой выполнили следующие подготовительные действия:

  • Создал код и провел все тесты. Использовал инструменты покрытия кода IDE для оценки областей кодовой базы, которые были охвачены модульными тестами, с акцентом на области алгоритмов машинного обучения.
  • Отредактированный код, в основном с использованием безопасного переименования, чтобы устранить необходимость в большинстве комментариев к коду. Удалены закомментированные блоки кода.
  • Добавлен ScalaDocs в ключевые разделы кода, посвященные машинному обучению.
  • Создайте список задач на GitHub для следующих рабочих шагов
  • Отправил скомпилированный файл VariantSpark.jar в публичный репозиторий Maven

Наше сообщество также создало Python API (оболочку) для удобства использования! Код ключа показан ниже.

Цель 2: выбор облачных сервисов

Команда CSIRO занимается разработкой ряда исследовательских инструментов в общедоступном облаке, включая такие приложения, как GT-Scan-2 на AWS. Они также хотели поработать, чтобы рассмотреть доступные варианты масштабирования заданий VariantSpark в общедоступном облаке.

Как и в случае с другой клиентской работой, первым уровнем рассмотрения был тип вычислительных ресурсов, которые мы хотели протестировать. Ниже представлен список рассмотренных нами сервисов AWS, сгруппированных по типам.

Одним из ключевых ограничений является то, что на момент начала работы в команде CSIRO Bioinformatics не было ни одного преданного профессионала DevOps. По этой причине мы решили начать НЕ с разработки решения для масштабирования, а сначала создать решение, главной целью которого является проведение быстрых демонстраций для широкого круга публики - как специалистов по биоинформатике, так и технических специалистов.

Цель 3: создание выборки

Как указывалось ранее, целью этого этапа работы было создание образца. Этот образец должен сделать использование VariantSpark в облаке быстрым, простым, бесплатным и увлекательным для «клиентов». Из соображений конфиденциальности мы включили реалистичные (а не реальные) данные, и команда создала поддельный фенотип - хипстеризм.

Мы также создали образец ноутбука Jupyter для этого синтетического недуга. Записная книжка Jupyter, а не сценарий bash, использовалась, чтобы новые пользователи могли легче понять, как работает VariantSpark. В биоинформатике записные книжки Jupyter становятся все более распространенными, поскольку они улучшают воспроизводимость исследований, поскольку содержат не только исполняемый код, но также визуализацию данных и текст разметки. Этот текст помогает документировать эксперименты и работы.

Использование SaaS для получения отзывов клиентов

Для этой части работы я рекомендовал использовать облачное решение SaaS (Spark как услуга) из-за простоты настройки и использования. Мы построили наш образец с помощью Databricks на AWS. Использование бесплатного кластера Databricks сообщества и примера записной книжки HipsterIndex Databricks позволяет новому пользователю выполнить свое первое задание с минимальными действиями по настройке.

Версия сообщества Databricks AWS включает 1 час бесплатного использования управляемых вычислений кластера Spark с одноузловой кластер. Узнай о нашей работе - ссылка. Вот презентация, которая включает демонстрацию экрана, показывающую, как запустить пример (демонстрация начинается в 18:00).

Кроме того, наша работа над этим образцом стала частью официальной документации Databricks, как пример приложения для геномики, построенного на Apache Spark.

Цель 4: выбор услуг для масштабирования

После успешного построения нашего образца пришло время приступить к масштабированию заданий VariantSpark. Сначала нам нужно было определить, какие сервисы AWS использовать для масштабного тестирования заданий VariantSpark. Мы должны рассмотреть возможность изучения сервисов AWS для вычислений и данных, которые лучше всего подходят для тестирования, масштабирования и проверки производительности.

Сначала мы отказались от лямбда-выражений, потому что мы работаем с алгоритмом машинного обучения с отслеживанием состояния, а лямбда-выражения не имеют состояния. Тогда мы могли бы рассмотреть следующее:

  • Неуправляемые виртуальные машины - EC2
  • Управляемые виртуальные машины - EMR
  • Неуправляемые контейнеры - ECS или EKS
  • Управляемые контейнеры - Fargate или Sagemaker

Мы снова попытались уменьшить размер этого списка, удалив некоторые параметры. Мы удалили EC2 из-за отсутствия членов команды DevOps в большинстве групп биоинформатики. Объем административных накладных расходов на настройку и обслуживание кластера Hadoop / Spark на EC2 не соответствовал размеру команды в CSIRO.

Мы удалили Fargate, потому что предпочитали использовать Kubernetes, а не ECS для управления контейнерами. На момент написания этой статьи Fargate еще не поддерживает EKS. Мы считаем, что Kubernetes стал стандартом для управления контейнерами в общедоступном облаке в целом, и мы выступаем за гибкость в нашей реализации.

Таким образом, AWS EMR, EKS и Sagemaker стали основой для начала нашей работы по масштабированию.

Цель 5: подготовка к масштабному тестированию

Теперь, когда мы проделали значительный объем подготовительной работы, нам осталось выполнить еще несколько шагов, чтобы можно было начать наши тесты масштабирования. Нам нужно было спроектировать и построить тестовые системы. Это включало в себя работу с командой над созданием образцов данных и нескольких образцов сценариев. Для удобства мы запускаем эти сценарии из записных книжек Jupyter, чтобы мы могли добавлять документацию об условиях выполнения тестирования прямо в записную книжку. Также нам нужно было проверить учетную запись AWS, регион AWS, пользователей IAM и установить лимиты сервисов AWS (платежные оповещения) для использования в нашей работе.

Кроме того, мы решили попробовать использовать как AWS CloudFormation, так и Terraform, чтобы мы могли выбрать лучший процесс автоматизации для этой работы и для постоянного перехода к использованию облачных сервисов командой.

Наконец, мы работали с группой в Сиднее над созданием и запуском пары примеров контейнеров Docker локально. Мы сделали это, потому что использование контейнеров для выполнения вычислений было для них внове. Мы оба создали контейнеры для образцов (например, этот, который включает в себя общий инструмент биоинформатики blastn, данные образцов и пример из прилагаемого блокнота Jupyter), а также использовали реестр биоконтейнеров. Мы попросили команду использовать инструменты рабочего стола Docker для локального запуска этих контейнеров.

Теперь, когда мы закончили эту подготовительную работу, мы были готовы начать работу по масштабированию. В следующем сообщении блога я подробно расскажу, как продвигается наша работа по масштабированию VariantSpark на AWS.