• 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

Tech

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

marzo 17, 2025 by Bluetab

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

Julián Felipe Parra

Technical Specialist

Introducción

En muchas ocasiones, los costos en la nube pueden dispararse debido a una configuración inadecuada o a la falta de conocimiento sobre cómo aprovechar al máximo los servicios disponibles. En el caso de Google Cloud Platform (GCP), los servicios más utilizados para almacenamiento son Google Cloud Storage (GCS) y BigQuery. Sin embargo, sin un enfoque adecuado en su configuración y administración, pueden generar gastos innecesarios.

El objetivo de este artículo es proporcionar un conjunto de recomendaciones para optimizar el uso de estos servicios, enfocándonos en cómo configurar correctamente los buckets de GCS y las tablas de BigQuery, asegurándonos de que cada servicio esté alineado con las necesidades específicas de nuestra implementación. A lo largo del artículo, exploraremos las mejores estrategias para gestionar el ciclo de vida de los datos, decidir cuándo activar el versionado, cómo organizar la estructura de almacenamiento en función del uso o tipología de los datos y qué aspectos técnicos deben considerarse para mantener un control eficiente de los costos.

Además, vamos a abordar un conjunto de preguntas clave que debemos plantearnos al configurar estos servicios. Responder estas preguntas nos ayudará a tomar decisiones más informadas y evitar sobrecostos innecesarios.

También veremos cómo, utilizando las APIs de Google, podremos revisar los metadatos actuales de nuestros recursos, permitiéndonos auditar y mejorar la configuración de nuestros entornos de almacenamiento de forma sencilla y efectiva.


Recomendaciones

Clase de almacenamiento GCS

Utiliza clases de almacenamiento como Standard, Nearline, Coldline, y Archive según la frecuencia de acceso a los datos. Por ejemplo, si los datos no serán accedidos en los próximos 30 días, podrías moverlos a Nearline o Coldline para optimizar los costos.

Ciclo de vida de los objetos en GCS

Configura políticas de ciclo de vida para mover, eliminar o archivar objetos automáticamente basándote en la antiguedad de los mismos. Esto ayuda a reducir el costo de almacenamiento sin intervención manual.

Versionado en GCS

Habilita el versionado solo cuando sea necesario. Si los datos cambian frecuentemente o si necesitas poder recuperar versiones anteriores de un archivo, el versionado es útil. Sin embargo, asegúrate de gestionar las versiones antiguas para no generar costos innecesarios por almacenamiento duplicado.

Buenas prácticas BigQuery

Particionamiento

El particionamiento es una técnica que divide las tablas en segmentos más pequeños y manejables según una columna específica, como la fecha. En BigQuery, el particionamiento por fecha es común, ya que permite reducir la cantidad de datos escaneados durante las consultas. Al particionar las tablas, se optimizan las consultas al enfocarse solo en los segmentos de datos relevantes, lo que mejora el rendimiento y reduce los costos asociados con el procesamiento de grandes volúmenes de datos.


Clustering

El clustering organiza los datos dentro de una tabla según una o más columnas de forma que los registros con valores similares se almacenan cerca unos de otros. Esta técnica es útil para mejorar la eficiencia de las consultas que filtran o agrupan por las columnas seleccionadas para el clustering. Al usar clustering junto con particionamiento, se puede mejorar aún más el rendimiento y reducir los costos de las consultas, ya que BigQuery puede leer menos datos y realizar búsquedas más rápidas sobre grandes conjuntos de datos.


Antipatrones

Aunque el particionamiento y el clustering son poderosas herramientas para optimizar el rendimiento y reducir costos, también existen varios antipatrones que debes evitar en BigQuery. Un antipatrón común es no diseñar el esquema de particionamiento y clustering en función de cómo se realizan las consultas. Por ejemplo, particionar por una columna que no se usa frecuentemente en los filtros de las consultas puede resultar en un uso ineficiente del espacio y aumentar los costos de procesamiento. Otro antipatrón es tener un número excesivo de columnas con clustering, lo que puede llevar a una sobrecarga de administración y a tiempos de consulta más lentos.

Además, un error frecuente es realizar consultas sin un uso adecuado de las funciones de agregación o sin aplicar filtros eficientes, lo que puede provocar que se escaneen grandes volúmenes de datos innecesarios, aumentando los costos. Un antipatrón muy importante es el uso de SELECT *, que es común en algunas consultas pero puede ser extremadamente costoso en BigQuery. Esto se debe a que BigQuery es un sistema de bases de datos columnar, lo que significa que almacena los datos por columnas, no por filas. Al usar SELECT *, estás solicitando todos los datos de todas las columnas, lo que puede resultar en una gran cantidad de datos escaneados innecesariamente, aumentando los costos de la consulta y afectando el rendimiento. En su lugar, se recomienda seleccionar solo las columnas necesarias para la consulta, optimizando tanto el rendimiento como los costos.

Otro antipatrón es la sobrecarga de las consultas con un número elevado de uniones o subconsultas complejas, lo que puede impactar negativamente el rendimiento.


Multirregión en GCS y BigQuery

Google Cloud Storage (GCS) y BigQuery ofrecen configuraciones multirregión que permiten distribuir datos y consultas a través de múltiples ubicaciones geográficas, lo que puede proporcionar ventajas significativas en términos de disponibilidad y desempeño. Sin embargo, es fundamental comprender las ventajas y desventajas que tienen estas configuraciones para tomar decisiones informadas al diseñar arquitecturas.


Google Cloud Storage (GCS)

Ventajas:

  • Alta disponibilidad y durabilidad: Los datos se replican automáticamente entre diferentes regiones dentro del continente seleccionado. Esto asegura que, en caso de un fallo en una región específica, el acceso a los datos no se vea afectado.
  • Optimización del acceso global: Los usuarios y servicios distribuidos en diferentes partes del mundo pueden acceder a los datos de manera más eficiente, aprovechando la proximidad geográfica.
  • Facilidad de gestión: Al elegir una configuración multirregión, no es necesario gestionar manualmente la replicación entre regiones. Google Cloud maneja automáticamente este proceso.

Desventajas:

  • Costo más elevado: Al elegir una ubicación multirregión, los costos de almacenamiento pueden aumentar, ya que los datos se replican en varias ubicaciones. Este costo adicional debe ser evaluado en función de los requisitos de disponibilidad.
  • Latencia adicional: Si bien el acceso global puede beneficiarse de la proximidad, también se debe considerar que el tráfico interregional puede generar latencias, especialmente si se usan servicios fuera de la región multirregión.

Utiliza ubicaciones multirregión cuando la alta disponibilidad y la resiliencia sean esenciales para tu aplicación. Por ejemplo, aplicaciones críticas que deben estar siempre disponibles, incluso durante desastres regionales.

Si los costos son una preocupación, evalúa si realmente necesitas una configuración multirregión o si una ubicación única o una configuración regional puede ser suficiente para tus necesidades.


BigQuery

Ventajas:

  • Desempeño optimizado para consultas globales: Cuando se ejecutan consultas en conjuntos de datos almacenados en una configuración multirregión, BigQuery puede optimizar la distribución de la carga de trabajo, ejecutando partes de las consultas cerca de los datos para reducir la latencia.
  • Alta disponibilidad de datos: Al igual que con GCS, los datos almacenados en BigQuery en una ubicación multirregión se replican automáticamente entre varias regiones, garantizando la durabilidad y disponibilidad incluso en situaciones de fallos regionales.
  • Reducción de la latencia para usuarios globales: Las consultas pueden ejecutarse más rápidamente si los datos están cerca de la ubicación de los usuarios finales, mejorando el tiempo de respuesta en escenarios globales.

Desventajas:

  • Costo por consultas interregionales: Aunque BigQuery maneja el procesamiento de manera eficiente, las consultas que abarcan múltiples regiones pueden generar costos adicionales, ya que se incurre en tarifas de transferencia de datos entre regiones.
  • Posible complejidad en la gestión de datos: Al almacenar datos en una configuración multirregión, debes estar al tanto de las políticas de acceso y las implicaciones de rendimiento para asegurarte de que las consultas no se vean innecesariamente afectadas por la latencia interregional.

Si tu aplicación requiere análisis en tiempo real o consultas que involucren grandes volúmenes de datos distribuidos globalmente, usar una configuración multirregión en BigQuery puede mejorar significativamente el rendimiento.

Considera el costo de las transferencias interregionales si tu flujo de trabajo involucra consultas entre datos almacenados en diferentes regiones. Para evitar costos innecesarios, puede ser útil limitar las consultas a una región específica o consolidar los datos en una región centralizada.

Ten en cuenta la ubicación de tus usuarios y servicios, ya que elegir la región correcta puede impactar tanto el costo como el desempeño de las consultas.


Herramientas para monitorear y controlar costos y rendimiento

En el entorno de la nube, controlar los costos y mantener el rendimiento óptimo de los servicios es esencial para una gestión eficiente de los recursos. Google Cloud ofrece varias herramientas que facilitan el monitoreo, la optimización de costos y el análisis del rendimiento de servicios como Google Cloud Storage (GCS) y BigQuery. A continuación, revisamos algunas de las herramientas más útiles disponibles en Google Cloud para gestionar ambos servicios.

Google Cloud Billing(Monitoreo de Costos y Estimaciones)

Es una de las herramientas principales para gestionar y monitorear los costos asociados con todos los servicios de Google Cloud, incluyendo GCS y BigQuery. Proporciona visibilidad detallada sobre el uso de los servicios y las tarifas que se están generando.

Funcionalidades clave:

  • Estadísticas de uso y costos: Permite obtener informes detallados sobre el uso de GCS y BigQuery, segmentados por proyectos, servicios o incluso usuarios. Puedes analizar los costos históricos, estimar los gastos futuros y crear alertas para evitar sorpresas.
  • Presupuestos y alertas: Puedes configurar presupuestos para cada servicio o proyecto y recibir alertas si los costos superan ciertos umbrales. Esto es especialmente útil para evitar gastos imprevistos en BigQuery, donde las consultas interregionales o el almacenamiento de grandes volúmenes de datos pueden generar costos adicionales.
  • Informes de costos detallados: Accede a informes granulares sobre las tarifas de almacenamiento, transferencia de datos, ejecución de consultas y otros servicios relacionados. Esta información es útil para identificar áreas donde se puede optimizar el uso y reducir costos.
  • Cost Breakdown: Puedes segmentar los costos por servicio, región, etiquetas o proyectos. Esto es útil para desglosar específicamente cuánto estás gastando en GCS y BigQuery, permitiéndote identificar áreas donde podrías reducir el gasto.
  • Recomendaciones de optimización: Google Cloud Billing ofrece recomendaciones personalizadas para optimizar los costos, por ejemplo, sugiriendo la transición de almacenamiento a clases más económicas en GCS o la revisión de patrones de consultas costosas en BigQuery.
  • Forecasting y Análisis Predictivo: La herramienta también ofrece funcionalidades para predecir los costos futuros basándose en el uso histórico y la tendencia actual, lo que te ayuda a planificar los recursos de manera más eficiente.

Usa Google Cloud Billing para establecer un control regular de los costos de GCS y BigQuery, y configura alertas para mantenerte dentro de los límites presupuestarios. Además, puedes crear informes personalizados para realizar un seguimiento más efectivo.

Utiliza las recomendaciones de optimización de Google Cloud Cost Management para ajustar la infraestructura de GCS y BigQuery a tus necesidades reales, asegurando una gestión de costos más eficaz.


Google Cloud Monitoring(Monitoreo de los servicios)

Para gestionar el rendimiento de GCS y BigQuery, Google Cloud Monitoring es la herramienta recomendada. Esta herramienta permite visualizar el estado de los recursos de Google Cloud, incluidas las métricas de rendimiento de almacenamiento y consultas.

Funcionalidades clave:

  • Métricas de rendimiento de GCS: Puedes monitorear tanto el tiempo de respuesta como la tasa de transferencia de los objetos almacenados en Google Cloud Storage (GCS), lo que te ayudará a detectar problemas de rendimiento que puedan afectar la eficiencia en el acceso a los datos. Además, es posible monitorear el uso del almacenamiento y obtener una visión clara de la cantidad de espacio que cada bucket está utilizando. Esto es clave para identificar rápidamente qué buckets están generando costos elevados, permitiéndote tomar decisiones informadas sobre la gestión del almacenamiento. También es importante monitorear el uso de la API de GCS, ya que una alta cantidad de solicitudes o un uso ineficiente de la API puede generar costos adicionales y afectar el rendimiento.
  • Métricas de rendimiento de BigQuery: Google Cloud Monitoring ofrece métricas detalladas sobre el rendimiento de las consultas en BigQuery, tales como el tiempo de ejecución, la cantidad de datos procesados y los recursos consumidos. Estas métricas son fundamentales para identificar consultas que podrían estar generando cuellos de botella o costos elevados. Además, es posible monitorear el uso de la API de BigQuery, lo que te permitirá detectar patrones anómalos en el consumo de la API, evitando posibles sobrecargos y asegurando un rendimiento óptimo de tus consultas. Monitorear tanto el uso de la API como el almacenamiento te permite optimizar tanto la infraestructura como los costos asociados con el procesamiento de datos.
  • Alertas de rendimiento: Al igual que con los costos, puedes establecer alertas para el rendimiento, como el tiempo de respuesta de GCS o la duración de las consultas en BigQuery, para tomar medidas preventivas si los indicadores de rendimiento superan ciertos umbrales.

