La Station B construit un lac de données en temps réel basé sur Hudi

3 millions de mots ! La communauté d’entretiens d’apprentissage big data la plus complète de tout le réseau vous attend !

Contexte et points douloureux

Dans l’application de scénarios Big Data, l’entreprise doit non seulement calculer les résultats des données, mais également garantir l’actualité. À l'heure actuelle, notre entreprise a développé deux liens. Les données à haute actualité passent par les liens en temps réel Kafka et Flink ; les données à faible actualité passent par les liens hors ligne Spark. La figure ci-dessus décrit brièvement le lien pour la déclaration, le traitement et l'utilisation des données de la station B. La collecte de données s'effectue principalement via les données d'événements comportementaux signalées par l'APP. Les données de journal rapportées par le serveur seront distribuées en flux continu au système d'entrepôt de Big Data via la passerelle et la couche de distribution.

Les données commerciales stockées dans MySQL sont périodiquement synchronisées par lots avec l'entrepôt de données via Datax. Les données sensibles au temps seront calculées en flux via Flink+Kafka. Les données à faible actualité sont calculées par lots via Spark+HDFS et finalement transmises au support de MySQL Redis Kafka pour être utilisées dans la formation de modèles IA et BI et dans les scénarios d'analyse de rapports.

Au cours du processus d'utilisation, de nombreux problèmes ont également été constatés.

1. L'actualité des données hors ligne n'est pas suffisante et le calcul par lots hors ligne est basé sur les heures/jours. De plus en plus d'entreprises espèrent que la ponctualité pourra atteindre le niveau de la minute, et les calculs horaires ou quotidiens hors ligne ne peuvent pas répondre aux besoins des entreprises. Afin d'atteindre une plus grande rapidité, l'entreprise développera un autre lien en temps réel.

2. Mais l’observabilité du lien en temps réel est faible. Comme il n'est pas pratique d'afficher les données dans Kafka, les données dans Kafka doivent être déplacées vers d'autres stockages avant d'être visualisées. Les liaisons de données en temps réel ne sont généralement pas faciles à aligner sur le temps de travail, et il est difficile de localiser avec précision le point de départ qui doit être réexécuté. Si les données sont anormales, l'entreprise choisit généralement de ne pas réexécuter le flux en temps réel, mais d'effectuer une réparation T-1 sur la liaison hors ligne.

3. La double liaison hors ligne en temps réel entraînera des frais généraux de ressources, de développement, d'exploitation et de maintenance doubles. De plus, un calibre incohérent entraînera des coûts d’interprétation supplémentaires.

4. Le pic des ressources informatiques tout au long de la journée est concentré tôt le matin et le pic d'utilisation de l'ensemble du cluster Big Data se situe entre 2h00 et 8h00 du matin. Exécutant principalement des tâches au niveau du ciel, il existe également un phénomène de mise en file d'attente des tâches. Les ressources des autres périodes sont relativement inutilisées et il existe des pics et des creux évidents lorsqu'elles sont utilisées. Il existe une marge d’optimisation dans l’utilisation globale des ressources.

5. En termes d'îlots de stockage de données, les utilisateurs doivent également cloner une copie des données sur HDFS, ce qui entraînera des problèmes de cohérence des données. Lorsque les données sont hors de l’entrepôt, les autorisations et les requêtes de fédération de données seront insuffisantes.

Nous espérons résoudre les problèmes ci-dessus grâce à la solution de lac de données en temps réel.

1. Nous utilisons Flink+Hudi pour stocker les incréments de données et les résultats des calculs incrémentiels dans Hudi, qui prend en charge les calculs de données à la minute près et améliore encore l'actualité des données.

2. De plus, Hudi a la dualité de la table de flux, qui peut non seulement effectuer une consommation incrémentielle de streaming en temps réel, mais peut également être utilisée comme table pour une requête directe. Par rapport au lien Kafka, l’observabilité est encore améliorée.

