Extiende Notebooks a Dataproc y Google Kubernetes Engine

En este documento, se ayuda a los administradores de sistemas y a los ingenieros de datos a elegir el mejor enfoque para ejecutar notebooks de Jupyter en Google Cloud. Se supone que estás familiarizado con los notebooks de Jupyter y Dataproc Hub.

El documento es parte de una serie que incluye las siguientes partes:

Esta serie está dirigida en particular a administradores que compilan entornos de notebook de Jupyter para la investigación de ciencia de datos.

Introducción

Empresas de todos los tamaños recopilan una cantidad de datos cada vez mayor. Para comprenderlos, se requieren recursos humanos y técnicos. Los usuarios finales, como científicos de datos o analistas de datos, a menudo, interactúan directamente con los datos mediante herramientas como editores de texto, entornos de desarrollo integrados (IDE) o entornos de notebook. Los administradores del sistema crean una infraestructura para ayudar a estos usuarios a realizar investigaciones.

Por lo general, los usuarios finales quieren realizar las siguientes acciones:

  • Ejecutar tareas interactivas a gran escala para facilitar el desarrollo y la depuración
  • Ejecutar tareas de datos y tareas de aprendizaje automático desde el mismo notebook
  • Tener acceso a entornos que coincidan con sus necesidades para mejorar la productividad
  • Mantener los notebooks separados de la infraestructura de procesamiento para que no pierdan el trabajo
  • Iniciar con rapidez un entorno que coincida con sus requisitos de hardware y software

Por lo general, los administradores del sistema quieren hacer las siguientes acciones:

  • Controlar los entornos de notebooks de forma centralizada para facilitar la administración
  • Automatizar la implementación de la plataforma que administra los ciclos de vida de los notebooks para minimizar la sobrecarga operativa
  • Proporcionar a los usuarios acceso limitado, pero suficiente para que puedan hacer sus trabajos
  • Permitir que los usuarios ejecuten sus trabajos de forma aislada para proporcionar flexibilidad al usuario final
  • Maximizar el uso de recursos para minimizar los costos y la sobrecarga.

En este documento, se ofrece una descripción general de las opciones de notebooks en Google Cloud. Los otros documentos de esta serie se enfocan en cómo personalizar e implementar JupyterHub en Google Cloud. JupyterHub ayuda a las organizaciones a administrar entornos de notebooks de Jupyter en un contexto multiusuario.

Terminología

En esta serie, se usan los siguientes términos y productos:

  • Producto: Una oferta oficial y privada que proporciona y admite Google Cloud.
  • Solución: Arquitectura y software de código abierto que usa varios productos de Google Cloud.
  • Administrador: Una persona que administra recursos que administran notebooks.
  • Usuario final: Una persona que ejecuta tareas de procesamiento interactivas mediante notebooks. Para los fines de esta serie, los usuarios finales son, en principio, científicos de datos.
  • Hub: Una IU para que los usuarios finales puedan personalizar e iniciar un servidor de notebook nuevo o acceder a la interfaz de Jupyter de un servidor de notebook existente.
  • Extremo: Una URL que usa un usuario final para acceder a una IU de un notebook.
  • JupyterHub: Un servidor multiusuario que entrega notebooks de Jupyter a varios usuarios y administra la creación, el proxy y el ciclo de vida de los servidores de notebooks.
  • Perfil del servidor de notebooks: Una configuración creada por un administrador que define el hardware y la configuración del software para el entorno del notebook.
  • Generador: Un proceso que es responsable de iniciar un servidor de notebook de usuario único.

Decide qué producto usar para implementar plataformas basadas en notebooks

El siguiente árbol de decisión te ayuda a determinar qué producto o solución usar cuando implementas la plataforma de desarrollo basada en notebooks.

Árbol de decisión para ayudar a determinar qué producto o solución usar a fin de implementar una plataforma de desarrollo basada en notebooks.

En el árbol que se ilustra en el diagrama, se muestra un conjunto de decisiones que te ayudan a determinar qué producto o solución usar para implementar una plataforma de notebook en Google Cloud.

La primera pregunta es si necesitas ejecutar el SDK de Apache Spark en un entorno distribuido. El resto de las decisiones dependen de tu respuesta a esta pregunta, de la siguiente manera.

No, no necesitas ejecutar Apache Spark en un entorno distribuido

