Unidad 6: Big Data

Significado: Datos de gran volumen, velocidad y variedad que escapan a soluciones convencionales
para manejarlos de manera eficiente y económica.
Orígenes de datos:
● Web & Social Media
● Machine Generated Data (servers, sensores, RFID, VMs, etc)
● Internet of Things
El volumen de datos está aumentando considerablemente gracias al boom de la web 2.0 y
aplicaciones que constantemente recolectan datos del ambiente (estudio del clima, aviones en vuelo,
investigaciones astronómicas, estudio del genoma humano, estado del tránsito). Produce que el
límite entre lo que se considera BigData y lo que no pueda ir cambiando.

Propiedades de los datos

● Volumen: Gran volumen. Terabytes, hexabytes.
● Velocidad: Se generan a una frecuencia muy elevada.
● Variedad:
○ Estructurados, semiestructurados y no estructurados.
○ Fuentes heterogéneas (no compatibles).
○ Datos históricos.
○ Pueden ser generados en tiempo real.
● Valor: Su procesamiento o análisis debe ser de utilidad al negocio.

Técnicas: Funcionamiento general de los sistemas que tratan con BigData.

● Procesamiento y almacenamiento en forma distribuida.
● Los nodos de la red son coordinados para resolver cada tarea.
● Algoritmos distribuidos (Ej: MapReduce).

Arquitectura distribuida: Sistema donde sus componentes distribuidos son el principal

aspecto de diseño sobre el que se basa el sistema. Tiende a ser más tolerante a fallos
(un nodo queda fuera de servicio, es reemplazado por otro).
Formas de escalar la arquitectura:
● Vertical: Aumentar la capacidad de procesamiento asignando más recursos a
un único nodo. Más simple de comprender y mantener, pero no es tolerante a
fallos. Limitado por la tecnología. (arquitecturas convencionales)
● Horizontal: Aumentar la capacidad de procesamiento asignando más nodos.
Dichos equipos no son capaces de manejar de manera individual un gran
volumen de operaciones, pero en conjunto si. Más difícil de comprender y
mantener, pero es tolerante a fallos. (arquitecturas distribuidas)

Herramientas: Para que permita tratar con BigData debe manejar al menos algún problema (volumen,
velocidad, variedad) de los datos.
● Frameworks de procesamiento
○ Hadoop
○ Spark
○ Twitter Storm: Similar a Hadoop pero orientado a procesar Streams de datos.
Objetivo: Proveer resultados casi en tiempo real para aplicaciones que generan
grandes flujos de datos a gran velocidad.
● DBMS NoSQL
○ HBase
○ Cassandra
○ MongoDB
● Sistemas de cola de mensajes
○ Apache Kafka

Hadoop:
● Framework open-source para procesamiento distribuido de grandes volúmenes de datos.
● Componentes centrales: HDFS, YARN Map-Reduce v2 Framework.
● No es un DBMS (puede usar uno como fuente de datos, como HBase).
Arquitectura:
● Hardware simple y económico.
 ● Grandes volúmenes de datos, procesados localmente.
● Alta velocidad de procesamiento para el almacenamiento.
Características:
● Escalabilidad: Facilidad para agregar nuevos nodos.
● Bajo costo: Hardware convencional.
● Flexible: Datos no estructurados.
● Tolerancia a fallos: Al caer un nodo, otros toman su trabajo.

HDFS (Hadoop Distributed File System):

● Almacenamiento distribuido
● Ideal para almacenar grandes archivos
● Modelo de acceso: una escritura, muchas lecturas
● Datos replicados

Falla del hardware: Es más la norma que la excepción. Una instancia de HDFS puede consistir de
cientos o miles de servidores, por lo tanto en algún momento existirá un componente fuera de
funcionamiento. La detección de fallas y una recuperación rápida y automática es uno de los
objetivos principales de HDFS.

Arquitectura: “Mover el procesamiento es más conveniente que mover los datos”.

HDFS presenta una arquitectura maestro/esclavo. Un cluster HDFS consiste en un único Namenode,
server maestro que administra el namespace del file system y regula el acceso a los archivos por
clientes. Además, hay un número de Datanodes, en general uno por nodo en el cluster, que
administran el almacenamiento de los nodos en los que corren. HDFS expone un namespace de file
system y permite guardar datos de usuario en archivos. Internamente los archivos son divididos en
uno o más bloques y esos bloques son almacenados en un conjunto de Datanodes. El namenode
ejecuta operaciones de namespace del file system como apertura, cierre, renombramiento y
directorios. También determina la asociación de bloques a Datanodes. Los Datanodes son
responsables de atender los pedidos de lectura y escrita por parte de los clientes del file system. Los
Datanodes también crean, eliminan y replican bloques a pedido del Namenode.
El sistema se encuentra diseñado de tal forma que los datos de usuario nunca pasan a través del
namenode.
● Namenode
○ Server maestro que administra el file system
○ Gestiona los directorios y la ubicación de los archivos en datanodes
○ Asociación de bloques de archivos a datanodes y gestiona sus réplicas
○ Provee a los clientes la lista de datanodes que poseen el archivo buscado
○ No almacena los datos de los archivos
○ Punto único de fallo
● Datanode
○ Atienden los pedidos de lectura y escritura por parte de clientes
○ Envía periódicamente un heartbeat al Namenode para indicar actividad
○ Envía periódicamente un reporte de bloques al Namenode (lista de todos los bloques
del datanode. Para conocer el estado real de los nodos ya que cuando un cliente
quiere escribir, solicita al Namenode la lista de Datanodes donde debe escribir. La
escritura se hace directo a los Datanodes pero nunca se reporta al Namenode)
○ Datanodes pueden comunicarse entre sí
○ Los datanodes que reciben los bloques se encargan de replicarlos al resto de los
nodes de acuerdo al factor de replicación.