3. Le lac de données en temps réel répond aux exigences en temps réel et hors ligne, ce qui permet de réduire les coûts et d'augmenter l'efficacité. En outre, il prend également en charge la demande de réexécution des données d'entrepôt de données hors ligne.

4. Grâce à un calcul incrémentiel, les ressources de données initialement allouées après 0 heure sont subdivisées et allouées à chaque minute de la journée entière, et les ressources sont utilisées par pics échelonnés.

5. Grâce au tri, à l'indexation, à la matérialisation, etc., nous pouvons directement interroger les données dans la table Hudi, afin d'obtenir l'effet de sortie des données de l'entrepôt.

exploration de scène

2.1 Scénario d'entreposage de base de données

Lorsque les données du système d'entreprise sont stockées dans MySQL, ces données doivent être importées dans l'entrepôt de données Big Data à des fins de reporting, d'analyse, de calcul et d'autres scénarios. À l'heure actuelle, l'entreposage de données d'entreprise n'est pas seulement utilisé pour l'ETL hors ligne, mais il est également censé être sensible au facteur temps. Par exemple, dans le scénario de révision du contenu des manuscrits, le personnel veut savoir si l'augmentation du nombre de manuscrits au cours des dix dernières minutes correspond à la main-d'œuvre chargée de la révision des manuscrits, et il existe des demandes de surveillance et d'alarme en temps réel. Les données du manuscrit proviennent de la base de données commerciale. Il n'est pas satisfait de la rapidité de la synchronisation actuelle des données au niveau du jour et de l'heure, et espère atteindre la rapidité du niveau des minutes.

Dans le contexte de la réduction des coûts et de l’augmentation de l’efficacité, nous devons non seulement répondre aux demandes des entreprises, mais également tenir compte de l’efficacité. Le lien en temps réel est utilisé dans les scénarios en temps réel, et le lien hors ligne est inutile dans les scénarios ETL par lots. Par conséquent, nous espérons créer une solution unifiée de flux et de lots via le lac de données en temps réel, tout en répondant aux exigences des scénarios en temps réel et hors ligne. Grâce à la recherche, il s'avère que les régimes existants entrent dans les catégories suivantes :

Premièrement, DataX exporte périodiquement des données par lots vers Hive.

Hive lui-même n'a pas la capacité de mettre à jour et exporte généralement le montant total quotidiennement, ce qui ne répond pas aux exigences de rapidité. De plus, cette solution pose également le problème de la redondance des données. Les partitions quotidiennes de la table Hive sont des instantanés de la table MySQL ce jour-là. Par exemple, les informations contenues dans un tableau d'informations utilisateur changent très peu et un instantané complet doit être stocké chaque jour. Autrement dit, chaque information utilisateur sera stockée une fois par jour. Si le cycle de vie de la table Hive est de 365 jours, alors cette donnée sera stockée de manière répétée 365 fois.

Deuxièmement, la solution Canal/CDC vers Hudi.

Les données de DB sont écrites dans Hudi via Canal ou Flink CDC, afin de répondre à l'exigence d'actualité. Étant donné que les données de Hudi sont mises à jour en temps réel, elles n'ont pas la capacité de lecture reproductible. Cette solution ne répond donc pas au scénario ETL. Même avec la capacité de « lecture instantanée » de Hudi. Bien qu'il soit possible de lire l'historique du commit de Hudi, obtenez un instantané des données à un moment donné. Cependant, si les données de validation sont conservées pendant une longue période, cela entraînera un trop grand nombre de fichiers, ce qui affectera les performances d'accès à la chronologie, puis affectera les performances de lecture et d'écriture de Hudi.

Troisièmement, la solution Hudi Export Hive.

