Hej Habr!
Datumoj estas la plej valora valoraĵo de kompanio. Preskaŭ ĉiu cifereca kompanio asertas tion. Estas malfacile argumenti pri ĉi tio: neniu grava IT-konferenco okazas sen diskuti alirojn al administrado, stokado kaj prilaborado de datumoj.
Datumoj venas al ni de ekstere, ĝi ankaŭ estas generita ene de la kompanio, kaj se ni parolas pri datumoj de telekomunika kompanio, tiam por internaj dungitoj ĉi tio estas magazeno de informoj pri la kliento, liaj interesoj, kutimoj kaj loko. Kun taŭga profilado kaj segmentado, reklamaj ofertoj estas plej efikaj. Tamen, en la praktiko, ne ĉio estas tiel rozkolora. La datumoj, kiujn kompanioj konservas, povas esti senespere malmodernaj, superfluaj, ripetemaj, aŭ ĝia ekzisto estas nekonata de iu ajn krom mallarĝa rondo de uzantoj. ¯_(ツ)_/¯
Unuvorte, datumoj devas esti efike administritaj - nur tiam ĝi fariĝos valoraĵo, kiu alportas realajn avantaĝojn kaj profiton al la komerco. Bedaŭrinde, solvi problemojn pri administrado de datumoj postulas venki sufiĉe multajn kompleksaĵojn. Ili ŝuldiĝas ĉefe al kaj la historia heredaĵo en la formo de "zooj" de sistemoj kaj la manko de unuigitaj procezoj kaj aliroj al ilia administrado. Sed kion signifas esti "datumita"?
Ĝuste pri tio ni parolos sub la tranĉo, same kiel kiel la malfermfonta stako helpis nin.
La koncepto de strategia administrado de datumoj Data Governance (DG) jam estas sufiĉe konata en la rusa merkato, kaj la celoj atingitaj de komerco kiel rezulto de ĝia efektivigo estas klaraj kaj klare deklaritaj. Nia kompanio ne estis escepto kaj starigis la taskon enkonduki la koncepton pri administrado de datumoj.
Do kie ni komencis? Komence, ni formis ŝlosilajn celojn por ni mem:
- Tenu niajn datumojn alireblaj.
- Certigu travideblecon de la datumvivciklo.
- Provizi kompaniajn uzantojn kun konsekvencaj kaj konsekvencaj datumoj.
- Provizi firmaajn uzantojn kun kontrolitaj datumoj.
Hodiaŭ, ekzistas dekduo da Data Governance-klasaj iloj sur la programara merkato.
Sed post detala analizo kaj studo de la solvoj, ni registris kelkajn kritikajn komentojn por ni mem:
- Plej multaj fabrikantoj ofertas ampleksan aron da solvoj, kiuj por ni estas superfluaj kaj duobligas ekzistantajn funkciojn. Plie, multekosta laŭ rimedoj, integriĝo en la nunan IT-pejzaĝon.
- La funkcieco kaj interfaco estas dizajnitaj por teknologoj, ne komercaj finuzantoj.
- Malalta postvivado de produktoj kaj manko de sukcesaj efektivigoj sur la rusa merkato.
- Alta kosto de programaro kaj plia subteno.
La kriterioj kaj rekomendoj voĉigitaj supre koncerne importanstataŭigon de programaro por rusaj kompanioj konvinkis nin movi al nia propra evoluo sur malfermfonta stako. La platformo, kiun ni elektis, estis Django, libera kaj malfermkoda kadro skribita en Python. Kaj tiel ni identigis ŝlosilajn modulojn kiuj kontribuos al la celoj deklaritaj supre:
- Registro de raportoj.
- Komerca glosaro.
- Modulo por priskribi teknikajn transformojn.
- Modulo por priskribi la datumvivciklon de la fonto ĝis la BI-ilo.
- Modulo pri kontrolo de kvalito de datumoj.
Registro de raportoj
Laŭ la rezultoj de internaj studoj en grandaj kompanioj, kiam oni solvas datumojn-rilatajn problemojn, dungitoj pasigas 40-80% de sia tempo serĉante ilin. Tial ni starigis al ni la taskon fari malfermajn informojn pri ekzistantaj raportoj, kiuj antaŭe estis disponeblaj nur por klientoj. Tiel, ni reduktas la tempon por generi novajn raportojn kaj certigas demokratiigon de datumoj.
La raporta registro fariĝis ununura raporta fenestro por internaj uzantoj de diversaj regionoj, fakoj kaj sekcioj. Ĝi solidigas informojn pri informaj servoj kreitaj en pluraj kompaniaj deponejoj de la kompanio, kaj estas multaj el ili en Rostelecom.
Sed la registro ne estas nur seka listo de evoluintaj raportoj. Por ĉiu raporto, ni provizas la necesajn informojn por ke la uzanto koniĝu kun ĝi:
- mallonga priskribo de la raporto;
- profundo de datumoj havebleco;
- klienta segmento;
- bildiga ilo;
- nomo de la kompania stokado;
- komercaj funkciaj postuloj;
- ligo al la raporto;
- ligo al aplikaĵo por aliro;
- stato de efektivigo.
Uznivelaj analizoj haveblas por raportoj, kaj raportoj estas vicigitaj ĉe la supro de la listo surbaze de protokolo-analitiko bazita sur la nombro da unikaj uzantoj. Kaj tio ne estas. Krom la ĝeneralaj karakterizaĵoj, ni ankaŭ donis detalan priskribon de la atributo-konsisto de la raportoj kun ekzemploj de valoroj kaj kalkulmetodoj. Tia detalo tuj donas al la uzanto respondon ĉu la raporto estas utila por li aŭ ne.
La evoluo de ĉi tiu modulo estis grava paŝo en la demokratiigo de datumoj kaj signife reduktis la tempon necesan por trovi la bezonatajn informojn. Krom redukti serĉtempon, la nombro da petoj al la subtena teamo por provizi konsultojn ankaŭ malpliiĝis. Estas neeble ne noti alian utilan rezulton, kiun ni atingis disvolvante unuigitan registron de raportoj - malhelpante la evoluon de duplikataj raportoj por malsamaj strukturaj unuoj.
Komerca glosaro
Vi ĉiuj scias, ke eĉ ene de la sama kompanio, entreprenoj parolas malsamajn lingvojn. Jes, ili uzas la samajn terminojn, sed ili signifas tute malsamajn aferojn. Komerca glosaro estas desegnita por solvi ĉi tiun problemon.
Por ni komerca terminaro ne estas nur konsultlibro kun priskribo de terminoj kaj kalkulmetodaro. Ĉi tio estas plentaŭga medio por disvolvi, interkonsenti kaj aprobi terminologion, konstrui rilatojn inter terminoj kaj aliaj informaj aktivoj de la kompanio. Antaŭ ol eniri la komercan glosaron, termino devas trapasi ĉiujn stadiojn de aprobo kun komercaj klientoj kaj la datumkvalita centro. Nur post tio ĝi fariĝas uzebla.
Kiel mi skribis supre, la unikeco de ĉi tiu ilo estas, ke ĝi permesas konektojn de la nivelo de komerca termino al specifaj uzantraportoj en kiuj ĝi estas uzata, same kiel al la nivelo de fizikaj datumbazaj objektoj.
Ĉi tio fariĝas ebla per la uzo de glosaj termino-identigiloj en la detala priskribo de registraj raportoj kaj la priskribo de fizikaj datumbazaj objektoj.
Nuntempe, pli ol 4000 XNUMX terminoj estas difinitaj kaj interkonsentitaj en la Terminaro. Ĝia uzo simpligas kaj plirapidigas la traktadon de alvenantaj petoj por ŝanĝoj en la informsistemoj de la kompanio. Se la bezonata indikilo jam estas efektivigita en iu ajn raporto, tiam la uzanto tuj vidos aron da pretaj raportoj, kie ĉi tiu indikilo estas uzata, kaj povos decidi pri la efika reuzo de ekzistantaj funkcioj aŭ ĝia minimuma modifo, sen komenci. novaj petoj por la disvolviĝo de nova raporto.
Modulo por priskribi teknikajn transformojn kaj DataLineage
Kio estas ĉi tiuj moduloj, vi demandas? Ne sufiĉas simple efektivigi la Raportan Registron kaj Terminaron; estas ankaŭ necese bazigi ĉiujn komercajn terminojn sur la fizika datumbaza modelo. Tiel, ni povis kompletigi la procezon de formi la datumvivciklon de fontsistemoj ĝis BI-bildigo tra ĉiuj tavoloj de la datumstokejo. Alivorte, konstruu DataLineage.
Ni evoluigis interfacon bazitan sur la formato uzita antaŭe en la firmao por priskribi la regulojn kaj logikon de datuma transformo. La samaj informoj estas enmetitaj per la interfaco kiel antaŭe, sed la difino de la termino identigilo el la komerca terminaro fariĝis antaŭkondiĉo. Jen kiel ni konstruas ligon inter la komercaj kaj fizikaj tavoloj.
Kiu bezonas ĝin? Kio malbonas kun la malnova formato, kun kiu vi laboris dum pluraj jaroj? Kiom pligrandiĝis la laborkostoj por generado de postuloj? Ni devis trakti tiajn demandojn dum la efektivigo de la ilo. La respondoj ĉi tie estas sufiĉe simplaj - ni ĉiuj bezonas ĉi tion, la datuman oficejon de nia kompanio kaj niajn uzantojn.
Efektive, la dungitoj devis adaptiĝi; komence tio kaŭzis iomete plialtiĝon de laborkostoj por preparado de dokumentado, sed ni solvis ĉi tiun aferon. Praktiko, identigado kaj optimumigado de problemaj areoj faris sian laboron. Ni atingis la ĉefan aferon - ni plibonigis la kvaliton de la evoluintaj postuloj. Devigaj kampoj, unuigitaj referenclibroj, eniga maskoj, enkonstruitaj kontroloj - ĉio ĉi ebligis signife plibonigi la kvaliton de transformaj priskriboj. Ni malproksimiĝis de la praktiko transdoni skriptojn kiel disvolvajn postulojn kaj dividis scion, kiu estis nur disponebla por la evolua teamo. La generita metadatumba datumbazo signife reduktas la tempon bezonatan por fari regresan analizon kaj disponigas la kapablon rapide taksi la efikon de ŝanĝoj sur iu ajn tavolo de la IT-pejzaĝo (montrilaj raportoj, agregaĵoj, fontoj).
Kion ĉi tio rilatas al ordinaraj uzantoj de raportoj, kio estas la avantaĝoj por ili? Danke al la kapablo konstrui DataLineage, niaj uzantoj, eĉ tiuj malproksimaj de SQL kaj aliaj programlingvoj, rapide ricevas informojn pri la fontoj kaj objektoj surbaze de kiuj aparta raporto estas generita.
Datumkvalita Kontrola Modulo
Ĉio, pri kio ni parolis supre, pri certigo de travidebleco de datumoj, ne gravas sen kompreni, ke la datumoj, kiujn ni donas al uzantoj, estas ĝustaj. Unu el la gravaj moduloj de nia Data Governance-koncepto estas la datumkontrola modulo.
En la nuna stadio, ĉi tio estas katalogo de ĉekoj por elektitaj entoj. La tuja celo por produkta evoluo estas vastigi la liston de ĉekoj kaj integriĝi kun la raporta registro.
Kion ĝi donos kaj al kiu? La fina uzanto de la registro havos aliron al informoj pri la planitaj kaj realaj datoj de raportpreteco, la rezultojn de finitaj kontroloj kun dinamiko kaj informoj pri la fontoj ŝarĝitaj en la raporton.
Por ni, la datumkvalita modulo integrita en niajn laborprocezojn estas:
- Rapida formado de atendoj de kliento.
- Farante decidojn pri plua uzo de datumoj.
- Akirante preparan aron de problemaj punktoj ĉe la komencaj stadioj de laboro por la disvolviĝo de regulaj kvalitkontroloj.
Kompreneble, ĉi tiuj estas la unuaj paŝoj en konstruado de plenrajta datuma administradprocezo. Sed ni certas, ke nur celkonscie farante ĉi tiun laboron, aktive enkondukante ilojn pri Data Governance en la laborprocezon, ni provizos al niaj klientoj informenhavon, altan nivelon de fido al la datumoj, travideblecon en ilia ricevo kaj pliigos la rapidecon de lanĉo. nova funkcieco.
Teamo de DataOffice
fonto: www.habr.com