YT – новая платформа распределенных вычислений

Максим Бабенко

История вопроса

Хронология событий

2004 – Статья Google про модель MapReduce и ее реализацию

– Mapreduce: Simplified data processing on large clusters (Jeffrey Dean, Sanjay Ghemawat)

2006 – Прототип модели MapReduce в Яндексе (YAMR)

2007 – Публичный релиз Apache Hadoop

– 4 September, 2007: release 0.14.1 available

2011 – Начало работ над YT

4

Ограничения YAMR

Мастер-сервер (хранящий метаданные) является единственной точкой отказа

Шедулер совмещен с мастером, ограниченные возможности по масштабированию

Нет разделения между слоями хранения данных и их обработки

Слабая поддержка метаданных и возможностей интроспекции состояния системы

5

Ограничения YAMR

Негибкая система распределения ресурсов в шедулере (слоты с фиксированным объемом памяти)

Неясные перспективы масштабирования на большие кластера и множество ДЦ

Большой объем унаследованного кода, масса неудачных архитектурных решений

– однако и большое количество клиентов

...и многое другое

6

Дизайн и архитектура

Взгляд сверху

Что такое YT?

Распределенное хранилище

– Метаданные (Кипарис)

– “Большие данные” (хранилище чанков)

Среда вычислений

– Базовые примитивы MapReduce

– Дополнительные табличные операции (sort, join и др.)

Примитивы для построения светлого будущего

– Гидра

8

Структура кластера YT

9

Структура кластера YT

Мастеры

– Поддерживают в памяти метаинформацию о системе (чанки, транзакции, Кипарис и пр.)

– Синхронно реплицированы, способны работать пока есть кворум

– Автоматический горячий failover (~10 сек)

– Координируют процессы репликации, балансировки и восстановления данных на нодах

10

Структура кластера YTПрокси

– Точка входа для внешних пользователей

– Предоставляют HTTP API

– Легкие (для управляющих команд)

– Тяжелые (для потоков данных)

– Выполняют аутентификацию

– Stateless

– Автоматическая балансировка нагрузки и failover11

Структура кластера YT

Шедулеры

– Планируют и запускают операции на данных (map, reduce, sort, join etc)

– Реплицированы, периодически сохраняют снепшоты состояния

– Автоматический failover (~1 минуты)

Ноды

– Хранят чанки с данными

– Выполняют элементарные шаги вычисления

12

Дизайн и архитектура

Метаданные

Репликация состояния

Paxos

– Придуман Лесли Лэмпортом в 90-х годах прошлого века

– MultiPaxos для задачи репликации лога

– Используется в Chubby

– Длинный путь от теории до работающего продакшен-решения

14

“There are significant gaps between the description of the Paxos algorithm and the needs of a real-world system. In order to build a real-world system, an expert needs to use numerous ideas scattered in the literature and make several relatively small protocol extensions. The cumulative effort will be substantial and the final system will be based on an unproven protocol.”

15

Paxos Made Live, An Engineering Perspective (Chandra, Griesemer, Redstone)

Репликация состояния

Альтернатива: atomic broadcast

– “Гидра”

– Существенно более простая интуиция

– Используется в Zookeeper

– Формальное обоснование: Raft

16

Гидра

Набор мастеров нечетного размера 2k+1

Кворум: строгое большинство, как минимум k+1 мастеров

– Любые два кворума имеют непустое пересечениеВ стационарном положении ровно один из мастеров является лидером, остальные фолловерами

– Определение лидера и фолловеров производится с помощью протокола голосования

17

Гидра

Все мутации проходят через лидера

– Вначале мутация записывается в логи на кворуме мастеров– Затем мутация применяется к состоянию в памяти

Чтение возможно с фолловеров

Восстановление производится путем воспроизведения логов

Периодические снепшоты

– Ускоряют восстановление– Экономят место на диске, занимаемое логами

18

Гидра

Эффективное решение– ~100 000 мутаций в секунду

– Объем состояния ограничен RAM (~100 GB)

