Sistemas Distribuidos

TEMA 1: INFRAESTRUCTURAS DE CÓMPUTO PARALELO

RESUMEN POR PARTES

Indice
1.1. - Introducción..................................................................................................................... 2
1.2. - Tipos de Sistemas Distribuidos ....................................................................................... 3
1.2.1 Sistemas de Información .............................................................................................. 3
1.2.2 Sistemas pervasivos (Ubícuos) ..................................................................................... 3
1.2.3 Sistemas de Cómputo de Altas Prestaciones................................................................ 4
1.3. - Sistemas Distribuidos de Computo ................................................................................. 4
1.3.1 Cluster .......................................................................................................................... 4
1.3.2. - Grid ............................................................................................................................ 6
1.3.3 - Cloud .......................................................................................................................... 7
1.4.- Paradigma Map / Reduce ................................................................................................. 8
1.5.- Hadoop.............................................................................................................................. 9
1.5.1 Hadoop Distributed File System ................................................................................. 10
1.5.2 Gestión de trabajos en cluster Hadoop ...................................................................... 10
1.6 Spark ................................................................................................................................. 10
1.6.1 Comparando Hadoop con Spark ................................................................................ 11
1.7 Spark SQL .......................................................................................................................... 11
1.1. - Introducción
Las definiciones no dejan de ser visiones parciales del sistema. «Un sistema en el cual, tanto los
componentes de hardware y software de un computador conectados en red, se comunican y
coordinan mediante paso de mensajes. Tanenbaum que formula, que los Sistemas Distribuidos
son algo más que nodos de cómputo conectados a través de una red, o sistemas que utilizan
mecanismos de paso de mensajes para establecer la comunicación de procesos. Para el usuario
una forma de ver el Sistema, para el ingeniero un conjunto de nodos conectados a través de una
red, más un paradigma que permite construir un sistema coherente a partir de un principio
simple.

Siguiendo el discurso científico, se necesitaría determinar en primer lugar, las causas que han
motivado la aparición y auge de los sistemas distribuidos. Al otro lado de la balanza, la posibilidad
de poder construir sistemas con potencia de cómputo suficiente para abordar la problemática
anterior. En este sentido, sabemos cómo construir sistemas a gran escala, a partir de unidades
de cómputo más pequeñas, e interconectarlas para que trabajen juntas, a través de redes de
interconexión de diferentes tecnologías, ayudadas con middlewares para coordinar todas las
actividades necesarias para la ejecución eficiente de las aplicaciones. No sería adecuado
empezar a describir las ventajas que aportan los sistemas distribuidos frente a los centralizados,
o esgrimir la lista de nuevos retos que se abren a la hora de construir este tipo de sistemas.

Prefiero dejar estos aspectos para algunas de las referencias clásicas que se dedican a esta clase
de comparativas, y centrar nuestros esfuerzos, en intentar profundizar en características de
diseño y nuevas problemáticas a resolver, a la hora de abordar algunos de los nuevos problemas
derivados en este tipo de sistemas.

Uno de los retos a resolver reside en hacer transparente

al usuario, la complejidad que supone el manejo eficiente
del sistema; tanto de los aspectos hardware, como del
middleware que se deberá incorporar para conseguir el
propósito anterior. La figura 1.1 muestra la arquitectura
subyacente.

La transparencia tiene múltiples dimensiones, y no es trivial encontrar el trade-off entre la

posibilidad de ocultar complejidad específica, frente a las prestaciones que ofrece la
implementación de esta.

Después de lo anterior, sería importante plantearse hacia dónde dirigir los esfuerzos a la hora de
implementar el middleware. Las opciones son tantas, que las apuestas del diseñador
determinarán la personalidad de este. Tampoco hay que olvidar, que demasiada transparencia
podría generar ineficiencias en el sistema; o dejar de entender el mismo.

No siempre, por tanto, será deseable la transparencia total de los módulos a seleccionar, que
nos ayuden en la confección de nuestros algoritmos.
1.2. - Tipos de Sistemas Distribuidos
Aunque nuestro interés será centrarnos en los sistemas distribuidos de cómputo, no me resisto
a comentar algunos de los aspectos más relevantes de los sistemas de información y pervasivos.

1.2.1 Sistemas de Información

Un sistema de información puede definirse, como un conjunto de componentes
interrelacionados que permiten capturar, procesar, almacenar y distribuir la información, para
apoyar la toma de decisiones y el control en una institución.

