Introduction : le nouveau type de table Transaction Table2.0 de MaxCompute (ci-après dénommé Transaction Table 2.0) sera disponible pour des tests le 27 juin 2023. Il prend en charge les solutions informatiques et de stockage de données en temps quasi réel basées sur Transaction Table 2.0.
Auteur : Shi Yuyang , ingénieur principal en recherche et développement de données chez Renjia
Présentation de l'entreprise
Renrenjia est une société Internet investie et créée conjointement par Alibaba Dingding et Renrenwo pour aider les clients à entrer dans la numérisation des ressources humaines et à s'appuyer sur l'innovation en matière de produits et de technologies pour piloter leurs stratégies. La société fournit principalement des services SaaS de ressources humaines, notamment la gestion du personnel, la gestion des salaires, la gestion de la sécurité sociale et des services à valeur ajoutée, accélérant l'autonomisation du domaine des ressources humaines et réalisant de nouvelles façons de travailler dans les ressources humaines. Actuellement, elle a servi des clients dans plusieurs secteurs du commerce électronique, des services de vente au détail et d'autres domaines.
Renrenjia est une start-up typique. Elle se trouve actuellement dans un environnement de marché hautement compétitif. La société propose plusieurs produits et les données de chaque produit sont indépendantes. Dans le même temps, afin de répondre aux besoins internes en matière de données CRM et de mieux intégrer les données, car il s'agit d'un défi de taille pour l'équipe de l'entrepôt de données, qui nécessite stabilité, précision et réponse rapide. L'équipe de l'entrepôt de données doit non seulement répondre aux besoins internes en matière de données, mais également optimiser les coûts informatiques.
Points faibles des entreprises
Lors de l'utilisation du service de calcul de mégadonnées MaxCompute d'Alibaba Cloud, il a été constaté qu'à mesure que les données boursières augmentent, le coût de la déduplication incrémentielle des données devient de plus en plus important.Une analyse spécifique a révélé les quatre raisons suivantes.
Les données incrémentielles sont de petite ampleur
Bien que l'entreprise propose plusieurs produits, la quantité de nouvelles données utilisateur et de modifications historiques chaque jour est à une échelle plus petite (Mo) par rapport à l'échelle de toutes les données historiques (Go).
Calcul secondaire des données historiques
Pour la déduplication incrémentielle des données, nous utilisons les données historiques complètes d'hier + les nouvelles données d'aujourd'hui pour effectuer des calculs de déduplication de fenêtre chaque jour. Cependant, la quantité de données qui doivent être mises à jour pour les données historiques complètes est en réalité très faible et les données historiques doivent être retiré à chaque fois pour la déduplication des fenêtres.Calcul, il s'agit sans aucun doute d'un coût de calcul relativement important.
Le fenêtrage pour supprimer les doublons est coûteux en calcul
L'utilisation de la fonction row_number pour ouvrir Windows afin de dédupliquer et d'obtenir les dernières données de la clé primaire de l'entreprise nécessite de combiner les données historiques d'hier + les données d'aujourd'hui. La table utilisateur a une taille de centaines de millions. Cependant, afin d'économiser les coûts de stockage et de modélisation ultérieure Pour les opérations de déduplication des données, cette partie du coût est assez importante, en fait, la plupart des données historiques n'ont pas été mises à jour et n'ont essentiellement pas besoin d'être impliquées à nouveau dans le traitement des calculs. Le coût estimé d'une seule instruction SQL pour dédoublonner les tables utilisateur une fois par jour, cela coûte 4,63 yuans (paiement au fur et à mesure).
Le coût du retrait du montant total est élevé
Si les données de la base de données d'entreprise sont extraites intégralement chaque jour, la quantité de données atteindra des centaines de millions, mais en fait, la quantité de données mises à jour est faible, ce qui exercera une grande pression sur la base de données commerciale et affectera sérieusement la performances de la base de données commerciale.
Amélioration de la déduplication des données de Transaction Table2.0
Le nouveau type de table Transaction Table2.0 de MaxCompute (ci-après dénommé Transaction Table 2.0) sera disponible pour des tests le 27 juin 2023. MaxCompute prend en charge les solutions informatiques et de stockage de données en temps quasi réel basées sur Transaction Table 2.0. L'équipe R&D de l'entrepôt de données des ressources humaines a immédiatement commencé à comprendre ses caractéristiques et ses fonctions. L'équipe de l'entrepôt de données des ressources humaines a découvert que son modèle de clé primaire caractéristique pouvait être utilisé pour dédupliquer les données et réduire les coûts de calcul du fenêtrage. Les principales méthodes de mise en œuvre sont les suivantes.
- Les informations de base incrémentielles quotidiennes de l'utilisateur sont ouvertes et dupliquées ;
- La clé primaire de la table de clé primaire ne pouvant pas être vide, il est nécessaire de filtrer les données dont la clé primaire métier est vide ;
- Insérez directement les données incrémentielles quotidiennes fenêtrées et les données dédupliquées dans la table de clé primaire, et le système effectuera automatiquement des calculs de déduplication basés sur la clé primaire de l'entreprise.
Mesures pratiques spécifiques pour améliorer
Comparaison globale
| Temps d'exécution SQL de déduplication (unités) | Coût estimé de la déduplication SQL (unité yuan) | |
|---|---|---|
| Montre ordinaire | 151 | 4,63 |
| Tableau des transactions2.0 | 72 | 0,06 |
Comparaison des coûts et des temps de calcul
1. Créez des instructions de table et insérez des instructions de mise à jour
déclaration de mise à jour
2. Coût et calcul
Coût estimé de l’opération de déduplication de la table de partition :
Le coût estimé ne peut pas être utilisé comme norme de facturation réelle et est uniquement à titre de référence. Veuillez vous référer à la facture pour le coût réel.
Coût estimé de l’exécution de la déduplication des tables de clés primaires :
Le coût estimé ne peut pas être utilisé comme norme de facturation réelle et est uniquement à titre de référence. Veuillez vous référer à la facture pour le coût réel.
Temps et ressources de calcul des tables partitionnées
Temps et ressources de calcul de la table de clé primaire de la table de transactions 2.0
Grâce à la comparaison ci-dessus, le coût quotidien du calcul SQL de la table utilisateur est passé de 4,63 yuans à 0,06 yuans, le temps de calcul a été réduit de moitié, le réduire_num a considérablement augmenté, le côté carte a diminué et la quantité de données du côté réduction a considérablement augmenté. .
Fusionner des petits fichiers
Transaction Table 2.0 prend en charge les fonctionnalités d'écriture incrémentielle et de requête de voyage dans le temps en temps quasi réel. Dans les scénarios où les données sont fréquemment écrites, un grand nombre de petits fichiers seront inévitablement introduits. Il est nécessaire de concevoir une stratégie de fusion raisonnable et efficace pour fusionner les petits fichiers. et dédupliquer les données.Il résout l'inefficacité de la lecture et de l'écriture des E/S d'un grand nombre de petits fichiers et soulage la pression sur le système de stockage, mais il doit également éviter une grave amplification d'écriture et des échecs de conflit causés par un compactage fréquent.
Il existe actuellement deux méthodes principales de fusion de données :
- Clustering : fusionnez simplement le DeltaFile du Commit dans un fichier volumineux sans modifier le contenu des données. Le système sera exécuté périodiquement en fonction de facteurs tels que la taille des fichiers nouvellement ajoutés et le nombre de fichiers, et ne nécessite aucune opération manuelle de la part de l'utilisateur. Résout principalement les problèmes d'efficacité et de stabilité de lecture et d'écriture des petits fichiers IO.
- Compactage : Tous les fichiers de données seront fusionnés selon une certaine stratégie pour générer un lot de nouveaux BaseFiles. Les lignes de données avec le même PK stockent uniquement le dernier statut et ne contiennent aucun statut historique ni aucune information sur les colonnes du système. Par conséquent, BaseFile Il le fait ne prend pas en charge les opérations de voyage dans le temps et est principalement utilisé pour améliorer l'efficacité des requêtes. Il aide les utilisateurs à déclencher activement en fonction de scénarios commerciaux et prend également en charge le déclenchement automatique périodique par le système en définissant les attributs de la table.
En résumé, lorsque des données incrémentielles sont confrontées à la surface de la clé primaire, les petits fichiers ne seront pas fusionnés immédiatement, donc un grand nombre de petits fichiers seront générés. Les petits fichiers occuperont une grande quantité d'espace de stockage et ne seront pas propices aux données. vitesse de requête. Compte tenu de la situation ci-dessus, nous pouvons ajouter de petits fichiers qui fusionnent manuellement la table de clé primaire après l'insertion, ou nous pouvons déclencher automatiquement le mécanisme de compactage en fonction de dimensions telles que la fréquence temporelle, le nombre de validations, etc. propriétés de la table, ou attendez la fusion du clustering par le système. Si les données ne sont mises à jour qu'une fois par jour, il est recommandé d'utiliser le mécanisme de clustering du système.
point important:
Le numéro de fichier et la taille affichés par desc extend table_name incluent les données de la corbeille. Actuellement, il n'existe aucun moyen de les afficher avec précision. Vous pouvez effacer les données de la corbeille ou utiliser le compactage pour observer le numéro de fichier à la fin du journal.
Requête de données temporelles et spatiales et réparation de données historiques
Pour les tables de type table de transactions 2.0, MaxCompute prend en charge l'interrogation d'une certaine heure historique ou d'une certaine version de la table source pour une requête d'instantané historique (requête TimeTravel), et prend également en charge la spécification d'un certain intervalle de temps historique ou d'un intervalle de version de la table source pour une incrémentation historique. requête (requête incrémentielle). Requête), vous devez définir acid.data.retain.hours pour utiliser la requête TimeTravel et la requête incrémentielle.
Requête de voyage dans le temps des données
1. Interrogez toutes les données historiques jusqu'à une heure spécifiée (telle qu'une constante de chaîne au format datetime) en fonction de TimeTravel (paramètre requis)
select * from mf_tt2 timestamp as of '2023-06-26 09:33:00' where dd='01' and hh='01';
Interroger les données historiques et le numéro de version
show history for table mf_tt2 partition(dd='01',hh='01');
Interroger toutes les données historiques jusqu'à la constante de version spécifiée
select * from mf_tt2 version as of 2 where dd='01' and hh='01';
2. Basé sur une requête incrémentielle, historique des données incrémentielles dans l'intervalle de temps spécifié (comme une constante de chaîne au format datetime). La valeur constante doit être configurée en fonction de l'heure de l'opération spécifique.
select * from mf_tt2 timestamp between '2023-06-26 09:31:40' and '2023-06-26 09:32:00' where dd= '01' and hh='01';
Interroger les données incrémentielles historiques de l'intervalle de version spécifié
select * from mf_tt2 version between 2 and 3 where dd ='01' and hh = '01';
Réparation de données
Sur la base de la requête TimeTravel, la quantité totale de données jusqu'à l'heure spécifiée est directement insérée dans une table temporaire, les données de la table de clé primaire de la table de transactions actuelle 2.0 sont effacées et les données de la table temporaire sont insérées dans la clé primaire de la table de transactions actuelle 2.0. tableau.
Choses à noter et projets futurs
Données supprimées dynamiquement et matériellement
Il n'existe aucun moyen de supprimer définitivement les données historiques (cette partie doit s'appuyer sur flink-cdc). Actuellement, cela peut être réalisé par suppression logicielle, ou via une période d'accumulation de données historiques, toutes les données historiques peuvent être filtrées et réinsérées. dans la table de clé primaire dans son ensemble ; une chose à mentionner ici est que flink-cdc+flink-sql prend en charge la suppression matérielle en temps réel des données, mais la tâche flink-cdc d'une seule table est relativement lourde et plusieurs tables nécessitent différentes ID de serveur. Il n'est pas recommandé pour les systèmes d'entreprise qui ont une forte pression de base de données à la source. Dans l'attente de la synchronisation ultérieure de l'intégralité de la base de données cda.
Espace de stockage accru
L'espace de stockage des données du modèle de clé primaire de la table de transactions 2.0 est légèrement plus grand que celui des données après fenêtrage dans la table de partition. La raison principale est que les données après fenêtrage sont réparties plus uniformément et que le taux de compression des données est plus élevé. Cependant, par rapport avec les données quotidiennes de SQL Le coût de calcul ponctuel et le coût quotidien de l'espace de stockage sont à un niveau de coût inférieur (négligeable).
flink-cdc
En coopération avec flink-cdc, il peut réaliser directement une synchronisation des données en temps quasi réel et améliorer la fraîcheur des données.
Synchronisation de toute la base de données
Nous attendons avec impatience l'intégration de la cible de syntaxe Flink cdas de calcul en temps réel d'Alibaba Cloud avec le côté MaxCompute pour réaliser une synchronisation complète de la bibliothèque et des modifications ddl.
vue matérialisée
Cela peut être fait en utilisant la combinaison de vue matérialisée + flink-cdc