Usa Google Cloud Monitoring para realizar un seguimiento constante de las métricas clave relacionadas con GCS y BigQuery, asegurando que ambas plataformas funcionen de manera eficiente y sin cuellos de botella que puedan afectar la experiencia del usuario o generar costos innecesarios.


BigQuery Query Plan Explanation(Optimización de Consultas)

Una de las principales preocupaciones en BigQuery es el rendimiento de las consultas. BigQuery Query Plan Explanation es una herramienta avanzada que permite examinar los planes de ejecución de las consultas y entender cómo BigQuery procesa los datos.

Funcionalidades clave:

  • Plan de ejecución: Analiza el plan de ejecución de las consultas, lo que te permite identificar posibles optimizaciones, como el uso de índices, particiones o la reorganización de las tablas.
  • Recomendaciones de optimización: En el plan de ejecución, BigQuery proporciona recomendaciones sobre cómo mejorar la consulta para reducir los costos y mejorar el tiempo de ejecución, como evitar la lectura de datos innecesarios o mejorar el uso de recursos.
  • Optimización de costos: Al mejorar las consultas, puedes reducir significativamente los costos asociados con la ejecución de las mismas, especialmente en escenarios donde se procesan grandes volúmenes de datos.

Utiliza BigQuery Query Plan Explanation para revisar y optimizar las consultas que realizan un uso intensivo de recursos, asegurando que el procesamiento de datos se haga de la manera más eficiente posible.

Preguntas claves

Para poder tomar la mejor decisión te puedes basar en la siguiente serie de preguntas y escenarios planteados:

  1. ¿Cuál es el volumen de datos que manejarás?
    • Escenario 1: Datos a gran escala
      Si estás gestionando un sistema de análisis de logs de aplicaciones distribuidas, el volumen de datos podría ser muy alto, con millones de registros generados cada hora. En este caso, podrías optar por usar GCS con la clase de almacenamiento Nearline o Coldline para los logs que no se consultan frecuentemente, pero que deben conservarse por un periodo largo.
    • Escenario 2: Datos pequeños y estáticos
      Si manejas un sitio web con archivos estáticos (por ejemplo, imágenes, CSS, etc.), el volumen de datos puede ser pequeño y relativamente estable. En este caso, podrías almacenar los archivos en un bucket con la clase Standard, ya que el acceso será frecuente y rápido.
  1. ¿Cuál es el ciclo de vida de tus datos?
    • Escenario 1: Datos temporales
      Imagina que gestionas un sistema de análisis de datos en tiempo real, donde los datos sólo tienen valor durante unas horas o días (por ejemplo, registros de métricas de uso de una aplicación móvil). Después de cierto tiempo, estos datos ya no son útiles. En este caso, puedes configurar un ciclo de vida en GCS para mover los archivos a Coldline después de 30 días y, después de 90 días, eliminarlos.
    • Escenario 2: Datos históricos y de cumplimiento
      Si tienes datos que deben ser almacenados durante años por razones de cumplimiento o auditoría (como registros financieros o médicos), debes asegurarte de que estos se conserven en almacenamiento de largo plazo y estén protegidos. En este caso, Coldline o Archive en GCS serían las mejores opciones, y podrías aplicar políticas de retención para garantizar que los datos se mantengan durante el tiempo requerido.
  1. ¿Necesitas versionar tus datos?
    • Escenario 1: Versionado de datos críticos
      Supongamos que estás manejando datos sensibles, como documentos legales o informes financieros, y necesitas poder recuperar versiones anteriores en caso de errores o cambios no deseados. Habilitar el versionado en GCS sería útil, ya que te permite mantener un historial de las versiones de cada archivo. Sin embargo, es importante configurar una política para eliminar versiones antiguas después de un tiempo para evitar el uso excesivo de almacenamiento.
    • Escenario 2: Datos no modificables
      Si trabajas con archivos que no cambian con frecuencia, como archivos multimedia o datos de respaldos que se actualizan solo una vez cada cierto tiempo, el versionado podría no ser necesario. En este caso, puedes evitar habilitar el versionado y ahorrar en costos de almacenamiento innecesarios.
  1. ¿Cómo organizar tus datos en GCS?
    • Escenario 1: Múltiples tipos de datos y permisos diferenciados
      Si trabajas con una organización que maneja diferentes tipos de datos (por ejemplo, datos de clientes, logs de servidores, imágenes de productos, etc.), lo ideal sería crear diferentes buckets para cada tipo de datos. Esto no solo organiza mejor los recursos, sino que también permite aplicar políticas de seguridad y ciclo de vida diferenciadas.
      • Bucket 1: Logs de servidores (logs)
      • Bucket 2: Archivos de usuarios (user-data)
      • Bucket 3: Imágenes de productos (product-images)
      • Además, puedes aplicar políticas de ciclo de vida distintas en cada bucket. Por ejemplo, los logs de servidores pueden tener una retención corta (mover a Coldline después de 30 días), mientras que las imágenes de productos pueden estar almacenadas a largo plazo en Nearline o Archive.
    • Escenario 2: Múltiples proyectos y entornos
      En un entorno con varios proyectos, podrías crear un bucket por proyecto o incluso por entorno (producción, desarrollo, pruebas) para mantener el aislamiento y la gestión controlada.
  1. ¿BigQuery será utilizado para análisis en tiempo real o consultas históricas?
    • Escenario 1: Análisis en tiempo real
      Supón que estás trabajando con un sistema de monitoreo de eventos en tiempo real, donde los datos se generan y se consultan de inmediato (por ejemplo, análisis de comportamiento de usuarios en una plataforma web). En este caso, deberías configurar tablas particionadas en BigQuery por fecha para asegurarte de que las consultas solo analicen los datos más recientes y no incurras en costos innecesarios por escanear grandes volúmenes de datos históricos.

      Partición por fecha: Crea tablas particionadas por fecha para consultas diarias de los datos más recientes.
    • Escenario 2: Consultas históricas
      Si trabajas con un sistema donde las consultas se hacen sobre grandes volúmenes de datos históricos (por ejemplo, análisis de tendencias de ventas a lo largo de varios años), entonces deberías usar clustering en BigQuery para organizar los datos y optimizar las consultas por las columnas más consultadas (como ID de producto, categoría, etc.).

      Clustering: Crear un clustering por producto_id y categoria_id para optimizar las consultas sobre estos campos.
  1. ¿Tienes políticas de seguridad y acceso claras para cada servicio?
    • Escenario 1: Acceso diferenciado para equipos
      Si tienes diferentes equipos (por ejemplo, equipo de desarrollo, operaciones, y análisis de datos), es fundamental definir roles y permisos para cada bucket en GCS y las tablas en BigQuery. Asegúrate de que solo los usuarios autorizados puedan modificar o acceder a datos sensibles.

      GCS: Usa IAM para otorgar permisos específicos a los diferentes buckets. Por ejemplo, solo el equipo de operaciones debe tener acceso de lectura/escritura al bucket de logs (logs).

      BigQuery: Asigna permisos de lectura a los analistas de datos para las tablas de BigQuery, pero solo permite escritura al equipo de desarrollo.
    • Escenario 2: Acceso por ubicación geográfica
      Si estás trabajando en una región con regulaciones de protección de datos (por ejemplo, en la UE), puedes configurar ubicaciones regionales en GCS para asegurar que los datos se almacenan en una región específica y controlar el acceso a ellos de acuerdo con las normativas locales.
      Con estos escenarios, tienes un marco claro de cómo abordar las decisiones de almacenamiento, ciclo de vida, versionado y seguridad, según las necesidades de tu proyecto.

Optimización

Para que puedas optimizar los costos aplicando las recomendaciones que se vieron anteriormente, es necesario que conozcas cómo están configurados los servicios, para esto puedes revisar varios ejemplos de código para obtener los metadatos de tus recursos en Google Cloud Storage (GCS) y BigQuery, utilizando las APIs de Google Cloud (en Python). Esto te permitirá obtener información sobre la configuración actual y ayudarte a identificar posibles mejoras o cambios.

  1. Revisar los metadatos de un bucket en GCS
    • Este código obtiene información sobre un bucket en Google Cloud Storage, incluyendo la clase de almacenamiento, las políticas de ciclo de vida, y más.
    • Instalar dependencias: Si no lo has hecho aún,  instala la biblioteca cliente de Google Cloud Storage en Python:

pip install google-cloud-storage
 

Código para obtener metadatos del bucket:


import csv
import concurrent.futures
from google.cloud import storage

#cambiar nombre del project-id
client = storage.Client(project="project-id")

def obtener_metadatos_bucket(bucket):
    metadatos = {
        "nombre_bucket": bucket.name,
        "ubicacion_bucket": bucket.location,
        "clase_almacenamiento": bucket.storage_class,
        "versionamiento_habilitado": bucket.versioning_enabled,
        "reglas_ciclo_vida": str(bucket.lifecycle_rules) if bucket.lifecycle_rules else "No hay reglas",
    }

    objetos = []
    blobs = client.list_blobs(bucket.name)
    for blob in blobs:
        objetos.append({
            "nombre_objeto": blob.name,
            "tamano_objeto": f"{blob.size} bytes"
        })

    return metadatos, objetos

def guardar_metadatos_csv(nombre_archivo, metadatos_buckets):
    with open(nombre_archivo, mode='w', newline='') as file:
        writer = csv.writer(file)

        # Encabezados
        writer.writerow(["Nombre del Bucket", "Ubicación", "Clase de Almacenamiento", "Versionamiento", "Reglas Ciclo de Vida", "Nombre del Objeto", "Tamaño del Objeto"])

        # Escribir los metadatos de cada bucket
        for metadatos, objetos in metadatos_buckets:
            for objeto in objetos:
                writer.writerow([
                    metadatos["nombre_bucket"],
                    metadatos["ubicacion_bucket"],
                    metadatos["clase_almacenamiento"],
                    metadatos["versionamiento_habilitado"],
                    metadatos["reglas_ciclo_vida"],
                    objeto["nombre_objeto"],
                    objeto["tamano_objeto"]
                ])

def procesar_bucket(bucket):
    try:
        metadatos, objetos = obtener_metadatos_bucket(bucket)
        return metadatos, objetos
    except Exception as e:
        print(f"Error al procesar el bucket {bucket.name}: {e}")
        return None

def obtener_y_guardar_metadatos():
    metadatos_buckets = []

    buckets = client.list_buckets()

    # Usar ThreadPoolExecutor para paralelizar la carga de metadatos
    with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor:
        futures = {executor.submit(procesar_bucket, bucket): bucket for bucket in buckets}

        for future in concurrent.futures.as_completed(futures):
            resultado = future.result()
            if resultado:
                metadatos_buckets.append(resultado)

    guardar_metadatos_csv('metadatos_buckets.csv', metadatos_buckets)

    print("Metadatos guardados en el archivo 'metadatos_buckets.csv'")

if __name__ == "__main__":
    obtener_y_guardar_metadatos()


 

Este script te permitirá ver información sobre:

  • La ubicación del bucket (para asegurarte de que cumple con las normativas de regulación de datos, si es necesario).
  • La clase de almacenamiento (Standard, Nearline, Coldline, Archive).
  • Si el versionado está habilitado.
  • Las políticas de ciclo de vida configuradas para el bucket.
  • Un listado de objetos dentro del bucket y su tamaño.
  1. Revisar los metadatos de una tabla en BigQuery

 

Este código obtiene metadatos sobre una tabla de BigQuery, como su esquema, particiones, y detalles de almacenamiento.

 

Instalar dependencias: Si aún no lo has hecho, instala el SDK de Google Cloud para BigQuery:

pip install google-cloud-bigquery 

Código para obtener metadatos de una tabla en BigQuery:

import csv
import concurrent.futures
from google.cloud import bigquery
from google.api_core.exceptions import NotFound

#cambiar nombre del project-id
client = bigquery.Client(project="project-id")

def obtener_metadatos_tabla(dataset_id, table_id):
    try:
        table_ref = client.dataset(dataset_id).table(table_id)
        
        table = client.get_table(table_ref)
        
        partition_field = "N/A"
        if table.time_partitioning and table.time_partitioning.field:
            partition_field = table.time_partitioning.field
        
        metadatos = {
            "dataset_id": dataset_id,
            "table_id": table.table_id,
            "descripcion": table.description,
            "esquema": ', '.join([f"{field.name} ({field.field_type})" for field in table.schema]),
            "partitioning_type": table.partitioning_type if table.partitioning_type else "No particionada",
            "partition_field": partition_field,  # Usamos la variable con la partición
            "clustering_fields": ', '.join(table.clustering_fields) if table.clustering_fields else "No clustering",
            "tamaño_bytes": table.num_bytes,
            "numero_filas": table.num_rows
        }
        return metadatos
    except NotFound:
        print(f"Tabla no encontrada: {dataset_id}.{table_id}")
        return None

