• Saltar a la navegación principal
  • Saltar al contenido principal
  • Saltar al pie de página
Bluetab

Bluetab

an IBM Company

  • Soluciones
    • DATA STRATEGY
    • DATA READINESS
    • DATA PRODUCTS AI
  • Assets
    • TRUEDAT
    • FASTCAPTURE
    • Spark Tune
  • Conócenos
  • Oficinas
    • España
    • Mexico
    • Perú
    • Colombia
  • talento
    • España
    • TALENT HUB BARCELONA
    • TALENT HUB BIZKAIA
    • TALENT HUB ALICANTE
    • TALENT HUB MÁLAGA
  • Blog
  • English

Blog

Gobierno del Dato: Una mirada en la realidad y el futuro

mayo 18, 2022 by Bluetab

Gobierno del Dato: Una mirada en la realidad y el futuro

Silvia Juliana Rueda Urrea

Experienced Consultant

En las últimas décadas las organizaciones han cambiado continuamente desde una mirada en el mejoramiento, el aprovechamiento de las oportunidades, la innovación y los ejes diferenciadores para superar a la competencia.

Un claro ejemplo de lo expuesto, es el gobierno del dato, para organizar la información, mantener una mejor comunicación con los consumidores y tomar decisiones.

Para White (2019), es indispensable que las organizaciones adopten el gobierno del dato para mejorar su rendimiento organizacional, brindar oportunidades a los clientes y contribuir al desarrollo de cualquier actor dentro de las empresas; además de logar a mediano plazo estar en el mundo globalizado de la virtualidad.

Desde este punto de vista, el gobierno de datos ayuda a tener una ventaja competitiva, superar los obstáculos, innovar con nuevos aprendizajes y establecer planes de acción ante posibles riesgos. En la importancia del gobierno de datos, es válido resaltar que, su organización o aplicabilidad depende de los contextos de las entidades; sin embargo, suele ser flexible, pero con elementos directivos de seguridad, calidad, agilidad en el almacenamiento y los expertos que se encargarán del circuito deberán tener profesionalismo, experiencia y compromiso.

Lo expuesto, genera una reflexión autónoma como participativa, que se centraliza en que el gobierno del dato permite el crecimiento de las organizaciones, los mantiene en el auge tecnológico y en la competencia, sin olvidar las necesidades del cliente.

Para organizaciones mundiales como IBM, la gestión de los datos brinda la oportunidad de flexibilizar las estrategias, tener analítica en la confianza, determinar la privacidad, seguridad, gestión de la información y sobre todo la catalogación inteligente del dato.

El gobierno del dato facilita una accesibilidad, trasformación, la actualización rápida y la operacionalización dinámica en las necesidades o quehaceres diarias de las entidades, pero, sus múltiples ventajas dependerán de las cualidades de las empresas de forma independiente y los objetivos que se tracen desde la visión panorámica de un proceso continuo y permanente (Lurillo, 2020).

Gobierno del dato

El Gobierno del dato permite a las organizaciones tomar mejores decisiones, ajustarse a la calidad, custodiar y seguir circuitos con la participación de todos los proyectos para tener exitosos resultados.

El gobierno del dato en sus muchas oportunidades y capacidades se caracteriza por tener un foco específico en el aprovechamiento de la tecnología por el uso de programas que permiten la agilidad y la gobernanza; además de tener una eficiencia de valor TI, tener mejor impacto productivo y dar soluciones ante problemáticas del entorno.

Otra de las características que priman en el gobierno del dato es el conocimiento específico del mismo y su uso transformacional con calidad, transparencia y migración. Entonces, ante las realidades y novedades de los datos, las organizaciones deben estar al día y adoptar las anteriores variables.

El gobierno del dato se encuentra en diferentes sectores de la misma organización como por ejemplo la arquitectura de datos, la custodia, la ingesta y el tratamiento de disposición final; estos pasos suelen estar acompañados de sus procesos, equipos generalizados y profesionales expertos. Estas capacidades del gobierno parten de las demandas del contexto, de los proyectos, una identificación inicial, un análisis panorámico, el perfilamiento, la definición, gestión, despliegue de almacenamiento y aprovechamiento final para una gestión especifica en los sectores productivos, financieros o empresariales (Ministerio de Tecnologías de la Información y las Comunicaciones, 2014).

Acciones

En la transformación digital de las organizaciones

Escrito por Silvia Juliana Rueda Urrea

Ante las acciones y ejecuciones, las organizaciones pueden generar impactos con los elementos de la figura anterior, tales como la gobernanza, la seguridad, el afianzamiento de la calidad, la migración de los datos desde los sistemas orígenes a los repositorios finales, el ciclo de vida del dato y todo en relación con la actualización y estandarizaciones en novedades digitales.

En cada sentido y horizontalidad de la gestión de los datos, el equipo debe manejar sólidas metodologías para alcanzar los objetivos y buscar que el equipo pueda contribuir a las metas con sus capacidades, habilidades y destrezas individuales como colectivas. 

 

En el camino tecnológico "un después de la pandemia”

Con relación a la situación de pandemia en todos los sectores se obtuvo una transformación significativa.

turned on gray laptop computer

Con las necesidades de innovación por los cierres masivos de las organizaciones, estas aprovecharon los datos y el auge digital para impactar en su quehacer, reapertura y adaptarse a las realidades tecnológicas.

Respecto a las innovaciones, con el paso de los días se crean nuevos sistemas que apoyan la gestión de los datos y que permiten tener óptimos resultados en la gestión diaria de cada empresa.

Finalmente, la invitación es abierta a seguir en el camino del cambio, de la tecnología y del aprovechamiento de los datos que seguramente son el camino al futuro.

Referencias Bibliográficas

IBM. Gestión de datos. 

Lurillo, M. (2020). Actividades Claves en el diseño de una estrategia de Gobierno de Datos. 

Ministerio de Tecnologías de la Información y las Comunicaciones. (2014). G.INF.06 Guía Técnica de Información – Gobierno del dato. 

White, D. (2019). Por qué los datos serán la clave del éxito en el futuro de las empresas. Opinión – BBVA. 

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

Silvia Juliana Rueda Urrea

Experienced Consultant

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Serverless Microservices

octubre 14, 2021
LEER MÁS

Data governance in the Contact Center services sector

septiembre 1, 2022
LEER MÁS

Oscar Hernández, nuevo CEO de Bluetab LATAM

mayo 16, 2024
LEER MÁS

Hashicorp Boundary

diciembre 3, 2020
LEER MÁS

Big Data e IoT

febrero 10, 2021
LEER MÁS

LakeHouse Streaming on AWS with Apache Flink and Hudi (Part 2)

octubre 4, 2023
LEER MÁS

Publicado en: Blog, Tech

Databricks on Azure – An architecture perspective (part 2)

marzo 24, 2022 by Bluetab

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

Francisco Linaje

AWS Solutions Architect

Gabriel Gallardo Ruiz

Senior Data Architect

En esta segunda entrega nos centraremos en analizar los diferentes servicios que ofrece Databricks para asegurar el escalado de nuestros servicios y la recuperación ante fallas del sistema, así como otros aspectos relativos a la seguridad como encriptación de los datos tanto reposo como en tránsito.

Primera entrega (link):

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

Segunda entrega:

  • Disaster Recovery
  • Escalabilidad
  • Seguridad
  • Logging y monitorización

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
  • Azure Data Lake: Permite almacenar múltiples formatos de datos en un mismo lugar para su explotación y análisis, actualmente Azure dispone la versión Gen2 .
  • Azure Key Vault: Servicio administrado de Azure que permite el almacenamiento seguro de secretos.
  • Azure Virtual Network (VNET): Red virtual aislada lógicamente en Azure.
  • DBFS (Databricks File Systen): Sistema de archivos de Databricks que se monta sobre los sistema de archivos distribuido de los Cloud Providers.
  • Data Lake: Paradigma de almacenamiento distribuido de datos provenientes de multitud de fuentes y formatos, estructurados, semi estructurados y sin estructurar.
  • Identity Provider (IdP): Entidad que mantiene la información de identidad de los individuos dentro de una organización.
  • Infraestructura como código o IaC: gestión y aprovisionamiento de la infraestructura a partir de código declarativo.
  • 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
  • Network Security Group o NSG: Especifican las reglas que regulan el tráfico de entrada y salida de la red y los clusters en Azure
  • Private Link: Permite el acceso privado (IP privada) a Azure PaaS a través de tu VNET, de la misma forma que los service endpoints el tráfico se enruta a través del backbone de Azure.
  • SQL Compute: Cluster reservados a queries para la visualización de la información almacenada en el Data Lake
  • Secret scope: Colección de secretos identificados por un nombre.
  • 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 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.
  • Service endpoints: Componente de red que permite conectar una VNET con los diferentes servicios dentro de Azure a través de la propia red de Azure.
  • TLS/ TLS1.2 (Transport Layer Security): es un protocolo de cifrado y comunicación que proporciona comunicaciones seguras por una red, comúnmente Internet.
  • 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.

Disaster Recovery

Entendemos por Disaster Recovery al conjunto de políticas, herramientas y procedimientos que permiten la recuperación de la infraestructura cuando el sistema en su conjunto cae, como por ejemplo una caída de una región de Azure.

No debemos confundir estas políticas y herramientas con las empleadas en materia de alta disponibilidad de nuestro sistema (mínimo nivel de servicios).

Para ello, cuando implementamos una solución en la nube, una de las principales preguntas que debemos plantearnos a la hora de diseñar e implementar nuestra solución es:

  • ¿Qué piezas son críticas en nuestro sistema?
  • ¿Qué daños pueden provocar en el servicio?
  • ¿Cómo puede el sistema adaptarse y recuperarse ante estos errores?

Dar respuesta a estas preguntas es de vital importancia si deseamos que nuestra solución pueda cumplir adecuadamente el estándar de calidad que hayamos planteado.

Para este punto debemos analizar en que ámbito de nuestra solución opera Databricks y que herramientas o pautas debemos seguir para que la plataforma pueda cumplir con su servicio.

Debemos recordar que Databricks ofrece soluciones en materia de transformación y almacenamiento de datos tanto batch como en streaming, utilizando Azure Blob storage como capa de persistencia de datos no estructurados, como asimismo diferentes herramientas relacionadas con orquestación de jobs o análisis ad-hoc de datos vía SQL como servicio de analitica. Por lo tanto en este punto veremos que diferentes herramientas pueden ser propuestas para sincronizar nuestros workspaces,activos/recursos involucrados entre nuestras regiones.


Conceptos DR

Para poder comprender que es Disaster Recovery, deberemos primero comprender dos conceptos importantes:

Recovery Point Objective (RPO)

Hace referencia a la cantidad de datos máxima pérdida (medida en minutos) aceptable después de una caída del sistema. En este caso al disponer de Azure Blob Storage como sistema de persistencia distribuido, el concepto aplicaría a los datos de usuario temporales almacenados por Databricks, como por ejemplo cambios realizados en nuestros notebooks.

Recovery Time Objective (RTO)

Entendemos por RTO al periodo de tiempo desde la caída del sistema hasta la recuperación del nivel de servicio marcado.

En la siguiente imagen, podemos observar ambos conceptos de una forma visual:

Esquema conceptual sobre los conceptos RPO/RTO (fuente: Databricks)

Es importante indicar que la corrupción existente en los datos no se verá mitigada por las políticas asociadas a DR, sin embargo Databricks ofrece Delta time travel como sistema de versionado.

Tipos de región y redundancia

Una vez comprendido los conceptos de RPO y RTO, deberemos comprender los diferentes tipos de regiones en los que operará nuestra solución:

  • Región primaria: Región principal donde opera el sistema de forma normal.
  • Región secundaria: Región alternativa que entrará en operativa en caso de caída de la región primaria.

En nuestro caso de uso, estamos implementando un workspace de Databricks, por lo tanto emplearemos como capa de persistencia principal Blob Storage. Este servicio ofrece diferentes posibilidades a la hora de replicar nuestros datos entre regiones, vamos a verlas.

Region primaria

  • Almacenamiento con redundancia local (LRS): se realizan tres copias síncronas dentro de una única ubicación física en la región primaria, reduciendo así el coste, pero afectando a la disponibilidad y durabilidad (once nueves) de los datos.
Diagrama de replicación LRS (fuente: Azure)
  • Almacenamiento con redundancia de zona (ZRS): copia síncrona de los datos en tres zonas de alta disponibilidad en la región primaria (doce nueves).
Diagrama de replicación ZRS (fuente: Azure)

Region primaria y secundaria

  • Almacenamiento con redundancia geográfica (GRS): Se realiza una copia LRS en la región primaria y secundaria.
Diagrama de replicación GRS (fuente: Azure)
  • Almacenamiento con redundancia de zona geográfica (GZRS): Se realiza una copia con ZRS en la región primaria y mediante LRS en la región secundaria.
Diagrama de replicación GZRS (fuente: Azure)

En ambos casos, el acceso a los datos en la región secundaria no estará disponible salvo activación de la opción de lectura RA.

Dadas estas configuraciones, en la siguiente imagen se pueden ver los escenarios planteados en los que nuestros datos dejarían de ser accesibles.

Disponibilidad y acceso al dato según la redundancia configurada (fuente: Azure)

Deberemos configurar el nivel de replicación y redundancia entre zonas con el fin de disponer de nuestros datos sincronizados y disponibles en las regiones secundarias con el fin de que estás puedan estar operativas.


Tipos de despliegue

Dentro de los tipos de despliegue, podemos encontrar diferentes combinaciones según la necesidad de respuesta y los costes que deseamos asumir por su disponibilidad.

  • Activo: Despliegue principal que ejecuta las funcionalidad y servicios propios del sistema.
  • Pasivo: Procesos que no operan en el despliegue principal y permanecen inactivos/pasivos hasta que el despliegue activo deje de funcionar por una caída.

Es posible encontrar combinaciones de estos: activo-pasivo, activo-activo. De forma general:

Backup Restore
Es la estrategia más económica y lenta que podemos implementar. El objetivo principal es tener un conjunto de puntos de restauración en ambas regiones que podamos emplear para recuperar el servicio, sin necesidad de aprovisionar elementos core del sistema en otras regiones. 

Pilot Light 
Las piezas más importantes de nuestro sistema se encuentran desplegadas de forma activa pero bajo mínimos dentro de nuestra región secundaria, de forma que ante una caída del sistema los servicios principales podrían estar operativos y podrían escalarse de forma gradual (activo-pasivo).

Warn Standby
Estaríamos en un escenario muy similar a Pilot Light pero donde no solo tendríamos activos nuestros sistemas principales sino también una buena parte de los secundarios funcionando bajo mínimos pero listos para ser escalados (activo-pasivo).

Multi-site
Este plan ofrece el mayor grado de respuesta ya que implica disponer de forma activa todas nuestras piezas en una región secundaria, listas para dar servicio en caso de caída de la región principal (activo-activo)

Deberemos elegir la estrategia que mejor se adapte a nuestro caso de uso que dependerá principalmente del nivel de respuesta y coste asumible.


Workflow típico de recuperación

Dentro de los diferentes procedimientos, encontramos la estrategia activa-pasiva como la solución más sencilla y barata pero a la vez efectiva a la hora de ofrecer respuesta y servicio en el caso donde tras una caída del sistema en la región principal, el sistema pasivo entra en funcionamiento dando soporte al servicio.

La estrategia podría ser implementada de forma unificada para toda la organización o por grupos/departamentos de forma independiente basados en sus propias reglas y procedimientos.

De una forma global nos encontraremos que el procedimientos típico a alto nivel sería el siguiente:

  • Caída de un servicio crítico en la región primaria: red, origen de datos, etc
  • Se levanta el servicio en la segunda región si ésta no está afectada.
    • Se deben parar todas las actividades relacionadas con el workspace que sigan en funcionamiento en la región primaria y realizar un backup de los cambios recientes si es posible.
    • Se inicia el proceso de recuperación de los servicios sobre la región secundaria. Actualizando el enrutamiento y direcciones de dominio a la nueva región.
  • Se verifica que el servicio funciona correctamente y con normalidad.
  • En algún punto, la incidencia en la región primaria se ve resuelta y los servicios de Azure vuelven a un funcionamiento normal. Por lo tanto se deberá restablecer el sistema sobre la región primaria.
    • De forma idéntica al punto 2.a se deben parar todos los servicios y cargas de trabajo en la región secundaria.
    • Además se deben de volver a actualizar el enrutamiento y las direcciones de dominio a la región primaria.
    • Por último se debe de realizar un backup de los datos generados durante la caída de la región primaria para ser replicados en esta.
  • Finalmente se verifica que el servicio vuelva a funcionar correctamente y con normalidad en la región primaria.

Una vez nos hacemos una idea general de como sería un workflow típico de recuperación activo-pasivo, estudiaremos como podemos aplicarlo dentro de Databricks en nuestros workspaces.


Disaster Recovery en Azure Databricks

Databricks como plataforma de Data Analytics, tiene los datos como principal activo. Por ello se deben de definir las estrategias que permitan no solo poder seguir operando los servicios de la plataforma y workflows productivos en la región de soporte, sino la estrategia que permita generar consistencia en la propia replicación de los diferentes data sources.

En la siguiente imagen se especifican a modo de diagrama los diferentes activos que se verían involucrados en la replicación del plano de control o de datos.

Estrategia y herramientas en la sincronización.

Una vez realizado un análisis de nuestro sistema, deberemos analizar pieza por pieza como podemos realizar el procedimiento de réplica y sincronización.

Existen dos principales estrategias:

  • Un cliente que sincroniza los datos productivos y activos de la región primaria a la secundaria en un flujo programado.
  • Herramientas de integración/despliegue continuo (CI/CD) para el despliegue de forma paralela de la infraestructura, código y otros recursos principales del sistema en ambas regiones, de forma que la región secundaria se encuentre sincronizada con todos los cambios y desarrollos para ser operativa en caso necesario.
Esquema de sincronización vía CI/CD (fuente: Databricks)

Herramientas

Databricks ofrece en la siguiente tabla un resumen del conjunto de estrategias que se podrían aplicar según el recurso/activo involucrado de nuestro workspace. 

Es importante señalar que a día de hoy no hay ningún servicio oficial por parte de Databricks que permita administrar e implementar una política activa-pasiva de los workspaces en Azure.

Herramientas de replicación
FEATURE
Sync Client
CI/CD
Código fuente, notebooks, librerías
Sincronización con la región secundaria
Despliegue en ambas regiones
Usuarios y grupos
Empleo SCIM para la sincronización en ambas regiones
Control de los metadatos de los usuarios y grupos a través de GIT.
Configuración de los pools
Empleo del CLI o API para la creación en la segunda región
Empleo de templates. Configurar la región secundara con min_idle_instances a 0
Configuración de los jobs
Empleo del CLI o API para la sincronización con la segunda región
Empleo de templates. Configurar la región secundaria con concurrencia a 0
ACLs
Mediante la API de Permisos 2.0 es posible replicar los controles de acceso sobre los recursos copiados
Empleo de templates.
Librerias
DBFS
Repositorio central
Scripts de inicialización del cluster
Replicar de una región a otra a través del almacenamiento en el workspace
Repositorio central
Metadata
Incluir las DDL en el código fuente.
Secretos
Replicacion via API o CLI en el momento de creación
Configuraciones del cluster
Replicacion via API o CLI en el momento de creación
Empleo de templates en GIT.
Permisos de Notebooks, jobs y directorios
Replicación mediante la API de Permisos 2.0
Empleo de templates en GIT.

Implementación

Una vez, tenemos clara nuestra estrategia deberemos estudiar como podemos implementarla, para ello disponemos un conjunto de herramientas que van desde IaC, librerías de sincronización de data sources y migración de workspaces. Sin embargo, ninguna de las librerías de sincronizado/migración es oficial y aún se encuentran en desarrollo.

  • Módulo Databricks de Terraform [1]: para replicar la infraestructura, workspaces, metadatos, etc
  • Databricks Workspace Migration Tools [2]: paquete de librerías para generar un punto de restauración y migración de nuestros workspaces en otras regiones e incluso otros proveedores cloud.
  • Databricks Sync (DBSync) [3]: especializado en la sincronización, creación de copias de seguridad y  restauración de workspaces.

Escalabilidad

En este punto, veremos las diferentes opciones que ofrece Databricks en materia de escalabilidad, debido a que este punto ya ha sido tratado profundamente por nuestros compañeros dentro de la entrada Databricks sobre AWS – Una perspectiva de arquitectura (parte 2), nos limitaremos a comentar las características equivalentes en Azure.

Auto Escalado de workers

De la misma forma que en AWS, Databricks ofrece sobre Azure la posibilidad de escalar horizontalmente de una forma dinámica el número de workers dependiendo el mínimo y máximo que hayamos definido, permitiendo mejorar el tiempo de los trabajos sin sobre asignar recursos y por lo tanto reduciendo el coste global por trabajo en hasta un 30%.

Por lo general, en la forma tradicional cuando se definían las políticas de escalado para nuestros clusters se tenían que establecer una serie de umbrales estáticos donde si estos son rebasados se aprovisionan recursos extra, en forma de nodos de cómputo de bajo coste y efímeros (Spot). En muchos casos el escalado in/out de estos recursos no es lo suficientemente rápido, generando una ralentización global del job y una utilización subóptima de los recursos.

Para ello Databricks propone un  nuevo tipo de escalado optimizado [6], donde a partir de la información de los ejecutores es capaz de adaptar rápidamente los recursos del trabajo a sus necesidades de una forma rápida y eficiente, sin necesidad de esperar a que el trabajo completo termine para comenzar el desescalado.

Auto escalado tradicional: Ejecutores activos vs total de ejecutores (fuente: Databricks)
Auto escalado optimizado de Databricks: Ejecutores activos vs total de ejecutores (fuente: Databricks)

Caracteristicas:

  • Posibilidad de escalado desde el mínimo al máximo en dos pasos.
  • Posibilidad de desescalado aun cuando el cluster no está en idle viendo el shuffle file
  • Desescalado en base al porcentaje de nodos trabajando
  • En cluster del tipo job, el desescalado puede producirse si estos están infrautilizados tras 40 segundos, en all-purpose tras 150 segundos. 
  • Posibilidad de configurar la frecuencia de escalado mediante la propiedad spark.databricks.agressiveWindowDownS