Ce schéma est une combinaison des deux schémas précédents. Une fois les données de la base de données écrites dans Hudi via Canal/CDC, elles sont périodiquement exportées vers la table Hive. Les tables Hudi sont utilisées dans des scénarios en temps réel et les tables Hive sont utilisées dans des scénarios ETL hors ligne. Afin de répondre aux exigences de la scène sous deux aspects en même temps. L'inconvénient est que l'utilisateur utilise deux tables en cours d'utilisation, et il y a un certain coût de compréhension et de redondance des données.

Quatrièmement, la solution Hudi Savepoint.

Cela résout principalement le problème de la redondance des données. Grâce à un point de sauvegarde périodique, les métadonnées de la chronologie de Hudi à ce moment-là peuvent être stockées. Lors de l'accès à Savepoint, il sera mappé pour accéder au fichier réel de Hudi afin d'éviter les fichiers de données de stockage redondants. Un Savepoint par jour équivaut à stocker un snapshot MySQL chaque jour, répondant ainsi aux exigences de relecture de scène ETL. Dans le même temps, vous pouvez également accéder directement aux dernières données de Hudi pour répondre aux demandes en temps réel des utilisateurs.

Mais ce schéma présente encore quelques défauts : il ne peut pas diviser avec précision les données sur plusieurs jours. Lors de l'écriture incrémentielle sur Hudi via Flink, Commit sera généré périodiquement, et le temps d'activité et l'alignement de Commit ne peuvent pas être contrôlés. Si les données d'hier et d'aujourd'hui relèvent du même Commit, Savepoint utilisera Commit comme force minimale. Lors de l'accès au point de sauvegarde d'hier, il contient les données d'aujourd'hui, ce qui n'est pas ce à quoi l'utilisateur s'attendait.

Afin de résoudre les problèmes ci-dessus, la solution que nous proposons est la vue instantanée Hudi Snapshot View. Une amélioration a été apportée au schéma Hudi Savepoint, qui est simplement un Hudi Savepoint avec filtrage.

Dans le schéma d'exportation Hive, des conditions de filtrage peuvent être ajoutées pour filtrer les données du lendemain. Nous intégrons une logique de filtrage dans la vue instantanée Hudi. Dans la vue instantanée, la logique de filtrage est implémentée au bas de Hudi et stockée dans Hudi Meta. Lors de l'accès à la vue de l'instantané, nous cracherons les données filtrées pour résoudre le problème des données multijournées dans l'instantané.

Comme le montre la figure ci-dessus, Delta Commit T3 contient les données du 1er et du 2 novembre. Lorsque les données sources de la vue instantanée sont stockées, toutes les données sources historiques de T1, T2 et T3 sont stockées. De plus, la condition de filtre Delta<=1er novembre est également stockée. Filtrez les données lors de la lecture et n'incluez que les données du 1er novembre et avant la fin de la requête, à l'exclusion des données du 2 novembre.

La vue instantanée stocke également les métadonnées et accède aux fichiers de données réels via le mappage, il n'y a donc aucun problème de stockage de données redondant. Il satisfait également aux scénarios en temps réel et hors ligne, réalisant l'unification du streaming et du batching. De plus, la vue instantanée découpe indépendamment une chronologie, qui prend en charge des opérations telles que le compactage et le clustering pour accélérer les requêtes.

Parlons ensuite du timing de génération de l’instantané. Après quel commit l'utilisateur doit-il créer cette vue instantanée ? Il y a deux concepts qui doivent être compris ici, l'un est le temps de l'événement et l'autre est le temps de traitement.

