Données au niveau du journal - Exportation cloud

L’exportation cloud est une fonctionnalité utilisée pour transférer automatiquement des données Log-Level (LLD) vers le stockage cloud. Xandr prend en charge le transfert de données vers les compartiments Amazon S3, les compartiments Google Cloud Storage et les conteneurs Microsoft Stockage Blob Azure. Les données commencent à être transférées dès que les données de lot sont disponibles. Cette configuration permet une activation plus rapide et un flux de travail plus simple pour les clients Xandr (par exemple, il n’est pas nécessaire d’interroger le service siphon comme avec le service Log-Level Data).

Configuration de l’exportation cloud

Configuration requise

Vérifiez les points suivants avant de passer à l’installation.

1. Les flux LLD que vous prévoyez de consommer doivent déjà être activés pour votre siège Xandr (ID de membre). Si ce n’est pas le cas, contactez votre représentant de compte pour vous abonner aux données au niveau du journal.
2. Seuls les formats protobuf, protobuf-delimited et avro sont actuellement pris en charge par Xandr Cloud Export.
3. Vous devez disposer des privilèges network Administration pour effectuer les étapes ci-dessous.

Configuration

Suivez les procédures décrites dans les sections ci-dessous pour le fournisseur de cloud vers lequel vous souhaitez exporter. Xandr prend actuellement en charge les éléments suivants via l’interface utilisateur Xandr :

• Amazon S3
• Microsoft Stockage Blob Azure
• Stockage cloud Google

Amazon S3

1. Create un compartiment Amazon S3 qui servira de zone de liste déroulante pour les données au niveau du journal à partir du système D’exportation Xandr Cloud.

2. Sélectionnez Données au niveau du journal dans le menu Réseau (ou Rapports) de l’interface utilisateur Microsoft Invest ou Microsoft Monetize.

3. Cliquez sur Gérer dans la colonne Exportation cloud du flux pour lequel vous souhaitez créer une exportation S3. La section Amazon S3 s’affiche.

4. Cliquez sur Nouveau pour configurer une nouvelle exportation ou sur Configurer pour modifier une exportation existante. La page Exportation cloud vers : Amazon S3 s’affiche.

5. Configuration. Entrez les informations du tableau ci-dessous, puis cliquez sur Enregistrer :

   Setting	Description
   Seau	Nom du compartiment Amazon S3 créé à l’étape 1.
   Chemin du manifeste	Racine des fichiers manifeste (par exemple, /manifests). Ce chemin d’accès de fichier ne prend pas en charge les macros.
   Chemin d’accès du flux	Chemin de flux avec des macros (par exemple, /feeds/%FEED_NAME%/%YEAR%/%MONTH%/%DAY%/%HOUR%/%TIMESTAMP%)
   Notification Email	Liste d’e-mails séparés par des virgules. Si l’exportation cloud ne peut plus accéder à votre compartiment, votre exportation sera désactivée et vous serez averti par e-mail.
   Format	Format de données pour les fichiers de données au niveau du journal (par exemple, protobuf )
   Chiffrement côté serveur	Chiffrement côté serveur appliqué aux fichiers LLD chargés : - Aucun : n’appliquez pas le chiffrement côté serveur - SSE-S3 : appliquer le chiffrement côté serveur avec des clés de chiffrement gérées par Amazon S3 - SSE-KMS : appliquez le chiffrement côté serveur avec des clés de chiffrement gérées par AWS KMS. Vous devez accorder à l’utilisateur Xandr AWS l’accès à votre clé. La sélection de SSE-S3 ou SSE-KMS remplace tous les paramètres de chiffrement de compartiment par défaut pour les fichiers chargés.

1. Autorisation. Pour chaque siège de membre Xandr, Xandr crée un utilisateur AWS unique pour charger des données dans des compartiments S3. Xandr génère une stratégie de compartiment suggérée à appliquer à votre compartiment qui permet à notre utilisateur AWS d’accéder à votre compartiment. Cette stratégie peut être utilisée telle qu’elle est, mais si vous avez déjà appliqué une stratégie à votre compartiment, vous devrez fusionner nos instructions de stratégie avec les vôtres.

2. Vérification. Une fois que vous avez appliqué une stratégie à votre compartiment, vous devez vérifier vos autorisations avant que votre exportation cloud S3 puisse être activée. Cliquez sur Vérifier (dans la page Exportation cloud vers : Amazon S3 ) pour exécuter une série de tests qui imitent les actions qui se produisent pendant une exportation réelle. Une fois votre exportation vérifiée, elle est active. Les données du flux seront automatiquement exportées vers votre compartiment S3 (à partir de l’heure suivante).