a) Sistemas de procesamiento de transacciones

Un sistema de procesamiento de transacciones es un tipo de sistema de información que

recolecta, almacena, modifica y recupera toda la información generada por las transacciones
producidas en una organización. Una transacción es un evento, que genera o modifica los datos
que se encuentran eventualmente almacenados en un sistema de información. Bajo esas
propiedades se pretende que una transacción siempre se complete o no , que los datos se
mantengan en estado válido en todo momento , que sea independiente y que sea permanente
frente a fallos del sistema .

La principal diferencia entre una base datos relacional y una

NoSQL, radica en el concepto de la estructura de los datos.
Además, este diseño beneficia una escalabilidad horizontal
simplemente añadiendo nodos para distribuir la carga, que
aventaja la escalabilidad vertical necesaria en bases de datos
relacionales. Estas razones principalmente hacen que las
bases de datos NoSQL sean las candidatas a adoptar cuando
se trate de manejar grandes volúmenes de datos de
naturaleza muy variada.

b) Integración de aplicaciones empresariales

El otro gran grupo de aplicaciones a nombrar, dentro de los sistemas de información, la

constituyen la Integración de Aplicaciones Empresariales. Otra clase importante de sistemas
distribuidos se encuentra en organizaciones que poseen una gran cantidad de aplicaciones de
red, pero cuya interoperabilidad se dificulta mucho. La necesidad de implementar la
comunicación entre aplicaciones llevo a desarrollar muchos tipos diferentes de modelos de
comunicación. La idea fundamental es que las
aplicaciones existentes puedan intercambiar
información directamente.

1.2.2 Sistemas pervasivos (Ubícuos)

En el mejor de los casos, los dispositivos pueden ser configurados por sus propietarios, pero ellos
deben descubrir su ambiente e integrarse lo mejor posible a los demás dispositivos. En este tipo
de ambientes, es común tener que trabajar con sistemas distribuidos donde la inestabilidad es
una constante, en vez de apostar por construir sistemas de imagen única, objetivo fundamental
en el diseño de middleware para sistemas distribuidos clásicos. Dispositivos pequeños, móviles
con batería, comunicaciones wifi, RFDI, y la autonomía de los sistemas autónomos y adaptación
al medio serían algunas de las características más relevantes.
1.2.3 Sistemas de Cómputo de Altas Prestaciones
En una primera aproximación, se podrían distinguir dos tipos de sistemas; aquellos que utilizan
la memoria principal para la comunicación y sincronización de procesos, y los que debido a las
necesidades de escalabilidad; comunican y sincronizan sus actividades, mediante la utilización
de paso de mensajes. Es interesante notar, el cambio sustancial que supone para el usuario el
diseño de aplicaciones en entornos distribuidos, frente al modelo de memoria compartida de los
multiprocesadores.

Los usuarios por lo general son reacios a los cambios, y la adopción de un nuevo paradigma de
programación para la programación de aplicaciones en las nuevas infraestructuras, supone un
desafío que puede frenar el avance de sistemas en este sentido.

1.3. - Sistemas Distribuidos de Computo

Construir sistemas que permitan conseguir el máximo paralelismo frente a parámetros de
costo/rendimiento a todos los niveles, ha sido desde los principios de la computación y sigue
siendo, una de las metas a conseguir para los diseñadores de computadoras.

1.3.1 Cluster
Intentando sintetizar al máximo; un cluster lo podemos definir como una colección de nodos de
cómputo independientes, conectados a través de una red; que trabajan de manera coordinada
(Sistemas de Imagen Única, SSI), para solucionar un problema, teniendo en cuenta diferentes
requerimientos prestacionales (tiempo de ejecución, throughput, consumo de energía etc).

 a (Nodo)

(Cluster
Middleware) b
→

Será función del Sistema Operativo fundamentalmente, y del middleware, figura 1.4 b);
coordinar sus módulos específicos de gestión de recursos a efectos de construir; tanto la interfaz
de usuario, como la infraestructura SSI requerida en este tipo de infraestructura.

Los problemas de diseño asociados a este tipo de sistema giran alrededor de conseguir:

• Escalabilidad • Seguridad
• Tolerancia de fallos • Facilitar la administración y gestión
• Balanceo de carga del mismo
• Interfaces homogéneas
En general, algunas de las características más relevantes de los clusters de HPC se muestran a
continuación:

Dentro de los sistemas que denominamos

Multicomputadores, una primera subdivisión
en la taxonomía mostrada en la figura 1.5, nos
acerca a los sistemas MPP (Masivelly Parallel
Proccessors) también conocidos como
Supercomputadores; donde asumiendo las
características generales enunciadas
anteriormente, se diseñan con componentes
específicos a medida, tanto a nivel hardware
como software.

Estos entornos se construyen a partir de ordenadores de sobremesa comerciales, que a un costo

mucho menor pueden obtener un rendimiento similar al de un sistema MPP. Por una parte, es
factible definir el sistema en función de sus objetivos, como puede ser la alta disponibilidad
implementados por sistemas como HA-OSCAR, el balanceo de carga gestionado por ejemplo, por
un sistema de tipo MOSIX o LVSP.

Otra forma de clasificar un sistema distribuido es a partir de la forma de utilización de los

recursos de cómputo. La primera opción en este sentido es la construcción de un sistema
construido para la ejecución de un único proceso de cómputo controlado por el sistema, a estos
sistemas se les denomina cluster Beowulf. Algunas de sus características se presentan a
continuación:

• Primer cluster construido con computadores personales 1994; con 16 DX4 procesadores
conectados mediante cannel bonded Ethernet. NASA Ames Centre)
• Nodos con mínimos recursos (sin monitor, ratón, tarjeta de vídeo)
• Un nodo servidor (frontend)
• Linux
• Sistema de ficheros compartido
• Herramientas de programación paralela (PVM, MPI)
• Sistemas de gestión de trabajos Batch, interactivos, secuenciales, paralelos

Tal disponibilidad de recursos sin embargo no determina una buena utilización de los mismos,
de hecho; diversos estudios han demostrado la baja utilización de recursos que se tiene en un
entorno de redes de ordenadores dirigido a usuarios con necesidades de interacción. De ahí, los
entornos NOW y COW configuran otro tipo de infraestructuras de cómputo a nivel local para
aprovechar los periodos de inactividad de los nodos individuales que poseen diferentes
instituciones; dotándolas sin coste adicional, de entornos de cómputo con una funcionalidad.
1.3.1.1 Visión de usuario/sistema
Pueden establecerse dos visiones radicalmente distintas, de la infraestructura analizada.

a) Visión de usuario

El usuario percibe el cluster, como si se tratase de un sistema convencional de tiempo

compartido. Como aspecto más relevante a destacar en este proceso, hay que poner especial
énfasis en la necesidad de especificar por parte del usuario, las necesidades de recursos de sus
aplicaciones, como se muestra en la figura 1.7. Será de vital importancia, que el entorno
proporcione herramientas orientadas a realizar análisis de escalabilidad, a partir de información
obtenida por el usuario; de pequeños prototipos que puedan alimentar a simuladores o modelos
analíticos entre otros, y que ayuden a determinar el número más adecuado de unidades de
procesamiento a utilizar, para la ejecución eficiente de las aplicaciones.

b) Visión del Administrador del Sistema

Frente a la visión de usuario, con requerimientos de transparencia de la infraestructura, la mayor

parte de las veces; las tareas del administrador del cluster se orientan a construir el entorno
adecuado para que el usuario.

Algunas de las tareas más relevantes a realizar, se citan a continuación:

• Administración de la red • Manejo de las políticas de planificación del

• Administración de servidores cluster
• Manejo del almacenamiento • Seguridad
• Arranque y parada del sistema • Monitorización ajuste y sintonización del
• Usuarios y cuotas sistema
• Instalación de herramientas e interfaces • Dimensionamiento del sistema y escalabilidad
• Virtualización de servicios y entornos

Dependiendo del tamaño y el uso, un clúster de procesamiento requiere de una administración

especializada y profesional, lo que lo hace poco atractivo para muchos investigadores.

