Aller au contenu principal

Connecter une source de données

Les connexions sont le premier élément d'état de plateforme dont dépendent vos tableaux de bord, et l'illustration la plus claire de la répartition des rôles : le tableau de bord est du code que votre agent écrit et peut réécrire en une minute ; la connexion est un identifiant, un chemin réseau et un schéma introspecté que quelqu'un a configuré une fois et qui doit continuer de fonctionner pendant un an.

Vous configurez une connexion une fois. À partir de là, chaque surface interroge à travers elle — votre agent via MCP, votre code via les SDKs, l'assistant intégré à l'application, et chaque tableau de bord publié.

Ce que vous pouvez connecter​

Vibedasher compte 20 types de connexion. Dix-neuf disposent d'une implémentation de service fonctionnelle, et dix-neuf sont proposés dans le sélecteur de connecteurs de l'application aujourd'hui. La différence compte si vous évaluez le produit face à une source spécifique, voici donc la liste complète plutôt qu'un chiffre marketing.

Bases de données et entrepôts​

SourceDans le sélecteurChargements incrémentaux
PostgreSQLouioui
MySQLouioui
SQL Server (MSSQL)ouioui
Oracleouioui
Redshiftouioui
Snowflakeouioui
BigQueryouioui
Athenaouioui
MongoDBouinon
Cassandraouinon
DynamoDBouinon

SaaS et stockages de fichiers​

SourceDans le sélecteurChargements incrémentaux
Salesforceouinon
HubSpotouinon
Marketoouinon
Mailchimpouinon
Google Sheetsouinon
Google Analyticsouinon
Azure Data Lakeouinon
Google Cloud Storageouinon
SAPnonnon

SAP a besoin de pyrfc, le SDK RFC NetWeaver propriétaire de SAP, qui n'est pas sur PyPI — le connecteur n'est donc pas déployé. Une ligne de connexion sap existe encore sur certains comptes, et l'introspection de schéma contre elle répond 404.

Import de fichier plat​

L'import accepte le CSV (.csv) et Excel (.xlsx, .xls).

Parquet n'est pas un format d'import. Vibedasher stocke vos données en Parquet en interne, mais ce n'est pas un format que vous pouvez importer. Si vos données sont déjà en Parquet, déposez-les dans un stockage que Vibedasher peut interroger, ou convertissez-les en CSV.

Les chargements incrémentaux ont besoin d'un dialecte SQL​

La colonne Chargements incrémentaux ci-dessus n'est pas une décision produit, c'est une contrainte mécanique. Un chargement incrémental fonctionne en réécrivant votre requête d'extraction pour ajouter un prédicat de filigrane (watermark), et cette réécriture a besoin d'un dialecte SQL que la plateforme peut analyser. Huit connecteurs en ont un — PostgreSQL, MySQL, SQL Server, Oracle, Redshift, Snowflake, BigQuery et Athena.

Tous les autres connecteurs, y compris MongoDB, DynamoDB et toutes les sources SaaS, s'actualisent par rechargement complet. C'est correct, juste plus coûteux : prévoyez le budget pour une source volumineuse, et voyez Garder vos données fraîches pour ce que effectiveMode remonte.

Ajouter une connexion​

  1. Ouvrez l'application sur cloud.vibedasher.com et allez dans Connexions.
  2. Choisissez le type de source et renseignez les détails de connexion — ou importez votre fichier.
  3. Lancez Tester la connexion. Cela ouvre réellement la connexion ; ce n'est pas une simple vérification de format de champ.
  4. Enregistrez. Vibedasher introspecte le schéma pour que les agents et le moteur de requêtes sachent quelles tables et colonnes existent.
Modifier une connexion plus tard

Les identifiants stockés sont masqués dans l'interface. Quand vous modifiez une connexion, laissez un champ masqué intact pour conserver la valeur existante — la plateforme détecte le masque au retour et préserve ce qu'elle a déjà, plutôt que d'écraser votre mot de passe par une rangée de points.

Vous pouvez aussi faire tout cela depuis le code :

schema = client.connections.get_schema(connection_type, connection_id)
tables = client.connections.get_tables(connection_type, connection_id)
const schema = await client.connections.getSchema(connectionType, connectionId);
const tables = await client.connections.getTables(connectionType, connectionId);

L'ensemble complet — create, list, get, update, updateMetadata, delete, test, getSchema, getTables, getTableSchema, validateQuery — se trouve dans la Référence API.

Qui peut gérer une connexion​

Les connexions ne sont pas couvertes par le modèle de droits d'accès des dossiers — il n'y a pas de droit par connexion. Les règles sont plus simples et méritent d'être énoncées clairement :

  • Tout créateur ou admin peut créer une connexion. Un visionneur ne le peut pas.
  • Seul le propriétaire de la connexion ou un admin peut la modifier ou la supprimer.
  • Une connexion n'est pas visible du reste du compte de la même façon qu'un dossier partagé.

Si vous avez besoin qu'une connexion soit gérée par plusieurs personnes, un admin devrait en être le propriétaire. Voir Qui peut voir quoi pour le reste du modèle de permissions.

Jeux de données​

Une connexion est une route vers vos données ; un jeu de données est ce que les tableaux de bord lisent réellement. Vous créez des jeux de données à partir d'une connexion — une table, ou le résultat d'une requête.

Chaque jeu de données obtient un alias cleanSQLName, qui est le nom de table contre lequel votre agent écrit du SQL. Un jeu de données passe par PENDING → DOWNLOADING → PROCESSING → READY, et un tableau de bord construit sur un jeu de données qui n'a pas atteint READY n'aura rien à afficher. Attendez READY.

Les jeux de données sont un état vivant, pas des imports ponctuels : déclenchez une actualisation pour en faire avancer un, et exécutez des projets dbt en aval de celui-ci. Les tableaux de bord récupèrent les données actualisées via le même moteur de requêtes, sans reconstruction — ce qui est toute la raison pour laquelle la moitié « données » vit ici et non dans la session de votre agent.

Prochaine étape​

Connectez votre agent au jeu de données — Construire avec votre agent (MCP) — ou pointez votre agent dessus. Puis configurez des actualisations pour qu'il reste fidèle.