Evolucionando una infraestructura de datos en AWS

En esta charla veremos como ha evolucionado la insfraestructura de datos de OLAPIC en AWS.
Charlaremos sobre los distintos desafios y decisiones que se presentaron y el stack de herramientas que se han utilizado. #Redshift #Firehose #Kinesis #SQS #EMR

Por Dr. Ezequiel Orbe - Data Engineer @Olapic

Transcript

1. Evolucionando una infraestructura de datos en AWS Ezequiel Orbe Sr. Data Engineer @ Olapic
2. 01. OLAPIC PLATAFORMA DE CONTENIDO VISUAL CURAR UGC GESTIONAR INFLUENCERS MEJORAR CONTENIDO ACTIVAR EL CONTENIDO ENTENDER EL IMPACTO
3. 02. INFRAESTRUCTURA DE DATOS “Infraestructura, sistemas y procesos necesarios para generar las métricas que se proveen a los clientes tanto internos como externos.”
4. 03. ARQUITECTURA • Es un “data pipeline”. • Los datos se ingestan, se procesan y se disponibilizan para su análisis. • Storage y Orchestration -> componentes transversales.
5. • Ingestion: principal punto de conflicto. ◦ Problemas de escalado (Widget Tracking y ETL). ◦ Falta de Flexibilidad (Service Tracking y ETL). • Processing & Analysis: no tan prioritarios. 04. ESTADO INICIAL • Redshift como core de la infraestructura de datos. • Anti-patrón: mezclar cómputo y almacenamiento ◦ Redshift necesita cierto margen de espacio libre en disco. ◦ Competencia por los recursos: jobs vs usuarios.
6. 05. STORAGE • S3 como source of truth. • Parquet como formato de datos. ◦ Formato columnar. Ideal para cargas analiticas. ◦ Soportado por Hadoop, Spark, Redshift Spectrum y Athena. • Snappy como formato de compresion ◦ Parquet/Snappy: 200 GB -> 5GB. • Lifecycle: ◦ 90 dias -> S3-IA ◦ 1 año -> Glacier • Datos particionados por dia.
7. 06. ORCHESTRATION • Reemplazamos Jenkins por Airflow. • Nos permite ◦ Crear programáticamente workflows de tareas. ◦ Programar su ejecución ◦ Monitorear los workflows. • Facilita la ejecución de backfills. • Open Source: ◦ https://github.com/apache/incubator-airflow
8. 07. PROCESSING & ANALYSIS Processing: • 100% SQL Jobs. • S3 + Parquet -> Redshift Spectrum. ◦ Reducir almacenamiento en Redshift. ◦ Impacto mínimo en nuestros jobs. • Airflow + Redshift Spectrum -> Backfills Analysis: • Chartio como BI Tool principal. ◦ No soporta Redshift Spectrum. • Redash como BI Tool complementaria. ◦ Para consultar Redshift Spectrum.
9. 08. INGESTION: WIDGET TRACKING API • Escalar los consumers manualmente. • INSERTS para cargar datos en Redshift. ◦ Gran impacto en la performance de Redshift. • Kinesis Firehose se encarga de todo ◦ Ingesta los datos ◦ Los deposita en S3 ◦ Los carga en Redshift usando COPY. • 2000 req/sec por stream. ◦ Esquema de fallbacks para incrementar el throughput.
10. 09. INGESTION: SERVICE TRACKING API • Service usado para trackear eventos de negocio de cada servicio/producto. • Falta de Flexibilidad -> esquema único • Dificil de procesar. ◦ Todo es un string. • Servicio -> Tópico -> Esquemas. • AVRO como formato de serializacion • Kinesis Stream como transporte. ◦ 1 shard = 1000 req/sec. • Spark consumer en EMR ◦ 3 nodos m3.xlarge ~ 2000 req/sec
11. 10. INGESTION: DB ETL • SQOOP en EMR para sync inicial. ◦ Mappers -> Archivos. ◦ Genera archivos Parquet. • Binlog Streamer para trackear cambios. • Workflow en Airflow para updates incrementales. • Poco control sobre el proceso de ETL. • Deployment engorroso. • Sync de tablas grandes (> 300GB). • No generaba archivos Parquet.
12. 11. PROXIMOS PASOS Processing: • Migrar jobs a Apache Spark. ◦ Explorando Apache Livy • Establecer un ciclo de vida para los jobs. Analysis: • Habilitar AWS Athena ◦ Chartio se puede conectar a Athena. • Rediseñar el data warehouse. Storage: • Crear un catálogo de datos. ◦ AWS Glue es una posibilidad
13. Q&A! MUCHAS GRACIAS!