En novembre 2023, GF Securities est devenue l'une des premières sociétés de titres à obtenir le niveau de gestion quantitative (niveau 4) grâce à l'évaluation de la maturité de la capacité de gestion des données DCMM. Actuellement, des dizaines de milliers d'opérations Kyuubi sont devenues la base d'une gestion complète des données GF. et les systèmes de données clés.
L'auteur de cet article est Liang Bowen, l'architecte de la plateforme big data de GF Securities, qui a participé à l'incubation du projet Apache Kyuubi et est devenu membre du PMC. Cet article présente et discute principalement de la plateforme Big Data de GF Securities, en se concentrant sur la stratégie de la plateforme intermédiaire d'intelligence numérique et les défis de l'ère des données sensibles, en se concentrant sur les quatre objectifs de transformation clés consistant à « améliorer l'efficacité et la contrôlabilité » et à construire une grande Couche d'activation des données basée sur Apache Kyuubi.Analyse architecturale, stratégies de mise en œuvre et amélioration de l'efficacité des liens complets des idées de contrôle intégré des droits. Dans le même temps, en tant qu'utilisateur et contributeur d'Apache Kyuubi, nous explorons et anticipons l'avenir de l'industrie et de la communauté.
Cet article couvre principalement le contenu suivant :
1. Analyse ciblée et avantages architecturaux de la couche habilitante Big Data et d'Apache Kyuubi
2. Stratégie de mise en œuvre et construction de scénarios pour la couche habilitante Apache Kyuubi Big Data
3. Idée globale de gestion et de contrôle intégrés des autorisations de données
4. Introduction aux capacités de contrôle des droits du plug-in Kyuubi Authz Spark et aux nouvelles fonctionnalités d'amarrage avec Ranger
01 Couche permettant le Big Data et les objectifs et l'architecture de Kyuubi
Pour la plateforme Big Data de GF Securities, nous espérons suivre la technologie écologique du Big Data sur la base de la compréhension de sa mission et de ses attentes en matière d'architecture, puis déterminer l'orientation de la transformation de l'autonomisation des données et déterminer les objectifs, les avantages et les points de décision du Big Data. couche d’autonomisation. .
GF Securities, qui construit continuellement un système de plateforme Big Data depuis 2014, est l'une des premières grandes maisons de titres à mettre en pratique et à faire évoluer une plateforme Big Data intégrée. En tant qu'élément important de la « plate-forme intermédiaire numérique », la construction par GF Securities d'une plate-forme intermédiaire de données intégrée au niveau de l'entreprise doit être unifiée dans la structure pour faire face à une supervision forte, un contrôle fort du pouvoir, l'accent mis sur des formulaires de données et des données de scénario stables et flexibles. besoins Réactivité et alignement. En termes d'architecture de plate-forme, nous adhérons à la méthode de réflexion « évaluation active, mise en œuvre prudente et évolution continue » et utilisons l'auto-recherche, l'intégration et l'introduction de divers moyens pour construire un système de services de données intégré avec notre propre stratégie de données. comme objectif. Plus précisément, nous espérons maintenir les capacités d'initiative et d'intégration du niveau de l'architecture au niveau du code source dans la sélection et l'adaptation des moteurs clés, des services clés et des liens clés sur la base d'une base de base unifiée. En mettant fortement l'accent sur l'écosystème open source du Big Data, nous continuerons à renforcer la prise en charge des scénarios de formulaires de données. Il s’agit d’une mission comportant des défis permanents.
Tout en absorbant activement les progrès et le développement technologiques de l'industrie, nous nous appuyons également activement sur nos propres exigences pour participer à la contribution et à la co-construction de l'écosystème du big data. Parmi eux, nous avons 1 membre PMC du projet Apache Kyuubi, se classant parmi les 4 premiers en termes de contribution au code. Et participé aux principaux projets Big Data, notamment le moteur de données Apache Spark, le stockage de lac de données Iceberg, l'entrepôt de données OLAP, etc. Parallèlement, nous avons apporté des contributions essentielles à l'écosystème Big Data Spark, notamment le contrôle d'autorisation Spark qui est compatible avec plusieurs lacs de données tels qu'Iceberg, et participé à l'achèvement de l'adaptation de Spark 3.1 à 3.5 et Scala2.13. .
Ce diagramme est uniquement à des fins schématiques et ne sert pas de représentation de l’architecture spécifique de la plateforme Big Data.
Avant d’envisager l’orientation de la transformation basée sur les données, examinons d’abord l’état actuel et les goulots d’étranglement potentiels de l’ensemble de la plateforme Big Data.
Le cœur de la base unifiée de la plate-forme Big Data comprend d'abord la base Hadoop et le service Hive Metastore. HDFS/YARN fourni par Hadoop continue de fournir des capacités de calcul et de stockage distribués fiables, qui constituent la base de l'écosystème global du Big Data. Hive Metastore sert de norme unifiée d'entrepôt de Big Data, fournissant des informations d'entrepôt pour ancrer divers moteurs et constitue la base de tous les scénarios de données. Nous avons introduit trois moteurs basés sur cela au cours de chaque période, à savoir Hive MR, Trino et Spark, chacun jouant un rôle différent. Premièrement, HiveMR fournit la solution finale d'exécution distribuée des requêtes et des traitements, et utilise également HiveSQL comme interface logique. . Deuxièmement, afin de répondre à la demande de rapidité dans les scénarios de requêtes, Trino/PrestoSQL a été introduit comme moteur de requêtes OLAP pour Adhoc et BI. Parce qu'il peut avoir des limitations architecturales sur un seul point et qu'il a rencontré des erreurs de calcul de 0 jour, il n'est utilisé que pour requêtes, et Trino est indépendant. La syntaxe deviendra un atout indépendant de HiveSQL. Parallèlement, le moteur Spark a été introduit dans certains scénarios en tant que moteur de calcul ETL compatible avec HiveSQL, mais SparkSQL n'a pas encore de solution adaptée et ne peut pas être utilisé à grande échelle de la même manière que HiveServer.
Voici plusieurs goulots d’étranglement causés par l’autonomisation des données :
1. Les interfaces du moteur pour les requêtes et le traitement sont incohérentes. En raison de l'énorme amélioration des performances de Trino lors de l'exploration des données, le développement de données utilise souvent Trino pour l'exploration des données en premier. Cependant, la syntaxe Trino est incompatible avec la syntaxe HiveSQL, ce qui entraîne la nécessité de réécrire et de vérifier une fois et de l'assembler à nouveau dans la logique de traitement des données. L’aller-retour est long et laborieux.
2. S'appuyer sur les détails des composants est trop compliqué pour les parties prenantes. Dans la recherche et le développement de données, lors de la connexion à la plate-forme Big Data, le développement d'un travail Big Data nécessite la prise en compte de nombreux facteurs, de la version de la pile technologique aux détails du chemin de configuration, en passant par le service de métadonnées de l'entrepôt de données HMS, le moteur (Spark, etc. ), format de stockage, format de tableau, etc. Cela entraîne une série de coûts de développement, de débogage et d'exploitation et réduit considérablement l'efficacité humaine, rendant impossible la concentration sur la finalisation de la logique des données métier.
3. La plateforme Big Data ne peut pas faire évoluer la version du composant de service dans son ensemble. Lorsque le travail détermine spécifiquement la combinaison et les détails des composants, cela signifie que la plate-forme Big Data fournit davantage de services en tant que couche inférieure de ressources et ne peut pas ombrer et faire évoluer uniformément les versions du moteur, introduire de nouveaux services de coordination et contrôler la couche inférieure en fonction des paramètres. dernières évaluations et besoins commerciaux, ressources, etc.
4. Les autorisations sont contrôlées via des canaux spécifiques et ne peuvent pas être ouvertes et habilitées en tant que service général. Elles ne peuvent être limitées qu'à des services spécifiques de la couche application. Des exigences réglementaires strictes dans le secteur financier exigent que des exigences telles que les contrôles d'autorisation de liste, le filtrage de contenu confidentiel, la réécriture SQL et l'audit centralisé soient respectées dans des scénarios spécifiques sur des plates-formes spécifiques. La réécriture de la couche application telle que les portails de données peut répondre aux besoins ci-dessus, mais elle limite considérablement la possibilité de connecter la plate-forme Big Data dans des scénarios généraux.
Sur le plan architectural, nous avons besoin d'une couche unifiée permettant de résoudre les problèmes ci-dessus tout en répondant aux exigences cohérentes de la direction financière.
Pour le positionnement cible de la couche d'autonomisation du Big Data, en plus d'examiner la situation actuelle et le fardeau de l'évolution historique, nous devons également comprendre les défis globaux dans une perspective à plus long terme afin de garantir la direction et la méthode de notre évolution.
En termes de défis macro, le centre de données intégré présente des défis généraux à toutes les étapes du cycle de vie des données, qui doivent être relevés de manière uniforme au niveau de la couche habilitante du Big Data :
1. Dans l'ingestion de données : la capacité d'ingérer des données hétérogènes provenant de sources multiples dans le lac de données, y compris des sources de données en streaming, par lots, structurées, très structurées et autres, nécessite des capacités multi-catalogues.
2. Sortie de données : poussez des actifs de données efficaces sur la scène pour former directement des capacités de support de données spécifiques, s'adapter à différents schémas, unifier puis transformer.
3. Avec l'informatique collaborative : La méthode du lac de données logique implique différents catalogues et sources de données hétérogènes dans les calculs sur site. La partie accès calculé remplace l'acquisition de données traditionnelle. Elle possède également les capacités de lecture et d'écriture de sources de données hétérogènes et nécessite une uniformité. vue logique.
4. Corrélation complexe : il répond aux requêtes ad hoc et à l'exploration de données, et dispose de capacités de calcul de corrélation complexe à plusieurs niveaux. En même temps, il utilise pleinement CBO et RBO pour maximiser les performances de réponse aux requêtes face à des données massives, et a la capacité de générer des résultats directement vers BI, AdHoc et d'autres scénarios.
5. De la gouvernance des données : La gestion globale des données met en avant de nouvelles exigences en matière de métadonnées et de liens de sang. Elle nécessite que les plateformes de données middle-end et Big Data soient capables de percevoir de manière proactive le flux de modifications des données et les relations fines dans le cycle de vie des données. , en particulier le traitement des données. Dans le même temps, les résultats de la gouvernance des données sont appliqués tout au long du cycle de vie.
6. Par traitement systématique : modélisation hiérarchique, dépendances d'ordonnancement, capacités ETL hautes performances, puissance de calcul distribuée et défis de stockage, etc.
En termes de micro-défis, les méthodes de traitement et les formes de sortie des données ont également subi de grands changements. La base unifiée doit répondre à ces nouvelles exigences induites par l'indexation/étiquetage, les formes mixtes et les scénarios flexibles :
1. Indicateurisation/étiquetage : la méthode de sortie des données va d'un seul tableau large traditionnel aux indicateurs de sortie, et d'autres sont générés sous une forme logique combinée avec des associations complexes et combinées dynamiquement au moment de l'exécution pour la sortie. Cela nous oblige à avoir la capacité de filtrer les lignes, d'effectuer le contrôle des données et d'optimiser les plans d'exécution. Il prend également en charge les tables étroites à plusieurs niveaux et les tables larges complexes. Dans le même temps, le traitement des données indexées et étiquetées nécessitera également la capacité de concurrence pour effectuer un traitement parallèle distribué multipoint sur le même champ de ressources.
2. Forme hybride : Une solution intégrée qui résout les défis posés par plusieurs architectures de stockage, y compris les lacs de données logiques et le stockage hétérogène. Elle dispose de capacités informatiques collaboratives multi-catalogues et répond à diverses exigences telles que les tables d'entrepôt, les tables de flux et les tables de dimensions. Entités de ressources qui participent aux calculs sous forme logique et de stockage.
3. Scénarios élastiques : Face à des scénarios élastiques avec des stratégies de ressources élastiques, il peut non seulement répondre aux requêtes explosives et complexes d'AdHoc, mais également effectuer des scénarios de traitement de lecture et d'écriture à grande échelle. Il doit y avoir une planification dynamique des ressources utilisées pendant l'exécution et une collaboration avec la base pour développer et récupérer les ressources d'exécution. Plus précisément, le plan d'exécution doit être entièrement optimisé et les capacités CBO et RBO du secteur doivent être utilisées en permanence pour effectuer des ajustements en utilisant toutes les informations sur site.
Par conséquent, d’un point de vue global, que ce soit d’un point de vue macro ou micro, il n’est plus possible de relever les défis actuels avec les caractéristiques traditionnelles des 4 V du Big Data, à savoir le volume, la variété, la vitesse et la valeur.
« Données sensibles » Agile Data est la compréhension et l'abstraction de la nouvelle ère des données par la plateforme Big Data de GF Securities. Les données sensibles nécessitent la construction d'un centre de données basé sur les données. Avec une activité de données plus active et une maturité des données plus efficace, les données elles-mêmes peuvent être exposées et approfondies dans des scénarios, afin qu'elles puissent être plus largement utilisées et prendre en charge des scénarios de données. de formes et de tailles diverses, tout en utilisant en interne une variété de formes de données mixtes pour répondre aux défis informatiques et de stockage. Les quatre principales caractéristiques des données sensibles AgileData peuvent être résumées comme « HEAD », à savoir hybride, maturité des données habilitante, activité des données active et puissance de calcul élastique dynamique.
1. Formulaire de données hybride Hybride : fournit un formulaire d'accès unifié vers le haut et utilise de manière exhaustive plusieurs formulaires de données vers le bas, y compris l'intégration d'entrepôts lacustres, l'intégration de lots en continu, le multi-catalogue hétérogène et d'autres moyens, pour unifier les formulaires de données ouvertes. Le traitement ne poursuit pas le caractéristiques d'un moteur unique, mais examine et gère de manière exhaustive les données et les moteurs en tant qu'exigences générales.
2. Maturité efficace des données Permettre : Utiliser des données matures et efficaces pour piloter des scénarios de données, passer par une bonne gouvernance et un bon contrôle des données, et obtenir une qualité de données fiable pour répondre aux spécifications des données. La plate-forme de données elle-même doit activer les éléments requis pour ces processus. Plus important encore, grâce à une itération continue de la maturité des données, la plate-forme de données et l'entreprise de données peuvent générer une valeur mutuelle.
3. Activité de données prêtes Actif : produits de données, indexés, étiquetés, entrées et sorties logiques/physiques flexibles, instantanés, prêts et efficaces.
4. Puissance de calcul de données élastique Dynamique : plate-forme de puissance de calcul dynamique et évolutive à grain fin, moteur de données adaptatif intégré à l'échelle mondiale, puissance de calcul à grande échelle et multi-location.
Combinée à l'analyse ci-dessus et à l'arrière-plan d'une stratégie de plate-forme intermédiaire basée sur les données, la plate-forme de données globale peut se transformer en une plate-forme de données sensibles et exporter les capacités de données de la plate-forme Big Data vers le monde extérieur sous la forme d'une autonomisation active.
Dans le passé, la plate-forme Big Data elle-même constituait le goulot d'étranglement de l'autonomisation des données, et les parties prenantes en amont et en aval devenaient de moins en moins réceptives aux demandes d'autonomisation. Face à divers scénarios de données, le développement des données manque de méthodes d'analyse systématique des capacités de la plate-forme.Il ne peut que proposer des demandes de liaison de données plus verticales pour les plates-formes Big Data, puis utiliser le plus petit chemin pour répondre aux besoins de méthodes techniques dispersées. La gestion de l'exploitation et de la maintenance, tout comme le contrôle des ressources et la gestion du système pendant l'exécution, impose diverses exigences à la plateforme Big Data en termes de ressources, d'autorisations, de disponibilité, de stabilité, etc. La plateforme Big Data a du mal à réduire le cycle de vie des données et ne peut que fonctionner à moindre coût, s’assurer que les moyens sont satisfaits tout en écartant la possibilité et la voie de l’évolution.
Après la transformation, la couche habilitante du Big Data elle-même adopte des moyens d'accès unifiés à faible coût, un moteur de puissance de calcul élastique unifié à haute performance, une gestion unifiée de l'entrepôt de données et un contrôle unifié des ressources et d'autres mesures de gestion et de contrôle, et a également une gouvernance des données en bas. L'amélioration de la maturité interne consiste à aligner de manière bidirectionnelle les métadonnées, les règles, les normes, etc. avec la gestion et le contrôle des données. À l'heure actuelle, le développement des données peut être investi de manière flexible dans divers scénarios d'application de données à la demande avec des capacités standardisées, depuis les scénarios de traitement des données qui nécessitent une puissance de calcul massive jusqu'à l'affichage des données et la sortie d'indicateurs avec des associations logiques complexes et des exigences de rapidité élevées. Dans le même temps, les exigences et le contrôle de la gestion de l'exploitation et de la maintenance sont directement mis en œuvre dans la couche d'autonomisation du Big Data, ce qui permet une autonomisation et un contrôle affinés du développement des données en termes d'autorisations, de stockage, de calcul, etc. L'architecture de la plate-forme Big Data elle-même peut également se concentrer sur l'intégration de davantage de technologies adaptées aux scénarios de données sensibles et les unifier dans le centre de données.
À ce stade, les quatre objectifs principaux de la couche d'autonomisation du Big Data, « amélioration de l'efficacité et contrôlabilité », ont été définis comme suit :
- Contrôle : la contrôlabilité est la bouée de sauvetage des scénarios financiers, satisfaisant tous les aspects des autorisations de données, des quotas de ressources, de l'audit et de la surveillance. Grâce à des capacités fines de gestion et de contrôle des données, il offre la possibilité d'une gestion et d'un contrôle affinés des données, est compatible avec la gestion et le contrôle de sources de données hétérogènes multidomaines et sert de condition préalable à des données contrôlables et ouvertes. En termes de gestion et de contrôle des ressources, il est possible de distinguer finement les différences de gestion et de contrôle des ressources et des autorisations de chaque utilisateur final de chaque ligne de données, et de contrôler finement les paramètres de réglage d'exécution. Fournissez une collecte et un contrôle d’audit intégrés, et améliorez les capacités d’exploitation des services et de positionnement des requêtes.
- Can : itération durable, évolution durable, disponibilité. Sous l'interface d'accès informatique unifiée, la base continue d'améliorer la version du moteur et la pile technologique globale du Big Data, est compatible avec les sources de données hétérogènes multi-domaines et les détails sous-jacents au stockage, et exploite pleinement les réalisations de l'industrie en matière de CBO, RBO, RBO, etc. pour améliorer continuellement le plan d'exécution. L'optimisation dans le processus permet d'optimiser itérativement les données de stock et les opérations de calcul des stocks. L'évolution durable signifie l'évolutivité et l'expansion d'un plus grand nombre de technologies Big Data et de services clés de coordination du cycle de vie, ainsi que la capacité d'intégrer des données et des services standardisés avec des capacités plus flexibles. La disponibilité signifie consolider davantage les capacités de haute disponibilité à tous les niveaux, y compris la couche moteur et la couche d'exécution, sur la base des capacités de stockage et de calcul distribuées d'origine, offrant aux scénarios de données des capacités d'exploitation fiables et des capacités de garantie de puissance de calcul.
- Efficacité : Améliorer l'efficacité tout au long du cycle de vie, en couvrant l'amarrage et l'autonomisation des données en amont (préparation des accès, etc.), pendant le processus (efficacité opérationnelle, contrôle des autorisations et mise en œuvre du filtrage des lignes), et après (audit, collecte de traçabilité, informations supplémentaires informations sur les métadonnées, etc.) ). Améliorez l’efficacité de l’exécution et reflètez en permanence les avantages apportés par l’optimisation des plans d’exécution en utilisant les mêmes données et la même logique. Améliorez l'efficacité du travail de développement des données et utilisez l'abstraction SQL pour vous concentrer sur la logique des données afin de terminer le traitement des requêtes des données, réduisant ainsi considérablement les exigences en matière d'environnement d'accès et la préparation des conditions.
- Astuce : En prenant en compte les actifs de données existants et les opérations de données comme référence, réduisez l'impact des modifications destructrices sur les actifs de données existants, tout en améliorant considérablement la réactivité et l'efficacité des données. Unifiez la méthode d'accès SQL et l'interface de programmation à faible coût, protégez les détails de l'infrastructure de base des exigences d'exploitation des données d'accès, fournissez une méthode d'accès légère et minimisez les exigences d'environnement linguistique. Unifiez les méthodes d'accueil dans différents scénarios d'utilisation et unifiez les réglages raffinés pour bénéficier à tous les scénarios.
Dans le cadre de l'objectif global d'"améliorer l'efficacité et la couche d'autonomisation du Big Data contrôlable", Apache Kyuubi entre dans notre champ de vision d'évaluation de l'architecture. Apache Kyuubi est souvent utilisé d'abord comme service facultatif pour la couche de passerelle de service SparkSQL. Spark et Spark SQL, en tant que moteurs informatiques matures, stables et en constante évolution, ont de bonnes performances et des capacités d'évolution dans différentes plages de données. Cependant, le positionnement global d'Apache Kyuubi en tant que portail de passerelle de données d'entrepôt lacustre sans serveur multi-tenant distribué lui offre de plus grandes possibilités de mission.
Tout d'abord, il se concentre sur la fourniture d'un modèle de service SQL (mais sans s'y limiter), permettant aux parties d'accès d'exécuter une logique interactive et abstraite plutôt que des tâches spécifiques de manière peu coûteuse, ce qui peut répondre aux besoins potentiels d'évolution et amélioration de l'efficacité; en même temps, afin de Le modèle de séparation des segments de serveur et de moteur de l'architecture principale de base renforce le modèle multi-tenant, qui peut isoler efficacement les besoins d'isolation des sessions des utilisateurs et répondre aux besoins précis de gestion et de contrôle des ressources et de la configuration ; Deuxièmement, le positionnement de compatibilité de Lake Warehouse signifie qu'il peut être basé sur les besoins réels du scénario. Combinaison flexible, différentes fonctionnalités du moteur et formes de stockage de données sous-jacentes inter-domaines, prenant en compte diverses combinaisons de base de plate-forme en constante évolution telles que les tables d'entrepôt, le stockage d'objets, les données. tables Lake, tables intégrées en streaming et par lots ; troisièmement, sa soumission et son exécution approfondies de la logique des données. Le processus spécifique peut être profondément adapté à chaque processus informatique pour faire jouer pleinement les caractéristiques du moteur et fournir des possibilités et le support clé sur site nécessaire. pour les autorisations de données, le traçage des données, la surveillance et la gestion, etc. dans une combinaison flexible de plug-ins.
GF Securities suit l'avancement du projet Apache Kyuubi depuis 2021 avec la conception globale de la mise à niveau de base, et la phase d'évaluation globale a commencé depuis la version 1.2. De nombreuses fonctionnalités d'Apache Kyuubi proviennent de son architecture de base. Le framework multicouche session-namespace-server-engine est resté stable depuis la version 1.0 et continue d'être enrichi et étendu. Apache Kyuubi joue sur une variété de fonctionnalités sur cette base, notamment des méthodes d'accueil et des portails unifiés, la multilocation et l'isolation de session, l'adaptation du moteur suite à l'évolution du moteur Spark, la gestion et le contrôle précis des ressources, ainsi que plusieurs modes d'isolation partagés, qui sont cohérents avec et répondre aux exigences du centre de données.Le positionnement cible et l'orientation de la construction de la couche d'autonomisation des données de NTU.
Construisez une couche d'autonomisation du Big Data dans le centre de données, fournissez des services et des capacités en amont et en aval de manière clé en main et réalisez le succès mutuel de la plate-forme et de l'activité de données grâce à une correspondance architecturale raisonnable. En combinant Kyuubi comme l'une des solutions d'architecture unifiées pour la couche d'activation du Big Data, nous connecterons architecturalement nos attentes et nos objectifs :
1. Accès unifié : utilisation standardisée du pilote JDBC avec le protocole Hive Thrift, prenant en compte un accès à faible coût dans des environnements multilingues. Dans le même temps, les services appropriés sont sélectionnés via l'espace de noms et la découverte de services est fournie sur le pilote JDBC pour assurer une prise en charge haute disponibilité, sans nécessiter une implémentation supplémentaire de la part de l'utilisateur.
2. Capacités SQL unifiées : utilisant SparkSQL en externe, il est compatible avec la syntaxe HiveSQL pour offrir la possibilité d'une transition en douceur des tâches et des actifs de données existants, et fournit des capacités de traitement d'extension de données clés telles que la mise à jour/suppression/fusion via une syntaxe de fonctionnalités supplémentaires et combinées. avec le format de lac de données Iceberg. La centralisation sous-jacente optimise les configurations de lecture et d'écriture, les commutateurs de fonctionnalités, l'activation de l'AQE, etc. en fonction des besoins du scénario.
3. Masquez les détails sous-jacents : 1) Insensiblement compatible avec les tables Iceberg, répondant aux opérations CRUD. 2) Introduire et faire évoluer la version de base du moteur en fonction des besoins de la plate-forme. 1 est la dernière version stable de Spark 3.3 et 2 peut continuer à gérer les moteurs Flink et Trino.
4. Contrôle des autorisations : couverture complète des besoins d'authentification et d'authentification. L'authentification de l'utilisateur est effectuée au point de connexion de la couche serveur pour l'accès des utilisateurs du terminal, avec une combinaison flexible de JDBC, de vérification de jeton et d'autres méthodes. L'authentification pénètre en profondeur dans le moteur d'exécution, fournit un contrôle des autorisations Spark Docking Ranger, détecte les autorisations fines des colonnes de la table de bibliothèque, le filtrage des lignes, le masquage des colonnes et d'autres règles, et intercepte ou prend effet directement dans le plan d'exécution.
5. Prise en charge complète du cycle de vie : contrôle précis des ressources informatiques et réglage unifié des paramètres. Ajustez la limite supérieure des ressources du travail à tout moment par l'utilisateur. Prend en charge l'extraction des relations sanguines au niveau des colonnes et l'alignement des plans d'exécution dans le moteur avec une gestion complète des données. Le cycle de vie des données couvre les composants nécessaires du scénario du plan d'accès et contrôle de manière centralisée les processus clés, tels que l'optimisation de l'écriture des petits fichiers, la limite de quantité de lecture, etc.
Avec Apache Kyuubi comme couche de passerelle de service SQL unifiée, nous pouvons enfin adopter pleinement une série d'évolutions de fonctionnalités clés sur Spark3 que nous observons depuis longtemps, activer et optimiser les paramètres pour les utilisateurs par défaut de manière standardisée et donner à tous les utilisateurs connectés les moyens d'agir. scénarios de données. De cette manière, les capacités de base sont rassemblées pour s’aligner sur les différentes exigences de la couche d’autonomisation du Big Data. Ceux-ci inclus:
- Exécution de requêtes adaptatives Exécution de requêtes dynamiques :
- AQE est l’une des fonctionnalités les plus populaires depuis Spark2.4, et est également la fonctionnalité clé la plus populaire de Spark3. En utilisant Spark3.3, nous bénéficions de la capacité importante d'être activé par défaut (Spark3.2+).
- L'asymétrie et le déséquilibre des données sont l'état normal des données, et AQE améliore considérablement les performances de fonctionnement dans cette situation. Il détermine dynamiquement le nombre de partitions pendant l'exécution et réintègre les capacités de traitement et la distribution des données.
- Cela permet aux requêtes et au traitement des données de se concentrer véritablement sur la logique métier et de réduire le coût en temps du réglage traditionnel de la granularité des tâches.
- Génération de code d'exécution complète WholeStage CodeGen :
- Lors de l'exécution en mode CodeGen, des détails d'exécution approfondis et des statistiques sur le site d'exécution sont générés pour générer le code d'exécution le plus efficace, de sorte que les mêmes actifs de données et la même logique de traitement des requêtes puissent continuer à bénéficier de l'optimisation du moteur pour améliorer les performances opérationnelles et raccourcir les performances. temps d'exécution.
- Allocation dynamique des ressources Allocation dynamique des ressources :
- Pendant la phase d'exécution, les instances d'exécuteur sont demandées et détruites de manière dynamique dans une plage de nombres contrôlable, maximisant ainsi l'utilisation des ressources d'exécution distribuées. Il prend pleinement en compte la demande urgente de services résidents combinée aux ressources de mise à l'échelle élastiques dans le scénario Adhoc, et prend également en compte la libération dynamique des ressources d'exécution sous le traitement des données. Améliorez considérablement la disponibilité globale et la contrôlabilité des ressources.
- DRA avec Shuffle Tracking ne repose pas sur l'allocation dynamique des ressources d'ESS :
- Utilisez ShuffleTracking pour éviter d’utiliser ESS (External Shuffle Service). Depuis longtemps, DRA exige que l'ESS réponde aux besoins de redistribution des exécuteurs.Cela nécessite que chaque nœud d'exécution de chaque cluster distribué installe un service ESS indépendant et expose les ports de communication, ce qui augmente considérablement les coûts et les restrictions d'exploitation et de maintenance. Possibilité d'évolution de version.
- L'utilisation unifiée de ShuffleTracking ne nécessite pas de déploiement indépendant de services et dépend dynamiquement des versions de tâches et de moteurs, ce qui réduit considérablement l'empreinte d'utilisation et les coûts d'exploitation et de maintenance. Il s'agit d'une fonctionnalité expérimentale fournie par Spark3.2+.
Une autre raison importante d'utiliser Kyuubi comme couche d'activation du Big Data est qu'il conserve toujours la combinaison flexible de divers protocoles front-end et services back-end sous la même apparence, c'est-à-dire qu'il expose les services via le serveur, ce qui le rend adapté à différents besoins d'amarrage.Vous pouvez choisir un protocole front-end adapté, tout en gardant la possibilité d'ajouter d'autres moteurs de types et de principes différents.
Actuellement, Apache Kyuubi a mis en œuvre avec succès cette idée architecturale, notamment :
La prise en charge du protocole frontal inclut le protocole HiveThrift, le protocole d'interface HTTP REST, le protocole Mysql (expérimental) et FlightSQL (démonstration de prototype), tandis que le service back-end prend en charge en profondeur Spark3.0+ (chaque composant est compatible avec tous versions principales couvrant 3.0 ~ 3.3), Flink, Trino, Doris (à partir de 1.6), etc., et a commencé à fournir des connecteurs approfondis pour d'autres entrepôts de lac sous-jacents sous Spark et d'autres moteurs, tels que le connecteur Spark DSV2 Hive, etc.
02 Stratégie de mise en œuvre et construction de scénarios pour la couche d'autonomisation du Big Data de Kyuubi
Après avoir expérimenté le positionnement cible de la couche d'activation du Big Data et l'analyse architecturale d'Apache Kyuubi comme l'un des services de base, nous avons commencé à réfléchir à la manière de la mettre en œuvre de manière efficace et fluide. La stratégie d'évolution et la construction de scénarios seront l'ajout d'Apache à la plateforme big data. Les points clés de Kyuubi. Il doit être progressivement connecté pour éviter les changements destructeurs et ne doit pas affecter les données et la logique existantes. Il doit également évoluer en douceur pour devenir un canal clé pour l'interrogation et le traitement des données de base et principales.
Par conséquent, nous avons adopté quatre niveaux pour promouvoir la mise en œuvre d'Apache Kyuubi, en suivant les principes du facile au difficile, de la lecture et de l'écriture, du fermé à l'ouvert, et en fixant des objectifs clairs et des points de vérification à chaque étape clé.
1. Hachures plates : requête ad hoc, requête en lecture seule. Donnez la priorité à l'introduction de Kyuubi en tant que moteur de requête dans le domaine de la couche d'application contrôlable et utilisez SparkSQL comme moteur de requête en lecture seule pour permettre des scénarios d'exploration de données. Et concentrez-vous sur la vérification de la faisabilité des scénarios multi-tenants en mode de partage global SERVER et de l'efficacité de la mise à l'échelle dynamique des ressources Spark DRA.
2. Construction pilote : testez l'eau pour les opérations d'exécution de lots de données en lecture seule et vérifiez les caractéristiques d'amarrage du système. Par exemple, le pilote est utilisé pour l'exécution de lots de qualité des données. Testez la capacité d'ancrer les tâches de traitement de données de syntaxe HiveSQL existantes avec Kyuubi et effectuez l'analyse et l'exécution basées sur la compatibilité SparkSQL.
3. Mise en œuvre mature : promotion ultérieure des opérations de traitement de données à grande échelle pour l'écriture des données. Activez pleinement toutes les combinaisons d'architecture de base attendues, y compris les capacités de référence du système complet telles que Kyuubi, Spark3.3, Iceberg, etc., et vérifiez l'isolation fine des ressources et le contrôle de la configuration aux niveaux UTILISATEUR et CONNEXION dans les scénarios de traitement de données.
4. Ouverture contrôlable : basée sur le principe de l'amarrage automatique du contrôle d'autorité, l'ouverture contrôlable est utilisée pour le traitement et l'exploration des données. Connectez-vous aux règles d'autorisation des données Ranger et appliquez les autorisations de table, de ligne, de ligne et de filtre de bibliothèque. Scénarios d'utilisation flexibles pour le développement de données d'amarrage. Dans le même temps, le traitement et l'exploration des données sont ciblés et isolés, et différentes ressources et stratégies de contrôle sont utilisées pour différents scénarios.
Au cours du processus de recherche et de mise en œuvre de l'architecture, nous avons réalisé que les exigences unifiées pour tous les aspects de la couche d'activation du Big Data et la sélection unique d'Apache Kyuubi ne signifient pas que le même ensemble de services doit être exposé au monde extérieur via le même port, mais qu'il devrait être basé de manière flexible sur les besoins de la combinaison du scénario pour atteindre un équilibre entre ressources et isolement. Utilisez pleinement chaque mode de partage pour réduire le temps de démarrage et d'arrêt, intégrer le problème de positionnement de l'interface utilisateur Kyuubi sur le moteur et répondre pleinement aux besoins d'isolation des ressources, d'isolation de configuration, etc. Parmi eux, nous devons diviser et utiliser les différents modes de partage dans Apache Kyuubi en fonction des besoins réels, par exemple :
- Dans des scénarios tels que les requêtes ad hoc et les outils BI, envisagez d'utiliser le mode SERVEUR pour éviter les opérations aller-retour répétées telles que la transmission de paquets, le démarrage et l'arrêt et l'allocation de ressources requises pour la soumission des tâches du moteur. les capacités d'authentification des utilisateurs finaux sont conservées dans ce mode.
- Scénarios de traitement des données, ETL, de collecte de données et d'inférence : envisagez de diviser les instances de moteur utilisées par les utilisateurs et les sessions, en utilisant respectivement le mode USER et le mode CONNECTION.
Dans le scénario d'opération de traitement de données, la couche permettant le Big Data a d'abord changé les idées et les méthodes de traitement des données et les capacités d'accueil de développement via Kyuubi. On peut s'attendre à ce que l'efficacité humaine du développement des données augmente de plus de 100 %. Le développement d'un nouveau type de données peut être achevé en quelques jours sur une période de plusieurs semaines. La préparation peut être achevée en une journée dans les délais les plus rapides. , et le développement et la vérification du lien complet peuvent être terminés en une semaine. En termes d'avantages spécifiques, le développement de tâches de traitement de données ne nécessite plus une compréhension détaillée des langages, des moteurs, des versions, des commutateurs de fonctionnalités, du réglage des clés, etc., mais peut se concentrer sur la logique de base et décrire de manière abstraite l'intention de l'interrogation et du traitement des données via SQL. Soumettez la langue à Kyuubi via le pilote JDBC et c'est fait. En particulier, la fonctionnalité JDBC sous la JVM est disponible immédiatement. Vous pouvez terminer la préparation en faisant simplement référence à la bibliothèque du pilote. D'autres langages tels que Python peuvent également se connecter facilement au pilote de diverses manières.
Dans les scénarios de requêtes ad hoc et de requêtes en libre-service d'exploration de données, et en tant que moteur non préféré, environ 20 % des requêtes HiveSQL utilisent activement Kyuubi (SparkSQL). En termes d'avantages spécifiques, dans l'hypothèse de coûts d'utilisation supplémentaires nuls, l'expérience et les actifs à plusieurs niveaux peuvent évoluer et augmenter en douceur, notamment : la réutilisation des requêtes de scénario HiveSQL produitisées existantes, la réutilisation de Hive UDF et la réutilisation du développement de données. Capacité et expérience dans HiveSQL. , réutilisation des ressources et capacités originales de l'entrepôt de données Hive, etc. Et l'exploration et le développement des données peuvent continuer à être effectués en utilisant le même ensemble de syntaxe de HiveSQL, ce qui évite grandement la conversion manuelle fastidieuse de la syntaxe entre Tinro/Hive-Hive. Pour les scénarios courants de traitement de données de travail externe et de récupération de données, nous continuons à nous concentrer sur Kyuubi en tant qu'entrée de lecture et d'écriture d'entrepôt de données unifiée. Ici, PySpark/Spark est utilisé comme client de liaison à titre d'exemple.
- La méthode d'accès PySpark complète l'implémentation du plug-in Spark Hive Dialect pour résoudre le problème d'incohérence entre le dialecte de dénomination des colonnes SparkSQL et le style HiveSQL, et résout le problème de conversion JDBC RDD.
- Le SQL pour la préparation et le traitement des données est soumis à Kyuubi via JDBC pour un traitement unifié dans l'entrepôt de données.
- L'extraction de données à l'aide de JDBC doit résoudre les problèmes de performances et d'accumulation de résultats intermédiaires. SparkRDD pousse l'opération autant que possible vers Kyuubi pour une exécution sur Spark. L'ensemble de résultats en cours d'exécution est obtenu séquentiellement via la méthode micro-batch Resultset. pour éviter l'accumulation de Spark sur le pilote sous Kyuubi. Pour tous les résultats de données, activez le commutateur incrémental_collection pour disperser la pression et obtenir les données de partition dans les résultats lot par lot.
- Toutes les connexions de données sont effectuées sous authentification de l'utilisateur et vérification des autorisations de données. Les autorisations de données sont basées sur les règles d'authentification sensibles au service Ranger et sont alignées sur une gestion et un contrôle complets des données.
- En tant qu'utilisateur, PySpark/Spark maintient des capacités d'exécution distribuées. Vous pouvez utiliser un cluster Spark autonome auto-construit ou le mélanger avec YARN dans des conditions contrôlables.
Les documents de méthode d'accès PySpark, les documents d'accès PyHive, le plug-in Spark Hive Dialect, etc. impliqués dans le processus ci-dessus ont tous été soumis à la communauté.
Dans l'ensemble, nous avons construit une couche d'autonomisation du Big Data via Apache Kyuubi, qui a considérablement amélioré l'efficacité du développement, l'efficacité opérationnelle ainsi que les niveaux de gestion et de contrôle :
● Efficacité opérationnelle augmentée de 50 % : par rapport au moteur Hive MR dans des scénarios de traitement de données typiques, le temps d'exécution de l'ensemble du lien est raccourci de 30 à 50 %, et certains scénarios peuvent même atteindre une amélioration de 60 à 70 %, reflétant pleinement l'optimisation du plan d'exécution du moteur.
● L'efficacité du développement a augmenté de 100 % : l'efficacité humaine dans le développement de nouveaux types de données a été améliorée, du niveau hebdomadaire au niveau quotidien, raccourcissant considérablement le cycle d'exploration des scénarios de données et le temps d'ancrage de la logique des données.
● Les capacités de gestion de l'exploitation et de la maintenance ont été améliorées de 100 % : la gestion, le contrôle et l'adaptabilité de l'exploitation et de la maintenance ont été améliorés. Ce que vous voyez est ce que vous gérez. Des ressources d'exploitation aux autorisations de contenu de données en passant par l'optimisation de la configuration, la gestion et le contrôle sont directement connectés. au scénario de données, permettant une gestion et un contrôle précis du cycle de vie complet.
03 Idée globale de gestion et de contrôle intégrés des autorisations de données
Dans l'identification de l'objectif « d'améliorer l'efficacité et la contrôlabilité » de la couche d'autonomisation du Big Data, la contrôlabilité est en fait l'étape la plus prioritaire. Dans le processus de mise en œuvre spécifique, l'amarrage contrôlable est la dernière étape, qui implique des éléments et composants supplémentaires qui doivent être davantage alignés sur le cycle de vie des données et convertis en stratégies de mise en œuvre grâce à un contrôle intégré des autorisations de données.
En tant que membre du secteur financier, qu’il s’agisse d’exigences réglementaires ou de besoins d’isolement de l’entreprise, le contrôle des autorisations de données est une condition préalable à l’autonomisation et à l’ouverture des données. Par conséquent, la stratégie du centre de données nécessite la mise en œuvre d’un contrôle d’autorité intégré :
1. En prenant en compte les autorisations de données, la même politique doit pouvoir se connecter à différents moteurs de la couche habilitante du Big Data, tels que Spark, Trino, etc.
2. Capable d'autoriser des données dans différentes dimensions et granularités, avec des autorisations au niveau des colonnes de la table de base de données en place.
3. Capable de répondre efficacement aux exigences raffinées de gestion et de contrôle des données, notamment le filtrage des lignes de données dans les tableaux, le masquage des colonnes, etc.
4. Être capable de connecter pleinement les résultats accumulés de la gouvernance des données, y compris les définitions de classification et de classification, les normes de données, etc. pour la gestion et le contrôle des données.
5. Prise en charge des autorisations qui peut être différenciée avec différentes stratégies dans différents scénarios de données : d'une part, l'entrepôt de données unifié peut obtenir différentes autorisations sous différents angles dans différents scénarios, et gérer et contrôler selon différentes méthodes de processus ; d'autre part, il peut différencier les autorisations à des fins différentes. Les règles d'autorisation réduisent le nombre de règles dans un seul scénario et améliorent l'efficacité de la correspondance des règles d'exécution.
Sur cette base, la couche habilitante du Big Data doit répondre aux besoins induits par le contrôle intégré des droits sur les données :
1. Appuyez-vous sur un service d'autorisation Big Data unifié pour contrôler uniformément les règles d'autorisation pour différents scénarios, comme le service Ranger.
2. La gestion, le contrôle et l'audit sont effectués de manière centralisée au sein du service intégré de contrôle des droits.
3. Tout en conservant un accès à faible coût, authentifiez efficacement l’identité des utilisateurs selon différents scénarios et méthodes.
4. Chaque moteur de la couche d'autonomisation des données utilise des plug-ins d'accueil ciblés, qui peuvent se connecter aux règles d'autorisation des données, appliquer des règles dans les plans d'authentification et d'exécution des données et intercepter les opérations non autorisées.
5. La couche d'autonomisation des données doit être capable de répondre à l'extraction de lignage au niveau des colonnes, à la perception des métadonnées, etc., et de fournir des informations sur la perception des changements de métadonnées de l'entrepôt de données pour une gestion complète des données.
6. La gestion intégrée des données synchronise ensuite les règles et spécifications de gestion dans des services intégrés de contrôle des droits, tels que la classification et le classement.
Dans l'écosystème actuel des systèmes Big Data, Apache Ranger est peut-être le seul service de contrôle des autorisations Big Data qui continue d'itérer, en particulier dans le contexte où le projet Apache Sentry a cessé sa maintenance après 2018. Le projet Apache Ranger fournit un docking avec différents moteurs mais n'inclut pas la prise en charge du moteur Spark et du système de définition de règles correspondant. Le plug-in Apache Kyuubi Authz est le seul choix pour s'interfacer avec la stratégie de contrôle d'accès Apache Ranger dans l'écosystème Spark. Sa définition de règle suit le style de règle Hive dans Ranger et prend entièrement en charge toutes les fonctionnalités clés de Ranger, couvrant les autorisations de colonne de table de bibliothèque, le filtrage de lignes, le masquage de colonne et d'autres règles de contrôle. GF Securities participe à l’évolution continue du plug-in Authz d’Apache Kyuubi :
●Pour la première fois, il a achevé l'adaptation à l'API DataSource V2 progressivement améliorée dans Spark 3.x, couvrant plus de 20 commandes et leurs plans d'exécution, et reste compatible avec les différences de détails de Spark 3.0-3.3.
● Pour la première fois, le propre plan d'exécution d'Iceberg est pris en charge, couvrant MergeInto, UpdateFrom et d'autres commandes V2 hétérogènes réécrites par les plug-ins Iceberg.
● Il fournit également un mode d'adaptation générale avec autorisation de DataSource V2, ce qui facilite l'adaptation pour connecter davantage de commandes de plug-in de lac de données et évoluer en permanence en fonction des changements de version du moteur.
● Autres traitements d'authentification liés aux vues temporaires/permanentes et aux fonctions temporaires/permanentes
La clé du contrôle intégré des droits sur les données a toujours été « d’unifier les entrepôts de données et le contrôle des droits ». La première nécessite l'unification des métadonnées de base et de l'entrepôt de données, tandis que la seconde nécessite que les règles d'autorisation des données puissent être mises en œuvre dans différents moteurs de données de couche habilitante et atténuer les différences.
La même politique de contrôle des autorisations de données prend effet dans tous les moteurs, et nous utilisons des moyens complets pour la satisfaire dans différents moteurs. Premièrement, HiveServer2 continue d'être un moteur de données disponible, utilisant le plug-in Hive fourni par Ranger et effectuant une intervention d'autorisation via HiveAuthorizer. Deuxièmement, utilisez le plug-in Kyuubi Authz pour connecter Kyuubi au moteur Spark. Ensuite, le moteur Trino est conservé pour continuer à prendre en charge la requête de la syntaxe Trino existante. Sur la base de l'utilisation du plug-in Trino fourni par Ranger, un développement secondaire est effectué et le même contrôle de politique d'autorisation utilisé dans Hive et Spark. est utilisé pour des catalogues spécifiques. Pour la partie stockage streaming dans l'entrepôt de données unifié, nous avons adapté Kafka de Ranger pour répondre aux exigences de connexion et d'authentification SASL/SCRAM.
À ce stade, le système de contrôle de puissance intégré est connecté.
04 Introduction du plug-in Spark d'authentification Kyuubi Authz et nouvelles fonctionnalités de Docking Ranger2.3
Comme mentionné précédemment, le service Ranger lui-même ne fournit pas d'accès aux données par le plug-in Spark. Kent Yao a précédemment fourni le plug-in de sécurité Spark Docking Ranger dans Apache Submarine, qui a été refactorisé et intégré à ce projet après l'open source Apache Kyuubi. À partir de la version 1.6.0, Apache Kyuubi fournit le plug-in Authz, qui est le seul choix pour s'interfacer avec la stratégie de contrôle d'accès Apache Ranger dans l'écosystème Spark. Sa définition de règle suit le style de règle Hive dans Ranger et prend entièrement en charge toutes les fonctionnalités clés de Ranger, couvrant les autorisations de colonne de table de bibliothèque, le filtrage de lignes, le masquage de colonne et d'autres règles de contrôle.
L'image ci-dessus est uniquement à titre d'illustration et n'est pas utilisée comme référence pour une structure de code spécifique.
Le mécanisme global du plug-in d'authentification Authz d'Apache Kyuubi est le suivant :
1. Activez le plug-in Authz via le mécanisme de plug-in SQL de Spark et injectez divers optimiseurs de contrôle d'accès, notamment RuleAuthorization, etc.
2. Effectuez le mappage des fonctionnalités et l'extraction des ressources sur les commandes SparkSQL et leurs plans d'exécution, et terminez l'analyse et la construction de la demande d'autorisation des commandes V1, V2 et autres dans PrivilegeBuilder.
3. Le plug-in Authz intègre le RangerBasePlugin, le composant principal du client Ranger. Grâce à cela, les règles de contrôle d'accès, les politiques, les informations utilisateur, etc. peuvent être régulièrement extraites de l'interface REST backend Ranger Admin et chargées dans la mémoire pour une utilisation ultérieure, et mise en cache en même temps.Garantie locale de continuité de service.
4. Effectuez la correspondance de règles et l'authentification sur les ressources d'entité impliquant le contrôle d'accès, qui prend en charge AccessRequest pour vérifier si les autorisations d'accès sont disponibles, l'application de règles de filtrage de lignes de filtre au niveau des lignes, le masquage des données au niveau des colonnes de masquage des données, etc.
Plus précisément, une règle de données Ranger complète le contrôle des autorisations basé sur les utilisateurs et les rôles RBAC à travers trois éléments principaux.
Une règle de contrôle des autorisations Ranger accorde des autorisations spécifiques aux ressources par utilisateur/rôle.
1. Ressources : Définir les ressources en trois dimensions : bibliothèque, table et colonne via des dimensions standard, prenant en charge la correspondance floue. Dans ce cadre, la gestion comprend les bases de données, les tables de données, les colonnes de données, les UDF, etc.
2. Utilisateurs et rôles : définissez des utilisateurs, des rôles et des groupes d'utilisateurs, liez des relations mutuelles, puis sélectionnez une plage d'autorisation à différentes granularités. Il peut exister une relation un-à-plusieurs entre des utilisateurs et des rôles, des groupes d'utilisateurs et des rôles d'utilisateur, et des rôles d'utilisateur et des rôles d'utilisateur. La différence entre les groupes d'utilisateurs et les rôles d'utilisateur réside dans le fait que les groupes d'utilisateurs peuvent avoir leurs propres attributs et que les groupes d'utilisateurs ne peuvent pas être liés à eux-mêmes.
3. Autorisations : opérations d'autorisation spécifiques accordées, y compris diverses autorisations d'opération accordées par l'accès aux ressources correspondantes, les règles de filtrage des lignes de données de filtrage au niveau des lignes et le DataMasking pour le masquage des données des colonnes spécifiées.
Ranger résume en outre les trois types de règles ci-dessus et fournit en outre des fonctionnalités générales telles que la période de validité, l'activation et la description. Les règles d'accès accordent diverses autorisations d'opération aux ressources correspondantes, telles que les autorisations SELECT/UPDATE des tables de bibliothèque, etc. Les règles de filtrage au niveau des lignes définissent les règles de filtrage des lignes de données. Différentes règles de filtrage peuvent être spécifiées en fonction de différents objets d'autorisation, et l'UDF peut être utilisée. DataMasking effectue le masquage des données sur les colonnes spécifiées.
Dans des applications spécifiques, les autorisations pour différentes ressources peuvent souvent être accordées de manière flexible. Par exemple, pour exposer des données spécifiques à l'extérieur, vous pouvez envisager d'utiliser l'autorisation d'accès sous forme de tableau dans la vue permanente pour maintenir l'association dans la logique perçue par l'utilisateur final, et en même temps, effectuer un filtrage au niveau des lignes sur cette donnée. vue pour contrôler la portée des données impliquées. De plus, le DataMasking peut être effectué sur la vue pour enfin mettre en œuvre des règles de masquage de données unifiées pour les données sensibles, évitant ainsi une intervention directe dans la table de données sous-jacente et l'impossibilité de terminer l'association.
Dans la couche habilitante du Big Data, nous avons besoin de différentes combinaisons « authentification-authentification » pour gérer différents scénarios.
La première consiste à traiter avec différents utilisateurs. Par exemple, les utilisateurs finaux utilisent un compte + un jeton pour compléter l'authentification de l'utilisateur via JDBC ou LDAP, tandis qu'en même temps, les utilisateurs exécutés par lots utilisent des mots de passe de compte, etc., pour s'authentifier via JDBC.
Deuxièmement, différentes stratégies de contrôle des droits sont utilisées dans différents scénarios. Dans le scénario de requête en libre-service pour les utilisateurs finaux, les règles les plus fines sont utilisées pour contrôler le comportement de l'utilisateur. Dans le scénario d'exécution de lots, une autorisation granulaire est accordée aux utilisateurs. en fonction des besoins de traitement des données. Réduire la pression sur le nombre de règles, réduire la mémoire occupée lors de l'exécution et le temps nécessaire à l'authentification.
GF Securities fournit un plug-in d'authentification JDBC pour Apache Kyuubi. D'une part, il est très facile à utiliser et peut se connecter rapidement à RMDBS pour compléter l'authentification, répondant aux exigences générales des bases de données communes pour les détails d'authentification. Le cryptage et la signature peuvent être rapidement complétés en mode SQL. D'autre part, dans le scénario d'authentification de génération dynamique de jetons, vous pouvez également vous connecter rapidement à des bases de données en mémoire telles que H2 pour éviter de déployer des méthodes de base de données et effectuer une série d'opérations d'authentification telles que la signature, le cryptage et la vérification de validité via SQL. . Les composants et la documentation ont été soumis à la communauté.
Les captures d'écran sont uniquement à titre d'illustration
Après avoir effectué la connexion avec diverses règles de contrôle des droits, la page d'audit Ranger peut nous aider à contrôler de manière globale les différentes ressources de données accessibles par les utilisateurs finaux de divers moteurs dans une perspective unifiée, y compris les tables de base de données, les UDF, etc., ainsi que les moteurs correspondants. et le calendrier des opérations, etc.
Une nouvelle fonctionnalité clé d'Apache Ranger 2.3 est la nouvelle condition de filtrage des lignes qui prend en charge les macros pour la correspondance dynamique des attributs utilisateur, ce qui est particulièrement utile. Cette fonctionnalité peut réduire considérablement le nombre de règles de filtrage de lignes, réutiliser efficacement les attributs des utilisateurs, etc., et conserver la possibilité d'autoriser les utilisateurs avec différentes granularités.
Dans le filtrage au niveau des lignes, les versions précédentes ne pouvaient spécifier que des règles de filtrage complètes distinctes pour chaque autorisation. Par exemple, pour filtrer la table de données en fonction de plusieurs ID d'indicateur différents spécifiés par l'utilisateur, vous devez les écrire un par un, par exemple index_id dans ( "1", "7", "9"...) etc. À l’heure actuelle, si chaque personne ou rôle a des détails de condition légèrement différents, plusieurs règles de filtrage de lignes différentes doivent être définies à plusieurs reprises et ne peuvent pas être réutilisées.
Avec la prise en charge de RANGER-3605 et RANGER-3550, vous pouvez utiliser cette fonctionnalité pour définir la condition de filtrage de ligne comme index_id dans ${{USER.allowIndexIds}}, ce qui peut découpler les règles de filtrage de ligne et l'autorisation, et définir les attributs spécifiques. La valeur est placée sous l'attribut utilisateur pour être réutilisée.
Ranger prend également en charge d'autres macros, telles que l'obtention d'attributs de groupe d'utilisateurs, la détermination si un utilisateur appartient à un groupe d'utilisateurs spécifique, etc. Il est recommandé que l'utilisation des macros se réfère à la description du problème Ranger ci-dessus.
La nouvelle interface et les fonctionnalités UserStore sont étroitement liées aux fonctionnalités ci-dessus d'Apache Ranger 2.3, couvrant l'extraction des attributs utilisateur, les relations utilisateur-groupe d'utilisateurs, etc. Les avantages liés à cela sont que les groupes d'utilisateurs peuvent être autorisés, ce qui réduit considérablement le nombre de règles d'autorisation. Dans le même temps, comme les groupes d'utilisateurs peuvent avoir leurs propres capacités de définition d'attributs, ils se complètent en combinaison avec des capacités de macro de filtrage de lignes.
Nous soumettrons les commutateurs de capacité pertinents à la documentation de Kyuubi pour une référence facile.
05 Perspectives et travaux de suivi
En tant que projet open source écologique de premier plan pour le Big Data dont l'incubation a rapidement été achevée, Apache Kyuubi positionne avec précision la niche écologique et l'intégration architecturale du Big Data, et présente une évolution technologique et une valeur commerciale bonnes et continues. Nous continuerons d'explorer et de mettre en pratique la pratique et l'application d'Apache Kyuubi dans la couche d'autonomisation du Big Data dans davantage de scénarios. Y compris l'introduction du moteur Flink pour explorer l'utilisation de scénarios informatiques en streaming et sa combinaison avec FlinkSQL pour éliminer les goulots d'étranglement dans la phase d'exploration des données en streaming ; l'amélioration de diverses fonctionnalités JDBC non implémentées par KyuubiHiveDriver pour résoudre le problème que Spark/PySpark ne peut écraser que dans écriture de scénarios ; expansion de plus en plus Les fonctionnalités FE efficaces résolvent les goulots d'étranglement et l'efficacité de l'accès aux données pour obtenir une gamme plus large de fonctionnalités d'accueil, telles que l'amélioration du protocole MySQL, l'amarrage du protocole PG, etc., et des méthodes d'accès aux données plus efficaces, telles que la vectorisation et l'étape accès tels que l'amélioration de FlightSQL.Count signifie.
Parallèlement, dans le plug-in de contrôle d'accès Authz, dans lequel nous sommes principalement impliqués, nous favoriserons davantage l'évolution de ses capacités clés. Tout d'abord, pour résoudre le problème actuel de la prise en charge d'un seul ensemble de stratégies de contrôle des droits, à mesure que DataSourceV2 et plusieurs catalogues ont progressivement mûri, il est devenu particulièrement critique de permettre à différents catalogues d'utiliser différentes règles de contrôle des droits. Deuxièmement, il dissocie l'analyse des commandes et du contrôle des droits pour renforcer son adaptabilité dans différents plans d'exécution de différents composants, fournit des plug-ins dynamiques basés sur les définitions SPI et étend davantage l'encapsulation de commandes privées et les plans d'exécution d'autres plug-ins et autres composants, et Permet la coexistence, par exemple, de commandes privées et de plans d'exécution à Paimon, Hudi, Delta Lake, Amoro, etc.
Apache Kyuubi continue de se développer en profondeur dans divers domaines et a désormais été mis en œuvre avec succès dans des centaines d'entreprises de fabricants Internet et informatiques, de sociétés de valeurs mobilières et d'autres secteurs à travers le monde, notamment GF Securities et Huatai Securities. En participant à la contribution d'Apache Kyuubi, chez GF Securities, sur la base de nos propres scénarios et vision stratégique des données, nous avons soumis des contributions et des révisions que nous avons promues et auxquelles nous avons participé, et avons activement communiqué et coopéré avec la communauté. Au cours de cette période, nous avons reçu un beaucoup d'aide de la part des committers, des contributeurs et des utilisateurs. , des conseils et du soutien.