AWS Cloud Engineer
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:
Segunda entrega (próximamente):
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:
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:
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.
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:
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.
En el siguiente diagrama se muestran los canales de comunicación entre Control Plane y Data Plane:
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:
Esta alternativa se caracteriza porque el Data Plane está administrado por el cliente. Las bondades de esta alternativa son las siguientes:
El detalle de las conexiones implementando un metastore interno con Glue, VPC Endpoints para STS y Kinesis y conexiones privadas es el siguiente:
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.
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:
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.
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:
En el momento de redacción de este documento los IdP soportados son los siguientes:
Se puede acceder a más información a través del siguiente enlace [3].
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:
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.
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:
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].
[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)
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.
Patrono
Patrocinador
© 2022 Bluetab Solutions Group, SL. All rights reserved.