Réplica de datos: HDFS está diseñado para almacenar de forma confiable un gran número de
archivos a través de máquinas de un gran cluster. Guarda los archivos como una secuencia de
bloques; todos los bloques de un archivo tienen el mismo tamaño con excepción del último. Los
bloques de archivos son replicados para proveer tolerancia a fallos. El tamaño de bloque y el factor
de réplica se pueden configurar mediante un archivo. Los archivos en HDFS son escritos una sóla
vez y admiten únicamente una escritura a la vez. El namenode toma todas las decisiones
relacionadas con la réplica de bloques. Una nueva réplica puede ser necesaria si:
● Un datanode no está disponible
● Réplica incorrecta / fallo en disco
● Se incrementa el factor de réplica
Alta y baja de nodos: Para dar de alta nodos nuevos es necesario agregarlos en un archivo de
configuración utilizado por el Namenode ($HADOOP_PREFIX/etc/hadoop/slaves).
Cuando se dan de alta nodos nuevos estos automáticamente se empiezan a utilizar para almacenar
datos nuevos. Los nodos nuevos o reactivados pueden estar siendo usados por debajo de su
capacidad (utilizar HDFS balancer, para redistribuir la carga).

Punto único de fallos: El namenode en Hadoop 1.x era un punto único de fallos. Desde la versión 2.x
Pueden configurarse dos namenodes donde uno es el maestro y el otro esclavo. El esclavo funciona
en modo stand by copiando los datos del master. En caso de fallar el nodo maestro, el esclavo puede
tomar el rol de maestro. Esto puede realizarse de forma manual o automática. La copia de datos del
maestro al esclavo se realiza a través de un log compartido de modificaciones. Este log compartido
debe estar almacenado en un NFS (network file system) compartido por ambos nodos. Esto significa
que el NFS se convierte en un nuevo punto único de fallos. En versiones más nuevas de HDFS
existe la posibilidad de usar un nuevo componente llamado Quorum Journal Manager, que reemplaza
el NFS con un sistema de logeo de transacciones distribuido.

YARN + Map Reduce v2:

Map Reduce: Plataforma de procesamiento de datos distribuidos mediante operaciones Map-Reduce.
Permite desarrollar aplicaciones para procesar grandes volúmenes de datos (TB) en paralelo.
● Función Map: Procesa pares de clave-valor, generando un grupo de claves-valores
intermedios.
● Función Reduce: Une y combina todos los valores intermedios asociados a la misma clave
intermedia.
● Mapper: Realizan la misma tarea en paralelo. Procesan datos del mismo nodo o cercanos.
Reciben la tarea a realizar y la ubicación del archivo.
● Reducer: Recibe, unifica, ordena, procesa y reduce los resultados obtenidos por el Mapper.

Un trabajo (job) de Map-Reduce generalmente separa los datos de entrada en chunks

independientes que son procesados por las tareas Map en paralelo. El framework ordena las salidas
del mapa, las cuales se convierten en datos de entrada de la tarea Reduce. Normalmente la entrada
y salida de un trabajo son almacenadas en un filesystem. Los nodos que almacenan y procesan son
los mismos, optimizando el ancho de banda a lo largo del cluster. Las aplicaciones Map-Reduce
pueden no estar escritas en Java.
El framework Map-Reduce opera exclusivamente con pares de clave/valor, es decir, las entradas de
los trabajos vienen dadas por un conjunto de <clave, valor> y
la salida del trabajo produce conjuntos de <clave, valor>.

Contador de palabras
● Map: los mappers generan la salida
● Shuffle: La salida de los mappers es repartida entre
los distintos reducers de acuerdo a las claves.
● Sort: Los datos recibidos por cada reducer son
agrupados por clave <key, [list of values]>
● Reduce: La función de reduce es invocada una vez
por cada clave, recibiendo la lista de todos los
valores para esa clave.

La función de reduce no puede invocarse hasta que todos los mappers hayan finalizado, ya que se
necesita la lista completa de datos para cada clave.
La salida final de los reducers se almacena en archivos en el HDFS, uno por cada reducer.
Ningún dato intermedio es almacenado en el HDFS, solo se utiliza la memoria y el file system local
de cada nodo para manejar el flujo de datos de un dato a otro.

YARN: Plataforma de manejo de recursos distribuidos.

● ResourceManager: Se encarga de asignar recursos (nodos) para la ejecución de trabajos.
Existe un único ResourceManager para todo el cluster. Por cada trabajo a realizar asigna un
ApplicationMaster y varios Containers a los distintos NodeManagers.
● NodeManager: Se encarga de administrar recursos para un nodo a pedido del
ResourceManager. Existe un único NodeManager por cada nodo.
 ● ApplicationMaster: Se encarga de coordinar las tareas a realizar para un trabajo particular y
solicitar recursos al ResourceManager. Existe un único ApplicationMaster por cada trabajo a
realizar. Su ciclo de vida comienza y finaliza con el del trabajo a realizar. Al finalizar notifica al
ResourceManager el cual a su vez notifica al cliente.
● Container: Cada container ejecuta una subtarea del trabajo a realizar. Pueden existir varios
containers pertenecientes a un mismo trabajo dentro de un mismo nodo. Cada instancia de
Container representa una asignación de recursos para esa tarea (procesador y memoria).
Una vez finalizada la tarea notifica a su ApplicationMaster.

Herramientas de Alto Nivel

● Pig: Permite ejecutar operaciones Map-reduce sobre datos de forma distribuida, mediante
comandos simples. Utiliza lenguaje Pig Latin.
● Hive: Permite ejecutar operaciones simil SQL sobre datos distribuidos (cluster Hadoop).
○ Pensado para Data Warehouse.
○ Se abstrae del almacenamiento distribuido utilizado y las operaciones Map Reduce.
○ Schema on-read:
■ Se cargan los datos
■ Se define la estructura de la tabla para acceder a dichos datos
■ Se leen los datos
○ Convierte queries simil SQL (HiveQL) en jobs para YARN.
○ No está pensado para sistemas OLTP, operaciones en tiempo real ni operaciones a
nivel de registro.
● Mahout: componente que se para sobre YARN Map Reduce para ejecutar operaciones de
Machine Learning sobre datos distribuidos.
● Oozie: herramienta de scheduling de jobs de Map Reduce, utilizada para coordinar la
ejecución de varias operaciones Map Reduce.
● Sqoop: Servicio que actúa como interfaz entre los datos guardados en clúster de Hadoop y
el mundo de bases de datos relacional.
● Flume: Servicio pensado para la consolidación de información de log en una plataforma de
datos distribuida.
● Zoo Keeper: Sistema de coordinación para sistemas distribuidos.
○ Ofrece servicios de configuración, nombres, grupos y sincronización.
○ Permite implementar esquemas de selección de líder, consenso y presencia de
nodos en un cluster.
○ Arquitectura:
■ Un cliente puede conectarse a cualquier servidor de zookeeper.
■ Lecturas siempre desde el nodo al que el cliente está conectado.
■ Las escrituras al servidor son enviadas al líder, el cual las replica al resto de
los nodos. Las escrituras requieren quorum (más de la mitad de los nodos)
para confirmarse (indicar al cliente escritura exitosa).
○ Garantías:
■ Consistencia secuencial: las actualizaciones de un mismo cliente se aplican
en orden secuencial. Ningún otro cliente va a percibir los cambios en un
orden distinto del aplicado por el original.
■ Atomicidad: los cambios se aplican satisfactoriamente o fallan, no hay
aplicación parcial.
■ Imágen de sistema única: un cliente va a ver la misma imágen del sistema
sin importar el servidor al que se conecte.
■ Confiabilidad:
● Si un cliente recibe una respuesta de éxito, el cambio fue aplicado
exitosamente, si no recibe la respuesta el cliente no puede saber si
el cambio se aplicó o no.
● Cualquier cambio exitoso visto por un cliente no va a perderse en
caso de una falla de un servidor. Nunca se realiza rollback.
■ Límite temporal: la imágen del sistema vista por un cliente está garantizada
en estar actualizada dentro de un límite de tiempo menor a decenas de
segundos. En caso de detectarse que es más vieja que este límite el cliente
va a recibir un error de conectividad.
○ Utilizado por:
■ YARN para soportar HA (alta disponibilidad) en su ResourceManager
 ■ HBase (base de datos NoSQL basada en HDFS)
