A mai világban már minden modern vállalkozás jelen van a digitális térben. Minden szervezetnek végig kell haladni a digitalizáció egyes szakaszain – a pénzforgalom alapszintű könyvelésétől a fejlett analitikáig, a prediktív modellezésig és az adatalapú digitális szolgáltatások fejlesztéséig.
A legtöbb vállalat esetében minden Excel munkafüzettel kezdődik. A vállalaton belüli adatforrások száma azonban a növekedéssel párhuzamosan bővül. Számos üzleti alkalmazást is használnak, például CRM-et, ERP-t, vagy WMS-t. Azonban a legtöbb esetében a jelentéseket és a keletkező adatokat még mindig Excel-ben elemzik.
Előbb-utóbb ez ahhoz vezet, hogy túl sok kimutatás készül a különböző rendszerekből exportált adatokból. Minden nap időbe telik manuálisan előkészíteni az adatokat a jelentésekhez, és kihívást jelenthet a különböző rendszerekből származó adatok összevonása. Ha pedig frissíteni kell a múltbeli időszakokra vonatkozó adatokat, akkor az igazi rémálommá válhat. A hibák megtalálása is ugyanilyen bonyolult, ehhez is manuálisan kell feldolgozni a jelentésekhez szükséges adatokat. Sok esetben gyakorlatilag egyszerűbb lenne teljesen újrakezdeni az egész riportot.
Még az Excel is jobb, mint a semmi
Első lépésként mindig interjút kell készíteni a vállalaton belül, azokkal a területekkel, akiknél vagy adatok keletkeznek, riportot készítenek, vagy a riportokat felhasználják. A hivatkozott cikkben lévő esetben is így tettek és kiderült, hogy az alkalmazottak az Excel munkafüzeteket használták forrásként, amelyeket betöltöttek Power BI-ba és ez alapján hoztak létre riportokat és vizualizációkat.
Ez természetesen nem a leghatékonyabb módszer, hiszen a legtöbb esetben lehetőség van közvetlenül az ERP rendszer adataihoz kapcsolódni és a számításokat is sokkal könnyebben el lehet végezni Power BI-ban.
Ezt követően áttekintették a meglévő jelentéseket és összehasonlították az adatforrásokkal. Ekkor derült ki, hogy nem csak Excel munkafüzetekből töltöttek be adatokat, hanem más forrásokat is használtak – olyan fájlokat, amelyek tervezési adatokat és jelentéseket tartalmaztak külső felhőalapú SaaS-ekből. Még a saját járműflottájuk mozgásáról szóló jelentéseket tartalmazó, a GPS-követő szolgáltatótól származó exportált PDF-fájlokat is felhasználták.
Éppen emiatt készítettek egy Excel fájlt, amely tartalmazta az összes forrást és azok tulajdonságait (hozzáférési módszer, szemcsézettség, frissítési sebesség, változás-előzmények stb.). Ezek tulajdonképpen a metaadatok voltak, erre a célra azonban létezik egy egyedileg kifejlesztett szoftver, az adatkatalógus. Ahhoz azonban, hogy az adatkultúrát meghonosítsuk egy vállalkozásban, kicsiben kellett kezdeni. Az Excel-fájl pedig tökéletes első lépés a jövőbeli katalógus felé.
Architektúra
A felhasznált adatokat rendszeresen ki kellett nyerni a forrásokból, és ezeket folyamatosan frissíteni kellett manuálisan. Az adatoknak az elemzők számára is a legrészletesebb szinten kellett rendelkezésre állniuk, mert ad hoc jelleggel kellett riportokat előállítani, nem lehetett tudni, hogy mikor milyen jelentéseket várnak el tőlük.
Az eddigiek ismeretében, a felmérés során elvetették a vállalati adattárház fejlesztésének klasszikus megközelítését. Úgy döntöttek, hogy nem hoznak létre egységes adatmodellt tényekkel, mérésekkel és előre meghatározott képletekkel a kimutatások kiszámításához. Arra jutottak, hogy a legmegfelelőbb architektúratípus ebben az esetben a „Data Lake” volt. Természetesen a Data Lake architektúrának is megvannak az előnyei és hátrányai és mindig meg kell vizsgálni, hogy a mi esetünkben biztosan ez-e a legjobb megoldás.
A Data Lake architektúra különböző szoftverek segítségével valósítható meg, például egy nyílt forráskódú, Apache komponenseket használó stack segítségével. A cikkben szereplő példában az ügyfél már rendelkezett előfizetéssel a Microsoft Azure-ra, és az üzleti alkalmazások egyes részeit olyan felhőszolgáltatásokon keresztül használta, mint például az MS Dynamix 365. Meg kell jegyezni, hogy az MS Azure az elmúlt évek során jelentős fejlődésen ment keresztül, és ma már minden szükséges eszközt tartalmaz a vállalati analitikai és Big Data rendszerek fejlesztéséhez. Ezért úgy döntöttek, hogy a rendszert az MS Azure segítségével állítják fel.
A részletes adatok tárolására Serverless SQL Poolt, az adatmárkákhoz Dedicated SQL Poolt, az adatok kinyerésére, átalakítására és betöltésére (ETL) pedig Synapse Pipelines eszközt használtak. A Power BI mindkét adattárolási réteghez csatlakozhat adatimport módban és élő lekérdezési módban is, vagyis a felhasználók nem korlátozottak a további adatfeldolgozásban, lehetőség van DAX mértékek írására.
Együk a tortát apránként
Egy projektet sok féleképpen meg lehet valósítani és a megvalósítás során különböző módszertanokat lehet alkalmazni. Az biztos, hogy senki sem szeret hosszú műszaki követelményeket összeállítani és mindenki minél gyorsabb eredményt szeretne. Ezért a cikkben taglalt projekt esetében úgy döntöttek, hogy rövid iterációkban, agilis fejlesztési stílusban valósítják meg a projektet.
Egy BI-rendszer kiépítésére irányuló projektet meg lehet valósítani rövid sprintekben. Például lehet kezdeni az összes adatforrás feldolgozásával, és minden iterációban hozzáadhatunk egy új feldolgozási szakaszt. Egy sprint irányulhat az operatív adattárolóba történő kezdeti betöltésre, egy az adattárházba történő betöltésre, és további sprinteket lehet kijelölni a Data Mart-ban lévő jelentések elkészítésére.
Ebben az esetben Data Lake architektúrát használtak. Összesen csak két réteg volt, de több tucat adatforrás. Ez azt jelentette, hogy logikus volt sprintekre bontani a munkát, minden sprintben több forrást is bevittek, és a teljes fejlesztési folyamatot elvégezték – az összeszereléstől a kész Data Mart-ig.
Emellett ez a felhasználók számára is nagyon kényelmes, mivel gyakran előfordul, hogy 2-3 forrásból állnak össze az adatok egy jelentéshez. Így az egyes iterációk eredménye olyan adatokat szolgáltat az elemzőknek, amelyekkel egy vagy több meglévő jelentést át tudnak vinni a Data Lake-be. Ez lehetővé teszi az adattárház használatára való fokozatos átállást, és elkerülhető, hogy a nagy mennyiségű adat rövid időre történő ellenőrzése elterelje a figyelmüket a munkájukról.
Végül minden egyes iteráció a következőkből állt:
- egy adapter kifejlesztése az adatok kinyeréséhez
- kezdeti betöltés
- az adatfrissítési folyamat konfigurálása
- Data Mart kiszámítása
- a Data Mart-ban lévő adatok felhasználók (elemzők) általi ellenőrzése
- a jelentések Excelből Azure Synapse-ra történő átállítása
Ebben a projektben összesen 37 adatforrás-rendszert kapcsoltak össze. Ebben voltak Excel-táblázatok, relációs adatbázisok, külső szolgáltatások API-val és más források.
Hibákból való tanulás
Természetesen egyetlen agilis fejlesztési folyamat sem megy hibák és stabilizálás nélkül. Éppen ezért az azonnali eredmények helyett, ők inkább a mélyreható elemzést választották. Világossá vált, hogy költséges dolog lenne az összes adatot a Data Lake-ből egy dedikált SQL Pool-ba helyezni.
Javasolták, hogy a Power BI jelentéseket Direct Query helyett adatimportálással töltsék be, azért hogy pénzt takarítsanak meg az ügyfélnek. Az előre elkészített adatok így a Power BI adatmodellben tárolódnának, ezért nem okoznának fogyasztást tárolási szempontból, és a Pool elérhetőségétől függetlenül rendelkezésre állnának.
Ezen túlmenően konfigurálták az adatkészletek frissítésének beállításait az összes jelentéshez, beleértve az adatfrissítést is (a Synapse Pipelines segítségével). Majd végül a Dedikált SQL szolgáltatás aktiválásának és deaktiválásának ütemezett beállítását is meg kellett oldani. Mindezek hatására a szolgáltatás költségei közel négyszeresére csökkentek.
A második hiba a vállalat saját járműparkjának mozgására vonatkozó adatok kinyerésére szánt külső SaaS-szel való együttműködés volt. Ahogy az gyakran előfordult, a szolgáltatás az adatokat egy JSON formátumú API-n keresztül szolgáltatta. Azonban ennek a JSON-nak a formátuma nem volt teljesen megfelelő. Kisebb méretű adatoknál ez még nem jelentett problémát, de amint ügyfél részletes GPS-koordináták betöltését kérte minden egyes útra, kiderült, hogy az Azure Pipelines szabványos eszközei nem használhatók a helytelenül formázott JSON-nal való munkához. Erre a megoldást az SQL és a JSON-szövegek kötegelt betöltése jelentette.
Mellettük még egy másik problémával is találkoztak, ami szintén egy külső szolgáltatás volt. Valamilyen belső okból kifolyólag visszavonta az összes engedélyezési kulcsot, ezért az ETL-folyamatok a szokásos adatok helyett hibaüzeneteket (HTTP 403) kezdett kapni. Ez még nem is lenne olyan nagy probléma, azonban sok API nagyon instabil tud lenni, ezért meg kellett változtatni a konfigurációt. Úgy sikerült megoldani ezt a problémát, hogy a percenként lekérdezést 30-ban maximalizálták.
Konklúzió
Ennek a rendszernek a legnagyobb előnye a kézi adatfeldolgozásból adódó munkaerő-hónapok vagy akár munkaévek megtakarítása. Természetesen ez egy vállalkozás számára elég sokba kerülhet, de a fő előny valami más. A legnagyobb előny az, hogy a felsővezetői kérés és az adatelemzés megtörténte elkészülte között az idő jelentős mértékben csökken. Mostanra lehetővé vált, hogy szinte bármilyen elemzési igényt egy munkanapon belül teljesíteni lehet. Ezt az időmegtakarítást pedig nagyon nehéz alábecsülni a vállalati döntéshozatal szempontjából.
Természetesen előfordulhatnak olyan esetek, amikor az adatmodellben nincs elegendő adat ahhoz, hogy megválaszoljon egy vezetői kérését. Szerencsére azonban a Power BI lehetőséget biztosít arra, hogy mindössze néhány kattintással új forrást csatlakoztassunk az adatmodellhez. Összességében elmondhatjuk, hogy a Data Lake elemző rendszerek a digitalizáció valamiféle új lépcsőfokává váltak. Mostantól az elemzők úgy láthatják el a feladataikat, hogy munkájuk során közelebb kerülnek az önkiszolgálás elvéhez, a felső vezetés pedig mindig naprakész információkhoz férhet hozzá a gyors és pontos döntéshozatalhoz.
Forrás: towardsdatascience