Paramétrez Openflow Connector for Kinesis¶

Conditions préalables¶

1. Assurez-vous d’avoir consulté À propos de Openflow Connector for Kinesis.

2. Assurez-vous que vous avez paramétré Openflow.

Configurez un flux Kinesis¶

En tant qu’administrateur AWS, effectuez les actions suivantes dans votre compte AWS:

1. Assurez-vous que vous disposez d’un compte AWS avec des autorisations IAM d’accès à Kinesis Streams et DynamoDB.

2. Optionnellement, créez une file d’attente de lettres mortes (DLQ) Kinesis Stream. Les messages qui ne peuvent pas être analysés avec succès peuvent être redirigés vers un DLQ désigné.

Paramétrage du compte Snowflake¶

En tant qu’administrateur de compte Snowflake, effectuez les tâches suivantes :

1. Créez un nouveau rôle ou utilisez un rôle existant et accordez le Privilèges de base de données.

2. Créez une base de données de destination et un schéma de destination qui serviront à créer les tables de destination pour le stockage des données.

   1. Si vous planifiez d’utiliser la capacité du connecteur à créer automatiquement la table de destination si elle n’existe pas encore, assurez-vous que l’utilisateur dispose des privilèges requis pour la création et la gestion d’objets Snowflake :

      Objet	Privilège	Remarques
      Base de données	USAGE
      Schéma	USAGE . CREATE TABLE .	Une fois les objets au niveau du schéma ont été créés, les privilèges CREATE object peuvent être révoqués.
      Table	OWNERSHIP	Uniquement requis lorsque vous utilisez le connecteur Kinesis pour ingérer des données dans une table existante. . Si le connecteur crée une nouvelle table cible pour les enregistrements du flux Kinesis, le rôle par défaut de l’utilisateur spécifié dans la configuration devient le propriétaire de la table.

      Vous pouvez utiliser le script suivant pour créer et configurer un rôle personnalisé (exigence : SECURITYADMIN ou équivalent) :

      USE ROLE SECURITYADMIN;
      
      CREATE ROLE kinesis_connector_role_1;
      GRANT USAGE ON DATABASE kinesis_db TO ROLE kinesis_connector_role_1;
      GRANT USAGE ON SCHEMA kinesis_schema TO ROLE kinesis_connector_role_1;
      GRANT CREATE TABLE ON SCHEMA kinesis_schema TO ROLE kinesis_connector_role_1;
      
      -- Only for existing tables
      GRANT OWNERSHIP ON TABLE existing_table1 TO ROLE kinesis_connector_role_1;
      

      Copy

3. Créez un nouvel utilisateur du service Snowflake avec le type SERVICE.

4. Autorisez l’utilisateur du service Snowflake le rôle que vous avez créé dans les étapes précédentes.

   GRANT ROLE kinesis_connector_role_1 TO USER kinesis_connector_user_1;
   ALTER USER kinesis_connector_user_1 SET DEFAULT_ROLE = kinesis_connector_role_1;
   

   Copy

5. Configurez avec l’authentification par paire de clés pour l’utilisateur de Snowflake SERVICE de l’étape 3.

6. Snowflake recommande vivement cette étape. Configurez un gestionnaire de secrets pris en charge par Openflow, par exemple AWS, Azure et Hashicorp, et stockez les clés publiques et privées dans le magasin de secrets.

   Note

   Si, pour une raison quelconque, vous ne souhaitez pas utiliser un gestionnaire de secrets, il vous incombe de protéger les fichiers de clés publiques et privées utilisés pour l’authentification par paires de clés conformément aux politiques de sécurité de votre organisation.

   1. Une fois le gestionnaire de secrets configuré, déterminez comment vous vous y authentifierez. Sur AWS, il est recommandé d’utiliser le rôle de l’instance EC2 associée à Openflow, car de cette manière, aucun autre secret ne doit être conservé.

   2. Dans Openflow, configurez un fournisseur de paramètres associé à ce gestionnaire de secrets, à partir du menu hamburger en haut à droite. Naviguez vers Controller Settings » Parameter Provider et récupérez les valeurs de vos paramètres.

   3. À ce stade, tous les identifiants peuvent être référencés avec les chemins de paramètres associés et aucune valeur sensible ne doit être conservée dans Openflow.

7. Si d’autres utilisateurs de Snowflake ont besoin d’accéder aux documents bruts ingérés et aux tables ingérées par le connecteur (par exemple, pour un traitement personnalisé dans Snowflake), accordez à ces utilisateurs le rôle créé à l’étape 1.

8. Désignez un entrepôt à utiliser par le connecteur. Commencez par la taille d’entrepôt la plus petite, puis faites des essais en fonction du nombre de tables répliquées et de la quantité de données transférées. Les tables de grande taille s’adaptent généralement mieux aux entrepôts multi-clusters, plutôt qu’aux entrepôts de grande taille.

Définir le connecteur¶

En tant qu’ingénieur des données, effectuez les tâches suivantes pour installer et configurer le connecteur :

Exécutez le flux¶

1. Cliquez avec le bouton droit de la souris sur l’avion et sélectionnez Enable all Controller Services.

2. Cliquez avec le bouton droit de la souris sur le groupe de processus importé et sélectionnez Start.

Le connecteur démarre l’ingestion des données.

{
    "id": 1,
    "name": "Steve",
    "body_temperature": 36.6,
    "approved_coffee_types": ["Espresso", "Doppio", "Ristretto", "Lungo"],
    "animals_possessed":
    {
        "dogs": true,
        "cats": false
    },
    "date_added": "2024-10-15"
}

Problèmes connus¶

• Le groupe de processus du connecteur possède un port de sortie appelé « Échec du téléchargement ». Il peut être utilisé pour gérer FlowFiles qui n’a pas été téléchargé avec succès vers Snowflake. Si ce port n’est pas connecté en dehors du groupe de processus du connecteur, il affichera un signe d’avertissement qui peut être ignoré.

• Tous les processeurs, lorsqu’ils sont à l’arrêt, peuvent être remis en marche une fois. En raison de son architecture interne, le processeur ConsumeKinesisStream n’effectuera aucun travail significatif lorsqu’on lui demandera de fonctionner une seule fois. Pour que le processeur commence à fonctionner, il doit être mis en marche et fonctionner pendant environ deux minutes.