Microsoft Stockage Blob Azure

1. Create un compte de stockage Azure qui hébergera un ou plusieurs conteneurs de stockage.

2. Create un conteneur de stockage Blob Azure à l’intérieur de votre compte de stockage qui servira de zone de dépôt pour les données au niveau du journal à partir du système D’exportation cloud Xandr.

3. Sélectionnez Données au niveau du journal dans le menu Réseau (ou Rapports) de l’interface utilisateur Xandr.

4. Cliquez sur Gérer dans la colonne Exportation cloud du flux pour lequel vous souhaitez créer une exportation stockage Blob Azure. La section Microsoft Stockage Blob Azure s’affiche.

5. Cliquez sur Nouveau pour configurer une nouvelle exportation ou sur Configurer pour modifier une exportation existante. La page Exportation cloud vers : Microsoft Stockage Blob Azure s’affiche.

6. Configuration. Entrez les informations du tableau ci-dessous, puis cliquez sur Enregistrer :

   Setting	Description
   Compte de stockage	Nom du compte de stockage Azure créé à l’étape 1.
   Container	Nom du conteneur de stockage d’objets blob Azure créé à l’étape 2.
   Chemin du manifeste	Racine des fichiers manifeste (par exemple, /manifests). Ce chemin d’accès de fichier ne prend pas en charge les macros.
   Chemin d’accès du flux	Chemin de flux avec des macros (par exemple, /feeds/%FEED_NAME%/%YEAR%/%MONTH%/%DAY%/%HOUR%/%TIMESTAMP%)
   Notification Email	Liste d’e-mails séparés par des virgules. Si l’exportation cloud ne peut plus accéder à votre conteneur, votre exportation sera désactivée et vous serez averti par e-mail.
   Format	Format de données pour les fichiers de données au niveau du journal (par exemple, protobuf)

7. Autorisation. Générez une signature d’accès partagé (SAP) pour le compte de stockage avec les autorisations suivantes :

   • Services autorisés - Objet blob
   • Types de ressources autorisés - Conteneur, Objet
   • Autorisations autorisées : lecture, écriture, suppression, liste, ajout, Create
   • Date/heure de début et d’expiration : sélectionnez la date d’expiration dans un avenir lointain
   • Protocoles autorisés - HTTPS uniquement
   • Après avoir créé le jeton SAS, collez-le dans le champ Jeton SAS de l’interface utilisateur Xandr, puis cliquez sur Enregistrer.

8. Vérification. Une fois que vous nous avez donné votre jeton SAS, vous devez vérifier vos autorisations SAS avant que votre Stockage Blob Azure Cloud Export puisse être activé. Cliquez sur Vérifier (dans la page Exporter dans le cloud vers : Microsoft Stockage Blob Azure) pour exécuter une série de tests qui imitent les actions qui se produisent lors d’une exportation réelle. Une fois votre exportation vérifiée, elle est active. Les données du flux seront automatiquement exportées vers votre conteneur Azure (à partir de l’heure suivante).

Stockage cloud Google

1. Create un compartiment de stockage Google qui servira de zone de liste déroulante pour les données au niveau du journal à partir du système D’exportation Xandr Cloud.

2. Sélectionnez Données au niveau du journal dans le menu Réseau (ou Rapports) de l’interface utilisateur Xandr.

3. Cliquez sur Gérer dans la colonne Exportation cloud du flux pour lequel vous souhaitez créer une exportation Google Cloud Storage. La section Stockage Google Cloud s’affiche.

4. Cliquez sur Nouveau pour configurer une nouvelle exportation ou sur Configurer pour modifier une exportation existante. La page Exportation cloud vers : Google Cloud Storage s’affiche.

5. Autorisation. Accédez à la console De stockage cloud, sélectionnez votre compartiment, puis cliquez sur AFFICHER LE PANNEAU D’INFORMATIONS. Ajoutez notre membre prod-lld-gcs-{XANDR MEMBER ID}@appnexus-cloud-export.iam.gserviceaccount.com Google à vos autorisations de compartiment et attribuez-lui le rôle Cloud Storage IAM (ce rôle dispose de l’accès administrateur complet). Voici un exemple de membre Google pour l’ID de membre Xandr 123456 : prod-lld-gcs-123456@appnexus-cloud-export.iam.gserviceaccount.com

