Evolución De Los Entornos Big Data Y Los Retos Para El Arquitecto De Datos
Total Page:16
File Type:pdf, Size:1020Kb
EVOLUCIÓN DE LOS ENTORNOS BIG DATA Y LOS RETOS PARA EL ARQUITECTO DE DATOS CARLOS GONZÁLEZ CANTALAPIEDRA Big Data Architect EVERLYN VERGARA SOLER Big Data Consultant Cuando se habla de entornos y aplicaciones Big Data, a menudo nos referimos a Hadoop (1). Se trata de una pieza fundamental en la evolución e implantación de este tipo de tecnologías en el entorno empresarial, pero si nos refiriésemos aBig Data como algo exclusivamente refe- rente a Hadoop, nos estaríamos equivocando. Hadoop fue creado por Doug Cutting para com- HADOOP, UNA PIEZA CLAVE EN EL ORIGEN DEL ECOSISTE- plementar la distribución Nutch, su motor de bús- MA BIG DATA queda basado en Apache Lucene en el año 2004. La primera versión de Hadoop estaba compuesta por En ese mismo año, Google publica su paper (2) dos componentes principales: sobre MapReduce. Google empezaba a tener problemas para poder indexar la web al ritmo al –– HDFS: sistema de archivos distribuidos que permite que ésta iba creciendo y necesitaba encontrar de forma transparente a los desarrolladores alma- una solución para poder acometer el problema. cenar un archivo de datos en diferentes máquinas Esta solución se basaba en un sistema de archivos de un cluster de Hadoop. Cada fichero que se distribuidos, que le proporcionaba la capacidad almacena en HDFS se divide en bloques de un de poder procesar en paralelo grandes cantida- tamaño definido y es cada uno de estos bloques des de información. La solución al problema es lo que se replica en diferentes nodos del cluster. simple, pero a la vez brillante, ya que el sistema –– MapReduce: framework de desarrollo que per- era capaz de distribuir la información a procesar mite a los desarrolladores ejecutar procesos en en diferentes ordenadores que actuaban de for- paralelo dentro de un cluster de Hadoop abstra- ma independiente cada uno de ellos, pero a la yendo la complejidad de dicho procesamiento vez formaban parte de un todo. en paralelo. En el año 2006, Google publica los detalles so- Una de las principales características de Hadoop que bre la tecnología que había desarrollado y esta es ha hecho que la tecnología se expanda es que puede acogida con gran interés por la comunidad Open ejecutarse sobre lo que se denomina «commodity hard- Source, que en septiembre del año 2007 libera la ware», es decir, máquinas baratas. Si a esto sumamos primera versión de Hadoop bajo licencia Apache. que Hadoop es Open Source, parece que es la combi- 405 >Ei 21 C. GONZÁLEZ CANTALAPIEDRA / E. VERGARA SOLER FIGURA 1 ARQUITECTURA YARN Fuente: https://www.edureka.co/blog/introduction-to-hadoop- 2-0-and-advantages-of-hadoop-2-0/ nación perfecta para procesar grandes cantidades de Todos estos nuevos productos nacen cada uno de información a un coste asumible para las empresas. ellos con un propósito muy concreto dentro del ecosis- tema. Por ejemplo, Apache Sqoop nace con el propó- Una vez que la primera versión de Hadoop fue libera- sito de poder comunicar dos mundos muy distintos: las da, numerosas empresas empezaron a vislumbrar los tradicionales bases de datos relacionales con Hadoop. beneficios del uso de esta tecnología. Facebook es Sqoop permite leer datos desde una base de datos re- una de estas primeras empresas que ven el beneficio lacional y escribir dichos datos en HDFS para que pos- en el uso de la tecnología, ya que en el año 2008 (3) teriormente sean procesados por otros productos del se generan cantidades ingentes de información debi- ecosistema. Y también permite la comunicación en el do a las decenas de millones de usuarios que tiene sentido contrario, leyendo datos de HDFS y escribiendo la plataforma y a más del billón de páginas visitadas dichos datos en bases de datos relacionales. diariamente. Facebook necesita almacenar esta in- formación para posteriormente analizarla y ver cómo Otro ejemplo es Apache Oozie, que permite la defini- mejorar la experiencia del usuario. Facebook empie- ción de flujos de trabajo, pudiendo estar escritos cada za a utilizar el paradigma de programación MapRe- uno de ellos basándose en frameworks o productos duce y desarrolla un framework para poder ejecutar diferentes. De esta manera, podemos definir en un sentencias SQL sobre datos que residen en HDFS. Este solo flujo la lectura de datos con Apache Sqoop desde framework será liberado a la comunidad Open Source una base de datos relacional, procesarlos con Apa- posteriormente con el nombre de Hive (4). che Hive, y posteriormente construir un job con Apache Spark (9) para escribir los resultados del proceso en una A partir de este momento, grandes compañías empie- base de datos NoSQL como Apache Cassandra (10). zan a hacer un uso intensivo de esta tecnología y a participar como contribuidores del core de Hadoop. La mayoría de estos productos tienen dependencias Compañías como Facebook, eBay, IBM o Linkedin se con Apache Hadoop e incluso entre ellos mismos, de convierten en contribuidores con más de 200.000 lí- manera que cuando el ecosistema comienza a cre- neas de código. cer, la configuración de estas dependencias entre los distintos componentes añade un grado más de difi- cultad en la instalación y mantenimiento de las plata- LAS DISTRIBUCIONES COMO PARTE DE LA EVOLUCIÓN formas. DEL ECOSISTEMA BIG DATA Para reducir esta complejidad surgen nuevos actores En paralelo al desarrollo y evolución de Hadoop, em- alrededor del ecosistema Hadoop. Empresas como pieza a crearse un ecosistema de productos que se Cloudera (11) o Hortonworks (12) nacen con el propósi- van desarrollando en paralelo. Apache Hive, Apache to de crear distribuciones empaquetadas que faciliten Pig (5), Apache Zookeeper (6), Apache Sqoop (7) o la instalación, configuración y monitorización declus - Apache Oozie (8) son algunos ejemplos claros de ters Hadoop y empiezan a incluir dentro de dichas dis- cómo este ecosistema va creciendo y enriqueciendo tribuciones más productos del ecosistema que facilitan el uso de la plataforma. el almacenamiento y procesamiento de datos. 22 405 >Ei EVOLUCIÓN DE LOS ENTORNOS BIG DATA Y LOS RETOS PARA EL ARQUITECTO DE DATOS y de la complejidad de los algoritmos), ven reducido FIGURA 2 drásticamente su tiempo de ejecución al utilizar este APACHE HADOOP VS APACHE SPARK nuevo framework. Por ejemplo, un algoritmo de regre- sión lógica basado en Apache Hadoop y posterior- mente basado en Apache Spark, arroja la compara- tiva en tiempos de ejecución que muestra la Figura 2. Aparte de la velocidad, Apache Spark aporta una ventaja muy importante desde el punto de vista de un desarrollador de software. Cualquier desarrollador que haya trabajado con el framework MapReduce de Hadoop sabe que es complejo, y la llegada de Apache Spark aporta mayor facilidad en el desarrollo de aplicaciones de este tipo. Esta facilidad viene dada porque Spark provee diferentes APIs para Scala, Java y Python que abstraen al desarrollador de la compleji- Fuente: http://spark.apache.org/images/logistic-regression.png dad a la que estaban acostumbrados al trabajar con el framework MapReduce. Y esto se traduce también En enero de 2012 se produce un hito importante den- en velocidad a la hora de construir aplicaciones. tro de Hadoop. Se libera YARN (Yet Another Resource Negotiator) también conocido como MapReduce v2. Uno de los puntos fuertes de Spark es su librería de strea- YARN es una evolución de MapReduce y su propósito ming o real time. Hay que puntualizar que sería más es desacoplar la gestión de los recursos de la planifi- adecuado hablar de «near real time», ya que Apache cación de las tareas. Por un lado, el ResourceManager Spark no proporciona verdadero tiempo real debido a se encarga de la gestión de los recursos a nivel global la manera que gestiona la consumición de eventos o dentro del cluster y el ApplicationMaster se encarga de información en «tiempo real», ya que realmente lo que la planificación de las tareas por cada una de las apli- hace Apache Spark es la ejecución de procesos deno- caciones que se ejecutan dentro del cluster. La Figura minados micro batch. Estos procesos micro batch es- 1 ilustra la arquitectura de YARN. tán constantemente en ejecución y leen información de la fuente cada un periodo de tiempo establecido A partir de este momento e impulsado en gran me- (en el caso de Apache Spark, un periodo mínimo de dida por las distribuciones de Cloudera y Hortonworks, 0.5 segundos). el ecosistema de productos y las integraciones con entornos Hadoop crece de forma exponencial en el Uno de los grandes aciertos de Apache Spark es su ámbito empresarial. versatilidad para poder ejecutarse sobre distintas pla- taformas, entre ellas YARN. En el momento en el que En este momento, Hadoop era un framework para aparece Apache Spark, muchas de las grandes em- realizar procesamiento de datos en batch, no forma- presas que han empezado a tener plataformas Big ba parte aún de este ecosistema una solución para el Data, basan dichas plataformas en clusters Hadoop. procesamiento de datos en real time o near real time. Al poder ejecutar Spark sobre YARN, las empresas no tienen que desprenderse de sus clusters Hadoop (y de APACHE SPARK Y PROCESAMIENTO EN NEAR REAL TIME las aplicaciones que se ejecutan sobre estos clusters), es más, lo ven como un nuevo elemento complemen- Apache Spark es un framework open source que tario y que les abre un nuevo abanico de posibilidades, permite el análisis de datos de forma distribuida y en sobre todo la posibilidad de procesar información en memoria. La llegada de Apache Spark aporta al eco- near real time, algo de lo que Hadoop carece de for- sistema Big Data capacidades de procesamiento de ma nativa. datos que hasta ese momento se podían conseguir combinando diferentes componentes, y no posible en La aparición de este tipo de frameworks -Apache todos los casos.