• Skip to primary navigation
  • Skip to main content
  • Skip to footer
Bluetab

Bluetab

an IBM Company

  • SOLUTIONS
    • DATA STRATEGY
    • Data Readiness
    • Data Products AI
  • Assets
    • TRUEDAT
    • FASTCAPTURE
    • Spark Tune
  • About Us
  • Our Offices
    • Spain
    • Mexico
    • Peru
    • Colombia
  • talent
    • Spain
    • TALENT HUB BARCELONA
    • TALENT HUB BIZKAIA
    • TALENT HUB ALICANTE
    • TALENT HUB MALAGA
  • Blog
  • EN
    • ES

Tech

Data Mesh

July 27, 2022 by Bluetab

Sí, Data Mesh es realmente transformacional, pero…
¿quién me ayuda a implantarlo?

En las últimas décadas, las compañías han tratado de generar o determinar un lugar que les permita mantener, controlar y acceder a datos analíticos de su empresa y del mercado; esto con el objetivo de mejorar su negocio.

Un ejemplo típico de ello es la utilización datos del comportamiento de los clientes y el uso de sus productos para la obtención de conocimientos claros y prácticos que les permitan administrar más eficientemente el negocio, así como mejorar y crear nuevos productos.

Sin embargo, al tratar de generar estas entradas de información, los profesionales dentro de la industria se enfrentan a varios retos que pueden llegar a crear mucha frustración y caminos cerrados. Tecnologías como el Big Data o los Data Lakes han ido dando soluciones conforme se evolucionaban los modelos.

Desde mayo de 2019 con la publicación de Zhamak Dehghani, estamos viendo una nueva evolución de las prácticas para diseñar arquitecturas de datos que están cambiando estos modelos del mundo del Big Data y del Data Lake.

Hasta ahora las clásicas tres capas de ingesta, procesamiento y publicación resultaban suficientemente eficientes. Pero esa eficiencia basada en la centralización y el gobierno, hoy genera silos de conocimiento, cuellos de botella en las organizaciones complejas, falta de escalabilidad en la agregación de características y en definitiva desconexión entre los originadores de la información y los consumidores.

El enfoque de Data Mesh es más que una metodología, un paradigma para la integración de una arquitectura de datos que descentraliza la propiedad de los dominios de datos, y al mismo tiempo define productos de datos analíticos, en un entorno que equilibra le gestión gobernada y la autonomía de los citados dominios. El paradigma Data Mesh, que hereda conceptos de la filosofía DDD (Data Driven Design), identifica cuatro conceptos como base de su modelo:

  • Los dominios como dueños de los datos, dominios cuya concepción inicial puede aproximarse a los dominios de negocio, y es donde se definen las entidades de datos y las relaciones con otros dominios para su consumo.
  • Los datos como producto, y como tal, pasan a ser susceptibles de proveer niveles de servicio. Pasando la responsabilidad de los mismo de la plataforma al equipo responsable del dominio.
  • La plataforma como autoservicio, automatizada y asegurando la independencia y la autonomía de cada dominio.
  • El gobierno federado, que asegure las decisiones próximas a los dominios pero que a la vez establezca las reglas de mínimos que aseguren la interoperabilidad entre ellos.

Este nuevo modelo supone además un cambio organizacional para asegurar su éxito. Los dominios además de dueños de sus productos de datos deben ser autónomos a la hora de desarrollar nuevos productos tanto para consumo propio como de otros dominios. Y, además, deben asegurar el consumo y el gobierno de los productos de datos. Y para ello deben contar con el conocimiento necesario de las plataformas, de forma que se asegure su autonomía, descargando del equipo de plataforma ciertas responsabilidades de gestión de dichos productos de datos.

Estos cambios a modelos más ágiles, pero a la vez de responsabilidades distribuidas, son fundamentalmente culturales, y requieren contar con equipos maduros capaces de asumir de forma autónoma la nueva distribución de responsabilidades, los nuevos procesos y su gobierno.

Vale, pero ¿por dónde empiezo?

Hoy nuestros clientes se enfrentan aún a un modelo en proceso de maduración en el mercado que genera muchas cuestiones de enfoque inicial.  Pese a que parece claro que ese equilibrio entre gobernabilidad y autonomía puede aportar eficiencias, el modelo metodológico de Data Mesh es aún emergente, y por descontado requiere del soporte de equipos senior técnicos y de negocio con alto nivel de madurez, capaces de tomar decisiones ágiles a lo largo del proceso, que no puede entenderse como puntual, sino de medio o largo plazo.

Bluetab a lo largo de los proyectos en entornos de clientes, ha desarrollado una metodología basada en experiencias de implantación de modelos de gobierno que aseguran un enfoque adecuado de este proceso de transformación. Una metodología muy operativa enfocada, más allá de un trabajo teórico, a la aplicación práctica de los modelos a los diferentes ecosistemas de nuestros clientes.

