BigData y Ecosistema Hadoop: Capgemini - UV

Biografía

• Biografía & presentación:

• Francisco Monzonís Lucas – Ingeniero Superior Informático – Master Degree M-Commerce Research Programme Abo Akademi – Scrum Manager – PMP por el Project Management Institute – Master Big Data & Analytics por el IE Business School. – Manager Insights & Data en Capgemini – Experiencia en proyectos Inteligencia Negocio (> 10 años) – francisco.monzonis-lucas@capgemini.com – http://linkedin.com/in/francisco-monzonis-lucas-b1798111b

Agenda

Motivación Arquitectura de referencia y el camino a Big Data Estado del arte de la tecnología: - Datawarehouse - Hadoop - Distribuciones Hadoop - In-memory & Otras

Resumen y guías Experiencia real. Análisis de Redes Sociales

Motivación

¿Por qué Big Data?

En la actualidad, muchas de las compañías de referencia en el panorama mundial centran su estrategia de negocios en el Big Data.

En algunas compañías españolas, se han creado Equipos de trabajo de innovación muy enfocados en el Big Data.

¿Por qué Big Data?

Revenue: 8,33 billion USD (2016)

Stock price: $145 (NASDAQ)

N. Employees:

Stores: n/a

Revenue: -

Stock price: $0,01 (BLIAQ)

N. Employees: 60.000 (2004)

Stores: 8.000 (2004)

Revenue: 5,5 billion USD (2016)

Stock price: -

N. Employees: 6.700

Not own resources (taxis)

Revenue: 1,7 billion USD (2016)

Stock price: -

N. Employees: 2.400

Not own resources (houses)

Revenue: 14,49 billion USD (2015)

Stock price: $88 (NASDAQ)

N. Employees: 125.000

Hotels: 6.000 (2016)

Revenue: 136 billion USD (2016)

Stock price: $856 (NASDAQ)

N. Employees: 300.000

Not own resources (houses)

Revenue: 485 billion USD (2016)

Stock price: $70 (NASDAQ)

N. Employees: 2,3 million

Stores: 6.300 (2015)

Sólo en españa, alrededor de

70.000 licencias de taxi.

¿Por qué Big Data?

A

¿Por qué Big Data?

La curva de Hype:

¿Por qué Big Data?

Los proyectos de Big Data, suelen venir dirigidos: Por el negocio. Por los datos. Figura clave CDO.

El uso de Big Data, permite: Conocer mejor el cliente. Personalizar el producto o servicio para el cliente Crear productos y servicios nuevos Abarcar mayor parte del mercado y en el momento adecuado Acercarnos a la prescripción, acción y toma de decisiones Reducir costes, con el uso extensivo de canales de venta digitales. Reducir el tiempo de reacción en la toma de decisiones

¿Por qué Big Data?

Variables que hay que manejar en un

proyecto de Big Data.

Capacidades Equipo

Regulación y Seguridad

Valor de Negocio

Arquitectura y Tecnología

Calidad y Confianza en

el dato

¿Por qué Big Data?

Factores clave por los que fracasa un proyecto de BigData

Factores Clave

• No existe caso de negocio

• No existe capacidades equipo

• Gestión cambio inadecuada

• Reinos de “taifas” (silos)

• Falta de sponsor

• Apoyo Dirección

• Aspectos culturales (emprendimiento/innovación)

• No existe un ROI tangible

• Exceso de tecnología

Riesgos y Limitaciones

• Regulación

• Seguridad / Privacidad

• Falta de datos (no se guardaron)

• Desconocimiento o acceso a los datos de la compañía

• Calidad y confiabilidad de los datos

• Globalización / Ancho de banda.

¿Por qué Big Data?

• Monetización de los datos.

Proveedor

del dato

Cliente

del dato

Datos corporativos Datos anonimizados

INTERFACE API ACCESO A DATOS

Petición de

información por parte

de un cliente

Obtención de datos

anonimizados y

agregados

Datos en bruto,

pero anonimizados

¿Por qué Big Data?

