- Saltar a la navegación principal
- Saltar al contenido principal
- Saltar a la barra lateral principal
- Saltar al pie de página
Bluetab
an IBM Company
Databricks sobre AWS - Una perspectiva de arquitectura (parte 1)
Alberto Jaen
AWS Cloud Engineer
Alfonso Jerez
AWS Cloud Engineer
Databricks se ha convertido en un producto de referencia en el ámbito de Plataformas de Datos proporcionando un entorno unificado para los roles de ingeniería y analítica. Debido a que no todas las organizaciones tienen los mismos tipos de carga de trabajo, Databricks ha diseñado diferentes planes que permiten adaptarse a las distintas necesidades y esto tiene un impacto directo en el diseño de la arquitectura de la plataforma.
Con esta serie de artículos se pretende abordar la integración de Databricks en entornos AWS analizando las alternativas ofrecidas por el producto respecto al diseño de arquitectura. Debido a la extensión de los contenidos, se ha considerado conveniente dividir en dos entregas:
Primera entrega:
- Planes y tipos de carga de trabajo
- Arquitectura alto nivel
- Networking
- Identidad y Gestión de accesos
Segunda entrega (próximamente):
- Seguridad
- Escalabilidad
- Logging y monitorización
- Despliegue
Introducción
Databricks se crea con la idea de poder desarrollar un entorno único en el que los distintos perfiles como Data Engineers, Data Scientists y Data Analyst pudiesen trabajar de forma colaborativa sin la necesidad de contar con proveedores de servicios externos que ofrezcan las distintas funcionalidades que cada uno de estos necesita en su día a día. El nacimiento de Databricks se lleva a cabo gracias a la colaboración de los fundadores de Spark, publicando DeltaLake y MLFlow como productos de Databricks siguiendo la filosofía open-source:
Este nuevo entorno colaborativo tuvo un gran impacto en su presentación debido a las novedades que ofrecía al integrarse las distintas tecnologías:
- Spark es un framework de programación distribuida que presenta como una de sus funcionalidades la capacidad de realizar consultas sobre los Delta Lakes en unos ratios de coste/tiempo superiores a los de la competencia, consiguiendo optimizar los procesos de análisis.
- Delta Lake se presenta como soporte de almacenamiento de Spark. Aúna las principales ventajas de los Data WareHouse y Data Lakes al posibilitar la carga de información estructurada y no estructurada mediante una versión mejorada de parquet que permite soportar transacciones ACID asegurando así la integridad de la información en los procesos ETL llevados a cabo por Spark
- MLFlow es una plataforma para la administración del ciclo de vida de Machine Learning que incluye: experimentación, reusabilidad, implementación y registro de modelos centralizados.
Glosario
- All Purpose Compute: diseñado para entornos colaborativos en los que se recurra de forma simultánea al clúster por parte de Data Engineers y Data Scientist
- Buckets S3: servicio de almacenamiento de objetos de AWS.
- Cross account role: rol que se disponibiliza para que Databricks pueda asumirlo desde su cuenta en AWS. Se utiliza para desplegar la infraestructura y para poder asumir otros roles dentro de AWS.
- Data roles: roles con permisos de acceso/escritura a los buckets de S3 que serán asumidos por el cluster a través del meta instance profile.
- Instance profile: rol que se provee al cluster con permisos de acceso a buckets de S3 y por el cual todos los usuarios con acceso al cluster tendrán los mismos permisos.
- Jobs Compute: enfocado a procesos orquestados mediante pipelines gestionados por Data Engineers que puedan conllevar autoescalado en ciertas tareas
- Jobs Light Compute: diseñado para procesos cuya consecución no sea crítica y no conlleve una carga computacional muy elevada
- Meta instance profile: rol que se provee al cluster con permisos para asumir los data roles.
- Identity Provider (IdP): entidad que mantiene la información de identidad de los individuos dentro de una organización.
- Secure Cluster Connectivity (SCC): comunicación a través de túnel inverso SSH entre Control Plane y cluster. Permite no tener puertos abiertos ni IPs públicas en las instancias.
- Security Token Service (STS): servicio web que permite solicitar credenciales temporales con unos privilegios limitados.
- Security Assertion Markup Language (SAML): estándar abierto utilizado para la autenticación. Basado en XML, las aplicaciones web utilizan SAML para transferir datos de autenticación entre dos entidades, el Identity Provider y el servicio en cuestión.
- SQL Compute: cluster reservados a queries para la visualización de la información almacenada en el Data Lake
- Virtual Private Cloud (VPC): red virtual aislada lógicamente en AWS.
- VPC Endpoint: componente de red que permite conectar una VPC con los diferentes servicios dentro de AWS a través de la red propia de AWS.
- Workspace: entorno compartido para acceder a todos los activos de Databricks. En este se organizan los diferentes objetos (notebooks, librerias, etc…) en carpetas y se administran los accesos a recursos computacionales como clusters y jobs.
Arquitectura
Arquitectura alto nivel
Antes de comenzar a analizar las diferentes alternativas que nos proporciona Databricks respecto al despliegue de infraestructura, conviene conocer los principales componentes del producto:
Control Plane: aloja los servicios back-end de Databricks necesarios para disponibilizar la interfaz gráfica, APIs REST para la gestión de la cuenta y workspaces. Dichos servicios están desplegados en una cuenta AWS propiedad de Databricks.
Data Plane: aloja toda la infraestructura necesaria para el procesamiento de datos: persistencia, clusters, servicios de logging, librerías spark, etc. El Data Plane se despliega en la cuenta AWS del cliente y puede estar administrada por:
- Databricks (Databricks Managed VPC).
- Por el cliente (Customer Managed VPC).
DBFS: sistema de almacenamiento distribuido disponible para los clusters. Es una abstracción sobre un sistema de almacenamiento de objetos, en este caso S3, y permite el acceso a ficheros y carpetas sin necesidad de utilizar URLs.
Databricks REST APIs: APIs REST disponibilizadas por Databricks a través de las cuales se podrán gestionar sus recursos de manera programática.
External Data Sources: posibles fuentes de datos alojados fuera de la cuenta de AWS del cliente, como por ejemplo una base de datos relacional o un servicio de almacenamiento de objetos.
Planes y tipos de carga de trabajo
El precio indicado por Databricks se imputa en relación a las DBUs consumidas por el cluster. Este parámetro está relacionado con la capacidad de procesamiento consumida por el cluster y dependen directamente del tipo de instancias seleccionadas (al configurar el cluster se facilita un cálculo aproximado de las DBUs que consumirá por hora el cluster)
El precio imputado por DBU depende de dos factores principales:
- Factor computacional: la definición de las características del cluster (Cluster Mode, Runtime, On-Demand-Spot Instances, Autoscaling, …) que se traducirá en la asignación de un paquete en concreto (Jobs Light Compute, Jobs Compute, SQL Compute y All Purpose Compute).
- Factor de arquitectura: la personalización de la misma (Customer Managed-VPC), en algunos aspectos requerirá tener una suscripción Premium e incluso Enterprise, lo que genera que el coste de cada DBU sea mayor a medida que se obtiene una suscripción con mayores privilegios.
La combinación de ambos factores, computacional y de arquitectura, definirá el coste final de cada DBU por hora de trabajo.
| PLAN | |||
|---|---|---|---|
| | Standard | Premium | Enterprise |
| | One platform for your data analytics and ML workloads | Data analytics and ML at scale across your business | Data analytics and ML for your mission critical workloads |
| Job Light Compute | $0,07/DBU | $0,10/DBU | $0,13/DBU |
| Job Compute | $0,10/DBU | $0,15/DBU | $0,20/DBU |
| SQL Compute | N/A | $0,22/DBU | $0,22/DBU |
| All-Purpose Compute | $0,40/DBU | $0,55/DBU | $0,65/DBU |
| Serverless SQL Compute | N/A | $0,55/DBU | $0,55/DBU |
Coste imputado por DBU respecto a los factores computacionales y arquitectónicos
En la siguiente tabla se puede observar las características principales por tipo de carga de trabajo:
| WORKLOAD TYPE | |||
|---|---|---|---|
| FEATURE | Jobs Light Comput | Jobs compute | All-purpose compute |
| Managed Apache Spark | | | |
| Job scheduling with libraries | | | |
| Job scheduling with notebooks | | | |
| Autopilot clusters | | | |
| Databricks Runtime for ML | | | |
| Managed MLflow | | | |
| Delta Lake with Delta Engine | | | |
| Interactive clusters | | | |
| Notebooks and collaboration | | | |
| Ecosystem integrations | | | |
Características por tipo de carga de trabajo
En la siguiente tabla se reflejan las características incluidas en cada uno de los planes enfocándose en la integración con AWS. Dichas características pueden ser un factor determinante en el momento de seleccionar el plan.
| PLAN | |||
|---|---|---|---|
| DESCRIPTION | Standard | Premium | Enterprise |
| Data Plane Control | | | |
| Databricks Managed VPC | | | |
| Customer Managed VPC | | | |
| Control Plane Networking | | | |
| Cluster - Control Plane (Public Connection) | | | |
| Cluster - Control Plane (Private Link) | | | |
| AWS S3 Permissions Management | | | |
| Instance Profile | | | |
| Credentials Passthrough (SCIM) | | | |
| Control Plane Encryption | | | |
| Default DMK Key | | | |
| DMK & CMK Keys | | | |
| At Rest Encryption | | | |
| S3 Bucket | | | |
| S3 Bucket - EBS | | | |
Características relacionadas con el plan de subscripción.
Networking
En el siguiente diagrama se muestran los canales de comunicación entre Control Plane y Data Plane:
Databricks Managed VPC
Esta alternativa se caracteriza porque el Data Plane es administrado por Databricks. La infraestructura se despliega a través de un cross-account role que se habilita para que Databricks pueda levantar y configurar la infraestructura necesaria. Las conexiones implementadas son las siguientes:
- Conexión cluster-root bucket a través de Gateway Endpoint
- Conexión cluster-STS y cluster-Kinesis a través de la red pública
- Conexión a metastore alojado en el Control Plane a través de la NAT Gateway
- Conexión a APIs REST a través de la NAT Gateway
- Secure cluster connectivity: conexión a infraestructura de control del cluster con tunel SSH inverso a través de la NAT Gateway
- Las instancias del cluster tienen acceso SSH a cualquier IP
Customer Managed VPC [1]
Esta alternativa se caracteriza porque el Data Plane está administrado por el cliente. Las bondades de esta alternativa son las siguientes:
- Mayor control y reducción de permisos necesarios en el cross-account role que utiliza Databricks. Por ejemplo, ya no es necesario que este rol tenga los permisos para poder crear una VPC.
- Gestión de las subredes dentro de la VPC de tal manera que se pueda determinar un rango que se ajuste adecuadamente al caso de uso.
- Consolidación de VPCs donde varios workspaces pueden utilizar la misma VPC para facilitar la gestión de los clusters, lo que conlleva un menor coste. Es importante tener en cuenta que no se pueden disponibilizar varias subredes dentro de la misma AZ en el mismo workspace.
- Posibilidad de limitar las conexiones salientes a través de los grupos de seguridad de la instancias, aplicando firewalls o disponiendo de endpoints para poder implementar toda comunicación a través de canales internos.
- Inclusión de VPC Endpoints para AWS STS y Kinesis.
- Private Links para comunicación privada con Control Plane.
- Posibilidad de implementar el metastore con AWS Glue en la cuenta del cliente (explicado en el segundo artículo).
El detalle de las conexiones implementando un metastore interno con Glue, VPC Endpoints para STS y Kinesis y conexiones privadas es el siguiente:
- Conexión cluster-root bucket a través de Gateway Endpoint
- Conexión cluster-STS y cluster-Kinesis a través de Interface Endpoints
- Conexión a APIs REST a través de Private Link
- Secure cluster connectivity: conexión a infraestructura de control del cluster con tunel SSH inverso a través de Private Link
- Las instancias del cluster tienen solo acceso a la red privada y sus endpoints
El Secure cluster connectivity utiliza un certificado TLS alojado en un Hashicorp Vault en el Control Plane para el caso de Databricks Managed VPC y Customer Managed VPC.
En la siguiente imagen se puede observar cómo optando por la Customer Managed VPC podemos reutilizar esta dentro de diferentes workspaces:
Es importante resaltar que no se puede realizar una transición de configuración de una Databricks Managed VPC a una Customer Managed VPC.
Conexiones a través de red privada (Private Links)
En el caso de optar por una Customer Managed VPC vamos a poder realizar la conexión segura del cluster a través de un canal interno aprovisionando un Private Link para conectar el Control Plane y el Data Plane (back-end). De la misma manera se habilitará un Private Link para el acceso a todas las APIs REST desde el Data Plane (back-end).
Además, también se puede habilitar una VPC de tránsito con un Private Link y Site-to-Site VPN a través de la cual el usuario va a poder realizar una conexión privada al Control Plane (front-end).
Los requisitos para poder desplegar estos Private Links son los siguientes:
- Enterprise Plan
- Utilizar el SCC (Secure Cluster Connectivity, es decir, el túnel ssh inverso entre cluster – Control Plane). Este es el canal utilizado por defecto.
- Contactar con un representante de Databricks para poder configurar los endpoints en su infraestructura.
Todas estas conexiones pueden verse en la siguiente imagen:
En la documentación [2] oficial se describen los pasos necesarios a seguir para poder entablar estas conexiones.
En el caso de habilitar los Private Links tanto del front-end como del back-end se puede habilitar la opción de que Databricks rechace toda conexión realizada a través de canales públicos. Para este caso no se podría utilizar el metastore por defecto alojado en el Control Plane porque AWS todavía no soporta las conexiones de tipo JDBC a través de Private Link por lo que habría que utilizar un metastore externo o implementar uno con Glue en el Data Plane. Ver sección de Posibilidades de Metastore en el próximo artículo para más información.
Identidad y Gestión de accesos
Single sign-on (SSO)
Single Sign-On (SSO) permite a los usuarios la autenticación a través de un Identity Provider (IdP) proporcionado por la organización. Se requiere compatibilidad con SAML 2.0.
Las dos alternativas posibles al usar SSO son las siguientes:
- Añadir usuarios a través de su IdP y habilitar la creación automática de usuarios. Si la cuenta del usuario no existe en el momento de iniciar sesión, esta se creará automáticamente.
- Añadir usuarios en Databricks de manera manual y deshabilitar la creación automática de usuarios. Si la cuenta del usuario no existe en el momento de iniciar sesión este no podrá acceder.
En el momento de redacción de este documento los IdP soportados son los siguientes:
- Microsoft Windows Active Directory
- AWS SSO
- Microsoft Azure Active Directory
- Google Workspace (SSO v1.0 & v2.0)
- Okta SSO
- OneLogin SSO
- Ping Identity SSO
Se puede acceder a más información a través del siguiente enlace [3].
Control de acceso a AWS S3
En esta sección se describen las diferentes alternativas que existen para poder administrar el acceso de los usuarios a los diferentes buckets de S3 que existan dentro de la infraestructura del cliente.
Instance profile
Este método se basa en disponibilizar un instance profile para las instancias EC2 que componen el cluster. Se caracteriza por el hecho de que todos los usuarios con acceso al cluster tendrán los mismos permisos, es decir, los permisos que tenga el instance profile.
Los pasos a completar para poder realizar esta configuración son los siguientes:
- Crear instance profile en AWS con los permisos necesarios para acceder a los buckets. Se debe configurar para que confíe en el cross-account role.
- Añadir al cross-account role la capacidad de asumir este rol.
- Registrar el instance profile dentro de Databricks a través de la UI o llamada a API de Databricks.
- Lanzar un cluster con el instance profile adjunto.
Es importante resaltar que Databricks comprueba si se tienen los permisos necesarios para asumir el instance profile cuando se registra en Databricks. Esta comprobación es un dry-run en el que se intenta lanzar una instancia con este rol sin realmente llegar a desplegarla. En el caso en el que el cross-account role tenga restricciones de etiquetas (por ejemplo, Vendor: “Databricks”) esta comprobación fallará ya que este dry-run se ejecuta sin ninguna etiqueta.
Credentials passthrough (SCIM)
Este mecanismo permite definir permisos a nivel de usuarios/grupos de Databricks a través de un meta instance profile asociado a las instancias del cluster. La gran diferencia que supone esta alternativa a la discutida en el anterior apartado es el hecho de poder habilitar diferentes permisos para diferentes usuarios/grupos que utilicen el mismo cluster.
En la siguiente imagen puede verse esta relación en más detalle:
Por lo tanto, las instancias del cluster asumen el meta instance profile que actúa como contenedor de los diferentes data roles que se pueden asumir. Son estos data roles los que contienen los permisos para acceder a los diferentes buckets. Por otro lado, se utilizará la API SCIM para poder definir qué grupos de usuarios pueden asumir los diferentes data roles embebidos dentro del meta instance profile.
Es importante resaltar que no se pueden asumir varios data roles simultáneamente en el mismo notebook. Además, el instance profile debe ser registrado como meta instance profile, a diferencia del anterior apartado donde se registraba como instance profile.
Toda la información sobre este apartado puede verse en el siguiente enlace [4].
Credentials passthrough (SSO/SAML)
En el caso de que la organización disponga de un Identity Provider se podrá utilizar el Credentials passthrough con SSO y así poder utilizar AWS IAM federation para mantener el mapeo usuarios – roles IAM dentro de su Identity Provider. Esto puede ser interesante para las organizaciones que quieran mantener centralizado la gestión de sus usuarios y los privilegios que estos tienen.
El siguiente diagrama explica el workflow:
- Configurar el IdP con la cuenta de AWS para que el IdP pueda controlar qué roles puede asumir
- Los usuarios inician sesión en Databricks a través de SAML SSO, los permisos sobre los roles son definidos por el IdP
- Databricks llama al STS y asume los roles para los usuarios enviando la respuesta SAML y obteniendo tokens temporales
- Cuando un usuario accede a S3 desde un cluster de Databricks, el runtime de Databricks utiliza los tokens temporales para que el usuario pueda asumir el rol provisto que la respuesta SAML indica.
Por lo tanto, este apartado y el anterior tienen ciertas similitudes, ambos necesitarán de un meta instance profile que asumen las instancias del cluster y data roles con los permisos de acceso a los buckets de S3. La diferencia radica en que en este caso es la respuesta SAML la que indica que grupos de usuarios pueden asumir los diferentes data roles y en el caso de Credentials Passthrough (SCIM) es el propio Databricks el que lo denota.
Toda la información sobre este apartado se puede ver en la siguiente documentación [5].
Referencias
[1] Customer Managed VPC Databricks Guide. [link] (November 04, 2021)
[2] Enable AWS Private Link. [link] (December 17, 2021)
[3] SSO Set up Guide. [link] (September 28, 2017)
[4] Access S3 buckets using IAM credential passthrough with SCIM. [link] (December 3, 2017)
[5] Access S3 buckets using IAM credential passthrough SAML 2.0 federation. [link] (June 11, 2017)
¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
Inicié mi carrera con el desarrollo, mantenimiento y explotación de bases de datos multidimensionales y Data Lakes. A partir de ahí empecé a interesarme sobre sistemas de datos y arquitecturas en la nube, certificándome en AWS cómo Solutions Architect y entrando en la práctica de Cloud Native dentro de Bluetab.
Actualmente trabajo como Cloud Engineer desarrollando un Data Lake con AWS para una empresa que organiza eventos deportivos internacionales.
Durante los últimos años me he especializado como Data Scientist en distintos sectores (banca, consultoría,…) y la apuesta por cambiar a Bluetab estuvo motivada por el interés en especializarme como Data Engineer y comenzar a trabajar con los principales proveedores Cloud (AWS, GPC y Azure).
Consiguiendo así en primer lugar acceder al grupo de práctica de Data Engineer y colaborar en proyectos reales de data como el actual con Olympics.
SOLUCIONES, SOMOS EXPERTOS
Te puede interesar
Footer
