Get best of the week

Data Engineer or die: uma única história de desenvolvedor

No início de dezembro, cometi um erro fatal, tomei uma decisão crucial em minha vida como desenvolvedor e fui transferido para a equipe de Engenharia de Dados (DE) dentro da empresa. No artigo, compartilharei algumas das observações que fiz durante dois meses de trabalho na equipe de DE.




Por que engenharia de dados?


Minha jornada para a DE começou no verão de 2019, quando Xnegdirigi para a Escola de Computação Distribuída , e lá cheguei à iluminação. Comecei a me interessar pelo tópico, a estudar algoritmos e até a escrever sobre eles . Depois, pensei no campo de aplicação e descobri rapidamente que o aplicativo prático em nossa empresa é distribuído por bancos de dados.

O que nossa equipe faz em geral? Nós, como todos os meninos e meninas da moda, queremos nos tornar uma empresa orientada a dados. E, para tornar isso possível, precisamos criar pelo menos um repositório confiável, no qual será possível criar quaisquer relatórios exigidos pela empresa. Mas o mais importante é que os dados nesse armazenamento devem ser confiáveis. Além disso, de acordo com esses dados, é necessário poder restaurar o estado do sistema no momento t. Tudo isso é complicado pelo fato de vivermos em um admirável mundo novo de microsserviços, e essa ideologia implica que cada serviço implementa sua pequena funcionalidade, seu banco de dados é seu próprio negócio e pode excluí-lo pelo menos todos os dias, mas ao mesmo tempo, devemos Ser capaz de receber e processar o status do serviço.

Deseja ser orientado a dados, torne-se primeiro orientado a eventos


Não tão simples. Os eventos são diferentes, e o desenvolvedor e o engenheiro de data os encaram de maneira diferente. A conversa sobre eventos é o tópico de um artigo separado, portanto, aqui não vou entrar nele. Além disso, alguém que Martin Fowler já escreveu esse artigo , não vou tirar os louros dele, nem deixá-lo famoso também.

Em geral, há algo em que pensar e a área é atraente. Aconteceu que, em nossa empresa, o Data Engineer é uma área de responsabilidade muito mais ampla do que apenas uma pessoa que escreve pipelines ETL / ELT (se você não sabe o que essas abreviações significam - venha a mitap . Como um anúncio contextual ).

Estamos envolvidos na arquitetura de construção de um armazém, modelagem de dados e problemas relacionados à segurança de dados e aos próprios pipelines, é claro. E precisamos garantir que, por um lado, os desenvolvedores de produtos não sejam muito onerosos com a nossa presença e precisem se distrair o menos possível com nossos requisitos ao verem novos recursos no sistema e, por outro lado, precisamos fornecer dados armazenados convenientemente. dados para analistas e equipes de BI. É assim que vivemos.

Dificuldades em mudar do desenvolvimento


No primeiro dia do meu trabalho, encontrei uma série de dificuldades que quero compartilhar com você.

1. A primeira coisa que vi foi a falta de ajuste e algumas práticas. Tome, por exemplo, cobertura de código com testes. No desenvolvimento, temos centenas de estruturas para teste. Ao trabalhar com dados, tudo é mais complicado. Sim, podemos testar os pipelines ETL com dados de teste, mas precisamos fazer tudo isso com nossas próprias mãos e procurar soluções para cada caso específico. Como resultado, a cobertura do teste é muito pior. Felizmente, há outra camada de feedback na forma de monitoramento e logs, mas isso já exige que reagamos em vez de proativos, o que nos enfurece .

2. O mundo da posição de DE não é exatamente o que parece para um desenvolvedor de produtos comum (bem, é claro, o leitor não é assim, e ele já sabe tudo, mas eu não sabia e agora ele está ajuntando). Como desenvolvedor, vi meu microsserviço, coloquei os dados em [banco de dados de sua escolha], salvei meu estado lá, obtive algo por ID e é normal. O serviço está girando, os pedidos estão confusos, só isso. Eles me pedem em outro serviço para atrapalhar meu estado, bem, eu vou lançar um evento em algum RabbitMQ e é isso. E aqui voltamos novamente à questão dos eventos descritos acima.

