Кирилл расскажет о таких темах, как практичность современных распределенных файловых систем для складирования структурированных данных, сложности синхронизации данных на разных Ламбда уровнях, а также несколько Big Data новинок для закрытия брешей в традиционном описании Ламбда архитектуры. Кирилл расскажет как о пользе этой модели, так и об извлеченных уроках ее использования.

1. HHDDCCOONNFF
«Ламбда Архитектура на
практике»
Кирилл Алешин
@kyrill007

2. План Доклада
• Ключевые идеи Ламбда архитектуры
• Ламбда архитектура: За и Против
• Практическая иллюстрация проблем ее реализации
• Новые подходы
• За чем же будущее?
• Ответы на вопросы
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

3. Ламбда Архитектура
• Изобретатель – Натан
Марц (Твиттер)
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

4. Copyright © 2013 Kyrill Alyoshin. All rights reserved.

5. Почему Ламбда Архитектура?
Потому что требуется решение для высокоскоростной
обработки неограниченного количества данных
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

6. Почему Ламбда Архитектура?
Хочется, чтобы f(все данные) работала очень быстро.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

7. Ламбда Архитектура: За
• Жесткий акцент на неизменяемости входящих данных.
• Возможность анализа на протяжении всего временного
континуума (контраст: реляционные базы данных).
• Акцентировка на сохранении именно «сырых данных», что
открывает возможность постоянного репроцессинга.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

8. Ламбда Архитектура: За
Эти концепции – ключевые идеи будущих
дата архитектур
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

9. Ламбда Архитектура: Против
Огромная сложность и цена реализации
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

10. Ламбда Архитектура: Против
• Фактически предлагается двойная кодировка всей логики в
разнородных средах: batch processing и streaming processing.
• Дуалистичная природа этой архитектуры – большая проблема.
• Любая попытка прикрутить новый абстракционный уровень над
этими подсистемами будет очень кастомизированным под
каждое конкретное решение и будет требовать глубочайшего
знания каждой из подсистем и самого фреймворка в целом (think
$$$$$).
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

11. Ламбда Архитектура: Против
Hadoop + Storm = Marriage made in hell
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

12. Ламбда Архитектура: Против
Но проблемы начинаются гораздо раньше
самой “женитьбы” Хадупа со Стормом.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

13. Проблемы: Бетч Уровень
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

14. Проблемы: Бетч Уровень
• Данные складируются прямо на файловой системе (HDFS) в
обыкновенных файлах в append-only mode.
• Да, именно предлагается база данных, состоящая из flat files.
• Однако, увы, складировать данные просто в однородные файлы
чрезвычайно не эффективно даже для Хадупа.
• Чтоб такое работало более менее быстро, наверное, не хватило
денег на железо даже у Твиттера.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

15. Проблемы: Бетч Уровень
Добро пожаловать Shredding Process.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

16. Проблемы: Бетч Уровень
• Входящие данные и в самом деле сладируются в однородные
файлы, но они уже попадают в Master Data Set через т.н.
«Процесс Измельчения».
• Процесс осуществляется через многошаговый Map-Reduce.
• Но, увы, «измельчение данных» на файловой системе приводит
к огромному количеству новых файлов, а Хадуп этого не любит.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

17. Проблемы: Бетч Уровень
Добро пожаловать Consolidation Process.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

18. Проблемы: Бетч Уровень
• Таким образом «измельченные данные» в маленьких файлах
абсорбируются в уже существующие (большие) файлы в Master
Data Set (мастер сет) на HDFS через отдельный Map-Reduce.
• Кто-нибудь видит здесь проблему?
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

19. Проблемы: Бетч Уровень
• Да, именно, мы мутируем мастер данные, которые в этот момент
могут читаться бегущими мап-редьюс работами...
• Это, конечно, не хорошо.
• Значит нужно писать собственный job scheduler, который бы
давал экслюзивный статус нашему «консолидатору».
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

20. Проблемы: Бетч Уровень
• Это, к сожалению, только цветочки.
• В чем одна из ключевых проблем складировки данных в плоских
файлах?
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

21. Проблемы: Бетч Уровень
В невозможности легкой коррекции данных
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

22. Проблемы: Бетч Уровень
• Плохие данные обязательно попадут в мастер сет и тем или
иным образом они должны быть удалены.
• Кто подскажет, как это сделать в неизменяемых файлах на
HDFS?
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

23. Проблемы: Бетч Уровень
• Можно записать новый «могильный» рекорд указывающий на то,
что предыдущее значение не верно, но...
• Надежнее просто переписать файлы (потенциально все файлы) в
новую директорию, убрав не верные значения, и потом
переименовать ее на место старой.
hadoop fs –cp /master-data-set /new-master-data-set
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
И вперед!!!

24. Проблемы: Бетч Уровень
• Интересно, а сколько это займет времени?
• Возьмем 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.

25. Проблемы: Бетч Уровень
• Отсутствие индексов и, как следствие, отсутствие идемпотентности
• Дубликация входящих данных автоматически означает вхождение
не верных данных.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

26. Проблемы: Уровень Запросов
• Основное требование к «уровню запросов» – это консистентность
данных для запрашевающего клиента во время view swapping.
• Увы, совсем не много баз данных, которые дают такой функционал.
• Натан рекоммендует ElephantDB, которую он сам и создал.
• Похоже он один, кто ее и использует.
• Отсутствие хорошей рабочей базы данных для Уровня Запросов –
это большая не решенная проблема в Ламбда Архитектуре.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

27. Ламбда Архитектура: Против
• Мы вообще не брались за проблему синхронизации данных на
разных уровнях: speed и batch.
• Это проблема похоже настолько неподьемна, что даже Гугл от нее
отказался (см. Google Cloud DataFlow).
• Повторюсь: ключевая проблема в том, что любое решение этой
проблемы будет чрезвычайно кастомизированным, и это
автоматически отсечет такую систему данных от всей Биг Дата
экосистемы и ее новых технологий: Spark, Drill, Hive, Pig, etc.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

28. Ламбда Архитектура: Новинки
Как же мы все-таки решили свои проблемы?
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

29. Ламбда Архитектура: Новинки
• Ответ: HBase и MapR mapr-db.
• Структурированные данные могут свободно храниться в
нормальной отлаженной распределенной базе данных.
• HBase поддерживает ключевое требование Ламбда Архитектуры:
неизменяемость данных.
• HBase полностью избавляет нас от проблемы корректировки
данных.
• HBase даeт индемпотентность за счет мгновенных запросов по
rowKey индексу.
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

30. Ламбда Архитектура: Новинки
• MapR-DB – это фирменная (proprietary) версия HBase.
• Полностью решает описаную проблему с Уровнем Запросов через
snapshotting functionality.
• Снимает много головоломок с правильным тьюнингом HBase.
• Рекоммендую!
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

31. За чем будущее?
• Не думаю, что будущее за решениями в стиле Ламбда
Архитектуры.
• Скорость обработки скорее будет достигаться за счет граммотного
использования операционной памяти, особенно учитывая
постоянную тенденцию к удешевлению ее стоимости.
• Думаю, что универсализм победит дуализм. 
Copyright © 2013 Kyrill Alyoshin. All rights reserved.

32. Вопросы Пожалуйста!
Copyright © 2013 Kyrill Alyoshin. All rights reserved.
Кирилл Алешин
kyrill@alyoshin-consulting.com
Twitter: @kyrill007