Límites de la transformación de datos - Simple Log Service - Centro de documentación de Alibaba Cloud

Límites y cuotas para la transformación de datos en Simple Log Service.

Configuración de tareas

Límite	Descripción
Número de tareas	Puede crear hasta 100 trabajos de transformación de datos en un proyecto. Importante Un trabajo consume cuota incluso cuando está detenido o finalizado. Para reducir el uso de la cuota, elimine los trabajos detenidos, finalizados o que no utilice. Para más información, consulte Manage data transformation jobs. Si necesita una cuota mayor, envíe un ticket.
Dependencias del grupo de consumidores del logstore de datos de origen	Cada trabajo de transformación de datos utiliza un grupo de consumidores de su logstore de origen. Mientras un trabajo se ejecute, no delete ni reset the checkpoint de su grupo de consumidores dependiente. De lo contrario, el trabajo reinicia el consumo de datos desde la hora de inicio configurada y podría generar resultados duplicados. Importante El trabajo actualiza periódicamente su progreso de consumo de shards en el grupo de consumidores dependiente. Por ello, la API GetCheckPoint de este grupo no refleja el progreso de procesamiento más reciente. Para consultar el progreso exacto, revise el módulo Shard consumption latency en Data Transformation Dashboard. Para más información, consulte How data transformation works, Glossary y Consumer group APIs.
Número de grupos de consumidores del logstore de origen	Puede crear hasta 30 grupos de consumidores en un logstore. Por lo tanto, un logstore de origen admite un máximo de 30 trabajos de transformación de datos. Para más información, consulte Basic resource limits. Si se supera este límite, los trabajos no se ejecutan después de iniciarlos. Para conocer los detalles de los mensajes de error, consulte How to view error logs. Importante Simple Log Service no elimina automáticamente los grupos de consumidores de los trabajos detenidos o finalizados. Para liberar grupos de consumidores, elimine los trabajos detenidos, finalizados o que no utilice. Para más información, consulte Manage data transformation jobs.
Modificación del intervalo de tiempo de un trabajo en ejecución	Después de modificar el intervalo de tiempo de un trabajo en ejecución, este comienza a procesar desde la nueva hora de inicio y gestiona todos los datos dentro del nuevo intervalo. Para ampliar el intervalo de tiempo: conserve el trabajo existente y cree uno nuevo que cubra el periodo adicional. Para reducir el intervalo de tiempo: los datos ya escritos en el destino no se eliminan. Si es necesario, limpie los datos de destino existentes antes de modificar el trabajo para evitar datos duplicados.
Número de destinos de salida	Puede configurar hasta 20 destinos de salida estáticos en un trabajo de transformación de datos. Si utiliza un único destino de salida estático y especifica dinámicamente el proyecto y el logstore en su código de transformación, puede escribir en hasta 200 destinos. Los datos escritos en destinos adicionales que superen este límite se descartan.

Transformación de datos

Límites	Descripción
Vista previa rápida	La vista previa rápida ayuda a depurar el código de transformación, con a continuación límites: No admite conexiones a recursos externos como RDS, OSS o SLS. Utilice entradas personalizadas para probar los datos de las tablas de dimensiones. Cada solicitud procesa un máximo de 1 MB de datos sin procesar y 1 MB de datos de tabla de dimensiones. Las solicitudes que superen estos límites devuelven un error. Cada solicitud devuelve como máximo los primeros 100 resultados procesados. La función Advanced preview no tiene estas restricciones.
Concurrencia en tiempo de ejecución	La concurrencia máxima en tiempo de ejecución de un trabajo de transformación de datos equivale al número de shards de lectura y escritura de su logstore de origen. Para más información, consulte How data transformation works. Para conocer los límites de shards de un logstore, consulte Basic resource limits. Para saber cómo split shards, consulte Manage shards. Importante Una concurrencia insuficiente en tiempo de ejecución no activa la función automatic sharding del logstore de origen. Divida manualmente los shards del logstore de origen para aumentar la concurrencia del trabajo. Para saber cómo configurar automatic sharding, consulte Manage shards. Dividir los shards del logstore de origen aumenta la concurrencia máxima en tiempo de ejecución únicamente para los datos escritos después de la división. Para los datos escritos antes, la concurrencia máxima depende del número de shards de lectura y escritura que tenía el logstore de origen en ese momento.
Carga de datos por unidad concurrente	La carga de datos por unidad concurrente depende del tamaño de los datos en el shard del logstore de origen. Una distribución desigual de los datos entre los shards genera puntos críticos que provocan retrasos en el procesamiento. Si los datos de origen utilizan KeyHash routing, distribuya las claves uniformemente entre los shards para reducir el desequilibrio.
Uso de memoria	Cada unidad concurrente tiene un límite de memoria de 6 GB. Superarlo degrada el rendimiento del trabajo y provoca retrasos en el procesamiento. Este límite suele superarse cuando se extraen demasiados LogGroups en un solo lote. Ajuste el parámetro avanzado `system.process.batch_size` para controlar el uso de memoria. Importante El valor predeterminado (y máximo) del parámetro avanzado `system.process.batch_size` es 1000. Establezca cualquier número entero positivo hasta 1000.
Uso de CPU	Cada unidad concurrente tiene un límite de CPU del 100%. Para cubrir requisitos mayores de CPU, aumente el límite de concurrencia.
Volumen de datos de la tabla de dimensiones	Las tablas de dimensiones admiten hasta dos millones de entradas y 2 GB de memoria. Los datos que superen estos límites se truncan. Las funciones afectadas incluyen res_rds_mysql, res_log_LogStore_pull y res_oss_file. Importante Si un trabajo utiliza varias tablas de dimensiones, todas comparten este límite. Mantenga los datos de las tablas de dimensiones lo más pequeños posible.

Escritura de datos de resultado

Límite

Descripción

Escritura en el logstore de destino

Aviso

No configure el almacén de destino como el almacén de origen actual (configuración de mismo origen). De lo contrario, los registros podrían escribirse en bucle, lo que genera costos adicionales de almacenamiento y tráfico. Usted es responsable del consumo de recursos y de los costos derivados.

Al escribir los resultados procesados en un logstore de destino, respete los límites de escritura del logstore. Para más detalles, consulte Basic resource limits y Data read and write.

Si utiliza la función e_outputLogStoreut y especifica el parámetro hash_key_field o hash_key con KeyHash routing, distribuya las claves uniformemente entre los shards para reducir el desequilibrio.

Identifique este límite mediante los registros de tareas. Consulte How to view error logs.

Importante

Cuando un trabajo de transformación de datos alcanza un límite de escritura del logstore de destino, reintenta indefinidamente para garantizar la integridad de los datos. Sin embargo, esto afecta el progreso del trabajo y provoca retrasos en el procesamiento del shard de origen actual.

Transmisión entre regiones

La transmisión de datos entre regiones a través de un endpoint de red pública puede presentar errores de red que retrasen los trabajos de transformación de datos. Para consultar los endpoints de Simple Log Service, consulte Service endpoints.

Habilite transfer acceleration para el proyecto de destino y configure su endpoint de transfer acceleration en el trabajo de transformación de datos para mejorar la estabilidad de la red. Para más información, consulte Manage transfer acceleration.