Основная идея в том что код выполняется как можно ближе к данным, и даже больше, он постоянно мигрирует между разными машинами, старясь быть ближе к ним, без остановки основного вычислительного алгоритма. В общем это continuations с переносом состояния между нодами. Это в пику подходу map-reduce когда у нас именно данные гоняются между нодами. Код все таки меньше места занимает, должно быть быстрее, это не гигабайты данных по сети гонять.

Рекомендую посмотреть презентацию:

Swarm: Distributed Computation in the Cloud from Ian Clarke on Vimeo.

Реализовано на Scala, хотя думаю что никто не мешает реализовать идею на другом языке, и тем более уж под JVM. Автор, правда, утверждает обратное, но причина в том что в Scala все уже есть для этого, уже сейчас, и для прототипа как раз подходит. Ну и насколько я понимаю подобную оптимизацию можно реализовать в GridGain и сейчас, указав ноды для MR, но тут идея более интересная.

Все о том что для сложноструктурированных данных классический подход (со всеми нормальными формами) не всегда работает. Т.е. иногда создать отдельную таблицу в БД под каждый тип сущности и установить связи просто не реально, ну например сколько их будет в случае большого магазина, например Озона? С десяток категорий с совершенно разными товарами, где общих полей мало, лишь поля цены, названия и пр. В общем в любом случае приходится придумывать что-то универсальное. Так вот, чтобы не изобретать свой велосипед, можно посмотреть в сторону технологий Semantic Web.

Что есть полезного:

• RDF – чрезвычайно простой и универсальный формат, а именно структурированеи в виде графа (и RDF это не XML)
• OWL – язык для структуризации, описания предметной области, в том числе вывода неявной информации, зависимостей, связей и пр.
• SPARQL – язык запросов к rdf данным

Хотя, если честно, эта область во-первых все еще только развивается, а во-вторых не все так просто и очень высокий порог для входа. Но чтото уже начинает вырисовываться.

PS а отчет советую прочитать

Но ведь Оракл используют независимо от того нужна ли нам реляционность, просто по привычке, и потому что «все так делают«. Я за все свое время редко встречал нормализованные структуры, и даже больше, часто встречал таблицы БД с колонками вида col_1, col_2, col_N и пр. нарушениями всех форм, когда также разрезали таблицы на отдельные, в том числе отдельные инстансы БД. Встречал также когда в Oracle складывали черт знает что, когда использовали как хранилище лога операций, десятки гигабайт логов, ну и т.д. И никакого серьезного положительного эффекта от реляционных возможностей во всех этих случаях не было.

Не знаю может это мне так всегда везло и в других проекта все всегда «красиво», не нарушается ни одной из «нормальных форм» и пр, но у меня опыт вот такой.

Под реляционностью в данном случае я подразумеваю не только то что данных хранятся в виде таблице (с заранее четко оговоренным списком атрибутов). Я имею ввиду все что вертится вокруг этого: нормальные формы, внешние ключи, связи и ограничения, acid, собственно реляционная алгебра и все прочее предназначенное для облегчения хранения и соблюдения целостности структурированных данных.

В общем я не сторонник использования реляционной БД всегда и везде, на любой чих. Это хорошая технология, спасающая в огромном множестве случаев, но RDBMS это совсем не серебряная пуля.

Поэтому хотел бы обратить внимание на другой тип баз, на колоночные БД.

Основная идея колоночных БД

Вообще базовая идея колоночных БД всего лишь в том что физически (на жестком диске) данные хранятся в другом порядке. Т.е. если обычная (рядная) БД будет все хранить построчно, то в данном случае по колонкам, в начале все данные первой колонки, потом второй, потом третьей и т.д. В рядном харнении все ячейки строки хранятся рядом, и обычно могут быть прочитаны с диска за одну операцию чтения. В колоночной наоборот, значения ячеек разнесены на разные блоки, и за одну операцию мы читаем несколько подряд идущих значений идной колонки.

Казалось бы мелочь, но все это не просто так, и действительно подобная организация хранения данных на самом деле не такое уж из ряда вон выходящее дело. И тот же Оракл, да и прочие РСУБД, используют и этот подход, как минимум для хранения блобов. Как правильно указали мне в комментариях на самом деле есть и традиционно реляционные СУБД, хранящие данные в колоночном виде, все таки одно другому не мешает, но это скорее редкость (об исключениях см. в списке примеров и в комментариях к записи) и все равно они обладают почти теми же свойствами (реляционность скорее из маркетинговых побуждений), а разделение на реляционные и неряляционные будет более глобально, поэтому я позволил себе разделить этот мир именно по критерию рядного vs колоночного хранения данных.

Дело в том что тут скорее задается начальный вектор архитектуры БД, а те задачи в которых востребован такой способ хранения также имеют свои специфические потребности, поэтому эта мелочь выливается в довольно интересные системы.

Перечислю что у нас обычно присуще колоночными базами данных (хочу подчеркнуть что обычно, но не все это обязательно каждой конкретно):

Позднее связывание

Данные у нас хранятся в виде группы полей (строка в таблице), так вот при обработке этой группы можно всегда использовать всю строку (все ячейки), или лишь ту колонку которая нам нужна в данный момент. В случае традиционной БД она хранит и читает всю строку целиком, они лежат подряд, никуда не денешься, колоночная же читает данные лишь из нужной колонки, и лишь только когда находит подходящую [по критерию] строку дочитывает для этой строки значения из недостающих колонок.

