México
Big Data en AWS
Damian Traverso - Solutions Architect
18/06/2015 | Bogotá
Agenda
• Desafíos de un proyecto de Big Data
• Visión simplificada del procesamiento Big Data
• ¿Cuáles tecnologías debo u...
Desafíos de un proyecto de Big Data
Big Data: El volumen crece continuamente
De PB para ZB
GB
TB
PB
ZB
EB
1990 2000 2010 2020
Big Data Real-time Big Data
Big Data: Necesita responder más rápido
Una gran variedad de soluciones y componentes
Glacier
S3 DynamoDB
RDS
EMR
Redshift
Data Pipeline
Kinesis
Cassandra CloudSe...
Simplificando el procesamiento
de Big Data
Simplificando el procesamiento de Big Data
Ingestión
Persistencia /
Storage Procesamiento Visualización
Datos
Respuestas
T...
¿Cuáles tecnologías debo
utilizar?
Glacier
S3
DynamoDB
RDS
Kinesis
Spark
Streaming
EMR
Ingestión Persistencia Proceso/Análisis Visualización
Data Pipeline
St...
Ingestión
de
datos
Tipos de datos para ingestión
• Transaccionales
– RDBMS
lectura/escritura
• Archivos
– Click-stream logs
– Texto libre
• S...
Stream
Storage
Database
Cloud
Storage
✔
¿Por qué un Stream Storage?
• Convierte múltiples
streams en unos pocos,
persistentes y ordenados
secuencialmente
• Descon...
¿Cuál Stream Store debo utilizar?
• Amazon Kinesis y Apache Kafka tienen muchas
similitudes
– Múltiples consumidores
– Ord...
Cloud Database &
Storage
✔
✔
Cloud Database and Storage Tier Anti-pattern
App/Web Tier
Client Tier
Database & Storage Tier
Database y Storage en la nube - Las herramientas correctas
App/Web Tier
Client Tier
Data Tier
Database & Storage Tier
Sear...
App/Web Tier
Client Tier
Data Tier
Database & Storage Tier
Amazon RDSAmazon
DynamoDB
Amazon
ElastiCache
Amazon S3
Amazon
G...
¿Que Storage debo utilizar?
• Nivel de estructuración de los datos
• Complejidad de las consultas
Grado de estructuración / complejidad de las queries
VS.
Storage
Structured – Simple Query
NoSQL
Amazon DynamoDB
Cache
Ama...
¿Cuál es la temperatura de sus datos?
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...
Amazon
RDS
Frecuencia de Requests
alta baja
Costo/GB
alta baja
Latencia
baja alta
Volumen
baja alta
Amazon
Glacier
Amazon
...
Procesamiento
✔ ✔
AML
Procesamiento
• Análisis Descriptivo: BI, OLAP, SQL/data warehouse
• Análisis Predictivo: sistemas de recomendación,
previ...
Frameworks de procesamiento
Normalmente existen dos tipos:
• Batch
– Procesamiento regular (ex: ETL)
– Análisis explorator...
Procesamiento Batch
• Accede a un gran volumen de datos fríos
para interactuar en búsqueda de
correlaciones
• Generalmente...
Caso de uso: Procesamiento Batch para ETL
Amazon
EMR
Amazon
S3
Amazon
Glacier
Amazon
Redshift
Procesamiento de Stream
• Analisa datos en pequeños grupos
– CEP – Complex Event Processor (if/then/else)
– Machine Learni...
Herramientas
• Batch processing/analytic
– Amazon Redshift
– Amazon EMR
• Hive, Pig, Spark, Impala, Presto, …
• Stream pro...
¿Cuál herramienta de procesamiento batch debo usar?
Redshift Impala Presto Spark Hive
Latencia de
las queries
Baja Baja Ba...
Spark Streaming Apache Storm
+ Trident
Kinesis Client
Library
Escalabilidad/Thro
ughput
~ Nodos ~ Nodos ~ Nodos
volumen ~ ...
✔ ✔ ✔
AML
Colocando todo junto
Arquitectura desconectada
• Múltiples etapas
• Storage desconectado del procesamiento
Procesar Almacenar Procesar Almacena...
Aplicaciones de Procesamiento (o conectores)
pueden escribir en múltiples Data Stores
Amazon
Kinesis
Amazon
Kinesis
Connec...
Frameworks de Procesamiento (Storm, Hive,
Spark, etc) pueden leer de múltiples Data Stores
Amazon
Kinesis
Amazon
Kinesis
C...
Patrones de diseño
Spark
Streaming,
Apache
Storm
Amazon
Redshift Spark,
Impala,
Presto
Hive
Amazon
Redshift
Hive
Spark,
Presto
Amazon
Kinesis...
Spark
Streaming
Amazon Kinesis / KafkaDatos
Apache Storm Native Client
Procesamiento Real-time
Amazon
DynamoDB
Native
Clie...
Amazon
Redshift
Hive
Spark,
Presto
Amazon
Kinesis/
Kafka
Amazon S3Datos
Respuestas
Processamento en Batch
Spark,
Impala,
Presto
Redshift
Spark,
Presto
Kinesis/
Kafka
S3Datos HDFS
Análisis interactivos
Respuestas
AML
Resumen
• Etapas de procesamiento Big Data: ingestión,
almacenamiento, procesamiento y visualización
• Usar las herramient...
¡Muchas Gracias!
 AWS Summits América Latina 2015 Arquitecturas y mejores practicas de Big Data en AWS
