Trei principii ale dezvoltării depozitelor de date

Gartner estimează că aproape 70 până la 80% dintre proiectele de business intelligence recent inițiate eșuează. Acest lucru se datorează nenumăratelor motive, de la alegerea proastă a instrumentului până la lipsa de comunicare între IT și părțile interesate de afaceri. După ce am implementat cu succes proiecte de BI în diverse industrii, sper să îmi împărtășesc experiențele în această postare de blog și să evidențiez motivele cheie pentru care proiectele de business intelligence eșuează. Acest articol va prezenta contramăsuri la eșec bazate pe trei principii care ar trebui să guverneze modul în care sunt construite depozitele de date. Urmărirea acestor concepte de depozit de date ar trebui să vă ajute, în calitate de dezvoltator de depozit de date, să navigați în călătoria de dezvoltare, evitând gropile comune sau chiar dolinele implementărilor BI.

Implementare Business Intelligence Data Warehouse

În timp ce criteriile pentru un depozit de date de business intelligence de succes ar varia în funcție de proiect, anumite minime sunt așteptate și necesare pentru toate proiectele. Iată o listă a principalelor atribute găsite de obicei într-un depozit de date de business intelligence de succes:

• Valoare: proiectele de business intelligence se pot întinde pe parcursul mai multor luni sau chiar ani. Cu toate acestea, este important să arătați beneficiile unui depozit de date părților interesate de afaceri foarte devreme în proiect, pentru a asigura finanțarea și interesul continuu. În mod ideal, părților interesate ar trebui să li se arate o valoare comercială semnificativă din noul sistem în primele trei săptămâni ale unui proiect.
• Self-service BI: Zilele de așteptare de la IT pentru a îndeplini cererile de date sau pentru a efectua analize de date s-au încheiat. Succesul oricărui proiect de BI se măsoară acum prin cât de bine dă putere utilizatorilor de afaceri să extragă valoare din sistem.
• Cost: proiectele BI au, în general, costuri de implementare inițiale relativ mari. Pentru a contrabalansa și compensa costul inițial ridicat, este important să proiectați depozite cu costuri reduse de întreținere. Dacă clientul necesită o echipă cu drepturi depline de dezvoltatori BI pentru a asigura/diagnostica problemele de calitate a datelor, pentru a face modificări de rutină la modelele de date sau pentru a gestiona eșecurile ETL, sistemul ar fi costisitor pentru buget și riscă să fie oprit după ceva timp. .
• Adaptabilitate: Abilitatea de a se adapta la cerințele în evoluție ale afacerii este crucială. Este important să țineți cont de numărul nenumărat de instrumente BI care sunt disponibile pe piață și de ritmul în care evoluează pentru a include funcționalități și caracteristici suplimentare. Împreună cu faptul că afacerile evoluează continuu, cerințele pentru depozit se vor schimba; adaptabilitatea necesită ca depozitele de date să fie proiectate pentru a permite utilizarea unor instrumente alternative de BI, cum ar fi diferite back-end-uri sau instrumente de vizualizare, în viitor și să fie adaptabile la schimbări adesea neprevăzute ale cerințelor.

Prin experiența mea în construirea de soluții de succes și, poate și mai important, fiind implicat în proiecte eșuate, am ajuns la concluzia că trei principii cheie sunt esențiale în creșterea probabilității implementării cu succes a unui sistem de business intelligence. Cu toate acestea, înainte de a le acoperi în detaliu, să începem cu un context.

Ce este un depozit de date?

Înainte de a aborda diferite concepte de depozit de date, este important să înțelegeți ce este de fapt un depozit de date.

Depozitele de date sunt adesea considerate ca sisteme de business intelligence create pentru a ajuta cu nevoile de raportare de zi cu zi ale unei entități de afaceri. Ele nu au aceleași cerințe de performanță în timp real (în implementările standard) ca sistemele de date OLTP și, în timp ce sistemele OLTP vor conține doar datele referitoare la un mic subset al afacerii, depozitele de date caută să cuprindă toate datele referitoare la afaceri .

