[Big Data] Data Lake : la tendance de développement du Big Data de nouvelle génération

1. Contexte de la technologie des lacs de données

Les grandes sociétés Internet nationales génèrent chaque jour des dizaines, des centaines de téraoctets, voire plusieurs pétaoctets de données brutes. Ces entreprises utilisent généralement des composants Big Data open source pour créer des plateformes Big Data. La plateforme Big Data est passée par trois étapes : la plateforme de données hors ligne représentée par Hadoop , la plateforme d'architecture Lambda et la plateforme d'architecture Kappa .

Le lac de données peut être considéré comme la dernière génération de plate-forme technologique Big Data. Afin de mieux comprendre l'architecture de base du lac de données, examinons le processus d'évolution de la plate-forme Big Data pour comprendre pourquoi nous avons besoin d'apprendre les données. technologie du lac.

1.1 Plateforme Big Data hors ligne (première génération)

La première étape : les composants de traitement de données hors ligne représentés par Hadoop . Hadoop est un composant de base pour le traitement des données par lots avec HDFS comme stockage principal et MapReduce comme modèle informatique de base. Autour de HDFS et MR, afin d'améliorer continuellement les capacités de traitement des données de la plateforme big data, une série de composants big data sont nés, comme HBase pour les opérations KV en temps réel, Hive pour SQL, Pig pour le workflow, etc. Dans le même temps, alors que les exigences de performance de chacun pour le traitement par lots sont de plus en plus élevées, de nouveaux modèles informatiques sont constamment proposés et des moteurs informatiques tels que Tez, Spark et Presto ont été produits, et le modèle MR a progressivement évolué vers un Modèle DAG.

Afin de réduire l'opération d'écriture des résultats intermédiaires dans le processus de traitement des données, les moteurs informatiques tels que Spark et Presto utilisent autant que possible la mémoire des nœuds informatiques pour mettre en cache les données, améliorant ainsi l'efficacité de l'ensemble du processus de données et le débit du système.

1.2Architecture Lambda

Avec l'évolution continue des capacités et des exigences de traitement des données, de plus en plus d'utilisateurs constatent que, quelle que soit la façon dont le mode de traitement par lots améliore les performances, il ne peut pas répondre aux scénarios de traitement avec des exigences élevées en temps réel. , comme Storm, Spark Streaming, Flink, etc.

Cependant, à mesure que de plus en plus d'applications sont mises en ligne, tout le monde découvre que le traitement par lots et le traitement de flux peuvent être utilisés ensemble pour répondre aux besoins de la plupart des applications. Pour les scénarios avec des exigences élevées en temps réel, une plate-forme de traitement de flux en temps réel sera construite en utilisant cette méthode.Pour Flink + Kafkarépondre aux besoins en temps réel des utilisateurs. L'architecture Lambda a donc été proposée, comme le montre la figure ci-dessous.

Le concept central de l'architecture Lambda est la séparation des flux et des lots . Comme le montre la figure ci-dessus, l'ensemble du flux de données circule de gauche à droite dans la plateforme. Après être entré dans la plate-forme, elle est divisée en deux parties, une partie adopte le mode de traitement par lots et l'autre partie adopte le mode informatique en streaming. Quel que soit le mode de calcul, le résultat final du traitement est fourni à l'application via la couche de service pour garantir la cohérence des accès.

Ce type d'architecture de données contient de nombreux composants Big Data, ce qui augmente considérablement la complexité et le coût de maintenance de l'architecture globale.

1.3 Points faibles de l'architecture Lambda

Après des années de développement, l'architecture Lambda est relativement stable et peut répondre aux scénarios d'application du passé. Mais il présente de nombreuses faiblesses fatales :

