HBase
 sql >> база данни >  >> NoSQL >> HBase

Индексиране на имейл с помощта на Cloudera Search и HBase

В предишната ми публикация научихте как да индексирате имейл съобщения в пакетен режим и в почти реално време, като използвате Apache Flume с MorphlineSolrSink. В тази публикация ще научите как да индексирате имейли с помощта на Cloudera Search с Apache HBase и Lily HBase Indexer, поддържани от NGDATA и Cloudera. (Ако не сте чели предишната публикация, препоръчвам ви да го направите за фон, преди да четете.)

Кой метод в почти реално време да изберете, HBase Indexer или Flume MorphlineSolrSink, ще зависи изцяло от вашия случай на употреба, но по-долу са някои неща, които трябва да имате предвид при вземането на това решение:

  • HBase оптимална среда за съхранение ли е за дадения случай на употреба?
  • Данните вече ли са приети в HBase?
  • Има ли някакъв модел на достъп, който изисква файловете да се съхраняват във формат, различен от HFiles?
  • Ако HBase в момента не работи, ще има ли достатъчно хардуерни ресурси, за да го изведе?

Има два начина да конфигурирате Cloudera Search за индексиране на документи, съхранявани в HBase:да промените директно конфигурационните файлове и да стартирате Lily HBase Indexer ръчно или като услуга, или да конфигурирате всичко с помощта на Cloudera Manager. Тази публикация ще се съсредоточи върху последното, защото това е най-лесният начин да активирате Търсене в HBase — или всяка друга услуга на CDH, в този смисъл.

Разбиране на HBase репликацията и Lily HBase Indexer

При проектирането на това решение Cloudera идентифицира четири основни изисквания, за да направи индексирането на HBase ефективно:

  • Закъснението при индексирането трябва да е в почти реално време (секунди) и да може да се настройва
  • Индексът Solr в крайна сметка трябва да е в съответствие с таблицата HBase, докато вмъкванията, актуализациите и изтриванията се прилагат към HBase
  • Механизмът за индексиране трябва да бъде мащабируем и устойчив на грешки
  • Процесът на индексиране не може да забави записите в HBase

За да отговори на тези изисквания, Cloudera Search използва естествения механизъм за репликация на HBase. За тези, които не са запознати с репликацията на HBase, ето кратко резюме на много високо ниво:

Тъй като актуализациите се прилагат към дневника за предварителна запис (WAL), HBase RegionServer слуша тези актуализации в отделна нишка. Когато буферът на тази нишка е запълнен или достигне края на файла, той изпраща партидите с всички репликирани актуализации към партньор RegionServer, работещ в различен клъстер. Следователно WAL е от съществено значение за работата на индексирането.

Cloudera Search използва механизма за репликация на HBase, който прослушва събитията на мутацията на HBase ред и вместо да изпраща актуализации към различен RegionServer, ги изпраща до Lily HBase Indexer. От своя страна Lily HBase Indexer прилага логиката на трансформация на Cloudera Morphlines, като разбива събитията в полета на Solr и ги препраща към Apache Solr Server.

Има големи предимства при използването на репликация на HBase спрямо прилагането на същата функционалност в HBase копроцесорите. Първо, репликацията работи паралелно и асинхронно с данните, които се поглъщат в HBase. Следователно индексирането на Cloudera Search не добавя никаква латентност или оперативна нестабилност към рутинната работа на HBase. Второ, използването на метода на репликация позволява безпроблемни промени в движение в логиката на трансформация. Обратно, за да се извърши промяна чрез модификация на копроцесора, е необходимо рестартиране на RegionServer, което би направило данните недостъпни за потребителите на HBase. Може би най-важното е, че внедряването на копроцесори е доста натрапчиво и, ако не се тества правилно, може да наруши производителността на HBase.

Този поток е илюстриран по-долу:

Инсталиране на Cloudera Search и внедряване на Lily HBase Indexer

Cloudera Manager изтегля и внедрява Cloudera Search като един пакет автоматично. Всичко, което трябва да направите, е да щракнете върху иконата „Пакети“ в горната навигация, да изберете версията на Solr и да я изтеглите, разпространявате и активирате:

Както споменахме по-горе, Cloudera Search зависи от репликацията на HBase и следователно това ще бъде активирано по-нататък. Активирайте репликацията, като щракнете върху HBase Service->Configuration->Backup и гарантиране, че „Активиране на репликация на HBase“ и „Разрешаване на индексиране“ са отметнати. Ако е необходимо, запазете промените и рестартирайте услугата HBase.

За да добавите Lily HBase Indexer, отидете на Услуги->Добавяне на услуга , изберете „Keystore Indexer“ и го добавете, като го насочите към HBase екземпляр, който ще се използва за обработка на имейли:

Конфигуриране на Solr

След това конфигурирайте Solr точно както е описано в предишната публикация тук.

  1. Генерирайте примерен конфигурационен файл schema.xml:
    $ solrctl --zk localhost:2181/solr \
    instancedir --generate $HOME/emailSearchConfig
    

  2. Редактирайте файла schema.xml в $HOME/emailSearchConfig с конфигурационния файл, който ще дефинира полета, свързани с обработката на имейли. Пълно копие на файла можете да намерите на тази връзка.
  3. Качете конфигурациите на Solr в ZooKeeper:
    $ solrctl --zk localhost:2181/solr instancedir  \
    --create email_collection $HOME/emailSearchConfig
    

  4. Генерирайте колекцията Solr:
    $ solrctl --zk localhost:2181/solr collection  \
    --create email_collection -s 1
    

Регистриране на индексатора

Тази стъпка е необходима за добавяне и конфигуриране на индексатора и репликацията на HBase. Командата по-долу ще актуализира ZooKeeper и ще добави myindexer като партньор за репликация за HBase. Той също така ще вмъкне конфигурации в ZooKeeper, които Lily HBase Indexer ще използва, за да посочи правилната колекция в Solr.

$ hbase-indexer add-indexer -n myindexer -c indexer-config.xml  \
       -cp solr.zk=localhost:2181/solr  \
       -cp solr.collection=collection1

Аргументи:

  • -n myindexer – указва името на индексатора, който ще бъде регистриран в ZooKeeper
  • -c indexer-config.xml – конфигурационен файл, който ще указва поведението на индексатора
  • -cp solr.zk=localhost:2181/solr  – указва местоположението на конфигурацията на ZooKeeper и Solr. Това трябва да се актуализира със специфичното за средата местоположение на ZooKeeper.
  • -cp solr.collection=collection1 – указва коя колекция да се актуализира. Припомнете си стъпката за конфигуриране на Solr, където създадохме колекция1.

В този случай файлът index-config.xml е сравнително лесен; всичко, което прави, е да посочи на индексатора коя таблица да гледа, класа, който ще се използва като мапер (com.ngdata.hbaseindexer.morphline.MorphlineResultToSolrMapper) и местоположението на конфигурационния файл Morphline. Типът на съпоставяне е зададен на колона защото искаме да получим всяка клетка като отделен Solr документ. По подразбиране типът на съпоставяне е зададен на ред , в който случай документът Solr става пълният ред.

Param name=”morphlineFile” указва местоположението на конфигурационния файл Morphlines. Местоположението може да бъде абсолютен път на вашия Morphlines файл, но тъй като използвате Cloudera Manager, посочете относителния път:“morphlines.conf”.

   
   


   
   

Съдържанието на конфигурационния файл на hbase-indexer може да бъде намерено на тази връзка.

За пълната справка на командата hbase-indexer е достатъчно да изпълните командата без никакви аргументи:

$ hbase-indexer

Usage: hbase-indexer 
where  an option from one of these categories:

TOOLS
  add-indexer
  update-indexer
  delete-indexer
  list-indexers

PROCESS MANAGEMENT
  server           run the HBase Indexer server node

REPLICATION (EVENT PROCESSING) TOOLS
  replication-status
  replication-wait

PACKAGE MANAGEMENT
  classpath        dump hbase CLASSPATH
  version          print the version

 or
  CLASSNAME        run the class named CLASSNAME
Most commands print help when invoked w/o parameters.

Конфигуриране и стартиране на Lily HBase Indexer

