• 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

Blog

DataOps

octubre 24, 2023 by Bluetab

DataOps

Walter Talaverano

Microsoft Certified | Certified

Introducción

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

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

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

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

 

Definición de DataOps

DataOps es un conjunto de prácticas que buscan aumentar la agilidad y colaboración en los equipos de datos. Se basa en los principios y prácticas de DevOps adaptados a las necesidades específicas de los proyectos relacionados con datos.

DataOps pretende acabar con la separación que tradicionalmente existe entre los equipos de desarrollo, operaciones y análisis de datos. Para ello, busca mejorar la colaboración y comunicación entre estos, uniéndolos en torno a un objetivo común.

Al integrar prácticas ágiles, automatización y control de versiones provenientes de DevOps, DataOps permite a las compañías gestionar los datos de forma más eficiente y efectiva. Con DataOps se logra reducir sustancialmente el tiempo que transcurre entre la recolección de datos y su implementación en soluciones de negocio.

De esta manera, DataOps habilita una gestión ágil de los datos, donde éstos fluyen rápidamente entre los equipos. Los datos de calidad están disponibles de forma confiable para alimentar la toma de decisiones y la creación de valor para el negocio de forma continua.

Las características clave de DataOps incluyen:

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

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

 

Contexto sobre la necesidad de DataOps en proyectos de datos

Tradicionalmente, los proyectos relacionados con datos han sido gestionados de forma manual y aislada. Los equipos de ingeniería, ciencia de datos e inteligencia de negocios trabajan en silos, lo que lleva a:

  • Procesos propensos a errores al realizarse manualmente
  • Retrasos en la entrega de valor al negocio 
  • Dificultad para rastrear el linaje de los datos
  • Problemas de calidad de datos
  • Reinvención de soluciones existentes
  • Limitada colaboración entre equipos

Estas problemáticas se han vuelto más evidentes con el crecimiento exponencial en volumen y complejidad de los datos. Las organizaciones requieren aprovechar los datos de manera ágil para soportar la toma de decisiones.

DataOps surge como respuesta a estas necesidades, implementando prácticas probadas en ingeniería de software como DevOps. Permite gestionar los datos de manera ágil, confiable y eficiente.

Los beneficios de adoptar dataOps incluyen:

  • Automatización de tareas manuales, reduciendo errores
  • Entrega rápida de valor al negocio 
  • Trazabilidad y linaje de datos
  • Democratización de datos de calidad 
  • Reutilización de soluciones
  • Mejor colaboración entre equipos
  • Toma de decisiones informada y ágil

Dado el veloz crecimiento en datos, DataOps se ha convertido en un imperativo para que las organizaciones puedan obtener valor de sus datos de forma eficiente y continua. Es una evolución necesaria en la forma en que se gestionan los proyectos relacionados con datos.

 

¿Cómo aplicar DataOps en un proyecto?

En bluetab tenemos amplia experiencia trabajando con clientes en la implementación de distintos servicios de manejo de datos, ayudándoles a adoptar prácticas maduras de DevOps. Sabemos que sin un enfoque adecuado, el uso de estas herramientas puede presentar desafíos en el control de versiones y flujos de despliegue.

Es por esto que guiamos a nuestros clientes en la aplicación de metodologías ágiles como GitFlow, lo cual les permite gestionar sus pipelines de datos de forma escalable y obtener valor de negocio de manera continua. Nuestro conocimiento y experiencia en DataOps permite a nuestros clientes maximizar el potencial de herramientas como en el caso que le presentamos a continuación.

 

Caso: Data Factory

Azure Data Factoryz (ADF) es una plataforma de integración de datos en la nube de Microsoft, que permite automatizar de forma flexible el movimiento y transformación de datos. Esta herramienta se ha vuelto muy popular en empresas para reemplazar los tradicionales ETL.

Sin embargo, la adopción de ADF no siempre se realiza aplicando las mejores prácticas de gestión. Errores comunes se relacionan con el control de versiones y los flujos de despliegue. Tradicionalmente, ADF se gestiona de la siguiente manera:

  • Un único repositorio Git para todo el desarrollo
  • La rama de publicación (adf_publish) se usa para despliegues a producción
  • Una rama de colaboración (main/master) para el trabajo en equipo y para generar la rama de publicación
  • Despliegues manuales a los distintos ambientes

Esta aproximación presenta limitaciones. Por ejemplo, no permite generar artefactos de ramas diferentes a la de colaboración. Esto dificulta la aplicación de parches rápidos a producción.

Para maximizar los beneficios de ADF, es recomendable implementar prácticas maduras de DevOps como GitFlow. Esto mejora el control de versiones, habilita entrega continua y facilita el despliegue y colaboración entre equipos. Adoptando estas metodologías, las organizaciones pueden gestionar ADF de forma ágil y escalable.

El trabajo simultáneo de múltiples ingenieros de datos sobre una misma instancia de Azure Data Factory puede ocasionar problemas si no se gestiona adecuadamente el flujo de colaboración y despliegue. Al realizar cambios sobre distintas ramas se pueden generar conflictos entre los desarrollos de diferentes miembros del equipo. Además, realizar modificaciones en la configuración cambiando la rama de publicación (adf_publish por defecto) o la de colaboración dificulta el seguimiento de la versión desplegada en producción.

Para evitar estas situaciones, es recomendable implementar un flujo de trabajo estandarizado como GitFlow. De esta manera se separan claramente las ramas de desarrollo y feature de las de entrega (release) y publicación (main). Así se reduce la fricción entre desarrolladores y se mantiene trazabilidad sobre lo implementado en el entorno productivo. La adopción de GitFlow promueve las buenas prácticas en el versionado y despliegue de Data Factory.


Es posible aplicar GitFlow a un DataFactory

Para ello se puede cambiar al siguiente flujo de trabajo:

La imagen muestra un flujo de trabajo basado en GitFlow aplicado a Azure Data Factory. La rama «develop» se utiliza para colaboración y las ramas «feature» para el trabajo individual. Además, se incorporan las ramas «release» para manejar versiones candidatas a producción, y «hotfix» con «bugfix» para correcciones rápidas. Una mejora clave es el uso de tags para versionar la rama «main» con los cambios desplegados a producción.

Esta implementación también incluye un flujo CI/CD independiente de las herramientas nativas de ADF. Los artefactos se generan a partir de una librería NPM configurada en el repositorio mediante el archivo packages.json:

{
  "scripts":{
     "build":"node node_modules/@microsoft/azure-data-factory-utilities/lib/index" 
  },

  "dependencies":{
    "@microsoft/azure-data-factory-utilities":"^1.0.0"
  }
} 

De esta manera se mejora el control de versiones, trazabilidad y colaboración entre desarrolladores. El uso de prácticas recomendadas como GitFlow en ADF potencia la entrega continua de valor a través de un pipeline de CI/CD estandarizado.

La librería /@microsoft/azure-data-factory-utilities/ permite validar y compilar el Data Factory, al compilar se obtiene como artefacto un ARM template que luego se despliega en los distintos ambientes.

Entonces el pipeline completo con el uso de esta librería se vería de la siguiente manera:

trigger: 
  branch:
    include:
      - develop
      - main
      - feature/*
      - hotfix/*
      - release/*
      - bugfix/*


pool:
  vmImage: 'ubuntu-latest'


steps:


# Installs Node and the npm packages saved in your package.json file in the build
- task: NodeTool@0
  inputs:
    versionSpec: '14.x'
  displayName: 'Install Node.js'


- task: Npm@1
  inputs:
    command: 'install'
    workingDir: '$(Build.Repository.LocalPath)' #replace with the package.json folder
    verbose: true
  displayName: 'Install npm package'


# Validates all of the Data Factory resources in the repository. You'll get the same validation errors as when "Validate All" is selected.
# Enter the appropriate subscription and name for the source factory. Either of the "Validate" or "Validate and Generate ARM temmplate" options are required to perform validation. Running both is unnecessary.
- task: Npm@1
  inputs:
    command: 'custom'
    workingDir: '$(Build.Repository.LocalPath)' #replace with the package.json folder
    customCommand: 'run build validate $(Build.Repository.LocalPath) /subscriptions/################'
  displayName: 'Validate'


# Validate and then generate the ARM template into the destination folder, which is the same as selecting "Publish" from the UX.
# The ARM template generated isn't published to the live version of the factory. Deployment should be done by using a CI/CD pipeline. 


- task: Npm@1
  inputs:
    command: 'custom'
    workingDir: '$(Build.Repository.LocalPath)' #replace with the package.json folder
    customCommand: 'run build export $(Build.Repository.LocalPath) /subscriptions/################ "ArmTemplate"'
  displayName: 'Validate and Generate ARM template'


# Publish the artifact to be used as a source for a release pipeline.


- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.Repository.LocalPath)/ArmTemplate' #replace with the package.json folder
    artifact: 'ArmTemplates'
    publishLocation: 'pipeline'
 

Una vez obtenido el ArmTemplate del DataFactory se puede desplegar de forma automatizada con otro pipeline de despliegue, esto se puede realizar de la forma tradicional mediante releases de Azure Devops.

Lo que hemos presentado muestra los beneficios de adoptar prácticas ágiles de DevOps en la gestión de datos a través de DataOps. Hemos compartido un caso práctico de cómo aplicar metodologías maduras como GitFlow en Azure Data Factory, logrando un mejor control de versiones, colaboración entre equipos y entrega continua de valor.

Los invitamos a conocer Bluetab y nuestra experiencia en estas prácticas sustentadas en múltiples implementaciones en Perú y la región. Será un gusto poder asesorarlos en la automatización de sus procesos de datos, adoptando prácticas ágiles probadas que les permitirán obtener valor de sus datos de forma eficiente y continua. Juntos podemos diseñar una estrategia DataOps efectiva, customizada a sus necesidades específicas.

Walter Talaverano

Microsoft Certified | Certified

¿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

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

febrero 15, 2022
LEER MÁS

Análisis de vulnerabilidades en contenedores con trivy

marzo 22, 2024
LEER MÁS

¿Qué está pasando en el mundo de la AI?

marzo 6, 2023
LEER MÁS

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

junio 7, 2023
LEER MÁS

Espiando a tu kubernetes con kubewatch

septiembre 14, 2020
LEER MÁS

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

febrero 23, 2023
LEER MÁS

Publicado en: Blog, Tech

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

octubre 16, 2023 by Bluetab

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

Deygerson Méndez

Data Engineer

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

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

 

¿Qué es Microsoft Fabric?

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

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

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

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

  • Amplia gama de capacidades integradas: Esto quiere decir que proporciona una suite completa de capacidades de análisis profundamente integradas, abarcando desde la ingeniería de datos, la ciencia de datos y el análisis en tiempo real.
  • Toma decisiones informadas: Gracias a la analítica avanzada de Microsoft Fabric, podrá tomar decisiones basadas en datos sólidos, impulsando así su estrategia empresarial.
  • Más eficiencia, menos esfuerzo: Al automatizar procesos repetitivos, Microsoft Fabric le libera para que pueda concentrarse en tareas más importantes y creativas.
  • Colaboración sin fronteras: La capacidad de colaborar en tiempo real entre equipos, independientemente de su ubicación, fomenta la creatividad y la innovación.
  • Gestión y gobernanza centralizadas: Con una sólida administración, Microsoft Fabric ofrece gobernanza y control en todas las experiencias.

 

Herramientas especializadas para cada necesidad:

Conviene especificar que, Microsoft Fabric nos ofrece un conjunto completo de experiencias de análisis diseñadas para trabajar conjuntamente sin problemas, cada una de ellas se adapta a un rol y tarea específica:

  • OneLake: Proporciona una ubicación unificada para almacenar todos los datos de la organización, donde se dan las experiencias. 

 

  • Synapse Data Warehousing: Ofrece un rendimiento líder en SQL y separa el proceso de almacenamiento, escalando independientemente cada componente.

Synapse Data Engineering: Proporciona una plataforma Spark de primer nivel, para transformar datos a gran escala y democratizar el uso de los datos.

  • Data Factory: Combina la simplicidad de Power Query con la potencia de Azure Data Factory, conectándote a más de 200 orígenes de datos.
  • Synapse Data Science: Permite crear, implementar y desplegar modelos de aprendizaje automático con facilidad, conectándose a Azure Machine Learning.
  • Synapse Real-Time Analytics: Puede transmitir grandes volúmenes de datos a la base de datos de KQL, con una latencia de pocos segundos, después usar un conjunto de consultas KQL para analizar y visualizar los resultados en informes de Power BI.
  • Power BI: La plataforma líder en inteligencia empresarial que permite tomar decisiones fundamentadas basadas en los datos.

Reducción de costos a través de capacidades unificadas:

En la actualidad, es común que los sistemas analíticos fusionen productos de diversos proveedores en un solo proyecto. Operando de forma independiente, implica una distribución de capacidad de cómputo en múltiples sistemas. Cuando uno de estos sistemas no se encuentra en uso, su potencial queda inhabilitado, lo que genera un notable desperdicio de recursos.

Fabric simplifica de manera significativa, la adquisición y gestión de recursos, ya que tendrás la posibilidad de adquirir un único conjunto de recursos computacionales, que potencian todas las operaciones, generando una reducción sustancial de costos, dado que cualquier unidad de cómputo sin uso puede ser aprovechada por cualquier otra operación. 

 

Impulsado por inteligencia artificial:

Gracias a la integración de Copilot (asistente de programación impulsado por inteligencia artificial desarrollado por GitHub), tendrás la capacidad de utilizar el lenguaje conversacional para desarrollar flujos, pipelines de datos, generar código, idear modelos de aprendizaje automático o visualizar los resultados obtenidos. Incluso podrás crear tus propias experiencias de lenguaje conversacional que combinen los modelos de Azure OpenAI Service.

 

Para conocer más acerca del servicio podrías ingresar al siguiente enlace: 

https://www.microsoft.com/es-es/microsoft-fabric

 

Entonces, ¿estás preparado para dar el salto? 

Aunque Microsoft Fabric se encuentra en su fase de prelanzamiento, ha sido meticulosamente diseñado para desafiar las convenciones y llevar a su empresa a un nivel completamente nuevo. 

Puedes suscribirte a la evaluación gratuita del servicio, sin necesidad de suministrar información de una tarjeta de crédito, en el siguiente enlace: https://learn.microsoft.com/es-es/fabric/get-started/fabric-trial

 

A modo de conclusión, Microsoft Fabric puede agregar valor y a la vez estarás listo para afrontar nuevos retos, crear experiencias excepcionales para tus clientes y alcanzar los objetivos en el análisis empresarial que son demandados por tu organización. 

Mediante su uso, los usuarios tendrán la capacidad de emplear un único producto que posee una estructura y experiencia cohesionadas, otorgando todas las competencias esenciales para que los desarrolladores extraigan conocimientos de los datos y los presenten a los interesados comerciales. 

Gracias a su enfoque (SaaS), todos los aspectos se fusionan y ajustan de manera automática, habilitando a los usuarios a registrarse rápidamente y empezar a obtener un valor empresarial tangible en cuestión de minutos. En Bluetab América, an IBM Company, nos encontramos entusiasmados por el potencial de esta nueva solución y estamos preparados con el mejor staff de profesionales, para ser un aliado estratégico en la implementación de este emocionante servicio.

Deygerson Méndez

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

Gobierno de Datos: ¿tendencia o necesidad?

octubre 13, 2022
LEER MÁS

LakeHouse Streaming en AWS con Apache Flink y Hudi

abril 11, 2023
LEER MÁS

Tenemos Plan B

septiembre 17, 2020
LEER MÁS

Algunas de las capacidades de Matillion ETL en Google Cloud

julio 11, 2022
LEER MÁS

$ docker run 2021

febrero 2, 2021
LEER MÁS

Conceptos básicos de AWS Glue

julio 22, 2020
LEER MÁS

Publicado en: Blog, Tech

Azure Data Studio y Copilot

octubre 11, 2023 by Bluetab

Azure Data Studio y Copilot

Marco LLapapasca

Enterprise Architect

La inteligencia artificial (IA) ha dejado de ser un mero concepto futurista para convertirse en una realidad tangible que está transformando la forma en que las empresas operan y cómo los profesionales tecnológicos desarrollan soluciones. 

Esta revolución no se limita únicamente a la automatización de tareas o a la creación de asistentes virtuales; va más allá, redefiniendo paradigmas y abriendo puertas a posibilidades antes inimaginables.

En el ámbito empresarial, la IA está potenciando la toma de decisiones, optimizando procesos y creando nuevas oportunidades de negocio. Para quienes están al frente del desarrollo tecnológico, representa una herramienta que amplía la creatividad, mejora la eficiencia y redefine los límites de lo que es posible.

Desde la perspectiva de Bluetab, expertos en el manejo y análisis de datos, es evidente que la IA está reconfigurando el panorama de la tecnología de la información. Una muestra clara de esta transformación es la reciente innovación conocida como “Copilot” integrada en Azure Data Studio, una herramienta líder en la administración de bases de datos. 

Esta innovación no solo promete cambiar la forma en que desarrollamos código, sino que también augura un futuro donde la sinergia entre la IA y la gestión de datos desbloqueará potenciales que hoy apenas comenzamos a vislumbrar.

En este contexto, es esencial comprender cómo la inteligencia artificial está moldeando el mundo tecnológico y empresarial, y cómo en empresas como Bluetab estamos al frente de esta revolución, aprovechando las oportunidades y enfrentando los desafíos que presentan, con visión, talento y casos que han sido puesto a prueba.

¿Qué es Copilot?

Copilot es un asistente de programación impulsado por inteligencia artificial desarrollado por GitHub, que fue presentado al público a mediados del 2021. Este asistente ha sido diseñado con un propósito principal: ofrecer sugerencias de código en tiempo real mientras estás desarrollando un programa. Pero, ¿qué es lo interesante? Es que se basa en el contenido previamente escrito para anticiparse a tu próximo paso.

El corazón de Copilot es Codex, un sistema que opera de forma similar a GPT-3. Codex tiene la capacidad de comprender el contexto proporcionado por el código del usuario y, a partir de ello, sintetizar nuevas líneas de código que se alineen con las intenciones del programador.

La conexión con Microsoft

GitHub, la empresa detrás de Copilot, fue adquirida por Microsoft en junio de 2018. No sorprende, entonces, que Copilot haya sido integrado en la suite de aplicaciones Microsoft 365, siendo útil en herramientas como Word, Excel, PowerPoint, Outlook, Teams, entre otras.

Link: https://news.microsoft.com/es-xl/presentamos-microsoft-365-copilot-su-copiloto-para-el-trabajo/

Copilot y Azure Data Studio

El poder de Copilot no se limita a las aplicaciones de ofimática. Como hemos comentado, ahora también ha sido integrado en Azure Data Studio. Esta herramienta es una solución multiplataforma de código abierto que facilita la creación y administración de bases de datos en SQL, T-SQL, sql cmd y PowerShell. Es compatible con Windows, macOS y Linux, haciendo que la herramienta sea extremadamente versátil, ideal tanto para proyectos heredados on premise como para aquellos basados en la nube.

¿Cómo comenzar?

Si estás listo para experimentar esta integración, sigue estos pasos:

  • Instalación de Azure Data Studio:
    Comienza por descargar e instalar Azure Data Studio. Puedes hacerlo directamente desde Link: https://learn.microsoft.com/en-us/sql/azure-data-studio/download-azure-data-studio?view=sql-server-ver16&tabs=redhat-install%2Credhat-uninstall
  • Configura la de conexión.
    Una vez instalado, agregar una nueva conexión SQL. New -> New connection

Como nosotros, vas a realizar una conexión local a Microsoft SQL Server, la cadena de conexión debería lucir así: Server=localhost\SQLEXPRESS01;Database=master;Trusted_Connection=True; 

Finalmente, nos debería quedar de la siguiente forma:

  • Instalación de extensiones:
    Azure Data Studio cuenta con una variedad de extensiones que potencian su funcionalidad. Procede a instalar y configurar la extensión que necesites para tu proyecto. En nuestro caso vamos a utilizar la extensión de:

    GitHub Copilot: Ofrece sugerencias de código en tiempo real. Puedes obtener sugerencias simplemente comenzando a escribir el código que deseas, o incluso escribiendo un comentario en lenguaje natural que describa lo que deseas que haga el código.
  • Configuración de la base de datos Northwind:
    Con Azure Data Studio ya configurado, es el momento perfecto para instalar la base de datos de ejemplo Northwind. Esta base es ideal para familiarizarte con las funcionalidades del programa. Puedes encontrar las instrucciones detalladas para su instalación en Link: https://gist.github.com/jmalarcon/e98d20735d17b3160766c041060d1902

Finalmente, tendremos la base de datos Northwind instalada:

Ahora, vamos a probar Copilot.

  • Definición y prueba de recomendaciones de Copilot:
    Vamos a interpretar y definir el comentario “/* agrupar y mostrar la cantidad de productos por categoría */”. Al hacerlo, pondremos a prueba las sugerencias que Copilot nos ofrece, para evaluar su precisión y relevancia.
  • Generación automática de script:
    Es impresionante observar cómo, con la ayuda de herramientas avanzadas, se nos presenta un script generado automáticamente, manteniendo una sintaxis SQL impecable.
  • Visualización del script generado:
    Tras seguir las recomendaciones y ajustes, así es como luce nuestro script final.
  • Abordando el error de «Invalid object name ‘dbo.categoria'»:
    Al ejecutar nuestro script, nos topamos con un obstáculo: el error “Invalid object name ‘dbo.categoria’.”. Un análisis minucioso de las tablas ‘Categories’ y ‘Products’ revela discrepancias en la nomenclatura. Es esencial asegurarse de que los nombres de las tablas y columnas sean consistentes para evitar este tipo de problemas. 

