Los sistemas de datos tienden a la producción

Los últimos diez años han visto una rotación casi completa en las herramientas disponibles para un profesional de datos. Mirando la pila de datos moderna de hoy, la mayoría de las herramientas (dbt, Looker, Snowflake, Fivetran, Hightouch, Census) no estaban disponibles comercialmente en 2012. Categorías completas (ELT, ETL inversa, almacenes en la nube) y marcos (activación de datos, mallas de datos , estructuras de datos, contratos de datos) se han creado. (O, en algunos casos, los equipos de datos han vuelto a descubrir prácticas SWE de hace décadas). Los seguidores de Twitter + Substack, los proyectos de código abierto, las carreras y las empresas han subido y bajado. La oportunidad abunda.

La posibilidad y el área de superficie para que un profesional de datos influya en la dirección de una empresa es sustancialmente mayor que hace una década. Desafortunadamente, la superficie de lo que puede salir mal ha crecido igual de rápido. Los desafíos van desde SLA técnicos de bajo nivel hasta sistemas, cultura, estándares y diseño organizacional de alto nivel. Las nuevas herramientas son increíblemente poderosas. Las empresas pueden crear y romper sistemas de datos a mayor velocidad que nunca.

He observado tres tendencias para los sistemas de datos en los últimos cinco años, que van desde las verticales técnicas dentro de los equipos de datos, así como desde las verticales comerciales respaldadas por datos. Intentaré describir estas tendencias a través de ejemplos que se generalicen a muchas empresas y, con suerte, describiré oportunidades, problemas y soluciones de manera que se generalicen a su equipo. Las tendencias, oportunidades, problemas y soluciones:

Los sistemas tienden a la producción

• Resumen : el trabajo de datos valiosos y las salidas terminan consumiéndose en casos de uso que son cada vez más importantes / grado de producción.
• Oportunidad : los resultados de un equipo de datos se pueden distribuir en un área de superficie mucho más grande e impactante.
• Problema : dado que las salidas de datos son consumidas por casos de uso más importantes, no hay un "endurecimiento" correspondiente de los flujos de trabajo, que inicialmente se configuraron de una manera muy ligera.
• Solución : Cree un camino para que los flujos livianos pasen a "producción", celebre el tiempo dedicado a fortalecer los sistemas a medida que avanzan hacia el grado de producción.

• Resumen : las salidas de datos inicialmente destinadas a un propósito específico encuentran cada vez más y sin saberlo adopción en muchos equipos y casos de uso.
• Oportunidad: los conocimientos diseñados para un caso de uso específico pueden impulsar una mejor toma de decisiones/resultados en más equipos.
• Problema : no hay dos equipos que tengan exactamente las mismas especificaciones, las mejoras para un caso de uso no se consumen en otro lugar.
• Solución : crear compromisos de consumidor/productor + visibilidad de las dependencias, centralizar la lógica empresarial.

• Resumen : los datos se pueden transformar en muchos pasos a lo largo de su viaje, la lógica comercial vive en una variedad de herramientas.
• Oportunidad : las herramientas de datos modernas permiten a las partes interesadas acceder a los datos y realizar transformaciones de última milla para moverse más rápido y desbloquearse.
• Problema : la lógica comercial en toda la pila hace que la reproducibilidad sea imposible, las transformaciones de última milla no benefician a otros consumidores de datos.
• Solución : Reduzca las áreas donde se puede inyectar la lógica comercial, cree políticas de "tiempo de vida" en las transformaciones de última milla, cree una cultura de estandarización y celebración del acceso a bases de códigos interfuncionales.

Verano 2019 . El auge de las bebidas carbonatadas enriquecidas es imparable, pero todavía hay algunos dueños de tiendas de licores que no lo saben. Eres ingeniero analítico en un mercado de bebidas alcohólicas B2C. Sus gerentes de cuenta (expertos en el consumo de alcohol) SABEN que las Garras volarán de los estantes, si solo las puede conseguir en las tiendas. Este es el elusivo mercado de la mejora de Pareto ganar/ganar/ganar, donde un mejor inventario beneficia al cliente, al minorista y a la empresa. Se le asignó la tarea de descubrir los artículos más vendidos que una tienda de licores en su red no ofrece.

