Propriétés du tSqlRow pour Apache Spark Batch

Ces propriétés sont utilisées pour configurer le tSqlRow s'exécutant dans le framework de Jobs Spark Batch.

Le composant tSqlRow Spark Batch appartient à la famille Processus en cours.

Le composant de ce framework est disponible dans tous les produits Talend avec Big Data et dans Talend Data Fabric.

Basic settings

Schema et Edit schema	Un schéma est une description de lignes. Il définit le nombre de champs (colonnes) à traiter et à passer au composant suivant. Lorsque vous créez un Job Spark, évitez le mot réservé `line` lors du nommage des champs. Built-in : le schéma est créé et conservé localement pour ce composant seulement. Repository : le schéma existe déjà et est stocké dans le Repository. Ainsi, il peut être réutilisé dans des Jobs et projets. Créez le schéma en cliquant sur le bouton Edit Schema. Note InformationsRemarque : Si vous effectuez des modifications, le schéma passe automatiquement en type built-in. View schema : sélectionnez cette option afin de voir uniquement le schéma. Change to built-in property : sélectionnez cette option pour passer le schéma en mode Built-In et effectuer des modifications locales. Update repository connection : sélectionnez cette option afin de modifier le schéma stocké dans le référentiel et décider de propager ou non les modifications à tous les Jobs. Si vous souhaitez propager les modifications uniquement au Job courant, cliquez sur No et sélectionnez à nouveau la métadonnée du schéma dans la fenêtre Repository Content.
SQL context	Sélectionnez les langages de requête que vous souhaitez que le tSqlRow utilise. SQL Spark Context : langage natif de requêtes Spark. SQL Hive Context : langage de requêtes Hive supporté par Spark. En mode SQL Hive Context, le tSqlRow ne vous permet pas d'utiliser le metastore de Hive. Si vous devez lire ou écrire des données dans le metastore Hive, utilisez les composants tHiveInput ou tHiveOutput à la place et, dans cette situation, vous devez créer différemment votre Job. Pour plus d'informations concernant les instructions de requêtes Hive supportées par Spark, consultez Supported Hive features (uniquement en anglais) (en anglais).
Query	Saisissez votre requête en faisant particulièrement attention à l'ordre des champs afin de correspondre à la définition du schéma. Le composant tSqlRow utilise le libellé de son lien d'entrée pour nommer la table enregistrée stockant les jeux de données depuis le même lien d'entrée. Par exemple, si un lien d'entrée est nommé row1, ce row1 est automatiquement le nom de la table dans laquelle effectuer les requêtes.

Schema et Edit schema

Un schéma est une description de lignes. Il définit le nombre de champs (colonnes) à traiter et à passer au composant suivant. Lorsque vous créez un Job Spark, évitez le mot réservé line lors du nommage des champs.

Built-in : le schéma est créé et conservé localement pour ce composant seulement.
Repository : le schéma existe déjà et est stocké dans le Repository. Ainsi, il peut être réutilisé dans des Jobs et projets.

Créez le schéma en cliquant sur le bouton Edit Schema.

Remarque : Si vous effectuez des modifications, le schéma passe automatiquement en type built-in.

View schema : sélectionnez cette option afin de voir uniquement le schéma.
Change to built-in property : sélectionnez cette option pour passer le schéma en mode Built-In et effectuer des modifications locales.
Update repository connection : sélectionnez cette option afin de modifier le schéma stocké dans le référentiel et décider de propager ou non les modifications à tous les Jobs. Si vous souhaitez propager les modifications uniquement au Job courant, cliquez sur No et sélectionnez à nouveau la métadonnée du schéma dans la fenêtre Repository Content.

SQL context

Sélectionnez les langages de requête que vous souhaitez que le tSqlRow utilise.

SQL Spark Context : langage natif de requêtes Spark.
SQL Hive Context : langage de requêtes Hive supporté par Spark.