¿A qué se debe esto?

Las herramientas basadas en inteligencia artificial, como Copilot, necesitan ser correctamente configuradas. En términos más sencillos, debemos «entrenarlas» o, de manera más precisa, proporcionarles la metadata de cada tabla. Al hacerlo, permitimos que la IA tome en cuenta esta información para hacer sugerencias más precisas y coherentes al momento de generar scripts.

La solución es sencilla y directa. Al ejecutar una consulta ‘SELECT’ en cada tabla involucrada, Copilot procederá automáticamente a escanear la tabla y recoger su metadata. Una vez obtenida esta información, la herramienta estará más informada y alineada con la estructura real de nuestra base de datos, permitiéndonos trabajar con mayor precisión y evitando inconvenientes similares en el futuro.

Re-evaluación y recomendaciones ajustadas:
Con las correcciones realizadas, volvemos a probar las recomendaciones. Esta vez, Copilot sugiere un script que considera las columnas correctas, demostrando su capacidad adaptativa

Resultado final:

Con las correcciones implementadas y las recomendaciones ajustadas, obtenemos un resultado final optimizado y preciso.

Estos puntos optimizados ofrecen una narrativa más clara y estructurada, facilitando la comprensión del proceso y los desafíos enfrentados.

La integración de Copilot en Azure Data Studio ha transformado el panorama del desarrollo y administración de bases de datos. Esta herramienta, que promete hacer el trabajo más intuitivo y eficiente, ha demostrado ser un aliado valioso en el ámbito tecnológico. Sin embargo, como toda herramienta, su eficacia radica en cómo se utiliza. A partir de nuestra experiencia en Bluetab, nos gustaría compartir algunas lecciones aprendidas y recomendaciones para maximizar el potencial de Copilot:

  • Verificación de nomenclatura: asegúrese siempre de revisar y validar la nomenclatura de tablas y columnas. Copilot es poderoso, pero también se basa en la consistencia de los datos con los que trabaja.
  • Pruebas continuas: no confíe ciegamente en las recomendaciones automáticas. Siempre es esencial realizar pruebas y validaciones para garantizar que el código generado sea el adecuado para su caso específico.
  • Capacitación continua: aunque Copilot facilita muchas tareas, es vital que los equipos de desarrollo continúen capacitándose y actualizándose en las mejores prácticas de SQL y administración de bases de datos.
  • Feedback activo: al ser una herramienta en constante evolución, proporcionar retroalimentación sobre su experiencia con Copilot puede ayudar a mejorar sus recomendaciones y adaptabilidad en el futuro.


En Bluetab, hemos presenciado y experimentado de primera mano cómo la integración de tecnologías avanzadas como Copilot puede potenciar la productividad de los equipos de desarrollo. Estamos comprometidos con la innovación y con brindar soluciones que estén a la vanguardia tecnológica pero, principalmente, en lograr mayores resultados en un menor tiempo. Esto le permite a nuestros clientes alcanzar retos mas complejos en los tiempos que el mercado lo demanda.

Nuestra misión es llevar estas capacidades y conocimientos al servicio de nuestros clientes, garantizando que puedan aprovechar al máximo las ventajas que la era digital tiene para ofrecer.

Marco LLapapasca

Enterprise Architect

¿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

Serverless Microservices

octubre 14, 2021
LEER MÁS

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

octubre 16, 2023
LEER MÁS

Bluetab en la ElixirConfEU 2023

mayo 3, 2023
LEER MÁS

MDM como ventaja competitiva en las organizaciones

junio 18, 2024
LEER MÁS

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

junio 4, 2024
LEER MÁS

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

mayo 9, 2023
LEER MÁS

Publicado en: Blog, Tech

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

octubre 4, 2023 by Bluetab

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

Alberto Jaen

AWS Cloud Engineer

Alfonso Jerez

AWS Cloud Engineer

Adrián Jiménez

AWS Cloud Engineer

Introducción

Este artículo es el segundo en una serie de publicaciones que se centran en la creación de un LakeHouse con Hudi a partir de una ingesta en streaming procesada por una aplicación Flink. El primer artículo se centra en sentar una buena base para esta plataforma, donde se desplegaron unas aplicaciones Flink con KDA (Kinesis Data Analytics) para cada tipo de formato (MoR, CoW para Hudi y JSON) que escriben el resultado de este procesamiento en unos buckets.

El envío de datos que se utiliza como input se mandaba en el anterior artículo desde una máquina en local ejecutando una aplicación de Locust, lo que puede presentar problemas a la hora de escalar y querer procesar un volumen alto de eventos. Además, las aplicaciones de Kinesis Data Analytics con Flink presentan problemas de agilidad en su modo de autoescalado. Todos estos nuevos retos serán resueltos en este artículo.

También se catalogarán estas tablas en Glue, servicio que disponibiliza un catálogo de datos en AWS, para poder acceder a estos y así realizar queries de todo tipo. Como motor de queries que consumirá estos metadatos se utilizará Athena, que proporciona una experiencia escalable, ágil y serverless para poder ejecutar queries con SQL o Spark para nuestras tablas alojadas en S3.

Por otro lado, en este artículo también se han desplegado los componentes necesarios para poder monitorizar nuestras aplicaciones y extraer así conclusiones sobre la velocidad a la que se ingestan los datos y los posibles problemas a resolver para que el procesamiento tenga la latencia requerida según los requisitos que se impongan.

Finalmente se realizará una comparativa en cuanto a rendimiento y latencia de las diferentes aplicaciones de Flink que escriben datos en los formatos de Hudi y JSON para así poder ver las diferentes ventajas e inconvenientes de estos formatos. 

Arquitectura

A continuación se puede ver la arquitectura a alto nivel que se desplegará:

Para un mayor entendimiento vamos a explicarla de izquierda a derecha. Como se puede observar, el cambio más reseñable con respecto al primer artículo es la inclusión de un cluster de Kubernetes para poder escalar los eventos que serán mandados como input de nuestra aplicación de streaming. De esta manera se podrá testear de manera exhaustiva el rendimiento de las aplicaciones de Flink dependiendo de su aprovisionamiento y sobre todo del tipo de formato y tabla en el que escriben al LakeHouse. Además, se ha disponibilizado un ALB (Application Load Balancer) que permite acceder a la interfaz de Locust para poder definir el número de usuarios a simular y cómo deben escalar estos con el tiempo. La URL para acceder a esta aparecerá como output al desplegar la infraestructura con Terraform.

Por otro lado se han realizado cambios reseñables en las aplicaciones KDA de Flink y el stream del que leen estas. Cada aplicación lee ahora como consumidores EFO (Enhanced Fan Out), de tal manera que cada una de ellas tiene un ancho de banda dedicado. La razón de este cambio y sus detalles serán explicados más en detalle en el apartado dedicado para Kinesis.