Roles en proyectos Big Data

CDO /

Manager

Analista de

negocio

Científico de

datos

Ingeniero de

datos

Administrador

de

Sistemas

Arquitecto

de datos

Experto

UX

Definir casos

de negocio

Validar

resultados

Seguimiento

del ROI

Visión

estratégica

Comunicación

con la dirección

Responsable

proyecto

Tecnología+

Negocio

Implementar

modelos

matemáticos

Análisis de

datos

Descubrir

patrones

Diseñar e

implementar

procesos.

Construcción

cuadros de

mando.

Pruebas de

sistema

Definir

componentes

tecnológicos

idóneos

Integración

componentes

Establecer

políticas de

datos y

seguridad

Configuración

y monitorización

de los sistemas

Presentar al

negocio la

información del

modo más

ergonómico y

usable posible

¿Por qué Big Data?

El CDO en el organigrama de la compañía

Dependencia directa del CEO

Dependencia del CIO

Existe una tendencia creciente a organigramas basados en el

primer modelo

En empresas cuya estrategia se basa en datos: CDO

CHIEF

EXECUTIVE

OFFICER

CHIEF

INFORMATION

OFFICER

CHIEF

DATA

OFFICER

¿Por qué Big Data?

Ley de Moore aplicada al Big Data Predice que aproximadamente cada dos años se duplica el número de transistores en un microprocesador . Los datos que se generan en la era digital siguen la ley de Moore.

¿Por qué Big Data?

Para los proyectos de Big Data, no hay que "obsesionarse" con la tecnología. Bajo nuestra opinión, la arquitectura técnica, hadoop sí o no, la distribución a elegir, etc… son decisiones estratégicas basadas en qué queremos hacer y por tanto, cómo vamos a usar la tecnología para conseguir esos fines. Y no al revés.

Las tecnologías Big Data son un facilitador permiten hacer a un coste razonable lo que antes era sencillamente

imposible o estaba solo al alcance de unos pocos.

Consideraciones

• Esta presentación pretende describir el estado del arte de las tecnologías Big Data en base a la experiencia de Capgemini – Tecnología emergente. En continua evolución

(cada menos de 6 meses cambia) – El % de implantación en el mercado Español está

creciendo (se empieza con una PoC)

Arquitectura de Referencia

Conceptos clave

Hay que conocer algunos conceptos clave : Por lotes/batch: programado para su ejecución diferida en el tiempo

Casi Tiempo Real/near real-time: existe una pequeña diferencia de tiempo entre el momento en que ocurre el evento y en el que se procesa (segundos, o pocos minutos).

Tiempo Real/real-time: la información se procesa y se consume en intervalos de tiempo muy muy pequeños (milisegundos, microsegundos).

Streaming: habitualmente asociado al flujo continuo de datos.

Lambda Architecture

Equilibrar la latencia, rendimiento y tolerancia a fallos mediante el uso de procesamiento por lotes para proporcionar puntos de vista pre-computados completos y exactos, mientras que al mismo tiempo utilizando el procesamiento de flujo en tiempo real para proporcionar vistas dinámicas.

Kappa Architecture

La Arquitecura Kappa es una variante de la Arquitectura Lambda, más reducida, en la cual se elimina el sistema de procesamiento batch. La ingesta de datos se realiza en su totalidad a través de streaming.

Datawarehouse y el concepto DataLake

Data warehouse

• Los Data warehouse almacenan grandes volúmenes de datos en estructuras definidas y estáticas que determinan el tipo de análisis que se puede hacer de los datos. Por tanto, su capacidad analítica (informes, cuadros de mando, …) está limitada por las propias estructuras de las fuentes.

Data Lake

• Un Data Lake es un repositorio de la totalidad de los datos de los que una organización dispone o puede obtener. Los datos se ‘ingieren’ en ‘bruto’ y se pueden guardar en ‘bruto’, sin ningún esquema o estructura pre-definida, o de forma estructurada.

• Esto proporciona una ventana ilimitada a los datos para poder realizar sobre ellos cualquier consulta, navegación, análisis, ….