1. Uso interno (herramienta BI / Looker)

La consulta inicial es fácil de escribir. Hay una tabla de tiendas (con market_idlos SKU más vendidos por mercado y un feed de inventario diario para cada tienda). Cada tienda tiene un feed de inventario diario. Algo como esto obtiene los artículos más vendidos que cada tienda no tiene:

select
  s.store_id,
  skus.sku_id,
  skus.market_rank
from dim_stores as s
left join tbl_top_selling_market_skus as skus
  on s.market_id = skus.market_id
left outer join dim_store_inventory as inv
  on s.store_id = inv.store_id
  and inv.sku_id = skus.sku_id
  and inv.remaining_qty > 0
where inv.sku_id is null
order by store_id, skus.market_rank desc
;

…el gerente de cuenta inicial da retroalimentación en el tablero durante todo el proceso.

Nota: La herramienta de BI es una infraestructura de equipo de datos. Ningún conocimiento/caso de uso/producto ha salido del dominio del equipo de datos. Un error tiene pocas consecuencias, la retroalimentación es probable + inmediata.

2. Uso interno (Herramientas internas / Salesforce)

Sin embargo, un equipo de ventas/éxito del cliente/administración de cuentas no pasa todo el día en Looker, pasan todo el día en Salesforce. Tener dos navegadores abiertos es una molestia. Este es un caso de uso de ETL inverso de libro de texto. Coloque los datos donde se utilizarán . Esto fue difícil hace años, ahora es trivial: firme un proveedor de ETL inverso, mueva sus puntos de datos de A a B en menos de un día.

Los artículos más vendidos que una tienda no tiene ahora están en Salesforce. El equipo de datos ha agregado contexto para otro equipo con poca fricción. De esto se trata la activación de datos: empoderar a otros equipos para que hagan mejor su trabajo con las herramientas con las que están familiarizados. Más gerentes de cuentas miran más artículos faltantes en el inventario, llaman a más tiendas, más SKU principales llegan a las tiendas de licores, se producen más ventas. todos ganan

…un administrador de cuentas se da cuenta de que una tienda de cervezas y vinos tiene licores en su lista de artículos más vendidos. El AM usa su contexto comercial y omite recomendar artículos que saben que la tienda no puede vender legalmente. Se ha agregado lógica comercial adicional a través de una capa de decisión humana.

Nota: Salesforce NO es una infraestructura de equipo de datos. Las perspectivas y los casos de uso han dejado el dominio del equipo de datos, pero no el de la empresa. Nada es de cara al cliente. Un error tiene pocas consecuencias, pero la retroalimentación no está garantizada. Se ha agregado lógica adicional (a través del juicio humano).

3. Uso externo (Automatización de Marketing)

La implementación de Salesforce es útil, pero sigue siendo de naturaleza bastante manual. Los gerentes de cuentas y los dueños de licorerías pasan demasiado tiempo en el teléfono. La mayoría de las licorerías hacen pedidos de inventario una vez por semana. El AM solicita la ayuda de las operaciones de datos y marketing para agilizar la comunicación a través de correos electrónicos automatizados en una cadencia semanal.

Se necesitan algunas columnas más, luego la tabla sin procesar se invierte con ETL en Hubspot / Iterable / Braze. Un asociado de CRM da los toques finales a la campaña de correo electrónico y se activa una campaña de correo electrónico titulada "Los mejores artículos que no lleva".

…el asociado de CRM a cargo del correo electrónico advierte que algunos de los artículos más vendidos (por recuento) son tragos de alcohol. Esto no coincide con la visión de la marca de la empresa o el caso de uso deseado por el cliente. La mayoría de los sistemas de correo electrónico permiten una capa adicional de lógica: el asociado de CRM usa su juicio para filtrar cualquier elemento con un volumen de 50 ml o menos.

