Este tema explica cómo mejorar el rendimiento de lectura y escritura en las tablas con clave primaria y las tablas escalables de anexión de Apache Paimon (Paimon) dentro de Realtime Compute for Apache Flink.
Límites
Las tablas Paimon solo son compatibles con Realtime Compute for Apache Flink cuando se utiliza Ververica Runtime (VVR) 8.0.5 o versiones posteriores.
Tablas con clave primaria
Optimizar el rendimiento de escritura
Las operaciones de escritura en tablas con clave primaria de Paimon se bloquean durante la compactación de archivos pequeños. Cuando un bucket contiene muchos archivos pequeños, o cuando el parámetro changelog-producer se establece en lookup, la compactación debe finalizar antes de que se complete cada checkpoint. Si la compactación tarda demasiado, los checkpoints exceden su tiempo de espera, lo que provoca contrapresión y reduce el throughput.
Para resolver problemas de rendimiento de escritura, elija uno o más de los siguientes métodos según su carga de trabajo:
Ajustar el paralelismo del sink: escale la cantidad de workers del sink para que coincida con su volumen de escritura.
Ajustar la configuración de checkpoints: aumente el intervalo entre checkpoints o permita la ejecución simultánea de varios checkpoints.
Habilitar la compactación completamente asíncrona: desvincule la compactación del ciclo de checkpoints para que las escrituras nunca se bloqueen.
Cambiar el formato de archivo a Avro: reduzca la sobrecarga de escritura cuando no se requieren consultas ad hoc de procesamiento analítico en línea (OLAP).
Limitar el tamaño de archivos temporales locales: restrinja el uso de disco provocado por los búferes de escritura desbordados.
Ajustar el paralelismo del sink
Utilice SQL Hints para establecer el parámetro sink.parallelism. Un mayor paralelismo distribuye la carga de escritura y compactación entre más workers, lo que reduce la probabilidad de que un solo bucket se convierta en un cuello de botella. Tenga en cuenta que un paralelismo más alto también incrementa el consumo de recursos.
Ajustar la configuración de checkpoints
Dado que el rendimiento de escritura en Paimon está estrechamente ligado a la frecuencia de los checkpoints, ajustar su comportamiento suele ser la forma más rápida de reducir la contrapresión.
Utilice cualquier combinación de los siguientes ajustes:
-
Aumente el intervalo de checkpoints mediante la configuración de
execution.checkpointing.interval. Para conocer los pasos de configuración, consulte How do I configure parameters for deployment running?.ImportanteEl intervalo de checkpoints afecta directamente a data latency, es decir, al tiempo transcurrido entre la escritura de los datos y su disponibilidad para consumo. Aumente este intervalo únicamente si su carga de trabajo admite una latencia mayor.
Agregue
execution.checkpointing.max-concurrent-checkpoints: 3para permitir que se ejecuten hasta tres checkpoints de forma simultánea. Esto reduce el impacto de los checkpoints lentos sobre el throughput general.Cambie a un despliegue por lotes para eliminar por completo la sobrecarga de los checkpoints.
Habilitar la compactación completamente asíncrona
De forma predeterminada, la compactación es síncrona con el ciclo de checkpoints. La compactación completamente asíncrona elimina esta dependencia: la compactación se ejecuta en segundo plano siempre que hay recursos disponibles, y los checkpoints continúan sin esperar a que termine la compactación.
La contrapartida es que los archivos pequeños pueden acumularse durante periodos de alta escritura. Esto no afecta el consumo de flujos, pero degrada el consumo por lotes y el rendimiento de consultas OLAP hasta que la compactación en segundo plano se pone al día. Supervise la cantidad de archivos pequeños en cada bucket mediante files table proporcionado por Paimon.
Configure los siguientes parámetros mediante ALTER TABLE statement o SQL Hints:
'num-sorted-run.stop-trigger' = '2147483647',
'sort-spill-threshold' = '10',
'changelog-producer.lookup-wait' = 'false'|
Parámetro |
Tipo |
Valor predeterminado |
Descripción |
|
|
Integer |
5 |
Número máximo de archivos pequeños permitidos en un bucket antes de pausar las escrituras hasta que la compactación se ponga al día. Establecer este valor en |
|
|
Integer |
N/A |
Cantidad de archivos pequeños a partir de la cual la ordenación por mezcla en memoria cambia a ordenación externa. Configure este parámetro para evitar el agotamiento de la memoria heap cuando se acumulan archivos pequeños. Si no sabe qué valor utilizar, establézcalo en |
|
|
Boolean |
true |
Controla si el sink espera a que finalice la generación del registro de cambios (que implica compactación) antes de completar un checkpoint. Establézcalo en |
Cambiar el formato de archivo a Avro
Si su caso de uso se centra en el consumo por lotes o de flujos y no requiere consultas ad hoc OLAP, configure los siguientes parámetros para cambiar el formato de archivo de datos y deshabilitar la recopilación de estadísticas. Esto mejora la eficiencia de las operaciones de escritura.
Configure los siguientes parámetros al crear la tabla:
'file.format' = 'avro',
'metadata.stats-mode' = 'none'Estos parámetros deben establecerse durante la creación de la tabla. No es posible cambiar el formato de archivo de una tabla existente.
Limitar el tamaño de archivos temporales locales
Establezca write-buffer-spill.max-disk-size en SQL Hints para limitar el espacio máximo de disco utilizado por los búferes de escritura desbordados. Esto evita que los workers de escritura consuman una cantidad excesiva de disco local.
Optimizar el rendimiento de lectura
Ajustar el paralelismo del source
Utilice SQL Hints para establecer el parámetro scan.parallelism del source de Paimon. Aumentar este valor permite que más lectores paralelos procesen datos simultáneamente.
Utilizar la tabla optimizada para lectura
Durante el consumo por lotes, la fase de escaneo completo del consumo de flujos y las consultas ad hoc OLAP, Paimon debe combinar datos de archivos pequeños en memoria mediante ordenación por mezcla. Una gran cantidad de archivos pequeños ralentiza significativamente este proceso.
Si no necesita consumir los datos más recientes, puede utilizar read-optimized table para mejorar la eficiencia del consumo. Cuando ha habilitado la compactación completamente asíncrona para maximizar el throughput de escritura, los archivos pequeños se acumulan más rápido de lo que se combinan; en este caso, usar la tabla optimizada para lectura permite leer solo los datos ya compactados, lo que mejora el rendimiento de lectura a cambio de no ver los registros escritos más recientemente.
Limitar el tamaño de la caché de lookup join
Al realizar operaciones de lookup join contra una tabla Paimon, los archivos en caché pueden crecer sin límite. Configure los siguientes parámetros en SQL Hints para controlar el crecimiento de la caché:
lookup.cache-max-disk-size: espacio máximo de disco utilizado por la caché de lookup.lookup.cache-file-retention: tiempo durante el cual se conservan los archivos en caché antes de su expiración.
Tablas escalables de anexión
Optimizar el rendimiento de escritura
El throughput de escritura de las tablas escalables de anexión depende del paralelismo del sink y del ancho de banda del sistema de archivos subyacente o de Object Storage Service (OSS). Antes de ajustar parámetros, compruebe que su sistema de almacenamiento cuenta con suficiente ancho de banda para admitir la tasa de escritura deseada. Luego aplique las siguientes optimizaciones:
Ajustar el paralelismo del sink: escale la cantidad de workers del sink para que coincida con su volumen de escritura.
Resolver la dispersión de datos: fuerce una redistribución (shuffle) entre el operador ascendente y el sink cuando los datos de entrada estén distribuidos de manera desigual.
Limitar el tamaño de archivos temporales locales: restrinja el uso de disco provocado por los búferes de escritura desbordados.
Ajustar el paralelismo del sink
Utilice SQL Hints para establecer el parámetro sink.parallelism. Tenga en cuenta que un paralelismo más alto incrementa el consumo de recursos.
Resolver la dispersión de datos
Los datos ascendentes no se redistribuyen antes de escribirse en una tabla escalable de anexión. Si la distribución de los datos de entrada es desigual, algunos workers del sink reciben mucha más información que otros, lo que deja recursos subutilizados y crea un cuello de botella en la escritura.
Establezca sink.parallelism en un valor diferente al paralelismo del nodo ascendente. Esto fuerza una redistribución entre el operador ascendente y el sink. Para confirmar que la redistribución está activa, revise la consola de desarrollo de Realtime Compute for Apache Flink: si el operador sink y su nodo ascendente aparecen en subtareas diferentes, significa que los datos se están redistribuyendo.
Limitar el tamaño de archivos temporales locales
Establezca write-buffer-spill.max-disk-size en SQL Hints para limitar el espacio de disco utilizado por los búferes de escritura desbordados.
Optimizar el rendimiento de lectura
Ajustar el paralelismo del source
Utilice SQL Hints para establecer el parámetro scan.parallelism del source de Paimon.
Ordenar datos para mejorar la eficiencia de las consultas
El orden de los datos afecta significativamente el procesamiento por lotes y el rendimiento de consultas ad hoc OLAP. Ordenar los datos según las columnas más utilizadas en las condiciones de filtro reduce la cantidad de información que cada consulta debe escanear.
La ordenación requiere ejecutar un job de Flink en modo por lotes. Antes de empezar, complete la configuración obligatoria descrita en Data management configuration. Después, configure los parámetros del job en el campo Entry Point Main Arguments.
Cuándo utilizar cada estrategia de ordenación:
|
Estrategia |
Recomendada cuando |
|
|
Consultas de rango con menos de cinco columnas de filtro |
|
|
Consultas de rango con cinco o más columnas de filtro |
|
|
Consultas que utilizan únicamente condiciones de igualdad |
El siguiente ejemplo ordena los datos de particiones específicas por las columnas date y type mediante Z-order:
compact
--warehouse 'oss://your-bucket/data-warehouse'
--database 'your_database'
--table 'your_table'
--order_strategy 'zorder'
--order_by 'date,type'
--partition 'dt=20240311,hh=08;dt=20240312,hh=09'
--catalog_conf 'fs.oss.endpoint=oss-cn-hangzhou-internal.aliyuncs.com'
--catalog_conf 'fs.oss.endpoint=oss-cn-beijing-internal.aliyuncs.com'
--table_conf 'write-buffer-size=256 MB'
--table_conf 'your_table.logRetentionDuration=7 days'|
Parámetro |
Descripción |
|
|
Ruta de OSS del almacén de datos que contiene el catálogo de la tabla Paimon. |
|
|
Nombre de la base de datos que contiene la tabla Paimon. |
|
|
Nombre de la tabla Paimon. |
|
|
Estrategia de ordenación. Valores válidos: |
|
|
Columnas por las cuales ordenar, separadas por comas. |
|
|
Particiones que se van a ordenar, separadas por punto y coma. Omita este parámetro si la tabla no está particionada. |
|
|
Parámetros de la cláusula WITH del catálogo que contiene la tabla Paimon. Especifique un parámetro por línea. |
|
|
Configuración temporal de la tabla, equivalente a SQL Hints. Especifique un parámetro por línea. |