Pools

Para reducir al máximo el tiempo de lanzamiento de una nueva instancia, Databricks permite mantener un set de clusters o pool pre-inicializado en estado idle listo para su empleo en nuestros trabajos o en los procesos de escalado. Si se llega al caso de que todo el pool de instancias se ha consumido, de forma automática se asignarán nuevas instancias al pool.

De la misma forma al escalado de los clusters, podremos definir un número máximo y mínimo de instancias que el pool podrá tener en estado idle para su posterior asignación al trabajo demandante y el tiempo que estas pueden permanecer desasignadas hasta su eliminación.

Respecto al tipo de instancias asignado al pool, no podrán cambiarse, tanto el driver como los workers del trabajo consumirán el mismo tipo de instancias.


Auto escalado del almacenamiento

Databricks ofrece la posibilidad de asignar un auto escalado en el almacenamiento local en disco del cluster con el fin de acotar la necesidad de dimensionado de estos. 

Databricks monitoriza el espacio libre en el disco de forma que en caso necesario se montará un disco externo sobre éste. Es importante señalar que estos discos una vez asignados no podrán desmontarse hasta que el cluster no sea eliminado, por ello se recomienda emplearlos en instancias Spot o que en instancias tengan una política de auto finalizado

Seguridad

Encriptación de datos databricks

Uno de los aspectos más importantes cuando vamos a seleccionar una plataforma para  el tratamiento de datos es la seguridad de los mismos. Debe ofrecer mecanismos de encriptación de datos tanto en los sistemas de almacenamiento, comúnmente conocido como datos en reposo (at rest), como cuando están en movimiento (in-transit).


En transito

Databricks encripta todos los datos que circulan por cada uno de sus diferentes componentes  y orígenes con TLS.  Además de la encriptación de datos, se encriptan con TLS todas las comunicaciones que se realizan entre el plano de control y el plano de datos, por tanto los comandos, consultas y meta-data viajan también encriptados.

Para plataformas que requieran un nivel alto de protección, se puede realizar la encriptación entre los nodos del cluster utilizando la encriptación RPC de Spark [7]. Está se realiza con cifrado AES de 128 bits a través de una conexión TLS 1.2. Está opción solo está disponible con el plan premiun y es necesario establecer los parámetros de configuración de Spark en el script de init del cluster o en el global si necesitamos que se aplique a todos los cluster del workspace. Es importante que tengamos en cuenta que la encriptación entre los nodos del cluster puede suponer una disminución en el rendimiento de los procesos y dado que la red privada de los nodos suele estar aislada, en la mayoría de los casos no será necesario este tipo de encriptación.

 
En reposo

Para el cifrado de los datos en reposo se utiliza SSE [8] (server-side encryption), cifra automáticamente los datos cuando se guardan en el almacenamiento distribuido (blob storage, ADLS y ADLS2).

Por defecto DBFS está encriptado usando claves administradas por Microsoft pero también permite la opción de usar claves administradas por el cliente, comúnmente conocidas como (CMK), permitiendo de este modo utilizar tu propia clave de cifrado para cifrar la cuenta de almacenamiento del DBFS. Además, tanto si se usa clave administradas como tu propia clave, también se ofrece la posibilidad de una capa adicional de cifrado utilizando un algoritmo/modo de cifrado diferente en la capa de infraestructura utilizando claves de cifrado administradas por la plataforma.

Para tener un completo cifrado de los datos en reposo, además del cifrado datos en el almacenamiento distribuido, se puede habilitar la encriptación de los disco locales de los nodos del clúster con lo que se permite la encriptación de los datos temporales que se guardan en las ejecuciones de los procesos. Actualmente está característica se encuentra en en versión preliminar pública y sólo está disponible para la creación del cluster desde el api REST utilizando la configuración siguiente:

{"enable_local_disk_encryption": true} 

También hay que tener en cuenta que activar esta opción puede suponer cierto impacto en el rendimiento de los procesos.

Diagrama de Arquitectura Databricks (fuente: Azure)

Logging

Para el correcto gobierno de una plataforma de ejecución de datos es necesario disponer de las herramientas necesarias para poder realizar el seguimiento y comprobación de ejecución de los workloads. Databricks integra en su plataforma todos elementos necesarios para realizar el mismo en un entorno de Spark. A continuación, vamos a resumir las opciones que integra Databricks out of the box aunque se pueden realizar monitorizaciones más avanzadas utilizando otras herramientas o servicios.

 

Cluster logs

Para cada uno de los cluster o job cluster creados en la plataforma podemos consultar de forma visual:

Captura Workspace - Sección Clusters

Event log: Se muestran todos los eventos relacionados con el ciclo de vida del cluster que han sucedido, como pueden ser, creación, terminación, cambios en la configuración…

Spark UI: Permite el acceso a la GUI ofrecida por Spark. Esta GUI es fundamental para poder detectar y solventar los problemas de performance en las aplicaciones de Spark.

Driver Logs : Permite ver los logs de ejecución tanto de la salida estándar , error y  log4j. Databricks también permite que se realice el volcado de logs en un filesystem determinado, para ellos es necesario configurarlo en las opciones avanzadas del cluster o indicándolo en la creación del cluster si se realiza desde crea desde API o CLI.

Metrics: Databricks proporciona acceso a Ganglia Metrics para obtener un mayor detalle del rendimiento que está ofreciendo el cluster

Captura Workspace - Ganglia Metrics

Registro de diagnóstico en Azure Databricks 

Azure Databricks nos ofrece la posibilidad de descargar los registros de las actividades realizadas por los usuarios a través del registro de diagnóstico [9]. Activando esta opción se enviarán los registros de la actividad de usuario a un destino seleccionado, Azure tiene disponibles 3 opciones para el envío de los registros: Cuenta de Almacenamiento, Event y Log Analytics.

Estos son los servicios que se pueden seleccionar para obtener registros de diagnóstico.

SERVICIOS DISPONIBLES PARA DIAGNÓSTICO
DBFS
sqlanalytics
modelRegistry
clusters
genie
repos
accounts
globalInitScripts
unityCatalog
jobs
iamRole
instancePools
notebook
mlflowExperiment
deltaPipelines
ssh
featureStore
sqlPermissions
workspace
RemoteHistoryService
databrickssql
secrets
mlflowAcledArtifact

La activación se puede realizar desde Azure Portal, API REST, CLI, ó powershell. Los registros están disponibles en un plazo de 15 minutos después de la activación.

Este sería el esquema de un registro de diagnóstico de salida 

Campo Descripción
operationversion
Versión del esquema del formato del registro de diagnóstico.
time
Marca de tiempo UTC de la acción.
properties.sourceIPAddress
Dirección IP de la solicitud de origen.
properties.userAgent
Explorador o cliente de API usado para realizar la solicitud.
properties.sessionId
Identificador de sesión de la acción.
identities

Información sobre el usuario que realiza las solicitudes:
* * : dirección de correo electrónico del usuario.

category
Servicio que registró la solicitud.
operationName
La acción, como el inicio de sesión, el cierre de sesión, la lectura, la escritura, etc.
properties.requestId
Identificador de solicitud único.
properties.requestParams

Pares clave-valor de parámetro usados en el evento.

El requestParams campo está sujeto a truncamiento. Si el tamaño de su representación JSON supera los 100 KB, los valores se truncan … truncated y la cadena se anexa a las entradas truncadas. En raras ocasiones, cuando un mapa truncado sigue siendo mayor que 100 KB, TRUNCATED en su lugar hay una sola clave con un valor vacío.

properties.response
Respuesta a la solicitud: * * : mensaje de error si se ha producido un error. * * : resultado de la solicitud. * * : código de estado HTTP que indica si la solicitud se realiza correctamente o no.
properties.logId
Identificador único de los mensa jes de registro.

Tabla Esquema Registro Salida (fuente: Azure)

Para la explotación de los registros, si se ha seleccionado la opción de Logs Analytics, podremos explotarlos de forma sencilla utilizando Azure Monitor. Pero si lo que se desea es explotar estos registros con cualquier otra plataforma, servicio o herramienta es posible tomando estos registros JSON del lugar del envio seleccionando en la activación.

Referencias

[1] Databricks Terraform Provider. [link]

[2] Databricks Workspace Migration Tools. [link]

[3] Databricks Sync. [link]

[4] Databricks Disaster Recovery [link]

[5] Cifrado entre nodos de trabajo[link]

[6] Optimized AutoScaling [link]

[7] Spark Security [link]

[8] Azure encriptación discos [link]

[9] Registro de diagnostico [link]

Navegación

Glosario

Disaster Recovery

Escalabilidad

Seguridad

Logging

Referencias

Autores

Do you want to know more about what we offer and to see other success stories?
DISCOVER BLUETAB

Francisco Linaje

AWS Solutions Architect

Gabriel Gallardo Ruiz

Senior Data Architect

SOLUTIONS, WE ARE EXPERTS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

You may be interested in

FinOps

mayo 20, 2024
READ MORE

Algunas de las capacidades de Matillion ETL en Google Cloud

julio 11, 2022
READ MORE

Data Mesh

julio 27, 2022
READ MORE

Espiando a tu kubernetes con kubewatch

septiembre 14, 2020
READ MORE

Bluetab en la ElixirConfEU 2023

mayo 3, 2023
READ MORE

Bluetab se incorporará a IBM

julio 9, 2021
READ MORE

Publicado en: Blog, Blog, Destacado, Practices, Tech

Databricks sobre Azure – Una perspectiva de Arquitectura (parte 1)

febrero 15, 2022 by Bluetab

Databricks sobre Azure - Una perspectiva de arquitectura (parte 1)

Francisco Linaje

AWS Solutions Architect

Gabriel Gallardo Ruiz

Senior Data Architect

Databricks tiene como objetivo dotar de un entorno intuitivo al usuario no especializado para que pueda desarrollar las diferentes funciones en materia de ingeniería y ciencia de datos, dotando además de una capa de gobierno y gestión del dato.

Nuestro objetivo con este artículo, no es tanto describir y analizar cómo emplear estas herramientas, sino ver como son integradas desde un punto de vista de arquitectura dentro del proveedor de Azure.

Databricks como solución Lakehouse

La plataforma Databricks sigue el paradigma de Lakehouse, en el que se combinan las bondades del Data Warehouse con las del Data Lake, permitiendo tener un buen rendimiento tanto en sus consultas analiticas gracias a la indexacion, como transaccionalidad a través de Delta Lake,  sin perder la flexibilidad de una arquitectura de datos abierta y escalable, junto a una mejor gobernanza del dato y del acceso a los recursos y servicios del lago, permitiendo de una forma general disponer de una arquitectura menos compleja y más integrada.

Este artículo se dividirá en dos entregas.

  • La primera, tendrá como objetivo explicar cómo Databricks organiza y despliega su producto en Azure, así como las diferentes configuraciones en materia de comunicación/seguridad entre Databricks y otros servicios de Azure.
  • La segunda, estará centrada en la capa de seguridad del dato y escalabilidad de la infraestructura así como monitorización, despliegue y recuperación ante errores.