■ Apache Kafka (plataforma de streaming distribuido)

Spark: Plataforma de computación distribuida diseñada para ser rápida y

de uso general.
Spark Stack
● Shark/SparkSQL: fuentes de datos estructuradas.
● Spark Streaming: Flujos continuos de datos.
● GraphX: procesamiento de grafos.
● ML: Machine Learning library.
● Tachyon/Alluxio: Almacenamiento distribuido en memoria.
Generalidad: Soporta distintas cargas de trabajo
● Lotes (batch)
● Streaming
● Consultas interactivas
● Combinar distintas cargas de trabajo

Spark vs Hadoop: En Hadoop, cada trabajo que ejecutamos lee y escribe datos de HDFS. Combinar
trabajos es lento porque tenemos HDFS como intermediario.
Spark encadena la ejecución de múltiples trabajos y persiste datos intermedios en memoria.

Manipulación de datos:
● RDD: Resilient Distributed Dataset, es la manera en que se almacenan y manipulan los datos
en spark. Es similar a una tabla.
● SparkContext (sc): Es una conexión entre un programa y un cluster de spark.
● Transformation: transforma un RDD en otro RDD.
● Action: transforma un RDD en un valor o resultado.
● sc.textFile:
● Leer archivos en distintas ubicaciones.
● Archivo local de la máquina debe ser accesible con el mismo path en todos los nodos (debe
copiarse el archivo a todas las máquinas o montarse una unidad de red en todos los nodos
que apunten a los mismos archivos).
● También soporta urls de HDFS u otros filesystems distribuidos.
Las transformaciones se aplican de manera diferida mientras que las acciones de manera inmediata.
Si filtramos un RDD el RDD resultante no es calculado hasta que los datos sean necesarios. Por otro
lado las acciones se calculan en el momento que se aplican.

Shuffle: Algunas transformaciones de spark requieren hacer shuffle (similar Hadoop).

Cuando los datos deben agruparse por clave spark reparte los datos entre los distintos nodos para
crear las particiones del nuevo RDD.

Persistencia de RDDs: Al persistir un RDD evitamos recalcularlo en cada trabajo. Son compartidos
por todos los trabajos de la misma aplicación. Se realiza con propósito de caching, pero no es
definitivo (se descarta por LRU).

Arquitectura
El spark driver y los executors funcionan a nivel aplicación.
● SparkDriver: Aplicación que corre en la máquina del usuario. Cuando
creamos una aplicación generamos varios RDDs y transformaciones,
que generan un grafo de transformaciones a aplicar. Este grafo es
convertido por el mismo driver en tasks que serán enviados a los
executors.
● Executors: se crean al comenzar una aplicación y se encargan de
ejecutar las tareas enviadas por el spark driver. Cachean los RDDs
utilizando un servicio llamado BlockManager que existe para cada
Executor. Esto permite que las tareas se ejecuten junto a su partición de datos.
● ClusterManager: Inicia los executors. Es “pluggable” o conectable (distintas aplicaciones,
 como YARN o Apache Mesos, pueden utilizarse para cumplir este rol).

Spark Streaming: Procesa datos de forma continua.

Alimenta al motor de Spark partiendo el trabajo en lotes.
DStream: Similar a un RDD, pero representa un flujo continuo de datos.Observa un directorio, se va
actualizando con los datos que se van agregando. Soporta casi todas las mismas operaciones que
un RDD, pero las aplica de forma continua.

Spark SQL
● Soporta datos estructurados en Sprak
● Permite realizar consultas SQL dentro de cualquier programa hecho en Spark
● Acceso a distintas fuentes de datos con una API uniforme (Hive, JSON, JDBC)
● Permite realizar JOINs y queries complejos entre las distintas fuentes de datos.
Para acceder a un cluster de Spark, se usa mayoritariamente SQL como interface.

Unidad 7: NoSQL
Son bases de datos que se alejan del modelo relacional y suelen ser distribuidas.
Bases más recientes que parten del modelo relacional, generalmente con arquitecturas distribuidas,
escalabilidad horizontal y tolerancia a fallos y pensadas para manejar BigData. Suelen estar
optimizadas para escritura y lectura, pero no para consultas complejas (JOIN) ni transacciones.

Teorema CDP (CAP)

Es un teorema sobre sistemas distribuidos que indica que un sistema distribuido no puede cumplir
con las siguientes 3 características al mismo tiempo:
● Consistencia: La garantía de que todos los nodos del sistema vean la misma información al
mismo tiempo, aunque no necesariamente sea rápido.
● Disponibilidad: La garantía de que el sistema responda correctamente sin errores, aunque
no necesariamente tenga la información actualizada.
● Tolerancia a Particionamiento: la garantía de que el sistema pueda seguir operando a
pesar de una falla parcial del sistema, aunque no necesariamente sea eficiente ni tenga la
última información disponible.

Modelos de datos/Tipos de DB NoSQL