1.3.2. - Grid
Un Grid lo podríamos definir como un tipo de sistema distribuido que comúnmente se construye
como una federación de sistemas de cómputo, en el que cada uno suele estar bajo un dominio
administrativo distinto, y en los que los componentes de hardware, software y tecnología de red
pueden ser muy diferentes. En el caso que nos ocupa, nos planteamos que hacer cuando
nuestras aplicaciones muestren necesidades de recursos superiores a la disponibilidad de
recursos locales de nuestras infraestructuras. Infraestructuras del tipo multicluster serían las
posibles propuestas al problema planteado Problemas ahora de coscheduling y co-asignación
serían ahora problemáticas a resolver
por el middleware a diseñar. Una de las
características más relevantes de los
sistemas grid estriba, en que los recursos
de distintas organizaciones son
compartidos por un grupo de personas o
instituciones para que colaboren entre si.
Esta colaboración se implementa como una organización virtual, en la que sus miembros tienen
derecho a usar los recursos que provee la organización virtual. Además, también se pueden
compartir otro tipo de recursos que pueden estar conectados a las distintas redes, tales como
telescopios, microscopios, sensores, etc...

A continuación, como se observa en la figura 1.10,

se presentan algunos de los retos más relevantes
a resolver en este tipo de sistemas. Donde la
heterogeneidad, el integrar diferentes dominios
de administración, suponer a Internet como la red
que integra el sistema, y manejar de manera
eficiente las características dinámicas de la carga,
son quizá los aspectos a tener en cuenta por el
diseñador del sistema

La necesidad de integrar múltiples dominios de administración, genera un nuevo nivel de

complejidad; donde los recursos de cada organización (cluster como unidad) son manejados por
los gestores de recursos locales de cada organización, siendo ahora tarea fundamental del
middleware hacer transparente esta complejidad.

1.3.3 - Cloud
La siguiente infraestructura pretende resolver la siguiente problemática. Por lo que, en
determinadas situaciones, la cantidad de recursos de la infraestructura estará
sobredimensionada, existiendo recursos libres infrautilizados. De manera similar, si hay
necesidad de recursos por la necesidad de picos de demanda de solicitudes, el cluster no podrá
atenderlas en general con la calidad de servicio
requerida. Por lo anterior, sería deseable ajustar
las necesidades de recursos de las aplicaciones,
al conjunto de recursos de la infraestructura en
tiempo de ejecución.

Cloud, el ajuste dinámico de los recursos en base a

posibles variaciones de la carga. Es de notar el cambio
de paradigma, donde los detalles no son dados al
usuario y por tanto no requiere del conocimiento,
experiencia, ni control de la infraestructura tecnológica
en la nube que les da cobertura. Esta situación implica
la provisión de recursos de manera dinámica y
escalable, frecuentemente virtualizados como servicios
a través de Internet.

Dentro de las características esenciales podemos destacar la solicitud bajo demanda, analizada
anteriormente, la virtualización y la característica de elasticidad.

a.- En relación a la virtualización, podemos observar las posibles alternativas en la imagen que
se adjunta.

Donde a nivel de emulación, se pretende ejecutar una aplicación preparada para una
determinada arquitectura ISA, en otra diferente. Es el nivel más antiguo de virtualización. A nivel
de poder desarrollar máquinas virtuales, se disponen de dos
alternativas basadas en el uso de un hipervisor, donde los de
nivel 1 actúan sobre el hardware directamente pudiendo ser
de virtualización completa, o paravirtualización . Los
hipervisores de nivel dos actúan por encima del S.O.

b.- La tercera característica a analizar es la

propiedad de elasticidad, quizá la más relevante
en los entornos del cloud. Consiste
fundamentalmente en adaptar los recursos
necesitados por las aplicaciones, a las
características dinámicas de las mismas. Algunas
de las alternativas más relevantes, se presentan
en la imagen que se muestra a continuación.

La problemática que supone su implementación viene derivada, por la multitud de opciones que
pueden integrar las posibles alternativas a la hora de generar las políticas asociadas.

1.4.- Paradigma Map / Reduce

Los recientes avances en las diferentes disciplinas científicas e ingeniería están generando
grandes cantidades de datos, que necesitan ser almacenados y analizados de manera eficiente.
El creciente volumen de datos digitalizados y procesados por aplicaciones, puede ser observado
en simulación, sensores de datos, procesamiento de imágenes médicas y en prácticamente todas
las áreas de conocimiento. Aplicaciones donde la necesidad de procesamiento no es el
requerimiento principal, sino el manejo en un tiempo razonable de ingentes cantidades de datos.

La computación de altas prestaciones tradicional está

implementada mediante arquitecturas paralelas del tipo
disco compartido , con nodos de cómputo y nodos de datos
diferenciados, como se muestra en la figura 1.13.