Esto se lleva a cabo estableciendo primero, casos de uso controlados y relevantes que permitan la visión desde la generación hasta el consumo de la información requerida por negocio, posteriormente, definiendo el plan de despliegue a los demás casos de uso de la organización y, finalmente y en paralelo, actuando sobre los requerimientos del cambio organizacional con comunicación y acciones específicas que habiliten la gestión del cambio.

Esta metodología inicia con el apoyo a la definición del contexto de dominios y la identificación de un primer caso de uso (MVP) que permita la visión end-to-end de los requerimientos a lo largo de los cuatro elementos, los citados dominios, los productos de datos y sus interdependencias, el modelo de autoservicio y las arquitecturas habilitadoras, y los requisitos de un gobierno no limitativo.

Una vez establecido dicho MVP e implantado, se genera el entendimiento global necesario para la definición de un plan de despliegue capaz de escalar a todo el ecosistema con éxito. Un plan que mediante métodos ágiles irá adaptándose a las diferentes particularidades y al propio cambio de requerimientos de negocio en el tiempo.

Pero el valor de nuestra aportación está en que, a lo largo de nuestros proyectos, hemos desarrollado herramientas prácticas de automatización para la implantación práctica de los modelos, aceleradores que Bluetab pone a disposición de sus clientes y que aseguran la optimización de los tiempos en el proceso de despliegue y su posterior evolución, y el apoyo a los clientes para una definición del modelo adecuado a su ecosistema y adaptada a sus requerimientos de negocio. Todo ello soportado por una estrategia de medición del valor aportado mediante datos objetivados KPIs.

En la definición de un ecosistema orientado a dominios es crucial el entendimiento del negocio y de la realidad de los consumos de datos dentro de cada una de las estructuras organizativas. A partir de ahí se puede establecer el debate para una definición de dominios consistente, acordada y de largo plazo.

Una herramienta como nuestra Matriz de Convergencia, donde se cruzan consumos, proyectos, orígenes, etc., permite una evaluación objetiva y profundizar en un mismo entendimiento y nomenclatura común en la organización. A partir de ahí, la definición del primer caso de uso y la priorización en el plan de escalado posterior se realiza de forma consistente.

En la generación de productos de datos, hay varios factores relevantes además del entendimiento y los modelos del consumo seguramente mediante API´s y una estrategia de disponibilización con la definición de mínimos requeribles. Uno de esos factores es la evaluación de la aportación del valor de dichos productos, y otro la estrategia de comunicación y comunicación/disponibilización a los demás dominios.

Para todo ello nuestro asset de gobierno del dato, Truedat, posibilita una solución que cubre desde el metadatado, a la generación de un Marketplace común, asegurando el control de los mínimos de gestión.

En la gestión del gobierno federado y el equilibrio entre el control y la autonomía de los dominios, nuestra Matriz de Madurez es fundamental para la evaluación del nivel de dicha madurez y el establecimiento del programa que cubra el gap de requerimientos. Y una vez establecido el programa, esta misma suite de servicios, Truedat, aporta capacidades adecuadas de calidad o trazabilidad que aseguran la implementación de las reglas que definan los propietarios en los dominios y la gestión técnica del end-to-end del ciclo de vida del dato.

Y finalmente en el desarrollo de una plataforma automatizada y enfocada al autoservicio de los dominios, nuestros modelos de arquitecturas, así como nuestras herramientas de despliegue automático de servicios y nuestros modelos de despliegue de estrategias Devops y MLops, aseguran una implantación optimizada de la estrategia y un time-to-market eficiente en su evolución de requerimientos.

La implantación de una estrategia Data Mesh genera aún muchas dudas sobre cómo abordarla en entornos complejos en el que coexisten diferentes arquitecturas, modelos de datos y requerimientos de consumo. Nuestro enfoque metodológico, más dirigido al desarrollo práctico de la puesta en marcha de cada uno de los pilares de la estrategia, puede asegurarte un despliegue ágil y en unos tiempos asumibles. De esta forma tanto las áreas técnicas como negocio pueden obtener el retorno de valor en los plazos requeridos.    

Síguenos y en próximos artículos entraremos en mayor detalle sobre cómo aterrizar de forma práctica y eficiente en este nuevo paradigma Data Mesh.

Autores

Liliana Palestina

CTO

Alvar Noe Arellanos

Business & IT Strategy Professional

Juan Manuel Sanchez

Data Strategy

Armando Camargo

Data Governance Manager

Jesus Saavedra

BI Manager

José Carranceja

COO

¿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

Essential features to consider when adopting a cloud paradigm

September 12, 2022
LEER MÁS

