HBase
 sql >> Base de données >  >> NoSQL >> HBase

Indexation des e-mails à l'aide de Cloudera Search et HBase

Dans mon article précédent, vous avez appris à indexer les e-mails en mode batch et en temps quasi réel, en utilisant Apache Flume avec MorphlineSolrSink. Dans cet article, vous apprendrez à indexer les e-mails à l'aide de Cloudera Search avec Apache HBase et Lily HBase Indexer, maintenus par NGDATA et Cloudera. (Si vous n'avez pas lu le message précédent, je vous recommande de le faire pour le contexte avant de continuer à lire.)

Quelle méthode en temps quasi réel choisir, HBase Indexer ou Flume MorphlineSolrSink, dépendra entièrement de votre cas d'utilisation, mais voici quelques éléments à prendre en compte lors de la prise de décision :

  • HBase est-il un support de stockage optimal pour le cas d'utilisation donné ?
  • Les données sont-elles déjà ingérées dans HBase ?
  • Existe-t-il un modèle d'accès qui exigera que les fichiers soient stockés dans un format autre que HFiles ?
  • Si HBase n'est pas en cours d'exécution, y aura-t-il suffisamment de ressources matérielles pour l'activer ?

Il existe deux manières de configurer Cloudera Search pour indexer les documents stockés dans HBase :modifier directement les fichiers de configuration et démarrer Lily HBase Indexer manuellement ou en tant que service, ou tout configurer à l'aide de Cloudera Manager. Cet article se concentrera sur ce dernier, car c'est de loin le moyen le plus simple d'activer la recherche sur HBase - ou tout autre service sur CDH, d'ailleurs.

Comprendre la réplication HBase et l'indexeur Lily HBase

Lors de la conception de cette solution, Cloudera a identifié quatre exigences majeures pour rendre l'indexation HBase efficace :

  • La latence d'indexation doit être en temps quasi réel (secondes) et ajustable
  • L'index Solr doit finalement être cohérent avec la table HBase tandis que les insertions, les mises à jour et les suppressions sont appliquées à HBase
  • Le mécanisme d'indexation doit être évolutif et tolérant aux pannes
  • Le processus d'indexation ne peut pas ralentir les écritures HBase

Pour répondre à ces exigences, Cloudera Search utilise le mécanisme de réplication natif de HBase. Pour ceux qui ne connaissent pas la réplication HBase, voici un bref résumé de très haut niveau :

Au fur et à mesure que les mises à jour sont appliquées au journal d'écriture anticipée (WAL), HBase RegionServer écoute ces mises à jour sur un thread séparé. Lorsque le tampon de ce thread est rempli ou qu'il atteint la fin du fichier, il envoie les lots avec toutes les mises à jour répliquées à un homologue RegionServer exécuté sur un cluster différent. Le WAL est donc essentiel pour que l'indexation fonctionne.

Cloudera Search utilise le mécanisme de réplication HBase, qui écoute les événements de mutation de ligne HBase et, au lieu d'envoyer des mises à jour à un autre RegionServer, les envoie à Lily HBase Indexer. À son tour, Lily HBase Indexer applique la logique de transformation Cloudera Morphlines, divisant les événements en champs Solr et les transmettant au serveur Apache Solr.

L'utilisation de la réplication HBase présente des avantages majeurs par rapport à l'implémentation de la même fonctionnalité dans les coprocesseurs HBase. Premièrement, la réplication fonctionne en parallèle et de manière asynchrone avec les données ingérées dans HBase. Par conséquent, l'indexation Cloudera Search n'ajoute aucune latence ou instabilité opérationnelle au fonctionnement HBase de routine. Deuxièmement, l'utilisation de la méthode de réplication permet des modifications transparentes à la volée de la logique de transformation. Inversement, pour effectuer un changement via une modification du coprocesseur, il faut redémarrer RegionServer, ce qui rendrait les données indisponibles pour les utilisateurs de HBase. Le plus important est peut-être que la mise en œuvre de coprocesseurs est assez intrusive et, si elle n'est pas testée correctement, peut perturber les performances de HBase.

Ce flux est illustré ci-dessous :

Installation de Cloudera Search et déploiement de Lily HBase Indexer

Cloudera Manager télécharge et déploie automatiquement Cloudera Search en tant que package unique. Tout ce que vous avez à faire est de cliquer sur l'icône "Packages" dans la barre de navigation supérieure, de choisir la version de Solr, de la télécharger, de la distribuer et de l'activer :

Comme mentionné précédemment, Cloudera Search dépend de la réplication HBase et, par conséquent, cela sera activé ensuite. Activez la réplication en cliquant sur Service HBase->Configuration->Sauvegarde et en veillant à ce que "Activer la réplication HBase" et "Activer l'indexation" soient cochés. Si nécessaire, enregistrez les modifications et redémarrez le service HBase.

Pour ajouter Lily HBase Indexer, allez dans Services->Ajouter un service , choisissez « Keystore Indexer » et ajoutez-le en le faisant pointer vers l'instance HBase qui sera utilisée pour le traitement des e-mails :

