Arquitectura Big Data: ¿Qué es?; Una arquitectura de big data está diseñada para manejar la ingestión, el procesamiento y el análisis de datos que son demasiado grandes o complejos para los sistemas de bases de datos tradicionales. El umbral en el que las organizaciones entran en el ámbito del big data difiere, dependiendo de las capacidades de los usuarios y sus herramientas. Para algunos, puede significar cientos de gigabytes de datos, mientras que para otros significa cientos de terabytes. A medida que avanzan las herramientas para trabajar con grandes conjuntos de datos, también lo hace el significado de big data. Cada vez más, este término se relaciona con el valor que puede extraer de sus conjuntos de datos a través de análisis avanzados, en lugar de estrictamente el tamaño de los datos, aunque en estos casos tienden a ser bastante grandes.

A lo largo de los años, el panorama de los datos ha cambiado. Lo que puede hacer, o se espera que haga, con los datos ha cambiado. El costo del almacenamiento ha disminuido drásticamente, mientras que los medios por los cuales se recopilan los datos siguen creciendo. Algunos datos llegan a un ritmo rápido, exigiendo constantemente ser recopilados y observados. Otros datos llegan más lentamente, pero en trozos muy grandes, a menudo en forma de décadas de datos históricos. Es posible que se enfrente a un problema de análisis avanzado o uno que requiera aprendizaje automático. Estos son desafíos que las arquitecturas de big data buscan resolver.

Las soluciones de Big Data suelen implicar uno o más de los siguientes tipos de carga de trabajo:

• Procesamiento por lotes de fuentes de big data en reposo.
• Procesamiento en tiempo real de big data en movimiento.
• Exploración interactiva de big data.
• Analítica predictiva y aprendizaje automático.

Considere las arquitecturas de big data cuando necesite:

• Almacenar y procesar datos en volúmenes demasiado grandes para una base de datos tradicional.
• Transformar datos no estructurados para análisis e informes.
• Capturar, procesar y analizar flujos de datos ilimitados en tiempo real o con baja latencia.

La mayoría de las arquitecturas de big data incluyen algunos o todos los siguientes componentes:

• Fuentes de datos. Todas las soluciones de big data comienzan con una o más fuentes de datos. Algunos ejemplos son:
  • Almacenes de datos de aplicaciones, como bases de datos relacionales.
  • Archivos estáticos producidos por aplicaciones, como los archivos de registro del servidor web.
  • Fuentes de datos en tiempo real, como dispositivos IoT.
