Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

3.608 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

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

  1. 1. HHDDCCOONNFF «Ламбда Архитектура на практике» Кирилл Алешин @kyrill007
  2. 2. План Доклада • Ключевые идеи Ламбда архитектуры • Ламбда архитектура: За и Против • Практическая иллюстрация проблем ее реализации • Новые подходы • За чем же будущее? • Ответы на вопросы Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  3. 3. Ламбда Архитектура • Изобретатель – Натан Марц (Твиттер) Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  4. 4. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  5. 5. Почему Ламбда Архитектура? Потому что требуется решение для высокоскоростной обработки неограниченного количества данных Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  6. 6. Почему Ламбда Архитектура? Хочется, чтобы f(все данные) работала очень быстро. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  7. 7. Ламбда Архитектура: За • Жесткий акцент на неизменяемости входящих данных. • Возможность анализа на протяжении всего временного континуума (контраст: реляционные базы данных). • Акцентировка на сохранении именно «сырых данных», что открывает возможность постоянного репроцессинга. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  8. 8. Ламбда Архитектура: За Эти концепции – ключевые идеи будущих дата архитектур Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  9. 9. Ламбда Архитектура: Против Огромная сложность и цена реализации Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  10. 10. Ламбда Архитектура: Против • Фактически предлагается двойная кодировка всей логики в разнородных средах: batch processing и streaming processing. • Дуалистичная природа этой архитектуры – большая проблема. • Любая попытка прикрутить новый абстракционный уровень над этими подсистемами будет очень кастомизированным под каждое конкретное решение и будет требовать глубочайшего знания каждой из подсистем и самого фреймворка в целом (think $$$$$). Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  11. 11. Ламбда Архитектура: Против Hadoop + Storm = Marriage made in hell Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  12. 12. Ламбда Архитектура: Против Но проблемы начинаются гораздо раньше самой “женитьбы” Хадупа со Стормом. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  13. 13. Проблемы: Бетч Уровень Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  14. 14. Проблемы: Бетч Уровень • Данные складируются прямо на файловой системе (HDFS) в обыкновенных файлах в append-only mode. • Да, именно предлагается база данных, состоящая из flat files. • Однако, увы, складировать данные просто в однородные файлы чрезвычайно не эффективно даже для Хадупа. • Чтоб такое работало более менее быстро, наверное, не хватило денег на железо даже у Твиттера. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  15. 15. Проблемы: Бетч Уровень Добро пожаловать Shredding Process. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  16. 16. Проблемы: Бетч Уровень • Входящие данные и в самом деле сладируются в однородные файлы, но они уже попадают в Master Data Set через т.н. «Процесс Измельчения». • Процесс осуществляется через многошаговый Map-Reduce. • Но, увы, «измельчение данных» на файловой системе приводит к огромному количеству новых файлов, а Хадуп этого не любит. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  17. 17. Проблемы: Бетч Уровень Добро пожаловать Consolidation Process. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  18. 18. Проблемы: Бетч Уровень • Таким образом «измельченные данные» в маленьких файлах абсорбируются в уже существующие (большие) файлы в Master Data Set (мастер сет) на HDFS через отдельный Map-Reduce. • Кто-нибудь видит здесь проблему? Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  19. 19. Проблемы: Бетч Уровень • Да, именно, мы мутируем мастер данные, которые в этот момент могут читаться бегущими мап-редьюс работами... • Это, конечно, не хорошо. • Значит нужно писать собственный job scheduler, который бы давал экслюзивный статус нашему «консолидатору». Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  20. 20. Проблемы: Бетч Уровень • Это, к сожалению, только цветочки. • В чем одна из ключевых проблем складировки данных в плоских файлах? Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  21. 21. Проблемы: Бетч Уровень В невозможности легкой коррекции данных Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  22. 22. Проблемы: Бетч Уровень • Плохие данные обязательно попадут в мастер сет и тем или иным образом они должны быть удалены. • Кто подскажет, как это сделать в неизменяемых файлах на HDFS? Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  23. 23. Проблемы: Бетч Уровень • Можно записать новый «могильный» рекорд указывающий на то, что предыдущее значение не верно, но... • Надежнее просто переписать файлы (потенциально все файлы) в новую директорию, убрав не верные значения, и потом переименовать ее на место старой. hadoop fs –cp /master-data-set /new-master-data-set Copyright © 2013 Kyrill Alyoshin. All rights reserved. И вперед!!!
  24. 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. 25. Проблемы: Бетч Уровень • Отсутствие индексов и, как следствие, отсутствие идемпотентности • Дубликация входящих данных автоматически означает вхождение не верных данных. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  26. 26. Проблемы: Уровень Запросов • Основное требование к «уровню запросов» – это консистентность данных для запрашевающего клиента во время view swapping. • Увы, совсем не много баз данных, которые дают такой функционал. • Натан рекоммендует ElephantDB, которую он сам и создал. • Похоже он один, кто ее и использует. • Отсутствие хорошей рабочей базы данных для Уровня Запросов – это большая не решенная проблема в Ламбда Архитектуре. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  27. 27. Ламбда Архитектура: Против • Мы вообще не брались за проблему синхронизации данных на разных уровнях: speed и batch. • Это проблема похоже настолько неподьемна, что даже Гугл от нее отказался (см. Google Cloud DataFlow). • Повторюсь: ключевая проблема в том, что любое решение этой проблемы будет чрезвычайно кастомизированным, и это автоматически отсечет такую систему данных от всей Биг Дата экосистемы и ее новых технологий: Spark, Drill, Hive, Pig, etc. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  28. 28. Ламбда Архитектура: Новинки Как же мы все-таки решили свои проблемы? Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  29. 29. Ламбда Архитектура: Новинки • Ответ: HBase и MapR mapr-db. • Структурированные данные могут свободно храниться в нормальной отлаженной распределенной базе данных. • HBase поддерживает ключевое требование Ламбда Архитектуры: неизменяемость данных. • HBase полностью избавляет нас от проблемы корректировки данных. • HBase даeт индемпотентность за счет мгновенных запросов по rowKey индексу. Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  30. 30. Ламбда Архитектура: Новинки • MapR-DB – это фирменная (proprietary) версия HBase. • Полностью решает описаную проблему с Уровнем Запросов через snapshotting functionality. • Снимает много головоломок с правильным тьюнингом HBase. • Рекоммендую! Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  31. 31. За чем будущее? • Не думаю, что будущее за решениями в стиле Ламбда Архитектуры. • Скорость обработки скорее будет достигаться за счет граммотного использования операционной памяти, особенно учитывая постоянную тенденцию к удешевлению ее стоимости. • Думаю, что универсализм победит дуализм.  Copyright © 2013 Kyrill Alyoshin. All rights reserved.
  32. 32. Вопросы Пожалуйста! Copyright © 2013 Kyrill Alyoshin. All rights reserved. Кирилл Алешин kyrill@alyoshin-consulting.com Twitter: @kyrill007

×