En ese caso, ¿necesitas usar el SDK de Apache Beam en una sola instancia y, luego, ejecutar el código en Dataflow?

  • Si necesitas usar el SDK de Beam, usa Notebooks que usen ejecutor directo de Apache Beam para proporcionar un entorno de investigación interactivo en una sola máquina. Para obtener más información, consulta la documentación de Apache Beam en Notebooks.
  • Si no necesitas usar el SDK de Beam, ¿necesitas administrar los perfiles de procesamiento de forma centralizada?
    • Si es así, usa GKE Hub Extended.
    • Si no es así, ¿debes consolidar el costo? Si es así, usa GKE Hub Extended. Si no es así, usa Notebooks.

Sí, necesitas usar Apache Spark en un entorno distribuido

En ese caso, ¿necesitas administrar los perfiles de clústeres de Dataproc de forma centralizada?

  • Si necesitas administrar perfiles de clúster de forma centralizada, ¿necesitas personalización avanzada de Dataproc Hub? Si es así, usa Dataproc Hub Extended. Si no es así, usa Dataproc Hub.
  • Si no necesitas administrar perfiles de clústeres de forma centralizada, usa notebooks de Dataproc.

Elige una infraestructura

De forma predeterminada, puedes ejecutar servidores de notebooks para notebooks de Jupyter en los siguientes productos de Google Cloud:

  • Dataproc: los usuarios ejecutan servidores de notebooks a través del componente de Jupyter en un clúster de Dataproc habilitado para Spark. Esta opción es útil si necesitas usar Spark en un entorno distribuido.
  • Notebooks: los usuarios ejecutan servidores de notebooks en una sola instancia de Compute Engine. Esta opción es útil si el trabajo puede ejecutarse en una sola instancia.

Si el framework de procesamiento no usa Spark en un entorno distribuido, primero debes explorar Notebooks. Si Notebooks no cumple con los requisitos, considera las opciones de Google Kubernetes Engine (GKE).

Cuando sabes si necesitas Dataproc, el siguiente paso es decidir qué flexibilidad deben tener los usuarios finales.

Elige un centro

Un centro, en general, permite a los administradores definir cómo se ven los entornos de notebook y permite que los usuarios finales administren el ciclo de vida del entorno del notebook. Google Cloud usa Cloud Console como centro predeterminado. Si bien Cloud Console proporciona flexibilidad a los usuarios finales, algunas empresas necesitan opciones administrativas adicionales para administrar los perfiles de notebook de manera centralizada. Los siguientes son algunos de los motivos:

  • Recopilar entornos de notebook en una cantidad limitada de máquinas a fin de minimizar los costos y maximizar el uso de los recursos
  • Proporcionar entornos de zona de pruebas a los usuarios finales para mejorar la seguridad
  • Definir con anterioridad entornos de notebook que los usuarios finales puedan comenzar mediante solo unos pocos clics para minimizar las tareas repetitivas
  • Usar plantillas para entornos de notebooks a fin de establecer la coherencia en toda la organización

Si no quieres que los usuarios finales trabajen en Cloud Console por alguno de estos motivos, puedes elegir una de las siguientes opciones:

  • Si usas Dataproc, puedes usar Dataproc Hub, un producto que aloja JupyterHub en una instancia de Notebooks y que genera entornos de notebooks en Dataproc. Dataproc Hub se basa en tecnología de código abierto, puedes personalizarlo.
  • Si no usas Dataproc, Google Cloud no proporciona una forma administrada de ejecutar JupyterHub para cargas de trabajo que no se basan en Dataproc. Sin embargo, para este caso, puedes usar GKE Hub Extended, una solución liviana que se ejecuta en GKE.

Puedes leer más sobre cada una de estas opciones en las siguientes secciones de este documento:

Dataproc Hub Extended

Si tu empresa está en Google Cloud y usa Spark, puedes usar Dataproc para procesar datos a gran escala y ejecutar inferencia y entrenamiento. Con Dataproc Hub, puedes administrar y estandarizar la configuración del clúster de forma centralizada mientras les proporcionas a los usuarios finales el entorno que necesitan. Para hacerlo, usa configuraciones de clúster, que son archivos YAML declarativos que definen los siguientes elementos:

  • Perfiles de hardware para los clústeres de Dataproc
  • Perfiles de software para el entorno de notebook

