Oracle adatbázis-kezelő rendszer és MPP adatbázisok (PDF)

1. Mutassa be az Oracle adatbázis-kezelő rendszer felépítését! Válaszában térjen ki a következőkre: a. Az Oracle adatbázis-kezelő rendszer architektúrája (tároló és memória struktúrák, folyamatok) b. A B-fa és Bitmap indexstruktúrák felépítése és működése _________________________________________________________________________________ a) Oracle architektúra  Fájl típusok o Vezérlő (control) fájl:  Az adatbázis konfigurációját tárolja.  Automatikusan módosul, ha új fájlt adunk az adatbázishoz.  Érdemes legalább három másolatot tartani, a szinkronizálást az Oracle automatikusan elvégzi. o Helyreállítási napló (redo log) fájlok:  a helyreállításhoz szükséges napló információkat tároljuk benne.  Érdemes különböző lemezeken több másolatot tartani belőle.  A naplóíró folyamat (log writer process) felel azért, hogy a memóriából a napló adatok kiíródjanak a diszkre. o Adatfájlok: az adatbázisban tárolt adatok szerepelnek benne o Paraméterfájl: olyan paraméterek, melyek befolyásolják egy példány méretét és tulajdonságait o Jelszófájl: a rendszergazdák (SYSDBA) jelszava  Fizikai tárolás Egy tábla adatai adatblokkokban vannak tárolva, a fizikailag egymás után elhelyezkedő adatblokkok halmaza az extens. A szegmens több extensből épül fel, amelyek ugyanahhoz az objektumhoz tartoznak. Egy táblatér több szegmensből állhat, az adatbázis több táblatérből épül fel. Egy táblateret egy vagy több fizikai fájlban lehet tárolni. A SYSTEM és SYSAUX táblaterek rendszerfunkciók ellátására szolgálnak, felhasználói adatok tárolására ezeket ne használjuk! Tábla adatai  adatblokkok  extens (több egymás utána adatblokk)  szegmens (több extens)  táblatér  adatbázis (egy vagy több fájlban tároljuk)  Memória struktúrák o PGA (program global area):  memóriaterület a szerveren, ami kizárólag egy adott szerver processhez tartozik.  Itt tárolódnak a futásidőben szükséges adatok, pl. rendezés, csoportosítás, join köztes adatszerkezetei. o SGA (system global area):  a példányhoz tartozó, közös memóriaterület  minden server process el tudja érni. SGA részei:  Database Buffer Cache: o itt tárolódnak le a diszkről kiolvasott adatok. Ha az adat módosul, ide menti le, majd ennek a tartalmát írja ki a diszkre  Redo Log Buffer: o az a memóriaterület, ahova a redo log naplóadatok először beíródnak. o Körpuffer szerkezete van.  Shared Pool: o Library Cache: ha megkap egy SQL lekérdezést a szerver, ahhoz hash-el generál egy ID-t és a lekérdezés az ID-val tárolódik a Shared Pool-ban, valamint a hozzá tartozó Execution Plan is. Ha újra ugyanez a lekérdezés érkezik a szerverhez, ezt olvassa ki, nem kell újra lefordítania. o Data Dictionary Cache: a data dictionary-t nagyon gyakran kell lekérdezni, ezért a feléje érkezett lekérdezések és eredmények itt eltárolódnak, hogy ha új kérés jön, ami egy ugyanolyan DD adatot kér, akkor innen ki tudja olvasni. Legfontosabb processek: o DBWn: database writer process, azért felel, hogy a memóriából kiíródjanak a tábla adatok a diszkre. o LGWR: log writer, a naplóinformációk kiírásáért felelős a redo log bufferből a redo log fájlokba. o SMON: system monitor, adatbázis karbantartási feladatok b) B-fa index és Bitmap index B-fa index: a hagyományos index B-fa szerkezetű. Két fajta csúcsa van:  Levélcsúcsok o A levél csúcs tartalmazza a kulcsértékeket (tábla oszlopának/oszlopainak tartalma, pl. ha a department_id oszlopra építettük az indexet, akkor a részlegazonosítók), illetve a kulcsértékeket tartalmazó rekordok ROWID-it. o Tehát a levél csúcs mutatja meg a keresett sor helyét a táblában. o A levélben a kulcsértékek növekvő vagy csökkenő sorrendben rendezetten helyezkednek el.  Belső csúcsok (a gyökér elem is ilyen). o A belső csúcsok a navigációt segítik, azaz hogy kevés lépésben eljussunk az adott kulcsérték bejegyzéshez. Bitmap index: itt is kulcsértékek vannak a levelekben, de itt nem ROWID-k, hanem ROWIDtartományok és az azokra vonatkozó Bitmap-ek kapcsolódnak hozzá. Minden sornak egy bit felel meg, ami azokra a sorokra lesz 1-es, amelyek az adott értéket tartalmazzák. Egy megfelelő oszlop(ok)ra épített index gyorsíthatja egy adott lekérdezés futtatását, azonban nem minden lekérdezést gyorsít! Ugyanakkor viszont a tárolása tárkapacitást emészt fel, és karbantartási költsége is van (azaz az adott oszlopot érintő DML műveleteket lassítja). 2. Ismertesse a lekérdezés optimalizálás szempontjait és folyamatát! Válaszában térjen ki a következőkre: a. Végrehajtási terv elemzése, access path-ok, join módszerek b. A Shared Pool Check működése c. Hintek, kardinalitás, statisztikák, hisztogram típusok Végrehajtási terv elemzése:  Szintaktikai ellenőrzése a kiadott utasításnak.  Szemantikai ellenőrzése: létező objektumokat akaroke lekérdezni, értelmes-e logikailag.  Shared Pool Check: Generál egy Hash kódot az utasításhoz. Ezt utána megvizsgálja, hogy megtalálható-e a már létező ID-k között, azaz volt-e már korábban kiadva az utasítás. Akkor az SQL szerver nem generálja le a végrehajtási tervet, mert régebben már megtette és letárolta. Ilyenkor előveszi a meglévő végrehajtási tervet és ezt hívjuk Soft Parse-nek. Ha nincs letárolva ilyen végrehajtási terv, akkor optimalizálnia kell, le kell generálnia egy row source-t és úgy ad eredményt. Ezt hívjuk Hard Parse-nak.  Optimization: itt megtervezi az optimális végrehajtást a végrehajtási terv segítségével. Ide kapcsolódik a CBO (Cost-Based Optimization), mely egy futási módja a SQL szervernek, ez az alapértelmezett Oracle-nél. Több végrehajtási terv készül el ilyenkor és a legkisebb költségűt választja ki. Költséget a tárolt adatok statisztikái alapján számolja ki.  Row Source Generation: az optimális végrehajtási tervhez legenerálja a kódot, amit ha lefuttat, megkapjuk a végeredményt. Access path: egy hozzáférési mód, hogy hogyan olvassuk ki a Row source-t. Ez egy unáris művelet: egy Row source a kimenet és egy Row source a bemenet. Access path típusok:  Táblák kiolvasására szolgáló módszerek Full Table Scan, Table Access by Rowid, Sample Table Scan  B-fa indexek kiolvasására szolgáló módszerek Index Unique Scan, Index Range Scan, Index Full Scan, Index Fast Full Scan, Index Skip Scan, Index Join Scan  Bitmap indexek kiolvasására szolgáló módszerek Bitmap Index Single Value, Bitmap Index Range Scan, Bitmap Merge Table clusters: Cluster Scan, Hash scan Join típusok:  Nested loop join: van két for ciklus (egymásba ágyazott): az első táblának fogja az első sorát és megnézi, hogy ahhoz mennyi hozzátartozó sor van a másik táblában. Általában a kisebb row sourcet választja külsőnek. o ha a row source-ok kevés rekordból állnak (kis tábla) o ha FIRST_ROWS módban vagyunk (nem a teljes eredményhalmazt hanem csak az első néhányat akarom visszakapni) o ha hatékonyan tudjuk olvasni a belső row source-t (arra van index készítve) o ilyenkor nem feltétlenül fut ténylegesen két ciklus, ha a belső ciklus kiváltható index olvasással  Sort-merge join: rendezi a feltételre vonatkozóan a táblákat és egy ideiglenes táblába eltárolja a két táblát. Ezeken a rendezett táblákon megy végig az összefuttatáshoz hasonló módszerrel. o nagy adathalmazokra alkalmazza, ha:  van megfelelő index a külső row source-ra, ezért nem kell rendezni  vagy ha amúgy is rendezni kell a lekérdezésben szereplő order by miatt, azt itt fel tudja használni  vagy ha nem equijoinról van szó, hanem egyenlőtlenségi feltétellel kapcsoljuk össze  Hash join: a kisebb táblára join kulcs szerint generál egy hash táblát, amikor keresi a másik (nagyobb) táblához tartozó sort a másik táblában, akkor veszi a hash alapján letárolt értéket. o egy nagy és egy kisebb adathalmaznál o ha equijoin-t használunk o ha a kisebbik adathalmaz belefér a memóriába, akkor különösen gazdaságos  Cartesian join (cross join): olyan join, ahol nincs összekapcsolási feltétel, minden sort minden sorral párosítunk (Descartes-szorzat). Nem önálló módszer, az előzőek közül valamelyikkel állítja elő. o ha nincs join feltétel o ha olyan sorrendet alakítunk ki több tábla között (hinttel kényszerítve), hogy a szomszédos tábláknak nincs közvetlen kapcsolata o ha ez a hatékony megoldás (ha két kicsi táblát join-olni kell egy nagy táblára, akkor célszerűbb előbb a két kis táblára cartesian joint végezni, és az eredményt a joinolni a nagy táblára) o ha ilyet észlelünk, érdemes átvizsgálni a lekérdezést, hogy biztos jól írtuk-e meg a tábla összekapcsoló részt Statisztika: mindenről tárol plusz információt, hogy az optimalizálót segítse a helyes döntésben:  táblák: hány sora van, hány blokkban tárolódnak az adatok  oszlopok: különböző értékek (Number of Different Values) - ha egy oszlopra van WHERE feltétel és van rajta index is, NULL-ok száma, adatok eloszlása  indexek: levél blokkok száma, famagasság stb.  rendszerről: I/O, CPU teljesítmény és kihasználtság Hisztogramok: a CBO alapból egyenletes eloszlásúnak feltételezi az adatokat, azaz az előforduló különböző értékekből kb. ugyanannyi van egy oszlopban. Ha ez nem így van, akkor a JOIN és szűrő kifejezések becslése pontatlan lehet. Hisztogram: A hisztogram azt mutatja meg, hogy melyik érték milyen gyakori egy oszlopban. Ez segítséget ad a kardinalitás becslésében. A hisztogramok fő típusai: height-balanced, frequency, hybrid. Kardinalitás: hány sorból fog állni az adott művelet eredményeként kapott row source. Hintek Ki tudunk kényszeríteni bizonyos fajta eljárást a végrehajtási tervben, adhatunk tippeket az optimalizálónak. Inkább csak tesztelésre érdemes használni. Szintaktikailag a hint egy speciális komment, amely következhet SELECT, UPDATE, INSERT, MERGE vagy DELETE után: SELECT... 3. Mutassa be az MPP (Massively Parallel Processing) adatbázisokat! Válaszában térjen ki a következőkre: a. Az MPP architektúra, az SMP és MPP architektúra közti különbségek, horizontális és vertikális skálázhatóság b. Adatelosztási stratégiák c. A Teradata komponenseinek bemutatása, data temperature, primary key, primary index SMP (Symmetric Multi Processor) Systems architektúra:  A klasszikus adatbázis rendszerek SMP alapúak.  Több processzor szolgál ki egy időben több process-t.  Mindegyik process egy processzorhoz van rendelve, de a processzorok közösen használják a system bus-t, a memóriát, tárolóegységet.  Az SMP vertikálisan skálázható. MPP („shared-nothing”) architektúra:  Controller (Head) Node: csak egy van belőle, metadata-t tárol és a data dictionary-t. Nyilvántartja, melyik Data Node tárol egy adott adatot, amit szeretnénk elérni.  Data Node: van több DN is, az adatokat szétosztva tárolják.  Shared-nothing: ezek a DN-ok különálló egységek és nem osztoznak egymás között a memórián, diszken. Minden DN-nek megvan a saját CPU- ja, memóriája és diszkje.  A DN-ek egyszerre dolgozhatnak ugyanazon a lekérdezésen. Több processzor párhuzamosan futtat egy folyamatot.  Horizontálisan skálázható: újabb Node-okat tudunk hozzácsatolni a rendszerhez és így növeljük az erőforrást. Adatelosztási stratégiák MPP rendszerekben A Head Node többféle stratégia szerint szétoszthatja egy tábla adatait a Data Node-okra:  Hash distribution: o A fejlesztő kiválaszt egy oszlopot a tábla létrehozásakor (distribution column), ezen oszlopérték alapján osztja szét a rekordokat a Head node a DN-okra: lefuttatja rajta a hash függvényt és az eredmény határozza meg, hogy melyik DN-ra kerül az adat. o Egyes DNok terhelése a distribution column megválasztásán múlik, akár nagyon aránytalan is lehet.  Even distribution / Round robin: o i-edik rekordot az i mod n DN-ra írja o egyenletes szétosztást garantál.  Range partition: o Egy kiválasztott oszlop értékeire intervallumokat határoz meg és ez alapján osztja szét a rekordokat. Ha a rekord érték egy adott intervallumban van, akkor az annak megfelelő DN-ra kerül. (pl. a könyvtár könyveinek szétosztása betűrend szerint)  Split on all: o kis tábláknál érdemes ezt választani o a tábla rekordjait rámásolja az összes DN-ra. o gyorsan join-olhatók a rekordok így MPP rendszer működése: 1. A kliens felveszi a kapcsolatot a Controller Node-al. 2. A CN az adatkatalógusa alapján (data dictionary) meghatározza az Execution Plant-t és a kérést továbbítja a DN-eknek. 3. A DN-ek párhuzamosan végrehajtják a saját adataikon a lekérdezést., majd visszaküldik az eredményt a CN számára, ami összegyűjti az eredményeket, majd továbbítja a kliensnek. Az írás és az olvasás párhuzamosan történik. Self managed adatbázisok: amikor ott van a hardver a cégnél, azon van az RDBMS, az adatok is itt vannak. Pl.: Teradata Teradata rendszer-komponensek, és bemutatásuk  Node: alapegysége a TeraData-nak. Minden Node-nak saját OS-e, processzora, memóriája, diszk komponense van. Több node egy kabinetté csatolható.  PE: CN helyett Parsing Engine van. A PE egy virtuális processzor, itt van a session felügyelete. A PE átveszi az SQL utasítást, megnézi, hogy helyes- e, benne van az optimalizáló. Ő osztja szét íráskor az adatokat is az AMP- kre.  BYNET: Nagy sebességű hálózat, összekapcsolja és kommunikál az összes AMP-vel és PE-vel a rendszerben. Nagy teljesítményű, hibatűrő, kiegyensúlyozott terhelésű, skálázható.  AMP (hozzáférési modul processzor): Az AMP-k a Teradatában a DN megfelelői. Képesek párhuzamosan dolgozni a kéréseken. Kezelik az általuk tárolt adatokon a tranzakciókat. Az AMP-ek előkészítik az adathalmazt, amit visszaküldenek a PE-nek, az előszortírozás, aggregálás is az AMPen történik.  VDISK: lemezek, adatokat tárolnak, saját AMP-hez kapcsolódnak Adathőmérséklet („Data Temperature”): Azokat az adatokat, amiket sűrűn olvasnak a felhasználók, egy gyors (de drága) tárolóegységen tartjuk (pl.: SSD), míg a ritkán használtak kerülhetnek lassabb (olcsóbb) diszkre. Cél: a gyakori adatok kiszolgálása gyors lemezről történjen. o az adat, amiket gyakran kérdeznek le (hot adatok) o kevésbé gyakran (warm) o nagyon ritkán (cold) Primary Key: ugyanaz a Teradata esetén, mint az RDBMS-ben. Ez azonosítja egyértelműen a sorokat a táblában. Erre alapból nem épül fel az index, külön meg kell adni. Nem muszáj PK-t megadni. Primary index: a primary index érték hash képe mutatja meg, hogy melyik AMP-re kerül a sor. Kötelező definiálni. o Unique Primary index: egy oszlopban egy érték csak egyszer fordulhat elő (egyedi) o Non-Unique Primary Index: egy oszlopban egy adott érték többször is előfordulhat Az egyedi Primary index egyenletes elosztást garantál, míg a Non-Unique esetben kialakulhat egy nem kiegyenlített elosztás, ezáltal az AMP-k aránytalan terhelése. Az AMP-n a sorok rendezve vannak a row hash alapján. 4. Mutassa be NoSQL adatbázisok jellemzőit és típusait! Válaszában térjen ki a következőkre: a. Konzisztencia: CAP tétel, ACID vs. BASE b. Horizontális és vertikális skálázhatóság c. Adatelosztás típusok d. A NoSQL adatbázisok különböző típusainak jellemzői, adatmodellje A CAP tétel Az elosztott rendszerek esetén az alábbi három követelmény közül maximum kettőt tudunk mindig garantálni:  Consistency: egy clusternél az adatok minden csomóponton egy adott pillanatban egyformák (a különböző node-okon egyforma adatokat találunk – replikáció)  Availability: egy clusterben mindig kapok választ az adatlekérdezésre, DE nem garantált, hogy a legfrissebbet. (a response time megfelelően gyors, ez persze függ attól, hogy a feladat alapján milyen válaszidőket várunk el)  Partition tolerance: ha van egy cluster és a clusternek egyes csomópontjai elhalnak, akkor elérhető-e a rendszer vagy nem. Egy elosztott rendszernél ez mindig elvárás! ACID tulajdonságok (ABKR esetén)  Atomosság (Atomicity): a tranzakció összes elemi utasítását vagy végrehajtjuk vagy egyet sem (mindent vagy semmit). Másképp: A tranzakcióba bevont DML utasításokat egy egységként kell kezelnie az adatbázis-kezelőnek.  Konzisztencia (Consistency): a tranzakciót követően is teljesülnek az adatbázisban előírt konzisztencia megszorítások (integritás megszorítások), azaz az adatelemekre és a közöttük lévő kapcsolatokra vonatkozó elvárások.  Elkülönítés (Isolation): ha több tranzakció fut párhuzamosan, egyszerre és ezek az utasítások keverednek, a tranzakciók végén az állapot olyan, mintha nem keveredtek volna (úgy kell lefutnia, mintha azalatt semmilyen másik tranzakciót nem hajtanánk végre)  Tartósság (Durability): ha befejeződött egy tranzakció, annak az adatbázisban kifejtett hatása nem veszhet el. Másképp: A lezárt tranzakciók eredménye nem veszhet el. BASE (NOSQL) Túl szigorú az ACID a NOSQL technológiákra, így kialakítottak egy új feltételrendszert. Ez sokkal kevésbé szigorú követelmény a tranzakciókra vonatkozóan.  Basic Availability: az adatbázis alapvetően elérhető (a kisebb kiesésekből gyorsan, automatikusan helyreáll)  Soft state: nem kell minden pillanatban konzisztensnek lennie az adatoknak a masterrel (hiszen a replikáció időbe telik), a rendszer állapota direkt beavatkozás nélkül is változhat, ahogy a módosítások továbbterjednek a clusterben  Eventually Consistent: a replikáció lezajlása után majd valamikor konzisztens lesz az egész cluster A 2 fő adatelosztás típus NoSQL adatbázisokban Sharding: az adatokat szétosztja különböző node-okra úgy hogy minden node-ra egyedi adathalmaz kerül (nem másolja, hanem szétosztja). Pl.: tábla rekordjai közül 5 rekord az egyikre, 5 a másikra. Replikáció: az adatokat több node-re rámásolja (a teljes adathalmaz több példányban létezik). Master-Slave: van egy master, ahová írni és olvasni is lehet és vannak slave-ek, melyekről csak olvasni lehet, a slave szerverek folyamatosan szinkronizálódnak a masterrel. Peer to Peer: mindegyik node egyforma rangú és mindegyikre lehet írni és olvasni is róluk. A node kezeli a másolatainak a szinkronizálását. (Van olyan rendszer, ahol a két koncepció egyszerre működik, pl. a Neo4j Causal Clusterben) Van olyan rendszer, ami mindkettőt tudja. Vertical scaling és horizontal scaling  Vertical scaling (scale up): egy szerverhez kapcsolódó komponenseket tudjuk cserélni, fejleszteni; több, jobb, gyorsabb erőforrást (CPU, memória, diszk) adunk a géphez.  Horizontal scaling (scale out): újabb node-okat (azaz komplett szervereket) tudunk hozzácsatolni a rendszerhez és így növelhetjük az erőforrást a bevont node-ok számával arányosan.  Key-Value store: kulcs-érték pár tároló pl.: Redis  Column store: oszloptároló pl.: HBase  Document store: dokumentumtároló pl.: MongoDB  Graph store: gráf adatbázis pl.: Neo4J 5. Ismertesse a dokumentumtároló típusú NoSQL adatbázis-kezelő rendszereket! Válaszában térjen ki a következőkre: a. A dokumentum adatmodell, JSON és BSON b. A MongoDB architektúrája: node típusok, replica set, replikáció és sharding c. A MongoDB működése: az olvasás és írás folyamata, primary node kiesésének kezelése BSON, JSON  JSON o univerzális fájlformátum, sok nyelv támogatja, emberi szemmel is könnyű olvasni és átlátható  BSON o a JSON bináris formátuma. o Sokféle típusú adatot képes tárolni (stringek, számok, dátumok, object, array, stb.) o A MongoDB a JSON dokumentumokat bináris kódolású formátumban, BSON formátumban kezeli. A MongoDB architektúra komponensei  Replica set:  mongod process-ek egy csoportja (mongod: kérések kiszolgálása, adatok menedzselése), nem kell ugyanabban az adatközpontban lenniük!  1 primary node + egy vagy több secondary. A primary és a hozzá tartozó secondary(k) ugyanazt az adathalmazt tárolják (replikáció). A kliens a primary-re kapcsolódik.  Master-slave elvű a működés.  Aszinkron a kommunikáció, azaz mindig van egy kis idő, amíg a változások átkerülnek a primaryról a secondary-ra.  Primary node kiesés: Ha a primary több mint 10 másodpercig nem válaszol, szavazással új primary-t választanak maguk közül a secondary-k. Akkor nyerhet egy adott node, ha a szavazatok több mint felével rendelkezik. Egyéb lehetséges node típusok:  Arbiter: o nem kap adatokat a primary-től és nem fogad el kérést o biztosítja a többségi szavazatokat valamelyik secondary számára a primary kiesése esetén.  Hidden node: o Fenntartja az elsődleges adatkészlet másolatát, de nem látható a kliensek számára, tehát nem lehet róla olvasni. o A hidden tagok nem válhatnak primary-vá. o Hot backup funkcióval bírnak.  Sharding: o Az adatok szétosztása több gép között egy kulcs alapján. o A shard key olyan mező, ami a gyűjtemény minden dokumentumában szerepel. Léteznie kell indexnek erre a kulcsra, sharding után már nem lehet megváltoztatni a kulcsot, sem az értékeit! o A sharding collection szinten történik. A kliens ilyenkor nem a sharded cluster egyik shardjához csatlakozik közvetlenül, hanem egy routing folyamathoz (mongos). Írás, olvasás Az írás kéréseket a primary kezeli. A primary rögzíti a változást az operation log-ba (oplog, egy speciális collection). A secondary(k) replikálják a primary oplog-ját, és alkalmazzák a saját tárolt adataikra. 6. Ismertesse a gráfadatbázis típusú NoSQL adatbázis-kezelő rendszereket! Válaszában térjen ki a következőkre: a. A gráf adatmodell (Labeled Property Graph és RDF) b. A Neo4j architektúrája: szerver típusok és azok szerepe, adatelosztás c. Neo4j adattárolás és feldolgozás: native graph storage, index-free adjacency Labeled property graph adatmodell  Gráf adatmodell, tehát csúcsokból és élekből indul ki. A csúcsoknak és a kapcsolatoknak lehetnek tulajdonságaik (kulcs-érték párok: property).  Egy csúcshoz tartozhat többféle címke (label) is. Ezzel csoportosítani lehet a csúcsokat, sokszor "típusként" funkcionál, azonban szerkezeti megkötést nem jelent.  Könnyen hozzáférhető, könnyen értelmezhető és sok mindent lehet vele modellezni. Nem kötött a séma, egy csúcshoz vagy kapcsolathoz különböző tulajdonságok kapcsolódhatnak. Pl. a Neo4J is ezt használja. Adattárolás és adatfeldolgozás Native graph processing: az adatbázis a kapcsolatok modellezésére és bejárására index-free adjacency-t használ. Minden node-hoz el van tárolva az index már, így külön indexre nincs szükség. Ezáltal nagyon gyorsan tudunk mozogni a gráfban. Native graph storage: A gráf adatok kifejezetten gráf tárolására optimalizált szerkezetben vannak. Külön fájlban vannak a node-ok, a kapcsolatok stb. Ez is azt a célt szolgálja, hogy minél könnyebben és gyorsabban tudjunk mozogni a gráfban. Architektúra Clustering A Neo4j esetében két funkciója van a clusternek: terhelés elosztás és hibatűrés. Az egyes cluster node-ok vagy core serverek, vagy replica szerepet töltenek be. A core serverek feladata, hogy stabillá tegyék a rendszert (olvasás és írás). A replicák a skálázási célt szolgálják, csak read requesteket fogadnak. Így elosztjuk a userek igényeit. A replicák elkérik a core serverektől a változásokat bizonyos időnként. Replikáció Itt csak replikáció van, azaz minden egyes szerverre rámásoljuk a teljes adatbázist. Ha nagyon sok lekérdezés, nem csak egy gépről tudnak olvasni, hanem többről is, így az terheléseloszlás biztosítva van. Ha kiesnek gépek, egy bizonyos pontig akkor is elérhető az adatbázis és működnek a lekérdezések. Sharding A Neo4j-ben nincs sharding. Azaz a gráf részeit nem lehet különböző szerverekre elhelyezni. 7. Ismertesse az oszloptároló típusú NoSQL adatbázis-kezelő rendszereket! Válaszában térjen ki a következőkre: a. Az HBase logikai és fizikai adatmodellje: keyspace, column family, column, row key, adat verziók kezelése, a tábla egy cellájának felépítése, a HFile struktúrája b. Az HBase architektúrája: HMaster, régió szerverek, Zookeeper c. Az HBase működése: az olvasás és írás folyamata, meta table szerepe, WAL, Memstore, Block Cache HBase: egy adattároló, ami a HDFS fájlrendszeren fut. Az HBase belső hash táblákat használ, amiben az adatokat indexelt fájlokban tárolja, a gyorsabb lekérdezés érdekében.  Oszloporientáltan tárolja az adatokat  A séma flexibilis, könnyű hozzáadni, törölni. Nagyon gyorsan lehet vele keresni nagy táblában is  Nincsenek relációs operációk, pl. join, másodlagos index, trigger  Horizontális skálázhatóság  HBase ideális ritka táblák (sparse table) tárolására, azaz ha nagyon sok a táblában az üres cella. Ilyenkor az adott sorokban az üres mező értékét nem adjuk meg, nem tárolunk null értéket. Ezt azért tehetjük meg, mert a tárolás nem rekord szintű, hanem cella szintű Logikai adatmodellje  Keyspace: HBase-ben a séma, táblákból áll össze.  Row Key: A sor egyedi kulcsa, ami egyértelműen azonosítja a sort (a relációs adattábla elsődleges kulcsához hasonló koncepció).  Column family: A column family egy táblán belül a logikailag összetartozó adatoknak a csoportja, amelyek tároláskor is együtt lesznek kezelve. Minden tábla column family-kből áll. Egy column family oszlopokból áll, de ezek dinamikusak, nem szükséges létrehozáskor megadni őket.  Column: A column family-n belül található "oszlop", hozzáadható, illetve kihagyható. Egy oszlopnak van neve, értéke és timestamp-je. o Name: a név mező a név-érték párból. o Cell value: Egy cellában tárolt érték, adott rowkey - column family - oszlop - verzió négyes által meghatározott érték. o Version / Timestamp: Az adatbeszúrás dátumát és idejét vagy verziószámát tartalmazza. Ezzel határozható meg a legfrissebb adat verzió. HBase architektúra, működése  ZooKeeper: egy szolgáltatás, mely képes ellenőrizni, hogy a szerverek elérhetők-e. Az ún. heartbeat csomagok forgalmát figyeli, amikor valakitől nem kap választ, gondoskodik arról, hogy egy másik szerver átvegye a helyét annak, ami kiesett.  HMaster server: Felelős a régió szerverek koordinálásáért, és az admin funkciók ellátásáért. Végrehajtja a DDL (tábla létrehozás, módosítás, törlés) műveleteket, illetve ő végzi az adatok felosztását, átrendezését a régió szerverek között.  Region server: ezeken a szervereken tároljuk az adatokat. Az egyes régiókhoz tartozik egy Memstore és több HFile.  Hadoop HDFS: a region szerverek ezen futnak Region server komponensek  Meta table: tábla, ami az összes region-t számontartja a rendszerben.  WAL (writeahead log): Fájl, diszken tárolódik. Ide íródik be először a kliens által kért módosítás, amit még nem tároltunk véglegesen.  Memstore: memória struktúra, de író cache, ami a disk-re írás előtt rendezi és tárolja az adatokat. Minden column familyre region-önként egy MemStore jut. Van neki egy korlátozott mérete, addig gyűjti a módosítási kéréseket. Ha eléri az előre meghatározott méretet, elmenti egy HFile-ba, ugyanúgy rendezve, mint ahogy a Memstore-ban volt (ez a region flush). Az adatokat a WALból szortírozzuk (rowkey alapján) mielőtt kiírjuk a HFileba.  Block Cache: régiószerver szinten lévő memória struktúra. Olvasó cache, gyakran olvasott adatokat tárol a memóriában. Amikor a cache megtelik, akkor a legrégebben használt adat kerül ki.  HFile: az adatokat itt tároljuk, rendezett kulcs-érték párokban. Ha betelt a Memstore akkor kiírja az HFile-ba, szekvenciálisan. Olvasás, írás folyamata 1. A kliens a Zookeperből lekérdezi a meta table helyét 2. A kliens lekérdezi a meta table-ből a régió szerver címét 3. Elküldi az adatokat a regio server WAL-jába 4. Átkerülnek a Memstoreba 5. Ha a Memstoreban elérik a limitet, szortírozza 6. Az adatok kiíródnak a HFile-okba. 8. Ismertesse a kulcs-érték tároló típusú NoSQL adatbázis-kezelő rendszereket! Válaszában térjen ki a következőkre: a. A kulcs-érték tárolók tipikus felhasználási területei b. A Redis architektúrája: szerver típusok, cluster architektúra, replikáció és sharding c. A Redis működése: in-memory működés, perzisztencia, adatstruktúrák A kulcs-érték tárolók a NoSQL adatbázisok egyik típusa, amelyek egyszerű adatstruktúrákat, nevezetesen kulcs-érték párokat használnak az adatok tárolására. Ezek rendkívül gyorsak, könnyen skálázhatók, és gyakran in-memory (memóriában) működnek. a) Tipikus felhasználási területek: Caching (Gyorsítótárazás): adatok átmeneti tárolása. Weboldalak gyors kiszolgálása. (az in-memory rendszereknél, mint a Redis) Session store/management: session kezelés lefejlesztésére is jó. (Webes alkalmazásokban a felhasználói munkamenetek tárolására használják.) Messaging channels: üzenetküldő funkció (van egy publisher, bármennyi subscriber, a publisher által az adott csatornára küldött üzenetet minden feliratkozott subscriber megkap) Időérzékeny adatok tárolása: olyan rendszerekben, ahol alacsony késleltetésű válaszokra van szükség Secondary indexes: indexelésre is használható b) Redis architektúra A Redis egy népszerű kulcs-érték tároló, amely in-memory adatbázisként működik, és számos fejlett funkcióval bír. Mind a replikációt, mind a shardingot támogatja attól függően, hogy hogyan konfiguráljuk a szervereket: Simple deployment: egyetlen node, nincs redundancia High Availability deployment: master-slave architektúra. Egy master node, több slave. Automatikus failover a slave-ek között. Clustered deployment: több egyenrangú node ("több master"), amelyek elosztva tárolják az adatokat (sharding). Skálázható a rendszer, nincs magas rendelkezésre állás. High Availability Clustered deployment: az előző kettő kombinációja, azaz több master, de tartoznak hozzájuk slave-ek is. Magas rendelkezésre állás. c) Redis Működése A Redis népszerűsége annak köszönhető, hogy rendkívül gyors, rugalmasan használható és széleskörű funkcionalitással rendelkezik, így ideális választás modern alkalmazások számára. In-memory típusú működés: az egész adatbázis a memóriában van, ez a fő előnye, azaz nagyon gyors. A diszkre való adatmentés (perzisztencia) opcionális, és konfigurálható. Perzisztencia szintek: 1. Disabled: Az adatok csak a memóriában tárolódnak, nem kerülnek mentésre a diszkre. Ha a szerver leáll, az adatok elvesznek. 2. Snapshotting: Időszakos mentések készülnek az adatbázis állapotáról, amelyek fájlba íródnak. Ez egyszerű módja az adatok időközi mentésének, de a két snapshot közötti adatok elveszhetnek. (RD file) 3. Command log: Minden írási műveletet folyamatosan naplóz, így az adatok szinte valós időben visszaállíthatók, a legkisebb adatvesztési kockázattal. (AO file) Adatstruktúrák A Redis nem csak egyszerű kulcs-érték párokat tárol, hanem fejlettebb adatstruktúrákat is: - String: Egyszerű szöveg vagy bináris adat. - List: Sorba rendezett elemek, például queue kezeléséhez. - Set: Egyedi elemek halmaza, például tags vagy ID-k. - Hash: Kulcs-érték párok összessége egy kulcson belül, például objektum tárolására. - Sorted Set: Prioritás szerint rendezett elemek, például ranglisták kezelésére. - Stream: Idősoros adatokhoz. 09. Üzleti intelligencia alapvető fogalma, szerepe, helye a. Fogalma b. Operatív és analitikai rendszerek közötti különbség c. Felhasználói és felhasználási módja (vertikális, horizontális megközelítés) d. Elemezze az alábbi ábrát a. Üzleti intelligencia alapvető fogalma Az üzleti intelligencia (angolul Business Intelligence, röviden BI) gyűjtőfogalom; magában foglalja azokat az alkalmazásokat, legjobb gyakorlatokat, eszközöket, amelyekkel megszerezhetünk olyan információkat, amelyekkel az üzleti döntéseket és az üzleti teljesítményt javíthatjuk. b. Operatív és analitikai rendszerek közötti különbség Aspektu Operatív rendszer Analitikai rendszer (BI) s Támogatja a cégek napi Támogatja a taktikai és stratégiai működési tevékenységét és döntéshozatalt és root-cause analízist Cél normál üzleti folyamatokat (pl. minta- vagy trend-analízis) (pl. beszerzés)  Optimalizált gyors  Optimalizált nagy mennyiségű tranzakció feldolgozásra, adattárolásra és gyors olvasási egyszerű olvasás/írás Adatbázis sebességre. műveletekre, kinézet  Adat sértetlenségen kis hangsúly a DB-  Nagy hangsúly az adat dizájnban, az ETL-Folyamat biztosítja sértetlenségen azt. Változékony adat, ami azonnali Az állandó és múltbéli kivonatok (delták, változásokat eszközöl a snapshotok). Adatok nem változnak Adat feldolgozott tranzakciók tovább. következtében. Többnyire tranzakció-alapú Elemző eszközök nagy adathalmazokhoz. Alkalmazás GUI-k egyedi adatok Előtérbe helyezi a vizualizációt. ok létrehozására, módosítására és törlésére. c. Felhasználói és felhasználási módja (vertikális, horizontális megközelítés) Ki használja a BI rendszereket? Egy vállalaton belül a felhasználók széles skálája létezik, mindegyikük más-más kérdésekkel fordul a BI-rendszerhez, és más-más igényeik vannak a rendszerrel szemben.  Vertikális megközelítés: az adatokat egy adott dimenzió vagy jellemző mentén csoportosítja. á  Horizontális megközelítés: horizontális megközelítés az adatokat több dimenzióban vagy jellemzőben hasonlítja össze. à d. Elemezze az ábrát  Tengelyek: X-tengely Business Value: egy alkalmazás milyen plusz információkat, üzleti értékeket nyújt a felhasználónak.  Tengelyek: Y-tengely Complexity: BI alkalmazás létrehozása, lefejlesztése mennyire bonyolult.  Feliratok o Reporting (mi történt?): megvannak a történelmi adatok, ezek alapján hozzuk meg a döntéseinket a jövőre vonatkozóan. o Monitoring (mi történik most?): itt már aktuálisabb mutatószámokat vizsgálunk, de még mindig a múlt adatai alapján dolgozunk. o Analyisis (miért történt?): nem csak tudjuk, hogy baj van, hanem megpróbáljuk megérteni, hogy miért van baj, mi okozza a csökkenést. Komplexebb az alkalmazás, interaktívabb a riport. o Prediction (mi történhet majd?): nem visszatekintünk a múltba, hanem megpróbáljuk megjósolni a jövőt matematikai, statisztikai úton. o Decision (mit kellene most tennem?): a rendszer itt már megoldásokat javasol egy problémára, azaz nem csak jósol, hanem döntéseket is hoz. Összefüggés van a lehetséges üzleti érték (business value) és a rendszer összetettsége (complexity) között. Minél összetettebb egy rendszer, annál nagyobb az üzleti értéke. 10. BI (analitikai) rendszerek felépítése a. Mutassa be a BI rendszerek rétegeit, architektúráját és adatfolyamatait az alábbi ábrák alapján b. Ismertesse a BI eszközök választása kapcsán a Best of breed selection ill. az Integrated stack selection megközelítéseket! c. Mutassa be a BI és a felhő kapcsolatát a tanult infrastruktúrákban (IaaS, PaaS, SaaS) a. Mutassa be a BI rendszerek rétegeit, architektúráját és adatfolyamatait az alábbi ábrák alapján Standard BI- Architecture (A. Kurz) Operative Data Sources Layer Az összes külső vagy belső működő forrásrendszer, ami információt szolgáltat a Data Warehouse felé, ebbe a rétegbe van csoportosítva. Tipikus forrásrendszerek: OLTP-Systems, Legacy Systems (régi host alkalmazások), ERP Systems (pl. SAP), bármilyen fajta tartalom az internetről (pl. Crawler Software-rel) vagy vásárolt adat. Data Warehouse és ETL-Layer A. Kurz architektúrája relációs adattárház megközelítést alkalmaz, ami azt jelenti, hogy DWH elemek tárolására relációs adatbázis technológiát használ. Az Adattárház rész a következőkből áll: Metadata-Repository, maga az Enterprise DWH (tartalmazza a releváns üzleti elemeket), magasan konszolidált adatot, hogy fejlessze a Reporting-teljesítményt. Ez a réteg tartalmazza az ETL részt is. Az ETL-rész felelős az átalakításért, tisztítja és betölti az adatokat a DWH táblákba. A forrásadatok betöltése történhet periodikusan vagy esemény-vezérelten. Application Layer Ez a réteg mondhatni egy közvetítő a felhasználó szemantikus nézete és a Technical Layer között a DWH-ban. A fő célja a rétegnek az, hogy lefordítsa a kért riportot SQL-re, a relációs DWH-n futtatva. Az SQL eredménye ezután elő van készítve a Presentation Layer számára. Ezt a “fordítási folyamatot” vezérli a metadata. Presentation Layer Ez a réteg felel a kért információ vizuális megjelenítéséért. Ennek a rétegnek a kezelése intuitív kell legyen, hogy egy IT- tapasztalat nélküli felhasználó is könnyen dolgozhasson vele. Software Ergonomics nézőpontnak is implementálva kell lennie ebben a rétegben. BI + Data Lake Mixed Architecture A Mixed Architecture egy olyan megközelítés, amely implicite azt állítja, hogy a BI és a Big Data egymást kiegészítő és nem kizáró jellegű. A modern analitikai ökoszisztémának olyan komponenseket kell biztosítania, amelyek a lehető legjobban illeszkednek az adatokhoz és a felhasználási esethez. A "produktív" rendszer mellett a felfedező platformok (vagy homokozók) egy elkülönített területet biztosítanak, ahol az adattudósok játszhatnak az adatokkal anélkül, hogy a rendszer többi felhasználóját "megzavarnák". Még ebben a vegyes architektúrában is minden releváns szemantikát a metaadatokban kell meghatározni. The „Analytics Pipeline“ Perspective Az "Analytics Pipeline" megváltoztatja a perspektívát. A statikus architektúra helyett tiszteletben tartja azt a tényt, hogy az adatoknak a forrásból való megszerzésétől sok lépés vezet el addig, amíg azok olyan helyre/formába kerülnek, ahol felhasználhatók. Ezt a lépéssorozatot egy csővezetékként lehet elképzelni. A rendszerarchitektúra szempontjából ebből az következik, hogy a csővezeték minden egyes lépéséhez egy technikai megoldást (komponenst) kell megvalósítani. b. Ismertesse a BI eszközök választása kapcsán a Best of breed selection ill. az Integrated stack selection megközelítéseket! Best of breed selection:  itt minimum három komponenst kell kiválasztani: egy adatbázist, egy betöltési eszközt (ETL) és egy riporting eszközt.  Megnézem ennek a három piacnak a szereplőit és az általuk nyújtott eszközöket, majd ezekből kiválasztom azt, ami az én céljaimnak a legjobban megfelel.  Pl.: a piacvezető ETL-eszköz kiválasztása és kombinálása a piac legjobb reporting-eszközével, bár az optimális integrációt mindkét gyártó nem ígéri. Integrated stack selection:  egy komplett csomagot választok ki, amiben mind a 3 eszköz megjelenik (AB, ETL és Riporting) és mindez egyetlen gyártótól.  Lehet, hogy az egyes komponensei nem a legjobbak a piacon, de cserébe az integrációval kevesebb gondom lesz, tehát megbízhatóbb lesz a működése.  Pl.: BI-Suite választása az egyik gyártótól, tudva, hogy az ETL megoldása nem a legjobb, de a Suite összetevők integrálása jól megoldott. c. Mutassa be a BI és a felhő kapcsolatát a tanult infrastruktúrákban (IaaS, PaaS, SaaS) IaaS:  Többnyire virtuális gépeket forgat a felhőben, ez azt jelenti, hogy a hálózatot, a tárolást és a szervert a felhő szolgáltatója kezeli, a többi pedig az ügyfelek felelőssége.  A klasszikus hosting modern módjának tekinthető. Ahelyett, hogy megvásárolnánk egy saját szervert, és teljes felelősséget vállalnánk a gépről, beleértve a hálózati infrastruktúrát, a vállalat egy virtuális szervert is feloszthat a felhőben az ETL szerver építésére. PaaS:  A felhőben kezelt adatbázis megoldások PaaS-nek tekinthetők.  A felhőalapú titkosító biztosítja, hogy az ügyfél rendelkezésére álljon egy futó adatbázis egy adott operációs rendszeren és egy hálózati infrastruktúrával. Az alkalmazás végrehajtása az adatok bevitele az ügyfél felelőssége. SaaS:  Egy végfelhasználói használatra kész szoftver, amelyet meghatározott elemzési usecaseekhez használhatunk.  A Tableau Public vagy a Power BI SaaS megoldásnak tekinthető, mivel a végfelhasználó az eszközt betölti az adatkivonatával, és az intuitív GUI segítségével elkészítheti a kívánt elemzést. 11. Adattárház architektúra a. Adattárház, adat piac fogalmai b. Inmon és Kimball architektúra megközelítései c. ATH architektúra variációk (4 darabot) d. ATH architektúra rétegei a. Adattárház, adat piac fogalmai  Adattárház (Data Warehouse): o „Adattárház” kifejezést Bill Inmon alkotta meg. o Az adattárház egy téma/tárgyorientált, integrált, időben változó, de nem illékony adatgyűjtemény, amely a vezetés döntéseit támogatja. o Egyéb megfogalmazások:  A DWH egy analitikus adatbázis, amely a döntéstámogató rendszer alapja.Hatalmas mennyiségű, csak olvasható adatra tervezték, és intuitív hozzáférést biztosít a döntéshozatalhoz szükséges információkhoz. [VPLR 1997].  A DWH a működési adatoktól elkülönített döntéstámogató adatbázist jelent, amelyet elsősorban a vállalatok döntéshozatali folyamatainak támogatására használnak. A DWH mindig többdimenziós kialakítású, és a múltbeli, tisztított, szintetizált, operatív belső és külső adatok hosszú távú tárolására szolgál. [AKU 1999].  Adat piac (Data Mart): o Az adattárház azon része, amely a vállalat egy részlegének, vagyis egy bizonyos ügyfélkörének készül. Pl.: egy adattárházban benne van az összes sales-es adat, amit lehetne elemezni. Kínában ülnek a kínai sales elemzők és security, performancia okokból nem akarjuk, hogy ők hozzáférjenek a teljes adattárházhoz, csak a rájuk vonatkozó adatokhoz. o A Data Mart tartalmát attribútumokra, dimenziókra, mutatószámokra bontjuk fel. Leggyakrabban star séma szerkezetben épül fel. o A Data Mart telepíthető fizikailag vagy virtuálisan. b. Inmon és Kimball architektúra megközelítései Inmon: “Top-Down” (fentről le) megközelítés:  Először meg kell tervezni az “Enterprise Data Warehouse”-t, ami be van ágyazva a DWH sémába.  Ez az EDWH a 3. NF-ban kell legyen és tárolnia kell az elemi adatot a legalacsonyabb szintű részletességgel. Itt az adat historikus, nincs törlés vagy felülírás.  Az EDW alapján építhetőek a Data Mart-ok, amik a dimenziós modellezés szabályait követik. Kimball: “Bottom-Up” (lentről fel) megközelítés:  Közvetlenül hozod létre a Data Mart-okat. Nincs szükség EDW-re.  Az elkülönített Data Mart-ok dimenziók által vannak összekapcsolva, amiket “Data Warehouse Bus”-nak neveznek. A DWB használatával kombinálhatóak a különböző Mart-ok.  Egy DWH egy vagy több Data Marts gyűjteménye. c. ATH architektúra variációk bemutatása (4 darabot)  Independent DMs (Független DM-ek) Legtöbb esetben “múltbéli megoldások”. Egy cégen belül több forrásrendszer van és minden egyes részlegnek saját data mart-ja van, önálló riporting funkcióval. Az egyes data martok függetlenül működnek egymástól, az átfedések miatt redundancia is előfordulhat. Problémája: Azonos adatintegrációs logikát kell többször is implementálni.  Data Mart-ok alkalmazkodó dimenziókkal Kimball megközelítését képviseli. Továbbra is mindenkinek saját data martja van, de a dimenziók az egyes DM-oknál ugyanazt a szemantikát, szintaktikát követik. Pl. a termékek ugyanazon struktúrával rendelkeznek minden részleg esetében. Problémája: Identical Data Integration Logic implementálva kell legyen több alkalommal is.  Central Data Warehouse Nincs szüksége data mart-okra, csak egy központi DWH-ra. 3NF struktúrában vannak a táblák. Megfontolandó kisebb mennyiségű adatnál és végfelhasználónál. Inmon megközelítése felé hajlik.  Several DWHs in parallel (Számos DWH párhuzamosan) Akkor alkalmazható, ha a cégek üzleti struktúrája jelentős különbséget mutat. Különböző core adattárházakat csinálunk, de nagyjából ugyanabból a forrásból meríthetnek. Akkor érdemes használni, amikor egy nagy vállalati concern-ben vagyunk, ahol többféle ágazatok vannak pl.: jogilag is szét vannak választva (leányvállalatok). d. ATH architektúra rétegei  Input layer / STAGING: Ez a réteg a nyers adatokat tartalmazza a forrás fájlból vagy rendszerből. A táblák szerkezete előre meghatározott a bemenő adatok struktúrájának segítségével.  Core layer / STORAGE: Itt kerül megvalósításra az üzleti modell, tartalmaz minden historikus adatot, amire a döntéshozatalnál szükség lesz.  Reporting Layer / OUTPUT: Ezt a réteget érik el a BI eszközök, amelyek segítségével készülnek a riportok, tehát itt on-the-fly számítások, dinamikus adatok stb. 12. Multidimenzionális modellezés I. a. Multidimenzionális modellezés 4 komponense és jellemzésük Tények (Adat típus, származás, Kimball konszolidációs szabályai) Dimenziók Hierarchiák (6 típusa) Aggregációs szabályok b. Csillagséma (felépítése, komponensei, előnyei, kulcs típusok) c. Galaxy és Hópehely sémák a. Multidimenzionális modellezés  A dimenziós modellezés az analitikus rendszerek adatmodellezési technikája.  Célja a fő számadatok (tények) különböző nézőpontokból (dimenziókból) történő elemzése. Ez a "többdimenziós" nézet a vállalat számára a lehető legjobb döntés meghozatalához szükséges betekintést nyújtja a vezetőnek.  A többdimenziós modellt gyakran egy adatkockaként ábrázolják, hogy elmagyarázzák, hogyan lehet egy üzleti számadatot különböző nézőpontokból elemezni. A multidimenzionális modell 4 elemből áll: 1) Tények A tények azok a működési adatok, amelyek a vezetés érdekeit szolgálják, és amelyeket a BI-rendszerek segítségével kell nyomon követni/megérteni. Adattípus alapján  Numerikus tény: Abszolút vagy relatív értéket képvisel.  Enumerikus tény: Állandók halmazát reprezentálja. Nem lehet aggregálni. Eredet alapján  Fizikai / tárolt tények: Egy forrásrendszerből a DWH-ba importált adatok.  Számított / származtatott tények: A fizikai tényekből származtatott / kiszámított tények az üzleti szabályoknak megfelelően. A számítás történhet az ETL-folyamat részeként, vagy a felhasználó hozzáférése során. Kimball konszolidációs szabályai alapján  Additív tények: az összes kapcsolódó dimenzió minden hierarchia-szintje között összesíthetők.  Félig-additív tények: ezek csak bizonyos kapcsolódó dimenziókra aggregálhatók.  Nem additív tények: nem összesíthetők 2) Dimenziók A döntéshozóknak különböző nézeteket kell kialakítaniuk a tényeikről. Ezeket a nézeteket dimenzióknak nevezik. Az MDD-ben a dimenziók a vonatkozó tények körül helyezkednek el. 3) Hierarchiák Egy dimenzió több hierarchiaszintre is tagolható. Például az "Idő" dimenzió a "Nap" "Hét" "Hónap" "Negyedév" "Év" szintekre bontható. Az a szint, amelyen a tény elérhető (pl. "Nap"), az "Idő"-dimenzió legrészletesebb (atomi) szintje. Ezt a speciális hierarchiaszintet "Granularitási szintnek" (LoG) is nevezik. Hierarchia típusok:  Flat structure  Flat structure with all level  Balanced tree structure  Unbalanced tree structure  Parallel Hierarchie Structure  Heterarchie (M:N Structure) 4) Aggregációs szabályrendszer Az aggregációs szabályrendszer meghatározza a tényadatoknak a hierarchia szintek mentén történő összevonására vonatkozó matematikai szabályokat. b. Csillagséma A többdimenziós modell klasszikus relációs adatmodellje a csillagséma. Két fő alkotóeleme, a központi „Tény” tábla és az azt körülvevő „Dimenzió” táblák. Komponensei:  Ténytábla: tartalmazza a mutatószámokat, a dimenzió táblákra mutató idegen kulcsokat és tartalmazhat tényeket leíró adatokat is. A kulcsa vagy egy surrogate key, vagy a dimenziótáblák kulcsai összetett kulcsként.  Dimenzió táblák: ezek tartalmazzák a kontextust, a szemszöget, amiből ránézünk a ténytábla rekordjaira. Általában kis táblákból áll, kevés hely kell nekik.  A két tábla típust összekötő kapcsolatok: 1:N típusú kapcsolat van a ténytábla és a dimenziótábla között. Előnyei:  néhány táblából áll  néhány, kevésbé komplex kapcsolat a táblák között  könnyű megértés  könnyű, gyors adatelérés  hozzáférés orientált  Néhány JOIN segítségével megválaszolhatóak az adatokra épülő kérdések. Kulcs típusok:  Business key: a forrásrendszerekből vett adatok eredeti elsődleges kulcsa, amire azért van szükség, hogy az adatok visszakövethetők maradjanak az adattárházban.  Surrogate key: egyfajta mesterséges, automatikusan inkrementálódó kulcs (ID). Egy egész számot tartalmaz, ami minden új sor beszúrásakor automatikusan növekszik. A dimenziótábláknak és a legtöbb esetben a ténytáblának is ez az elsődleges kulcsa. Azért ezt a megoldást választották, mert az int típusú értékeket gyorsabb összekapcsolni, mint például karaktermezőket. c. Galaxy és hópehely sémák  Galaxy: o A Galaxy-séma kibővítése a star sémának a Kimball-Touch segítségével o 2 vagy több ténytábla, amelyek egy vagy több általános dimenziót használnak, egy „galaxist” építenek. A dimenziókon keresztül egyik ténytáblából át tudok menni a másikra.  Hópehely: o Dimenzió táblákat normalizálják o A normalizált dimenzió táblák a star schemaban úgy néznek ki, mint a hópelyhek. 13. Multidimenzionális modellezés II. a. SCD és a 4 megvalósítási típusa b. AS IS, AS OF, AS POSTED megjelenés a riportokban c. Többnyelvűség a dimenziókban d. Nyomon követhetőség (traceability) e. Hiba protokollok f. Előaggregációk a. SCD és a 4 megvalósítási típusa A SCD (Slowly Changing Dimension) koncepciója arra a tényre alapszik, hogy egy dimenzió tartalma az idő múlásával megváltozhat. Ez koncepció válaszokat ad arra, hogy miként kezelje a tények változásait az adattárházakban a rendszerünk.  Type 0: o Nem csinálunk semmit a betöltést követően, nem módosítjuk a meglévő rekordokat csak újakat töltünk a meglévőkhöz. o Ezt nagyon ritkán szokták használni.  Type 1: o Egyszerűen felülírjuk a meglévő adatokat az új adatokkal. Ezáltal az adattárház naprakész adatokat tartalmaz. o Nem tudjuk visszakövetni a változásokat.  Type 2: o A tábla tartalmaz olyan extra oszlopokat, ami biztosítja a historikus adatok meglétét minden egyes frissítéskor, így visszanézhetjük, hogy melyik adat hogyan változott az idők folyamán. Pl. VALID_FROM és VALID_TO oszlopok. o Itt új értelmet nyer a Surrogate Key is.  Type 3: o Új oszlopokat adunk a táblához úgy, hogy az egyikben a jelenlegi érték, a másikban pedig a historikus érték kerül tárolásra. Ha változik egy adat, akkor ugyanazon a soron a meglévő oszlopértéket átírjuk, amit átírtunk adat pedig bekerül a historikus értéket tároló oszlopba. o Limitáltabb lehetőség, hisz olyan szinten tudsz nyomon követni egy változást, ahány különböző oszlopot hozol létre. b. AS IS, AS OF, AS POSTED megjelenés a riportokban  AS IS: A jelentéseknek tükröznie kell a dimenzió-hierarchia jelenlegi állapotát. Az üzlet aszerint a dimenzió érték szerint szeretné látni a mutatószámokat, ami jelenleg érvényes. Pl.: egy Stuttgartban lévő bolt egy új régióba van besorolva, akkor oda szeretném felaggregálni a forgalmát és nem oda, ahol régen volt.  AS OF: A jelentéseknek tükröznie kell a dimenzió-hierarchia eredeti állapotát. Az előző ellentéte. Az üzlet aszerint a dimenzió érték szerint szeretné látni a mutatószámokat, ami eredetileg érvényes volt. Pl.: Ha Stuttgart be volt sorolva egy régióba, majd átkerül egy másikba, akkor is az eredetivel akarunk számolni. Mi mindig a riport időszak elejétől szeretnénk figyelni Stuttgart-ot.  AS POSTED: A jelentéseknek tükröznie kell a történelmi igazságot (a dimenzió-hierarchia állapota a tény beillesztésének időpontjával). A tranzakciót abba az érték struktúrába soroljuk be, ami akkor érvényes, amikor a tranzakció létrejött. Pl.: Stuttgart július 15-ig be volt sorolva egy X régióba, és július 15-én átsoroljuk Y régióba, majd jön egy tranzakció július 17-én, akkor már az Y-nal számolunk. c. Többnyelvűség a dimenziókban  Nemzetközi vállalatoknál, ahol a felhasználók több országban vannak jelen, előfordulhat, hogy a nemzetközi felhasználók számára különböző nyelveken kell tárolni a leíró adatokat.  A leíró adatok több nyelven történő tárolásához egyszerűen csak egy oszlopot kell hozzáadni a dimenziós táblához: A "LANG_CD" oszlop tartalmazza a leíró adatok minden egyes rendelkezésre álló fordításának nyelvi kódjait. d. Nyomonkövethetőség (Traceability) A nyomonkövethetőségi mechanizmusok beépítése az adatmodellbe nagyon hasznos:  Az adatminőségi problémák elemzése  Az adattárház tartalmának ellenőrzése egy auditálási forgatókönyvben A nyomonkövethetőség az adattárházak kontextusában a következő kérdésekre válaszol: - Honnan származnak az adataim (melyik forrásrendszerből/interfészből)? - Mikor töltötték be az adattárházba? - Melyik betöltési folyamat illesztette be a rekordokat? e. Hiba protokollok (Error protocols) A rekordok visszautasítása az ETL-folyamat során nem ritka, és ennek több oka is lehet: – Adattípus/formátum eltérés – Érvénytelen értékek – Duplikátumok – Üzleti / integráltsági szabályok megsértése. Hasznos, ha az ilyen rekordokat nem csak visszautasítjuk, hanem úgynevezett „Hiba”- táblákban tároljuk, ahol az adatminőség-menedzserek később elemezhetik őket. f. Előaggregációk (PreAggregations) Az előaggregálásosk a gyakran használt adatok jelentésének felgyorsítására szolgálnak. Előnyei:  Kevésbé összetett lekérdezések  Gyorsabb adatlekérdezés (kevesebb rekordot kell beolvasni az összesített táblából). Kevesebb rendszerterhelés (komplex számításokat csak az aggregátum-frissítéskor kell elvégezni) 14. ETL folyamata I. a. ETL lépései és viszonya az ATH rétegekhez b. Extract (ütemezett, eseményvezérelt, ad-hoc és realtime, delta vs. full, forrás fájlok típusai, lehetséges problémák) c. Transform (duplikáció eliminálás, harmonizáció, filtering, adatintegritás biztosítása, aggregátumok készítése) a. ETL lépései és viszonya az ATH rétegekhez Adatfolyamatok különböző forrásokból származó adatok gyűjtésére, az adatok üzleti szabályok szerinti átalakítására és a célhelyek adattárba való betöltésére szolgálnak.  Extract: Az ETL-folyamat első része az adatok kinyerését jelenti a forrásrendszer(ek)ből.  Transform: Az adatátalakítás szakaszában számos szabályt vagy funkciót alkalmaznak a kinyert adatokra annak előkészítése érdekében, hogy a végső célba betöltődjenek.  Load: A betöltési fázis betölti az adatokat a végcélba, amely bármilyen adattároló lehet, beleértve az egyszerűen elválasztott lapos fájlt vagy az adattárházat is. b. Extract fázis esetei  Ütemezett: Az adatokat meghatározott időközönként, például pl. „Minden nap 17 órakor”  Eseményvezérelt: Az adatok kézbesítése akkor történik, amikor egy bizonyos esemény bekövetkezik, pl. A „kivonat fájl eléri a 2 GB-ot”  Ad hoc: A DWH alkalmazáskezelő manuálisan indíthatja el a betöltési folyamatokat. Pl. kezdeti betöltés  Valós idejű: A forrásrendszer minden változása azonnal elindítja a betöltést. Extract réteg két fajtája:  Delta: Operatív rendszerben új vagy megváltozott adatokra vonatkozóan csak a változás valamilyen leírását továbbítjuk. A helyes „delta” azonosítása a felület kialakításának kritikus része, és gyakran inkább üzleti kérdés, mint műszaki.  Full: Operatív rendszer adatait egy az egyben továbbítjuk. Ez akkor helyénvaló, ha a kibontott rekordok száma nem olyan nagy. Általában ezt a megközelítést lehet kiválasztani a törzsadatokhoz, amelyekre szükség van a mérettáblák betöltéséhez. Forrás fájlok típusai:  Flat File: A közönséges fájlformátumok rögzített hosszúságú szövegfájlok vagy CSV-fájlok. Itt a felső költség minimális, és magas tömörítési arány érhető el, ami csökkenti a hálózati forgalmat. Típusai: CSV  Self-Describing: Az általános „önleíró” formátumok a JSON vagy az XML. Ezek a formátumok sokkal összetettebb adatszerkezeteket (például tömböket) tesznek lehetővé, és XML esetében lehetővé teszik a séma validálását az interfész nagyobb robusztusságának biztosítása érdekében. Ma már zip, gzip, tar tömörítések vannak. Érdemesebb egy self describing-ot választani, azaz egy XML formátumot egy flat fájlhoz képest, mert sokkal jobb a hibatűrése. Ilyenkor a tömörített fájlt ki kell tömöríteni és elindulhat a betöltés. Lehetséges problémák:  Date – Datetime: az egyik dátumot ad, a másik dátumot és időbélyeget is.  Boolean – SmallInt: sok adatbázis kezelő ismeri a booleant, de sok viszont nem, ilyenkor true/false helyett 0/1 van.  TimeZone problem: fogja a rendszer és küldi a dátumokat, de a mi rendszerünk nem tudja, hogy Amerikából jött, ezért egységesítenünk kell-e az időpontokat a mi adattárházunkra.  Decimal sign: 12,22 vesszővel írjuk le vagy ponttal? Ahány ország, annyiféle mód van. A dokumentációban jelezni kell, hogy hogyan kell rögzíteni.  File code page: UTF-8, ANSI kódolással érkezik egy karakter. Ha nincs a megfelelő formátumba átkonvertálva, nem fogjuk tudni betölteni.  EOL problem(Windows/Unix): \n, \t, \r mikor melyik kell.  Special characters (byte/character): ékezetes betűk  NULL value: null, vagy kérdőjel c. Transform réteghez kapcsolódó fogalmak  Duplikáció eltávolítás: a DWH-ban nem kívánnak másolatokat, az ETL- folyamatnak meg kell határoznia és el kell távolítania ezeket a másolatokat. Szükség esetén a másolatok előfordulása tárolható egy “Hiba” táblázatban.  Harmonizálás o Információ kódolás: az ETL-folyamatnak harmonizálnia kell az eltérő kódolást a DWH célrendszerébe. Pl.: nemek (N, M, vagy Nő, Férfi, vagy 0, 1) o Adattípusok / -Formátumok. Pl.: dátumok (2018-12-01, vagy 2018. 12. 01.)  Filtering: Azokat az információkat, amelyek nem felelnek meg az adatminőségi követelményeknek, vagy amelyek üzleti szempontból nem relevánsak, az ETL-folyamatban ki kell szűrni.  Adatintegritás biztosítása: Mivel egy adattárház nem használ adatbázis-oldali RI-ellenőrzéseket az ETL-folyamatnak biztosítania kell az adatok integritását. Pl.: ezt megtehetjük a betöltési sorrend segítségével: Először töltse be a dimenziókat, majd töltse be a tényeket, de csak akkor, ha létezik a hivatkozott dimenzió kulcs.  Agreggációk készítése: ésszerű lehet az ETL-folyamat részeként előzetesen kiszámítani a magasan konszolidált számadatokat. 15. ETL folyamata II. a. Load (surrogate key, hisztorizáció, locking) b. ETL eszközök vs. ETL szkripts c. Implementációs kérdések (Nyomon követhetőség, clean up, performancia, GDPR, anonimizáció) a. Load réteggel kapcsolatos fogalmak  Surrogate Keys Amikor új rekordokat helyez be a tárolórétegbe, a Load folyamatnak ki kell számítania az új rekordok új helyettesítő kulcsait. Általában ezt egy „MAX (helyettesítő kulcs) + 1, AS NEW_SURROGATE KEY“ logika valósíthatja meg.  Hisztorizáció (Historization) Ebben a fázisban a historizálás számos aspektusát le kell fedni: - A betöltési időbélyegző hozzárendelése minden rekordhoz. - Dimenzió-historizálás biztosítása SCD használata esetén.  Locking A zárolás akkor szükséges, ha egy célt több folyamat is betölthet. Ebben az esetben a reteszelő mechanizmus biztosítja, hogy a párhuzamos terhelések miatti integritás-megsértések ne forduljanak elő. b. ETL eszközök vs. ETL script ETL eszközök Előnyök Hátrányok A betöltési folyamatokat összeállítják a Magas licence költség fejlesztőkörnyezettel. A dokumentáció generálható a Az eszközspecialistákat nehéz megtalálni metadata-ból a piacon, és magasak az áraik. Készenléti csatlakozók számos Más ETL-platformra való áttérés forrásrendszer-típushoz. többnyire nem lehetséges Out-of-the-Box modulok az Az adatokat végül át kell helyezni a DB- adatintegráció számos tipikus lépéséhez ből az ETL-szerverre és vissza. (Process Alerting, ütemezés, OS- parancsok, hibakezelés stb.) ETL szkriptelés Előnyök Hátrányok Nincsenek licencköltségek Minden szabvány-funkcionalitást manuálisan kell megvalósítani. Függetlenség az eszközgyártóktól Konfiguráció-kezeléshez külső eszköz (pl. SVN, Git stb.) szükséges. Sok SQL / Script fejlesztő áll Nagy mennyiségű szkriptet talán rendelkezésre a szervezetben / a piacon. nehezebb karbantartani c. Implementáció (Nyomon követhetőség, clean up, performancia, GDPR, anonimizáció)  Nyomonkövethetőség (traceability): az adatfeldolgozás nyomon követhetősége sok ellenőrzési forgatókönyvben és hibaelemzés esetén segít. o LOAD_TIMESTAMP: rekord beszúrási ideje o ETL_LOAD_SID: melyik ETL-lépés helyezte be a rekordot. o SOURCE_SYSTEM_SID: rekord eredete  Cleanup: Ki kell takarítani néha az ATH-t, de nem mindegy mit törlünk. o Kikapcsolt felhasználó/ügyfél és kapcsolódó adatok o Nem szükséges értékek o Anonimizálás  Anonimizáció: az olyan közvetlen és közvetett személyes azonosítók eltávolításának folyamata, amelyek alapján egy személyt azonosítani lehet. o Zajkiegészítés: ahol a személyes azonosítók pontatlanul vannak kifejezve. o Helyettesítés/Permutáció: amikor a személyazonosítókat egy táblázatban megkeverik vagy véletlen értékekkel helyettesítik. o Aggregáció/K anonimitás: amikor a személyes azonosítókat egy tartományba vagy csoportba általánosítják.  Performancia: Kerüljük a felesleges hálózati forgalmat az ETL szerver és a DB között. Így javítható a performancia: o Számításokat csak a DB szerveren végezzünk. o Fontos, hogy a platform skálázható legyen. o Komplex számítást több, egyszerű lépésekre bontsuk fel. o Próbáljuk párhuzamosítani a betöltési folyamatokat. o Győződjünk meg arról, hogy az összes rendszerkonfigurációs paraméter megfelelően van beállítva. o Próbáljuk ütemezni az ETL folyamatokat alacsony teljes DB terheléssel (pl.: éjszaka, hétvégén). o Használjunk set processinget az időigényes row processing helyett.  GDPR (General Data Protection Regulation): o Az Európai Parlament 2016. április 14-én hagyta jóvá, és 2018. május 25- én lépett hatályba. o Célja: az összes uniós polgár adatának védelme Átalakította azt, ahogyan a régióban az adatvédelemhez viszonyultak 16. Riportkészítés, OLAP a. Riportok definíciója, felhasználási módjai, típusai b. Adatkocka és megjelenítése a relációs modellben c. Mi az az OLAP? d. Definiálja a tipikus OLAP függvényeket (pivoting, slicing, dicing, drilldown, rollup)! a. Riportok definíciója, felhasználási módjai, típusai Riport: az információk felhasználók számára történő fogadásának-szolgáltatásának folyamata egy BI rendszeren keresztül.  Felhasználási módok: jogszabályi jelentés, vezetői jelentés, döntési feljegyzés, nyilvántartás, beszámoló, üzleti elemzés, idősoros elemzés, adatvizualizáció  Típusok: o Standard-Reporting o Adhoc-Reporting (Self Service) o Analysis (OLAP & Visual Analysis) o Planning and Simulation o Dashboards and Cockpits o Advanced Analytics and Data Mining b. Adatkocka és megjelenítése a relációs modellben Az adatkocka, más néven OLAP-kocka, egy multidimenzionális adatszerkezet, amely lehetővé teszi a nagy mennyiségű adat gyors és hatékony elemzését.  Sztár- és hópehelysémánál alkalmazható.  Aggregált vagy előre kiszámított adatokat tartalmaz.  Haladó üzleti logikát és write-back opciókat valósít meg. c. Mi az OLAP? Edgar Codd alkotta meg a fogalmat. A technológia 1970-től van szabadalmaztatva. Az OLAP (Online Analytical Processing) az adatok elemzésére és riportolására szolgáló technológia és eljárások gyűjtőneve. Az OLAP rendszerek célja, hogy lehetővé tegyék a felhasználók számára az adatok multidimenzionális és interaktív feldolgozását, valamint a komplex üzleti kérdések gyors megválaszolását. Az OLAP rendszerek kiemelkedő jellemzője az adatkockák (OLAP-kockák) használata. Fajtái:  ROLAP: Relational OLAP o Relációs OLAP o Az adattárolás RDBMS-ben történik, lehetőleg egy DataWarehouse/DataMart-ban. o Közvetlen hozzáférés az adatbázishoz o Nagy mennyiségű adat kezelésére alkalmas  MOLAP: Multidimensional OLAP o Az adatokat egy többdimenziós kockában tárolják o Külön fizikai adattároló (saját indexekkel)  HOLAP: Hybrid OLAP o Megkísérli egyesíteni a legjobb jellemzőit a MOLAP-nak és a ROLAP-nak o Relációs adatbázis és többdimenziós kockák tárolják az adatokat o Amelyek gyorsabb lekérdezés-feldolgozást igényelnek a MOLAP-ban tárolódnak. A ROLAP pedig a többit tárolja. d. Definiálja az OLAP függvényeket  Pivoting: A kocka térbeli forgatása. Forgatás után új perspektíva kapható az adatokról.  Slicing: A kocka egy dimenzióján végez kiválasztást, ami egy alkockát eredményez. Csökkenti a kockák dimenziószámát.  Dicing: A Dice művelet a slice "kiterjesztése". A kocka több dimenzióján végez kiválasztást.  Rollup: Az adatok aggregálása egy kockadimenzió hierarchiája mentén. Az adatokat hierarchia emelkedésével aggregálják (pl.: SUM, COUNT, MIN, MAX).  Drilldown: Roll-Up ellentéte. Az adatok kifejtése a legalacsonyabb dimenziós hierarchia mentén. 17. Big Data rendszer alapok a) Mi a Big Data definíciója? Milyen változások és igények indikálták a Big Data rendszerek megjelenését? b) Ismertesse az 5V elméletet! c) Mit takar az ETL és ELT paradigma? Melyikre mi jellemző? d) Ismertessen egy tetszőleges feldolgozású Big Data rendszer teljes folyamatát az adat kinyeréstől a vizualizációig. Jellemezze pár mondatban az egyes lépéseket. a. Mi a Big Data definíciója? Milyen változások és igények indikálták a Big Data rendszerek megjelenését? A Big Data egy nagy mennyiségű (volume), nagy sebességű (velocity) és/vagy sokoldalú (variety) információs eszköz, amely költséghatékony, innovatív információfeldolgozást igényel, lehetővé teszi az adatok jobb megértését, a döntéshozás támogatását és a folyamatok automatizálását. (Forrás: Gartner) Mi indikálta a megjelenését? A mai üzlet igények megjelenése. A vezetői döntések meghozatalához adatok értelmezésére, azaz, információ előállítására van szükség. b. Ismertesse az 5V elméletet! 5V = Volume + Variety + Velocity + Value + Veracity  data Volume – adatmennyiség: Az emberiség még sosem termelt annyi adatot, mint manapság, köszönhetően a szociális interakciónak (közösségi média, chat) és a gépek által generált adatoknak (pl. IOT eszközök)  data Velocity – adatsebesség: A sebességet is megnövelték a hatalmas adatmennyiségek, ezért új adatfeldolgozási módszereket kell találni: o Batch: az adatokat batchekként összegyűjti, és meghatározott időpontokban feldolgozza azokat egyben. A klasszikus adattárházak így működnek. o Realtime: ahogy létrejön egy adat, rögtön feldolgozzuk azt. Feltételezzük, hogy az adatok folyamatosan, szünet nélkül jönnek. o Streaming: ahogy létrejön egy adat, rögtön feldolgozzuk azt. Feltételezzük, hogy az adatok folyamatosan, szünet nélkül jönnek. (u.a. mint a realtime)  data Variety – különböző adatszerkezetek (megjelenése): o Struktúrált adatok. Pl. CSV o Félig struktúrált adatok. Pl. XML, JSON, HTML o Struktúrálatlan adatok. Pl. JPG, MP4  data Value – adat értéke  data Veracity – megbízható adat o Az adat ellenőrzése és hitelesítése fontos. c. Mit takar az ETL és ELT paradigma? Melyikre mi jellemző?  ETL: o Extract, Transform, Load folyamat - (Adat) kinyerés, átalakítás, betöltés folyamata. o Klasszikus adattárházakra jellemző o Az adatokat először kinyerjük a forrásrendszerekből, át kell alakítani (a DWH sémájába), majd betöltjük. o Nem optimális struktúrálatlan adatok kezeléséhez  ELT: o Extract, Load, Transform folyamat - (Adat) kinyerés, betöltés, átalakítás folyamata. o A Big Data technológia ezt részesíti előnyben. o Az adatokat először kinyerjük a forrásrendszerekből, azokat betöltjük (a Data Lake-be). Az átalakítás pedig csak akkor történik meg, amikor az adatokra szükség van (pl. analizálásnál). o Data Lake (adattároló) d. Ismertessen egy tetszőleges feldolgozású Big Data rendszer teljes folyamatát az adat kinyeréstől a vizualizációig. Jellemezze pár mondatban az egyes lépéseket. A Big Data rendszerek ELT technológiát használnak és általában batch vagy streaming alapú feldolgozást. Egy teljes folyamatsor egy elképzelt kereskedelmi áruházlánc esetében a következő lépésekből áll: 1. Adatkinyerés (Extract): A kereskedelmi áruházlánc online platformján tárolt adatokat kigyűjtjük, például vásárlói információkat, termékek adatait és tranzakciókat. Az adatok nagy méretű adattárolókban vannak elhelyezve. 2. Adatbetöltés (Load): Az ELT folyamat Load lépése során az adatokat a Big Data rendszerbe betöltjük. Az adatokat a forrásból kinyerjük és egy központi adattárolóba, például Hadoop HDFS-re vagy egy adatfolyam-kezelő rendszerbe (pl. Apache Kafka) töltjük fel. 3. Adattranszformáció (Transform): Ebben a lépésben a betöltött adatokat átalakítjuk olyan formátumra vagy struktúrára, amely alkalmas az elemzésre vagy a vizualizációra. Például összekapcsoljuk a vásárlói adatokat a termékadatokkal, létrehozunk aggregált statisztikákat és lényeges mutatókat (pl. vásárlói kosarak elemzése, legnépszerűbb termékek stb.). 4. Batch feldolgozás: A transzformált adatokat jelen példában a batch feldolgozás módszerével dolgozzuk fel. Ez azt jelenti, hogy az adatokat csoportokba rendezzük, majd ezeket a csoportokat egyszerre dolgozzuk fel. Például éjszakánként vagy meghatározott időközönként futó feldolgozási feladatok során tömegesen elemzik és aggregálják az adatokat. 5. Adatvizualizáció: Miután feldolgoztuk és előkészítettük az adatokat, megjelenítjük azokat vizuális eszközökkel, például diagramokkal, grafikonokkal vagy interaktív dashboardokkal. Ezek a vizualizációk lehetővé teszik a döntéshozók vagy a szakemberek számára, hogy könnyen értelmezhessék az adatokat és meghozzák a szükséges üzleti döntéseket. 18. Big Data adattárolás a) Mi jellemzi az egyes adatstruktúrákat (structured, semi-structured, unstructured)? b) Jellemezzen egy szabadon választott fájltípust, ami a Big Data világ előtt is használatban volt, de inputként ma is előfordulhat - tulajdonságok, előnyök-hátrányok Big Data szempontból! c) Jellemezzen egy szabadon választott Big Data fájltípust, amit a Big Data rendszerek miatt fejlesztették - tulajdonságok, előnyök-hátrányok Big Data szempontból! d) Mutasson be egy evolúciós folyamatot, ami bemutatja a fájltípusok/adattípusok fejlődését. Legyen legalább 4 példa megoldás, lehetőleg a végén a Databricks saját megoldásával. a. Mi jellemzi az egyes adatstruktúrákat (structured, semi-structured, unstructured)?  Struktúrált adatok o Táblázat, relációs adatbázis táblája o Klasszikus adattárházakra jellemző o Pl. CSV  Félig struktúrált adatok o Nincs fix felépítésük, általában „nested” (beágyazott) a felépítésük o Általában nincs adattípus o A fájlban össze van keverve a data és a metadata o Pl. XML, JSON, HTML  Struktúrálatlan adatok o Semmi struktúrájuk nincs o Bináris formátumban tárolt adatok o Pl. JPG, MP4 b. Jellemezzen egy szabadon választott fájltípust, ami a Big Data világ előtt is használatban volt, de inputként ma is előfordulhat - tulajdonságok, előnyök- hátrányok Big Data szempontból! Az egyik olyan fájltípus, amely a Big Data előtt is használatban volt, és ma is gyakran előfordul, a CSV (Comma-Separated Values) fájlformátum.  Tulajdonságok: o Struktúrált fájlformátum, fix felépítésű o Sor orientált o Az adatokat elválasztójellel (vessző, tabulátor, pontosvessző) elválasztott cellákba helyezi  Előnyök Big Data szempontból: o Egyszerű feldolgozni, mivel könnyen felosztható (splitelhető) az elválasztó karakterek nyomán o Széles körben támogatják a platformok, így könnyű exportálni/importálni  Hátrányok Big Data szempontból: o Nem tud adattípust (pl. string/int/bool) eltárolni o Nem tud meta adatot eltárolni o Karakterkezelés nem egységes c. Jellemezzen egy szabadon választott Big Data fájltípust, amit a Big Data rendszerek miatt fejlesztették - tulajdonságok, előnyök-hátrányok Big Data szempontból! A parquet fájltípus egy bináris alapú, sémavezérelt adattárolási formátum a Big Data rendszerek számára.  Tulajdonságok: o Bináris formátum, ez hatékonyabb tárolást eredményez o Sémavezérelt o Oszlop orientált  Előnyök Big Data szempontból: o Nagyon jól tudja tárolni a nested adatokat (még jobban, mint az ORC) o Jól tudja tárolni a meta adatokat o Felosztható, illetve tömöríhető,  Hátrányok Big Data szempontból: o Nincsenek ACID tranzakciók, nem használható adattárház fejlesztésére o Más platformokkal az integráció problémás d. Mutasson be egy evolúciós folyamatot, ami bemutatja a fájltípusok/adattípusok fejlődését. Legyen legalább 4 példa megoldás, lehetőleg a végén a Databricks saját megoldásával.  CSV o Korai fájltípus, 1978 óta létezik, viszont emiatt széleskörben, régóta bevált és alkalmazott o Sor orientált formátum o Nem tud adattípust tárolni, csak sima szöveget tárol az elválasztókkal o Nem tud metaadatokat tárolni o Nem tud nested adatokat tárolni o Felosztható az elválasztó karakterek mentén  JSON o Webes alkalmazásokban, API-kban, adatbázisokban használják o Szintén sor orientált formátum o Tud adattípust is tárolni már o Már tartalmaz metaadatokat is o Képes nested adatokat tárolni o Kezdetben nem volt felosztható, de azóta már van rá megoldás  Parquet o Kifejezetten Big Data rendszerek számára lett fejlesztve o Oszlop orientált formátum o Tud adattípust tárolni o Tud meta adatot tárolni o Tud nested adatokat tárolni o Felosztható o Nincsenek ACID tranzakciók  Delta Lake (Delta Parquet) o Kifejezetten Big Data rendszerek számára lett fejlesztve o Oszlop orientált formátum o Tud adattípust tárolni o Tud tárolni meta adatot a Delta Lake révén o Tud tárolni nested adatokat is o Felosztható o Már vannak ACID tranzakciók, de nem mindegyik működik jól 19. Big Data adatfeldolgozás a) Jellemezze a batch processing feldolgozási módot! Működési elv, előnyök, hátrányok. Készítsen ábrát a működési elv szemléltetéséhez! b) Jellemezze a stream processing feldolgozási módot! Működési elv, előnyök, hátrányok. Készítsen ábrát a működési elv szemléltetéséhez! c) Mutassa be gyakorlati felhasználási példán keresztül a két feldolgozási mód közötti különbséget, lehetséges felhasználási területet. d) Magyarázza meg, hogy mit jelent a micro-batch kifejezés. Hol használjuk? a. Jellemezze a batch processing feldolgozási módot! Működési elv, előnyök, hátrányok. Készítsen ábrát a működési elv szemléltetéséhez!  Működési elv: Az adatokat a feldolgozás előtt kötegekbe szervezi, majd a feldolgozás kötegenként történik. A kötegelés alapja lehet pl. idő, adatmennyiség.  Előnyök: o Nagy mennyiségű adatok feldolgozásához és alaposabb analitikához jobb  Hátrányok: o Kevésbé jó a folyamatosan érkező adatok feldolgozásával, (közel) valós idejű eredmények meghatározásánál b. Jellemezze a stream processing feldolgozási módot! Működési elv, előnyök, hátrányok. Készítsen ábrát a működési elv szemléltetéséhez!  Működési elv: A feldolgozandó adatok nem várnak (pl valamilyen határidőre), a feldolgozásuk beérkezéskor történik.  Előnyök: o Előnyösebb folyamatosan érkező és feldolgozandó adatok esetén, mikor (majdnem) valós időben van szükségünk az információkra o Machine learning támogatás  Hátrányok: o Kevésbé jó nagyon nagy mennyiségű adatok feldolgozásakor és mélyebb analitika esetén c. Mutassa be gyakorlati felhasználási példán keresztül a két feldolgozási mód közötti különbséget, lehetséges felhasználási területet.  Batch: Példa lehet egy bolthálózat, ahol a nap végi zárással az eladási adatokat beküldik a rendszerbe és a beérkező adatokat nap végén feldolgozza.  Streaming: Példa lehet egy olyan eset, amikor a beérkező adatok feldolgozására és kiértékelésére szinte azonnal és nem csak bizonyos időközönként történik (pl. tőzsde, social media visszajelzések gyors feldolgozása, stb) A legfőbb különbséget a feldolgozás ideje jelenti. A batch előnye a sok adat egyidejű feldolgozása, míg a streaming folyamatosan, azonban csak kevesebb adatot tud feldolgozni. A kiváltó esemény a batchnél tehát az idő, amit vártunk, hogy feldolgozhassuk az adatot, a streamingnél a kiváltó esemény pedig maga a beérkezés. d. Magyarázza meg, hogy mit jelent a micro-batch kifejezés. Hol használjuk? A "micro-batch" egy adatfeldolgozási módszer, amely során az adatok kisebb batch- ekben vannak feldolgozva. Eltér a hagyományos batch feldolgozástól, mivel a mikro-batch esetében a batch-ek mérete jellemzően kisebb és gyakran periodikusan érkeznek. Nagyjából úgy fogható fel, mint az „arany középút” a streaming és batch feldolgozás között. Működése: A mikro-batch feldolgozás során az adatok kis időközönként érkeznek és kerülnek feldolgozásra. A kis időközönkénti darabolással lehetővé válik az adatok folyamatos feldolgozása és elemzése, miközben a kis batch-ek lehetővé teszik az adatfeldolgozási műveletek gyorsítását. Hol használjuk? Általában ott, ahol fontos a gyors válaszidő és a folyamatos adatfeldolgozás. Például: valós idejű elemzések, stream alapú adatfolyamatok vagy olyan rendszerekben, ahol az adatok gyorsan változnak és frissítésekre van szükség rendszeres időközönként. 20. Big Data rendszerek - Apache Spark a) Ismertesse az Apache Spark jellemzőit - célja, tulajdonságai, működési elve, felépítése, alap építőkövei, adatkezelése! b) Mit nevezünk lazy evaluationnek és hogyan jelenik ez meg az Apache Sparkon belül? Mondjon rá példát! c) Mik jellemzi az Apache Spark action és transformation elemeit? Hozzon példákat mindkét esetre! d) Milyen betöltési stratégiákat és eszközöket használ az Apache Spark, és milyen forrásokat használhat? a. Ismertesse az Apache Spark jellemzőit - célja, tulajdonságai, működési elve, felépítése, alap építőkövei, adatkezelése! Az Apache Spark egy nyílt forráskódú elosztott adatfeldolgozási keretrendszer nagy adatok feldolgozására. Célja:  Nagy adatmennyiségek gyors és hatékony feldolgozása elosztott környezetben.  Rugalmas programozási modell biztosítása számítási feladatokhoz. Tulajdonságai:  Nyílt forráskódú  Elosztott, emiatt hibatűrő  In-memory működés: emiatt gyorsabban futtatható, mint a Hadoop  Batch és real-time processingre is képes  Flexibilis, támogat több programozási nyelvet is, például Scala, Java, Python, SQL. Machine Learning modelleket is támogatja. Működési elve:  Az RDD-k (Resilient Distributed Dataset) a Spark fő építőköve, ami az adatokat az adatcsomópontokon elosztva kezeli.  A "transzformációk" (transformation) és "műveletek" az RDD-ken végezhetők, amelyek lehetővé teszik az adatok manipulálását és transzformálását. A "cselekvések" (action) hajtják végre a számításokat az RDD-ken, így generálva az eredményeket.  Kulcsfontosságú jellemzője a Sparknak az in-memory adatfeldolgozás. Az adatokat memóriában tárolja az elosztott csomópontokon, ami gyors és hatékony adatelérést tesz lehetővé a számítások során. Ez azt jelenti, hogy az adatokat nem kell folytonosan lemezre írni és onnan visszaolvasni a számítások során, ami hatalmas sebességnövekedést eredményez. Alap építőkövei:  Spark Core: Az alapja a Sparknak, amely az RDD-ket és az alapvető funkciókat biztosítja a feldolgozáshoz.  Spark SQL: SQL-képességeket ad a Sparkhoz  Spark Streaming: Valós idejű adatfeldolgozást tesz lehetővé  Spark MLlib: Gépi tanulási könyvtár, ami előre elkészített algoritmusokat kínál a gépi tanuláshoz.  GraphX: Gráf-feldolgozást biztosít. Adatkezelése: A Spark képes:  Batch feldolgozásra  Streaming feldolgozásra  Számos fájlrendszert támogat (HDFS, ill. lokális fájlrendszert is)  Gépi tanulási modelleket is támogat  Sok adatbázissal és tárolóval integrálható, pl. Cassandra, MongoDB b. Mit nevezünk lazy evaluationnek és hogyan jelenik ez meg az Apache Sparkon belül? Mondjon rá példát! A lazy evaluation („hanyag/lusta kiértékelés”) egy koncepció, lényege, hogy az adatfeldolgozási folyamat során a transzformációk nem azonnal kerülnek kiértékelésre, hanem csak akkor, amikor egy akció műveletre van szükség. Az Apache Spark is alkalmazza ezt a koncepciót. Például, ha egy RDD-t transzformálunk (select, distinct, groupby, sum, orderby, filter műveletek), az nem történik meg azonnal. Csak akkor történik kiértékelés, amikor egy akciót (show, count, collect, save műveletek) hívunk. c. Mi jellemzi az Apache Spark action és transformation elemeit? Hozzon példákat mindkét esetre! Az Apache Sparkban az "action" és "transformation" két alapvető típusú művelet, amelyeket az RDD-ken (Resilient Distributed Dataset) végezhetünk.  Transformation: A "transformation" műveletek egy másik DataFrame-et adnak vissza. Változatlanok - azaz a DataFrame egyik példánya nem módosítható, ha egyszer már létrehozták. Lehetnek széles vagy szűk műveletek. Példa: select, distinct, groupby, sum, orderby, filter  Action: Az akciók olyan parancsok, amelyeket a Spark közvetlenül a végrehajtásuk idején számol ki. Az összes korábbi átalakítás lefuttatásából állnak, hogy egy tényleges eredményt kapjunk vissza. Egy akció egy vagy több feladatból (job) áll. Példa: show, count, collect, save. d. Milyen betöltési stratégiákat és eszközöket használ az Apache Spark, és milyen forrásokat használhat? Betöltési eszközök:  SparkSession  DataFrame API  Spark SQL Betöltési stratégiák:  Streaming adatfolyamok: Spark Streaming használatával lehetőség van streaming betöltésére például Apache Kafka vagy Flume forrásokból.  Batch feldolgozás Források, ahonnan betölthet adatot:  Fájlrendszerek o HDFS: Hadoop ökoszisztéma fájlrendszere o Local file system: helyi fájlrendszeren tárolt adatok o Felhő alapú tárolók: Amazon S3, Azure Blob Storage  Adatbázisok, adatkezelő rendszerek: o Hagyományos adatbázisok: MySQL, PostgreSQL, Oracle, stb. o NoSQL adatbázisok: Cassandra, MongoDB. o Hive: Hadoop ökoszisztéma részeként szolgáló adatkezelő rendszer.  Streaming vagy valós idejű adatfolyamok: Kafka, Flume  Egyéb adatforrások (pl. API) 21. Big Data rendszerek - DataBricks a) Ismertesse az Databricks jellemzőit - célja, tulajdonságai, működési elve! b) Részletezze a Databricks felépítését és működési elvét - managed Spark clusters, cloud, notebook, languages, dbfs, workspaces! c) Ismertesse a Delta fájlformátum jellemzőit! a. Ismertesse az Databricks jellemzőit - célja, tulajdonságai, működési elve! Az Azure Databricks egy nyílt forráskódú adatfeldolgozási és gépi tanulási platform, amely a Spark-ot és a felhőalapú környezetet ötvözi. Notebook orientált a működése. Célja: Az adatok elemzésének, feldolgozásának és vizualizációjának elősegítése. Tulajdonságai:  Könnyen használható grafikus felhasználói felülettel rendelkezik  Támogatja a csapatmunkát, lehetővé teszi az adatok megosztását és egyidejű módos?

Oracle adatbázis-kezelő rendszer és MPP adatbázisok (PDF)

Document Details

Tags

Related

Summary

Full Transcript