Lorsque les données sont retardées, même si l'heure réelle atteint 0 heures, il se peut qu'elles soient toujours en cours de traitement à 22 heures. À ce stade, si la vue d'instantané est effectuée, les données de vue d'instantané lues par l'utilisateur seront relativement petites. Parce que Commit est le temps de traitement, pas le temps d'un événement commercial. Cette vue instantanée doit être effectuée après que l'heure de l'événement ait atteint 0 heure pour garantir l'intégrité des données. À cette fin, nous avons ajouté la progression du traitement dans Hudi. Ce concept est similaire à l'utilisation de Watermark dans Flink pour identifier la progression du traitement. Nous avons étendu Hudi Meta pour stocker la progression du traitement dans Commit. Lorsque l'heure de l'événement avance jusqu'à 0 heure, l'opération Snapshot View démarre pour informer les tâches en aval qu'elles peuvent être appelées. Avec la progression du traitement de l'événement dans Meta, la progression du traitement peut également être obtenue lors de l'interrogation de Hudi, afin de porter certains jugements.

De plus, nous avons également réalisé l’adaptation de la couche moteur. En termes d'utilisation, le SQL écrit par l'utilisateur est fondamentalement le même que celui d'origine. Grâce au paramètre truc ou set, précisez s'il faut interroger la partition instantanée ou la partition en temps réel. Dans le scénario de l'entreposage de base de données, il répond non seulement à la rapidité des scénarios en temps réel, mais répond également aux exigences hors ligne de l'ETL, réalise avec succès l'unification du temps réel et hors ligne et atteint l'objectif de réduction des coûts et d'augmentation de l'efficacité.

2.2 Scène de stockage en point enterré

Parlons ensuite de la scène des points d’enfouissement dans les entrepôts. En tant que société Internet, notre société définit également les événements de comportement des utilisateurs, collecte des données, les signale à l'entrepôt, puis les analyse et les utilise. Utilisez les données pour stimuler le développement commercial.

Les rapports de notre entreprise sur les événements comportementaux des utilisateurs ont atteint une échelle considérable, et il existe de nombreux événements comportementaux. Aujourd'hui, des dizaines de milliers d'ID d'événements comportementaux ont été définis, et des centaines de milliards de données sont ajoutées chaque jour, et le trafic est très important. L'entreposage en point enterré est un projet au niveau de l'entreprise, et toutes les parties commerciales présentes sur le site signalent des points enfouis. Lors de l'utilisation de points enterrés, notre société connaît un grand nombre d'utilisations croisées des métiers départementaux. Par exemple, l’IA publicitaire doit utiliser les données rapportées par d’autres secteurs d’activité pour la collecte d’échantillons et la formation.

Dans l'architecture d'origine, les données rapportées par l'extrémité APP sont transmises et nettoyées, et tombent dans les partitions de table pré-divisées de l'entrepôt de données, qui sont fournies au côté commercial pour le développement et l'utilisation. Cette division commerciale est une division grossière basée sur des informations commerciales telles que les BU et les types d'événements. Les tâches en aval peuvent utiliser les tables de leur propre service et les tables d'autres services, et doivent uniquement demander une autorisation.

Mais l’architecture présente également quelques problèmes. L'isolement d'un flux de données ne suffit pas, et des dizaines de milliers de points enterrés sont transmis par le même canal, et l'isolement est insuffisant pour le nettoyage. Il est facile qu'un certain événement comportemental augmente fortement au cours de l'activité, ce qui affecte la progression globale du traitement des tâches. De plus, les utilisateurs métier doivent filtrer une grande quantité de données inutiles. Dans les tâches métier en aval, un seul de vos propres événements de comportement peut être utilisé à des fins d'analyse. Mais à cette époque l’incident de comportement se mélange à d’autres incidents de comportement dans le même département. Dans le filtrage conditionnel, la couche moteur ne peut effectuer qu'un filtrage au niveau de la partition. En chargeant les fichiers de la partition entière, puis en filtrant, il y a un gaspillage d'E/S pour la lecture de fichiers plus volumineux. En parallèle, la gestion des autorités est difficile lorsque les départements utilisent les données de manière croisée : si un événement de comportement d'une autre BU est utilisé, il est nécessaire de demander l'autorité de l'ensemble de la table de la BU. Grosseur de particules, il y a un risque. L’aval a des demandes infimes. Actuellement, les données en streaming sont nettoyées toutes les heures. La rapidité en aval se situe au niveau horaire, ce qui ne répond pas aux demandes de rapidité des utilisateurs.