En cuanto a la monitorización y la extracción de métricas en NRT (Near Real Time) se han desplegado unas funciones lambdas que acceden a las tablas apoyándose en Athena gracias a haber registrado los metadatos de estas en el catálogo de Glue. Es importante resaltar que los metadatos de las tablas de Hudi son registrados en Glue por Flink pero en el caso de JSON se despliega un crawler que registra estas tablas en el catálogo. Este crawler se debe ejecutar manualmente para que esta tabla quede registrada en Glue.

Escalado

Kinesis Stream

Dado que el objetivo es someter la aplicación a una carga considerable de eventos por segundo, es necesario explicar cómo cada una de las piezas de la arquitectura pueden escalar de acuerdo al volumen de datos.

Como hemos comentado previamente, se ha optado por un Kinesis Stream On-Demand para automatizar el escalado de los shards durante las pruebas de carga. Es necesario tener en cuenta que estos streams pueden acomodar una tasa de escritura de hasta el 200% de lo especificado por el número de shards en un momento dado.

Una vez que el stream se encuentra por encima del 100%, aumentará automáticamente el número de shards en un plazo de 15 minutos. La única limitación por tanto es no superar el doble del volumen de escritura admitido en menos de dicho periodo.

Por otro lado, dado que se tendrán tres aplicaciones de Flink leyendo del mismo stream, las limitaciones a nivel de lectura serán el mayor problema. Un Kinesis Stream solo admite 5 llamadas GetRecord por shard por segundo. Dado que cada aplicación tiene que leer todo el stream (y por lo tanto, todos los shards), aumentar el número de shards no ayuda a solventar este problema.

La solución pasa por registrar cada una de las aplicaciones como un consumidor Enhanced Fan-Out. Esta funcionalidad de los Kinesis Stream provee a cada uno de estos consumidores con un límite individual de 5 llamadas GetRecord y 2MB por shard por segundo de lectura.

Esta configuración se realiza en el lado del consumidor, en nuestro caso mediante el conector de Kinesis para Flink:

'scan.stream.recordpublisher' = 'EFO',
'scan.stream.efo.registration' = 'EAGER/LAZY',
'scan.stream.efo.consumername' = '{consumer_name}' 

Conviene mencionar que alternativamente, es posible aumentar la latencia de lectura de nuestras aplicaciones de Flink. Por defecto Flink realiza una lectura cada 200 ms por shard, de modo que una aplicación consume completamente la cuota de lectura de un stream. Incrementando este valor a 600ms podríamos acomodar las tres aplicaciones, a costa de una mayor latencia:

scan.shard.getrecords.intervalmillis = '600' 

También se hará uso de la opción Adaptive Reads, que modifica dinámicamente el número de eventos recogidos por llamada en función del tamaño de cada record. Esto permite aprovechar los 2 MB/s por shard disponibles para cada consumidor: 

'scan.shard.adaptivereads' = 'true' 

En lo que respecta al escalado en KPUs (Kinesis Processing Unit) de Flink, se ha optado por no hacer uso del autoescalado, ya que cada proceso de escalado incurren en downtime para la aplicación. Debido a los diferentes requerimientos de cada una de las aplicaciones, las acciones de escalado en momentos inesperados podrían interrumpir las pruebas de carga. Además es interesante medir el rendimiento de escritura de cada una de las aplicaciones en igualdad de capacidad de computación.

Hudi

Timeline

Uno de los sistemas base sobre la que se sustenta el funcionamiento y características de Hudi es la timeline. Hudi guarda un registro temporal de todas las acciones que se han realizado sobre la tabla, así como el estado de esta acción.

Las principales acciones que componen la timeline son

  • Commits – escritura atómica de un conjunto de registros en la tabla en formato columnar
  • Delta Commit – similar al commit, representa una escritura de registros en forma de logs en una tabla Merge on Read
  • Compaction – compactación de las escrituras en logs (delta commits) de una tabla MoR a formato columnar
  • Cleans – borrado de versiones antiguas de archivos
  • Rollback – eliminado de los registros escritos por un commit o delta commit fallido
  • Savepoint – marca un conjunto de archivos como “guardados” para que no sean eliminados por el proceso de limpieza. Permite restaurar la tabla a un punto anterior en la timeline

Cualquiera de estas acciones pueden encontrarse en uno de estos tres estados

  1. Requested – una acción ha sido planeada sin iniciar
  2. Inflight – la acción está en proceso
  3. Completed – denota que la acción ha sido completada


Tipos de tabla

Como se ha dejado entrever en el funcionamiento de la timeline de Hudi, existen dos tipos de escritura soportados: columnar y logs. El formato columnar (parquet) constituye la forma final de una tabla de Hudi, junto con los metadatos de la timeline. Sin embargo, es posible hacer uso de las escrituras en logs (avro) para disminuir la latencia de escritura y eventualmente compactarse a formato columnar sin entorpecer la escritura.

El uso de estos métodos de escritura dan lugar a los dos tipos de tabla que Hudi pone a nuestra disposición

  • Copy on Write – las escrituras se realizan exclusivamente en formato columnar, creando un nuevo fichero con los nuevos registros de la tabla. Los datos están disponibles inmediatamente pero incurre en mayor latencia de escritura
  • Merge on Read – hace uso de la escritura en logs. Los nuevos registros son inicialmente escritos como logs, y posteriormente serán transformados a formato columnar por el proceso de compactación. Obtenemos menor latencia de escritura a costa de latencia de lectura; los nuevos registros no estarán disponibles hasta que se realice la compactación.

Tipos de Query

Para poder aprovechar las características de cada tipo de tabla, existen tres tipos de queries que se pueden realizar sobre una tabla de Hudi

  • Snapshot – obtiene la última versión de la tabla. Para las tablas MoR esto implica incurrir en un proceso de compactación para obtener los últimos registros en formato log. 
  • Read Optimized – para tablas MoR, lee sólamente los registros ya expuestos en formato columnar sin incurrir en latencia de lectura adicional.
  • Incremental – recoge únicamente los nuevos registros desde un cierto commit o compactación, facilitando la creación de pipelines incrementales. No está soportada por Athena

Integración con Glue Catalog


El conector de Hudi permite una integración nativa con el catálogo de Glue en AWS. Basta con añadir las dependencias de Hive en nuestra aplicación de Flink:

com.amazonaws.aws-java-sdk-glue
org.apache.hive.hive-common
org.apache.hive.hive-exec 

Y especificar la configuración del catálogo en el conector de Hudi:

'hive_sync.enable' = 'true',
'hive_sync.db' = '{glue_database}',
'hive_sync.table' = '{table_name}',
'hive_sync.partition_fields' = '{partition_fields}',
'hive_sync.mode' = 'glue',
'hive_sync.use_jdbc' = 'false' 

Con esta integración, la aplicación creará automáticamente las tablas en el catálogo. Como hemos mencionado anteriormente, existen distintos tipos de query para consultar una tabla de Hudi. Se crearán por tanto en el catálogo distintas tablas para soportar las diferentes consultas.

Para una tabla CoW, la tabla se consultará mediante una query Snapshot. Para MoR en cambio se pondrán a disposición dos tablas, para soportar consultas Read Optimized o Snapshot.

La principal aplicación de Glue es de soporte a las lambdas para que al ejecutar las queries mediante Athena su ejecución pueda realizarse de una forma más eficiente, rápida y segura:

  • Glue Catalog: almacenamiento centralizado de la información acerca de la organización, diseño y formato de los datos, utilizado por Athena para realizar directamente las consultas a S3 sin necesidad de tener que apoyarse en terceros para conseguir esta información
  • Automatización del Esquema: Glue rastrea y cataloga automáticamente los datos en S3, detectando y adaptando los cambios en el esquema. Esto evita posibles errores y permite la lectura de los nuevos campos en caso de que se produzcan alteraciones en los esquemas de los eventos

Configuración de Hudi

Es importante entender las configuraciones que nos ofrece Hudi para optimizar nuestra aplicación, en particular para una aplicación en Near Real Time conviene estar al tanto de las opciones disponibles. Aunque la capacidad de configuración es inmensa [1], se intentará sintetizar las que pueden ser más relevantes para una primera toma de contacto con esta tecnología.

Particionado

Apache Hudi ofrece los tipos de particionado que pueden encontrarse en otras soluciones, se detallarán las principales y se justificara la implementada:

  • Simple: particionado basado en un único campo, en este caso el campo escogido es ‘ticker’ ya que se ha identificado que es el que tiene una cardinalidad menor.
  • Particionado Compuesto: particionamiento basado en múltiples campos, podría resultar interesante escoger un campo de baja cardinalidad (ticker) y otro de cardinalidad media (fecha)
  • Particionado Dinámico: elección de la variable en base de los valores, puede resultar interesante cuando la cardinalidad de las variables puede sufrir variaciones y se quiera una actualización del particionamiento de una forma automática y flexible.

Índices

Apache Hudi cuenta con una múltiples  tipos de indexación[2], comentaremos brevemente los más comunes:

  • Bloom Index – Hace uso de un bloom filter sobre la key de los eventos, adicionalmente se puede complementar con un filtrado por rango de de key. Funciona bien cuando tratamos con una tabla donde la mayoría de cambios ocurren en las particiones más recientes o para deduplicado de eventos.
  • Simple: indexación realizada mediante la combinación de FileID y RecordKey. Recomendado cuando las operaciones Upsert no son tan frecuentes debido a la simplicidad que este ofrece.

