Cómo FiveStars rediseñó la pila de ingeniería de datos

Construir y administrar la infraestructura usted mismo le da más control, pero el esfuerzo por mantener todo bajo control puede desviar recursos de la innovación en otras áreas. A Matt Doka, CTO de FiveStars, una plataforma de marketing para pequeñas empresas, no le gusta esta compensación e intenta subcontratar todo lo que puede.

Esto es evidente en su renuencia a administrar sus propios servidores, pero quizás sea más evidente en su enfoque de la ingeniería de datos, donde se acerca al final de un viaje de cinco años para automatizar o subcontratar gran parte del trabajo técnico de rutina y enfocarse internamente. recursos sobre análisis de datos. .

FiveStars ofrece a las pequeñas empresas un servicio de tarjeta de fidelización en línea, el equivalente digital de una tarjeta de sello “compre nueve, obtenga una gratis”, que pueden vincular a los números de teléfono y tarjetas de pago de sus clientes. Más de 10.000 pequeñas empresas utilizan sus servicios y Doka estima que casi 70 millones de estadounidenses se han unido a los programas de fidelización que opera. Recientemente cambió al procesamiento de pagos, una opción aceptada por aproximadamente el 20% de sus clientes, y ofrece sus propias terminales de pago compatibles con PCI.

Registrar todas estas interacciones crea una gran cantidad de datos, pero eso no es la mitad. Para unir los procesadores de pago heredados que dejan la terminal en paz y permiten que los clientes llamen al soporte cuando deja de funcionar, FiveStars incorpora sistemas de telemetría en sus terminales que brindan información periódicamente sobre el estado de su conexión, el nivel de la batería y el rendimiento de la aplicación.

“La mayor parte de nuestra carga ni siquiera son las transacciones, los puntos o las tarjetas de crédito en sí”, dice. “Son muchos datos de telemetría del dispositivo para asegurarse de que sea la mejor experiencia de su clase cuando alguien quiere hacer un pago o ganar algunos puntos”.

Determinar esto a partir de los datos requirió mucho análisis, un trabajo para el que un equipo de datos de 10 personas tenía menos tiempo, porque proteger la infraestructura de datos lo consumía todo.

El equipo de datos que construyó la primera versión de la infraestructura de datos de FiveStars comenzó en el área de ventas y marketing del negocio, no en TI. Doka dice que este accidente histórico significó que, si bien realmente conocían los datos, tenían poca experiencia en la gestión de la infraestructura.

Cuando Doka se hizo cargo del equipo, descubrió que estaban escribiendo todo a mano: código de automatización del servidor, consultas a la base de datos, análisis, todo. “¡Escribieron guiones bash!” dice Doka. “Incluso hace 10 años había sistemas que podían generar scripts bash”.

El sistema era frágil, muy manual y basado en mucho conocimiento tribal. El resultado fue que los analistas de datos dedicaron la mayor parte de su tiempo a hacer que el sistema funcionara. “Lucharon por obtener nuevos conocimientos de datos que se convirtieron en análisis”, dice.

En 2019, agrega, la respuesta de todos a tal problema fue usar Apache Airflow, una plataforma de código abierto para administrar flujos de trabajo de ingeniería de datos escrita en Python. Diseñado originalmente para hacer exactamente lo que el equipo de Doka en AirBnB todavía hace a mano.

Doka eligió la versión alojada de Airflow para reemplazar el sistema homebrew intensivo en recursos de FiveStars. “Quería sacarnos del negocio de implementar nuestra propia infraestructura porque estos son analistas de datos o incluso ingenieros de datos, no SRE experimentados”, dijo. “Tampoco es un buen uso de nuestro tiempo”.

La adopción de Airflow significó que Doka podía dejar de preocuparse por cualquier otra cosa que no fueran los servidores. “Ha habido mucho progreso en la estandarización y los conceptos básicos de lo que se está impulsando”, dice. “Simplemente estás heredando todas estas mejores prácticas que inventamos o reinventamos nosotros mismos”.

Pero agregó: “La forma en que trabajas en Airflow depende completamente del equipo de desarrollo, por lo que aún pasas muchos ciclos cerebrales estructurando cada nuevo proyecto”. Y su queja particular fue que deberías crear tu propia documentación de tus mejores prácticas.

Entonces, solo un año después de comenzar a migrar a Airflow, Doka estaba buscando algo mejor para ayudarlo a automatizar más sus procesos de ingeniería de datos y estandarizar algunas de sus decisiones críticas para el negocio que consumen menos tiempo.

Lanzó su red de par en par, pero la mayoría de las herramientas que encontró resolvieron solo una parte del problema.