Afin de résoudre les problèmes ci-dessus, nous avons procédé à quelques optimisations architecturales. Comme le montre la figure ci-dessus, une fois les données déclarées et transmises, les données sont déposées dans la table Hudi du ménage. Les utilisateurs accèdent ou utilisent ces données via View, qui peut être utilisé dans des scénarios tels que l'ETL hors ligne, le calcul en temps réel et l'analyse de rapports BI.

Pour les données nécessitant une actualité de deuxième niveau, des liens Kafka de haute qualité seront utilisés pour fournir des services en ligne, et cette proportion est relativement faible. La plateforme de gestion d'événements Polaris et la gestion des métadonnées sont responsables de la gestion du cycle de vie de l'ensemble du point d'enfouissement des événements comportementaux, des règles de distribution, etc.

Le contrôle de la plate-forme commence par le reporting en périphérie, la distribution des règles, l'isolation des activités et une isolation améliorée. Une fois que les données sont tombées dans la table Hudi de l'entreprise, un clustering est effectué pour trier et indexer les données de l'entreprise. Grâce à la couche moteur, le saut de données au niveau du fichier/du bloc de données est effectué pour réduire la surcharge d'E/S liée à la lecture réelle de la quantité de données. Les utilisateurs lisent les données via Hive View et la plateforme gère les autorisations au niveau des événements de comportement en ajoutant des événements de comportement autorisés à la vue de l'utilisateur. Par exemple, lorsque les étudiants du département a utilisent les événements comportementaux du département b, ajoutez simplement un identifiant de l'événement comportemental du département b à la vue du département a. Lors de la soumission de SQL pour inspection, une vérification des autorisations au niveau de l'événement comportemental sera effectuée. Lorsque la transmission incrémentielle nettoie la table Hudi, la table Hudi prend en charge la consommation incrémentielle, ce qui peut atteindre une rapidité infime. Des tâches en temps réel en aval peuvent être utilisées derrière cette vue, de manière à réaliser l'unification des flux par lots.

En termes d'optimisation côté Hudi, comme les données de trafic ne sont pas mises à jour lorsqu'elles entrent dans le lac, nous adoptons le mode sans index et supprimons l'attribution du bucket et d'autres processus pour améliorer la vitesse d'écriture. Dans le même temps, le délai ETL en aval du clustering incrémentiel de Flink n'a pas augmenté de manière significative. Après le clustering, les données deviennent ordonnées. L'index enregistre la distribution des événements de comportement et peut être filtré au niveau du fichier et du bloc de données via une requête conditionnelle. De plus, des moteurs tels que Flink et Spark prennent également en charge la suppression des prédicats des tables Hudi, ce qui améliore encore l'efficacité. En termes de prise en charge de View par Flink, l'aval de View peut définir un filigrane ou définir l'attribut with sur View, etc.

Grâce à la combinaison de l'ajustement de l'architecture et des capacités de Hudi, nous avons amélioré l'isolement et la rapidité de la gestion des points enterrés et économisé des ressources.

2.3 Scénario de rapport BI en temps réel

Parlons ensuite du scénario de rapport BI en temps réel. Dans le cadre de l'architecture d'origine, une fois les données de trafic et les données de base de données importées dans l'entrepôt de données, elles seront jointes et élargies, et les résultats du calcul d'origine seront sortis vers un stockage tel que MySQL après agrégation. Les rapports BI se connecteront directement à MySQL pour l'affichage des données. Un autre lien hors ligne effectuera la réparation des données T-1.