Например для запроса select col_1 from table where col_2 = 10 традиционная БД будет читать все строки, проверяя каждую на условие во второй колонке, и для совпавших вернет значение первой ячейки этих строк. При этому если у нас в таблице десяток колонок то будет прочитано куча лишних данных (в данном примере что-то около 80% мусора). Чтобы такого перерасхода вычислительных ресурсов не было нужно добавить индекс, который сразу ограничит набор нужных строк. Этот индекс и есть та самая дополнительная колонка, через которую пройдет позднее связывание в традиционной БД. В случае колоночной БД будет читаться лишь 2я колонка, и при совпадении условия к ней будет привязано значение из первой колонки. Очень похоже на то что у нас вся таблица состоит лишь из индексов по колонкам.

Как результат это то что мы можем иметь огромное количество колонок. Если для реляционной БД больше пары десятков колонок уже начинаются проблемы (неэффективное использование чтения с диска и памяти), то для колоночной таблицы имеющие сотни и тысячи колонок это вполне нормально.

Получается что рядная БД удобна когда нам обычно нужно использовать данные всей строки (в условиях и связях при селекте, апдейте и пр.), а колоночная когда данных много, но обычно используется лишь небольшая их часть.

Разная структура данных

Связанные данные хранят в одной таблице (не забываем что при этом можно использовать огромное количество колонок), а связи между таблицами здесь не приживаются, по многим причинам. Но! здесь можно не боятся хранить сложные структуры в ячейках, в том числе вложенные списки, подтаблицы, структуры XML, JSON и пр.

Размер отдельной ячейки часто можно не обращать внимания, пусть даже каждая ячейка столбца имеет свой размер, тут это не особо сильно влияет, в итоге не обязательно изначально жестко типизировать колонки таблицы, пусть в одной строке будет int, в другой string, а в третьей бинарная картинка в несколько мегабайт, и весь этот разброд может быть вдоль одной колонки, если, конечно, такое востребовано. К тому же вполне мы спокойно храним null значения, они просто пропускаются, тогда как рядная БД никуда не денется – место на диске займет, но оставит его пустым, но при обработке дополнительные затраты.

Одним из применений этого подходя является ответвление БД имеющих всего одну колонку, помимо ключа, в которой и хранится все что нужно. Внешне все это выглядит как огромный HashTable. Такие БД еще называют key-value storage или document oriented database.

Сжатие данных

Очень распространенная штука это использование сжатия данных. Тут возможно не заслуга использования колоночности, а больше того как именно такие БД используют, но факт что это популярно и дает вполне неплохой эффект, при этом для того класса приложений где это нужно обычно лишь при незначительной потере в производительности.

Большие объемы данных

По вышеуказанным причинам получается что в такой структуре удобно хранить огромные объемы данных, а шардинг и реплиция обычно из коробки, как само собой разумеющееся. Возможно это и не следствие колоночноый архитектуры, а даже наоборот причина, но в общем будем иметь ввиду что «большие объемы» и «колоночное хранение» идут бок о бок. Конечно же тут сразу появляются различные возможности для параллельной обработки хранимых данных, например используя подход mapreduce и пр.

Доступ

Подобная БД обычно востребована при хранении и обработки больших объемов данных, поэтому в данном случае и язык запросов может быть весьма далек от стандартного SQL, и даже вовсе не иметь оного. И конечно никакой тебе реляционности, да и транзакции так себе поддерживаются. Доступ к данным будет через какойто специфичный API, что с другой стороны позволяет более тесную интеграцию приложения и хранимых данных.

Но получается что средства доступа по универсальности и скорости разработки/использования выглядят обычно хуже возможностей предоставляемых Oracle и компании.

Сравнение с RDBMS

RDBMS:

• соблюдается целостность данных (foreign keys, транзакционность)
• четко структурированные данные
• запросы по всей структуре БД, используя стандартизованный язык
• результат запроса это небольшой (относительно БД) кусок данных
• быстрое извлечение нужной структуры (в том числе быстрая реализация запроса)

Колоночные БД:

• хранят большие объемы данных, упрощеный шардинг, репликация и пр.
• данные гораздо менее структурированы
• данные обрабатываются большим блоком (параллельно, massive parallel processing), или вообще сразу вся база
• оптимальным будет индивидуальный подход к обработке, тесная интеграция с данными
• худшая (ручная) поддержка целостности данных

Где стоит использовать

Может хранить огромные объемы слабоструктурированных данных, спокойно смасштабируется на большой кластер и запросы будет обрабатывать параллельно по всему кластеру.

Здесь достаточно просто хранить большие блоки данных, документов (в документ-ориентированных БД) и/или сложных структур. Также довольно распространено хранилище данных вида «Ключ-Значение» (aka Properties Pattern, Хэш-таблица) с большими группами которых идет различная работа. Отлично подходит для задач, которые я привел в записи «Хранилище для обработки данных«. Ну и также это хранилище логов и прочее в этом духе. Особенно хорошо если данные лишь дописываются, а не изменяются существующие.

Больший выигрыш будет если храним много, но в реальных операциях используется лишь часть колонок, или вовсе одна, помимо идентификатора конечно.

