• 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
  • English

Blog

Usando los Grandes Modelos de Lenguaje en información privada

marzo 11, 2024 by Bluetab

Roger Pou Lopez
Data Scientist

Un RAG, acrónimo de «Retrieval Augmented Generation», representa una estrategia innovadora dentro del procesamiento de lenguaje natural. Se integra con los Grandes Modelos de Lenguaje (LLM, por sus siglas en inglés), tales como los que usa ChatGPT internamente (GPT-3.5-turbo o GPT-4), con el objetivo de mejorar la calidad de la respuesta y reducir ciertos comportamientos no deseados, como las alucinaciones.

https://www.superannotate.com/blog/rag-explained

Estos sistemas combinan los conceptos de vectorización y búsqueda semántica, junto con los LLMs para retroalimentar su conocimiento con información externa que no se incluyó durante su fase de entrenamiento y que, por lo tanto, desconocen.

Existen ciertos puntos a favor de utilizar RAGs:

  • Permiten reducir el nivel de alucinaciones que presentan los modelos. A menudo, los LLM responden con información incorrecta (o inventada), aunque semánticamente su respuesta tenga sentido. A esto se le denomina alucinación. Uno de los objetivos principales del RAG es intentar reducir al máximo este tipo de situaciones, especialmente cuando se pregunta por cosas concretas. Esto es de alta utilidad si se quiere utilizar un LLM de forma productiva.
  • Utilizando un RAG, ya no es necesario reentrenar el LLM. Este proceso puede llegar a ser costoso económicamente, dado que necesitaría GPUs para su entrenamiento, además de la complejidad que puede conllevar ese entrenamiento.
  • Son sistemas económicos, rápidos (utilizan información indexada) y además, no dependen del modelo que se está utilizando (en cualquier momento podemos cambiarlo por de GPT-3.5 a Llama-2-70B).

En contra:

  • Se va a necesitar ayuda de código, matemáticas y no va a ser tan sencillo como lanzar un simple prompt modificado.
  • En la evaluación de los RAGs (veremos más adelante en el artículo) vamos a necesitar modelos potentes como GPT-4.

Ejemplo de caso de uso

Existen varios ejemplos donde los RAGs están siendo utilizados. El ejemplo más típico es su uso con chatbots para consultar información muy específica del negocio.

  • En call-centers, los agentes están empezando a utilizar un chatbot con información sobre tarifas para poder responder de forma rápida y eficaz a las llamadas que reciben.
  • En chatbots, como asistentes de venta donde están ganando popularidad. Aquí, los RAGs ayudan a responder a comparativas entre productos o cuando se consulta de manera específica sobre un servicio, haciendo recomendaciones de productos similares.

Componentes de un RAG

https://zilliz.com/learn/Retrieval-Augmented-Generation

Vamos a hablar en detalle sobre los distintos componentes que conforman un RAG para poder tener una idea aproximada, y luego vamos a hablar de cómo interaccionan entre sí estos elementos.

Base de conocimiento

Este elemento es un concepto un poco abierto pero también lógico: se refiere al conocimiento objetivo del cual sabemos que el LLM no es consciente y que tiene un alto riesgo de alucinación. Este conocimiento, en formato de texto, puede estar en muchos formatos: PDF, Excel, Word, etc… Los RAGs avanzados son capaces también de detectar conocimientos en imágenes y tablas.

En general, todo contenido va a ser en formato de texto y va a necesitar ser indexado. Como los textos humanos son muchas veces desestructurados, se recurre a la subdivisión de los textos con estrategias llamadas chunking.

Modelo de Embeddings

Un embedding es la representación vectorial generada por una red neuronal entrenada sobre un cuerpo de datos (texto, imágenes, sonido, etc.) que es capaz de resumir la información de un objeto de ese mismo tipo hacia un vector dentro de un espacio vectorial concreto.

Por ejemplo, en el caso de un texto que se refiere a “Me gustan los patitos de goma azules” y otro que dice “Adoro los patitos de goma amarillos”, al ser convertidos en vectores, estos estarán más próximos en distancia entre sí que un texto que se refiere a “Los automóviles del futuro son los coches eléctricos”.

Este componente es el que, posteriormente, nos permitirá indexar de forma correcta los distintos chunks de información de texto.

Base de datos vectorial

Es el lugar donde vamos a guardar y indexar la información vectorial de los chunks mediante los embeddings. Se trata de un componente muy importante y complejo donde, afortunadamente, ya existen varias soluciones open source muy válidas para poder desplegarlo de forma «fácil», como Milvus o Chroma.

