Olá Habr! Nós da Dodo Pizza Engineering realmente amamos os dados (e quem não gosta deles agora?). Agora haverá uma história sobre como acumular todos os dados do mundo Dodo Pizza e dar a qualquer funcionário da empresa acesso conveniente a esse conjunto de dados. Desafio sob o asterisco: salve os nervos da equipe de engenharia de dados.
Como Plyushkins reais, salvamos todos os tipos de informações sobre o trabalho de nossas pizzarias:
- lembre-se de todos os pedidos dos usuários;
- sabemos quanto tempo levou para fazer a primeira pizza em Syktyvkar;
- Vemos quanto tempo a pizza esfria na prateleira de calor em Voronezh agora;
- armazenar dados em baixas de produtos;
- e muito, muito mais.
Atualmente, várias equipes são responsáveis por trabalhar com dados na Dodo Pizza, uma delas é a equipe de engenharia de dados. Agora eles (isto é, nós) têm uma tarefa: dar a qualquer funcionário da empresa acesso conveniente a esse conjunto de dados.
Quando começamos a pensar em como fazer isso e começamos a discutir o problema, encontramos uma abordagem muito interessante para o gerenciamento de dados - Data Mesh (você encontrará um enorme artigo chique aqui). Suas idéias se encaixaram muito bem em nossa idéia de como queremos construir nosso sistema. O restante do artigo será repensar a abordagem e como a vemos sendo implementada na Dodo Pizza Engineering.
O que queremos dizer com "dados"
Para começar, vamos decidir o que queremos dizer com dados na Dodo Pizza Engineering:
- Eventos que enviam serviços (temos um barramento comum construído usando o RabbitMQ);
- Registros dentro do banco de dados (para nós, MySQL e CosmosDB);
- Clique em um aplicativo e site para celular.
Para que o negócio da Dodo Pizza use e conte com esses dados, é importante que as seguintes condições sejam atendidas:
- Eles devem ser holísticos. Devemos ter certeza de que não alteramos os dados no processo de processamento, armazenamento e exibição. Se uma empresa não puder confiar em nossos dados, ela não será útil.
- Eles devem ser marcados com hora e não substituídos. Isso significa que, a qualquer momento, queremos poder reverter os dados desse período. Por exemplo, descubra quantas pizzas foram vendidas em 8 de julho de 2018.
- Eles devem ser confiáveis. No processo de coleta e armazenamento de dados, devemos não apenas perder a integridade, mas também a confiabilidade. Não podemos perder dados, intervalos de tempo, porque, juntamente com eles, perdemos a confiança de nossos clientes (externos e internos).
- Eles devem estar com um esquema estável - escrevemos solicitações para esses dados. Nós realmente não queremos que eles mudem tanto com a alteração do código do aplicativo, com a refatoração, que nossos pedidos param de funcionar. Quem escreve os pedidos nunca saberá que você fez a refatoração até que tudo quebre. Eu não gostaria de saber sobre isso dos clientes.
Dados todos esses requisitos, chegamos à conclusão de que os dados no Dodo são um produto. O mesmo que API de serviço público. Dessa forma, a mesma equipe proprietária do serviço deve possuir os dados. Além disso, as alterações no esquema de dados devem sempre ser compatíveis com versões anteriores.
Abordagem Tradicional - Data Lake
Para resolver os problemas de armazenamento e processamento confiáveis de big data, existe uma abordagem tradicional adotada por muitas empresas que trabalham com esse pool de informações - o Data Lake. Como parte dessa abordagem, os engenheiros de dados coletam informações de todos os componentes do sistema e as colocam em um grande armazenamento (pode ser, por exemplo, Hadoop, Azure Kusto, Apache Cassandra ou até mesmo uma réplica do MySQL se os dados forem quebrados).
Além disso, esses mesmos engenheiros escrevem solicitações para esse armazenamento. A implementação dessa abordagem na Dodo Pizza Engineering implica que a equipe de Engenharia de Dados possua o esquema de dados no repositório analítico.
Nesse cenário, a equipe se torna gatos muito tristes e é por isso:
- Ela deve monitorar as alterações em TODOS os serviços da empresa. E existem muitas delas e muitas alterações (em média, mesclamos ~ 100 solicitações pull por semana, enquanto muitos serviços não fazem solicitações pull).
- Ao alterar o esquema de dados, o gerente de produto e a equipe que alteram o esquema de dados devem esperar até que a Engenharia de Dados complete o código necessário para que as alterações sejam suportadas. Além disso, há muito tempo nos destacamos e a situação em que uma equipe está esperando por outra é muito rara. E não queremos que isso se torne uma parte "normal" do processo de desenvolvimento.
- Ela deve estar imersa em todo o negócio da empresa. Uma cadeia de pizzarias parece um negócio simples, mas apenas parece. É muito difícil reunir competências suficientes em uma equipe para criar um modelo de dados adequado para toda a empresa.
- É um único ponto de falha. Cada vez que você precisa alterar os dados que o serviço retorna ou gravar uma consulta, todas essas tarefas caem para a equipe de Engenharia de Dados. Como resultado, a equipe tem uma lista de pendências sobrecarregada.
Acontece que a equipe está no cruzamento de um grande número de necessidades e é improvável que seja capaz de satisfazê-las. Ao mesmo tempo, estará em constante pressão e estresse de tempo. Nós realmente não queremos isso. Portanto, você precisa pensar em como resolver esses problemas e, ao mesmo tempo, ter a oportunidade de analisar os dados.
Fluindo do Data Lake para o Data Mesh
Felizmente, não apenas nos perguntamos essa questão. De fato, um problema semelhante já foi resolvido na indústria (aleluia!). Somente em outra área: implantação de aplicativos. Sim, estou falando da abordagem do DevOps, em que a equipe determina como implantar o produto que eles criaram.
Uma abordagem semelhante à solução de problemas do Data Lake foi sugerida por Zhamak Dehghani, consultor da ThoughtWorks. Observando a Netflix e o Spotify resolverem esses problemas, ela escreveu um artigo incrível sobre Como ir além de um lago de dados monolítico para uma malha de dados distribuídos (o link para ele estava no início do artigo). As principais idéias que tiramos dela para nós mesmos:
- Divida o Data Lake grande em domínios de dados muito semelhantes aos domínios de design controlados por domínio. Cada domínio é um pequeno contexto delimitado.
- A equipe de recursos, responsável pelos domínios DDD, também é responsável pelos domínios de dados correspondentes. Eles armazenam o circuito, fazem alterações, carregam dados nele. Ao mesmo tempo, eles mesmos sabem tudo: como alterar o carregamento de dados e não quebrar nada quando o aplicativo é alterado. O conhecimento não vai a lugar nenhum. Para abrir os dados, eles não precisam ir a lugar algum. A própria equipe conduz um ciclo de desenvolvimento completo, desde a alteração de dados operacionais até o fornecimento de dados analíticos a terceiros. Uma equipe possui tudo o que está associado ao domínio (o domínio comercial e o domínio de dados).
- Engenheiro de dados - uma função dentro da equipe de recursos. Isso não precisa ser um indivíduo, mas é imperativo que a equipe possua essa competência.
Enquanto isso, a equipe de engenharia de dados ...
Se você imagina que tudo isso é realizado com o clique de um dedo, resta responder a duas perguntas:
O que a equipe de Engenharia de Dados fará agora? A Dodo Pizza Engineering já possui uma equipe de plataforma / SRE. Sua tarefa é fornecer ferramentas aos desenvolvedores para facilitar a implantação de serviços. A equipe de engenharia de dados executará a mesma função apenas para dados.
Transformar dados operacionais em dados analíticos é um processo complexo. Tornar a análise disponível para toda a empresa é ainda mais difícil. É a solução para esses problemas que a equipe de engenharia de dados tratará.
Vamos fornecer à equipe de recursos um conjunto conveniente de ferramentas e práticas com as quais eles podem publicar dados de seus serviços para o resto da empresa. Também seremos responsáveis pelas partes gerais da infraestrutura do pipeline de dados (filas, armazenamento confiável, clusters para realizar transformações nos dados).
Como as habilidades de engenheiro de dados aparecerão na equipe de recursos? A equipe de recursos está ficando mais difícil. Obviamente, poderíamos tentar contratar um engenheiro de dados em cada uma de nossas equipes. Mas é muito difícil. É difícil encontrar uma pessoa com boa experiência em processamento de dados e convencê-la a trabalhar dentro de uma equipe de compras.
A grande vantagem do Dodo é que amamos o aprendizado interno. Portanto, agora o nosso plano é este: a equipe de Engenharia de Dados começa a publicar os dados de alguns serviços, gritos, picadas, mas continua a comer o cacto. Assim que entendemos que temos um processo pronto para publicação, começamos a falar sobre isso na equipe de recursos.
Temos várias maneiras de fazer isso:
- DevForum , no qual informaremos como é o processo que criamos, quais ferramentas existem e como usá-las com mais eficiência.
- Falar na DevForum nos ajudará a obter feedback dos desenvolvedores do produto. Depois disso, poderemos unir equipes de produtos e ajudá-los a resolver problemas com a publicação de dados, organizar o treinamento para equipes.
Consumo de dados
Agora eu falei muito sobre a publicação de dados. Mas também há consumo. E esse problema?
Temos uma equipe de BI maravilhosa que escreve relatórios muito complexos para uma empresa de gerenciamento. Dentro do Dodo IS, existem muitos relatórios para nossos parceiros que os ajudam a gerenciar pizzarias. Em nosso novo modelo, pensamos neles como consumidores de dados que possuem seus próprios domínios de dados. E são os consumidores que serão responsáveis por seus próprios domínios. Às vezes, um domínio do consumidor pode ser descrito com uma única solicitação ao repositório analítico - e isso é bom. Mas entendemos que isso nem sempre funcionará. É por isso que queremos que a plataforma que criaremos para as equipes de produtos também sejam usadas pelos consumidores de dados (porque, no caso de relatórios dentro do Dodo IS, serão apenas equipes).
É assim que vemos o trabalho com dados na Dodo Pizza Engineering. Temos o prazer de ler seus pensamentos sobre isso nos comentários.