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

Bluetab

an IBM Company

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

Bluetab

Javi:Prueba

marzo 7, 2024 by Bluetab

Deygersn Méndez
DATA

En el dinámico mundo empresarial actual; la tecnología es la clave para la innovación y el éxito. Por ello, si estás buscando una forma fresca y emocionante de potenciar las capacidades de análisis de datos de tu organización, estás en el lugar correcto.

En el siguiente artículo te contaremos desde bluetab, nuestra experiencia sobre Microsoft Fabric, la nueva solución de análisis que nos ofrece este big player tecnológico. Con ella podemos abarcar todo el ciclo de vida del dato, es decir, desde el movimiento de datos pudiendo crear pipelines para la ingesta, hasta la transformación y carga de los mismos. A su vez, el análisis en tiempo real, la inteligencia empresarial, la gobernanza y el cumplimiento, todo ello en un mismo espacio de trabajo; además de contar con herramientas de inteligencia artificial integradas, que nos ayudan a generar soluciones basadas en información en un menor tiempo.

¿Qué es Microsoft Fabric?

La documentación oficial de Microsoft describe el servicio como “no es solo otra solución tecnológica, sino una plataforma integral diseñada para simplificar y optimizar sus procesos empresariales mediante una infraestructura moderna, la cual se presenta, como una solución altamente integrada y fácil de usar”. 

Microsoft Fabric está basado, en un modelo de Software como Servicio (SaaS) que lleva la simplicidad y la integración a un siguiente nivel. 

A la vez, ofrece un conjunto completo de servicios, que incluye un lago de datos unificado denominado OneLake, que permite mantener los datos en su lugar mientras utiliza sus herramientas de análisis preferidas, e incorpora servicios nuevos y existentes como Power BI, Azure Synapse Analytics y Azure Data Factory en un entorno unificado.

Es importante mencionar que está integración nos ofrece grandes ventajas, como, por ejemplo:

  • Amplia gama de capacidades integradas: Esto quiere decir que proporciona una suite completa de capacidades de análisis profundamente integradas, abarcando desde la ingeniería de datos, la ciencia de datos y el análisis en tiempo real.
  • Toma decisiones informadas: Gracias a la analítica avanzada de Microsoft Fabric, podrá tomar decisiones basadas en datos sólidos, impulsando así su estrategia empresarial.
{
  "nombre":"Jonh Doe",
  "profesion":"Programador",
  "edad":25,
  "lenguajes":["PHP","Javascript","Dart"],
  "disponibilidadParaViajar":true,
  "rangoProfesional": {
      "aniosDeExperiencia": 12,
      "nivel": "Senior"
  }
}
Tabla de contenidos
  1. ¿Qué es Microsoft Fabric?

Publicado en: Sin categorizar

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

marzo 5, 2024 by Bluetab

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

Rubén Villa

Big Data & Cloud Architect

Jon Garaialde

Cloud Data Solutions Engineer/Architect

Alfonso Jerez

Analytics Engineer | GCP | AWS | Python Dev | Azure | Databricks | Spark

Alberto Jaén

Cloud Engineer | 3x AWS Certified | 2x HashiCorp Certified | GitHub: ajaen4

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

Los contenidos de cada artículo son los siguientes:

Primera entrega:

  • Introducción
  • Data Lakehouse & Delta
  • Conceptos.
  • Arquitectura.
  • Planes y tipos de carga de trabajo.
  • Networking.

Esta entrega:

  • Seguridad
  • Persistencia
  • Billing

El primer artículo puede visitarse en el siguiente enlace

Glosario

  • Control Plane: aloja los servicios back-end de Databricks necesarios para disponibilizar la interfaz gráfica, APIs REST para la gestión de la cuenta y workspaces. Dichos servicios están desplegados en una cuenta AWS propiedad de Databricks. Ver primer artículo para más información.
  • Credentials Passthrough: mecanismo utilizado por Databricks para la gestión de accesos a las diferentes fuentes de datos. Ver primer artículo para más información.
  • Cross-account role: rol que se disponibiliza para que Databricks pueda asumirlo desde su cuenta en AWS. Se utiliza para desplegar la infraestructura y para poder asumir otros roles dentro de AWS. Ver primer artículo para más información.
  • Compute Plane: aloja toda la infraestructura necesaria para el procesamiento de datos: persistencia, clusters, servicios de logging, librerías spark, etc. El Data Plane se despliega en la cuenta AWS del cliente. Ver primer artículo para más información.
  • Data role: roles con permisos de acceso/escritura a los buckets de S3 que serán asumidos por el cluster a través del meta instance profile. Ver primer artículo para más información. Ver primer artículo para más información.
  • DBFS: sistema de almacenamiento distribuido disponible para los clusters. Es una abstracción sobre un sistema de almacenamiento de objetos, en este caso S3, y permite el acceso a ficheros y carpetas sin necesidad de utilizar URLs. Ver primer artículo para más información.
  • IAM Policies: políticas a través de las cuales se definen los permisos de acceso en AWS.
  • Key Management Service (KMS): servicio de AWS que permite crear y administrar claves de encriptación.
  • Pipelines: series de procesos en los que se ejecuta un conjunto de datos.
  • Prepared: datos procesados desde raw que se utilizaran como base para poder crear los datos Trusted.
  • Init Script (User Data Script): las instancias de EC2 lanzadas desde los clúster de Databricks permiten incluir un script con el cual instalar actualizaciones de software, descargar librerías/módulos, entre otros, en el momento que esta se arranca
  • Mount: Para evitar tener que cargar internamente los datos que se requieren para el proceso, Databricks posibilita la sincronización con fuentes externas, como S3, para facilitar la interacción con los distintos archivos (simula que estos se encuentran en local haciendo así más simple los relatives paths) pero realmente estos se encuentran almacenados en la fuente de almacenamiento externa correspondiente.
  • Personal Access (PAT) Token: token para la autenticación personal que sustituye la autenticación por usuario y contraseña.
  • Raw: datos ingestados sin procesar.
  • Root Bucket: directorio de raíz para el workspace (DBFS root). Utilizado para alojar cluster logs, revisiones de notebooks y librerías. Ver primer artículo para más información.
  • Secret Scope: entorno en el que almacenar información sensible mediante pares clave valor (nombre – secreto)
  • Trusted: datos preparados para su visualización y estudio por parte de los diferentes grupos de interés.
  • Workflows: secuencia de tareas.
  •  

Seguridad de la información

Visita Data security and encryption en esté enlace

Databricks presenta configuraciones de seguridad de datos para proteger la información que está en tránsito o en reposo. En la documentación se ofrece una descripción general de las características de encriptación disponibles. Dichas características incluyen claves gestionadas por el cliente para encriptación, encriptación del tráfico entre nodos de clúster, encriptación de consultas y resultados, y encriptación de buckets S3 en reposo.