LLM

Es lógico, puesto que el RAG es una solución que nos permite ayudar a responder de forma más veraz a estos LLMs. No tenemos por qué restringirnos a modelos muy grandes y eficientes (pero no económicos como GPT-4), sino que pueden ser modelos más pequeños y más «sencillos» en cuanto a la calidad de respuestas y número de parámetros.

A continuación podemos ver una imagen representativa del proceso de carga de información en la base de datos vectoriales.

https://python.langchain.com/docs/use_cases/question_answering/

Funcionamiento a Alto Nivel

Ahora que tenemos un poco más claras las piezas del rompecabezas, surgen algunas dudas:

  • ¿Cómo interactúan estos componentes entre sí?
  • ¿Por qué hace falta una base de datos vectorial?

Vamos a intentar esclarecer un poco el asunto.

https://www.hopsworks.ai/dictionary/retrieval-augmented-generation-llm

La idea intuitiva del funcionamiento de un RAG es la siguiente:

  1. El usuario hace una pregunta. Transformamos la pregunta a un vector con el mismo sistema de embedding que hemos utilizado para guardar los chunks. Esto nos va a permitir comparar nuestra pregunta con toda la información que tenemos indexada en nuestra base de datos vectorial.
  2. Calculamos las distancias entre la pregunta y todos los vectores que tenemos en la base de datos. Seleccionamos, con una estrategia, algunos de los chunks y añadimos todas esas piezas de información dentro del prompt como contexto. La estrategia más sencilla es basarse en seleccionar un número (K) de vectores más próximos a la pregunta.
  3. Se lo pasamos al LLM para que genere la respuesta en base a los contextos. Es decir, el prompt contiene instrucciones + pregunta + contexto devuelto por el sistema de Retrieval. Por este motivo, la parte de «Augmentation» en las siglas del RAG, dado que estamos haciendo prompt augmentation.
  4. El LLM nos ha generado una respuesta en base a la pregunta que hacemos y el contexto que le hemos pasado. Esta será la respuesta que el usuario va a visualizar.

Es por eso que necesitamos un embedding y la base de datos vectorial. Ahí está un poco el truco. Si eres capaz de encontrar información muy parecida a tu pregunta en tu base de datos vectorial, entonces puedes detectar contenido que puede ser de utilidad para tu pregunta. Pero para todo ello, necesitamos un elemento que nos permita poder comparar textos de forma objetiva y esa información no podemos tenerla guardada de forma desestructurada si necesitamos hacer preguntas de forma frecuente.

También, que al final todo esto termina en el prompt, que nos permite que sea un flujo independiente del modelo de LLM que vayamos a usar.

Evaluación de los RAG

De igual manera que los modelos de estadística o ciencias de datos más clásicos, tenemos una necesidad de cuantificar cómo está funcionando un modelo antes de utilizarlo de manera productiva.

La estrategia más básica (por ejemplo, para medir la efectividad de una regresión lineal) consiste en dividir el conjunto de datos en distintas partes como train y test (80 y 20% respectivamente), entrenando el modelo en train y evaluando en test con métricas como el root-mean-square error, dado que el conjunto de test son datos que no ha visto el modelo. Sin embargo, un RAG no consta de entrenamiento sino de un sistema compuesto de distintos elementos donde una de sus partes es usar un modelo de generación de texto.

Más allá de esto, aquí ya no tenemos datos cuantitativos (es decir, números) y la naturaleza del dato consiste en texto generado que puede variar en función de la pregunta que le hagamos, el contexto detectado por el sistema de Retrieval y incluso el comportamiento no determinista que tienen los modelos de redes neuronales.

Una estrategia básica que podemos pensar es en ir analizando a mano qué tan bueno está funcionando nuestro sistema, en base a hacer preguntas y ver cómo están funcionando las respuestas y los contextos devueltos. Pero este enfoque se vuelve impracticable cuando queremos evaluar todas las posibilidades de preguntas en documentos muy grandes y de forma recurrente.

¿Entonces, cómo podemos hacer esta evaluación?

El truco: Aprovechando los propios LLMs. Con ellos podemos construir un conjunto de datos sintético con el que se haya simulado la misma acción de hacer preguntas a nuestro sistema, tal como si un humano lo hubiera hecho. Incluso le podemos añadir un nivel de fineza mayor: utilizar un modelo más inteligente que el anterior y que funcione como un crítico, que nos indique si lo que está sucediendo tiene sentido o no.