Por ejemplo, puedes usar Dataproc Hub para la siguiente situación:

  1. Un usuario final crea su propio entorno de notebook a partir de una lista de opciones de configuración que selecciona el administrador.
  2. Cuando se ejecuta un entorno desde el notebook, el usuario final explora de forma interactiva los datos a gran escala mediante PySpark. Los usuarios también pueden ejecutar tareas de AA con TensorFlow o PyTorch.

De forma predeterminada, la arquitectura de Dataproc Hub es similar a la que se muestra a continuación:

Arquitectura de Dataproc Hub.

Dataproc Hub usa los siguientes productos de Google Cloud y software de código abierto:

  • Dataproc aloja el servidor de notebook.
  • Notebooks proporciona una instancia de Compute Engine para ejecutar JupyterHub y ayudar a brindar acceso identificado y seguro a la IU mediante el proxy de inversión.
  • El servidor de proxy de inversión es una herramienta de código abierto que recibe y reenvía solicitudes entrantes al backend adecuado. Dataproc Hub usa una versión administrada por Google del servidor proxy de inversión.
  • El agente de proxy de inversión es una herramienta de código abierto que se ejecuta a la par de JupyterHub en una instancia de Compute Engine y hace coincidir solicitudes y respuestas entre el backend y el cliente.
  • El autenticador de JupyterHub para proxies de Google Cloud (gcp-proxies-authenticator) proporciona identificación transparente del usuario mediante encabezados proporcionados por el proxy de inversión. El código está disponible en el repositorio de autenticador de JupyterHub para proxies de Google Cloud en GitHub.
  • JupyterHub se instala en una instancia de Compute Engine de Notebooks para aprovechar el servicio del agente de proxy de inversión.
  • El generador de Dataproc proporciona un formulario al usuario final para que pueda crear servidores de notebooks en Dataproc en una zona seleccionada. El código está disponible en el repositorio de autenticador de JupyterHub para proxies de Google Cloud en GitHub.

En algunos casos, es posible que debas extender la versión base de Dataproc Hub para modificar la arquitectura general o adaptar algún código a tus necesidades. Debido a que Dataproc Hub se basa en software de código abierto, puedes extender las capacidades del producto. Por ejemplo, puedes hacer lo siguiente:

GKE Hub Extended

GKE Hub Extended ayuda a consolidar los costos mediante la centralización de la infraestructura de procesamiento. En la siguiente arquitectura, se muestra cómo los usuarios finales pueden crear sus propios entornos de zona de pruebas en una infraestructura de GKE.

Arquitectura que explica cómo los usuarios finales pueden crear sus propios entornos de zona de pruebas en una infraestructura de GKE.

En esta arquitectura, los administradores usan perfiles de servidor de notebooks para proporcionar una lista de entornos permitidos a un equipo de usuarios finales. Los perfiles son objetos JSON declarativos que definen los siguientes elementos:

  • Perfiles de hardware para los Pods
  • Perfiles de software para el entorno de notebook

En el diagrama, las plantillas de perfil se encuentran junto al administrador de TI como imágenes personalizadas. Cuando un usuario final elige una imagen, se inicia un servidor de notebook en un nodo de GKE. En el diagrama, estos servidores se representan con las casillas user-*.

Como se muestra en el diagrama, GKE Hub Extended es una solución liviana que usa los siguientes productos de Google Cloud y software de código abierto:

  • El servidor de proxy de inversión es una herramienta de código abierto que recibe y reenvía solicitudes entrantes al backend adecuado. GKE Hub usa una versión administrada por Google del servidor proxy de inversión.
  • El servidor de proxy de inversión es una herramienta de código abierto que se ejecuta en GKE como su propia implementación y que coincide con las solicitudes y respuestas entre el backend y el cliente. Hay un agente que se ejecuta a la par de la implementación de JupyterHub para ayudar a brindar acceso seguro a la IU de JupyterHub. La tarea de enrutar usuarios a servidores de notebook se controla mediante JupyterHub. Para obtener más información, consulta el archivo README del repositorio de proxy de inversión en GitHub.
  • El autenticador de JupyterHub para proxies de Google Cloud (gcp-proxies-authenticator) proporciona identificación transparente del usuario mediante encabezados proporcionados por el proxy de inversión. El código está disponible en el repositorio de autenticador de JupyterHub para proxies de Google Cloud en GitHub.
  • KubeSpawner brinda un formulario a los usuarios finales para que puedan crear servidores de notebooks en el mismo clúster de Kubernetes que aloja JupyterHub. KubeSpawner también proporciona una manera para que los administradores gestionen perfiles de servidor de notebooks a través de un parámetro profile_list. El código está disponible en el repositorio de generador de Kubernetes de JupyterHub en GitHub.

