1 / 81

Павел Клеменков parser@cs.msu.su

МГУ имени М.В. Ломоносова Объединенная компания «Афиши» и «Рамблера». Обзор современных подходов к обработке больших данных и их применение для построения рекомендательных систем. Павел Клеменков parser@cs.msu.su. Цифровая вселенная.

margo
Download Presentation

Павел Клеменков parser@cs.msu.su

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. МГУ имени М.В. ЛомоносоваОбъединенная компания «Афиши» и «Рамблера» Обзор современных подходов к обработке больших данных и их применение для построения рекомендательных систем Павел Клеменковparser@cs.msu.su

  2. Цифровая вселенная По оценкам IDC размер “цифровой вселенной” в 2006 г. составлял 0.18 зеттабайт А к 2011 г. должен был достигнуть 1.8 зеттабайт Продемонстрировав десятикратный рост за 5 лет!

  3. Источники данных • Нью-Йоркская фондовая биржа генерирует около терабайта данных в день • Объем хранилищ Facebook каждый день увеличивается на 50 ТБ • Internet Archive уже хранит 2 ПБ данных и прирастает 20 ТБ в месяц • Эксперименты на БАК могут генерировать до 1 ПБ данных в секунду!

  4. “Большие данные” характеризуются объемом, разнообразием и скоростью, с которой структурированные и неструкутрированные данные поступают по сетям передачи в процессоры и хранилища, наряду с преобразованием этих данных в ценную для бизнеса информацию [Gartner] Что такое “большие данные”?

  5. 4V Volume (объем) Variety (разнообразие) Velocity (скорость) Value (ценность)

  6. The End of an Architectural Era Архитектура большинства СУБД почти идентична System R (70-е годы): • Упор на дисковое хранение и индексацию • Многопоточность, чтобы скрыть задержки • Блокировки • Журнализация транзакций • Немасштабируемы

  7. Вертикальное масштабирование? Бесконечно мощного сервера нет! Вертикальный рост конечен.

  8. Оптимизация запросов?Создание индексов? Дополнительные операции.Деградация под нагрузкой

  9. Кэш на чтение? Отказ от строгой консистентности.Усложнение клиентского ПО.

  10. Очередь операций вставки/обновления? Размер очереди ограничен. Персистентность очереди.

  11. Денормализация схемы? Избыточность данных. Аномалии.

  12. Горизонтальное масштабирование? Отказ от нормализации.Отказ от join. Усложнение клиентского ПО.

  13. Промежуточные итоги • Отказ от строгой консистентности • Уход от нормализации и внедрение избыточности • Потеря выразительности SQL и моделирование части функций программно • Усложнение клиентского ПО • Сложность поддержания работоспособности и отказоустойчивости

  14. NoSQL • NoSQL – это не бездумный отказ от реляционной модели! • “NoSQL” - название реляционной СУБД, не использующей SQL (1998 г.) • Бум NoSQL обусловлен ростом Интернет-индустрии

  15. Мантра NoSQL • Решение для задачи, а не наоборот • Неограниченное горизонтальное масштабирование • Свободная схема или ее отсутствие • Консистентность в жертву производительности • Простота развертывания и администрирования • Большинство программ императивные

  16. NoSQL и CAP

  17. Классификация NoSQL хранилищ по модели данных

  18. Хранилища ключ-значение • Простая модель данных – ассоциативный массив • Доступ к данным только по ключу • Информация о структуре занчений не сохраняется • Обычно все данные хранятся в памяти с возможностью сохранения на диск

  19. Документные хранилища • “Документ” – множество пар ключ-значение • Документы могут быть вложены и объединяться в коллекции • Отсутствие схемы как в документе, так и в коллекции • Доступ к значениям по ключу или с помощью языка запросов • MapReduce

  20. Б-деревья только на добавление • Все изменения пишутся в конец файла • При ошибках всегда можно восстановить последнее состояние • Запись не блокирует чтение

  21. Колоночные хранилища • Таблица – упорядоченный ассоциативный массив строк • Строка – ассоциативный массив семейств колонок • Семейство колонок – ассоциативный массив колонок с зафиксированными ключами • Колонка – кортеж <ключ, значение, временная метка>

  22. Колоночные хранилища

  23. Хранилища на графах • Данные естественным образом представляются графом • Граф – это вершины с аттрибутами и ребра со свойствами • Доступ к вершинам и ребрам по индексам на аттрибутах и свойствах • Вычисления – обход графа по ребрам с заданными свойствами

  24. Производительность. Вставки

  25. Производительность. Чтение

  26. Производительность. Обновления

  27. Производительность. Чтение

  28. Почему MapReduce? • Средняя производительность HDD ~100МБ/c • Прочесть 1 ТБ ~ 2.5 часа • Прочесть 1 ТБ параллельно со 100 дисков ~ 2 минуты • Произвольный доступ к диску медленный • Последовательный доступ быстрый!

  29. MapReduce – модель распределенных вычислений (Google, 2004)

  30. История Hadoop • 2002 – поисковый движок Nutch • 2003 – GFS (Google) • 2004 – Nutch Distributed File System (NDFS) • 2004 – MapReduce (Google) • 2005 – Nutch MapReduce • 2006 – Nutch → Hadoop • 2008 – Yahoo! анонсирует Hadoop кластер • 2008 – Apache Hadoop

  31. Дизайн-принципы HDFS • Очень большие файлы (ГБ, ТБ, ПБ) • Пакетный доступ к данным (пишем один раз, читаем много) • Аппаратные сбои неизбежны (репликация и лог для метаданных) • Локальность вычислений

  32. Чтение файла из HDFS

  33. Запись файла в HDFS

  34. Hadoop MapReduce

  35. Производительность Hadoop Сортировка записей по 100 байт http://sortbenchmark.org Май 2009, Yahoo!

  36. Экосистема Hadoop • Hive – распределенное хранилище(HDFS, HiveQL) • Pig – среда исполнения и язык программирования вычислений • Hbase – распределенное колоночное хранилище • ZooKeeper – высокодоступный координационный сервис

  37. О Erlang в двух словах • Функциональный ЯП • Создавался Ericsson для управления коммутационным оборудованием • Легковесные процессы взаимодействуют в соответствии с моделью акторов • Порождение 200000 процессов ~ 10 мкс • Отказоустойчивость оборудования – 99.9999999% (Ericsson)

  38. Disco • Фреймворк MapReduce вычислений на больших данных (Nokia Research Center) • Ключевое свойство - простота: • Нет планировщика • Облегченный доступ к локальным ресурсам • Независимый от ЯП протокол • Упрощенная DDFS с децентрализацией метаданных

  39. Disco vs Hadoop (задержки) Подсчет слов в файле (1 Б)

  40. Disco vs Hadoop (производительность) Подсчет слов в английской Википедии

  41. DDFS vs HDFS (чтение)

  42. DDFS vs HDFS (запись)

  43. В поисках “Hadoop реального времени” • Анализ данных в реальном времени • Высокочастотная торговля • Поисковые системы реального времени • Социальные сети • Персонализация контента • ...

  44. Yahoo! S4 • Предоставить простой интерфейс поточной обработки данных • Обеспечить горизонтальное масштабирование и высокую доступность кластера • Минимизировать задержки, используя только оперативную память узлов • Создать децентрализованное, симметричное решение без единой точки отказа

  45. Yahoo! S4 • Вычисление – граф • Вершины – вычислительные элементы (PE) • Ребра – потоки событий • PE – это актор с изолированным состоянием

  46. События • Событие – кортеж именованных значений • События группируются по именам значений в кортеже • Группировка важна, потому что состояние хранится в памяти узла и изолировано • PE может или создать новый поток, или опубликовать результат

  47. Производительность S4 Кластер из 8 узлов (4 процессора, 16 ГБ)

  48. Storm • Storm (Twitter) – распределенная система вычислений в реальном времени • Первый публичный релиз через год после S4 • Устраняет недостатки S4

  49. Особенности Storm • Два варианта использования: • обработка потоков событий • распределенный RPC • Прозрачное горизонтальное масштабирование • Гарантия обработки сообщений • Отказоустойчивость, перераспределение вычислений • Независимость от ЯП

  50. Модель вычислений • Вычисление – топология (граф) • Ребра – маршруты передачи данных • Вершины: • трубы (spout) – генерируют данные • молнии (bolt) – производят вычисления

More Related