Nota: Las perspectivas y los casos de uso han dejado el dominio del equipo de datos y de la empresa. Los resultados del equipo de datos ahora están orientados al cliente. Un error tiene mayores consecuencias, es menos probable que la retroalimentación se entregue correctamente a la parte interesada correcta. Se ha agregado lógica comercial adicional (a través de la transformación de última milla en la capa de CRM).

4. Uso externo (Aplicación de Producción)

El equipo de datos escucha al equipo de AM y CRM: algunas licorerías son bastante antiguas y no revisan el correo electrónico. Otras tiendas de licores son la nueva escuela y no quieren esperar una semana entera para recibir un correo electrónico sobre las tendencias en su mercado. El grupo decide vincular al equipo de aplicaciones minoristas para colocar los "Artículos principales que no lleva" en la aplicación de producción en la que se ejecutan todos los minoristas. El equipo de datos mueve su salida a un depósito de AWS S3, donde la ingeniería de producción la recoge. Los empleados de la tienda de licores ahora pueden ver esta lista todos los días, sin necesidad de un administrador de cuentas o fricción por correo electrónico. White Claw y Whispering Angel llegan a todas las tiendas de Estados Unidos.

…un minorista presenta una queja al minorista CX: deliberadamente dejaron de almacenar Smirnoff Peppermint Vodka después de las vacaciones. Literalmente, podría ser uno de los artículos más vendidos de L90, pero es extremadamente estacional y no quieren verlo en su lista recomendada. Esta retroalimentación llega al equipo de ingeniería de producción, ese equipo realiza un ajuste lógico en la capa de aplicación para identificar y eliminar artículos de temporada anteriores.

Nota: Las perspectivas y los casos de uso han dejado el dominio del equipo de datos y de la empresa. Los resultados del equipo de datos están orientados al cliente. Un error tiene mayores consecuencias, es menos probable que se entregue la retroalimentación a la parte interesada correcta. Se ha agregado lógica adicional (a través de la lógica comercial en la capa de aplicación de producción).

Una última hipótesis: el equipo de ingeniería a cargo de consumir fuentes de inventario (diferente del equipo a cargo de la aplicación minorista) migra a un nuevo esquema de inventario. No están al tanto de un solo paso del proyecto "Los elementos principales que no llevas", las dependencias que el equipo de datos ha creado en silencio sobre su trabajo o las dependencias que otros han creado sobre el trabajo del equipo de datos. Eliminan la tabla inicial. NULLLos correos electrónicos fluyen hacia Looker, Salesforce, Hubspot y la aplicación de producción minorista. El equipo de datos ha roto prod.

Recapitulemos lo que sucedió, tanto bueno como malo:

Desde la perspectiva de un profesional de datos que comenzó su carrera antes de la "activación de datos", ¡todo lo que acaba de suceder (excepto el final) es increíble! Lo que comenzó como un tablero de Looker se convirtió rápidamente en una aplicación de producción, con valor comercial demostrado en cada paso. No se necesitaron recursos de SWE hasta el final, cuando los usuarios ya habían validado el producto sugerido.

El impacto y la trayectoria profesional de un profesional de datos están limitados por el área de superficie en la que pueden influir. El analista de inteligencia de negocios de 2012 se coronó en presentaciones internas de Tableau +. El profesional de datos de hoy PUEDE colocar filas en Salesforce, activar correos electrónicos de marketing y crear productos de datos para consumo en aplicaciones y servicios de producción. ¡Esta es una noticia increíble!

En el lado malo: el profesional de datos de hace diez años estaba acostumbrado a los mensajes "Oye, los datos se ven mal". El peor de los casos fue poner métricas incorrectas en una plataforma de tablero. Hoy, el equipo de datos puede despertarse con las notificaciones de Pagerduty de que han roto Salesforce, Hubspot y la aplicación de producción, incluso si Pagerduty está configurado . La activación de datos ha elevado las apuestas de lo que un equipo de datos puede romper.

