How-to: Apache Solr для анализа данных

Автор: Питер Уитни (Peter Whitney)

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

Если спросить хорошо осведомленного специалиста о том, для чего предназначен Solr, вероятно, он ответит, что Solr (в сочетании с Apache Lucene) представляет собой платформу для полнотекстового поиска с открытым исходным кодом. Этот инструмент используется для индексирования документов и последующего поиска среди них с помощью запросов свободной формы, во многом похожих на запросы к Google. Другой специалист может добавить, что Solr имеет широкие возможности индексирования на основе геолокации с поддержкой радиуса, ограничивающего прямоугольника (bounding box) и поиска по заданному региону. Оба ответа будут правильными.

Менее известен тот факт, что с помощью Solr (+Lucene) также можно запрашивать индексированные данные для анализа и при этом получать ответы невероятно быстро. Применяя Solr подобным образом, вы можете расширить арсенал своего кластера и повысить эффективность использования ресурсов. В некоторой степени Solr может обеспечить возможности, подобные возможностям in-memory NoSQL СУБД (нереляционной СУБД с размещением данных в оперативной памяти).

В этой статье мы научимся использовать преимущество высокой скорости обработки запросов, обеспечиваемое Solr. На примере я покажу, как индексировать документы и выполнять сложные запросы. Затем я дам вам рекомендации, позволяющие определить, целесообразно ли применение данного подхода для решения конкретной задачи. В конце мы кратко сравним возможности Solr с возможностями in-memory NoSQL СУБД, например, MongoDB.

Подыщем набор данных

При поиске подходящего набора данных у меня было несколько критериев. Необходимо было малое количество полей, чтобы данные можно было легко понять. Кроме того, нам требовались данные, характерные для бизнес-задач. Наконец, необходимо было наличие полей с числовыми значениями, чтобы можно было продемонстрировать возможности Solr, такие как фильтрация на основе сравнения (comparison filtering) и фильтрация на основе диапазона (range filtering).

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

1

Я загрузил CSV-файл по указанной выше ссылке и для ясности изменил его имя на rates.csv. Первые строки из этого файла представлены ниже:

 zip,eiaid,utility_name,state,service_type,ownership,comm_rate,ind_rate,res_rate
  35218,195,Alabama Power Co,AL,Bundled,Investor Owned,0.105761195393,0.0602924366735,0.114943267065
  35219,195,Alabama Power Co,AL,Bundled,Investor Owned,0.105761195393,0.0602924366735,0.114943267065
  35214,195,Alabama Power Co,AL,Bundled,Investor Owned,0.105761195393,0.0602924366735,0.114943267065
  35215,195,Alabama Power Co,AL,Bundled,Investor Owned,0.105761195393,0.0602924366735,0.114943267065
  35216,195,Alabama Power Co,AL,Bundled,Investor Owned,0.105761195393,0.0602924366735,0.114943267065
  35210,195,Alabama Power Co,AL,Bundled,Investor Owned,0.105761195393,0.0602924366735,0.114943267065
  35211,195,Alabama Power Co,AL,Bundled,Investor Owned,0.105761195393,0.0602924366735,0.114943267065
  35212,195,Alabama Power Co,AL,Bundled,Investor Owned,0.105761195393,0.0602924366735,0.114943267065
  35213,195,Alabama Power Co,AL,Bundled,Investor Owned,0.105761195393,0.0602924366735,0.114943267065

Создание и загрузка схемы

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

Первым делом, создадим на локальном диске конфигурацию по умолчанию. Реализуем это посредством следующей команды, где /tmp/electric_rates – локальный каталог, в котором Solr разместит файлы конфигурации:

solrctl --zk localhost:2181/solr instancedir --generate /tmp/electric_rates

В каталоге /tmp/electric_rates появится файл schema.xml. Это достаточно большой XML-файл, содержащий некоторые определения, которые мы будем использовать в дальнейшем. Основной нашей заботой на данный момент являются определения полей.

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

<field name="zip" type="int" indexed="true" stored="true" required="true"/>
<field name="eiaid" type="int" indexed="false" stored="true"/>
<field name="utility_name" type="string" indexed="true" stored="true" omitNorms="true"/>
<field name="state" type="string" indexed="true" stored="true" omitNorms="true"/>
<field name="service_type" type="string" indexed="false" stored="true" omitNorms="true"/>
<field name="ownership" type="string" indexed="false" stored="true" omitNorms="true"/>
<field name="comm_rate" type="double" indexed="true" stored="true"/>
<field name="ind_rate" type="double" indexed="true" stored="true"/>
<field name="res_rate" type="double" indexed="true" stored="true"/>

Как видим, здесь присутствуют поля целочисленного (int), строкового (string) и вещественного (double) типов. Обратите внимание на то, что только некоторые поля будут проиндексированы (indexed=»true»). По этим полям мы будем выполнять поиск или применять к ним функции группировки. Атрибут omitNorms=»true» информирует Solr о том, что поля с данным атрибутом НЕ следует оптимизировать для ускоренного поиска (boosting search).

Отредактировав файл schema.xml, создадим каталог экземпляра Solr с помощью Apache ZooKeeper, выполнив следующую команду:

solrctl --zk localhost:2181/solr instancedir --create electric_collection /tmp/electric_rates

Теперь создадим новую коллекцию:

