Los 7 proyectos de Hadoop y Spark más comunes

Hay un viejo axioma que dice algo como esto: si le ofreces a alguien todo tu apoyo y respaldo financiero para hacer algo diferente e innovador, terminará haciendo lo que todos los demás están haciendo.

Lo mismo ocurre con Hadoop, Spark y Storm. Todos piensan que están haciendo algo especial con estas nuevas tecnologías de big data, pero no lleva mucho tiempo encontrar los mismos patrones una y otra vez. Las implementaciones específicas pueden diferir un poco, pero según mi experiencia, aquí están los siete proyectos más comunes.

Proyecto No. 1: consolidación de datos

Llámelo un "centro de datos empresarial" o "lago de datos". La idea es que tiene fuentes de datos dispares y desea realizar análisis en todas ellas. Este tipo de proyecto consiste en obtener feeds de todas las fuentes (ya sea en tiempo real o por lotes) y enviarlos a Hadoop. A veces, este es el primer paso para convertirse en una "empresa basada en datos"; a veces simplemente desea informes bonitos. Los lagos de datos generalmente se materializan como archivos en HDFS y tablas en Hive o Impala. Hay un mundo nuevo y audaz donde gran parte de esto aparece en HBase, y en Phoenix, en el futuro, porque Hive es lento.

A los vendedores les gusta decir cosas como "esquema al leer", pero en realidad, para tener éxito, debe tener una buena idea de cuáles serán sus casos de uso (ese esquema de Hive no se verá muy diferente de lo que haría en un almacén de datos empresarial). La verdadera razón de un lago de datos es la escalabilidad horizontal y un costo mucho menor que Teradata o Netezza. Para el "análisis", muchas personas configuran Tableau y Excel en la interfaz. Las empresas más sofisticadas con "científicos de datos reales" (fanáticos de las matemáticas que escriben Python incorrecto) utilizan Zeppelin o iPython notebook como interfaz.

Proyecto No. 2: Análisis especializado

Muchos proyectos de consolidación de datos comienzan aquí, donde tiene una necesidad especial y obtiene un conjunto de datos para un sistema que realiza un tipo de análisis. Estos tienden a ser increíblemente específicos de un dominio, como el riesgo de liquidez / simulaciones de Monte Carlo en un banco. En el pasado, tales análisis especializados dependían de paquetes patentados anticuados que no podían escalar como lo hicieron los datos y con frecuencia sufrían de un conjunto de características limitado (en parte porque el proveedor de software no podía saber tanto sobre el dominio como la institución sumergido en él).

En los mundos Hadoop y Spark, estos sistemas tienen aproximadamente el mismo aspecto que los sistemas de consolidación de datos, pero a menudo tienen más HBase, código no SQL personalizado y menos fuentes de datos (si no solo una). Cada vez más, se basan en Spark.

Proyecto No. 3: Hadoop como servicio

En cualquier organización grande con proyectos de "análisis especializado" (e irónicamente uno o dos proyectos de "consolidación de datos"), inevitablemente comenzarán a sentir la "alegría" (es decir, el dolor) de administrar algunos clústeres de Hadoop configurados de manera diferente, a veces de diferentes vendedores. A continuación, dirán, "Quizás deberíamos consolidar esto y agrupar recursos", en lugar de tener la mitad de sus nodos inactivos la mitad del tiempo. Podrían ir a la nube, pero muchas empresas no pueden o no quieren, a menudo por motivos de seguridad (léase: política interna y protección laboral). Por lo general, esto significa muchas recetas de Chef y ahora paquetes de contenedores de Docker.

No lo he usado todavía, pero Blue Data parece tener lo más parecido a una solución lista para usar aquí, que también atraerá a organizaciones más pequeñas que carecen de los medios para implementar Hadoop como servicio.

Proyecto n. ° 4: análisis de transmisión

Mucha gente lo llamaría "transmisión", pero el análisis de transmisión es bastante diferente de la transmisión desde dispositivos. A menudo, la analítica de transmisión es una versión más en tiempo real de lo que hizo una organización por lotes. Tomemos como ejemplo la detección del fraude o el lavado de dinero: ¿por qué no hacerlo sobre la base de la transacción y detectarlo como sucede en lugar de al final de un ciclo? Lo mismo ocurre con la gestión de inventario o cualquier otra cosa.

En algunos casos, se trata de un nuevo tipo de sistema transaccional que analiza los datos bit a bit a medida que los transfiere a un sistema analítico en paralelo. Estos sistemas se manifiestan como Spark o Storm con HBase como almacén de datos habitual. Tenga en cuenta que la analítica de transmisión no reemplaza todas las formas de analítica; aún querrá sacar a la luz tendencias históricas o buscar datos pasados ​​en busca de algo que nunca consideró.

Proyecto No. 5: Procesamiento de eventos complejos

Aquí estamos hablando de procesamiento de eventos en tiempo real, donde los segundos son importantes. Si bien aún no es lo suficientemente rápido para aplicaciones de latencia ultrabaja (picosegundos o nanosegundos), como los sistemas comerciales de alta gama, puede esperar tiempos de respuesta de milisegundos. Los ejemplos incluyen la clasificación en tiempo real de registros de datos de llamadas para empresas de telecomunicaciones o el procesamiento de eventos de Internet de las cosas. A veces, verá que estos sistemas usan Spark y HBase, pero generalmente se caen de bruces y deben convertirse a Storm, que se basa en el patrón Disruptor desarrollado por el intercambio LMAX.

En el pasado, estos sistemas se basaban en software de mensajería personalizado, o productos de mensajería cliente-servidor de alto rendimiento y listos para usar, pero los volúmenes de datos actuales son demasiado para ambos. Los volúmenes de comercio y la cantidad de personas con teléfonos celulares se han disparado desde que se crearon esos sistemas heredados, y los sensores médicos e industriales bombean demasiados bits. Todavía no lo he usado, pero el proyecto Apex parece prometedor y dice ser más rápido que Storm.

Proyecto n. ° 6: Streaming como ETL

A veces, desea capturar datos de transmisión y almacenarlos en algún lugar. Estos proyectos suelen coincidir con el nº 1 o el nº 2, pero añaden su propio alcance y características. (Algunas personas piensan que están haciendo el n. ° 4 o el n. ° 5, pero en realidad están volcando al disco y analizando los datos más tarde). Estos casi siempre son proyectos de Kafka y Storm. Spark también se usa, pero sin justificación, ya que realmente no necesita análisis en memoria.

Proyecto No. 7: Reemplazo o aumento de SAS

SAS está bien; SAS es agradable. SAS también es caro y no estamos comprando cajas para todos ustedes, científicos y analistas de datos, para que puedan "jugar" con los datos. Además, quería hacer algo diferente de lo que SAS podría hacer o generar un gráfico más bonito. Aquí está su bonito lago de datos. Aquí está iPython Notebook (ahora) o Zeppelin (más tarde). Introduciremos los resultados en SAS y almacenaremos los resultados de SAS aquí.

Si bien he visto otros proyectos de Hadoop, Spark o Storm, estos son los tipos "normales" de todos los días. Si está utilizando Hadoop, probablemente los reconozca. Algunos de los casos de uso de estos sistemas los he implementado años antes, trabajando con otras tecnologías.

Si eres un veterano demasiado asustado de lo "grande" en big data o el "hacer" en Hadoop, no lo tengas. Cuanto más cambian las cosas, más permanecen igual. Encontrarás muchos paralelismos entre las cosas que solías implementar y las tecnologías hipster que giran alrededor de la Hadooposfera.