Le problème de l'architecture originale réside dans la construction répétée de liens en temps réel et hors ligne, les coûts de calcul et de stockage élevés, les coûts de développement et d'exploitation élevés et les coûts d'interprétation de haut niveau. Les données Kafka doivent être copiées vers un autre stockage pour être interrogées, et l'observabilité est relativement faible. De plus, les liens Kafka sont difficiles à réparer les données. Il est difficile de déterminer le point de départ de la réparation du lien Kafka, et la méthode T-1 est généralement utilisée pour la réparation. Il existe des problèmes tels que les îlots de stockage de données.

Les scénarios de rapports BI en temps réel ne nécessitent généralement pas de ponctualité de deuxième niveau, et une ponctualité à la minute près peut répondre aux exigences. Nous avons remplacé Kafka par Hudi, qui répondait à la fois aux exigences en temps réel et hors ligne, a réalisé l'unification des lots de flux, a réduit les coûts et a unifié le calibre des données.

Par rapport à Kafka, Hudi peut interroger directement les données dans Hudi, et il est plus facile et plus pratique d'alarmer que Kafka.

Par exemple, comparez les données d'il y a sept jours sur Kafka et créez une alarme de seuil. Il faut consommer les données d'il y a sept jours et les données actuelles, effectuer des calculs, puis émettre une alarme. L'ensemble du processus est plus compliqué. La requête SQL de Hudi est cohérente avec la requête SQL hors ligne. Pour le système DQC, le schéma de DQC en temps réel et de DQC hors ligne est unifié et le coût de développement est faible. Pour les tâches comportant des exigences de rapidité de deuxième niveau, le lien Kafka est également requis.

De plus, les données peuvent être conservées hors de l’entrepôt. Les rapports BI peuvent être directement interrogés et connectés à la table Hudi interrogée pour l'affichage des données.

En utilisation réelle, il existe également quelques problèmes. Lorsque la requête agrégée est directement effectuée sur la table détaillée de Hudi, le temps de requête est trop long et il y a un problème d'amplification de lecture.

Supposons que DQC en temps réel compte les données pendant près d'une heure toutes les cinq minutes pour surveiller le nombre d'éléments de données. Les données de près d'une heure seront calculées en cinq minutes, et les données de près d'une heure seront calculées dans les cinq minutes suivantes. En faisant glisser la fenêtre, les données intermédiaires seront calculées plusieurs fois et il y aura une sérieuse amplification des E/S.

De plus, prenons le scénario du rapport BI comme exemple. En supposant qu'une courbe DAU soit affichée, chaque point correspond à la valeur cumulée des données historiques. Les données de 1 point sont la valeur cumulée des données de 0 point ~ 1 point. Les données au point 2 sont la valeur cumulée des données du point 0 au point 2. Lors de l'affichage sur l'interface, il est nécessaire de calculer n points, et chaque point sera calculé à plusieurs reprises, ce qui entraînera un temps de requête long et le problème de l'amplification de la lecture.

De plus, les coûts de développement, d’exploitation et de maintenance sont relativement élevés. Les utilisateurs afficheront plusieurs indicateurs sur l'interface d'un panel BI. Il peut s'agir de données de dimensions différentes provenant du même calendrier Hudi. Si dix indicateurs sont produits, dix tâches en temps réel doivent être développées et maintenues, ce qui entraîne des coûts de développement et de maintenance élevés et une faible fiabilité. Lorsqu'une exception se produit dans une tâche en temps réel, certains indicateurs seront absents de ce panneau.

La solution d'optimisation que nous proposons consiste à construire la vue matérialisée de projection via Flink+Hudi. Grâce à l'état Flink State, seuls les calculs de données incrémentielles doivent être ingérés, évitant ainsi le problème de l'amplification de la lecture. Les résultats de la requête sont calculés à l'avance et les données de résultat sont directement interrogées pour obtenir l'effet d'accélérer la requête.

