La gente trata de enseñarte Big Data centrándose en enseñar la tecnología como Hadoop, Spark y otras cosas. La verdad es que esta estrategia es incorrecta, una pérdida de tiempo.
Esto tiene que parar, ¡y se detiene hoy!
En este primer post voy a comenzar con el opuesto exacto de entrar en Big Data. Al no enfocarse en la tecnología. Porque lo más importante que primero necesita comprender es: qué problemas ayuda a resolver Big Data.
Mi motivación para esta impresionante serie de blogs
Mi motivación para esta serie es esta. Todos los días tropiezo con publicaciones en Twitter, Reddit o LinkedIn donde la gente pregunta:
“Quiero aprender sobre Big Data como un principiante absoluto, pero ¿por dónde empiezo?”
Nadie señala que para comenzar con Big Data necesitas descubrir el por qué.
¿Por qué Big Data?
¿Qué tiene de malo la forma tradicional de almacenar y analizar datos?
Por lo tanto, estoy tomando las cosas en mis manos y lo ayudaré a impulsar su viaje de Big Data hacia el éxito.
Cuando haya terminado con este, le recomiendo que lea las siguientes cinco partes:
- Dominio de Big Data con procesamiento distribuido (MapReduce)
- Cómo todos pueden cosechar el poder de la minería de datos (Chispa)
- ¿Qué es Stream y procesamiento por lotes?
- La plataforma perfecta Big Data
- ¿Qué es Hadoop y por qué es tan extrañamente popular?
LA CURVA DEL PALO DE HOCKEY DEL ÉXITO CATASTRÓFICO
Lo primero que quiero señalar es el concepto de crecimiento exponencial.
El crecimiento exponencial se define por la función: 
Lo que eso significa es que el valor básicamente se duplica con cada paso dado. Al principio parece que nada está pasando y de repente se va por el techo. Míralo qué belleza!
Esta curva es lo que todo inversor está buscando. Es cómo las nuevas empresas exitosas prosperan. Aquí es donde está el dinero grande.
Duplicar el número de usuarios cada mes o duplicar los dispositivos de IoT conectados a su plataforma es una gran cosa. Pero este tipo de éxito catastrófico creará algunos problemas.
Permanezcamos con el ejemplo IoT. El crecimiento exponencial de los datos que se almacenan y procesan exige que también su infraestructura de TI tenga que ser capaz de manejarlo. Y aquí es donde comienzan los problemas.
EL PROCESO DE CARGA DE TRANSFORMADA DE EXTRACTO EXTREMADAMENTE PROBLEMÁTICO (ETL)
Un despliegue típico de la plataforma de la vieja escuela se parecería a la imagen siguiente. Los dispositivos usan una API de datos para cargar datos que se almacenan en una base de datos SQL. Una herramienta analítica externa está consultando datos y cargando los resultados nuevamente a SQL db. Los usuarios luego usan la interfaz de usuario para mostrar los datos almacenados en la base de datos.
Ahora, cuando el front-end consulta datos de la base de datos SQL, ocurren los siguientes tres pasos:
- La base de datos extrae todas las filas necesarias del almacenamiento
- Los datos extraídos se transforman, por ejemplo, ordenados por marca de tiempo o algo mucho más complejo
- Los datos extraídos y transformados se cargan en el destino (la interfaz de usuario) para la creación de gráficos
Con la explosión de cantidades de datos almacenados, el proceso de ETL comienza a ser un problema real.
Analytics funciona con grandes conjuntos de datos, por ejemplo, días enteros, semanas, meses o más. Los conjuntos de datos son muy grandes, como 100 GB o Terabytes. Eso significa miles de millones o billones de filas.
Esto tiene el resultado de que el proceso de ETL para grandes conjuntos de datos toma más y más tiempo. Muy rápidamente, el rendimiento de ETL es tan malo que ya no ofrecerá resultados a los análisis.
Una solución tradicional para superar estos problemas de rendimiento es tratar de aumentar el rendimiento del servidor de la base de datos. Eso es lo que se llama ampliar.
ESCALANDO EL SISTEMA: LA SALIDA FÁCIL
Para ampliar el sistema y, por lo tanto, aumentar las velocidades de ETL, los administradores recurren a hardware más potente al:
- Acelerando el rendimiento del extracto mediante la adición de discos más rápidos para leer físicamente los datos más rápidamente.
- Aumento de RAM para el almacenamiento en caché de filas. Lo que ya está en la memoria no tiene que ser leído por unidades de disco lentas.
- Usando CPUs más potentes para un mejor rendimiento de transformación (aquí también ayuda más RAM)
- Aumentar u optimizar el rendimiento de la red para una entrega de datos más rápida al front-end y análisis
Ampliar el sistema es bastante fácil.
Pero con un crecimiento exponencial es obvio que tarde o temprano (más pronto que tarde) volverás a tener los mismos problemas. En algún momento, simplemente ya no puede escalar más porque ya tiene un sistema de monstruos o no puede permitirse comprar hardware más costoso.
El siguiente paso que podrías tomar sería escalar.
ESCALANDO EL SISTEMA: LA SALIDA COMPLICADA
Escalar es lo contrario de escalar. En lugar de construir sistemas más grandes, el objetivo es distribuir la carga entre muchos sistemas más pequeños.
La forma más simple de escalar una base de datos SQL es usar una red de área de almacenamiento (SAN) para almacenar los datos. Luego puede usar hasta ocho servidores SQL, adjuntarlos a la SAN y dejarlos manejar las consultas. De esta forma, la carga se distribuye entre esos ocho servidores.
Una desventaja importante de esta configuración es que, como el almacenamiento se comparte entre los servidores sql, solo se puede usar como una base de datos de solo lectura. Las actualizaciones deben hacerse periódicamente, por ejemplo, una vez al día. Para hacer actualizaciones, todos los servidores SQL tienen que desconectarse de la base de datos. Luego, uno conecta el db en modo lectura-escritura y actualiza los datos. Este procedimiento puede llevar un tiempo si se deben cargar muchos datos.
Este enlace a una página de Microsoft MSDN tiene más opciones para escalar una base de datos SQL por usted.
Deliberadamente no quiero entrar en detalles sobre posibles soluciones de escalamiento. El punto que intento hacer es que, si bien es posible escalar las bases de datos SQL, es muy complicado.
No hay una solucion perfecta. Cada opción tiene sus altibajos. Un problema importante común es el esfuerzo administrativo que debe realizar para implementar y mantener una solución escalada.
LA TRISTE CONCLUSIÓN
Repasemos lo que hemos aprendido hoy.
Con un éxito catastrófico en forma de crecimiento exponencial surgen algunos problemas importantes de las bases de datos SQL tradicionales.
El proceso de ETL está impidiendo que el análisis haga su trabajo porque la base de datos no puede entregar datos lo suficientemente rápido para el análisis.
Los métodos de escalado tradicionales para db relacionales, como escalar o escalar, difícilmente pueden seguir el ritmo del crecimiento exponencial. Cada solución viene con ciertas concesiones que deben ser consideradas. El mantenimiento de operaciones para un sistema de este tipo puede ser muy complicado y consumir mucho tiempo.
Debe preguntarse a sí mismo: ¿realmente vale la pena gastar todo ese dinero en una solución que al final podría no funcionar tan bien? Probablemente no?
LA FORMA BIG DATA
Entonces, ¿cómo es la forma Big Data de lidiar con el problema de ETL? Bueno, puedes ir directamente a mi próxima publicación para eso:
En él, repasaremos los detalles de cómo el problema SQL ETL se resuelve con el concepto de procesamiento distribuido. Hablaré sobre qué es el procesamiento distribuido y por qué es la base de los sistemas Big Data como Hadoop