Construire le Data Lakehouse de nouvelle génération

Un entrepôt de données a été défini par Bill Inmon comme « une collection de données orientée sujet, intégrée, non volatile et variant dans le temps à l’appui des décisions de la direction » il y a plus de 30 ans. Cependant, les entrepôts de données initiaux n’étaient pas en mesure de stocker des données hétérogènes massives, d’où la création de lacs de données. À l’époque moderne, le data lakehouse apparaît comme un nouveau paradigme. Il s’agit d’une architecture de gestion de données ouverte caractérisée par de solides capacités d’analyse et de gouvernance des données, une grande flexibilité et un stockage ouvert.

Si je ne pouvais utiliser qu’un seul mot pour décrire le lac de données de nouvelle génération, ce serait unification:

Stockage de données unifié pour éviter les problèmes et les risques liés au stockage redondant et à l’ETL intersystème.
Gouvernance unifiée des données et des métadonnées avec prise en charge d’ACID, Schema Evolution et Snapshot.
Application de données unifiée qui prend en charge l’accès aux données via une interface unique pour plusieurs moteurs et charges de travail.

Examinons l’architecture d’un data lakehouse. Nous constaterons qu’il n’est pas seulement pris en charge par des formats de table tels qu’Apache Iceberg, Apache Hudi et Delta Lake, mais plus important encore, il est alimenté par un moteur de requête hautes performances pour extraire la valeur des données.

Les utilisateurs recherchent un moteur de requête qui permet un accès rapide et fluide aux sources de données les plus populaires. Ce qu’ils ne veulent pas, c’est que leurs données soient verrouillées dans une certaine base de données et rendues indisponibles pour d’autres moteurs ou qu’ils consacrent du temps et des coûts informatiques supplémentaires au transfert de données et à la conversion de format.

Pour transformer ces visions en réalité, un moteur de recherche de données doit répondre aux questions suivantes :

Comment accéder à plus de sources de données et acquérir plus facilement des métadonnées ?
Comment améliorer les performances des requêtes sur des données provenant de diverses sources ?
Comment permettre une planification des ressources et une gestion de la charge de travail plus flexibles ?

Apache Doris fournit une réponse possible à ces questions. Il s’agit d’une base de données OLAP en temps réel qui aspire à se transformer en une passerelle d’analyse de données unifiée. Cela signifie qu’il doit être facilement connecté à divers SGBDR, entrepôts de données et moteurs de lac de données (tels que Hive, Iceberg, Hudi, Delta Lake et Flink Table Store) et permettre une écriture rapide des données et des requêtes sur ces sources de données hétérogènes. . Le reste de cet article est une explication approfondie des techniques d’Apache Doris dans les trois aspects ci-dessus : acquisition de métadonnées, optimisation des performances des requêtes et planification des ressources.

Acquisition de métadonnées et accès aux données

Apache Doris 1.2.2 prend en charge une grande variété de formats de lac de données et d’accès aux données à partir de diverses sources de données externes. En outre, via la fonction de valeur de table, les utilisateurs peuvent analyser directement les fichiers dans le stockage d’objets ou HDFS.

Pour prendre en charge plusieurs sources de données, Apache Doris s’efforce d’acquérir des métadonnées et d’accéder aux données.

Acquisition de métadonnées

Les métadonnées consistent en des informations sur les bases de données, les tables, les partitions, les index et les fichiers de la source de données. Ainsi, les métadonnées de diverses sources de données se présentent sous différents formats et modèles, ce qui complique la connexion des métadonnées. Un service d’acquisition de métadonnées idéal devrait inclure les éléments suivants :

UN structure des métadonnées pouvant accueillir des métadonnées hétérogènes.
Un cadre de connexion de métadonnées extensible qui permet une connexion de données rapide et peu coûteuse.
Fiable et efficace accès aux métadonnées qui prend en charge la capture de métadonnées en temps réel.
Authentification personnalisée services pour s’interfacer avec des systèmes externes de gestion des privilèges et ainsi réduire les coûts de migration.