def obtener_tablas_datasets():
    metadatos_tablas = []

    datasets = client.list_datasets()

    with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor:
        futures = []
        
        for dataset in datasets:
            tablas = client.list_tables(dataset.dataset_id)
            for tabla in tablas:
                futures.append(executor.submit(obtener_metadatos_tabla, dataset.dataset_id, tabla.table_id))
        
        for future in concurrent.futures.as_completed(futures):
            metadatos = future.result()
            if metadatos:
                metadatos_tablas.append(metadatos)

    return metadatos_tablas

def guardar_metadatos_csv(nombre_archivo, metadatos_tablas):
    with open(nombre_archivo, mode='w', newline='') as file:
        writer = csv.DictWriter(file, fieldnames=metadatos_tablas[0].keys())
        writer.writeheader()
        writer.writerows(metadatos_tablas)

def procesar_metadatos():
    metadatos_tablas = obtener_tablas_datasets()

    guardar_metadatos_csv('metadatos_tablas.csv', metadatos_tablas)
    print("Metadatos guardados en el archivo 'metadatos_tablas.csv'")

if __name__ == "__main__":
    procesar_metadatos()


 

Este script te permitirá obtener información clave sobre:

  • El esquema de la tabla (nombres y tipos de los campos).
  • Particionamiento: Si la tabla está particionada por fecha u otra columna y cómo se está gestionando.
  • Clustering: Si la tabla usa clustering para optimizar las consultas.
  • Tamaño de la tabla y el número de filas.
  1. Obtener detalles sobre el uso de GCS y BigQuery

 

Para obtener más detalles acerca del uso y las métricas de tus servicios de GCS y BigQuery, puedes utilizar el servicio de Cloud Monitoring o la API de Stackdriver para obtener métricas sobre almacenamiento y consultas, pero esto va más allá de revisar metadatos y entra en el análisis de rendimiento.

 

Conclusión

 

En resumen, la optimización de los costos en Google Cloud Platform, especialmente en servicios clave como GCS y BigQuery, es fundamental para mantener un control eficiente sobre el gasto y maximizar el rendimiento de tus recursos. Siguiendo las recomendaciones sobre almacenamiento, ciclo de vida de los datos, versionado y seguridad, podrás tomar decisiones más informadas y alineadas con las necesidades específicas de tu proyecto. Además, con las herramientas y APIs disponibles, puedes auditar y ajustar continuamente tu infraestructura para asegurar que siempre estés aprovechando al máximo cada recurso. Con una gestión adecuada, los costos no tienen por qué ser un obstáculo, sino una oportunidad para mejorar la eficiencia y la escalabilidad de tu plataforma en la nube.

Julián Felipe Parra

Technical Specialist

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

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY

+

DATA Engineering

+

GEN IA

+

Te puede interesar

PERSONAL MAPS: conociéndonos más

octubre 24, 2023
LEER MÁS

Tenemos Plan B

septiembre 17, 2020
LEER MÁS

Los Incentivos y el Desarrollo de Negocio en las Telecomunicaciones

octubre 9, 2020
LEER MÁS

FinOps

mayo 20, 2024
LEER MÁS

DataOps

octubre 24, 2023
LEER MÁS

¿Existe el Azar?

noviembre 10, 2021
LEER MÁS

Publicado en: Blog, Tech

¿Cómo pueden las empresas asegurarse de que sus datos estén estructurados, escalables y disponibles cuando se necesiten?

septiembre 13, 2024 by Bluetab

¿Cómo pueden las empresas asegurarse de que sus datos estén estructurados, escalables y disponibles cuando se necesiten?

Rodrigo (SACDOR) Casiano

Data Architect | Data Tech Lead | Data Management | IA Engineer

Actualmente para las empresas impulsadas por los datos, la gestión efectiva e inteligencia artificial se han vuelto primordiales; cada clic, compra, contenido en redes sociales, telemetría de autos, maquinas  e interacción genera información que, cuando se aprovecha correctamente, puede desbloquear nuevas ideas que aportan valor impulsando el crecimiento y la innovación, permitiendo diferenciarlas de otras empresas del mismo sector convirtiendo a la información generada en su ADN, pero ¿Cómo pueden las empresas asegurarse de que sus datos estén bien estructurados, sean escalables y estén disponibles cuando se necesiten? La respuesta radica en una sólida Arquitectura de Datos.

La Arquitectura de Datos es el plano que guía el diseño, la organización y la integración de los sistemas dentro y fuera de una organización, es el fundamento principal sobre el cual se construyen los productos de datos que permiten diferenciar a las empresas. A continuación, exploraremos los pilares clave una Arquitectura de Datos, tomando inspiración del libro «Diseñando Aplicaciones Intensivas en Datos» de Martin Kleppmann.

Pilar 1: Confiabilidad

La confiabilidad es la base de cualquier arquitectura de datos, esto lo hace el pilar más importante entre todos. Hoy más que nunca, las empresas confían en sus datos para tomar decisiones críticas, y datos poco confiables pueden llevar a costosos errores, por ejemplo, en las industrias reguladas como lo es la Banca, los reportes generados para las entidades reguladoras deben ser confiables, de lo contrario podrían ser multados, impactando fuertemente al negocio, no solo en lo económico, en ocasiones también en su reputación, lograr la confiabilidad de los datos implica varias consideraciones:

  • 1.1 Calidad de los Datos: Asegúrese de que los datos sean precisos, consistentes y estén libres de errores. Implemente procesos de homologación, validación y limpieza de datos para mantener una alta calidad de datos, normalmente esto es controlado por un Gobierno de Datos dentro de la empresa.
  • 1.2 Tolerancia a Fallos: Diseñe sistemas que puedan resistir fallos de manera elegante, esto implica redundancia, respaldo y estrategias de conmutación por error, a fin de garantizar la disponibilidad de los datos, para esto se debe considerar un equipo multidiciplinario para diseñar los componetes fisicos o lógicos de la arquitectura.
  • 1.3 Monitoreo y Alertas: Implemente un monitoreo sólido para detectar problemas en tiempo real y configure alertas automatizadas para abordar los problemas de manera expedita, es muy importante no solo contar con el monitoreo de la infraestructura, si no también contar con el monitoreo de los procesos, asegurándose que terminan de forma exitosa, automatizando de preferencia el rollback correspondiente en caso de fallo a fin de evitar errores al dejar procesos incompletos.

Pilar 2: Escalabilidad

A medida que las empresas crecen, también lo hace el volumen de información que manejan, la escalabilidad garantiza que los sistemas de datos puedan manejar cargas crecientes sin degradación del rendimiento. Las consideraciones clave para la escalabilidad incluyen:

  • 2.1 Escalabilidad Horizontal: Diseñe sistemas que puedan expandirse mediante la adición de más máquinas al clúster. Este enfoque, a menudo denominado "escalabilidad horizontal", permite un crecimiento sin problemas, además, hoy en día existen plataformas Cloud como Azure, AWS, GCP, Snowlfake, Databricks entre otras que ayudan a gestionar la escalabilidad de una forma "sencilla", pagando por uso, permitiendo a las empresas ahorrar costos.
  • 2.2 Particionamiento y Fragmentación: Divida los datos en fragmentos más pequeños y manejables a través de técnicas como el particionamiento y la fragmentación, esto permite una distribución y recuperación eficientes de los datos, siendo esto un punto muy importante en soluciones cloud ya que si la eficiencia es proporcional a menores costos y soluciones más rápidas.
  • 2.3 Balanceo de Carga: Implemente el balanceo de carga para distribuir equitativamente las solicitudes de datos entrantes en varios servidores o clústeres. Herramientas como Nginx y HAProxy pueden ayudar en este aspecto, este tipo de componentes se utilizan sobre todo cuando disponibilizamos API que puedan se consumidas por ejemplo el despliegue de un modelo de IA y/o un API de consulta de datos parecido a plataformas como Retaillink.

Pilar 3: Mantenibilidad

La mantenibilidad se trata de garantizar que su arquitectura de datos siga siendo eficiente y manejable a medida que evoluciona, para esto, algunas estrategias son:

  • 3.1 Automatización: Automatice tareas rutinarias como copias de seguridad, actualizaciones y escalabilidad para reducir el esfuerzo manual y minimizar el riesgo de errores humanos.
  • 3.2 Documentación: Mantenga una documentación completa de su arquitectura de datos, modelos de datos y procesos. Esto ayuda en la incorporación de nuevos miembros del equipo y en la solución de problemas, hoy en días es algo que se deja al ultimo lo cual representa un riesgo para las empresas ademas que la curva de nuevos recursos se vuelve mayor teniendo un impacto directo en el tiempo de onboardin y a su vez en temas economicos.
  • 3.3 Control de Versiones: Aplique los principios de control de versiones a los esquemas de datos y las configuraciones, lo que le permite realizar un seguimiento de los cambios y volver atrás cuando sea necesario eficientando los despligues a producción.

Pilar 4: Flexibilidad

En el entorno empresarial actual, la adaptabilidad es crucial. Su arquitectura de datos debe ser lo suficientemente flexible como para adaptarse a los requisitos cambiantes.

  • 4.1 Evolución de Esquemas: Permita cambios en los esquemas sin interrumpir las canalizaciones de datos. Técnicas como la versión de esquemas y el esquema "al leer" pueden ser valiosas asi mismo generando modelo de datos que permitan ir creciendo de forma incremental ayudando a que las nuevas integraciones sean más eficiente.
  • 4.2 Desacoplamiento: Desacople los componentes en su arquitectura de datos para reducir las interdependencias, lo que facilita la sustitución y/o actualización de partes individuales, otro de la beneficios de contar con una arquitectura Desacoplada es ahorro que se genera en la implementación de una Arquitectura de Datos Empresarial.

Pilar 5: Rendimiento

El rendimiento es un aspecto crítico de la arquitectura de datos, especialmente para aplicaciones en tiempo real y de alto rendimiento, este pilar se debe definir junto con los usuarios de la plataforma ya que ellos debran definir los SLAs que debe cumplir la misma. Enfoque en:

  • 5.1 Indexación: Implemente estrategias de indexación adecuadas para acelerar las operaciones de recuperación de datos, especialmente para conjuntos de datos grandes.
  • 5.2 Caché: Utilice mecanismos de caché para almacenar datos de acceso frecuente en la memoria, reduciendo la necesidad de recuperarlos de un almacenamiento más lento, este tipo de soluciones se usan cuanto tenemos aplicaciones que consumen nuestras plataformas de Big Data.
  • 5.3 Optimización de Consultas: Optimice las consultas de bases de datos para minimizar los tiempos de respuesta y el consumo de recursos.

En conclusión, una Arquitectura de Datos bien diseñada constituye la base de los productos de datos. Al priorizar la confiabilidad, la escalabilidad, la mantenibilidad, la flexibilidad y el rendimiento, las empresas pueden aprovechar todo el potencial de sus activos de datos. En una era en la que los datos son un activo estratégico, una sólida Arquitectura de Datos no es solo una opción; es una necesidad para un crecimiento y competitividad sostenibles.

Rodrigo (SACDOR) Casiano

Data Architect | Data Tech Lead | Data Management | IA Engineer

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

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY

+

DATA Engineering

+

GEN IA

+

Te puede interesar

Serverless Microservices

octubre 14, 2021
LEER MÁS

5 errores comunes en Redshift

diciembre 15, 2020
LEER MÁS

Desplegando una plataforma CI/CD escalable con Jenkins y Kubernetes

septiembre 22, 2021
LEER MÁS

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

septiembre 12, 2022
LEER MÁS

Guía avanzada sobre almacenamiento en Snowflake

octubre 3, 2022
LEER MÁS

$ docker run 2021

febrero 2, 2021
LEER MÁS

Publicado en: Blog, Tech

MDM como ventaja competitiva en las organizaciones

junio 18, 2024 by Bluetab

MDM como ventaja competitiva en las organizaciones

Maryury García

Cloud | Data & Analytics

Al igual que los recursos naturales, los datos actúan como el combustible impulsor de la innovación, la toma de decisiones y la creación de valor en diversos sectores. Desde las grandes empresas tecnológicas hasta los pequeños startups, la transformación digital está empoderando a los datos para convertirse en la base que genera conocimiento, optimiza la eficiencia y ofrece experiencias personalizadas a los usuarios.

La Gestión de Datos Maestros (MDM – Master Data Management) juega un papel esencial en proporcionar una estructura sólida para asegurar la integridad, calidad y consistencia de los datos en toda la organización.

A pesar de existir esta disciplina desde mediados de los años 90, algunas organizaciones no han adoptado MDM plenamente, esto puede ser por diversos factores, como la falta de comprensión de los beneficios, el coste, la complejidad y/o mantenimiento.

“Según encuesta de Gartner, el mercado global de MDM se valoró en 14.600 millones de dólares en 2022 y se espera que alcance los 24.000 millones de dólares en 2028, con una tasa de crecimiento anual compuesta (CAGR) del 8,2%”.

