A propos d’Openflow

Snowflake Openflow est un service d’intégration qui connecte n’importe quelle source de données et n’importe quelle destination avec des centaines de processeurs prenant en charge les données textuelles structurées et non structurées, les images, l’audio, la vidéo et les données de capteurs. Basé sur Apache NiFi, Openflow vous permet d’exploiter un service entièrement géré dans votre propre Cloud pour un contrôle total.

Note

La plateforme Openflow est actuellement disponible pour le déploiement dans les propres VPCs des clients, à la fois dans AWS et Snowpark Container Services.

Cette rubrique décrit les principales fonctionnalités d’Openflow, ses avantages, son architecture, son workflow et ses cas d’utilisation.

Fonctions clés et avantages

Ouvert et extensible

Un service géré extensible alimenté par Apache NiFi, qui vous permet de créer et de développer des processeurs à partir de n’importe quelle source de données vers n’importe quelle destination.

Plateforme unifiée d’intégration des données

Openflow permet aux ingénieurs de données de traiter des extractions et des chargements de données bidirectionnels complexes grâce à un service entièrement géré qui peut être déployé au sein de votre propre VPC ou au sein de votre déploiement Snowflake.

Prêt pour l’entreprise

Openflow offre dès l’installation des mécanismes intégrés de sécurité, de conformité, d’observabilité et de maintenabilité pour l’intégration des données.

Ingestion haute vitesse de tous les types de données

Une plateforme unifiée vous permet de gérer des données structurées et non structurées, en mode streaming et en lot, depuis votre source de données vers Snowflake, à quasiment toutes les échelles.

Ingestion continue de données multimodales pour le traitement d’AI

Ingestion des données non structurées quasiment en temps réel pour vous permettre de discuter immédiatement avec vos données provenant de sources comme Sharepoint, Google Drive, etc.

Types de déploiement Openflow

Openflow est pris en charge à la fois dans les versions Bring Your Own Cloud (BYOC) et Snowpark Container Services (SPCS).

Openflow - Snowflake Deployment

Openflow - Snowflake Deployment, en utilisant Snowpark Container Services (SPCS), fournit une solution rationalisée et intégrée pour la connexion. Étant donné que SPCS est un service entièrement autonome au sein de Snowflake, il est facile à déployer et à gérer. SPCS offre un environnement pratique et rentable pour l’exécution de vos flux de données. Un avantage clé de Openflow - Snowflake Deployment est son intégration native au modèle de sécurité de Snowflake, qui permet une authentification, une autorisation et une sécurité réseau transparentes, ainsi que des opérations simplifiées.

Lors de la configuration de Openflow - Snowflake Deployments, suivez le processus indiqué dans Configurer Openflow - Déploiement Snowflake.

Openflow - Bring Your Own Cloud

Openflow - Bring Your Own Cloud (BYOC) fournit une solution de connexion que vous pouvez utiliser pour vous connecter en toute sécurité à des systèmes publics et privés et gérer le prétraitement des données sensibles localement, dans les limites sécurisées de l’environnement Cloud de votre entreprise. BYOC fait référence à une option de déploiement dans laquelle le moteur de traitement des données Openflow, ou le plan de données, s’exécute dans votre propre environnement Cloud, tandis que Snowflake gère l’ensemble du service Openflow et du plan de contrôle.

Lors de la configuration de déploiements BYOC, suivez le processus comme indiqué dans Configuration d’Openflow - BYOC.

Cas d’utilisation

Utilisez Openflow si vous souhaitez récupérer des données depuis n’importe quelle source et les envoyer vers n’importe quelle destination avec une gestion minimale, couplée à la sécurité et à la gouvernance des données intégrées de Snowflake.