Hay que destacar que dentro del soporte para claves gestionadas por el cliente, que permite la protección y control de acceso a datos en el control plane de Databricks, como archivos fuente de notebooks, resultados de notebooks, secretos, consultas SQL y tokens de acceso personal. También se puede configurar claves para encriptar datos en el bucket S3 raíz y volúmenes EBS del clúster.

Otra posibilidad que ofrece Databricks es la de utilizar claves de AWS KMS para encriptar consultas de SQL y su historial almacenado en el control plane. 

Por último, también facilita la encriptación del tráfico entre nodos de clúster y la administración de configuraciones de seguridad del workspace por parte de los administradores. 

En este articulo hablaremos sobre dos de las opciones: customer-managed keys y el encriptado del trafico entre nodos workers del clúster


Customer-managed keys

Visita Customer-managed keys en esté enlace

Los administradores de cuentas de Databricks pueden configurar claves gestionadas para la encriptación. Se destacan dos casos de uso para agregar una clave gestionada por el cliente: datos de servicios gestionados en el control plane de Databricks (como notebooks, secretos y consultas SQL) y almacenamiento del workspaces (buckets S3 raíz y volúmenes EBS).

Hay que destacar que las claves gestionadas para volúmenes EBS no se aplican a recursos de cómputo serverless, ya que estos discos son efímeros y están vinculados al ciclo de vida de la carga de trabajo serverless. En la documentación de Databricks existen comparaciones de los casos de uso de claves gestionadas por el cliente y se menciona que esta función está disponible en la subcripción Enterprise.

Respecto al concepto de configuraciones de claves de encriptación, estos son objetos a nivel de cuenta que hacen referencia a las claves en la nube del usuario. Los administradores de cuentas pueden crear estas configuraciones en la consola de la cuenta y asociarlas con uno o más workspaces. El proceso de configuración implica la creación o selección de una clave simétrica en AWS KMS y la posterior edición de la política de la clave para permitir a Databricks realizar operaciones de encriptación y desencriptación. Se pueden consultar en la documentación las instrucciones detalladas junto con ejemplos de políticas JSON necesarias para ambas configuraciones de uso (servicios gestionados y almacenamiento workspaces).

Por último, existe la posibilidad de agregar una política de acceso a un rol IAM de cuenta cruzada (cross-account) en AWS, en caso de que la clave KMS esté en una cuenta diferente. 


Encriptación en tránsito

Para esta parte, es muy importante destacar la importancia del script de inicio (init script) 

Encriptación en tránsito

  • Encrypt traffic between cluster worker nodes
  • Example init script
  • Use cluster-scoped init scripts

en Databricks, el cual, entre otras cosas, sirve para configurar la encriptación entre nodos de workers en un clúster de Spark. Este script de inicio permite obtener un secreto de encriptación compartido a partir del scope de claves almacenado en DBFS. Si se rota el secreto actualizando el archivo del almacén de claves en DBFS, se debe reiniciar todos los clústeres en ejecución para evitar problemas de autenticación entre los workers de Spark y el driver. Señalar que, dado que el secreto compartido el cual se almacena en DBFS, cualquier usuario con acceso a DBFS puede recuperar el secreto mediante un notebook.

Se pueden utilizar instancias de AWS específicas que cifran automáticamente los datos entre los nodos de trabajadores sin necesidad de configuración adicional, pero utilizar el init-script proporciona un nivel añadido de seguridad para los datos en tránsito o un control total sobre el tipo de encriptación que se quiere aplicar.

El script será el encargado de obtener el secreto del almacén de claves y su contraseña, así como configurar los parámetros necesarios de Spark para la encriptación. Lanzado como Bash, realizará estas tareas y en caso de ser necesario, realizará una espera hasta que el archivo de almacén de claves esté disponible en DBFS y la derivación del secreto de encriptación compartido a partir del hash del archivo de almacén de claves. Una vez completada la inicialización de los nodos del driver y de los workers, todo el tráfico entre estos nodos se cifrará utilizando el archivo de almacén de claves.

Este tipo de características están dentro del plan Enterprise

Persistencia y metastores

Databricks admite dos tipos principales de almacenamiento persistente: DBFS (Databricks File System) y S3 (Simple Storage Service de AWS).

DBFS

DBFS es un sistema de archivos distribuido integrado directamente con Databricks, almacenando datos en el almacenamiento local del clúster y de los workspaces. Proporciona una interfaz de archivo similar a HDFS estándar y facilita la colaboración al ofrecer un lugar centralizado para almacenar y acceder a datos.

S3

Por otro lado, Databricks también puede conectarse directamente a datos almacenados en Amazon S3. Los datos en S3 son independientes de los clústeres y de los workspaces y pueden ser accedidos por varios clústeres y usuarios. S3 destaca por su escalabilidad, durabilidad y la capacidad de separar almacenamiento y cómputo, lo que facilita el acceso a datos incluso desde múltiples entornos.

En cuanto a los metastores, Databricks en AWS admite varios tipos, incluyendo:

Metastore de Hive

Databricks puede integrarse con el metastore de Hive, permitiendo a los usuarios utilizar tablas y esquemas definidos en Hive.

Metastore Glue en Data Plane

Databricks también tiene la posibilidad de alojar el metastore en el propio compute plane con Glue.

Estos metastores permiten a los usuarios gestionar y consultar metadatos de tablas, facilitando la gestión de esquemas y la integración con otros servicios de datos. La elección del metastore dependerá de los requisitos específicos del flujo de trabajo y las preferencias de gestión de metadatos en el entorno de Databricks en AWS.

Unity Catalog 

Sin duda alguna, una nueva funcionalidad de Databricks que permite unificar estos metastores previos y amplifica las distintas opciones y herramientas que ofrece cada uno de ellos es el Unity Catalog

Unity Catalog proporciona capacidades centralizadas de control de acceso, auditoría, linaje y descubrimiento de datos.

Características clave de Unity Catalog

  • Administra políticas de acceso a datos en un solo lugar que se aplican a todos los workspaces que se definan.
  • Basado en ANSI SQL, permite a los administradores otorgar estos permisos mediante una sintaxis SQL.
  • Captura automáticamente registros de auditoría a nivel de usuario.
  • Permite etiquetar tablas y esquemas, proporcionando una interfaz de búsqueda eficaz para buscar información.

Databricks recomienda configurar todo el acceso al almacenamiento de objetos en la nube mediante Unity Catalog para gestionar relaciones entre datos en Databricks y almacenamiento en la nube.