Primera entrega:

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

Segunda entrega (próximamente):

  • DR
  • Cifrado
  • Escalabilidad
  • Logging y monitorización
  • Despliegue

Glosario

  • Azure Data Lake: Permite almacenar múltiples formatos de datos en un mismo lugar para su explotación y análisis, actualmente Azure dispone la versión Gen2 .
  • 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.
  • Azure Key Vault: Servicio administrado de Azure que permite el almacenamiento seguro de secretos.
  • Azure Virtual Network (VNET): Red virtual aislada lógicamente en Azure.
  • Continuous integration and continuous delivery CI/CD: Conjunto de herramientas y pautas automatizadas que permiten aplicar una integración y puesta en producción continua
  • Data Lake: Paradigma de almacenamiento distribuido de datos provenientes de multitud de fuentes y formatos, estructurados, semi estructurados y sin estructurar.
  • Identity Provider (IdP): Entidad que mantiene la información de identidad de los individuos dentro de una organización.
  • 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.
  • Network Security Group o NSG: Especifican las reglas que regulan el tráfico de entrada y salida de la red y los clusters en Azure.
  • Notebook: Interfaz web para ejecutar código en un cluster, abstrayendo del acceso al mismo.
  • PrivateLink: Permite el acceso privado (IP privada) a Azure PaaS a través de la VNET del usuario, de la misma forma que los service endpoints el tráfico se enruta a través del backbone de Azure.
  • Azure role-based access control (RBAC): Sistema de autorización integrado en Azure Resource Manager que permite asignar permisos granulares sobre recursos a usuarios de Azure.
  • 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.
  • 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.
  • Service Endpoints: Componente de red que permite conectar una VNET con los diferentes servicios dentro de Azure a través de la propia red de Azure.
  • Service Principal: Entidad creada para que la administración y gestión de tareas que no queden asociadas a un miembro de la organización en particular si no a un servicio
  • Secret Scope: Colección de secretos identificados por un nombre.
  • Single Sign On (SSO): Permite a los usuarios la autenticación a través de un Identity Provider (IdP) proporcionado por la organización, requiriendo de compatibilidad con SAML 2.0.
  • 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

Databricks como producto

Databricks permanece integrado dentro de Azure como servicio propio a diferencia de otros proveedores, permitiendo el despliegue de una forma más directa y sencilla ya sea desde la propia consola o mediante templates.

Dentro de los servicios ofrecidos por Databricks destacan: 

  • Databricks SQL: ofrece una plataforma para realizar consultas SQL ad-hoc contra el Data Lake, así como múltiples visualizaciones de los datos con dashboards.
  • Databricks Data Science & Engineering: proporciona un workspace que permite la colaboración entre diferentes roles (ingenieros de datos, científicos de datos, etc) para el desarrollo de diferentes pipelines para la ingesta y explotación del Data Lake.
  • Databricks Machine Learning: ofrece un entorno para el desarrollo y explotación de modelos de machine learning end-to-end.

Además Databricks ofrece Spark como framework de programación distribuida, así como integración con Delta Lake y soporte a transacciones ACID para datos estructurados y no estructurados, unificación de fuentes batch y streaming.

Databricks ofrece también una solución en material de orquestación y despliegue de jobs de una forma productiva, permitiendo además paralelismo entre ellos, hasta 1000 de forma concurrente. Pudiendo emplearse solo dentro del workspace de Data Science & Engineering

Diagrama de procesos orquestados (fuente: Databricks)

Dentro de las ventajas añadidas ofrecidas por Databricks se encuentra el empleo de Databricks File System (DBFS), se trata de un sistema de ficheros distribuido de acceso para los clusters.

  • Permite montar puntos de almacenamiento para acceder a los objetos sin necesidad de credenciales específicos para su uso.
  • Evita la necesidad de emplear urls para acceder a los objetos, facilitando el acceso vía directorios y semántica.
  • Otorga una capa de persistencia al almacenar en el file system los datos, evitando que estos se pierdan cuando el cluster es finalizado.

Databricks Repos: ofrece integración y sincronización con repositorios GIT, incluyendo una API para el empleo de pipelines de CI/CD. Los proveedores Git actuales incluidos son:

  • GitHub
  • Bitbucket
  • GitLab
  • Azure DevOps

 

Overview de la arquitectura

En esta sección analizaremos cómo se realiza el despliegue de Databricks dentro de la cuenta del cliente en su proveedor cloud, este caso Azure.

Databricks se compone principalmente de dos capas; una de control (interna) y otra de datos (externa/cliente).

Diagrama a alto nivel de la arquitectura (fuente: Databricks)

En la imagen anterior podemos ver como la capa de control permanece en la suscripción de databricks, bajo su control, diseño y administración interna siendo compartida esta por todos los usuarios.

 Los principales servicios contenidos, son:

  • Notebooks: Todos los notebook, resultados y configuraciones permanecen encriptados
  • Job Scheduler
  • Rest API
  • Metastore: Hive metastore gestionado por databricks
  • Cluster manager: Solicita máquinas virtuales para los clúster que se  lanzarán en el plano de datos

La capa de datos se encuentra dentro de la suscripción del cliente y por lo tanto será administrada por él. En esta capa encontramos los jobs y clusters empleados para la ejecución de las ETLs, así como los datos empleados en ellas.

Es importante señalar que Databricks disponibiliza dos interfaces de red en cada nodo desplegado, en una de ellas se direccionara el tráfico hacia el plano de control y en la otra el tráfico interno entre nodos (driver – ejecutores)

Databricks ofrece dos métodos principales para realizar el despliegue del plano de datos y que posteriormente comentaremos en profundidad:

  • Por un lado tenemos Databricks managed VNET, siendo este el despliegue dado por defecto donde Databricks se encarga de desplegar los recursos necesarios dentro de la cuenta del cliente. 
  • Por otro lado tenemos un segundo tipo de despliegue Databricks VNET injection donde es el cliente el que disponibiliza los recursos mínimos necesarios para el correcto funcionamiento y comunicación contra el control-plane.

En ambos casos, la topología de red en el Data Plane se compondrá de dos subredes.

  1. Container subnet o “private” subnet
  2. Host subnet or “public” subnet
Arquitectura de Databricks en Azure (fuente: Databricks)

Secure Cluster Connectivity [2]

En contextos de seguridad más restrictivos, será posible asignar como puerta de enlace un NAT  gateway u otro dispositivo egress traffic como un balanceador de carga, firewall, etc, para eliminar la necesidad de asignar direcciones IP públicas a los hosts.

Conexión del workspace con SCC (fuente: Databricks)

Planes y tipos de carga de trabajo

Además del coste de la infraestructura empleada para el procesamiento y el almacenamiento en Azure, Databricks añade un sobrecargo extra expresado en DBU (unidades de procesamiento) en función del tipo de instancia levantada y su tamaño, así como el tipo de workload empleado. 

Se distinguen 2 tipos principales: 

  • Jobs Cluster: Ejecución de pipelines programadas no iterativas, distinguiéndose según el tamaño del cluster aprovisionado en ligero o normal. Los jobs suelen emplearse creando clusters efímeros y siendo eliminados después de la ejecución de los mismos.
  • All purpose: Clusters empleados para trabajar de forma iterativa (MANDATORY) permitiendo ejecutar  y desarrollar diferentes notebooks concurrentemente.

Además, según el tipo de cuenta contratada Standard o Premium se realizarán cargos adicionales sobre el coste de la DBU.

AZURE PLAN
Standard
Premium
One platform for your data analytics and ML workloads
Data analytics and ML at scale across your business
Job Light Compute
$0,07/DBU
$0,22/DBU
Job Compute
$0,15/DBU
$0,30/DBU
SQL Compute
N/A
$0,22/DBU
All-Purpose Compute
$0,40/DBU
$0,55/DBU

Coste imputado por DBU respecto a los factores computacionales y arquitectónicos

WORKLOAD TYPE (STANDARD TIER)
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 plan Standard

WORKLOAD TYPE (STANDARD TIER)
FEATURE
Jobs Light Comput
Jobs compute
All-purpose compute
Role Based Access Control for clusters, jobs,
notebooks and tables
JDBC/ODBC Endpoints Authentication
Audit Logs
All Standard Plan Features
Azure AD credential passthrough
Conditional Authentication
Cluster Policies
IP Access List
Token Management API

Características por tipo de carga de trabajo plan Premium

Es importante señalar que además podrán obtenerse descuentos de hasta el 37% en los precios por DBU, realizando compras aprovisionadas de estas (DBCU o Databricks Commit Units) para 1 o 3 años.

Networking

En este apartado explicaremos los dos diferentes tipos de despliegue ya comentados anteriormente y sus peculiaridades en materia de conexión y acceso al plano de control, así como al control del tráfico entrante/saliente.

 

Red administrada por Databricks

En esta alternativa, Azure permite a Databricks desplegar el plano de datos sobre nuestra suscripción, disponibilizando los recursos que permitirán la conexión contra el plano de control y el despliegue de jobs, clusters y otros recursos.

  • La comunicación entre el plano de datos y plano de control independientemente de tener activado Secure Cluster Connectivity (SCC) se realizará por el backbone interno de Azure, sin enrutar tráfico sobre la red pública.
  • Secure Cluster Connectivity (SCC) podrá ser activado para  poder trabajar sin IPs públicas.
  • El tráfico inbound/outbound de los clusters estará controlado mediante diferentes reglas por el network security group NSG que no podrán ser modificables por el usuario.


Red administrada por el cliente (VNET injection) [1]

Databricks ofrece la posibilidad de poder desplegar el plano de datos sobre una VNET propia administrada por el cliente. Esta solución ofrece mayor versatilidad y control sobre los diferentes componentes de nuestra arquitectura.

  • La comunicación entre el Data Plane y Control Plane se realizará sobre el backbone interno de Azure de la misma forma que en la red administrada por Databricks vista anteriormente, además de la misma forma podremos activar SCC.
  • En este caso al ser nuestra propia VNET tendremos control sobre las reglas definidas en nuestros NSG.
NSG provisionado por Databricks por delegación en la VNET del cliente (fuente: Databricks).
  • Se deberá ser propietario de la VNET para poder permitir que se delegue a Databricks su configuración o el despliegue de recursos [3].
  • Podremos habilitar cualquier componente de arquitectura que consideremos dentro de nuestra VNET ya que estará administrada por nosotros:
    • Conectar Azure Databricks a otros servicios de Azure de una forma más segura empleando service endpoints o private endpoints.
    • Conectarse a tus recursos on-premise empleando user-defined routes.
    • Permite desplegar un network virtual appliance para inspeccionar el tráfico
    • Custom DNS
    • Custom egress NSG rules
    • Aumentar el rango CIDR de la máscara de red para la VNET entre /16 – /24 y /26 para las subredes.
Diagrama de conexión mediante PrivateLink con servicios nativos de Azure (fuente: Databricks)

Dentro de las peculiaridades de ambos despliegues, es importante señalar:

  • No es posible reemplazar una VNet existente en un workspace por otra, si fuera necesario se deberá crear un nuevo workspace con una nueva VNET.
  • Tampoco es posible añadir SCC a un workspace una vez ya ha sido creado, si fuera necesario también deberá volver a crear el workspace.