Ejemplo de conjunto de datos de evaluación

https://docs.ragas.io/en/stable/getstarted/evaluation.html

Aquí lo que tenemos son muestras de Pregunta-Respuesta de cómo hubiera funcionado nuestro sistema de RAG simulando las preguntas que le podría hacer un humano en comparativa al modelo que estamos evaluando. Para hacer esto, necesitamos dos modelos: el LLM que utilizaríamos en nuestro RAG, por ejemplo, GPT-3.5-turbo (Answer) y otro modelo con mejor funcionamiento para generar una “verdad” (Ground Truth), como GPT-4.

Es decir, en otras palabras, el ChatGPT 3.5 sería el sistema generador de preguntas y el ChatGPT 4 sería como la parte crítica.

Una vez generado nuestro conjunto de datos de evaluación, lo que nos queda es cuantificar numéricamente con algún tipo de métrica.

Métricas de Evaluación

La evaluación de las respuestas es algo nuevo pero ya existen proyectos de código abierto que logran cuantificar de forma efectiva la calidad de los RAGs. Estos sistemas de evaluación permiten medir la parte de «Retrieval» y «Generation» por separado.

https://docs.ragas.io/en/stable/concepts/metrics/index.html

Faitfulness Score

Mide la veracidad de nuestras respuestas dado un contexto. Es decir, con qué porcentaje lo que se pregunta es verdad en función del contexto conseguido a través de nuestro sistema.  Esta métrica sirve para intentar controlar las alucinaciones que pueden tener los LLMs. Un valor muy bajo en esta métrica implicaría que el modelo se está inventando cosas, aunque se le dé un contexto. Por lo tanto, es una métrica que debe estar lo más cercano a uno.

Answer Relevancy Score

Cuantifica la relevancia de la respuesta en base a la pregunta que se le hace a nuestro sistema. Si la respuesta no es relevante a lo que le preguntamos, no nos está respondiendo adecuadamente. Por lo tanto cuanto más alta sea esta métrica, mejor.

Context Precision Score

Evalua si todos los elementos de nuestros ground-truth ítems dentro de los contextos, son rankeados de forma prioritaria o no.

Context Recall Score

Cuantifica si el contexto devuelto se alinea con la respuesta anotada. En otras palabras, cómo de relevante es el contexto respecto a la pregunta que hacemos. Una valor bajo indicaría que el contexto devuelto es poco relevante y no nos ayuda a responder la pregunta.

El cómo todas estas métricas se están evaluando es un poco más complejo pero podemos encontrar ejemplos bien explicados en la documentación de RAGAS.

Ejemplo práctico utilizando LangChain, OpenAI y ChromaDB

Vamos a utilizar el framework de LangChain que nos permite construir un RAG de forma muy fácil.

El dataset que vamos a utilizar es un ensayo de Paul Graham, un dataset típico y pequeño en cuanto a tamaño.

La base de datos vectorial que vamos a utilizar va a ser Chroma, open-source y con plena integración con LangChain. El uso de esta va a ser completamente transparente, utilizando los parámetros por defecto.

NOTA: Cada llamada a un modelo asociado, tiene un coste monetario y conviene revisar el pricing de OpenAI. Nosotros vamos a trabajar con un dataset pequeño de 10 preguntas pero si se escalase, el coste podría incrementarse.

import os
from dotenv import load_dotenv  

load_dotenv() # Configurar OpenAI API Key

from langchain_community.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain.prompts import ChatPromptTemplate

embeddings = OpenAIEmbeddings(
    model="text-embedding-ada-002"
)

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size = 700,
    chunk_overlap = 50
)

loader = TextLoader('paul_graham/paul_graham_essay.txt')
text = loader.load()
documents = text_splitter.split_documents(text)
print(f'Número de chunks generados gracias al documento: {len(documents)}')

vector_store = Chroma.from_documents(documents, embeddings)
retriever = vector_store.as_retriever()
Número de chunks generados gracias al documento: 158

Dado que el texto del libro está en inglés, debemos de hacer nuestro template de prompt esté en inglés.

from langchain.prompts import ChatPromptTemplate

template = """Answer the question based only on the following context. If you cannot answer the question with the context, please respond with 'I don't know':

Context:
{context}

Question:
{question}
"""

prompt = ChatPromptTemplate.from_template(template)

