Realtime Compute for Apache Flink:Performance tuning for Paimon tables

Ajuster le parallélisme du sink

Utilisez les SQL Hints pour définir le paramètre sink.parallelism. L'augmentation du parallélisme répartit la charge d'écriture et de compaction sur davantage de workers, réduisant ainsi le risque qu'un seul compartiment devienne un goulot d'étranglement. Notez qu'un parallélisme plus élevé augmente également la consommation de ressources.

Ajuster les paramètres des points de contrôle

Étant donné que les performances d'écriture dans Paimon sont étroitement liées à la fréquence des points de contrôle, l'ajustement du comportement des points de contrôle est souvent le moyen le plus rapide de réduire la contre-pression.

Utilisez n'importe quelle combinaison des ajustements suivants :

• Augmentez l'intervalle des points de contrôle en configurant execution.checkpointing.interval. Pour les étapes de configuration, consultez la rubrique How do I configure parameters for deployment running?

  Important

  L'intervalle des points de contrôle affecte directement la latence des données — le temps écoulé entre l'écriture des données et leur disponibilité pour la consommation. N'augmentez cet intervalle que si votre charge de travail tolère une latence plus élevée.

• Ajoutez execution.checkpointing.max-concurrent-checkpoints: 3 pour permettre l'exécution simultanée de jusqu'à trois points de contrôle. Cela réduit l'impact des points de contrôle lents sur le débit global.

• Basculez vers un déploiement par lots pour éliminer totalement la surcharge des points de contrôle.

Activer la compaction entièrement asynchrone

Par défaut, la compaction est synchronisée avec le cycle des points de contrôle. La compaction entièrement asynchrone rompt cette dépendance : la compaction s'exécute en arrière-plan dès que des ressources sont disponibles, et les points de contrôle progressent sans attendre la fin de la compaction.

La contrepartie est que les petits fichiers peuvent s'accumuler pendant les périodes d'écriture intense. Cela n'affecte pas la consommation en flux continu, mais dégrade les performances de consommation par lots et des requêtes OLAP jusqu'à ce que la compaction en arrière-plan rattrape son retard. Surveillez le nombre de petits fichiers dans chaque compartiment à l'aide de la table files fournie par Paimon.

Configurez les paramètres suivants à l'aide de l'instruction ALTER TABLE ou des SQL Hints :

'num-sorted-run.stop-trigger' = '2147483647',
'sort-spill-threshold' = '10',
'changelog-producer.lookup-wait' = 'false'

Changer le format de fichier vers Avro

Si votre activité se concentre sur la consommation par lots ou en flux continu et ne nécessite pas de requêtes ad hoc OLAP, configurez les paramètres suivants pour modifier le format des fichiers de données et désactiver la collecte de statistiques. Cela améliore l'efficacité des opérations d'écriture.

Configurez les paramètres suivants lors de la création de la table :

'file.format' = 'avro',
'metadata.stats-mode' = 'none'

Limiter la taille des fichiers temporaires locaux

Définissez write-buffer-spill.max-disk-size dans les SQL Hints pour plafonner l'espace disque maximal utilisé par les tampons d'écriture déversés. Cela empêche les workers d'écriture de consommer excessivement le disque local.

Ajuster le parallélisme de la source

Utilisez les SQL Hints pour définir le paramètre scan.parallelism de la source Paimon. L'augmentation de cette valeur permet à davantage de lecteurs parallèles de traiter les données simultanément.

Utiliser la table optimisée pour la lecture

Lors de la consommation par lots, de la phase de scan complet de la consommation en flux continu et des requêtes ad hoc OLAP, Paimon doit fusionner les données des petits fichiers en mémoire à l'aide d'un tri fusion. Un grand nombre de petits fichiers ralentit considérablement ce processus.

Si vous n'avez pas besoin de consommer les données les plus récentes, vous pouvez utiliser la table read-optimized pour améliorer l'efficacité de la consommation. Lorsque vous avez activé la compaction entièrement asynchrone pour maximiser le débit d'écriture, les petits fichiers s'accumulent plus vite qu'ils ne sont fusionnés ; dans ce cas, l'utilisation de la table optimisée pour la lecture afin de lire uniquement les données déjà compactées améliore les performances de lecture, au prix de la non-visibilité des enregistrements écrits très récemment.

Limiter la taille du cache de jointure par recherche

Lors de l'exécution de jointures par recherche (lookup joins) sur une table Paimon, les fichiers mis en cache peuvent croître sans limite. Configurez les paramètres suivants dans les SQL Hints pour contrôler la croissance du cache :

• lookup.cache-max-disk-size — L'espace disque maximal utilisé par le cache de recherche.

• lookup.cache-file-retention — La durée de conservation des fichiers mis en cache avant expiration.

Ajuster le parallélisme du sink

Utilisez les SQL Hints pour définir le paramètre sink.parallelism. Notez qu'un parallélisme plus élevé augmente la consommation de ressources.

Résoudre le déséquilibre des données

Les données en amont ne sont pas brassées avant d'être écrites dans une table extensible par ajout. Si la distribution des données en amont est déséquilibrée, certains workers de sink reçoivent beaucoup plus de données que d'autres, laissant certaines ressources sous-utilisées et créant un goulot d'étranglement d'écriture.

Définissez sink.parallelism sur une valeur différente du parallélisme du nœud en amont. Cela force un brassage entre l'opérateur en amont et le sink. Pour confirmer que le brassage est actif, consultez la console de développement Realtime Compute for Apache Flink : si l'opérateur sink et son nœud en amont apparaissent dans différentes sous-tâches, les données sont bien brassées.

Limiter la taille des fichiers temporaires locaux

Définissez write-buffer-spill.max-disk-size dans les SQL Hints pour plafonner l'espace disque utilisé par les tampons d'écriture déversés.

Ajuster le parallélisme de la source

Utilisez les SQL Hints pour définir le paramètre scan.parallelism de la source Paimon.

Trier les données pour améliorer l'efficacité des requêtes

L'ordre des données affecte considérablement les performances du traitement par lots et des requêtes ad hoc OLAP. Le tri des données selon les colonnes les plus couramment utilisées dans les conditions de filtre réduit la quantité de données que chaque requête doit analyser.

Le tri nécessite l'exécution d'une tâche Flink en mode batch. Avant de commencer, effectuez la configuration requise décrite dans la rubrique Data management configuration. Configurez ensuite les paramètres de la tâche dans le champ Entry Point Main Arguments.

Quand utiliser chaque stratégie de tri :

L'exemple suivant trie les données dans des partitions spécifiques par les colonnes date et type à l'aide de 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'