При таком хранении гораздо проще бежать вдоль столбца, выполняя нужные операции. Причем операции лучше независимые, или групповые, и когда они затрагивают большой блок хранимых данных. К примеру брать большими кусками и агрегировать результат – самое оно. Это такие задачи как обработать лог отдельных операций, и просуммировать результаты в течении каждого отдельного периода (что вообще запросто превратить в mapreduce обработку). В случае лога веб-серверов это может быть агрегация посещений по браузерам (т.е. используется отдельная колонка). Или иным образом разбивая данные независимо, и обрабатывая эти сгруппированные данные параллельно, например mapreduce’ом.

Где не стоит использовать

Не стоит использовать когда нам нужна именно классическая реляционная структура, и когда у нас данные (и связи) постоянно меняются. Под «меняются» я подразумеваю изменение и удаление существующих данных, смену связей между ними. Хотя если данные лишь дополняются, то уже стоит подумать.

Так же не подойдет если у нас много колонок, и мы оперируем в основном всей строкой, нет особого смысла менять тип БД. Хотя в большинстве случаев, как я уже упоминал, значения в нескольких колонкам, которые нам нужно обрабатывать одновременно, даже удобней объединить в общую структуру, к примеру в список имя/значений, или превратив в xml, yaml или json, по вкусу.

Также не пойдет вариант когда операции проводятся лишь небольшом объеме базы, здесь мы просто не получим никакого выигрыша (или точнее наступим на грабли колоночных БД), и больше вероятность что хранение по строкам будет гораздо удобнее.

Ну и конечно не подойдет когда нам нужны классические SQL запросы. Что-то «в стиле SQL» они часто имеют, но это уже на самом деле другой подход и по другому выполняется.

Реализации

HBase – представляет собой часть Apache Hadoop, можно сказать классическая реализация Гуглового Bigtable, рассчитана в первую очередь на большие объемы данных, и на хранение этих данных в большом кластере. Типы данных ничем не ограниченны. Я именно именно на hbase ориентировался когда приводил приводил основные тонкости/отличия, но не ограничивался им.

Из возможностей: сразу учтено что каждая колонка может иметь несколько ячеек (получается что помимо того что в строке несколько строк, в колонке тоже несколько ячеек, этакое минидерево, для хранения списочных и связанных данных), может хранить любые бинарные данные, может хранить одновременно несколько версии (версионность из коробки), поддерживает фильтры Блума, rest интерфейс доступа (помимо java api) и пр.

Но, как минимум в данный момент, не имеет индексов, кроме как по ключу. Если честно, как и сам Hadoop эта база еще развивается, поэтому БД в данный момент достаточно сырая.

Прочие

CouchDB

реализация на Erlang. Не совсем колоночная, это документная БД (document oriented DB), но по сути внутри одна большая колонка, и все приемы соответствующие. БД, конечно, не привязана к определенной платформе (т.е. к Эрлангу). Запросы пишутся на Javascript(!) в виде mapreduce операций, доступ через REST. Благодаря отказоустойчивости самого Erlang’а – очень интересное решение

Hipertable

реализация bigtable на С, изначально как основная альтернатива Hadoop HBase, именно так себя позиционировали. Причем хранение так же было организовано поверх Hadoop HDFS. Как там сейчас обстоит дело не знаю.

The Cassandra Project

реализация от Facebook, тоже базируется на идеях Google BigTable и поэтому похожа на HBase.

Project Voldermort

распределенный key-value storage, на java.

Kdb+

коммерческая БД и язык обработки, заточенные под time-series data. Это всевозможные логи, биллинг, биржы и пр. Язык обработки имеет очень сильную базу для обработки массивов (БД в данном случае является отдельным огромным многомерным массивом) и особенно распределенных во времени. В результате многие узкоспециализированные задачи (всяческие кубы, временные данные) выполняются в разы быстрее. Как минус – БД и все вокруг нее являются излишне закрытыми от людей извне

LucidDB

Open Source реляционная СУБД с основой на колоночной структуре. Расчитывается в первую очеред на аналитику, bi и пр.

Sybase IQ

Еще одна реляционная колоночная СУБД, для нужд аналитики. В этот раз коммерческая

Amazon SimpleDB, Google BigTable, Yahoo Everest

закрытые внутренние реализации от монстров интернета.

Ссылки

• PDF – «Column-Stores vs. Row-Stores: How Different Are They Really?»
• Debunking Yet Another Myth: Column-Stores As A Storage-Layer Only Optimization (и предыдущие в цикле статей)
• Is the Relational Database Doomed?

Самый известный, наверное, подход к cloud вычислениям это mapreduce, и он прекрасно здесь организован. А так как этот mapreduce не всем понятен, да и не всегда нужен полностью, то здесь помимо него предлагается своя реализация java.lang.concurency.ExecutorService который разбрасывает переданные вычисления по кластеру.

В отличии от того же Hadoop здесь не гнались за обязательной возможностью обрабатывать терабайты данных за один проход. GridGain удобней будет для длительных вычислений на объемах гораздо поменьше, по хорошему это то что можно передать между нодой в одном List’е, что, возможно, даже практичней. Я не хочу сказать что для больших объемов эта платформа не подойдет, просто при большом объеме данных (а не вычислений над ними) все упирается уже в хранилище данных, и они этим сознательно не занимались, но в случае когда это нужно – можно всегда использовать и внешнюю БД и даже Hadoop HDFS/HBase.