Ambos tipos de índices pueden ser usados en su forma global

  • Índice global – Imponen la unicidad de las keys en todas las particiones de la tabla, es decir, garantizan que existirá sólamente un registro con una cierta key.
  • Índice no global – La unicidad de la key sólo es exigida a nivel de partición. Si los datos son consistentes y una key sólo va a existir en una partición, este tipo de índices ofrecen un rendimiento mucho mayor y mejor escalado.

En este caso, se ha optado por un Bloom Index, el cual es el que se toma por defecto en caso de que no se declare expresamente:

"hoodie.index.type" = "BLOOM" 

La elección de este tipo de indexación se debe a que los casos de uso que se han planteado requieren de un procesamiento de datos considerablemente alto y eficiente.

Tipos de operación

Apache Hudi ofrece varios tipos de operaciones[3] que permiten a los usuarios administrar y modificar conjuntos de datos de gran tamaño. A continuación se detallan tanto las principales operaciones realizadas en los Stress Tests como en otros escenarios:

  • Upsert – Es la operación por defecto, y ejecutará un insert o un update dependiendo de si el registro ya existe tras una búsqueda en el índice. Con esta operación la tabla no tendrá duplicados para su clave primaria.
  • Insert – Esta operación ignora la búsqueda en el índice a la hora de insertar eventos. Es la más rápida pero la tabla puede contener duplicados. Aún así es útil si se utilizan métodos auxiliares  de deduplicado, o simplemente la existencia de estos es tolerable en el caso de uso.
  • Delete: Hudi ofrece dos métodos de borrado. Soft Delete convierte a nulos los valores del evento a excepción de la key. Hard Delete ejecuta un borrado físico del evento en la tabla.
  • Bulk Insert Operación similar al Insert pero optimizada para la inserción de un gran volumen de datos, a costa de sacrificar ciertas garantías en el control del tamaño de ficheros. Escala bien para cientos de TBs en caso de bootstrap inicial de una tabla de gran tamaño.

Compactación

En el caso de usar una tabla MoR es posible configurar el ritmo de compactación de logs en parquet para buscar el equilibrio entre latencia de escritura y lectura que más convenga al caso de uso. Se pueden especificar una estrategia de tiempo o número de delta commits (o ambos) que ejecutan un proceso de compactación:

compaction.delta_commits
compaction.delta_seconds
compaction.trigger.strategy 

Acciones asíncronas

Ciertas acciones de la timeline como la compactación, limpieza, archivado y clustering pueden ser realizadas asíncronamente por la aplicación, o incluso ser relegadas a procesos auxiliares a la aplicación de escritura. Para el caso de Flink, puede ayudar a mejorar la latencia de escritura y evitar problemas de BackPressure en la aplicación:

compaction.async.enabled
hoodie.clean.async
hoodie.archive.async
hoodie.clustering.async.enabled 

Stress Tests & Insights

Al desplegar las aplicaciones, se ha procedido a realizar distintos tests variando tanto la carga máxima de eventos como la concurrencia y el grado exponencial de crecimiento de los mismos. Esto ha sido posible  gracias a la flexibilidad ofrecida por Locust al estar levantado sobre un cluster de Kubernetes, pudiendo establecer un límite máximo de concurrencia de eventos y un incremental de los mismos. En los tests se ha establecido un límite máximo de 5 a 15K usuarios simultáneos (Peak Concurrency) escalando la frecuencia de los mismos de forma lineal, desde 5 a 20 usuarios más por segundo (Spawn Rate):

Se ha procedido a monitorizar los distintos test para así sacar conclusiones del rendimiento teniendo en cuenta las características específicas de cada uno de los formatos. Las métricas en las que se han apoyado los análisis son tanto las nativas de CloudWatch Metrics (CPU & Memory Utilization, KPUs, LastCheckpoint SIze & Duration,..), como las métricas obtenidas a partir de las Lambdas que periódicamente consultan el número de eventos disponibles en los buckets y realizan cálculos del promedio de la latencia de los mismos.


Número de Eventos

A la hora de analizar el número total de eventos procesados, los cuales son enviados de forma gradual, es decir, a medida que pasa el tiempo cada vez son más los eventos que se envían por segundo, se identifica una tendencia bastante similar aunque destacan JSON y Hudi MoR sobre Hudi CoW en cuanto a la rendimiento. Cabe destacar que JSON muestra un crecimiento más estable y constante en comparación con Hudi MoR y CoW y esto se debe a que estos últimos son capaces de manejar actualizaciones incrementales en los datos.

La similitud entre JSON y Hudi MoR hace que la elección se base completamente en las características del proyecto. En caso de que los datos no sean actualizados JSON puede resultar una solución más interesante debido principalmente a su simplicidad, mientras que si hay una alta frecuencia de actualización de datos históricos, Hudi MoR puede ser una mejor solución. Esto se debe tanto a la mayor eficiencia en las tareas de lectura como por la posibilidad de registrar las distintas versiones de los datos.

 

Latencia

Debido a la dificultad de estandarizar la lógica del cálculo de la latencia entre 3 tipos de almacenamiento distintos, se ha optado por simplificarla calculandolo como la diferencia entre la hora de creación del evento y la del procesamiento en la respectiva aplicación.

Se observa un comportamiento similar entre JSON y Hudi MoR, aunque este primero de una forma más crítica, al tener una latencia inicial muy baja pero a medida que tanto el tiempo de procesamiento como el volumen de carga aumenta, esta latencia se ve negativamente afectada.

La elección entre JSON y Hudi MoR dependerá tanto de la tolerancia de fallo que tenga la aplicación como las propias características de cada uno de los formatos, en caso de que la estructura de los datos sea estable y no cambie con frecuencia,o bien, no dependa de actualizaciones incrementales y pueda lidiar con reescrituras completas, en ese caso JSON puede que sea una mejor opción.