La carpeta de GKE Hub en el repositorio funciona como ejemplo para mostrar cómo configurar el entorno que se describe en esta sección. Puedes bifurcar el repositorio superior y extender el código para GKE Hub.

Consideraciones comunes para elegir un notebook

Las siguientes consideraciones son importantes cuando decides cómo configurar una infraestructura de notebook para la experimentación:

  • Acceso a las interfaces: indica cómo los usuarios finales acceden a la IU del producto, incluida la autenticación y el acceso a la red. Esta decisión afecta la seguridad.
  • Relación entre los usuarios y los servidores de notebooks: indica si un usuario puede usar varios servidores de notebook a la vez o si el usuario está limitado a un servidor de notebook. A menudo, esta decisión afecta la productividad y los costos.
  • Framework de procesamiento: indica si tienes requisitos heredados o requisitos de tecnología específicos para el procesamiento. Spark es un ejemplo de un requisito de tecnología. A menudo, esta decisión afecta la productividad.
  • Infraestructura subyacente: indica qué producto de infraestructura de Google Cloud usar y si los usuarios comparten la infraestructura. Esta decisión afecta la escalabilidad y los costos.

En el resto de este documento, se describen las opciones para abordar cada una de estas consideraciones.

Acceso a la interfaz web

Los usuarios finales acceden a los notebooks y a las interfaces web relacionadas a través de una URL de extremo. Los extremos tienen características diferentes:

  • Conectividad: indica si el extremo está expuesto de forma privada (como a través de notebooks.corp.example.com) o de forma pública (como a través de notebooks.example.com).
  • Seguridad de red: indica si un recurso en una red específica puede acceder al extremo.
  • Autenticación: indica la forma en que el sistema verifica la identidad de los usuarios cuando acceden al extremo.
  • Dominio: indica si se puede acceder al extremo a través de un dominio personalizado o a través de un dominio proporcionado por Google. Puedes administrar dominios personalizados a través de Cloud DNS o de una solución similar.
  • Hub: indica qué tecnología puede dirigir a los usuarios al servidor de notebook.

La mayoría de estas consideraciones dependen de una combinación de la plataforma de notebook que usas y del proxy conectado a ella. En las arquitecturas que se describen en esta serie, puedes elegir entre los siguientes proxies:

  • IAP: un producto que administra el acceso a las aplicaciones web, como JupyterHub, que se ejecuta en Compute Engine o en GKE.
  • Proxy de inversión: una solución de código abierto que incluye un servidor proxy de inversión y un agente. En esta serie, se usa un servidor administrado por Google.
  • Puerta de enlace de componentes: un producto administrado por Dataproc que combina el proxy de inversión y Apache Knox, una puerta de enlace de API, para ayudar a proporcionar acceso seguro a los extremos web de Dataproc.

A fin de simplificar la administración de dominios, Google Cloud usa en gran parte el proxy de inversión para productos como los notebooks de Jupyter que necesitan externalizar una IU web. El proxy de inversión usa un dominio administrado por Google.

En la siguiente tabla, se enumeran las características de la lista anterior para cada producto o solución de notebook de Google Cloud.

Plataforma Proxy Autenticación Dominio Hub
Jupyter de Dataproc Puerta de enlace del componente Administrada por Google Proporcionado por el proxy Cloud Console
Dataproc Hub Proxy de inversión gcp-proxies-authenticator Proporcionado por el proxy Basado en JupyterHub
Dataproc Hub Extended Proxy de inversión gcp-proxies-authenticator Proporcionado por el proxy Basado en JupyterHub
Notebooks Proxy de inversión Administrada por Google Proporcionado por el proxy Cloud Console
GKE Hub Extended Proxy de inversión gcp-proxies-authenticator Proporcionado por el proxy Basado en JupyterHub