solrctl --zk localhost:2181/solr collection --create electric_collection

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

Проиндексируем данные с помощью следующей команды:

curl “http://localhost:8983/solr/electric_collection_shard1_replica1/update/csv?header=true& \ rowid=id&stream.file=/tmp/rates.csv&stream.contentType=text/csv;charset=utf-8"

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

Быстрые ответы на бизнес-вопросы

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

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

  • Операционная система: CentOS 6.6

  • Версия дистрибутива Cloudera (CDH): 5.0.0

  • Версия Solr: 4.10.3

  • Объем памяти, доступный Solr: 5,84 ГБ

  • Версия Java: 1.7.0_67

  • Количество процессоров: 1

Сколько энергетических компаний обслуживает штат Мэриленд?

Чтобы ответить на этот вопрос, к полю state применим фильтр, позволяющий выделить данные, относящиеся только к штату Мэриленд (MD). Затем определим количество энергетических компаний, обслуживающих Мэриленд, сгруппировав результаты по названиям компаний (по полю utility_name). Количество результатов в группах ограничим до одного, поскольку нас интересует лишь количество групп. Следующий запрос выполняет описанные действия:

http://localhost:8983/solr/electric_collection_shard1_replica1/select?q=state%3A%22MD%22&wt=json&indent=true&group=true&group.field=utility_name&rows=10&group.limit=1

Ниже представлено описание параметров запроса:

2

В ответе мы получили 4 группы. Запрос был обработан за 23 миллисекунды.

Какая из энергетических компаний Мэриленда предлагает самый низкий бытовой тариф?

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

http://localhost:8983/solr/electric_collection_shard1_replica1/select?q=state%3A%22MD%22&wt=json&indent=true&group=true&group.field=utility_name&rows=1&group.limit=1&sort=res_rate+asc

Ниже представлено описание добавленных или измененных параметров запроса:

3

Самый низкий тариф в штате Мэриленд предлагает компания «The Potomac Edison Company» (0,03079 $/кВт·ч). Запрос был обработан за 4 миллисекунды.

Какова величина минимального и максимального бытового тарифа без учета отсутствующих данных?

Чтобы ответить на этот вопрос, необходимо исключить строки, в которых поле res_rate имеет значение 0,0, поскольку это значение подразумевает отсутствие данных. Это можно реализовать посредством запроса с фильтром на основе диапазона, исключив нижнюю границу, равную 0,0. Чтобы получить минимальное и максимальное значение поля res_rate, сообщим Solr о том, что необходимо рассчитать статистические характеристики для поля res_rate. Ниже представлен соответствующий запрос:

http://localhost:8983/solr/electric_collection_shard1_replica1/select?q=*:*&fq=%7b!frange+l%3D0.0+incl%3Dfalse%7dres_rate&wt=json&indent=true&rows=0&stats=true&stats.field=res_rate

Описание параметров запроса:

4

Минимальное значение бытового тарифа 0,0260022258659, а максимальное – 0,849872773537. Запрос был обработан за 5 миллисекунд.

Какому штату и почтовому индексу соответствует самый высокий бытовой тариф?

Чтобы ответить на этот вопрос, мы используем максимальное значение поля res_rate, полученное в предыдущем запросе, в качестве фильтра, как показано ниже:

http://localhost:8983/solr/electric_collection_shard1_replica1/select?q=res_rate:0.849872773537&wt=json&indent=true&rows=1

Описание параметров запроса:

5

Самый высокий бытовой тариф действует на Аляске в регионе с почтовым индексом 99634. Запрос был обработан за 1 миллисекунду.

Критерии целесообразности применения Solr для анализа данных

Необходимо отметить, что Solr не является in-memory NoSQL СУБД общего назначения. Приняв это во внимание, приведем несколько критериев относительно целесообразности применения Solr в аналитических целях:

  • Ваша задача требует очень высокой скорости обработки запросов.

  • Данные, которые необходимо анализировать, уже хранятся в Apache Hadoop.

  • Вы можете легко задать схему для индексирования данных.

  • Вам необходимо выполнять запросы (фильтрацию) по многим полям.

  • Количество индексируемых данных соответствует возможностям кластера Solr.

Если большинство или все вышеперечисленные критерии выполняются, значит Solr прекрасно подходит для анализа ваших данных.

Сравнение Solr и MongoDB

MongoDB – одна из самых популярных NoSQL СУБД. Давайте сравним Solr и MongoDB:

6

Обратите внимание, в будущем поддержка Kudu может обеспечить новые интересные возможности для Solr.

Заключение

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

Чтобы ответить на вопросы, приведенные в качестве примеров, мы использовали группировку, сортировку, фильтрацию на основе сравнения, фильтрацию на основе диапазона и расчет статистических характеристик. Хотя Solr не следует рассматривать, как in-memory NoSQL СУБД общего назначения, тем не менее этот инструмент можно успешно применять в аналитических целях, получая в качестве преимущества высокую скорость обработки запросов. Таким образом, имея в своем арсенале Solr, архитектор экосистемы Hadoop приобретает дополнительные возможности, которые могут существенно облегчить решение определенных задач.

По материалам: Cloudera

Перевод Станислава Петренко

Добавить комментарий

Ваш e-mail не будет опубликован.

закрыть

Поделиться

Отправить на почту
закрыть

Вход

закрыть

Регистрация

+ =