Databricks on Azure – An architecture perspective (part 2)

March 24, 2022
LEER MÁS

Snowflake, el Time Travel sin DeLorean para unos datos Fail-Safe.

February 23, 2023
LEER MÁS

Using Large Language Models on Private Information

March 11, 2024
LEER MÁS

¿Existe el Azar?

November 10, 2021
LEER MÁS

Oscar Hernández, new CEO of Bluetab LATAM.

May 16, 2024
LEER MÁS

Filed Under: Blog, Blog, Outstanding, Tech

Some of the capabilities of Matillion ETL on Google Cloud

July 11, 2022 by Bluetab

Algunas de las capacidades de Matillion ETL en Google Cloud

Duvan Duque

Data Engineer | Google Cloud Associate Cloud Engineer

Matilion ETL es un producto que nos permite recopilar datos de distintas fuentes y estructurarlos actualmente cuenta con versiones para Snowflake, Delta Lake en Databricks, Amazon Redshift, Azure Synapse, Google BigQuery siendo esta última en la que vamos a profundizar.

En Google cloud se cuenta con 4 opciones para implementar Matillion las cuales son:

Matillion ETL for BigQuery – Cluster:

  • 12 usuarios concurrentes , 36 entornos y autobalanceo zonal para satisfacer la demanda de forma constante

Matillion ETL for BigQuery – Extra Large:

  • 12 usuarios concurrentes y 36 entornos

Matillion ETL for BigQuery – Large:

  • 5 usuarios concurrentes y 15 entornos

Matillion ETL for BigQuery – Medium:

  • 2 usuarios concurrentes y 6 entornos

Matillion ETL for Snowflake:

  • Esta opción está dirigida a Snowflake

El servicio se encuentra ubicado en el Marketplace de Google De ahora en adelante se hablará de la versión médium ya en ese momento las necesidades del proyecto no se necesitaban más recursos.

Cada una de las versiones tiene un costo diferente la versión médium tiene un precio estimado sin descuentos de 1437.05 USD al mes teniendo en cuenta que la instancia se encuentre encendida durante 30 días 24 horas y la facturación mínima es por 1 minuto.

Una vez lanzado el servicio desde Marketplace se creará una instancia en compute engine la cual cuenta con una dirección IP estática mediante la cual se puede acceder al servicio

Una vez dentro se debe establecer estructura de proyectos los cuales pueden contener carpetas para organizar el flujo de trabajo los cuales van a contener dos tipos de Jobs orquestación y transformación. los cuales se pueden crear realizando un clic derecho sobre las carpetas.

Cada de los jobs cuenta con distintos componentes y capacidades para el caso del job de orquestación son los siguientes:


Componentes de carga

Estos componentes son los que extraen información de las diversas fuentes para llevarla a Bigquery entre ellos tuve la oportunidad de usar integraciones con Hubspot, APIs, Cloud storage y Facebook. siendo estos solo una pequeña porción de la lista de integraciones disponibles

Componentes de descarga

Los cuales principalmente tienen como fuente una tabla de Bigquery y la llevan a otro destino como Cloud Storage

Componentes DDL

Los cuales permiten manipular las tablas de Bigquery

Componentes de flujo

Los cuales permiten realizar operaciones con los otros componentes

Componentes de iteración

Los cuales permiten crear ciclos de un componente

Componentes de código

Los cuales permiten ejecutar códigos como Bash, Jython, Python 2 y Python 3

Componentes de transformación

Los cuales permiten ejecutar otros Jobs de orquestación y transformación

los nombrados anteriormente solo son algunos de los que tuve la oportunidad de trabajar ya que eran los requeridos para alcanzar las necesidades del proyecto y cabe mencionar que la herramienta cuenta con más.
Los jobs tienen la capacidad de encadenar y ejecutar distintos componentes.

Es posible encadenar y establecer condiciones en un Job o múltiples para su ejecución dentro de otro Job

se cuenta con la capacidad agendar la ejecución de los Jobs dentro del propio Matillion

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

Duvan Duque

Data Engineer | Google Cloud Associate Cloud Engineer

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Data Mesh

July 27, 2022
LEER MÁS

Boost Your Business with GenAI and GCP: Simple and for Everyone

March 27, 2024
LEER MÁS

Workshop Ingeniería del caos sobre Kubernetes con Litmus

July 7, 2021
LEER MÁS

MDM as a Competitive Advantage in Organizations

June 18, 2024
LEER MÁS

Spying on your Kubernetes with Kubewatch

September 14, 2020
LEER MÁS

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

October 4, 2023
LEER MÁS

Filed Under: Blog, Tech

CLOUD SERVICE DELIVERY MODELS

June 27, 2022 by Bluetab

Modelos de entrega de servicios en la nube

