Este documento está dirigido a operadores y administradores de TI que quieran configurar el acceso seguro a los datos para los analistas por medio de herramientas de inteligencia empresarial (IE), como Tableau y Looker. No ofrece orientación para usar las herramientas de IE o interactuar con las API de Dataproc.
Este documento es la primera parte de una serie que te permitirá crear una solución de extremo a extremo para proporcionar a los analistas acceso seguro a los datos mediante herramientas de IE. En este documento, se explican los siguientes conceptos:
- Una arquitectura propuesta
- Una visualización de alto nivel de los límites, las interacciones y las herramientas de redes de componentes en la arquitectura
- Una visualización de alto nivel de la autenticación y la autorización en la arquitectura
En la segunda parte de esta serie, Conecta tu software de visualización a Hadoop en Google Cloud, se muestra cómo se debe configurar la arquitectura en Google Cloud.
Arquitectura
En el siguiente diagrama, se muestran la arquitectura y el flujo de eventos que se explican en este documento. Para obtener más información sobre los productos que se usan en esta arquitectura, consulta Componentes de la arquitectura.
- Las aplicaciones cliente se conectan a través de la conectividad de la base de datos de Java (JDBC) a un solo punto de entrada en un clúster de Dataproc. Apache Knox proporciona el punto de entrada, que se instala en el nodo de instancia principal del clúster. La TLS protege la comunicación con Apache Knox.
- Apache Knox delega la autenticación mediante un proveedor a un sistema como un directorio LDAP.
- Después de la autenticación, Apache Knox enruta la solicitud del usuario a uno o más clústeres de backend. Tú defines las rutas y la configuración como topologías personalizadas.
- Un servicio de procesamiento de datos, como Apache Hive, recibe datos en el clúster de backend seleccionado y toma la solicitud.
- Apache Ranger intercepta la solicitud y determina si el procesamiento debe avanzar, según si el usuario tiene una autorización válida.
- Si la validación se realiza correctamente, el servicio de procesamiento de datos analiza la solicitud y muestra los resultados.
Componentes de la arquitectura
La arquitectura consta de los siguientes componentes.
- La plataforma de Hadoop administrada:
- Dataproc. Dataproc es un servicio administrado por Google Cloud de Apache Spark y Apache Hadoop que te permite aprovechar las herramientas de datos de código abierto para el procesamiento por lotes, las consultas, la transmisión y el aprendizaje automático. Dataproc es la plataforma que respalda la solución descrita en este documento.
- La autenticación y autorización de usuarios:
- Apache Knox. Apache Knox actúa como un punto de acceso HTTP único para todos los servicios subyacentes en un clúster de Hadoop. Apache Knox está diseñado como un proxy inverso con proveedores conectables para la autenticación, autorización, auditoría y otros servicios. Los clientes envían solicitudes a Knox y, según la URL de solicitud y los parámetros, este enruta la solicitud al servicio de Hadoop adecuado. Debido a que Knox es un punto de entrada que controla de manera transparente las solicitudes del cliente y oculta la complejidad, se encuentra en el centro de la arquitectura.
- Apache Ranger. Apache Ranger proporciona autorización detallada para que los usuarios realicen acciones específicas en los servicios de Hadoop. También audita el acceso de los usuarios para implementar acciones administrativas.
- Motores de procesamiento:
- Apache Hive. Apache Hive es un software de almacén de datos que permite el acceso y la administración de grandes conjuntos de datos que se encuentran en un almacenamiento distribuido mediante SQL. Apache Hive analiza las consultas de SQL, realiza análisis semánticos y compila un grafo acíclico dirigido (DAG) de etapas para que se ejecute un motor de procesamiento. En la arquitectura que se muestra en este documento, Hive actúa como el punto de traducción entre las solicitudes de los usuarios. También puede actuar como uno de los diversos motores de procesamiento. Apache Hive está omnipresente en el ecosistema de Hadoop y abre la puerta a los profesionales familiarizados con SQL estándar para realizar análisis de datos.
- Apache Tez. Apache Tez es el motor de procesamiento a cargo de ejecutar los DAG que prepara Hive y de mostrar los resultados.
- Apache Spark. Apache Spark es un motor de estadísticas unificado para el procesamiento de datos a gran escala que admite la ejecución de los DAG. La arquitectura muestra el componente de Spark SQL de Apache Spark para demostrar la flexibilidad del enfoque que se presenta en este documento. Una restricción es que Spark SQL no tiene compatibilidad oficial con el complemento Ranger. Por esta razón, la autorización se debe realizar mediante las LCA detalladas en Apache Knox en lugar de usar la autorización detallada que proporciona Ranger.
Descripción general de los componentes
En las siguientes secciones, obtendrás información más detallada sobre cada componente. También descubrirás cómo los componentes interactúan entre sí.
Aplicaciones cliente
Las aplicaciones cliente incluyen herramientas que pueden enviar solicitudes a un extremo HTTPS de REST, pero que no necesariamente son compatibles con la API de Dataproc Jobs. Las herramientas de IE, como Tableau y Looker, tienen controladores de JDBC HiveServer2 (HS2) y Spark SQL que pueden enviar solicitudes a través de HTTP.
En este documento, se supone que las aplicaciones cliente son externas a Google Cloud y que se ejecutan en entornos como una estación de trabajo de analistas local o en otra nube. Por lo tanto, la comunicación entre las aplicaciones cliente y Apache Knox debe protegerse con un certificado de CA firmado o de SSL/TLS autofirmado.
Punto de entrada y autenticación del usuario
Los clústeres del proxy corresponden a uno o más clústeres de Dataproc de larga duración que alojan la puerta de enlace de Apache Knox.
Apache Knox actúa como el punto de entrada único para las solicitudes de clientes. Knox se instala en el nodo de instancia principal del clúster del proxy. Knox realiza la terminación de SSL, delega la autenticación del usuario y reenvía la solicitud a uno de los servicios de backend.
En Knox, cada servicio de backend se configura en lo que se denomina una topología. El descriptor de topología define las siguientes acciones y los siguientes permisos:
- La forma en que se delega la autenticación para un servicio.
- El URI al que el servicio de backend reenvía las solicitudes.
- Las listas simples de control de acceso por autorización de servicio (LCA)
Knox te permite integrar la autenticación con sistemas empresariales y de administración de identidades en la nube. Puedes usar proveedores de autenticación a fin de configurar la autenticación de usuario para cada topología. Knx usa Apache Shiro de forma predeterminada para autenticarse en un servidor LDAP de demostración local de ApacheDS
Como alternativa, puedes elegir utilizar Knox para usar Kerberos. En el diagrama anterior, como ejemplo, puedes ver un servidor de Active Directory alojado en Google Cloud fuera del clúster.
Para obtener información sobre cómo conectar Knox a los servicios de autenticación empresarial, como un servidor externo de ApacheDS o Microsoft Active Directory (AD), consulta la guía del usuario de Apache Knox y la documentación de Google Cloud sobre Active Directory administrado y AD federado.
Para el caso de uso de este documento, siempre que Apache Knox actúe como la única conexión a los clústeres de proxy y backend, no es necesario que uses Kerberos.
Motores de procesamiento
Los clústeres de backend son los clústeres de Dataproc que alojan los servicios para procesar solicitudes de usuario. Los clústeres de Dataproc pueden escalar automáticamente la cantidad de trabajadores para satisfacer la demanda de tu equipo de analistas sin necesidad de realizar una configuración manual.
Te recomendamos usar clústeres de Dataproc de larga duración en el backend. Los clústeres de Dataproc de larga duración permiten que el sistema entregue solicitudes de analistas de datos sin interrupciones. De manera alternativa, si el clúster solo necesita entregar solicitudes durante un breve período, puedes usar clústeres específicos de trabajos, que también se conocen como clústeres efímeros. Los clústeres efímeros también pueden ser más rentables que los clústeres de larga duración.
Si usas clústeres efímeros, asegúrate de volver a crear los clústeres en la misma zona y bajo el mismo nombre para evitar modificar la configuración de la topología. Con el uso de la misma zona y el mismo nombre, Knox puede enrutar las solicitudes con transparencia mediante el nombre de DNS interno del nodo principal cuando vuelves a crear el clúster efímero.
HS2 es responsable de atender las consultas de los usuarios a Apache Hive. HS2 se puede configurar para usar varios motores de ejecución, como el motor Hadoop MapReduce, Apache Tez y Apache Spark. En este documento, HS2 está configurado para usar el motor Apache Tez.
Spark SQL es un módulo de Apache Spark que incluye una interfaz JDBC/ODBC para ejecutar consultas de SQL en Apache Spark. En el diagrama de arquitectura anterior, Spark SQL se muestra como una alternativa para atender consultas sobre los usuarios.
Un motor de procesamiento, ya sea de Apache Tez o Apache Spark, llama al Administrador de recursos YARN para ejecutar el DAG de motor en las máquinas de trabajador del clúster. Por último, las máquinas de trabajador de clúster acceden a los datos. Para almacenar y acceder a los datos en un clúster de Dataproc, usa el conector de Cloud Storage, no el sistema de archivos distribuido Hadoop (HDFS). Para obtener más información sobre los beneficios de usar el conector de Cloud Storage, consulta la documentación del conector de Cloud Storage.
En el diagrama de arquitectura anterior, se muestra una topología de Apache Knox que reenvía solicitudes a Apache Hive y otra que reenvía solicitudes a Spark SQL. En el diagrama, también se muestran otras topologías que pueden reenviar solicitudes a servicios en los mismos clústeres o en clústeres de backend diferentes. Los servicios de backend pueden procesar diferentes conjuntos de datos. Por ejemplo, una instancia de Hive puede ofrecer acceso a información de identificación personal (PII) para un conjunto restringido de usuarios, mientras que otra instancia de Hive puede ofrecer acceso a datos que no sean PII para un consumo más amplio.
Autorización de usuarios
Se puede instalar Apache Ranger en los clústeres de backend de modo que se pueda proporcionar una autorización detallada para los servicios de Hadoop. En la arquitectura, un complemento Ranger para Hive intercepta las solicitudes del usuario y determina si este puede realizar una acción en función de los datos de Hive, según las políticas de Ranger.
Como administrador, puedes definir las políticas de Ranger mediante la página de administración de Ranger. Te recomendamos que configures Ranger para almacenar estas políticas en una base de datos externa de Cloud SQL. Externalizar las políticas tiene las siguientes dos ventajas:
- Las hace persistentes en caso de que se borre cualquiera de los clústeres de backend.
- Permite que las políticas se administren de forma central en todos los grupos o en los grupos personalizados de clústeres de backend.
Si deseas asignar políticas de Ranger a las identidades o los grupos de usuarios correctos, debes configurar Ranger para sincronizar las identidades desde el mismo directorio al que está conectado Knox. Según la configuración predeterminada, las identidades de usuario que utiliza Ranger se toman del sistema operativo.
Apache Ranger también puede externalizar sus registros de auditoría a Cloud Storage para que sean persistentes. Ranger utiliza Apache Solr como su motor de indexación y consulta para permitir las búsquedas de los registros de auditoría.
A diferencia de HiveServer2, Spark SQL no tiene compatibilidad oficial con el complemento Ranger, por lo que debes usar las LCA disponibles en Apache Knox para administrar su autorización. Para usar estas LCA, agrega las identidades de LDAP que pueden usar cada servicio, como Spark SQL o Hive, al descriptor de topología correspondiente para el servicio.
Si deseas obtener más información, consulta Prácticas recomendadas para usar Apache Ranger en Dataproc.
Alta disponibilidad
Dataproc proporciona un modo de alta disponibilidad (HA). En este modo, hay varias máquinas configuradas como nodos principales, una de las cuales está en estado activo. Este modo permite la ejecución de operaciones YARN y HDFS sin interrupciones a pesar de cualquier falla o reinicio del nodo único.
Sin embargo, si el nodo principal falla, la IP externa de punto de entrada único cambia, por lo que debes volver a configurar la conexión de la herramienta IE. Cuando ejecutes Dataproc en modo HA, debes configurar un balanceador de cargas HTTP(S) externo como punto de entrada. El balanceador de cargas enruta las solicitudes a un grupo de instancias no administrado que agrupa los nodos de instancia principal del clúster. Como alternativa a un balanceador de cargas, puedes aplicar una técnica de DNS round robin, pero existen algunas desventajas con este enfoque. Estas configuraciones están fuera del permiso de este documento.
Cloud SQL también proporciona un modo de alta disponibilidad, con redundancia de datos que se puede realizar mediante la replicación síncrona entre las instancias principales y las instancias en espera ubicadas en diferentes zonas. Si hay una falla en una instancia o una zona, esta configuración reduce el tiempo de inactividad. Sin embargo, ten en cuenta que una instancia configurada con HA se cobra al doble del precio que una instancia independiente.
Cloud Storage actúa como el almacén de datos. Para obtener más información sobre la disponibilidad de Cloud Storage, consulta las descripciones de las clases de almacenamiento.
Redes
En una arquitectura de red en capas, los clústeres del proxy se encuentran en una red perimetral. Los clústeres de backend se encuentran en una red interna protegida por reglas de firewall que solo permiten el tráfico entrante desde los clústeres de proxy.
Los clústeres de proxy están aislados de los otros clústeres porque están expuestos a las solicitudes externas. Las reglas de firewall solo permiten que un conjunto restringido de direcciones IP de origen acceda a los clústeres del proxy. En este caso, las reglas de firewall solo permiten solicitudes provenientes de las direcciones de tus herramientas de IE.
La configuración de las redes en capas está fuera del permiso de este documento. En Conecta tu software de visualización a Hadoop en Google Cloud, usa la red default durante todo el instructivo. Si quieres obtener más información sobre las opciones de configuración de la red en capas, consulta las prácticas recomendadas para la seguridad de la red de VPC y la descripción general y ejemplos para configurar interfaces de red múltiples..
¿Qué sigue?
- Lee la segunda parte de la serie Conecta tu software de visualización a Hadoop en Google Cloud y aprende a configurar la arquitectura en Google Cloud.
- Configura la arquitectura en Google Cloud mediante estos archivos de configuración de Terraform.
- Descubre las prácticas recomendadas para usar Apache Ranger en Dataproc.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.