2. Big Data en AWS
Damian Traverso - Solutions Architect
18/06/2015 | Bogotá
3. Agenda
• Desafíos de un proyecto de Big Data
• Visión simplificada del procesamiento Big Data
• ¿Cuáles tecnologías debo utilizar?
• Arquitectura de Referencia
• Patrones de Diseño
15. ¿Por qué un Stream Storage?
• Convierte múltiples
streams en unos pocos,
persistentes y ordenados
secuencialmente
• Desconecta productores y
consumidores de datos
• Actúa como un buffer o
una cola
• Streams en secuencia son
más faciles de procesar
• Preserva el orden para los
consumidores
• Streaming MapReduce
• El consumidor puede
realizar un replay y
reprocesar
16. ¿Cuál Stream Store debo utilizar?
• Amazon Kinesis y Apache Kafka tienen muchas
similitudes
– Múltiples consumidores
– Orden de los registros
– MapReduce de Streaming
– Baja latencia
– Alta durabilidad, disponibilidad y escalabilidad
• Diferencias
– Un registro dura 24 horas en Kinesis, en Kafka es configurable
– Tamaño de 50 Kb en Kinesis, en Kafka es configurable
– Kinesis es un servicio totalmente gestionado – fácil de provisionar,
monitorear y escalar.
Kafka exige un trabajo de administración de disponibilidad y escalamiento
como un proceso on-premise
19. Database y Storage en la nube - Las herramientas correctas
App/Web Tier
Client Tier
Data Tier
Database & Storage Tier
Search
Hadoop/HDFS
Cache
Blob Store
SQL NoSQL
20. App/Web Tier
Client Tier
Data Tier
Database & Storage Tier
Amazon RDSAmazon
DynamoDB
Amazon
ElastiCache
Amazon S3
Amazon
Glacier
Amazon
CloudSearch
HDFS on Amazon EMR
Database y Storage en la nube - Las herramientas correctas
21. ¿Que Storage debo utilizar?
• Nivel de estructuración de los datos
• Complejidad de las consultas
22. Grado de estructuración / complejidad de las queries
VS.
Storage
Structured – Simple Query
NoSQL
Amazon DynamoDB
Cache
Amazon ElastiCache
Structured – Complex Query
SQL
Amazon RDS
Search
Amazon CloudSearch
Unstructured – No Query
Cloud Storage
Amazon S3
Amazon Glacier
Unstructured – Custom Query
Hadoop/HDFS
Elastic MapReduce
Gradodeestructuración
Grado de complejidad de las queries
24. Temperatura de los datos: Calientes, Tibios o Fríos
Caliente Tibio Frío
Volumen MB–GB GB–TB PB
Tamaño del registro B–KB KB–MB KB–TB
Latencia ms ms, seg min, horas
Durabilidad Baja - Alta Alta Muy Alta
Frecuencia de
requests Muy Alta Alta Baja
Costo/GB $$-$ $-¢¢ ¢
25. Amazon
RDS
Frecuencia de Requests
alta baja
Costo/GB
alta baja
Latencia
baja alta
Volumen
baja alta
Amazon
Glacier
Amazon
CloudSearch
Estructuración
baja
alta
Amazon
DynamoDB
Amazon
ElastiCache
27. Procesamiento
• Análisis Descriptivo: BI, OLAP, SQL/data warehouse
• Análisis Predictivo: sistemas de recomendación,
previsión de page-views, subasta de anuncios on-line
• Clasificación: análisis de sentimiento, fraude, anti
spam, clustering de clientes para crear perfiles de
consumo
• Correlación: comparar lo que se sabe sobre el negocio
(BI) con las oscilaciones del mercado, tiempo y
temperatura, reputación en las redes sociales
28. Frameworks de procesamiento
Normalmente existen dos tipos:
• Batch
– Procesamiento regular (ex: ETL)
– Análisis exploratorio (ex:data science)
• Stream
– IoT, click-stream, social monitoring,
crawlers, etc
29. Procesamiento Batch
• Accede a un gran volumen de datos fríos
para interactuar en búsqueda de
correlaciones
• Generalmente necesita minutos o horas para
obtener una respuesta
Por ejemplo: Generar reportes por horas, días o
meses
30. Caso de uso: Procesamiento Batch para ETL
Amazon
EMR
Amazon
S3
Amazon
Glacier
Amazon
Redshift
31. Procesamiento de Stream
• Analisa datos en pequeños grupos
– CEP – Complex Event Processor (if/then/else)
– Machine Learning (fraude, recomendaciones, etc.)
• Responde en corto lapso de tiempo
– Real-time o Near Real-time dependiendo de cada
aplicación
Por ejemplo: análisis de 1min de
operaciones
34. ¿Cuál herramienta de procesamiento batch debo usar?
Redshift Impala Presto Spark Hive
Latencia de
las queries
Baja Baja Baja Baja - Media Media - Alta
Durabilidad Alta Alta Alta Alta Alta
volumen 1.6PB Max ~Nodos ~Nodos ~Nodos ~Nodos
Managed Si EMR
bootstrap
EMR
bootstrap
EMR
bootstrap
Si (EMR)
Storage Nativo HDFS HDFS/S3 HDFS/S3 HDFS/S3
# of BI Tools Alta Media Alta Baja Alta
Latencia
de las
queries
Baja Alta
35. Spark Streaming Apache Storm
+ Trident
Kinesis Client
Library
Escalabilidad/Thro
ughput
~ Nodos ~ Nodos ~ Nodos
volumen ~ Nodos ~ Nodos ~ Nodos
Administración Si (EMR bootstrap) Hágalo usted
mismo
EC2 + Auto Scaling
Tolerencia a fallas Built-in Built-in KCL Check pointing
Lenguages de
programación / API
Java, Python, Scala Java, Scala,
Clojure
Java, Python
¿Cuál herramienta de procesamiento de Stream debo usar?
39. Aplicaciones de Procesamiento (o conectores)
pueden escribir en múltiples Data Stores
Amazon
Kinesis
Amazon
Kinesis
Connectors
Amazon
S3
Datos Amazon
DynamoDB
Lambda Architecture
Análisis
Real Time
Análisis
Exploratório
40. Frameworks de Procesamiento (Storm, Hive,
Spark, etc) pueden leer de múltiples Data Stores
Amazon
Kinesis
Amazon
Kinesis
Connectors
Amazon
S3
Datos Amazon
DynamoDB
Hive Spark
Respuestas
Storm
Respuestas
47. Resumen
• Etapas de procesamiento Big Data: ingestión,
almacenamiento, procesamiento y visualización
• Usar las herramientas correctas de acuerdo con
el trabajo a ser realizado
– Ingestión: Dados transaccionales, archivos, stream
– Almacenamiento: nivel de estructuración, complejidad de las
queries, datos calientes VS fríos, etc.
– Procesamiento: Latencia de las queries
• Arquitectura de referencia en Big Data y patrones
de diseño
a alguns desafios de projetos Big Data
Estabelcer uma visão Simplificada a concepção de um projeto de big data
Identificar as tecnologias para cada caso de uso
Apresentar uma arquitetura de referência
Falar de alguns design patterns
Melhores práticas
Desafios que nossos clientens enfrentam
Volume do universo de dados deve crescer vertiginosamente nos próximos anos
Alguns estudos apontam que o volume de dados em 2020 será 10x maior que 2013
A convergencia de muitas tecnologias como cloud, mobile, social, avanços na área de genoma, IoT, pesquisa espacial pressionam o crescimento
Due to the convergence of many technologies of cloud, mobile, social, and advancements in many field such as genomics, life sciences, space, the size of the digital universe is growing at an ever increasing rate.
Customers have also found tremendous value in being able to mine this data to make better medicine, tailored purchasing recommendations, detect fraudulent financial transactions in real time, provide on-demand digital content such as movies and songs, predict weather forecasts, the list goes on and on.
E que descobrimos ?
Que quanto mais rápido criamos dados, mais rápido queremos respostas.
As data creation is becoming more real-time and continuous
so is the need to manage it
Vamos começar elaborando uma visão simplificada do processamento de Big Data
Um jeito de pensar em big data é ter em mente os ciclos do processo ou um pipeline onde os dados entram de um lado
geram respostas do outro.
Tudo isso dentro de um tempo aproprioado milisegundos para real time, minutos ou horas para outros tipos de necessidade.
Tempo muda e baseado nele mudam também os tipos de componentes que v. deve usar no pipeline.
Vamos começar alinhando alguns desses compontentes dentro das categorias
Vamos fazer um map sem reduce
Sei que há poucas empresas aqui mas o ecosistema de parceiros é bem maior. Isso não significa que o suporte da Aws se restija somente a essas empresas
Vamos falar um pouco sobre a primeira fase, : a Ingestão
Vamos receber dados de sistemas transacionais baseados em bancos relacionais
Vamos receber arquivos de logs com formatação variada
Vamos receber textos livre, imagens
Vamos receber sinais de dispositivos de IoT
Vamos receber streams de dados das redes sociais
A próxima questão é que tipo de storage a gente tem que usar
Dados formatados e relacionais podem ser gravados em Databases SQL e NoSQL
Logs e textos pouco ou semi formatados podem ser gravados em Storage
Streaming de dados precisa ser retidos em uma fila ou storage intermediario para que sejam analisados o mais rápido possivel (Kinesis, Kafa)
Vamos falar um pouco mais sobre o tratamento de streaming de dados
Converte múltiplos streams em poucos e persistentes ordenados sequencialmente Streams em sequencia são mais fáceis de processar
Desconecta produtores e consumidores de dados (essa desconexão é importante para escalar horizontamente)
Atua como um buffer ou uma fila
Preserva para o cliente a ordenação
Você pode fazer um timpo de mapreduce para selecionar dados importantes e separar sinal de ruído -- Streaming “MapReduce”
Consumidor pode dar um replay e reprocessar
Leia o Slide
Muitos dos clientes já familiarizados com o kafka não querem a complexidade de gestão, criar, escalar, monitorar e manter. O kinesis é bem fácil e não tem essa complexidade.
http://blog.cloudera.com/blog/2014/09/apache-kafka-for-beginners/
https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines
https://blogs.apache.org/flume/entry/flume_ng_architecture
https://blogs.apache.org/flume/
https://blogs.apache.org/flume/
Use considerations
Take all the undifferentiated heavy lifting
Focus less on muck
We want to offer choice
Maintain update
Keep in mind even thought Kafka is open source,
Put a lot more efforts into kafka
Lot of effort and smart engineering
Passado o Streaming vamos falar dos outros formatos de storage
Aqui o que não fazer
Bancos de daods RELACIONAIS orientados a transações (OLTP) são ótimos para muitas coias
mas encontram sérias restrições para escalar.
Temos muitos casos de clientes que entenderam após a implementação que o RDBMS não atende necessidades e precisam migrar para NoSQL.
5.000 writes or reads/second em um dynamo v. só configura quantos righs/second v. quer em um OLTP isso vai dar muito trabalho exigir muita configuração e gestão.
Banco relacional pode (e deve) ser substituido por outro banco ou storage no formato adequado a demanda e uso
OLTP
OLAP
NoSQL
As soluções
AWS para cada caso de uso.
Como eu escolho um deles?Vamos nos ater em algumas dimensões
2 x 2 Matrix
Structured
Level of query (from none to complex)
Draw down the slide
Agora vamos adicionar a dimensão tempo
Temos aqui o EMR dando suporte a PRESTO IMPALA SPARK HIVE PIG
MPP - Procesamento Paralelo Massivo em Redshift, Presto e Impala
Hadoop – com MapReduce, Tez, Spark,
Vamos falar sobre a dimensão da latência da query e como ela se contextualiza
O Redshift é ótimo para agregar dados dada a sua arquitetura colunar e processamento MPP
Outro aspecto importante dessa dimensão é a quantidade de ferramentas BI (ultima linha) com que o software se conecta
Se v. usa um storage hdfs ou s3, pode processar com varias ferramentas usando clusters separados e transientes.
Query Speed
Redshift – Extremely fast SQL queries
Spark, Impala – Extremely Fast to Fast Hive QL
Hive, Tez – Moderately Fast to Slow Hive QL
Data Volume?
UDFs?
Manageability?
http://yahoodevelopers.tumblr.com/post/85930551108/yahoo-betting-on-apache-hive-tez-and-yarn
https://amplab.cs.berkeley.edu/benchmark/
Essas soluções são meio equivalentes
O SPARK é interessante porque tem o seu ecosistema com o MLIB, Spark-SQL,
Similar to multi-tier web-app-data architectures
Concept of a “data bus” or “data pipeline”
This is a summary of all six design patterns together. This summarizes all of the solutions available in the context of the temperature of the data and the data processing latency requirements.
Hive – 1 year worth of click stream data
Spark – 1 year of click stream data – what people are buying frequently together
Redshift – reem
ting, enterprise reporting tool – SQL Heavy
Impala – same as redshift
Preseto same league as Impala presto – Interactive SQL analytics – have a Hadoop installed base….
NoSQL – Analytics on NoSQL
This is a summary of all six design patterns together. This summarizes all of the solutions available in the context of the temperature of the data and the data processing latency requirements.
Hive – 1 year worth of click stream data
Spark – 1 year of click stream data – what people are buying frequently together
Redshift – reporting, enterprise reporting tool – SQL Heavy
Impala – same as redshift
Preseto same league as Impala presto – Interactive SQL analytics – have a Hadoop installed base….
NoSQL – Analytics on NoSQL
This is a summary of all six design patterns together. This summarizes all of the solutions available in the context of the temperature of the data and the data processing latency requirements.
Hive – 1 year worth of click stream data
Spark – 1 year of click stream data – what people are buying frequently together
Redshift – reporting, enterprise reporting tool – SQL Heavy
Impala – same as redshift
Preseto same league as Impala presto – Interactive SQL analytics – have a Hadoop installed base….
NoSQL – Analytics on NoSQL
This is a summary of all six design patterns together. This summarizes all of the solutions available in the context of the temperature of the data and the data processing latency requirements.
Hive – 1 year worth of click stream data
Spark – 1 year of click stream data – what people are buying frequently together
Redshift – reporting, enterprise reporting tool – SQL Heavy
Impala – same as redshift
Preseto same league as Impala presto – Interactive SQL analytics – have a Hadoop installed base….
NoSQL – Analytics on NoSQL
The world is producing an ever increasing volume, velocity, and variety of big data. Consumers and businesses are demanding up-to-the-second (or even millisecond) analytics on their fast-moving data, in addition to classic batch processing. AWS delivers many technologies for solving big data problems. But what services should you use, why, when, and how? In this session, we simplify big data processing as a data bus comprising various stages: ingest, store, process, and visualize. Next, we discuss how to choose the right technology in each stage based on criteria such as data structure, query latency, cost, request rate, item size, data volume, durability, and so on. Finally, we provide reference architecture, design patterns, and best practices for assembling these technologies to solve your big data problems at the right cost.