Conexiones contra el plano de control

Conexión plano de control y de datos en Databricks (fuente: Databricks)

Tal y como ya hemos comentado anteriormente, toda comunicación con el plano de control se realiza por dentro del backbone de Azure por defecto [2]. También se debe destacar:

  • A nivel de red, toda conexión que se realiza contra el plano de control al crear un cluster en el plano de datos se realiza vía HTTPS (443) y sobre una dirección IP diferente a la empleada para otros servicios de aplicación Web o APIs.
  • Cuando el plano de control  lanza nuevos jobs o realiza otras tareas de administración del clúster, estas solicitudes se envían al clúster a través de este túnel inverso.
  • Para realizar las conexiones entre el plano de control y de datos, se habilitará una dirección IP pública sobre la subred pública aunque el tráfico posteriormente sea enrutado dentro del backbone, además no se dejarán puertos abiertos o se asignarán direcciones IP públicas sobre los clusters.
  • Si en nuestro caso de uso se deben de emplear unas condiciones más restrictivas de seguridad, Databricks ofrece la posibilidad de activar la opción de secure cluster connectivity permitiendo eliminar toda dirección IP pública para realizar la conexión entre el plano de control y de datos,  para ello se servirá:
    • Por defecto en la red administrada por Databricks (managed VNET)  se habilita un NAT para poder realizar esta comunicación.
    • Si el cliente despliega la infraestructura sobre su propia red (VNET Injection deployment) este deberá aportar un dispositivo de red para el tráfico saliente, que podra ser un NAT Gateway, Load Balancer, Azure Firewall o un dispositivo de terceros.

Identidad y Gestión de accesos

Databricks ofrece diferentes herramientas para administrar el acceso a nuestros recursos y servicios de Azure de una forma sencilla e integrada en la propia plataforma.

Podremos encontrar herramientas como filtrados de IP, SSO, permisos de uso sobre los servicios de Databricks, acceso a secretos, etc.

IP access lists

Databricks permite a los administradores definir listas de acceso IP para restringir el acceso a la interfaz de usuario y la API a un determinado conjunto de direcciones IP y subredes, permitiendo el acceso solo desde las redes de la organización. Los administradores sólo podrán realizar la gestión de IP access list con el API REST.

Single sign on (SSO) 

Mediante Azure Active Directory podremos configurar SSO para todos nuestros usuarios de Databricks evitando la duplicación en la gestión de identidades.

System for Cross-domain Identity Management (SCIM)

Permite a través de un IdP (actualmente Azure Active Directory) crear usuarios en Azure Databricks y otorgarles un nivel de permisos y permanecer sincronizados, se debe disponer de un plan PREMIUM. Si los permisos son revocados los recursos ligados a este usuario no son eliminados.

Acceso a recursos

El acceso principal a los diferentes servicios de Databricks vendrá dado por los entitlements donde se indicará si el grupo/usuario tendrá acceso a cada uno de ellos (cluster creation, Databricks SQL, Workspaces)

Por otro lado, dentro de Databricks se pueden emplear ACLs para configurar el acceso a los diferentes recursos como clusters,tablas, pools, jobs y objetos del workspace (notebooks, directorios, modelos, etc). Otorgar esta granularidad sobre el acceso a los recursos solo está disponible mediante el plan PREMIUM, por defecto todos los usuarios tendrán acceso a los recursos.

Estos permisos se encuentran gestionados desde el usuario administrador u otros usuarios con permisos delegados.

Existen 5 niveles de permisos con sus múltiples implicaciones dependiendo del recurso al que se apliquen; No permissions, can read, can run, can edit, can manage.

A continuación, se indican los permisos asociados al recurso que se desea emplear. En caso de que dos políticas puedan solaparse, la opción más restrictiva primará sobre la otra.

Permisos según el nivel asociado al usuario sobre los directorios del workspace (Fuente: Databricks)
Permisos según el nivel asociado al usuario sobre el notebook (Fuente: Databricks)
Permisos según el nivel asociado al usuario sobre el repositorio (Fuente: Databricks)

Azure Datalake Storage ADLS

A través de Azure Active Directory (Azure AD) puedes realizar la autenticación directamente desde Databricks con Azure Datalake Storage Gen1 y 2, permitiendo al cluster de Databricks acceder a estos recursos directamente sin necesidad de tener un service principal. Requiere del plan  PREMIUM y activar credentials passthrough en opciones avanzadas en el momento de creación del cluster en Databricks. Disponible en clusters estándar y de alta simultaneidad.

Activación de credentials passthrough en la opciones de configuración del cluster (Fuente: Databricks)

Credential passthrought es un método de autenticación que emplea la identidad (Azure AD) utilizada para la autenticación en Databricks para conectarte al Datalake. El acceso a los datos será controlado a través de los roles de RBAC (permisos a nivel de usuario) y ACLs (permisos a nivel de directorio y archivo) configuradas.

Las listas de control de acceso (ACL) controlan el acceso al recurso comprobando si la entidad que desea acceder tiene los permisos adecuados.


Secretos
[5]

Accesos

Por defecto, todos los usuarios sin importar el plan contratado pueden crear secretos y acceder a ellos (MANAGE permission). Solo a través del plan PREMIUM es posible configurar permisos granulares para controlar el acceso. La gestión de estos se podrá realizar a través de Secrets API 2.0 o Databricks CLI (0.7.1 en adelante).

La gestión de los secretos se realiza a nivel de scope (colección de secretos identificados por un nombre), en concreto una ACL controla la relación entre el principal (usuario o grupo), el scope y el nivel de permiso. Por ejemplo: cuando un usuario accede al secreto desde un notebook vía Secrets utility el nivel de permiso se aplica en base a quien ejecuta el comando.

Por defecto, cuando un scope es creado se le aplica un nivel de permiso MANAGE, sin embargo el usuario que crea el scope podrá añadir permisos granulares.

Distinguimos 3 niveles de permiso en Databricks-backed scopes:

  • Manage: Puede modificar las ACLs y además tiene permisos de lectura y escritura sobre el scope.
  • WRITE: tiene permisos de lectura y escritura sobre el scope.
  • READ: solo tiene permisos de lectura sobre el scope y los secretos a los que tiene acceso.

Los usuarios administradores de un workspace tienen acceso a todos los secretos de todos los scopes

Almacenamiento

Los secretos podrán ser referenciados desde los scopes que a su vez harán referencia a sus respectivos vaults donde los secretos son almacenados.
Existen dos tipos de soporte de almacenamiento para los secretos:

  • Databricks-backed
  • Azure Key Vault

Podremos emplear Databricks-backed como soporte de almacenamiento de los secretos sin la necesidad de un plan PREMIUM, sin embargo ya sea tanto para emplear Azure Key Vault o por otro lado el empleo de permisos granulares en ambos soportes, sí será necesario contratar el plan PREMIUM.

Es importante destacar que si el Key Vault existe en un tenant diferente al que alberga el workspace de Databricks, el usuario que crea el scope debe de tener permisos para crear service principals sobre el key vault del tenant, de lo contrario se arrojará el siguiente error.

Unable to grant read/list permission to Databricks service principal to KeyVault 

Debido a que Azure Key Vault es ajeno a Databricks solo será posible realizar operaciones de lectura por defecto y no pueden ser administradas desde Secrets API 2.0, deberá emplearse por contra Azure SetSecrets REST API o desde el portal de Azure UI.

Es importante señalar, que todos los usuarios tendrán acceso a los secretos de un mismo Key Vault aunque se encuentren en diferentes scopes. Se considera buena práctica replicar los secretos en diferentes Key Vaults según subgrupos se tengan aunque puedan ser redundantes.

Ahora mediante RBAC [4] (role-based access control) ya es posible mediante diferentes roles controlar el acceso a los secretos del Vault desde Azure.

Por último, simplemente indicar que los scopes podrán consumirse desde la librería dbutils, si el valor es cargado correctamente aparece referenciado como REDACTED.

dbutils.secrets.get(scope = "nombre_scope_databricks", key = "nombre_secreto") 

Conexiones on-premise

Por último, indicar que es posible establecer una conexión on-premise para nuestro plano de datos en Azure, para ello es indispensable que este se encuentre alojado en nuestra propia red mediante VNET injection.

Arquitectura de Databricks en Azure (fuente: Databricks)

Azure define como principal método el uso de Transit Virtual Network para establecer esta conexión on-premise, siguiendo los siguientes pasos:

  1. Crear un Network Gateway (VPN o ExpressRoute) entre la red de tránsito y on-premise, para ello deberemos crear tanto el Customer Gateway en el lado on-premise como el Virtual Gateway en el lado de Azure.
  2. Deberemos establecer el peering entre el plano de datos y la red de tránsito. Una vez establecido, Azure Transit configura todas las rutas, sin embargo no se incluyen las de retorno hasta el plano de control para los clusters de Databricks, para ello se deberán configurar las user-defined routes y asociarlas a las subredes del plano de datos.

Otras soluciones alternativas también podrían emplearse mediante el uso de Custom DNS o el empleo de un virtual appliance o firewalls.

Referencias

[1] Customer Managed VNET Databricks Guide. [link] (Enero 26, 2022)

[2] Secure Cluster Connectivity. [link]  (Enero 26, 2022)

[3] Subnet Delegation. [link] (Enero 3, 2022)

[4] Role-based access control [link] (Octubre 27, 2021)

[5] Databricks secrets scopes [link] (Enero 26, 2022)

Navegación

Glosario

Arquitectura

Planes y tipos de carga de trabajo

Networking

Identidad y Gestión de accesos

Referencias

Autores

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

Francisco Linaje

AWS Solutions Architect

Gabriel Gallardo Ruiz

Senior Data Architect

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Introducción a los productos de HashiCorp

agosto 25, 2020
LEER MÁS

5 errores comunes en Redshift

diciembre 15, 2020
LEER MÁS

Databricks on Azure – An architecture perspective (part 2)

marzo 24, 2022
LEER MÁS

Detección de Fraude Bancario con aprendizaje automático

septiembre 17, 2020
LEER MÁS

Databricks sobre Azure – Una perspectiva de Arquitectura (parte 2)

marzo 24, 2022
LEER MÁS

Domina los Costos en la Nube: Optimización de GCS y BigQuery en Google Cloud

marzo 17, 2025
LEER MÁS

Publicado en: Blog, Blog, Outstanding, Practices, Tech

Databricks on Azure – An Architecture Perspective (part 1)

febrero 15, 2022 by Bluetab

Databricks on Azure - An architecture perspective (part 1)

Francisco Linaje

AWS Solutions Architect

Gabriel Gallardo Ruiz

Senior Data Architect

Databricks aims to provide an intuitive environment for the non-specialist users to develop the different functions in data engineering and data science, also providing a data governance and management layer.
Our goal with this article is not focus so much to describe and analyze how to use these tools, but to see how they are integrated from an architectural point of view within the Azure provider.

Databricks as a Lakehouse solution