Los nodos de cómputo tienen un mínimo de

almacenamiento local, y están conectados entre ellos y
entre los nodos de datos por redes de comunicación de altas prestaciones. Aunque los avances
tecnológicos permitan redes de conexión cada vez más rápidas, el gran volumen de datos que
necesita ser transferido a través de la red por las aplicaciones intensivas de datos hace con que
el uso de estas arquitecturas no sea adecuado. Los modelos de programación paralela como MPI
y OpenMP, proporcionan un cierto nivel de abstracción sobre las operaciones de comunicación
y sincronización.
Las aplicaciones desarrolladas bajo el paradigma MapReduce
(figura 1.15), son paralelizadas de forma automática, y pueden
ser ejecutadas en un cluster de ordenadores de manera
sencilla. En tiempo de ejecución, el framework que implementa
MapReduce proporciona soluciones para cada una de las
necesidades de las aplicaciones paralelas.

Por ejemplo, se aplica una política predefinida para partición de los datos de entrada y la división
del trabajo en tareas, una política de planificación de las tareas en los diferentes nodos de
computación, una política de gestión de tolerancia a fallos, y un patrón de comunicación
transparente entre las diferentes tareas de la aplicación. MapReduce es un modelo de
programación que permite el procesamiento y la gestión de grandes volúmenes de datos. Los
archivos de entrada son divididos en bloques de tamaños más pequeños y son distribuidos entre
los nodos de cómputo. En la función MAP los datos de entrada son procesados y es generada
una lista de pares intermedios.

A continuación, la función Reduce se aplica sobre estas tuplas intermedias y hace la agrupación
de los valores que tienen la misma clave. Los datos de entrada son repartidos en bloques y
distribuidos para los nodos del cluster donde serán ejecutadas las funciones MAP. Estas tuplas
son almacenadas en los discos locales de cada nodo, ordenadas y distribuidas para los nodos
que ejecutarán las funciones de reducción.

1.5.- Hadoop
El proyecto Apache Hadoop consta de cuatro módulos principales:

HDFS: sistema de archivos distribuido de Hadoop. Este es el sistema de archivos que administra
el almacenamiento de grandes conjuntos de datos en un clúster de Hadoop. HDFS puede
manejar datos estructurados y no estructurados. El hardware de almacenamiento puede variar
desde cualquier HDD de nivel de consumidor hasta unidades empresariales.

Map/Reduce: El componente de procesamiento del ecosistema Hadoop. Asigna los fragmentos

de datos del HDFS en los discos locales para procesar las tareas. MapReduce maneja los bloques
en paralelo para combinarlos en el resultado deseado.

YARN: Otro planificador de recursos. Responsable de administrar los recursos informáticos y la

programación de trabajos.

Hadoop Common: El conjunto de bibliotecas y utilidades comunes del que dependen otros
módulos. Otro nombre para este módulo es el núcleo de Hadoop, ya que proporciona soporte
para todos los demás componentes de Hadoop.

Hadoop es un framework que implementa MapReduce desarrollado como un sistema de código

abierto, e implementado en lenguaje de programación Java.

A continuación, presentamos los puntos principales del sistema de archivos distribuidos de

Hadoop y cómo el planificador de trabajos Hadoop planifica y gestiona la ejecución de un trabajo
en su entorno.
1.5.1 Hadoop Distributed File System
Cuando se carga un archivo en el sistema, HDFS hace la división del archivo en bloques menores
con tamaño modificable por el usuario . A continuación, los bloques son distribuidos entre los
nodos de cómputo. El NameNode mantiene una tabla para establecer una correspondencia
entre cada bloque del fichero y su ubicación en el correspondiente nodo del cluster. NameNode
gestiona lo que llamamos namespace, es decir, la estructura jerárquica de directorios y los
metadatos para todos los archivos y directorios en HDFS.

DataNodes también mantienen el NameNode actualizado sobre sus estados. Durante el proceso
de inicialización, cada DataNode informa al NameNode sobre que bloques mantiene
almacenados. A continuación, los DataNode siguen informando al NameNode sobre los cambios
que se producen en los bloques que mantiene y reciben instrucciones del NameNode para crear,
mover o borrar los bloques que gestiona. NameNode mantiene todo el namespace en la
memoria.