• Coût élevé de la gouvernance des données : Le processus informatique en temps réel ne peut pas réutiliser le système de lignage et de gestion de la qualité des données de l'entrepôt de données hors ligne. Il est nécessaire de réimplémenter un système de traçabilité et de gestion de la qualité des données pour l’informatique en temps réel.
• Coûts de développement et de maintenance élevés : il est nécessaire de maintenir simultanément deux ensembles de systèmes d'entrepôt de données hors ligne et en temps réel, et le même ensemble de logique informatique doit stocker deux ensembles de données. Par exemple, pour mettre à jour une ou plusieurs données originales, il est nécessaire de réexécuter l'entrepôt de données hors ligne, et le coût de mise à jour des données est très élevé.
• Calibre de données incohérent : étant donné que les calculs hors ligne et en temps réel utilisent deux codes complètement différents, en raison de l'arrivée retardée des données et de la durée d'exécution différente des deux types de codes, les résultats des calculs sont incohérents.

Alors, existe-t-il une architecture qui puisse résoudre le problème de l’architecture Lambda ?

1.4 Architecture Kappa

Le lien de traitement « séparation flux-batch » de l'architecture Lambda augmente la complexité de la recherche et du développement. C’est pourquoi certains se demandent s’il est possible d’utiliser un seul système pour résoudre tous les problèmes. À l’heure actuelle, la méthode la plus populaire consiste à le faire sur la base du flow computing. Ensuite, introduisons l'architecture Kappa, en Flink + Kafkaconnectant l'ensemble du lien en série. L'architecture Kappa résout les problèmes liés aux moteurs informatiques incohérents entre la couche de traitement hors ligne et la couche de traitement en temps réel dans l'architecture Lambda, aux coûts élevés de développement, d'exploitation et de maintenance et aux résultats informatiques incohérents.

Le schéma de l'architecture Kappa est également appelé schéma d'intégration flux-batch . Nous l'empruntons Flink + Kafkapour créer un scénario d'intégration flux-batch, mais si nous devons effectuer une analyse plus approfondie des données de la couche ODS, nous devons accéder au moteur informatique Flink pour écrire les données dans Kafka au niveau de la couche DWD, et également écrire une partie de les données de résultat à Kafka au niveau de la couche DWS. L'architecture Kappa n'est pas parfaite, elle présente également de nombreux problèmes.

1.5 Points faibles de l'architecture Kappa

• Faible capacité de retour en arrière des données : Kafka a une faible capacité à prendre en charge une analyse de demande complexe. Face à une analyse de données plus complexe, il est nécessaire d'écrire les données des couches DWD et DWS dans ClickHouse, ES, MySQL ou Hive pour une analyse plus approfondie. Cela apporte sans aucun doute complexité du lien. Le plus gros problème est que lors du backtracking des données, la capacité de backtracking des données est très faible en raison de la complexité du lien.
• Faible capacité d'analyse OLAP : Puisque Kafka est un système de stockage séquentiel, il n'y a aucun moyen pour le système de stockage séquentiel d'effectuer directement une analyse OLAP dessus. Par exemple, les stratégies d'optimisation telles que le pushdown de prédicat sont relativement difficiles à mettre en œuvre sur la plate-forme de stockage séquentiel ( Kafka). Des choses difficiles.
• La synchronisation des données est remise en question : l'architecture Kappa dépend fortement des files d'attente de messages. Nous savons que la précision des files d'attente de messages dépend strictement de l'ordre de ses données en amont. Cependant, plus il y a de couches de données dans les files d'attente de messages, plus il est probable qu'elles doivent être hors service. Habituellement, les données de la couche ODS sont absolument exactes. Lorsque les données de la couche ODS sont écrites dans la couche DWD après le calcul, elles seront dans le désordre. DWD vers DWS est plus susceptible d'être dans le désordre. Ce type de le problème d’incohérence des données est très grave.

1.6 Résumé des points faibles de l'architecture Big Data

De l'architecture Hadoop traditionnelle à l'architecture Lambda, et de l'architecture Lambda à l'architecture Kappa, l'évolution de l'infrastructure des plateformes Big Data inclut progressivement toutes sortes de capacités de traitement de données requises par les applications, mais ces plateformes présentent encore de nombreux problèmes.