Modelo de objetos de Unity Catalog

  • Metastore: Contenedor de metadatos de nivel superior, expone un espacio de nombres de tres niveles (catálogo.esquema.tabla).
  • Catálogo: Organiza activos de datos, primera capa en la jerarquía.
  • Esquema: Segunda capa, organiza tablas y vistas.
  • Tablas, vistas y volúmenes: Niveles más bajos, con volúmenes que proporcionan acceso no tabular a datos.
  • Modelos: No son activos de datos, registran modelos de aprendizaje automático.

Billing

A continuación, se detalla la función de Databricks en AWS que permite la entrega y acceso a registros de uso facturables. Los administradores de cuenta pueden configurar la entrega diaria de registros CSV a un bucket S3 de AWS. Cada archivo CSV proporciona datos históricos sobre el uso de clústeres en Databricks, clasificándolos por criterios como ID de clúster, SKU de facturación, creador del clúster y etiquetas. La entrega incluye registros tanto para workspaces en ejecución como para aquellos cancelados, garantizando la representación adecuada del último día de dicho workspace (debe haber estado operativo al menos 24 h).

La configuración implica la creación de un bucket S3 y un rol IAM en AWS, junto con la llamada a la API de Databricks para establecer objetos de configuración de almacenamiento y credenciales. La opción de soporte de cuentas cruzadas permite la entrega a cuentas AWS diferentes mediante una política de bucket S3. Los archivos CSV se encuentran en <bucket-name>/<prefix>/billable-usage/csv/, es recomendable revisar las bestpractices de seguridad de S3.

La API de la cuenta permite configuraciones compartidas para todos los workspaces o configuraciones separadas para cada espacio o grupos. La entrega de estos CSV permite que los owners de cuentas descarguen directamente los registros. La propiedad del objeto S3 se autoconfigura como «Bucket owner preferred» para admitir la propiedad de los objetos recién creados.

Se destaca un límite en la cantidad de configuraciones de entrega de registros y se requiere ser administrador de cuenta, además de proporcionar el ID de cuenta. Especial cuidado con las dificultades de acceso si se configura la propiedad del objeto S3 como «Object writer» en lugar de «Bucket owner preferred».

Campos paramétricos de configuración Description
workspaceId
Workspace Id
timestamp
Established frequency (hourly, daily,…)
clusterId
Cluster Id
clusterName
Name assigned to the Cluster
clusterNodeType
Type of node assigned
clusterOwnerUserId
Cluster creator user id
clusterCustomTags
Customizable cluster information labels
sku
Package assigned by Databricks in relation to the cluster characteristics.
dbus
DBUs consumption per machine hour
machineHours
Cluster deployment machine hours
clusterOwnerUserName
Username of the cluster creator
tags
Customizable cluster information labels

Referencias

  1. https://bluetab.net/es/databricks-sobre-aws-una-perspectiva-de-arquitectura-parte-1/ 
  2. https://docs.databricks.com/en/security/keys/index.html | 2024-02-06
  3. https://docs.databricks.com/en/security/keys/customer-managed-keys.html |  2024-02-06
  4. https://docs.databricks.com/en/security/keys/encrypt-otw.html | 2024-02-24
  5. https://docs.databricks.com/en/security/keys/encrypt-otw.html#example-init-script |  2024-02-24
  6. https://docs.databricks.com/en/init-scripts/cluster-scoped.html |  2023-12-05
  7. https://docs.databricks.com/en/data-governance/unity-catalog/index.html | 2024-02-26
 

Navegación

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

Rubén Villa

Big Data & Cloud Architect

Alfonso Jerez

Analytics Engineer | GCP | AWS | Python Dev | Azure | Databricks | Spark

Jon Garaialde

Cloud Data Solutions Engineer/Architect

Alberto Jaén

Cloud Engineer | 3x AWS Certified | 2x HashiCorp Certified | GitHub: ajaen4

SOLUCIONES, SOMOS EXPERTOS
DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS
Te puede interesar

Oscar Hernández, nuevo CEO de Bluetab LATAM

mayo 16, 2024
LEER MÁS

Desplegando una plataforma CI/CD escalable con Jenkins y Kubernetes

septiembre 22, 2021
LEER MÁS

Hashicorp Boundary

diciembre 3, 2020
LEER MÁS

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

abril 7, 2021
LEER MÁS

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

junio 4, 2024
LEER MÁS

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

febrero 23, 2023
LEER MÁS

Publicado en: Blog, Practices, Tech

Databricks sobre AWS – Una perspectiva de arquitectura (parte 1)

marzo 5, 2024 by Bluetab

Databricks sobre AWS – Una perspectiva de arquitectura (parte 1)

Jon Garaialde

Cloud Data Solutions Engineer/Architect

Rubén Villa

Big Data & Cloud Architect

Alfonso Jerez

Analytics Engineer | GCP | AWS | Python Dev | Azure | Databricks | Spark

Alberto Jaén

Cloud Engineer | 3x AWS Certified | 2x HashiCorp Certified | GitHub: ajaen4

Databricks se ha convertido en un producto de referencia en el ámbito de plataformas de análisis unificadas para crear, implementar, compartir y mantener soluciones de datos, proporcionando un entorno para los roles de ingeniería y analítica. Debido a que no todas las organizaciones tienen los mismos tipos de carga de trabajo, Databricks ha diseñado diferentes planes que permiten adaptarse a las distintas necesidades, y esto tiene un impacto directo en el diseño de la arquitectura de la plataforma. 

Con esta serie de artículos, se pretende abordar la integración de Databricks en entornos AWS, analizando las alternativas ofrecidas por el producto respecto al diseño de arquitectura, además se abordarán las bondades de la plataforma de Databricks por sí misma. Debido a la extensión de los contenidos, se ha considerado conveniente dividirlos en tres entregas:

Primera entrega:

  • Introducción.
  • Data Lakehouse & Delta.
  • Conceptos.
  • Arquitectura.
  • Planes y tipos de carga de trabajo.
  • Networking.

Segunda entrega:

  • Seguridad.
  • Persistencia.
  • Billing.

Introducción

Databricks se crea con la idea de poder desarrollar un entorno único en el que distintos perfiles (como Data Engineers, Data Scientists y Data Analysts) puedan trabajar de forma colaborativa sin la necesidad de contar con proveedores de servicios externos que ofrezcan las distintas funcionalidades que cada uno de estos necesita en su día a día.

El área de trabajo de Databricks proporciona una interfaz unificada y herramientas para la mayoría de las tareas de datos, entre las que se incluyen:

  • Programación y administración de procesamiento de datos.
  • Generación de paneles y visualizaciones.
  • Administración de la seguridad, la gobernanza, la alta disponibilidad y la recuperación ante desastres.
  • Detección, anotación y exploración de datos.
  • Modelado, seguimiento y servicio de modelos de Machine Learning (ML).
  • Soluciones de IA generativa.


