J'utilise Hbase et Spark. J'ai besoin d'obtenir des données filtrées de la table par statut (peut-être 0,1,2,3). Je n'ai besoin que de ces données avec le statut = 0 - c'est environ 5% de toutes les données dans Hbase.
Qu'est-ce qui sera le plus rapide - utiliser le filtre pour Scan sur Hbase ou utiliser le filtre Spark pour rdd de toutes les données ayant lu toutes les données Hbase?
Et pourquoi? De quoi cela dépend-il?
JavaRDD<MyType> rdd = <get all data from table with new Scan()> rdd.filter(r->r.getStatus()==0)
OU
Scan scan = new Scan(); scan.setFilter(new SingleColumnValueFilter(...)); JavaRDD<MyType> rdd = <get data from table with scan>
3 Réponses :
Pourquoi ne pas utiliser DS / DF au lieu de RDD? car ce dernier disparaîtra avec le temps.
Voir https://blog.cloudera.com/spark-hbase-dataframe-based-hbase-connector/
Mon point de vue est que comme prédicat push down ne peut pas être désactivé à l'aide de Catalyst Optimizer - afaik - votre exemple utilisant un DF / DS entraînera le même plan physique. Donc, dans ce sens, il n'y aurait aucune différence de performance. Si l'on met en cache, nous pourrions voir la désactivation - voir Comment empêcher le refoulement du prédicat? .
Maintenant, je note qu'il existe différents connecteurs pour cela (au fil du temps), il peut donc y avoir une approche différente en fonction du type de connecteur que vous utilisez. Il semble que nous soyons passés d'une période de demande de refoulement de prédicat à un moment où nous ne pouvons pas le désactiver en général.
Dans tous les cas, votre échantillon de 5% des données serait pour moi, en général, un signe pour souhaiter un refoulement de prédicat.
Le filtrage par valeurs de colonne côté HBase est censé être lent, car il nécessite de parcourir toute la table (la lenteur dépend vraiment de la taille des données). D'un autre côté, ne pas le filtrer du côté HBase signifie que vous devez d'abord transférer la table ENTIÈRE du côté Spark, puis la filtrer via Spark, n'est-ce pas? Étant donné que vos valeurs cibles ne représentent que 5% de l'ensemble des données, j'imagine que ce serait exagéré. Vous ne savez pas quelles tailles de données vous traitez, mais cela peut avoir des implications importantes sur la mémoire (côté serveur et côté client) et également sur le trafic réseau. Avec tout cela à l'esprit, je pense que vous êtes moins bien avec le filtre Spark (qui d'ailleurs n'est pas nécessairement aussi rapide en premier lieu, pour autant que je me souvienne)
Différent de ma compréhension. Intéressant.
Vraiment? Si vous effectuez simplement une analyse complète avec hbase-spark et un filtre côté client dans le RDD en aval, cela se propagera d'une manière ou d'une autre vers le serveur et ne fournira pas la table complète?
Ah je lis votre lien. C'est peut-être spécifique à SHC. Je dois vérifier cela...
Il existe quelques options au fil du temps.
ok pour obtenir une analyse plus rapide dans HBase, vous pouvez essayer de regarder dans FuzzyRowFilter. https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/filter/FuzzyRowFilter.html
ce que fait ce type de filtre est d'ignorer les touches de ligne qui ne correspondent pas à votre modèle spécifié, ce qui accélère la numérisation. Cela prend également des modèles partiels.
Donc, dans votre cas, votre statut doit faire partie de la clé de ligne.
Que s'est-il passé lorsque vous l'avez essayé? Avez-vous obtenu des chiffres de performances inattendus?
Non, cela fonctionne à la fois. Mais maintenant je ne peux pas tester le big data pour le savoir.
Une petite note. HBase n'a pas été conçu pour prendre en charge ces requêtes. Bien sûr, ils fonctionnent, mais ils sont contre la philosophie de HBase. S'il y a beaucoup de données, les deux requêtes prendront très longtemps (avec la supposée plus courte celle avec le filtre HBase, comme répondu ci-dessous), mais en général, ces types de requêtes doivent être évitées ou un index spécifique doit être construit.