Compartir vía


Control de datos duplicados en Azure Data Explorer

Los dispositivos que envían datos a la nube mantienen una caché local de los datos. Según el tamaño de los datos, la memoria caché local puede almacenar datos de varios días o incluso meses. Es conveniente proteger las bases de datos analíticos de aquellos dispositivos que por error vuelven a enviar los datos almacenados en caché y provocan la duplicación de datos en la base de datos analíticos. Los duplicados pueden afectar al número de registros devueltos por una consulta. Esto es relevante cuando se necesita un recuento preciso de registros, como en el recuento de eventos. En este tema se describen los procedimientos recomendados para controlar los datos duplicados para estos tipos de escenarios.

La mejor solución para la duplicación de datos es evitar dicha duplicación. Si es posible, corrija el problema con antelación en la canalización de datos, lo que ahorrará costos asociados con el movimiento de datos a lo largo de la canalización de datos y evitará que se empleen recursos en tratar con los datos duplicados introducidos en el sistema. Sin embargo, en situaciones en las que no es posible modificar el sistema de origen, hay varias maneras de gestionar este escenario.

Conocimiento del impacto de los datos duplicados

Supervise el porcentaje de datos duplicados. Una vez detectado el porcentaje de datos duplicados, puede analizar el ámbito del problema y el impacto sobre el negocio para elegir la solución adecuada.

Ejemplo de consulta para identificar el porcentaje de registros duplicados:

let _sample = 0.01; // 1% sampling
let _data =
DeviceEventsAll
| where EventDateTime between (datetime('10-01-2018 10:00') .. datetime('10-10-2018 10:00'));
let _totalRecords = toscalar(_data | count);
_data
| where rand()<= _sample
| summarize recordsCount=count() by hash(DeviceId) + hash(EventId) + hash(StationId)  // Use all dimensions that make row unique. Combining hashes can be improved
| summarize duplicateRecords=countif(recordsCount  > 1)
| extend duplicate_percentage = (duplicateRecords / _sample) / _totalRecords  

Soluciones para tratar datos duplicados

Solución 1: no eliminar los datos duplicados

Determine los requisitos de su negocio y su nivel de tolerancia a los datos duplicados. Algunos conjuntos de datos pueden aceptar un determinado porcentaje de datos duplicados. Si los datos duplicados no tienen una repercusión importante, puede ignorar su presencia. La ventaja de no eliminar los datos duplicados es que no se sobrecargará adicionalmente el proceso de ingesta o el rendimiento de consultas.

Solución 2: administrar las filas duplicadas durante la consulta

Otra opción es filtrar las filas duplicadas en los datos durante la consulta. La función de agregado arg_max() se puede usar para filtrar los registros duplicados y devolver el último registro en función de la marca de tiempo (u otra columna). La ventaja de este método es una ingesta más rápida, ya que la desduplicación se produce durante el tiempo de consulta. Además, todos los registros (incluidos los duplicados) están disponibles para auditoría y solución de problemas. La desventaja de utilizar la función arg_max es el tiempo de consulta adicional y la carga en la CPU cada vez que se consultan los datos. Según la cantidad de datos consultados, esta solución podría no ser funcional o consumir demasiada memoria, por lo que sería necesario recurrir a otras opciones.

En el ejemplo siguiente, se consulta el último registro ingerido para un conjunto de columnas que determinan los registros únicos:

DeviceEventsAll
| where EventDateTime > ago(90d)
| summarize hint.strategy=shuffle arg_max(EventDateTime, *) by DeviceId, EventId, StationId

Esta consulta también se puede colocar dentro de una función en lugar de consultar directamente la tabla:

.create function DeviceEventsView
{
    DeviceEventsAll
    | where EventDateTime > ago(90d)
    | summarize arg_max(EventDateTime, *) by DeviceId, EventId, StationId
}

Solución 3: usar vistas materializadas para desduplicar

Las vistas materializadas se pueden utilizar para realizar la desduplicación mediante las funciones de agregación take_any()/arg_min()/arg_max() (consulte el ejemplo 4 de Comando .create materialized-view).

Nota:

Las vistas materializadas tienen un costo de consumo de recursos del clúster, lo que puede no ser insignificante. Para más información, consulte las consideraciones de rendimiento de las vistas materializadas.

Solución 4: Uso de la eliminación temporal para eliminar duplicados

La eliminación temporal admite la posibilidad de eliminar registros individuales y, por tanto, se puede usar para eliminar duplicados. Esta opción solo se recomienda para eliminaciones poco frecuentes y no si necesita desduplicar constantemente todos los registros entrantes.

Elección entre vistas materializadas y eliminación temporal para la desduplicación de datos

Hay varias consideraciones que pueden ayudarle a elegir entre el uso de vistas materializadas o la eliminación temporal para la desduplicación:

  • Administración y orquestación: las vistas materializadas son una solución totalmente administrada. Una vista se define una vez y el sistema controla la desduplicación de todos los registros entrantes. La eliminación temporal requiere orquestación y administración. Por lo tanto, si las vistas materializadas funcionan para su caso de uso, siempre debe elegir esta opción.
  • Cuándo se desduplican los registros: con la eliminación temporal, los registros duplicados se agregan primero a una tabla y, a continuación, se eliminan; por lo tanto, entre los procesos de ingesta y de eliminación temporal, la tabla contiene duplicados. Con las vistas materializadas, los registros de la vista siempre estarán desduplicados, ya que se desduplican antes de entrar en la vista.
  • Frecuencia: si una tabla debe desduplicarse constantemente, use vistas materializadas. Si prevé que los duplicados serán poco frecuentes y que podrá identificarlos durante la ingesta, el proceso de eliminación temporal normalmente funciona mejor que las vistas materializadas. Por ejemplo, si está en una situación en la que las ingestas no suelen tener duplicados, pero en ocasiones ingiere una secuencia que sabe que sí los contiene. En este escenario, es mejor controlar estos duplicados mediante la eliminación temporal que definir una vista materializada que intentará desduplicar constantemente todos los registros.

Solución 5: etiquetas de extensión ingest-by

Las etiquetas de extensión "ingest-by": se pueden usar para evitar duplicados durante la ingesta. Esto solo es pertinente en los casos de uso en los que se garantiza que cada lote de ingesta no tiene duplicados y solo se esperan estos si el mismo lote de ingesta se ingiere más de una vez.

Resumen

La duplicación de datos se puede tratar de varias maneras. Evalúe las opciones detenidamente, teniendo en cuenta el precio y el rendimiento, para determinar el método correcto para su negocio.