Выбор языка запросов для извлечения фактов из вашего Dataset

Зиновьев Алексей

Давайте жнакомиться!• отважный житель

солнечного Питербурха

• любитель Pig Latin и Hive

- ненавистник

• вечерами думает как вершина, а по утрам подгружает в память события прошедшего дня

Жила-была задачка

Некая соц.сетьВ целом:● 200 000 000 пользователей● 8 500 000 сообществВ сутки:● 40 000 000 пользователей● 250 000 000 сообщений● 8 000 000 постов● 12 000 000 фотографий● 7 000 000 дружб

Вредоносная деятельность● Нарушение законов этики, морали и статей УК РФ

● Создание “теневой” подсети спам-аккаунтов

● Взлом профилей реальных пользователей

● Рассылка спама со своих и взломанных профилей

● Привлечение внимание при помощи появления в списке

посетивших страницу пользователя

Выгоды соц.сети● Предотвращаем распространение “эпидемий” по взлому

профилей и утечку персональных данных

● Предотвращаем спам до его появления

● Уменьшаем количество жалоб

● Снижаем нагрузку на модераторов

● Сокращаем штат модераторов

Данные● Граф связей (~ 9 * 10^6, 39 Гб)

● Демография

● “Лайки/Классы” пользователей

● История “логинов” (включая неудачные попытки

авторизации) (~ 3,2 * 10^8, 12 Гб)

● Посты в группах

● Жалобы на спам

А что нужно делать-то? Необходимо на основании графа друзей, истории заходов в соц.

сеть, а также анализа иной деятельности предложить мат.модель,

позволяющую с высокой достоверностью (ошибка первого рода не

более 1% и ошибка второго рода не более 10%) определять, что

пользователь является злоумышленником.

Существующее на данный момент решение имеет ошибку первого

рода более 10% и ошибку второго рода более 20%.

Основные признаки● Local feature: степень вершины

● Global feature: значение PageRank для каждой вершины

● Global-local feature: значение локального коэффициента

кластеризации (LCC)

● Количество попыток аутентификации

● Анкетные данные (пол, возраст, регион проживания)

● Удаленность от столицы и от государственных границ

Распределение числа друзей

Набор инструментов

● R 3.0.3 ( прототипирование моделей)

● python 23 + scypi + numpy + pandas (моделирование)

● Hadoop 2.6 (кластерная инфраструктура)

● Pig 14 (вычисление неграфовых признаков)

● Giraph 1.1 (вычисление графовых признаков)

● Cloud Storage + BigQuery для тяжелых агрегатов

● Hive баловства ради

Виды Hadoop - фреймворков

● Универсальные (низкоуровневое API :

MapReduce/Spark/Tez)

● Абстрактные (Pig, Crunch)

● SQL - подобные (Hive, Impala, Shark)

● Процессинг графов (Giraph, GraphX или GraphLab)

● Машинное обучение (Mahout, MLib, Oryx)

● Потоковая обработка (Spark Streaming, Storm)

Spark

● MapReduce в памяти

● Иногда в 100 раз быстрее

MapReduce

● Поддержка Shark (SQL), MLlib

(Machine learning), GraphX

● RDD - базовый строительный блок

(неизменяемая распределнная

коллекция объектов)

MapReduce vs Spark

MapReduce исповедует однопроходную модель вычислений

со множеством чтений/записей с диска, плох в итеративной

обработке

Spark хорош в обработке потоковых данных, число

чтений/записей с диска уменьшено по сравнению с

MapReduce

Свинья везде грязь найдет● Режим MapReduce и local

● Легкие настройки hadoop - кластера

● Ленивое исполнение и возможность пошаговой отладки

● 10 строк вместо 10 джоб

● Встроенные команды работы с HDFS

● Работа со сложными иерархическими схемами данных

● Возможность написания пользовательских функций

Стадии обработки и выполнения вашего скрипта

Операторы Pig превращаются в цепочку map/reduce - задач

Свинья везде грязь найдет● Можно написать свою процедуру парсинга/загрузки

● Множественные способы группировки и объединения

данных (JOIN, CROSS, COGROUP, GROUP, UNION,

SPLIT)

● Полноценный FOREACH

● Подробная пошаговая инструкция трансформации ваших

данных

Старый друг лучше новых двухПриходит время, когда вам нужно обрабатывать большие, но

однородные, плоские, данные с постоянной структурой.

Вы не готовы писать на “среднеуровневом” Pig и хотите

применить свой опыт в SQL.

Hive - спасение для аналитиков из Facebook

Старый друг лучше новых двух● У вас появляется метахранилище со схемами таблиц

● Вы обнаружите у себя в HDFS много всего интересного

● Вам придется повозиться с настройками

● У вас появляются индексы и возможность не сканировать

всю таблицу при поиске пары записей

● и даже какие-то транзакции!!!!

● Обилие форматов хранения данных

Разный подход к параллелизации

На плечах титанов

Почему Giraph?

● Open-source воплощение Pregel

● Запускалось на уже имеющейся инфраструктуре Hadoop

● Вычисления происходят в памяти (а ее было достаточно)

● Простая возможность для проведения итерационных

вычислений (важно при вычислении PageRank)

А что происходит на самом деле?

Ну если совсем лень...

Google Cloud Platform● App Engine

● Big Query

● Cloud SQL

● Cloud Storage

● Compute Engine

Пластиковые вилки для макарон

Compute Engine● Инфраструктура как сервис

● Linux VM вместе с дисками и айпишниками

● От 1 слабенького ядра до серьезного кластера

● Особенно приятно на таком масштабируется Hadoop

● И да, это очень напоминает Amazon

Cloud Storage

● Объекты хранятся в бакетах - неизменяемых

структурированных кучках данных размером до 5ТБ

● Хорошо подходит для хранения сырых датасетов и логов

● Интегрируется со всеми другими гугловыми сервисами (и

не только с ними)

Big Query

● Похож на SQL с небольшой примесью самописных

функций

● Может обрабатывать данные, хранящиеся в Cloud

Storage

● Пробегает по таблице в 1 Тб за секунды

● Опирается на мощь движка Dremel

Пример

Почему-то я задаю вопросы...

1. Можно ли запустить Pig не на Hadoop - кластере?

2. Можно ли задавать разный уровень параллелизма в Pig для разных операторов?

3. Можно ли было обойтись без Giraph при вычислении графовых фич в моей задаче?