• Almacenamiento de datos. Los datos para las operaciones de procesamiento por lotes generalmente se almacenan en un almacén de archivos distribuido que puede contener grandes volúmenes de archivos grandes en varios formatos. Este tipo de tienda a menudo se llama lago de datos. Las opciones para implementar este almacenamiento incluyen el Almacén de Azure Data Lake o los contenedores de blobs en Almacenamiento de Azure.
• Procesamiento por lotes. Debido a que los conjuntos de datos son tan grandes, a menudo una solución de big data debe procesar archivos de datos utilizando trabajos por lotes de larga duración para filtrar, agregar y preparar los datos para el análisis. Por lo general, estos trabajos implican leer archivos de origen, procesarlos y escribir la salida en nuevos archivos. Las opciones incluyen la ejecución de trabajos de U-SQL en Azure Data Lake Analytics, el uso de trabajos de Hive, Pig o Map/Reduce personalizados en un clúster de Hadoop de HDInsight o el uso de programas Java, Scala o Python en un clúster de HDInsight Spark.
• Ingestión de mensajes en tiempo real. Si la solución incluye fuentes en tiempo real, la arquitectura debe incluir una forma de capturar y almacenar mensajes en tiempo real para el procesamiento de secuencias. Este podría ser un almacén de datos simple, donde los mensajes entrantes se colocan en una carpeta para su procesamiento. Sin embargo, muchas soluciones necesitan un almacén de ingesta de mensajes para actuar como un búfer para los mensajes y para admitir el procesamiento de escalabilidad horizontal, la entrega confiable y otra semántica de cola de mensajes. Esta parte de una arquitectura de transmisión a menudo se conoce como almacenamiento en búfer de transmisión. Las opciones incluyen Azure Event Hubs, Azure IoT Hub y Kafka.
• Procesamiento de flujos. Otro componente de la arquitectura de big data. Después de capturar mensajes en tiempo real, la solución debe procesarlos filtrando, agregando y preparando los datos para su análisis. Los datos de flujo procesados se escriben en un receptor de salida. Azure Stream Analytics proporciona un servicio de procesamiento de secuencias administrado basado en consultas SQL que se ejecutan perpetuamente y que funcionan en secuencias no limitadas. También puede utilizar tecnologías de streaming Apache de código abierto como Storm y Spark Streaming en un clúster de HDInsight.
• Almacén de datos analíticos. Muchas soluciones de big data preparan los datos para el análisis y luego sirven los datos procesados en un formato estructurado que se puede consultar utilizando herramientas analíticas. El almacén de datos analíticos utilizado para atender estas consultas puede ser un almacén de datos relacional al estilo Kimball, como se ve en la mayoría de las soluciones tradicionales de inteligencia empresarial (BI). Alternativamente, los datos podrían presentarse a través de una tecnología NoSQL de baja latencia como HBase, o una base de datos interactiva de Hive que proporcione una abstracción de metadatos sobre los archivos de datos en el almacén de datos distribuido. Azure Synapse Analytics proporciona un servicio administrado para el almacenamiento de datos a gran escala basado en la nube. HDInsight admite Interactive Hive, HBase y Spark SQL, que también se pueden usar para servir datos para el análisis.
• Análisis y reporting. El objetivo de la mayoría de las soluciones de big data es proporcionar información sobre los datos a través del análisis y la generación de informes. Para permitir a los usuarios analizar los datos, la arquitectura puede incluir una capa de modelado de datos, como un cubo OLAP multidimensional o un modelo de datos tabular en Azure Analysis Services. También puede admitir BI de autoservicio, utilizando las tecnologías de modelado y visualización en Microsoft Power BI o Microsoft Excel. El análisis y los informes también pueden tomar la forma de exploración interactiva de datos por parte de científicos de datos o analistas de datos. Para estos escenarios, muchos servicios de Azure admiten blocs de notas analíticos, como Jupyter, lo que permite a estos usuarios aprovechar sus habilidades existentes con Python o R. Para la exploración de datos a gran escala, puede usar Microsoft R Server, ya sea independiente o con Spark.
• Orquestación. Dentro de la arquitectura, la mayoría de las soluciones de big data consisten en operaciones de procesamiento de datos repetidas, encapsuladas en flujos de trabajo, que transforman los datos de origen, mueven los datos entre múltiples fuentes y sumideros, cargan los datos procesados en un almacén de datos analíticos o envían los resultados directamente a un informe o panel. Para automatizar estos flujos de trabajo, puede usar una tecnología de orquestación como Azure Data Factory o Apache Oozie y Sqoop.

Cuando se trabaja con conjuntos de datos muy grandes, puede llevar mucho tiempo ejecutar el tipo de consultas que los clientes necesitan. Estas consultas no se pueden realizar en tiempo real y, a menudo, requieren algoritmos como MapReduce que operan en paralelo en todo el conjunto de datos. Los resultados se almacenan por separado de los datos sin procesar y se utilizan para la consulta.

Un inconveniente de este enfoque es que introduce latencia: si el procesamiento tarda unas horas, una consulta puede devolver resultados que tienen varias horas de antigüedad. Idealmente, le gustaría obtener algunos resultados en tiempo real (tal vez con cierta pérdida de precisión) y combinar estos resultados con los resultados del análisis por lotes.

La arquitectura lambda, propuesta por primera vez por Nathan Marz, aborda este problema creando dos rutas para el flujo de datos. Todos los datos que entran en el sistema pasan por estas dos vías:

• Una capa por lotes (ruta en frío) almacena todos los datos entrantes en su forma sin procesar y realiza el procesamiento por lotes en los datos. El resultado de este procesamiento se almacena como una vista por lotes.
• Una capa de velocidad (ruta caliente) analiza los datos en tiempo real. Esta capa está diseñada para una baja latencia, a expensas de la precisión.

La capa por lotes se alimenta a una capa de servicio que indexa la vista por lotes para realizar consultas eficientes. La capa de velocidad actualiza la capa de servicio con actualizaciones incrementales basadas en los datos más recientes.

Un inconveniente de la arquitectura big data lambda es su complejidad. La lógica de procesamiento aparece en dos lugares diferentes, las rutas fría y caliente, utilizando diferentes marcos. Esto conduce a una lógica de cálculo duplicada y a la complejidad de administrar la arquitectura para ambas rutas.

La arquitectura big data kappa fue propuesta por Jay Kreps como una alternativa a la arquitectura lambda. Tiene los mismos objetivos básicos que la arquitectura lambda, pero con una distinción importante: todos los datos fluyen a través de una sola ruta, utilizando un sistema de procesamiento de flujo.

Hay algunas similitudes con la capa por lotes de la arquitectura lambda, ya que los datos de eventos son inmutables y todos se recopilan, en lugar de un subconjunto. Los datos se ingieren como un flujo de eventos en un registro unificado distribuido y tolerante a errores. Estos eventos se ordenan y el estado actual de un evento solo cambia si se anexa un nuevo evento. Al igual que la capa de velocidad de una arquitectura lambda, todo el procesamiento de eventos se realiza en el flujo de entrada y se conserva como una vista en tiempo real.

Desde un punto de vista práctico, Internet de las Cosas (IoT) representa cualquier dispositivo que esté conectado a Internet. Esto incluye su PC, teléfono móvil, reloj inteligente, termostato inteligente, refrigerador inteligente, automóvil conectado, implantes de monitoreo cardíaco y cualquier otra cosa que se conecte a Internet y envíe o reciba datos. El número de dispositivos conectados crece cada día, al igual que la cantidad de datos recopilados de ellos. A menudo, estos datos se recopilan en entornos altamente restringidos, a veces de alta latencia. En otros casos, los datos se envían desde entornos de baja latencia por miles o millones de dispositivos, lo que requiere la capacidad de ingerir rápidamente los datos y procesarlos en consecuencia. Por lo tanto, se requiere una planificación adecuada para manejar estas restricciones y requisitos únicos.

Las arquitecturas big data basadas en eventos son fundamentales para las soluciones de IoT.

La puerta de enlace en la nube ingiere eventos del dispositivo en el límite de la nube, utilizando un sistema de mensajería confiable y de baja latencia.

Los dispositivos pueden enviar eventos directamente a la puerta de enlace en la nube o a través de una puerta de enlace de campo. Una puerta de enlace de campo es un dispositivo o software especializado, generalmente ubicado con los dispositivos, que recibe eventos y los reenvía a la puerta de enlace en la nube. La puerta de enlace de campo también puede preprocesar los eventos del dispositivo sin procesar, realizando funciones como el filtrado, la agregación o la transformación de protocolos.

Después de la ingestión, los eventos pasan por uno o más procesadores de flujo que pueden enrutar los datos (por ejemplo, al almacenamiento) o realizar análisis y otro procesamiento.

Los siguientes son algunos tipos comunes de procesamiento. (Esta lista no es exhaustiva).

• Escritura de datos de eventos en almacenamiento en frío, para archivado o análisis por lotes.
• Análisis de rutas activas, analizando el flujo de eventos en tiempo (casi) real, para detectar anomalías, reconocer patrones en ventanas de tiempo de rodadura o activar alertas cuando se produce una condición específica en la transmisión.
• Manejo de tipos especiales de mensajes de no telemetría de dispositivos, como notificaciones y alarmas.
• Aprendizaje automático.