Figura 01: CAGR en el mercado global MDM

Antes de sumergirnos en el mundo de MDM, es importante comprender algunos conceptos relevantes del mismo.

Para gestionar los datos maestros, la primera pregunta que nos formulamos es ¿Qué son los datos maestros? Los datos maestros constituyen el conjunto de datos compartidos, esenciales y críticos para la ejecución de un negocio, que tienen vida útil (tiempo de vigencia) y contienen la información clave para el funcionamiento de la organización, como por ejemplo datos de clientes, productos, números de cuenta, entre otros.

Una vez definidos, es importante conocer sus características ya que los datos maestros son aquellos que se caracterizan por ser únicos, persistentes, íntegros, amplia cobertura, entre otros., esto es vital para garantizar la coherencia y calidad.

Por lo tanto, resulta fundamental contar con un enfoque que considere tanto los aspectos organizacionales (identificación de dueños del dato, usuarios impactados y matrices, entre otros) así como los procesos (relacionados a las políticas, flujos, procedimientos y mapeos), por lo tanto, nuestra propuesta como Bluetab sobre este enfoque se resume en cada una de estas dimensiones.

Figura 02: Caso de Uso: Enfoque Datos Maestros

Otro aspecto que considerar desde nuestra experiencia en datos maestros, que resulta ser clave para iniciar con una implementación organizacional, es comprender su “ciclo de vida”, esto es que contenga:

  • Las áreas de negocio input del dato maestro (referidos a las áreas que consumirán la información)
  • Los procesos asociados al dato maestro (que crean, bloquean, reportan, actualizan los atributos del dato maestro, es decir, el tratamiento que tendrá el dato maestro)
  • Las áreas output del dato maestro (referidos a que áreas finalmente mantienen el dato maestro)
  • Todo esto cruzado por los dueños del dato y soportados por políticas asociadas, procedimientos y documentación.
Figura 03: Caso de Uso: Matriz del ciclo de vida del Dato Maestro

La Gestión de los Datos Maestros o MDM es una “disciplina” y ¿por qué? Porque reúne un conjunto de conocimientos, políticas, prácticas, procesos y tecnologías (referido como herramienta tecnológica para recopilar, almacenar, gestionar y analizar los datos maestros). Esto perminte concluir es que es mucho más que una herramienta.

A continuación, proporcionamos algunos ejemplos que permitirán una mejor comprensión del aporrte de una adecuada gestión de datos maestros en diversos sectores:

  • Sector minorista: las empresas minoristas por citar un ejemplo de una empresa de pastelería utilizarían MDM para gestionar datos maestros de catálogo de productos, clientes, proveedores, empleados, recetas, inventario, ubicación; creando un perfil detallado del cliente, con la finalidad de asegurar una experiencia de compra consistente y personalizada en todos los canales de venta.
  • Sector financiero: las instituciones financieras podrían gestionar datos de clientes, cuentas, productos financieros, precio, disponibilidad, transacciones históricas, información crediticia; lo que ayuda a mejorar la precisión y seguridad en las transacciones y operaciones financieras, así como verificar la identidad de sus clientes antes de abrir una cuenta.
  • Sector de salud: en el ámbito de la salud, los datos más importantes son utilizados para gestionar datos de pacientes, datos de procedimientos, datos de diagnóstico, datos de imágenes, instalaciones médicas y medicamentos, garantizando la integridad y privacidad de la información confidencial, por colocar un ejemplo un hospital puede utilizar un MDM para generar un EMR (Registro Médico Electrónico) para cada paciente.
  • Sector de telecomunicaciones: en el ámbito de telecomunicaciones, las empresas utilizan MDM para gestionar los datos maestros de sus dispositivos, servicios, proveedores, clientes y facturación.

En la Gestión de los Datos Maestros se realizan las siguientes operaciones fundamentales: la limpieza de datos, que elimina duplicados; el enriquecimiento de datos, que garantiza registros completos; y el establecimiento de una única fuente de verdad. El tiempo que pueda conllevar dependerá del estado de los registros que tenga la organización y sus objetivos de negocio. A continuación, podemos visualizar las tareas que se realizan:

Figura 04: Tareas claves MDM

Ahora que ya tenemos el concepto más claro, hay que tener en cuenta que la estrategia de la gestión de los datos maestros ponerlos en orden: actualizados, precisos, no redundancia, consistentes e íntegros.

 

¿Qué beneficios brinda la implementación de un MDM?

  • Calidad y consistencia de datos: mejora la calidad de los datos maestros al eliminar duplicados y corregir errores, asegurando la integridad de la información en toda la organización.
  • Eficiencia y ahorro de recursos: ahorra tiempo y recursos al automatizar tareas de limpieza, enriquecimiento y actualización de datos, liberando al personal para tareas más estratégicas.
  • Toma de decisiones informadas: permite la identificación de patrones y tendencias a partir de datos confiables, lo que impulsa la toma de decisiones estratégicas y oportunas.
  • Experiencia del cliente mejorada: mejora la experiencia del cliente al brindar una visión 360 grados del cliente, lo que permite ofrecer interacciones más personalizadas y relevantes.

 

En bluetab hemos ayudado a clientes de diferentes industrias en su estrategia de datos maestros, tanto en la definición, análisis y diseño de la arquitectura como en la implementación de una solución integral. Derivado de ello, compartimos estos 05 pasos que te permitirán iniciar en la gestión de datos maestros:

  1. Enumere sus objetivos y defina un alcance
    Lo primero es identificar ¿cuáles son las entidades de datos que le interesa priorizar como objetivo comercial dentro de la organización?, una vez identificado luego evalúe la cantidad de fuentes, definiciones, excepciones y volúmenes que tienen las entidades.

 

  1. Defina los datos que va a utilizar
    ¿Qué parte de los datos es importante para tomar las decisiones? Puede tratarse simplemente de todos o varios campos del registro para rellenar, como el nombre, la dirección y el número de teléfono. Apóyese de personal de gobierno para la definición.

 

  1. Establezca procesos y owners
    ¿Quién será el responsable de contar con los derechos para modificar o crear los datos? ¿Para qué y cómo se utilizarán estos datos para reforzar o potenciar el negocio?, una vez formulada estas preguntas, es importante contar con un proceso de cómo se tratará la información desde el registro del dato maestros hasta su compartición final (usuarios o aplicaciones).

 

  1. Busque la escalabilidad
    Una vez que ya definió los procesos,  trate de que puedan ser integrados a los cambios que se den más adelante, recuerde tomarse un tiempo para la definición de sus procesos y evite realizar cambios drásticos a futuro.

 

  1. Encuentre la arquitectura de datos correcta, no tome atajos
    Una vez definido y generado los pasos anteriores, es el momento de acercarse con su socio estratégico de Big Data & Analytics que le permitirá garantizar que esas definiciones sean compatibles dentro del sistema o bases de datos que alberguen la información de su compañía.
Figura 05: Primeros Pasos MDM

Consideraciones finales

A partir de nuestra experiencia, sugerimos considerar los siguientes aspectos a la hora de relevar / definir el proceso por cada dominio para la gestión de los datos maestros sujeto al alcance del proyecto:

  • Gestión de rutas:
    • Considerar como el dueño de la creación de los datos maestros los da de alta (de forma automatizada y eliminando el ingreso manual de datos de cualquier otra aplicación) y como cualquier proceso actual de un área / persona centraliza la información del resto de áreas involucradas en el dato maestro de forma manual (emails, llamadas, exceles, etc.). Se debe automatizar en un workflow.
  • Alertas & notificaciones:
    • Se recomienda establecer los plazos para la completitud de los datos por cada área y responsable que actualiza un dato maestro.
    • Se debe sincerar el tiempo de completitud de cada dato entre todas las áreas involucradas, así también se debe configurar las alertas que comuniquen los datos maestros actualizados.
  • Procesos de bloqueo – discontinuación:
    • Una alternativa viable es realizar estos cambios en el operacional y de ahí ser comunicados mediante réplica al MDM.
  • Integración:
    • Evaluar la posibilidad de integrarse con terceros para automatizar proceso de alta en clientes, proveedores, etc. y evitar la manualidad: RENIEC, SUNAT, Google (coordinadas X, Y, Z), u otros agentes evaluando adecuación al negocio.
  • Incorporación de terceros:
    • Considerar la incorporación de clientes y proveedores al inicio de los flujos de creación de datos maestros y en los puntos de actualización.
Figura 06: Aspectos a considerar MDM

En resumen, los datos maestros son los datos comunes más importantes para una organización y son la base de muchos procesos en el día a día a nivel empresarial. La gestión de datos maestros ayuda a garantizar que los mismos sean actualizados, precisos, no redundancia, consistentes, íntegros y compartidos adecuadamente, brindando beneficios tangibles en la calidad de los datos, eficiencia operativa, toma de decisiones informadas y experiencia del cliente. Esto es lo que contribuye al éxito y la competitividad de la organización en un entorno digital cada vez más impulsado por datos.

Si ha sido de interés este artículo, te agradecemos compartirlo y en bluetab estaremos deseosos de escuchar los desafíos y necesidades que tienes en tu organización en cuanto a datos maestros y de referencia.

Maryury García

Cloud | Data & Analytics

¿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

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

mayo 18, 2022
LEER MÁS

Mi experiencia en el mundo de Big Data – Parte I

octubre 14, 2021
LEER MÁS

Conceptos básicos de AWS Glue

julio 22, 2020
LEER MÁS

Workshop Ingeniería del caos sobre Kubernetes con Litmus

julio 7, 2021
LEER MÁS

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

febrero 15, 2022
LEER MÁS

MODELOS DE ENTREGA DE SERVICIOS EN LA NUBE

junio 27, 2022
LEER MÁS

Publicado en: Blog, Tech

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

junio 4, 2024 by Bluetab

Jeanpierre Nuñez
Senior Data Engineer

¿Sabías que los árboles de decisión pueden ayudarte a resolver problemas complejos?

En este artículo, te revelaremos cómo en Bluetab utilizamos esta poderosa herramienta de análisis de datos con el fin de impulsar a las decisiones de nuestros clientes en diversas industrias usando AWS.

Árboles de decisión: herramientas poderosas para la toma de decisiones

Los árboles de decisión son diagramas que representan las posibles opciones, resultados y consecuencias de una decisión. Se construyen a partir de nodos que contienen preguntas o condiciones, y ramas que conectan las respuestas o acciones. De esta forma, se puede visualizar el flujo lógico de la decisión y elegir la mejor alternativa.

En Bluetab, creemos en la toma de decisiones inteligentes basadas en datos. Para lograrlo, utilizamos herramientas poderosas como los árboles de decisión, que son valiosos en una variedad de sectores. A continuación, exploraremos cómo aplicamos los árboles de decisión y los beneficios que ofrecen a nuestros clientes en diferentes industrias.

Clasificación y regresión con árboles de decisión

Clasificación: los árboles de decisión de clasificación son excelentes para segmentar y categorizar datos. En el contexto empresarial, se utilizan para tomar decisiones sobre la asignación de recursos, la identificación de oportunidades de mercado y la personalización de ofertas. En el sector de la salud, los árboles de clasificación ayudan a diagnosticar enfermedades en función de síntomas y pruebas.

Regresión: los árboles de regresión se centran en predecir valores numéricos. Se utilizan para proyectar rendimientos financieros, tasas de crecimiento y otros valores cuantitativos. En el sector financiero, son esenciales para predecir el rendimiento de inversiones y carteras.

Caso práctico: Árboles de decisión en el sector de la salud

Sector de la salud: En el sector de la salud, utilizamos los árboles de decisión para diagnosticar enfermedades en función de síntomas y pruebas. Por ejemplo, si un paciente tiene fiebre, dolor de garganta y tos, el árbol de decisión nos indica que lo más probable es que tenga una infección respiratoria y nos recomienda el tratamiento adecuado.

Beneficios de los árboles de decisión en diferentes sectores

  • Toma de decisiones personalizadas: los árboles de decisión permiten decisiones precisas y personalizadas en función de los datos y las necesidades de cada sector.
  • Eficiencia operativa: al automatizar procesos repetitivos y mejorar la toma de decisiones, las empresas pueden optimizar sus operaciones.

Caso práctico: árboles de decisión en el sector bancario

Sector bancario: En el sector bancario, los árboles de decisión son vitales para la gestión de riesgos y la personalización de servicios. Los bancos utilizan estos árboles para segmentar a los clientes en grupos según su comportamiento financiero, lo que les permite ofrecer productos y servicios financieros a medida. También son esenciales en la evaluación crediticia, donde garantizan préstamos más seguros y tasas de interés adecuadas. Además, los árboles de decisión se aplican en la prevención de fraudes, donde detectan patrones sospechosos y protegen los activos de los clientes.

