A principis de desembre, vaig cometre un error fatal i vaig fer un punt d'inflexió en la meva vida com a desenvolupador i vaig passar a l'equip d'Enginyeria de Dades (DE) de l'empresa. En aquest article compartiré algunes observacions que vaig fer durant dos mesos de treball a l'equip de DE.
Per què enginyeria de dades?
El meu viatge a DE va començar l'estiu del 2019, quan nosaltres anem a , i allà vaig aconseguir la il·luminació. Vaig començar a interessar-me pel tema, estudiar algorismes i fins i tot sobre ells , i després va pensar en l'àmbit d'aplicació i ràpidament va descobrir que l'aplicació pràctica a la nostra empresa són bases de dades distribuïdes.
Què fa exactament el nostre equip? Nosaltres, com tots els nois i noies de moda, volem convertir-nos en una empresa basada en dades. I perquè això sigui possible, hem de construir almenys una instal·lació d'emmagatzematge fiable, que es pugui utilitzar per crear els informes que l'empresa necessiti. Però el més important és que les dades d'aquest emmagatzematge s'han de confiar. A més, utilitzant aquestes dades, cal poder restaurar l'estat del sistema en el moment t. Tot això es complica pel fet que vivim en un nou món valent de microserveis, i aquesta ideologia implica que cada servei implementa la seva petita funcionalitat, la seva base de dades és el seu propi negoci i la pot esborrar almenys cada dia, però al mateix temps hem de poder rebre i tramitar l'estat del servei.
Si voleu ser impulsat per dades, primer convertiu-vos en impulsat per esdeveniments
No tan senzill. Els esdeveniments són diferents i el desenvolupador i l'enginyer de dades els miren de manera diferent. Parlar d'esdeveniments és un tema per a un article separat, així que no hi entraré aquí. A més, aquest article ja ho ha fet un tal Martin Fowler, no li llevaré els llorers, que també es faci famós.
En general, hi ha molt a pensar i per això aquesta zona és atractiva. Succeeix que a la nostra empresa, un enginyer de dades és una àrea de responsabilitat molt més àmplia que una persona que escriu pipelines ETL/ELT (si no saps què signifiquen aquestes abreviatures, vine a . Com a publicitat contextual).
Ens ocupem de l'arquitectura d'emmagatzematge, el modelatge de dades, qüestions relacionades amb la seguretat de les dades i els propis pipelines, per descomptat. També hem d'assegurar-nos que, d'una banda, la nostra presència no sigui molt onerosa per als desenvolupadors de productes i que s'hagin de distreure el menys possible amb els nostres requisits a l'hora de tallar noves funcions al sistema, i d'altra banda, cal proporcionar-los convenientment disposats en dades d'emmagatzematge per als analistes i l'equip de BI. Així és com vivim.
Dificultats en la transició del desenvolupament
En el meu primer dia de feina, em vaig trobar amb una sèrie de dificultats que vull compartir amb vosaltres.
1. El primer que vaig veure va ser l'absència de tuling i algunes pràctiques. Preneu, per exemple, la cobertura del codi amb proves. Tenim centenars de marcs de prova en desenvolupament. Quan es treballa amb dades, tot és més complicat. Sí, podem provar pipelines ETL amb dades de prova, però ho hem de fer tot manualment i buscar solucions per a cada cas concret. Com a resultat, la cobertura de la prova és molt pitjor. Afortunadament, hi ha una altra capa de retroalimentació en forma de seguiment i registres, però això ja ens obliga a reaccionar de manera reactiva i no pas proactiva, la qual cosa és indignant i inquietant.
2. El món des d'una perspectiva DE no és gens el que sembla a un desenvolupador de producte normal (bé, és clar que el lector no és així, i ja ho sap tot, però jo no ho sabia i ara m'estic fotent amunt). Com a desenvolupador, creo el meu propi microservei, poso les dades a [base de dades de la vostra elecció], deso el meu estat allà, obteniu alguna cosa per identificació i està bé. El servei és lent, les comandes són confuses, això és tot. Em demanen que busqui el meu estat en un altre servei, així que llençaré un esdeveniment a algun RabbitMQ i ja està. I aquí vam tornar de nou al tema dels esdeveniments descrits anteriorment.
El que el servei necessita per al treball operatiu no ens convé per a les dades històriques, així que comença la qüestió de la reelaboració dels contractes de servei i el treball estret amb els equips de desenvolupament. No us podeu ni imaginar quantes hores hem trigat a posar-nos d'acord: quin tipus d'Event Driven és a la nostra empresa.
3. Cal pensar amb el cap. No, no vull dir que els desenvolupadors no pensin (tot i que qui sóc jo per parlar en nom de tothom), és que en el desenvolupament de productes, molt sovint, ja tens algun tipus d'arquitectura, i retalles diferents barreges de l'endarreriment. Per descomptat, això requereix planificació i reflexió, però això és un treball en corrent, on el principal problema és simplement fer-ho bé i de manera eficient.
Per a nosaltres, no és tan senzill perquè la transferència de diversos components del sistema des d'un monòlit càlid i acollidor al món de la selva salvatge de microserveis no és tan senzill. Quan el servei comença a emetre esdeveniments, heu de reconsiderar la lògica per omplir l'emmagatzematge, perquè les dades ara semblen diferents. Aquí és on cal pensar molt i a fons, ja no com a desenvolupador, sinó com a enginyer de dades. És una història normal quan passes dies amb quadern i bolígraf o amb un retolador a la pissarra. És molt difícil, no m'agrada pensar, també m'encanta la producció.
4. Potser el més important és la informació. Què fem quan ens falten coneixements? Qui va dir stackoverflow? Treu aquesta persona de l'habitació. Anem a llegir documents, llibres sobre el tema, i també hi ha una comunitat que organitza fòrums, trobades i conferències. La documentació és fantàstica, però, malauradament, pot ser incompleta. Utilitzem Cosmos DB en diversos projectes. Molta sort llegint la documentació d'aquest producte. Els llibres són l'única salvació, afortunadament existeixen i es poden trobar, contenen molts coneixements fonamentals i cal llegir molt i constantment. Però el problema és de la comunitat.
Ara és difícil trobar almenys una conferència o trobada adequada a la nostra zona. No, és clar, hi ha moltes trobades amb la paraula Data, però al costat d'aquesta paraula sol haver-hi abreviatures estranyes com ML o AI. Per tant, això no és per a nosaltres, estem parlant de com construir instal·lacions d'emmagatzematge, i no de com untar-nos de neurones. Aquests hipsters s'han apoderat de tot. Com a resultat, estem sense comunitat. Per cert, si sou enginyer de dades i coneixeu bones comunitats, escriu-hi als comentaris.
Conclusions i anunci de la trobada
Amb què acabem? La meva primera experiència em diu que sentir-se a la pell d'un enginyer de dades serà útil per a tots els desenvolupadors. Només ens permet mirar les coses d'una altra manera i no sorprendre'ns quan els nostres ulls s'injecten de sang quan veiem com els desenvolupadors tracten les seves dades. Per tant, si hi ha un DE a la vostra empresa, només heu de parlar amb aquests nois, aprendràs moltes coses noves (sobre tu mateix).
I finalment, l'anunci. Com que és difícil trobar trobades sobre el nostre tema durant el dia, vam decidir fer-ne les nostres. Per què som pitjors? Per sort tenim un increïble i els nostres amics de , que, com nosaltres, consideren que els enginyers de dades estan injustament privats d'atenció.
Aprofitant aquesta oportunitat, convido a tots els que els interessin a venir a la nostra primera trobada de la comunitat amb el prometedor títol "DE or DIE", que tindrà lloc el 27.02.2020 de febrer de XNUMX a l'oficina de Dodo Pizza. Detalls a .
Si passa alguna cosa, hi seré, pots dir-me personalment a la cara com estic equivocat amb els desenvolupadors.
Font: www.habr.com