Configurer Solr

Ensuite, configurez Solr exactement comme décrit dans le post précédent ici.

  1. Générez un exemple de fichier de configuration schema.xml :
    $ solrctl --zk localhost:2181/solr \
instancedir --generate $HOME/emailSearchConfig

  2. Modifiez le fichier schema.xml dans $HOME/emailSearchConfig, avec le fichier de configuration qui définira les champs pertinents pour le traitement des e-mails. Une copie complète du fichier est disponible sur ce lien.
  3. Téléchargez les configurations Solr sur ZooKeeper :
    $ solrctl --zk localhost:2181/solr instancedir  \
--create email_collection $HOME/emailSearchConfig

  4. Générez la collection Solr :
    $ solrctl --zk localhost:2181/solr collection  \
--create email_collection -s 1

Enregistrement de l'indexeur

Cette étape est nécessaire pour ajouter et configurer l'indexeur et la réplication HBase. La commande ci-dessous mettra à jour ZooKeeper et ajoutera myindexer en tant qu'homologue de réplication pour HBase. Il insérera également des configurations dans ZooKeeper, que Lily HBase Indexer utilisera pour pointer vers la bonne collection dans Solr.

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

Argumentation :

  • -n myindexer – spécifie le nom de l'indexeur qui sera enregistré dans ZooKeeper
  • -c indexer-config.xml - fichier de configuration qui spécifiera le comportement de l'indexeur
  • -cp solr.zk=localhost:2181/solr  – spécifie l'emplacement de ZooKeeper et de la configuration Solr. Cela devrait être mis à jour avec l'emplacement spécifique à l'environnement de ZooKeeper.
  • -cp solr.collection=collection1 – spécifie quelle collection mettre à jour. Rappelez-vous l'étape de configuration de Solr où nous avons créé collection1.

Le fichier index-config.xml est relativement simple dans ce cas; tout ce qu'il fait est de spécifier à l'indexeur quelle table regarder, la classe qui sera utilisée comme mappeur (com.ngdata.hbaseindexer.morphline.MorphlineResultToSolrMapper) et l'emplacement du fichier de configuration Morphline. Le type de mappage est défini sur colonne parce que nous voulons obtenir chaque cellule en tant que document Solr individuel. Par défaut, le type de mappage est défini sur ligne , auquel cas le document Solr devient la ligne complète.

Param name="morphlineFile" spécifie l'emplacement du fichier de configuration Morphlines. L'emplacement peut être un chemin absolu de votre fichier Morphlines, mais puisque vous utilisez Cloudera Manager, spécifiez le chemin relatif :"morphlines.conf".

Le contenu du fichier de configuration hbase-indexer se trouve sur ce lien.

Pour la référence complète de la commande hbase-indexer, il suffit d'exécuter la commande sans aucun argument :

$ 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.

Configuration et démarrage de Lily HBase Indexer

Si vous vous souvenez, lorsque vous avez ajouté Lily HBase Indexer, vous avez spécifié l'instance de HBase à laquelle il est associé. Par conséquent, vous n'avez pas besoin de le faire dans cette étape. Vous devez cependant spécifier la logique de transformation Morphlines qui permettra à cet indexeur d'analyser les messages électroniques et d'extraire tous les champs pertinents.

Allez dans Services et choisissez Lily HBase Indexer que vous avez ajouté précédemment. Sélectionnez Configurations->Afficher et modifier->Service-Wide->Morphlines . Copiez et collez le fichier de morphlines.

La bibliothèque de morphlines de messagerie effectuera les actions suivantes :

1.     Lisez les événements de messagerie HBase avec la commande extractHBaseCells
2. Divisez le texte non structuré en champs avec la commande grok
3. Si Message-ID est absent de l'e-mail, générez-le avec la commande generateUUID
4. Convertissez la date/l'horodatage en un champ compréhensible par Solr, avec la commande convertTimestamp
5. Supprimez tous les champs supplémentaires que nous n'avons pas spécifiés dans schema.xml, avec la commande sanitizeUknownSolrFields

