Más información sobre la Data Workbench Anuncio de fin de vida útil.
Enlaces a información adicional sobre parámetros específicos en el archivo Log Processing.cfg.
Los filtros definidos en la variable Log Processing.cfg incluye lo siguiente:
El filtrado definido por estos parámetros se produce después de que las entradas de registro abandonen los descodificadores y después de las transformaciones, pero antes de su evaluación por la variable Log Entry Condition. En general, al cambiar cualquiera de estos parámetros se producen cambios en la composición del conjunto de datos.
La técnica recomendada para usar Sensor las fuentes de datos para construir un conjunto de datos que cubra un período de tiempo específico es usar los parámetros Hora de inicio y Hora de finalización para el conjunto de datos.
Se prefiere utilizar los parámetros Hora de inicio y Hora de finalización en lugar de otras técnicas, como mover archivos de registro para separarlos por directorio. Al establecer las horas de inicio y finalización del conjunto de datos, el servidor de Data Workbench utiliza automáticamente solo las entradas de registro que se produjeron dentro del intervalo determinado. Suponiendo que la hora de finalización esté en el pasado, el servidor de Data Workbench suele actualizar el conjunto de datos utilizando el mismo conjunto de entradas de registro, incluso si el conjunto de datos se actualiza, por ejemplo, añadiendo una nueva transformación.
En esencia, es un proceso de filtrado en las entradas de registro disponibles. Si la variable Log Entry Condition devuelve el valor false, la entrada de registro se filtra fuera del conjunto disponible de entradas de registro.
La variable Log Entry Condition se describe mediante el uso de operaciones de condición (consulte Condiciones) y puede utilizar cualquiera de los campos de entrada recopilados por Sensor (consulte la Data Workbench Sensor Guía ) o cualquier campo extendido producido por transformaciones contenidas en el Log Processing.cfg para definir las condiciones de prueba. Log Entry se aplican durante el procesamiento del registro y, opcionalmente, se pueden aplicar durante la transformación.
Este ejemplo muestra el uso de la variable log entry condition para datos de sitios web. Puede usar la variable Log Entry Condition para crear conjuntos de datos que se centren en una parte específica del sitio web o en visitantes que realicen alguna acción específica en el sitio.
La variable Log Entry Condition en este ejemplo crea un conjunto de datos que incluye solo las entradas de registro que forman parte del almacén del sitio. Usando la variable RECondition test con el patrón coincidente “/store/.*” y cs-uri-stem como entrada para la expresión regular, solo páginas web que comiencen con la cadena “/store/” se incluyen en el conjunto de datos.
El número de ID de seguimiento en el conjunto de datos aumenta artificialmente, pero el número total de entradas de registro procesadas por el servidor de Data Workbench no aumenta artificialmente, por lo que se preserva el número total de eventos contables en el conjunto de datos. Una vez divididos los datos de un solo elemento, los datos se asocian para siempre con dos ID de seguimiento diferentes y no se pueden relacionar.
Por ejemplo, si trabaja con datos web, cada ID de seguimiento representa un visitante único. Si habilita la división de claves, los visitantes del conjunto de datos con grandes cantidades de datos de evento se dividen en varios visitantes. Aunque el número de visitantes en el conjunto de datos aumenta artificialmente, el número total de eventos contables, como vistas de página o reservas, no aumenta artificialmente. Una vez divididos, los datos de los subvisitantes no pueden relacionarse.
La división de claves utiliza un algoritmo probabilístico. Como resultado, existe un equilibrio entre el uso de la memoria, la probabilidad de fallo y el umbral de división de claves ( Split Key Bytes) y el tamaño del conjunto de datos. Con la configuración recomendada (como se indica a continuación), la tasa de errores es baja. De los elementos cuyos datos de evento superen el umbral de división de claves, aproximadamente 1 de cada 22.000 (normalmente menos de 1 por conjunto de datos) tendrán algunos de sus datos truncados en lugar de divididos.
Los valores recomendados para cada parámetro (sin y con división de claves) se muestran en la siguiente tabla.
Parámetro | Sin división de claves | División clave |
---|---|---|
Bytes de clave máxima del grupo | 1e6 | 2e6 |
Dividir espacio del bloque de claves | 6e6 | 6e6 |
Bytes de clave divididos | 0 | 1e6 |
Proporción de espacio de clave dividida | 10 | 10 |
Group Maximum Key Bytes especifica la cantidad máxima de datos de evento que se pueden procesar para un único ID de seguimiento. Los datos que exceden este límite se filtran del proceso de construcción del conjunto de datos. Split Key Bytes representa el número de bytes en los que se divide un único ID de seguimiento en varios elementos. Los elementos se dividen en aproximadamente este número de bytes según una distribución de probabilidad. Split Key Space Ratio y Split Key Bucket Space controle la utilización de la memoria y la velocidad de fallo de la división de claves.
Group Maximum Key Bytes, Split Key Bytes, Split Key Space Ratioy Split Key Bucket Space todo debe declararse para que la división de claves funcione correctamente. No cambie los valores de estos parámetros sin consultar el Adobe.