Résumé : Cet article est compilé à partir du partage de Zeng Qingdong (Xile), ingénieur de développement principal d'Alibaba Cloud, lors du Streaming Lakehouse Meetup. Le contenu est principalement divisé en quatre parties :
- Introduction au schéma de mise en œuvre de l'analyse traditionnelle des entrepôts de données
- Paimon+StarRocks construit une solution intégrée d'analyse de données pour les lacs et les entrepôts
- Comment utiliser et mettre en œuvre la combinaison de StarRocks et Paimon
- Analyse de l’entrepôt de StarRocks Community Lake Planification future
Cliquez pour voir la vidéo et le discours originaux PPT
1. Introduction au schéma de mise en œuvre de l'analyse traditionnelle des entrepôts de données
La mise en œuvre de l'analyse d'entrepôt de données traditionnelle est une architecture Lambda typique.La figure ci-dessous montre que l'architecture traditionnelle est principalement divisée en deux couches : la couche supérieure est la couche de liaison en temps réel et la couche inférieure est la couche de liaison hors ligne. couche de liaison. Leurs données passent par la couche d'ingestion de données sur la gauche et intègrent les données dans un middleware de file d'attente de messages comme Kafka via différents chemins, puis divisent les données en deux données identiques, qui sont respectivement divisées en lien en temps réel et en lien par lots. est traité et finalement agrégé à la couche de service de données pour réaliser la capacité de fournir des services d'analyse de données aux utilisateurs.
L'émergence de l'architecture Lambda est principalement due à l'émergence de la demande des utilisateurs pour une analyse en temps réel et à la maturité progressive de la technologie de traitement des flux. Mais il présente également des inconvénients évidents : comme le montre la figure ci-dessus, il nécessite de maintenir deux systèmes, ce qui entraînera une augmentation des coûts de déploiement et des coûts de main-d'œuvre. Lorsque l’entreprise évolue, les deux systèmes doivent également être modifiés pour s’adapter aux évolutions de l’entreprise.
Avec la maturité progressive de la technologie de traitement de flux, l'architecture Kappa a été introduite après l'architecture Lambda, comme le montre la figure suivante.
L'architecture Kappa utilise des liens de traitement de flux pour remplacer l'architecture Lambda d'origine. En raison de la maturité du traitement de flux, il est possible d'effectuer des calculs en temps réel et hors ligne via un ensemble de systèmes.
L'architecture Kappa a un principe : elle estime que le double calcul des données historiques n'est inutile que si cela est nécessaire. Cela rend souvent nécessaire de rejouer l'intégralité du processus de saisie des données une fois lorsque les utilisateurs doivent recalculer les données historiques ou que de nouveaux changements commerciaux se produisent. En cas de consommation massive de données historiques, cela entraînera inévitablement un gaspillage de ressources et rencontrera des goulots d'étranglement.
2. Paimon+StarRocks construit une solution intégrée d'analyse de données pour les lacs et les entrepôts
2.1 Centre de lac de données
La première solution est une solution de centre de lac de données pour Paimon et StarRocks afin de créer une analyse intégrée des données du lac et de l'entrepôt.
StarRocks lui-même est une base de données MPP. En même temps, il peut être connecté aux composants du lac de données dans différents formats. Il peut être utilisé simplement comme moteur de requête pour se connecter aux composants du lac de données afin de réaliser des fonctions de requête. Comme le montre la figure ci-dessus, les composants Paimon de la couche de données tels que ODS peuvent être interrogés via StarRocks ou Spark.
Dans cette architecture, Paimon compense les lacunes du middleware de file d'attente de messages dans l'architecture Kappa présentée ci-dessus en termes de modification des données, de retour en arrière et d'interrogation en plaçant et en indexant les données, rendant ainsi cette architecture plus tolérante aux pannes et prend en charge une plus large gamme de capacités. Parallèlement, en termes de traitement par lots, Paimon est également entièrement compatible avec les capacités de HIVE.
2.2 Requête accélérée
La deuxième solution est une solution de requête accélérée permettant à Paimon et StarRocks de créer une analyse intégrée des données des lacs et des entrepôts.
Elle diffère de la première solution dans la mesure où la quasi-totalité du système est réalisée uniquement par StarRocks. Une fois les données connectées à Paimon et utilisées comme couche ODS, les données sur Paimon sont lues à travers les caractéristiques d'apparence de StarRocks et une vue matérialisée est établie en tant que couche DWD.
La vue matérialisée de StarRocks possède certaines capacités ETL.Après avoir été utilisée comme couche DWD, elle est utilisée comme couche DWS via la deuxième couche de vue matérialisée imbriquée, et enfin fournie à la couche de service de données pour l'analyse des données.
Les deux avantages de l'utilisation de ce système de StarRocks pour coopérer avec l'architecture de Paimon sont :
- Simplifie l'exploitation et la maintenance, car il n'a pas besoin de maintenir divers composants et n'a besoin que de StarRocks et Paimon pour achever la construction de solutions d'analyse de données ;
- La vitesse des requêtes est rapide, car StarRocks est un moteur de lac de données avec un système autonome de création d'index, de stockage de données et d'optimisation des requêtes, il est donc plus rapide que les autres moteurs de requête présentés ci-dessus.
2.3 Vue matérialisée
Le code SQL sur le côté droit de la figure ci-dessus décrit comment créer une vue matérialisée asynchrone StarRocks. Il présente principalement les caractéristiques suivantes :
- Grâce à la définition SQL, il est facile à utiliser et à maintenir ;
- Le pré-calcul réduit la latence des requêtes et la surcharge de double calcul ;
- Routage automatique des requêtes, pas besoin de réécrire SQL, accélération transparente ;
- Prend en charge l'actualisation automatique asynchrone des données, l'actualisation programmée et l'actualisation intelligente par partition ;
- Prend en charge la construction multi-tables, la table de base peut provenir d'une table intérieure, d'une table extérieure et d'une vue matérialisée existante.
2.4 Séparation chaud et froid
C'est la particularité de la séparation chaud et froid via Paimon + StarRocks.
Le concept de séparation chaude et froide consiste à stocker les données chaudes fréquemment interrogées sur un moteur OLAP comme StarRocks avec des requêtes rapides, et à stocker les données froides rarement interrogées sur des composants de stockage de fichiers distants relativement bon marché, tels que OSS et HDFS.
Comme le montre l'exemple de séparation chaud et froid Paimon + StarRocks ci-dessus, si une telle table MV séparée chaud et froid est construite, lorsque cette table est interrogée, les données chaudes distribuées sur StarRocks et les données froides distribuées sur Paimon seront automatiquement sélectionnées. Les résultats de la requête sont ensuite combinés et renvoyés à l'utilisateur.
3. Comment utiliser et mettre en œuvre la combinaison de StarRocks et Paimon
3.1 Utilisation de l'apparence de Paimon
Grâce à l'abstraction par StarRocks du catalogue d'apparences, peu après le lancement de Paimon, StarRocks a réalisé la prise en charge de l'apparence Paimon en implémentant l'interface correspondante. Lors de la connexion au catalogue externe Paimon, il vous suffit d'exécuter l'instruction Create External Catalog suivante sur StarRocks, de spécifier Paimon comme type et de renseigner le chemin correspondant pour interroger directement les données dans Paimon.
3.2 Connecteur JNI
JNI Connector est une fonctionnalité plus importante qui fait la combinaison de StarRocks et Paimon.
L'arrière-plan de JNI Connector est que les composants de traitement de données de StarRocks sont écrits dans des programmes C++, mais la plupart des SDK fournis par les composants du lac de données sont Java et il n'y a pas de SDK C++. Si StarRocks souhaite accéder aux données sous-jacentes du composants du lac de données via BE, uniquement. Il peut accéder à ses formats ORC/Parquet natifs et autres, mais ne peut pas appliquer les fonctions avancées fournies par ces composants.
JNI Connector est un connecteur abstrait applicable à tous les SDK Java externes. Il est utilisé sur le composant BE de StarRocks et constitue une couche intermédiaire entre BE et le composant du lac de données Java SDK.
La fonction principale de JNI Connector est d'appeler le SDK Java du composant du lac de données pour lire les données du lac de données, puis d'écrire les données lues dans une mémoire hors tas dans un arrangement de mémoire que le BE de StarRocks peut reconnaître, et puis écrivez ceci. La mémoire est remise au programme BE C++ pour qu'il s'exécute, afin qu'il puisse relier BE et Java SDK.
Le connecteur JNI présente les caractéristiques suivantes :
- Accédez rapidement à diverses sources de données Java sans considérer la conversion des données ;
- Fournit une interface Java facile à utiliser ;
- Déjà pris en charge la table Hudi MOR, la table Paimon ;
- Prise en charge des types complexes Struct, Map, Array ;
- Le code BE n’a aucune intrusion et n’a pas besoin de prendre en compte l’implémentation spécifique du C++.
La figure ci-dessous est une introduction à certains détails du connecteur JNI.
Ce qui précède est le format de stockage des champs de longueur fixe et celui du bas est le format de stockage des champs de longueur variable.
-
Format de stockage de champs de longueur fixe
- La première partie est la définition de savoir si chaque ligne de données de cette colonne est nulle.
- La deuxième partie est la partie données, où sont stockées des données spécifiques de longueur fixe.
-
Format de stockage de champs de longueur variable
- La première partie est un tableau indiquant si chaque ligne de cette colonne est nulle ;
- La deuxième partie consiste à décrire l'adresse de début de chaque ligne de données dans la troisième partie des données spécifiques à commencer la lecture ;
- La troisième partie concerne les données spécifiques.
4. Planification future de l'analyse Hucang de la communauté StarRocks
À l'heure actuelle, StarRocks prend déjà en charge certaines fonctionnalités de Paimon, et certaines fonctionnalités n'ont pas encore été implémentées. Ensuite, les futurs projets visant à améliorer les caractéristiques de l'analyse des tables Paimon sont les suivants :
-
Prise en charge de l'analyse des types complexes
-
Statistiques des colonnes de support
-
Prise en charge de la mise en cache des métadonnées
-
Prise en charge du voyage dans le temps
-
Prise en charge de la vue matérialisée en streaming basée sur l'apparence de Paimon
Questions et réponses
Q : Comment gérer efficacement les vues matérialisées ?
R : Une fois la vue matérialisée créée, elle peut être automatiquement actualisée et planifiée, sans dépendre de composants externes pour déclencher l'actualisation. La fonctionnalité de réécriture de requêtes permet aux utilisateurs d'interroger uniquement la table de base sans spécifier de vue matérialisée. Ces deux fonctionnalités réduisent de nombreux problèmes de gestion. Quant aux dépendances entre vues matérialisées et tables de base, et entre vues matérialisées imbriquées, EMR-Serverless-StarRocks lancera une fonction d'affichage web pour la planification des tâches et les dépendances des tables.
Q : La solution intégrée d'analyse des données de l'entrepôt Paimon+StarRocks Lake Warehouse propose-t-elle des plans spécifiques pour la sécurité des données, tels que le contrôle d'accès, l'audit des données, etc. ?
R : À l'heure actuelle, ce que j'ai appris sur les autorisations de gestion des données de StarRocks est basé sur des autorisations de visualisation, de modification et autres basées sur les rôles, et différentes autorisations sont accordées à différents rôles. De plus, il existe une fonction d'authentification de composant correspondante pour les données sur OSS ou HDFS.
Q : Dans l'architecture intégrée lac-entrepôt avec StarRocks comme corps principal, après avoir lu les données de Paimon, seront-elles réécrites dans Paimon ?
R : Une fois les données de la couche ODS lues à partir de Paimon, elles seront transférées dans la vue matérialisée StarRocks, puis une couche de vues matérialisées StarRocks imbriquées ne sera pas réécrite dans Paimon.