JIRA adatok adattárházba töltése : folyamatok
Alakítsuk ki a JIRA → JSON → CSV/Oracle staging → DW adatbetöltési folyamatot hibatűréssel, naplózással és testreszabott modullal.
✅ Cél: Python modul REST lekéréssel, naplózással, JSON mentéssel, CSV exporttal, előkészítve Oracle betöltésre
📁 Projekt struktúra javaslat
🧱 1. .env
fájl (konfiguráció)
🧰 2. logger.py
– Naplózó modul
🌐 3. jira_api.py
– REST lekérdező modul
Ez fogja lekérni az issues
, projects
, users
adatokat, JSON fájlba menteni és visszaadni feldolgozásra.
💾 4. exporter.py
– JSON és CSV fájlmentés
🔁 5. transformers.py
– Mező értelmezés, dictionary mapping
🧵 6. main.py
– Fővezérlés
🔧 1. Oracle staging tábla – példa
Hozz létre egy staging táblát Oracle-ben, például:
📦 2. Python Oracle connector: cx_Oracle
telepítés
Telepítsd a szükséges csomagot:
🔑 3. .env
– Oracle elérés beállítása
🧩 4. loaders/oracle_loader.py
– Betöltő modul
🧵 5. main.py
frissítve – betöltéssel együtt
✅ Eredmény
Futtatás után:
-
jira_issues_raw.json
→ teljes JSON mentés -
jira_issues.csv
→ könnyen betölthető CSV backup -
jira_issues_stg
→ staging tábla Oracle-ben, naprakészen
🔄 Következő lépés: végső adattárház tábla betöltése
A staging tábla után egy PL/SQL vagy Python által meghívott SQL script végzi a feltöltést a final DW táblába – deduplikálás, lookup-ok, konverziók stb.
Egy Pythonból indított MERGE INTO
Oracle betöltést, ami a staging táblából (pl. jira_issues_stg
) egy végső adattárház táblába (jira_issues_dw
) tölti az adatokat – upsert (update + insert) logikával.
🎯 Cél
-
Új JIRA rekord → INSERT
-
Létező rekord (pl. issue ID alapján) → UPDATE, ha az adatok változtak
-
Betöltést Python indítja (
cx_Oracle
) -
DW tábla:
jira_issues_dw
🧱 1. Oracle DW tábla létrehozása
⚙️ 2. MERGE SQL – üzleti logika
💡 A WHERE
záradék az UPDATE
részben biztosítja, hogy csak akkor történjen frissítés, ha valóban változott az adat.
🧩 3. Python modul: oracle_loader.py
kiegészítése
🧵 4. main.py
frissítése
✅ Mi történik végrehajtáskor?
-
Lekérjük a JIRA adatokat REST API-n keresztül.
-
A JSON adatokat CSV-be és staging Oracle táblába töltjük (
jira_issues_stg
). -
A Pythonból indított
MERGE INTO
lekérdezés:-
beszúrja az új sorokat (
INSERT
) -
frissíti a meglévőket, ha változott bármelyik mező (
UPDATE
) -
így az adattárház tábla mindig naprakész marad
-
🔍 Tobábbi bővítési lehetőségek
-
Audit tábla: naplóz, ki és mikor töltött be mit
-
Hash alapú változásdetektálás: gyorsabb összehasonlítás
-
Historikus DW táblák: változáskövetés (pl. SCD Type 2)
-
Automatikus időzítés (
cron
,Airflow
,dbms_scheduler
)
A hash-alapú változásdetektálás egy hatékony technika az adattárház betöltés során, különösen nagy adatmennyiség vagy sok mező összehasonlítása esetén.
Ez a módszer segít gyorsan eldönteni, hogy egy rekord változott-e a staging és a cél (DW) tábla között, anélkül hogy minden mezőt külön-külön kellene összehasonlítani a MERGE
-ben.
🎯 Mi a cél?
👉 Minimalizálni az UPDATE
műveleteket a MERGE INTO
-ban, csak ha tényleg változott az adat.
🧠 Ötlet lényege:
-
Kiszámítunk egy hash értéket a mezőkből a staging táblában (pl.
summary
,status
,priority
, stb.) -
Ugyanilyen hash érték van tárolva a DW táblában
-
MERGE
során csak akkor történikUPDATE
, ha a staging és DW hash értékei eltérnek
🧱 1. Oracle DW tábla kiegészítése
⚙️ 2. Hash érték kiszámítása – Oracle oldalon
Használjunk pl. STANDARD_HASH
függvényt:
🧩 3. MERGE INTO
módosítva – hash logikával
🔍 Előny: A WHERE
záradékban egy mezőt hasonlítunk össze (hash_val
), nem négyet.
🐍 4. Python alternatíva: hash érték kiszámítása előre
Ha a hash-t inkább Pythonban szeretnéd előállítani, használhatod:
Majd az issue_rows
rekordhoz hozzáadhatod a hash_val
mezőt, és betöltöd a stagingbe.
Ez akkor hasznos, ha:
-
az Oracle hash függvény nem elérhető (pl. régi verzió)
-
a logikát teljesen Pythonban szeretnéd kontrollálni
🧵 Összefoglalva
Előny | Miért jó a hash-alapú változásdetektálás? |
---|---|
✅ Gyors | Csak egy mezőt hasonlít össze |
✅ Egyszerű | Nem kell minden mezőhöz OR logika |
✅ Skálázható | 10–20 mező esetén is könnyen kezelhető |
✅ Kompatibilis | Oracle STANDARD_HASH vagy Python hashlib |
Bemutatok egy teljes Python példát, amely:
-
Lekérdezi a JIRA
issues
adatokat REST API-n keresztül (egyszerűsített dummy adat) -
Kiszámítja a hash-t Pythonban (
hashlib
segítségével) -
Staging Oracle táblába tölti be az adatokat (
jira_issues_stg
) -
Majd Oracle oldalról
MERGE INTO
-val tölti ajira_issues_dw
táblába a hash alapján, változásdetektálással
📁 Mappastruktúra (ajánlott)
📌 1. config.py
🧮 2. utils.py
– hash számítás
🔄 3. jira_loader.py
– REST hívás + hash + staging betöltés
🏗️ 4. Oracle staging + DW tábla
Staging tábla:
DW tábla:
🚀 5. dw_loader.py
– MERGE INTO
🧪 6. main.py
– futtatás
✅ Mit nyertünk?
Funkció | Megoldás |
---|---|
REST API lekérés | requests |
JSON parsing | Python native |
Hash számítás változásra | hashlib |
Oracle staging betöltés | cx_Oracle.executemany() |
DW betöltés csak változásra | MERGE INTO + hash összehasonlítás |
SCD2 elvek és használatuk
SCD Type 2 (Slowly Changing Dimension Type 2) logikára jellemző Megőrzi az adatok történetét, nem csak frissít, hanem új sort hoz létre, ha egy érték változik (pl. státusz vagy prioritás megváltozik egy JIRA issue-n).
🧠 Alapelvek – SCD Type 2
Mező | Szerepe |
---|---|
issue_id | Business kulcs (azonosítja az entitást) |
start_date | Érvényesség kezdete |
end_date | Érvényesség vége (NULL = aktuális rekord) |
current_flag | Y / N jelzi, hogy az adott rekord az aktuális verzió-e |
hash_val | Segít detektálni, hogy változott-e valami |
Egyéb mezők | summary , status , priority , stb. – változhatnak időben |
🏗️ 1. DW Tábla SCD 2 struktúrával
🔁 2. MERGE
helyett → SCD2 logika (Python + SQL együtt)
Python logika:
-
Hash-t kiszámítod, staging-be betöltöd (ahogy eddig)
-
DW-ben megnézed: van-e aktív rekord (current_flag = 'Y') az issue_id-re
-
Ha nincs: INSERT
-
Ha van, de a
hash_val
különbözik:-
Lezárod a régit (
end_date
,current_flag='N'
) -
Újat nyitsz (
current_flag='Y'
,end_date=NULL
)
-
🧩 3. SCD Type 2 betöltés Pythonban – scd2_loader.py
🔄 4. main.py
frissítése
✅ Eredmény: Történetmegőrzés DW-ben
issue_id | summary | status | start_date | end_date | current_flag |
---|---|---|---|---|---|
10001 | "Bug A" | "Open" | 2024-01-01 | 2024-03-01 | N |
10001 | "Bug A" | "Resolved" | 2024-03-01 | NULL | Y |
✨ Bővíthető funkciók
-
updated_by
mező (ki frissítette) -
change_reason
mező (miért lett változás?) -
is_deleted
jelölés törölt elemekre -
Historikus
custom_field
dictionary-vel bővítés
Megjegyzések
Megjegyzés küldése