Beneficios en banca:

  • Gestión de riesgos: los árboles de decisión ayudan a evaluar y gestionar los riesgos crediticios, lo que es esencial en la industria bancaria.
  • Personalización de servicios: los clientes bancarios reciben ofertas personalizadas que se ajustan a sus necesidades financieras, lo que mejora su satisfacción y lealtad.
  • Prevención de fraudes: la detección temprana de transacciones fraudulentas protege a los clientes y a los bancos.

Decisiones Inteligentes en AWS: implementación de árboles de decisión y migración de datos

Introducción: 

En un mundo empresarial en constante evolución, la toma de decisiones informadas es clave para el éxito. Exploraremos ahora cómo la implementación de árboles de decisión en AWS y la migración de datos desde SQL Server pueden empoderar a las organizaciones en diferentes sectores. Analizaremos la arquitectura de soluciones en AWS que permite esta implementación y migración, detallando cada paso del proceso.

Arquitectura en AWS para Implementar árboles de decisión:

  • Ingesta de datos: comenzamos considerando la ingesta de datos desde diversas fuentes. AWS Glue se destaca como una solución versátil que puede conectarse a una amplia variedad de fuentes de datos.
  • Almacenamiento de datos: una vez que los datos se han ingestado, se almacenan de manera centralizada en Amazon S3. Esto proporciona un lugar único para la administración y acceso eficiente a los datos.
  • Procesamiento de datos y generación de árboles de decisión: utilizamos AWS Glue para transformar y preparar los datos para su análisis. En esta etapa, AWS Lambda y AWS SageMaker entran en juego para implementar algoritmos de árboles de decisión, brindando un enfoque avanzado de aprendizaje automático.
  • Análisis y consultas: una vez que se han generado los árboles de decisión, AWS Athena permite realizar consultas SQL interactivas en los datos almacenados en S3. Esto facilita la exploración de datos y la toma de decisiones basadas en los resultados de los árboles.

Migración de datos desde SQL Server a AWS:

  • Ingesta de datos: cuando se trata de la migración de datos desde SQL Server de Microsoft, AWS Database Migration Service (DMS) es una herramienta valiosa. Facilita la migración de bases de datos completas o datos específicos de SQL Server a bases de datos compatibles con AWS, como Amazon RDS o Amazon Redshift.

Arquitectura de solución en AWS utilizando AWS S3, Glue, Lambda, SageMaker, S3 y Athena:

  • Ingesta de datos: utilizamos AWS Database Migration Service (DMS) para transferir datos desde la fuente de datos SQL Server a una base de datos compatible con AWS.
  • Transformación de datos: AWS Glue se encarga de transformar y preparar los datos recién migrados para su análisis.
  • Generación de árboles de decisión: implementamos algoritmos de árboles de decisión utilizando AWS Lambda o AWS SageMaker para llevar a cabo análisis avanzados.
  • Almacenamiento de datos: los datos procesados y los resultados de los árboles de decisión se almacenan en Amazon S3.
  • Consultas y análisis: utilizamos AWS Athena para realizar consultas SQL interactivas en los datos almacenados en S3 y tomar decisiones basadas en los resultados.

Para la implementación de un arbol de clasificación vamos a utilizar los siguientes servicios: Amazon S3, Aws Glue Crawler, Aws Glue Job, IAM , Cloud Watch. 

Se seleccionan como mínimo estos servicios para poder mostrar los beneficios de este modelo.

Creacion del bucket en Amazon S3

Buscaremos ‘S3’ en la barra de busqueda y seleccionaremos el nombre del servicio para visualizar lo siguiente:

Daremos clic en ‘Crear Bucket’ y visualizaremos la siguiente pantalla:

Debemos colocar un nombre que se asocie a nuestro flujo de trabajo y seleccionar tambien la región como minimo.

Colocaran siguiente y podran observan una vista previa del bucket, luego dar en clic en crear bucket:

Para nuestro ejemplo práctico estamos seleccionando un csv publico llamado Iris. 

El conjunto de datos Iris contiene medidas de 150 flores (setosa, versicolor, virginica) con 4 características, usado comúnmente para clasificación.

Lógicamente para un modelo de ML deberiamos brindar una data ya transformada y trabajada con el propósito de tener las caracteristias y hacer las predicciones necesarias.

Daras clic en cargar y seleccionaras el csv:

Finalmente visualizaremos la carga con éxito y ya seremos capaces de obtener esta información desde otro servicios en AWS.

Creación del servicio AWS Glue Crawler

AWS Glue Crawler es una herramienta que descubre y cataloga automáticamente datos almacenados en diversos formatos y ubicaciones, facilitando la preparación y análisis de datos en AWS.

Buscaremos el servicio AWS Glue en la barra de busqueda, nos desplazaremos en la sección lateral izquierdo y daremos clic en Crawlers:

Daremos un nombre a nuestro Crawler y una descripción a elección personal, luego daremos clic en Next:

En el dropdown list de data source elegiremos el servicio de S3.

Luego colocaras Browse S3 y podras seleccionar el bucket creado previamente, deberías ser capaz de visualizar lo siguiente:

En la siguiente seccion podrás seleccionar algun rol si tienes configurado previamente, para este ejemplo crearemos un nuevol, le pondremos un nombre asociado a nuestro proceso.

Luego veremos la selección de nuestra base de datos Catalogo , sin embargo tendremos que crearlo de la siguiente manera dando clic en Add Database:

Ingresamores el nombre de la base de datos asociada a nuestro ejemplo:

Luego podremos agregar un prefijo de forma opcional cuando disponibilice los datos en el catalogo de AWS Glue, podría estar vacio también si no lo necesita. Seleccionaremos ejecución a demanda para nuestro caso.

Finalmente en la siguiente pestaña podremos visualizar creado nuestro crawler y le daremos clic en ‘Run crawler’. Deberiamos ver lo siguiente:

Creacion del Job en AWS Glue

Luego en la misma seccion lateral izquierda de AWS Glue buscaremos la seccion de ETL Job y crearemos un flujo con la interfaz grafica, haciendolo de esta manera podremos tener facilmente el código generado para tener acceso a nuestra fuente.

Luego de agregas nuestro objeto de catálogo y seleccionar lo que hemos creado previamente. Deberiamos visualizar el job de la siguiente manera:

Hasta aquí ya procederemos a colocar un nombre al job y agregar nuestro código. Haremos uso de las siguientes librerias:

`DecisionTreeClassifier` construye un modelo de árbol de decisión para clasificación.

`MulticlassClassificationEvaluator` evalúa su rendimiento multiclase. `CrossValidator` realiza validación cruzada, ajustando hiperparámetros con `ParamGridBuilder`.

Juntos, permiten la construcción, evaluación y ajuste eficaz de modelos de árboles de clasificación en PySpark MLlib.

A continuación, se muestra el código utilizado:

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
from pyspark.ml.feature import StringIndexer, VectorAssembler
from pyspark.ml.evaluation import MulticlassClassificationEvaluator
from pyspark.ml.tuning import CrossValidator, ParamGridBuilder
from pyspark.ml.classification import DecisionTreeClassifier
from pyspark.ml import Pipeline
from pyspark.sql.functions import col,udf
from pyspark.sql.window import Window
from pyspark.sql import functions as F
from awsglue.dynamicframe import DynamicFrame
from pyspark.sql.types import ArrayType, DoubleType

# Inicializar contexto de Spark y Glue
args = getResolvedOptions(sys.argv, ["JOB_NAME"])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args["JOB_NAME"], args)
# Nombre de la base de datos y tabla en el catálogo de AWS Glue
database_name = "db-decision-tree-iris"
input_table_name = "mliris_csv"
output_table_name = "mliris_results"
# Crear DynamicFrame desde el catálogo de Glue
input_dyf = glueContext.create_dynamic_frame.from_catalog(
    database=database_name,
    table_name=input_table_name,
)
# Convertir DynamicFrame a DataFrame
df = input_dyf.toDF()
# Añadir una columna de índice
df = df.withColumn("row_index", F.monotonically_increasing_id())
# Preprocessing: StringIndexer for categorical labels
stringIndexer  = StringIndexer(inputCol="species", outputCol="label")
# Preprocessing: VectorAssembler for feature columns
assembler = VectorAssembler(inputCols=["sepal_length", "sepal_width", "petal_length", "petal_width"], outputCol="features")
#data = assembler.transform(data)
# Split data into training and testing sets
train_data, test_data = df.randomSplit([0.8, 0.2], seed=42)
# Create a Decision Tree Classifier instance
dt = DecisionTreeClassifier(labelCol='label', featuresCol='features')
# Assemble all the steps (indexing, assembling, and model building) into a pipeline.
pipeline = Pipeline(stages=[stringIndexer, assembler, dt])
paramGrid = ParamGridBuilder() \
    .addGrid(dt.maxDepth,[3, 5, 7]) \
    .addGrid(dt.minInstancesPerNode, [1,3,5]) \
    .build()
crossval = CrossValidator(estimator=pipeline, estimatorParamMaps=paramGrid,
                      evaluator=MulticlassClassificationEvaluator(
                      labelCol='label', predictionCol='prediction', metricName='accuracy'),
                      numFolds=5)

cvModel = crossval.fit(train_data)
best_model = cvModel.bestModel
predictions = best_model.transform(test_data)
predictions.show(100,truncate=False)


# Evaluate the model performance
evaluator = MulticlassClassificationEvaluator(labelCol="label", predictionCol="prediction", metricName="accuracy")
accuracy = evaluator.evaluate(predictions)
print(f"Test Accuracy: {accuracy:.2f}")
precision = evaluator.evaluate(predictions, {evaluator.metricName: "weightedPrecision"})
print(f"Weighted Precision: {precision:.2f}")
recall = evaluator.evaluate(predictions, {evaluator.metricName: "weightedRecall"})
print(f"Weighted Recall: {recall:.2f}")
f1_score = evaluator.evaluate(predictions, {evaluator.metricName: "f1"})
print(f"F1 Score: {f1_score:.2f}")
# Acceder al modelo de árbol de decisión dentro del pipeline
tree_model = best_model.stages[-1]  # Suponiendo que el clasificador de árbol de decisión es el último paso en tu pipeline
# Obtener el resumen del modelo
print(tree_model._java_obj.toDebugString())
output_path = "s3://bucket-training-tree-decision/output/parquet_data/"
# Función UDF para convertir VectorUDT a lista
vector_to_list_udf = udf(lambda v: v.toArray().tolist(), returnType=ArrayType(DoubleType()))
# Convertir la columna probability a lista
df = predictions.withColumn("probability", vector_to_list_udf(col("probability")))
df = df.withColumn("rawPrediction", vector_to_list_udf(col("rawPrediction")))
df = df.withColumn("features", vector_to_list_udf(col("features")))
df_subset = df.select(*["sepal_length", "sepal_width", "petal_length", "petal_width", "species", "row_index", "label", "features", "prediction", "probability"])
# Escribir el DataFrame en formato Parquet en S3
df_subset.write.parquet(output_path, mode="overwrite")
# Finalizar trabajo
job.commit()


Como se visualiza el estado del job se encuentra en ‘Succeeded’:

Configuración de políticas mediante S3 y IAM

A continuación, debemos también configurar las políticas de IAM para el acceso desde Glue hacia S3. Iremos a la sección de permisos en nuestro bucket:

Editaremos la política de la siguiente manera:

Luego en IAM a nuestro rol de machine que creamos en la sección de AWS Grawler, añadiremos el rol de s3Full Access. Seleccionamos nuestro rol:

Verificamos que tengamos nuestra relacion de confianza de la siguiente manera:

Luego añadiremos el permiso de AmazonS3FullAccess.

Finalmente al agregar el permiso deberiamos de ver nuestros permisos de la siguiente manera:

Ahora mediante CloudWatch podremos visualizar el log de nuestro job, verificar si se guardo correctamente nuestro modelo y tambien poder ver una previsualización de las reglas y predicciones.

Aquí podemos visualizar nuestros resultados e incluso la regla de clasificación:

Aquí se puede visualizar los valores de Accuracy , weighted precision y recall, y el F1 Score. A continuación, se explica el significado de cada métrica.

  1. Test Accuracy (Exactitud de Prueba):
    • Significado: proporción de predicciones correctas respecto al total de predicciones en el conjunto de prueba.
    • Utilidad: mide la precisión general del modelo y es especialmente útil cuando las clases están balanceadas.
  2. Weighted Recall (Recuperación Ponderada):
    • Significado: promedio ponderado de las tasas de verdaderos positivos para cada clase.
    • Utilidad: evalúa la capacidad del modelo para recuperar instancias de cada clase, considerando el desequilibrio en la distribución de las clases.
  3. Weighted Precision (Precisión Ponderada):
    • Significado: promedio ponderado de las precisiones para cada clase.
    • Utilidad: indica la proporción de instancias correctamente clasificadas entre las que el modelo predijo como positivas, considerando el desequilibrio de clases
  4. F1 Score:
    • Significado: media armónica de precisión y recuperación. Cuantifica la relación equilibrada entre la precisión y la capacidad de recuperación del modelo.
    • Utilidad: útil en problemas de clasificación desbalanceados, ya que considera tanto los falsos positivos como los falsos negativos, proporcionando una métrica global de rendimiento del modelo. Un F1 Score alto indica un equilibrio entre precisión y recuperación.