Modelele de depozit de date oferă avantaje unei afaceri numai atunci când depozitul este privit ca centrul central al „toate lucrurile de date” și nu doar un instrument prin care sunt produse rapoartele operaționale. Toate sistemele operaționale ar trebui să aibă o comunicare bidirecțională cu depozitul de date pentru a introduce date și pentru a primi feedback cu privire la modul de îmbunătățire a eficienței operaționale. Orice schimbare a afacerii, cum ar fi o creștere a prețurilor sau o reducere a ofertei/inventarului, ar trebui mai întâi să fie prototipată și prognozată în mediul dvs. de depozit de date, astfel încât afacerea dvs. să poată prezice și cuantifica în mod fiabil rezultatul. În acest context, toate știința datelor și funcțiile de analiză a datelor ar fi centrate în jurul depozitului de date.

Există multe componente ale unui depozit de date și nu este doar o bază de date:

• O bază de date este un mediu prin care vă stocați datele.
• Un depozit de date depășește asta pentru a include instrumente și componente necesare pentru a extrage valoarea de afaceri din datele dvs. și poate include componente precum conducte de integrare, cadre de calitate a datelor, instrumente de vizualizare și chiar pluginuri de învățare automată.

Iată o reprezentare mai vizuală a diferenței dintre o bază de date și o structură de depozit de baze de date. Bazele de date sau noile meta-magazine de date logice, cum ar fi Hive, formează steaua centrală a sistemului stelar al unui depozit de date, cu toate celelalte componente ca planete care se rotesc. Totuși, spre deosebire de un sistem stea, un depozit de date poate avea una sau mai multe baze de date, iar aceste baze de date ar trebui să fie interschimbabile cu noile tehnologii, așa cum vom discuta mai târziu în articol.

Primul principiu al depozitului de date: calitatea datelor domnește suprem

Depozitele de date sunt utile și valoroase doar în măsura în care părțile interesate de afaceri au încredere în datele din interior. Pentru a asigura acest lucru, trebuie construite cadre care captează și corectează automat (acolo unde este posibil) problemele de calitate a datelor. Curățarea datelor ar trebui să facă parte din procesul de integrare a datelor, cu audituri periodice ale datelor sau profilarea datelor pentru a identifica orice probleme legate de date. În timp ce aceste măsuri proactive sunt implementate, trebuie să luați în considerare și măsuri reactive atunci când datele proaste scapă de aceste porți și sunt raportate de utilizator.

Pentru a asigura încrederea utilizatorilor în sistemul de depozit de date, orice date proaste evidențiate de utilizatorii de afaceri ar trebui să fie investigate cu prioritate. Pentru a ajuta la aceste eforturi, linia datelor și cadrele de control al datelor ar trebui să fie integrate în platformă pentru a se asigura că orice probleme legate de date pot fi identificate și remediate rapid de către personalul de asistență. Majoritatea platformelor de integrare a datelor integrează un anumit grad de soluții de calitate a datelor, cum ar fi DQS în MS SQL Server sau IDQ în Informatica.

Profitați de aceste platforme încorporate dacă utilizați un instrument comercial în conductele dvs. de integrare a datelor, dar, suplimentar sau altfel, asigurați-vă că construiți mecanismele care v-ar ajuta să vă mențineți calitatea datelor. De exemplu, majoritatea instrumentelor de integrare a datelor nu au o funcționalitate bună pentru a urmări descendența datelor. Pentru a depăși această limitare, se poate construi un cadru personalizat de control al loturilor folosind o serie de tabele de control pentru a urmări fiecare flux de date care are loc în sistem.

Este foarte dificil să recâștigați încrederea părților interesate de afaceri dacă aceștia se confruntă cu o calitate proastă în platforma dvs., așa că investiția inițială în cadrele de calitate a datelor ar trebui să merite costul.

Al doilea principiu al depozitului de date: Întoarceți triunghiul

Această figură ilustrează împărțirea eforturilor în implementarea și utilizarea majorității depozitelor de date.