El nacimiento de Databricks se lleva a cabo gracias a la colaboración de los fundadores de Spark, publicando Delta Lake y MLFlow como productos de Databricks siguiendo la filosofía open-source.

Colaboración Spark, Delta Lake y MLFlow

Este nuevo entorno colaborativo tuvo un gran impacto en su presentación debido a las novedades que ofrecía al integrarse las distintas tecnologías:

  • Spark es un framework de programación distribuida que presenta como una de sus funcionalidades la capacidad de realizar consultas sobre los Delta Lakes en unos ratios de coste/tiempo superiores a los de la competencia, consiguiendo optimizar los procesos de análisis.
  • Delta Lake se presenta como soporte de almacenamiento de Spark. Aúna las principales ventajas de los Data WareHouse y Data Lakes al posibilitar la carga de información estructurada y no estructurada mediante una versión mejorada de Parquet que permite soportar transacciones ACID asegurando así la integridad de la información en los procesos ETL llevados a cabo por Spark.
  • MLFlow es una plataforma para la administración del ciclo de vida de Machine Learning que incluye: experimentación, reusabilidad, implementación y registro de modelos centralizados.

Data Lakehouse & Delta

Un Data Lakehouse es un sistema de gestión de datos que combina los beneficios de los Data Lakes y los Data Warehouses.

Diagrama de un Data Lakehouse (fuente: Databricks)

Un Data Lakehouse proporciona capacidades de almacenamiento y procesamiento escalables para organizaciones modernas que desean evitar sistemas aislados para procesar diferentes cargas de trabajo, como el aprendizaje automático (ML) y la inteligencia empresarial (BI). Un Data Lakehouse puede ayudar a establecer una única fuente de verdad, eliminar costes redundantes y garantizar la actualización de los datos.

Los Data Lakehouses utilizan un patrón de diseño de datos que mejora, enriquece y refina gradualmente los datos a medida que avanzan a través de diferentes capas. Este patrón se conoce frecuentemente como arquitectura de medallón.

Databricks se basa en Apache Spark. Apache Spark habilita un motor enormemente escalable que se ejecuta en recursos informáticos desacoplados del almacenamiento.

El Data Lakehouse de Databricks utiliza dos tecnologías clave adicionales:

  • Delta Lake: capa de almacenamiento optimizada que admite transacciones ACID y aplicación de esquemas.
  • Unity Catalog: solución de gobernanza unificada y detallada para datos e inteligencia artificial.

Patrón de diseño de datos

  • Ingesta de datos

En la capa de ingesta, los datos llegan desde diversas fuentes en lotes o en streaming, en una amplia gama de formatos. Esta primera etapa proporciona un punto de entrada para los datos en su forma sin procesar. Al convertir estos archivos en tablas Delta, se pueden aprovechar las capacidades de aplicación de esquemas de Delta Lake para identificar y manejar datos faltantes o inesperados.

Para gestionar y registrar estas tablas de manera eficiente según los requisitos de gobierno de datos y los niveles de seguridad necesarios, se puede utilizar Unity Catalog. Este catálogo permite realizar un seguimiento del linaje de los datos a medida que se transforman y refinan, al mismo tiempo que facilita la aplicación de un modelo unificado de gobernanza para mantener la privacidad y la seguridad de los datos confidenciales.

  • Procesamiento, curación e integración de datos

Después de verificar los datos, se procede a la selección y refinamiento. En esta etapa, los científicos de datos y los profesionales de aprendizaje automático suelen trabajar con los datos para combinarlos, crear nuevas características y completar la limpieza. Una vez que los datos estén completamente limpios, se pueden integrar y reorganizar en tablas diseñadas para satisfacer las necesidades comerciales específicas.

El enfoque de esquema en la escritura, junto con las capacidades de evolución del esquema de Delta, permite realizar cambios en esta capa sin necesidad de reescribir la lógica subyacente que proporciona datos a los usuarios finales.

  • Servicio de datos

La última capa proporciona datos limpios y enriquecidos a los usuarios finales. Las tablas finales deben estar diseñadas para satisfacer todas las necesidades de uso. Gracias a un modelo de gobernanza unificado, se puede rastrear el linaje de los datos hasta su fuente de verdad única. Los diseños de datos optimizados para diversas tareas permiten a los usuarios acceder a los datos para aplicaciones de aprendizaje automático, ingeniería de datos, inteligencia empresarial e informes.

Características

  • El concepto de Data Lakehouse se basa en aprovechar un Data Lake para almacenar una amplia variedad de datos en sistemas de almacenamiento de bajo coste, como Amazon S3 en este caso. Esto se complementa con la implementación de sistemas que aseguren la calidad y fiabilidad de los datos almacenados, garantizando la coherencia incluso cuando se accede a ellos desde múltiples fuentes simultáneamente.
  • Se emplean catálogos y esquemas para proporcionar mecanismos de gobernanza y auditoría, permitiendo operaciones de manipulación de datos (DML) mediante diversos lenguajes, y almacenando historiales de cambios y snapshots de datos. Además, se aplican controles de acceso basados en roles para garantizar la seguridad.
  • Se emplean técnicas de optimización de rendimiento y escalabilidad para garantizar un funcionamiento eficiente del sistema.
  • Permite el uso de datos no estructurados y no-SQL, además de facilitar el intercambio de información entre plataformas utilizando formatos de código abierto como Parquet y ORC, y ofreciendo APIs para un acceso eficiente a los datos.
  • Proporciona soporte para streaming de extremo a extremo, eliminando la necesidad de sistemas dedicados para aplicaciones en tiempo real. Esto se complementa con capacidades de procesamiento masivo en paralelo para manejar diversas cargas de trabajo y análisis de manera eficiente.

Conceptos: Account & Workspaces

En Databricks, un workspace es una implementación de Databricks en la nube que funciona como un entorno para que su equipo acceda a los activos de Databricks. Se puede optar por tener varios espacios de trabajo o solo uno, según las necesidades.

Una cuenta de Databricks representa una única entidad que puede incluir varias áreas de trabajo. Las cuentas habilitadas para Unity Catalog se pueden usar para administrar usuarios y su acceso a los datos de forma centralizada en todos los workspaces de la cuenta. La facturación y el soporte también se manejan a nivel de cuenta.


Billing: Databricks units (DBUs)

Las facturas de Databricks se basan en unidades de Databricks (DBU), unidades de capacidad de procesamiento por hora según el tipo de instancia de VM.


Authentication & Authorization