Finalmente se guardaron los resultados de nuestro modelo en nuestro bucket en un folder llamado output, deberia verse de la siguiente manera:

Conclusión

Esta arquitectura de solución en AWS permite a las organizaciones no solo implementar árboles de decisión eficaces sino también migrar datos desde sistemas heredados como SQL Server. Ambos procesos se combinan para empoderar a las organizaciones en la toma de decisiones informadas, mejorando la eficiencia operativa y maximizando las oportunidades de mercado. Como puedes ver, los árboles de decisión son una herramienta muy útil para tomar decisiones inteligentes basadas en datos.

En Bluetab, te ayudamos a implementarlos en tu organización para que puedas mejorar tu eficiencia operativa, personalizar tus ofertas y aprovechar las oportunidades de mercado. Si quieres saber más sobre cómo podemos ayudarte, no dudes en contactarnos.

Tabla de contenidos
  1. ¿Sabías que los árboles de decisión pueden ayudarte a resolver problemas complejos?
  2. Creacion del bucket en Amazon S3
  3. Creación del servicio AWS Glue Crawler
  4. Creacion del Job en AWS Glue
  5. Configuración de políticas mediante S3 y IAM

Publicado en: Blog, Practices, Tech

FinOps

mayo 20, 2024 by Bluetab

FinOps

La Ingeniería del Ahorro en la Era de la Nube y como aplicarlo funcional y técnicamente

Francis Josue De La Cruz

Big Data Architect

Wiener Morán

Data Engineer

En el mundo empresarial actual, la eficiencia en la gestión de costos en la nube se ha convertido en una prioridad. Aquí es donde entra en juego FinOps (Financial Operations), una práctica emergente que combina estratégicas presupuestales, la tecnología de la información (servicios en la nube), estrategias de negocios para maximizar el valor de la nube y sobretodo la inventiva y desarrollo para tratar de sacar provecho económico. En este artículo queremos compartir desde Bluetab, cómo nuestros clientes pueden implementar FinOps, con un enfoque particular en los servicios de Azure de Microsoft.

Estos servicios en la nube brindan una poderosa flexibilidad en la construcción de soluciones y hacen realidad la meta común de pasar del CAPEX al OPEX. Esto se enfrenta al nuevo desafío que las empresas ahora tienen, de monitorear cientos o miles de recursos a la vez para mantener las finanzas alineadas a los presupuestos tecnológicos definidos. Una buena (y necesaria) práctica para esto, es el monitoreo activo de los recursos y costos cloud, lo que permite identificar oportunidades de optimización de recursos no utilizados o infrautilizados, para aplicar los cambios de configuración, prendido y apagado oportuno que pueden conllevar a una significativa reducción de costos.

¿Qué es FinOps?

FinOps es un enfoque, paradigma cultural y operativo que permite a las organizaciones equilibrar y alinear mejor los costos con el valor en entornos de nube. Se trata de una práctica colaborativa, que involucra a equipos de finanzas, operaciones y desarrollo, para gestionar los costos de la nube de manera más efectiva y eficiente.

¿En qué etapa del proyecto se debe considerar el FinOps?

El FinOps, o la gestión financiera de la nube, se debe considerar desde las primeras etapas de un proyecto que involucra servicios en la nube, ya que ayuda a entender y optimizar los costos asociados.

No siempre demanda tener un equipo dedicado desde el inicio, especialmente en proyectos pequeños o medianos, pero sí requiere que alguien asuma la responsabilidad de monitorear y optimizar los costos. A medida que el proyecto crece y el gasto en la nube se incrementa, puede ser beneficioso establecer un equipo dedicado o función de FinOps para gestionar estos costos de manera más efectiva.

Pasos para Implementar FinOps en una empresa usando Servicios de Azure

1. Comprensión y adopción de la cultura FinOps

Educación y Conciencia: capacite a su equipo sobre los principios de FinOps. Esto incluye entender cómo el gasto en la nube afecta a la empresa y cómo pueden contribuir a una gestión más eficiente.

Combinando la Agilidad (Scrum-finOps) en la empresa

Es posible combinar el framework scrum con el enfoque FinOps agregando nuevas ceremonias enfocadas en el mismo, con la finalidad de implementar nuevas prácticas de comunicación y gestión. Por ejemplo, reuniones semanales donde se presentan como va el presupuesto del proyecto y reuniones diarias de cómo va el consumo de los servicios en los diferentes ambientes (development, quality assurance y production).

Colaboración interdepartamental: fomente la colaboración entre los equipos de finanzas, operaciones y desarrollo. La comunicación efectiva es clave para el éxito de FinOps.

2. Análisis del gasto actual en Azure

Auditoría de servicios: realice un inventario de todos los servicios de Azure utilizados. Comprenda cómo se están utilizando y si son esenciales para las operaciones comerciales.

Herramientas de gestión de costos: utilice herramientas como Azure Cost Management y Billing para obtener una visión clara del gasto.

3. Optimización de recursos y costos

Identificación de recursos subutilizados: busque instancias, almacenamiento o servicios que estén infrautilizados. Azure ofrece herramientas para identificar estos recursos.

Implementación de mejores prácticas: aplique prácticas recomendadas para la optimización de recursos, como el escalado automático, la elección de instancias reservadas o el apagado de recursos no utilizados.

3. Optimización de recursos y costos

Establecimiento de presupuestos: defina presupuestos claros para diferentes equipos o proyectos. Azure Cost Management puede ayudar en este proceso.

Pronósticos de gasto: antes de empezar el desarrollo de ahorro de costos en una empresa, se debe tener claro el uso y gasto actual, para estimar el ahorro proyectado. Imagínese cuanto ahorraría en una empresa con más de diez mil pipelines.

Ejemplo: estrategias de ahorro de costos de migración All-purpose hacia Job Clusters en 1 aplicación realtime (13,5 horas prendidas) ahorro de 44% aproximadamente.

Tipos Dbu/hora #DBU/hora Horas activas RT #Clusters Total diario Total mensual Total Anual
Job Cluster-REALTIME
$0,30
3,75
13,5
1
$15,19
$455,63
$5.467,50
All Purpose-REALTIME
$0,55
3,75
13,5
1
$27,84
$835,31
$10.023,75

5. Gobernanza y políticas de uso

Políticas de uso: establezca políticas claras para el uso de recursos en Azure. Esto incluye quién puede aprovisionar recursos y qué tipos de recursos están permitidos.

Automatización de la gobernanza: implemente políticas automatizadas para garantizar el cumplimiento y evitar gastos innecesarios.

Comparativa de características de servicios de gobernanza de costos:

Google Cost Management AWS Cost Management Microsoft Cost Management
Informes y paneles de control
Visualización de informes de costos, personalización mediante Looker Studio.
Proporciona informe de gastos y sus detalles (AWS Cost Explorer)
Reportes y análisis de la organización. Extensible el análisis con Power BI.
Control de Acceso
Uso de políticas para permisos granulares y nivel de jerarquía. Puede establecer quien visualiza los costos y quien realiza los pagos.
Permite establecer mecanismos de gobernanza y seguimiento de la información de facturación en la organización
Control de acceso basado en roles de Azure RBAC. Los usuarios con Azure Enterprise usan una combinación de permisos del Azure Portal y Enterprise (EA)
Presupuesto y alertas
Configuración de presupuestos que envíen alerta por correo si se supera el umbral.
Presupuestos con notificaciones de alerta automáticas (AWS Budgets)
Las vistas de presupuestos pueden estar limitadas por suscripción, grupos de recursos o colección de recursos. Soporta alertas.
Recomendaciones
Recomendaciones inteligentes para optimizar costos, las cuales son fácilmente aplicables.
Alinea el tamaño de los recursos asignados con la demanda real de la carga de trabajo (Rightsizing Recommendations)
Optimizaciones de costos según recomendaciones usando Azure Advisor.
Cuotas
Configuracion de limites de cuotas, que restringe la cantidad de recursos que se pueden utilizar.
Mediante el Service Quotas, limitan los servicios siendo los valores máximos para los recursos.
Dispone de diferentes clasificaciones de límites, algunos de ellos: generales, grupo de administración, suscripción, grupo de recursos, plantilla.

6. Desarrollo e innovación

Ahorro de Costos con el Despliegue de Job Clusters en Databricks

En el mundo de la ciencia de datos y el análisis de grandes volúmenes de datos, Databricks se ha establecido como una plataforma líder. Una de las características clave de Databricks es su capacidad para manejar diferentes tipos de clústeres, siendo los más comunes los «All-Purpose Clusters» y los «Job Clusters». En este artículo, nos centraremos en cómo el despliegue de Job Clusters puede ser una estrategia efectiva para ahorrar costos, especialmente en comparación con los All-Purpose Clusters.

Diferencia entre All-Purpose Clusters y Job Clusters

Antes de sumergirnos en las estrategias de ahorro de costos, es crucial entender la diferencia entre estos dos tipos de clústeres:

All-Purpose Clusters: están diseñados para ser utilizados de manera interactiva y pueden ser compartidos por varios usuarios. Son ideales para el desarrollo y la exploración de datos.

Job Clusters: se crean específicamente para ejecutar un trabajo y se cierran automáticamente una vez que el trabajo ha finalizado. Son ideales para trabajos programados y procesos automatizados. La desventaja en el entorno de Azure de este tipo de despliegue de cluster es que al ser más barato no tiene funciones de gestión de control de uso.

Ejemplo Despliegue Job Cluster

				
					# Configuración de Databricks API
DATABRICKS_INSTANCE = 'https://tu-instancia-databricks.com'
TOKEN = 'tu-token-de-acceso'
JOB_ID = 'tu-job-id'

# Headers para la autenticación
HEADERS = {
    'Authorization': f'Bearer {TOKEN}'
}

# Verificar el estado del job
def check_job_status(job_id):
    response = requests.get(f'{DATABRICKS_INSTANCE}/api/2.0/jobs/get?job_id={job_id}', headers=HEADERS)
    if response.status_code == 200:
        return response.json()['state']
    else:
        raise Exception("Error al obtener el estado del job")

# Cancelar el job si está en ejecución
def cancel_job(job_id):
    response = requests.post(f'{DATABRICKS_INSTANCE}/api/2.0/jobs/runs/cancel', json={"job_id": job_id}, headers=HEADERS)
    if response.status_code != 200:
        raise Exception("Error al cancelar el job")

# Desplegar el job
def deploy_job(job_id):
    response = requests.post(f'{DATABRICKS_INSTANCE}/api/2.0/jobs/run-now', json={"job_id": job_id}, headers=HEADERS)
    if response.status_code == 200:
        return response.json()['run_id']
    else:
        raise Exception("Error al desplegar el job")

# Verificar si el job está corriendo y esperar hasta que lo esté
def wait_for_job_to_run(job_id):
    while True:
        status = check_job_status(job_id)
        if status['life_cycle_state'] == 'RUNNING':
            print("El job está corriendo.")
            break
        elif status['life_cycle_state'] == 'TERMINATED':
            print("El job ha terminado o ha sido cancelado.")
            break
        elif status['life_cycle_state'] == 'PENDING':
            print("El job está pendiente de ejecución, esperando...")
            time.sleep(10)  # Esperar un tiempo antes de volver a verificar
        else:
            raise Exception(f"Estado del job desconocido: {status['life_cycle_state']}")

# Script principal
if __name__ == '__main__':
    # Verificar si el job está actualmente en ejecución y cancelarlo si es necesario
    try:
        status = check_job_status(JOB_ID)
        if status['life_cycle_state'] == 'RUNNING':
            print("Cancelando el job en ejecución...")
            cancel_job(JOB_ID)
    except Exception as e:
        print(f"Error al verificar o cancelar el job: {e}")

    # Desplegar el job
    try:
        print("Desplegando el job...")
        run_id = deploy_job(JOB_ID)
        print(f"Job desplegado con run_id: {run_id}")
    except Exception as e:
        print(f"Error al desplegar el job: {e}")

    # Esperar a que el job esté en 'RUNNING'
    try:
        wait_for_job_to_run(JOB_ID)
    except Exception as e:
        print(f"Error al esperar que el job esté corriendo: {e}")

				
			

Automatización y programación Cosmos DB:

Automatizar y programar un script para reducir al mínimo los Request Units (RU/s) en Azure Cosmos DB puede ayudar a optimizar los costos, especialmente durante los períodos de baja demanda o basándose en métricas de rendimiento o un horario predefinido. Puedes hacer esto usando PowerShell o Python primero debes obtener el throughput actual (RU/s configuradas) del contenedor y luego calcular el 1% de este valor para establecer el nuevo throughput. A continuación, un ejemplo básico en ambos lenguajes.

Usando PowerShell

				
					from azure.cosmos import CosmosClient
import os

# Configuración de Azure Cosmos DB
URL = os.environ.get('AZURE_COSMOS_DB_URL')
KEY = os.environ.get('AZURE_COSMOS_DB_KEY')
DATABASE_NAME = 'tuBaseDeDatos'
CONTAINER_NAME = 'tuContenedor'

