Обзор современных подходов к обработке больших данных и их

advertisement
МГУ имени М.В. Ломоносова
Объединенная компания «Афиши» и «Рамблера»
Обзор современных подходов к
обработке больших данных
и их применение для построения
рекомендательных систем
Павел Клеменков
parser@cs.msu.su
Цифровая вселенная
По оценкам IDC размер “цифровой вселенной”
в 2006 г. составлял 0.18 зеттабайт
А к 2011 г. должен был достигнуть 1.8
зеттабайт
Продемонстрировав десятикратный рост за 5
лет!
Источники данных




Нью-Йоркская фондовая биржа генерирует
около терабайта данных в день
Объем хранилищ Facebook каждый день
увеличивается на 50 ТБ
Internet Archive уже хранит 2 ПБ данных и
прирастает 20 ТБ в месяц
Эксперименты на БАК могут генерировать
до 1 ПБ данных в секунду!
Что такое “большие данные”?
“Большие данные” характеризуются
объемом, разнообразием и скоростью, с
которой структурированные и
неструкутрированные данные поступают по
сетям передачи в процессоры и хранилища,
наряду с преобразованием этих данных в
ценную для бизнеса информацию [Gartner]
4V
Volume (объем)
Variety (разнообразие)
Velocity (скорость)
Value (ценность)
The End of an Architectural Era
Архитектура большинства СУБД почти
идентична System R (70-е годы):

Упор на дисковое хранение и индексацию

Многопоточность, чтобы скрыть задержки

Блокировки

Журнализация транзакций

Немасштабируемы
Вертикальное масштабирование?
Бесконечно мощного сервера нет!
Вертикальный рост конечен.
Оптимизация запросов?
Создание индексов?
Дополнительные операции.
Деградация под нагрузкой
Кэш на чтение?
Отказ от строгой консистентности.
Усложнение клиентского ПО.
Очередь операций вставки/обновления?
Размер очереди ограничен.
Персистентность очереди.
Денормализация схемы?
Избыточность данных.
Аномалии.
Горизонтальное масштабирование?
Отказ от нормализации.
Отказ от join.
Усложнение клиентского ПО.
Промежуточные итоги





Отказ от строгой консистентности
Уход от нормализации и внедрение
избыточности
Потеря выразительности SQL и
моделирование части функций программно
Усложнение клиентского ПО
Сложность поддержания
работоспособности и отказоустойчивости
NoSQL



NoSQL – это не бездумный отказ от
реляционной модели!
“NoSQL” - название реляционной СУБД, не
использующей SQL (1998 г.)
Бум NoSQL обусловлен ростом Интернетиндустрии
Мантра NoSQL






Решение для задачи, а не наоборот
Неограниченное горизонтальное
масштабирование
Свободная схема или ее отсутствие
Консистентность в жертву
производительности
Простота развертывания и
администрирования
Большинство программ императивные
NoSQL и CAP
Классификация NoSQL хранилищ по модели
данных
Тип
Примеры
Хранилища ключ-значение Redis
Scalaris
Riak
Tokyo Tyrant
Документные хранилища
Колоночные хранилища
Хранилища на графах
SimpleDB
CouchDB
MongoDB
BigTable
Hbase
Cassandra
Neo4j
Хранилища ключ-значение




Простая модель данных – ассоциативный
массив
Доступ к данным только по ключу
Информация о структуре занчений не
сохраняется
Обычно все данные хранятся в памяти с
возможностью сохранения на диск
Документные хранилища





“Документ” – множество пар ключ-значение
Документы могут быть вложены и
объединяться в коллекции
Отсутствие схемы как в документе, так и в
коллекции
Доступ к значениям по ключу или с
помощью языка запросов
MapReduce
Б-деревья только на добавление



Все изменения пишутся в конец файла
При ошибках всегда можно восстановить
последнее состояние
Запись не блокирует чтение
Колоночные хранилища




Таблица – упорядоченный ассоциативный
массив строк
Строка – ассоциативный массив семейств
колонок
Семейство колонок – ассоциативный
массив колонок с зафиксированными
ключами
Колонка – кортеж
<ключ, значение, временная метка>
Колоночные хранилища
Хранилища на графах




Данные естественным образом
представляются графом
Граф – это вершины с аттрибутами и ребра
со свойствами
Доступ к вершинам и ребрам по индексам
на аттрибутах и свойствах
Вычисления – обход графа по ребрам с
заданными свойствами
Производительность. Вставки
Производительность. Чтение
Производительность. Обновления
Производительность. Чтение
Почему MapReduce?



Средняя производительность HDD
~100МБ/c
Прочесть 1 ТБ ~ 2.5 часа
Прочесть 1 ТБ параллельно со 100 дисков ~
2 минуты

Произвольный доступ к диску медленный

Последовательный доступ быстрый!
MapReduce – модель распределенных
вычислений (Google, 2004)
История 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
Дизайн-принципы HDFS