Le processus spécifique est que l'utilisateur soumet une requête SQL à Excalibur Server pour une analyse SQL. Pendant le processus d'analyse, la création de la projection est soumise, une tâche Stream est soumise, puis les données de la table d'origine sont lues de manière incrémentielle et, après le calcul de matérialisation, elles sont stockées dans la table de matérialisation de la projection. Lorsque la requête SQL atteint la règle de matérialisation, la requête sera réécrite pour interroger directement la table de résultats afin d'obtenir l'effet d'accélération.

En étendant le processus d'analyse de Flink Batch SQL, les règles de matérialisation et les métadonnées de projection seront chargées lors de la requête. Et jugez la progression actuelle de la matérialisation du filigrane de la table matérialisée. Si les conditions sont remplies, réécrivez la requête dans la table matérialisée Projection.

Nous nous référons aux règles de matérialisation de Calcite et ajoutons le support syntaxique de TVF.

Prend en charge la création de Projection. Lorsque les utilisateurs soumettent des requêtes par lots, ils peuvent ajouter un indice à l'instruction select pour inviter le moteur de requête, et la requête sera réutilisée. Le moteur créera une projection pour la requête.

Prend en charge la syntaxe et les règles Projection DDL de Flink SQL pour la réécriture des requêtes SQL. Lorsque l'utilisateur soumet une requête par lots, s'il existe une projection correspondante, elle peut être réécrite. Après la réécriture, les résultats de la projection peuvent être utilisés directement, ce qui accélère considérablement la requête et peut obtenir une réponse de deuxième niveau, voire de la milliseconde.

La réécriture et la rétrogradation de Projection sont basées sur des indicateurs tels que Watermark, qui masquent des problèmes tels que les retards et les échecs des tâches en temps réel de Projection et garantissent la fiabilité des résultats des requêtes. Nous avons ajouté des informations sur la progression du traitement des données Watermark dans Hudi Meta. Pendant le processus d'écriture des données, nous enregistrerons la progression de la matérialisation dans Commit Meta. Lors de la correspondance des règles de matérialisation, si elle est trop en retard par rapport à l'heure actuelle, la réécriture de la projection actuelle sera rejetée et elle sera directement rétrogradée vers la table d'origine pour la requête de données.

Ajoutez la création d'indices sur l'instruction select et obtenez l'effet d'accélérer la requête grâce à la capacité de matérialisation. Cela résout non seulement le problème de l'amplification de lecture, mais réduit également les coûts de développement, d'exploitation et de maintenance de l'utilisateur grâce à une rétrogradation automatique.

À l’avenir, nous optimiserons l’efficacité de la projection. Recyclez les projections qui ne peuvent pas être réalisées avant longtemps. Fusionnez plusieurs projections avec les mêmes dimensions pour réduire le coût de calcul des projections. De plus, nous nous connecterons au système d'indicateurs et accélérerons la requête via le cache du système d'indicateurs pour répondre au calcul de flux de certains scénarios à QPS élevé.

Dans le passé, Flink SQL était utilisé pour l'écriture en continu et Spark SQL pour la réparation par lots. Deux ensembles de SQL sont encore nécessaires pour le développement, l'exploitation et la maintenance. Sous la solution de base de données en temps réel Hudi, nous faisons référence à la solution de correction hors ligne.

La réexécution de la partition historique utilise Flink Batch Overwrite, ce qui est cohérent avec la méthode de réparation hors ligne.

Pour réexécuter la partition actuelle, nous utilisons la méthode Flink Stream Overwrite. Par exemple, les données de partition actuelles doivent être effacées et supprimées, puis écrites. Parce qu'il est écrit sans index, il n'y a aucun moyen d'écraser les données précédemment écrites sous forme de mise à jour. Nous étendons le catalogue Hudi pour prendre en charge Flink SQL, et l'opération de suppression de partition de table supprime les partitions et les données. Ensuite, Flink Stream Overwrite est implémenté par écriture en streaming.

