Кирилл Алешин, Ламбда Архитектура на практике

HDCONFHDCONF

«Ламбда Архитектура на практике»

Кирилл Алешин

@kyrill007

Copyright © 2013 Kyrill Alyoshin. All rights reserved.

План Доклада

• Ключевые идеи Ламбда архитектуры • Ламбда архитектура: За и Против • Практическая иллюстрация проблем ее реализации • Новые подходы • За чем же будущее? • Ответы на вопросы


Ламбда Архитектура

• Изобретатель – Натан Марц (Твиттер)


Почему Ламбда Архитектура?

Потому что требуется решение для высокоскоростной обработки неограниченного количества данных


Почему Ламбда Архитектура?

Хочется, чтобы f(все данные) работала очень быстро.


Ламбда Архитектура: За

• Жесткий акцент на неизменяемости входящих данных.

• Возможность анализа на протяжении всего временного континуума (контраст: реляционные базы данных).

• Акцентировка на сохранении именно «сырых данных», что открывает возможность постоянного репроцессинга.


Ламбда Архитектура: За

Эти концепции – ключевые идеи будущих дата архитектур


Ламбда Архитектура: Против

Огромная сложность и цена реализации


Ламбда Архитектура: Против • Фактически предлагается двойная кодировка всей логики в

разнородных средах: batch processing и streaming processing.

• Дуалистичная природа этой архитектуры – большая проблема.

• Любая попытка прикрутить новый абстракционный уровень над этими подсистемами будет очень кастомизированным под каждое конкретное решение и будет требовать глубочайшего знания каждой из подсистем и самого фреймворка в целом (think $$$$$).



Hadoop + Storm = Marriage made in hell



Но проблемы начинаются гораздо раньше самой “женитьбы” Хадупа со Стормом.


Проблемы: Бетч Уровень


Проблемы: Бетч Уровень • Данные складируются прямо на файловой системе (HDFS) в

обыкновенных файлах в append-only mode.

• Да, именно предлагается база данных, состоящая из flat files.

• Однако, увы, складировать данные просто в однородные файлы чрезвычайно не эффективно даже для Хадупа.

• Чтоб такое работало более менее быстро, наверное, не хватило денег на железо даже у Твиттера.



Добро пожаловать Shredding Process.


Проблемы: Бетч Уровень • Входящие данные и в самом деле сладируются в однородные

файлы, но они уже попадают в Master Data Set через т.н. «Процесс Измельчения».

• Процесс осуществляется через многошаговый Map-Reduce.

• Но, увы, «измельчение данных» на файловой системе приводит к огромному количеству новых файлов, а Хадуп этого не любит.



Добро пожаловать Consolidation Process.


Проблемы: Бетч Уровень • Таким образом «измельченные данные» в маленьких файлах

абсорбируются в уже существующие (большие) файлы в Master Data Set (мастер сет) на HDFS через отдельный Map-Reduce.

• Кто-нибудь видит здесь проблему?


Проблемы: Бетч Уровень • Да, именно, мы мутируем мастер данные, которые в этот момент

могут читаться бегущими мап-редьюс работами...

• Это, конечно, не хорошо.

• Значит нужно писать собственный job scheduler, который бы давал экслюзивный статус нашему «консолидатору».


Проблемы: Бетч Уровень • Это, к сожалению, только цветочки.

• В чем одна из ключевых проблем складировки данных в плоских файлах?



В невозможности легкой коррекции данных


Проблемы: Бетч Уровень • Плохие данные обязательно попадут в мастер сет и тем или

иным образом они должны быть удалены.

• Кто подскажет, как это сделать в неизменяемых файлах на HDFS?


Проблемы: Бетч Уровень • Можно записать новый «могильный» рекорд указывающий на то,

что предыдущее значение не верно, но...

• Надежнее просто переписать файлы (потенциально все файлы) в новую директорию, убрав не верные значения, и потом переименовать ее на место старой.

hadoop fs –cp /master-data-set /new-master-data-set

И вперед!!!


Проблемы: Бетч Уровень • Интересно, а сколько это займет времени?

• Возьмем 2ТБ Хадуп сервер (узел) • @1000 MB/s = 35 min (теория) • @200 MB/s = 3 h (практика) • @20 MB/s = 30 h (в режиме онлайн)

• 30 часов, чтобы исправить одно значение???

• Обратите внимане, что во всех случаях это означает отключение рабочего кластера (i.e. outage).


Проблемы: Бетч Уровень • Отсутствие индексов и, как следствие, отсутствие идемпотентности

• Дубликация входящих данных автоматически означает вхождение не верных данных.


Проблемы: Уровень Запросов • Основное требование к «уровню запросов» – это консистентность

данных для запрашевающего клиента во время view swapping.

• Увы, совсем не много баз данных, которые дают такой функционал.

• Натан рекоммендует ElephantDB, которую он сам и создал.

• Похоже он один, кто ее и использует.

• Отсутствие хорошей рабочей базы данных для Уровня Запросов – это большая не решенная проблема в Ламбда Архитектуре.


Ламбда Архитектура: Против • Мы вообще не брались за проблему синхронизации данных на

разных уровнях: speed и batch.

• Это проблема похоже настолько неподьемна, что даже Гугл от нее отказался (см. Google Cloud DataFlow).

• Повторюсь: ключевая проблема в том, что любое решение этой

проблемы будет чрезвычайно кастомизированным, и это автоматически отсечет такую систему данных от всей Биг Дата экосистемы и ее новых технологий: Spark, Drill, Hive, Pig, etc.


Ламбда Архитектура: Новинки

Как же мы все-таки решили свои проблемы?


Ламбда Архитектура: Новинки • Ответ: HBase и MapR mapr-db.

• Структурированные данные могут свободно храниться в нормальной отлаженной распределенной базе данных.

• HBase поддерживает ключевое требование Ламбда Архитектуры: неизменяемость данных.

• HBase полностью избавляет нас от проблемы корректировки данных.

• HBase даeт индемпотентность за счет мгновенных запросов по rowKey индексу.


Ламбда Архитектура: Новинки

• MapR-DB – это фирменная (proprietary) версия HBase.

• Полностью решает описаную проблему с Уровнем Запросов через snapshotting functionality.

• Снимает много головоломок с правильным тьюнингом HBase.

• Рекоммендую!


За чем будущее?

• Не думаю, что будущее за решениями в стиле Ламбда Архитектуры.

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

• Думаю, что универсализм победит дуализм.


Вопросы Пожалуйста!

Кирилл Алешин [email protected]

Twitter: @kyrill007

mailto:[email protected]

Кирилл Алешин, Ламбда Архитектура на практике

Technology