● Key-Value Store:
○ Guarda los datos en forma de diccionario (clave única - valor)
○ Los datos no suelen poseer estructura y son opacos para el motor
○ El usuario se encarga de manejar el formato de los datos
○ Suelen permitir operaciones simples como lectura y escritura pero no soportan
operaciones de consulta compleja.
● Column Oriented:
○ Los datos se almacenan en filas con múltiples columnas.
○ Los nombres de las columnas están almacenados junto con los datos.
○ Las columnas pueden ser variables, multidimensionales y tener omisiones.
○ Se dificultan las operaciones tipo JOIN.
● Document Store:
○ Los datos se almacenan en forma de documentos de texto (JSON, XML)
○ Sigue una estructura de datos flexible

¿Cuando usar un motor NoSQL?

● Datos no estructurados
● Volúmenes grandes de operaciones relativamente simples (no requieren transacciones ni
constraints complejas)
● Tolerancia a fallos: se necesita garantizar la accesibilidad a los datos.
● Escalabilidad: se necesita poder aumentar fácilmente la capacidad en el futuro.

MongoDB:
● Tipo: Documented Store
● Guarda los datos en formato BSON (Binary JSON)
● Asegura la disponibilidad mediante la replicación y redundancia de los datos.
● Schema-flexible: Se predefine un schema, pero no es necesario que se respete
 ● Soporta operaciones atómicas a nivel de documento.
● Asegura el escalamiento mediante particionamiento de los datos (sharding)

Arquitectura:

● Conceptos:
● Replicación: Mantener copias redundantes de datos entre distintos equipos de un
mismo clúster. Garantizar la disponibilidad de los datos.
ReplicaSet: Conjunto de nodos que se encarga de mantener un mismo conjunto de
datos. El nodo primario es el que recibe las operaciones de escritura. Luego los
nodos secundarios reciben copias de los datos directamente desde el nodo primario.
● Sharding: Particionar los datos en distintas máquinas, para facilitar el acceso de
acuerdo a quién los use.
● Componentes:
○ Config Servers: mantienen metadatos sobre la distribución de los datos en los
shards. En un entorno productivo existen 3 config servers que se mantienen
sincronizados. Si algún config server no está disponible, el cluster comienza a
funcionar en modo sólo lectura hasta que este se recupere.
○ Shard: Contiene los datos de una partición de una colección de mongo. Cada shard
se encarga de manejar los datos de su partición. Los datos se particionan basados
en su clave y el particionamiento puede ser por rango de clave o por hash de clave.
○ QueryServer: se encargan de recibir queries de los clientes y comunicarse con los
config servers y shards. Un cliente sólo se comunica con un query server a la vez, el
cual maneja el ciclo de vida del query completo.
● Mantenimiento:
○ Split: Cuando un bloque de datos crece demasiado, este se parte para distribuirse
entre distintos shards. El particionamiento de bloques es sólo un cambio de
metadatos, no hay ningún movimiento físico de datos hasta que intervenga una tarea
de balanceo.
○ Balance: Se encarga de mover datos de un shard a otro de acuerdo a la carga de
los shards. Estas tareas se disparan desde un query server y mueven bloques para
distribuir de manera pareja los datos entre todos los shards.

Modelo de datos:
● Documento: Equivalente a un registro en los RDBMS. Está conformado por varias duplas
clave-valor, donde el valor puede ser a su vez un nuevo documento. Cada documento debe
poseer un Id (llamado _Id) para poder identificarlo unívocamente en una colección.
● Collection: Equivalente a una tabla en un RDBMS. Es una agrupación de documentos que
pueden compartir o no un mismo schema. Las collections no están relacionadas entre sí, por
lo que deben agruparse dentro de una misma collection aquellos datos que se deseen
acceder de forma directa bajo una misma consulta.
● Tipos de Datos:
○ String
○ Number
○ Boolean (True/False)
○ NULL (es un tipo de datos diferente)
○ arrays
○ documents
● Consideraciones de modelado:
○ Pensar de antemano qué consultas se quieren responder y la
consistencia requerida para un conjunto de datos relacionados.
 Dada que la consistencia solamente se asegura dentro de un mismo documento,
aquellos datos deben estar en la misma collection.
○ Al estar los datos desnormalizados, se puede diseñar una collection por cada
consulta que se quiere responder.
○ Un documento tiene un tamaño máximo, por lo que es conveniente separar en varias
collections en caso que se exceda dicho tamaño.
○ Pueden crearse índices para mejorar la performance de las consultas.

Criterios de diseño:
● Queries a realizar
● Elección del Shard Key
○ Define cómo se van a distribuir los
dato en el cluster
○ NO debe tener baja cardinalidad
(datos quedan mal repartidos)
○ NO debe haber predominio de uno o
pocos valores
● Nivel de atomicidad

HBase
● Tipo: Column Oriented / Key Value
● Utiliza HDFS como filesystem
● Las tablas se almacenan en forma de logs (HDFS no permite sobreescritura)
● Basado en BigTable, Google
● No permite actualizaciones desde un punto de vista físico, pero si desde un punto de vista
lógico: Cuando actualizamos un dato se inserta un nuevo registro en el log indicando el
nuevo valor. Al momento de leer el valor para esa clave se busca el registro con el timestamp
más reciente. Físicamente una vez almacenado el registro en disco, puede volver a leerse
pero nunca se sobreescribe. Pero desde un punto de vista lógico el registro fue actualizado.

Modelo de datos:
Las columnas se agrupan por column family. Las column
family se definen a nivel esquema, pero su contenido es
libre: cualquier cantidad de columnas con nombres
arbitrarios para cada fila.

Column Family: Agrupan columnas en la tabla. Las column

families deben predefinirse en la creación de la tabla, luego
pueden crearse columnas arbitrarias dentro de ella.
Sirven de unidad de control para distintos aspectos del
tratamiento de datos:
● Compresión:
○ RECORD: La compresión se realiza limita al registro actual, es más rápido para el
acceso aleatorio, pero tiene menor capacidad de compresión.
○ BLOCK: Comprime los datos de la familia para todos los registros, alcanza un nivel
alto de compresión, pero debe descomprimirse el bloque entero para acceder a un
único registro.
● BloomFilters: Genera un índice extra para los nombres de columna, útil en los casos en que
se tienen una gran cantidad de columnas nombradas de forma variables. Consultar
eficientemente los registros en los que una columna determinada está presente.
● IN_MEMORY: Mantener familia en memoria para un acceso más rápido
● MAX_VERSIONS y MAX_LENGTH: Opciones que modifican la funcionalidad (no solo la
performance)
○ MAX_VERSIONS: default 3, cuántas versiones a recordar para las columnas en la
familia
○ MAX_LENGTH: máxima cantidad de bytes a almacenar: default (32bits=4gb)