Alejandro León

Senior Data Consultant

Este artículo nos pretende acercar a los modelos de entrega que hoy en día se ocupan dentro de las nubes principales del mercado y cómo es que estas adoptan estos mismos modelos para sopesar las necesidades de un mundo tecnológico y cambiante constantemente.

  • PaaS (Platform as a Service), plataforma como servicio.
  • IaaS (Infraestructure as a Service), infraestructura como servicio.
  • SaaS (Software as a Service), software como servicio.

Por otra parte, se tienen los modelos de despliegue que se pueden implementar en las organizaciones: la nube privada, pública e híbrida, entre otras.

SAAS (SOFTWARE COMO SERVICIO)

El término software como servicio, infiere básicamente al software residente, es decir; el (instalado) en la nube, aunque no todos los sistemas SaaS son sistemas instalados en la nube, la mayoría sí.

SaaS es un modelo de software basado en la Web, que provee el software a través de un navegador web, en donde cada una de las aplicaciones son accesibles desde diferentes dispositivos hacia el usuario final, por medio de una interfaz ligera, ocupando la interfaz de los navegadores que tenemos hoy en día.

En un sistema SaaS, el usuario no requiere saber sobre el alojamiento del software ni el Sistema Operativo (SO), así como tampoco si está escrito en algún lenguaje de programación como, por ejemplo: PHP, Java o .Net; Adicionalmente, el usuario final no requiere instalar ningún software o programa, inclusive no gestiona ni administra la infraestructura principal de la nube, incluyendo redes, SO, servidores, ni las funcionalidades de las aplicaciones individuales, salvo las posibles configuraciones personalizadas requeridas por el servicio de nube correspondiente.

Una aplicación típica de software SaaS es Gmail, un programa de correo electrónico de Google, es un programa que se utiliza a través de un navegador web, proporcionando la misma funcionalidad de Microsoft Outlook o Apple Mail, pero sin necesidad de configurar la cuenta de correo electrónico, solo basta ingresar directamente a Gmail para acceder a su correo, dada la importancia de este tipo de modelo de servicio en la informática en la nube.

A finales de los 90 y a inicios del 2000, surgieron los ASP (Application Service Provider) proveedores de servicios de aplicaciones, estas empresas proporcionan servicios de software a múltiples organizaciones desde un centro de cómputo y a través de Internet.

En los últimos años, los servicios SaaS han evolucionado como modelo de bajo demanda, ya que el pago del servicio depende de su uso y consumo. La aparición de herramientas como Google Apps apunta a los servicios SaaS como modelo de desarrollo de software del siglo XXI.

SaaS ha provocado diversos cambios en su uso e incluso para las otras licencias del software, esto es un gran reto entre el software como servicio basado tanto en código abierto (software libre) y el software propietario, modelo popular representado por Microsoft y los otros grandes como IBM, Oracle, SAP.

PLATAFORMA COMO SERVICIO (PAAS)

La plataforma como servicio (PaaS), ofrece un entorno de desarrollo de aplicaciones a los programadores, quienes las desarrollan y ofrecen sus servicios a través de la plataforma PaaS. Por otra parte, el proveedor ofrece estos servicios regularmente para el desarrollo de aplicaciones kits de herramientas (toolkits), lenguajes de programación, estándares de desarrollo y canales de distribución. Estos estándares permiten el desarrollo y la programación de aplicaciones de software, dado el bajo costo como la oportunidad que ofrecen los canales de comunicaciones establecidos, para la comercialización hacia los clientes.

Los sistemas PaaS son muy rentables ya que facilitan a los desarrolladores de aplicaciones y pequeñas empresas innovadoras para expandirse a través de aplicaciones web sin el coste y complejidad que supondría la compra de servidores, configuraciones y la puesta en funcionamiento.

INFRAESTRUCTURA COMO SERVICIO (IAAS)

La infraestructura como servicio (IaaS), proporciona los servicios básicos necesarios para ejecutar las aplicaciones. Este modelo brinda servicios de almacenamiento de datos, capacidad de procesamiento, servidores y otros equipamientos físicos, en pago exclusivo por uso.

Esto puede incluir también, la entrega de sistemas operativos SO y tecnología de virtualización para gestionar los recursos. Al usuario se le provee la capacidad de almacenamiento, procesamiento, redes y otros recursos informáticos fundamentales en donde este es capaz de desplegar y ejecutar un software específico, que puede incluir SO y/o aplicaciones.

El usuario final no gestiona ni controla la infraestructura principal de la nube, pero

puede tener el control sobre el SO, almacenamiento y aplicaciones desplegadas.

En la práctica el cliente IaaS “renta” (paga por uso y prestaciones) de los recursos informáticos en su propio data center (centro de datos), en lugar de comprarlos e instalarlos.

