На почетокот на декември, направив фатална грешка и направив пресврт во мојот живот како програмер и се преселив во тимот на Data Engineering (DE) во рамките на компанијата. Во оваа статија ќе споделам некои согледувања што ги направив во текот на два месеци работа во тимот на ДЕ.
Зошто инженерство на податоци?
Моето патување во ДЕ започна во летото 2019 година, кога ние ајде да одиме на , и таму постигнав просветлување. Почнав да се интересирам за темата, да проучувам алгоритми, па дури и за нив , а потоа размислувавме за опсегот на примена и брзо дознавме дека практичната примена во нашата компанија се дистрибуирани бази на податоци.
Што точно прави нашиот тим? Ние, како и сите модерни момчиња и девојчиња, сакаме да станеме компанија управувана од податоци. И за да стане возможно ова, треба барем да изградиме доверлив капацитет за складирање, кој може да се користи за да се изготват какви било извештаи што и се потребни на компанијата. Но, најважно е дека на податоците во ова складирање мора да им се верува. Покрај тоа, користејќи ги овие податоци, треба да можете да ја вратите состојбата на системот во времето t. Сето ова е комплицирано од фактот дека живееме во храбар нов свет на микросервисите, а оваа идеологија имплицира дека секој сервис спроведува своја мала функционалност, нејзината база на податоци е нејзина работа и може да ја брише барем секој ден, но на во исто време мора да можеме да ја примаме и обработуваме состојбата на услугата.
Ако сакате да бидете Водени од податоци, прво станете Водени од настани
Не толку едноставно. Настаните се различни, а развивачот и инженерот за податоци гледаат на нив поинаку. Разговорот за настани е тема за посебна статија, затоа нема да навлегувам овде. Покрај тоа, таков напис веќе има извесен Мартин Фаулер, нема да му ги одземам ловориките, нека стане и познат.
Генерално, има многу за размислување и затоа оваа област е атрактивна. Се случува во нашата компанија, инженерот за податоци да е многу поширока област на одговорност отколку само лице кое пишува ETL/ELT цевководи (ако не знаете што значат овие кратенки, дојдете на . Како контекстуално рекламирање).
Се занимаваме со архитектура на складирање, моделирање на податоци, прашања поврзани со безбедноста на податоците и самите цевководи, се разбира. Ние, исто така, треба да се погрижиме дека, од една страна, нашето присуство не е многу оптоварувачко за развивачите на производи и тие треба што помалку да се одвлекуваат од нашите барања при сечење нови функции во системот, а од друга страна, ние треба да ги обезбеди соодветно поставени во складирање на податоци за аналитичарите и тимот на БИ. Така живееме.
Тешкотии при преминот од развој
На мојот прв работен ден наидов на голем број тешкотии кои сакам да ги споделам со вас.
1. Првото нешто што го видов беше отсуството на тулинг и некои практики. Земете, на пример, покривање на код со тестови. Имаме стотици рамки за тестирање во развој. Кога работите со податоци, сè е покомплицирано. Да, можеме да ги тестираме цевководите ETL на податоците од тестот, но сето тоа треба да го направиме рачно и да бараме решенија за секој конкретен случај. Како резултат на тоа, покриеноста на тестот е многу полоша. За среќа, постои уште еден слој на повратни информации во форма на мониторинг и логови, но ова веќе бара од нас да реагираме реактивно наместо проактивно, што е огорчено и вознемирувачко.
2. Светот од перспектива на DE воопшто не е како што изгледа на обичен развивач на производи (добро, се разбира читателот не е таков, а тој веќе знае се, но јас не знаев и сега се заебам горе). Како програмер, создавам сопствен микросервис, ги ставам податоците во [база на податоци по ваш избор], ја зачувувам мојата држава таму, добивам нешто со лична карта и тоа е во ред. Услугата е бавна, нарачките се збунувачки, тоа е сè. Ме прашуваат да ја побарам мојата држава во друга услуга, па ќе фрлам настан во некој RabbitMQ и тоа е тоа. И тука повторно се вративме на прашањето за настаните опишани погоре.
Она што и е потребно на услугата за оперативна работа не ни одговара за историски податоци, па затоа започнува прашањето за преработка на договорите за услуги и блиска работа со развојните тимови. Не можете ни да замислите колку часа ни требаа да се договориме: каков настан е воден во нашата компанија.
3. Треба да размислувате со своја глава. Не, не мислам дека програмерите не размислуваат (иако кој сум јас да зборувам за секого), само во развојот на производите многу често веќе имате некаква архитектура и отсекувате различни мешања од заостанатите. Се разбира, ова бара планирање и размислување, но ова е стрим работа, каде што главниот проблем е едноставно да се направи добро и ефикасно.
За нас тоа не е толку едноставно затоа што преносот на различни компоненти на системот од топол и пријатен монолит во светот на дивата микросервисна џунгла не е толку едноставен. Кога услугата ќе започне да исфрла настани, треба да ја преиспитате логиката за пополнување на складиштето, бидејќи податоците сега изгледаат поинаку. Ова е местото каде што треба да размислувате многу и темелно, веќе не како развивач, туку како инженер за податоци. Тоа е нормална приказна кога поминувате денови со тетратка и пенкало или со маркер на табла. Многу е тешко, не сакам да размислувам, сакам и продукција.
4. Можеби најважна е информацијата. Што правиме кога ни недостасува знаење? Кој рече stackoverflow? Извадете ја оваа личност од собата. Одиме да читаме документи, книги на темата, а има и заедница која организира форуми, состаноци и конференции. Документацијата е одлична, но за жал, може да биде нецелосна. Ние користиме Cosmos DB во голем број проекти. Среќно читајќи ја документацијата за овој производ. Книгите се единствениот спас, за среќа, постојат и можат да се најдат, содржат многу основни знаења и мора да читате многу и постојано. Но, проблемот е во заедницата.
Сега е тешко да се најде барем една соодветна конференција или средба во нашата област. Не, се разбира, има многу средби со зборот Data, но покрај овој збор обично има чудни кратенки како ML или AI. Значи, ова не е за нас, ние зборуваме како да изградиме складишта, а не како да се мачкаме со неврони. Овие хипстери презедоа се. Како резултат на тоа, ние сме без заедница. Патем, ако сте инженер за податоци и познавате добри заедници, пишете во коментари.
Заклучоци и најава за состанокот
Со што завршуваме? Моето прво искуство ми кажува дека чувството во чевлите на инженер за податоци ќе биде корисно за секој развивач. Тоа само ни овозможува да гледаме поинаку на работите и да не бидеме изненадени кога очите ни се крвави кога ќе видиме како програмерите ги третираат нивните податоци. Значи, ако има ДЕ во вашата компанија, само разговарајте со овие момци, ќе научите многу нови работи (за себе).
И на крајот најавата. Бидејќи е тешко да се најдат состаноци на нашата тема во текот на денот, решивме да направиме свои. Зошто сме полоши? За среќа имаме неверојатно и нашите пријатели од , кои, како и ние, чувствуваат дека инженерите за податоци неправедно се лишени од внимание.
Искористувајќи ја оваа прилика, ги поканувам сите што се грижат да дојдат на нашиот прв состанок на заедницата со ветувачки наслов „DE or DIE“, кој ќе се одржи на 27.02.2020 февруари XNUMX година во канцеларијата на Dodo Pizza. Детали на .
Ако нешто се случи, јас ќе бидам таму, можете лично да ми кажете колку грешам за програмерите.
Извор: www.habr.com