ProHoster >> Blog >> Administrimi >> Si të zgjedhin kompanitë mjetet për inxhinierët e të dhënave dhe të mos e shndërrojnë gjithçka në një kopsht teknologjik: përvoja e PROFI.RU

Si të zgjedhin kompanitë mjetet për inxhinierët e të dhënave dhe të mos e shndërrojnë gjithçka në një kopsht teknologjik: përvoja e PROFI.RU

Redaktori i Netologjisë bisedoi me liderin e ekipit BI në Profi.ru 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 "Inxhinier të Dhënash». 

Ç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.

Si të zgjedhin kompanitë mjetet për inxhinierët e të dhënave dhe të mos e shndërrojnë gjithçka në një kopsht teknologjik: përvoja e PROFI.RU
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Ă«.

Si të zgjedhin kompanitë mjetet për inxhinierët e të dhënave dhe të mos e shndërrojnë gjithçka në një kopsht teknologjik: përvoja e PROFI.RU
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.

Si të zgjedhin kompanitë mjetet për inxhinierët e të dhënave dhe të mos e shndërrojnë gjithçka në një kopsht teknologjik: përvoja e PROFI.RU
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. 

Si të zgjedhin kompanitë mjetet për inxhinierët e të dhënave dhe të mos e shndërrojnë gjithçka në një kopsht teknologjik: përvoja e PROFI.RU
Harta e teknologjive dhe kompanive nĂ« fushĂ«n e tĂ« dhĂ«nave dhe AI. — 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

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster