Масштабирование VariantSpark

Это вторая часть серии, состоящей из нескольких частей, в которой подробно описана работа с командой CSIRO Bioinformatics над масштабированием их пользовательской библиотеки машинного обучения VariantSpark в облаке AWS.

VariantSpark построен на Scala на ядре Apache Spark. VariantSpark реализует настраиваемый алгоритм машинного обучения (RandomForest), который включает разбиение чрезвычайно широких входных данных для анализа. Хотя он был создан для использования с геномными данными, Variant Spark также можно использовать с другими типами широких входных данных. Эти входные данные могут включать до 100 миллионов функций. Вы можете прочитать первую часть этой серии блогов, если вы новичок в VariantSpark.

На этом этапе проекта мы решили протестировать ряд сервисов AWS на пригодность для масштабирования заданий VariantSpark. Эти службы предоставляют вычислительные ресурсы одним из двух способов - путем предоставления и управления виртуальными машинами или контейнерами докеров. Рассмотренные нами сервисы AWS перечислены ниже:

  • EMR (Elastic Map Reduce) - сервис AWS для управляемых вычислительных кластеров Hadoop / Spark, работающих на управляемых виртуальных машинах EC2.
  • EKS (Elastic Kubernetes Service) - сервис AWS для оркестровки контейнеров докеров с помощью Kubernetes, работающий на управляемых виртуальных машинах EC2.
  • Sagemaker - сервис AWS для управляемых контейнеров докеров для машинного обучения, опять же, работающий на управляемых кластерах экземпляров EC2.

Цель 1. Выберите один - виртуальные машины или контейнеры

Мы решили начать с работы с виртуальными машинами, а не с контейнерами. Для этого мы выбрали AWS EMR или Elastic Map Reduce, поскольку он обеспечивает управляемую среду Hadoop / Spark в кластере инстансов EC2.

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

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

В качестве подготовительного шага группа выполнила самую большую рабочую нагрузку («Огромная 2» - см. ниже) в локальном кластере Hadoop / Spark, чтобы у нас был текущий базовый уровень для сравнения. Мы использовали jar-файл VariantSpark 2.x, который был скомпилирован для Apache Spark 2.2 на этом этапе нашего тестирования.

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

Понимание примера входных данных

Геномные данные представлены в нескольких различных типах данных. VariantSpark предназначен для работы с различными из них - с поддержкой .csv, .vcf, .bz2 или parquet. Мы использовали наиболее оптимизированный тип (паркет) для наших тестов на масштабирование. Несмотря на то, что мы тестировали множество наборов данных, в этом сообщении блога мы сосредоточимся на двух крупнейших синтетических наборах данных (показанных ниже Huge1 и Huge2). Для каждого запуска задания используются файлы двух типов - файл ввода и файл меток. Также наши входные паркетные файлы разбиты на файлы размером ~ 1 ГБ каждый.

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

  1. Огромный 1 - большие образцы GWAS1–5k * 100M функций → 217 ГБ
  2. Huge 2 - большие образцы GWAS2–10k * 50M функций → 221 ГБ

Цель 2: настроить EMR для тестирования

Для начала мы разработали основной набор инструкций по настройке кластера для VariantSpark-on-EMR. Вот инструкция - ссылка. Обратите внимание, что VariantSpark включает клиентский инструмент vs-emr, который дополняет интерфейс AWS для воспроизводимой установки по сценарию.

Ниже показана схема архитектуры VS-EMR. Обратите внимание, что ключевыми компонентами нашей установки являются сам кластер EMR, а также несколько сегментов S3. Сегменты S3 содержат как источник (данные для анализа), так и файлы конфигурации кластера (файлы загрузчика и т. Д.).

Также мы включили сервис Jupyter notebook, потому что мы считаем, что использование записных книжек предпочтительнее использования командной строки для наших экспериментов по масштабированию.

Следует отметить, что мы попытались использовать AWS CloudFormation для автоматизации тестовых запусков кластеров EMR. В конечном итоге мы решили не продолжать использовать CloudFormation, поскольку на данном этапе тестирования это не принесло нам пользы.

Цель 3: конфигурация плана и параметры

Затем мы работали над тем, чтобы сделать масштабное тестирование VS-EMR быстрым и простым. Мы подготовили образцы данных и сценарии начальной загрузки. Однако нам также пришлось поработать над серьезной проблемой - определением тестовой конфигурации (ов).

Для VS-EMR существует ПЯТЬ категорий настроек конфигурации.

Для начала мы сравнили потенциальные наборы конфигураций с заданиями, выполняемыми из локального кластера. Чтобы понять сложность этого этапа нашей работы, мы показали несколько примеров экранов конфигурации ниже. Для начала ниже приведен пример конфигурации кластера EMR, показанный как результат работы инструмента «aws cli»:

Далее приведен пример конфигурации Apache Spark кластера EMR:

Наконец, вот пример команды задания VariantSpark из spark-submit:

Общие сведения об этапах выполнения задания VS

Когда мы работали над созданием подходящих конфигураций тестирования, мы рассматривали рабочие шаги, связанные с запуском задания VariantSpark. VariantSpark обрабатывает входной файл и файл меток и выводит значимые геномные варианты. Для этого VariantSpark использует различные типы вычислительных процессов. Эти процессы требуют разного количества ЦП, ОЗУ и операций ввода-вывода.

