Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Big Data. Методы и средства анализа. Учебное пособие
.pdf
При большом количестве наблюдений иерархические методы кластерно-
го анализа не пригодны. В таких случаях используют неиерархические методы, основанные на разделении, которые представляют собой итеративные ме-
тоды дробления исходной совокупности. В процессе деления новые кластеры
формируются до тех пор, пока не будет выполнено правило остановки. Существуют два подхода. Первый заключается в определении границ клас-
теров как наиболее плотных участков в многомерном пространстве исходных
данных, т.е. определение кластера там, где имеется большое "сгущение
точек". Второй подход заключается в минимизации меры различия объектов.
Факторный анализ - это метод, применяемый для изучения
взаимосвязей между значениями переменных. Вообще, факторный анализ
преследует две цели - сокращение числа переменных и классификацию
переменных, т.е. определение структуры взаимосвязей между переменными.
Соответственно, факторный анализ может использоваться для решения
задач сокращения размерности данных или для решения задач
классификации. Фактор в "сжатом" виде содержит информацию о
нескольких переменных. В один фактор объединяются переменные, которые
сильно коррелируют между собой. В результате факторного анализа
отыскиваются такие комплексные факторы, которые как можно более полно
объясняют связи между рассматриваемыми переменными.
Методы поиска ассоциативных правил (association rule) - целью является
нахождение закономерностей между связанными событиями в базах данных.
Часто встречающиеся приложения с применением ассоциативных
правил: розничная торговля: определение товаров, которые стоит продвигать
совместно; выбор местоположения товара в магазине; анализ
потребительской корзины; прогнозирование спроса; перекрестные продажи:
если есть информация о том, что клиенты приобрели продукты A, Б и В, то
какие из них вероятнее всего купят продукт Г; маркетинг: поиск рыночных
сегментов, тенденций покупательского поведения; сегментация клиентов:
выявление общих характеристик клиентов компании, выявление групп
покупателей; оформление каталогов, анализ сбытовых кампаний фирмы,
определение последовательностей покупок клиентов (какая покупка
последует за покупкой товара А); анализ Web-логов.
21
3.3. Методы визуализации
С возрастанием количества накапливаемых данных, даже при
использовании сколь угодно мощных и разносторонних алгоритмов Data
Mining, становится все сложнее "переваривать" и интерпретировать
полученные результаты. А, как известно, одно из положений Data Mining -
поиск практически полезных закономерностей. Закономерность может стать
практически полезной, только если ее можно осмыслить и понять.
В 1987 году по инициативе ACM SIGGRAPH IEEE Computer Society
Technical Committee of Computer Graphics, в связи с необходимостью
использования новых методов, средств и технологий данных, были
сформулированы соответствующие задачи направления визуализации.
К способам визуального или графического представления данных
относят графики, диаграммы, таблицы, отчеты, списки, структурные схемы,
карты и т.д. Визуализация традиционно рассматривалась как
вспомогательное средство при анализе данных, однако сейчас все больше
исследований говорит о ее самостоятельной роли.
Традиционные методы визуализации могут находить следующее
применение: представлять пользователю информацию в наглядном виде;
компактно описывать закономерности, присущие исходному набору данных;
снижать размерность или сжимать информацию; восстанавливать пробелы в
наборе данных; находить шумы и выбросы в наборе данных.
Каждый из алгоритмов Data Mining использует определенный подход к
визуализации. Для деревьев решений - это визуализатор дерева решений,
список правил, таблица сопряженности. Для нейронных сетей в зависимости
от инструмента это может быть топология сети, график изменения величины
ошибки, демонстрирующий процесс обучения. Для карт Кохонена: карты
входов, выходов, другие специфические карты. Для линейной регрессии в
качестве визуализатора выступает линия регрессии. Диаграммы и графики
рассеивания часто используются для оценки качества работы того или иного
метода.
В данный момент существует огромное количество как методов анализа
данных, так и программных средств для анализа. Богатый выбор позволяет
найти максимально подходящий метод решения конкретной задачи.
22
Глава 4. ВНЕДРЕНИЕ ИНТЕЛЛЕКТУАЛЬНЫХ БАЗ ДАННЫХ.
РЫНОК ИНСТРУМЕНТОВ
4.1. Обзор NOSQL систем
В последние годы появилась целая серия решений альтернативных
реляционным БД. Эти технологии известны как «NoSQL базы данных».
Основная проблема реляционных БД заключается в том, что они не
могут справляться с быстрым анализом и поиском для Big data. Можно
выделить три конкретные проблемные области:
горизонтальное масштабирование при больших объемах данных, например
как в случае Digg (3 терабайта для зеленых значков, отображаемых, если
ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по
входящим сообщениям) или eBay (2 петабайта в целом);
производительность каждого отдельного сервера;
негибкий дизайн логической структуры.
Многие компании нуждаются в нахождении новых путей для хранения
и масштабирования огромных массивов данных. Рассмотрим так называемые
NoSQL базы данных подробнее.
Термин NoSQL был придуман Эриком Эвансом (Eric Evan / Racker),
когда Джоан Оскарсон (Johan Oskarsson) из Last.fm хотел организовать
мероприятие для обсуждения распределенных баз данных с открытым
исходным кодом.
Под термином NoSQL скрывается большое количество продуктов с
абсолютно разными дизайнами. Однако используются три основных
параметра для сравнения этих систем: масштабируемость; модель данных и
запросов; система хранения данных. Проанализируем некоторые NoSQL БД.
Масштабируемость - автоматическое распределение данных между
несколькими серверами (распределенные базы данных). К ним относятся
СУБД Cassandra, HBase, Riak, Scalaris и Voldemort.
Особенности распределенных БД: поддержка нескольких датацентров
и возможность добавления новых машин в работающий кластер прозрачно
для приложений пользователей.
23
Нераспределенные базы данных включают в себя CouchDB, MongoDB,
Neo4j, Redis и Tokyo Cabinet. Эти системы могут служить прослойкой для
хранения данных для распределенных систем; MongoDB предоставляет
ограниченную поддержку шардинга (sharding), так же как и Lounge для
CouchDB, и Tokyo Cabinet может использоваться как система хранения
файлов для Voldemort.
Модель данных и запросов. Существует огромное многообразие
моделей данных и API запросов в NoSQL базах данных.
Система семейства столбцов (columnfamily) используется в Cassandra и
HBase, и ее идея была привнесена в них из документов, описывающих
устройство Google Bigtable. В обеих системах в БД есть строки и столбцы,
как обычно, но количество строк невелико: каждая строка имеет больше или
меньше столбцов, в зависимости от необходимости, и столбцы не должны
быть определены заранее.
Система ключ/значения проста и несложна для реализации, но
неэффективна, если вы заинтересованы только в запросе или обновлении
части данных. Также трудно реализовать сложные структуры поверх
распределенных систем.
24
Документо-ориентированные базы данных - это по существу следующий
уровень систем ключ/значение, позволяющих связывать вложенные данные с
каждым ключом. Поддержка таких запросов более эффективна, чем просто
возвращение всего BLOB каждый раз.
Neo4J обладает уникальной моделью данных, храня объекты и связи в
качестве узлов и ребер графа. Для запросов, которые соответствуют этой
модели (например, иерархических данных), они могут быть в тысячу раз
быстрее, чем альтернативные варианты.
Scalaris использует распределенные транзакции между несколькими
ключами. При этом необходимо учитывать компромисс между
последовательностью и наличием свободных мест при оценке в
распределенных системах.
Система хранения данных - способ хранения данных внутри системы.
Обеспечивает возможность «выдерживания» высоких нагрузок хранилищем.
Базы данных хранящие данные в памяти, являются очень быстрыми
(Redis может выполнять до 100 000 операций в секунду), но не могут
работать с данными, превышающими размер доступной оперативной памяти.
Долговечность (сохранение данных в случае сбоя на сервере или отключения
питания) также может быть проблемой (в новых версиях будет поддержка
append-only log). Количество данных, которые могут ожидать записи на диск,
потенциально велико. Другая система с хранением данных в оперативной
памяти — Scalaris, решает проблему долговечности с помощью репликации,
но она не поддерживает масштабирования на несколько датацентров, так что
потеря данных вероятна и тут — в случае отключения питания.
25
Memtables и SSTables буферизируют запросы на запись в памяти
(memtable), после записи в commit лог для сохранности (см.подробнее
http://wiki.apache.org/cassandra/ArchitectureOverview). После накопления
достаточного количества записей, Memtable сортируется и записывается на
диск, уже как SSTable. Это дает производительность, близкую к
производительности памяти, в то же время система лишена проблем,
актуальных при хранении только в памяти.
B-деревья используются в БД уже очень давно. Они обеспечивают
надежную поддержку индексирования, но производительность очень низкая
при использовании на машинах с жесткими дисками на магнитных дисках
(которые по-прежнему наиболее экономически эффективны), так как
происходит большое количество позиционирований головки при записи или
чтении данных.
В CouchDB используют B-деревья с функцией добавления (append-only
B-Trees — бинарное дерево, которое не нужно перестраивать при добавлении
элементов), что позволяет получить неплохую производительность при
записи данных на диск.
4.2. БД MongoDB
MongoDB (от "humongous") это масштабируемый, высокопроизводительный, документо-ориентированный сервер БД с открытым
исходным кодом. Одна из наиболее популярных NoSQL БД. Это нечто
среднее между key-value хранилищами (которые обычно быстры и
масштабируемы) и традиционными реляционными базами данных ( MySQL,
PostgreSQL и т.п.), которые предоставляют расширенные запросы и богатый
функционал. Написан на C++. Можно использовать в веб-приложениях.
Последние версии достаточно стабильны для использования в коммерческих
проектах. Проект разрабатывает команда специалистов на постоянной
основе, выходят исправления ошибок, появляются новые идеи по проекту,
используется немалым числом крупных интернет-проектов, среди которых
присутствует SourceForge. Написаны драйверы для популярных языков
программирования.
Особенности использования. Рассмотрим некоторые различия в работе
с MongoDB по сравнению с привычным SQL. Все примеры кода написаны на
26
JavaScript и могут быть проверены в интерактивной консоли. По аналогии с
{ doc_id: 153,
title: 'Some title',
body: '...A lot of text...',
author_id: 73,
date: 'Sun Oct 31 2010 03:00:00 GMT+0300 (MSK)',
additional: {
location: {
country: 'Russia',
city: 'Moscow' },
category: 'books' }
tags: ["tag1", "tag2", "tag3"]
}
тем, как в консоли mysql можно выполнять SQL-запросы, интерактивная
консоль MongoDB позволяет выполнять команды сервера БД, используя язык
JavaScript. По умолчанию используется движок SpiderMonkey, при желании
мы можем поменять его на V8. На официальном сайте можно найти onlineвариант консоли, который работает прямо в браузере, плюс к тому небольшое введение для начинающих. Начинать рекомендуется именно с этого.
Структура информации. Структуру данных в реляционных системах
на примере MySQL мы можем представить в виде следующей иерархии: База
данных -> Таблица -> Строка -> Поле + Значение. В MongoDB это выглядит
так: База данных -> Коллекция -> Документ -> ключ + значение. Таблицы в
реляционных БД должны быть жестко структурированы, в то время как в
MongoDB можно создавать документы произвольной структуры.
Пример документа в формате JSON:
Имеется полная свобода во вложенности ключей документа, что
избавляет нас от необходимости денормализации, как в SQL, т.е. нам не
нужно разносить одну сущность в разные документы. Как и в SQL, в
MongoDB есть индексы, причем полная их поддержка. Можно строить
индекс по любому ключу приведенного выше документа, в том числе по
вложенному country или по массиву tags. Можно делать составные индексы
по нескольким ключам документа. Правила оптимизации индексов для SQL
во многом подходят и для MongoDB и описаны в документации.
Выборка. Предположим, надо выбрать все документы из определенной
коллекции, у которых значение city равно "Moscow". В SQL нам приходится
27
прибегать к инструкции JOIN, т.к. в унифицированной системе наподобие
SELECT docs.title, loc.city FROM documents docs
INNER JOIN doc_location d_loc ON d_loc.doc_id = docs.doc_id
INNER JOIN location loc ON loc.loc_id = d_loc.loc_id
db.find({additional.location.city: "Moscow"});
// $doc - произвольный документ
// Вставить документ
db.insert($doc);
// Обновить документ или добавить новый если его не
существует, 2 варианта
db.save($doc);
// или
db.update({name: "Joe"}, $doc, true); // первый
аргумент - условие, второй - новый документ, третий вставка если исходный документ не найден
// Атомарная операция. Увеличить параметр counter на
единицу
db.update({name: "Joe"}, {$inc : {counter : 1}});
Drupal мы не всегда можем записать всю информацию в одну таблицу.
Например:
В MongoDB это делается так, учитывая что все хранится в одном документе:
По аналогии с JOIN мы также можем создавать ссылки на объекты
других коллекций, и нам не придется делать отдельные запросы для
получения связанных документов.
MongoDB хорошо справляется с большим количеством документов
(миллионы), скорость выборки, как и в SQL, оптимизируется индексами,
лимитами на количество получаемых документов за один запрос, как и в
привычных реляционных БД, индексы отрицательно влияют на скорость
записи. Есть знакомая нам операция EXPLAIN, выполняющая те же
функции, что и в MySQL.
Запись. В SQL есть оператор INSERT для добавления и UPDATE для
обновления записей. Запись в MongoDB выполняется при помощи трех
функций: insert – добавление, save – обновление, update – обновление.
Рассмотрим примеры:
28
MongoDB поддерживает несколько видов атомарных операций, полный
SELECT author, SUM(votes) FROM comments GROUP BY author;
список можно узнать из документации.
Мы можем использовать синхронный и асинхронный типы записи,
асинхронный по умолчанию, и он быстрее, т.к. приложению не приходится
ждать ответа от сервера. MongoDB рекомендуют использовать при большом
количестве одновременных запросов (более тысячи в секунду), особенно при
большом количестве операций записи. Судя по многочисленным отзывам,
именно быстрая запись - одно из главных преимуществ этой БД.
Агрегация. Решим задачу: из таблицы с комментариями надо выбрать
суммарное количество голосов за каждого автора. В SQL это решается
довольно просто:
В MongoDB реализация более сложная, но и более мощная. Называется
она Map/Reduce.
Фактически, это альтернатива оператора GROUP BY и функцийагрегаторов (SUM, MAX, MIN, ...) для NoSQL (в нашем контексте). В общих
чертах эта операция происходит следующим образом.
1. Выбираются необходимые документы из БД. Поскольку это обычный
запрос на выборку, к нему подходят общие правила оптимизации, такие как
добавление индексов и лимитирование количества выбираемых данных.
2. На языке JavaScript создается функция map, которая проходит по
каждому документу, найденному на предыдущем шаге, и собирает
необходимую информацию для агрегации.
3. Далее вновь на JS создается функция reduce, которая получает данные
маппинга, сгруппированные по какому-то определенному в функции map
ключу. Происходит агрегация данных.
4. При желании можно определить функцию finalize, которая будет
запускаться после reduce и производить финальные действия над данными.
Получаем результат агрегации и используем его в нашем приложении.
29
Рассмотрим на примере последовательность этапов:
{ text: "lmao! great article!",
author: 'kbanker',
votes: 2
}
// Ключ - имя пользователя автора;
// Значение - количество голосов за текущий
комментарий.
var map = function() {
emit(this.author, {votes: this.votes});
};
reduce('kbanker', [{votes: 2}, {votes: 1}, {votes: 4}]);
var reduce = function(key, values) {
var sum = 0;
values.forEach(function(doc) {
sum += doc.votes; });
return {votes: sum};
};
1. Документ - коллекция комментариев следующей структуры (JSON):
с комментарием автора "kbanker" с двумя голосами.
2. Функция map (этап маппинга)
Как мы отметили ранее, map - это функция на языке JavaScript, которая
проходит по каждому документу и собирает необходимую информацию в
формате пары ключ -> значение. Генерируется эта пара при помощи вызова
операции emit:
3. Функция Reduce (этап агрегации)
В каждый вызов функции reduce (по одному на ключ) поступают два
аргумента: ключ и массив значений, собранные на этапе маппинга. В нашем
примере для автора "kbanker" вызов reduce будет примерно таким:
Теперь опишем функцию для подсчета голосов:
30
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]