Les cas d’utilisation d’Openflow incluent :

  • Ingérer des données à partir de sources de données non structurées, telles que Google Drive et Box, et les rendre prêtes pour le chat dans vos assistants AI avec Snowflake Cortex ou utiliser les données pour votre propre traitement personnalisé.

  • Répliquez la capture des données de changement (CDC) des tables de base de données dans Snowflake pour une réplication complète et centralisée.

  • Ingérer des événements en temps réel à partir de services de flux, tels qu’Apache Kafka, dans Snowflake pour des analyses en temps quasi réel.

  • Ingérer des données depuis des plateformes SaaS comme LinkedIn Ads vers Snowflake pour la création de rapports, les analyses et de les insights.

  • Créer un flux de données Openflow à l’aide de Snowflake et des processeurs et services de contrôleur<controllers/index> NiFi.

Sécurité

Snowflake utilise des fonctionnalités de sécurité de pointe qui vous assurent les plus hauts niveaux de sécurité pour votre compte, vos utilisateurs et toutes les données que vous stockez dans Snowflake. Voici quelques aspects clés :

Authentification
  • Les runtimes utilisent le Jeton géré par Snowflake comme méthode d’authentification par défaut et recommandée.

  • Le jeton géré par Snowflake fonctionne de manière cohérente à travers les types de déploiement SPCS et BYOC.

  • Les déploiements BYOC peuvent également utiliser l’authentification par paire de clés pour une gestion explicite des identifiants de connexion.

Autorisation
  • Openflow prend en charge des rôles à granularité fine pour RBAC.

  • ACCOUNTADMIN pour accorder des privilèges pour pouvoir créer des déploiements et des runtimes.

Chiffrement en transit
  • Les connecteurs Openflow prennent en charge le protocole TLS, en utilisant des clients Snowflake standard pour l’ingestion des données.

  • Toutes les communications entre les déploiements Openflow et le plan de contrôle Openflow sont chiffrées à l’aide du protocole TLS.

Gestion des secrets (BYOC)
Support pour les liens privés
  • Les connecteurs Openflow sont compatibles avec la lecture et l’écriture de données dans Snowflake à l’aide d’une connexion PrivateLink AWS entrante.

Tri-Secret Secure support
  • Le connecteur Openflow est compatible avec Tri-Secret Secure pour l’écriture des données sur Snowflake.

Authentification de jeton géré par Snowflake

Le jeton géré par Snowflake est la méthode d’authentification recommandée et par défaut pour les environnements d’exécution Openflow se connectant à Snowflake. Cette méthode d’authentification fonctionne de manière cohérente pour les déploiements Openflow - Snowflake et les déploiements BYOC. Le jeton géré par Snowflake fournit une expérience unifiée et simplifiée pour la configuration de la connexion Snowflake.

Avantages clés

Configuration simplifiée

Le jeton géré par Snowflake élimine la nécessité de générer, de stocker et de faire pivoter des identifiants de connexion de longue durée tels que des paires de clés. Le jeton est automatiquement géré par Snowflake, ce qui réduit les frais généraux.

Unifié entre les types de déploiement

Si vous déployez Openflow dans Snowpark Container Services (SPCS) ou Bring Your Own Cloud (BYOC), vous configurez l’authentification de la même manière en utilisant la stratégie d’authentification SNOWFLAKE_MANAGED.

Sécurité renforcée

Les jetons sont de courte durée et automatiquement actualisés, ce qui réduit le risque associé à l’exposition des informations d’identification.

Fonctionnement

Lorsque vous configurez un connecteur ou un processeur pour se connecter à Snowflake, sélectionnez SNOWFLAKE_MANAGED comme Stratégie d’authentification Snowflake. Le runtime obtient et gère automatiquement le jeton utilisé pour s’authentifier auprès de Snowflake en votre nom.

Le comportement du Jeton géré par Snowflake varie en fonction de votre type de déploiement :

Openflow - Snowflake Deployments

Lors de l’exécution dans un déploiement géré par Snowflake, le runtime utilise les jetons de session SPCS fournis nativement par l’environnement SPCS. Ces jetons sont disponibles au moment de l’exécution et ne nécessitent aucune configuration supplémentaire.

Déploiements BYOC

Lors de l’exécution dans un déploiement BYOC, le runtime utilise la fédération d’identité de charge de travail pour s’authentifier auprès de Snowflake. Le runtime échange automatiquement son identité de fournisseur Cloud (par exemple, un rôle AWS IAM) pour un jeton Snowflake.

