Bluetab

an IBM Company

Bluetab

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

by

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

¿Cómo gobernar los productos de datos? Hacia un gobierno de los datos federado

by

¿CÓMO GOBERNAR LOS PRODUCTOS DE DATOS?

HACIA UN GOBIERNO DE LOS DATOS FEDERADO

Una de las características de la evolución de los modelos tradicionales de gobierno del dato es incorporar el gobierno del ciclo de vida del dato, y por lo tanto ampliar el “enfoque dato” al “enfoque del dato como producto y de los productos de datos”.

  • ¿Cómo aprender a generar valor a partir de los datos desde las áreas de negocio?
  • ¿Qué beneficios tiene tratar los datos como un producto?
  • ¿Cómo encontrar el equilibrio entre el grado de centralización y de distribución de infraestructura y gobierno de los datos?

Desde Bluetab creemos en la visión de un gobierno del dato integral, un enfoque que combina principios y políticas globales para los aspectos más relevantes, y una gestión descentralizada y federada por dominios de datos.

En este paper ponemos foco en el rol de la Oficina Central (Data Management Office), así como en la infraestructura o plataforma de datos y los dominios de datos, en un entorno federado. Además, Te contamos nuestras recomendaciones para la transición hacia la aportación de valor mediante los datos.

¡Descárgalo aquí!

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Publicado en: pow

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

by

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

¿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

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

by

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

Mi experiencia en el mundo de Big Data – Parte II

by

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

Hacia un Gobierno del Dato 2.0: Del Gobierno del Dato al Gobierno de los Productos de datos

by

Hacia un Gobierno del Dato 2.0:

Del Gobierno del Dato al Gobierno de los Productos de datos

  • ¿Cuáles son las consecuencias de no gestionar adecuadamente los datos de una compañía?
  • ¿Por qué muchos programas de Gobierno del Dato fracasan o no obtienen los resultados previstos?

Desde Bluetab pensamos que ha crecido la importancia de gobernar todo el ciclo de vida del dato. Creemos que es necesario un nuevo enfoque, evolucionar hacia un Gobierno del Dato 2.0 que tenga en cuenta:

  • Una nueva visión de los datos: Compartición y reutilización
  • El impacto de las nuevas arquitecturas de datos basadas en Cloud
  • Agile mindset: Cómo organizarnos para trabajar en proyectos de datos
  • Gobierno del ciclo de vida del dato: Enfoques federados y Gobierno de los Productos de Datos
¡Descárgalo aquí!

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Publicado en: pow

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