Mostrando entradas con la etiqueta Zylk. Mostrar todas las entradas
Mostrando entradas con la etiqueta Zylk. Mostrar todas las entradas

19 febrero 2018

No hay mejor andar que no parar, HADOOP 3.0

Aprovechando la jornada de trabajo con Felipe Haynes y Raú Marín de Hortonworks y  David Olmos y Gustavo Fernández de Zylk. Os dejamos un pequeño articulo sobre la nueva versión de Hadoop 3.0 .
Recordar que Zylk y Hortonworks realizan el próximo 15 de marzo en el Hotel NH Collection Villa de Bilbao un evento con conferencias, networking y casos de éxito de la utilización del Big Data 




Principales diferencias entre  HADOOP 2.0 y 3.0 :

CARACTERÍSTICA
HADOOP 2.x
HADOOP 3.x
Versión Java mínima soportada
java 7
java 8
Esquema de almacenamiento
Usa un esquema de replica que multiplica x3 el espacio de almacenamiento.
Soporta erasure coding(1) en HDFS reduciendo el espacio de almacenamiento.
Tolerancia a fallos
Puede manejarse mediante la replicación (que es un desperdicio de espacio).
Puede manejarse mediante erasure coding ofreciendo el mismo nivel de tolerancia a fallos pero con una considerable reducción de espacio de almacenamiento.
Storage Overhead
(Sobrecarga del espacio de almacenamiento)
HDFS tiene una sobrecarga del 200% en el espacio de almacenamiento, ya que hace copias al 100% de los datos (el factor de réplica mínimo y por defecto en Hadoop 2 es de 3) los cuáles, en la mayoría de las ocasiones, no son usados . Por ejemplo: Si hay 6 bloques, habrá 18 bloques ocupados debido al esquema de replicación.
Con el  erasure coding   en Hadoop 3, si hay 6 bloques de datos, ocupará un espacio de 9 bloques - 6 bloques de datos y 3 para la paridad - lo que conlleva una menor sobrecarga de almacenamiento. El resultado final: en lugar de necesitar multiplicar por 3 el almacenamiento, el método de almacenamiento de erasure coding tendrá una sobrecarga de 1.5x, manteniendo el mismo nivel de recuperación de datos. Reduce a la mitad el costo de almacenamiento de HDFS a la vez que conserva la durabilidad de los datos. La sobrecarga de almacenamiento se puede reducir de 200% a 50%. Además, se beneficia de un ahorro de costes en infraestructuras.
YARN Timeline Service
Utiliza un viejo timeline service que tiene problemas de escalabilidad.
Mejora el timeline service v2 y mejora la escalabilidad y la confiabilidad del mismo.
Rango de puertos por defecto
En Hadoop 2.0, algunos puertos predeterminados son del rango de puertos efímeros(2) de Linux (32768-61000). Por lo tanto, en el momento de la puesta en marcha, pueden  fallar al conectarse al entrar en conflicto con otras aplicaciones.
En Hadoop 3.0 estos puertos se han movido fuera del rango efímero.
Sistemas de ficheros compatibles
  • HDFS (Sistema de ficheros por defecto)
  • Sistema de archivos FTP: almacena todos sus datos en servidores FTP accesibles remotamente
  • Sistema de archivos Amazon S3 (Simple Storage Service)
  • Sistema de archivos Windows Azure Storage Blobs (WASB).
Es compatible con todos los anteriores, así como con el sistema de archivos Microsoft Azure Data Lake y Aliyun Object Storage System .
Escalabilidad
  • Podemos escalar hasta 10,000 nodos por clúster.
  • Hadoop 2 y Hadoop 1 solo usan un único NameNode para administrar todos los Namespaces.
  • En Hadoop 2 hay  solamente un NameNode en standby
  • Se pueden escalar más de 10.000 nodos por cluster.
  • Hadoop 3 tiene múltiples Namenodes para múltiples Namespaces debido al uso de  NameNode Federation que mejora la escalabilidad.
  • Hadoop 3 soporta múltiples NameNodes en stanby.