6. Configuration. Entrez les informations du tableau ci-dessous, puis cliquez sur Enregistrer :

   Setting	Description
   Compartiment	Nom du compartiment de stockage Google créé à l’étape 1.
   Chemin du manifeste	Racine des fichiers manifeste (par exemple, /manifests). Ce chemin d’accès de fichier ne prend pas en charge les macros.
   Chemin d’accès du flux	Chemin de flux avec des macros (par exemple, /feeds/%FEED_NAME%/%YEAR%/%MONTH%/%DAY%/%HOUR%/%TIMESTAMP%)
   Notification Email	Liste d’e-mails séparés par des virgules. Si l’exportation cloud ne peut plus accéder à votre compartiment, votre exportation sera désactivée et vous serez averti par e-mail.
   Format	Format de données pour les fichiers de données au niveau du journal (par exemple, protobuf)

   Avertissement

   Ne créez pas manuellement de chemins liés au manifeste ou au flux. Cela entraînera l’échec de la vérification de votre exportation en raison de listes de contrôle d’accès au niveau de l’objet.

   Les chemins nécessaires seront automatiquement créés par Xandr.

7. Vérification. Une fois que vous avez donné à notre membre Google le rôle d’Administration de stockage dans votre compartiment, vous devez vérifier vos autorisations avant que votre exportation Google Storage Cloud puisse être activée. Cliquez sur Vérifier (dans la page Exportation cloud vers : Google Cloud Storage ) pour exécuter une série de tests qui imitent les actions qui se produisent lors d’une exportation réelle. Une fois votre exportation vérifiée, elle est active. Les données du flux seront automatiquement exportées vers votre compartiment Google Cloud Storage (à compter de l’heure suivante).

Échecs et désactivation des exportations

Si l’exportation échoue, Xandr exécute automatiquement des tests de vérification pour s’assurer que l’échec n’est pas dû à un problème d’autorisation.

• Si l’échec est dû à un problème d’autorisation, votre exportation est désactivée et vous en êtes averti par e-mail. Vous devrez ensuite vérifier à nouveau votre exportation. Une vérification réussie réactivera votre exportation.
• Si l’échec n’est pas dû à des problèmes d’autorisations, l’exportation est automatiquement à nouveau tentée.

Macros de chemin de flux

Les macros peuvent être utilisées dans les chemins de flux pour personnaliser l’emplacement de sortie du flux par heure de données, horodatage du flux et d’autres métadonnées. Les macros prises en charge sont répertoriées ci-dessous :

Fichiers manifestes

Les fichiers manifeste permettent de suivre les fichiers chargés par le service Cloud Export. Étant donné que les magasins d’objets cloud (par exemple, Amazon S3, Stockage Blob Azure, Google Cloud Storage) sont finalement cohérents, une source de vérité (c’est-à-dire, les fichiers qui doivent exister) est requise pour les consommateurs en aval. Le fichier manifeste est un objet JSON écrit dans un emplacement préconfiguré dans votre compartiment. Elle est spécifiée au format JSONSchema . Nous recommandons que tous les accès aux chemins d’accès (par exemple, pour le traitement des données, la purge, etc.) soient effectués en référençant d’abord les fichiers manifestes. Les fichiers manifeste contiennent des informations importantes sur l’âge, la status et le format des données.

Nommage des fichiers et chemins d’accès

Les fichiers manifeste sont créés lorsque le flux commence à traiter pendant une heure donnée. Les fichiers seront créés à l’emplacement du chemin d’accès que vous avez spécifié. Les noms de fichier manifeste contiennent le nom du flux, un horodatage indiquant l’heure des données (la plage de temps qu’il couvre) et un horodatage de traitement. Un fichier manifeste est créé pour chaque flux, ID de membre (siège), heure de données et exécution de flux. Xandr retraite automatiquement les données en fonction des besoins. Les fichiers reçoivent également des suffixes indiquant le status du travail de flux associé.

• Si un fichier manifeste a le suffixe « -failed » ou « -processing », cela indique que le flux n’a pas été correctement traité.
• Si un fichier manifeste n’a pas de suffixe, cela indique que les données du flux sont prêtes pour l’ingestion.

Format général

{feed_name}-{seat_id}-{YYYYMMddHH}-{yyyyMMddHHmmss}.json[-{suffix}]

État : « Traitement »

État : « Échec »

État : « Réussi »

Flux de travail de traitement des flux