Ако си спомняте, когато сте добавили Lily HBase Indexer, сте посочили екземпляра на HBase, с който е свързан. Следователно не е необходимо да правите това в тази стъпка. Трябва обаче да посочите логиката на трансформацията на Morphlines, която ще позволи на този индексатор да анализира имейл съобщенията и да извлече всички съответни полета.

Отидете на Услуги и изберете Lily HBase Indexer, който сте добавили по-рано. Изберете Configurations->View and Edit->Service-Wide->Morphlines . Копирайте и поставете файла morphlines.

Библиотеката с морфини по имейл ще извърши следните действия:

1.     Прочетете имейл събитията на HBase с командата extractHBaseCells
2. Разбийте неструктурирания текст на полета с командата grok
3. Ако Message-ID липсва в имейла, генерирайте го с командата generateUUID
4. Преобразувайте клеймото за дата/време в поле, което Solr ще разбере, с командата convertTimestamp
5. Изхвърлете всички допълнителни полета, които не сме посочили в schema.xml, с командата sanitizeUknownSolrFields

Командата extractHBaseCells заслужава повече внимание, тъй като тя е единственото нещо, различно в конфигурацията на морфлиновете на HBase Indexer. Параметрите са:

  • inputColumn – определя колони, за които да се абонирате (може да бъде заместващ знак)
  • outputFied – името на полето, където се изпращат данните
  • тип – типът на полето (това е низ в случай на тялото на имейла)
  • източник – може да бъде стойностен или квалифициран; value указва, че стойността на клетката трябва да бъде индексирана
extractHBaseCells {
       mappings : [
        {
          inputColumn : "messages:*"
          outputField : "message"
          type : string
          source : value
          }
        ]
      }

Изтеглете копие на този файл morphlines от тук.

Една важна забележка е, че полето id ще бъде автоматично генерирано от Lily HBase Indexer. Тази настройка може да се конфигурира във файла index-config.xml по-горе чрез посочване на атрибута unique-key-field. Най-добрата практика е да оставите името по подразбиране на идентификатор – тъй като не е посочено в xml файла по-горе, полето за идентификатор по подразбиране е генерирано и ще бъде комбинация от RowID-Column Family-Column Name.

В този момент запазете промените и стартирайте Lily HBase Indexer от Cloudera Manager.

Настройване на таблицата входяща кутия в HBase

Има много начини да създадете таблицата в HBase програмно (Java API, REST API или подобен метод). Тук ще използвате обвивката на HBase, за да създадете таблицата на входящата поща (умишлено като използвате описателно име на фамилията на колоните, за да направите нещата по-лесни за следване). В производствените приложения фамилното име винаги трябва да е кратко, тъй като винаги се съхранява с всяка стойност като част от ключа на клетката. Следната команда ще направи това и ще активира репликацията в семейство колони, наречено „съобщения“:

hbase(main):003:0>  create 'inbox', {NAME => 'messages', REPLICATION_SCOPE => 1}

За да проверите дали таблицата е създадена правилно, изпълнете следната команда:

hbase(main):003:0> describe 'inbox'
DESCRIPTION                                                                ENABLED
 {NAME => 'inbox', FAMILIES => [{NAME => 'messages', DATA_BLOCK_ENCODING => ' true
 NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '1', VERSIONS => '3',
 COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => '2147483647', KEEP_DEL
 ETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', ENCODE
 _ON_DISK => 'true', BLOCKCACHE => 'true'}]}

От този момент всеки имейл, поставен във „входящата кутия“ на таблицата в колона семейство „съобщения“, ще задейства събитие към Lily HBase Indexer, който ще обработи събитието, ще го раздели на полета и ще го изпрати до Solr за индексиране.

Схемата на таблицата входяща кутия е проста:ИД на реда е името на лицето, на което принадлежи тази входяща кутия. Всяка клетка е отделно съобщение, като колоната е уникален целочислен идентификатор. По-долу е дадена моментна снимка на примерна таблица, както се показва от интерфейса HBase на Hue:

Достъп до данните