“DBT, por ejemplo, se centró en cómo cambiar los datos dentro de una instancia de Snowflake”, dice. “Ese es un muy buen trabajo, pero ¿cómo obtienes datos de todas tus fuentes en Snowflake?” Para eso, agrega, “Había algunas plataformas que podían eliminar todo el movimiento de datos de forma estandarizada, como Fivetran, pero en realidad no te daban un lenguaje con el que trabajar”.

Después de revisar varias otras opciones, Doka finalmente se decidió por Ascend.io. “Me gustó que haya una forma estándar de escribir una consulta SQL o código Python y crea un linaje y una topología”, dijo. “El sistema puede saber automáticamente de dónde provienen todos los datos; cómo condujo al análisis final”.

No solo elimina la molestia de administrar servidores, dice, sino que también elimina la decisión de cómo trabaja.

“Ahorra a los ingenieros y analistas de datos una tonelada de sobrecarga mental”, dice. “Pueden concentrarse en la pregunta que están tratando de responder y el análisis que están tratando de hacer”.

Agrega que es más fácil para los analistas no solo concentrarse en su propio trabajo, sino también monitorearse entre sí.

“Existen todos estos documentos que simplemente se construyen por diseño, donde cada analista, sin pensarlo, ha dejado un rastro de fragmentos obvios de cómo llegaron a donde están”. “Entonces, si nuevas personas se unen al proyecto, es más fácil ver lo que está pasando”.

Ascend usa otro proyecto de Apache, Chispa – chispearcomo motor de análisis y tiene su propia API de Python, PySpark.

Los primeros casos de uso importantes de Airflow tardaron menos de un mes en migrar. “Tomó una hora activarlo y dos minutos conectar Postgres y algunas de nuestras fuentes de datos”, dice Doka. “Fue demasiado rápido”.

Duplicar algunos flujos de trabajo fue tan fácil como mover SQL básico de Airflow a Ascend. “Una vez que trabajábamos en paridad, simplemente cambiábamos [old] escurrir y poner [new] el conector de salida debe ir donde tiene que ir”, dice.

Lo más útil de Ascend fue que hizo cambios en el código tan rápido que el equipo pudo desarrollar y arreglar todo en tiempo real. “El sistema puede saber dónde han cambiado o no partes del flujo de trabajo, y si nada cambia, no vuelve a ejecutar todo, por lo que no está desperdiciando cómputo”, dice. “Fue una velocidad realmente agradable”.

Algunas cosas todavía implicaban esperar toda la noche. “Hay un servicio upstream que solo se puede descargar de 2 a. m. a 5 a. m., por lo que fue complicado obtener el código correcto para asegurarse de que se estaba descargando en el momento adecuado del día, pero no fue necesariamente culpa de Ascend”. él dice.

Movilizando el cambio cultural

La transición a Ascend no supuso grandes necesidades de reciclaje o contratación. “Ahora que tenemos todo abstracto, el edificio es casi cero”, dice Doka, que ahora tiene tres personas trabajando en los nuevos sistemas y unos seis analistas informando y generando información basada en los datos.

“La mayor parte del trabajo de infraestructura se ha ido”, dijo. “Todavía hay algo de trabajo de ETL, la transformación y la limpieza nunca se llevan a cabo, pero ahora se hace de manera estandarizada. Una cosa que me tomó tiempo digerir fue la transición de lo que llamo Python vainilla, que usé con Airflow, a Spark Python. Es una sensación diferente a simplemente escribir código de procedimiento”. Esto no es conocimiento esotérico, solo algo que el equipo de FiveStars no ha usado antes y con lo que necesita familiarizarse.

Un tema recurrente en el viaje de ingeniería de datos de Doka fue encontrar cosas nuevas que pudiera dejar de construir y comprar en su lugar.

“Cuando construyes, posees y administras una pieza de infraestructura en tu hogar, tienes un mayor nivel de control y conocimiento”, dice. “Pero muchas veces sacrificas mucho tiempo por ello, y muchas veces no tienes la mejor experiencia para desarrollarlo”.

No fue fácil convencer a los colegas de los beneficios de hacer menos. “Tuve problemas con el equipo en ambas ocasiones”, dice. “Siempre es parte de la transición a un sistema más abstracto”.

Doka dice que ha trabajado con varias empresas emergentes como inversionista o consultor, y siempre les dice a los fundadores con mentalidad tecnológica que eviten administrar la infraestructura ellos mismos y elijan el mejor proveedor para alojar todo por ellos, y no solo porque les ahorra tiempo. “También aprenderá mejores prácticas trabajando con ellos”, dice. Ofrece el mismo consejo a los líderes de TI empresariales cuando trabajan con equipos internos. “Lo más consistente que he visto en mis 11 años como CTO es que la gravedad empuja a las personas a ‘construir aquí’ por alguna razón”, dijo. “Nunca entendí eso”. Es algo a lo que tienes que resistirte constantemente o perder el tiempo manteniendo cosas que no son parte del negocio principal.