Tipos de Datos: Los valores de las columnas son arrays de bytes, cualquier dato que quiera
almacenarse debe convertirse por parte de la aplicación al formato deseado. Al leerse los datos, la
aplicación debe encargarse de interpretar los datos correctamente.
 ● Ids: Deben ser generados por la aplicación, no existen campos autonuméricos. Ids
secuenciales no se recomiendan. Generar muchos registros secuenciales en poco tiempo
implica mucha carga de trabajo para un único nodo.
● Timestamps: Se definen a nivel microsegundo. Si dos actualizaciones de la misma timestamp
coincidieran ambas se almacenarían, pero el sistema devolvería la que se encuentre primero.

Arquitectura:

Heterogénea a nivel cluster, no todos los nodos son iguales.

● Master: se encarga de manejar los metadatos de las tablas y de asignar los rangos de claves
a las regiones. Si el nodo maestro se cae, el cluster puede seguir funcionando pero en forma
limitada. No se pueden realizar cambios de schema, ni realizar region splits (cuando una
región crece excediendo el límite permitido, se parte la región en dos nuevas, cada una
manejando un subrango de la región original. El split siempre es en el mismo RegionServer,
no se distribuye hacia otros. Distribuir las regiones es tarea del Master). A medida que las
regiones van creciendo, el Master se encarga de invocar el load balancer y reasignarlas a
diferentes region servers para balancear la carga del sistema.
● Region: es una partición de una tabla, cada tabla se parte en múltiples regiones, las cuales
manejan un rango de claves definido por el master. Almacenan filas enteras, No puede
quedar una fila separada en dos regiones.
● RegionServer: maneja las regiones que le son asignadas por el master y se encarga de
atender a los clientes.
● Cliente: los clientes únicamente se conectan a los region servers.
● Catalogo: Para conocer donde está almacenada una fila, el cliente accede a las tablas del
catálogo que indican qué region server se encarga de manejar cada región. Las tablas del
catálogo se almacena en Zookeeper, y lo primero que un cliente tiene que hacer para poder
leer el catálogo es consultar a Zookeeper cuál es dicha ruta.

Localidad de Regiones y RegionServer

HBase utiliza HDFS como almacenamiento para los datos, como consecuencia no controla
directamente donde son almacenados estos.

Cassandra
● Tipo: Column Oriented / Key Value
● Es autosuficiente (no depende de Hadoop ni ninguna otra herramienta)
● Totalmente distribuido (sin puntos únicos de falla)

Modelo de datos:
● Table: Es similar a una tabla RDBMS
● Cell: Es una terna key-value-timestamp
● Column: Primer componente de una celda, denota el nombre de la
propiedad que estamos modelando.
● Value: Es el valor almacenado en la celda.

Tipos de Datos:
Permite definir tipos de datos a través de un schema para sus valores de
columna, nombres de columna y ids de fila.
● Factor replicación: la cantidad de veces que un dato debe ser replicado en el cluster.
● Quorum: (N/2)+1 donde N es el factor de replicación.
● Snitch: Determinar nodos más cercanos, para minimizar retardos en respuestas.
 ● Hint: cuando un nodo no está disponible para escritura, se guarda un hint en un nodo vecino
que indica los datos pendientes de escritura cuando se recupere.
● Gossip: es el protocolo de comunicación que utiliza Cassandra para intercambiar datos de
estado entre los nodos.
● Coordinator: Nodo que se conecta el cliente para hacer un request, el cliente sólo interactúa
con este nodo.

Escritura: Los datos se almacenan replicados N veces, donde N es el factor de replicación.

Cuando se va a almacenar un dato, se utiliza la clave del registro para determinar cuales son los
nodos encargados de almacenar las N replicas correspondientes.

Eventually Consistent (consistencia eventual): La consistencia de datos está dada por el orden
temporal en que suceden los eventos, para determinar el orden de los eventos tanto para la escritura
como lectura se utiliza el timestamp. Siempre el dato con el timestamp más reciente es el que se
guarda/lee (en caso de empate se resuelve mediante el elemento de mayor valor de acuerdo a la
regla de ordenamiento que corresponda (sort)).
No tiene registro de valores previos de un dato, sólo almacena la versión más reciente.

Write Consistency: Especifica cuántas réplicas deben realizarse antes de confirmar al cliente que la
escritura fue exitosa. ANY es el menos consistente, pero más rápido, ALL es el más consistente, pero
más lento.
● ANY: retorna si ningún nodo de los correspondientes a la clave está disponible, caso en el
cual se crea un HINT y se almacena el dato en un nodo coordinador. Cuando se recupere
alguno de los nodos correspondientes se realiza la escritura. Tiene la desventaja que el dato
no puede leerse hasta que esté disponible alguno de los nodos de la clave.
● ONE: retorna si se puede almacenar al menos una copia en uno de los nodos
correspondientes a la clave.
● QUORUM: retorna si puede almacenar al menos (N/2)+1 copias
● LOCAL_QUORUM: similar a quorum pero dentro del data center, es más rápido porque evita
comunicación con nodos más alejados.
● EACH_QUORUM: quorum en cada datacenter.
● ALL: debe escribirse en todos los nodos de replicación.

Read Consistency:
● ONE: retorna la respuesta del nodo más cercano (según lo indicado por el snitch)
● QUORUM: cuando un quorum de respuestas es obtenido, se responde el que tenga el
timestamp más reciente.
● LOCAL_QUORUM: cuando un quorum dentro del datacenter es alcanzado, responde el dato
con el timestamp más reciente.
● EACH_QUORUM: cuando un quorum en cada uno de los data centers es alcanzado, se
retorna la respuesta que tenga el timestamp más reciente.
● ALL: cuando todas las replicas hayan sido respondidas se retorna la que tenga el timestamp
más reciente.

