Hola Habr! En Dodo Pizza Engineering realmente amamos los datos (¿y a quién no le gustan ahora?). Ahora habrá una historia sobre cómo acumular todos los datos del mundo de Dodo Pizza y dar a cualquier empleado de la empresa un acceso conveniente a esta matriz de datos. Desafío bajo el asterisco: salva los nervios del equipo de Ingeniería de Datos.
Al igual que los Plyushkins reales, guardamos todo tipo de información sobre el trabajo de nuestras pizzerías:
- recuerda todos los pedidos de los usuarios;
- sabemos cuánto tiempo llevó hacer la primera pizza en Syktyvkar;
- Vemos cuánto tiempo se enfría la pizza en el estante de calor en Voronezh en este momento;
- almacenar datos sobre cancelaciones de productos;
- y mucho, mucho más
Actualmente, varios equipos son responsables de trabajar con datos en Dodo Pizza, uno de ellos es el equipo de Ingeniería de Datos. Ahora ellos (es decir, nosotros) tienen una tarea: dar a cualquier empleado de la compañía un acceso conveniente a esta matriz de datos.
Cuando comenzamos a pensar en cómo hacer esto y comenzamos a discutir el problema, encontramos un enfoque muy interesante para la gestión de datos: Data Mesh (aquí encontrará un artículo elegante y elegante). Sus ideas cayeron muy bien en nuestra idea de cómo queremos construir nuestro sistema. El resto del artículo será nuestro replanteamiento del enfoque y de cómo lo vemos implementado en Dodo Pizza Engineering.
¿Qué queremos decir con "datos"?
Para comenzar, decidamos qué queremos decir con los datos en Dodo Pizza Engineering:
- Eventos que envían servicios (tenemos un bus común construido usando RabbitMQ);
- Registros dentro de la base de datos (para nosotros, esto es MySQL y CosmosDB);
- Clickstream desde una aplicación móvil y un sitio web.
Para que el negocio de Dodo Pizza use y confíe en estos datos, es importante que se cumplan las siguientes condiciones:
- Deben ser holísticos. Debemos estar seguros de que no cambiamos los datos en el proceso de su procesamiento, almacenamiento y visualización. Si una empresa no puede confiar en nuestros datos, entonces no serán de ninguna utilidad.
- Deben tener una marca de tiempo y no sobrescribirse. Esto significa que en cualquier momento queremos poder retroceder y mirar los datos de ese período de tiempo. Por ejemplo, averigüe cuántas pizzas se vendieron el 8 de julio de 2018.
- Deben ser confiables. En el proceso de recopilación y almacenamiento de datos, no solo debemos perder integridad, sino también confiabilidad. No podemos perder datos, segmentos de tiempo, porque junto con ellos perdemos la confianza de nuestros clientes (tanto externos como internos).
- Deben estar con un esquema estable: escribimos solicitudes para estos datos. Realmente no queremos que cambien tanto con el cambio del código de la aplicación, con la refactorización, que nuestras solicitudes dejen de funcionar. El que escribe las solicitudes nunca sabrá que realizó la refactorización hasta que todo se rompa. No quisiera saber esto de los clientes.
Dados todos estos requisitos, llegamos a la conclusión de que los datos en Dodo son un producto. Igual que la API de servicio público. En consecuencia, el mismo equipo propietario del servicio debe ser el propietario de los datos. Además, los cambios en el esquema de datos siempre deben ser compatibles con versiones anteriores.
Enfoque tradicional - Data Lake
Para resolver los problemas de almacenamiento y procesamiento confiables de big data, muchas empresas que trabajan con dicho grupo de información adoptan un enfoque tradicional: Data Lake. En el marco de este enfoque, los ingenieros de datos recopilan información de todos los componentes del sistema y los colocan en un gran almacenamiento (esto puede ser, por ejemplo, Hadoop, Azure Kusto, Apache Cassandra o incluso una réplica MySQL, si los datos entran en él).
Además, estos mismos ingenieros escriben solicitudes a dicho almacenamiento. La implementación de este enfoque en Dodo Pizza Engineering implica que el equipo de Ingeniería de Datos será el propietario del esquema de datos en el repositorio analítico.
Con este escenario, el equipo se convierte en gatos muy tristes y por eso:
- Ella debe monitorear los cambios en TODOS los servicios dentro de la empresa. Y hay muchos de ellos y hay muchos cambios (en promedio combinamos ~ 100 solicitudes de extracción por semana, mientras que muchos servicios no hacen solicitudes de extracción).
- Al cambiar el esquema de datos, el gerente de producto y el equipo que cambia el esquema de datos deben esperar hasta que Data Engineering complete el código necesario para que los cambios sean compatibles. Además, hemos sido destacados durante mucho tiempo y la situación en la que un equipo espera a otro es muy rara. Y no queremos que esto se convierta en una parte "normal" del proceso de desarrollo.
- Ella debe estar inmersa en todo el negocio de la empresa. Una cadena de pizzerías parece un negocio simple, pero parece. Es muy difícil reunir suficientes competencias en un equipo para construir un modelo de datos adecuado para toda la empresa.
- Es un solo punto de falla. Cada vez que necesite cambiar los datos que devuelve el servicio o escribir una consulta, todas estas tareas recaen en el equipo de Ingeniería de Datos. Como resultado, el equipo tiene una cartera de pedidos sobrecargada.
Resulta que el equipo está en la intersección de una gran cantidad de necesidades y es poco probable que pueda satisfacerlas. Al mismo tiempo, estará en constante presión y estrés. Realmente no queremos esto. Por lo tanto, debe pensar cómo resolver estos problemas y al mismo tiempo tener la oportunidad de analizar los datos.
Fluyendo de Data Lake a Data Mesh
Afortunadamente, no solo nos hicimos esta pregunta. De hecho, un problema similar ya se ha resuelto en la industria (¡aleluya!). Solo en otra área: implementación de aplicaciones. Sí, estoy hablando del enfoque DevOps, donde el equipo determina cómo implementar el producto que crean.
Zhamak Dehghani, consultor de ThoughtWorks, sugirió un enfoque similar para la resolución de problemas de Data Lake. Al ver que Netflix y Spotify resuelven tales problemas, ella escribió un artículo increíble sobre Cómo moverse más allá de un lago de datos monolítico a una malla de datos distribuidos (el enlace al principio del artículo). Las ideas principales que sacamos para nosotros mismos:
- Divida el gran lago de datos en dominios de datos que son muy similares a los dominios de diseño basados en dominio. Cada dominio es un pequeño contexto acotado.
- El equipo de funciones, que es responsable de los dominios DDD, también es responsable de los dominios de datos correspondientes. Almacenan el circuito, le hacen cambios, cargan datos en él. Al mismo tiempo, ellos mismos lo saben todo: cómo cambiar la carga de datos y no romper nada cuando la aplicación cambia. El conocimiento no va a ninguna parte. Para abrir los datos, no tienen que ir a ningún lado. El equipo mismo lleva a cabo un ciclo de desarrollo completo desde el cambio de datos operativos hasta el suministro de datos analíticos a terceros. Un equipo posee todo lo relacionado con el dominio (tanto el dominio empresarial como el dominio de datos).
- Ingeniero de datos: un rol dentro del equipo de funciones. Esto no tiene que ser un individuo, pero es imprescindible que el equipo posea esta competencia.
Mientras tanto, el equipo de Ingeniería de Datos ...
Si imagina que todo esto se realiza con el clic de un dedo, queda por responder dos preguntas:
¿Qué hará el equipo de ingeniería de datos ahora? Dodo Pizza Engineering ya tiene un equipo de plataforma / SRE. Su tarea es proporcionar a los desarrolladores herramientas para una fácil implementación de servicios. El equipo de ingeniería de datos desempeñará la misma función solo para datos.
Convertir los datos operativos en datos analíticos es un proceso complejo. Hacer que los análisis estén disponibles para toda la empresa es aún más difícil. Es la solución a estos problemas con la que se ocupará el equipo de Ingeniería de Datos.
Vamos a proporcionar a Feature Team un conjunto conveniente de herramientas y prácticas con las que pueden publicar datos de su servicio para el resto de la empresa. También seremos responsables de las partes de infraestructura general de la tubería de datos (colas, almacenamiento confiable, clústeres para realizar transformaciones en los datos).
¿Cómo aparecerán las habilidades del ingeniero de datos dentro del equipo de funciones? El equipo de funciones se está volviendo más difícil. Por supuesto, podríamos intentar contratar un ingeniero de datos en cada uno de nuestros equipos. Pero es muy dificil. Encontrar una persona con una buena experiencia en el procesamiento de datos y convencerlo para que trabaje dentro de un equipo de abarrotes es difícil.
La gran ventaja de Dodo es que amamos el aprendizaje interno. Entonces, nuestro plan es este: el equipo de Ingeniería de Datos comienza a publicar los datos de algunos servicios, gritos, pinchazos, pero continúa comiendo el cactus. Tan pronto como entendemos que tenemos un proceso listo para su publicación, comenzamos a hablar de ello en Feature Team.
Tenemos varias formas de hacer esto:
- DevForum , en el que le diremos cómo es el proceso que creamos, qué herramientas hay y cómo usarlas de manera más efectiva.
- Hablar en DevForum nos ayudará a recopilar comentarios de los desarrolladores de productos. Después de eso, podremos unirnos a equipos de productos y ayudarlos a resolver problemas con la publicación de datos, organizar la capacitación para equipos.
Consumo de datos
Ahora hablé mucho sobre la publicación de datos. Pero también hay consumo. ¿Qué hay de este problema?
Tenemos un maravilloso equipo de BI que escribe informes muy complejos para una empresa de gestión. Dentro de Dodo IS, hay muchos informes para nuestros socios que los ayudan a administrar pizzerías. En nuestro nuevo modelo, los consideramos consumidores de datos que tienen sus propios dominios de datos. Y son los consumidores los responsables de sus propios dominios. A veces, un dominio de consumidor se puede describir con una sola solicitud al repositorio analítico, y esto es bueno. Pero entendemos que esto no siempre funcionará. Es por eso que queremos que la plataforma que crearemos para los equipos de productos también sea utilizada por los consumidores de datos (en el caso de los informes dentro de Dodo IS, estos serán solo equipos).
Así es como vemos trabajar con datos en Dodo Pizza Engineering. Nos complace leer su opinión sobre esto en los comentarios.