Чтобы узнать о потребностях в ресурсах для этапов задания VariantSpark, мы использовали вывод консоли Spark (интегрированный в EMR). Анализ задания VariantSpark состоит из 4 основных этапов. Каждый из этих этапов выполняет действие, и для каждого требуются разные типы и количество ресурсов кластера. Этапы следующие:

  • Подготовка Spark Executors - выполняется за миллисекунды, требует минимальных ресурсов.
  • Zip with Index - подготавливает данные, запускается в течение нескольких минут при правильном размере кластера, требует соответствующих вычислений, операций ввода-вывода и памяти.
  • Подсчет при важности - загружает данные, запускается в течение 10 минут при правильном размере кластера, требует достаточного объема памяти исполнителя для размещения всех данных. ВАЖНО: если памяти кластера недостаточно, данные будут «перетекать» на диск, и этот процесс будет выполняться в 30–50 раз медленнее.
  • Выполнить деревья решений - анализ данных с использованием нескольких шагов для каждого дерева, переменное время выполнения (от минут до часов), зависит от (настроенного) количества деревьев, требует соответствующих вычислений и памяти. Количество деревьев решений влияет на качество результатов анализа. Для нашего первоначального тестирования мы начали с запуска очень небольшого количества деревьев (100), позже мы расширили наше тестирование, включив в него анализ, в результате которого было получено до 10 000 деревьев. Правильный учет потребностей в построении деревьев - ключевой аспект масштабирования VariantSpark.

Ниже показано задание VariantSpark, выполняющееся в консоли Spark. Вы можете увидеть четыре типа этапов задания в консоли Spark - Executors, Zip, Count и Decision Trees. Вы заметите, что большая часть времени обработки тратится на «построение дерева» (временные метки 13: 22–13: 32 ниже).

Цель 4: отслеживать эффективные размеры

Мы работали с рядом инструментов и интерфейсов, чтобы понять, какие ресурсы необходимы для каждой аналитической работы VariantSpark. Эти инструменты позволили нам «заглянуть» в выполнение заданий, чтобы понять, как настраивать и масштабировать ресурсы AWS EMR. Мы использовали следующие инструменты:

  • Консоль EMR - этапы работы и журналы
  • Ganglia Console - распределение и использование ресурсов живого кластера
  • Spark Console - текущие шаги задания, использование ресурсов исполнителя и журналы.

Слева и ниже показаны образцы выходных данных включенных инструментов мониторинга Ganglia для EMR.

Мы использовали эти инструменты, чтобы понять, правильно ли мы выбрали размер и настроили наш кластер EMR. На первом изображении показано распределение и использование нагрузки на сервер.

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

Во время тестирования мы попробовали несколько типов инстансов EC2. Мы получили наилучшие результаты со следующим:

  • Тип инстанса - R4 - причина: оптимизирован для "большого объема памяти"
  • Размер инстанса - r4.16xlarge - причины: конкурентоспособная цена на ядро ​​(64 ЦП) и большой объем оперативной памяти (400 ГБ)

На рисунках ниже показана производительность, измеренная за время построения 100 деревьев [левый график] или количество деревьев, построенных за час [правый график] для набора данных "HUGE1". . Цифры сравнивают количество ядер, необходимых как для локальных (синий-c16…), так и для кластеров AWS (зеленый-r4…)

«Графики выше показывают, что с увеличением количества используемых ядер мы получили 5-кратное увеличение количества деревьев, построенных за час, и аналогичное уменьшение времени создания дерева (для базового уровня в 100 деревьев)».

Успех! Подводя итог, мы обнаружили, что для больших наборов данных 5-кратное повышение производительности ( для AWS EMR по сравнению с локальным кластером) может быть достигнуто за счет эффективности построения ключевого дерева решений. этап анализа каждого задания VariantSpark.

Цель 5: минимизировать затраты на обслуживание

Теперь, когда мы смогли успешно запустить самую большую синтетическую рабочую нагрузку с помощью повторяемого процесса (клонирование кластера EMR) в разумные сроки, мы хотели понять, как лучше всего минимизировать затраты на сервисы AWS.

Конечно, истинное сравнение затрат включает БОЛЬШЕ, чем затраты на обслуживание. Вы можете вспомнить из первого сообщения в блоге этой серии, что одной из ключевых целей этого проекта было ускорение цикла обратной связи для анализа данных. Ниже приводится сравнение «истинной стоимости» VariantSpark, работающего в обеих средах.

Общие сведения о расценках на услуги EMR

Мы хотели понять, как лучше всего приобретать услуги EMR. Нам нужно было рассмотреть ряд факторов, в том числе количество, тип и размер экземпляров EMR EC2. Также нам нужно было оптимизировать ценообразование на EMR, выбрав наиболее подходящий тип для наших нужд. Мы рассматривали следующие варианты ценообразования:

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

На этом этапе нашей работы мы узнали, что использование спотовых и спотовых парков EMR привело к значительной экономии затрат. Мы также узнали, что ресурсы EC2 будут распределяться в зависимости от доступности. Мы заметили, что ресурсы, как правило, распределяются быстрее, когда мы запрашиваем экземпляры меньшего размера, например, r4.large против r4.4xlarge и т. Д.

СОВЕТ. Как уже упоминалось, мы обнаружили большую ценность, используя кнопку «CLONE» на консоли EMR. После того, как мы создали конфигурацию запуска задания кластера / Spark / VariantSpark, мы просто «клонировали» эти параметры, чтобы быстро запросить новый спотовый парк AWS EMR для выполнения еще одного теста. Кроме того, нам очень нравится гибкость использования консоли AWS для обновления любых значений параметров из клонированного набора ДО того, как мы запустили следующий экземпляр задания.

Примечание: эта работа была проведена с членами команды CSIRO Bioinformatics / Data61 доктором Денисом Бауэром, Арашем Баятом и Петром Сзулом.

Следующие шаги: тестирование контейнеров и автоматизация

Теперь, когда мы завершили успешное масштабирование VariantSpark в облаке AWS, нам не терпелось сравнить сервисы на основе контейнеров с тем, что мы создали на основе EMR.

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