Consideraciones de modelado:
● Pensar de antemano qué consultas se quiere responder. Generalmente se diseña una
ColumnFamily por cada consulta, aunque implique desnormalizar.
● No hay índices creados automáticamente.
● Todos los datos pertenecientes a una fila deben poder almacenarse en un único nodo, ya
que la clave de la fila es que se utiliza para determinar qué nodos del cluster replicarán la fila.
● Existen distintos criterios para determinar los nodos a partir de la clave (aleatorio, ordenado),
el criterio óptimo depende de las consultas que se quieran realizar.
● Cuando una fila contiene supercolumnas, las subcolumnas no pueden indexarse, cuando se
accede a una subcolumnas se leen todos los contenidos de la supercolumna contenedora.

Arquitectura:
Homogénea, los nodos son todos iguales.
No hay nodos maestros, al estar todos los datos replicados el sistema no posee un punto único de
falla. Un cliente se conecta a cualquier nodo y este nodo se encarga de coordinar la consulta con el
resto de los nodos del cluster.

Particionamiento de datos: Cada nodo le es asignado un token (un identificador único en el cluster)
ya sea manualmente o automáticamente.
Las claves de los registros insertados luego se les aplica una función hash la cual determina en qué
rango de tokens pertenece.
Un servidor se encarga de manejar todos los registros cuyo hash sea menor al token del servidor. De
esta manera se dice que los servidores forman un anillo, donde cada uno se encarga de manejar su
rango correspondiente.
Cada servidor posee la réplica principal de su rango, pero además posee las réplicas secundarias y
terciarias de los dos nodos anteriores en el anillo.
A lo largo del tiempo puede ser que algunos servidores tengan más carga que otros, en ese caso
pueden re-calcularse los tokens para que los rangos de datos tengan aproximadamente el mismo
tamaño. Otras situaciones que pueden requerir rebalanceo es cuando se agregan o quitan nodos al
cluster.

Comparación

Unidad 8: Cloud Databases

Computación como servicio a través de internet. La entrega de recursos computacionales a
demanda, desde aplicaciones hasta data centers, a través de internet en un modelo “pay-for-use”.

Tipos de cloud
● Nubes públicas: Son propiedad de compañías que ofrecen acceso rápido a recursos
computacionales a través de una red pública a un costo asequible.
● Nubes privadas: Es una infraestructura operada únicamente para una sola organización, ya
sea gestionada internamente o por un tercero, y ubicada interna o externamente.
● Nubes híbridas: Usa bases de nube privada combinadas con la integración estratégica y el
uso de los servicios de nube pública.

Modelos de servicio en la nube

● IaaS (Infraestructura como Servicio): Provee hardware como CPUs,
memoria, almacenamiento, redes y balanceadores de carga.
● PaaS (Plataforma como Servicio): Proporciona a los usuarios con
plataformas de desarrollo y administración que proveen acceso on-
demand para acceder a los recursos de hardware disponibles.
● DaaS o DBaaS (Base de datos como Servicio): Independiza a las
 organizaciones de comprar motores de bases de datos y almacenamiento de costo elevado.
● SaaS (SW como Servicio): La forma definitiva de recursos de la nube que ofrece
aplicaciones de software a clientes en términos de servicios de accesibilidad

DaaS (Database as service)

La utilización de soluciones de datos como un servicio en la nube. Utilizar recursos remotos (cloud)
de forma transparente.Se trasladan algunos de los principales problemas a la nube:
● Administración de la base de datos
● Backups
● Mantenimiento del data center
● Optimización (tuning) de la base de datos

Objetivos principales
● Consolidación de la información
● Proporciona un recurso externo de almacenamiento y procesamiento de datos
● Abstracción del hardware: la base de datos queda pensada como un componente de
software únicamente (servicio).

Requerimientos de usuario
● Administración simplificada
● Alto rendimiento
● Escalabilidad horizontal
● Alta disponibilidad (HA: High Availability)
● Funcionalidad adicional:
○ Snapshot y live migrations on-the-fly
○ Backup & restore
○ Analytics, etc.

Requerimientos de administración:
● Reducción de costos: Hardware + mantenimiento, configuración, administración, etc.
● Acuerdos de Nivel de Servicio (SLA)

Restricciones y requerimientos en el cloud público

● Arquitectura elástica: auto-scaling
● Modelo de costos ajustado al cómputo efectivamente realizado
● Garantías de Seguridad
● Posibilidad de distribución geográfica de los datos

Anonimización de los datos

Para que exista una verdadera “anonimización” de datos personales, ésta debe ser irreversible.
● Singling out: supone aislar algunos datos del individuo de todo el conjunto de sus datos
personales
● Linkability: es la posibilidad de vincular al menos dos datos a un sujeto o grupo de sujetos,
de manera que que si es sobre estos últimos, la anonimización sería “fuerte” respecto a aislar
a un individuo (no se podría reconocer el mismo) pero sería “débil” sobre la “linkability” al
poder identificarlo respecto a un grupo
● Inference: permite conocer el valor de un atributo sobre el valor de conjunto de otros
atributos.

Multitenancy
● Sofware Multitenancy: Arquitectura de software en la cual una sola instancia de la
aplicación se ejecuta en el servidor, pero sirviendo a múltiples clientes u organizaciones
(tenedor o “tenant”).
● Database Multitenancy: Segreación de datos, espacio de almacenamiento y recursos de
procesamiento para múltiples clientes u organizaciones que permite crear múltiples “tenant
databases” dentro de una instancia de motor de base de datos.
● La clave en multitenancy es el aislamiento de los tenants, tanto en recursos como en
 acceso.

Modalidades
● Modalidad PaaS:
○ Se provee un motor de base de datos en un servidor (usualmente virtualizado)
○ El usuario es responsable de la administración (DBA) y gestión de los datos
○ Ejemplos: DB2 on Cloud, Informix on Cloud, Oracle on Cloud
● Modalidas DBaaS (Managed Services):
○ Servicio de datos totalmente gestionado por el proveedor de Cloud
○ Ejemplos: IBM Cloudant, IBM dashDB, Amazon DynamoDB

(Algo de IBM Cloudant que esta en ingles y para mi no es importante)

Cloudant Cluster
● Horizontalmente escalable
● Los datos se auto-fragmentan en el clúster
● Todos los datos almacenados por triplicado
● Construido utilizando un diseño maestro-maestro, por lo que no hay punto único de falla para
leer o escribir
● Replicación del centro de datos cruzados
● Equilibrio de carga geográfica para el acceso del usuario a los datos más cercanos a ellos