La commande extractHBaseCells mérite plus d'attention, car c'est la seule chose différente dans la configuration des morphlines de HBase Indexer. Les paramètres sont :

  • inputColumn - spécifie les colonnes auxquelles s'abonner (peut être un caractère générique)
  • outputFied – le nom du champ où les données sont envoyées
  • type - le type du champ (il s'agit d'une chaîne dans le cas du corps de l'e-mail)
  • source – peut être de valeur ou qualifié ; valeur spécifie que la valeur de la cellule doit être indexée
extractHBaseCells {
       mappings : [
        {
          inputColumn : "messages:*"
          outputField : "message"
          type : string
          source : value
          }
        ]
      }

Téléchargez une copie de ce fichier de morphlines à partir d'ici.

Une remarque importante est que le champ id sera automatiquement généré par Lily HBase Indexer. Ce paramètre est configurable dans le fichier index-config.xml ci-dessus en spécifiant l'attribut unique-key-field. Il est recommandé de laisser le nom par défaut de l'id — comme il n'a pas été spécifié dans le fichier xml ci-dessus, le champ d'id par défaut a été généré et sera une combinaison de RowID-Column Family-Column Name.

À ce stade, enregistrez les modifications et démarrez Lily HBase Indexer à partir de Cloudera Manager.

Configuration du tableau de la boîte de réception dans HBase

Il existe de nombreuses façons de créer la table dans HBase par programme (API Java, API REST ou une méthode similaire). Ici, vous utiliserez le shell HBase pour créer la table de la boîte de réception (en utilisant intentionnellement un nom de famille de colonne descriptif pour faciliter le suivi). Dans les applications de production, le nom de famille doit toujours être court, car il est toujours stocké avec chaque valeur dans le cadre d'une clé de cellule. La commande suivante le fera et activera la réplication sur une famille de colonnes appelée « messages » :

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

Pour vérifier que la table a été correctement créée, exécutez la commande suivante :

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'}]}

À partir de ce moment, tout e-mail placé dans la table "boîte de réception" dans la famille de colonnes "messages" déclenchera un événement vers Lily HBase Indexer, qui traitera l'événement, le divisera en champs et l'enverra à Solr pour indexation.

Le schéma de la table de la boîte de réception est simple :l'ID de ligne est le nom de la personne à qui appartient cette boîte de réception. Chaque cellule est un message individuel, la colonne étant un identifiant entier unique. Vous trouverez ci-dessous un instantané d'un exemple de tableau tel qu'il est affiché par l'interface HBase de Hue :

Accéder aux données

Vous avez le choix entre de nombreux outils visuels pour accéder aux emails indexés. Hue et Solr GUI sont deux très bonnes options. HBase permet également un certain nombre de techniques d'accès, non seulement à partir d'une interface graphique, mais également via le shell HBase, l'API et même des techniques de script simples.

L'intégration avec Solr vous offre une grande flexibilité et peut également fournir des options de recherche très simples et avancées pour vos données. Par exemple, la configuration du fichier Solr schema.xml de sorte que tous les champs de l'objet e-mail soient stockés dans Solr permet aux utilisateurs d'accéder au corps complet des messages via une simple recherche, avec le compromis entre l'espace de stockage et la complexité de calcul.

Alternativement, vous pouvez configurer Solr pour stocker uniquement un nombre limité de champs, tels que l'identifiant, l'expéditeur et le sujet. Avec ces éléments, les utilisateurs peuvent rapidement rechercher Solr et récupérer le ou les ID de message qui, à leur tour, peuvent être utilisés pour récupérer le message complet à partir de HBase lui-même.

L'exemple ci-dessous stocke uniquement l'ID de message dans Solr mais indexe tous les champs de l'objet e-mail. La recherche de Solr dans ce scénario récupère les ID de messagerie, que vous pouvez ensuite utiliser pour interroger HBase. Ce type de configuration est idéal pour Solr car il réduit les coûts de stockage et tire pleinement parti des capacités d'indexation de Solr.

Le script shell ci-dessous envoie une requête à l'API Solr Rest pour un mot-clé "productId" et renvoie le champ "id" au format CSV. Le résultat est une liste d'ID de document qui correspondent à la requête. Le script parcourt ensuite les identifiants et les divise en ID de ligne, famille de colonne et nom de colonne, qui sont utilisés pour accéder à HBase via l'API REST HBase standard.

#!/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

Conclusion

Dans cet article, vous avez vu à quel point il est facile d'indexer les e-mails stockés dans HBase - en temps quasi réel et de manière totalement non intrusive pour le flux HBase principal. En résumé, gardez ces principales étapes à l'esprit :

  • Activer la réplication dans HBase
  • Configurer correctement Lily HBase Indexer
  • Utilisez Morphlines dans Lily HBase Indexer pour faciliter les transformations (aucun codage requis !)

Si vous avez eu l'occasion de lire le post précédent, vous pouvez constater que le fichier morphlines.conf est pratiquement identique dans les trois cas. Cela signifie qu'il est très facile de développer les cas d'utilisation de la recherche sur l'écosystème Hadoop. Si les données sont déjà dans HDFS, utilisez MapReduceIndexerTool pour les indexer. Si les données arrivent via Flume, utilisez SolrMorphlineSink avec un fichier de morphlines identique. Si plus tard vous décidez que HBase correspond au cas d'utilisation, seul un changement minimal est nécessaire pour commencer l'indexation des cellules dans HBase :ajoutez simplement la commande extractHBaseCells au fichier morphlines.

Bien que cet exemple se concentre sur les e-mails en tant que cas d'utilisation, cette méthode peut être appliquée dans de nombreux autres scénarios où HBase est utilisé comme couche de stockage et d'accès. Si votre entreprise utilise déjà HBase pour un cas d'utilisation spécifique, envisagez d'implémenter Cloudera Search en plus. Il ne nécessite aucun codage et peut vraiment ouvrir les données à un public beaucoup plus large dans l'organisation.

Jeff Shmain est architecte de solutions chez Cloudera.