Для многих случаев это очень удобный вариант, отличная альтернатива hadoop’у, ну в самом деле не обязательно у нас что-то грандиозное, вполне может быть у нас пара тысяч независимых операций и cloud из нескольких серверов, и этот самый простой способ распараллелить все. Если основной упор на вычисления, например параллельно обработать несколько тысяч url’ов, на каждый по 1-2 минуты, то GridGain предлагает очень удобное подспорье. И, кстати, очень просто организуется архитектура для случая когда есть несколько gui клиентов, на слабых компах, а все вычисления для них производятся в cloud.

Как я уже говорил платформа давно развивается (кстати нашими соотечественниками), хорошо документирована, внутренняя часть уже вполне стабильна, и к тому же хорошо развиты инструменты мониторинга, алгоритмы балансировки, восстановления после сбоя и пр. и пр. Для ознакомления стоит посмотреть скринкаст «Grid Application in 15 Minutes»

Вcе элементы этого процесса, конечно, должны где то хранится. И если конечную информацию можно структурировать, завести с десяток таблиц в БД, настроить связи и складывать туда, то входная информация по определению у нас не структурирована, ну или, как минимум, слабо структурированная. Если делать сложную структуру то из-за специфики нашей задачи нам будет очень сложно отследить целостность данных. К слову о сложности работы с такой структурированностью замечу что я попытался было нарисовать это подход, но не смог сделать чтобы это было внятно, без всего лишнего.

Поэтому нужно придумывать какое то простое и универсальное решения для этой задачи. Одна из них это структура когда у нас для всего выделена одна таблица, в первые колонки которой заливается начальная структура. Далее они обрабатываются нашей программой для структурирования, и результат складывается рядом, в следующие колонки. Причем если результат мы получаем не за один шаг, что чаще и бывает, то в таком случае мы последовательно выполняем все шаги, складывая новые данные правее от текущих.

В итоге получаем примерно такие шаги:

1. (первая колонка) список URL
2. выкачиваем документ по этому адресу, складываем в колонку 2
3. убираем весь мусор (стили, js, реклама и пр.) из html и кладем в колонку 3
4. вырезаем текстовые контент (убираем навигацию, и пр.), результат в колонку 4
5. делаем PDF, результат в колонку 5

Рис 1. Таблица с несколькими колонками

Рис 2. Таблица с вертикальной обработкой

Мы складываем в колонку справа если у нас идет обработка 1 к 1 (см. рис 1), если же у нас идет какая либо вертикальная агрегация (см. рис 2), то новые данные стоит записывать под текущим блоком, в той же колонке, что есть более универсальный подход. В случае СУБД у нас получается для первого варианта таблица с колонками block_id, data_id, col_1...col_N, для второго варианта block_id, data_id, value. Где

• block_id это у нас идентификатор обрабатываемого блока,
• data_id идентификатор элемента данных, которым мы оперируем,
• и col_1..col_n или value это те данные которые нужно обработать.

В случае файловой системы получается только второй вариант, идентификатором тут будет путь к файлу. Следуя этим подходам в Apache Hadoop есть HDFS для варианта хранения в файлах, и HBase для хранения в виде таблицы.

Наверное сразу возникает претензия что у нас всегда данные если не дублируются, то остается слишком много временных данных, старые на каждом этапе остаются, а новые (выведенные из предыдущих) складываются рядом. Зачем это? Затем что иначе нам нужно следить за транзакциями, усложнять процесс распараллеливания обработки. Гораздо проще складывать рядом, и когда придет время (например когда мы дойдем до конечного шага), можно будет выкинуть все лишнее. Если мы можем позволить себе это, то так получается гораздо удобнее. Дополнительные бонусы тут в том что на любом этапе мы можем переиграть обработку заново (как замена rollback’а) или сделать новую «ветку» обработки, выполнив другие функции. И, как минимум, всегда можем проследить историю операций.

Но еще более важно то что мы получаем независимые функции. Почти функции в том виде в котором они приняты в функциональном программировании. Т.е. у нас входные параметры и есть результат, и функция не должна больше ничего менять, не должна трогать входные данные, и не зависеть ни от каких данных кроме этих. Каждую из них может разрабатывать отдельный разработчик, не сильно заботясь об общей архитектуре приложения, и даже на совершенно разных языках можно писать, выбирая тот который больше подходит для конкретной задачи, которая к тому же имеет очень четкие границы.

где:
α — доля вычислений которые могут быть произведены только последовательно,
p — размер кластера (ну или количество процессоров/вычислителей).

И чем меньше α тем ближе масштабируемость к линейной. При 10% последовательного кода, к примеру, выходит что больше чем 100 компьютеров использовать не имеет никакого смысла, никакого серьезного прироста не будет, хоть на 1000 запускай. И добиться этих 10% не всегда просто.

Понятно что для того чтобы мы могли ускорять программу добавляя процессоры она должна иметь минимум таких обязательно последовательных участков. Это, кстати, один из стопоров увеличения количества ядер, так как сейчас очень мало программ которые используют параллельное вычисление, α у большинства в районе единицы, и тут как не добавляй ядра, программа не заработает быстрее.

Так вот MapReduce это такой подход построения архитектуры при котором просто не получится написать не параллельное приложение, α будет близко к 0. Алгоритм разбивается на 2 слоя параллельных операций и, в итоге, очень хорошо масштабируется. Надо заметить что алгоритм в виде функции map+reduce может быть гораздо медленней чем он же в стандартном (имеющим последовательные участки) виде, но стандартный алгоритм будет иметь предел после которого добавляя процессоры мы не выигрываем в производительности, с map+reduce вариантом этот предел почти недостижим. Дополнительным плюсом здесь является независимость, и при сбое отдельного участка его можно вычислить заново, не перезапуская весь процесс.

