por Monte Zweben y Syed Mahmood de Splice Machine
Apache Hadoop surgió en el escenario tecnológico en el 2006 con la promesa de proporcionar a las organizaciones la capacidad de almacenar un volumen de datos sin precedentes utilizando hardware básico.
Esta promesa no sólo se refería al tamaño de los conjuntos de datos sino también al tipo de datos, como los datos generados por los dispositivos IoT, sensores, servidores y medios sociales que las empresas estaban cada vez más interesadas en analizar. La combinación de volumen, velocidad y variedad de datos se conocía popularmente como Big Data.
El schema-on-read jugó un papel vital en la popularidad de Hadoop. Las empresas pensaron que ya no tenían que preocuparse por el tedioso proceso de definir qué tablas contenían qué datos y cómo se conectaban entre sí, un proceso que llevaba meses y que no se podía ejecutar ni una sola consulta antes de que se completara.
En este valiente nuevo mundo, las empresas podían almacenar tantos datos como pudieran en repositorios basados en Hadoop conocidos como Data Lakes y preocuparse por cómo se analizarán más tarde.
Los Data Lakes comenzaron a aparecer en las empresas. Estos Data Lakes fueron habilitados por las distribuciones comerciales de Big Data - un número de motores de computación independientes de código abierto soportados en una plataforma que impulsaría el data lake para analizar los datos de diferentes maneras.
Y encima de eso, todo esto siendo Código Abierto era gratis probarlo! ¿Qué podría salir mal?
El esquema de lectura (Schema-on-Read) fue un error
Como con tantas cosas en la vida, las características de Hadoop que se pregonaban como sus ventajas también resultaron ser su talón de Aquiles.
Primero, con el schema-on-read levantado, los terabytes de datos estructurados y no estructurados comenzaron a fluir en los lagos de datos. Con el marco y la capacidad de gobierno de datos de Hadoop aún en proceso de definición, se hizo cada vez más difícil para las empresas determinar el contenido de su lago de datos y el linaje de sus datos.
Además, los datos no estaban listos para ser consumidos. Las empresas comenzaron a perder la fe en los datos que estaban en sus lagos de datos y lentamente estos lagos de datos comenzaron a convertirse en pantanos de datos (Data Swamps). La filosofía de "constrúyelo y vendrán" del scheme-on-road fracasó.
La complejidad de Hadoop y los motores de computación en forma de conducto
En segundo lugar, las distribuciones Hadoop proporcionaron varios motores de computación de código abierto como Apache Hive, Apache Spark y Apache Kafka, por nombrar sólo algunos, pero esto resultó ser un caso de "demasiado bueno para ser cierto".
Un ejemplo: una plataforma comercial de Hadoop consistía en 26 de estos motores separados. Estos motores de computación eran complejos de operar y requerían habilidades especializadas para unir los conductos que eran difíciles de encontrar en el mercado.
El enfoque equivocado: El lago de datos Vs El proyecto
En tercer lugar, y lo más importante, los proyectos data lake comenzaron a fracasar porque las empresas dieron prioridad al almacenamiento de todos los datos de la empresa en una ubicación central con el objetivo de poner estos datos a disposición de todos los desarrolladores - un almacén de datos uber si se quiere, en lugar de pensar en cómo los datos impactarían en las aplicaciones.
Como resultado, los clústeres Hadoop se convirtieron a menudo en las puertas de entrada de los conductos de datos empresariales que filtran, procesan y transforman los datos que luego se exportan a otras bases de datos y mercados de datos para la elaboración de informes en sentido descendente y casi nunca encuentran su camino hacia una aplicación empresarial real en la empresa de tejido operativo.
Como resultado, los lagos de datos terminan siendo un conjunto masivo de motores de computación dispares, que operan con cargas de trabajo dispares, todos compartiendo el mismo almacenamiento.
Esto es muy difícil de manejar. El aislamiento de los recursos y las herramientas de gestión en este ecosistema están mejorando, pero todavía tienen un camino por recorrer.
Las empresas, en su mayor parte, no fueron capaces de cambiar su enfoque de utilizar sus lagos de datos como depósitos de datos baratos y pipelines de procesamiento a plataformas que consumen datos y alimentan aplicaciones de misión crítica.
Por ejemplo, Apache Hive y Apache Spark están entre los motores de computación más utilizados para los lagos de datos de Hadoop. Ambos motores se utilizan con fines analíticos, ya sea para procesar consultas de tipo SQL (Hive) o para realizar transformaciones de datos de tipo SQL y construir modelos predictivos (Spark). Estas implementaciones de lagos de datos no se han centrado lo suficiente en cómo utilizar operativamente los datos en las aplicaciones.
Estrategia para el futuro
Por lo tanto, si su organización está preocupada por los recientes acontecimientos en el ecosistema de Hadoop y cada vez más presionada para demostrar el valor de su lago de datos, debería empezar por centrarse primero en las aplicaciones operativas y luego trabajar de nuevo en los datos.
Al centrarse en la modernización de las aplicaciones con datos e inteligencia, terminará con aplicaciones que pueden aprovechar los datos para predecir lo que podría suceder en el futuro basándose en la experiencia y ser proactivos para tomar decisiones en el momento que resulten en resultados empresariales superiores.
A continuación se presentan 5 ingredientes para una estrategia exitosa de modernización de aplicaciones:
A continuación se presentan 5 ingredientes para una estrategia exitosa de modernización de aplicaciones:
-
Elegir una aplicación para modernizar: En lugar de enfocar sus esfuerzos en centralizar los datos, primero, elija una aplicación que le gustaría modernizar.
El principal candidato para ello es una de las muchas aplicaciones internas y personalizadas que se han quedado atrás en el mercado y que necesitan ser más ágiles, inteligentes y basadas en datos.
Una vez que haya identificado la aplicación que puede ofrecer una ventaja competitiva a su organización, entonces podrá centrarse en la obtención de los datos necesarios para impulsar esa aplicación y en si esos datos pueden estar disponibles desde el lago de datos.
-
Utilice el SQL de escalado (scale-out SQL) para la modernización de su aplicación: SQL ha sido el caballo de batalla de las cargas de trabajo en la empresa durante varios años y hay cientos de desarrolladores, analistas de negocios y personal de TI en su organización que están completamente familiarizados con SQL.
No incurra en tiempo, gastos y riesgos adicionales al reescribir su aplicación SQL original en una API de NoSQL de bajo nivel.
Seleccione una plataforma que le permita mantener los patrones familiares y la potente funcionalidad de SQL para modernizar la aplicación, pero hágalo en una arquitectura que pueda escalar de forma elástica en una infraestructura económica.
El escalamiento trae el poder de un clúster entero para que se aplique a la computación, haciéndolo mucho más rápido que los viejos sistemas SQL que funcionaban en un sistema centralizado. Con el scale-out se puede añadir más capacidad y quitarla a medida que las cargas de trabajo también cambian.
-
Adopte una plataforma ACID: El cumplimiento del ACID es el mecanismo a través del cual las transacciones mantienen la integridad de la base de datos y permite a los usuarios realizar acciones como el commit y el rollback.
Se trata de una funcionalidad crítica para potenciar las aplicaciones operativas, ya que garantiza que la base de datos no haga visibles los cambios a los demás hasta que se haya emitido un commit.
Seleccione una plataforma que proporcione capacidad ACID a nivel de transacción individual en la base de datos. De lo contrario, todas estas ramificaciones de consistencia deben ser manejadas en el código de la aplicación.
Todos los sistemas SQL tradicionales cumplían con el ACID. Los lagos de datos descartaron erróneamente esto haciendo que las aplicaciones sean muy difíciles de escribir.
-
Unificar los motores analíticos: Según un reciente blog de Gartner, históricamente, había buenas razones para separar la infraestructura de TI en componentes operativos (OLTP) y analíticos (OLAP), pero ya no es así.
ETL mata nuestros SLA's con latencia. Solía ocurrir que las cargas de trabajo operacional y analítica interferían entre sí y había que separarlas. Además, las plataformas de datos heredadas funcionaban tan mal que teníamos que transformar el esquema operacional en star-schemas o snowflake-schemas que eran mejores para las cargas de trabajo analítico.
Este ETL ya no es necesario y se puede ejecutar el análisis en la plataforma operativa, a menudo utilizando el esquema operativo. Al implementar esta plataforma se asegurará de que su aplicación se ejecuta en una plataforma que minimiza el movimiento de datos y no contribuye a la latencia de la aplicación.
Esto entrega sus conocimientos, informes y cuadros de mando actuales frente a los datos de ayer o de la semana pasada.
-
Embeber el machine learning nativo: Una de las principales razones para modernizar su aplicación es inyectar Inteligencia Artificial y Machine Learning en ella para que pueda aprender de la experiencia, adaptarse dinámicamente a los cambios y tomar decisiones en el momento.
Para que su aplicación sea inteligente es fundamental que seleccione una plataforma que tenga incorporado el aprendizaje automático a nivel de base de datos, de modo que los datos actualizados estén siempre disponibles para que los modelos puedan experimentar, entrenar y ejecutar.
Este es fundamentalmente un enfoque diferente al que ha utilizado su lago de datos hasta ahora. Este enfoque ofrece un valor comercial tangible a la línea de negocio más rápido a través de la aplicación (el proyecto) que ahora puede aprovechar el lago de datos.
Este enfoque garantizará que, además de modernizar las aplicaciones que proporcionan a su negocio una ventaja competitiva, también preservará la inversión en su lago de datos.
Si desea saber más sobre las cinco señales de advertencia de que su aplicación se está quedando atrás en los esfuerzos de transformación digital, obtenga una copia del white paper hoy mismo.