Conceptos relacionados con la administración de identidades de Databricks y su acceso a los activos de Databricks.

  • User: un individuo único que tiene acceso al sistema. Las identidades de los usuarios están representadas por direcciones de correo electrónico.
  • Service Principal: identidad de servicio para usar con jobs, herramientas automatizadas y sistemas como scripts, aplicaciones y plataformas CI/CD. Las entidades de servicio están representadas por un ID de aplicación.
  • Group: colección de identidades. Los grupos simplifican la gestión de identidades, facilitando la asignación de acceso a workspaces, datos y otros objetos. Todas las identidades de Databricks se pueden asignar como miembros de grupos.
  • Access control list (ACL): lista de permisos asociados al workspace, cluster, job, tabla o experimento. Una ACL especifica a qué usuarios o procesos del sistema se les concede acceso a los objetos, así como qué operaciones están permitidas en los activos. Cada entrada en una ACL típica especifica un tema y una operación.
  • Personal access token: cadena opaca para autenticarse en la API REST, almacenes SQL, etc.
  • UI: interfaz de usuario de Databricks, es una interfaz gráfica para interactuar con características, como carpetas del workspace y sus objetos contenidos, objetos de datos y recursos computacionales.


Data science & Engineering

Las herramientas de ingeniería y ciencia de datos ayudan a la colaboración entre científicos de datos, ingenieros de datos y analistas de datos.

  • Workspace: entorno para acceder a todos los activos de Databricks, organiza objetos (Notebooks, bibliotecas, paneles y experimentos) en carpetas y proporciona acceso a objetos de datos y recursos computacionales.
  • Notebook: interfaz basada en web para crear flujos de trabajo de ciencia de datos y aprendizaje automático que pueden contener comandos ejecutables, visualizaciones y texto narrativo.
  • Dashboard: interfaz que proporciona acceso organizado a visualizaciones.
  • Library: paquete de código disponible que se ejecuta en el cluster. Databricks incluye muchas bibliotecas y se pueden agregar las propias.
  • Repo: carpeta cuyos contenidos se versionan juntos sincronizándolos con un repositorio Git remoto. Databricks Repos se integra con Git para proporcionar control de código fuente y de versiones para los proyectos.
  • Experiment: colección de ejecuciones de MLflow para entrenar un modelo de aprendizaje automático.


Databricks interfaces

Describe las interfaces que admite Databricks, además de la interfaz de usuario, para acceder a sus activos: API y línea de comandos (CLI).

  • REST API: Databricks proporciona documentación API para el workspace y la cuenta.
  • CLI: proyecto de código abierto alojado en GitHub. La CLI se basa en la API REST de Databricks.


Data management

Describe los objetos que contienen los datos sobre los que se realiza el análisis y alimenta los algoritmos de aprendizaje automático.

  • Databricks File System (DBFS): capa de abstracción del sistema de archivos sobre un almacén de blobs. Contiene directorios, que pueden contener archivos (archivos de datos, bibliotecas e imágenes) y otros directorios.
  • Database: colección de objetos de datos, como tablas o vistas y funciones, que está organizada para que se pueda acceder a ella, administrarla y actualizarla fácilmente.
  • Table: representación de datos estructurados.
  • Delta table: de forma predeterminada, todas las tablas creadas en Databricks son tablas delta. Las tablas delta se basan en el proyecto de código abierto Delta Lake, un marco para el almacenamiento de tablas ACID de alto rendimiento en almacenes de objetos en la nube. Una tabla Delta almacena datos como un directorio de archivos en el almacenamiento de objetos en la nube y registra los metadatos de la tabla en el metastore dentro de un catálogo y un esquema.
  • Metastore: componente que almacena toda la información de la estructura de las distintas tablas y particiones en el almacén de datos, incluida la información de columnas y tipos de columnas, los serializadores y deserializadores necesarios para leer y escribir datos, y los archivos correspondientes donde se almacenan los datos. Cada implementación de Databricks tiene un metastore central de Hive al que pueden acceder todos los clusters para conservar los metadatos de la tabla.
  • Visualization: representación gráfica del resultado de ejecutar una consulta.


Computation management

Describe los conceptos para la ejecución de cálculos en Databricks.

  • Cluster: conjunto de configuraciones y recursos informáticos en los que se ejecutan Notebooks y jobs. Hay dos tipos de clusters: all-purpose y job.
    • Un cluster all-purpose se crea mediante la interfaz de usuario, la CLI o la API REST, pudiendo finalizar y reiniciar manualmente este tipo de clusters.
    • Un cluster job se crea cuando se ejecuta un job en un nuevo cluster job y finaliza cuando se completa el job. Los jobs cluster no pueden reiniciar.
  • Pool: conjunto de instancias y listas para usar que reducen los tiempos de inicio y escalado automático del cluster. Cuando se adjunta a un pool, un cluster asigna los nodos driver y workers al pool. Si el pool no tiene suficientes recursos para atender la solicitud del cluster, el pool se expande asignando nuevas instancias del proveedor de instancias. Cuando se finaliza un cluster adjunto, las instancias que utilizó se devuelven al pool y pueden ser reutilizadas por un cluster diferente.
  • Databricks runtime: conjunto de componentes principales que se ejecutan en los clusters administrados por Databricks. Se disponen de los siguientes runtimes:
    • Databricks runtime incluye Apache Spark, además agrega una serie de componentes y actualizaciones que mejoran sustancialmente la usabilidad, el rendimiento y la seguridad del análisis.
    • Databricks runtime para Machine Learning se basa en Databricks runtime y proporciona una infraestructura de aprendizaje automático prediseñada que se integra con todas las capacidades del workspace de Databricks. Contiene varias bibliotecas populares, incluidas TensorFlow, Keras, PyTorch y XGBoost.
  • Workflows: marcos para desarrollar y ejecutar canales de procesamiento de datos:
    • Jobs: mecanismo no interactivo para ejecutar un Notebook o una biblioteca, ya sea de forma inmediata o programada.
    • Delta Live Tables: marco para crear canales de procesamiento de datos confiables, mantenibles y comprobables.
  • Workload: Databricks identifica dos tipos de cargas de trabajo sujetas a diferentes esquemas de precios:
    • Ingeniería de datos (job): carga de trabajo (automatizada) que se ejecuta en un cluster job que Databricks crea para cada carga de trabajo.
    • Análisis de datos (all-purpose): carga de trabajo (interactiva) que se ejecuta en un cluster all-purpose. Las cargas de trabajo interactivas normalmente ejecutan comandos dentro de un Notebooks de Databricks. En cualquier caso, ejecutar un job en un cluster all-purpose existente también se trata como una carga de trabajo interactiva.
  • Execution context: estado de un entorno de lectura, evaluación e impresión (REPL) para cada lenguaje de programación admitido. Los lenguajes admitidos son Python, R, Scala y SQL.


Machine learning