La elección de Hudi CoW sobre MoR puede darse cuando se necesite una alta tolerancia a errores y una alta capacidad de recuperación de eventos de escritura fallidos o corrompidos.`


Uso de CPU

Al analizar el uso de CPU, se ha identificado cierta homogeneidad entre los distintos tests aun trabajando con distintas cargas de trabajo. JSON Y Hudi MoR destacan por tener los niveles de uso de CPU más bajos, ambos por distintos motivos. JSON destaca por la simplicidad al incluir directamente los nuevos datos sin necesidad de tener que lidiar con versionado de datos, mientras que MoR no consume tanta CPU ya que por sus características, el consumo mayor de CPU se hace al realizar consultas de lectura, en las tareas de escritura únicamente identifica los cambios que serán aplicados al consultarlos.

Recordar que las métricas nativas de CloudWatch únicamente nos permiten monitorizar las aplicaciones, que corresponden a las tareas de escritura. La monitorización de las tareas de lectura corresponde a las Lambdas mencionadas anteriormente. 

En este caso MoR es más beneficioso respecto a CoW, dado que el mayor consumo de CPU en MoR se produce al consultar los datos almacenados mientras que en CoW tiene lugar al actualizar los datos.

La elección entre los formatos más eficientes se deben a las necesidades del proyecto, en caso de que se requiera una mayor tolerancia al fallo, versionado de los datos y una mayor eficiencia de lectura, se optara por MoR frente a JSON, entre los dos formatos de Hudi, de nuevo, la elección dependerá de las características del proyecto, en caso de que las consultas requieran transformaciones pesadas y/o complejas se optaría por MoR, si en cambio, el proyecto requiera de una mayor integridad de datos y/o la ingesta de datos sea en batch,  resultaría más interesante CoW debido a que al trabajar con esos volúmenes de datos, el contar con copias de seguridad, en caso de surgir errores, el impacto en término de costes y tiempo de recuperación es menor.

 

Memory Utilization

JSON de nuevo destaca por tener los valores de uso de memoria más bajos aunque para la operativa de transformaciones que se realizan son relativamente altos y más teniendo en cuenta que no tiene que lidiar con la administración de versiones o la combinación de datos. Estos valores se deben a que no tiene capacidades de compresión optimizadas ni manejo eficiente de esquemas.

Respecto a Hudi, se pueden obtener unas conclusiones similares a las del apartado de uso de CPU, MoR tiene una utilización de memoria mayor que JSON debido al procesamiento de logs delta y la administración de versiones y una menor a CoW ya que la consolidación real de los datos no ocurre durante la escritura.


Last Checkpoint Size

Destacar, nuevamente, la estabilidad de JSON frente a las aplicaciones Hudi, ya que no solo muestra en los test realizados un valor inferior a ambos, si no una estabilidad que no se consigue ni con MoR ni CoW, ya que como puede apreciarse, al monitorear el tamaño de los Checkpoints, se percibe una volatilidad considerable.

La volatilidad percibida en las aplicaciones Hudi se debe principalmente a fallos surgidos en Checkpoints lo que conlleva que el Checkpoint posterior al fallido, tenga un volumen mayor. Además de esto, la volatilidad en los tamaños de los Checkpoints puede estar relacionado con las operaciones de optimización y compactación realizadas internamente que puede conllevar la compactación del estado y que esto reduzca considerablemente el tamaño del mismo.

Desafíos en el desarrollo

Read Throughput de Kinesis y EFO

Para no sobrepasar el límite de lectura sobre el Kinesis Stream se ha optado por suscribir los consumidores como Enhanced Fan-Out. En algunas pruebas en conjunto con Autoscaling esto ha dado problemas con el conector de Kinesis de Flink siendo incapaces de cerrar conexiones a la hora de escalar el cluster.


Configuración de Hudi

La configuración de Hudi ha sido otro de los puntos de fricción durante el desarrollo. Bajo cargas elevadas los procesos de compactación y limpieza son más propensos a causar problemas de Backpressure y causar errores en la aplicación. Aunque configurar estos procesos para que ocurran de forma asíncrona puede aliviar este problema, pueden surgir conflictos y desalineación entre procesos bajo cargas elevadas. Un equilibrio entre estas configuraciones y la capacidad del cluster de la aplicación son claves para el buen funcionamiento de la aplicación.

Heterogeneidad de formato

Al hacer un análisis del rendimiento de las 3 aplicaciones, se cuenta con una dificultad adicional debido a la naturaleza de los tipos de formato, teniendo esto tanto un impacto a la hora de plantear la arquitectura como en el planteamiento de las lógicas.
El distinto comportamiento de los formatos en la ingesta, complica el desarrollo de las lógicas a la hora de calcular la latencia. MoR escribe en logs previa compactación, por lo que los datos no están disponibles inmediatamente como ocurre con CoW o JSON.  Esto implica que la métrica común medible para todos los formatos es la de disponibilidad de lectura, la cual no es el principal objetivo de una tabla MoR.  


Sincronización con el Glue Catalog

Una de las grandes ventajas que nos hemos encontrado con Hudi es su capacidad para sincronizarse con el catálogo de Glue, creando las tablas y manteniéndose actualizadas sin necesidad de un crawler. Esto permite una aplicación y arquitectura más limpia que para el caso de JSON, para el cual debe ejecutarse manualmente al desplegar las aplicaciones.

Conclusiones

Los resultados de los tests muestran diferencias considerables entre los formatos JSON, Hudi MoR y CoW en términos de eficiencia, capacidad de respuesta y utilización de recursos. Se procede a analizar cada uno de los aspectos más en detalle:

  • Eficiencia de Procesamiento: JSON y Hudi MoR destacan en la mayoría de las métricas, mostrando un desempeño óptimo en términos de Latencia, CPU & Memory Utilization. Sin embargo, el comportamiento de JSON es más estable y predecible, aunque MoR cuente con ventajas sobre JSON, como por ejemplo, en la gestión de actualizaciones incrementales.
  • Resiliencia y Tolerancia a Fallos: la tolerancia a fallos es un factor muy importante en la decisión sobre la elección entre Hudi y JSON. En el caso de  MoR y CoW, dependerá del grado de criticidad, ya que a nivel general el rendimiento en tareas de escritura para MoR es superior.
  • Uso de Recursos: JSON se muestra como el más ligero, con baja utilización de CPU y memoria, debido a su simplicidad inherente. Mientras que Hudi MoR y CoW, por la naturaleza de su diseño y gestión de datos, requieren más recursos, especialmente en operaciones que involucran el manejo de versiones y la compactación de datos.

Para finalizar, resulta interesante identificar en quéque casos de uso o proyectos puede resultar más recomendable cada uno de los formatos en función de las características de los mismos y las red flags que puedan establecerse:

  • JSON: Recomendado para aplicaciones con estructuras de datos estables que no requieren actualizaciones incrementales y donde la simplicidad y la estabilidad son clave.
  • Hudi MoR: Adecuado para proyectos que requieren una gestión eficiente de actualizaciones incrementales y donde la latencia y la eficiencia en la escritura son cruciales.
  • Hudi CoW: Ideal para contextos donde la integridad de los datos es esencial, y se necesita una robusta recuperación de errores, especialmente en escenarios de ingestas en batch. 

Referencias

[1] Configuraciones Tablas Hudi. [link]

[2] Tipos de Indexacion Hudi. [link]

[3] Tipos de Operaciones Hudi. [link]

Autores

Alberto Jaen

AWS Cloud Engineer

Empecé mi carrera laboral con el desarrollo, mantenimiento y administración de bases de datos multidimensionales y Data Lakes. A partir de ahí comencé a estar interesado en plataformas de datos y arquitecturas cloud, estando certificado 3 veces en AWS y 2 con Hashicorp.

Actualmente me encuentro trabajando como un Cloud Engineer desarrollando Data Lakes y DataWarehouses con AWS para un cliente relacionado con la organización de eventos deportivos a nivel mundial.

Alfonso Jerez

AWS Cloud Engineer

Apasionado de los datos y las nuevas tecnologías, especializado como AWS Cloud Engineer en la optimización de DataWarehouses y procesos de ingesta y transformación de Data Lakes. Motivado por la mejora continua y automatización de la integración de servicios.

Colaborando activamente con el grupo de Práctica Cloud en investigaciones y desarrollo de blogs de tecnologías punteras e innovadoras tales como esta, fomentando así el continuo aprendizaje.

Adrián Jiménez

AWS Cloud Engineer

Dedicado al aprendizaje constante de nuevas tecnologías y su aplicación, disfrutando de utilizarlas en la resolución de desafíos tecnológicos. Desarrollo mi carrera como Cloud Engineer diseñando, implementando y manteniendo infraestructura en AWS.

Colaboro activamente en la Práctica Cloud, donde investigamos y experimentamos con nuevas tecnologías, buscando soluciones para los retos que enfrentan nuestros clientes.

Navegación

¿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

Data-Drive Agriculture; Big Data, Cloud & AI aplicados

noviembre 4, 2020
LEER MÁS

Usando los Grandes Modelos de Lenguaje en información privada

marzo 11, 2024
LEER MÁS

Oscar Hernández, nuevo CEO de Bluetab LATAM

mayo 16, 2024
LEER MÁS

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

mayo 18, 2022
LEER MÁS

Una estrategia analítica eficiente

diciembre 13, 2022
LEER MÁS

Introducción a los productos de HashiCorp

agosto 25, 2020
LEER MÁS

Publicado en: Practices, Tech

El futuro del Cloud y GenIA en el Next ’23

septiembre 19, 2023 by Bluetab

El futuro del Cloud y GenIA en el Next ’23

Lucas Calvo

Cloud Engineer

Javi Perez

Cloud Engineer

Gabriel Gallardo

Cloud Engineer

Este año desde Bluetab hemos ido al Google Cloud Next, la conferencia anual organizada por Google Cloud, uno de nuestros partners de referencia además de uno de los principales proveedores Cloud del mundo. Este evento está orientado para dar a conocer todos sus nuevos anuncios de productos así como casos de usos de éxito que se han realizado con distintos clientes sobre su plataforma. 

En esta ocasión, hemos viajado hasta San Francisco para ver todas las últimas novedades que nos presenta Google, así como tener la oportunidad de debatir sobre distintas áreas como la inteligencia artificial, aprendizaje automático, análisis de datos y otros temas relacionados con los servicios de Google Cloud con los principales ingenieros que los desarrollan.

Tal y como viene siendo costumbre este año los anuncios más importantes han venido relacionados con la Generative AI, esta revolución tecnológica que nos ha abierto un mundo de posibilidades y avances. Comenzando por la parte clásica, a medida que seguimos generando más datos y explorando sistemas cada vez más complejos con datos que tienen un mayor grado de actualización para garantizar que las recomendaciones y los resultados sean reflejos precisos del mundo en evolución que nos rodea, debemos disponer de una capacidad de cómputo escalable que proporciona una gran conectividad. Orquestar las cargas de trabajo actuales a gran escala siempre ha requerido un esfuerzo manual para gestionar los fallos. Sin embargo, hoy somos capaces de simplificar los esfuerzos que conlleva la gestión de estas cargas de trabajo, sobre todo las destinadas a IA con la integración de las TPU en la nube en GKE, el servicio Kubernetes más escalable y líder del sector en la actualidad. 

Este ha sido uno de los anuncios más importantes del Next’23, ya que ahora los clientes pueden mejorar la productividad del desarrollo de IA aprovechando GKE para gestionar la orquestación de cargas de trabajo de IA a gran escala en las nuevas Cloud TPU v5e, así como en Cloud TPU v4. Esta nueva generación tiene hasta 2,5 veces más rendimiento en comparación con Cloud TPU v4, pero lo realmente importante es la nueva tecnología Multi Slicing que permite realizar entrenamientos distribuidos más allá de los límites físicos de una TPU, escalando a cientos de pods con estos dispositivos.

Igualmente, merece la pena destacar la mejor en las instancias de cómputo para las cargas de trabajo no relacionadas con la IA, pero que tienen igual o mayor importancia para nuestros, para ello Google presente su nueva familia de VMs basadas respectivamente en procesadores de AMD (C3D) o ARM (C3A) que se suman a las instancias A3 donde disfrutaremos de las nuevos GPUs de Nvidia: las H100. Todo aderezado con las nuevas reservas, ahora en versión preliminar, que son una nueva función de Compute Engine que permite reservar capacidad para una fecha futura.

Aunque estas nuevas ventajas  abren las posibilidades a un nuevo mundo en la nube, la realidad sigue siendo que trabajar con Large Language Models es complicado, no solo se necesita losl últimos avances en hardware, sino también el tiempo a invertir para obtener un resultado de calidad. Google se ha puesto las pilas para solventar esta problemática, y ofrecer a nuestros clientes el nuevo concepto de “Model Garden” que Microsoft anunció en su conferencia anual Build y que también AWS está trabajando para incorporar en Amazon JumpStart. Esta nueva capacidad permite elegir con qué Modelo Fundacional queremos trabajar en un click, solo necesitamos entender qué tipo de Prompt Engineering estamos trabajando para comenzar a construir nuestras soluciones de Information Retrieval con Vertex AI Search and Conversation. Pero Google Cloud no se queda en el “Model Garden” donde podremos encontrar los últimos LLM como son: Llama 2 y Code Llama de Meta, Falcon LLM del Technology Innovation Institute y Claude 2 de Anthropic, sino que también podremos personalizarlo con las características más relevantes que nosotros creamos conveniente para el caso de uso que estamos trabajando, lo cual nos permite generar un flujo de trabajo de tipo Reinforcement Learning with Human Feedback (RLHF), aumentando la confianza en nuestras aplicaciones conversacionales y de búsqueda mediante la IA generativa.

Con los nuevos productos de Vertex AI, la base de datos original de la organización se convierte en la pieza fundamental para que la IA generativa se capaz de buscar la información que es relevante para la persona que le está preguntado acerca de una cuestión de negocio, y para que la experiencia sea más sencilla posible se presentaron las nuevas extensiones Vertex AI permiten a los modelos realizar acciones y recuperar información específica en tiempo real y actuar en nombre de los usuarios a través de Google y aplicaciones de terceros como Datastax, MongoDB y Redis, sin olvidar los nuevos conectores que ayudan a ingerir datos de otras aplicaciones empresariales como Salesforce, Confluence y JIRA.

Finalmente, se ha presentado la evolución del Vertex AI Feature Store para su uso tiempo real mediante la búsqueda vectorial y semántica con BigQuery, que mejora su integración de machine learning mediante BigQuery ML, e incorpora la facilidad de uso de notebooks con Colab para crear nuevos modelos a medidas pero con todas las funciones de seguridad y cumplimiento de normativas que una organización require. Es decir, un nuevo mundo de posibilidades para integrar la Generative AI con tu negocio.

Y es a nivel empresarial donde más destaca su anuncio más esperado, la presentación global de Duet AI dentro de Google Workspaces y Google Cloud Services. Aún tendremos que esperar algunos días para que se vayan actualizando todos los servicios con nueva capacidad de IA generativa que nos permitirá realizar una búsqueda avanzado entre todos los documentos que almacenemos en Google Drive para encontrar aquellos que son realmente interesantes par la tarea que estamos haciendo, o ser capaces de escribir actas de forma automática mediante Chat y preguntar por el propio contenido de la reunión, así como crear nuevos presentaciones en base a breves pero concisas descripciones, ahora tiempo de tener que empezar de cero sin una buena base. Duet AI proporciona un asistente de IA generativa entrenada específicamente, por ejemplo, en la documentación de GKE para ayudar a los equipos de la plataforma a reducir el tiempo que tardan en aprender y gestionar Kubernetes, no solo a la hora de desplegar una nueva aplicación, sino también a la hora de encontrar los bugs y depurar su origen, o incluso registrar nuestros findings de seguridad para identificar las fallas que puedan existir en nuestras aplicaciones. Con Duet AI, se podría incluso llevar a plantear una migración de código legacy, o documentar aquellas partes del código que se quedan huérfanas de forma automática. Además, este anuncio no solo se queda ahí ya que Duet permitirá a usuarios sin conocimientos realizar consultas para monitorizar sus aplicaciones con lenguaje natural, evitando así el uso de otros lenguajes más complejos como Promql.

Por la parte más tradicional de data también hemos tenido distintos anuncios como  el nuevo producto que se ha lanzado de BigQuery, BigQuery Studio que nos ofrece un espacio único para el trabajo de ingeniería de datos facilitando que todos los profesionales aceleren los datos hacia los flujos de trabajo de IA . Podríamos destacar entre sus características más importantes que es un espacio de trabajo unificado usando SQL y notebooks en el cual se permite el uso múltiples lenguajes de programación (SQL, Python, Spark, Javascript y lenguaje natural), además ofrece control de versiones e historial de revisiones centralizado y un asistente de código y chat impulsado por IA que nos permitirá mejorar la productividad. Otra parte importante que hay que señalar en BigQuery Studio es que permite realizar de forma sencilla y automática el profiling, la calidad y el linaje para todos los assets de datos coordinado con herramientas como dataplex.

Además en esta edición, se han presentado nuevas funcionalidades para poder llevar BigLake a una plataforma lakehouse gestionada. Entre las nuevas características encontramos la integración con formatos de datos abiertos (Apache Iceberg, Delta y Hudi) permitiendo un control de acceso detallado y rendimiento de forma integrada. Otra de las novedades que se ha incluido BigLake son las tablas gestionadas que usan formato abierto Apache Iceberg y permiten uso de streaming sobre ellas con alto rendimiento así como todas las ventajas que ofrece Apache Iceberg. Con el servicio de BigLake se puede afrontar los nuevos retos que plantean arquitecturas orientadas al Data Mesh de una forma mucho más sencilla y dando la posibilidad de compartir nuestros set de datos dentro de toda la organización.

También en la parte de contenedores y orquestación ha habido algunos puntos importantes, con anuncios en sus productos estrellas y diferenciales en el mercado como es GKE y Cloud Run. Desde hace unos años Google está apostando cada vez más a soluciones de orquestación de contenedores totalmente administradas, ya lo vimos con autopilot en 2021 y Cloud Run y ahora además está queriendo hacer más sencillo el uso de Kubernetes integrándose con Duet para realizar recomendaciones y configuraciones de aplicaciones y servicios con lenguaje natural.

Todas las novedades las podemos resumir en el siguiente post

https://cloud.google.com/blog/topics/google-cloud-next/next-2023-wrap-up

Conclusiones

  • El Next’23 nos ha permitido charlar con los profesionales de Google y  compartir ideas y conocimientos con los distintos partner que han asistido al evento lo que nos permite debatir nuevas visiones y confirmar que desde Bluetab estamos realizando los pasos correctos. Como siempre, las sesiones son de gran utilidad y abarcan las nuevas características y funcionalidades que podemos esperar en los próximos meses para Kubernetes.
  • Después de volver de Next’23 reafirmamos que Google sigue siendo una de las mejores soluciones en el mercado de la analítica avanzada con uno de los anuncios más importantes del Next, Duet. Google es uno de los primeros proveedores cloud que han integrado la parte de Generative AI en su plataforma y esto es gracias a Duet que es una asistente que te ayudará a enfrentarte con los distintos retos que puedan surgir en Google Cloud. 
  • Pero no todo va a ser inteligencia artificial, uno de los puntos que más hay que trabajar y más importantes para una organización es la parte de FinOps, muchas veces el gran olvidado. En este Next hemos visto distintas soluciones aportadas por clientes para una optimización de costes y distintas estrategias para el gobierno y el control de estos. Aún así todas las soluciones pasan por realizar distintos desarrollos exportando los datos de la facturación a Bigquery y creando Dashboard en Looker, una solución de momento que no es totalmente administrada. En este apartado hay mucho trabajo por hacer para que la parte de FinOps sea mucho más proactiva y podamos hacer recomendaciones en tiempo real a los desarrolladores para disminuir el gasto en la organización.

 

Ha sido un placer vivir esta experiencia con todos los desarrolladores e ingenieros de Google y con el resto de compañeros. Además solo nos queda agradecer al equipo de partners de Google España por su dedicación y seguro que nos vemos en la próxima edición. Hasta entonces, sigamos explorando nuevas ideas y tecnologías.

¡Nos vemos en Las Vegas!»

Lucas Calvo

Cloud Engineer

Javi Perez

Cloud Engineer

Gabriel Gallardo

Cloud 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

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

noviembre 17, 2021
LEER MÁS

MODELOS DE ENTREGA DE SERVICIOS EN LA NUBE

junio 27, 2022
LEER MÁS

Mi experiencia en el mundo de Big Data – Parte II

febrero 4, 2022
LEER MÁS

FinOps

mayo 20, 2024
LEER MÁS

Big Data e IoT

febrero 10, 2021
LEER MÁS

PERSONAL MAPS: conociéndonos más

octubre 24, 2023
LEER MÁS

Publicado en: Blog, Tech

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

junio 7, 2023 by Bluetab

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

Resumen

Los avances en Generative AI y en los grandes modelos de lenguaje, LLMs por sus siglas en inglés (Large Language Models), permiten transferir el pre-entrenamiento de estos modelos en una tarea simple, como predecir las palabras que faltan en una frase a tareas más complejas, como procesar documentos en papel para extraer sus datos de forma automática. Esta transferencia del entrenamiento funciona tan bien que es posible plantear desarrollar casos de uso que cierren el gap entre la digitalización y las actividades que requieren documentos en papel.

Hemos desarrollado un proyecto para modernizar la tecnología de AI de Fastcapture, nuestro IDP (Intelligent Document Processing), con Generative AI y LLMs. Hemos conectado Fastcapture con Hugging Face, un hub de la comunidad Open Source de AI. Los resultados que hemos obtenido están muy por encima de un F1 score de 0.9.

 

Introducción

Estamos viviendo una era de disrupciones. Esta situación está produciendo un momento de constantes avances tecnológicos. Me voy a fijar en 2 de ellos, la digitalización y el desarrollo de aplicaciones con inteligencia artificial (AI).

La pandemia COVID-19 ha sido terrible. Ahora bien, una de sus consecuencias ha sido la aceleración de la digitalización. El crecimiento de usuarios digitales ha sido de 2 dígitos en la gran mayoría de las empresas. Sin embargo, muchas actividades en las empresas siguen requiriendo documentos en papel. Un informe del US Bureau of Labor Statistics indica que las compañías americanas se gastaron $5,3Bn en cargar manualmente los documentos durante el año 2021.

Los avances en AI, y en particular los avances en Generative AI y en los grandes modelos de lenguaje han alcanzado un momento que, a parte de la aparición de aplicaciones sorprendentes como ChatGPT, permite el desarrollo de casos de uso de tratamiento de textos e imágenes con unos niveles de precisión muy elevados >0.9.

Juntando estas piezas, hoy es realmente posible plantear automatizar el procesamiento de documentos en papel a escala para convertirlos en datos digitales listos para ser consumidos y analizados en cualquier otra actividad de la empresa. 

 

El problema

Muchas actividades en las empresas siguen requiriendo documentos en papel. Facturas, contratos, informes. Estos documentos contienen datos relevantes y disponer de una versión digital es clave para la digitalización de las empresas. 

Una forma de convertir los documentos en papel en datos digitales es mediante cargas manuales. También se pueden convertir en datos digitales utilizando aplicaciones del tipo de un IDP. Un IDP consiste en un grupo de pipelines con pasos para procesar los documentos y convertirlos en datos digitales. El primer paso es la conversión del documento en texto con un modelo OCR (Optical Character Recognition). 

A continuación vienen los pasos para tratar el texto. Los pasos de tratamiento del texto pueden utilizar modelos de AI. Típicamente estos modelos de AI están basados en una arquitectura RNN (Recurrent Neural Network). Los modelos RNN tratan la secuencia de palabras en orden, una a una. Estos modelos se enfrentan a 2 dificultades a la hora de realizar su tarea. La primera es su capacidad de tratamiento del contexto. Según se van alejando las palabras y las frases, el modelo empieza a perder su capacidad para relacionarlas. La segunda es la dificultad que tienen para escalar y, por lo tanto, para ser entrenados en grandes volúmenes de textos. Estas 2 dificultades suponen un techo para la precisión del IDP y por lo tanto para su capacidad de automatizar la conversión de documentos en papel en datos digitales.

 

La solución propuesta

Los LLM se basan en la arquitectura de los Transformers. Esta arquitectura propuesta en el paper “Attention is all you need” Vaswani et al. 2017 fué totalmente revolucionaria. Trata la secuencia a través del mecanismo de atención mediante matrices. El mecanismo de atención permite realizar un mejor procesamiento del contexto. 

Todas las palabras se encuentran a la misma distancia entre sí medida en número de operaciones matemáticas. Y permite escalar el entrenamiento de forma horizontal. Los modelos basados en esta arquitectura se pueden entrenar con cantidades de textos muy grandes. 

En el paper “Improving Language Understanding by Generative Pre-Training” Radford et al. 2018 proponen un nuevo framework de 2 fases para entrenar los LLMs. Un pre-entrenamiento no supervisado sobre un objetivo sencillo, predecir la siguiente palabra de un texto, y con grandes volúmenes de textos. Y un fine-tune para adaptar el modelo a resolver una tarea NLP concreta como extraer datos relevantes de un documento, y con pocos ejemplos. 

Esta combinación es ideal para transferir el pre-entrenamiento de un modelo con grandes cantidades de textos a tareas para las que se disponen de pocos ejemplos. 

Nuestra aproximación consiste en utilizar LLMs pre-entrenados disponibles en la comunidad Open Source y realizar un fine-tune para convertir los documentos en papel en datos digitales. 

Hemos conectado nuestro IDP Fastcapture con el hub de Hugging Face donde residen LLMs pre-entrenados Open Source para acceder a ellos y generar versiones especializadas mediante un fine-tune en nuestro hub privado sin enviar los datos al hub público.

 

Cómo incorporar los LLMs en un IDP

La estrategia que hemos seguido para incorporar los LLMs en nuestro IDP Fastcapture se ha basado en 3 pilares, aprender a través de I+D, apoyarnos en la comunidad Open Source de AI y construir sobre lo que ya teníamos.

Estos han sido los pasos clave del proyecto:

  1. La selección del LLM pre-entrenado
  2. El diseño del contexto del Transformer
  3. Utilizar entornos multi-GPU para realizar el fine-tune y el servicing

 

La selección del LLM pre-entrenado

La comunidad Open Source de AI da acceso a LLMs pre-entrenados con un nivel de calidad enterprise-grade. Nuestro caso de uso requiere un modelo tipo encoder con capacidades multi idioma. De esta manera un único modelo será capaz de extraer datos relevantes de documentos del mismo tipo con diferente idioma.

Nos decantamos por el modelo pre-entrenado XLM-R propuesto en el paper “Unsupervised Cross-lingual Representation Learning at Scale” Conneau et al. 2020. El modelo XLM-R ha sido pre-entrenado en 2.5TB de textos con 100 idiomas. Hemos utilizado las siguientes tallas:

Modelo

Número de parámetros

XLM-RLarge

550M

XLM-RXL

3.5B



Diseño del contexto del Transformer

Diseñar cómo usar el contexto del LLM es un factor importante a la hora de conseguir niveles de performance de 0.9.

Los documentos están organizados en páginas y frases. Lo que queremos es que el LLM analice frase a frase en búsqueda de datos relevantes. Los tipos de documentos que manejamos son más bien telegráficos, con poco texto. Esto suele ser una tónica habitual al tratar documentos en papel en el mundo empresarial. 

Para dar una mejor oportunidad al LLM de hacer su tarea ubicamos la frase de interés a la derecha del contexto y completamos el contexto por la izquierda con las frases predecesoras que quepan.

El siguiente esquema muestra el diseño al que nos referimos.

Fine-tune y servicing en un entorno multi-GPU

Realizar un fine-tune de un LLM requiere utilizar GPU’s (Graphics Processing Units). El modelo XLM-RLarge puede entrenarse sin utilizar un framework que optimice el uso de la memoria o que distribuya el modelo entre diferentes GPUs. 

Sin embargo la versión XLM-RXL es tan grande que al realizar el algoritmo de gradient descent no cabe y requiere utilizar frameworks de optimización y/o que distribuyan el modelo en el entorno multi-GPU.

El proyecto lo hemos realizado en una máquina virtual con 4 GPUs NVIDIA a10g, y hemos utilizado el framework propuesto en el paper “ZeRO: Memory Optimizations Toward Training Trillion Parameter Models” Rajbhandari et al. 2020. ZeRO optimiza el uso de la memoria para almacenar el estado del modelo a la hora de entrenar y permite distribuir los gradientes y los parámetros entre las GPUs.

Utilizar entornos multi-GPU y frameworks de optimización como ZeRO, a parte de poder escalar el proceso de fine-tuning, permite gestionar los recursos computacionales que requieren modelos extra grandes. 

 

Resultados

En el proyecto hemos utilizado 2 juegos de datos, uno de factura y otro de informes económicos.

 

El impacto de la talla en el performance depende del caso de uso

Las siguientes gráficas muestran el F1 score de las 2 tallas, L y XL, en cada uno de los juegos de datos.

Gráfica 1. F1 score fine-tune facturas XLM-RLarge
Gráfica 2. F1 score fine-tune facturas XLM-RXL
Gráfica 3. F1 score fine-tune informes XLM-RLarge
Gráfica 4. F1 score fine-tune informes XLM-RXL

Estas gráficas ayudan a visualizar la diferencia de performance entre las tallas L y XL en los 2 juegos de datos y poder decidir qué modelo utilizar en el IDP. En el caso de las facturas la talla XL obtiene un score medio 8 puntos básicos mejor que la talla L, mientras que en el caso de los informes económicos la diferencia del score medio es de 1 punto básico. 

Al elegir el tamaño de modelo adecuado para cada caso de uso hay que considerar varios factores como el performance del modelo, los recursos de computación y el trade-off entre precisión y complejidad. En algunos casos, un modelo más pequeño puede proporcionar resultados suficientemente precisos con menores requisitos de computación y menor complejidad de mantenimiento. 

La importancia de diseñar el contexto al trabajar con LLMs

El diseño del contexto es clave para cualquier caso de uso con LLMs. La siguiente gráfica muestra el resultado de un fine-tune del modelo XLM-RLarge sin utilizar el contexto con diseño de ventana. El F1 score medio es 3 puntos básicos inferior sin utilizar el diseño de contexto con ventana.

Gráfica 3. F1 score fine-tune informes XLM-RLarge
sin el diseño de contexto con ventana

Referencias

Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, and Illia Polosukhin. 2017. Attention is all you need. arXiv:1706.03762 

Alec Radford, Karthik Narasimhan, Tim Salimans, Ilya Sutskever. Improving Language Understanding by Generative Pre-Training. 2018. 

Alexis Conneau, Kartikay Khandelwal, Naman Goyal, Vishrav Chaudhary, Guillaume Wenzek, Francisco Guzman, Edouard Grave, Myle Ott, Luke Zettlemoyer, Veselin Stoyanov. Unsupervised Cross-lingual Representation Learning at Scale. 2020. arXiv:1911.02116v2.

Samyam Rajbhandari∗ , Jeff Rasley∗ , Olatunji Ruwase, Yuxiong He. ZeRO: Memory Optimizations Toward Training Trillion Parameter Models. 2020. arXiv:1910.02054v3

¿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

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

octubre 4, 2023
LEER MÁS

Cambios de liderazgo en Bluetab EMEA

abril 3, 2024
LEER MÁS

Workshop Ingeniería del caos sobre Kubernetes con Litmus

julio 7, 2021
LEER MÁS

Guía avanzada sobre almacenamiento en Snowflake

octubre 3, 2022
LEER MÁS

5 errores comunes en Redshift

diciembre 15, 2020
LEER MÁS

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

septiembre 13, 2024
LEER MÁS

Publicado en: Blog, Destacado, Tech

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

Footer

LegalPrivacidadPolítica de cookies

Patrono

Patrocinador

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