Map в данном случае независимо обрабатывает входящие блоки данных. Но хоть сами входящие данные не зависят друг от друга, то результат обработки часто зависит от их связей между собой. Обработкой первоначально независимой информации занимается соответственно Map, он подготавливает блоки данных для обработки, обработкой итоговых, уже зависимых друг от друга, данных займется Reduce.

Один из классических примеров использования mapreduce – подсчитать распределение слов. В этом случае map обрабатывает входной текст, как независимые блоки. На выходе получаем пары «слово — кол-во употреблений» . В простейшем случае map не анализирует текст, а лишь разбивает по пробелам, в итоге из текста 5 раз содержащего слово «hello» на выходе будет не пара «hello — 5», а 5 пар по «hello — 1». Вот этот выхлоп уже связан друг с другом, и reduce обрабатывает эту связь. Ему на вход приходят блоки с одинаковым ключем пары, он в свою очередь суммирует цифровые значения этих пар. Поэтому обоих случаев наших «hello — x» он выдаст «hello — 5». Основную работу тут выполняет reduce. Такой, не совсем простой, способ подсчета количества слов полезен когда объем анализируемого текста измеряется гигабайтами (и более). Map выдаст огромный файл отсортированных пар «слово — количество» Так как он отсортирован то пробегая по нему достаточно просто вызвать reduce для всех групп с одним ключом, и получить суммарное количество для каждого из слов.

Хочу заметить что mapreduce, конечно, не панацея, часто он совсем не оптимален, и для малых объемов вообще не имеет смысла, но это самое простое и универсальное решение для масштабируемых алгоритмов, хорошо подходящий для различных data mining решений.

Ну, во-первых, благодаря стандартизации упрощается работа всех связанных систем, грязные данные тянули за собой слишком много костылей во внешних системах, что лишь увеличивало степень неопределенности. А вот после очистки данных уже можно найти тысячи положительных эффектов, все зависит от конкретной ситуации. От снижение количества искажений при анализе клиентской базы, до возможности проведения таких BI операций, о которых до этого и речи быть не могло за отсутствием нужных данных. В конце концов мы будем точно знать кто наши клиенты, а не предполагать основываясь на куче неверных данных.

Основные блоки данных

Приведу список основных элементов данных и то что можно получить на из основе.

Адрес

1. Дает возможность сделать географическую привязку клиента, для:
   1. Анализ эффективности деятельности филиалов, проанализировав объемы клиентов в различных зонах.
   2. Анализ действия рекламной компании, сравнивая области с различным уровнем объема уличной рекламы по разным частям города.
   3. Сегментация уровня дохода/социального положения клиентов по стоимости жилья. Как минимум можно составить характеристики по районам города, а по хорошему еще составить отдельный список элитного жилья, и наоборот.
   4. Обнаружение аномалий в распределении. К примеру повышенный объем страховок в одном из регионов относительно других регионов, при прочих равных факторах, возможно говорит о наличии неучтенного повышенного риска для жителей данной области (т.е. жители чего то опасаются, лучше узнать чего именно, пока не поздно).
   5. Определить где можно открыть новый филиал/банкомат/магазин и пр.
2. Обнаружение связей:
   1. соседи и друзья
   2. семья
   3. коллеги, при анализе рабочего адреса
3. Дополнение недостающей информации (например индекс,который, как известно, никто не заполняет правильно), что может устранять неоднозначности адреса, ускорять доставку корреспонденции и пр.
4. Удаление из базы мусорных записей.

Имя

1. Определение пола. Нужно для:
   1. Формировании исходящей корреспонденции. Может и мелочь, но меня лично раздражает эта запись в поздравительных письмах типа «уважаемый(ая)». Ты или определись с моим полом или не делай вид что письмо совсем уж персональное.
   2. Сегментация по полу при исследованиях
2. Уточнение семейных связей (используя совместно со значениями адреса и возраста)

Телефон

1. Дополнение недостающей информации (код города из адреса или наоборот)
2. Обнаружение связей (по домашнему и рабочему телефонам)
3. Определение сферы деятельности по рабочему телефону (используя справочники организаций)

Прочие поля

Название компании в которой работает клиент дает установить связи, определить уровни доверия, платежеспособности, доходов и пр. и пр. Тут больше зависит от того какие имеются сторонние базы организаций. Кстати, название компании и должность одни из немногих полей которые чаще всего позволяют заполнить произвольным образом, и, как следствие, требуют тщательной очистки и насыщения, иначе не могут в полной мере использоваться при анализе клиентской базы.

Связи между клиентами

Зачем нам знать связи между клиентами? Допустим мы почистили данные и нашли связи между людьми, но для чего нам выяснение всяких связей и пр.? Бесспорно, это хорошо что мы выяснили зависимости, но как на этом заработать?
Приведу пару примеров, навскидку:

• Анализ нового клиента. Т.е. известное «скажи мне кто твой друг и я скажу кто ты» в действии.
  • К примеру у нас появляется новый клиент, молодой человек или девушка, по которому мы определили что он родственник нашего существующего vip клиента, и даже то что это сын или дочь. В таком случае нам лучше пометить и этого клиента как VIP, или ввести тип вроде VIP-related. Вполне возможно что если ему не понравится сервис, он может отговорит и своего отца пользоваться нашими услугами. Да, дети иногда имеют хорошее влияние на своих родителей, да еще и с учетом юношеского максимализма. В общем лучше подстраховаться сразу.
  • С другой стороны таким образом можно вычислить родственника (или соседа/друга) нежелательного клиента, или мошенника.
  • Ну конечно дополнительные критерии для скоринга.
• Следующий вариант это коллеги. Если в одной организации есть несколько лояльных клиентов, то такую организацию будет гораздо проще поставить на какое либо корпоративное обслуживание. Опять же будет возможность улучшить лояльность компании, которой делается соответствующее предложение, предложив перед этим какой то бонус найденным (но ничего не подозревающим) «инсайдерам». Но это уже в сторону вирусного маркетинга и пр., тут главное что нашли точку куда можно приложить силу.

На самом деле тут можно придумать много очень хитрых вариантов использования, все зависит конкретно от тонкостей текущего бизнеса.

Да, и еще, тут еще интересный момент есть: для обнаружения связей между клиентами можно воспользоваться базами «Одноклассников» и «В Контакте». Если у нас не трудно достать базы не только всех гос. структур, но и вполне серьезных коммерческих организаций, банков и операторов сотовой связи, то база «Одноклассников» вообще не проблема, рано или поздно базы социальных сетей будут в продаже. Кстати, в случае БД социальных сетей типа «Одноклассников» все даже проще, так как доступ ко всем связям есть извне, через web, не надо прямого доступа к серверам. Я более чем уверен что уже есть софт который вытаскивает всю нужную информацию с этих сайтов и сохраняет ее в нужном виде. В конце концов вполне реально самостоятельно сделать парсинг подобных сайтов и последующее насыщение профайла, по мере надобности, так даже правильнее будет. Причем это будет вполне законно, в отличии от краденных баз.

Поэтому проведем экперимент, сравним алгоритм по умолчанию, и пару считающихся лучшими алгоритмов. Выберем, так сказать, the best of the best среди хэширования Конкретно для меня, это равная вероятность состояний отдельных бит, в 32х битном целом. Т.е. чем ближе вероятность появления «1″ в каждой из позиций к вероятности 1/2 тем лучше.

И так, помимо алгоритма по умолчанию решил попробовать SDBM:

public int hash(String val) {
    int hash = 0;
    for (char c: val.toCharArray()) {
	hash = c + (hash << 6) + (hash << 16) - hash;
    }
    return hash;
}

и DJB2:

public int hash(String val) {
    int hash = 0;
    for (char c: val.toCharArray()) {
	hash = ((hash << 5) + hash) + c;
    }
    return hash;
}

и подсчитал отклонение от середины для случайно сгенеренных слов (как коротких так и длинных), на английском, русском, смешанном, смешанном+случайный регистр.

И вот график среднего отклонения, по этим четырем тестам:

По оси X - номер бита, по Y отклонение от равномерного, среднее для 4х тестов.
Видно что алгоритм по умолчанию, что DJB2 нормально работают лишь для первых 15 бит, дальше отклонения все больше и больше (на практике понижается вероятность заполнения бита по мере удаления от начала) В Java же int является 32х битным, поэтому в таком случае лучше использовать SDBM, который гораздо меньше отклоняется.

Да, кстати, для чисто русского текста результаты всегда получше чем для чисто английского и даже их смеси.

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

PS: это для моих потребностей важна именно равномерность, не буду утверждать что для всех остальных случаев SDBM алгоритм лучше/быстрее/пр., но вероятно что именно так.

Т.к. вся архитектура обработки состоит из небольших функций, то обработку можно легко распараллелить на кластере. К тому же облегчает разбивка на отдельные куски и восстановление после сбоя. Используя распределенную ФС мы разбиваем данные на небольшие кусочки, с каждым из которых и работает отдельный элемент кластера.

Так же эту идею можно встретить под названием Split/Aggregate. Т.е. суть в том что входные данные (неважно какого размера) разбиваются на отдельные элементы (этап split), к примеру построчно, каждая строка как отдельное значение для обработки. Эти блоки строк раcпределяются по кластеру для обработки, где для каждой строки вызывается функция обработки (map). Результат выполнения опять объединяется (reduce/aggregate) в выходной файл. Если нужно, то данные сохраняются отсортироваными в определенном порядке, к примеру по внешнему ключу.

Область применения

Сам подход очень хорошо подходит для длительной обработки больших объемов данных, причем когда нам не требуется определенная последовательность процесса или получение результата по мере поступления новых данных. Т.е. если у нас в наличии пару гигабайт данных для обработки и нам нужен конечный результат обработки, то это отличный вариант, но если у нас тот же гигабайт постоянно поступает небольшими кусочками, и мы должны их тут же отправлять на обработку, ожидая результат как можно скорее, то удобней иной подход, нежели чем MapReduce и Hadoop в частности.

Например это очень подходит когда нам нужно обработать стопку csv файлов. Ну или один, но большой. В каждой строке несколько колонок с данными, на основе этого получаем результат, тоже в csv. Так вот обработку такого файла легко распаралелить на нескольких машинах, построчно, или блоками, скажем по 100 строк, равномерно раскидать по серверам, обработать, а потом результирующие строки склеить в выходной файл. Если надо можно еще отсортировать чтобы было в том же порядке что и во входящих данных. Все это требует гораздо меньше ресурсов чем сама обработка данных.