Entorno integrado de extremo a extremo que incorpora servicios administrados para el seguimiento de experimentos, entrenamiento de modelos, desarrollo y administración de funciones, y servicio de funciones y modelos.

  • Experiments: principal unidad de organización para el seguimiento del desarrollo de modelos de aprendizaje automático. Los experimentos organizan, muestran y controlan el acceso a ejecuciones registradas individuales de código de entrenamiento de modelos.
  • Feature Store: repositorio centralizado de funciones. Permite compartir y descubrir funciones en toda su organización y también garantiza que se utilice el mismo código de cálculo de funciones para el entrenamiento y la inferencia del modelo.
  • Models & model registry: modelo de aprendizaje automático o aprendizaje profundo que se ha registrado en el registro de modelos.


SQL

  • SQL REST API: interfaz que permite automatizar tareas en objetos SQL.
  • Dashboard: representación de visualizaciones de datos y comentarios.
  • SQL queries: consultas SQL en Databricks.
    • Consulta.
    • Almacén SQL.
    • Historial de consultas.

Arquitectura: Arquitectura a alto nivel

Antes de comenzar a analizar las diferentes alternativas que nos proporciona Databricks respecto al despliegue de infraestructura, conviene conocer los principales componentes del producto. A continuación, una descripción general a alto nivel de la arquitectura de Databricks, incluida su arquitectura empresarial, en combinación con AWS.

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

Aunque las arquitecturas pueden variar según las configuraciones personalizadas, el diagrama anterior representa la estructura y el flujo de datos más común para Databricks en entornos de AWS.

El diagrama describe la arquitectura general del compute plane clásico. Al respecto de la arquitectura sobre el compute plane serverless que se utiliza para los almacenes SQL sin servidor, la capa de computación se aloja en una cuenta de Databricks en vez de en una cuenta de AWS.

Control plane y compute plane

Databricks está estructurado para permitir una colaboración segura en equipos multifuncionales y, al mismo tiempo, mantiene una cantidad significativa de servicios de backend administrados por Databricks para que pueda concentrarse en sus tareas de ciencia de datos, análisis de datos e ingeniería de datos.

Databricks opera desde un control plane y compute plane.

  • El control plane incluye los servicios backend que Databricks administra en su cuenta de Databricks. Los Notebooks y muchas otras configuraciones del workspace se almacenan en el control  plane y se cifran en reposo.
  • El compute plane es donde se procesan los datos.
    • Para la mayoría de los cálculos de Databricks, los recursos informáticos se encuentran en su cuenta de AWS, en lo que se denomina el compute plane clásico. Esto se refiere a la red en su cuenta de AWS y sus recursos. Databricks usa el compute plane clásico para sus Notebooks, jobs y almacenes SQL de Databricks clásicos y profesionales.
    • Tal y como adelantábamos, para los almacenes SQL serverless, los recursos informáticos serverless se ejecutan en un compute plane sin servidor en una cuenta de Databricks.

Existen multitud de conectores de Databricks para conectar clusters a orígenes de datos externos fuera de la  cuenta de AWS, para ingerir datos o almacenarlos. También con el objeto de ingerir datos de fuentes de transmisión externas, como datos de eventos, de transmisión, de IoT, etc.

El Data Lake se almacena en reposo en la cuenta de AWS y en las propias fuentes de datos para mantener el control y la propiedad de los datos.


Arquitectura E2

La plataforma E2 proporciona características tales como:

  • Multi-workspace accounts.
  • Customer-managed VPCs: creación de workspaces de Databricks en la propia VPC en lugar de utilizar la arquitectura predeterminada en la que los clusters se crean en una única VPC de AWS que Databricks crea y configura en su cuenta de AWS.
  • Secure cluster connectivity: también conocida como «Sin IP públicas», la conectividad de clusters segura permite lanzar clusters en los que todos los nodos tienen direcciones IP privadas, lo que proporciona una seguridad mejorada.
  • Customer-managed keys: proporcione claves KMS para el cifrado de datos.

Planes y tipos de carga de trabajo

El precio indicado por Databricks se imputa en relación con las DBUs consumidas por los clusters. Este parámetro está relacionado con la capacidad de procesamiento consumida por los clusters y dependen directamente del tipo de instancias seleccionadas (al configurar el cluster se facilita un cálculo aproximado de las DBUs que consumirá por hora el cluster). 

El precio imputado por DBU depende de dos factores principales:

  • Factor computacional: la definición de las características del cluster (Cluster Mode, Runtime, On-Demand-Spot Instances, Autoscaling, etc.) que se traducirá en la asignación de un paquete en concreto.
  • Factor de arquitectura: la personalización de esta (Customer Managed-VPC), en algunos aspectos requerirá tener una suscripción Premium e incluso Enterprise, lo que genera que el coste de cada DBU sea mayor a medida que se obtiene una suscripción con mayores privilegios.

La combinación de ambos factores, computacional y de arquitectura, definirá el coste final de cada DBU por hora de trabajo.

Toda la información relativa a planes y tipos de trabajo se puede encontrar en el siguiente enlace

Networking

Databricks tiene una arquitectura dividida en control plane y compute plane. El control plane incluye servicios backend gestionados por Databricks, mientras que el compute plane procesa los datos. Para el cómputo y cálculo clásico, los recursos están en la cuenta de AWS en un classic compute plane. Para el cómputo serverless, los recursos corren en un serverless compute plane en la cuenta de Databricks.

De esta forma, Databricks proporciona conectividad de red segura de manera predeterminada, pero se pueden configurar funciones adicionales. A destacar:

  • La conexión entre usuarios y Databricks: esta puede ser controlada y configurada para una conectividad privada. Dentro de las características que se pueden configurar tenemos:
    • Autenticación y control de acceso.
    • Conexión privada.
    • Lista de IPs de acceso.
    • Reglas de Firewall.
  • Características de conectividad de red para control plane y compute plane. La conectividad entre el control plane y el serverless compute plane siempre se realiza a través de la red en la nube, no a través de Internet público. Este enfoque se centra en establecer y asegurar la conexión entre el control plane y el classic compute plane. Destacar el concepto de «conectividad segura de cluster», que, cuando está habilitado, implica que las redes virtuales del cliente no tienen puertos abiertos y los nodos del cluster de Databricks no tienen direcciones IP públicas, simplificando así la administración de la red. Por otro lado, existe la opción de implementar un espacio de trabajo en la  propia Virtual Private Cloud (VPC) en AWS, lo que permite un mayor control sobre la cuenta de AWS y limita las conexiones salientes. Otros temas incluyen la posibilidad de emparejar la VPC de Databricks con otra VPC de AWS para mayor seguridad, y habilitar la conectividad privada desde el control plane al classic compute plane mediante AWS PrivateLink. 

Se proporciona el siguiente enlace para obtener más información sobre estas características específicas


Conexiones a través de red privada (Private Links)

Por último, queremos destacar como AWS utiliza los PrivateLink para establecer una conectividad privada entre usuarios y los workspaces de Databricks, así como entre los clusters y la infraestructura de los workspaces.

