Ce document est destiné aux opérateurs et aux administrateurs informatiques qui souhaitent configurer un accès sécurisé aux données pour les analystes de données à l'aide d'outils d'informatique décisionnelle tels que Tableau et Looker. Il ne fournit pas de conseils sur l'utilisation des outils d'informatique décisionnelle ni sur l'interaction avec les API Dataproc.
Cet article constitue la première partie d'une série qui vous aide à créer une solution de bout en bout pour offrir aux analystes de données un accès sécurisé aux données à l'aide des outils d'informatique décisionnelle. Ce document présente les concepts suivants :
- Une suggestion d'architecture.
- Vue d'ensemble des limites, des interactions et de la mise en réseau des composants au sein de l'architecture.
- Vue d'ensemble de l'authentification et de l'autorisation au sein de l'architecture.
La deuxième partie de cette série, intitulée Connecter votre logiciel de visualisation à Hadoop sur Google Cloud, vous explique comment configurer l'architecture sur Google Cloud.
Architecture
Le schéma suivant illustre l'architecture et le flux d'événements expliqués dans ce document. Pour plus d'informations sur les produits utilisés dans cette architecture, consultez la section Composants d'architecture.
- Les applications clientes se connectent via Java Database Connectivity (JDBC) à un point d'entrée unique sur un cluster Dataproc. Le point d'entrée est fourni par Apache Knox, qui est installé sur le nœud maître du cluster. La communication avec Apache Knox est sécurisée par TLS.
- Apache Knox délègue l'authentification via un fournisseur d'authentification à un système tel qu'un annuaire LDAP.
- Après l'authentification, Apache Knox achemine la requête de l'utilisateur vers un ou plusieurs clusters de backend. Vous définissez les routes et la configuration en tant que topologies personnalisées.
- Un service de traitement des données, tel qu'Apache Hive, écoute le cluster de backend sélectionné et traite la requête.
- Apache Ranger intercepte la requête et détermine si elle doit être traitée en se basant sur la validité de l'autorisation de l'utilisateur.
- Si la validation réussit, le service de traitement des données analyse la requête et renvoie les résultats.
Composants d'architecture
L'architecture est constituée des composants suivants.
- La plate-forme Hadoop gérée :
- Dataproc. Dataproc est un service Apache Spark et Apache Hadoop géré par Google Cloud qui vous permet de bénéficier d'outils de données Open Source pour le traitement par lot, l'émission de requêtes, le streaming et le machine learning. Dataproc est la plate-forme au cœur de la solution décrite dans ce document.
- Authentification et autorisation des utilisateurs :
- Apache Knox. Apache Knox agit comme point d'accès HTTP unique pour tous les services sous-jacents d'un cluster Hadoop. Apache Knox est conçu comme un proxy inverse avec des fournisseurs connectables pour l'authentification, l'autorisation, l'audit et d'autres services. Les clients envoient des requêtes à Knox et, en fonction de l'URL et des paramètres de la requête, Knox l'achemine vers le service Hadoop approprié. Comme Knox est un point d'entrée qui gère de manière transparente les requêtes des clients et masque la complexité, il se trouve au centre de l'architecture.
- Apache Ranger. Apache Ranger fournit des autorisations précises qui permettent aux utilisateurs d'effectuer des actions spécifiques sur les services Hadoop. Il audite également l'accès des utilisateurs et met en œuvre des actions administratives.
- Moteurs de traitement :
- Apache Hive. Apache Hive est un logiciel d'entreposage de données qui permet d'accéder à des ensembles de données volumineux et de les gérer dans un espace de stockage distribué en utilisant SQL. Apache Hive analyse les requêtes SQL, effectue une analyse sémantique et crée un graphe orienté acyclique (DAG, Directed Acyclic Graph) des étapes que le moteur de traitement doit exécuter. Dans l'architecture présentée dans ce document, Hive sert de point de traduction entre les requêtes utilisateur. Il peut également faire partie des multiples moteurs de traitement. Apache Hive est omniprésent dans l'écosystème Hadoop et permet aux professionnels qui connaissent le SQL standard d'analyser des données.
- Apache Tez. Apache Tez est le moteur de traitement chargé d'exécuter les DAG préparés par Hive et de renvoyer les résultats.
- Apache Spark. Apache Spark est un moteur d'analyse unifié conçu pour le traitement des données à grande échelle et compatible avec l'exécution de DAG. L'architecture utilise le composant Spark SQL d'Apache Spark pour démontrer la flexibilité de l'approche présentée dans ce document. La seule restriction est que Spark n'est pas compatible avec le plug-in Ranger officiel. Pour cette raison, l'autorisation doit être effectuée via les LCA de haut niveau d'Apache Knox plutôt que d'utiliser les autorisations plus précises fournies par Ranger.
Présentation des composants
Les sections suivantes décrivent plus en détail chacun des composants. Vous découvrirez également comment les composants interagissent les uns avec les autres.
Applications clientes
Les applications clientes incluent des outils permettant d'envoyer des requêtes à un point de terminaison REST HTTPS, mais qui n'acceptent pas nécessairement l'API Jobs de Dataproc. Les outils d'informatique décisionnelle tels que Tableau et Looker disposent de pilotes HiveServer2 (HS2) et JDBC Spark SQL qui peuvent envoyer des requêtes via HTTP.
Dans ce document, nous partons du principe que les applications clientes sont externes à Google Cloud et s'exécutent dans des environnements tels qu'un poste de travail d'analyste, sur site ou sur un autre cloud. Ainsi, la communication entre les applications clientes et Apache Knox doit être sécurisée via un certificat SSL/TLS signé par une autorité de certification ou par un certificat autosigné.
Point d'entrée et authentification des utilisateurs
Les clusters de proxy sont un ou plusieurs clusters Dataproc à longue durée qui hébergent la passerelle Apache Knox.
Apache Knox sert de point d'entrée unique pour les requêtes clientes. Knox est installé sur le nœud maître du cluster de proxy. Knox fournit une terminaison SSL, délègue l'authentification utilisateur et transfère la requête à l'un des services de backend.
Dans Knox, chaque service de backend est configuré dans ce que l'on appelle une topologie. Le descripteur de topologie définit les actions et autorisations suivantes :
- La manière dont la méthode d'authentification est déléguée pour un service.
- L'URI vers lequel le service de backend transfère les requêtes.
- Listes de contrôle d'accès (LCA) par service simples.
Knox vous permet d'intégrer l'authentification aux systèmes de gestion d'entreprise et aux systèmes de gestion d'identité sur le cloud. Pour configurer l'authentification des utilisateurs pour chaque topologie, vous pouvez utiliser des fournisseurs d'authentification. Knox utilise Apache Shiro pour s'authentifier par défaut sur un serveur LDAP ApacheDS local de démonstration.
Vous pouvez également choisir Knox pour utiliser Kerberos. Dans le schéma précédent, vous pouvez voir un serveur Active Directory hébergé sur Google Cloud en dehors du cluster.
Pour en savoir plus sur la connexion de Knox à des services d'authentification d'entreprise tels qu'un serveur ApacheDS externe ou Microsoft Active Directory (AD), consultez le guide d'utilisation d'Apache Knox et la documentation Managed Active Directory et Federated AD de Google Cloud.
Pour le cas d'utilisation décrit dans ce document, tant qu'Apache Knox fait office de contrôleur unique vers les clusters du proxy et du backend, vous n'avez pas à utiliser Kerberos.
Moteurs de traitement
Les clusters de backend sont les clusters Dataproc hébergeant les services qui traitent les requêtes des utilisateurs. Les clusters Dataproc peuvent procéder à un autoscaling du nombre de nœuds de calcul afin de répondre à la demande de votre équipe d'analystes sans reconfiguration manuelle.
Nous vous recommandons d'utiliser des clusters Dataproc à longue durée de vie dans le backend. Les clusters Dataproc à longue durée de vie permettent au système de traiter les requêtes des analystes de données sans interruption. Si le cluster n'a besoin de traiter que les requêtes pendant une brève période, vous pouvez également utiliser des clusters spécifiques à la tâche, également appelés clusters éphémères. Les clusters éphémères peuvent également être plus rentables que les clusters à longue durée de vie.
Si vous utilisez des clusters éphémères, pour éviter de modifier la configuration de la topologie, veillez à recréer les clusters dans la même zone et sous le même nom. L'utilisation des mêmes zones et noms permet à Knox d'acheminer les requêtes de manière transparente à l'aide du nom DNS interne du nœud maître lorsque vous recréez le cluster éphémère.
HS2 est responsable du traitement des requêtes utilisateur adressées à Apache Hive. HS2 peut être configuré pour utiliser différents moteurs d'exécution tels que le moteur Hadoop MapReduce, Apache Tez et Apache Spark. Dans ce document, HS2 est configuré pour utiliser le moteur Apache Tez.
Spark SQL est un module d'Apache Spark qui inclut une interface JDBC/ODBC permettant d'exécuter des requêtes SQL sur Apache Spark. Dans le schéma d'architecture précédent, Spark SQL est une option alternative à la gestion des requêtes utilisateur.
Un moteur de traitement, Apache Tez ou Apache Spark, appelle le gestionnaire de ressources YARN pour exécuter le DAG du moteur sur les machines de nœud de calcul du cluster. Enfin, les machines de nœud de calcul du cluster accèdent aux données. Pour stocker les données dans un cluster Dataproc et y accéder, utilisez le connecteur Cloud Storage et non le système de fichiers distribué Hadoop. Pour en savoir plus sur les avantages de l'utilisation du connecteur Cloud Storage, reportez-vous à la documentation sur le connecteur Cloud Storage.
Le schéma d'architecture précédent montre une topologie Apache Knox qui transfère les requêtes à Apache Hive, et une autre topologie qui transmet les requêtes à Spark SQL. Le schéma présente également d'autres topologies permettant de transférer des requêtes vers des services dans des clusters de backend identiques ou différents. Les services de backend peuvent traiter différents ensembles de données. Par exemple, une instance Hive peut offrir un accès à des informations personnelles (PII) pour un ensemble restreint d'utilisateurs, tandis qu'une autre instance Hive peut offrir un accès à des données sans informations personnelles pour une utilisation plus générale.
Autorisation des utilisateurs
Apache Ranger peut être installé sur les clusters de backend afin de fournir une autorisation détaillée pour les services Hadoop. Dans l'architecture, un plug-in Ranger pour Hive intercepte les requêtes des utilisateurs et détermine si un utilisateur est autorisé à effectuer une action sur les données Hive, en fonction de stratégies Ranger.
En tant qu'administrateur, vous définissez les stratégies Ranger à l'aide de la page d'administration de Ranger. Nous vous recommandons vivement de configurer Ranger pour stocker ces stratégies dans une base de données Cloud SQL externe. L'externalisation des stratégies a deux avantages :
- Elles sont persistantes en cas de suppression d'un cluster du backend.
- Elle permet de centraliser la gestion des stratégies pour tous les groupes ou pour des groupes personnalisés de clusters de backend.
Pour attribuer des stratégies Ranger aux identités d'utilisateur ou aux groupes appropriés, vous devez configurer le service Ranger pour synchroniser les identités à partir du même répertoire que celui auquel Knox est connecté. Par défaut, les identités des utilisateurs utilisées par Ranger proviennent du système d'exploitation.
Apache Ranger peut également externaliser ses journaux d'audit vers Cloud Storage pour les rendre persistants. Ranger utilise Apache Solr comme moteur d'indexation et de requêtes pour permettre d'effectuer des recherches dans les journaux d'audit.
Contrairement à HiveServer2, Spark SQL n'est pas compatible avec le plug-in Ranger officiel. Vous devez donc utiliser les LCA de haut niveau disponibles dans Apache Knox pour gérer les autorisations. Pour utiliser ces LCA, ajoutez les identités LDAP autorisées à utiliser chaque service, par exemple Spark SQL ou Hive, dans le descripteur de topologie correspondant au service.
Pour plus d'informations, consultez la section Bonnes pratiques pour l'utilisation d'Apache Ranger sur Dataproc.
Haute disponibilité
Dataproc fournit un mode haute disponibilité (HA). Dans ce mode, plusieurs machines sont configurées en tant que nœuds maîtres, dont une à l'état actif. Ce mode permet des opérations YARN et HDFS ininterrompues même en cas de défaillance ou de redémarrage d'un nœud unique.
Toutefois, en cas de défaillance du nœud maître, l'adresse IP externe du point d'entrée change et vous devez donc reconfigurer la connexion de l'outil d'informatique décisionnelle. Lorsque vous exécutez Dataproc en mode haute disponibilité, vous devez configurer un équilibreur de charge HTTP(S) comme point d'entrée. L'équilibreur de charge achemine les requêtes vers un groupe d'instances non géré qui regroupe vos nœuds maîtres de cluster. Au lieu d'un équilibreur de charge, vous pouvez appliquer une technique round-robin DNS à la place, mais cette méthode présente des inconvénients. Ces configurations n'entrent pas dans le cadre du présent document.
Cloud SQL offre également un mode haute disponibilité avec redondance des données rendue possible par la réplication synchrone entre les instances maîtres et les instances de secours situées dans différentes zones. En cas de défaillance d'une instance ou d'une zone, cette configuration réduit les temps d'arrêt. Sachez toutefois qu'une instance configurée pour la haute disponibilité est facturée le double du prix d'une instance autonome.
Cloud Storage fait office de datastore. Pour en savoir plus sur la disponibilité de Cloud Storage, consultez la section Descriptions des classes de stockage.
Mise en réseau
Dans une architecture de réseau multicouche, les clusters proxy se trouvent dans un réseau de périmètre. Les clusters de backend se trouvent dans un réseau interne protégé par des règles de pare-feu qui n'autorisent que le trafic entrant provenant des clusters de proxy.
Les clusters de proxy sont isolés des autres clusters, car ils sont exposés à des requêtes externes. Les règles de pare-feu n'autorisent qu'un ensemble restreint d'adresses IP sources à accéder aux clusters de proxy. Dans ce cas, les règles de pare-feu n'autorisent que les requêtes provenant des adresses de vos outils d'informatique décisionnelle.
La configuration des réseaux multicouche dépasse le propos de ce document. Dans la section Connecter votre logiciel de visualisation à Hadoop sur Google Cloud, vous utilisez le réseau default tout au long de ce tutoriel. Pour en savoir plus sur la configuration des réseaux multicouches, consultez les bonnes pratiques concernant la sécurité du réseau VPC ainsi que la présentation et les exemples illustrant comment configurer plusieurs interfaces réseau.
Étape suivante
- Lisez la deuxième partie de la série, intitulée Connecter votre logiciel de visualisation à Hadoop sur Google Cloud, et découvrez comment configurer l'architecture sur Google Cloud.
- Configurez l'architecture sur Google Cloud à l'aide de ces fichiers de configuration Terraform.
- Découvrez les bonnes pratiques concernant l'utilisation d'Apache Ranger sur Dataproc.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.