Este enfoque ha comenzado a verse insuficiente ya que es muy difícil determinar por adelantado toda la inteligencia y conocimiento que se pueda extraer de la variedad de diferentes fuentes (como bases de datos propietarias, archivos, herramientas de terceros, medios de comunicación, redes sociales, …) Muchas veces no se tienen las preguntas de antemano, por lo que las verdaderas preguntas nacen cuando se analizan los distintos datos de los que dispones

Capgemini: Arquitectura de Referencia BIGDATA

Gobierno del Proyecto

Gobierno del Dato

Por lotes / / Casi T.R. / Streaming

Info

rma

ció

n d

e R

efe

ren

cia

Eve

nto

s/D

ato

s

(es

tru

ctu

rad

os

y n

o)

Utilización Almacenamiento Adquisición de la Información

Capgemini: Arquitectura de Referencia BIGDATA

Ingestion tier

Insights tier Unified operations tier

System monitoring System management

Unified data management tier

Data mgmt. services

MDM DQM

Audit and policy mgmt.

Processing tier

Workflow management

Distillation tier

HDFS storage Unstructured and structured data

In-memory

MPP database

Real time

Micro batch

Mega batch

SQL NoSQL

SQL MapReduce

Query interfaces

SQL

Sources Action tier

Real-time ingestion

Micro batch ingestion

Batch ingestion

Real-time insights

Interactive insights

Batch insights

Graph

GIS

Text

Image & Video

El camino

Paso 1: Descarga de datos del DW al Data Lake … para obtener almacenamiento inmediato y mejorar el rendimiento

DATA LAKE Descarga al Data lake

Mover los datos ‘cold’ dentro del

Data Lake

Ahorros de almacenamiento inmediato y reducción de costes El Data Lake proporciona nuevas capacidades analíticas

Datos Hot

Reconciliation

Business Transform

CDR

Master Data

BI Applications Integration Layer DW Platform Semantic Layer End Users Source Systems

DW

CRM

CRM Analytics

Reporting

Staging area

Landing area

Extract Transform Load

Sem

anti

c La

yer

Datos no usados en el dia a dia (Históricos, tickets, …)

Paso 2: Ir moviendo al Data Lake la integración y flujo de datos … para obtener un Datawarehouse optimizado común

Visión estratégica, mejora la eficiencia y reduce coste total (TCO) Se crea un almacén de datos optimizado (CDW + otros)

CDW

Datos Hot

Reconciliation

Business Transform

Sem

anti

c La

yer

CRM

CDR

Master Data

BI Applications Integration Layer DW Platform Semantic Layer End Users Source Systems

DW

DATA LAKE (Datos Cold)

Staging area

Landing area

Social Media

QoS Sandbox

Dat

a V

irtu

aliz

atio

n

CRM Analytics

Reporting

ETL Offloading

Datos no estructurados

Datos estructurados

Paso 3: Ingesta nuevas fuentes de datos y clasificación según … la temperatura (Hot/Cold) para realizar un ‘Data Lake inicial’

Information Dissemination Layer

Infrastructure

Data Governance, ILM, Privacy & Security

Batch & Real-time

Data Ingestion

Optimized Common Data Warehouse Ecosystem

Data Warehouse

Data Lake Tools

Security & Audit

Staging / Landing

Queries (SQL like)

Discovery Platform

In Platform Analytics

Profiling, MDM, Cleansing, DQ

Big Analytics

Visualization

Predictive Analytics

BI Reporting

Planning / Forecasting

Unstructured (Internal & external, e.g., QoS, CDR, social media…)

Structured (Internal + external, e.g., CRM, Finance, MDM)

Data Integration

Archive, Backup / DR

EDW Staging

Data Access

Data Marts

API Batch Virtual

Guardar la información en bruto sobre el Data Lake.

Resumen, de las diferentes opciones Cómo incorporar Big Data en la compañía.

1. Hadoop

como nuevo

repositorio

2. Hadoop

como

fuente para

el Dwh