Cea mai mare parte a efortului este investit în construirea și întreținerea depozitului, în timp ce valoarea adăugată de a avea un depozit pentru analiza de afaceri este o parte mult mai mică a efortului. Acesta este un alt motiv pentru care proiectele de business intelligence eșuează adesea. Uneori, este nevoie de prea mult timp în ciclul proiectului pentru a arăta clientului orice valoare semnificativă, iar când sistemul este în sfârșit pus în funcțiune, este încă nevoie de mult efort IT pentru a obține orice valoare de afaceri din el. După cum am spus în introducere, proiectarea și implementarea sistemelor de business intelligence poate fi un proces costisitor și îndelungat. Prin urmare, părțile interesate se vor aștepta pe bună dreptate să înceapă rapid să culeagă valoarea adăugată prin eforturile lor de business intelligence și de depozitare a datelor. Dacă nu se materializează nicio valoare adăugată sau dacă rezultatele pur și simplu sunt prea târziu pentru a avea vreo valoare reală, nu prea îi împiedică să tragă de la priză.

Al doilea principiu al dezvoltării depozitului de date este întoarcerea triunghiului așa cum este ilustrat aici.

Alegerea dvs. de instrumente de business intelligence și cadrele pe care le puneți în aplicare trebuie să vă asigure că o parte mai mare a efortului depus în depozit este de a extrage valoarea afacerii decât de a o construi și de a o întreține. Acest lucru va asigura un nivel ridicat de implicare din partea părților interesate de afaceri, deoarece aceștia vor vedea imediat valoarea investiției în proiect. Mai important, permiteți afacerii să fie autosuficientă în extragerea de valoare fără a avea o dependență atât de puternică de IT.

Puteți adera la acest principiu urmând metodologii de dezvoltare incrementală atunci când construiți depozitul, pentru a vă asigura că furnizați funcționalitatea de producție cât mai repede posibil. Urmând strategia de data mart a lui Kimball sau metodologiile de proiectare a depozitului de date Data Vault de la Linstedt vă va ajuta să dezvoltați sisteme care se construiesc progresiv, ținând cont de schimbarea fără probleme. Utilizați un strat semantic în platforma dvs., cum ar fi un cub MS SSAS sau chiar un Business Objects Universe, pentru a oferi o interfață de afaceri ușor de înțeles pentru datele dvs. În cazul primei, veți oferi, de asemenea, un mecanism ușor pentru ca utilizatorii să interogheze datele din Excel - încă cel mai popular instrument de analiză a datelor.

Încorporarea instrumentelor BI care susțin BI cu autoservire, cum ar fi Tableau sau PowerBI, va contribui doar la îmbunătățirea angajamentului utilizatorului, deoarece interfața de interogare a datelor este acum simplificată drastic, spre deosebire de scrierea SQL.

Stocarea datelor sursă într-un lac de date înainte de popularea unei baze de date va ajuta la expunerea datelor sursă utilizatorilor foarte devreme în procesul de îmbarcare. Cel puțin utilizatorii avansați, cum ar fi business quants, vor putea acum să digere datele sursă (prin fișierele brute) conectând instrumente precum Hive/Impala deasupra fișierelor. Acest lucru va ajuta la reducerea timpului necesar afacerii pentru a analiza un nou punct de date de la săptămâni la zile sau chiar ore.

Al treilea principiu al depozitului de baze de date: Plug and Play

Datele sunt pe punctul de a deveni echivalentul digital al petrolului. În ultimii ani, am asistat la o explozie a numărului de instrumente care pot fi utilizate ca parte a unei platforme de depozit de date și a ratei de inovare. În frunte se află nenumăratele instrumente de vizualizare disponibile chiar acum, cu opțiuni avansate pentru back-end-uri aproape în urmă. Având în vedere acest mediu și tendința ca cerințele de afaceri să se schimbe în mod constant, este important să rețineți că ar trebui să schimbați componente ale stivei de tehnologie sau chiar să introduceți/eliminați altele în timp, așa cum o impun schimbările de afaceri și tehnologice.