The Databricks platform follows the Lakehouse paradigm, in which the benefits of the Data Warehouse are combined with those of the Data Lake, allowing to have a good performance both in its analytical queries thanks to indexing, and transactionality through Delta Lake, without losing the flexibility of an open and scalable data architecture, along with better data governance and access to the resources and services of the lake, allowing in a general way to have a less complex and more integrated architecture.

This article will be divided into two deliverys.

  • The first one, will explain how Databricks organizes and deploys its product on Azure, as well as the different configurations in terms of communication/security between Databricks and other Azure services.
  • The second, will be focused on the data security layer and scalability of the infrastructure as well as monitoring, deployment and failover.

First delivery:

  • Architecture Overview
  • Workload types and plans
  • Networking
  • Identity and Access Management

Second delivery (coming soon):

  • Disaster Recovery
  • Encryption
  • Scalability
  • Logging and monitoring
  • Deployment

Glossary

  • Azure Data Lake: Allows to store multiple data formats in the same place for its exploitation and analysis, currently Azure has the Gen2 version.
  • All Purpose Compute: Designed for collaborative environments in which the cluster is used simultaneously by Data Engineers and Data Scientist.
  • Azure Key Vault: Azure managed service that enables secure storage of secrets.
  • Azure Virtual Network (VNET): Logically isolated virtual network in Azure.
  • Azure role-based access control (RBAC): Authorization system integrated into Azure Resource Manager that allows you to assign granular permissions on resources to Azure users.
  • Continuous integration and continuous delivery CI/CD: A set of automated tools and guidelines for continuous integration and production start-up.
  • Data Lake: Paradigm of distributed storage of data from a multitude of sources and formats, structured, semi-structured and unstructured.
  • Identity Provider (IdP): Entity that maintains the identity information of individuals within an organization.
  • Jobs Compute: Focused on processes orchestrated through pipelines managed by data engineers that may involve auto-scaling in certain tasks.
  • Jobs Light Compute: Designed for processes whose achievement is not critical and does not involve a very high computational load.
  • Network Security Group or NSG: Specifies the rules that regulate inbound and outbound network traffic and clusters in Azure.
  • Notebook: Web interface to execute code in a cluster, abstracting from the access to it.
  • PrivateLink: Allows private access (private IP) to Azure PaaS through your VNET, in the same way that service endpoints traffic is routed through the Azure backbone.
  • Security Assertion Markup Language (SAML): Open standard used for authentication. Based on XML, web applications use SAML to transfer authentication data between two entities, the Identity Provider and the service in question.
  • Secure Cluster Connectivity (SCC): SSH reverse tunnel communication between Control Plane and cluster. It allows not having open ports or public IPs in the instances.
  • Service endpoints: Network component that allows connecting a VNET with the different services within Azure through Azure’s own network.
  • Service Principal: Entity created for the administration and management of tasks that are not associated to a particular member of the organization but to a service.
  • Secret scope: Collection of secrets identified by a name.
  • Single Sign On (SSO): Allows users to authenticate through an Identity Provider (IdP) provided by the organization, requiring SAML 2.0 compatibility.
  • Workspace: Shared environment to access all Databricks assets. It organizes the different objects (notebooks, libraries, etc…) in folders and manages access to computational resources such as clusters and jobs.

Architecture

Databricks as a product

Databricks remains integrated within Azure as its own service unlike other providers, allowing the deployment in a more direct and simple way either from the console itself or through templates.

Among the services offered by Databricks, the following stand out:

  • Databricks SQL: offers a platform to perform ad-hoc SQL queries against the Data Lake, as well as multiple visualizations of the data with dashboards.
  • Databricks Data Science & Engineering: provides a workspace that allows collaboration between different roles (data engineers, data scientists, etc.) for the development of different pipelines for the ingestion and exploitation of the Data Lake.
  • Databricks Machine Learning: provides an environment for the development and exploitation of end-to-end machine learning models.

Databricks also offers Spark as a distributed programming framework, as well as integration with Delta Lake and its support for ACID transactions for structured and unstructured data, unification of batch sources and streaming.

Databricks also offers a solution in terms of orchestration and deployment of jobs in a productive way, allowing parallelism between them, up to 1000 concurrently. It can be used only within the Data Science & Engineering workspace.

Orchestrated process diagram (source: Databricks)

Among the added benefits offered by Databricks is the use of Databricks File System (DBFS), a distributed file system for cluster access.

  • It allows mounting storage points to access objects without the need for credentials.
  • It avoids the need to use urls to access objects, facilitating access via directories and semantics.
  • It provides a layer of persistence by storing data in the file system, preventing it from being lost when the cluster is terminated.

Databricks Repos: offers integration and synchronization with GIT repositories, including an API for the use of CI/CD pipelines. Current Git providers included are:

  • GitHub
  • Bitbucket
  • GitLab
  • Azure DevOps

 

Architecture Overview

In this section we will discuss how Databricks is deployed within the customer’s account in their cloud provider, in this case Azure.

Databricks is primarily composed of two layers; a Control Plane (internal) and a Data Plane (external/client).

High level diagram of the architecture (source: Databricks)

In the previous image we can see how the Control Plane remains in the databricks subscription, under its control, design and internal administration being shared by all users.
The main services contained are:

  • Notebooks: All notebooks, results and configurations remain encrypted.
  • Job Scheduler
  • Rest API
  • Metastore: Hive metastore managed by databricks
  • Cluster manager: Requests virtual machines for clusters to be launched on the Data Plane.

The Data Plane is inside the customer’s subscription and will therefore be managed by him. In this layer we find the jobs and clusters used for the execution of the ETLs, as well as the data used in them.

It is important to note that Databricks provides two network interfaces in each deployed node, one of them will route the traffic to the Control Plane and the other one will route the internal traffic between nodes (driver – executors).

Databricks offers two main methods to deploy the Data Plane, which we will discuss in depth later:

  • On the one hand we have Databricks managed VNET, this being the deployment given by default where Databricks takes care of deploying the necessary resources within the client account.
  • On the other hand we have a second type of deployment Databricks VNET injection where the client is the one that provides the minimum resources necessary for the correct operation and communication against the control-plane.

In both cases, the network topology in the Data Plane will be composed of two subnets.

  • Container subnet or «private» subnet.
  • Host subnet or «public» subnet.
Databricks architecture in Azure (source: Databricks)

Secure Cluster Connectivity [2]

In more restrictive security contexts, it will be possible to assign a NAT gateway or other egress traffic devices such as a load balancer, firewall, etc, as a gateway to eliminate the need to assign public IP addresses to hosts.

Workspace connection with SCC (source: Databricks)

Workload plans and types

In addition to the cost of the infrastructure used for processing and storage in Azure, Databricks performs a load expressed in DBU (processing units) depending on the type of instance lifted and its size, as well as the type of workload used. We distinguish 2 main types:

  • Jobs Cluster: for execution of scheduled non-iterative pipelines, distinguished according to the size of the provisioned cluster into light or normal.Jobs are usually used by creating ephemeral clusters and being deleted after the execution of the jobs.
  • All purpose: Clusters used to work iteratively (MANDATORY for this use) allowing to run and develop different notebooks concurrently.

In addition, depending on the type of Standard or Premium account contracted, additional charges will be made on the cost of the DBU.

AZURE PLAN
Standard
Premium
One platform for your data analytics and ML workloads
Data analytics and ML at scale across your business
Job Light Compute
$0,07/DBU
$0,22/DBU
Job Compute
$0,15/DBU
$0,30/DBU
SQL Compute
N/A
$0,22/DBU
All-Purpose Compute
$0,40/DBU
$0,55/DBU

Imputed cost per DBU for computational and architectural factors

WORKLOAD TYPE (STANDARD TIER)
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

Characteristics by type of workload Standard plan

WORKLOAD TYPE (STANDARD TIER)
FEATURE
Jobs Light Comput
Jobs compute
All-purpose compute
Role Based Access Control for clusters, jobs,
notebooks and tables
JDBC/ODBC Endpoints Authentication
Audit Logs
All Standard Plan Features
Azure AD credential passthrough
Conditional Authentication
Cluster Policies
IP Access List
Token Management API

Features by workload type Premium plan

It is important to note that it is also possible to obtain discounts of up to 37% in the prices per DBU, by making purchases of these (DBCU or Databricks Commit Units) for 1 or 3 years.

Networking

In this section we will explain the two different types of deployment discussed above and their peculiarities in terms of connection and access to the Control Plane, as well as incoming/outgoing traffic control.

Network managed by Databricks

In this alternative, Azure allows Databricks to deploy the Data Plane over our subscription, making available the resources that will allow the connection against the Control Plane and the deployment of jobs, clusters and other resources.

  • The communication between the Data Plane and the Control Plane, regardless of having Secure Cluster Connectivity (SCC) enabled, will be done through Azure’s internal backbone, without routing traffic over the public network.
  • Secure Cluster Connectivity (SCC) can be enabled to work without public IPs.
  • The inbound/outbound traffic of the clusters will be controlled by different rules by the network security group NSG that cannot be modified by the user.


Customer managed network (VNET injection) [1]

Databricks offers the possibility of being able to deploy the Data Plane over our own VNET managed by us. This solution offers greater versatility and control over the different components of our architecture.

  • The communication between the Data plane and Control Plane will be done over the internal Azure backbone in the same way as in the network managed by Databricks seen above, also in the same way we can activate SCC.
  • In this case when owning our own VNET, we will have control over the rules defined in our NSGs.
NSG provisioned by Databricks by delegation on the customer's VNET (source: Databricks).
  • You must be the owner of the VNET to allow Databricks to be delegated its configuration or resource deployment [3].
  • We will be able to enable any architecture component we consider within our VNET as it will be managed by us:
    • Connect Azure Databricks to other Azure services in a more secure way employing service endpoints or private endpoints.
    • Connect to your on-premise resources using user-defined routes.
    • Allows you to deploy a virtual network appliance to inspect traffic.
    • Custom DNS
    • Custom egress NSG rules
    • Increase the CIDR range of the network mask for the VNET between /16 – /24 and /26 for the subnets.
Diagram of connection via PrivateLink with native Azure services (source: Databricks)

Among the peculiarities of both deployments, it is important to point out:

  • It is not possible to replace an existing VNet in a workspace with another one, if it was necessary a new workspace, a new VNET must be created.
  • It is also not possible to add SCC to the workspace once it has already been created, if it was necessary, the workspace must also be recreated.

 

Connections against the Control Plane

Databricks Control and Data Plane connection (source: Databricks)

As we have previously discussed, all communication with the Control Plane is done inside the Azure backbone by default [2]. It should also be noted:

  • At the network level, any connection made against the Control Plane when creating a cluster in the Data Plane is made via HTTPS (443) and over a different IP address than the one used for other Web application services or APIs.
  • When the Control Plane launches new jobs or performs other cluster administration tasks, these requests are sent to the cluster through this reverse tunnel.
  • To make connections between the Control and Data Plane, a public IP address will be enabled on the public subnet even if the traffic is subsequently routed within the backbone, and no ports will be left open or public IP addresses will be assigned on the clusters.
  • If in our use case more restrictive security conditions must be used, Databricks offers the possibility to activate the secure cluster connectivity option or , allowing to remove all public IP addresses to make the connection between the control and Data Plane, for this purpose will be used:
    • By default in the network managed by Databrics (managed VNET) a NAT is enabled to be able to perform this communication.
    • If the customer deploys the infrastructure on its own network (VNET Injection deployment) it must provide a network device for outgoing traffic, which could be a NAT Gateway, Load Balancer, Azure Firewall or a third party device.