# Inicializar cliente de Cosmos DB
client = CosmosClient(URL, credential=KEY)
database = client.get_database_client(DATABASE_NAME)
container = database.get_container_client(CONTAINER_NAME)

# Obtener el throughput actual
throughput_properties = container.read_throughput()
if throughput_properties:
    current_ru = throughput_properties['throughput']
    min_ru = max(int(current_ru * 0.01), 400)  # Calcula el 1%, pero no menos de 400 RU/s

    # Actualizar RU/s
    try:
        container.replace_throughput(min_ru)
    except Exception as e:
        print(f"Error al actualizar RU/s: {e}") 

				
			

Usando Python para reducir RUS bajo demanda o horario de bajo rendimiento

				
					from azure.cosmos import CosmosClient
import os
from datetime import datetime

# Configuración de Azure Cosmos DB
URL = os.environ.get('AZURE_COSMOS_DB_URL')
KEY = os.environ.get('AZURE_COSMOS_DB_KEY')
DATABASE_NAME = 'tuBaseDeDatos'
CONTAINER_NAME = 'tuContenedor'

# Inicializar cliente de Cosmos DB
client = CosmosClient(URL, credential=KEY)
database = client.get_database_client(DATABASE_NAME)
container = database.get_container_client(CONTAINER_NAME)

# Obtener la hora actual
current_hour = datetime.now().hour

# Definir RU/s según la hora del día
if 0 <= current_hour < 7 or 18 <= current_hour < 24:
    new_ru = 400  # RU/s más bajas durante la noche
else:
    new_ru = 1000  # RU/s estándar durante el día

# Actualizar RU/s
container.replace_throughput(new_ru)

				
			

7. Monitoreo continuo y mejora

Revisiones regulares: realice revisiones periódicas del gasto y la utilización de recursos.

Ajustes y mejoras: esté dispuesto a ajustar políticas y prácticas según sea necesario para mejorar continuamente la eficiencia del gasto.

Capacitación y conciencia continua

Un factor diferencial de este tipo de servicios y acompañamiento a nuestros socios tecnológicos es la posibilidad de descubrir, probar a escala y medir objetivamente los beneficios de cada plan de optimización de recursos y costos en sus plataformas, mismo que se plantea como resultado de una revisión regular, proactiva y basada en los cambios liberados por los proveedores de nube.

En Bluetab estamos comprometidos con el ahorro y nuestros especialistas en administración de datos con gusto podrán ayudarte a alcanzar niveles eficientes de monitoreo de costos, servicios y consumo en nubes, que apalanquen tu inversión tecnológica y gastos de operación.

7. Monitoreo continuo y mejora

Implementar FinOps en una empresa que utiliza servicios de Azure no es solo una estrategia para reducir costos, sino una transformación cultural y operativa. Requiere un cambio en la forma en que las organizaciones piensan y actúan respecto al uso de la nube.

Al adoptar FinOps, las empresas pueden no solo optimizar sus gastos en la nube, sino también mejorar la colaboración entre equipos, aumentar la agilidad y fomentar una mayor innovación.

 

Francis Josue De La Cruz

Big Data Architect

Wiener Morán

Data Engineer

¿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

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

mayo 9, 2023
LEER MÁS

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

noviembre 17, 2021
LEER MÁS

Algunas de las capacidades de Matillion ETL en Google Cloud

julio 11, 2022
LEER MÁS

Bluetab se incorporará a IBM

julio 9, 2021
LEER MÁS

Usando los Grandes Modelos de Lenguaje en información privada

marzo 11, 2024
LEER MÁS

Cambios de liderazgo en Bluetab EMEA

abril 3, 2024
LEER MÁS

Publicado en: Blog, Tech

Potencia Tu Negocio con GenAI y GCP: Simple y para Todos

marzo 27, 2024 by Bluetab

Alfonso Zamora
Cloud Engineer

Introducción

El objetivo principal de este artículo es presentar una solución para el análisis y la ingeniería de datos desde el punto de vista del personal de negocio, sin requerir unos conocimientos técnicos especializados. 

Las compañías disponen de una gran cantidad de procesos de ingeniería del dato para sacarle el mayor valor a su negocio, y en ocasiones, soluciones muy complejas para el caso de uso requerido. Desde aquí, proponemos simplificar la operativa para que un usuario de negocio, que anteriormente no podía llevar a cabo el desarrollo y la implementación de la parte técnica, ahora será autosuficiente, y podrá implementar sus propias soluciones técnicas con lenguaje natural.

Para poder cumplir nuestro objetivo, vamos a hacer uso de distintos servicios de la plataforma Google Cloud para crear tanto la infraestructura necesaria como los distintos componentes tecnológicos para poder sacar todo el valor a la información empresarial.

Antes de comenzar

Antes de comenzar con el desarrollo del artículo, vamos a explicar algunos conceptos básicos sobre los servicios y sobre distintos frameworks de trabajo que vamos a utilizar para la implementación:

  1. Cloud Storage[1]: Es un servicio de almacenamiento en la nube proporcionado por Google Cloud Platform (GCP) que permite a los usuarios almacenar y recuperar datos de manera segura y escalable.
  2. BigQuery[2]: Es un servicio de análisis de datos totalmente administrado que permite realizar consultas SQL en conjuntos de datos masivos en GCP. Es especialmente eficaz para el análisis de datos a gran escala.
  3. Terraform[3]: Es una herramienta de infraestructura como código (IaC) desarrollada por HashiCorp. Permite a los usuarios describir y gestionar la infraestructura utilizando archivos de configuración en el lenguaje HashiCorp Configuration Language (HCL). Con Terraform, puedes definir recursos y proveedores de manera declarativa, facilitando la creación y gestión de infraestructuras en plataformas como AWS, Azure y Google Cloud.
  4. PySpark[4]: Es una interfaz de Python para Apache Spark, un marco de procesamiento distribuido de código abierto. PySpark facilita el desarrollo de aplicaciones de análisis de datos paralelas y distribuidas utilizando la potencia de Spark.
  5. Dataproc[5]: Es un servicio de gestión de clústeres para Apache Spark y Hadoop en GCP que permite ejecutar eficientemente tareas de análisis y procesamiento de datos a gran escala. Dataproc admite la ejecución de código PySpark, facilitando la realización de operaciones distribuidas en grandes conjuntos de datos en la infraestructura de Google Cloud.

Qué es un LLM 

Un LLM (Large Language Model) es un tipo de algoritmo de inteligencia artificial (IA) que utiliza técnicas de deep learning y enormes conjuntos de datos para comprender, resumir, generar y predecir nuevos contenidos. Un ejemplo de LLM podría ser ChatGPT que hace uso del modelo GPT desarrollado por OpenAI. 

En nuestro caso, vamos a hacer uso del modelo Codey[6] (code-bison) que es un modelo implementado por Google que está optimizado para generar código ya que ha sido entrenado para esta especialización que se encuentra dentro del stack de VertexAI[7]

Y no solo es importante el modelo que vamos a utilizar, sino también el cómo lo vamos a utilizar. Con esto, me refiero a que es necesario comprender los parámetros de entrada que afectan directamente a las respuestas que nos dará nuestro modelo, en los que podemos destacar los siguientes:

  • Temperatura (temperature): Este parámetro controla la aleatoriedad en las predicciones del modelo. Una temperatura baja, como 0.1, genera resultados más deterministas y enfocados, mientras que una temperatura alta, como 0.8, introduce más variabilidad y creatividad en las respuestas del modelo.
  • Prefix (Prompt): El prompt es el texto de entrada que se proporciona al modelo para iniciar la generación de texto. La elección del prompt es crucial, ya que guía al modelo sobre la tarea específica que se espera realizar. La formulación del prompt puede influir en la calidad y relevancia de las respuestas del modelo, aunque hay que tener en cuenta la longitud para que cumpla con el  número máximo de tokens de entrada que es 6144.
  • Tokens de salida (max_output_tokens): Este parámetro limita el número máximo de tokens que se generarán en la salida. Controlar este valor es útil para evitar respuestas excesivamente largas o para ajustar la longitud de la salida según los requisitos específicos de la aplicación.
  • Recuento de candidatos (candidate_count): Este parámetro controla el número de respuestas candidatas que el modelo genera antes de seleccionar la mejor opción. Un valor más alto puede ser útil para explorar diversas respuestas potenciales, pero también aumentará el costo computacional.

Desarrollo del prompt

Una vez que hemos definido los parámetros y sabemos bien para qué sirve cada uno de ellos y comprendemos lo que es un prompt, vamos a enfocarnos en cómo utilizarlo e implementar uno que se pueda adaptar a nuestras necesidades.

Como se ha comentado anteriormente, el objetivo es generar tanto código Pyspark como terraform para poder realizar las tareas de creación de infraestructura y tratamiento del dato. Como son tareas totalmente distintas, como primera decisión importante para nuestro prompt se ha optado por dividirlo en dos partes específicas para que cada prompt esté entrenado con ejemplos para generar un lenguaje u otro.

Para cada uno de los prompt, se hace una introducción para especificar cuál va a ser el objetivo y qué peticiones se van a realizar, y después una serie de ejemplos en los que se le da un input en lenguaje natural simulando una petición, y posteriormente también se le da el output deseado para asignar el texto al código específico. El objetivo es generar un prompt estructurado que pueda ser procesado de manera eficiente por el modelo para que en los siguientes casos, pueda asociar los ejemplos que tiene disponibles con respuestas adecuadas.

Vamos a poner en práctica estos pequeños tips para ver una de las entradas al prompt de terraform:

input: I need to read a file named `myfile.csv` inside the folder `data/input` in a bucket called `application-data-input`, and I need to create a new dataset and table in BigQuery called `tst_tf_ai`. The process has to read the file, remove the first three characters of the name, and write the result in BigQuery. The schema of the table will be ‘name’ of String type and ‘surname’ of String type. The infrastructure has to be deployed in the project `project-cloud-223` in GCP, and region `europe-southwest1`.
output: «`hcl
terraform {
 required_version = «>= 0.15»
 required_providers {
  google = «~> 5.0»
 }
}

resource «google_storage_bucket» «temporary_files» { 
 project       = «project-cloud-223» 
 name          = «temporary-files-dataproc» 
 location      = «europe-southwest1» 
 force_destroy = true 
} 

resource «google_storage_bucket» «bucket1» { 
 project       = «project-cloud-223» 
 name          = «application-data-input» 
 location      = «europe-southwest1» 
 force_destroy = true 
} 

resource «google_storage_bucket_object» «folder1» {
 name    = «data/input/»
 bucket  = google_storage_bucket.bucket1.name
 content = » «
}

resource «google_bigquery_dataset» «dataset» { 
 project       = «project-cloud-223» 
 dataset_id    = «tst_tf_ai» 
 friendly_name = «tst_tf_ai» 
 description   = «Description» 
 location      = «europe-southwest1» 
} 

resource «google_bigquery_table» «table» { 
 project              = «project-cloud-223» 
 dataset_id           = google_bigquery_dataset.dataset.dataset_id 
 deletion_protection  = false
 table_id             = «tst_tf_ai» 
 schema               = <<EOF
[ 
 { 
  «name»: «name», 
  «type»: «STRING», 
  «mode»: «NULLABLE», 
  «description»: «The name» 
 }, 
 { 
  «name»: «surname», 
  «type»: «STRING», 
  «mode»: «NULLABLE», 
  «description»: «The surname» 
 }
] 
EOF 
} 
«`

Author Name

Es importante implementar ejemplos lo más parecido posible a tu caso de uso para que las respuestas sean más precisas, y también que tenga bastantes ejemplos con variedad de peticiones para que sea más inteligente a la hora de devolver las respuestas. Una de las prácticas para que sea más interactiva la implementación del prompt, puede ser ir probando con distintas peticiones, y si no es capaz de hacer lo que se le ha pedido, se debería modificar las instrucciones.

Como hemos podido observar, el desarrollo del prompt sí necesitamos conocimientos técnicos para poder traducir las peticiones a código, por lo que esta tarea sí se debería de abordar por una persona técnica para posteriormente evadir a la persona de negocio. En otras palabras, necesitamos que una persona técnica genere la primera base de conocimiento para que luego las personas de negocio puedan hacer uso de este tipo de herramientas.

También se ha podido ver, que la generación de código en terraform es más compleja que la generación en Pyspark, por lo que se han requerido de más ejemplos de entrada en la realización del prompt de terraform para que se ajuste a nuestro caso de uso. Por ejemplo, hemos aplicado en los ejemplos que en terraform siempre cree un bucket temporal (temporary-files-dataproc) para que pueda ser utilizado por Dataproc.

Casos prácticos

Se han realizado tres ejemplos con peticiones distintas, requiriendo más o menos infraestructura y transformaciones para ver si nuestro prompt es lo suficientemente robusto. 