Есть мнение что при обработке данные не стоит перегонять в текстовые файлы, пусть все хранится в БД, и читать оттуда поблочно, тут же складывая полученные результаты. В этом тоже есть свои плюсы и минусы, тут каждый решает сам, в зависимости от задач. Распределенная ФС, кстати, очень хорошо заменяет БД как центральное хранилище данных, а привести в структурный вид, удобный для БД можно уже и отдельным этапом (например отдельной задачей mapreduce). Хотя загрузку и средствами БД можно легко и быстро сделать.

Пример алгоритма

Приведу один простой пример, может понятней будет.

mapNumbers(«1, 4 and 3″)

Пусть он выделит все цифры в тексте, например регэкспом \d+, не суть важно. В нашем случае выдаст пары {num:1, num:4, num:3}, где num – имя ключа, а 1,4 и 3 – его значения

reduceSum(num[])

На вход придет список пар с одинаковым ключем, в нашем случае ключ num. Пусть метод выполняет суммирование всех цифр для переданного списка пар. Т.е. в нашем случае ему на вход придут те три пары num:#, и он произведет суммирование 1 + 4 + 3, выдав 8

На самом деле функции иногда в сотни раз сложнее, но суть та же.

Реализации MapReduce кластера под java

Apache Hadoop

Apache Hadoop – одна из основных реализаций системы для такой обработки. Поддерживает как MapReduce так и распределенную файловую систему (HDFS). Подпроектом еще идет как минимум реализация BigTable. map/reduce могут быть написаны не обязательно на Java, вполне подойдет все что может запускаться под этой ОС. Кстати, базовой ОС является Unix, хотя как я понимаю под Windows тоже работает, через cygwin.

Недавно Yahoo! сообщил что они успешно используют Hadoop для обработки объемов порядка 300 терабайт на кластере из 10 000 серверов. Из чего можно сделать вывод что для повседневных задач по обработки текущих данных Hadoop хватит с лихвой.

GridGain

GridGain скорее рассчитан(но не ограничивается этим) не на обработку терабайтов данных, а разбиение на кучу задач, не важно каких. Больше подходит название SplitAggregate. Т.е. мы задаем объем задач, GridGain раскидывает это по кластеру, и далее передает нам результат. И здесь уже хоть сразу все через БД делай, хоть используй поверх распределенной ФС (от того же Hadoop даже), не суть важно. Авторы к примеру предлагают так юнит тесты запускать, т.е. разбиваем по методам на кластер, и все они параллельно тестируются. Надо это попробовать, если окажется десяток лишних компов под рукой

А еще эти товарищи очень не любят писать лишний код сами, а предпочитают интегрировать готовые, зарекомендовавшие себя решения. Что я считаю очень правильно, зачем лишний раз изобретать велосипед? Так вот, я к тому что система получается очень гибкая, красиво написанная, настраиваемая в спринге и интегрируется с кучей прочих около grid решений.

Cloud Computing

В свете последнего расцвета cloud computing, сервисов типа Amazon S3 и EC2 все это становится довольно интересным. Сейчас можно не ждать несколько часов для обработки, когда можно запустить все это на кластере из сотен серверов, получить результат через несколько минут заплатив за аренду этого кластера совсем небольшую сумму.

В общем, расскажу на примере одной недавней задачки.

Вот возьмем такую задачу: в анкете есть поле, заполняемое названием магазина, а организации, к примеру, надо делать отчет по покупкам в определенных магазинах. Ну хотя этот отчет можно на основе других данных сделать. Да на самом деле неважно, зачем эти данные могу понадобиться, они точно требуются, и в нашем случае важно то, что они должны быть обрабатываемы и понятны.

Начинаем разбирать… Фантазия людей безгранична: вот возьмем к примеру Евросеть, как название только не напишут, могут как «ЕВРОСЕТЬ ЦЕНТР», или «ЕВРОСЕТЬ (ООО ЦЕНТР ХАБАРОВСК)». Ну с этим все более понятно, есть вхождение слова Евросеть и значит нашли магазин.

Следующий вариант это написание типа «Evroset». Сразу не найдем, тут нам надо сделать обратную транслитерацию. А есть, кстати, тот же DIXIS, для которого получается надо делать обратную операцию.

С учетом транслитерации и самих ошибок начинаются проблемы, потому люди пишут и как «Evroset», и как «Euroset», как «euroset.ru», да и в общем-то тоже самое для русского. К тому же бывают опечатки, или просто незнания правильного написания. «Техносила» может быть написана как «TECHNOSILA», или как «TEHNO SILA» (буковки C вообще нет), и т.д. А как вам «ЦИФРАГАД»(видимо не угодил он покупателю) и «ЦИФР0ГРАД» (Ноль вместо О, не иначе как кулхаксор писал), или «ЦЫФРАГРАТ» (ага, афтар жжет)?
Вывод такой: искать по вхождению не имеет смысла. Перебирать все варианты возможных ошибок, фантазий и пр. для каждого магазина просто нереально. Итого остается вариант искать по близости написания. Т.е. строка сравнивается по написанию со всеми магазинами, и берется тот, который наиболее похож. Естественно нужно еще найти какой-то минимальный порог, меньший 100% совпадения, но очень высокий, чтобы «ТЕХНОМИКС» не совпадал с «ТЕХНОМИР».