Structure des métadonnées

Les anciennes versions de Doris prennent en charge une structure de métadonnées à deux niveaux : base de données et table. Par conséquent, les utilisateurs doivent créer des mappages pour les bases de données et les tables externes une par une, ce qui est un travail lourd. Ainsi, Apache Doris 1.2.0 a introduit la fonctionnalité Multi-Catalogue. Avec cela, vous pouvez mapper des données externes au niveau du catalogue, ce qui signifie :

Vous pouvez mapper l’ensemble de la source de données externe et en ingérer toutes les métadonnées.
Vous pouvez gérer les propriétés de la source de données spécifiée au niveau du catalogue, telles que la connexion, les privilèges et les détails d’ingestion de données, et gérer facilement plusieurs sources de données.

Les données dans Doris se répartissent en deux types de catalogues :

Catalogue interne : les bases de données et les tables Doris existantes appartiennent toutes au catalogue interne.
Catalogue externe : Il est utilisé pour s’interfacer avec des sources de données externes. Par exemple, HMS External Catalog peut être connecté à un cluster géré par Hive Metastore, et Iceberg External Catalog peut être connecté à un cluster Iceberg.

Vous pouvez utiliser le SWITCH déclaration pour changer de catalogue. Vous pouvez également effectuer des requêtes fédérées à l’aide de noms complets. Par exemple:

SELECT * FROM hive.db1.tbl1 a JOIN iceberg.db2.tbl2 b
ON a.k1 = b.k1;

Cadre de connexion de métadonnées extensible

L’introduction du niveau catalogue permet également aux utilisateurs d’ajouter de nouvelles sources de données simplement en utilisant le CREATE CATALOG déclaration:

CREATE CATALOG hive PROPERTIES (
    'type'='hms',
    'hive.metastore.uris' = 'thrift://172.21.0.1:7004',
);

Dans les scénarios de lac de données, Apache Doris prend actuellement en charge les services de métadonnées suivants :

Services de métadonnées compatibles Hive Metastore
Formation du lac de données cloud d’Alibaba
Colle AWS

Cela ouvre également la voie aux développeurs qui souhaitent se connecter à davantage de sources de données via le catalogue externe. Tout ce dont ils ont besoin est d’implémenter l’interface d’accès.

Accès efficace aux métadonnées

L’accès aux sources de données externes est souvent entravé par les conditions du réseau et les ressources de données. Cela nécessite des efforts supplémentaires de la part d’un moteur de requête de données pour garantir la fiabilité, la stabilité et la rapidité d’accès aux métadonnées.

Doris permet une grande efficacité dans l’accès aux métadonnées en Méta cache, qui comprend le cache de schéma, le cache de partition et le cache de fichiers. Cela signifie que Doris peut répondre aux requêtes de métadonnées sur des milliers de tables en quelques millisecondes. De plus, Doris prend en charge l’actualisation manuelle des métadonnées au niveau Catalogue/Base de données/Table. Pendant ce temps, il permet la synchronisation automatique des métadonnées dans Hive Metastore en surveillant Hive Metastore Event, de sorte que toute modification peut être mise à jour en quelques secondes.

Autorisation personnalisée

Les sources de données externes sont généralement fournies avec leurs propres services de gestion des privilèges. De nombreuses entreprises utilisent un seul outil (tel qu’Apache Ranger) pour fournir une autorisation pour leurs multiples systèmes de données. Doris prend en charge un plug-in d’autorisation personnalisé, qui peut être connecté au propre système de gestion des privilèges de l’utilisateur via l’interface Doris Access Controller. En tant qu’utilisateur, il vous suffit de spécifier le plug-in d’autorisation pour un catalogue nouvellement créé, puis vous pouvez facilement effectuer l’autorisation, l’audit et le cryptage des données sur les données externes dans Doris.

Accès aux données

Doris prend en charge l’accès aux données sur les systèmes de stockage externes, y compris le stockage d’objet compatible HDFS et S3 :