Existe-t-il une technologie de stockage qui peut non seulement prendre en charge un retour en arrière efficace des données, prendre en charge la mise à jour des données, mais également réaliser une lecture et une écriture par lots de données, et peut également réaliser un accès aux données au niveau de quelques minutes à quelques secondes ?

1.7 Exigences de construction d’un entrepôt de données en temps réel

Il s’agit également d’un besoin urgent de construction d’entrepôts de données en temps réel. En fait, certains problèmes rencontrés dans l'architecture Kappa peuvent être résolus en mettant à niveau l'architecture Kappa. Ensuite, nous partagerons principalement la technologie actuelle des lacs de données chauds.

Existe-t-il donc une telle architecture qui puisse non seulement répondre aux exigences en temps réel, mais également répondre aux exigences de l'informatique hors ligne, et peut également réduire les coûts de développement, d'exploitation et de maintenance, et résoudre les problèmes rencontrés dans l'architecture Kappa construite par file d'attente de messages ? La réponse est oui, ce qui sera discuté en détail plus loin dans l’article.

2. Le lac de données aide à résoudre les problèmes de l'entrepôt de données

2.1 Amélioration continue du concept de lac de données

Un lac de données est un référentiel centralisé pouvant stocker des données structurées et non structurées. Les données commerciales peuvent être stockées telles quelles (sans les structurer au préalable) et exécuter différents types d'analyses, des tableaux de bord et visualisations au traitement du Big Data, en passant par l'analyse en temps réel et l'apprentissage automatique pour guider une meilleure prise de décision.

2.1.1 Stockage des données originales

• Le lac de données doit disposer d’une capacité de stockage suffisante pour stocker toutes les données de l’entreprise.
• Les lacs de données peuvent stocker différents types de données, notamment des données structurées, semi-structurées (XML, Json, etc.) et non structurées (images, vidéos, audios).
• Les données du lac de données sont une copie complète des données métier d'origine, et ces données conservent leur apparence d'origine dans le système métier.

2.1.2 Fonction de stockage sous-jacente flexible

En utilisation réelle, les données du lac de données ne sont généralement pas fréquemment consultées. Afin d'obtenir un rapport coût-performance acceptable, un moteur de stockage rentable est généralement sélectionné pour la construction du lac de données.

• Fournissez un stockage à très grande échelle pour le Big Data, ainsi que des capacités évolutives de traitement de données à grande échelle.
• S3Les plates-formes de stockage distribuées telles que // peuvent OSSêtre utilisées HDFScomme moteurs de stockage.
• Prend en charge les formats de structure de données tels que Parquet, Avro et ORC.
• Peut fournir une fonction d'accélération du cache de données.

2.1.3 Moteur de calcul riche

Du calcul par lots de données à l'informatique en streaming, en passant par l'analyse de requêtes interactives et l'apprentissage automatique, tous les types de moteurs informatiques appartiennent à la catégorie que les lacs de données devraient couvrir. Grâce à la combinaison des technologies du Big Data et de l'intelligence artificielle, divers algorithmes d'apprentissage automatique/d'apprentissage profond ont été continuellement introduits.Par exemple, le framework TensorFlow/ PyTorcha pris en charge la lecture d'échantillons de données de S3/ OSS/ pour la formation en apprentissage automatique. HDFSPar conséquent, pour un projet de lac de données qualifié, la possibilité de brancher les moteurs de calcul et de stockage est une capacité de base que les lacs de données doivent posséder.

2.1.4 Une gestion parfaite des données

• Les lacs de données doivent disposer de capacités complètes de gestion des métadonnées . Y compris la source de données, le format des données, les informations de connexion, le schéma de données, la gestion des autorités et d'autres fonctionnalités.
• Les lacs de données doivent disposer de capacités complètes de gestion du cycle de vie des données . Non seulement les données originales peuvent être stockées, mais les données de résultats intermédiaires de diverses analyses et traitements doivent également pouvoir être sauvegardées, et le processus d'analyse et de traitement des données peut être complètement enregistré pour aider les utilisateurs à retracer le processus de génération de tout morceau de données complètement.
• Les lacs de données doivent disposer de capacités complètes d'acquisition et de diffusion de données . Le lac de données doit être capable de prendre en charge diverses sources de données, d'obtenir des données complètes/incrémentielles à partir de sources de données associées, puis de standardiser le stockage. Les lacs de données peuvent transmettre les données vers les moteurs de stockage appropriés pour répondre aux différentes exigences d'accès aux applications.