CONCLUSIONES

Una vez abordados estos conceptos podemos comentar que la nube (Cloud) es un sinónimo de Internet y en términos científicos, una representación simple de una red de conexión de datos compleja y dispositivos interconectados que forman la nube.

En la actualidad, surgen nubes públicas y privadas como subconjuntos de Internet en función de sus relaciones entre sí con pequeñas, medianas y grandes empresas.

De hecho, las nubes públicas y privadas se dan a conocer como redes internas o externas, al igual que los centros de datos corporativos o de la nube; en la práctica la diferencia reside en las relaciones de las empresas con la nube.

La definición de público o privado de la computación en la nube debe facilitar las relaciones entre los proveedores del servicio y los clientes, mediante las tarifas acordadas previamente o gratuitas, regularmente las ofertas comerciales siempre deben cumplir la calidad de los requisitos de servicio de los clientes, ofreciendo acuerdos de nivel de servicio, tipo SLA (Service Level Agreements).

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

Alejandro León

Senior Data Consultant

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

De documentos en papel a datos digitales con Fastcapture y Generative AI

June 7, 2023
LEER MÁS

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

April 11, 2023
LEER MÁS

Bluetab is certified under the AWS Well-Architected Partner Program

October 19, 2020
LEER MÁS

El futuro del Cloud y GenIA en el Next ’23

September 19, 2023
LEER MÁS

Databricks on AWS – An Architectural Perspective (part 2)

March 5, 2024
LEER MÁS

MICROSOFT FABRIC: Una nueva solución de análisis de datos, todo en uno

October 16, 2023
LEER MÁS

Filed Under: Blog, Tech

Myths and truths of software engineers

June 13, 2022 by Bluetab

Mitos y verdades de los ingenieros de software

Camilo Andrés Montoya Hernández

Desarrollo de Software

Últimamente, tras el crecimiento exponencial en las diferentes tecnologías y la alta demanda de ingenieros de software (sistemas, IT, entre otras denominaciones) a nivel mundial, múltiples organizaciones han puesto su mirada en estos profesionales y  las actividades que realmente desarrollan en su diario vivir, sin embargo, aún existe mucha especulación con ideas que no son del todo ciertas y la creencia de que la programación es solo para unos cuantos superdotados, por eso hoy en Bluetab, an IBM Company queremos aclarar todos esos mitos que se pudieron escuchar de conocidos, amigos o incluso docentes así mismo como las dudas que uno mismo puede plantear en algún momento si se llegó a considerar dirigir la vida profesional en el campo del software.

Sin más preámbulo, comencemos:

 

Mito: Para programar hay que ser un experto en matemáticas.

 

Realidad: Para dedicarse a la programación, el conocimiento matemático adquirido en la educación básica y secundaria puede llegar a ser suficiente. Solo áreas específicas, como el desarrollo de juegos, la inteligencia artificial o la creación de algoritmos de machine learning pueden requerir habilidades más avanzadas, pero no es un requerimiento excluyente para programar, y aun así, siempre está la posibilidad de implementar herramientas y bibliotecas (porciones de software que otras personas ya escribieron y resuelven parte de los problemas que se presenten a lo largo del proyecto) las cuales evitan tener que realizar expresiones matemáticas complejas dentro del código y enfocarse en lo verdaderamente importante. En resumidas cuentas, los conocimientos sobre matemáticas no son directamente proporcionales a las habilidades que se tengan o se puedan llegar a desarrollar para desenvolverse como ingeniero de software.

 

Mito: La tecnología no es para las mujeres.

 

Realidad: La idea de que las mujeres descarten carreras relacionadas con la tecnología a simple vista parece algo normal y que no tiene importancia, lo anterior ya que la publicidad, las series y las propias entrevistas de RRHH para un cargo han fomentado el estereotipo del “programador hombre”, lo anterior sumado a la desigualdad en los números (en cantidad de mujeres dentro del ámbito tecnológico y la diferencia de salarios vs. el género masculino) puede traducirse en un ambiente hostil para las mujeres. Sin embargo, poco a poco el crecimiento acelerado del sector del software está modificando la cultura en el sector de las ciencias de la computación. Hace unas semanas, varías compañeras de Bluetab, an IBM Company conversaron sobre su experiencia en las TIC y su labor como colaboradoras (Bluetab América, an IBM Company, 2022) de la compañía, haciendo énfasis en aspectos importantes, como, por ejemplo, el que los equipos de trabajo conformados por profesionales de ambos géneros tienen un mayor grado de resolución de problemas, además, logran tasas más altas de productividad e innovación.

Por último, es importante resaltar que no se trata de un problema biológico, sino histórico, no obstante, el número de mujeres que aprenden a programar y deciden enfocar su vida profesional a estos roles está en constante crecimiento y las iniciativas de gobiernos y organismos privados por la igualdad en este sector son fuente de motivación para romper esa brecha

 