Futuro de Cloud
● La nube es el impulsor de la innovación del futuro.
● La nube híbrida se consolidará.
● Se perderá la disconformidad con la nube.
● Las batallas de la nube irán más allá del precio.
● El área de servicios cloud gestionados será mayor.
● Un hogar para las pequeñas empresas en la nube.

Unidad 9: Internet of Things

● Son dispositivos inteligentes interactuando con otros dispositivos, ambientes, infraestructuras
● Los cuales generan grandes volúmenes de datos
● Que mediante el procesamiento y análisis de los mismos datos generados
● Nos permiten tomar acción y control de la situación en cuestión
● Y en conjunto con otras soluciones de IoT forman red de redes.

Dispositivos inteligentes
Cuenta con:
● Sensores (capacidad de tomar información de la realidad/entorno/ambiente)
● Procesamiento (de información)
● Comunicación (con otros dispositivos)
● Control remoto (a partir de lo anterior se permite su control a distancia)
● Identidad (dentro de la red de dispositivos)
El fin último de estos dispositivos es evitar la interacción humana.

Capacidades de IoT
● Comunicación y cooperación: Las “cosas” tienen la habilidad de enlazarse con recursos de
internet y otros dispositivos, para utilizar datos y servicios y a su vez actualizar su estado.
Algunas de las tecnologías inalámbricas que se utilizan son: GSM, UMTS, Wi-Fi, Bluetooth,
ZigBee.
○ Direccionamiento: Los dispositivos pueden ser localizados y direccionados
 mediante discovery, lookup o servicios de nombre. Gracias a esto pueden ser
configurados y gestionados remotamente.
○ Identificación: Los dispositivos deben ser unívocamente identificables. RFID, NFC
(Near Field Communication) y lectores de códigos de barras son ejemplos de
tecnologías con las que objetos pasivos y sin energía propia pueden ser
identificados.
○ Bajo consumo
● Sensado: Los dispositivos recolectan información sobre su entorno mediante sensores, la
cual puede ser almacenada, reenviada o un motivo para disparar una reacción.
● Actuación: Los dispositivos poseen actuadores para manipular su entorno, pudiendolo hacer
de forma remota gracias al acceso a Internet.
● Procesamiento Embebido de datos: Los objetos inteligentes poseen capacidad de
procesamiento y de almacenamiento, pudiendo procesar información interpretada por un
sensor y almacenar el estado de una situación en particular.
○ Localización: Los dispositivos inteligentes conocen su ubicación o pueden ser
localizado. Los mecanismos más populares para localizar los dispositvos son GPS y
la red de telefonía celular, pero también existen otras tecnologías como medición de
tiempo por ultrasonido, UWB, radio beacons y tecnologías ópticas.
○ Interfaces de usuario: Los dispositivos inteligentes pueden comunicarse con
personas de distintas formas, por ejemplo mediante un smartphone. Otras
alternativas son interfaces especialmente diseñadas, reconocimiento de imágenes,
voz y gestos.
● Uso eficiente de energía
● Menor tamaño y bajo costo

Tipos de aplicaciones
Acción y Control
● Dispositivos interactuando con otros dispositivos/máquinas/infraestructuras
● Objetivo: Modificación del ambiente
Análisis
● Dispositivos de recolección de información para futuro análisis
● Objetivo: Identificar tendencias y comportamiento

Desafíos tecnológicos:
● Escalabilidad: Incluye una amplia variedad de dispositivos que interactúan con el entorno.
● Arrive and operate (plug & play): No deben requerir de un usuario que las configure y
adapte a situaciones particulares. Necesitan conectarse esporádicamente, auto-organizarse
y configurarse.
● Interoperabilidad: Gran diversidad de dispositivos que componen IoT, logran una
comunicación mediante la utilización de standards.
● Descubrimiento: Servicios para identificación automática de dispositivos, como pueden ser
buscadores de dispositivos o proveedores de información con estado de dispositivos.
● Complejidad de software: Se necesita una infraestructura compleja y extensa para
gestionar los dispositivos y almacenar y procesar la información que generan.
● Volúmenes de datos: Existen escenarios complejos en los que se gestionan grandes
volúmenes de información originada por múltiples dispositivos distribuidos
● Interpretación de datos: La información suministrada por sensores es interpretada para
poder ser analizada y en caso de ser necesario disparar acciones en el ambiente.
● Seguridad personal y privacidad: Además de la seguridad tradicional de internet, se puede
limitar acceso a servicios o visibilidad de comunicación en ciertos momentos.
● Tolerancia a fallos: El dinamismo de los dispositivos conectados a Internet implican que la
estructura de IoT sea pensada de una forma robusta y tolerante a fallos.
● Fuentes de energía: Contar con hardware y software de bajo consumo.
 ● Comunicaciones a corta distancia: La comunicación inalámbrica entre dos dispositivos que
se encuentran en contacto o a pocos centímetros consume poca energía, simplifica el
direccionamiento y disminuye el riesgo de interferencia con otros dispositivos lejanos.
● Comunicación inalámbrica: Actualmente existen estándares de comunicación inalámbrica
como ZigBee, con un uso de energía más eficiente que los tradicionales como GSM, UMTS,
Wi-Fi y Bluetooth pero cuentan con ancho de banda limitado.

Arquitectura de una solución IoT