3. Hadoop

como

descarga

para el Dwh

4. Hadoop como

Data Lake

Estado arte tecnologías

Clasificaciones o Tipos de Big Data

Volumen / Velocidad / Variedad

• Fuentes datos actuales (estructuradas)

• Las capacidades analíticas te las dan los orígenes de datos

• La velocidad y el volumen tienen costes altos

Data warehouse vs Data Lake (Hadoop)

• Nuevas fuentes datos (estructuradas y no)

• Nuevas capacidades analíticas • Nuevas opciones de disponer

velocidad y volumen a costes reducidos

Las tecnologías Datawarehouse

Datawarehouse (Large)

• Obtención de ventaja de simbiosis entre hardware y software. • Concepto de Appliance • Modelo tradicional RDBMS (relacional). • Simplificación, y consecuentemente abaratamiento, en la

administración (autoregulación , modelos estándares,…). • Modelos de crecimiento flexibles :

– un cuarto, – un medio, – ….

• Coste razonable de implementación/migración.

Appliances

Tratamiento Paralelo Masivo

Modelo relacional

(SQL)

Datawarehouse (Large)

• Optimización gradual con técnicas especializadas, cada fabricante usa propias (compresión, modelos columnares, cachés, in memory, índices especializados, distribución, ordenación...)

• Utilización de discos de alto rendimiento y SSD, con replicación y TF. • Comunicaciones basadas en buses y redes de alta velocidad. • Diferentes modelos, hardware propietario o commoditty. • Facilitación de integración Hadoop. • Arquitectura MPP (masively parallel processing) frente a SMP

(symmetric multi-processing). • Fabricantes prinicipales:

Las tecnologías Hadoop

Historia

2015 2016 2014 2013 2012 2011 2010 2009 2008 2007 2006 2005 2004 2003 2002

Ecosistema Hadoop

● Qué es Hadoop?

● Principales productos del ecosistema Hadoop

● Stack tecnológico

Qué es Hadoop?

● Hadoop es un framework que permite el proceso distribuido de grandes

volúmenes de datos entre clusters de computación.

● Está diseñado para escalar desde un solo servidor a miles de máquinas, cada

una ofreciendo capacidad de cálculo y de almacenamiento.

● Tolerancia a fallos: el dato está replicado.

● Incluye:

o Hadoop Commons

o Hadoop Distributed File System (HDFS™)

o Hadoop YARN (yet another resource negotiator)

o Hadoop MapReduce

● Yahoo: 4500 nodes (2*4cpu boxes w 4*1TB disk & 16GB RAM)

HDFS

MapReduce 2

Storage managers

General Purpose Execution Engines

YARN

Stack Tecnológico

HDFS (sistema ficheros)

● Distribuido, tolerante a fallos, throughput-optimized data storage

● Es un sistema de ficheros, no una BD de tablas estructuradas.

● Los datos se reparten por todo el cluster.

● Cada nodo del clúster tiene un “cachito” de los datos. Estos

“cachitos” se llamas bloques y son de 64MB por defecto.

● HDFS ha demostrado escalabilidad hasta 200 PB en un cluster de

4500 nodos

hdfs dfs -ls /user/hadoop/file1

hdfs dfs -mkdir /user/hadoop/dir1 /user/hadoop/dir2

hdfs dfs -rm hdfs://nn.example.com/file /user/hadoop/emptydir

YARN / Mapreduce

● MapReduce:

o Fwk con servicios para distribuir trabajos y aglutinar resultados, ordenar, agrupar, filtrar, etc.

o Es un modelo de programación, basado en paradigma “divide y vencerás”

● YARN:

o Gestiona acceso a recursos de las aplicaciones (memoria, CPU)

o Monitoriza nodos.

o Planifica trabajos.

o Soporta distintos tipos de aplicaciones (no solo MapReduce).

MapReduce

Ejemplo: contar el número de apariciones de cada palabra.

Hiv

e

Pig

Cas

cad

ing

Gir

aph

Mah

ou

t

SQL Engines