En mode SQL Hive Context, le tSqlRow ne vous permet pas d'utiliser le metastore de Hive. Si vous devez lire ou écrire des données dans le metastore Hive, utilisez les composants tHiveInput ou tHiveOutput à la place et, dans cette situation, vous devez créer différemment votre Job.

Pour plus d'informations concernant les instructions de requêtes Hive supportées par Spark, consultez Supported Hive features (uniquement en anglais) (en anglais).

Query

Saisissez votre requête en faisant particulièrement attention à l'ordre des champs afin de correspondre à la définition du schéma.

Le composant tSqlRow utilise le libellé de son lien d'entrée pour nommer la table enregistrée stockant les jeux de données depuis le même lien d'entrée. Par exemple, si un lien d'entrée est nommé row1, ce row1 est automatiquement le nom de la table dans laquelle effectuer les requêtes.

Advanced settings

Register UDF jars	Ajoutez les .jar Spark SQL ou Hive SQL UDF (user-defined function, fonction personnalisée) que vous souhaitez que le tSqlRow utilise. Si vous ne souhaitez pas appeler votre fonction personnalisée à l'aide de son nom de classe entièrement qualifié, vous devez définir un alias de fonction pour cette fonction personnalisée, dans la table Temporary UDF functions et utiliser cet alias. Il est recommandé d'utiliser l'approche de l'alias, car un alias est souvent pratique pour appeler une fonction personnalisée à partir d'une requête. Une fois cette ligne ajoutée à la table, cliquez dessus pour afficher le bouton [...], puis cliquez sur ce bouton pour afficher l'assistant d'import de .jar. Via cet assistant, importez les fichiers .jar des fonctions personnalisées que vous souhaitez utiliser.
Temporary UDF functions	Renseignez cette table pour donner à chaque classe de fonction personnalisée importée un nom de fonction temporaire à utiliser dans la requête, dans le tSqlRow. Si vous avez sélectionné SQL Spark Context dans la liste SQL context, la colonne UDF output type s'affiche. Dans cette colonne, vous devez sélectionner le type de données de sortie de la fonction personnalisée Spark SQL à utiliser.

Ajoutez les .jar Spark SQL ou Hive SQL UDF (user-defined function, fonction personnalisée) que vous souhaitez que le tSqlRow utilise. Si vous ne souhaitez pas appeler votre fonction personnalisée à l'aide de son nom de classe entièrement qualifié, vous devez définir un alias de fonction pour cette fonction personnalisée, dans la table Temporary UDF functions et utiliser cet alias. Il est recommandé d'utiliser l'approche de l'alias, car un alias est souvent pratique pour appeler une fonction personnalisée à partir d'une requête.

Une fois cette ligne ajoutée à la table, cliquez dessus pour afficher le bouton [...], puis cliquez sur ce bouton pour afficher l'assistant d'import de .jar. Via cet assistant, importez les fichiers .jar des fonctions personnalisées que vous souhaitez utiliser.

Temporary UDF functions

Renseignez cette table pour donner à chaque classe de fonction personnalisée importée un nom de fonction temporaire à utiliser dans la requête, dans le tSqlRow.

Si vous avez sélectionné SQL Spark Context dans la liste SQL context, la colonne UDF output type s'affiche. Dans cette colonne, vous devez sélectionner le type de données de sortie de la fonction personnalisée Spark SQL à utiliser.

Utilisation