O que o serviço precisa para o trabalho operacional não é adequado para dados históricos; a questão de processar contratos de serviço e trabalhar em estreita colaboração com as equipes de desenvolvimento começa. Você nem imagina quantas horas levamos para concordar: que tipo de evento ele é em nossa empresa.

3. Você precisa pensar com sua cabeça. Não, não quero dizer que os desenvolvedores não pensem (embora quem sou eu para falar por todos), é apenas que, no desenvolvimento de produtos, você já tem algum tipo de arquitetura e está cortando vários pedidos em atraso. Obviamente, isso requer planejamento e reflexão, mas este é um trabalho de streaming, onde o principal problema é simplesmente bom e de alta qualidade.

Não é tão simples aqui, porque a transferência de vários componentes do sistema de um monólito acolhedor e confortável para o mundo da selva selvagem de microsserviços não é tão simples. Quando o serviço começa a polvilhar com eventos, você precisa revisar a lógica de preenchimento do armazenamento, porque os dados agora parecem diferentes. Aqui você precisa pensar muito e completamente, não como desenvolvedor, mas como engenheiro de dados. É uma história normal quando você passa dias com um caderno e uma caneta ou com um marcador próximo ao quadro. É muito difícil, não gosto de pensar, adoro figos e em produção.

4. Talvez o mais importante seja a informação. O que fazemos quando nos falta conhecimento? Quem disse que o stackoverflow? Tire essa pessoa da sala. Vamos ler documentos, livros sobre o assunto e ainda existe uma comunidade que organiza fóruns, reuniões e conferências. A documentação é legal, mas infelizmente está incompleta. Estamos usando o Cosmos DB em vários projetos. Boa sorte lendo a documentação deste produto. Felizmente, os livros são a única salvação, eles existem e podem ser encontrados, eles têm muito conhecimento fundamental e você precisa ler muito e constantemente. Mas a comunidade está com problemas.

Agora, em nossa direção, é difícil encontrar pelo menos uma conferência ou reunião adequada. Obviamente, existem muitas mitaps com a palavra Data, mas abreviações estranhas como ML ou AI geralmente aparecem ao lado dessa palavra. Então, isso não é para nós, estamos falando sobre como construir instalações de armazenamento, e não como manchar os neurônios. Esses descolados encheram tudo. Como resultado, estamos sem comunidade. A propósito, se você é um engenheiro de dados e conhece boas comunidades, escreva nos comentários.

Conclusões e anúncio do mitap


O que temos no final? Minha primeira experiência me diz que sentir-se no lugar de um engenheiro será útil para todos os desenvolvedores. Ele apenas permite que você veja as coisas de maneira diferente e não se surpreenda quando nossos olhos estão sangrando ao ver como os desenvolvedores tratam seus dados. Portanto, se sua empresa tem DE, basta conversar com esses caras e aprender muito (sobre você).

E, finalmente, o anúncio. Como é impossível encontrar atenuações em nosso tópico durante o dia, decidimos fazer o nosso. E o que, o que somos piores? Felizmente, temos uma incrívelSchvepssse nossos amigos do New Professions Lab , que, como nós, pensam que os engenheiros de data são injustamente privados de atenção.

Aproveito esta oportunidade para convidar todos os interessados ​​a virem para a nossa primeira reunião da comunidade com o promissor nome “DE or DIE”, que será realizada em 27/02/2020 no escritório da Dodo Pizza. Detalhes no TimePad .

Se houver alguma coisa, eu estarei lá, você pode me dizer pessoalmente como estou errado com os desenvolvedores.

More articles:


All Articles