Az incrementális / változás követő adattárház töltés jellemzői közé tartoznak a következők:
Adatváltozások kezelése: Az incrementális töltés során csak azokat az adatokat töltjük be, amelyek megváltoztak az előző töltés óta. Ez csökkenti a feldolgozási időt és az erőforrásigényt1.
Hatékonyság: Mivel csak a változásokat kell feldolgozni, az incrementális töltés gyorsabb és hatékonyabb, mint a teljes újratöltés. Ez különösen nagy adattárházak esetén előnyös1.
Kisebb adatforgalom: Az incrementális töltés kevesebb adatot mozgat, ami csökkenti a hálózati terhelést és az adatbázis terhelését1.
Konzisztencia fenntartása: Az incrementális töltés során fontos az adatkonzisztencia fenntartása, különösen akkor, ha több forrásból származó adatokat integrálunk1.
Időbélyegek használata: Az adatváltozások nyomon követéséhez gyakran használnak időbélyegeket vagy verziószámokat, amelyek segítenek azonosítani a frissítendő rekordokat1.
Micro-batch feldolgozás: Az incrementális töltés gyakran micro-batch feldolgozással történik, ahol kisebb adatcsomagokat dolgoznak fel rövidebb időközönként
További szempontok
Delta vagy CDC technika Az adatok változásának követésére és kiválasztására különböző módszereket használhatunk, például logikai időbélyegek, trigger-ek vagy naplóállományok elemzését.
Betöltési időablakok Az inkrementális töltés gyakran előre meghatározott időablakokban történik (pl. óránként, naponta, hetente).
Konfliktuskezelés Meg kell oldani a duplikációkat, törölt rekordok kezelését és az adatok konzisztenciáját.
Backup és visszaállítási lehetőségek A részleges töltések miatt fontos a megfelelő visszaállítási stratégia kialakítása hiba esetére.
Forrás táblák töltési folyamata
Forrásadatok előkészítése
- Az adatforrásokból (OLTP rendszerek Dblink, CSV, API stb.) a szükséges rekordokat kiválasztják.
- Ha az adatok nagy mennyiségűek, akkor particionált vagy szűrt lekérdezések használhatók.
Változások azonosítása (Change Data Capture - CDC)
A megváltozott adatok azonosításához időbélyeg (timestamp), verziószám, vagy egyéb technikák szükségesek:
TIMESTAMP alapú változáskövetés: ha a forrás táblák tartalmaznak egy LAST_UPDATE_DATE mezőt, akkor ezt lehet használni.
LOG MINER vagy Materialized View Logs (MVIEW Logs): ezek az Oracle beépített mechanizmusai a változások követésére.
Triggers vagy Audit Tables: egyedi fejlesztéssel trigger-ek vagy naplózási táblák használhatók a változások követésére.
Adatok betöltése staging (előfeldolgozási) rétegbe
- Az új vagy módosított rekordokat egy staging táblába másoljuk (pl. STG_CUSTOMERS).
- Az adatokat tisztítjuk, validáljuk és transzformáljuk.
- Delta feldolgozás és céladatbázis frissítése
Az adatok betöltése az adattárházba (DWH layer) háromféleképpen történhet:
- INSERT: ha az új rekord még nem létezik a céladatbázisban.
- UPDATE: ha egy meglévő rekord módosult.
- DELETE vagy SOFT DELETE: ha egy rekord törlődik vagy archiválásra kerül.
Partíciózás és indexek optimalizálása
Particionálás: nagy adatmennyiségnél időalapú vagy hash-partíciókat lehet használni.
Indexek kezelése: az inkrementális töltés előtt/után az indexek karbantartása szükséges.
Szükséges technikai mezők és szerepük
Technikai Mező Szerepe
- ID vagy PRIMARY KEY
Egyedi azonosító minden rekordhoz, amely alapján az UPDATE/DELETE műveletek végrehajthatók.
- LAST_UPDATE_DATE vagy LAST_MODIFIED_DATE
Az utolsó módosítás időpontja, amely segít az inkrementális betöltésben.
- CREATED_DATE
Az adat létrehozásának időpontja, amely segíthet a változások nyomon követésében.
- IS_DELETED vagy STATUS_FLAG
Az adatok törlésének vagy állapotának jelölésére (pl. 'A' – aktív, 'D' – törölt).
- BATCH_ID / LOAD_ID
Az aktuális betöltési folyamat azonosítója, amely segít a hibaelhárításban és a rollback műveletekben.
- SOURCE_SYSTEM_ID
Több forrás esetén az azonosításukra használt mező.
- VERSION_NUMBER
Verziókövetés esetén segít a duplikációk kezelésében és az időalapú elemzésekben.
- HASH_KEY vagy CHECKSUM
Hasznos lehet az adatok változásának nyomon követésére, különösen ha az adatok nem rendelkeznek egyértelmű timestamp mezővel.
Minták:
Incrementális adatok kiválasztása időbélyeg alapján
FROM SOURCE_TABLE
WHERE LAST_UPDATE_DATE >= TO_DATE('2025-02-01', 'YYYY-MM-DD');
Adatok betöltése a Staging táblába
SELECT ID, NAME, LAST_UPDATE_DATE, IS_DELETED
FROM SOURCE_TABLE
WHERE LAST_UPDATE_DATE >= (SELECT MAX(LAST_UPDATE_DATE) FROM DWH_CUSTOMERS);
Delta Update a céladatbázisba
USING STG_CUSTOMERS s
ON (d.ID = s.ID)
WHEN MATCHED THEN
UPDATE SET d.NAME = s.NAME, d.LAST_UPDATE_DATE = s.LAST_UPDATE_DATE
WHEN NOT MATCHED THEN
INSERT (ID, NAME, LAST_UPDATE_DATE) VALUES (s.ID, s.NAME, s.LAST_UPDATE_DATE);
Használhatunk seciális eszközöket/technológiákat a változás követésre (pl. GoldenGate, Materialized View Log, LogMiner) .
A hash-kód delta képzéshez is használható
Hash-kód generálása forrásadatokból
Egy kiválasztott oszlopcsoportból (pl. az összes releváns mezőből) hash-kódot számítunk.
A hash-kódot egy hash-függvény segítségével képezzük (pl. Oracle DBMS_CRYPTO.HASH, ORA_HASH, STANDARD_HASH).
Adatok összehasonlítása a forrásoldali és a céladatbázisban levő tábla tartalommal
- Az új hash-kódot összevetjük a céladatbázisban tárolt hash-kóddal.
- Ha a hash-kód megváltozott, akkor az adott rekord módosult.
- Ha nincs egyező rekord, akkor új bejegyzésről van szó.
Minta:
Tegyük fel, hogy van egy CUSTOMERS tábla az alábbi mezőkkel:
- CUSTOMER_ID
- NAME
- PHONE_NUMBER
- LAST_UPDATE_DATE
Ahelyett, hogy az összes oszlopot soronként összehasonlítanánk, generálhatunk egy hash-kódot ezekből az oszlopokból, és ezt használhatjuk a változások detektálására.
Hash-kód generálása forrásoldalon
STANDARD_HASH(NAME || EMAIL || PHONE_NUMBER, 'SHA256') AS HASH_VALUE
FROM SOURCE_CUSTOMERS;
Itt a STANDARD_HASH függvény egy egyedi SHA256 hash-t generál a NAME, EMAIL és PHONE_NUMBER oszlopok alapján.
Hash-kód összevetése a céladatbázissal
FROM SOURCE_CUSTOMERS s
LEFT JOIN DWH_CUSTOMERS d
ON s.CUSTOMER_ID = d.CUSTOMER_ID
WHERE s.HASH_VALUE <> d.HASH_VALUE OR d.CUSTOMER_ID IS NULL;
Ez a lekérdezés azokat a rekordokat adja vissza, ahol az adatok módosultak vagy újonnan jelentek meg.
Megváltozott adatok frissítése az adattárházban
USING (
SELECT CUSTOMER_ID, NAME, EMAIL, PHONE_NUMBER,
STANDARD_HASH(NAME || EMAIL || PHONE_NUMBER, 'SHA256') AS HASH_VALUE
FROM SOURCE_CUSTOMERS
) s
ON (d.CUSTOMER_ID = s.CUSTOMER_ID)
WHEN MATCHED AND d.HASH_VALUE <> s.HASH_VALUE THEN
UPDATE SET d.NAME = s.NAME,
d.EMAIL = s.EMAIL,
d.PHONE_NUMBER = s.PHONE_NUMBER,
d.HASH_VALUE = s.HASH_VALUE
WHEN NOT MATCHED THEN
INSERT (CUSTOMER_ID, NAME, EMAIL, PHONE_NUMBER, HASH_VALUE)
VALUES (s.CUSTOMER_ID, s.NAME, s.EMAIL, s.PHONE_NUMBER, s.HASH_VALUE);
- Az adatok frissülnek, ha a hash-kód megváltozott.
- Új rekordok bekerülnek.
Milyen előnyei és hatásai vannak a hash-kód alapú delta képzésnek?
✅ Előnyök:
- Gyors összehasonlítás – Ahelyett, hogy minden oszlopot egyenként vizsgálnánk, csak a hash-kódokat kell összehasonlítani.
- Kevesebb erőforrás-felhasználás – Nagyobb táblák esetén is hatékony, mert nem szükséges minden mezőt lekérdezni.
- Egyszerű implementáció – SQL-ben egyszerűen kezelhető hash függvényekkel.
- Nem függ az időbélyegtől – Ha az időbélyeg nem megbízható, a hash-kód megoldást nyújthat.
⚠ Lehetséges problémák és korlátok:
- Hash-ütközések (nagyon ritka) – Bár nagyon kis eséllyel, de két különböző adat generálhat azonos hash-kódot (különösen gyenge hash-függvényeknél, pl.
ORA_HASH). - Nagy adatmennyiségnél számítási költség – A hash-kód kiszámítása CPU-intenzív lehet nagy mennyiségű rekord esetén.
- Nem mutatja a konkrét változást – Csak azt jelzi, hogy egy rekord változott, de azt nem, hogy melyik mező módosult.
Mikor érdemes használni?
✔ Ha nagy mennyiségű adatot kell összehasonlítani inkrementális betöltéshez.
✔ Ha nincs egyértelmű vagy megbízható timestamp vagy verziószám.
✔ Ha gyors összehasonlításra van szükség, például napi frissítésnél.
✔ Ha a forrás és cél adatszerkezet nem teljesen azonos, de a releváns mezők egyezősége biztosított.
Megjegyzések
Megjegyzés küldése