Databricks sobre AWS - Una perspectiva de arquitectura (parte 2)

Este artículo es el segundo de una serie de dos que pretende abordar la integración de Databricks en entornos AWS analizando las alternativas ofrecidas por el producto respecto al diseño de arquitectura. En el primero se habló acerca de temas más relacionados con la arquitectura y networking, en esta segunda entrega hablaremos sobre temas relacionados con la seguridad y administración general.

Los contenidos de cada artículo son los siguientes:

Primera entrega:

Planes y tipos de carga de trabajo
Arquitectura alto nivel
Networking
Identidad y Gestión de accesos

Esta entrega:

Seguridad
Escalabilidad
Persistencia
Billing
Despliegue

El primer artículo puede visitarse en el siguiente enlace [1].

Glosario

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. Ver primer artículo para más información.
Credentials Passthrough: mecanismo utilizado por Databricks para la gestión de accesos a las diferentes fuentes de datos. Ver primer artículo para más información.
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. Ver primer artículo para más información.
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. Ver primer artículo para más información.
Data role: 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. Ver primer artículo para más información. Ver primer artículo para más información.
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. Ver primer artículo para más información.
EC2 Fleet: configuración necesaria para poder definir las características con detalle de un grupo de instancias en AWS.
Elastic Block Store (EBS): servicio de almacenamiento de disco duro de AWS.
IAM Policies: políticas a través de las cuales se definen los permisos de acceso en AWS.
Key Management Service (KMS): servicio de AWS que permite crear y administrar claves de encriptación.
Pipelines: series de procesos en los que se ejecuta un conjunto de datos.
Prepared: datos procesados desde raw que se utilizaran como base para poder crear los datos Trusted.
Init Script (User Data Script): las instancias de EC2 lanzadas desde los cluster de Databricks permiten incluir un script con el cual instalar actualizaciones de software, descargar librerías/módulos, entre otros, en el momento que esta se arranca
Identity Federation: entidad que mantiene la información de identidad de los individuos dentro de una organización. Su uso principal es el de la autorización y autenticación.
Meta instance profile: rol que se provee al cluster con permisos para asumir los data roles. Ver primer artículo para más información.
Mount: Para evitar tener que cargar internamente los datos que se requieren para el proceso, Databricks posibilita la sincronización con fuentes externas, como S3, para facilitar la interacción con los distintos archivos (simula que estos se encuentran en local haciendo así más simple los relatives paths) pero realmente estos se encuentran almacenados en la fuente de almacenamiento externa correspondiente.
Personal Access (PAT) Token: token para la autenticación personal que sustituye la autenticación por usuario y contraseña.
Raw: datos ingestados sin procesar.
Root Bucket: directorio de raíz para el workspace (DBFS root). Utilizado para alojar cluster logs, revisiones de notebooks y librerías. Ver primer artículo para más información.
Secret Scope: entorno en el que almacenar información sensible mediante pares clave valor (nombre – secreto)
Trusted: datos preparados para su visualización y estudio por parte de los diferentes grupos de interés.
Workflows: secuencia de tareas.

Seguridad

En este apartado se analizará la seguridad de la información tratada en Databricks desde dos perspectivas: mientras la información se encuentra en tránsito y mientras los datos se encuentran en reposo.

Encriptación en tránsito

Encriptación en cliente (cluster-s3)

Este apartado trata sobre la encriptación de los datos enviados a los buckets desde el cluster para así poder definir unas policies en los buckets para rechazar toda comunicación entrante sin encriptar. La configuración necesaria para el root bucket y los buckets donde se guardan los datos (raw, prepared y trusted) son diferentes ya que el root bucket forma parte del DBFS.

Root bucket

Para poder encriptar la comunicación desde el cliente debemos incluir un fichero llamado core-site.xml en cada nodo del cluster a través de un init script, ya sea global o específico a un cluster. Esta configuración se rellena para el DBFS ya que el root bucket forma parte de este.

En este fichero debemos añadir el algoritmo a utilizar y la clave en KMS, pudiendo ser claves administradas por el cliente. Un ejemplo del contenido de este fichero podría ser el siguiente:

<property>
    <name>fs.s3a.server-side-encryption-algorithm</name>
    <value>SSE-KMS</value>
 </property>
 <property>
    <name>fs.s3a.server-side-encryption.key</name>
    <value>${kms_key_arn}</value>
 </property>

