Los equipos de TI que buscan construir arquitecturas de big data tienen una gran cantidad de opciones de tecnología que pueden mezclar y combinar para satisfacer sus necesidades de análisis y procesamiento de datos. Pero hay una desventaja en eso: juntar todas las piezas necesarias es una tarea abrumadora.
Encontrar e implementar las tecnologías de big data adecuadas dentro del ecosistema en expansión de Hadoop es un proceso largo que se mide con frecuencia en años, a menos que los ejecutivos corporativos inviertan grandes cantidades de dinero y recursos en los proyectos para acelerarlos. Los pasos en falso son comunes y el plano arquitectónico de una empresa no se traducirá necesariamente en otras organizaciones, incluso en la misma industria.
«Le digo a la gente que no es algo que se pueda pedir en Amazon u obtener en la Apple Store», dijo Bryan Lari, director de análisis institucional del MD Anderson Cancer Center de la Universidad de Texas en Houston. La construcción completa de una arquitectura de big data, agregó, «es compleja y es un viaje. No es algo que vayamos a implementar en seis meses o un año». Tampoco hay una fórmula tecnológica de fácil aplicación a seguir. «Dependiendo del caso de uso o del usuario, hay diferentes herramientas que hacen lo que tenemos que hacer», dijo Lari.
El entorno de big data de MD Anderson se centra en un clúster de Hadoop que entró en producción en marzo, inicialmente para procesar datos de signos vitales recopilados de dispositivos de monitoreo en las habitaciones de los pacientes. Pero la plataforma de lago de datos también incluye HBase; La base de datos NoSQL complementaria de Hadoop; el software Hive SQL-on-Hadoop; y varias otras tecnologías de código abierto de Apache como Pig, Sqoop, Oozie y Zookeeper. Además, la organización de investigación y tratamiento del cáncer ha implementado un almacén de datos de Oracle como un repositorio posterior para respaldar las aplicaciones de análisis y generación de informes, además del sistema de computación cognitiva Watson de IBM para proporcionar procesamiento de lenguaje natural y capacidades de aprendizaje automático. En el futuro, también se agregarán nuevas herramientas de visualización de datos, gobernanza y seguridad.
Bryan Laridirector de análisis institucional del MD Anderson Cancer Center de la Universidad de Texas
El equipo de TI de MD Anderson comenzó a trabajar con Hadoop a principios de 2015. Para hacer una demostración de algunas aplicaciones potenciales y aprender sobre la tecnología, el centro primero construyó un clúster piloto utilizando el software Apache Hadoop básico; más tarde, incorporó la distribución de Hortonworks de Hadoop para la implementación de producción.
Vamshi Punugoti, director asociado de sistemas de información de investigación en MD Anderson, dijo que la experiencia obtenida en el proyecto piloto también debería ayudar a hacer más fácil hacer frente a las modificaciones en la arquitectura que probablemente serán necesarias a medida que surjan nuevas herramientas de big data para aumentar o reemplazar las existentes. unos. «Es un campo en constante evolución, e incluso los datos que recopilamos cambian constantemente», dijo Punugoti. «Sería ingenuo asumir que lo tenemos todo cubierto».
Dirigiéndonos hacia una mejor arquitectura
De manera similar, un equipo de ingeniería de plataforma de la compañía de viajes compartidos Uber pasó aproximadamente 12 meses construyendo una arquitectura de big data multifacética, pero con aún más componentes tecnológicos y en un modo más apresurado. Vinoth Chandar, ingeniero de software senior del equipo Hadoop de Uber, dijo que los sistemas existentes de la compañía con sede en San Francisco no podían mantenerse al día con los volúmenes de datos que generaban sus operaciones comerciales de rápido crecimiento. Como resultado, muchos de los datos no se pudieron analizar de manera oportuna, un gran problema porque el negocio de Uber «es inherentemente en tiempo real» por naturaleza, dijo Chandar.
Para permitir que los gerentes de operaciones se vuelvan más impulsados por los datos, Chandar y sus colegas configuraron un entorno de lago de datos Hadoop que también incluye HBase, Hive, el motor de procesamiento Spark, el sistema de cola de mensajes de Kafka y una combinación de otras tecnologías. Algunas de las tecnologías son de cosecha propia, por ejemplo, una herramienta de ingestión de datos llamada Streamific. Con la arquitectura en su lugar, Uber se está «poniendo al día con el estado del arte en big data y análisis», dijo Chandar. Pero no fue fácil llegar allí. «Para ponerlo todo junto, puedo decir que 10 personas no durmieron durante un año», agregó medio en broma.
Sin embargo, los desafíos arquitectónicos no son motivo de risa para las organizaciones. La consultora Gartner predice que hasta 2018, el 70% de las instalaciones de Hadoop no alcanzarán sus objetivos de ahorro de costos y generación de ingresos debido a una combinación de habilidades inadecuadas y dificultades de integración de tecnología. Los obstáculos de integración se están exacerbando, dijo el analista de Gartner Merv Adrian, por un aumento constante en el número de tecnologías de big data relacionadas que los proveedores de distribución de Hadoop apoyan como parte de sus ofertas comerciales (consulte «Proporciones de Elefantina»).
En una presentación en la Cumbre de BI del Pacífico Noroeste de 2016 en Grants Pass, Oregón, Adrian enumeró un total de 46 tecnologías de código abierto que giran en torno a Hadoop y que cuentan con el respaldo de uno o más de los proveedores de distribución. Pero conectar conjuntos específicos de esos componentes en arquitecturas de big data en funcionamiento es un trabajo que se deja a las organizaciones de usuarios, según Adrian. «La mayoría de los proyectos de Hadoop de cualquier importancia son artesanales: estás juntando las piezas», dijo.
Cambios de planes a lo largo del camino
Este tipo de trabajo a destajo puede ser una tarea difícil incluso cuando Hadoop no forma parte de la imagen. Celtra Inc., que ofrece una plataforma para diseñar anuncios de video y visualización en línea, tuvo varios arranques en la implementación de una arquitectura de procesamiento basada en la nube que ahora combina Spark y su módulo Spark SQL con un repositorio de Amazon Simple Storage Service (S3), MySQL bases de datos relacionales y un sistema de almacenamiento de datos de Snowflake Computing.
«Hubo mucho ensayo y error», dijo Grega Kespret, directora de ingeniería de análisis de la empresa con sede en Boston. «Lo que es un desafío es crear una arquitectura que satisfaga las necesidades de su negocio, pero que no se exceda». Si lo hace, advirtió, podría «terminar con un desastre».
Inicialmente, Celtra recopiló datos sobre las interacciones publicitarias de los visitantes del sitio web y otros eventos rastreables en S3 y usó Spark como un motor de extracción, transformación y carga (ETL) para agregar la información con datos operativos en MySQL para usos de informes. Pero fue difícil analizar los datos de eventos sin procesar con esa configuración, dijo Kespret. Luego, la compañía agregó un sistema de análisis separado basado en Spark, que ayudó, pero aún requería que los analistas de datos de Celtra unieran, limpiaran y validaran los datos del evento ellos mismos, una empresa que, según él, era «algo propensa a errores».
A finales de 2015, después de intentar pero rechazar otras tecnologías, Kespret y su equipo recurrieron a Snowflake como un tanque de almacenamiento para los datos del evento después de que pasan por MySQL y se organizan por sesiones de usuario para facilitar el trabajo de los analistas. El sistema Snowflake entró en producción en abril pasado después de un período de lanzamiento suave anterior. Kespret dijo que el siguiente paso es almacenar los agregados de datos en Snowflake y eliminar un segundo proceso ETL que los canaliza a otro almacén de datos MySQL.
‘Días del Salvaje Oeste’ sobre el desarrollo de big data
El co-creador de Hadoop, Doug Cutting, reconoció que la gran cantidad de opciones tecnológicas puede complicar el proceso de construcción de arquitecturas de big data. Para muchas organizaciones de usuarios que buscan aprovechar Hadoop y sus tecnologías de cohorte, «hay una especie de espuma en estos días del Salvaje Oeste», dijo Cutting, quien ahora es el arquitecto jefe del proveedor de Hadoop Cloudera Inc.
Pero Cutting piensa que los beneficios de los sistemas de big data, incluida una mayor flexibilidad arquitectónica, soporte para nuevos tipos de aplicaciones de análisis y menores costos de TI, bien valen la pena por los problemas de integración. Y atribuyó gran parte del problema a la falta de familiaridad con el proceso de desarrollo e implementación de código abierto. «Muy pronto no será tan abrumador», dijo. «La gente se acostumbrará».
Tal vez sea así, pero incluso los gerentes de TI de Yahoo Inc., que afirma ser el mayor usuario de Hadoop, no son del todo inmunes a sentir la presión. Cutting trabajó en Yahoo, con sede en Sunnyvale, California, cuando se originó Hadoop en 2006, y la empresa de servicios de Internet y búsqueda web fue el primer usuario de producción de la tecnología. Actualmente, el entorno de big data de la empresa incluye alrededor de 40 clústeres que combinan Hadoop con HBase, Spark, el motor de procesamiento en tiempo real Storm y otras tecnologías.
En general, el vasto ecosistema de tecnología que se ha construido alrededor de Hadoop es una bendición para los usuarios, dijo Sumeet Singh, director senior de desarrollo de productos para plataformas de nube y big data en Yahoo. Singh señaló que el enfoque de código abierto acelera el ritmo del desarrollo tecnológico y permite que los equipos de TI participen en la planificación y creación de herramientas que sean útiles para sus empresas sin tener que hacer todo el trabajo ellos mismos. «Sé que hay una gran cantidad de proyectos de código abierto, pero no todos serán adoptados ampliamente», dijo. «Habrá convergencia y verdaderos ganadores claros».
Sin embargo, el universo de los macrodatos no es todo sol y cielos azules. «Viene con su conjunto de problemas», dijo Singh, y agregó que a veces su mente «se dispara simplemente al lidiar con» los esfuerzos de código abierto en curso y la miríada de permutaciones tecnológicas que son posibles en las arquitecturas de big data.