Abstraction Engines Graph processing

Engines

Machine Learning

Stack Tecnológico

Sqo

op

HDFS

MapReduce 2

Storage managers

General Purpose Execution Engines

YARN HBase

PIG

● Procesamiento de datos basado en Map Reduce

● Lenguaje de alto nivel, fácil de programar

● Análisis de grandes volúmenes de datos

● Flujo de datos procedimental, que pemite:

o JOIN’s y transformación de datos.

● También se pueden programar utilidades en java, python, ruby, … y llamarlas desde Pig.

people = LOAD ‘/user/training/customers’ AS (cust_id, name);

orders = LOAD ‘/user/training/orders’ AS (ord_id, cust_id, cost);

groups = GROUP orders BY cust_id;

totals = FOREACH groups GENERATE group, SUM(orders.cost) AS t;

result = JOIN totals BY group, people BY cust_id;

DUMP result;

Hive

● Lenguaje de consultas para acceder a Hadoop

● Lenguaje SQL (no estándar) y limitado → HiveSQL (HQL)

● Reduce el tiempo de desarrollo.

● Se ejecuta sobre Mapreduce, Spark o Tez.

● Orientado a batch. Modo interactivo → Stinger Initiative

SELECT customers.cust_id, SUM(cost) AS total

FROM customers

JOIN orders

ON customers.cust_id = orders.cust_id

GROUP BY customers.cust_id

ORDER BY total DESC;

Hive

https://cwiki.apache.org/confluence/display/Hive/Roadmap

HBase

● Es una base de datos no relacional y distribuida orientada a la columna.

● No admite SQL

● Almacenamiento distribuido a través de un cluster de máquinas.

● HBase es el componente de Hadoop a usar, cuando se requiere escrituras/lecturas en tiempo real y acceso aleatorio para grandes conjuntos de datos.

● Particiones de datos autogestionadas

HBase

● Qué no es:

o No es una base de datos SQL

o No es relacional

o No usa JOIN’s

o Sin transaccionalidad.

o No sustituye los sistemas RDBMS

● Para qué se utiliza? Se utiliza en casos de procesamiento de grandes volúmenes de información que encajen bien con el paradigma clave-valor. Por ejemplo: almacenar y procesar líneas de logs.

HBase

● La información se organiza en familias de columnas (clave-valor).

● Físicamente, los datos de cada familia de columna se almacenan de forma contigua.

Sqoop

● Herramienta para realizar transferencias de datos masivas entre RDBMs y Hadoop (HDFS, HIVE, HBase).

● Bases de datos soportadas:

o MySQL

o PostgreSQL

o Oracle

o HSQLDB

● Paralelizado (MapReduce), incremental, etc.

● Ejemplo de uso: importar datos de una BD SQL a Hive.

Sqoop

[root@quickstart.cloudera ~] sqoop import-all-tables \

-- num-mappers 1 \

--connect jdbc:mysql://quickstart.cloudera:3306/retail_db \

--username=retail_dba \

--password=cloudera \

--compression-codec=snappy \

--as-avrodatafile \

--warehouse-dir=/user/hive/warehouse/userXX

[root@quickstart.cloudera ~] sqoop import \ --query 'SELECT a.*, b.* FROM a JOIN b on (a.id == b.id) WHERE $CONDITIONS' \

Otros

● Cascading: ETL basado en Java/Scala (soporta MR, Tez y Flink)

● Giraph: Proceso de grafos. Ejemplo: lo usa Facebook para analizar el grafo social que forman sus usuarios así como las conexiones que existen entre ellos.

● Mahout: Librerías para machine learning

Spark

Gra

ph

X

MLi

b

Spar

k SQ

L

Spar

k St

ream

ing

Streaming

Stack Tecnológico

Hiv

e

Pig

Cas

cad

ing

Gir

aph

Mah

ou

t

Sqo

op

HDFS

MapReduce 2

YARN HBase

SQL Engines

Abstraction Engines Graph processing

Engines

Machine Learning Storage managers

General Purpose Execution Engines

Spark

