Lorsqu'une entreprise a besoin de créer un système d'entrepôt de données indépendant pour prendre en charge les services de BI et d'analyse commerciale, elle dispose d'une architecture hybride de « lac de données + entrepôt de données ». Mais l'architecture hybride entraîne des coûts de construction, des coûts de gestion et des coûts de développement commercial plus élevés. Avec le développement de la technologie Big Data, en ajoutant des transactions distribuées, la gestion des métadonnées, des performances SQL extrêmes, des capacités d'interface SQL et API de données à la couche de lac de données, les entreprises peuvent prendre en charge à la fois les entreprises de lac de données et d'entrepôt de données basées sur une architecture unifiée. l'architecture intégrée de l'entrepôt du lac.
— Introduction à l'architecture intégrée du lac et de l'entrepôt —
Les lacs de données d'entreprise traditionnels sont principalement construits sur la base de Hadoop ou du stockage dans le cloud, offrant des capacités de données semi-structurées et non structurées pour les tâches de science des données et d'apprentissage automatique. La BI d'entreprise et l'analyse commerciale nécessitent une garantie de cohérence stricte dans le processus de traitement des données et d'excellentes performances SQL dans le processus d'analyse, mais Hadoop open source ou le stockage en nuage n'ont pas ces capacités, les entreprises doivent donc créer un système d'entrepôt de données indépendant. Pour prendre en charge ce type de l'entreprise, il existe une architecture hybride de « lac de données + entrepôt de données ». L'architecture hybride entraîne des coûts de construction, de gestion et de développement commercial plus élevés. Avec le développement de la technologie Big Data, en ajoutant des transactions distribuées, la gestion des métadonnées, des performances SQL extrêmes, des capacités d'interface SQL et API de données à la couche de lac de données, les entreprises peuvent prendre en charge à la fois les activités de lac de données et d'entrepôt de données sur la base d'une architecture unifiée. L'industrie et la communauté open source explorent les technologies connexes l'une après l'autre. Transwarp a commencé à développer des technologies connexes basées sur Hadoop en 2014 et a fourni des fonctionnalités telles que les transactions distribuées dans le moteur d'analyse relationnelle Inceptor en 2016. En 2017, les ingénieurs d'Uber ont commencé à développer le projet Apache Hudi. En 2019, Netflix a ouvert le projet Iceberg. En 2020, Databricks a lancé Delta Lake sur son service cloud. La large participation et la promotion vigoureuse de la communauté.
CCID Consulting a souligné dans le "Rapport de recherche sur la technologie intégrée des lacs et des entrepôts" publié en juillet 2022 que les principales caractéristiques clés de l'architecture intégrée des lacs et des entrepôts comprennent :
- Prend en charge l'analyse et l'exploration de données multimodèles, y compris les données structurées, semi-structurées (telles que JSON) et non structurées
- La prise en charge des transactions garantit la cohérence et l'exactitude des opérations de données simultanées.
- Prise en charge de la BI, vous pouvez utiliser les outils de BI directement sur les données source, sans passer par la longue liaison de données compliquée de la modélisation de l'entrepôt de données à l'analyse commerciale de l'amarrage du datamart, et la rapidité de réponse de l'entreprise est élevée.
- Une copie des données est stockée et la gouvernance des données est effectuée directement dans le lac de données, ce qui réduit la puissance de calcul et les coûts de stockage causés par les copies de données et les flux redondants.
- Le stockage et l'informatique sont séparés, le stockage des données est partagé à l'échelle mondiale et mis à l'échelle en fonction des besoins en capacité, tandis que la puissance de calcul peut être adaptée de manière flexible en fonction des besoins informatiques, et l'informatique et le stockage peuvent être étendus indépendamment en fonction de leurs besoins respectifs.
- Ouverture commerciale, prend en charge SQL et API standardisés, et peut prendre en charge de manière flexible divers langages et cadres d'apprentissage automatique.
Le "Rapport de recherche sur la technologie intégrée du lac et de l'entrepôt" a également souligné qu'il existe trois façons de mettre en œuvre l'intégration du lac et de l'entrepôt en termes de voie de réalisation technologique :
La première façon est d'étendre la capacité du lac de données basé sur le système Hadoop à l'entrepôt de données, et de construire directement l'entrepôt de données dans le lac de données, pour éventuellement évoluer vers l'intégration du lac et de l'entrepôt, de sorte que le système d'entrepôt de données peut être construit sur le stockage du lac de données relativement peu coûteux, nécessite une meilleure prise en charge des transactions et des performances SQL. Certaines entreprises étrangères prospères sur le plan numérique, telles qu'Uber, utilisent ces voies techniques, en utilisant de nouveaux formats de stockage tels que Hudi sur Hadoop pour répondre aux besoins commerciaux des entrepôts de données. National Transwarp Technology est le principal promoteur de ce type de technologie.Transwarp Technology a réalisé un support de transaction distribué et des capacités SQL basées sur les formats de fichiers HDFS et ORC en 2015. Par conséquent, les produits Transwarp ont passé des centaines de clients.Pratique de production et polissage, par rapport à le cadre technologique open source, a une maturité relativement bonne et a aidé de nombreux clients à mettre en œuvre l'architecture intégrée de lac et d'entrepôt.
La deuxième voie est basée sur le stockage sur plate-forme cloud ou le stockage d'objets tiers, sur lequel Hadoop ou d'autres technologies développées en interne sont construites pour construire une architecture intégrée lac-entrepôt.Certains fournisseurs de cloud promeuvent cette voie. Cette voie réalise la séparation du stockage et de l'informatique basée sur des services cloud au niveau de la couche de stockage, tandis que des capacités telles que les transactions distribuées et la gestion des métadonnées reposent sur des cadres techniques auto-développés ou sur l'intégration d'Iceberg open source.
La troisième voie consiste à mener une recherche et un développement approfondis basés sur la technologie des bases de données et à prendre en charge plusieurs modèles de données et technologies de séparation stockage-informatique pour répondre aux besoins des lacs de données, représentés par Snowflake et Databricks. Ci-dessous, nous expliquerons les principes de mise en œuvre et les différences entre Apache Hudi, Iceberg, Delta Lake et Starlink Inceptor dans deux articles.
—Apache Hudi—
Hudi est l'abréviation de Hadoop Upserts Delete et Incrementals.Comme son nom l'indique, il s'agit de fournir des capacités de mise à jour, de suppression et de traitement de données incrémentielles sur Hadoop. Hudi est un projet de lac de données conçu par les ingénieurs d'Uber pour répondre aux besoins de son analyse de données interne. Le scénario commercial consiste à synchroniser les données de commande de voyage générées en ligne vers un centre de données unifié, puis à les fournir aux opérateurs de la ville de niveau supérieur. pour analyse et traitement. En 2014, l'architecture du lac de données d'Uber était relativement simple : les journaux d'activité étaient synchronisés avec S3 via Kafka, et la couche supérieure utilisait l'EMR pour l'analyse des données ; la base de données relationnelle en ligne et NoSQL seraient synchronisées avec la source fermée Vertica via des tâches ETL. Pour les bases de données analytiques, les étudiants en opérations urbaines mettent principalement en œuvre l'agrégation de données via Vertica SQL, mais le coût élevé de l'extension du système limite le développement commercial. L'équipe Uber a ensuite migré vers l'écosystème open source Hadoop pour résoudre des problèmes tels que des problèmes d'évolutivité. Cependant, Hadoop natif ne fournit pas de transactions distribuées à haute simultanéité ni de capacités de modification et de suppression de données. Par conséquent, les tâches ETL d'Uber mettent périodiquement à jour le les données sont synchronisées avec la table d'analyse et tous les anciens fichiers de données existants sont réécrits, ce qui entraîne un retard de données élevé et une consommation de ressources. De plus, en aval du lac de données, un grand nombre de travaux de streaming consommeront de manière incrémentielle les données nouvellement écrites, et la consommation de streaming du lac de données est également une fonction nécessaire pour eux. Par conséquent, ils espèrent que le projet Hudi pourra non seulement résoudre les besoins généraux du lac de données, mais également réaliser une mise à jour/suppression rapide et une consommation incrémentielle en continu. De cette manière, la liaison de données d'Uber peut être simplifiée sous la forme illustrée dans la figure ci-dessous, où DeltaStreamer est un service d'ingestion de données indépendant, qui est responsable de la lecture des données en amont et de leur écriture sur Hudi.
La mise à jour et la suppression rapides sont l'exigence principale, de sorte que le projet Hudi a fait beaucoup de conception de système pour cette exigence. S'il est nécessaire de modifier les données dans le fichier de données, la manière la plus primitive est de lire les données du fichier de données initial dans la mémoire, de les fusionner avec les données à modifier dans la mémoire, puis d'écrire les données dans la fichier de données. Cela provoque la lecture et l'écriture de toutes les données, et si le fichier est volumineux, cette performance est extrêmement lente. Le mécanisme MVCC peut résoudre ce problème. Les données de chaque mise à jour incrémentielle seront écrites indépendamment dans un fichier delta au lieu de modifier le fichier de données initial. Lors de la lecture des données, les données initiales et les données du fichier delta sont lues dans la mémoire. , puis Fusionner en fonction de la version des données et des anciennes et nouvelles conditions. Hudi affine encore la conception de MVCC et conçoit deux formats de table de données, Copier sur écriture et Fusionner sur lecture, pour différents scénarios. La table au format Copier sur écriture générera une version de la quantité totale de nouvelles données après chaque opération de transaction, de sorte que la lecture ultérieure de la table de données est plus rapide mais que l'opération de transaction est lente. Il convient à certaines tables de données de petite et moyenne taille qui sont modifiées rarement mais lues fréquemment, telles que les tables de codes ; la table de données dans la fusion à la lecture est écrit dans une table de données indépendante lors de l'opération de modification. Dans le fichier delta/delete, le fichier de base et le fichier delta sont lus ensemble dans la mémoire et fusionnés en fonction des enregistrements lors de la lecture. Cette méthode a une vitesse de modification rapide et une vitesse de lecture relativement lente, plus adaptée aux grandes quantités de données ou aux Tables modifiées plus fréquemment. Les développeurs peuvent choisir le schéma approprié pour chaque table en fonction des besoins de l'entreprise. Il convient de mentionner que l'implémentation de la plupart des moteurs de stockage adopte par défaut le format Merge on Read.
Le stockage en colonnes a des performances d'analyse de données relativement bonnes, mais comme il ne peut pas localiser avec précision une certaine ligne d'enregistrement, les performances des requêtes sont généralement médiocres. Hudi a conçu un HoodieKey similaire à la clé primaire pour de meilleures performances de requête, et a fourni des fonctions telles que BloomFilter sur le HoodieKey, de sorte que, qu'il s'agisse d'une vérification ponctuelle ou d'une suppression précise des données, vous puissiez trouver la zone de données qui doit être modifiée plus rapidement, ainsi améliorer la performance des opérations transactionnelles.
De plus, afin de prendre en charge la lecture incrémentielle des données en continu, Hudi prend en charge trois perspectives de lecture différentes pour le moteur d'analyse supérieur : lire uniquement les fichiers incrémentiels (vue incrémentielle), lire uniquement les données initiales (vue optimisée en lecture). quantité totale de données (affichage en temps réel), pour l'analyse des données en temps réel, vous ne pouvez lire que des fichiers incrémentiels. Pour certaines entreprises qui ne nécessitent pas une grande précision des données, comme l'apprentissage automatique, vous pouvez utiliser la méthode de lecture des données initiales Pour accélérer, et pour les tâches d'entrepôt de données qui nécessitent la cohérence des données, il est nécessaire d'utiliser la méthode de fusion et de lecture de la quantité totale de données.
Différent de Delta Lake afin de mieux servir le métier de l'apprentissage automatique, Apache Hudi est principalement destiné à l'ETL et à l'analyse statistique de données structurées, ainsi qu'à de meilleurs effets de calcul en temps réel, qui tournent tous autour du métier SQL, donc sa conception n'a pas trop pris en compte les besoins des langages de programmation et des frameworks d'apprentissage automatique.
— Apache Iceberg —
Le lac de données de Netflix a d'abord été créé à l'aide d'Apache Hive. Le stockage de données sous-jacent est basé sur HDFS, et Hive fournit des garanties de schéma de table de données et une prise en charge limitée de la fonction ACID. Étant donné que Hive doit fournir une requête de métadonnées de table de données basée sur un métastore indépendant, les performances du métastore sont insuffisantes lorsque la partition de données est particulièrement grande, ce qui conduit au fait que les performances d'analyse des requêtes sur certaines tables de données avec de nombreuses partitions ne peuvent pas répondre aux besoins des entreprises. besoins Le plus gros problème auquel l'équipe est confrontée. De plus, l'implémentation ACID de Hive n'est pas assez complète. Une écriture de transaction sur HDFS et le metastore aura une atomicité insuffisante. Dans certains cas d'échec, les données auront certaines incohérences, et un travail supplémentaire de vérification des données sera introduit. De plus, Netflix espère s'étendre au stockage d'objets, afin de réaliser la séparation du stockage et de l'informatique. Sur la base des raisons ci-dessus, Netflix a construit le projet Iceberg pour résoudre divers problèmes liés à la création de lacs de données. Il convient de souligner qu'Iceberg est un format de stockage de table de données conçu pour les systèmes de lac de données, et non un processus ou un service indépendant.C'est la plus grande différence par rapport à Delta Lake et Hudi, qui nécessitent que le moteur informatique charge la bibliothèque Iceberg.
Étant donné qu'Iceberg souhaite résoudre divers problèmes causés par les nombreuses partitions de Netflix, il se concentre sur la conception de la gestion des métadonnées et des fonctions liées aux partitions de la table de données. Contrairement à divers autres moteurs qui s'appuient sur un méta-service, Iceberg stocke les métadonnées directement dans le fichier, comme illustré dans la figure ci-dessus. Tous les états de la table sont enregistrés dans le fichier de métadonnées, et les nouvelles modifications apportées à la table généreront un nouveau fichier de métadonnées, qui stocke le schéma de table, la partition, l'instantané et certaines autres informations d'attribut de table. Cette conception est qu'Iceberg doit s'appuyer sur un méta-service indépendant afin de résoudre d'autres moteurs, et le méta-service peut avoir des goulots d'étranglement de performances.
Le stockage physique des données de la table Iceberg est enregistré sous la forme de fichiers de données, ce qui est différent des autres systèmes (tels que Hive, Hudi, etc.) qui adoptent une structure à deux niveaux de "répertoire-fichier", car d'autres systèmes s'appuyer sur les répertoires de fichiers pour la segmentation des partitions, l'optimisation SQL Lors de l'optimisation de l'élagage des partitions, il est nécessaire d'appeler plusieurs fois l'API distante du système de fichiers pour déterminer l'état de chaque répertoire, déterminant ainsi la partition et l'élagage en fonction du plan d'exécution. Parce que l'appel API du système de fichiers est plus lent que le calcul de la mémoire, notamment dans le nombre de partitions Dans les cas relativement volumineux, cela prend souvent beaucoup de temps. La méthode d'Iceberg consiste à utiliser plusieurs fichiers manifestes pour gérer directement les fichiers de données, de sorte que le moteur de calcul peut charger directement le fichier manifeste dans le contenu, de sorte que seul le calcul en mémoire est requis pendant le processus d'optimisation. L'élagueuse de partition ne nécessite pas plusieurs accès au système de fichiers, améliorant ainsi la vitesse d'accès. Il est enregistré par le fichier manifeste et pointe vers le fichier de données correspondant. Le fichier manifeste enregistre une ligne d'informations pour chaque fichier de données, y compris des informations sur la partition et certaines données de métrique, qui fournit un support de données pour l'optimisation ultérieure de la partition.
Sur la base de cette conception d'architecture, chaque fois qu'une opération de transaction est effectuée sur la table de données, un nouveau fichier de métadonnées sera généré. Après chaque validation, le catalogue Iceberg pointera le pointeur de métadonnées vers le nouveau fichier de métadonnées via une opération atomique. Par conséquent, au niveau de l'isolement des transactions, Iceberg ne peut fournir que le niveau d'isolement sérialisable et ne peut pas fournir d'autres niveaux d'isolement plus élevés, et toutes les opérations de transaction se font au niveau de la table complète, alors que la plupart des autres moteurs de stockage peuvent le faire au niveau de la partition. Cette conception rendra Iceberg plus susceptible de rencontrer des conflits de verrouillage dans des opérations simultanées dans une activité de production réelle. Par exemple, la table large dans la couche intermédiaire de l'entrepôt de données aura plus de conflits de verrouillage en raison du traitement simultané de plusieurs flux de données. Iceberg adopte une stratégie de contrôle de concurrence optimiste (concurrence optimiste). Après un conflit, l'opération de transaction SQL de la session en cours sera retentée en fonction des nouvelles données de transaction. L'avantage de cette méthode est que la mise en œuvre du protocole de transaction est relativement simplifiée, mais l'inconvénient est que plus les opérations de transaction simultanées sont effectuées sur la même table, le taux d'abandon des transactions augmentera rapidement et les ressources de calcul SQL seront gaspillées. Par conséquent, en termes de support de transaction, Iceberg est plus faible que d'autres projets.
Dans la mise en œuvre de MVCC, Iceberg a également adopté la mise en œuvre de Merge on Read. Toutes les opérations de modification d'une transaction sont stockées de manière indépendante dans le fichier de suppression. En termes de conception, Iceberg s'inspire pleinement de l'idée du binlog de la base de données. Il existe deux manières d'enregistrer les comportements dans le fichier de suppression. L'une est la suppression de position, qui enregistre quel fichier de données en détail. Une ligne est supprimée, ce qui est principalement utilisé pour la suppression précise d'une petite quantité de données ; il existe un autre moyen, Equality deletes, qui ne peut pas enregistrer quelles lignes spécifiques sont supprimées, mais il enregistrera quel type de expression est utilisée pour sélectionner ces lignes de données et exécuter la suppression, principalement utilisée pour certaines opérations de suppression par lots. Puisqu'il n'est pas nécessaire de modifier directement les données dans le fichier de données, ni de fichiers à accès aléatoire, Iceberg a donc des exigences relativement faibles pour le système de fichiers sous-jacent et ne nécessite pas de transactions au niveau du système de fichiers, d'accès aléatoire et POSIX interfaces, même le stockage d'objets S3 le plus simple peut également être pris en charge, ce qui garantit également que Netflix peut ensuite créer un lac de données basé sur le stockage d'objets.
Pour résumer, Iceberg adopte une conception d'architecture très différente pour résoudre certains problèmes rencontrés par Netflix, car son cœur est de résoudre les problèmes de performances et d'évolutivité des métadonnées rencontrés dans le scénario de requête de données, en particulier le processus de partition. ; Les fonctions ACID peuvent être fournies dans les opérations de données, mais les performances de concurrence des transactions sont faibles ; la construction du lac de données peut être basée sur le stockage d'objets. De plus, Iceberg lui-même n'est pas un moteur de stockage, il ne peut donc pas fournir de fonctions telles que les clés primaires et doit être utilisé conjointement avec des moteurs informatiques tels que Spark et Presto. Par conséquent, les caractéristiques du groupe d'entreprises auquel Iceberg convient sont également très distinctes.Dans les scénarios de marketing et de contrôle des risques des entreprises Internet en ligne typiques, il existe une grande quantité de données en temps réel ou de données de journal, qui sont toutes des données raffinées. analyse selon l'axe du temps Données récentes La valeur est élevée mais la valeur des données à moyen et long terme n'est pas grande Le nombre de partitions de données est particulièrement important et il a la capacité de développer et d'optimiser les moteurs de calcul. En raison de sa capacité de transaction relativement faible dans la conception, il n'est pas adapté au traitement par lots de données hautement simultané et à la modélisation d'entrepôt de données. En outre, une attention particulière doit être accordée à la gestion de la sécurité des données, car des dommages aux fichiers de métadonnées peuvent entraîner une perte de données.
- Résumé -
Cet article présente les deux architectures intégrées de lac et d'entrepôt d'Apache Hudi et d'Apache Iceberg. Le prochain article continuera à présenter les deux technologies de Transwarp Inceptor et Delta Lake.