En este caso hipotético, los gerentes de tiendas y cuentas estarán molestos durante uno o dos días hasta que se solucione el error. A fin de cuentas, este error es relativamente gratuito.

¡Eso no significa que no pueda ser costoso! Imagine un resultado de ciencia de datos que predice la rotación de clientes y se envía un código de promoción de $ 5 cuando esa probabilidad cruza un cierto umbral. Ahora, imagine que el modelo está mal entrenado o recalibrado, o realmente cualquier cosa. Los mismos canales de activación de datos pueden usarse para enviar inadvertidamente millones de dólares en códigos promocionales.

La pila de datos moderna hace que sea increíblemente fácil producir salidas de datos, independientemente de si se deben producir o si el equipo que creó las entradas sabe cómo se consumen las salidas. Estas herramientas no requieren que se refuercen la canalización o la consulta inicial, ya que se elevan a casos de uso más importantes. No requieren el consentimiento o la visibilidad de quienes construyeron el resultado inicial.

Si recuerda la lógica comercial adicional:

• El gerente de cuenta usó su criterio y no recomendó SKU de licor a las tiendas de cerveza/vino.
• El asociado de CRM eliminó SKU <= 50 ml debido a consideraciones de marca
• El equipo de aplicaciones del minorista eliminó los SKU altamente estacionales debido a los comentarios de los clientes.

Entonces, ¿qué podemos hacer para solucionar estos problemas?

Los sistemas tienden a la producción

Las historias de terror, los problemas generalizados y las soluciones técnicas para los sistemas de producción se han escrito con elocuencia a través de data twitter y substack. Las soluciones son, en gran medida, las mejores prácticas que SWE ha conocido durante décadas (o, como dijo Zach Kanter de otra manera , la ingeniería de datos del status quo es solo ingeniería de software sin mejores prácticas ). Algunas de las piezas/principios que mejor me han quedado para los equipos de datos:

Los equipos de datos no controlan sus entradas (h/t Nick Schrock )

Los datos de salida son la base de muchas decisiones en las organizaciones, sin importar si el responsable es un ser humano o un algoritmo. Sin embargo, los equipos de datos no controlan sus entradas como lo hacen los ingenieros de software. Los equipos de datos deben estar a la defensiva en sus cálculos invirtiendo en control de calidad; tanto para problemas pasados ​​como para problemas que aún no han ocurrido. Esta prueba debe incluir:

• Validez de filas individuales ( intcuando espera un int, <50 cuando espera <50)
• Validez de las filas agregadas (supuestos de granularidad, contexto comercial en torno a los recuentos de filas, recuentos de filas en relación con ayer, distribuciones de agregaciones como sumas, promedios, p90, medianas)
• Existencia/obsolescencia de los datos (última vez que se actualizaron las tablas)

El costo de un error es exponencialmente más alto en un sistema de producción que en una puesta en escena. Cree canalizaciones de prueba de datos y patrones de desarrollo e implementación que detecten errores y prueben suposiciones lo antes posible.

Estas son soluciones que pueden implementar los equipos de datos que eligen las herramientas adecuadas (nos gusta Great Expectations ) y se esfuerzan. Eso es el 20% del problema. El 80% restante de los desafíos organizacionales y de comunicación son los que hacen que los sistemas se rompan. Estas son las soluciones para toda la empresa:

Crear escapes de datos de grado de producción

O bien, crear datos deliberadamente . Las empresas que creen que la ciencia de datos es poderosa también deberían creer en la creación deliberada de datos de producción para potenciar el aprendizaje automático y los casos de uso de análisis avanzados (h/t Yali Sasoon). Esto requiere asociarse con ingenieros y una alineación de toda la empresa para que los datos se puedan crear deliberadamente, no extraer dolorosamente.

Crear y celebrar un camino hacia la producción