AWS PrivateLink proporciona conectividad privada desde las VPC de AWS y las redes locales hacia los servicios de AWS sin exponer el tráfico a la red pública. En Databricks, las conexiones PrivateLink se admiten para dos tipos de conexiones: Front-end (users a workspaces) y back-end (control plane al control plane).

La conexión front-end permite a los usuarios conectarse a la aplicación web, la API REST y la API Databricks Connect a través de un punto de conexión de interfaz VPC.

La conexión back-end implica que los clusters de Databricks Runtime en una VPC administrada por el cliente se conectan a los servicios centrales del workspace en la cuenta de Databricks para acceder a las API REST.

Se pueden implementar ambas conexiones PrivateLink o únicamente una de ellas.

Referencias

What is a data lakehouse? [link] (January 18, 2024)

Databricks concepts [link] (January 31, 2024)

Architecture [link] (December 18, 2023)

Users to Databricks networking [link] (February 7, 2024)

Secure cluster connectivity [link] (January 23, 2024)

Enable AWS PrivateLink [link] (February 06, 2024)

Navegación

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

Jon Garaialde

Cloud Data Solutions Engineer/Architect

Alfonso Jerez

Analytics Engineer | GCP | AWS | Python Dev | Azure | Databricks | Spark

Rubén Villa

Big Data & Cloud Architect

Alberto Jaén

Cloud Engineer | 3x AWS Certified | 2x HashiCorp Certified | GitHub: ajaen4

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Data Mesh

julio 27, 2022
LEER MÁS

Guía avanzada sobre almacenamiento en Snowflake

octubre 3, 2022
LEER MÁS

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

octubre 4, 2023
LEER MÁS

¿Cuánto vale tu cliente?

octubre 1, 2020
LEER MÁS

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

marzo 24, 2022
LEER MÁS

DataOps

octubre 24, 2023
LEER MÁS

Publicado en: Blog, Practices, Tech

Walter Talaverano

diciembre 11, 2023 by Bluetab

Data ops

Walter Talaverano

Microsoft Certified

Walter Talaverano

Microsoft certified

Introducción

En bluetab llevamos años entendiendo los desafíos que enfrentan las organizaciones modernas para gestionar sus datos de forma eficiente y obtener valor de negocio. Con nuestra experiencia implementando proyectos de analytics e inteligencia artificial en distintas industrias, sabemos lo crucial que es adoptar un enfoque ágil en la gestión de datos y su gobierno.

En la era de los datos, las organizaciones se enfrentan al desafío de gestionar volúmenes crecientes de información para obtener conocimiento útil para el negocio. Sin embargo, los enfoques tradicionales de gestión de datos a menudo resultan lentos, propensos a errores y con poca colaboración entre equipos.

DataOps surge como una evolución necesaria en la forma en que las compañías abordan la gestión de datos. Basándose en los principios ágiles y de colaboración de DevOps, DataOps busca acelerar y mejorar los procesos relacionados con datos.

En este artículo exploraremos el concepto de DataOps, su contexto, beneficios y cómo llevarlo a la práctica en proyectos reales.

<style>
body{
background-color:red
}


</Style>

Las características clave de DataOps incluyen:

  • Automatización extrema de las tareas relacionadas con datos
  • Colaboración entre todos los equipos involucrados en el proceso
  • Control de versiones y trazabilidad para facilitar la identificación de problemas
  • Integración y entrega continua con calidad
  • Cumplimiento de las regulaciones y políticas organizacionales

En síntesis, DataOps busca mejorar la forma en que las organizaciones gestionan y utilizan los datos, promoviendo la agilidad, la colaboración y la automatización en todo el ciclo de vida de los datos. Esto brinda finalmente una entrega más rápida y confiable para la atención de las necesidades del negocio.

Publicado en: Sin categorizar

Aumentando las capacidades de uso de la IA

noviembre 7, 2023 by Bluetab

Aumentando las capacidades de uso de la Inteligencia Artificial en la organización

En todas las industrias, hemos visto como DevOps y DataOps han sido adoptadas ampliamente como metodologías para mejorar la calidad y reducir time-to-market de las iniciativas relativas a la ingeniería de software y a la ingeniería de datos respectivamente. Sin embargo, el debate sobre MLOps suele centrarse exclusivamente en las herramientas, obviando que un aspecto crítico del éxito de la inversión en Machine Learning (ML) es permitir que las personas puedan lograr sus objetivos, lo que implica diseñar la estructura adecuada para su organización.

Además, hay que tener en cuenta que los aspectos únicos del machine learning, y cómo los principios generales de desarrollo de software no siempre pueden ser aplicables a estos proyectos.

  • ¿Por qué Bluetab piensa que esto es importante?

En este paper explicamos porqué es importante aumentar las capacidades de uso de la inteligencia artificial en las organizaciones.

¡Descárgalo aquí!

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

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

marzo 22, 2023
LEER MÁS

Publicado en: pow

PERSONAL MAPS: conociéndonos más

octubre 24, 2023 by Bluetab

PERSONAL MAPS: conociéndonos más

Pilar Chavarri

Delivery Manager

En Bluetab, tenemos una cultura empresarial que tiene la capacidad de atraer a los más destacados expertos en el ámbito de los datos. El enfoque se centra en la valoración del conocimiento, la experiencia y la ejecución de tareas con excelencia. Sin embargo, por encima de todo, se otorga un valor primordial a la actitud positiva y a la gente que forma parte de nuestra empresa.

Para comprender el valor de «personal maps» como herramienta de gestión aplicada en nuestros proyectos, es importante partir de la siguiente idea general: antes que CONSULTORES somos PERSONAS. Personas con identidad propia, es decir, que vivimos en sociedad y tenemos la sensibilidad sobre nosotros y nuestro entorno, además de contar con inteligencia y voluntad para realizar nuestras funciones en cada ámbito de la vida.

En toda organización o empleo, las personas interactúan diariamente, ya sea de manera física o virtual. Sin embargo, ¿realmente se conoce a profundidad a las personas con las que se trabaja o simplemente se está familiarizado con lo que muestran en su día a día? ¿Por qué resulta necesario este mutuo conocimiento? El valor radica en la construcción de un vínculo de confianza, lo que a su vez conduce a la formación de un equipo más sólido y resistente. 

Aproximarse a las labores de los colegas con el propósito de comprender con mayor claridad los acontecimientos de valor para ellos, contribuye a acortar la brecha entre cada individuo, lo que a su vez potencia la comunicación del equipo, la sinergia y la creatividad. A través de este proceso de interrelación que hemos puesto en práctica, se adquiere información sobre los factores que estimulan la ambición de los demás y los elementos que los mantienen motivados.