Próxima SlideShare
Cargando en…5
×

AWS Summits América Latina 2015 Arquitecturas y mejores practicas de Big Data en AWS

464 visualizaciones

Publicado el

AWS Summits América Latina 2015 Arquitecturas y mejores practicas de Big Data en AWS

Publicado en: Tecnología
0 comentarios
2 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
464
En SlideShare
0
De insertados
0
Número de insertados
7
Acciones
Compartido
0
Descargas
16
Comentarios
0
Recomendaciones
2
Insertados 0
No insertados

No hay notas en la diapositiva.
  • 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





  • Hive
    Spark
    Storm
    Kafka
    HBase
    Flume
    Impala
    Cascading


    EMR
    DynamoDB
    S3
    Redshift
    Kinesis
    RDS
    Glacier
  • 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.

  • AWS Summits América Latina 2015 Arquitecturas y mejores practicas de Big Data en AWS

    1. 1. México
    2. 2. Big Data en AWS Damian Traverso - Solutions Architect 18/06/2015 | Bogotá
    3. 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
    4. 4. Desafíos de un proyecto de Big Data
    5. 5. Big Data: El volumen crece continuamente De PB para ZB GB TB PB ZB EB 1990 2000 2010 2020
    6. 6. Big Data Real-time Big Data Big Data: Necesita responder más rápido
    7. 7. Una gran variedad de soluciones y componentes Glacier S3 DynamoDB RDS EMR Redshift Data Pipeline Kinesis Cassandra CloudSearch AML
    8. 8. Simplificando el procesamiento de Big Data
    9. 9. Simplificando el procesamiento de Big Data Ingestión Persistencia / Storage Procesamiento Visualización Datos Respuestas Tiempo
    10. 10. ¿Cuáles tecnologías debo utilizar?
    11. 11. Glacier S3 DynamoDB RDS Kinesis Spark Streaming EMR Ingestión Persistencia Proceso/Análisis Visualización Data Pipeline Storm Kafka Redshift Cassandra CloudSearch Kinesis Connector Kinesis enabled app App Server Web Server Devices AML
    12. 12. Ingestión de datos
    13. 13. Tipos de datos para ingestión • Transaccionales – RDBMS lectura/escritura • Archivos – Click-stream logs – Texto libre • Stream – IoT devices – Tweets Database Cloud Storage Stream Storage
    14. 14. Stream Storage Database Cloud Storage ✔
    15. 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. 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
    17. 17. Cloud Database & Storage ✔ ✔
    18. 18. Cloud Database and Storage Tier Anti-pattern App/Web Tier Client Tier Database & Storage Tier
    19. 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. 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. 21. ¿Que Storage debo utilizar? • Nivel de estructuración de los datos • Complejidad de las consultas
    22. 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
    23. 23. ¿Cuál es la temperatura de sus datos?
    24. 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. 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
    26. 26. Procesamiento ✔ ✔ AML
    27. 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. 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. 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. 30. Caso de uso: Procesamiento Batch para ETL Amazon EMR Amazon S3 Amazon Glacier Amazon Redshift
    31. 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
    32. 32. Herramientas • Batch processing/analytic – Amazon Redshift – Amazon EMR • Hive, Pig, Spark, Impala, Presto, … • Stream processing – Apache Spark streaming – Apache Storm (+ Trident) – Amazon Kinesis client and connector library AML
    33. 33. ¿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
    34. 34. 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?
    35. 35. ✔ ✔ ✔ AML
    36. 36. Colocando todo junto
    37. 37. Arquitectura desconectada • Múltiples etapas • Storage desconectado del procesamiento Procesar Almacenar Procesar AlmacenarDatos Respuestas
    38. 38. 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
    39. 39. 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
    40. 40. Patrones de diseño
    41. 41. Spark Streaming, Apache Storm Amazon Redshift Spark, Impala, Presto Hive Amazon Redshift Hive Spark, Presto Amazon Kinesis/ Kafka Amazon DynamoDB Amazon S3Datos Caliente FríoTemperatura de los datos Latenciadelasqueries Baja Alta Respuesstas HDFS Hive Native Client Temperatura de los dados X Latencia de las queries
    42. 42. Spark Streaming Amazon Kinesis / KafkaDatos Apache Storm Native Client Procesamiento Real-time Amazon DynamoDB Native Client Respuestas
    43. 43. Amazon Redshift Hive Spark, Presto Amazon Kinesis/ Kafka Amazon S3Datos Respuestas Processamento en Batch
    44. 44. Spark, Impala, Presto Redshift Spark, Presto Kinesis/ Kafka S3Datos HDFS Análisis interactivos Respuestas
    45. 45. AML
    46. 46. 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
    47. 47. ¡Muchas Gracias!

    ×