Los datos grandes pueden ser un gran dolor de cabeza, a menos que usted sepa cómo manejarlos a escala. El gerente de ingeniería de Credit Karma, Dustin Lyons, habló con ConsejoTecnologico.com sobre cómo maneja sus datos el gigante fintech.
Fintech es una de las categorías de inversión de capital riesgo de más rápido crecimiento. Desde 2010, más de 1.200 empresas de capital riesgo han transferido más de 22.000 millones de euros a las cuentas bancarias de más de 1.800 nuevas empresas, según Pitchbook. El CEO de J.P. Morgan, Jamie Dimon, quien recientemente se retiró de la consideración de Secretario del Tesoro en la administración Trump, advirtió a sus colegas que «Silicon Valley está llegando».
Una de las estrellas más brillantes de fintech es Credit Karma, con sede en San Francisco, fundada en 2007 con más de 368 millones de euros en fondos de riesgo recaudados desde entonces. Hoy en día, la compañía, que da puntajes de crédito gratuitos y gana dinero haciendo recomendaciones personalizadas a sus usuarios y comparándolos con productos, tiene más de 60 millones de usuarios.
Es fundamental para su éxito averiguar cómo ofrecer una experiencia de usuario más personalizada. Recientemente hablé con Dustin Lyons, gerente de ingeniería de Credit Karma, para obtener más información sobre cómo la plataforma de consumidores maneja los grandes datos a esta escala y volumen.
Un problema de gran envergadura
ConsejoTecnologico.com: Cuéntame un poco más sobre la escala de los datos gestionados por Credit Karma.
Lyons: Nuestra infraestructura de datos maneja regularmente más de 750.000 eventos por minuto, procesando 600-700MB por minuto. Nuestro pipeline de datos fue construido originalmente usando PHP, pero vimos que no iba a escalar para satisfacer las demandas de nuestro crecimiento. Estábamos usando Gearman para paralelizar la importación de datos entre máquinas, pero a medida que la ingesta de datos crecía, empezamos a investigar otros lenguajes y herramientas con un mejor soporte para la gestión de cargas de trabajo concurrentes.
VER: Cómo The New York Times utiliza herramientas de programación reactiva como Scala para escalar
Un enfoque paralelizado
ConsejoTecnologico.com: Suena como un buen problema para tener. ¿Qué es lo que hiciste?
Lyons: Necesitábamos una nueva arquitectura, no herramientas en los bordes: Estábamos en un cohete de crecimiento. Algunos de nuestros ingenieros habían estado probando Scala y Akka y sabíamos que queríamos alejarnos de los tipos dinámicos y de la falta de concurrencia de primera clase en PHP.
Así que empezamos con Scala y Akka de Lightbend, usando Apache Kafka, y empezamos a construir un Akka Actor System que podría ayudarnos a paralelizar el trabajo a través de hilos y cajas. Encontramos éxito en este enfoque: Scala nos da seguridad tipográfica y el rendimiento de la JVM, y Akka abstrae la complejidad de los sistemas distribuidos multihilo. Esto era mucho más adecuado para la escala de datos que estábamos viendo.
Aún así, nuestras versiones iniciales en producción se encontraron con un obstáculo, superando constantemente el espacio en pilas y el consumo masivo de memoria. Nos dimos cuenta de que nos faltaba algo fundamental para tratar de procesar literalmente decenas de millones de eventos.
Bajo presión (trasera)
ConsejoTecnologico.com: ¿Cómo te las arreglaste para evitarlo?
Más información sobre Big Data
Lyons: Básicamente nos tropezamos con un concepto muy importante que había sido ignorado: Contrapresión. Este nuevo concepto nos introdujo entonces a las ideas del Manifiesto Reactivo. La contrapresión, y está bien definida en el Manifiesto, es un mecanismo de retroalimentación que permite a un sistema controlar la velocidad a la que los mensajes son recibidos por los actores de abajo. Esto evita que los componentes más lentos del sistema se vean abrumados por componentes más rápidos. Habíamos desarrollado actores que empujaban los datos sin evaluar el rendimiento del trabajo entre ellos.
Afortunadamente, nuestros amigos de Lightbend proveen una herramienta para resolver esto: Arroyos Akka. Proporciona una API de streaming que introduce el concepto de demanda entre editores y suscriptores. En lugar de que los actores introduzcan mensajes en el sistema, Akka Streams se mueve hacia un modelo en el que los actores piden y arrastran el trabajo a lo largo del sistema. De esta manera, los actores más lentos pueden solicitar trabajo a medida que los recursos se liberan. Por esta razón, veíamos muchos errores de espacio en la producción.
VER: Cómo una compañía mejoró la productividad de los desarrolladores en un 700% con programación reactiva.
Después de reescribir la lógica central para usar los Streams de Akka, estos errores desaparecieron y el uso de la memoria se volvió mucho más predecible. Al cambiar a este sistema basado en tirones, en lugar de cargar de antemano una gran cantidad de trabajo para hacer cola en la memoria, fuimos capaces de reducir el uso en pilas en un 300%. Ahora utilizamos Scala, Akka y Akka Streams en muchos de nuestros escenarios críticos de canalización rápida de datos.
Boletín informativo de Big Data Insights
Domine los fundamentos de la analítica de datos de gran tamaño siguiendo estos consejos de expertos y leyendo los conocimientos sobre las innovaciones de la ciencia de datos. Lunes de entrega