Identity and Access Management

Databricks offers different tools to manage access to our Azure resources and services in a simple and integrated way in the platform itself.

We can find tools such as IP filtering, SSO, usage permissions on Databricks services, access to secrets, etc.

IP access lists

Databricks allows administrators to define IP access lists to restrict access to the user interface and API to a specific set of IP addresses and subnets, allowing access only from the organization’s networks, and administrators can only manage IP access lists with the REST API.

Single sign on (SSO)

Through Azure Active Directory we will be able to configure SSO for all our Databricks users avoiding duplication in identity management.

System for Cross-domain Identity Management (SCIM)

Allows through an IdP (currently Azure Active Directory) to create users in Azure Databricks and grant them a level of permissions and stay synchronized, you must have a PREMIUM plan. If permissions are revoked the resources linked to this user are not deleted.

Access to resources

The main access to the different Databricks services will be given by the entitlements where it will be indicated if the group/user will have access to each one of them (cluster creation, Databricks SQL, Workspaces).

On the other hand, within Databricks ACLs can be used to configure access to different resources such as clusters, tables, pools, jobs and workspace objects (notebooks, directories, models, etc). Granting this granularity on access to resources is only available through the PREMIUM plan, by default all users will have access to resources.

These permissions are managed from the administrator user or other users with delegated permissions.

There are 5 levels of permissions with their multiple implications depending on the resource to which they apply; No permissions, can read, can run, can edit, can manage.

The permissions associated with the resource to be used are indicated below. If two policies may overlap, the more restrictive option will take precedence over the other.

Permissions according to the level associated to the user on the workspace directories (Source: Databricks)
Permissions according to the level associated to the user on the notebook (Source: Databricks)
Permissions according to the level associated to the user on the repository (Source: Databricks)


Azure Datalake Storage

Through Azure Active Directory (Azure AD) you can authenticate directly from Databricks with Azure Datalake Storage Gen1 and 2, allowing the Databricks cluster to access these resources directly without the need of a service principal. Requires PREMIUM plan and enable credential passthrough in advanced options at the time of cluster creation in Databricks. Available in Standard and High Concurrency clusters.

Enabling credentials passthrough in the cluster configuration options (Source: Databricks)

Credential passthrough is an authentication method that uses the identity (Azure AD) used for authentication in Databricks to connect to Datalake. Access to data will be controlled through the RBAC roles (user level permissions) and ACLs (directory and file level permissions) configured.

Access control lists (ACLs) control access to the resource by checking if the entity you want to access has the appropriate permissions.

 

Secrets [5].

Access

By default, all users regardless of the contracted plan can create secrets and access them (MANAGE permission). Only through the PREMIUM plan it is possible to configure granular permissions to control access. The management of these can be done through Secrets API 2.0 or Databricks CLI (0.7.1 onwards).

Secrets are managed at the scope level (collection of secrets identified by a name), specifically an ACL controls the relationship between the principal (user or group), the scope and the permission level. For example: when a user accesses the secret from a notebook via Secrets utility the permission level is applied based on who executes the command.

By default, when a scope is created a MANAGE permission level is applied to it, however the user who creates the scope can add granular permissions.

We distinguish 3 permission levels in Databricks-backed scopes:

  • MANAGE: can modify ACLs and also has read and write permissions on the scope.
  • WRITE: has read and write permissions on the scope.
  • READ: only has read permissions on the scope and the secrets to which it has access.

The administrator users of the workspace have access to all the secrets of all the scopes.

Storage

The secrets can be referenced from the scopes that in turn will reference their respective vaults where the secrets are stored.

There are two types of storage media for secrets:

  • Databricks-backed
  • Azure Key Vault

We can use Databricks-backed as a storage medium for the secrets without the need for a PREMIUM plan, however either to use Azure Key Vault or on the other hand the use of granular permissions in both cases, it will be necessary to hire the PREMIUM plan.

It is important to note that if the Key Vault exists in a different tenant than the one hosting the Databricks workspace, the user creating the scope must have permissions to create service principals on the tenant’s key vault, otherwise the following error will be thrown.

Unable to grant read/list permission to Databricks service principal to KeyVault 

Because Azure Key Vault is external to Databricks, only read operations will be possible by default and cannot be managed from the Secrets API 2.0, Azure SetSecrets REST API or from the Azure UI portal must be used instead.

It is important to note, that all users will have access to the secrets of the same KEY VAULT even if they are in different scopes, it is considered good practice to replicate the secrets in different Key Vaults according to subgroups even if they may be redundant.

Now with RBAC [4] (role-based access control) it is possible to control the access to the secrets of the Vault that have this service activated through different roles, these roles must be assigned to the user.

The scopes can be consumed from the dbutils library, if the value is loaded correctly it appears as REDACTED.

dbutils.secrets.get(scope = "scope_databricks_scope_name", key = "secret_name") 

On-premise connections

Finally, it is necessary to comment that it is also possible to establish an on-premise connection for our Data Plane in Azure, for this it is essential that it is hosted in our own network (VNET injection).

Databricks architecture in Azure (source: Databricks)

Azure defines as the main method to establish this on-premise connection using Transit Virtual Network, following these steps:

  1. Create a Network Gateway (VPN or ExpressRoute) between the transit network and on-premise, for this we must create both the Customer Gateway on the on-premise side and the Virtual Gateway on the Azure side.
  2. Establish the peering between the Data Plane and the transit network. Once the peering is established Azure Transit configures all the routes, however the return routes to the Control Plane for the Databricks clusters are not included, for this the user-defined routes should be configured and associated to the subnets of the Data Plane.

Other alternative solutions could also be employed through the use of Custom DNS or the use of a virtual appliance or firewalls.

Referencias

[1] Customer-managed VNET Databricks guide. [link] (January 26, 2022)

[2] Secure Cluster Connectivity. [link] (January 26, 2022)

[3] Subnetwork Delegation. [link] (January 3, 2022)

[4] Role-based access control [link] (October 27, 2021)

[5] Databricks secret scopes [link] (January 26, 2022)

Navegation

Glossary

Architecture

Workload plans and types

Networking

Identity and Access Management

References

Authors

Do you want to know more about what we offer and to see other success stories?
DISCOVER BLUETAB

Francisco Linaje

AWS Solutions Architect

Gabriel Gallardo Ruiz

Senior Data Architect

SOLUTIONS, WE ARE EXPERTS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

You may be interested in

Los Incentivos y el Desarrollo de Negocio en las Telecomunicaciones

octubre 9, 2020
READ MORE

¿Existe el Azar?

noviembre 10, 2021
READ MORE

Conceptos básicos de AWS Glue

julio 22, 2020
READ MORE

Data-Driven Agriculture; Applied Big Data, Cloud & AI

noviembre 4, 2020
READ MORE

DataOps

octubre 24, 2023
READ MORE

Azure Data Studio y Copilot

octubre 11, 2023
READ MORE

Publicado en: Blog, Outstanding, Practices, Tech

Mi experiencia en el mundo de Big Data – Parte II

febrero 4, 2022 by Bluetab

Mi experiencia en el mundo de Big Data - Parte II

David Emmanuel Reyes Núñez

Senior Data Engineer

En la entrega anterior (adjunto) creamos los scripts para enlistar y descargar archivos desde Google Drive hacia nuestro filesystem local.

En esta entrega continuaremos con el código de la función processDriveFiles.py y crearemos los scripts para hacer la carga de archivos hacia Google Cloud

La funcionalidad de este script es procesar los archivos listados en nuestro archivo parameters.csv, los cuales tengan el parámero Status con valor 1, recordemos que esto le indica a nuestro programa si el archivo se descargará y procesará o no.

A continuación, el código básico de esta función. Para nuestro ejemplo solo incluiremos archivos con extensión csv y separados por pipes “|”.

En pasos anteriores ya descargamos nuestro archivo al servidor local, el paso siguiente será ingestarlo en Big query y subir el archivo a nuestro proyecto de GCP.

El siguiente código se encarga de validar el archivo e ingestarlo hacia nuestro destino definido.

#Validamos que el tamaño del archivo sea mayor a 0 para poder cargarlo al destino definido en el archivo de configuración, en este caso nuestro destino es Google Cloud Storage y BigQuery, al cual le dimos el valor 1 en nuestro archivo.
file_size=os.stat(props['archivo_origen']).st_size

if (int(file_size)>0):
   if(int(props['Destino'])=1):        

#Tenemos las variables siguientes, sus valores son devueltos por la función upload_GCS_BQ:
#exit_codeBQ  - Bandera para indicar si la ingesta fue exitosa o no.
#registros    - Almacena el numero de registros del archivo.
#Timestamp_date – La fecha en que se hace la ingesta.
#strerror  - Si hay error en la ingesta, esta variable almacena el #código del error
                           exit_codeBQ,registros,Timestamp_Date,strerror=upload_GCS_BQ(creds,props,item['id'])
else:
    print('archivo vacio')

#Al final del proceso, eliminamos los archivos descargados a nuestro servidor, para liberar el espacio ocupado

file_name=str(props.get('archivo_origen')).split('.')
    fname = file_name[0]+'.*'
    r = glob.glob(fname) #función usada por python para buscar archivos
    for i in r:
        print('Eliminando..'+str(i))
        os.remove(i)
 

A continuación, el código de la función upload_GCS_BQ el cual realiza la ingesta del archivo al proyecto de Google Cloud definido en el archivo de configuración.

#Librerias de GCP 
from google.cloud import bigquery
from google.cloud import storage
from google.api_core.exceptions import BadRequest
from google.cloud.exceptions import NotFound
from apiclient.errors import HttpError
#Biblioteca de Python para manejo de archivos csv
import csv

def upload_GCS_BQ(creds,props,file_id):
    
    exit_codeBQ=0
    strerror=""
    registros=0
    Timestamp_Date = datetime.datetime.today().strftime('%Y-%m-%d %H:%M:%S.%f %Z') # obtenemos la fecha de sistema en formato Timestamp
   
        #Se realiza la carga a Google Cloud Storage
        Current_Date = datetime.datetime.today().strftime ('%Y-%b-%d %H_%M_%S')
        #Dentro de props, vienen las propiedades del archivo
        #a cargar, dividimos el nombre del archivo para agregarle 
        #la fecha y así crear un archivo de respaldo
        if props.get('archivo_origen').find('.')!=-1:
            file_part=props.get('archivo_origen').split('.',1)
            filename_bkp=file_part[0]+' '+str(Current_Date)+'.'+file_part[1]
        else:
            filename_bkp=props.get('archivo_origen')+str(Current_Date)
        #usando funciones de las bibliotecas de google se realiza la carga del archivo a Google Cloud Storage
        try:
            bucket = creds.get('clientGS').get_bucket(props.get('Bucket_GCS'))    

            blob = bucket.blob(props.get('Path_GCS')+props.get('archivo_origen'))
            blob.upload_from_filename(props.get('archivo_origen'))

            registros=0

            dest_bucket = creds.get('clientGS').get_bucket(props.get('Bucket_GCS'))

            new_blob_name=props.get('Path_GCS_bkp')+filename_bkp
            new_blob = bucket.copy_blob(
                             blob, dest_bucket, new_blob_name)


            #Seteamos la variable exit_codeBQ en 1 para validar que la carga fue exitosa
            exit_codeBQ=1
        #si hay errores en la carga se setea la variable a 0
        except BadRequest as e:
            for err in e.errors:
                error=err
            exit_codeBQ=0
 