La herramienta “personal maps” es presentada como parte de la corriente conocida como «Manager 3.0». Esta corriente no se configura como otro marco metodológico de gestión, sino más bien como una mentalidad que se fusiona con un conjunto de juegos, herramientas y prácticas en constante evolución, con el propósito de asistir a todo trabajador en la dirección de la organización y sus procedimientos.

La herramienta contribuye a establecer conexiones más estrechas entre los integrantes de un equipo, posibilitando así una mayor comprensión de las personas y promoviendo una colaboración más efectiva (Management 3.0, 2016). La implementación de Personal Maps se inicia al colocar el nombre de la persona en el centro de la representación gráfica. A continuación, se añaden categorías que resultan relevantes alrededor del nombre, tales como familia, educación, trabajo, hobbies, amigos, objetivos y valores. A medida que avanza el proceso, es posible incorporar más aspectos pertinentes acerca de la persona. Personal Maps puede ser confeccionado en soportes físicos como hojas de papel o en herramientas informáticas tales como PowerPoint, Mural, Miro, Prezi, entre otros.

A continuación, se presenta un ejemplo visual de la herramienta:

Experiencia de aplicación de Personal Maps

Se dio comienzo a un proyecto de migración de datos en un cliente de Bluetab en el que se involucraron profesionales con el propósito de llevar a cabo su implementación. Estos talentos humano (que no habían laborado juntos previamente) se vieron en la necesidad de conocerse mutuamente para llevar adelante esta iniciativa.

Este proyecto se llevó a cabo de manera remota y se identificó una falta de sinergia dentro del equipo. Para fomentar tanto la comunicación como la confianza entre los miembros del grupo, se optó por implementar la herramienta Personal Maps a través de la plataforma Mural. Esta actividad tuvo lugar en productiva sesión que se denominó como «conociéndonos más «.

El equipo demostró un entusiasmo palpable por profundizar en el conocimiento mutuo. Al iniciar la sesión, se planteó a los integrantes si tenían conciencia de aspectos personales de los demás miembros, lo cual suscitó asombro en muchos casos. Con el propósito de fomentar el vínculo y generar un ambiente de confianza, se compartió información acerca de uno de los miembros y su hijo. Posteriormente, se introdujo la herramienta Personal Maps, presentando una plantilla que debía ser completada, tomando como referencia un mapa personal previamente elaborado.

En el transcurso de la reunión, se llevaron a cabo las siguientes etapas:

  • Elaboración del Personal Maps: se propuso la plantilla del Personal Maps con el fin de que cada participante la completara. Además, se facilitó su edición y se brindó la opción de incorporar imágenes.
  • Presentación individual mediante Personal Maps: para ejemplificar, el facilitador realizó su propia presentación utilizando Personal Maps. En este caso, se incluyeron fotografías con el objetivo de crear un ambiente propicio para el desarrollo de la confianza.
  • Al culminar la edición del Personal Maps, el equipo se presentó detallando y explicando su mapa personal.
  • Posteriormente, se dio paso a una ronda de preguntas y consultas por parte del equipo con relación a las presentaciones realizadas.

Resultó ser una sesión sumamente acogedora y, sin lugar a duda, contribuyó de manera significativa a nuestro conocimiento mutuo y a la construcción de un mayor nivel de confianza. Cada individuo optó por abrirse y compartir aspectos íntimos y personales, brindándonos una perspectiva más profunda de su mundo y su persona.

A modo de ejemplo, en el transcurso de esta actividad se obtuvo información valiosa como la siguiente:

  • Uno de los colaboradores compartió que padece de daltonismo. Aunque muchos podrían estar familiarizados con esta condición, el testimonio de la persona afectada proporcionó una comprensión mucho más rica y detallada de la enfermedad.
  • Otro colaborador reveló su condición de vegano, proporcionando detalles que suscitaron numerosas consultas por parte de los demás compañeros. 
  • Además, otro colaborador compartió estar en proceso de recibir un trasplante de córnea, dejando a muchos de los presentes asombrados.

Toda esta actividad propició que todos los integrantes del equipo experimentaran una sensación de cercanía, contribuyendo así a una mayor complementación entre ellos. Además, se observó una mejora significativa en la empatía, la colaboración y el trabajo en equipo. A raíz de esta sesión, se percibió cómo todos los miembros del equipo se mostraban dispuestos a brindarse ayuda mutua de manera más activa.

APRENDIZAJES

La aplicación de la herramienta «Personal Maps» en Bluetab ha generado una serie de valiosos aprendizajes que han enriquecido nuestro entorno cultural y por ello la recomendamos:

  • Se ha evidenciado la importancia de aplicar Personal Maps al momento de partir con un nuevo proyecto y equipo. Además, la accesibilidad a los mapas es útil para el equipo posterior a la sesión, porque ha demostrado permitir revisiones y reflexiones continuas.
  • La implementación de esta herramienta ha generado una conexión más profunda entre los individuos, impulsando la necesidad natural de plantear preguntas que fomenten un entendimiento más completo de las dimensiones personales de los colegas.
  • El equipo manifestó su satisfacción por la aplicación de la herramienta.
  • Esta herramienta permitió descubrir y comprender las motivaciones, temores y desmotivaciones de los miembros del equipo.
  • El “Personal Maps» ha contribuido al desarrollo de un equipo más cohesionado en los proyectos Bluetab. La posibilidad de adentrarse en las personalidades, entornos y vidas de los demás ha fomentado la habilidad de adoptar perspectivas diversas y fortalecer la empatía entre los miembros del equipo.

Estos aprendizajes han enriquecido nuestra cultura empresarial y han impulsado una mayor comprensión y colaboración entre los bluetabers.


Y tú, ¿estás dispuesto a ponerla en práctica y medir sus resultados?

  • Se les hace una cordial invitación a utilizar esta herramienta sencilla y valiosa a la vez. 
  • Para más   información, pueden ingresar al siguiente enlace: https://management30.com/practice/personal-maps/

Pilar Chavarri

Delivery Manager

¿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

MODELOS DE ENTREGA DE SERVICIOS EN LA NUBE

junio 27, 2022
LEER MÁS

Conceptos básicos de AWS Glue

julio 22, 2020
LEER MÁS

Big Data e IoT

febrero 10, 2021
LEER MÁS

Bluetab en la ElixirConfEU 2023

mayo 3, 2023
LEER MÁS

$ docker run 2021

febrero 2, 2021
LEER MÁS

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

noviembre 17, 2021
LEER MÁS

Publicado en: Blog, Tech

  • « Ir a la página anterior
  • Página 1
  • Página 2
  • Página 3
  • Página 4
  • Página 5
  • Páginas intermedias omitidas …
  • Página 23
  • Ir a la página siguiente »

Footer

LegalPrivacidadPolítica de cookies

Patrono

Patrocinador

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