Ahora vamos a definir nuestro RAG mediante LCEL. El modelo a utilizar que responderá a las preguntas de nuestro RAG va a ser GPT-3.5-turbo.  Importante es que el parámetro de la temperatura esté a 0 para que el modelo no sea creativo.

from operator import itemgetter

from langchain_openai import ChatOpenAI
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough 

primary_qa_llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0)

retrieval_augmented_qa_chain = (
    {"context": itemgetter("question") | retriever, "question": itemgetter("question")}
    | RunnablePassthrough.assign(context=itemgetter("context"))
    | {"response": prompt | primary_qa_llm, "context": itemgetter("context")}
)

.. y ahora es posible hacerle ya preguntas a nuestro sistema RAG.

question = "What was doing the author before collegue? "

result = retrieval_augmented_qa_chain.invoke({"question" : question}) 

print(f' Answer the question based: {result["response"].content}')
Answer the question based: The author was working on writing and programming before college.

También podemos investigar cuales han sido los contextos devueltos por nuestro retriever. Como hemos mencionado, la estrategia de Retrieval es la por defecto y nos devolverá los top 4 contextos para responder a una pregunta.

display(retriever.get_relevant_documents(question))
display(retriever.get_relevant_documents(question))
[Document(page_content="What I Worked On\n\nFebruary 2021\n\nBefore college the two main things I worked on, outside of school, were writing and programming. I didn't write essays. I wrote what beginning writers were supposed to write then, and probably still are: short stories. My stories were awful. They had hardly any plot, just characters with strong feelings, which I imagined made them deep.", metadata={'source': 'paul_graham/paul_graham_essay.txt'}),
 Document(page_content="Over the next several years I wrote lots of essays about all kinds of different topics. O'Reilly reprinted a collection of them as a book, called Hackers & Painters after one of the essays in it. I also worked on spam filters, and did some more painting. I used to have dinners for a group of friends every thursday night, which taught me how to cook for groups. And I bought another building in Cambridge, a former candy factory (and later, twas said, porn studio), to use as an office.", metadata={'source': 'paul_graham/paul_graham_essay.txt'}),
 Document(page_content="In the print era, the channel for publishing essays had been vanishingly small. Except for a few officially anointed thinkers who went to the right parties in New York, the only people allowed to publish essays were specialists writing about their specialties. There were so many essays that had never been written, because there had been no way to publish them. Now they could be, and I was going to write them. [12]\n\nI've worked on several different things, but to the extent there was a turning point where I figured out what to work on, it was when I started publishing essays online. From then on I knew that whatever else I did, I'd always write essays too.", metadata={'source': 'paul_graham/paul_graham_essay.txt'}),
 Document(page_content="Wow, I thought, there's an audience. If I write something and put it on the web, anyone can read it. That may seem obvious now, but it was surprising then. In the print era there was a narrow channel to readers, guarded by fierce monsters known as editors. The only way to get an audience for anything you wrote was to get it published as a book, or in a newspaper or magazine. Now anyone could publish anything.", metadata={'source': 'paul_graham/paul_graham_essay.txt'})]

Evaluando nuestro RAG

Ahora que ya tenemos nuestro RAG montado gracias a LangChain, nos falta evaluarlo. 

Parece que tanto LangChain como LlamaIndex empiezan a tener maneras de evaluar de forma fácil los RAGs sin moverse del framework. Sin embargo, por ahora, la mejor opción es utilizar RAGAS, una librería que ya habíamos mencionado y está específicamente diseñada con ese propósito. Internamente, va a utilizar GPT-4 como modelo crítico, tal y como hemos mencionado anteriormente.

from ragas.testset.generator import TestsetGenerator
from ragas.testset.evolutions import simple, reasoning, multi_context
text = loader.load()
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size = 1000,
    chunk_overlap = 200
)
documents = text_splitter.split_documents(text)