Nuevos casos de uso
Hadoop 2 no soporta GPUs (Graphics Processing Unit)
 Hadoop 3 permite la programación de recursos adicionales, tales como discos y tarjetas gráficas para una mejor integración. Por ejemplo, el administrador del clúster podría definir recursos como GPU, licencias de software o almacenamiento conectado localmente. Las tareas de YARN se pueden programar según la disponibilidad de estos recursos. Esta característica proporciona la base para admitir GPU en clústeres de Hadoop, lo que mejora un rendimiento de los cálculos necesarios para los casos de uso de Ciencia de datos e Inteligencia Artificial.
Nuevos componentes
El uso de Erasure Coding incluye nuevos componentes en la arquitectura:

  • Namenode Extension (ECManager): reside en el Namenode y coordina toda la tarea de codificación y decodificación.

  • Client Extension (ECClient):es la extensión del cliente HDFS que notifica al ECManager los bloques que faltan y lee los datos reconstruidos por el ECWorker.

  • Datanode Extension (ECWorker): ubicados en los Datanode. Cada vez que se decodifica o codifica un bloque, el ECWorker del Datanode lleva a cabo su cálculo siguiendo las instrucciones enviadas por el ECManager quién le suministra el esquema de codificación.

(1) La funcionalidad HDFS Erasure Coding usa RAID (Redundant Array of Inexpensive Disks). RAID implementa EC utilizando stripping, es decir, almacena los ficheros de manera lógica en forma de bloque (unidad pequeña) y almacena cada bloque en discos diferente. Para cada bloque (celda) se calculará y almacenará la paridad. Esto se llama codificación. Se almacena 1 bloque de paridad por cada 2 bloques de datos. Lo que implica tener un 50% de sobrecarga del espacio de almacenamiento frente al 200% que supone el antiguo replicado con factor 3 del 100% de los datos en Hadoop 2.

(2) Los puertos efímeros son puertos temporales asignados por la pila de IP de una máquina y se asignan dentro de un rango designado de puertos para este propósito. Cuando la conexión finaliza, el puerto efímero está disponible para su reutilización, aunque la mayoría de las pilas IP no reutilizarán ese número de puerto hasta que se haya utilizado todo el conjunto de puertos efímeros. Por lo tanto, si el programa cliente se vuelve a conectar, se le asignará un número de puerto efímero diferente para su lado de la nueva conexión.)


Para más información se puede consultar:


·        How Apache Hadoop 3 Adds Value Over Apache Hadoop 2

·        Apache Hadoop 3.0.0

·        Comparison Between Hadoop 2.x vs Hadoop 3.x 1

·        What’s New in Hadoop 3.0 – Enhancements in Apache Hadoop 3

·        What's new in hadoop 3.0

·        Getting to Know Hadoop 3.0 -Features and Enhancements. Why Hadoop 3.0? What’s New in Hadoop 3.0? Difference between Hadoop 2.x vs. Hadoop 3.x

·        Hadoop 3.0 - Revolution or evolution?



07 diciembre 2016

Big Data LibreCon 2016 - Zylk Industry 4.0 - Compartiendo la experiencia de proyectos de Big Data

Aprovechando la participación Iñigo Sánchez Méndez de Zylk Industry 4.0 en el Librecon 2016 , donde nos explica junto a Angel Barrio de Euskaltel cómo darle valor a los datos recogidos en tiempo real y apoyándose en herramientas open source. Os dejamos la ponencia "Inteligencia del dato aplicada al negocio de las telecomunicaciones" :





Hemos aprovechado para realizar una entrevista a Gustavo Fernandez  Director Técnico en zylk.net :

En los proyectos de Big Data que has participado, que aspecto reseñarías como importante en el ámbito organizativo (implicación del cliente, infraestructuras, visión tecnológica a medio plazo,...)