La segunda parte de la función realiza la carga a BigQuery, a partir del archivo que ya está en nuestro bucket de Google Cloud Storage

# Configuramos las opciones de la tabla definidas en el API de BigQuery
        dataset_ref =   creds.get('clientBQ').dataset(str(props.get('DataSet_BQ')))
        job_config = bigquery.LoadJobConfig()
        job_confighis = bigquery.LoadJobConfig()
        job_config.skip_leading_rows = 1
        job_confighis.skip_leading_rows=1
        job_config.field_delimiter = '|'
        job_confighis.field_delimiter = '|'
        job_config.write_disposition = 'WRITE_TRUNCATE'
        job_confighis.write_disposition = 'WRITE_APPEND'
        job_config.autodetect=True
        job_confighis.autodetect=True

#Establecemos el formato de origen de nuestro archivo como CSV
        job_config.source_format = bigquery.SourceFormat.CSV
        job_confighis.source_format = bigquery.SourceFormat.CSV
        uri = "gs://"+props.get('Bucket_GCS')+"/"+props.get('Path_GCS')+props.get('archivo_origen') #Este es el path de nuestro archive en Cloud Storage

        try:
            load_job = creds.get('clientBQ').load_table_from_uri(
                uri, dataset_ref.table(props.get('Tabla')), job_config=job_config)  # API request

            load_job.result()  #Espera a que termine la carga de la tabla.
            destination_table = creds.get('clientBQ').get_table(dataset_ref.table(props.get('Tabla')))
            registros=destination_table.num_rows
#Obtenemos el id de la tabla a partir de las propiedades definidas            
table_id=str(props.get('proyecto')) +'.'+str(props.get('DataSet_BQ'))+'.'+str(props.get('Tabla'))

            table = creds.get('clientBQ').get_table(table_id)  
            



#Agregamos un campo para colocar la fecha de modificación de la tabla
            original_schema = table.schema
            new_schema = original_schema[:]  # Creates a copy of the schema.
            new_schema.append(bigquery.SchemaField("FECHA_MODIFICACION", "TIMESTAMP"))

            table.schema = new_schema
            table = creds.get('clientBQ').update_table(table, ["schema"])  

#Hacemos un update para agregar la fecha de modificación
queryUpdate="UPDATE "+str(props.get('DataSet_BQ'))+"."+str(props.get('Tabla')) +" SET FECHA_MODIFICACION = TIMESTAMP('"+Timestamp_Date.strip() +"') WHERE TRUE"
            dml_statement = ("UPDATE "+str(props.get('DataSet_BQ'))+"."+str(props.get('Tabla')) +" SET FECHA_MODIFICACION = TIMESTAMP('"+Timestamp_Date.strip() +"') WHERE TRUE")
            query_job = creds.get('clientBQ').query(dml_statement)  
            query_job.result()  

                     #Seteamos la variable exit_codeBQ en 1 para validar que la carga fue exitosa
 
            exit_codeBQ=1
  #si hay errores en la carga se setea la variable a 0
except BadRequest as e:
            for err in e.errors:
                strerror=str(err)
            
            exit_codeBQ=0
     
    #Con este return devolvemos los valores de cada variable a la función principal
    return exit_codeBQ,registros,Timestamp_Date,strerror
 

Este es el Código básico para cargar nuestros archivos en Google Cloud Storage y Big Query, haciendo uso de las funciones incluidas en sus APIs.

Para mayor referencia de su uso, puedes consultar los siguientes enlaces:

Google Drive: https://developers.google.com/drive/api/v2/about-sdkGoogle Cloud Storage: https://cloud.google.com/storage/docs/reference/libraries#client-libraries-usage-pythonGoogle Big Query: https://cloud.google.com/bigquery/docs/reference/libraries#client-libraries-usage-pythonCargar un archivo CSV desde Cloud Storage:https://cloud.google.com/bigquery/docs/loading-data-cloud-storage-csv

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

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Características esenciales que debemos tener en cuenta al adoptar un paradigma en la nube

septiembre 12, 2022
LEER MÁS

Workshop Ingeniería del caos sobre Kubernetes con Litmus

julio 7, 2021
LEER MÁS

Del negocio físico a la explosión del On-Line

abril 7, 2021
LEER MÁS

Entrena y Despliega tu Modelo de Machine Learning en 15 Minutos con Databricks

junio 10, 2025
LEER MÁS

Mi experiencia en el mundo de Big Data – Parte II

febrero 4, 2022
LEER MÁS

LakeHouse Streaming en AWS con Apache Flink y Hudi (Parte 2)

octubre 4, 2023
LEER MÁS

Publicado en: Blog, Tech

Cómo preparar la certificación AWS Data Analytics – Specialty

noviembre 17, 2021 by Bluetab

Cómo preparar la certificación AWS Data Analytics - Specialty

Sergi Lehkyi

Data Engineer

Sobre la certificación

El examen de especialidad AWS Data Analytics se centra principalmente en los servicios de AWS relacionados con datos, cubriendo los dominios:

  • Recolección de datos.
  • Gestión de datos y almacenamiento.
  • Procesamiento.
  • Análisis y visualización.
  • Seguridad.

El examen trata en profundidad los siguientes servicios de AWS:

  • Amazon S3
  • Amazon Redshift
  • Amazon Kinesis
  • Amazon EMR
  • Amazon ElasticSearch
  • Amazon Athena
  • AWS Glue
  • Amazon QuickSight
  • AWS Lake Formation
  • Amazon Managed Streaming for Apache Kafka (Amazon MSK)

*Todos los servicios de datos que puedan interactuar con los anteriores (SageMaker, Backup, Glacier, GuardDuty etc.)

Se puede encontrar más en la página web de [AWS Datalakes and Analytics], también aquí está la [guía oficial del examen] y [preguntas de muestra].

Todo el contenido de este artículo es válido para el examen de 2021. Recomendamos que revises si existe alguna actualización del examen.


Sobre el coste

El coste del examen es de $300 (€270 + 21% IVA si estás en España). Además, si ya has realizado otros exámenes de AWS, obtienes un 50% de descuento en el siguiente, por lo que éste examen sale por solo €163,35. Antes de la prueba oficial se puede hacer un examen de práctica que cuesta $40 (€36 + 21% de IVA si estás en España) y nuevamente, si ya obtuviste cualquier otra certificación de AWS, el coste es cero.


Dónde y cómo

Puedes realizar el examen en línea o ir a un centro de pruebas. Recomendamos ir a un centro de pruebas oficial, principalmente por la estabilidad de la conexión a internet. Es obligatorio el uso de mascarilla en la realización presencial. Sobre la documentación, es importante presentar dos acreditaciones.


Preparación

Con aproximadamente 2 horas al día (seis días a la semana) se puede preparar para el examen en un periodo de 6-8 semanas, siempre contando con experiencia previa en los servicios mencionados.

Recursos útiles durante la preparación:

[AWS Certified Data Analytics Specialty Exam Study Path from Tutorials Dojo] – es una lista bastante completa de temas que debes verificar antes del examen, con algunas preguntas de muestra, hojas de referencia para los servicios de análisis y algunos escenarios comunes en las preguntas del examen.

[AWS Analytics Overview] – un documento técnico con la descripción general de todos los servicios de análisis de AWS.

[Data Lakes and Analytics] – otra descripción general de los servicios de análisis de AWS.

[Data Analytics Fundamentals] – curso oficial de AWS, recomendable para comenzar la preparación.

[Exam Readiness: AWS Certified Data Analytics – Specialty] – curso oficial de AWS que te ayudará a cubrir todos los temas cubiertos en el examen.

[Visualizing with QuickSight] – un plan de estudio para mejorar tu comprensión sobre QuickSight. Imprescindible para dominar la parte de visualización del examen.

[AWS Hadoop Fundamentals] – aunque está un poco fuera de alcance, ayuda a comprender mejor Hadoop y cómo se integra en AWS EMR. Si conoces perfectamente Hadoop, este curso no es necesario.

Otros cursos de [AWS Training] cubriendo S3, RDS, SageMaker, etc. serán buenos para expandir su conocimiento ya que hay algunas preguntas que tocan estos temas y los cursos son realmente breves, pero informativos. En especial, echa un vistazo a todo lo relacionado con S3.

[Tutorials Dojo’s AWS Certified Data Analytics Specialty Practice Exams 2021] – esencial para poner a prueba tus conocimientos y descubrir dónde están tus puntos débiles. También es un buen indicador de su preparación para el examen; es recomendable obtener un 90% antes del examen.


Conclusión

Los exámenes de certificación de AWS necesitan esfuerzo y dedicación pero además, tener experiencia práctica ayuda mucho para enfrentarte a los mismos. Por ejemplo, si trabajas habitualmente con AWS Glue, seguramente no te hará falta estudiar mucho acerca de este servicio porque ya conoces sus capacidades y funcionalidad a partir de tu trabajo del día a día. Muchas veces esta experiencia es más relevante de cara al examen que revisar algunos posibles escenarios teóricos: si te has enfrentado directamente con los problemas estarás mucho más seguro de cara al examen.

Espero que este pequeño resumen te ayude a preparar la certificación y consigas mejorar tus capacidades profesionales en el análisis de datos. Anímate a realizarla y veras que, aunque requiere esfuerzo, es una meta perfectamente alcanzable.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Sergi Lehkyi
Data Engineer

En mi camino profesional he pasado por desarrollo web, administración de bases de datos, ciencia de datos y últimamente estoy enfocado en las tecnologías y soluciones de Cloud, especialmente AWS.

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Data-Drive Agriculture; Big Data, Cloud & AI aplicados

noviembre 4, 2020
LEER MÁS

Análisis de vulnerabilidades en contenedores con trivy

marzo 22, 2024
LEER MÁS

Mitos y verdades de los ingenieros de software

junio 13, 2022
LEER MÁS

Empoderando a las decisiones en diversos sectores con árboles de decisión en AWS

junio 4, 2024
LEER MÁS

PERSONAL MAPS: conociéndonos más

octubre 24, 2023
LEER MÁS

Snowflake: Zero-Copy clone, o cómo librarte del duplicado de datos al clonar.

marzo 22, 2023
LEER MÁS

Publicado en: Blog, Practices, Tech

  • « Ir a la página anterior
  • Página 1
  • Páginas intermedias omitidas …
  • Página 4
  • Página 5
  • Página 6
  • Página 7
  • Página 8
  • Páginas intermedias omitidas …
  • Página 10
  • Ir a la página siguiente »

Footer

LegalPrivacidadPolítica de cookies
LegalPrivacy Cookies policy

Patrono

Patron

Sponsor

Patrocinador

© 2025 Bluetab Solutions Group, SL. All rights reserved.