"YT — новая платформа распределённых вычислений". Максим Бабенко, Яндекс.
4 likes5,481 views
Документ описывает создание и архитектуру новой платформы распределенных вычислений yt, начиная с истоков разработки и основных технологических решений, таких как MapReduce и Apache Hadoop. Основное внимание уделяется архитектурным ограничениям предыдущих систем, таких как Yamr, и количеству улучшений, внедренных в yt, включая новый подход к репликации и управлению данными. Платформа предлагает масштабируемое и гибкое решение для обработки больших данных с акцентом на высокую доступность и производительность.
"YT — новая платформа распределённых вычислений". Максим Бабенко, Яндекс.
- 2. YT – новая платформа распределенных вычислений Максим Бабенко
- 4. Хронология событий 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
- 5. Ограничения YAMR Мастер-сервер (хранящий метаданные) является единственной точкой отказа Шедулер совмещен с мастером, ограниченные возможности по масштабированию Нет разделения между слоями хранения данных и их обработки Слабая поддержка метаданных и возможностей интроспекции состояния системы 5
- 6. Ограничения YAMR Негибкая система распределения ресурсов в шедулере (слоты с фиксированным объемом памяти) Неясные перспективы масштабирования на большие кластера и множество ДЦ Большой объем унаследованного кода, масса неудачных архитектурных решений – однако и большое количество клиентов ...и многое другое 6
- 7. Дизайн и архитектура Взгляд сверху
- 8. Что такое YT? Распределенное хранилище – Метаданные (Кипарис) – “Большие данные” (хранилище чанков) Среда вычислений – Базовые примитивы MapReduce – Дополнительные табличные операции (sort, join и др.) Примитивы для построения светлого будущего – Гидра 8
- 10. Структура кластера YT Мастеры – Поддерживают в памяти метаинформацию о системе (чанки, транзакции, Кипарис и пр.) – Синхронно реплицированы, способны работать пока есть кворум – Автоматический горячий failover (~10 сек) – Координируют процессы репликации, балансировки и восстановления данных на нодах 10
- 11. Структура кластера YT Прокси – Точка входа для внешних пользователей – Предоставляют HTTP API – Легкие (для управляющих команд) – Тяжелые (для потоков данных) – Выполняют аутентификацию – Stateless – Автоматическая балансировка нагрузки и failover 11
- 12. Структура кластера YT Шедулеры – Планируют и запускают операции на данных (map, reduce, sort, join etc) – Реплицированы, периодически сохраняют снепшоты состояния – Автоматический failover (~1 минуты) Ноды – Хранят чанки с данными – Выполняют элементарные шаги вычисления 12
- 14. Репликация состояния Paxos – Придуман Лесли Лэмпортом в 90-х годах прошлого века – MultiPaxos для задачи репликации лога – Используется в Chubby – Длинный путь от теории до работающего продакшен-решения 14
- 15. “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)
- 16. Репликация состояния Альтернатива: atomic broadcast – “Гидра” – Существенно более простая интуиция – Используется в Zookeeper – Формальное обоснование: Raft 16
- 17. Гидра Набор мастеров нечетного размера 2k+1 Кворум: строгое большинство, как минимум k+1 мастеров – Любые два кворума имеют непустое пересечение В стационарном положении ровно один из мастеров является лидером, остальные фолловерами – Определение лидера и фолловеров производится с помощью протокола голосования 17
- 18. Гидра Все мутации проходят через лидера – Вначале мутация записывается в логи на кворуме мастеров – Затем мутация применяется к состоянию в памяти Чтение возможно с фолловеров Восстановление производится путем воспроизведения логов Периодические снепшоты – Ускоряют восстановление – Экономят место на диске, занимаемое логами 18
- 19. Гидра Эффективное решение – ~100 000 мутаций в секунду – Объем состояния ограничен RAM (~100 GB) Автоматическое восстановление при сбоях (диски, сеть, машины целиком) – Горячий failover (~10 сек) Периодическая кросс-валидация состояний мастеров – Логи и снепшоты снабжены контрольными суммами Минорные апдейты серверов без даунтайма 19
- 20. Гидра Универсальный и переиспользуемый компонент Подходит для репликации любого конечного автомата Простой интерфейс состояния: – ApplyMutation – SaveSnapshot – LoadSnapshot Мутации должны быть детерминированными! – Общий источник случайности на всех репликах Полностью автоматические репликация и восстановление 20
- 21. Кипарис Единое дерево объектов – пространство имен Узлы имеют атрибуты – как системные, так и пользовательские 21
- 22. Кипарис Может использоваться как распределенная файловая система – вместо файлов данные обычно хранятся в таблицах $ yt create directory //home/vasya 1-2-3-4 $ yt upload //home/vasya/some_file < file 5-6-7-8 $ yt list //home/vasya some_file $ yt get //home/vasya/some_file/@size 1024 22
- 23. Кипарис Интроспекция состояния кластера – Большинство параметров системы представлены виртуальными узлами – Аналог procfs $ yt get //home/vasya/file/@chunk_ids 1-2-3-4 $ yt get //sys/chunks/1-2-3-4/@size 1024 $ yt get //sys/chunks/1-2-3-4/@stored_replicas node0400.somecluster.net node0401.somecluster.net node0402.somecluster.net 23
- 24. Кипарис Поддерживает транзакции (в том числе вложенные) Поддерживает блокировки на узлах Используется как сервис координации (Chubby, Zookeeper) $ yt start_tx 1-2-3-4 $ yt upload --tx 1-2-3-4 //work/f1 < file1 5-6-7-8 $ yt set --tx 1-2-3-4 //work/@latest_file “f1” $ yt commit_tx 1-2-3-4 24
- 25. Дизайн и архитектура “Большие данные”
- 26. Чанки Иммутабельные блобы – Желаемый размер 100Mb-1Gb Хранятся на нодах – Сотни тысяч чанков на одной ноде Базовый строительный блок для файлов и таблиц 26
- 27. Репликация и 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
- 28. Репликация и erasure coding Почему бы всегда не использовать RS вместо репликации? Восстановление может быть дорогим – Репликация требует одного чтения при восстановлении – RS(n, k) требует n чтений Пример – 3-кратная репликация: оверхед 200%, 1 чтение – RS(6,3): оверхед 50%, 6 чтений 28
- 29. Репликация и erasure coding 29 Нужен компромисс – Коды с локальным восстановлением (LRC) LRC(12,2,2) – оверхед 33% – выдерживает выпадение 3 нод – <7 чтений в среднем
- 30. Планы на будущее
- 31. Масштабнее Шардирование метаинформации (Кипариса) Шардирование шедулера Междатацентровые инсталляции – Дополнительный координирующий слой (поверх Гидры) – Синхронная и асинхронная репликация данных между ДЦ Слой совместимости с Hadoop 31
- 32. Интерактивнее Таблицы с быстрым доступом по ключу – Статические данные в виде табличных чанков – In-memory дельты с репликацией состояния Табличные транзакции на основе timestamps – MVCC SQL-подобный язык запросов Потоковые модели вычислений (Storm, MillWheel) 32
- 34. 34 Максим Бабенко руководитель группы разработки YT к.ф.-м.н. +7(916)7807914 [email protected] © ООО «Яндекс», 2013