Note

Pour utiliser un jeton géré par Snowflake dans les déploiements BYOC, vous devez d’abord configurer des Rôles d’exécution pour votre déploiement.

Quand utiliser le jeton géré par Snowflake

Utilisez le jeton géré par Snowflake pour :

  • Toutes les nouvelles configurations de connecteurs dans les déploiements SPCS et BYOC.

  • Migrations de l’authentification par paire de clés vers le modèle d’authentification simplifié et géré.

  • Scénarios dans lesquels vous souhaitez éviter de gérer des paires de clés ou d’autres identifiants de connexion de longue durée.

Autres méthodes d’authentification

Bien que le jeton géré par Snowflake soit recommandé, les déploiements BYOC prennent également en charge l’authentification par paire de clés (KEY_PAIR) pour les cas où vous avez besoin d’une gestion des identifiants explicite. Pour plus d’informations sur l’authentification par paire de clés, voir Authentification par paire de clés et rotation de paires de clés.

Pour plus d’informations sur les mécanismes d’authentification sous-jacents, voir ce qui suit :

Architecture

Le diagramme suivant illustre l’architecture Openflow :

Architecture Openflow

L’agent de déploiement installe et démarre l’infrastructure de déploiement Openflow dans votre VPC et synchronise régulièrement les images de conteneurs à partir du registre d’images du système Snowflake.

Les composants Openflow comprennent :

Déploiements

Un déploiement est l’endroit où vos flux de données s’exécutent, dans des exécutions individuelles. Vous aurez souvent plusieurs exécutions pour isoler différents projets et différentes équipes ou pour des raisons SDLC, le tout associé à un seul déploiement. Les déploiements existent en deux types Bring Your Own Cloud (BYOC) et Openflow - Snowflake.

Plan de contrôle

Le plan de contrôle est une couche contenant tous les composants utilisés pour gérer et observer les environnements d’exécution Openflow. Cela inclut le service et l’API Openflow, avec lesquels les utilisateurs interagissent via le canevas Openflow ou via l’interaction avec les APIs Openflow. Sur Openflow - Snowflake Deployments, le plan de contrôle se compose d’une infrastructure et de services Cloud publics appartenant à Snowflake, ainsi que de l’application de plan de contrôle elle-même.

Déploiements BYOC

Les déploiements BYOC sont des déploiements qui servent de conteneurs pour des environnements d’exécution qui sont déployés dans votre environnement Cloud. Ils encourent des frais en fonction de leur utilisation du calcul, de l’infrastructure et du stockage. Pour plus d’informations, voir Considérations relatives aux coûts et à la mise à l’échelle d’Openflow BYOC.

Openflow - Snowflake Deployments

Les déploiements Openflow - Snowflake sont des conteneurs pour les environnements d’exécution et sont déployés à l’aide d’un pool de calcul. Des frais d’utilisation sont facturés en fonction de leur temps de fonctionnement et de l’utilisation du calcul. Pour plus d’informations, voir Considérations relatives aux coûts et à la mise à l’échelle des déploiements Openflow Snowflake.

Temps d’exécution

Les :emph:`environnements d’exécution`hébergent vos pipelines de données, le framework assurant sécurité, simplicité et évolutivité. Vous pouvez déployer des exécutions Openflow dans votre VPC à l’aide d’Openflow. Vous pouvez déployer des connecteurs Openflow dans vos exécutions, mais également créer des pipelines entièrement nouveaux en utilisant des processeurs et des services de contrôleur Openflow.

Exécution Openflow - Snowflake Deployment

Les environnements d’exécution de déploiements Openflow - Snowflake sont déployés en tant que service:doc:`Snowpark Container Services </developer-guide/snowpark-container-services/overview>`vers un déploiement Openflow - Snowflake Deployment, qui est représenté par un pool de calcul sous-jacent. Les clients demandent une exécution par le biais du déploiement, qui exécute une requête pour le compte de l’utilisateur auprès du service. Une fois l’exécution créée, les clients y accèdent via un navigateur Web à l’URL générée pour ce service sous-jacent.