Il est utile de comprendre comment les travaux de flux interprètent les fichiers manifeste afin de générer votre logique en aval. Le processus est le suivant :

1. Le chemin du manifeste est analysé pour les entrées avec le suffixe « -processing ». Les entrées avec ce suffixe indiquent une exécution précédente qui a rencontré une erreur irrécupérable. Ces entrées sont renommées avec un suffixe « -failed » (par exemple, json-processing>.json-failed).  
2. Un fichier manifeste est généré et écrit dans le compartiment avec un suffixe « -processing ».
3. Les données de flux sont écrites dans le compartiment.
4. Si le processus d’écriture échoue, le fichier manifeste est renommé pour inclure un suffixe « -failed » (par exemple, .json-failed). Si le processus d’écriture est correctement terminé, le suffixe « -processing » est simplement supprimé (par exemple, .json-processing>.json), ce qui indique une exécution terminée.

Schéma de fichier manifeste

Le schéma du fichier manifeste est décrit dans le format JSONSchema bien connu. Xandr recommande des classes de génération de code à partir du JSONSchema que nous fournissons. Un projet qui y parvient pour Java est jsonschema2pojo.  

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "description": "Schema for the cloud export feed file manifest",
  "type": "object",
  "required": [
    "hour",
    "files",
    "feed_type",
    "path",
    "processed_on",
    "feed_properties",
    "seat_id"
  ],
  "properties": {
    "hour": {
      "description": "Timestamp for the data in yyyy-MM-dd HH:mm:ss",
      "type": "string"
    },
    "files": {
      "description": "array of object describing the exported files",
      "type": "array",
      "items": {
        "$ref": "#/definitions/feed_file"
      }
    },
    "feed_type": {
      "description": "name of the feed",
      "type": "string"
    },
    "path": {
      "description": "fully qualified destination location",
      "type": "string"
    },
    "processed_on": {
      "description": "completion timestamp of feed (yyyyMMddHHmmss)",
      "type": "string"
    },
    "feed_properties": {
      "description": "data format related information",
      "type": "object",
      "$ref": "#/definitions/feed_properties"
    },
    "seat_id" : {
      "description" : "the Xandr seat id that these files belong to",
      "type" : "integer"
    }
  },
  "definitions": {
    "feed_file": {
      "type": "object",
      "required": [
        "checksum",
        "name"
      ],
      "properties": {
        "checksum": {
          "type": "string"
        },
        "name": {
          "type": "string"
        }
      }
    },
    "feed_properties": {
      "type": "object",
      "required": [
        "compression_type",
        "container_format",
        "checksum_type",
        "data_format"
      ],
      "properties": {
        "compression_type": {
          "description": "type of compression used on the files (BLOCK level compression for sequence files)",
          "type": "string",
          "enum": [
            "DEFLATE",
            "GZIP",
            "SNAPPY",
            "NONE"
          ]
        },
        "container_format": {
          "description": "container format of the data",
          "type": "string",
          "enum": [
            "AVRO",
            "SEQUENCE",
            "NONE"
          ]
        },
        "data_format": {
          "description": "format of the data",
          "type": "string",
          "enum": [
            "protobuf",
            "protobuf-delimited",
            "avro"
          ]
        },
        "checksum_type": {
          "description": "type of checksum",
          "type": "string",
          "enum": [
            "MD5"
          ]
        }
      }
    }
  }
}

Exemple de fichier manifeste

{
  "hour" : "2017-02-09 16:00:00",
  "files" : [ {
    "checksum" : "ccd5774e8fc785b4df3d63627f992c4b",
    "name" : "998-10-ccd5774e8fc785b4df3d63627f992c4b-998"
  }, {
    "checksum" : "c8c442ff5eb24237573faa2d60a689b1",
    "name" : "998-11-c8c442ff5eb24237573faa2d60a689b1-998"
  } ],
  "feed_type" : "standard_feed",
  "path" : "/standard_feed/2017/02/09/16/20170209220747",
  "processed_on" : "20170209220747",
  "feed_properties" : {
    "compression_type" : "SNAPPY",
    "container_format" : "SEQUENCE",
    "data_format" : "protobuf",
    "checksum_type" : "MD5"
  },
  "seat_id" : 998
}

Échecs/chargements partiels

Les échecs de travail de flux peuvent entraîner un chargement partiel des données. Pour éviter de consommer des données partiellement chargées, utilisez les noms de fichier manifeste pour déterminer ce qu’il faut consommer.