Mito: Todos los informáticos son programadores.

 

Realidad: Actualmente se tiene la falsa creencia de que quien estudia informática en la universidad (o por medio de un aprendizaje autodidacta recurriendo a otras fuentes de contenido) es por obligación programador, a pesar de esto, se debe considerar la informática en sí misma es muy extensa y contempla un abanico de múltiples áreas que van desde el análisis de sistemas, administración de servidores, desarrollo de software, bases de datos, hasta redes y gerencia de proyectos. 

 

Los profesionales de las carreras de sistemas, tecnología o software en algún momento pueden llegar a tratar  lo largo de su aprendizaje todos los contenidos mencionados, pero, enfocándose a los ingenieros de software, ellos son personas que suelen poseer un conocimiento técnico profundo y selecto puesto que necesitan captar conocimientos muy puntuales que fomenten el desarrollo de la lógica y la resolución de problemas, por lo cual es normal que una persona con este rol no suela manejar temas de redes, soporte o administración de servidores, ya que no son de su área de formación ni se desempeñan día a día en esas actividades.

 

Mito: Programar es muy complejo.

 

Realidad: Programar no es una habilidad que surja de forma espontánea, requiere formarse y practicar mucho para lograr cierto dominio y fluidez, además, al igual que otros trabajos tiene cierto grado de dificultad, pero una de las ventajas de las funciones vinculadas con la tecnología es que al realizar el trabajo en equipo se pueden encontrar soluciones accesibles y más óptimas, sumado a esto, el hecho de que en los últimos años hayan aparecido lenguajes muy fáciles de aprender cómo Python, JavaScript, Kotlin o herramientas No Code vuelve una realidad la premisa de que todos pueden aprender a programar.

 

Las carreras asociadas a la informática tienen un marco de trabajo dirigido especialmente hacia el pensamiento lógico, aunque en realidad, el desarrollo de software no es tan diferente de aprender un nuevo idioma. Los lenguajes de programación, al igual que el inglés, el italiano o cualquier idioma, se componen de palabras, gramática, sintaxis y tienen un propósito: comunicarse (en este escenario la comunicación es con cualquier dispositivo electrónico).

Finalmente, es cierto que como en todas las profesiones y áreas del conocimiento hay personas que puedan tener mayores skills de entrada, en este punto, la actitud va a marcar una gran diferencia para ser o no un buen ingeniero de software. Como se ha recalcado a lo largo del artículo, no es necesario ser un genio para conseguir un desempeño notable en la programación, mientras más tiempo se dedica a aprender (utilizando la técnica de estudio que más se adapte a la forma de aprender de cada uno y los medios de preferencia para cada persona) y practicando con diferentes retos y plataformas, mejor se va a desenvolver el ingeniero.

 

Mito: El día a día de un programador es solitario.

 

Realidad: El cine y la televisión han provocado que las personas crean que trabajar en tecnología está ligado a llevar una vida solitaria y apartada de la sociedad (en lo que a nivel profesional/laboral se refiere). Por el contrario, los ingenieros de software no solo trabajan en equipo en su día a día puesto que necesitan estar en contacto con el cliente, con el equipo de trabajo para poder obtener las soluciones a sus problemas, sino que integran una comunidad cercana, fuerte y participativa, por lo cual se entiende que el sector avanza a pasos agigantados gracias a la mentalidad de sus profesionales.

 

Para codificar es muy importante saber comunicarse asertivamente (cualidades que van más allá del pensamiento matemático y el razonamiento lógico), poder pensar soluciones ágiles y a nivel cooperativo, expresar correctamente ideas y opiniones, volviendo fundamental el evento de tener en cuenta la participación de otros individuos cuando se escribe código, se interactúa con el usuario o se elige la arquitectura de la aplicación, habilidades blandas que vuelven casi obligatoria la interacción constante de los ingenieros con otros profesionales.

 

Mito: Si se quiere programar, hay que aprender el lenguaje que esté de moda o el que mejor oferta económica brinde.

 

Realidad: Cada lenguaje tiene su propósito específico y se adapta mejor o no en los diferentes proyectos de una compañía. De todas formas, diferente no es equivalente a ser mejor o peor, por lo tanto, la verdadera pregunta que un ingeniero de software debe realizarse no es: “¿Cuál es el mejor lenguaje de programación?”, sino: “¿Qué lenguaje es el más adecuado para solucionar los requerimientos planteados dentro del proyecto?”.

 