Sistema de computación distribuida y tolerante a fallos.

Diferencias con Hadoop:

● Más rápido: está optimizado para trabajar en memoria.

● API más potente y flexible que MapReduce: desarrollo más fácil

● APIs en Scala, Python y Java.

Spark puede ejecutarse sobre si mismo o sobre otros gestores:

● Amazon EC2

● Standalone Deploy Mode

● Apache Mesos

● Hadoop YARN

Spark

Benchmark Daytona GraySort contest:

Spark SQL

● Integrado con Spark: Se pueden lanzar consultas desde código.

● Acceso a distintas fuentes de datos: JSON, tablas Hive

● Compatibilidad con Hive: HiveQL, datos y user defined functions.

Spark Streaming

● Ingestión de datos en “mini-batches”

● Usado en implementación de Arquitecturas Lambda

● Latencia ligada a la duración del “mini-batch”

● Facilidad de uso, tolerante a fallos, integrado con Spark…

● Posibilidad de uso de Mlib.

Stack Tecnológico

Hiv

e

Pig

Ca

sca

din

g

Spark

Gra

ph

X

MLi

b

Spar

k SQ

L

Spar

k St

ream

ing

Streaming

Hiv

e

Pig

Cas

cad

ing

Gir

aph

Mah

ou

t

Sqo

op

HDFS

MapReduce 2

YARN HBase

SQL Engines

Abstraction Engines Graph processing

Engines

Machine Learning Storage managers

General Purpose Execution Engines

Stack Tecnológico

Ha

wq

Sto

rm

Flu

me

Ka

fka

Imp

ala

Hiv

e

Pig

Ca

sca

din

g

Spark

Gra

ph

X

MLi

b

Spar

k SQ

L

Spar

k St

ream

ing

Streaming

Hiv

e

Pig

Cas

cad

ing

Gir

aph

Mah

ou

t

Sqo

op

HDFS

MapReduce 2

YARN HBase

SQL Engines

Abstraction Engines Graph processing

Engines

Machine Learning Storage managers

General Purpose Execution Engines

Impala (interface de consulta)

● Orientado a consultas interactivas

o Consultas ad-hoc

o Integración herramientas BI (Pentaho, Microstrategy, …)

● 10 veces más rápido que Hive o Pig

● Motor de ejecución particular (no MapReduce)

● Open source: Impala está incluido en distribuciones de Cloudera, MapR, Oracle, y Amazon

Pig, Hive and Impala

Hawq (interface de consulta)

● Creado por Pivotal

● Compatible con estándares SQL

● Benchmark hecho por Pivotal:

● Mayor rendimiento vs Impala

● 21x más rápido vs Stinger (Hive).

● Diseñado para manejar datos de PB.

Storm (ingesta)

● Modelo de computación distribuido basado en procesamiento Streaming.

● Está en continua ejecución, esperando siempre nuevos eventos, a diferencia de MapReduce que es un programa que empieza y termina.

● Características más importantes: ● Rápido - hasta un millón de mensajes de 100 bytes por segundo por nodo

● Escalable – Con cálculos en paralelo en distintos nodos de un cluster

● Tolerante a fallos

● Seguro – Se garantiza el procesado único de cada mensaje.

● Preparado para producción out of the box

● Aplicación en modelos en los que se requiere una escucha activa y continuada de eventos que deben ser procesados en el mismo momento de su recepción.

● Ejemplo: procesamiento información sensores.

Kafka (ingesta)

• Sistema de mensajería de publicación-suscripción rápido, escalable, duradero y con tolerancia a fallos.

• Se utiliza a menudo en lugar de intermediarios de mensajes tradicionales como JMS y AMQP debido a su mayor rendimiento, fiabilidad y replicación.

• Casos de uso: – Stream Processing, Website Activity Tracking, Metrics

Collection and Monitoring, Log Aggregation

• API’s Kafka: – Producer API: publicación de registros de streams para tópicos Kafka.

– Consumer API: subscripción a tópicos y procesamiento de streams