Optimisation des performances des requêtes

Après avoir ouvert la voie à l’accès aux données externes, la prochaine étape pour un moteur de requête serait d’accélérer les requêtes de données. Dans le cas d’Apache Doris, des efforts sont faits sur la lecture des données, le moteur d’exécution et l’optimiseur.

Lecture de données

La lecture des données sur les systèmes de stockage distants est souvent entravée par la latence d’accès, la simultanéité et la bande passante d’E/S. Il est donc préférable de réduire la fréquence de lecture.

Lecteur de format de fichier natif

Améliorer l’efficacité de la lecture des données implique d’optimiser la lecture des fichiers Parquet et des fichiers ORC, qui sont les fichiers de données les plus courants. Doris a refactorisé son lecteur de fichiers, qui est adapté à chaque format de données. Prenons l’exemple du Native Parquet Reader :

Réduire la conversion de format: Il peut convertir directement des fichiers au format de stockage Doris ou à un format plus performant en utilisant l’encodage par dictionnaire.
Indexation intelligente d’une granularité plus fine: Il prend en charge l’index de page pour les fichiers Parquet, de sorte qu’il peut utiliser l’indexation intelligente au niveau de la page pour filtrer les pages.
Refoulement des prédicats et matérialisation tardive: Il lit d’abord les colonnes avec des filtres, puis lit les autres colonnes des lignes filtrées. Cela réduit considérablement le volume de lecture de fichiers car cela évite de lire des données non pertinentes.
Fréquence de lecture inférieure: S’appuyant sur le débit élevé et la faible simultanéité du stockage distant, il combine plusieurs lectures de données en une seule afin d’améliorer l’efficacité globale de la lecture des données.

Cache de fichiers

Doris met en cache les fichiers du stockage distant sur des disques locaux hautes performances afin de réduire les frais généraux et d’augmenter les performances de lecture des données. De plus, il a développé deux nouvelles fonctionnalités qui rendent les requêtes sur les fichiers distants aussi rapides que celles sur les fichiers locaux :

Cache de bloc : Doris prend en charge le cache de bloc des fichiers distants et peut ajuster automatiquement la taille du bloc de 4 Ko à 4 Mo en fonction de la demande de lecture. La méthode de cache de bloc réduit l’amplification de lecture/écriture et la latence de lecture dans les caches froids.
Hachage cohérent pour la mise en cache : Doris applique un hachage cohérent pour gérer les emplacements de cache et planifier l’analyse des données. Ce faisant, il évite les défaillances du cache provoquées par la mise en ligne et hors ligne des nœuds. Cela peut également augmenter le taux de réussite du cache et la stabilité du service de requête.

Moteur d’exécution

Les développeurs ne veulent sûrement pas reconstruire toutes les fonctionnalités générales pour chaque nouvelle source de données. Au lieu de cela, ils espèrent réutiliser le moteur d’exécution vectorisée et tous les opérateurs de Doris dans le scénario data lakehouse. Ainsi, Doris a refactorisé les nœuds de scan :

Superposez la logique: Toutes les requêtes de données dans Doris, y compris celles sur les tables internes, utilisent les mêmes opérateurs, tels que Join, Sort et Agg. La seule différence entre les requêtes sur les données internes et externes réside dans l’accès aux données. Dans Doris, tout ce qui se trouve au-dessus des nœuds d’analyse suit la même logique de requête, tandis qu’en dessous des nœuds d’analyse, les classes d’implémentation s’occuperont de l’accès aux différentes sources de données.
Utiliser un cadre général pour les opérateurs de numérisation: même pour les nœuds d’analyse, différentes sources de données ont beaucoup en commun, telles que la logique de répartition des tâches, la planification des sous-tâches et des E/S, le refoulement des prédicats et le filtre d’exécution. Par conséquent, Doris utilise des interfaces pour les gérer. Ensuite, il implémente une logique de planification unifiée pour…