Definición del algoritmo y clave KMS a utilizar en la encriptación del root bucket

Data lake buckets

En el caso de los buckets del Data Lake debemos añadir unas configuraciones de Spark en el cluster para que éste configure la encriptación.

Un ejemplo de configuración podría ser el siguiente, donde en la parte inferior incluimos la misma información que en el anterior apartado, es decir, el algoritmo y clave de encriptación.

spark_conf = {
    "spark.databricks.repl.allowedLanguages" : "python,sql",
    "spark.databricks.cluster.profile" : "serverless",
    "spark.databricks.passthrough.enabled" : true,
    "spark.databricks.pyspark.enableProcessIsolation" : true,
    "spark.databricks.hive.metastore.glueCatalog.enabled" : true,
    "spark.hadoop.aws.region" : var.aws_region,
    #caches for glue to run faster
    "spark.hadoop.aws.glue.cache.db.enable" : true,
    "spark.hadoop.aws.glue.cache.db.size" : 1000,
    "spark.hadoop.aws.glue.cache.db.ttl-mins" : 30,
    "spark.hadoop.aws.glue.cache.table.enable" : true,
    "spark.hadoop.aws.glue.cache.table.size" : 1000,
    "spark.hadoop.aws.glue.cache.table.ttl-mins" : 30,
    #encryption
    "spark.hadoop.fs.s3a.server-side-encryption.key" : var.datalake_key_arn
    "spark.hadoop.fs.s3a.server-side-encryption-algorithm" : "SSE-KMS"
  }

Definición del algoritmo y clave a utilizar en la encriptación de los buckets del Data Lake

Esta configuración puede también incluirse a través de la UI de Databricks en la sección Spark config a la hora de crear el cluster.

Entre nodos del cluster

Existe la posibilidad de añadir una capa más de seguridad implementando la encriptación cuando la información es compartida entre los worker nodes cuando la consecución de las tareas así lo requiera.

Para facilitar la integración de este servicio se puede hacer uso de las instancias EC2 de AWS que encriptan el tráfico entre ellas por defecto. Estas son los siguientes:

Encriptación en reposo

En este apartado se describe cómo encriptar la información cuando esta está en reposo. Los métodos para encriptar estos datos son diferentes para el Data Plane y Control Plane ya que estos están administrados por diferentes entidades (Databricks y el cliente, respectivamente).

Encriptación s3 y EBS (Data Plane)

Para la encriptación de nuestra capa de persistencia dentro del Data Plane es necesario crear una clave dentro de KMS y registrar esta en Databricks a través de la Account API. Existe la posibilidad de elegir si encriptar solo el root bucket o el root bucket y EBS. Esta diferenciación se logra a través de la política que se adjunte a la propia clave, dando los permisos necesarios para encriptar buckets del Data Lake o incluir además la posibilidad de encriptar EBS.

Las características de esta funcionalidad son las siguientes:

Solo serán afectadas las operaciones de escritura posteriores a la adición de la clave de encriptación, es decir, los datos ya existentes que no se hayan actualizado seguirán sin encriptar.
La encriptación del Control Plane no se ve afectada.
Esta funcionalidad es compatible con la rotación automática de las claves en KMS.
Es importante resaltar que esta clave si se podrá registrar después de la creación del workspace en cuestión.

Toda la información sobre este tipo de encriptación está en el siguiente enlace [2].

Encriptación Control Plane

En este apartado se describe la manera de encriptar todos los elementos alojados en el Control Plane (notebooks, secretos y queries SQL e historial de queries).

Por defecto el Control Plane aloja una Databricks Managed Key (DMK) para cada workspace, una clave de encriptación administrada por Databricks. A continuación se deberá crear una Customer Managed Key (CMK) administrada por el usuario y registrarla a través de la Account API Databricks. Databricks entonces utiliza ambas claves para encriptar y desencriptar la Data Encryption Key (DEK), que es guardada como un secreto encriptado.

La DEK se cachea en memoria para varias operaciones de lectura y escritura y es desalojada de ésta en ciertos intervalos para que las consecuentes operaciones necesiten una nueva llamada a la infraestructura del cliente para obtener otra vez la CMK. Por lo tanto, en el caso de perder los permisos a esta clave, una vez el intervalo de tiempo de refresco se cumpla se perderá el acceso a los elementos alojados en el Control Plane.

Esto se puede ver más en detalle en la siguiente imagen:

Es importante resaltar que en el caso de querer añadir una clave de encriptación a un workspace ya creado habrá que realizar una PATCH request adicional a través de la Account API.

Toda la información sobre este tipo de encriptación está en el siguiente enlace [3].

Secret Management

El desarrollo de pipelines o workflows generalmente conlleva la necesidad de comunicación de información crítica o de carácter confidencial entre las distintas fases del proceso. Esta información en otros entornos Cloud suelen almacenarse en un Secret Scope para evitar comprometer la integridad de la misma. Un ejemplo de la información tratada en estos Secret Scopes podrían ser las credenciales de acceso a una base de datos.

Databricks posibilita una gestión integral con AWS, tanto del Secret Scope como de los secretos, mediante la API de Databricks. Se debe tener muy en cuenta que de forma predeterminada se asignan permisos de gestión completa (Manage permission) del Secret Scope a menos que esto se declare a la hora de desplegarlo (los permisos asignables al conjunto de usuarios son Read, Write y Manage).

Para suscripciones Premium o Enterprise, Databricks ofrece la posibilidad de gestionar los permisos a los usuarios de una manera más granular mediante el ACL (Access Control List) pudiendo así asignar distintos niveles de permisos en función del grupo de usuarios.

Estos secretos por defecto son almacenados en una base de datos encriptada gestionada por Databricks y el acceso a la misma puede gestionarse mediante Secret ACLs. Este tipo de información puede ser gestionada directamente desde el KMS de AWS volcando los pares clave-valor y gestionando los permisos de acceso al mismo mediante IAM.

Service Principal

Para todas aquellas tareas de administración en las que no proceda que las ejecute un miembro de la organización en particular podremos hacer uso del Service Principal.

Un Service Principal es una entidad creada para usarse con herramientas automatizadas, correr trabajos y aplicaciones, es decir, una cuenta de administración no nominal. Es posible restringir los accesos de esta entidad a través de permisos. Un Service Principal no puede acceder a Databricks a través de la UI, sus acciones son solo posibles a través de la APIs.

La manera recomendada para trabajar con esta entidades es que un administrador cree un token en representación del Service Principal para que este pueda autenticarse con el token y realizar las acciones necesarias.

Se han encontrado las siguientes limitaciones al trabajar con un Service Principal:

Se debe crear un PAT Token antes para inicializar el módulo de tokens, si no resultará en un error al intentar crear el token para el Service Principal.
Un Service Principal no puede crear un cluster, deberá ser creado por un administrador.

Escalabilidad

Alternativas de escalado

Databricks, al igual que otros servicios que ofrecen la posibilidad de desplegar un cluster serverless también ofrece una funcionalidad común al resto como es el auto-escalado. Esta funcionalidad está gestionada completamente por Databricks en cuanto a las distintas situaciones que deben darse para que se decida auto-escalar el número de nodos del cluster (scaling out) o la tipología de los mismos (scaling up).

Databricks destaca en esta funcionalidad respecto a la competencia debido a que ofrece un auto-escalado optimizado que consigue de promedio un ahorro del 30% mayor respecto al resto de soluciones (aunque también ofrece la posibilidad de implantar la versión estándar). La principal diferencia entre la versión optimizada y la estándar está en la incorporación del scale-down.

El que otras soluciones no incluyan el “scale-down” se debe a que la eliminación de nodos puede comprometer al proceso, ya que aunque el nodo en cuestión no esté realizando ninguna tarea puede contener información en caché o shuffle files que sí vayan a ser necesarios para procesos futuros en otros nodos. Esta acción se considera como sensible ya que la eliminación de un nodo que contenga información utilizada en otros procesos provocaría la necesidad de reprocesamientos, lo cual generaría unos costes mayores al del ahorro generado por el scale-down.

Databricks, en la nueva actualización, implementa una validación en la identificación de los nodos menos requeridos cuando se produce una infrautilización del cluster, teniendo en cuenta lo siguiente:

No se estén ejecutando tareas
No se identifiquen shuffle files o información en caché necesaria para procesos futuros aunque estos procesos vayan a ejecutarse en otros nodos.

Con esto lo que se permite es un “scale-down” más agresivo ya que en todo momento se tienen identificados qué nodos son susceptibles de eliminar sin poner en riesgo la integridad del proceso. Databricks toma medidas preventivas en este tipo de escalado e implanta tiempos de espera extra para validar con una mayor seguridad que esta acción es correcta (Job Cluster: 30’’ , All-Purpose Cluster: 2’ 30’’)