2.2 Architecture du lac de données open source

L'architecture LakeHouse est devenue la tendance la plus en vogue dans l'évolution de l'architecture actuelle. Elle permet d'accéder directement au système de gestion des données stockées, qui combine les principaux avantages de l'entrepôt de données. LakeHouse est construit sur la base d'une architecture de séparation stockage-informatique . Le plus gros problème avec la séparation du stockage et de l'informatique réside dans le réseau , en particulier pour les entrepôts de données avec accès à haute fréquence, les performances du réseau sont cruciales. Il existe de nombreuses options pour implémenter Lakehouse, telles que Delta, Hudi, Iceberg. Bien que l'objectif des trois soit différent, ils ont tous les fonctions générales d'un lac de données, telles que : la gestion unifiée des métadonnées, la prise en charge de plusieurs moteurs de calcul et d'analyse, ainsi que la prise en charge de l'analyse de haut niveau et de la séparation du calcul et du stockage.

Alors, à quoi ressemble généralement une architecture de lac de données open source ? Ici, j'ai dessiné un diagramme d'architecture, qui est principalement divisé en quatre couches :

2.2.1 Système de fichiers distribué

La première couche est le système de fichiers distribué. Pour les utilisateurs qui choisissent la technologie cloud, ils choisissent généralement S3 et Alibaba Cloud pour stocker les données ; les utilisateurs qui aiment la technologie open source utilisent généralement leur propre HDFS pour stocker les données.

2.2.2 Couche d'accélération des données

La deuxième couche est la couche d'accélération des données. L'architecture du lac de données est une architecture typique de séparation de stockage et de calcul, et la perte de performances de lecture et d'écriture à distance est très importante. Notre pratique courante consiste à mettre en cache les données fréquemment consultées (données chaudes) localement sur le nœud informatique, afin de réaliser la séparation des données chaudes et froides . L’avantage de cette méthode est d’améliorer les performances de lecture et d’écriture des données et d’économiser la bande passante du réseau. Nous pouvons choisir l'open source Alluxioou Alibaba Cloud Jindofs.

2.2.3 Couche de format de tableau

La troisième couche est la couche de format Table, qui encapsule les fichiers de données dans des tables ayant des significations commerciales, et les données elles-mêmes fournissent une sémantique au niveau de la table telle que ACID, Snapshot, schema, etc. partitionCette couche peut choisir l'un des trois mousquetaires des lacs de données open source Delta. , , sont une technologie permettant de créer des lacs de données, ce ne sont pas eux-mêmes des lacs de données .HudiIcebergDeltaHudiIceberg

2.2.4 Moteur de calcul

La quatrième couche est constituée de divers moteurs de calcul de données. Y compris Spark, Flink, Hive, Presto, etc., ces moteurs informatiques peuvent tous accéder à la même table dans le lac de données.

3. Comparaison des concepts de lac de données et d'entrepôt de données

3.1 Comparaison entre lac de données et entrepôt de données

Laissez-moi vous parler de l'essence du lac de données tel que je le comprends. Si vous ne comprenez pas l'essence d'une nouvelle chose, il vous sera difficile de la contrôler. L'image ci-dessous montre tout.

Après avoir compris le concept de lac de données, nous devons clarifier davantage les caractéristiques de base qu'un lac de données doit avoir, en particulier les caractéristiques d'un lac de données par rapport à un entrepôt de données. Référons-nous au tableau de comparaison officiel de la comparaison de l'entrepôt de données AWS et du lac de données.

Chaque entreprise a besoin d'un entrepôt de données et d'un lac de données, car ils répondent à des besoins et à des cas d'utilisation différents :

