J'ai récemment donné une conférence au LA Hadoop User Group sur les choses à faire et à ne pas faire avec Apache HBase. Le public était excellent et avait des questions très informées et bien articulées. Jody de Shopzilla était un excellent hôte et je lui dois un grand merci pour avoir donné l'opportunité de parler avec plus de 60 LA Hadoopers. Étant donné que tout le monde ne vit pas à Los Angeles ou ne peut pas se rendre à la rencontre, j'ai résumé ici certains des points saillants. Pour ceux d'entre vous qui ont une journée bien remplie, voici le tl;dr :
- HBase est bon, mais ne remplace pas RDBMS ou HDFS
- Une bonne configuration signifie un bon fonctionnement
- Surveiller surveiller surveiller surveiller surveiller
Chez Cloudera, nous sommes de grands fans de HBase. Nous aimons la technologie, nous aimons la communauté et nous avons constaté qu'elle convient parfaitement à de nombreuses applications. Les utilisations réussies de HBase ont été bien documentées et, par conséquent, de nombreuses organisations se demandent si HBase convient à certaines de leurs applications. L'impulsion de mon exposé et de ce billet de blog de suivi est de clarifier certaines des bonnes applications pour HBase, de mettre en garde contre certaines applications médiocres et de mettre en évidence les étapes importantes pour un déploiement réussi de HBase.
Quand utiliser HBase
La considération la plus importante lorsque l'on regarde HBase est que, bien qu'il s'agisse d'une excellente solution à de nombreux problèmes, ce n'est pas une solution miracle. HBase n'est pas optimisé pour les applications transactionnelles classiques ou même l'analyse relationnelle. Ce n'est pas non plus un substitut complet à HDFS lors de l'exécution de MapReduce par lots volumineux. Jetez un œil à certains des cas d'utilisation de cet article pour avoir une idée des applications qui conviennent le mieux à HBase et si vous avez des questions, allez-y et publiez sur les listes. Ai-je mentionné que la communauté est fantastique ?
Avec cette mise en garde, pourquoi devriez-vous utiliser HBase ? Si votre application a un schéma de variable où chaque ligne est légèrement différente, vous devriez alors regarder HBase. A titre d'exemple, faire un exercice de modélisation à l'aide d'un schéma relationnel standard; Lorsque vous ne pouvez pas ajouter de colonnes assez rapidement et que la plupart d'entre elles sont NULL dans chaque ligne, vous devriez envisager HBase. Si vous constatez que vos données sont stockées dans des collections, par exemple des métadonnées, des données de message ou des données binaires qui sont toutes indexées sur la même valeur, vous devez alors envisager HBase. Si vous avez besoin d'un accès basé sur des clés aux données lors du stockage ou de la récupération, vous devriez envisager HBase.
Services d'assistance
En supposant que vous soyez convaincu que HBase convient parfaitement à votre application, voici quelques conseils à prendre en compte lors de son déploiement. Il y a quelques services de soutien qui sont importants et un qui est nécessaire. Si vous n'avez jamais regardé ZooKeeper auparavant, c'est le moment. HBase utilise ZooKeeper pour divers services de coordination distribués tels que l'élection du maître. Au fur et à mesure que HBase se développe et se développe, il continue de s'appuyer sur ZooKeeper pour des fonctionnalités supplémentaires, ce qui en fait un élément clé du système. En outre, vous devez disposer de services réseau appropriés, tels que NTP et DNS. HBase dépend du fait que tous les nœuds du cluster ont des horloges étroitement synchronisées et se réfèrent les uns aux autres de manière cohérente. L'utilisation de NTP et de DNS garantit que vous ne rencontrerez pas de comportements étranges lorsqu'un nœud A pense que l'heure est demain et que le nœud B pense que c'est hier. Vous éviterez également les situations où le nœud maître dit au nœud C de desservir une région mais le nœud C ne connaît pas son propre nom et ne répond pas. L'utilisation de NTP et de DNS vous évitera bien des maux de tête au début.
J'ai dit que la considération la plus importante lors de la sélection de HBase est de s'assurer que vous avez un cas d'utilisation qui convient. La chose la plus importante à faire lors de l'utilisation de HBase est de surveiller le système. La surveillance est la clé du succès des opérations HBase. Comme c'est le cas avec de nombreux systèmes distribués, HBase est sensible aux défaillances en cascade. Si un nœud commence à permuter, il peut perdre le contact avec le maître, ce qui oblige un autre serveur à prendre la charge et à être surchargé. Ce deuxième serveur échouera et l'échec se répercutera en cascade. Vous devez surveiller la mémoire, le processeur, les E/S et la latence et la bande passante du réseau sur chacun de vos nœuds HBase pour vous assurer qu'ils fonctionnent dans des paramètres sains. La surveillance est la pratique la plus importante pour exploiter un cluster HBase sain.
Bonnes pratiques pour l'architecture HBase
Avance rapide vers votre cluster HBase bien surveillé exécutant un cas d'utilisation parfait, voici quelques bonnes pratiques. Utilisez un préfixe de clé qui se distribue bien en fonction de votre cas d'utilisation. Si vous préfixez votre clé par un horodatage ou toute valeur similaire qui, une fois triée, est stockée ou interrogée dans un lot, vous surchargerez probablement chaque serveur de région à tour de rôle au lieu de répartir uniformément la charge. Vous devez également maintenir le nombre de régions à un nombre raisonnable en fonction de la taille du magasin de mémoire et de la quantité de RAM et la JVM RegionServer doit être limitée à 12 Go de tas Java pour minimiser les longues pauses GC. Par exemple, une machine avec 36 Go de RAM qui exécute également un démon DataNode pourrait gérer environ 100 régions avec des écritures actives et un memstore de 48 Mo chacune. Cela laisse suffisamment de marge pour les besoins en mémoire de DataNode et RegionServer, l'espace de mémoire tampon des fichiers Linux et une taille de vidage raisonnable pour chaque RegionServer.
Quelques recommandations de configuration incluent la désactivation du compactage automatique (par défaut, cela se produit toutes les 24 heures à partir du moment où vous démarrez HBase) et programmez-le pour qu'il s'exécute tous les jours en dehors des heures de pointe. Vous devez également configurer la compression (telle que LZO) et placer explicitement le répertoire de configuration HBase correctement configuré dans votre CLASSPATH.
À NE PAS FAIRE HBase
Nous avons couvert un large éventail de bonnes pratiques pour HBase. Il y a aussi quelques habitudes d'utilisation à éviter. Par exemple, ne vous attendez pas à utiliser HBase comme remplacement de gros pour chacune de vos bases de données relationnelles. HBase est excellent dans de nombreux domaines, mais il ne remplace pas les bases de données relationnelles. Pour commencer, il ne parle pas SQL, n'a pas d'optimiseur, ne prend pas en charge les transactions d'enregistrements croisés ou les jointures. Si vous n'en utilisez aucun dans votre application de base de données, HBase pourrait très bien être la solution idéale.
Soyez prudent lorsque vous exécutez des charges de travail mixtes sur un cluster HBase. Lorsque vous avez des SLA sur l'accès à HBase indépendamment de toute tâche MapReduce (par exemple, une transformation dans Pig et la diffusion de données à partir de HBase), exécutez-les sur des clusters distincts. HBase est gourmand en CPU et en mémoire avec un accès sporadique important aux E/S séquentielles, tandis que les tâches MapReduce sont principalement liées aux E/S avec une mémoire fixe et un CPU sporadique. La combinaison de ces éléments peut entraîner des latences imprévisibles pour les conflits HBase et CPU entre les deux. Un cluster partagé nécessite également moins d'emplacements de tâches par nœud pour répondre aux exigences du processeur HBase (généralement la moitié des emplacements sur chaque nœud que vous alloueriez sans HBase). Gardez également un œil sur l'échange de mémoire. Si HBase commence à échanger, il y a de fortes chances qu'il manque un battement de cœur et soit supprimé du cluster. Sur un cluster occupé, cela peut surcharger une autre région, provoquant son échange et une cascade d'échecs.
Réflexions finales
Un dernier conseil avant de résumer. Lors du chargement de HBase, utilisez HFileOuputFormat si le chargement via un travail MapReduce ou une collection de serveurs utilisant des puts par lots. Le chargement avec un seul client créera un goulot d'étranglement sur ce client et ne tirera pas parti de l'évolutivité offerte par HBase.
En résumé, considérez HBase lorsque vous chargez des données par clé, recherchez des données par clé (ou plage), servez des données par clé, interrogez des données par clé ou lorsque vous stockez des données par ligne qui ne sont pas bien conformes à un schéma.
Cas d'utilisation
- Apache HBase :optimisé par le wiki HBase
- Mozilla :Déplacement de Socorro vers HBase
- Facebook :le nouveau système de messagerie en temps réel de Facebook :HBase
- StumbleUpon :HBase sur StumbleUpon
