Datos de nivel de registro: exportación en la nube
Importante
- No cree manualmente ninguna ruta de acceso relacionada con manifiestos o fuentes. Si lo hace, la exportación no podrá comprobarse debido a las ACL de nivel de objeto. Xandr creará automáticamente las rutas de acceso necesarias.
- Xandr proporciona exportaciones masivas de datos de nivel de registro (LLD) mediante claves específicas del cliente (tal como se configura mediante los procedimientos de esta página). Los datos se exportan a través de transferencias de archivos SSL a la ubicación de almacenamiento en la nube del cliente (consulte a continuación las opciones). La seguridad de esos contenedores o cubos de cliente es responsabilidad exclusiva del cliente.
Cloud Export es una característica que se usa para transferir automáticamente datos de Log-Level (LLD) al almacenamiento en la nube. Xandr admite la transferencia de datos a cubos de Amazon S3, cubos de Google Cloud Storage y contenedores de Microsoft Azure Blob Storage. Los datos comienzan a transferirse en cuanto los datos por lotes están disponibles. Esta configuración proporciona una habilitación más rápida y un flujo de trabajo más sencillo para los clientes Xandr (por ejemplo, no es necesario sondear el servicio siphon como con el servicio Log-Level Data).
Configuración de exportación en la nube
Requisitos previos
Confirme lo siguiente antes de continuar con la configuración.
- Las fuentes LLD que planea consumir ya deben estar habilitadas para su asiento Xandr (id. de miembro). Si ese no es el caso, póngase en contacto con su representante de cuenta para suscribirse a los datos de nivel de registro.
- En este momento, Xandr Cloud Export solo admite los formatos protobuf, protobuf-delimitado y avro .
- Debe tener privilegios de Administración de red para realizar los pasos siguientes.
Instalación
Siga los procedimientos descritos en las secciones siguientes para el proveedor en la nube al que desea exportar. Actualmente, Xandr admite lo siguiente a través de la interfaz de usuario de Xandr:
Nota:
Si usa un firewall u otras características de seguridad que restringen ip, agregue todas estas direcciones IP e intervalos a la lista de permitidos:
Direcciones IP: 68.67.155.230, 68.67.155.231, 68.67.135.70, 68.67.135.71
Intervalos IP correspondientes a direcciones o máscaras de subred: 185.83.140.64/28, 68.67.146.64/28, 43.250.0.160/28, 68.67.156.64/28
Amazon S3
Create un cubo de Amazon S3 que servirá como caja desplegable para los datos de nivel de registro del sistema Xandr Cloud Export.
Seleccione Datos de nivel de registro en el menú Red (o Informes) de la interfaz de usuario de Microsoft Invest o Microsoft Monetize.
Haga clic en Administrar en la columna Exportación en la nube de la fuente para la que desea crear una exportación S3. Se mostrará la sección Amazon S3 .
Haga clic en Nuevo para configurar una nueva exportación o en Configurar para editar una exportación existente. Se mostrará la página Cloud Export to: Amazon S3 (Exportación en la nube a: Amazon S3 ).
Configuración. Escriba la información de la tabla siguiente y haga clic en Guardar:
Configuración Descripción Cubo Nombre del bucket de Amazon S3 creado en el paso 1. Ruta de acceso del manifiesto Raíz de los archivos de manifiesto (por ejemplo, /manifests). Esta ruta de acceso de archivo no admite macros. Ruta de acceso de fuente Ruta de acceso de fuente con macros (por ejemplo, /feeds/%FEED_NAME%/%YEAR%/%MONTH%/%DAY%/%HOUR%/%TIMESTAMP%) Notificación Email Lista de correos electrónicos separados por comas. Si Cloud Export ya no puede acceder al cubo, la exportación se desactivará y se le notificará por correo electrónico. Format Formato de datos para archivos de datos de nivel de registro (por ejemplo, protobuf ) Cifrado del lado servidor Cifrado del lado servidor aplicado a los archivos LLD cargados:
- Ninguno: no aplique el cifrado del lado servidor.
- SSE-S3 : aplicación del cifrado del lado servidor con claves de cifrado administradas por Amazon S3
- SSE-KMS : aplique el cifrado del lado servidor con claves de cifrado administradas por AWS KMS. Debe conceder al usuario de Xandr AWS acceso a la clave.
Al seleccionar SSE-S3 o SSE-KMS, se invalidará cualquier configuración de cifrado de cubo predeterminada para los archivos cargados.
Advertencia
No cree manualmente ninguna ruta de acceso relacionada con manifiestos o fuentes. Si lo hace, la exportación no podrá comprobarse debido a las ACL de nivel de objeto. Xandr creará automáticamente las rutas de acceso necesarias.
Autorización. Para cada asiento de miembro de Xandr, Xandr crea un usuario de AWS único para cargar datos en cubos de S3. Xandr genera una directiva de cubo sugerida para aplicarla al bucket que permite a nuestro usuario de AWS acceder al bucket. Esta directiva se puede usar tal y como está, pero si ya tiene una directiva aplicada al cubo, tendrá que combinar nuestras instrucciones de directiva con las suyas.
Verificación. Una vez que aplique una directiva al cubo, debe comprobar los permisos antes de que se pueda activar la exportación de S3 Cloud. Haga clic en Comprobar (en la página Cloud Export to: Amazon S3 ) para ejecutar una serie de pruebas que imitan las acciones que se producen durante una exportación real. Una vez verificada la exportación, está activa. Los datos de la fuente se exportarán automáticamente al cubo S3 (a partir de la próxima hora).
Microsoft Azure Blob Storage
Create una cuenta de Almacenamiento de Azure que hospedará uno o varios contenedores de almacenamiento.
Create un contenedor de Azure Blob Storage dentro de la cuenta de almacenamiento que servirá como una casilla desplegable para los datos de nivel de registro del sistema Xandr Cloud Export.
Seleccione Datos de nivel de registro en el menú Red (o Informes) en la interfaz de usuario de Xandr.
Haga clic en Administrar en la columna Cloud Export de la fuente para la que desea crear una exportación de Azure Blob Storage. Se mostrará la sección Microsoft Azure Blob Storage.
Haga clic en Nuevo para configurar una nueva exportación o en Configurar para editar una exportación existente. Se mostrará la página Cloud Export to: Microsoft Azure Blob Storage (Exportación en la nube a: Microsoft Azure Blob Storage).
Configuración. Escriba la información de la tabla siguiente y haga clic en Guardar:
Configuración Descripción Cuenta de almacenamiento Nombre de la cuenta de Almacenamiento de Azure creada en el paso 1. Container Nombre del contenedor de Azure Blob Storage creado en el paso 2. Ruta de acceso del manifiesto Raíz de los archivos de manifiesto (por ejemplo, /manifests). Esta ruta de acceso de archivo no admite macros. Ruta de acceso de fuente Ruta de acceso de fuente con macros (por ejemplo, /feeds/%FEED_NAME%/%YEAR%/%MONTH%/%DAY%/%HOUR%/%TIMESTAMP%) Notificación Email Lista de correos electrónicos separados por comas. Si Cloud Export ya no puede acceder a su contenedor, la exportación se desactivará y se le notificará por correo electrónico. Format Formato de datos para archivos de datos de nivel de registro (por ejemplo, protobuf) Autorización. Genere una firma de acceso compartido (SAS) para la cuenta de almacenamiento con los permisos siguientes:
- Servicios permitidos: blob
- Tipos de recursos permitidos: contenedor, objeto
- Permisos permitidos: lectura, escritura, eliminación, lista, agregarCreate
- Fecha y hora de inicio y expiración: seleccione la fecha de expiración en un futuro lejano.
- Protocolos permitidos: solo HTTPS
- Después de crear el token de SAS, péguelo en el campo Token de SAS de la interfaz de usuario de Xandr y haga clic en Guardar.
Verificación. Una vez que nos proporcione el token de SAS, debe comprobar los permisos de SAS antes de que se pueda activar el Azure Blob Storage Cloud Export. Haga clic en Comprobar (en la página Cloud Export to: Microsoft Azure Blob Storage) para ejecutar una serie de pruebas que imitan las acciones que se producen durante una exportación real. Una vez verificada la exportación, está activa. Los datos de la fuente se exportarán automáticamente al contenedor de Azure (a partir de la próxima hora).
Google Cloud Storage
Create un bucket de Almacenamiento de Google que servirá como un cuadro desplegable para los datos de nivel de registro del sistema Xandr Cloud Export.
Seleccione Datos de nivel de registro en el menú Red (o Informes) en la interfaz de usuario de Xandr.
Haga clic en Administrar en la columna Exportación en la nube de la fuente para la que desea crear una exportación de Google Cloud Storage. Se mostrará la sección Google Cloud Storage .
Haga clic en Nuevo para configurar una nueva exportación o en Configurar para editar una exportación existente. Se mostrará la página Cloud Export to: Google Cloud Storage (Exportación en la nube a: Google Cloud Storage ).
Autorización. Vaya a la consola de Almacenamiento en la nube, seleccione el cubo y haga clic en MOSTRAR PANEL DE INFORMACIÓN. Agregue nuestro miembro
prod-lld-gcs-{XANDR MEMBER ID}@appnexus-cloud-export.iam.gserviceaccount.com
de Google a los permisos del bucket y asígnele el rol IAM de Almacenamiento en la nube (este rol tiene acceso de administrador completo). Un ejemplo de miembro de Google para el identificador de miembro de Xandr 123456 es:prod-lld-gcs-123456@appnexus-cloud-export.iam.gserviceaccount.com
Configuración. Escriba la información de la tabla siguiente y haga clic en Guardar:
Configuración Descripción Cubo Nombre del cubo de almacenamiento de Google creado en el paso 1. Ruta de acceso del manifiesto Raíz de los archivos de manifiesto (por ejemplo, /manifests). Esta ruta de acceso de archivo no admite macros. Ruta de acceso de fuente Ruta de acceso de fuente con macros (por ejemplo, /feeds/%FEED_NAME%/%YEAR%/%MONTH%/%DAY%/%HOUR%/%TIMESTAMP%) Notificación Email Lista de correos electrónicos separados por comas. Si Cloud Export ya no puede acceder al cubo, la exportación se desactivará y se le notificará por correo electrónico. Formato Formato de datos para archivos de datos de nivel de registro (por ejemplo, protobuf) Advertencia
No cree manualmente ninguna ruta de acceso relacionada con manifiestos o fuentes. Si lo hace, la exportación no podrá comprobarse debido a las ACL de nivel de objeto.
Xandr creará automáticamente las rutas de acceso necesarias.
Verificación. Una vez que asigne a nuestro miembro de Google el rol De almacenamiento Administración en el cubo, debe comprobar los permisos antes de que se pueda activar la exportación en la nube de Google Storage. Haga clic en Comprobar (en la página Cloud Export to: Google Cloud Storage ) para ejecutar una serie de pruebas que imitan las acciones que se producen durante una exportación real. Una vez verificada la exportación, está activa. Los datos de la fuente se exportarán automáticamente al cubo de Google Cloud Storage (a partir de la próxima hora).
Errores y desactivación de exportación
Si se produce un error en la exportación, Xandr ejecuta automáticamente las pruebas de comprobación para asegurarse de que el error no se debe a un problema de permisos.
- Si el error se produjo por un problema de permisos, la exportación se desactivará y se le notificará por correo electrónico. A continuación, tendrá que volver a comprobar la exportación. Una comprobación correcta reactivará la exportación.
- Si el error no se produjo por problemas de permisos, la exportación se volverá a intentar automáticamente.
Nota:
Si Xandr ha desactivado la exportación en la nube debido a un problema de permisos, una vez que se haya vuelto a comprobar y volver a habilitar la exportación, solo se rellenará de nuevo hasta un máximo de 3 días de datos de fuente.
Macros de ruta de acceso de fuente
Las macros se pueden usar dentro de las rutas de acceso de fuente para personalizar la ubicación de salida de la fuente por hora de datos, marca de tiempo de fuente y otros metadatos. Las macros admitidas se enumeran a continuación:
Macro | Description |
---|---|
%DAY% | Día de datos (dd) |
%FEED_NAME% | Nombre de la fuente |
%HOUR% | Hora de datos (HH) |
%MONTH% | Mes de datos (MM) |
%TIMESTAMP% | Marca de tiempo de procesamiento de fuentes (aaaaMMddHHmmss) Nota: Dado que los directorios se sobrescriben cuando se copian datos y Xandr a veces puede volver a procesar los datos, la macro %TIMESTAMP% es necesaria para las rutas de acceso de fuente. |
%YEAR% | Año de datos (aaaa) |
Archivos de manifiesto
Los archivos de manifiesto ayudan a realizar un seguimiento de los archivos cargados por el servicio Cloud Export. Dado que los almacenes de objetos en la nube (por ejemplo, Amazon S3, Azure Blob Storage, Google Cloud Storage) son finalmente coherentes, se requiere una fuente de verdad (es decir, qué archivos deben existir) para los consumidores de bajada. El archivo de manifiesto es un objeto JSON escrito en una ubicación preconfigurada en el cubo. Se especifica en el formato JSONSchema . Se recomienda que todo el acceso a las rutas de acceso (por ejemplo, para el procesamiento de datos, la purga, etc.) se realice haciendo referencia primero a los archivos de manifiesto. Los archivos de manifiesto contienen información importante sobre la edad, el estado y el formato de los datos.
Rutas de acceso y nomenclatura de archivos
Los archivos de manifiesto se crean cuando la fuente comienza a procesarse durante una hora determinada. Los archivos se crearán en la ubicación de ruta de acceso especificada. Los nombres de archivo de manifiesto contienen el nombre de la fuente, una marca de tiempo que indica la hora de los datos (el intervalo de tiempo que abarca) y una marca de tiempo de procesamiento. Se crea un archivo de manifiesto para cada fuente, identificador de miembro (asiento), hora de datos y ejecución de fuentes. Xandr vuelve a procesar automáticamente los datos según sea necesario. A los archivos también se les proporcionan sufijos que indican el estado del trabajo de fuente asociado.
- Si un archivo de manifiesto tiene un sufijo "-failed" o "-processing", indica que la fuente no se procesó correctamente.
- Si un archivo de manifiesto no tiene ningún sufijo, indica que los datos de la fuente están listos para la ingesta.
Formato general
{feed_name}-{seat_id}-{YYYYMMddHH}-{yyyyMMddHHmmss}.json[-{suffix}]
Estado: "Procesamiento"
Posnombre | -Tratamiento |
Ejemplo | standard_feed-998-2017013109-20170131132522.json-processing |
Estado: "Error"
Nota:
Dado que los errores pueden producirse en situaciones irrecuperables que hacen imposible cambiar el sufijo del archivo de manifiesto, es posible que un sufijo de archivo de manifiesto cambie de "procesamiento" a "erróneo" algún tiempo más tarde (por ejemplo, durante la siguiente ejecución correcta). Por ejemplo, si se produce un error en un proceso de exportación en la nube debido a un cambio en la directiva de acceso del cubo, ya no podrá escribir en ese bucket (y la exportación se desactivará). El sufijo de archivo del manifiesto seguirá siendo "-processing" hasta que la exportación se reactive y se ejecute correctamente.
Posnombre | -Fallado |
Ejemplo | standard_feed-998-2017013109-20170131132522.json-failed |
Estado: "Correcto"
Posnombre | Ninguno |
Ejemplo | standard_feed-998-2017013109-20170131132522.json |
Flujo de trabajo de procesamiento de fuentes
Resulta útil comprender cómo interpretan los trabajos de fuente los archivos de manifiesto para crear la lógica de bajada. El proceso es el siguiente:
- La ruta de acceso del manifiesto se examina en busca de entradas con el sufijo "-processing". Las entradas con este sufijo indican una ejecución anterior que experimentó un error irrecuperable. Se cambia el nombre de estas entradas con un sufijo "-failed" (por ejemplo, json-processing>.json-failed).
- Se genera un archivo de manifiesto y se escribe en el cubo con un sufijo "-processing".
- Los datos de la fuente se escriben en el cubo.
- Si se produce un error en el proceso de escritura, se cambiará el nombre del archivo de manifiesto para incluir un sufijo "-failed" (por ejemplo, error de .json). Si el proceso de escritura se completa correctamente, el sufijo "-processing" simplemente se quita (por ejemplo, .json-procesamiento>.json), lo que indica una ejecución completada.
Esquema de archivo de manifiesto
El esquema del archivo de manifiesto se describe en el conocido formato JSONSchema . Xandr recomienda clases de generación de código a partir de JSONSchema que proporcionamos. Un proyecto que lo logra para Java es 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"
]
}
}
}
}
}
Ejemplo de archivo de manifiesto
{
"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
}
Errores o cargas parciales
Los errores del trabajo de fuente pueden provocar la carga parcial de datos. Para evitar consumir datos cargados parcialmente, use los nombres de archivo de manifiesto para determinar qué consumir.
- No consuma archivos que tengan el sufijo "-processing" o "-failed". Se trata de conjuntos de datos incompletos.
- Use solo datos de rutas de acceso correspondientes a cargas completadas (es decir, archivos de manifiesto con una extensión .json pero sin sufijo adicional).
Purga
Al purgar datos antiguos del cubo, los archivos de manifiesto se deben usar para determinar cuándo los datos son aptos para purgar. Purgue solo los archivos que ya no sean pertinentes (por ejemplo, más de una semana).
Nota:
Para mejorar el rendimiento del directorio, los archivos de manifiesto anteriores a 30 días se moverán a una carpeta /archive ubicada dentro de la ruta de acceso del archivo de manifiesto. Por precaución, si tiene procedimientos o scripts que hacen referencia directamente a la ruta de acceso del archivo de manifiesto, debe modificarlos para que también busquen en la carpeta /archive los archivos de manifiesto anteriores a 30 días.
Reprocesamiento
Las fuentes que se vuelven a procesar durante una hora determinada nunca sobrescribirán los datos antiguos. Xandr volverá a procesar los datos cuando se detecten incoherencias. Cuando se vuelve a procesar un trabajo de fuente, habrá dos (o más) archivos de manifiesto correspondientes a la misma hora de datos. Sin embargo, las marcas de tiempo y las rutas de acceso de procesamiento variarán entre las ejecuciones. El archivo con la marca de tiempo más reciente será el corregido.
Pérdida de datos de cliente
Xandr no vuelve a exportar los datos que ya se han exportado correctamente. Para mitigar las situaciones en las que es posible que haya eliminado accidentalmente los datos exportados correctamente, se recomienda aprovechar las características de copia de seguridad o control de versiones del proveedor en la nube.
Solución de problemas
Criterios de unicidad para las configuraciones
La configuración de Cloud Export debe ser única, lo que significa:
- Para rutas de acceso de manifiesto:
- Para Microsoft Azure, si el destino (cuenta de almacenamiento y contenedor) combinado y la ruta de acceso son iguales, el identificador de miembro y la fuentedeben ser diferentes.
- Para todas las demás configuraciones, si el bucket y la ruta de acceso son iguales, el id. de miembro y la fuentedeben ser diferentes.
- En el caso de las rutas de acceso de fuente, si la ruta de acceso destino y fuente resuelta es la misma, el identificador de miembro debe ser diferente y la fuente y el formatodeben ser iguales.
Problemas de comprobación
En la sección siguiente se describen algunos problemas comunes que puede encontrar al configurar la comprobación.
Posibles acciones de comprobación erróneas:
- Comprobación de archivos de manifiesto en GLACIER
- Comprobación del acceso a metainformación en los archivos de manifiesto
- Creación de prefijo en
<path>
Comprobación de archivos de manifiesto en GLACIER
Causa potencial: el archivado de archivos de manifiesto no está configurado correctamente
Se aplica a: Amazon S3
Solución:
Asegúrese de que todas las reglas de ciclo de vida están configuradas para mover objetos de manifiesto a Glacier solo si no están en la ruta de acceso de manifiestos (los manifiestos o el archivo están bien).
Comprobación del acceso a metainformación en los archivos de manifiesto
Causa potencial: está revocando el acceso a nivel de objeto para manifiestos no archivados
Se aplica a:
- Amazon S3
Solución: para cada objeto, aws s3api get-object-acl --bucket <bucket> --key <object>
debe producir lo siguiente como una de las concesiones para cada objeto de manifiesto no archivado:
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "aws-slld",
"ID": "669331f902bdea32b620b6e6c85123d153b5b30c8318b101d2fd202bc3906fe1"
},
"Permission": "FULL_CONTROL"
},
- Google Cloud Storage
Solución: para cada objeto, gsutil acl get <object>
debe producir lo siguiente como una de las concesiones para cada objeto de manifiesto no archivado:
{
"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"
}
Creación de prefijo en <path>
Causa potencial: ya ha aplicado la autorización al cubo o contenedor, pero ha creado manualmente cualquier manifiesto o fuente de "carpetas".
Se aplica a: Todas las configuraciones de exportación en la nube
Solución:
Los objetos creados manualmente tienen distintas ACL que pueden denegar el acceso al sistema de exportación en la nube. Elimine los objetos de fuente o manifiesto creados manualmente. El sistema De exportación en la nube creará los objetos necesarios por sí solo.