Cuando un cliente necesita acceder a un archivo, primero consulta al NameNode sobre la

ubicación de los bloques que componen el archivo y luego empieza a interactuar directamente
con los DataNodes donde se almacenan los bloques. Sin embargo, en los entornos en que existen
limitaciones a la disponibilidad de disco, no es viable disponer de réplicas de los bloques de
entrada.

1.5.2 Gestión de trabajos en cluster Hadoop

Los trabajos MapReduce presentados al cluster son inyectados al sistema en la cola de trabajos
gestionada por el jobtracker, como se puede observar en la figura 1.18. El orden de ejecución de
estos trabajos es definido por la política de planificación de trabajos de Hadoop. Los trabajos
encolados son divididos por Hadoop en un conjunto de tareas Map y tareas Reduce. La figura
1.18 presenta la planificación de trabajos en Hadoop.

1.6 Spark
Apache Spark es una herramienta de código abierto. Está diseñado para un rendimiento rápido
y utiliza RAM para almacenar en caché y procesar datos. Spark realiza diferentes tipos de cargas
de trabajo de big data. Con API de alto nivel fáciles de usar, Spark puede integrarse con muchas
bibliotecas diferentes, incluidas PyTorch y TensorFlow.

El motor Spark se creó para mejorar la deficiencia de MapReduce y mantener sus beneficios.
Aunque Spark no tiene su sistema de archivos, puede acceder a datos en muchas soluciones de
almacenamiento diferentes.
Hay cinco componentes principales de Apache Spark:

• Apache Spark Core. La base de todo el proyecto. Spark Core es responsable de las funciones
necesarias como la programación, el despacho de tareas, las operaciones de entrada y salida,
la recuperación de fallas, etc. Otras funcionalidades se construyen sobre él.
• Spark Streaming. Este componente permite el procesamiento de flujos de datos en vivo. Los
datos pueden provenir de muchas fuentes diferentes, incluidas Kafka, Kinesis, Flume, etc.
• Spark SQL. Spark utiliza este componente para recopilar información sobre los datos
estructurados y cómo se procesan los datos.
• Biblioteca de aprendizaje automático (MLlib). Esta biblioteca consta de muchos algoritmos
de aprendizaje automático. El objetivo de MLlib es la escalabilidad y hacer que el aprendizaje
automático sea más accesible.
• GraphX. Un conjunto de API que se utilizan para
facilitar las tareas de análisis de gráficos.

Las aplicaciones Spark, como se muestra en la figura

1.19, constan de un proceso controlador y un
conjunto de procesos ejecutores. Los ejecutores son
los encargados de realizar efectivamente el trabajo
que les asigne el conductor.

1.6.1 Comparando Hadoop con Spark

Los dos framework manejan los datos de formas bastante diferentes. Aunque tanto Hadoop con
MapReduce como Spark con RDD procesan datos en un entorno distribuido, Hadoop es más
adecuado para el procesamiento por lotes. El objetivo de Hadoop es almacenar datos en discos
y luego analizarlos en paralelo en lotes en un entorno distribuido. MapReduce no requiere una
gran cantidad de RAM para manejar grandes volúmenes de datos.

Hadoop se basa en el hardware de todos los días para el almacenamiento y es el más adecuado
para el procesamiento de datos lineal. Apache Spark funciona con conjuntos de datos
distribuidos resistentes, ver figura 1.20. Con los cálculos en memoria y las API de alto nivel, Spark
maneja de manera efectiva las transmisiones en vivo de datos no estructurados. Además, los
datos se almacenan en un número predefinido de particiones.

Sin embargo, datos de entrada compartidos no son manejados eficientemente por Hadoop
causando accesos innecesarios a disco y tráfico en la red.

1.7 Spark SQL

Uno de los módulos de Spark orientado a consultas
sobre datos estructurados es Spark SQL, como se
observa en la figura 1.22. En los RDD comentados
anteriormente, Spark no conoce ningún tipo de
estructura, en este framework, se trata de
proporcionar una estructura a los datos para su
optimización.

Aparece el “Data Frame”, como nueva estructura de datos de Spark para este fin.

En el ejemplo siguiente, se observa como se construye a partir de un fichero json la “Data Frame”
comentada anteriormente. A partir de esta estructura de manejo distribuido como los RDD, se
pueden empezar a realizar consultas, poner filtros, escribir directamente en una tabla, etc.