Cet article de blog a été publié sur Hortonworks.com avant la fusion avec Cloudera. Certains liens, ressources ou références peuvent ne plus être exacts.
En 2016, nous avons publié la deuxième version v1.0.1 de Spark HBase Connector (SHC). Dans ce blog, nous passerons en revue les principales fonctionnalités que nous avons mises en œuvre cette année.
Prise en charge du codeur Phoenix
SHC peut être utilisé pour écrire des données sur le cluster HBase pour un traitement ultérieur en aval. Il prend en charge la sérialisation Avro pour les données d'entrée et de sortie et utilise par défaut une sérialisation personnalisée à l'aide d'un simple mécanisme de codage natif. Lors de la lecture des données d'entrée, SHC pousse les filtres vers HBase pour des analyses efficaces des données. Compte tenu de la popularité des données Phoenix dans HBase, il semble naturel de prendre en charge les données Phoenix comme entrée dans HBase en plus des données Avro. De plus, l'utilisation par défaut du codage binaire natif simple semble susceptible de modifications futures et constitue un risque pour les utilisateurs qui écrivent des données de SHC dans HBase. Par exemple, avec SHC à l'avenir, la rétrocompatibilité doit être correctement gérée. Donc, par défaut, SHC doit passer à un format plus standard et bien testé comme Phoenix.
Pour le support de clé composite, avant cette fonctionnalité, la longueur de la valeur de chaque dimension devait être fixe, à l'exception de la dernière dimension de la clé composite. Cette limitation a été supprimée par le codeur Phoenix. Actuellement, si les utilisateurs choisissent Phoenix comme codeur de données, ils n'ont pas besoin de spécifier la longueur de chaque partie de la clé composite dans le catalogue.
Comme Phoenix est le codeur par défaut, le seul changement pour les utilisateurs est que s'ils veulent utiliser PrimitiveType comme codeur de données, ils doivent spécifier "tableCoder":"PrimitiveType" dans leurs catalogues pour informer SHC qu'ils veulent utiliser PrimitiveType à la place de Phoenix en tant que "tableCoder".
def catalog =s"""{
|"table":{"namespace":"default", "name":"table1″, "tableCoder":"PrimitiveType"},
|"rowkey ”:”key”,
|”columns”:{
|”col0″:{“cf”:”rowkey”, “col”:”key”, “type”:”string”} ,
|”col1″ :{“cf”:”cf1″, “col”:”col1″, “type”:”booléen”},
|”col2″:{“cf” :”cf2″, “col”:”col2″, “type”:”double”},
|”col3″:{“cf”:”cf3″, “col”:”col3″, “type” :”float”},
|”col4″:{“cf”:”cf4″, “col”:”col4″, “type”:”int”},
|”col5″ :{“cf”:”cf5″, “col”:”col5″, “type”:”bigint”},
|”col6″:{“cf”:”cf6″, “col”:”col6 ″, “type”:”smallint”},
|”col7″:{“cf”:”cf7″, “col”:”col7″, “type”:”string”},
|”col8″:{“cf”:”cf8″, “col”:”col8″, “type”:”tinyint”}
|}
|}”””.stripMargin
Mettre en cache les connexions Spark HBase
SHC ne mettait pas en cache les objets de connexion dans HBase auparavant. Plus précisément, l'appel à "ConnectionFactory.createConnection" a été effectué chaque fois que SHC avait besoin de visiter des tables et des régions HBase. Les utilisateurs pouvaient le voir simplement en consultant les journaux de l'exécuteur et en observant les connexions du gardien de zoo établies pour chaque demande. Dans la documentation de l'interface Connection, il est indiqué que la création de la connexion est une opération lourde et que les implémentations de connexion sont thread-safe. Par conséquent, pour les processus de longue durée, il serait très utile que SHC conserve une connexion en cache. Grâce à cette fonctionnalité, SHC réduit considérablement le nombre de connexions créées et améliore considérablement ses performances dans le processus.
Prend en charge les familles de colonnes dupliquées
SHC a pris en charge la prise en charge des familles de colonnes dupliquées. Désormais, les utilisateurs peuvent définir leurs catalogues comme ceci :
def catalog =s"""{
|"table":{"namespace":"default", "name":"table1″, "tableCoder":"PrimitiveType"},
|"rowkey ”:”key”,
|”columns”:{
|”col0″:{“cf”:”rowkey”, “col”:”key”, “type”:”string”} ,
|”col1″ :{“cf”:”cf1″, “col”:”col1″, “type”:”booléen”},
|”col2″:{“cf” :”cf1″, “col”:”col2″, “type”:”double”},
|”col3″:{“cf”:”cf1″, “col”:”col3″, “type” :”float”},
|”col4″:{“cf”:”cf2″, “col”:”col4″, “type”:”int”},
|”col5″ :{“cf”:”cf2″, “col”:”col5″, “type”:”bigint”},
|”col6″:{“cf”:”cf3″, “col”:”col6 ″, “type”:”smallint”},
|”col7″:{“cf”:”cf3″, “col”:”col7″, “type”:”string”},
|”col8″:{“cf”:”cf3″, “col”:”col8″, “type”:”tinyint”}
|}
|}”””.stripMargin
Dans la définition du catalogue ci-dessus, les colonnes "col0", "col1" et "col2" ont la même famille de colonnes "cf1".
Utiliser l'API Spark UnhandledFilters
SHC a également implémenté l'API Spark unhandledFilters, qui est une optimisation efficace. Cette API informe Spark des filtres que SHC n'implémente pas au lieu de renvoyer tous les filtres. Le comportement précédent, dans ce cas, consistait à réappliquer tous les filtres une fois les données extraites dans Spark. Cela devrait être idempotent, donc ne change aucune donnée, mais peut être coûteux si les filtres sont compliqués.
Communauté SHC
La communauté SHC est plus grande et plus influente qu'il y a un an. En 2016, nous avons donné des conférences au Hadoop Summit et au meetup HBase/Spark, et rédigé des blogs détaillés. Avec l'augmentation du nombre d'utilisateurs du SHC, nous recevons un plus grand nombre de questions d'utilisateurs. Nous sommes très heureux de voir une adoption accrue de SHC et si vous avez des idées sur la façon de l'améliorer, veuillez nous faire part de vos commentaires via Hortonworks Community Connection.
RECONNAISSANCE
Nous tenons à remercier l'équipe Bloomberg de nous avoir guidés dans ce travail et de nous avoir également aidés à valider ce travail. Nous tenons également à remercier la communauté HBase pour ses commentaires et son amélioration. Enfin, ce travail a tiré les leçons des intégrations précédentes de Spark HBase et nous tenons à remercier leurs développeurs d'avoir ouvert la voie.
RÉFÉRENCE :
SHC : https://github.com/hortonworks-spark/shc
Apache HBase : https://hbase.apache.org/
Apache Spark : http://spark.apache.org/
Apache Phoenix : https://phoenix.apache.org/
