Cet article explique comment Apache Doris vous aide à importer des données et à effectuer une capture de données modifiées (CDC) à partir de bases de données en amont telles que MySQL vers Doris sur la base du streaming Flink. Mais tout d’abord, vous pourriez vous demander : qu’est-ce qu’Apache Doris et pourquoi devrais-je prendre la peine de le faire ?
Eh bien, Apache Doris est un entrepôt de données analytiques en temps réel open source qui prend en charge à la fois les requêtes ponctuelles à haute simultanéité et les analyses complexes à haut débit. Il fournit des capacités de requête analytique en moins d’une seconde et s’avère pratique pour l’analyse multidimensionnelle, les tableaux de bord et d’autres services de données en temps réel.
Aperçu
- Comment effectuer une synchronisation des données de bout en bout en quelques secondes
- Comment assurer la visibilité des données en temps réel
- Comment faciliter l’écriture de petits fichiers volumineux
- Comment garantir un traitement Exactly-Once de bout en bout
Actualité en temps réel
Le connecteur Flink-Doris dans Doris suivait une méthode « Cache and Batch Write » pour l’ingestion de données. Cependant, cela nécessite un choix judicieux de la taille du lot et de l’intervalle d’écriture par lot ; sinon les choses pourraient mal tourner. Par exemple, si la taille du lot est trop importante, des erreurs de MOO peuvent se produire. D’un autre côté, des écritures fréquentes pourraient entraîner la génération d’un trop grand nombre de versions de données.
Pour éviter de tels problèmes, Doris implémente une méthode Stream Write, qui fonctionne comme suit :
- Une tâche Flink, une fois démarrée, lance de manière asynchrone une requête HTTP Stream Load.
- Les données sont transmises à Doris via le mécanisme de codage de transfert par blocs de HTTP.
- La requête HTTP se termine au point de contrôle, ce qui signifie que la tâche de chargement de flux est terminée. Pendant ce temps, la prochaine demande de chargement de flux sera lancée de manière asynchrone.
- Répétez les étapes ci-dessus.
- Agrégation rapide des versions de données
L’écriture hautement simultanée de petits fichiers peut générer trop de versions de données dans Doris et ralentir les requêtes de données. Ainsi, Doris a amélioré sa capacité de compactage des données afin d’agréger rapidement les données.
Tout d’abord, Doris a introduit le compactage rapide. Plus précisément, le compactage des données sera déclenché une fois que les versions de données augmenteront. Pendant ce temps, en analysant les métadonnées des tablettes, Doris peut identifier ces tablettes avec trop de versions de données et effectuer le compactage en conséquence.
Deuxièmement, pour l’écriture de petits fichiers, qui se produit avec une simultanéité et une fréquence élevées, Doris implémente le compactage cumulatif. Il isole ces tâches de compactage du compactage de base lourd du point de vue de la planification pour éviter une influence mutuelle entre elles.
Enfin, Doris adopte une méthode d’agrégation de données à plusieurs niveaux, qui garantit que chaque agrégation ne concerne que des fichiers de tailles similaires. Cela réduit considérablement le nombre total de tâches d’agrégation et l’utilisation du processeur du système.
Exactement une fois
La sémantique Exactly-Once signifie que les données seront traitées une fois et une seule. Il empêche les données d’être retraitées ou perdues même si la machine ou l’application tombe en panne.
Flink implémente un protocole 2PC pour réaliser la sémantique Exactly-Once des opérateurs Sink. Sur cette base, le connecteur Flink-Doris de Doris implémente Stream Load 2PC pour fournir un traitement Exactly-Once. Les détails sont les suivants:
- Une tâche Flink lancera une requête Stream Load PreCommit une fois qu’elle sera démarrée. Ensuite, une transaction sera ouverte et les données seront envoyées en continu à Doris via le mécanisme de segmentation de HTTP.
- La requête HTTP se termine au point de contrôle et le chargement du flux est terminé. Le statut de la transaction sera défini sur Pré-engagé. À ce moment, les données ont été écrites dans BE et sont devenues invisibles pour les utilisateurs.
- Le point de contrôle initie une demande et change le statut de la transaction en Committed. Après cela, les données deviendront visibles pour les utilisateurs.
- Dans le cas d’échecs de l’application Flink, si la transaction précédente est en statut pré-engagé, le point de contrôle lancera une demande de restauration et changera le statut de la transaction en Aborted.
Performances de Doris dans les scénarios à haute simultanéité
Description du scénario
Importez des données depuis Kafka à l’aide de Flink. Après ETL, utilisez le connecteur Flink-Doris pour l’ingestion de données en temps réel dans Doris.
Exigences
Les données en amont sont écrites dans Doris à une fréquence élevée de 100 000 par seconde. Pour obtenir une visibilité des données en temps réel, les données en amont et en aval doivent être synchronisées en 5 secondes environ.
Configurations Flash
Concurrence : 20
Intervalle de point de contrôle : 5 s
Voici comment Doris procède :
Compactage en temps réel
Comme le montre le résultat, Doris parvient à agréger les données rapidement et à maintenir le nombre de versions de données dans les tablettes en dessous de 50. Pendant ce temps, le score de compactage reste stable.
L’utilisation du processeur
Après avoir optimisé la stratégie de compactage des petits fichiers, Doris réduit l’utilisation du processeur de 25 %.
Latence des requêtes
En réduisant l’utilisation du processeur et le nombre de versions de données, Doris organise les données de manière plus ordonnée et permet ainsi une latence de requête beaucoup plus faible.
Performances de Doris dans des scénarios à faible latence (test de résistance de haut niveau)
Description
- Test de charge Stream Load mono-BE, mono-tablette côté client
- Données en temps réel <1s
Voici les scores de compactage avant et après optimisation :
Suggestions d’utilisation de Doris
Scénarios à faible latence
En ce qui concerne les scénarios nécessitant une visibilité des données en temps réel (comme la synchronisation des données en quelques secondes), les fichiers de chaque ingestion sont généralement de petite taille. Ainsi, il est recommandé de réduire cumulative_size_based_promotion_min_size_mbytede la valeur par défaut de 64 à 8 (mesurée en Mo). Cela peut grandement améliorer les performances de compactage.
Scénarios à haute simultanéité
Pour les scénarios d’écriture hautement simultanés, il est recommandé de réduire la fréquence de Stream Load en augmentant l’intervalle de point de contrôle à 5-10 s. Cela augmente non seulement le débit des tâches Flink, mais réduit également la génération de petits fichiers et évite ainsi une pression supplémentaire sur le compactage. De plus, pour les scénarios avec des exigences moins strictes en matière de temps réel (telles que la synchronisation des données en quelques minutes), il est recommandé d’augmenter l’intervalle de point de contrôle à 5 à 10 minutes. De cette manière, le connecteur Flink-Doris peut toujours garantir l’intégrité des données via le mécanisme 2PC+Checkpoint.
Conclusion
Apache Doris réalise des données en temps réel grâce à sa méthode Stream Write, sa capacité de traitement des transactions et l’agrégation des versions de données. Ces techniques l’aident à réduire l’utilisation de la mémoire et du processeur, ce qui permet une latence plus faible. De plus, pour l’intégrité et la cohérence des données, Doris implémente Stream Load 2PC pour garantir que toutes les données sont traitées exactement une fois. C’est ainsi que Doris facilite l’ingestion rapide et sûre des données.