generator = TestsetGenerator.with_openai()
testset = generator.generate_with_langchain_docs(
    documents, 
    test_size=10, 
    distributions={simple: 0.5, reasoning: 0.25, multi_context: 0.25}
)
test_df = testset.to_pandas()
display(test_df)
question
contextsground_truthevolution_typeepisode_done
0What is the batch model and how does it relate…[The most distinctive thing about YC is the ba…The batch model is a method used by YC (Y Comb…simpleTrue
1How did the use of Scheme in the new version o…
[In the summer of 2006, Robert and I started w…
The use of Scheme in the new version of Arc co…
simpleTrue
2How did learning Lisp expand the author’s conc…[There weren’t any classes in AI at Cornell th…Learning Lisp expanded the author’s concept of…simpleTrue
3How did Moore’s Law contribute to the downfall…[[4] You can of course paint people like still…Moore’s Law contributed to the downfall of com…simpleTrue
4Why did the creators of Viaweb choose to make …[There were a lot of startups making ecommerce…The creators of Viaweb chose to make their eco…simpleTrue
5During the author’s first year of grad school …[I applied to 3 grad schools: MIT and Yale, wh…reasoningTrue
6What suggestion from a grad student led to the…[McCarthy didn’t realize this Lisp could even …reasoningTrue
7What makes paintings more realistic than photos?[life interesting is that it’s been through a …By subtly emphasizing visual cues, paintings c…multi_contextTrue
8«What led Jessica to compile a book of intervi…[Jessica was in charge of marketing at a Bosto…Jessica’s realization of the differences betwe…multi_contextTrue
9Why did the founders of Viaweb set their price…[There were a lot of startups making ecommerce…The founders of Viaweb set their prices low fo…simpleTrue
test_questions = test_df["question"].values.tolist()
test_groundtruths = test_df["ground_truth"].values.tolist()
answers = []
contexts = []
for question in test_questions:
  response = retrieval_augmented_qa_chain.invoke({"question" : question})
  answers.append(response["response"].content)
  contexts.append([context.page_content for context in response["context"]])

from datasets import Dataset # HuggingFace
response_dataset = Dataset.from_dict({
    "question" : test_questions,
    "answer" : answers,
    "contexts" : contexts,
    "ground_truth" : test_groundtruths
})
from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_recall,
    context_precision,
)

metrics = [
    faithfulness,
    answer_relevancy,
    context_recall,
    context_precision,
]

results = evaluate(response_dataset, metrics)
results_df = results.to_pandas().dropna()
question
answercontextsground_truthfaithfulnessanswer_relevancycontext_recallcontext_precision
0What is the batch model and how does it relate…The batch model is a system where YC funds a g…
[The most distinctive thing about YC is the ba…
The batch model is a method used by YC (Y Comb…
0.7500000.9131561.01.000000
1How did the use of Scheme in the new version o…
The use of Scheme in the new version of Arc co…
[In the summer of 2006, Robert and I started w…
The use of Scheme in the new version of Arc co…
1.0000000.9106431.01.000000
2How did learning Lisp expand the author’s conc…
Learning Lisp expanded the author’s concept of…
[So I looked around to see what I could salvag…
Learning Lisp expanded the author’s concept of…
1.0000000.9246371.01.000000
3How did Moore’s Law contribute to the downfall…Moore’s Law contributed to the downfall of com…
[[5] Interleaf was one of many companies that …
Moore’s Law contributed to the downfall of com…
1.0000000.9406821.01.000000
4Why did the creators of Viaweb choose to make …
The creators of Viaweb chose to make their eco…
[There were a lot of startups making ecommerce…
The creators of Viaweb chose to make their eco…
0.6666670.9604471.00.833333
5What suggestion from a grad student led to the…
The suggestion from grad student Steve Russell…
[McCarthy didn’t realize this Lisp could even …
The suggestion from a grad student, Steve Russ…
1.0000000.9317301.00.916667
6What makes paintings more realistic than photos?
By subtly emphasizing visual cues such as the …
[copy pixel by pixel from what you’re seeing. …
By subtly emphasizing visual cues, paintings c…
1.0000000.9634141.01.000000
7«What led Jessica to compile a book of intervi…Jessica was surprised by how different reality…
[Jessica was in charge of marketing at a Bosto…
Jessica’s realization of the differences betwe…
1.0000000.9544221.01.000000
8Why did the founders of Viaweb set their price…
The founders of Viaweb set their prices low fo…
[There were a lot of startups making ecommerce…
The founders of Viaweb set their prices low fo…
1.0000001.0000001.01.000000

Visualizamos las distribuciones estadísticas que salen:

results_df.plot.hist(subplots=True,bins=20)

Podemos observar que el sistema no es perfecto aunque hemos generado solamente 10 preguntas (haría falta generar muchas más) y también se puede observar que en una de ellas, la pipeline del RAG ha fallado en crear el ground truth.

Aun así podríamos sacar algunas conclusiones:

  • algunas veces no es capaz de dar respuestas muy veraces (faithfulness)
  • la relevancia de la respuesta es variable pero consistentmente buena (answer_relevancy)
  • el context recall es perfecto pero el context precision ya no tanto

Ahora aquí nos podemos plantear probar con distintos elementos:

  • cambiar el embedding utilizado por uno que podemos encontrar en HuggingFace MTEB Leaderboard.
  • mejorar el sistema de retrieval con estrategias diferentes a la por defecto
  • evaluar con otros LLMs

Con estas posibilidades, es viable analizar cada una de esas estrategias anteriores y escoger la que mejor se ajuste a nuestros datos o criterios monetarios.

Conclusiones

En este artículos hemos visto en qué consiste un RAG y cómo podemos evaluar un workflow completo. Todo esta materia está en auge ahora mismo dado que es una de las alternativas más eficaces y económicas para evitar el fine-tuning de los LLMs. 


Es posible que se encuentren nuevas métricas, nuevos frameworks, que hagan la evaluación de estos más sencilla y eficaz; pero en los próximos artículos no solo vamos a poder ver su evolución, sino también cómo llevar a production una arquitectura basada en RAGs.

Tabla de contenidos
  1. Componentes de un RAG
  2. Funcionamiento a Alto Nivel
  3. Evaluación de los RAG
  4. Métricas de Evaluación
  5. Conclusiones

Publicado en: Blog, Practices, Tech

PERSONAL MAPS: conociéndonos más

octubre 24, 2023 by Bluetab

PERSONAL MAPS: conociéndonos más

Pilar Chavarri

Delivery Manager

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

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

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

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

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

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

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

Experiencia de aplicación de Personal Maps

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

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

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

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

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

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

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

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

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

APRENDIZAJES

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

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

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


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

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

Pilar Chavarri

Delivery Manager

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

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

La gestión del cambio: El puente entre las ideas y el éxito

febrero 5, 2025
LEER MÁS

El futuro del Cloud y GenIA en el Next ’23

septiembre 19, 2023
LEER MÁS

KubeCon 2023: Una mirada hacia el futuro de Kubernetes

abril 26, 2023
LEER MÁS

Espiando a tu kubernetes con kubewatch

septiembre 14, 2020
LEER MÁS

Desplegando una plataforma CI/CD escalable con Jenkins y Kubernetes

septiembre 22, 2021
LEER MÁS

Algunas de las capacidades de Matillion ETL en Google Cloud

julio 11, 2022
LEER MÁS

Publicado en: Blog, Tech

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

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

marzo 6, 2023
LEER MÁS

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

noviembre 17, 2021
LEER MÁS

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

abril 7, 2021
LEER MÁS

Bluetab en la ElixirConfEU 2023

mayo 3, 2023
LEER MÁS

Conceptos básicos de AWS Glue

julio 22, 2020
LEER MÁS

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

febrero 15, 2022
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

Entrena y Despliega tu Modelo de Machine Learning en 15 Minutos con Databricks

junio 10, 2025
LEER MÁS

Gobierno de Datos: ¿tendencia o necesidad?

octubre 13, 2022
LEER MÁS

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

mayo 9, 2023
LEER MÁS

Cómo depurar una Lambda de AWS en local

octubre 8, 2020
LEER MÁS

PERSONAL MAPS: conociéndonos más

octubre 24, 2023
LEER MÁS

Big Data e IoT

febrero 10, 2021
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

Bluetab se certifica como AWS Well Architected Partner Program

octubre 19, 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

Oscar Hernández, nuevo CEO de Bluetab LATAM

mayo 16, 2024
LEER MÁS

Mi experiencia en el mundo de Big Data – Parte II

febrero 4, 2022
LEER MÁS

Data-Driven Agriculture; Applied Big Data, Cloud & AI

noviembre 4, 2020
LEER MÁS

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

marzo 24, 2022
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

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

septiembre 12, 2022
LEER MÁS

Detección de Fraude Bancario con aprendizaje automático

septiembre 17, 2020
LEER MÁS

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

octubre 16, 2023
LEER MÁS

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

noviembre 4, 2020
LEER MÁS

Hashicorp Boundary

diciembre 3, 2020
LEER MÁS

Detección de Fraude Bancario con aprendizaje automático II

septiembre 17, 2020
LEER MÁS

Publicado en: Practices, 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 12
  • Ir a la página siguiente »

Footer

LegalPrivacidadPolítica de cookies
LegalPrivacy Cookies policy

Patrono

Patron

Sponsor

Patrocinador

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