Es necesario disponer de un caso de uso que aporte valor en un tiempo corto y que a su vez sea tractor del cambio cultural necesario que estos proyectos deben motivar en la organización. No hay que olvidar que este tipo de proyectos deberían ser algo más que artefactos tecnológicos, ya que conllevan un cambio organizativo y un cambio en los paradigma relacionado con el desarrollo IT. De la mano de estos proyectos de Big Data podría hacerse un plan a largo plazo para introducir el desarrollo ágil el devops etc.. si esto no se hace es probable que esta tipología de proyectos, a medio plazo, no puedan ser gestionados en las organizaciones de tamaño medio/grande. Por esa razón en el equipo de zylk hemos añadido ese tipo de perfiles, que facilitan la incorporación de estas nueva formas de hacer a las organizaciones. Por ejemplo es necesario que las organizaciones, a medio plazo, se planteen la necesidad de la figura del CDO.



Como ves actualmente, el posicionamiento y madurez de las soluciones basadas  en Software Libre para dar respuestas a los nuevos paradigmas en Big Data.


En el mundo de las soluciones de este tipo en la actualidad "o se es software libre o no se es". Es algo que en general ya está pasando con casi todo el software pero que en el mundo del Big Data reside en su propia génesis. O se es software libre o no se es. Son casos claros de este cambio todos los proyectos del ecosistema apache hadoop, o la empresa Hortonworks. Recientemente parte del equipo de zylk se desplazó a la apache europe Big Data (http://events.linuxfoundation.org/events/apache-big-data-europe) y en estas conferencias se podía ver claramente que todos "IBM, Microsoft incluso google" apuestan por los modelos de desarrollo abiertos y con licencias open. Allí también pudimos ver que los grandes consumidores, que a su vez son los grandes contributors, de estas tecnologías también usan las soluciones abiertas. Trivago, Linkedin, Soptify etc...

Todo esto se explica de manera bastante natural si entendemos que los desarrolladores que están contribuyendo al desarrollo de estas tecnologías, no las desarrollan con la finalidad última de desarrollar un software, como hacían las empresas de software privativo, sino que las desarrollan porque el core de sus negocios las necesita. Por esa razón son, y no pude ser de otra manera, desarrollos open en comunidad. Han visto la clara ventaja competitiva que supone el software abierto. Un ejemplo de este fenómeno, aunque no pertenece al mundo de apache, son los desarrollos open de Netflix. Casi todas las empresas que en la actualidad juegan un papel fundamental dentro "internet" liberan código y desarrollan en modelos abiertos. AirBnB, Netflix, Facebook, Twitter etc..  Para ser una empresa cool, antes tenías que tener futbolín (google rules), ahora hay que desarrollar proyectos open. Para mi todo se enmarca dentro de una suerte de, responsabilidad social corporativa, de las empresas que dan forma a internet; y no podría, ni debería, ser de otra manera.

En la Analítica de datos, hasta llegar a obtener las beneficios que para las organizaciones tiene el disponer de modelos predictivos de su negocio, por que fases consideras que hay que pasar?  "El reto de pasar del dato y de la información al modelado del negocio, para ser proactivos "

Bueno, creo que hay que pasar por varias fases, y estas cambian dependiendo de la fase de madurez en la que la organización se encuentre. En cualquier caso, desde zylk creemos que la única forma de afrontar proyectos es siguiendo metodologías ágiles. Hay que definir proyectos que resuelvan problemas de negocio y tiene que estar en producción desde el primer día. Un proyecto que no llega a producción, se marchita, y se queda obsoleto en muy poco tiempo. Esto en cuanto a la visión metodológica. También hay una visión técnica y una visión filosófica de todo esto. Hace poco me leí el libro La salvación de lo bello en el que, en una de sus partes, se reflexiona sobre el concepto de conocimiento, verdad e información (http://www.zylk.net/es/web-2-0/blog/-/blogs/la-salvacion-de-lo-bello). Y por último, desde el punto de vista técnico, creemos que hay que empezar por capturar los datos y disponer de un sistema de procesado en tiempo real y luego ir subiendo hacia las capas de Analítica avanzada y Machine Learning. En cualquier caso todo dependerá del proyecto y de la organización.



Entrando en la parte técnica, y comenzando por la ingesta d información de diferentes fuentes, que definición y característica seleccionarías de Apache Nifi?

Hay varias cosas que destacaría de Apache Nifi, la primera es que para una persona versada en BI clásico los conceptos que maneja son sencillos de aprehender. Por otro lado es una herramienta muy versátil que implementa la mayoría de los patrones necesarios a la hora de implementar un sistema de ingesta omnichannel. Backpresure, circuit break etc... Además dispone de un modelo para despliegue en dispositivos propios de lo que se conoce como IoT (https://nifi.apache.org/minifi/), esto es fundamental para poder desarrollar proyectos Big Data alineados con el "Internet de las cosas"


Habéis implementado Microservicios, que buenas practicas recomendarías:

Hemos usado microservicios siguiendo las buenas prácticas definidas Martin Fowler http://www.martinfowler.com/articles/microservices.html. Las características principales que en nuestro caso nos interesaban eran, la elasticidad, resiliencia, autodiscover y la integración dentro de una plataforma de gestión de recursos. En nuestro caso lo que hemos hecho ha sido usar AVRO IPC + YARN para poder desplegar y desarrollar los microservicios dentro de un cluster típico de hadoop. Lo hemos hecho así para no tener que desplegar un sistema de containers basados Docker con Kubernetes o Mesos o cualquiera de estas soluciones. Lo hemos hecho así porque los microservicios que desarrollamos son necesarios para el tratamiento de los datos y por tanto creíamos que lo mejor era definir una arquitectura de los mismos consistente con la tipología de cluster que desplegamos.


Que planteamiento técnico habéis utilizado para el dimensionamiento y monitorizacion de la carga de los procesos en tiempo real?

Principalmente no perder datos. La idea es que el sistema va a fallar en algún momento, las cosas no siempre funciona y lo principal es evitar el efecto bola de nieve. Por tanto siempre montamos sistemas desacoplados y las llamadas entre los sistemas desacoplados usa el patrón Circuit Breaker (http://martinfowler.com/bliki/CircuitBreaker.html)

Para la monitorización lo que hacemos es integrar los desarrollos realizados con el sistema de monitorización del gestor del cluster, en la mayoría de nuestras implantaciones Ambari (https://ambari.apache.org/)

---------------------------------------------------------------------------

Agradecer a Gustavo Fernandez, a Iñigo Sánchez Méndez  y  Angel Barrio por compartir su experiencia en Big Data.




7M9A0107

02 marzo 2016

Liferay 6.2 Certified Professional Developer - Open Source


Bilbomática, continua con su apuesta por la especialización en el ámbito del software Libre. Actualmente nos encontramos en proceso de certificación de nuestros profesionales en Liferay 6.2 Certified Professional Developer.

 The Liferay Certification Program focuses on providing opportunities for members of the Liferay community to demonstrate their expertise and differentiate themselves as certified Liferay professionals. The Liferay Certification Program gives companies adopting Liferay another benchmark to use for assessing a candidate's Liferay knowledge and expertise.
Aprovechamos esta entrada para dejaros un interesante articulo publicado en el Blog de Zylk, partner especialistas en productos Open Source, sobre Migración, diseño responsive y tunning SEO en Liferay 6.2 EE para el portal de Visure Solutions 

 "...desde Zylk.net, hemos estado trabajando en la migración del portal de Visure Solutions (www.visuresolutions.com), desde una versión 5.2.3 CE de Liferay a una versión 6.2 EE. De esta migración, se desprenden varias mejoras respecto al anterior portal:

     - Aplicación de las recomendaciones SEO
    - Diseño responsive para la correcta visualización de los contenidos del portal en dispositivos móviles

    - Organización de los contenidos por países..."