Pe baza experienței personale, ar fi norocos dacă o platformă ar putea dura 12 luni fără vreo schimbare semnificativă. Un efort rezonabil este inevitabil în aceste situații; cu toate acestea, ar trebui să fie întotdeauna posibilă schimbarea tehnologiilor sau a designului, iar platforma dvs. ar trebui să fie proiectată pentru a satisface această eventuală nevoie. Dacă costul de migrare al unui depozit este prea mare, compania ar putea pur și simplu să decidă că costul nu este justificat și să renunțe la ceea ce ați construit în loc să caute să migreze soluția existentă la noi instrumente.

Construirea unui sistem care să răspundă tuturor nevoilor viitoare imaginabile este imposibilă. Prin urmare, este nevoie de un anumit nivel de apreciere că orice proiectați și construiți acum ar putea fi înlocuit cu timpul atunci când construiți depozite de date. În acest scop, aș susține utilizarea instrumentelor și design-urilor generice acolo unde este posibil, mai degrabă decât cuplarea strânsă a platformei dvs. la instrumentele pe care rulează. Desigur, acest lucru trebuie făcut după o planificare și o analiză atentă, deoarece puterea multor instrumente, în special bazele de date, este în individualitatea lor și în completare strânsă.

De exemplu, performanța ETL este îmbunătățită dramatic atunci când se utilizează proceduri stocate într-o bază de date pentru a crea noi date de analiză de afaceri, spre deosebire de extragerea și procesarea datelor în afara bazei de date folosind Python sau SSIS. În ceea ce privește nivelul de raportare, instrumentele de vizualizare ar oferi anumite funcționalități care nu sunt ușor disponibile în altele - de exemplu, Power BI acceptă interogări MDX personalizate, dar Tableau nu. Ideea mea nu este să susțin abandonarea procedurilor stocate sau evitarea cuburilor SSAS sau Tableau în sistemele dumneavoastră. Intenția mea este doar să promovez importanța de a fi atent în justificarea oricăror decizii de cuplare strânsă a platformei tale cu instrumentele sale.

O altă dolină potențială este în stratul de integrare. Este foarte ușor să utilizați un instrument precum SSIS pentru integrarea datelor dvs. datorită capacităților sale de depanare sau ușurinței de utilizare cu platforma SQL Server. Cu toate acestea, migrarea a sute de pachete SSIS către un alt instrument ar deveni un proiect foarte costisitor. În cazurile în care faceți mai ales „EL”, căutați să utilizați un instrument generic pentru a vă procesa. Folosirea unui limbaj de programare precum Python sau Java pentru a scrie un încărcător generic pentru a vă încărca stratul de staging va ajuta la reducerea pachetelor SSIS individuale pe care le-ați fi cerut altfel. Această abordare nu numai că ajută la reducerea costurilor de întreținere și migrare viitoare, dar ajută și la automatizarea mai multor aspecte ale procesului de integrare a datelor, fără a fi nevoie să scrieți noi pachete individuale (conform Principiului 2).

În toate aceste cazuri, trebuie să decideți asupra unui compromis practic între beneficiile imediate și costurile viitoare de migrare pentru a vă asigura că depozitul nu va fi casat pentru că nu poate face față schimbărilor sau pentru că schimbarea ar fi necesitat prea mult timp, efort sau investiție.

Încheierea

Există multe motive pentru care un anumit sistem de business intelligence poate eșua și există, de asemenea, unele neglijențe comune care pot duce la un eventual eșec. Peisajul tehnologic în continuă schimbare, bugetul limitat pentru sistemele de date din cauza priorității secundare greșite pentru sistemele operaționale și complexitatea și dificultatea absolută a lucrului cu date înseamnă că trebuie să se aibă în vedere nu numai obiectivele imediate, ci și planurile viitoare atunci când se proiectează și construirea componentelor unui depozit de date.

Elementele fundamentale ale depozitării datelor prezentate în acest articol sunt menite să vă ajute să vă ghidați atunci când luați aceste considerații importante. Desigur, luarea în considerare a acestor principii nu garantează succesul, dar cu siguranță ele vă vor ajuta să evitați eșecul.