Limites du connecteur Google Drive

Cette page liste les limites et les considérations pour l'ingestion depuis Google Drive à l'aide de Databricks Lakeflow Connect.

Limitations générales des connecteurs SaaS

Les limitations de cette section s'appliquent à tous les connecteurs SaaS de Lakeflow Connect.

• Lorsque vous exécutez un pipeline planifié, les alertes ne se Trigger pas immédiatement. Au lieu de cela, ils Trigger lors de l’exécution de la prochaine mise à jour.
• Lorsqu’une table source est supprimée, la table de destination n’est pas automatiquement supprimée. Vous devez supprimer la table de destination manuellement. Ce comportement n'est pas cohérent avec le comportement de Spark Declarative Pipelines sur Lakeflow.
• Pendant les périodes de maintenance de la source, Databricks pourrait ne pas être en mesure d'accéder à vos données.
• Si un nom de table source entre en conflit avec un nom de table de destination existant, la mise à jour du pipeline échoue.
• La prise en charge des pipelines multi-destination est uniquement via l'API.
• Vous pouvez éventuellement renommer une table que vous ingérez. Si vous renommez une table dans votre pipeline, il devient un pipeline API uniquement, et vous ne pouvez plus modifier le pipeline dans l'interface utilisateur.
• Si vous sélectionnez une colonne après qu'un pipeline a déjà start, le connecteur ne renseigne pas automatiquement les données historiques pour la nouvelle colonne. Pour ingérer des données historiques, exécutez manuellement un refresh complet sur la table.
• Databricks ne peut pas ingérer deux tables ou plus portant le même nom dans le même pipeline, même si elles proviennent de schémas sources différents.
• Le système source suppose que les colonnes du curseur augmentent de façon monotone.
• Le connecteur ingère des données brutes sans transformations. Utilisez les Spark Declarative Pipelines en aval sur les Lakeflow Pipelines pour les transformations.

Limitations spécifiques au connecteur

• Lors de l'ingestion non structurée à l'aide d'un fichier binaire, le contenu de chaque fichier est chargé en mémoire sous forme d'un enregistrement unique. Ainsi, les fichiers de plus de 100 Mo peuvent entraîner l'échec de la mise à jour (par exemple, en raison d'une erreur de mémoire insuffisante ou d'un dépassement de la limite de 2 Go pour les colonnes binaires dans Delta). Pour éviter cela, excluez les fichiers volumineux en utilisant un row_filter sur la colonne length dans table_configuration. Par exemple, "row_filter": "length <= 104857600" ignore les fichiers de plus de 100 Mo. Il n'y a pas de limite de taille de fichier pour les formats de fichier structurés.
• L'ingestion non structurée (BINARYFILE) ne prend en charge que le mode de stockage SCD_TYPE_1. L'ingestion structurée (CSV, JSON, XML, EXCEL et d'autres formats) ne prend en charge que le mode de stockage APPEND_ONLY. Le type 2 de SCD n'est pas pris en charge. Lors de la configuration du mode de stockage, définissez storage_mode dans table_configuration. La configuration du champ scd_type génère une erreur.
• La sélection individuelle de fichiers n'est pas prise en charge. Le connecteur ingère tous les fichiers d'un dossier ou d'un lecteur configuré. Pour affiner les fichiers ingérés, utilisez file_filters avec un path_filter modèle de caractères génériques.
• Pendant l'ingestion non structurée (BINARYFILE), les suppressions de fichiers ne sont suivies que lors de l'ingestion depuis un lecteur partagé. Les suppressions de fichiers ne sont pas suivies lors de l'ingestion à partir d'un dossier. Les mises à jour de fichiers sont suivies dans les deux cas.
• BINARYFILE, CSV, JSON, XML, EXCEL, PARQUET, AVRO, ORC sont pris en charge. Les formats non pris en charge (par exemple, Google Forms, Google Sites) sont ignorés lors de l'ingestion.