Dataproc Hub Extended y GKE Hub Extended también pueden usar IAP y un dominio personalizado. El repositorio de GitHub ai-notebook-extended proporciona un ejemplo de cómo lograr esto para Dataproc Hub Extended en grupos de instancias administrados.

Relación entre los usuarios y los servidores de notebooks

Según el producto que uses, la relación entre los notebooks y los usuarios puede variar, como se muestra en la tabla siguiente.

Herramienta Relación Usuario:Notebook
Jupyter de Dataproc N:N
Dataproc Hub 1:1
Dataproc Hub Extended 1:1 (puedes personalizar el código de generador para 1:N)
Notebooks N:N
GKE Hub 1:N (puedes configurar el generador para 1:1)

Las implicaciones de las relaciones en la tabla anterior son las siguientes:

  • Si usas Jupyter de Dataproc, cualquier usuario final que tenga acceso a una URL de puerta de enlace de componentes puede acceder al notebook que está conectado a esa URL.
  • Si usas Dataproc Hub, un usuario final que tenga acceso a una URL de proxy de inversión puede acceder al centro que está conectado a esa URL. Sin embargo, el usuario no puede acceder a los servidores de notebooks de otros usuarios. De forma predeterminada, un usuario solo puede iniciar un servidor de notebook de un solo usuario a la vez.
  • Si usas Dataproc Hub Extended, un usuario final que tenga acceso a una URL de proxy de inversión puede acceder al centro que está conectado a esa URL. Sin embargo, el usuario no puede acceder a los servidores de notebooks de otros usuarios. De forma predeterminada, un usuario puede iniciar solo un servidor de notebook de un solo usuario a la vez, pero puedes personalizar el código de generador para cambiar este comportamiento.
  • Si usas Notebooks, cualquier usuario final que tenga el acceso autenticado a una URL del proxy de inversión puede acceder al notebook que está conectado a esa URL.
  • Si usas la solución de GKE Hub, los usuarios finales que tengan acceso a una URL de proxy de inversión podrán acceder al centro que está conectado a esa URL. Sin embargo, los usuarios solo pueden ver sus propios servidores de notebooks. De forma predeterminada, si habilitas la opción correspondiente, los usuarios pueden ejecutar varios servidores de notebooks de un solo usuario a la vez.

Debes tener en cuenta lo siguiente:

  • Acceder a la IU detrás de una URL del proxy de inversión requiere que el usuario tenga la función serviceAccountUser para la cuenta de servicio de la instancia que aloja el agente.
  • Para acceder a una aplicación protegida con IAP, el usuario debe tener los permisos adecuados a nivel de IAP.

Resumen

Google Cloud ofrece varias opciones para ejecutar notebooks. En esta serie de documentos, se brinda ayuda para tomar la decisión correcta. Usa los siguientes lineamientos:

  1. Si no necesitas administrar de manera central los perfiles de servidores de notebooks, y si los usuarios finales pueden trabajar en una sola instancia, usa Notebooks y el proxy de inversión.
  2. Si no necesitas administrar de forma centralizada los perfiles de servidores de notebooks, y si los usuarios finales necesitan Apache Spark en un entorno distribuido, usa notebooks de Dataproc a través del componente Jupyter de Dataproc y la puerta de enlace de componentes.
  3. Si necesitas administrar los perfiles del servidor de notebook de manera centralizada y, si los usuarios finales necesitan Spark en un entorno distribuido, usa Dataproc Hub y el proxy de inversión.
  4. Si necesitas personalizar Dataproc Hub, usa la solución de Dataproc Hub de GitHub como base.
  5. Si necesitas administrar los entornos de usuario de forma centralizada y quieres usar Kubernetes, compila sobre la solución de ejemplo de GKE Hub. Para obtener información sobre la configuración de GKE Hub con el proxy de inversión, consulta Instructivo: Genera servidores de notebooks en Google Kubernetes Engine (GKE) en esta serie.

Una de las principales ventajas de usar Dataproc Hub Extended y GKE Hub Extended es que puedes personalizarlos por completo. Por ejemplo, puedes ejecutar un centro en GKE y generar notebooks cuando sea necesario, ya sea en Dataproc o GKE. Si necesitas ayuda con las personalizaciones que no están en el repositorio de GitHub, comunícate con el equipo local de Google Cloud para saber cómo puede ayudar Google Cloud.

¿Qué sigue?