Очень большие файлы (ГБ, ТБ, ПБ)
Пакетный доступ к данным (пишем один
раз, читаем много)
Аппаратные сбои неизбежны (репликация и
лог для метаданных)
Локальность вычислений
Чтение файла из HDFS
Запись файла в HDFS
Hadoop MapReduce
Производительность Hadoop
Сортировка записей по 100 байт
http://sortbenchmark.org
Май 2009, Yahoo!
Размер Число Число
узлов map
Число Степень
Время
reduce репликации
500 Гб
1 ТБ
100 ТБ
1 ПБ
2600
2700
10000
20000
1406
1460
3452
3658
8000
8000
190000
80000
1
1
2
2
59 сек
62 сек
173 мин
975 мин
Экосистема Hadoop




Hive – распределенное хранилище
(HDFS, HiveQL)
Pig – среда исполнения и язык
программирования вычислений
Hbase – распределенное колоночное
хранилище
ZooKeeper – высокодоступный
координационный сервис
О Erlang в двух словах





Функциональный ЯП
Создавался Ericsson для управления
коммутационным оборудованием
Легковесные процессы взаимодействуют в
соответствии с моделью акторов
Порождение 200000 процессов ~ 10 мкс
Отказоустойчивость оборудования –
99.9999999% (Ericsson)
Disco


Фреймворк MapReduce вычислений на
больших данных (Nokia Research Center)
Ключевое свойство - простота:

Нет планировщика

Облегченный доступ к локальным ресурсам

Независимый от ЯП протокол

Упрощенная DDFS с децентрализацией
метаданных
Disco vs Hadoop (задержки)
Подсчет слов в файле (1 Б)
Hadoop
PDisco
ODisco
Время (мс)
12324
359
35
Disco vs Hadoop (производительность)
Подсчет слов в английской Википедии
DDFS vs HDFS (чтение)
DDFS vs HDFS (запись)
В поисках “Hadoop реального времени”

Анализ данных в реальном времени

Высокочастотная торговля

Поисковые системы реального времени

Социальные сети

Персонализация контента

...
Yahoo! S4




Предоставить простой интерфейс поточной
обработки данных
Обеспечить горизонтальное
масштабирование и высокую доступность
кластера
Минимизировать задержки, используя
только оперативную память узлов
Создать децентрализованное,
симметричное решение без единой точки
отказа
Yahoo! S4

Вычисление – граф

Вершины – вычислительные элементы (PE)

Ребра – потоки событий

PE – это актор с изолированным
состоянием
События




Событие – кортеж именованных значений
События группируются по именам значений
в кортеже
Группировка важна, потому что состояние
хранится в памяти узла и изолировано
PE может или создать новый поток, или
опубликовать результат
Производительность S4
Кластер из 8 узлов (4 процессора, 16 ГБ)
Событий/c
Ошибка
Скорость передачи (Мб/c)
2000
3644
7268
10480
12432
14900
16000
20000
0.0%
0.0%
0.2%
0.4%
0.7%
1.5%
1.7%
4.2%
2.6
4.9
9.7
14.0
16.6
19.9
21.4
26.7
Storm



Storm (Twitter) – распределенная система
вычислений в реальном времени
Первый публичный релиз через год после
S4
Устраняет недостатки S4
Особенности Storm





Два варианта использования:

обработка потоков событий

распределенный RPC
Прозрачное горизонтальное
масштабирование
Гарантия обработки сообщений
Отказоустойчивость, перераспределение
вычислений
Независимость от ЯП
Модель вычислений

Вычисление – топология (граф)

Ребра – маршруты передачи данных

Вершины:

трубы (spout) – генерируют данные

молнии (bolt) – производят вычисления



Событие – кортеж (как в S4)
Кортеж полность обработан, если обработан
каждый кортеж дерева
Избежать повторных вычислений можно с
помощью транзакций
Рекомендательные системы
Задача рекомендательной системы – дать
человеку направление до наиболее
интересных и полезных для него объектов в
пространстве возможных вариантов
Рекомендательная система – программа,
задачей которой является предсказать оценку,
которую пользователь поставит объекту, с
которым он еще не встречался, на основании
характеристик этого объекта и/или профиля
пользователя
Apache Mahout


Классификация:

Логистическая регрессия

Байесовские классификаторы

Случайный лес
Кластеризация

K-Means

Иерархическая кластеризация

MinHash
Apache Mahout



Понижение размерности:

SVD

PCA
Рекомендательные алгоритмы:

Фильтрация по схожести пользователей

Фильтрация по схожести объектов

Slope One
И многие другие...
Фильтрация по схожести пользователей
∑ (r a , p − r̄ a)(rb , p− r̄ b )
sim (a , b)=
p∈ P
(r
(r
∑
∑
a , p − r̄ a)
b , p− r̄ b )
√
√
2
p∈ P
2
p∈P
sim ( a , b)∗ (r b , p− r̄ b )
∑
b∈ N
pred (a , b)= r̄ a +
sim ( a , b)
∑
b∈N
Фильтрация по схожести пользователей
DataModel model =
new FileDataModel(new File(“data.txt”));
UserSimilarity sim =
new PearsonCorrelationSimilarity(model);
UserNeighborhood neighbor =
new NearestNUserNeighborhood(3, sim,
model);
Recommender recommender = new
GenericUserBasedRecommender(model,neighbor,
sim);
List<RecommendedItem> recommendations =
recommender.recommend(1234, 10);
Фильтрация по схожести пользователей