• Un entrepôt de données est une base de données optimisée pour analyser les données relationnelles des systèmes transactionnels et des systèmes d'applications métier. Définissez la structure des données et le schéma à l'avance pour fournir une requête SQL rapide. Les données brutes subissent une série de transformations ETL pour fournir aux utilisateurs un « résultat de données unique » fiable.
• Un lac de données est différent car il stocke non seulement les données relationnelles provenant des systèmes d'applications métier, mais également les données non relationnelles provenant des applications mobiles, des appareils IoT et des médias sociaux. Lors de la capture de données, il n'est pas nécessaire de définir à l'avance une structure de données ou un schéma. Cela signifie que les lacs de données peuvent stocker tous les types de données sans structures de données élaborées. Différents types d'analyses (telles que les requêtes SQL, l'analyse du Big Data, la recherche en texte intégral, l'analyse en temps réel et l'apprentissage automatique) peuvent être utilisées sur les données.

caractéristique	base de données	lac de données
données	Données relationnelles provenant de systèmes transactionnels, de bases de données opérationnelles et d'applications métiers	Données non relationnelles et relationnelles provenant d'appareils IoT, de sites Web, d'applications mobiles, de réseaux sociaux et d'applications d'entreprise
Schéma	Conception avant la mise en œuvre de l'entrepôt de données (schéma écrit)	Écrire au moment de l'analyse (lire le schéma)
le rapport qualité prix	Des résultats de requête plus rapides entraînent des coûts de stockage plus élevés	Des résultats de requête plus rapides nécessitent des coûts de stockage inférieurs
qualité des données	Des données hautement réglementées pouvant servir de base à des faits importants	Toutes les données qui peuvent ou non être réglementées (telles que les données brutes)
utilisateur	analyste d'affaires	Data scientists, développeurs de données et analystes commerciaux (utilisant des données réglementaires)
analyser	Reporting par lots, BI et visualisation	Apprentissage automatique, analyse prédictive, découverte de données et analyse

Le tableau ci-dessus présente les différences entre les lacs de données et les entrepôts de données traditionnels. Ensuite, nous analyserons plus en détail les caractéristiques des lacs de données des deux niveaux de stockage de données et d'informatique.

3.2 Mode écriture et mode lecture

3.2.1 Mode écriture

La logique cachée derrière le « schéma d'écriture » de l'entrepôt de données est qu'avant que les données ne soient écrites, le schéma des données doit être confirmé, puis les données sont importées. L'avantage est que l'entreprise et les données peuvent être bien ;combiné

3.2.2 Mode lecture

Le lac de données met l'accent sur un « schéma lisible », et la logique sous-jacente est que l'incertitude des entreprises est normale : puisque nous ne pouvons pas prédire l'évolution et les changements de l'entreprise, nous maintenons alors un certain degré de flexibilité. Différer la conception structurelle, afin que l'ensemble de l'infrastructure ait la capacité d'adapter les données à l'entreprise « à la demande ». Par conséquent, les lacs de données sont plus adaptés au développement et aux entreprises innovantes.

3.3 Processus de développement de l'entrepôt de données

Le lac de données adopte un « mode de lecture du temps » flexible et rapide.Dans la vague de transformation numérique, il aide vraiment les entreprises à achever leur transformation technologique, à compléter la précipitation des données et à faire face aux problèmes sans fin de demande de données liés au développement rapide des entreprises.

3.4 Schéma d'architecture du lac de données

Le lac de données peut être considéré comme une nouvelle génération d’infrastructure Big Data. Dans cette architecture, qu'il s'agisse de traitement de flux de données ou de traitement par lots, le stockage des données est unifié Icebergsur . De toute évidence, cette architecture peut résoudre les problèmes de l’architecture Lambda et de l’architecture Kappa :

3.4.1 Résoudre le problème de la petite quantité de données stockées dans Kafka

À l'heure actuelle, l'idée de base de tous les lacs de données est un système de gestion de fichiers basé sur HDFS, le volume de données peut donc être très important.

3.4.2 Prise en charge des requêtes OLAP

De même, le lac de données est implémenté sur la base de HDFS. Seul le moteur de requête OLAP actuel nécessite quelques adaptations pour effectuer des requêtes OLAP sur les données de la couche intermédiaire.

3.4.3 Intégration de la gouvernance des données

Une fois les données du flux par lots stockées sur HDFS, S3 et d'autres supports, le même système de lignée de données et de gestion de la qualité des données peut être réutilisé.

3.4.4 Unification de l'architecture des lots de flux

Par rapport à l'architecture Lambda, l'architecture du lac de données dispose d'un schéma et d'une logique de traitement des données unifiés, et les utilisateurs n'ont plus besoin de conserver deux copies des données.

3.4.5 Statistiques de données cohérentes

Grâce à l’adoption d’un système de calcul et de stockage intégré unifié par flux et par lots, la cohérence des données est garantie.

3.5 Quel est le meilleur

On ne peut pas dire que les lacs de données et les entrepôts de données sont meilleurs ou pires. Chacun a ses mérites et peut se compléter les uns les autres. Laissez-moi vous faire un dessin ici pour votre compréhension :

• Les métadonnées du lac et de l'entrepôt sont parfaitement connectées et se complètent. Le modèle de l'entrepôt de données est renvoyé au lac de données (devenant une partie des données d'origine) et l'application structurée du lac est déposée dans les données. entrepôt.
• Développement unifié des lacs et des entrepôts, les données stockées dans différents systèmes peuvent être gérées uniformément via la plateforme.
• Pour les données du lac de données et de l'entrepôt de données, en fonction des besoins du développement commercial, il est déterminé quelles données sont stockées dans l'entrepôt de données et quelles données sont stockées dans le lac de données, formant ainsi l'intégration du lac et du entrepôt.
• Les données sont dans le lac, le modèle est dans l'entrepôt et la transformation est répétée.

4. Le lac de données permet de mettre à niveau l'architecture de l'entrepôt de données

4.1 L'objectif de la construction d'un lac de données

Data Lake Technology Icebergprend actuellement en charge trois formats de fichiers : Parquet, Avro, ORC. Comme le montre la figure ci-dessous, Icebergles capacités qu'il possède sont résumées comme suit : ces capacités sont cruciales pour construire l'intégration des lacs et des entrepôts.

• La couche de stockage de données adopte un modèle de stockage de données standard et unifié.
• Construisez une construction de données en temps quasi réel T + 1pour garantir l’actualité des données.
• La traçabilité des données est plus pratique et les coûts d’exploitation et de maintenance sont inférieurs.

4.2 Accès aux données en temps quasi réel

La technologie des lacs de données Icebergprend non seulement en charge la séparation lecture-écriture, mais prend également en charge la lecture simultanée, la lecture incrémentielle, la fusion de petits fichiers et peut également prendre en charge les délais du deuxième niveau à la minute. Sur la base de ces avantages, nous essayons d'utiliser ces fonctions pour créer un lien complet en temps réel basé sur Icebergl'architecture d'entrepôt de données Flink Real-time avec intégration de flux par lots.

Comme le montre la figure ci-dessous, Icebergchaque commitopération modifie la visibilité des données, par exemple en changeant les données d'invisibles à visibles. Au cours de ce processus, un enregistrement de données en temps quasi réel peut être réalisé.

4.3 Entrepôt de données en temps réel - système d'analyse de lac de données

Lors de la création d'un entrepôt de données hors ligne, les opérations d'accès aux données doivent d'abord être effectuées, comme l'extraction régulière des données avec le système de planification hors ligne, puis après une série d'opérations ETL, et enfin l'écriture des données dans la table Hive. est relativement grande. Par conséquent, avec l'aide de la structure de table d'Iceberg, Flink ou Spark Streaming peuvent être utilisés pour obtenir un accès aux données en temps quasi réel afin de réduire la latence des données.

Sur la base des fonctions ci-dessus, passons en revue l'architecture Kappa discutée ci-dessus. Nous connaissons déjà les points faibles de l'architecture Kappa. Étant donné qu'Iceberg peut être utilisé comme un excellent format de table, il peut également prendre en charge Streaming Reader et Streaming Sink. Alors, est-il possible d’envisager de remplacer Kafka par Iceberg ?

Le stockage sous-jacent d'Iceberg est un stockage bon marché comme HDFS ou S3 et prend en charge des structures de stockage telles que Parquet, ORC et Avro. L'analyse OLAP peut être effectuée sur les données de résultat de la couche intermédiaire. Basé sur la fonction Streaming Reader d'Iceberg Snapshot, il peut réduire considérablement le délai des tâches hors ligne du niveau jour au niveau horaire et le transformer en un système d'analyse de lac de données en temps quasi réel.

Dans la couche de traitement intermédiaire, vous pouvez utiliser Presto pour effectuer quelques requêtes SQL simples. Comme Iceberg prend en charge la lecture en continu, vous pouvez également accéder directement à Flink dans la couche intermédiaire du système et utiliser Flink directement dans la couche intermédiaire pour effectuer un traitement par lots. ou des tâches informatiques en streaming. , sortez le résultat intermédiaire vers l'aval après un calcul plus approfondi.

4.4 Avantages et inconvénients d'Iceberg remplaçant Kafka

En général, les avantages d'Iceberg remplaçant Kafka comprennent principalement :

• Réaliser l'unification flux-batch au niveau de la couche de stockage
• La couche intermédiaire prend en charge l'analyse OLAP
• Un support parfait pour un backtracking efficace
• réduction des coûts de stockage

Bien entendu, il existe certaines lacunes, telles que :

• La latence des données passe du temps réel au temps quasi réel
• L'interfaçage avec d'autres systèmes de données nécessite un travail de développement supplémentaire

4.5 Résoudre le problème de synchronisation des données MySQL via Flink CDC

Iceberg fournit un format de table de stockage de lac de données unifié et prend en charge plusieurs moteurs de calcul (notamment Spark, Presto, Hive) pour l'analyse des données ; il peut générer des fichiers de données purement en colonnes, et les fichiers en colonnes sont très adaptés aux opérations OLAP ; Iceberg est basé sur The Snapshot. le mode conception prend en charge la lecture incrémentielle des données ; l'interface Iceberg présente un degré élevé d'abstraction et une bonne compatibilité, et est indépendante à la fois du moteur informatique de niveau supérieur et du moteur de stockage de niveau inférieur, ce qui permet aux utilisateurs de définir facilement leur propre logique métier.

Téléchargez les données avec le drapeau CDC directement appendsur Iceberg et, au mergemoment de , effectuez une comparaison unique de ces données incrémentielles avec la quantité totale des dernières données conformément à un certain format organisationnel et à une certaine méthode de calcul efficace merge. L'avantage est qu'il prend en charge l'importation et la lecture des données en temps réel ; le Flink SQL de cette solution informatique prend en charge nativement l'ingestion CDC et ne nécessite pas de conception de domaine métier supplémentaire.

5. Perspectives de développement de la technologie des lacs de données

Les lacs de données pourraient être le point positif de la prochaine révolution technologique du Big Data. Nous devons saisir l'opportunité, saisir l'opportunité et en apprendre davantage sur les lacs de données. Mais ma suggestion est toujours "apprendre sans utiliser", pourquoi dis-tu ça ? Exemple : en $Début\; 2018$ , nous avons lancé Flink en essaim, puis mis à jour la version chaque mois. C'est juste un emmerdeur. Par conséquent, nous attendons que les grandes sociétés Internet comblent les trous, puis nous lancerons directement le lac de données de manière courte, plate et rapide, mais nous devons apprendre.

6. Résumé

Grâce à cet article, nous avons une compréhension de base de ce qu'est un lac de données, pourquoi nous devons apprendre un lac de données et quels problèmes pratiques il peut résoudre. Plus tard, nous continuerons à nous concentrer sur les raisons pour lesquelles Iceberg a été choisi comme solution de lac de données.