A la hora de autoescalar, ya sea scale-up o scale-down, se tiene en cuenta tanto el grado de saturación/infrautilización de CPU general, como la de los nodos por individual, pudiendo identificarse los siguientes escenarios:

Up-Scaling: si el uso de CPU supera el 80%, todos los nodos están siendo utilizados y esto se mantiene al menos durante 30’’, se procede al scale-up hasta que esta situación deje de darse.
Down-Scaling: Además de las comprobaciones anteriormente mencionadas debe identificarse que el 90% de los nodos no estén ocupados al menos durante 10’, una vez transcurrido este tiempo si la situación no ha cambiado se procede al scale-down

El autoescalado optimizado de Databricks se recomienda especialmente cuando las tareas tienen picos pronunciados, ya que esto genera un rápido escalado para soportar la demanda y en caso de que sea un pico puntual y la demanda no se mantenga, estos nodos quedarían operativos aunque no vayan a procesar información:

Workers usage packaging

En búsqueda de la eficiencia general del cluster surgen iniciativas como la posibilidad de realizar agrupaciones para que la asignación de tareas sea lo más óptima posible y haga que otras acciones, como el auto-escalado, puedan llevarse a cabo de una forma más eficiente y sin comprometer la integridad de los procesos.

Esta agrupación de nodos en función del uso se realiza por dos motivos principales, la priorización en la asignación de tareas a nodos (indicado el orden de prioridad en la siguiente imagen), y la correcta identificación de saturación o infrautilización generalizada de los nodos del clúster. La agrupación es la siguiente:

Low Usage: sin contenedores y el uso de CPU menor de 30%
Medium Usage: uso de la CPU mayor al 30%
High Usage: uso del CPU mayor al 60%

Como se ha mencionado anteriormente, son dos las grandes ventajas que se consiguen con este tipo de agrupaciones:

Identificación de nodos infrautilizados: optimización a la hora de asignar qué nodos van a ser eliminados en caso de que se requiera un scale-down

Priorización en la asignación de tareas: Como se indica en la imagen, se asigna una priorización de nodos a la hora de asignar tareas, siendo esta “Medium Usage” > “Low Usage” > “High Usage”, para que, en un primer lugar, se pueda asignar siempre a los nodos ya usados y en caso de que haya que realizar un scale-down se disponga de nodos “libres” disponibles, y en segundo lugar, no sobresaturar los nodos que ya se encuentran operativos:

Como alternativa a esta agrupación, Databricks ofrece un soporte de almacenamiento externo (External Shuffle Service – ESS) para así tener el grado de saturación del nodo como único factor a tener en cuenta a la hora de decidir qué nodo eliminar en los procesos de scaling-down.

Familia de instancias para el cluster

A la hora de poder definir más las características del cluster que aporten más poder de adaptación a las diferentes casuísticas que se puedan dar existe la alternativa que se denomina EC2 Fleet.

Esta se basa en poder solicitar instancias ofreciendo un abanico de posibilidades en cuanto al tipo de instancias (ilimitado) y las availability zones donde se deben adquirir estas. Permite también definir si las instancias son On-Demand o Spot, pudiendo especificar en ambos casos el precio máximo de adquisición:

El uso de EC2 Fleet no supone un coste extra, se paga únicamente por el coste de las instancias.

Existen las siguientes limitaciones relacionadas con este servicio:

Servicio disponible únicamente vía API o AWS CLI
La solicitud se limita a una región

Cabe destacar que dicha solución se encuentra en Private-Preview en el momento en el que se escribió este artículo.

Persistencia

DBFS

Con el fin de posibilitar el despliegue de los cluster de Spark, Databricks recurre a DBFS como sistema de almacenamiento distribuido. Este se apoya en terceros, como es el caso de S3, para así ser capaz tanto de lanzar como de llevar a cabo las tareas requeridas.

DBFS permite la vinculación de fuentes de almacenamiento como S3 mediante los mount, lo que permite simular la visualización de los archivos almacenados en local, aunque estos sigan estando físicamente almacenados en S3. Esta simulación facilita tanto las tareas de autenticación a la hora de consultar los archivos y a su vez la simplificación de los paths a la hora de referenciar los mismos, evitando así tener que cargar los archivos en DBFS cada vez que estos sean consultados.