• Ne consommez pas de fichiers qui auront le suffixe « -processing » ou « -failed ». Il s’agit de jeux de données incomplets.
• Consommez uniquement les données des chemins d’accès correspondant aux chargements terminés (c’est-à-dire, les fichiers manifeste avec une extension .json mais aucun suffixe supplémentaire).

Purge

Lors de la purge des anciennes données de votre compartiment, les fichiers manifeste doivent être utilisés pour déterminer quand les données sont éligibles pour la purge. Videz uniquement les fichiers qui ne sont plus pertinents (par exemple, plus d’une semaine).

Retraitement

Les flux traités à nouveau pendant une heure donnée ne remplaceront jamais les anciennes données. Xandr retraite les données lorsque des incohérences sont détectées. Lorsqu’un travail de flux est retraité, il y a deux fichiers manifeste (ou plus) correspondant à la même heure de données. Toutefois, les horodatages de traitement et les chemins d’accès diffèrent entre les exécutions. Le fichier avec le dernier horodatage sera le fichier corrigé.

Perte de données client

Xandr ne réexporte pas les données qui ont déjà été exportées avec succès. Pour atténuer les situations dans lesquelles vous avez peut-être accidentellement supprimé des données exportées avec succès, nous vous recommandons de tirer parti des fonctionnalités de sauvegarde ou de gestion de version de votre fournisseur de cloud.

Résolution des problèmes

Critères d’unicité pour les configurations

Votre configuration d’exportation cloud doit être unique, ce qui signifie que :

• Pour les chemins d’accès de manifeste :
  • Pour Microsoft Azure, si la destination (compte de stockage et conteneur) combinée et le chemin d’accès sont identiques, l’ID de membre et le fluxdoivent être différents.
  • Pour toutes les autres configurations, si le compartiment et le chemin sont identiques, l’ID de membre et le fluxdoivent être différents.
• Pour les chemins d’accès de flux, si les chemins d’accès de destination et de flux résolu sont identiques , l’ID de membre doit être différent et le flux et le formatdoivent être identiques.

Problèmes de vérification

La section ci-dessous décrit quelques problèmes courants que vous pouvez rencontrer lors de la configuration de la vérification.

Actions de vérification ayant échoué possibles :

• Vérification des fichiers manifeste dans GLACIER
• Vérification de l’accès aux méta-informations sur les fichiers manifeste
• Création d’un préfixe à l’adresse <path>

Vérification des fichiers manifeste dans GLACIER

Cause potentielle : l’archivage des fichiers manifeste n’est pas correctement configuré

S’applique à : Amazon S3

Solution :

Vérifiez que toutes les règles de cycle de vie sont configurées pour déplacer les objets manifeste vers Glacier uniquement s’ils ne se trouvent pas dans le chemin des manifestes (manifestes/archive est correct).

Vérification de l’accès aux méta-informations sur les fichiers manifeste

Cause potentielle : Vous révomez l’accès au niveau de l’objet pour les manifestes non archivés

S’applique à :

• Amazon S3

Solution : Pour chaque objet, aws s3api get-object-acl --bucket <bucket> --key <object> doit produire ce qui suit comme l’une des subventions pour chaque objet manifeste non archivé :

{
   "Grantee": {
    "Type": "CanonicalUser",
    "DisplayName": "aws-slld",
    "ID": "669331f902bdea32b620b6e6c85123d153b5b30c8318b101d2fd202bc3906fe1"
    },
    "Permission": "FULL_CONTROL"
},

• Stockage cloud Google

Solution : Pour chaque objet, gsutil acl get <object> doit produire ce qui suit comme l’une des subventions pour chaque objet manifeste non archivé :

{
    "email": "prod-lld-gcs-<member>@appnexus-cloud-export.iam.gserviceaccount.com",
    "entity": "user-prod-lld-gcs-<member>@appnexus-cloud-export.iam.gserviceaccount.com",
    "role": "OWNER"
}

Création d’un préfixe à l’adresse <path>

Cause potentielle : Vous avez déjà appliqué l’autorisation à votre compartiment ou conteneur, mais vous avez créé manuellement des « dossiers » de manifeste ou de flux.

S’applique à : Toutes les configurations d’exportation cloud

Solution :

Les objets créés manuellement ont des listes de contrôle d’accès différentes qui peuvent refuser l’accès au système d’exportation cloud. Supprimez tous les objets de manifeste ou de flux créés manuellement. Le système d’exportation cloud crée lui-même les objets nécessaires.