Автоматическое восстановление при сбоях (диски, сеть, машины целиком)

– Горячий failover (~10 сек)

Периодическая кросс-валидация состояний мастеров

– Логи и снепшоты снабжены контрольными суммами

Минорные апдейты серверов без даунтайма

19

ГидраУниверсальный и переиспользуемый компонент

Подходит для репликации любого конечного автомата

Простой интерфейс состояния:

– ApplyMutation– SaveSnapshot– LoadSnapshot

Мутации должны быть детерминированными!

– Общий источник случайности на всех репликах

Полностью автоматические репликация и восстановление20

Кипарис

Единое дерево объектов

– пространство имен

Узлы имеют атрибуты

– как системные, так и пользовательские

21

Кипарис

Может использоваться как распределенная файловая система

– вместо файлов данные обычно хранятся в таблицах

$ yt create directory //home/vasya1-2-3-4

$ yt upload //home/vasya/some_file < file5-6-7-8

$ yt list //home/vasyasome_file

$ yt get //home/vasya/some_file/@size1024

22

Кипарис

Интроспекция состояния кластера

– Большинство параметров системы представлены виртуальными узлами

– Аналог procfs

$ yt get //home/vasya/file/@chunk_ids1-2-3-4

$ yt get //sys/chunks/1-2-3-4/@size1024

$ yt get //sys/chunks/1-2-3-4/@stored_replicasnode0400.somecluster.netnode0401.somecluster.netnode0402.somecluster.net

23

Кипарис

Поддерживает транзакции (в том числе вложенные)

Поддерживает блокировки на узлах

Используется как сервис координации (Chubby, Zookeeper)

$ yt start_tx1-2-3-4

$ yt upload --tx 1-2-3-4 //work/f1 < file15-6-7-8

$ yt set --tx 1-2-3-4 //work/@latest_file “f1”

$ yt commit_tx 1-2-3-4

24

Дизайн и архитектура

“Большие данные”

Чанки

Иммутабельные блобы

– Желаемый размер 100Mb-1Gb

Хранятся на нодах

– Сотни тысяч чанков на одной ноде

Базовый строительный блок для файлов и таблиц

26

Репликация и erasure codingНоды кластера выпадают

– ~10 замен дисков на кластере размера ~1000 в неделю

Репликация: k реплик, оверхед k-1, выдерживает выпадение k-1 нод

Коды Коши-Рида-Соломона RS(n, k): оверхед k/n, выдерживает выпадение k нод

Сравнительный пример

– 3-кратная репликация: оверхед 200%

– RS(6, 3): оверхед 50%

– Доступность RS(6,3) не хуже тройной репликации27

Репликация и erasure coding

Почему бы всегда не использовать RS вместо репликации?

Восстановление может быть дорогим

– Репликация требует одного чтения при восстановлении

– RS(n, k) требует n чтений

Пример

– 3-кратная репликация: оверхед 200%, 1 чтение

– RS(6,3): оверхед 50%, 6 чтений

28

Репликация и erasure coding

29

Нужен компромисс

– Коды с локальным восстановлением (LRC)

LRC(12,2,2)

– оверхед 33%

– выдерживает выпадение 3 нод

– <7 чтений в среднем

Планы на будущее

Масштабнее

Шардирование метаинформации (Кипариса)

Шардирование шедулера

Междатацентровые инсталляции

– Дополнительный координирующий слой (поверх Гидры)

– Синхронная и асинхронная репликация данных между ДЦ

Слой совместимости с Hadoop

31

Интерактивнее

Таблицы с быстрым доступом по ключу

– Статические данные в виде табличных чанков

– In-memory дельты с репликацией состояния

Табличные транзакции на основе timestamps

– MVCC

SQL-подобный язык запросов

Потоковые модели вычислений (Storm, MillWheel)

32

Спасибо за внимание!

34

Максим Бабенкоруководитель группы разработки YTк.ф.-м.н.

+7(916)7807914

babenko@yandex-team.ru

© !!! «"#$%&'», 2013