Сравнивать полную строку нет смысла, потому что чисто символьная разница между «СВЯЗНОЙ В ОКЕЕ НА МАРШАЛА ЖУКОВА», «СЕТЬ МАГАЗИНОВ САТЕЛЛИТ» и пр. далека от написания самого названия магазина. Из первой фразы надо сразу убирать адрес, но это просто, мы убираем все окончания начинающиеся на «на», «у», «ул», «в», «пр». Второй случай содержит часто употребимые слова, их можно выделить даже мельком пробежав все названия, хотя лучше с этим справился простенький скрипт. Но, так как даже после этого, во фразе все равно может остаться невыловленный нами мусор, надо сравнивать слова по отдельности, а не всю фразу.

Думаете стало находить? А фиг то там! Потому что если мы начнем таким образом сравнивать «EURO SET» и «BETA LINK», или, что еще хуже, «ЗАОБЕТА ЛИНК СПБ», то они станут непохожи, ведь из слова «BETA LINK», что «бета» что «линк» лишь наполовину похожи на «беталинк»… Поэтому надо сравнивать слова не только по одному, но и группами близлежащих, и к тому же не учитывая пробелы…

А еще надо учитывать чтобы из-за этой похожести «ДОМ.ТЕХНИКА» не совпал с «ДОМОТЕХНИКА» Тут, на самом деле, начинается новая проблема. И если дальше копать, то выясняем что магазинов с элементами «техно/техника/техникс», «мир», «центр», «видео» и пр. просто немеряно А ведь чем длиннее строка тем меньшую непохожесть вносит всего одна опечатка. Поэтому подобные элементы нужно сразу учитывать, чтобы не вносили погрешности. Но, опять же, тут надо учитывать что есть «М-ВИДЕО», который почти полностью состоит из одного из этих самых частоупотребимых элементов. Т.е. в данном случае нельзя отбрасывать эту часть, как мы делали с простым мусором (который упомянул выше, как например «СЕТЬ МАГАЗИНОВ»). Эти элементы надо сравнивать как обязательную и неотемлимую часть. И в тоже время требовать, чтобы ничего лишнего не было, т.е. «МИР ВИДЕО И АУДИО» это уже должно подпадать под мусор.

Да, и еще, насчет этих частоупотребымих элементов и мусора. Есть не только магазины, который в офлайне, но и интернет-магазины. А уж они то любят занять распространенное слово. И если на сайте telephone.ru продается достаточно товаров чтобы быть заметным, то нужно уметь его выделять. Вы думаете что его пишут как название сайта? Фиг то там! Он и сам себя именует как телефон.ру, и поэтому его пишут например как: «РОСТОВ.ТЕЛЕФОН.РУ» и так далее с учетом всех возможных опечаток. И выделяя его, нам ни в коем случае нельзя ошибиться и выделить «СОТОВЫЕ ТЕЛЕФОНЫ». Хотя в действительности для подобных сайтов не требует внесения каких-то особо уникальных вещей в алгоритм, но иметь ввиду это надо.

Ладно, это мы чуток разобрались с общеизвестными брендами, написание которых, чаще все же уникально. А ведь есть некоторые «псевдобренды», или не знаю как назвать. В общем, суть в том, что многим нашим предпринимателям лень думать над уникальным названием, и очень многие берут себе название типа «МИР», «МИР ТЕХНИКИ», «БЫТОВАЯ ТЕХНИКА», «ЭЛЕКТРОНИКА». И этих название просто куча в анкетах, и хотя клиент прекрасно понимает, что как таковой сети магазинов с таким именем нет в природе, но учитывать надо, из-за того, что слишком часто упоминается. И ведь приходится И, с учетом всего вышенаписанного, «БЫТОВАЯ ТЕХНИКА» должна отличатся от «МИР БЫТОВОЙ ТЕХНИКИ», от «ВИДЕО И БЫТОВАЯ ТЕХНИКА», но совпадать с «БЫТОВАЯ ТЕХНИКА 4″, «БЫТОВАЯ ТЕХНИКА МАГАЗИН №12 ЧП СОКОЛОВ С.И.», а «МИР» не должен совпасть с «АПЕЛЬСИНОВЫЙ МИР», «МИР ТЕХНИКИ», но совпадать с «МИР В ГИПЕРМАРКЕТЕ СЕМЬЯ» ну и т.д. Т.е. мусор если и может присутствовать, то только указывающий на месторасположение или тип.

Вот примерно такими вещами я сейчас и занимаюсь, если кому не лень тот может попробовать реализовать такой алгоритм, он не такой уж и сложный Я привел на примере магазинов цифровой техники, но примерно также делается и для многих других вещей: для брендов, названий товаров, автомобилей и пр. что имеет конечный описанный объем названий. А вот когда требуется просто выделить что-то из фразы, к примеру адрес, то тут все гораздо хитрей.
А еще подумайте как вообще можно написать адрес, или телефон, и как же определить настоящие это данные или нет, и поверьте, фантазия людей похоже действительно не имеет границ.
А ведь мало написать выделение данных, нужно чтобы алгоритм сразу отбрасывал, как мусор, данные о человеке типа «Мери Попинс, ул. Ленина 1 кв. 1, тел. 123-12-34″

Если интересно, то еще немного можно почитать на OSP.RU: Фываяч и Микки Маус и Пылесосы в ассортименте