Bluetab

an IBM Company

Bluetab

Databricks on Azure – An architecture perspective (part 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

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

Databricks on Azure – An Architecture Perspective (part 1)

by

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

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

Towards data governance 2.0: From data governance to data product governance

by

TOWARDS DATA GOVERNANCE 2.0:

FROM DATA GOVERNANCE TO DATA PRODUCT GOVERNANCE

  • What are the consequences of not properly managing a company's data?
  • Why do many Data Governance programs fail or do not achieve the expected results?

From Bluetab we think that the importance of governing the entire life cycle of the data has grown. We believe that a new approach is necessary, to evolve Towards a Data Government 2.0 that takes into account:

  • A new view of data: Sharing and reuse
  • The impact of new cloud-based data architectures
  • Agile mindset: How to organize ourselves to work on data projects
  • Data Lifecycle Governance: Federated Approaches and Data Product Governance
¡Descárgalo aquí!

SOLUTIONS, WE ARE EXPERTS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

You may be interested in

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

by

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

¿Existe el Azar?

by

¿Existe el Azar?

Lorelei Ambriz

Technician

Una breve e informal introducción a la teoría del caos matemático y la teoría de la probabilidad matemática.

Para poder responder a la pregunta sobre la existencia del azar, primero abordaremos otro concepto con el cual posiblemente ya estemos parcialmente familiarizados. Dicho concepto es el caos matemático, o también conocido coloquialmente como el efecto mariposa. Así como algunos conceptos relacionados a este: sistemas dinámicos y determinismo.


¿Qué es el caos matemático?

En resumen, la teoría del caos, o caos matemático (para no perder de vista las matemáticas) tiene como centro de estudio, los sistemas dinámicos que aparentan tener un comportamiento aleatorio, sin embargo estos son gobernados por patrones y determinismo.


¿Qué es un sistema dinámico?

Un sistema dinámico es un conjunto de fenómenos deterministas que interactúan uno con otro dentro de este conjunto en función de una colección de parámetros (usualmente el parámetro más usado es el tiempo).

Un ejemplo sencillo de sistema dinámico es un péndulo simple. Para detallar un poco más, mencionemos los componentes de este sistema. Un péndulo simple consiste en un tubo/varilla que en uno de los extremos sostiene un peso mientras que del otro, estará sostenido de forma que pueda columpiarse. Los componentes de este sistema son: la longitud de la varilla, el peso que carga, la fuerza gravitatoria y la altura inicial a la que hará su primera oscilación. El resultado de la ejecución de este sistema es una medición del tiempo.

Un ejemplo mucho más sofisticado es el planeta Tierra. Entre sus componentes más notorios están: árboles, agua, aire, radiación recibida por el sol, la geografía del planeta, etc. Uno de los resultados apreciables en este sistema como resultado de estos componentes es el clima de la Tierra.


¿Qué es el determinismo?

Decimos que un modelo es determinista cuando existe una ley o regla que siempre va a cumplir dicho modelo asociado a un fenómeno particular. O en otras palabras, está determinado por dichas leyes y las condiciones que le rodean. Por dar un ejemplo, como si se tratase de la descripción de la maquinaria en un reloj con péndulo. En esta maquinaria hay todo un sistema dinámico que cambia con respecto al tiempo. Poseé un conjunto de engranajes, manecillas y un péndulo, que organizados de forma específica, nos dará como resultado un dispositivo con el que medir el tiempo a lo largo de un día.

Para comprender y/o descubrir las leyes o reglas que gobiernan estos sistemas, los matemáticos, en resumen, recurrimos a la búsqueda de patrones con un razonamiento lógico deductivo así como algunas veces es necesaria la experimentación e incluso el método científico.


Y ahora, ¿Qué sigue?

Habiendo hablado un poco sobre sistemas dinámicos, determinismo y caos matemático introduciremos el siguiente concepto: estabilidad de sistemas dinámicos. ¿Cómo podemos considerar la estabilidad?. Sin entrar en el rigor matemático pero con algo de matemáticas, un sistema es estable cuando tenemos una curva ‘f’ definida por una condición inicial ‘x0’ en este sistema y trazamos una “tubería” alrededor de esta curva para que quede contenida en esta (vecindad de convergencia). Y entonces para cualquier condición inicial ‘t0’ cercana a ‘x0’, que nos define una curva ‘g’ ocurrirá uno de los siguientes casos:

  • Si g → f (tiende o cada vez se acerca más a f) entonces el sistema es asintóticamente estable.
  • Si g permanece dentro de la tubería en todo momento, entonces el sistema es estable.
  • Si a partir de un momento, g sale de la tubería y de cualquier tubería con centro en f, entonces el sistema es inestable.


Observación: si ‘g’ saliera 1 vez (o incluso n veces), entonces hacemos una tubería con centro en f que contenga a toda la curva g. Por eso se dice que sale de todas las tuberías posibles, porque entonces ‘g’ se vuelve completamente diferente a ‘f’ a partir de algún momento.

Ahora usando ejemplos con pares idénticos de péndulos para tener una mayor visibilidad de los casos anteriores:

  • Levanta el par de péndulos, y al soltarlos de forma simultánea, estos oscilarán con la misma frecuencia y se detendrán casi al mismo tiempo. Esto es estabilidad asintótica.
  • Levanta el par de péndulos, pero instalados sobre una “máquina de movimiento perpetuo”. Al soltarlos estos oscilarán con la misma frecuencia hasta que se detenga la máquina.
  • Ahora considera un par de péndulos dobles, y levanta dicho par a una misma posición. Al soltar los péndulos, después de unos segundos cada péndulo tendrá su trayectoria completamente diferente al otro. Esto es inestabilidad. De hecho, en este caso en particular, las trayectorias parecieran ser aleatorias. Sin embargo siguen cumpliendo las leyes que rigen a los péndulos.

Cabe recordar que aunque creamos ponemos a la misma altura los péndulos, en el mundo físico hay una diferencia mínima entre estas alturas. Para los sistemas estables, la estabilidad parece menospreciar dicha diferencia. En cambio, el sistema inestable es altamente sensible a estos cambios y esta pequeña diferencia inicial termina siendo una enorme diferencia al poco tiempo.


¿Dónde más podemos ver el caos matemático?

La respuesta es relativamente fácil: en casi todos los lugares a donde miremos. Desde las trayectorias y posición donde caen las hojas de un árbol al desprenderse de sus ramas, las acciones de las acciones en la bolsa, hasta incluso los procesos biológicos de los seres vivos y sin olvidar un ejemplo muy importante: el clima de la Tierra. Una persona podría reflexionar que todo el universo está gobernado por caos matemático, determinismo absoluto. Simplemente las relaciones que ocurren entre los componentes del universo pueden ser desde relativamente simples, a altamente complejas.


Ahora con todo lo planteado: ¿Existe el azar?

La respuesta pareciera ser que no. Sin embargo, notemos un detalle importante sobre lo que conocemos del azar: podemos tener la seguridad que un resultado o salida obtenido de un evento aleatorio es desconocido, ya que si lo supiéramos de antemano, entonces el evento no sería aleatorio. En este punto pareciera que podemos ver el caos matemático como azar, sin embargo este es determinista y eso nos implica que conociendo todos los componentes que definen esta curva (leyes, condiciones iniciales e interacciones entre todas las variables), podemos conocer de antemano todas las salidas. Pero aquí está precisamente el detalle: conocer todas las interacciones de forma precisa entre todas las variables. Cuando estas interacciones se vuelven muy complejas dentro del sistema y este se vuelve inestable, en lugar de intentar comprender lo que ocurre entre estas variables, podemos empezar a analizar las posibles salidas o resultados de este. De este análisis podemos ver que otros patrones empiezan a emerger: distribuciones de probabilidad.


Distribuciones de probabilidad: un vistazo a la teoría de la probabilidad.

La teoría de la probabilidad es una rama dentro de las matemáticas que estudia los eventos aleatorios y estocásticos. Si bien la teoría clásica de la probabilidad se reduce a hacer conteos de casos favorables y compararlos contra todos los posibles escenarios, cuando se propone un conjunto de axiomas basados en la teoría de conjuntos y la teoría de la medida por parte de Andréi Kolmogórov es que la teoría de la probabilidad adquiere rigor matemático y así se puede extender su estudio más allá de los marcos clásicos de esta. Argumentos en el contexto de la probabilidad utilizados en diversas áreas como la física, economía, biología entre otras cobran fuerza gracias a esta aportación. A partir de aquí es que surge la teoría moderna de la probabilidad. Algunos de los conceptos y resultados más importantes de esta teoría moderna son:

  • Variables aleatorias y funciones de distribución.
  • Leyes de los grandes números.
  • Teorema del límite central.
  • Procesos estocásticos.


Conexión entre los sistemas caóticos y la probabilidad.

Como platicamos anteriormente, estudiando las salidas o resultados de sistemas dinámicos inestables podemos ver que hay patrones que emergen de estos. Curiosamente estos se comportan como variables aleatorias y funciones de distribución de la teoría de la probabilidad. Esto se debe a algunos resultados importantes como son las leyes de los grandes números y el teorema del límite central entre otros. Recordando que la teoría de la probabilidad adquiere su rigurosidad a partir de los axiomas de Kolmogorov que tienen origen en la teoría de conjuntos y la teoría de la medida.


Entonces: ¿el azar existe?

Si bien podemos concluir que el universo es gobernado por leyes de las cuales algunas conocemos y otras no (de aquí podemos abrir otro tema para otra ocasión: Lo que sabemos, lo que no sabemos, y lo que no sabemos que no sabemos), y esto tiene implícito la omnipresencia del determinismo. Podemos concluir que el azar no tiene lugar en el universo. Sin embargo, recordemos que la teoría de la probabilidad es una construcción humana, cuya rigurosidad y patrones pueden ser conectados con otras áreas, y como ya vimos, particularmente pueden ser conectados con el caos matemático para cambiar el enfoque de estudio de los fenómenos regidos por el caos. Pasando de conocer las leyes que los gobiernan para entender las salidas y resultados de estos, a conectar dichos patrones con las distribuciones de probabilidad que tienen toda una teoría matemática que las respalda, así como un área que las explota como es la estadística.


Explotando el azar

Sabiendo que el azar está directamente conectado con el desconocimiento de resultados y ocurrencias. Y precisamente por esta razón es que podemos explotar la teoría de la probabilidad, entonces podemos pasar a construir un objeto muy importante dentro de la ciencia de la computación: los generadores de números aleatorios.

Estos generadores son objetos muy útiles para dotar de nuestros procesos con la esencia del caos y así traer la complejidad del mundo a nuestros análisis, modelos, simulaciones y demás. Sin embargo, cabe mencionar que para obtener generadores de números aleatorios que en verdad tengan lo que buscamos, es importante notar que no debe haber un patrón sencillo en estos. ¿Entonces cómo podemos recurrir a construir un buen generador de números aleatorios?. La respuesta se encuentra en el mismo caos. Por ejemplo, usar las curvas que recorren los péndulos dobles, o la paridad en los dígitos decimales de π, entre otros.

Simulando el azar en nuestros procesos, podemos aprovechar una de las características más importantes de este, la cual es: la imparcialidad. Con esta, eliminamos sesgos de nuestras muestras (característica fundamental para entrenar con imparcialidad a nuestros modelos de aprendizaje máquina), contribuyendo incluso al mismo entrenamiento que ocurre en los modelos de aprendizaje máquina y aprendizaje profundo por medio de la optimización de las funciones de costo. Otra simulación muy importante a mencionar es la simulación de MonteCarlo, la cuál nos permite obtener muestras aleatorias que representan lo que podemos modelar, así como pueden ser usadas para diferentes cálculos computacionales pesados que de forma clásica podrían ser desde muy complejos, hasta imposibles.


Conclusión

El azar es un constructo humano que si bien no existe en el universo de forma natural debido a la naturaleza compleja de este, como concepto humano nos ayuda a comprender y estudiar lo que sucede reduciendo la complejidad que surge de forma natural. Así que en efecto, el azar existe, porque la humanidad lo construyó y un día se dió cuenta que le ayudaba a comprender mejor el complejo universo en el que vivimos.

¿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

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