Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

3.605 visualizaciones

Publicado el

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

Publicado en: Tecnología
  • Sé el primero en comentar

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

  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

×