Кирилл Алешин, Ламбда Архитектура на практике
DESCRIPTION
Кирилл расскажет о таких темах, как практичность современных распределенных файловых систем для складирования структурированных данных, сложности синхронизации данных на разных Ламбда уровнях, а также несколько Big Data новинок для закрытия брешей в традиционном описании Ламбда архитектуры. Кирилл расскажет как о пользе этой модели, так и об извлеченных уроках ее использования.TRANSCRIPT
HDCONFHDCONF
«Ламбда Архитектура на практике»
Кирилл Алешин
@kyrill007
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
План Доклада
• Ключевые идеи Ламбда архитектуры • Ламбда архитектура: За и Против • Практическая иллюстрация проблем ее реализации • Новые подходы • За чем же будущее? • Ответы на вопросы
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Ламбда Архитектура
• Изобретатель – Натан Марц (Твиттер)
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Почему Ламбда Архитектура?
Потому что требуется решение для высокоскоростной обработки неограниченного количества данных
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Почему Ламбда Архитектура?
Хочется, чтобы f(все данные) работала очень быстро.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Ламбда Архитектура: За
• Жесткий акцент на неизменяемости входящих данных.
• Возможность анализа на протяжении всего временного континуума (контраст: реляционные базы данных).
• Акцентировка на сохранении именно «сырых данных», что открывает возможность постоянного репроцессинга.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Ламбда Архитектура: За
Эти концепции – ключевые идеи будущих дата архитектур
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Ламбда Архитектура: Против
Огромная сложность и цена реализации
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Ламбда Архитектура: Против • Фактически предлагается двойная кодировка всей логики в
разнородных средах: batch processing и streaming processing.
• Дуалистичная природа этой архитектуры – большая проблема.
• Любая попытка прикрутить новый абстракционный уровень над этими подсистемами будет очень кастомизированным под каждое конкретное решение и будет требовать глубочайшего знания каждой из подсистем и самого фреймворка в целом (think $$$$$).
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Ламбда Архитектура: Против
Hadoop + Storm = Marriage made in hell
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Ламбда Архитектура: Против
Но проблемы начинаются гораздо раньше самой “женитьбы” Хадупа со Стормом.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень • Данные складируются прямо на файловой системе (HDFS) в
обыкновенных файлах в append-only mode.
• Да, именно предлагается база данных, состоящая из flat files.
• Однако, увы, складировать данные просто в однородные файлы чрезвычайно не эффективно даже для Хадупа.
• Чтоб такое работало более менее быстро, наверное, не хватило денег на железо даже у Твиттера.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень
Добро пожаловать Shredding Process.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень • Входящие данные и в самом деле сладируются в однородные
файлы, но они уже попадают в Master Data Set через т.н. «Процесс Измельчения».
• Процесс осуществляется через многошаговый Map-Reduce.
• Но, увы, «измельчение данных» на файловой системе приводит к огромному количеству новых файлов, а Хадуп этого не любит.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень
Добро пожаловать Consolidation Process.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень • Таким образом «измельченные данные» в маленьких файлах
абсорбируются в уже существующие (большие) файлы в Master Data Set (мастер сет) на HDFS через отдельный Map-Reduce.
• Кто-нибудь видит здесь проблему?
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень • Да, именно, мы мутируем мастер данные, которые в этот момент
могут читаться бегущими мап-редьюс работами...
• Это, конечно, не хорошо.
• Значит нужно писать собственный job scheduler, который бы давал экслюзивный статус нашему «консолидатору».
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень • Это, к сожалению, только цветочки.
• В чем одна из ключевых проблем складировки данных в плоских файлах?
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень
В невозможности легкой коррекции данных
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень • Плохие данные обязательно попадут в мастер сет и тем или
иным образом они должны быть удалены.
• Кто подскажет, как это сделать в неизменяемых файлах на HDFS?
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень • Можно записать новый «могильный» рекорд указывающий на то,
что предыдущее значение не верно, но...
• Надежнее просто переписать файлы (потенциально все файлы) в новую директорию, убрав не верные значения, и потом переименовать ее на место старой.
hadoop fs –cp /master-data-set /new-master-data-set
И вперед!!!
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень • Интересно, а сколько это займет времени?
• Возьмем 2ТБ Хадуп сервер (узел) • @1000 MB/s = 35 min (теория) • @200 MB/s = 3 h (практика) • @20 MB/s = 30 h (в режиме онлайн)
• 30 часов, чтобы исправить одно значение???
• Обратите внимане, что во всех случаях это означает отключение рабочего кластера (i.e. outage).
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Бетч Уровень • Отсутствие индексов и, как следствие, отсутствие идемпотентности
• Дубликация входящих данных автоматически означает вхождение не верных данных.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Проблемы: Уровень Запросов • Основное требование к «уровню запросов» – это консистентность
данных для запрашевающего клиента во время view swapping.
• Увы, совсем не много баз данных, которые дают такой функционал.
• Натан рекоммендует ElephantDB, которую он сам и создал.
• Похоже он один, кто ее и использует.
• Отсутствие хорошей рабочей базы данных для Уровня Запросов – это большая не решенная проблема в Ламбда Архитектуре.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Ламбда Архитектура: Против • Мы вообще не брались за проблему синхронизации данных на
разных уровнях: speed и batch.
• Это проблема похоже настолько неподьемна, что даже Гугл от нее отказался (см. Google Cloud DataFlow).
• Повторюсь: ключевая проблема в том, что любое решение этой
проблемы будет чрезвычайно кастомизированным, и это автоматически отсечет такую систему данных от всей Биг Дата экосистемы и ее новых технологий: Spark, Drill, Hive, Pig, etc.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Ламбда Архитектура: Новинки
Как же мы все-таки решили свои проблемы?
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Ламбда Архитектура: Новинки • Ответ: HBase и MapR mapr-db.
• Структурированные данные могут свободно храниться в нормальной отлаженной распределенной базе данных.
• HBase поддерживает ключевое требование Ламбда Архитектуры: неизменяемость данных.
• HBase полностью избавляет нас от проблемы корректировки данных.
• HBase даeт индемпотентность за счет мгновенных запросов по rowKey индексу.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Ламбда Архитектура: Новинки
• MapR-DB – это фирменная (proprietary) версия HBase.
• Полностью решает описаную проблему с Уровнем Запросов через snapshotting functionality.
• Снимает много головоломок с правильным тьюнингом HBase.
• Рекоммендую!
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
За чем будущее?
• Не думаю, что будущее за решениями в стиле Ламбда Архитектуры.
• Скорость обработки скорее будет достигаться за счет граммотного использования операционной памяти, особенно учитывая постоянную тенденцию к удешевлению ее стоимости.
• Думаю, что универсализм победит дуализм.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Вопросы Пожалуйста!
Кирилл Алешин [email protected]
Twitter: @kyrill007