Ahora bien, el pensamiento de “¿qué lenguaje de programación es el mejor remunerado económicamente?” provocará frustración al desarrollador llevándolo nuevamente a la idea de que la programación es difícil, lo primero por aprender es la lógica de la programación y el razonamiento para la resolución de problemas de ese índole, y sólo después de eso, escoger el primer lenguaje de programación el cual debe ir orientado especialmente a los gustos e intereses del profesional, lo anterior ya que a algunos de los profesionales se les da bien el frontend, a otros el backend, el big data, el machine learning, entre muchas más áreas en las que se requiere implementar una solución de software.

 

Mito: Programar es una tarea muy rutinaria.

 

Realidad: Codificar es una tarea que implica mucha creatividad, quizás no en todo el aspecto artístico o asociado a manualidades, pero sí en cuanto a todas las posibles soluciones que pueden generarse hacía una misma necesidad o problema; están asociadas al ingenio del equipo para encontrar la alternativa más conveniente al caso específico. Cada proyecto requiere de un enfoque mental diferente, por lo que la rutina profesional se ve muy reducida y se tiende a llevar una vida dinámica.

 

En segundo lugar, se cree que un ingeniero de software pasa la mayor parte de su tiempo frente a la pantalla y escribiendo código. Por el contrario, el éxito de un proyecto depende de la colaboración de un equipo y del diálogo, corroborando lo explicado previamente en el mito: “El día a día de un programador es solitario”.

 

Para concluir, la programación es una profesión que permite crear desde cero algo que antes no existía. La primera vez que se escribe un programa que logra que el computador ejecute la serie de instrucciones deseadas se vuelve casi un momento mágico. Y las siguientes veces… también.

 

Finalmente es posible observar que, existen muchos mitos asociados tanto a la programación como a los ingenieros de software, no obstante, esperamos que este artículo haya sido de mucha utilidad y mejore a grandes rasgos el panorama respecto a los temas aquí tratados y sea motivación para que se decida incursionar en el mundo de la tecnología aprovechando los beneficios que Bluetab, an IBM Company tiene, ya sea que se busque aprender desarrollo de software o se esté apuntando a una nueva oportunidad laboral.

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

Camilo Andrés Montoya Hernández

Desarrollo de Software

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Starburst: Construyendo un futuro basado en datos.

May 25, 2023
LEER MÁS

Desplegando una plataforma CI/CD escalable con Jenkins y Kubernetes

September 22, 2021
LEER MÁS

Incentives and Business Development in Telecommunications

October 9, 2020
LEER MÁS

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

November 17, 2021
LEER MÁS

Azure Data Studio y Copilot

October 11, 2023
LEER MÁS

Some of the capabilities of Matillion ETL on Google Cloud

July 11, 2022
LEER MÁS

Filed Under: Blog, Tech

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

May 18, 2022 by Bluetab

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

Silvia Juliana Rueda Urrea

Experienced Consultant

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

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

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

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

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

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

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

Gobierno del dato

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

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

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

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

Acciones

En la transformación digital de las organizaciones

Escrito por Silvia Juliana Rueda Urrea

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

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

 

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

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

turned on gray laptop computer

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

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

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

Referencias Bibliográficas

IBM. Gestión de datos. 

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

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

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

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

Silvia Juliana Rueda Urrea

Experienced Consultant

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Databricks on Azure – An Architecture Perspective (part 1)

February 15, 2022
LEER MÁS

$ docker run 2021

February 2, 2021
LEER MÁS

Snowflake Advanced Storage Guide

October 3, 2022
LEER MÁS

Basic AWS Glue concepts

July 22, 2020
LEER MÁS

Mi experiencia en el mundo de Big Data – Parte II

February 4, 2022
LEER MÁS

Big Data and loT

February 10, 2021
LEER MÁS

Filed Under: Blog, Tech

Databricks on Azure – An architecture perspective (part 2)

March 24, 2022 by Bluetab

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

Francisco Linaje

AWS Solutions Architect

Gabriel Gallardo Ruiz

Senior Data Architect

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

Primera entrega (link):

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

Segunda entrega:

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

