Conozca los factores que afectan el rendimiento de la transformación de datos y cómo optimizar el throughput mediante el ajuste de shards y la lógica de transformación.
Según how it works, la velocidad general de un trabajo de transformación de datos depende del número de shards en el logstore de origen y de la complejidad de la lógica de transformación. Como referencia, planifique un throughput de procesamiento de 1 MB/s de datos sin comprimir por shard, equivalente a aproximadamente 85 GB diarios por shard. Por ejemplo, si la tasa de escritura de datos del logstore de origen es de 1 TB al día, divídalo en como mínimo 12 shards (1,024 GB / 85 GB por shard ≈ 12). Para obtener más información sobre la división de shards, consulte Split a shard.
Rendimiento de la transformación de datos
La velocidad de la transformación de datos depende de la lógica de transformación. Los factores clave son a continuación:
-
Datos de salida
El rendimiento disminuye a medida que aumenta el volumen de datos de salida. Generar más entradas de registro (por ejemplo, al dividir una entrada en varias), agregar más campos o aumentar el tamaño de su contenido consume más recursos de CPU y de red, lo que reduce el throughput.
Escribir en varios destinos, agregar numerosas etiquetas a cada entrada de registro o crear más grupos de registros ralentiza el rendimiento. Cada acción incrementa las interacciones de red y la sobrecarga.
-
Lógica de transformación
Una lógica de transformación compleja requiere más búsquedas, cálculos y sincronizaciones con recursos externos. Todo esto consume recursos adicionales de cómputo y de red, y reduce el throughput.
-
Fuentes de datos externas
Si utiliza una fuente de terceros para enriquecer sus datos, los volúmenes mayores de datos extraídos ralentizan la transformación. La extracción de datos entre regiones, como objetos de OSS en otra región, reduce aún más el rendimiento.
Escalado de la transformación del logstore de origen
-
Escalado de la transformación de datos en tiempo real.
Aumente el número de shards para mejorar el rendimiento de la transformación de datos en tiempo real. Para obtener más información sobre los métodos de facturación de los shards, consulte Pay-by-feature billing.
-
Escalado de la transformación de datos históricos.
La división de shards solo afecta a los datos recién escritos. Para procesar un gran volumen de datos históricos en un logstore con pocos shards, cree varios trabajos de transformación de datos. Configure cada trabajo para que procese un rango de tiempo separado y sin superposiciones. Por ejemplo, para procesar registros históricos del 1 al 10 de septiembre, cree diez trabajos que procesen los datos en incrementos diarios, como
[9/1, 9/2), [9/2, 9/3), ..., [9/10, 9/11).NotaEl tiempo de transformación corresponde al momento de recepción del registro. Para obtener más información, consulte Create a data transformation job.
Escalado de la transformación del logstore de destino
La cantidad de shards necesaria para un logstore de destino depende de dos factores:
-
Throughput de escritura. Un solo shard de logstore admite un throughput máximo de escritura de 5 MB/s. Calcule la cantidad de shards de destino necesarios según el número de shards de origen y la concurrencia de procesamiento.
Por ejemplo, si el logstore de origen tiene 20 shards, el logstore de destino necesita como mínimo 4 shards.
-
Requisitos de consulta y análisis. Si crea un índice y ejecuta consultas sobre los datos del logstore de destino, planifique la cantidad de shards según el alcance de sus consultas. Como regla general, aprovisione un shard por cada 50 millones de entradas de registro consultadas simultáneamente.
Por ejemplo, suponga que escribe 10 GB de registros al día, donde cada entrada tiene un promedio de 1 KB. Esto equivale a 10 millones de entradas de registro diarias. Si sus consultas deben abarcar un período de 30 días, consultará aproximadamente 300 millones de entradas de registro. En este escenario, configure el logstore de destino con 6 shards (300 millones de entradas / 50 millones de entradas por shard).