Сложность O(MN)
На практике – O(M+N), т.к. векторы очень
разрежены
Слишком медленный для Веба
Предварительное вычисление матрицы
схожести сильно влияет на качество
Фильтрация по схожести объектов
∑ (r u ,a − r̄ u)( ru , b− r̄ u)
sim ( a , b)=
u∈U
(r
(r
∑
∑
u , a− r̄ u)
u ,b − r̄ u)
√
√
2
u∈U
2
u∈U
∑ sim (i, p)∗ r u ,i
i ∈ ratedItems (u)
pred (u , p)=
∑ sim (i , p)
i∈ ratedItems (a )
Фильтрация по схожести объектов
DataModel model =
new FileDataModel(new
File(“data.txt”));
ItemSimilarity sim =
new
PearsonCorrelationSimilarity(model);
Recommender recommender =
new GenericItemBasedRecommender(model,
sim);
List<RecommendedItem> recommendations =
recommender.recommend(1234, 10);
Фильтрация по схожести объектов




Сложность O(N2M)
На практике O(NM), т.к. у большинства
пользователей мало оценок
Более устойчив к предварительному
вычислению матрицы схожести
Применяется Amazon (2003 г.)
Мера Жаккарда
∣ A ∩B∣
J=
∣ A ∪ B∣
Мера Жаккарда
Ο(min(∣ A∣ ,∣B∣))
∣ A ∩B∣
J=
∣ A ∪ B∣
Ο(∣ A∣+∣B∣)
MinHash
A= {url1 , url 2 , …, urlk }
h : A →ℕ
hmin ( A)= min x∈ A (h (x))
J ( A , B)= P [hmin ( A)= hmin (B)]
Особенности MinHash

Сигнатура множества вычисляется один раз

Размер сигнатуры не меняется

Одна хеш-функция имеет высокую
дисперсию, поэтому нужно использовать
среднее нескольких хеш-функций
Кластеризация
M
A
P
Фильтрация
логов во
временном
окне
Кластеризация
M
A
P
Фильтрация
логов во
временном
окне
R
E
D
U
C
E
Множество
уникальных
URL
Кластеризация
M
A
P
Фильтрация
логов во
временном
окне
R
E
D
U
C
E
Множество
уникальных
URL
Подсчет
значений
хеш-функций
Кластеризация
M
A
P
Фильтрация
логов во
временном
окне
Подсчет
значений
хеш-функций
R
E
D
U
C
E
Множество
уникальных
URL
Вычисление
минимума
Кластеризация
M
A
P
Фильтрация
логов во
временном
окне
Подсчет
значений
хеш-функций
R
E
D
U
C
E
Множество
уникальных
URL
Вычисление
минимума
Группировка
минимумов
(кластеры)
Кластеризация
M
A
P
Фильтрация
логов во
временном
окне
R
E
D
U
C
E
Множество
уникальных
URL
Подсчет
значений
хеш-функций
Группировка
минимумов
(кластеры)
Вычисление
минимума
Отсечение
небольших
кластеров
Рекомендации
M
A
P
Фильтрация
логов во
временном
окне
Рекомендации
M
A
P
Фильтрация
логов во
временном
окне
R
E
D
U
C
E
Множество
уникальных
URL
Рекомендации
M
A
P
Фильтрация
логов во
временном
окне
R
E
D
U
C
E
Множество
уникальных
URL
Подсчет
кликов по
группам
Рекомендации
M
A
P
Фильтрация
логов во
временном
окне
Подсчет
кликов по
группам
R
E
D
U
C
E
Множество
уникальных
URL
Подсчет
кликов по
группам
Рекомендации
M
A
P
Фильтрация
логов во
временном
окне
Подсчет
кликов по
группам
R
E
D
U
C
E
Множество
уникальных
URL
Подсчет
кликов по
группам
Группировка
новостей
Рекомендации
M
A
P
Фильтрация
логов во
временном
окне
Подсчет
кликов по
группам
Группировка
новостей
R
E
D
U
C
E
Множество
уникальных
URL
Подсчет
кликов по
группам
Отсечение
непопулярных
новостей
Производительность

Hadoop кластер из 8 узлов

Временное окно кластеризации – 5 суток (8
ГБ логов)

Время кластеризации – 7 минут

Временное окно рекомендаций – 5 часов

Время генерации рекомендаций – 3.5-4
минуты
Благодарности

Кузнецов Сергей Дмитриевич

Добров Борис Викторович

Когаловский Михаил Рувимович

Калиниченко Леонид Андреевич
Вопросы?
Download