● Conectividad y Comunicación: HTTP tiene 2 cuestiones, el overhead de datos en los
mensajes, y también el consumo de energía. Por eso, se muta a un protocolo más simple,
pequeño y binario, MQTT, desarrollados especialmente para IoT, con un modelo de
mensajes Publish-Subscriber basado en un modelo de broker, implementado sobre el
protocolo TCP.
● Gestión de dispositivos: estamos incluyendo las siguientes acciones como posibles:
○ Habilidad de desconectar dispositivos no autorizados o robados
○ Actualizar el software de un dispositivo
○ Actualizar credenciales de seguridad
○ Activar o desactivar capacidades de hardware de forma remota
○ Ubicar un dispositivo perdido
○ Eliminar información de un dispositivo robado
○ Configuración remota de conectividad (Wi-Fi, GPRS, etc)
● Recolección de datos, análisis y actuación: Capaz de recolectar información de una gran
variedad de dispositivos, almacenarla, analizarla y luego actuar. La arquitectura de referencia
está diseñada para gestionar un gran número de dispositivos. Si estos dispositivos se
encuentran constantemente generando flujos de información, se requiere un sistema de
almacenamiento que escale fácilmente y pueda manejar diversidad de datos y volúmenes.
● Escalabilidad
○ Soportar miles de dispositivos conectados
○ Constante envío, recepción y acción sobre datos
○ Infraestructura en el Cloud
● Seguridad:
○ Riesgo inherentes a cualquier sistema de Internet
○ Riesgos específicos de dispositivos IoT
○ Asegurar que no se realizará daño mediante el uso incorrecto de actuadores
La seguridad debe garantizarse en todas las etapas del ciclo de vida del dispositivo:
1) Inicialización segura: Asegurar la integridad del software instalado en el mismo.
2) Acceso de control: Controlar el acceso a recursos con distintos niveles de permisos
3) Autenticación: Mecanismos de autenticación al conectar el dispositivo a una red
4) Firewalls e IPS (Intrusion Prevention Systems): Existe una gran diversidad de
protocolos entre dispositivos, los cuales pueden no ser los estándares de Internet
para los que la mayoría de Firewalls y sistemas de protección están preparados. Por
lo tanto, se hace necesaria la incorporación de mecanismos de filtrado e inspección
de paquetes específicos para protocolos particulares.
5) Actualización y parches: Una vez que el dispositivo está en uso, deberá poseer la
capacidad de recibir actualizaciones periódicas de software y parches puntuales para
resolver problemas de seguridad e integridad. Estas actualizaciones deben realizarse
sin comprometer el consumo de ancho de banda y por consiguiente la funcionalidad
del dispositivo.
Algunas amenazas a la seguridad:
● Acceso no autorizado a sistemas de control, vehículos e incluso el cuerpo humano
● Tratamiento incorrecto de pacientes por sensores manipulados o historia clínica
modificada
● Acceso físico a hogares y empresas
● Pérdida del control de un vehículo
 ● Pérdida de notificación de alarmas críticas por DDoS (Distributed Denial of Service)
● Daño crítico de infraestructura por cambios en configuración de seguridad o
regulación de temperatura y voltajes
● Localización no autorizada de personas o vehículos
● Vigilancia no autorizada
● Alta Disponibilidad
● Análisis predictivo
● Integración

Arquitectura
● Cliente / comunicaciones externas: web / portal, tablero de instrumentos, API
● Procesamiento de eventos y análisis (incluido el
almacenamiento de datos)
● Capa de agregación / bus: ESB y agente de mensajes
● Transportes relevantes: MQTT / HTTP / XMPP / CoAP /
AMQP, etc.
● Dispositivos

Gateways
El ecosistema de IoT está compuesto por varios componentes o capas La capa más baja contiene
sensores y dispositivos que realizan mediciones y
acciones sobre el mundo que los rodea. Un Gateway
actúa como un intermediario seguro entre “la nube” y
estos sensores y dispositivos. La capa más alta se
encarga de la gestión y monitoreo del ecosistema IoT,
permitiendo análisis de los datos recolectados y
persistidos.
La capa de Gateway puede ser un conjunto de Gateways
interconectados en red que realizan la intercomunicación
entre todos los sensores y dispositivos del entorno.
Un Gateway de IoT es un dispositivo que permite comunicación máquina-a-máquina al conectar
dispositivos

Datos en IoT
Tipos de datos:
● No estructurados (Diversas fuentes, raw/no tipados)
● Series de tiempo y geoespaciales
● Grandes volúmenes
● Crecimiento acelerado, Real Time, Near Real Time
Características del soporte:
● Escalable
● Tolerante a fallos
● Procesamiento de eventos
● Time Series DB (TSDB)

Topología de BD
1. Simple y centralizada: En la cual los sensores remotos transmiten datos a un servicio
central de almacenamiento, procesamiento y reporte.
2. Filtrado local y agregación: En este modelo la información obtenida en la red de
dispositivos es pre-procesada antes de ser transmitida, generalmente en operaciones de
filtrado y agregación
3. Almacenamiento y procesamiento de datos federado: En muchos casos es necesario un
enfoque de federación. La distancia entre los nodos y el servidor centralizado pueden hacer
 inviable el enfoque centralizado. Se pueden desplegar Gateways dentro de la red para
preprocesar datos provenientes de distintos dispositivos y luego retransmitirlos al centro de
procesamiento. Esto no sólo descomprime la red de comunicaciones sino que también
reduce notablemente las capacidades de almacenamiento y procesamiento requeridas para
el centro de procesamiento. En algunos casos los Gateways transmitirán pocos datos al
centro de procesamiento y le proveerán un mecanismo para realizar consultas remotas de
datos, las cuales pueden abarcar varios Gateways.

MQTT
● Protocolo para mensajería sobre TCP/IP
● Arquitectura Cliente/Servidor (Cliente/Broker)
● Publicación/subscripción de mensajes
● Liviano, abierto, simple y de fácil implementación
● Uso eficiente de ancho de banda

Broker
● Receptor de mensajes
● Filtra mensajes y determina receptores
● Envía mensajes a clientes interesados
Ej: Mosquitto, HiveMQ, CloudMQTT

Cliente
● Cualquier dispositivo conectado a un Broker
● Puede publicar y/o recibir mensajes
Ej: Paho, HiveMQ Web Client

Topic
● “Canal” para suscribirse y/o publicar mensajes (Ej: sensores/humedad/ar/buenosaires)
● Wildcards (“comodines”)
○ +: Cualquier tópico dentro de un nivel (Ej: sensores/+/ar)
○ #: Cualquier tópico sin límite de niveles (Ej: sensores/temperatura/ar/#)

Calidad del servicio (Quality of Service - QoS)

● 0: Sin reintentos ni notificación (fire and forget)
● 1: Asegura que al menos se entrega una vez
○ Cliente debe enviar ACK
○ Pueden recibirse paquetes duplicados
● 2: Asegura que se entregue exactamente una vez
○ Complejo y costoso: se intercambian 4 paquetes

Last Will and Testament: Mensaje especificado por un cliente. Ejecutado cuando el broker MQTT
detecta que el dispositivo está caído

Seguridad: Usuario y contraseña. Lista de Control de acceso (ACL). MQTT no provee encriptación.
Puede usarse con TLS (Transport Layer Security)