Además, la información almacenada por el cluster al desplegarse, como puede ser los scripts iniciales, tablas generadas, metadata, etc. Pueden ser almacenados en fuentes de almacenamiento como S3 para que estén disponibles aunque el clúster no lo esté.

Posibilidades de Metastore

A la hora de elegir como y donde desplegar el metastore Databricks propone las siguientes alternativas:

Metastore Hive (por defecto): utilizar el metastore Hive por defecto desplegado en el Control Plane. Este metastore estará administrado completamente por Databricks.
Metastore Hive externo: posibilidad de utilizar un metastore Hive externo ya existente.
Metastore Glue en Data Plane: posibilidad de alojar el metastore en el propio Data Plane con Glue.

Es importante resaltar que es necesario tener una Customer Managed VPC para las opciones de Hive externo y Glue. Ver primer artículo para más información.

Las alternativas de un metastore externo, ya sea Hive o Glue, podrían ser interesantes en los casos que se necesite acceder a un metastore ya existente, centralizando estos catálogos, o que se busque tener más autonomía y control. También al realizar la implementación con Glue se podría facilitar el acceso a estos metadatos desde otros servicios en AWS, como por ejemplo Athena, y también presenta una latencia de acceso a estos más baja al poder realizar la comunicación a través de la red privada de AWS.

Billing

En este apartado se describe brevemente donde poder acceder con detalle a la información acerca de los costes que Databricks va a imputar al cliente.

Para poder acceder a esta información es necesario completar la configuración necesaria para generar y alojar estos logs dentro de la infraestructura desplegada en AWS. Toda esta información puede consultarse en el siguiente enlace [4].

Los logs presentan una generación diaria (debe haber estado operativo el workspace al menos 24 h) en el que se imputan las horas de cómputo y la tarifa que se aplica a dichas horas en función de las características del cluster y el paquete asignado por Databricks.

Campos	Descripción
workspaceId	Workspace Id
timestamp	Frecuencia establecida (horaria, diaria,...)
clusterId	Cluster Id
clusterName	Nombre asignado al Cluster
clusterNodeType	Tipo de nodo asignado
clusterOwnerUserId	Id user creador del cluster
clusterCustomTags	Etiquetas de información personalizables del cluster
sku	Paquete asignado por Databricks en relación a las características del cluster
dbus	Consumo de DBUs por hora máquina
machineHours	Horas máquinas de despliegue del cluster
clusterOwnerUserName	Username del creador del cluster
tags	Etiquetas de información personalizables del cluster

Despliegue

Alternativas para el despliegue

En este apartado se describirán las diferentes alternativas y herramientas que se pueden utilizar para poder desplegar un entorno funcional y seguro de Databricks sobre AWS.

Databricks-AWS Quickstart

Esta alternativa se caracteriza por la ejecución de un script de CloudFormation creado por Databricks que da la posibilidad de crear una Databricks Managed VPC o Customer Managed VPC.

Para ambas modalidades Databricks crea un cross-account role con los permisos necesarios (que difieren para cada alternativa, siendo los de la opción de Customer Managed VPC más limitados) y crea una Lambda a través de llamadas a las APIs de Databricks para levantar la infraestructura necesaria, configurar esta y registrarla dentro del Control Plane. Todas estas llamadas harán uso del cross-account role para poder autenticarse en la cuenta de AWS del cliente.

Infraestructura como código (IaaC)

CloudFormation

CloudFormation es el servicio de infraestructura como código de AWS. Se podría reutilizar el código creado por Databricks en el Quickstart pero esta alternativa supondría un uso demasiado intensivo de las APIs ya que no existen módulos específicos para el despliegue con Databricks.

Terraform

Terraform es una herramienta de infraestructura como código que es agnóstica a los distintos proveedores de nube, es decir, se puede utilizar con cualquiera de ellos.

Terraform presenta unos módulos disponibles para Databricks que simplifican el despliegue y reducen la necesidad de hacer llamadas a las APIs de Databricks pero que no la eliminan completamente. Por ejemplo, habrá que hacer llamadas a una API para poder utilizar el Credentials Passthrough sin una Identity Provider (SSO).

En esta iniciativa se ha creado un repositorio [5] de GitHub público para poder desplegar un entorno haciendo uso de esta herramienta.

Se ha dividido la infraestructura a desplegar en diferentes módulos por simplicidad, los principales son los siguientes:

VPC: despliegue de todas las redes, endpoints, NAT Gateways, etc… necesarias.
S3: creación del root bucket (bucket donde Databricks guarda librerías y logs) y los buckets donde vamos a almacenar los datos a tratar.
Databricks IAM roles: creación del cross-account role, meta instance profile, data roles, rol para glue y rol para que el cluster pueda dejar los logs en el bucket.
Databricks cluster: módulo para la creación y despliegue de un cluster de instancias de EC2 para su uso en Databricks.
Databricks provisioning: registro de toda la infraestructura en Databricks (credenciales, redes y almacenamiento) y creación de workspace dentro de Databricks.
Databricks management: creación de grupos de usuarios, clusters e instance profiles (meta rol que se asigna al cluster que tiene capacidad de asumir los data roles).

Por lo tanto, el diagrama de la arquitectura a alto nivel es el siguiente:

El despliegue completo se puede realizar por debajo de los 5 minutos.

Lanzamiento de Clusters

A la hora de estimar un tiempo promedio en el lanzamiento y disponibilidad de las instancias se ha considerado oportuno diferenciar en subgrupos debido a la similitud del tiempo empleado en cada uno de ellos:

Pool: en el caso del Pool de Instancias no tiene como única ventaja el disponer de instancias disponibles ya arrancadas para ser usadas (aunque esto repercuta en un coste), si no que es el cluster que facilita las mismas en un menor tiempo (resaltar que no es necesario esperar a que se obtengan el número de instancias mínimas para hacer uso de ellas):

Además, cabe destacar que los tiempos indicados a continuación son correctos para la primera instancia que se levanta, para el resto el tiempo se reduce considerablemente.
Job y All-Purpose Cluster: en caso del All-Purpose cluster se ha analizado el modo High-Concurrency al ser necesario para trabajar de forma colaborativa. En este caso, los tiempos son algo mayores respecto al anterior, consumiendo entre 3-4 minutos para un cluster estándar:

Requisitos mínimos de infraestructura AWS:

En la siguiente tabla se especifican los requisitos mínimos respecto a redes, computación y almacenamiento que desde nuestro punto de vista debe tener un despliegue en cliente. Es importante resaltar que esta presenta diferencias con el repositorio de GitHub presentado en el capítulo de Despliegue.

Las diferencias son las siguientes:

Comunicación Control Plane – Data Plane: El repositorio implementa una comunicación pública a través de una NAT y en esta tabla se propone la utilización de un Private Link para poder realizar la conexión a través de la red privada de AWS. Visitar el primer artículo para acceder a más información.
Comunicación user – Front-end (Control Plane): El repositorio implementa una comunicación pública a través de internet y en esta tabla se propone la utilización de una VPN conjuntamente con unos Private Links, para poder realizar la comunicación a través de la red privada de AWS. Visitar el primer artículo para obtener más información.

GROUP	SUBGROUP	MINIMUM REQUIREMENTS	EXTERNAL NEEDS
Networking	Subnets	3 private subnets with 3 Availability Zones	N/A
	VPC Endpoints	S3 Gateway Endpoint STS Interface Endpoint Kinesis Interface Endpoint	N/A N/A N/A
	Private Links	VPC Endpoint for connection Cluster (Data Plane) - Control Plane VPC Endpoint for connection with REST APIs (Control Plane) VPC Endpoint for connection user-frontend (Control Plane)	Contact with authorized Databricks support contact Contact with authorized Databricks support contact Contact with authorized Databricks support contact
	VPN	Site to site VPN para conectar la red del cliente con la VPC de tránsito	Communication with the customer
Compute	Minimal instances	Zero with one autoscaling group	N/A
Storage	Bucket Instances	S3 EBS Volumes	N/A N/A

Requisitos mínimos necesarios para el despliegue de Databricks en AWS

Referencias

[1] Databricks on AWS – Architectural Perspective (part 1) [link] (January 13, 2022)

[2] EBS and S3 Encryption on Data Plane [link]

[3] Control Plane Encryption [link]

[4] Billing Logs Access [link]

[5] Databricks Deployment on AWS – GitHub Repository Guide [link]

Navegación

Requisitos mínimos necesarios para el despliegue de Databricks en AWS

Referencias

Autores

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?

Alberto Jaen

AWS Cloud Engineer

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.

Alfonso Jerez

AWS Cloud Engineer

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.