En el archivo ai_gen.py vemos el código necesario para hacer las peticiones y los tres ejemplos, en el que cabe destacar la configuración escogida para los parámetros del modelo:

  • Se ha decidido darle valor 1 a candidate_count para que no tenga más que una respuesta final válida para devolver. Además que como se ha comentado, aumentar este número también lleva aumento de costes.
  • El max_output_tokens se ha decidido 2048 que es el mayor número de tokens para este modelo, ya que si se necesita generar una respuesta con diversas transformaciones, no falle por esta limitación.
  • La temperatura se ha variado entre el código terraform y Pyspark, para terraform se ha optado por 0 para que siempre dé la respuesta que se considera más cercana a nuestro prompt para que no genere más de lo estrictamente necesario para nuestro objetivo. En cambio para Pyspark se ha optado por 0.2 que es una temperatura baja para que no sea muy creativo, pero para que también pueda darnos diversas respuestas con cada llamada para también poder hacer pruebas de rendimiento entre ellas.

Vamos a realizar un ejemplo de petición que está disponible en el siguiente repositorio github, en el que está detallado en el README paso por paso para poder ejecutarlo tú mismo. La petición es la siguiente:

In the realm of ‘customer_table,’ my objective is the seamless integration of pivotal fields such as ‘customer_id’, ‘name’, and ‘email’. These components promise to furnish crucial insights into the essence of our valued customer base.

Conversely, when delving into the nuances of ‘sales_table,’ the envisioned tapestry includes essential elements like ‘order_id’ ‘product’ ‘price’, ‘amount’ and ‘customer_id’. Theseattributes, meticulously curated, will play a pivotal role in the nuanced exploration and analysis of sales-related data.

The ‘bigtable_info’ table will have all the fields resulting from the union of the two tables, ‘customer_table’ and ‘sales_table.’ Here, the outcome of joining the two tables by the ‘customer_id’ numeric field will be stored.

Furthermore, as part of our meticulous data collection strategy, I plan to inaugurate a dedicated Google Cloud Storage bucket christened ‘sales-etl-bucket.’ This repository is strategically designed to serve as a robust container for collating data, particularly hailing from CSV files. This endeavor is set to enhance the efficiency and organizational prowess of our data management processes.

To enhance the structure, two distinct subfolders, ‘input/sales’ and ‘input/customers’ have been ingeniously incorporated within the ‘sales-etl-bucket,’ ensuring a refined organization of the incoming data streams.

You will need to read the CSV files within the ‘input/sales’ folder to write the data into the ‘sales_table’. Additionally, you should perform the same operation with the files from the ‘input/customers’ folder to write the data into the ‘customer_table’. Finally, you are required to perform a join between the sales and customers information based on the ‘customer_id’ number field and write the merged information into the ‘bigtable_info’.

Author Name

Ejecutamos  y vamos a analizar las salidas generadas en las carpetas generated/customers/python/etl.py y generated/terraform/main.tf.:

terraform {
 required_version = ">= 0.15"
 required_providers {
   google = "~> 5.0"
 }
}


resource "google_storage_bucket" "temporary_files" {
 project       = "my-cloud-project"
 name          = "temporary-files-dataproc"
 location      = "europe-southwest1"
 force_destroy = true
}


resource "google_storage_bucket" "sales_etl_bucket" {
 project       = "my-cloud-project"
 name          = "sales-etl-bucket"
 location      = "europe-southwest1"
 force_destroy = true
}


resource "google_storage_bucket_object" "sales_folder" {
 name    = "input/sales/"
 bucket  = google_storage_bucket.sales_etl_bucket.name
 content = " "
}


resource "google_storage_bucket_object" "customers_folder" {
 name    = "input/customers/"
 bucket  = google_storage_bucket.sales_etl_bucket.name
 content = " "
}


resource "google_bigquery_dataset" "raw_sales_data" {
 project       = "my-cloud-project"
 dataset_id    = "raw_sales_data"
 friendly_name = "Raw Sales Data"
 description   = "This dataset contains the raw sales data."
 location      = "europe-southwest1"
}


resource "google_bigquery_table" "customer_table" {
 project              = "my-cloud-project"
 dataset_id           = google_bigquery_dataset.raw_sales_data.dataset_id
 deletion_protection  = false
 table_id             = "customer_table"
 schema               = <<EOF
[
 {
   "name": "customer_id",
   "type": "INT64",
   "mode": "REQUIRED",
   "description": "The customer ID."
 },
 {
   "name": "name",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The customer's name."
 },
 {
   "name": "email",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The customer's email address."
 }
]
EOF
}


resource "google_bigquery_table" "sales_table" {
 project              = "my-cloud-project"
 dataset_id           = google_bigquery_dataset.raw_sales_data.dataset_id
 deletion_protection  = false
 table_id             = "sales_table"
 schema               = <<EOF
[
 {
   "name": "order_id",
   "type": "INT64",
   "mode": "REQUIRED",
   "description": "The order ID."
 },
 {
   "name": "product",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The product name."
 },
 {
   "name": "price",
   "type": "FLOAT64",
   "mode": "NULLABLE",
   "description": "The product price."
 },
 {
   "name": "amount",
   "type": "INT64",
   "mode": "NULLABLE",
   "description": "The product amount."
 },
 {
   "name": "customer_id",
   "type": "INT64",
   "mode": "REQUIRED",
   "description": "The customer ID."
 }
]
EOF
}


resource "google_bigquery_dataset" "master_sales_data" {
 project       = "my-cloud-project"
 dataset_id    = "master_sales_data"
 friendly_name = "Master Sales Data"
 description   = "This dataset contains the master sales data."
 location      = "europe-southwest1"
}


resource "google_bigquery_table" "bigtable_info" {
 project              = "my-cloud-project"
 dataset_id           = google_bigquery_dataset.master_sales_data.dataset_id
 deletion_protection  = false
 table_id             = "bigtable_info"
 schema               = <<EOF
[
 {
   "name": "customer_id",
   "type": "INT64",
   "mode": "REQUIRED",
   "description": "The customer ID."
 },
 {
   "name": "name",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The customer's name."
 },
 {
   "name": "email",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The customer's email address."
 },
 {
   "name": "order_id",
   "type": "INT64",
   "mode": "REQUIRED",
   "description": "The order ID."
 },
 {
   "name": "product",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The product name."
 },
 {
   "name": "price",
   "type": "FLOAT64",
   "mode": "NULLABLE",
   "description": "The product price."
 },
 {
   "name": "amount",
   "type": "INT64",
   "mode": "NULLABLE",
   "description": "The product amount."
 }
]
EOF
}


Vemos que va a añadir un bucket con dos carpetas para poder subir los datos a la carpeta correspondiente dependiendo si es sales o customer. También ha creado dos datasets, uno para la capa de raw para tener los datos según nos han venido de origen con las tablas de customers y sales, y el segundo dataset para la tabla final que almacenará el resultado de juntar la información de ambas tablas.

Vamos a revisar el código pyspark:

from pyspark.sql import SparkSession
from pyspark.sql import functions as F


# Configure Spark session
spark = SparkSession.builder.appName("SalesETL").getOrCreate()


# Define file paths
sales_path = "gs://sales-etl-bucket/input/sales/*.csv"
customers_path = "gs://sales-etl-bucket/input/customers/*.csv"


# Read CSV files into DataFrames
sales_df = spark.read.csv(sales_path, header=True, inferSchema=True)
customers_df = spark.read.csv(customers_path, header=True, inferSchema=True)


# Write tables to BigQuery
sales_df.write.format("bigquery") \
   .option("temporaryGcsBucket", "temporary-files-dataproc") \
   .option("table",  "raw_sales_data.sales_table") \
   .mode("overwrite") \
   .save()
customers_df.write.format("bigquery") \
   .option("temporaryGcsBucket", "temporary-files-dataproc") \
   .option("table",  "raw_sales_data.customer_table") \
   .mode("overwrite") \
   .save()


# Join sales and customers tables
bigtable_info_df = sales_df.join(customers_df, on="customer_id", how="inner")


# Write joined table to BigQuery
bigtable_info_df.write.format("bigquery") \
   .option("temporaryGcsBucket", "temporary-files-dataproc") \
   .option("table",  "master_sales_data.bigtable_info") \
   .mode("overwrite") \
   .save()


# Stop the Spark session
spark.stop()

Se puede observar que el código generado realiza la lectura por cada una de las carpetas e inserta cada dato en su tabla correspondiente. 

Para poder asegurarnos de que el ejemplo está bien realizado, podemos seguir los pasos del README en el repositorio GitHub[8] para aplicar los cambios en el código terraform, subir los ficheros de ejemplo que tenemos en la carpeta example_data y a ejecutar un Batch en Dataproc. 

Finalmente, vemos si la información que se ha almacenado en BigQuery es correcta:

  • Tabla customer:
  • Tabla sales:
  • Tabla final:

De esta forma, hemos conseguido de a través de lenguaje natural, tener un proceso funcional totalmente operativo. Hay otro ejemplo que se puede ejecutar, aunque también animo a hacer más ejemplos, o incluso mejorar el prompt, para poder meterle ejemplos más complejos, y también adaptarlo a tu caso de uso.

Conclusiones y Recomendaciones

Al ser ejemplos muy concretos sobre unas tecnologías tan concretas, cuando se hace un cambio en el prompt en cualquier ejemplo puede afectar a los resultados, o también, modificar alguna palabra de la petición de entrada. Esto se traduce en que el prompt no es lo suficientemente robusto como para poder asimilar distintas expresiones sin afectar al código generado. Para poder tener un prompt y un sistema productivo, se necesita más entrenamiento y distinta variedad tanto de soluciones, peticiones, expresiones,. … Con todo ello, finalmente podremos tener una primera versión que poder presentar a nuestro usuario de negocio para que sea autónomo.

Especificar el máximo detalle posible a un LLM es crucial para obtener resultados precisos y contextuales. Aquí hay varios consejos que debemos tener en cuenta para poder tener un resultado adecuado:

  • Claridad y Concisión:
    • Sé claro y conciso en tu prompt, evitando oraciones largas y complicadas.
    • Define claramente el problema o la tarea que deseas que el modelo aborde.
  • Especificidad:
    • Proporciona detalles específicos sobre lo que estás buscando. Cuanto más preciso seas, mejores resultados obtendrás.
  • Variabilidad y Diversidad:
    • Considera incluir diferentes tipos de ejemplos o casos para evaluar la capacidad del modelo para manejar la variabilidad.
  • Feedback Iterativo:
    • Si es posible, realiza iteraciones en tu prompt basándote en los resultados obtenidos y el feedback del modelo.
  • Prueba y Ajuste:
    • Antes de usar el prompt de manera extensa, realiza pruebas con ejemplos y ajusta según sea necesario para obtener resultados deseados.

Perspectivas Futuras

En el ámbito de LLM, las líneas futuras de desarrollo se centran en mejorar la eficiencia y la accesibilidad de la implementación de modelos de lenguaje. Aquí se detallan algunas mejoras clave que podrían potenciar significativamente la experiencia del usuario y la eficacia del sistema:

1. Uso de distintos modelos de LLM:

La inclusión de una función que permita a los usuarios comparar los resultados generados por diferentes modelos sería esencial. Esta característica proporcionaría a los usuarios información valiosa sobre el rendimiento relativo de los modelos disponibles, ayudándoles a seleccionar el modelo más adecuado para sus necesidades específicas en términos de precisión, velocidad y recursos requeridos.

2. Capacidad de retroalimentación del usuario:

Implementar un sistema de retroalimentación que permita a los usuarios calificar y proporcionar comentarios sobre las respuestas generadas podría ser útil para mejorar continuamente la calidad del modelo. Esta información podría utilizarse para ajustar y refinar el modelo a lo largo del tiempo, adaptándose a las preferencias y necesidades cambiantes de los usuarios.

3. RAG (Retrieval-augmented generation)

RAG (Retrieval-augmented generation) es un enfoque que combina la generación de texto y la recuperación de información para mejorar las respuestas de los modelos de lenguaje. Implica el uso de mecanismos de recuperación para obtener información relevante de una base de datos o corpus textual, que luego se integra en el proceso de generación de texto para mejorar la calidad y la coherencia de las respuestas generadas.

Enlaces de interés

Cloud Storage[1]: https://cloud.google.com/storage/docs

BigQuery[2]: https://cloud.google.com/bigquery/docs

Terraform[3]: https://developer.hashicorp.com/terraform/docs

PySpark[4]: https://spark.apache.org/docs/latest/api/python/index.html

Dataproc[5]: https://cloud.google.com/dataproc/docs

Codey[6]: https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/code-generation

VertexAI[7]: https://cloud.google.com/vertex-ai/docs

GitHub[8]: https://github.com/alfonsozamorac/etl-genai

Tabla de contenidos
  1. Introducción
  2. Antes de comenzar
  3. Qué es un LLM 
  4. Desarrollo del prompt
  5. Casos prácticos

Publicado en: Blog, Practices, Tech

  • Página 1
  • Página 2
  • Página 3
  • Páginas intermedias omitidas …
  • Página 8
  • Ir a la página siguiente »

Footer

LegalPrivacidadPolítica de cookies

Patrono

Patrocinador

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