Bluetab

Usando los Grandes Modelos de Lenguaje en información privada

Roger Pou Lopez
Data Scientist

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

Estos sistemas combinan los conceptos de vectorizaciónbú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.

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.
https://zilliz.com/learn/Retrieval-Augmented-Generation

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.

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.

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.

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/

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.

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.

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.

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

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.

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.

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

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.

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'})]

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.

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.

Javi:Prueba

Deygersn Méndez
DATA

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

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

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

Rubén Villa

Big Data & Cloud Architect

Jon Garaialde

Cloud Data Solutions Engineer/Architect

Alfonso Jerez

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

Alberto Jaén

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

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

Los contenidos de cada artículo son los siguientes:

Primera entrega:

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

Esta entrega:

  • Seguridad
  • Persistencia
  • Billing

El primer artículo puede visitarse en el siguiente enlace

Glosario

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

Seguridad de la información

Visita Data security and encryption en esté enlace

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

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

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

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

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


Customer-managed keys

Visita Customer-managed keys en esté enlace

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

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

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

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


Encriptación en tránsito

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

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

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

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

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

Persistencia y metastores

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

DBFS

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

S3

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

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

Metastore de Hive

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

Metastore Glue en Data Plane

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

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

Unity Catalog 

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

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

Características clave de Unity Catalog

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

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

Modelo de objetos de Unity Catalog

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

Billing

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

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

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

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

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

Referencias

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

Rubén Villa

Big Data & Cloud Architect

Alfonso Jerez

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

Jon Garaialde

Cloud Data Solutions Engineer/Architect

Alberto Jaén

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

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

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

Jon Garaialde

Cloud Data Solutions Engineer/Architect

Rubén Villa

Big Data & Cloud Architect

Alfonso Jerez

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

Alberto Jaén

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

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

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

Primera entrega:

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

Segunda entrega:

  • Seguridad.
  • Persistencia.
  • Billing.

Introducción

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

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

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


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

Colaboración Spark, Delta Lake y MLFlow

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

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

Data Lakehouse & Delta

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

Diagrama de un Data Lakehouse (fuente: Databricks)

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

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

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

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

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

Patrón de diseño de datos

  • Ingesta de datos

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

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

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

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

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

  • Servicio de datos

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

Características

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

Conceptos: Account & Workspaces

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

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


Billing: Databricks units (DBUs)

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


Authentication & Authorization

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

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


Data science & Engineering

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

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


Databricks interfaces

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

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


Data management

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

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


Computation management

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

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


Machine learning

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

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


SQL

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

Arquitectura: Arquitectura a alto nivel

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

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

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

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

Control plane y compute plane

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

Databricks opera desde un control plane y compute plane.

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

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

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


Arquitectura E2

La plataforma E2 proporciona características tales como:

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

Planes y tipos de carga de trabajo

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

El precio imputado por DBU depende de dos factores principales:

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

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

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

Networking

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

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

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

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


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

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

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

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

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

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

Referencias

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

Databricks concepts [link] (January 31, 2024)

Architecture [link] (December 18, 2023)

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

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

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

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

Jon Garaialde

Cloud Data Solutions Engineer/Architect

Alfonso Jerez

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

Rubén Villa

Big Data & Cloud Architect

Alberto Jaén

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

Walter Talaverano

Data ops

Walter Talaverano

Microsoft Certified

Walter Talaverano

Microsoft certified

Introducción

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

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

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

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

<style>
body{
background-color:red
}


</Style>

Las características clave de DataOps incluyen:

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

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

Aumentando las capacidades de uso de la IA

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

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

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

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