Descargado 20 veces
Subido porAmazon Web Services LATAM
AWS Summits América Latina 2015 Arquitecturas y mejores practicas de Big Data en AWS
El documento resume los desafíos y las etapas clave del procesamiento de Big Data, incluida la ingestión, el almacenamiento, el procesamiento y la visualización. Recomienda usar las herramientas adecuadas de AWS para cada etapa según el tipo y temperatura de los datos, y la complejidad de las consultas. También presenta una arquitectura de referencia desconectada y patrones de diseño para colocar las piezas juntas de manera efectiva.
Más contenido relacionado
Similar a AWS Summits América Latina 2015 Arquitecturas y mejores practicas de Big Data en AWS
Más de Amazon Web Services LATAM
AWS Summits América Latina 2015 Arquitecturas y mejores practicas de Big Data en AWS
- 1.
- 2. Big Data enAWS Damian Traverso - Solutions Architect 18/06/2015 | Bogotá
- 3. Agenda • Desafíos deun 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. Desafíos de unproyecto de Big Data
- 5. Big Data: Elvolumen crece continuamente De PB para ZB GB TB PB ZB EB 1990 2000 2010 2020
- 6. Big Data Real-timeBig Data Big Data: Necesita responder más rápido
- 7. Una gran variedadde soluciones y componentes Glacier S3 DynamoDB RDS EMR Redshift Data Pipeline Kinesis Cassandra CloudSearch AML
- 8.
- 9. Simplificando el procesamientode Big Data Ingestión Persistencia / Storage Procesamiento Visualización Datos Respuestas Tiempo
- 10.
- 11. Glacier S3 DynamoDB RDS Kinesis Spark Streaming EMR Ingestión Persistencia Proceso/AnálisisVisualización Data Pipeline Storm Kafka Redshift Cassandra CloudSearch Kinesis Connector Kinesis enabled app App Server Web Server Devices AML
- 12.
- 13. Tipos de datospara ingestión • Transaccionales – RDBMS lectura/escritura • Archivos – Click-stream logs – Texto libre • Stream – IoT devices – Tweets Database Cloud Storage Stream Storage
- 14.
- 15. ¿Por qué unStream 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 Storedebo 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.
- 18. Cloud Database andStorage Tier Anti-pattern App/Web Tier Client Tier Database & Storage Tier
- 19. Database y Storageen 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 DataTier 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 deboutilizar? • 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
- 23. ¿Cuál es latemperatura de sus datos?
- 24. Temperatura de losdatos: 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 altabaja Costo/GB alta baja Latencia baja alta Volumen baja alta Amazon Glacier Amazon CloudSearch Estructuración baja alta Amazon DynamoDB Amazon ElastiCache
- 26.
- 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 Normalmenteexisten dos tipos: • Batch – Procesamiento regular (ex: ETL) – Análisis exploratorio (ex:data science) • Stream – IoT, click-stream, social monitoring, crawlers, etc
- 29. Procesamiento Batch • Accedea 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
- 33. 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
- 34. ¿Cuál herramienta deprocesamiento 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 ApacheStorm + 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?
- 36.
- 37.
- 38. Arquitectura desconectada • Múltiplesetapas • Storage desconectado del procesamiento Procesar Almacenar Procesar AlmacenarDatos Respuestas
- 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
- 41.
- 42. Spark Streaming, Apache Storm Amazon Redshift Spark, Impala, Presto Hive Amazon Redshift Hive Spark, Presto Amazon Kinesis/ Kafka Amazon DynamoDB Amazon S3Datos CalienteFríoTemperatura de los datos Latenciadelasqueries Baja Alta Respuesstas HDFS Hive Native Client Temperatura de los dados X Latencia de las queries
- 43. Spark Streaming Amazon Kinesis /KafkaDatos Apache Storm Native Client Procesamiento Real-time Amazon DynamoDB Native Client Respuestas
- 44.
- 45.
- 46.
- 47. Resumen • Etapas deprocesamiento 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
- 48.
Notas del editor
- #4 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
- #5 Desafios que nossos clientens enfrentam
- #6 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.
- #7 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
- #8 Hive Spark Storm Kafka HBase Flume Impala Cascading EMR DynamoDB S3 Redshift Kinesis RDS Glacier
- #9 Vamos começar elaborando uma visão simplificada do processamento de Big Data
- #10 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.
- #12 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
- #13 Vamos falar um pouco sobre a primeira fase, : a Ingestão
- #14 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
- #15 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
- #16 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
- #17 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
- #18 Passado o Streaming vamos falar dos outros formatos de storage
- #19 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.
- #20 Banco relacional pode (e deve) ser substituido por outro banco ou storage no formato adequado a demanda e uso OLTP OLAP NoSQL
- #21 As soluções AWS para cada caso de uso.
- #22 Como eu escolho um deles? Vamos nos ater em algumas dimensões
- #23 2 x 2 Matrix Structured Level of query (from none to complex) Draw down the slide
- #24 Agora vamos adicionar a dimensão tempo
- #34 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,
- #35 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/
- #36 Essas soluções são meio equivalentes O SPARK é interessante porque tem o seu ecosistema com o MLIB, Spark-SQL,
- #39 Similar to multi-tier web-app-data architectures Concept of a “data bus” or “data pipeline”
- #43 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
- #44 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
- #45 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
- #46 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
- #48 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.