– Streams API: procesamiento de streams (input output).

– Connector API: conexión de productores/consumidores con

aplicaciones o systemas de datos existentes.

Por ejemplo: un conector a una BD relacional puede capturar los

cambios en una tabla.

Flume (ingesta)

● Es un servicio distribuido para capturar de forma eficiente, agregar y mover grandes cantidades de datos log de diferentes orígenes (diferentes servidores) a un repositorio central, simplificando el proceso de recolectar estos datos para almacenarlos en Hadoop y poder analizarlos. Flume y Chukwa son proyectos parecidos, la principal diferencia es que Chukwa está pensado para ser usado en Batch.

Flume

Sources:

• Avro Source

• Thrift Source

• JMS Source

• Converter

• Spooling Directory Source

• BlobDeserializer

• NetCat Source

• Sequence Generator

• Syslog Sources

• HTTP Source

• ...

Channels:

• Memory Channel

• JDBC Channel

• File Channel

• Kafka Channel

• Spillable Memory Channel

• Pseudo Transaction Channel

• Custom Channel

Sinks:

• HDFS Sink

• Logger Sink

• Avro Sink

• Thrift Sink

• IRC Sink

• File Roll Sink

• Null Sink

• HBaseSink

• MorphlineSolr Sink

• ElasticSearch Sink

• ...

Flume vs. Kafka

● Kafka es multipropósito, con distintos productores y distintos consumidores. Flume esta especializado en escribir en HDFS.

● Flume soporta más tipos de productores y consumidores por defecto.

● Los dos son zero data loss debidamente configurados, pero Kafka es high-available.

● Kafka y Flume se integran perfectamente: Para hacer streaming desde Kafka a Hadoop, se recomienda utilizar Flume que utilice Kafka como source.

Las tecnologías Distribuciones Hadoop

Distribuciones Hadoop

● Distribución: empaquetado de tecnologías del ecosistema Hadoop con una capa de gestión añadida y soporte empresarial.

Cloudera

● Distribuye Cloudera Enterprise

● Contribuyente principal del proyecto Impala.

● Incluye, entre otros, los siguientes servicios:

o Seguridad

o Gobierno de dato

o Gobierno operacional

● Cloudera Manager y Cloudera Navigator no son OS: ● Cloudera Manager: permite gestionar el cluster

● Cloudera Navigator: gobierno del dato

Cloudera

HortonWorks

● Distribuye la Hortonworks Data Platform (HDP)

● Contribuyente principal del proyecto Hive.

● Todo Opensource

● HDP incluye los siguientes servicios:

o Seguridad

o Gobierno de dato

o Gobierno operacional

● Propulsor de la "Stinger Initiative”:

o Mejorar Hive para tratar consultas interactivas (no batch)

o Consultas a escala de petabyte. Todo Opensource

HortonWorks

MapR

● Mapr-FS en vez de HDFS:

o Mejor rendimiento, confiabilidad, eficiencia, mantenibilidad y facilidad de uso.

o Se puede montar vía NFS (network file system).

o Posix-compliant (norma portabilidad)

o Soporta Impala

o Mapr-DB en vez de

HBase:

MapR

Las tecnologías In-memory & Otras

Bases de datos In-memory

• Almacenamiento de los datos en memoria principal.

• Algunas soportan ACID (atomicity, consistency, isolation, durability)

• No hay prevención completa de pérdida de datos en caso de fallo de corriente, solo algunos acercamientos: – Snapshots (fotos de estado)

– Journaling (a modo de log de las acciones realizadas)

– NVRAM (RAM no volátil)

– High Availability (replicación)

• Híbridos: Lectura en memoria, escritura en disco

In-memory

In-memory y otras

• In-memory – SAP Hana – Oracle TimesTen – Spark

• NoSQL – Mongo-DB – Cassandra – NEO4J – …

SAP HANA

• Extreme-APPs basadas en SAP Hana. • Integración en el ecosistema ERP • Solución propietaria, pero abierta a futuros desarrollos • Procesamiento en memoria, relacional y columnar. • Integración con otros sistemas. • Rápida implantación. • Coste de licencias