Glosario

  • All Purpose Compute: Diseñado para entornos colaborativos en los que se recurra de forma simultánea al clúster por parte de Data Engineers y Data Scientist
  • Azure Data Lake: Permite almacenar múltiples formatos de datos en un mismo lugar para su explotación y análisis, actualmente Azure dispone la versión Gen2 .
  • Azure Key Vault: Servicio administrado de Azure que permite el almacenamiento seguro de secretos.
  • Azure Virtual Network (VNET): Red virtual aislada lógicamente en Azure.
  • DBFS (Databricks File Systen): Sistema de archivos de Databricks que se monta sobre los sistema de archivos distribuido de los Cloud Providers.
  • Data Lake: Paradigma de almacenamiento distribuido de datos provenientes de multitud de fuentes y formatos, estructurados, semi estructurados y sin estructurar.
  • Identity Provider (IdP): Entidad que mantiene la información de identidad de los individuos dentro de una organización.
  • Infraestructura como código o IaC: gestión y aprovisionamiento de la infraestructura a partir de código declarativo.
  • Jobs Compute: Enfocado a procesos orquestados mediante pipelines gestionados por data engineers que puedan conllevar autoescalado en ciertas tareas
  • Jobs Light Compute: Diseñado para procesos cuya consecución no sea crítica y no conlleve una carga computacional muy elevada
  • Network Security Group o NSG: Especifican las reglas que regulan el tráfico de entrada y salida de la red y los clusters en Azure
  • Private Link: Permite el acceso privado (IP privada) a Azure PaaS a través de tu VNET, de la misma forma que los service endpoints el tráfico se enruta a través del backbone de Azure.
  • SQL Compute: Cluster reservados a queries para la visualización de la información almacenada en el Data Lake
  • Secret scope: Colección de secretos identificados por un nombre.
  • Secure Cluster Connectivity (SCC):  Comunicación a través de túnel inverso SSH entre Control Plane y cluster. Permite no tener puertos abiertos ni IPs públicas en las instancias.
  • Security Assertion Markup Language (SAML): Estándar abierto utilizado para la autenticación. Basado en XML, las aplicaciones web utilizan SAML para transferir datos de autenticación entre dos entidades, el Identity Provider y el servicio en cuestión.
  • Service endpoints: Componente de red que permite conectar una VNET con los diferentes servicios dentro de Azure a través de la propia red de Azure.
  • TLS/ TLS1.2 (Transport Layer Security): es un protocolo de cifrado y comunicación que proporciona comunicaciones seguras por una red, comúnmente Internet.
  • Workspace: Entorno compartido para acceder a todos los activos de Databricks. En este se organizan los diferentes objetos (notebooks, librerias, etc…) en carpetas y se administran los accesos a recursos computacionales como clusters y jobs.

Disaster Recovery

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

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

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

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

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

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

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


Conceptos DR

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

Recovery Point Objective (RPO)

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

Recovery Time Objective (RTO)

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

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

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

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

Tipos de región y redundancia

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

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

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

Region primaria

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

Region primaria y secundaria

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

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

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

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

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


Tipos de despliegue

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

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

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

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

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

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

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

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


Workflow típico de recuperación

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

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

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

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

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


Disaster Recovery en Azure Databricks

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

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

Estrategia y herramientas en la sincronización.

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

Existen dos principales estrategias:

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

Herramientas

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

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

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

Implementación

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

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

Escalabilidad

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

Auto Escalado de workers

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

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

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

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

Caracteristicas:

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


Pools

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

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

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


Auto escalado del almacenamiento

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

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

Seguridad

Encriptación de datos databricks

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


En transito

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

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

 
En reposo

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

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

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

{"enable_local_disk_encryption": true} 

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

Diagrama de Arquitectura Databricks (fuente: Azure)

Logging

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

 

Cluster logs

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

Captura Workspace - Sección Clusters

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

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

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

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

Captura Workspace - Ganglia Metrics

Registro de diagnóstico en Azure Databricks 

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

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

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

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

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

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

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

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

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

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

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

Tabla Esquema Registro Salida (fuente: Azure)

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

Referencias

[1] Databricks Terraform Provider. [link]

[2] Databricks Workspace Migration Tools. [link]

[3] Databricks Sync. [link]

[4] Databricks Disaster Recovery [link]

[5] Cifrado entre nodos de trabajo[link]

[6] Optimized AutoScaling [link]

[7] Spark Security [link]

[8] Azure encriptación discos [link]

[9] Registro de diagnostico [link]

Navegación

Glosario

Disaster Recovery

Escalabilidad

Seguridad

Logging

Referencias

Autores

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

Francisco Linaje

AWS Solutions Architect

Gabriel Gallardo Ruiz

Senior Data Architect

SOLUTIONS, WE ARE EXPERTS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

You may be interested in

Bank Fraud detection with automatic learning II

September 17, 2020
READ MORE

Introduction to HashiCorp products

August 25, 2020
READ MORE

CDKTF: Otro paso en el viaje del DevOps, introducción y beneficios.

May 9, 2023
READ MORE

IBM to acquire Bluetab

July 9, 2021
READ MORE

We have a Plan B

September 17, 2020
READ MORE

5 common errors in Redshift

December 15, 2020
READ MORE

Filed Under: Blog, Blog, Outstanding, Practices, Tech

  • « Go to Previous Page
  • Page 1
  • Page 2
  • Page 3
  • Page 4
  • Page 5
  • Page 6
  • Page 7
  • Go to Next Page »

Footer

LegalPrivacy Cookies policy

Patron

Sponsor

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