Lorsque l'outil prend en charge les tâches de réexécution en cascade, nous pouvons réparer du niveau ODS le plus source jusqu'à la fin, et nous n'avons plus besoin de développer et de maintenir les tâches de réparation Spark T-1. Vraiment obtenu l'effet de l'intégration par lots de flux.

Optimisation des infrastructures

En termes d’optimisation des infrastructures, nous optimisons le Service à Table. Étant donné que les tâches telles que le compactage et le clustering consomment plus de ressources et interagissent avec les tâches d'écriture, les performances d'écriture sont dégradées. Nous résolvons ce problème en divisant le service de table et en l'exécutant via des ressources indépendantes.

Nous mettons le processus de génération du plan d'exécution du plan de compactage et du plan de clustering dans la tâche d'écriture, et exécuterons réellement le processus indépendant de la tâche de compactage et de clustering. Il évite l'interaction entre l'écriture et le service de table et améliore les performances d'écriture. Dans le même temps, il prend en charge la stratégie d'ajustement dynamique du plan de compactage et réduit les E/S inutiles en ajustant la fréquence.

Hudi Manager est utilisé pour la gestion et l'hébergement à grande échelle, y compris l'hébergement de services de table, tels que le compactage, le clustering, l'hébergement de tâches de projection, le fonctionnement indépendant, l'isolation des ressources et une stabilité d'écriture améliorée. Prend en charge l'extraction automatique, peut être batch ou flux.

En termes de gestion des tables, les données sources de Hudi sont construites lors de la construction de la table, remplaçant les données sources construites lors de la première écriture, afin d'éviter l'omission de paramètres importants. Par exemple, lors de l'importation de données par lots dans Hudi, vous ne vous souciez pas du champ de comparaison preCombine et les métadonnées de la table sont initialisées. Lors des écritures en streaming, les métadonnées de la table ne sont pas modifiées. L'absence de ce champ correspondant entraînera l'impossibilité d'obtenir le résultat fusionné correct.

En termes de configuration des politiques, lorsque l'utilisateur sélectionne les scénarios OLAP et ETL, l'intervalle d'exécution des différents services de table peut être automatiquement configuré. Par exemple, le scénario ETL en aval est une planification au niveau journalier. Par rapport aux scénarios OLAP, nous pouvons utiliser une fréquence de compactage plus faible.

Comme le montre la figure ci-dessus, au cours du processus d'utilisation réelle, nous avons découvert et résolu de nombreux problèmes de qualité, de stabilité et de performances des données, et apporté des améliorations fonctionnelles pour contribuer à la communauté. Couvre plusieurs aspects tels que le récepteur, le compactage, le clustering, le package commun, la source, le catalogue, etc. Certaines des capacités mentionnées dans les scénarios précédents seront transmises à la communauté sous forme de PR ou de RFC l'une après l'autre.

Résumé et perspectives

Nous avons effectué une série de pratiques concernant le flux de données dans le lac, les données de base de données dans la scène du lac, la scène de rapport et l'intégration de lots de flux.

Ensuite, nous approfondirons le domaine des entrepôts de données, explorerons la réduction de la stratification des entrepôts de données grâce à des tâches matérialisées et effectuerons une stratification intelligente grâce à l'analyse, au diagnostic et à l'optimisation des tâches stratifiées. Rendre les étudiants en commerce plus concentrés sur l'utilisation des données, réduire la charge de travail de la superposition des entrepôts de données et évoluer vers l'intégration du lac et de l'entrepôt. Améliorez le calcul incrémentiel, prenez en charge Join ETL autour de Hudi et optimisez la logique Join au niveau de la couche de stockage. Explorez l'utilisation de Hudi dans le domaine de l'IA.

En termes de noyau, nous améliorerons Hudi Meta Store à l'avenir pour unifier la gestion des métadonnées, améliorer le service de table et améliorer la capacité d'épissage des colonnes de Hudi Join.

Si cet article vous est utile, n'oubliez pas de « J'aime », « J'aime » et « Favoris » trois fois !