6
votes

Performance des jointures dans Spark-SQL

En supposant que nous avons un cluster sain et pour le cas d'utilisation, nous avons

Deux jeux de données avec 1 billlion + enregistrements

Nous devons comparer les deux jeux de données et trouver

Duplicates dans le jeu de données d'origine

Je prévoyais d'écrire un

Query SQL avec Join sur les colonnes à vérifier pour être vérifiée DUPLICATES

Je voulais savoir comment sera le

performance pour cette requête ainsi que les raffinements

qui peut être fait dans les jeux de données (partitionnement de lataframe) avant de les rejoindre.

S'il vous plaît dressez-vous avec vos observations.


6 commentaires

Les deux jeux de données de 1 milliard d'enregistrements sont-ils tous deux?


Oui VRSA. Les deux sont 1 milliard plus


Par "DUPLICATES" Vous voulez dire des tuples dans le jeu de données 1 qui sont également présents dans le jeu de données 2?


Oui mais les colonnes sur lesquelles nous souhaitons vérifier les duplicats sont configurés par l'utilisateur. Supposons que vous disposiez de 10 colonnes dans les deux jumelles, la saisie de l'utilisateur décidera que le nombre de colonnes devons-nous vérifier les mêmes valeurs. Il peut être 1 à 10. Le chèque en double de niveau d'enregistrement direct n'est pas l'exigence


OK, et avez-vous besoin de l'ensemble du tuple joint pour être renvoyé dans les résultats ou simplement les utilisateurs de colonnes configurés pour correspondre?


Les colonnes requises peuvent être différentes de l'utilisateur spécifié pour le chèque en double.


3 Réponses :


2
votes

La performance de la requête pour les jeux de données de cet ordre ne peut être prédite mais peut être traitée. J'ai travaillé avec un jeu de données de 700 millions d'enregistrements et ci-dessous sont les propriétés de surbrillance qui ont aidé à modifier mon application.

  • spark.sql.shuffle.partitions (trouver la tache douce vous-même)
  • Spark.Serializer (de préférence du kryosérienzer)

    attribue également aux ressources de cluster pour votre application importe beaucoup. Veuillez vous reporter à ce blog . Merci.


1 commentaires

Merci Vrsa. S'il vous plaît pouvez-vous également me suggérer que comment puis-je séparer mon jeu de données avant de rejoindre lorsque mes conditions de jointure sont dynamiques.



4
votes

Je voulais savoir comment sera la performance p>

comparé à quoi? En ce qui concerne les nombres absolus, je pense que cela dépendra évidemment de vos données et de votre groupe. P>

Cependant, dans Spark 2.0 Les améliorations de performance sont assez importantes. P>

et les raffinements p> BlockQuote>

L'optimiseur de catalyseur est assez bon (plus après 2.0). Sous il s'occupe de la plupart de vos optimisations telles que la taille de la colonne, le prédicat Push Down, etc. (In 2.0, il existe également une génération de code qui s'occupe de générer un code très optimisé qui permet d'améliorer de très grandes améliorations de performance.) P>

et Ces mêmes améliorations sont disponibles dans l'ensemble de la planche, que vous utilisiez API de DataFrames / jeux de données ou SQL. P>

Comme exemple de type d'optimisations de requête que le catalyseur de Spark a fait deux dataframes DF1 et DF2 avec le même schéma. (comme votre cas) et que vous souhaitez les rejoindre sur certaines colonnes pour obtenir seulement l'intersection et la sortie de ces tuples. P>

Disons que mon schéma des cadres de données est comme suit (appelant df.schema ): p> xxx pré>

Nous avons l'identifiant, l'âge, la ville, les colonnes de noms de mes ensembles de données. P>

Maintenant donné ce que vous voulez ferez-vous quelque chose comme p> xxx pré>

si vous examinez le plan physique de ce qui précède, vous remarquerez de nombreuses optimisations effectuées sous la hotte par Catalyst Optimizer: P>

df1.join(
    df2.select("df2.name").distinct, 
    $"df2.name"===$"df1.name"
   ).select("df1.id","df1.name", "df1.age", "df1.city" )


0 commentaires

0
votes

Avez-vous essayé d'augmenter le noyau exécuteur à 4 ou plus en fonction de votre configuration de cluster et également tout en faisant une étincelle-Soumettre mieux pour ne pas mentionner non. des exécuteurs. Laissez Spark décide non. des exécuteurs à utiliser. Cela peut améliorer la performance dans une certaine mesure lorsque vous travaillez avec d'énormes ensembles de données.


1 commentaires

L'augmentation des cœurs d'exécution arrivera au niveau d'exécution de l'optimisation. En ce moment, j'essaie de préparer mes jeux de données et de la bonne façon de trouver les doublons entre eux sur la base des colonnes.