Con demasiada frecuencia, las empresas celebran iteraciones rápidas en un entorno de desarrollo sin obtener la orientación o el tiempo para fortalecer ese trabajo hacia el grado de producción. Celebre este trabajo y obtenga tiempo y propiedad multifuncionales explícitos para fortalecer los sistemas.

Los sistemas tienden hacia la federación ciega

Nuevamente, ¡celebremos este problema! Si muchas personas encuentran diferentes casos de uso comercial para los resultados del equipo de datos, está haciendo algo bien. Pero, de la misma manera que un tablero ad-hoc podría convertirse en una plataforma de tablero hace 10 años, esa consulta ad-hoc puede convertirse en una aplicación de producción sin que usted lo sepa.

Aproveche un solo plano de control para la orquestación basada en eventos

Fivetran, dbt y Hightouch tienen la capacidad de programar trabajos a través de programaciones cron y la interfaz de usuario. Esto permite que la orquestación se construya de maneras que no muestren la visibilidad de las dependencias implícitas. Imagine que Hightouch está programado para moverse exp_fb_click_idstodos los días a las 8 a. m. a través de la interfaz de usuario. Fivetran y dbt no tienen visibilidad de esa dependencia, ni tampoco aquellos que contribuyen a las bases de código aguas arriba de Hightouch.

En su lugar, utilice una herramienta de orquestación (Dagster/Prefect/Airflow) como único plano de control. Combine las dependencias entre las herramientas y cree un DAG holístico que se ejecute en función de los éxitos de los pasos anteriores en lugar de esperar que las tareas ascendentes tengan éxito en un momento determinado del día. reagrupar _

Cree asignaciones uno a uno de las exportaciones del equipo de datos a casos de uso posteriores

Los equipos de datos deben estar familiarizados con la forma en que dbt sugiere estructurar proyectos . Por lo general, la capa de ensayo se organiza y nombra de una manera que hace que la relación de uno a uno con las entradas de origen sea extremadamente clara. Use un patrón similar para las salidas. En la misma medida en que debería ser obvio que el objeto Oportunidad y Cuenta de Salesforce representan una tabla dbt en preparación, debería ser obvio que las exportaciones de datos se utilizan para un único caso de uso.

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.opportunity
;

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.account
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_retailer_app
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_salesfrce
;

En lugar de resumir la layerinitis, lo dirigiré nuevamente al maravilloso hilo y definición de Jean-Michel Lemieux. El consejo general es suyo, con algunos datos específicos que me han funcionado.

La definición técnica de la estratinitis es que los equipos pongan el código donde se sientan más cómodos mientras optimizan la velocidad frente a poner el código donde pertenece al considerar una perspectiva a más largo plazo del sistema de software en general.

Reduzca las áreas donde se puede inyectar la lógica empresarial en la última milla:

Hightouch y Census permiten transformaciones de SQL. Fivetran solía . La mayoría de los consumidores de activación de datos (Sales/CX CRM, CDP) permiten una capa de lógica empresarial SQL o de código bajo/sin código. Siempre que sea posible, no escriba lógica empresarial en estas herramientas. Si sigue el mapeo uno a uno de las exportaciones del equipo de datos a los casos de uso posteriores, su ETL inverso siempre puede ser:

select * from exp_table_for_single_use_case;

Los cambios en la lógica empresarial deben aplicarse a ese modelo dbt, en lugar de en la última milla.

Cree políticas de "Tiempo de vida" en transformaciones de última milla:

Un equipo de datos no puede deshacerse por completo de las transformaciones de última milla. No desea que sus partes interesadas se sientan bloqueadas por el equipo de datos. Siempre será necesario introducir correcciones urgentes o iterar en la lógica empresarial que sea más rápida que una actualización de dbt PR + Snowflake.

En términos más generales, las partes interesadas de su negocio tienen un contexto que usted no tiene. Quiere ver cómo están cambiando sus datos. Piense en el SKU estacional, el volumen y la lógica de categorización de tiendas que el ingeniero de análisis pasó por alto. ¡Cree un mundo donde las partes interesadas de su negocio puedan mejorar su trabajo!