Имате избор от много визуални инструменти за достъп до индексираните имейли. Hue и Solr GUI са много добри опции. HBase също така позволява редица техники за достъп, не само от GUI, но и чрез HBase обвивката, API и дори прости техники за скриптове.

Интеграцията със Solr ви дава голяма гъвкавост и може също да предостави много прости, както и разширени опции за търсене на вашите данни. Например, конфигурирането на файла Solr schema.xml така, че всички полета в имейл обекта да се съхраняват в Solr, позволява на потребителите да имат достъп до пълните тела на съобщения чрез просто търсене, с компромис между пространството за съхранение и сложността на изчисленията.

Като алтернатива можете да конфигурирате Solr да съхранява само ограничен брой полета, като идентификатор, изпращач и тема. С тези елементи потребителите могат бързо да търсят в Solr и да извличат идентификатора(ите) на съобщението, което от своя страна може да се използва за извличане на цялото съобщение от самия HBase.

Примерът по-долу съхранява само идентификатора на съобщението в Solr, но индексира всички полета в имейл обекта. Търсенето в Solr в този сценарий извлича имейл идентификатори, които след това можете да използвате за запитване на HBase. Този тип настройка е идеална за Solr, тъй като поддържа ниски разходите за съхранение и се възползва напълно от възможностите на Solr за индексиране.

Скриптът на обвивката по-долу изпраща заявка към Solr Rest API за ключова дума „productId“ и връща полето „id“ във формат CSV. Резултатът е списък с идентификатори на документи, които съответстват на заявката. След това скриптът преглежда идентификаторите и ги разделя на идентификатор на ред, семейство колони и име на колона, които се използват за достъп до HBase чрез стандартния HBase REST API.

#!/bin/bash

#  Query SOLR and return the id field for every document
#  that contains the word resign
query_resp=$(curl -s 'http://spark:8983/solr/collection1_shard1_replica1/select?q=productId&fl=id&wt=csv')

# Loop through results of the previous command,
# and use the id to retrieve the cells from HBase via the HBase REST API
for i in  $query_resp
do
            if [ "$i" != "id" ]; then
            cmd=$(echo $i |awk -F'-' '{print "curl -s http://spark:20550/inbox/" $1 "/" $2 ":"  $3}')
            $cmd -H "Accept: application/x-protobuf "
            fi
done

Заключение

В тази публикация видяхте колко лесно е да индексирате имейли, които се съхраняват в HBase – в почти реално време и напълно ненатрапчиво към основния поток на HBase. В обобщение, имайте предвид следните основни стъпки:

  • Активиране на репликацията в HBase
  • Конфигурирайте правилно Lily HBase Indexer
  • Използвайте Morphlines в Lily HBase Indexer, за да помогнете с трансформациите (не се изисква кодиране!)

Ако сте имали възможност да прочетете предишната публикация, можете да видите, че файлът morphlines.conf е практически идентичен и в трите случая. Това означава, че е много лесно да разширите случаите на използване на търсене в екосистемата Hadoop. Ако данните вече са в HDFS, използвайте MapReduceIndexerTool, за да ги индексирате. Ако данните пристигат през Flume, използвайте SolrMorphlineSink с идентичен морфлайн файл. Ако по-късно решите, че HBase отговаря на случая на използване, е необходима само минимална промяна, за да започнете индексирането на клетките в HBase:Просто добавете командата extractHBaseCells към файла morphlines.

Въпреки че този пример се концентрира върху имейли като случай на използване, този метод може да се приложи в много други сценарии, където HBase се използва като слой за съхранение и достъп. Ако вашето предприятие вече използва HBase за конкретен случай на употреба, помислете за внедряване на Cloudera Search върху него. Не изисква кодиране и наистина може да отвори данните за много по-широка аудитория в организацията.

Джеф Шмейн е архитект на решения в Cloudera.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Apache Spark идва в Apache HBase с HBase-Spark модул

  2. Какво е автоматичен отказ при отказ в NameNode в Hadoop HDFS?

  3. Как да:Активирайте удостоверяване и оторизация на потребителя в Apache HBase

  4. HBase BlockCache 101

  5. Настройка на производителността в MapReduce за подобряване на производителността