MongoDB

DW

Características

MongoDB. Base de datos NoSQL

Almacenamiento interno en formato BSON. Orientado a documentos de esquema libre.

No implementa propiedades ACID.

Los datos son recuperados de forma muy rápida de la BBDD.

Rapidez ejecución consultas simples. No apto para consultas complejas (análisis de datos)

No dispone de capacidades analíticas

Modelo de datos muy simple

Facilidad de escalado

Alta concurrencia

Rápida implantación

Ofrece ventajas sobre las SGBDR en cuanto a volumen de datos y coste

Integración con herramientas BI (Microstrategy, …)

Tecnologías Resumen y Mapeado

Gartner Magic Quadrant Dwh

Soluciones Hadoop se valoran como DW

Forrester Wave Big Data Hadoop Solutions 2016

Resumen Tecnologías

Cloudera HortonWorks MapR Oracle Big

Data Appliance

IBM Big insights

Apache Hadoop

PivotalHDB WANDisco

Oracle Exadata

IBM Netezza

Teradata HP Vertica GreenPlum

ECM

Algunas posibles guías

• Si se tienen consultas ad-hoc, las consultas y necesidades analíticas se conocen de antemano y los datos son de menos de 600Tb, la recomendación sería un Data warehouse.

• Si la estrategia de la empresa está dirigida por los datos, debería usarse ser Hadoop, para guardar el máximo de datos posibles.

• Si el volumen de datos a gestionar es mayor de 600TB, la recomendación seria ir hacia un modelo basado en Hadoop pero teniendo en cuenta la complejidad de las consultas requeridas.

• Si se tienen necesidades de negocio propias y se requiere responder tan pronto sea posible, la recomendación también podría ser ir hacia un modelo basado en Hadoop

• Si los volúmenes de datos son pequeños, no se requiere analítica, pero se requiere alta velocidad la recomendación podría ser NoSQL

http://server.dzone.com/articles/oracle-vs-teradata-vs-hadoop-1

Criterios de valoración: Posibles puntos a considerar

Almacenamiento.

•Capacidades para el almacenamiento de grandes volúmenes de datos procedentes de fuentes diversas, tanto estructurados como no estructurados.

Escalado.

•Facilidad de crecimiento sin que las prestaciones se vean comprometidas.

Capacidad analítica.

•Capacidad para realizar cálculos analíticos sobre los datos almacenados en la plataforma.

Latencia de los datos requerida

•¿cuánta historia se quiere tener en línea? ¿es posible pasar cierta historia a un área fría con menores costes de almacenamiento (redireccionar datos de la tabla de un SGBD hacia el HDFS) ¿cuántos usuarios necesitarían acceder en concurrencia a la historia?¿con qué frecuencia...?

Open Source.

•Basado estándares abiertos ó solución propietaria.

Acceso on-line usuarios.

•Facilidad para el desarrollo de la funcionalidad de consultas on-line de tickets de compra.

Adaptación nuevas necesidades.

•Posibilidad de implementar nuevas funcionalidades no previstas inicialmente.

Tiempo de implantación.

•Tiempo que se tardaría en tener una solución operativa.

Precio de la infraestructura.

•Coste de la infraestructura sobre la que se instalaría la plataforma. Coste de las máquinas, licencias, coste de implantación.

Experiencia Real. Análisis Redes Sociales

www.capgemini.com

The information contained in this presentation is proprietary. © 2015 Capgemini. All rights reserved. Rightshore® is a trademark belonging to Capgemini.

About Capgemini With almost 140,000 people in over 40 countries, Capgemini is one of the world's foremost providers of consulting, technology and outsourcing services. The Group reported 2013 global revenues of EUR 10.1 billion. Together with its clients, Capgemini creates and delivers business and technology solutions that fit their needs and drive the results they want. A deeply multicultural organization, Capgemini has developed its own way of working, the Collaborative Business ExperienceTM, and draws on Rightshore ®, its worldwide delivery model.