Una política de "Tiempo de vida" es un retroceso gravitatorio hacia la centralización. Permita transformaciones de última milla, pero revíselas y vuelva a llevar la lógica empresarial a una capa central de ciencia de datos/dbt a una cadencia que funcione para su equipo de datos y las partes interesadas de la empresa.

Cree una cultura de estandarización y celebración del acceso a bases de códigos interfuncionales

Por defecto, las personas escriben la lógica empresarial en la herramienta con la que se sienten más cómodos. Para un asociado de CRM, podría ser Hubspot/Iterable/Braze. La mejor manera para que los equipos de datos eviten la lógica comercial en expansión no es solo limitar las transformaciones de última milla en otras herramientas, sino también invitar a otros a usar sus herramientas.

Esta puede ser una toma ️️️. Hay muchas razones para preocuparse por los miembros del equipo que no son de datos que escriben lógica en SQL y hacen PR de dbt. Lo que puedo garantizar: esta lógica se escribirá, y si el equipo de datos se mantiene, se escribirá fuera de su visibilidad. Si un equipo de datos puede educar y alentar las contribuciones a su base de código, invitan a escribir el código donde más pertenece.

Aterrizando el avión:

Es un buen momento para ser un líder de datos. La última década de desarrollo del ecosistema de datos ha mercantilizado el movimiento y la manipulación de datos a través de herramientas propias y de terceros. Un profesional de análisis talentoso con un sueño y una tarjeta de crédito puede potenciar los informes internos, las herramientas internas, las automatizaciones de marketing y las aplicaciones de producción. Esta es una noticia objetivamente increíble para las empresas y los profesionales de datos.

• La pila de datos moderna permite que un equipo de datos produzca cualquier cosa, independientemente de si debería hacerlo, y sin permiso ni visibilidad de ingeniería de producción.
• La pila de datos moderna permite que una parte interesada del negocio agregue la lógica comercial de última milla para potenciar los flujos de trabajo de producción, independientemente de si deberían hacerlo, y sin el permiso o la visibilidad del equipo de datos.

En algún momento, sus productos de datos romperán la aplicación de producción. Se enviarán correos electrónicos de marketing que no deberían haber sido. El equipo de CRM culpará al equipo de datos, el equipo de datos culpará al equipo de ingeniería de producción. Una de las lecciones más importantes que he aprendido, pero con la que todavía lucho a diario: la capacidad de entrar en una habitación tensa/Zoom y recordarles a todos que todos estamos en el mismo equipo es un superpoder. Ese es el verdadero resumen de cómo poner en producción los sistemas de datos.

Si puedes crear una cultura donde:

• Los ingenieros de producción crean el escape de datos con intención y entusiasmo por cómo se utilizarán los datos.
• Los miembros del equipo de datos buscan casos de uso, solicitan comentarios y preguntan a sus partes interesadas: "Oye, ¿qué haces realmente con los datos que te envío?"
• Los SWE pueden asesorar y mejorar las mejores prácticas y estándares del equipo de datos para elevar los flujos de datos ad-hoc al grado de producción.
• Los miembros del equipo de datos pueden asesorar y mejorar a las partes interesadas del negocio sobre cómo agregar lógica comercial, marcos para el lugar al que pertenece la lógica.
• Cada equipo invita a otros a sus bases de código y fomenta una perspectiva a largo plazo sobre la arquitectura general de la empresa.

Ian Macomber es el Jefe de Ingeniería de Análisis y Ciencia de Datos en Ramp, la primera y única tarjeta corporativa que ayuda a las empresas a gastar menos. Anteriormente, fue vicepresidente de análisis e ingeniería de datos en Drizly.

¡También hay una cuarta tendencia! Estén atentos a Data Systems Tend Towards Calculation , que fue demasiado para caber en un artículo.