Règle d'utilisation	Ce composant est utilisé comme étape intermédiaire. Ce composant, ainsi que la Palette Spark Batch à laquelle il appartient, ne s'affiche que lorsque vous créez un Job Spark Batch. Notez que, dans cette documentation, sauf mention contraire, un scénario présente uniquement des Jobs Standard, c'est-à-dire des Jobs Talend traditionnels d'intégration de données.
Connexion à Spark	Dans l'onglet Spark Configuration de la vue Run, définissez la connexion à un cluster Spark donné pour le Job complet. De plus, puisque le Job attend ses fichiers .jar dépendants pour l'exécution, vous devez spécifier le répertoire du système de fichiers dans lequel ces fichiers .jar sont transférés afin que Spark puisse accéder à ces fichiers : Yarn mode (Yarn Client ou Yarn Cluster) : Lorsque vous utilisez Google Dataproc, spécifiez un bucket dans le champ Google Storage staging bucket de l'onglet Spark configuration. Lorsque vous utilisez HDInsight, spécifiez le blob à utiliser pour le déploiement du Job, dans la zone Windows Azure Storage configuration de l'onglet Spark configuration. Lorsque vous utilisez Altus, spécifiez le bucket S3 ou le stockage Azure Data Lake Storage (aperçu technique) pour le déploiement du Job, dans l'onglet Spark configuration. Lorsque vous utilisez Qubole, ajoutez tS3Configuration à votre Job pour écrire vos données métier dans le système S3 avec Qubole. Sans tS3Configuration, ces données métier sont écrites dans le système Qubole HDFS et détruites une fois que vous arrêtez votre cluster. Lorsque vous utilisez des distributions sur site (on-premises), utilisez le composant de configuration correspondant au système de fichiers utilisé par votre cluster. Généralement, ce système est HDFS et vous devez utiliser le tHDFSConfiguration (en anglais). Standalone mode : utilisez le composant de configuration correspondant au système de fichiers que votre cluster utilise, comme le tHDFSConfiguration Apache Spark Batch ou le tS3Configuration Apache Spark Batch (en anglais). Si vous utilisez Databricks sans composant de configuration dans votre Job, vos données métier sont écrites directement dans DBFS (Databricks Filesystem). Cette connexion fonctionne uniquement pour le Job dans lequel vous l'avez définie.

Règle d'utilisation

Ce composant est utilisé comme étape intermédiaire.

Ce composant, ainsi que la Palette Spark Batch à laquelle il appartient, ne s'affiche que lorsque vous créez un Job Spark Batch.

Notez que, dans cette documentation, sauf mention contraire, un scénario présente uniquement des Jobs Standard, c'est-à-dire des Jobs Talend traditionnels d'intégration de données.

Connexion à Spark

Dans l'onglet Spark Configuration de la vue Run, définissez la connexion à un cluster Spark donné pour le Job complet. De plus, puisque le Job attend ses fichiers .jar dépendants pour l'exécution, vous devez spécifier le répertoire du système de fichiers dans lequel ces fichiers .jar sont transférés afin que Spark puisse accéder à ces fichiers :

Yarn mode (Yarn Client ou Yarn Cluster) :
- Lorsque vous utilisez Google Dataproc, spécifiez un bucket dans le champ Google Storage staging bucket de l'onglet Spark configuration.
- Lorsque vous utilisez HDInsight, spécifiez le blob à utiliser pour le déploiement du Job, dans la zone Windows Azure Storage configuration de l'onglet Spark configuration.
- Lorsque vous utilisez Altus, spécifiez le bucket S3 ou le stockage Azure Data Lake Storage (aperçu technique) pour le déploiement du Job, dans l'onglet Spark configuration.
- Lorsque vous utilisez Qubole, ajoutez tS3Configuration à votre Job pour écrire vos données métier dans le système S3 avec Qubole. Sans tS3Configuration, ces données métier sont écrites dans le système Qubole HDFS et détruites une fois que vous arrêtez votre cluster.
- Lorsque vous utilisez des distributions sur site (on-premises), utilisez le composant de configuration correspondant au système de fichiers utilisé par votre cluster. Généralement, ce système est HDFS et vous devez utiliser le tHDFSConfiguration (en anglais).
Standalone mode : utilisez le composant de configuration correspondant au système de fichiers que votre cluster utilise, comme le tHDFSConfiguration Apache Spark Batch ou le tS3Configuration Apache Spark Batch (en anglais).

Si vous utilisez Databricks sans composant de configuration dans votre Job, vos données métier sont écrites directement dans DBFS (Databricks Filesystem).

Cette connexion fonctionne uniquement pour le Job dans lequel vous l'avez définie.

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – faites-le-nous savoir.

Laissez vos commentaires ici