Non HBase solution pour stocker des données énormes et mettre à jour en temps réel

Question

Salut, j'ai développé une application où je dois stocker TB de données pour la première fois, puis 20 GB incrémental mensuel comme insérer/mettre à jour/supprimer sous la forme de xml qui sera appliqué en plus de ces 5 To de données. Enfin, sur demande, je dois générer un instantané complet de toutes les données et créer des fichiers texte 5K en fonction de la logique afin que les données respectives soient dans les fichiers respectifs.

J'ai réalisé ce projet en utilisant HBase. J'ai créé 35 tables dans la HBase ayant une région de 10 à 500. J'ai mes données dans mon HDFS et l'utilisation de mapreduce i des données de charge en vrac dans des tables Hbase réceptives. Ensuite, j'ai une application d'analyse syntaxique SAX écrite en Java pour analyser tous les fichiers incrémentaux xml entrants et mettre à jour les tables HBase. La fréquence des fichiers xml est d'environ 10 fichiers xml par minutes et un total de 2000 mises à jour. Le message incrémental est strictement dans l'ordre.

Enfin, sur demande, je lance ma dernière application mapreduce pour scanner toutes les tables Hbase et créer des fichiers texte 5K et les livrer au client.

Les 3 étapes fonctionnent bien mais quand je suis allé déployer mon application sur un serveur de production qui est un cluster partagé, l'équipe d'infrastructure ne nous permet pas d'exécuter mon application car je fais un scan complet sur HBase.

J'ai utilisé le cluster de 94 nœuds et les plus grandes données de table HBase que j'ai est d'environ 2 milliards. Toutes les autres tables ont moins d'un million de données.

Le temps total nécessaire à mapreduce pour numériser et créer des fichiers texte est de 2 heures.

Maintenant, je cherche une autre solution pour implémenter cela.

Je peux utiliser HIVE parce que j'ai des enregistrements de niveau insérer/mettre à jour et supprimer cela aussi de manière très précise.

J'ai également intégré la table HBase et HIVE afin que, pour les données incrémentales, la table HBase soit utilisée et pour le balayage de table complet, HIVE sera utilisé. Mais comme HIVE utilise le gestionnaire de stockage Hbase je ne peux pas créer de partition dans la table HIVE et c'est pourquoi HIVE scan de table devient très lent même 10 fois plus lent que HBase Full scan de table

Je ne peux pas penser à une solution en ce moment coincé . S'il vous plaît aidez-moi avec une autre solution où HBase n'est pas impliqué. Puis-je utiliser le fichier AVRO ou Perquet dans ce cas d'utilisation? Mais je ne sais pas comment AVRO prendra en charge la mise à jour au niveau de l'enregistrement.

Answer 1

Je vais répondre à ma question. Mon problème est que je ne veux pas effectuer une analyse de table complète sur Hbase, car elle aura une incidence sur les performances du serveur de la région et spécialement sur le cluster partagé, il atteindra les performances en lecture de HBase.

Donc, ma solution en utilisant Hbase, car il est très bon pour la mise à jour spécialement mise à jour delta qui est mise à jour des colonnes. Par conséquent, afin d'éviter que l'analyse de table complète ne prenne un instantané de la table HBase, exportez-la dans HDFS et exécutez une analyse de table complète sur l'instantané de la table Hbase.

Voici les étapes détaillées du processus

Créer un cliché

snapshot 'FundamentalAnalytic','FundamentalAnalyticSnapshot' 

Snapshot Exporter vers hdfs locaux

hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot FundamentalAnalyticSnapshot -copy-to /tmp -mappers 16 

pilote de configuration de travail pour MapReduce rhum sur l'instantané Hbase

String snapshotName="FundamentalAnalyticSnapshot"; 
Path restoreDir = new Path("hdfs://quickstart.cloudera:8020/tmp"); 
String hbaseRootDir = "hdfs://quickstart.cloudera:8020/hbase"; 



TableMapReduceUtil.initTableSnapshotMapperJob(snapshotName, // Snapshot name 
         scan, // Scan instance to control CF and attribute selection 
         DefaultMapper.class, // mapper class 
         NullWritable.class, // mapper output key 
         Text.class, // mapper output value 
         job, 
         true, 
         restoreDir); 

L'exécution de mapreduce sur un snapshot Hbase permet également d'ignorer le scan sur la table Hbase et il n'y aura pas non plus d'impact sur le serveur de région.

Answer 2

La clé de l'utilisation efficace de HBase est DESIGN. Avec un bon design, vous n'aurez jamais à faire un scan complet. Ce n'est pas ce que HBase a été fait pour. Au lieu de cela, vous auriez pu faire un scan avec Filter - quelque chose que HBase a été construit pour gérer efficacement.

Je ne peux pas vérifier votre conception maintenant mais je pense que vous devrez peut-être. L'idée n'est pas de concevoir une table HBase comme vous auriez une table RDBMS et la clé est de concevoir une bonne rowkey. Si vous rowKey est bien construit, vous ne devriez jamais faire un scan complet.

Vous pouvez également utiliser un projet comme Apache Phoenix si vous souhaitez accéder à votre table en utilisant d'autres colonnes que la clé de ligne. Il fonctionne également bien.J'ai une bonne expérience avec Phoenix.