Evolucionando una infraestructura de datos en AWS Ezequiel Orbe Sr. Data Engineer @ Olapic

01. OLAPIC PLATAFORMA DE CONTENIDO VISUAL CURAR UGC GESTIONAR INFLUENCERS MEJORAR CONTENIDO ACTIVAR EL CONTENIDO ENTENDER EL IMPACTO

02. INFRAESTRUCTURA DE DATOS “Infraestructura, sistemas y procesos necesarios para generar las métricas que se proveen a los clientes tanto internos como externos.”

03. ARQUITECTURA ● Es un “data pipeline”. ● Los datos se ingestan, se procesan y se disponibilizan para su análisis. ● Storage y Orchestration -> componentes transversales.

● 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.

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.

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

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.

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.

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

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.

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

Q&A! MUCHAS GRACIAS!