Redaktori i Netologjisë bisedoi me liderin e ekipit BI në Pavell Sayapin për sfidat që zgjidhin inxhinierët e të dhënave në ekipin e tij, cilat janë mjetet që përdorin për këtë dhe si mund të afrohemi në mënyrë të duhur ndaj zgjedhjes së mjeteve për zgjidhjen e detyrave të të dhënave, përfshirë ato jo-standarde. Pavelli është mësues në kursin "».
Çfarë bëjnë inxhinierët e të dhënave në Profi.ru
Profi.ru është një shërbim që ndihmon klientët të takohen me specialistë në shumë fusha të ndryshme. Në bazën e shërbimit ka më shumë se 900 mijë specialistë në 700 lloje shërbimesh: mësues, mjeshtra të riparimit, trajnerë, ekspertë të bukurisë, artistë dhe të tjerë. Çdo ditë regjistrohen më shumë se 10 mijë porosi të reja — kjo krijon rreth 100 milion ngjarje në ditë. Të ruash rendësinë në një sasi të tillë të dhënash është e pamundur pa inxhinierë profesionistë të të dhënave.
Idealisht, Data Engineer zhvillon kulturën e punës me të dhënat, përmes së cilës kompania mund të fitojë përfitime shtesë ose të zvogëlojë kostot. Ai sjell vlerë për biznesin, duke punuar në ekip dhe duke qenë një lidhje e rëndësishme mes pjesëmarrësve të ndryshëm — nga zhvilluesit te konsumatorët e raportimeve. Por në secilën kompani detyrat mund të ndryshojnë, prandaj le të shqyrtojmë ato në shembullin e Profi.ru.
Mblidhen të dhënat për të marrë vendime dhe u ofrohen përdoruesve të fundit — menaxherëve të lartë, menaxherëve të produkteve, analistëve.
Të dhënat duhet të jenë të kuptueshme për marrjen e vendimeve dhe të lehta për t'u përdorur. Nuk duhet të bëni përpjekje për të gjetur përshkrimin ose për të formuluar një pyetje të komplikuar SQL që merr parasysh shumë faktorë të ndryshëm. Pamja ideale është që përdoruesi të shikojë në panelin e kontrollit dhe të jetë i kënaqur me gjithçka. E nëse i mungojnë të dhënat nën një këndvështrim të caktuar, ai shkon në bazë dhe me një pyetje të thjeshtë SQL merr atë që i nevojitet.
Vendi i procesit të Cilësisë së të Dhënave në strukturën e përgjithshme të depozitës së të dhënave
Dokumentacioni paqartësues për punën me të dhënat ka një rëndësi të madhe. Kjo e thjeshton punën për inxhinierin e të dhënave (nuk e shqetësojnë me pyetje), dhe për përdoruesin e të dhënave (ai mund të gjejë vetë përgjigjet për pyetjet e tij). Në Profi.ru këto dokumente janë mbledhur në forumin e brendshëm.
Komforti përfshin edhe shpejtësinë e marrjes së të dhënave. Shpejtësia = disponueshmëria në një hap, klik — në dashboard. Por në praktikë, gjithçka është më e ndërlikuar.
Tableau i njëjtë nga këndvështrimi i përdoruesit përfundimtar të dashboard-it nuk lejon të nxjerrë të gjitha përmasat e mundshme. Përdoruesi kënaqet me filtrat që zhvilluesi i dashboard-it ka bërë. Kjo krijon dy skenarë:
- Zhvilluesi bën shumë prerje për dashboard-in ⟶ numri i faqeve rritet ndjeshëm. Kjo zvogëlon disponueshmërinë e të dhënave: bëhet e vështirë të kuptohet se ku është cila informacion.
- Zhvilluesi krijon vetëm prerjet kryesore. Të gjesh informacion është më e lehtë, por për një prerje pak më pak standard, përsëri do të duhet të shkohet ose në bazën e të dhënave, ose te analistët. Kjo gjithashtu ndikon negativisht në disponueshmërinë.
Disponibiliteti është një koncept i gjerë. Ai përfshin si praninë e të dhënave në formën e duhur, ashtu edhe mundësinë për të marrë informacion në panelët e kontrollit, si dhe segmentimin e nevojshëm të të dhënave.
Grumbullojnë të dhëna nga të gjitha burimet në një vend.
Burimet e të dhënave mund të jenë të brendshme dhe të jashtme. Për shembull, ndonjëherë biznesi i dikujt varet nga raportet meteorologjike që duhet të grumbullohen dhe ruhen nga burime të jashtme.
Informacioni duhet të ruhet me shënimin e burimit dhe gjithashtu në mënyrë që të dhënat të mund të gjenden lehtësisht. Në Profi.ru, kjo detyrë është zgjidhur përmes dokumentacionit të automatizuar. Dokumentacioni për burimet e brendshme të të dhënave përdor skedarë YML.
Krijojnë tabela informacioni.
Vizualizimi i të dhënave është më mirë të bëhet me një mjet profesional, siç është Tableau.
Shumica e njerëzve marrin vendime emocionalisht — rëndësi ka qartësia dhe estetikë. Excel, për shembull, nuk është shumë i përshtatshëm për vizualizim: nuk përmbush të gjitha nevojat e përdoruesve të të dhënave. Për shembull, një menaxher produkti dëshiron të futet thellë në numra, por në mënyrë që të jetë e përshtatshme për ta bërë atë. Kjo i lejon atij të zgjidhë problemet e tij, dhe jo të mendojë se si të marrë informacionin dhe të mbledhë metrikat.
Vizualizimi i cilësisë së të dhënave mundëson marrjen e vendimeve më lehtë dhe më shpejt.
Sa më i lartë të jetë niveli i një personi në punë, aq më e madhe është nevoja për të pasur të dhëna të agreguara në telefon. Detajet nuk janë të nevojshme për menaxherët e lartë — është e rëndësishme të kontrollohet situata në tërësi dhe BI është një mjet i mirë për këtë.
Shembulli i panelit të produktit Profi.ru (një nga fletët). Për arsye të konfidencialitetit, emrat e metrikave dhe akseve janë fshehur.
Shembuj të detyrave reale
Detyra 1 — të transferosh të dhënat nga sistemet përkatëse (operacionale) në një depo të dhënash ose ETL.
Një nga detyrat rutinore të inxhinierit të të dhënave.
Për këtë mund të përdoren:
- skripte të shkruara vetë, të cilat aktivizohen përmes cron ose me ndihmën e një orkestruesi të veçantë si Airflow ose Prefect;
- Zgjidhje ETL me kod të hapur: Pentaho Data Integration, Talend Data Studio dhe të tjera;
- zgjidhje pronësore: Informatica PowerCenter, SSIS dhe të tjera;
- zgjidhje në cloud: Matillion, Panoply dhe të tjera.
Në një version të thjeshtë, detyra zgjidhet duke shkruar një skedar YML me 20 rreshta. Kjo zgjat rreth 5 minuta.
Në rastin më të komplikuar, kur duhet të shtohet një burim i ri — për shembull, një bazë të dhënash të re — mund të zgjasë deri në disa ditë.
Në Profi, kjo detyrë e thjeshtë — në një proces të rregullt — përbëhet nga këto hapa:
- Të kuptojmë nga klienti cila është informacioni i nevojshëm dhe ku ndodhet.
- Të kuptojmë nëse ka akses në këto të dhëna.
- Nëse nuk ka akses, të kërkojmë nga administratorët.
- Të shtojmë një degë të re në Git me kodin e detyrës në Jira.
- Të krijojmë një migrim për shtimin e të dhënave në modelin kryesor përmes një skripti interaktiv Python.
- Të shtojmë skedarët e ngarkesave (skedari YML me përshkrimin e burimeve të të dhënave dhe tabelës ku regjistrohen).
- Të testojmë në skenë.
- Të ngarkojmë të dhënat në depo.
- Të krijojmë një kërkesë për tërheqje.
- Të kalojmë rishikimin e kodit.
- Pas kalimit të rishikimit të kodit, të dhënat ngarkohen në degën kryesore dhe automatikisht shpërndahen në prodhim (CI/CD).
Detyra 2 — të vendosim në një mënyrë të përshtatshme të dhënat e ngarkuara.
Një detyrë tjetër e shpeshtë — është të vendosim të dhënat e ngarkuara në një mënyrë që përdoruesi përfundimtar (ose vegla BI) të ketë lehtësi në punë me to dhe të mos duhet të bëjë lëvizje të panevojshme për të kryer shumicën e detyrave. Kjo do të thotë të ndërtojmë ose azhurnojmë Dimension Data Store (DDS).
Për këto mund të aplikohen zgjidhjet nga detyra e parë, pasi kjo është gjithashtu një proces ETL. Në variantin më të thjeshtë, përditësimi i DDS bëhet përmes skripteve SQL.
Detyra 3 është nga detyrat jo tipike.
Në Profi po lind analiza në kohë reale. Generohet një numër i madh ngjarjesh nga ekipet produktive — i regjistrojmë ato në ClickHouse. Por atje nuk mund të futen regjistrime një nga një në numër të madh, prandaj detyrohemi t'i bashkojmë regjistrimet në grupe. Kështu që nuk mund të shkruajmë drejtpërdrejt — na nevojitet një përpunues ndërmjetës.
Përdoreshin motorë të bazuar në Apache Flink. Deri tani, rendi i veprimit është ky: motori përpunon rrjedhën e ngjarjeve që vijnë ⟶ i grumbullon ato në grupe në ClickHouse ⟶ në lëvizje llogarit numrin e ngjarjeve për 15 minuta ⟶ i dërgon shërbimit që përcakton nëse ka anomali — krahason me vlerat për 15 minuta të ngjashme me një thellësi prej 3 muajsh ⟶ nëse ka, dërgon një njoftim në Slack.
Skema për analizën e faqeve (pjesa e ngarkesës)
Korniza Apache Flink garanton dorëzim të paktën një herë. Megjithatë, ekziston një mundësi për kopjime. Në rastin e RabbitMQ, kjo mund të zgjidhet duke përdorur Correlation ID. Kjo garanton dorëzimin unik ⟶ integritetin e të dhënave.
Numërojmë ngjarjet përsëri me ndihmën e Apache Flink, shpërndajmë përmes një panele të customizuar, të shkruar në NodeJS, + frontend në ReactJS. Kërkimi i shpejtë nuk dha zgjidhje të ngjashme. Po ashtu, kodi u krijua thjesht — shkrimi nuk zuri shumë kohë.
Monitorimi është më tepër teknik. Ne shikojmë anomalitë për të parandaluar problemet në faza të hershme. Disa metrika globale thelbësore të kompanisë nuk janë përfshirë akoma në monitorim, pasi drejtimi i analizës në streaming është në fazën e formimit.
Veglat kryesore të inxhinierëve të të dhënave
Me detyra të inxhinierëve të të dhënave është mëse e qartë, tani pak rreth mjeteve që përdoren për zgjidhjen e tyre. Sigurisht, mjetet në kompani të ndryshme mund të ndryshojnë (dhe duhet të ndryshojnë) — gjithçka varet nga vëllimi i të dhënave, shpejtësia e përftimit të tyre dhe moshomogjeniteti. Ajo gjithashtu mund të varet nga prirja e specialistit ndaj një mjeti të vetëm, thjesht sepse ai/ajo ka punuar me të dhe e njeh mirë. Në Profi.ru ne ndaluam në këto variante →
Për vizualizimin e të dhënave — Tableau, Metabase
Tableau u përzgjodh prej kohësh. Ky sistem lejon analizimin e shpejtë të masave të mëdha të të dhënave dhe në të njëjtën kohë nuk kërkon një implementim të kushtueshëm. Për ne është i përshtatshëm, i bukur dhe i zakontë — shpesh punojmë në të.
Metabase-i njeh shumë pak njerëz, ndonëse është shumë i mirë për prototipizim.
Nga mjetet e vizualizimit mund të përmendim gjithashtu Superset nga Airbnb. Karakteristika e tij e veçantë është shumë lidhje me bazat e të dhënave dhe mundësi për vizualizim. Megjithatë, për përdoruesin e zakonshëm, ai është më pak i përshtatshëm se Metabase, pasi nuk lejon lidhjen e tabelave; për këtë është e nevojshme të krijosh paraqitje të veçanta.
Në Metabase, mund të lidhni tabela, madje shërbimi e bën këtë vetë duke marrë parasysh skemën e bazës së të dhënave. Ndërsa, ndërfaqja e Metabase është më e thjeshtë dhe më e këndshme.
Ka shumë mjete — thjesht gjeni tuajin.
Për ruajtjen e të dhënave — ClickHouse, Vertica
ClickHouse është një mjet falas dhe i shpejtë për ruajtjen e ngjarjeve produktore. Analistët krijojnë vetë analitikën e tyre (nëse kanë mjaft të dhëna) ose inxhinierët e të dhënave marrin aggregatet dhe i ngarkojnë në Vertica për të ndërtuar vitrina.
Vertica është një produkt i shkëlqyer dhe i përshtatshëm për shfaqjen e vitrinave përfundimtare.
Për menaxhimin e rrjedhave të të dhënave dhe kryerjen e llogaritjeve — Airflow
Të dhënat i ngarkojmë përmes mjeteve të konsolës. Për shembull, përmes klientit që vjen me MySQL, kështu bëhet më shpejt.
Avantazhi i mjeteve të konsolës — shpejtësia. Të dhënat nuk kalojnë përmes memories së të njëjtit proces Python. Disavantazhi është se kontrolli mbi të dhënat është më i vogël, ndërsa ato fluturojnë nga një DB në një tjetër.
Gjuha kryesore e programimit — Python
Python ka një prag shumë më të ulët për t'u mësuar + kompania ka kompetenca në këtë gjuhë. Arsyeja tjetër është që DAG-ët e Airflow shkruhen në Python. Këto skripte janë thjesht një mbështjellës mbi ngarkesat, puna kryesore bëhet përmes skripteve konsolë.
Java përdorim për zhvillimin e analitikës në kohë reale.
Qasja në zgjedhjen e mjeteve të të dhënave — çfarë të bëjmë për të mos zhvilluar një zoologji teknologjike.
Në treg ka shumë mjete për të punuar me të dhënat në çdo fazë: nga shfaqja e tyre deri te shfaqja në dashboard për këshillin e drejtorëve. Nuk është çudi që disa kompani mund të kenë një sërë zgjidhjesh të pakënaqshme — ajo që quhet zoologji teknologjike.
Zoologjia teknologjike — ato janë mjete që kryejnë të njëjtat funksione. Për shembull, Kafka dhe RabbitMQ për shkëmbim mesazhesh ose Grafana dhe Zeppelin për vizualizim.
— tregon se sa shumë zgjidhje të dyfishuara mund të jenë
Gjithashtu, shumë njerëz për qëllime personale mund të përdorin mjete të ndryshme ETL. Në Profi, pikërisht kjo është situata. ETL kryesor është në Airflow, por disa për ngarkimet e tyre personale përdorin Pentaho. Ata testojnë hipoteza dhe përmes inxhinierëve këto të dhëna nuk është e nevojshme t'i kalojnë. Kryesisht, mjeteve "vetë-shërbimi" u drejtohen specialistë mjaft të përvojë, të cilët janë të angazhuar në aktivitete hulumtuese — studiojnë rrugë të reja për zhvillimin e produktit. Grupi i të dhënave të tyre për analizë është interesant kryesisht për ta, për më tepër, ai ndryshon vazhdimisht. Prandaj, nuk ka kuptim të futen këto ngarkesa në platformën kryesore.
Duke kopshtit zoologjik. Shpesh përdorimi i teknologjive të dyfishuara lidhet me faktorët njerëzorë. Ekipet e mbyllura kanë zakon të punojnë me një mjet të caktuar, i cili mund të mos përdoret nga një ekip tjetër. Dhe ndonjëherë, autonomia është rruga e vetme për të zgjidhur detyra të veçanta. Për shembull, ekipi i R&D ka nevojë të testojë diçka duke përdorur një mjet të caktuar — thjesht është i dobishëm, ndonjë anëtar i ekipit e ka përdorur atë më parë ose ka ndonjë arsye tjetër. Të presësh burimet e administratorëve të sistemeve për instalimin dhe konfigurimin e këtij mjeti është një proces i gjatë. Ndërkohë, administratorët e kujdesshëm dhe të sakta duhet të provoshin se kjo është me të vërtetë e nevojshme. Kështu, ekipi e instalon mjetin në makinat e tij virtuale dhe zgjidh problemet e tyre specifike.
Kopshti zoologjik i zgjidhjeve nuk është një problem, për aq kohë sa kjo nuk kërkon një angazhim të madh nga ana e administratorëve për të mbështetur mjetin. Duhet të merret parasysh se si përdorimi i mjetit ndikon në burimet e mbështetjes.
Një arsye tjetër e zakonshme për shfaqjen e mjeteve të reja është dëshira për të provuar një produkt të panjohur në një fushë mjaft të re, ku ende nuk janë formuar standardet ose nuk ka rekomandime të provuara. Inxhinieri i të dhënave, ashtu si zhvilluesi, duhet gjithmonë të eksplorojë mjete të reja me shpresën për të gjetur një zgjidhje më efikase për detyrat aktuale ose për t'u mbajtur i informuar për atë që ofron tregu.
Sundimi për të provuar mjete të reja është në të vërtetë i madh. Por për të bërë një zgjedhje të arsyeshme, nevojitet së pari disiplinë vetjake. Kjo do të ndihmojë që të mos i jepni fund plotësisht impulseve kërkuese, por të merrni parasysh mundësitë e kompanisë për të mbështetur infrastrukturën për mjetin e ri.
Nuk duhet të përdoren teknologjitë thjesht për shkak se janë teknologji. Mënyra më e mirë për ta trajtuar këtë çështje është pragmatike: detyra ⟶ një set mjetesh që mund ta zgjidhin këtë detyrë.
Pastaj, vlerëso çdo mjet dhe zgjidh atë më të optimalin. Për shembull, ky mjet mund të zgjidhë detyrën më efikas, por nuk ka kompetenca për të, ndërsa ky është pak më pak efektiv, por në kompani ka njerëz që dinë si të punojnë me të. Ky mjet është me pagesë, por i lehtë për mbështetje dhe përdorim, ndërsa ky është një open source modern, por për mbështetje kërkon një ekip administratoresh. Këto dihen dykahësitë që kërkojnë një mendje të qetë për t'u zgjidhur.
Zgjedhja e mjetit është gjysma një skak dhe gjysma një përvojë personale. Nuk ka siguri të plotë se mjeti do t'i përshtatet.
Për shembull, në Profi filluam me Pentaho, sepse kishim ekspertizë për këtë mjet, por përfundimisht kjo u tregua një vendim i gabuar. Repazitorin e brendshëm të Pentaho, ndërsa projekti u rrit, filloi të ngadalësohej shumë. Për ta ruajtur të dhënat, për shembull, nevojitej një minutë, dhe nëse ka zakon të ruajë punën vazhdimisht, koha thjesht arratisej. Kësaj i shtohej një nisje e ndërlikuar, detyra sipas orarit - kompjuteri ngrinte.
Përpjekjet përfunduan pas kalimit në Airflow - një mjet popullor, me një komunitet të madh.
Prania e një komuniteti shërbimi, mjeteve është e rëndësishme për zgjidhjen e detyrave të komplikuara — mund të kërkosh këshilla nga kolegët.
Nëse një kompani është e zhvilluar dhe ka burime, ka kuptim të mendohet për blerjen e mbështetjes teknike. Kjo ndihmon në zgjidhjen e shpejtë të problemeve dhe merr rekomandime për përdorimin e produktit.
Nëse flasim për qasjen në përzgjedhje, në Profi ndjekim këto parime:
- Mos e merrni vendimin vetëm. Kur një person zgjedh diçka, ai automatikisht është i bindur në drejtësinë e tij. Një gjë tjetër është të bindësh të tjerët, kur duhet të sjellësh argumente të forta në mbrojtje. Kjo ndihmon gjithashtu për të parë pikëpamjet e dobëta të mjetit.
- Të konsultoheni me specialistin kryesor të të dhënave (dialogu në vertical). Kjo mund të jetë inxhinieri kryesor i të dhënave (Chief Data Engineer), drejtuesi i ekipit BI. Të lartëat e shohin situatën më gjerë.
- Të komunikoni me ekipe të tjera (dialogu në horizontal). Çfarë mjete përdorin ata dhe sa mirë funksionojnë. Ndërsa ndoshta, mjeti i kolegëve mund të zgjidhë detyrat tuaja dhe nuk do të jetë e nevojshme të krijoni një zookeeper zgjidhjesh.
Kompetencat e brendshme si një zëvendësim efektiv për shërbimet e jashtme
Qasja ndaj zgjedhjes së mjeteve mund të konsiderohet edhe përdorimi i kompetencave të brendshme të kompanisë.
Shpesh hasen situata ku biznesi ka një detyrë komplekse, por nuk ka fonde për ta realizuar atë. Detyra është e madhe dhe e rëndësishme, dhe në mënyrë ideale, do të ishte më mirë të angazhohej një ofrues shërbimesh të jashtme, i cili ka përvojën përkatëse. Por për shkak se ndihma financiare nuk është në dispozicion, detyra iu besua ekipit të brendshëm. Përveç kësaj, zakonisht biznesi i beson më shumë punonjësve të tij, veçanarisht kur ata kanë vërtetuar eficencën e tyre.
Disa shembuj të tillë janë situatat kur një drejtim i ri zhvillohet nga punonjësit e brendshëm, siç është kryerja e testeve të ngarkesës dhe krijimi i një depo të dhënash. Sidomos depoja e të dhënave, pasi është një histori unike për çdo biznes. Një depo nuk mund të blihet, mund të angazhohesh vetëm ekspertë të jashtëm që ta ndihmojnë të ndërtohet me mbështetje nga ekipi i brendshëm.
Për më tepër, me avancimin e drejtimit të ri, ekipi mund të kuptojë se nevoja për një ofrues shërbimesh të jashtme ka rënë.
Në Profi, implementimi i BI-së ishte brenda kompanisë. Vështirësia kryesore ishte se biznesi dëshironte të niste BI-në shpejt. Por ndërtimi i një projekti të tillë kërkonte kohë: për të rritur kompetencat, për të ngarkuar të dhënat, për të ndërtuar një skemë të përshtatshme depoje, për të zgjedhur mjetet dhe për t'i zotëruar ato.
Faza kryesore — e nxehtë — kur gjithçka u ndërtua dhe u kristalizua, zgjati rreth një vit. Dhe projekti vazhdon të zhvillohet ende.
Kur ndërrtohet depoja e korporatës për të dhënat, është e rëndësishme të respektohen standarde të larta, të mbrohesh pozitat e tua dhe të mos bësh punë të shpejta për hir të biznesit.
Me shumë dhimbje, na duhej të riformatojmë pjesën më të madhe të projektit, e cila duhej bërë atëherë me ngut.
Por ndonjëherë, qasja "me ngut" është e arsyeshme. Kështu, në zhvillimin e produkteve, ajo mund të jetë madje e vetmja e saktë. Duhet të lëvizim shpejt përpara, të testojmë hipotezat për produktet dhe më shumë. Por depoja duhet të bazohet në një arkitekturë të fortë, nd otherwise it will not be able to adapt quickly to the growing business and the project will stall.
Në këtë projekt të komplikuar, kine lideri ynë na ndihmoi shumë, duke mbrojtur progresin e punëve, duke shpjeguar menaxhmentit çfarë po bëjmë, duke siguruar burimet dhe thjesht duke na mbrojtur. Pa një mbështetje të tillë, nuk jam i sigurt se do të kishim arritur të lansojmë projektin.
Në tregtime të tilla, një rol të rëndësishëm luajnë ata që quhen early adopters — ata që janë të gatshëm të provojnë të reja — mes menaxherëve të lartë, analistëve dhe menaxherëve të produkteve. Për të bërë që një temë e papërpunuar të fluturojë, nevojiten pionerë që të konfirmojnë se gjithçka funksionon dhe është e lehtë për t'u përdorur.
Nëse dikush dëshiron të ndajë zgjidhjen e detyrës së tretë nga ato të përmendura më sipër — mirëseardhët 🙂
Burimi: habr.com
