Zobrazují se příspěvky se štítkemDWH. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemDWH. Zobrazit všechny příspěvky

pátek 2. května 2014

Oracle BigData Summit


  • Enterprise-wide Business Analytics from Office to Mobile
    (Tomáš Pospíšil, BI Sales Representative Oracle)
  •  Big Data experience from customer implementation    
    (Martin Patočka, Principal Consultant Oracle)



čtvrtek 15. března 2012

Prezentace z Oracle Partner Technology Day - 2. sekce zaměřené na BI/DW/DIS

13.3.2012 proběhl v andel's Hotel Prague další ročník Oracle Partner Technology Day. Prezentace z druhé sekce zaměřené na Business Intelligence, Data Warehousing & Data Integration najdete níže.

pondělí 3. října 2011

čtvrtek 22. září 2011

Oracle Database Appliance




Více informací o Oracle Database Appliance najdete zde.

pondělí 18. července 2011

Prezentace z DWH semináře pro BI/DW komunitu

Ve čtvrtek 30.6.2011 proběhl seminář na téma "Jak nejlépe řešit paralelní úlohy v DWH", prezentace ze semináře najdete níže:

  1. Paralelní zpracování, partitioning - praktické dopady
    Jakub Illner

  2. Oracle Database 11g – novinky pro DWH
    David Krch

  3. Oracle Data Integrator 11g - novinky, tipy a triky
    Erik Eckhardt

  4. Úspěchy Exadaty v DWH nejenom
    Josef Krejčí

pondělí 23. května 2011

7. Oracle Czech BI/DW Experts Bootcamp

V pátek 20.5.2011 proběhl již 7. Oracle Czech BI/DW Experts Bootcamp, kterého se zúčastnilo 13 vybraných konzultantů a architektů od 11 Oracle partnerů:
  • Jiří Zamouřil (Oracle Consulting)
  • Petr Šimbera (Simora)
  • Jan Jůza (CCA)
  • Karel Hübl (GEMsystem)
  • Jiří Doubravský (Pike Electronic)
  • Jiří Bohuslav (Sophia Solutions)
  • Petr Kovář (SITEWELL)
  • Richard Sklenařík (NESS Logos)
  • Jan Nožka (Neit Consulting)
  • Michal Kaštovský (Sefira)
  • Jaroslav Oplíštil (Adastra)
  • Martin Čevela (O2 Business Solutions)
  • Jakub Illner (Oracle Consulting)

  • Erik Eckhardt, Josef Krejčí, Petr Podbraný (Oracle Presales)

Agenda setkání a prezentace:

I. část - Tipy, triky a zkušenosti z BI/DW projektů:

II. část - Novinky z Oracle

čtvrtek 29. dubna 2010

FAT – FACTORY TESTY V DWH

1. Co jsou Factory testy?
FAT – Factory Acceptance Test - je jeden z řady mnoha testů, které se provádějí před nasazením DWH nebo jeho nové verze do provozu.

FAT plynule navazuje na Unit a Extract testy (EAT) a dále pokračuje uživatelskými testy (UAT) jež zahrnují systémové integrační testy, testy bezpečnosti systému (SAT), ověření správnosti statických dat (SDAT) a regresní testy (RAT). Celý proces testování je završen podepsáním akceptačního protokolu. V tomto článku se zaměřím pouze na jednu část tohoto testovacího řetězce, na popis FAT.

FAT je první test, který umožňuje ověřit nasazované řešení jako celek. Do této chvíle se ověřovala správná funkčnost jednotlivých modulů řešení, ale teprve test celého systému DWH nám umožní říci, že dodávané řešení je kompletní a s požadovaným chováním.

V průběhu FAT je potřeba se zaměřit na následující části DWH:
• Migrace
• Datový model
• ETL Moduly
• Procesy
• Výstupy - reporty, uživatelské rozhraní (EUL) a dávkové rozhraní
• Dokumentace

FAT se provádějí v rámci vývojového týmu tj. maximálně se využívají stávající vývojáři DWH a jejich vývojové nástroje. Jak externí síly lze využít administrátory databáze pro přípravu testovacího prostředí.


1.1 Test migrace
Každé nové řešení DWH je nutno nasadit do běžného – produkčního provozu. Je celkem jedno, zda se jedná o první nasazení DWH nebo jen doplnění nové funkčnosti do již existujícího DWH, vždy se však musí nově vyvinuté řešení nasazovat prostřednictvím migračních modulů, které jsou seskupovány do migračních procesů. Vždy je od migrace vyžadováno, aby proběhla rychle a bez problémů, v přesně definovaném časovém úseku. Aby bylo tohoto dosaženo, je nutno migrační proces otestovat již v rámci FAT.

Cílem tohoto testu je ověřit že:
• do migrace jsou zařazeny všechny požadované moduly
• moduly provádějí požadovanou činnost
• moduly obsahují požadované informační části (autor, popis, datum změny …)
• moduly se vzájemně nechtěně neovlivňují
• moduly jsou prováděny v požadovaném pořadí
• moduly jsou dokončeny v požadovaném čase
• migrace se zastaví v případě výskyty chyby v některém z modulů
• všechny aktivity modulů jsou auditovány

Vzhledem k tomu, že test migrace vyžaduje vždy přípravu nového prostředí DWH, migraci nelze spouštět opakovaně, provádí se tento test ve FAT pouze jednou. Ověření správnosti opravy chyb nalezených v tomto testu se nechává do testů UAT.


1.2 Datový model
Cílem tohoto testu je ověřit správnost nasazovaného datového modelu DWH. V průběhu tohoto testu je nutno provést kontrolu:

Tabulek
– zda vytvořené tabulky jsou správně pojmenované a jejich jména splňují metodické požadavky, tabulky jsou umístěny ve správném databázovém prostoru a obsahují požadované oddíly (partition).

Sloupců tabulek – zde je třeba ověřit správnost názvu sloupce, jeho datový typ a délku, omezení sloupce

Primární a unikátní klíče tabulek – název klíče musí odpovídat definovaným standardům a klíče musí obsahovat správné sloupce a to ve správném pořadí

Indexy – názvy indexů musí odpovídat standardům a musí být umístěny ve správném databázovém prostoru.

Poznámka: Ač jsou view a triggery standardně požadovány za součást datového modelu, zde je nutno je zahrnout do testů ETL modulů neboť jejich definice je většinou výstupem programátorské práce a jsou i součástí ETL procesů. View používané v EUL je nutno testovat jako součást testů uživatelského rozhraní.


1.3 ETL moduly
ETL modul je logická komponenta DWH, která zajišťuje přenos dat ze zdroje do cíle (zdroj i cíl může být zároveň DWH) podle zadaného algoritmu.
Smyslem tohoto testu, je ověřit kompletnost realizovaných ETL modulů vůči logickému mapování uvedenému v zadávací dokumentaci.

Požadavek je, aby pro testování byla ve zdroji dostupná data rozsahem blížící se skutečnosti. U každého ETL modulu je nutno ověřit:

Opakovatelnost – modul musí být opakovaně spustitelný nad stejným vzorkem dat. V případě, že tomu tak není, je nutno tuto informaci udržovat v dokumentaci modulu.
Pokud data na vstupu i v cíli nebyla změněna a nezměnilo se podmínky běhu, nesmí mapování, při opakovaném běhu, provádět žádné změny na cílových datech

Logování – každá modul musí o své činnosti zaznamenávat informace (začátek a konec běhu, počet zpracovávaných záznamů, počet vložených a změněných záznamů)

Ošetření chyb – modul musí v případě chyby, i jediné, ukončit svoji činnost a ohlásit příčinu chybu.

Funkcionalita – podle určení modulu je nutno otestovat zda modul vkládá, mění nebo jen maže záznamy ve svém cíly podle zadaného algoritmu popsaného v zadávací dokumentaci.

Reversibilita – modul musí umět záznam, které je označen jako logicky zrušený, tento záznam nastavit jako aktivní.

Výkonnost – doba zpracování dat modulu musí být přiměřená jako pro zpracování plné množiny dat na vstupu, tak i přírůstkového množství. FAT však nejsou primárně určeny k výkonnostním testů, neboť i dostupné systémové prostředky výpočetní techniky bývají omezené, ale již zde se dá přehledově určit, zda je implementace logického mapování navržena optimálně s dostatečnou výkonnostní rezervou. Zde nalezené problémy je ještě možno včas a s minimálními náklady odstranit.

Spolupráce s ostatními moduly – modul nesmí negativně ovlivňovat současně běžící jiné moduly tj. např. nesmí zamykat celé tabulky, pokud to není vyžadováno funkcí mapování.


1.4 Procesy
Procesy spojují jednotlivé ETL moduly do jednoho celku, který doplňují o podpůrné funkce jako je vytváření a mazání partition, počítání statistik a mnohé další.ETL moduly jsou propojeny logickými operátory, které umožňují jejich paralelní běh. Při testech procesů je nutno se zaměřit na:

Kompletnost – proces obsahuje všechny ETL moduly spouštěné ve správném pořadí a se správnými parametry.

Závislosti – pro každý proces musí být nastaveno za jakých podmínek je možné proces spustit tj. jaká vstupní data musí být k dispozici, které další procesu musí být dokončený nebo naopak nesmí běžet současně.

Reakce na vstupní data – proces musí být schopen na základě typu vstupních dat (plný/přírůstkový) spouštět příslušné modulu

Oznámení – proces při dokončení nebo v případě chyby zasílá oznámení příslušným adresátům s doplňujícími informacemi např. o počtu zpracovaných záznamů.


1.5 Výstupy - reporty,uživatelské rozhraní EUL a dávkové rozhraní
Reporty a uživatelské rozhraní je klíčový prostředek pro zpřístupnění dat koncovým uživatelům. Testy této oblasti budou maximálně soustředěny v dalších kolech UAT. V prostředí FAT je však možno zkontrolovat:

Kompletnost - jsou připraveny všechny požadované reporty nebo jejich vzory. EUL obsahuje všechny datové položky, které mají být zpřístupněny. Aktivní prvky reportů vykonávají svou činnost.

Datovou kvalitu – reporty zobrazují správné datové položky v odpovídajícím formátu. Data pro EUL jsou aktualizována.

Testy dávkového výstupního rozhraní zahrnují oba výše uvedené body. Je nutno zkontrolovat jak úplnost – v dávce jsou zahrnuty všechny soubory, tak i obsahově.


1.6 Dokumentace
Obsah dokumentace je sice schvalován při vytváření požadavků pro vývoj, přesto v průběhu vývoje může dojít k realizaci změnových požadavků nebo k odchylkám (samozřejmě schváleným uživateli) od původního zadání. Všechny tyto změny musí být podchyceny v aktuální podobě v dokumentaci projektu. Nejlépe se kompletnost a především pochopitelnost dokumentace pro i jiné účastníky projektu, ověří v průběhu FAT tak, že jednotlivé testovací případy nevytváří ani zadavatel, ani programátor, ale tester, doposavad do problematikou dané oblasti se nezabývající.


2. Příprava testů
Přípravu FAT nelze nijak podcenit a je nutno se na tyto testy začít připravovat se začátkem vývoje. Je nutné zajistit připravenost testovacích dat, testovací infrastrukturu a rozdělit testovací oblasti mezi budoucí testery. Osvědčilo se křížové rozdělení jednotlivých oblastí mezi vývojáře, tak aby žádný vývojář netestoval oblast kterou vyvíjel. Časová souslednost je znázorněna na časovém diagramu na obr. 1


  • Příprava TC – testovací případy jsou připravovány již v průběhu vývoje

  • Provádění TC (Datový model) – testy datového modelu mohou být prováděny již v průběhu vývoje, neboť úplný datový model je nutný předpoklad pro zahájení fáze vývoje

  • Provádění TC (Migrace) – test migrace je první test provádění v rámci FAT

  • Provádění TC (ETL moduly) – testy infrastrukty lze provádět již v průběhu vývoje, ale jinak se jedná o hlavní náplň FAT

  • Provádění TC (Procesy) – testy procesů probíhají po celo dobu FAT

  • Provádění TC (Výstupy) – testy uživatelského rozhraní a dávkové výstupy lze provádět až po nahrání všech dat ETL moduly...
Na podporu FAT a přípravu testovacích případů je výhodné využít některých z bug tracking systémů neboť se tím docílí vyšší produktivity testů.


3. Shrnutí
Provedením všech požadovaných kroků FAT a vyhledáním maximálního počtu chyb v DWH již ve FAT a jejich odstranění, umožní zdárné dokončení celého vývojového cyklu DWH a zvýší prestiž dodavatele řešení.


Jiří Zamouřil (Oracle Consulting)

pondělí 12. dubna 2010

Oracle Warehouse Builder 11g Release 2 (11.2.0.1.0) Standalone Software je k dispozici

Týden po uvolnění Oracle Database 11g Release 2 pro MS Windows je k dispozici i samostatná verze OWB 11g Release 2 (11.2.0.1.0). Stáhnout si ji můžete zde.

úterý 6. dubna 2010

Oracle Database 11g Release 2 pro MS Windows je již ke stažení

Na OTN je od pátku ke stažení Oracle Database 11gR2 (přesně 11.2.0.1.0) i pro MS Windows, link najdete zde (Standalone verze OWB 11gR2 zatím dostupná není).



eec.

pátek 5. března 2010

Seminář: Vlastnosti Oracle Database 11g pro Datové sklady

Dnes dopoledne proběhl seminář o novinkách Oracle Database 11g pro Datové sklady. Všem účastníkům semináře děkujeme! Prezentace ze semináře jsou dostupné níže.


Prezentace ze semináře:

eec.

pondělí 11. ledna 2010

Data Mart pro ČNB výkaznictví

1. Popis oblasti
Data mart pro ČNB výkaznictví jinak také Regulatory reporting data mart (dále jen RRDM) vznikl na základě požadavku na vytvoření hybridního data martu od oddělení Regulatorní výkaznictví Banky. Data mart je stavěn jako nadstavba již existujícího datového skladu. V prvním kroku bylo rozhodnuto, že nově budovaný data mart bude přebírat data, která do DWH již nyní dodávají, následující systémy:
  • Systém kreditních karet
  • Systém pro běžné privátní klientské účty
  • Hlavní kniha – Finanční systém Banky
  • Klientský pobočkový systém
  • Externí data – Správa externích dat DWH
  • Finanční rekonciliace – Rekonciliace finančních dat ze zdrojových systémů a Hlavní knihy v DWH
2. Popis současného stavu
Oddělení regulatorního výkaznictví v současné době provozuje, na DWH zcela nezávislý, data mart, který slouží pro potřeby tvorby reportů pro ČNB. Tento data mart je plněn daty z různých zdrojových systémů v různé podobě a tvoří datovou základnu pro systém DaMiAs.
Data Migration Asistant (DaMiAs) je soubor programů plnících funkci rozhraní a zároveň datové pumpy, kdy vstupní část je závislá na konkrétní struktuře dat v datovém skladu. Výstupem jsou pak zpracované údaje importované do jednotné datové základny SDI.
Požadavek na nový, částečně závislý, data mart vznikl, aby došlo především k odstranění negativních důsledků aktuálního stavu:
  • Business intelligence architektura Banky nemá jednotnou platformu,
  • Zdroje nejsou vynakládány efektivně – je nakupován dodatečný hardware, v databázích jsou uložena duplicitní data,
  • Systémy nejsou podporovány ze strany úseku IT vývoj
Současná architektura datového skladu a závislých data martů v Bance vychází a je založena na metodice Ralpha Kimballa, i když ne vždy zcela dogmaticky dodržované.

3. Návrh řešení
Navrhované řešení RRDM je zobrazeno na následujícím obrázku.


Jedná se o hybridní řešení data martu, kdy struktury tabulek jsou orientované výkaznicky, tj. tabulky jsou vlastně časové řezy, vždy k ultimo měsíce. RRDM se skládá ze tří vrstev:
Závislá část RRDM (datově závislá na DWH) zahrnuje vrstvy L0 a L1. Nezávislou část (plněná a spravovaná prostřednictvím systému DaMiAs) tvoří vrstva L2. Části, na obrázku vybarvené odstíny modré barvy, budou vytvářeny a budou plněny v rámci vývoje nového inkrementu DWH.
Návrh logického datového modelu pro vrstvy L0 a L1 je znázorněn na ER diagramu:


Vrstva L1 je, z hlediska entit a jejich vazeb, téměř stejná jako L0 a liší se pouze o barevně zvýrazněné entity. Červeně označené v L1 chybí, modře označené mají v L1 jinou strukturu (liší se v atributech a případně granularitou záznamů).

3.1 Vrstva L0
Popis
Jedná se vrstvu, ve které jsou umístěny tabulky, které jsou přímo plněné z jediného zdroje – DWH. Součástí této vrstvy může být i oblast externích dat (RRDM_EXT), což jsou číselníky a převodové můstky spravované manuálně a používané pouze pro RRDM. V tomto inkrementu oblast externích dat nebude realizována, neboť nevznikl žádný požadavek na číselník pro RRDM
Tabulky jsou členěny, tam kde to má význam, podle typu účtu nebo zdroje klienta
Vrstva může obsahovat pomocné – stage tabulky pro optimalizaci zpracování dat.

Zpracování dat
Data se do této vrstvy vkládají jednou měsíčně, vždy po uzavření měsíce v DWH pro daný zdrojový systém. Data se nahrávají automaticky po jednotlivých zdrojových systémech samostatným procesem pro každý zdroj. Při nahrávání se stávající data nejprve vymažou a potom se nově vkládají.

Historie dat
Je udržována datová historie pouze pro jeden – aktuální měsíc. Data nejsou archivována.

Přístup uživatelů
Do této vrstvy mají přístup všichni uživatelé s právem pro výběr dat (select) bez možnosti data měnit. Tito uživatelé mají roli RRDM0_ALL_SELECT. Data zde lze upravovat pouze opětovným spuštěním standardního procesu nahrávání dat. (role RRDM0_ALL_CHANGE).

Umístění
Tabulky této vrstvy jsou umístěny pod uživatelem RRDM0_OWNER.

3.2 Vrstva L1
Popis
Vrstva L1 je plněna ETL procesem z vrstvy L0. Tato vrstva dále obsahuje výstupní tabulky z DaMiAs, která je dále využívána reportovacím systémem SDI. Součástí této vrstvy bude Data Correction Tool (DCT), což je pro Banku vyvinutý nástroj na opravu dat.
Tabulky jsou členěny stejně jako v L0, obsahují však navíc členění podle času – měsíční členění.
V této vrstvě budou také definovány tabulky OUT_GL_STAV_DETAIL a OUT_GL_STAV, do kterých bude systém DaMiAs vkládat data. Struktury těchto tabulek a indexy tabulky definuje Oddělení regulatorního výkaznictví. Tabulky budou mít členění podle času. Partition bude definována jako měsíční, vždy k ultimo měsíce.

Zpracování dat
Data jsou plněna na měsíční bázi. Kromě tabulek GL_ACCOUNTS, ACCOUNT FR BALANCE a GL_ACCOUNT_CLASSF_USAGES, které v L1 zcela chybí a tabulek ACCOUNT_GL_BALANCES a GL_BALANCES, které se v některých atributech odlišují, jsou tabulky shodné s vrstvou L0. Data v L1 mohou být upravována:
  • Standardním spuštěním ETL procesu
  • Manuálně prostřednictvím DCT
  • Skriptem, který všechny změny ukládá do zvláštní log tabulky, společné s DCT
V současné době DCT nemá definováno API pro logování změn v externích skriptech nebo aplikacích, proto toto aplikační rozhraní musí být připraveno v rámci vývojových prací.

Historie dat
Požadavkem uživatelů je mít data dostupná po dobu 6 měsíců přímo v databázi a po dobu 10 let z offline zálohy. Obnova ze zálohy starší 6 měsíců by se prováděla jen na základě požadavku Oddělení regulatorního výkaznictví. Pro offline zálohu je navrženo rozšíření stávajícího Operátorského prostředí DWH o možnosti archivace databáze do formátu Oracle Export nebo Oracle Data Pump. Takto extrahované archivační soubory budou uloženy v archivačním systému Banky. Po dobu, než bude vyvinuta DWH Archivace, nebudou data v RRDM mazána. Předpokládá se nasazení DWH Archivace v průběhu jednoho roku, tj. data v L1 by měla být maximálně za 12 měsíců.

Přístup uživatelů
Do této vrstvy mají přístup všichni uživatelé s právem pro výběr dat (select) bez možnosti data měnit. Tito uživatelé mají roli RRDM1_ALL_SELECT. Data zde lze upravovat pouze opětovným spuštěním standardního procesu nahrávání dat. (role RRDM1_ALL_CHANGE) nebo skriptem resp. DCT s rolí RRDM1_DC_CHANGE

Umístění
Tabulky této vrstvy jsou umístěny pod uživatelem RRDM1_OWNER. Výstupní tabulky DaMiAs potom pod uživatelem OUT_OWNER.

3.3 Vrstva L2
Popis
Vrstva L2, jedná se o nezávislou část RRDM, bude spravována a řízena systémem DaMiAs. Do této vrstvy budou data nahrávaná z vrstvy L1 a dalších systémů, které budou ve správě administrátora DaMiAs. Pro tuto vrstvu bude vyčleněn tabulkový prostor 100 GB.

Zpracování dat
Data budou zpracovávána pouze prostřednictvím systému DaMiAs. Postupy a metody tohoto zpracování nejsou součástí tohoto dokumentu a ani nejsou součástí tohoto řešení.

Historie dat

Délka historie dat je řízena systémem DaMiAs.

Přístup uživatelů

Nepředpokládá se, že do této vrstvy budou přímo přistupovat uživatelé. Veškerá správa se bude provádět prostřednictvím DaMiAs, který bude využívat vlastníka této vrstvy DAMIAS_OWNER.

Umístění

Tabulky této vrstvy budou umístěny pod uživatelem DAMIAS_OWNER

4. Změny prováděné v DWH
Tato koncepce řešení RRDM nevyžaduje žádné zásadní změny v ODS/DWH kromě následujících:
  • Budou doplněny procesy pro plnění a čištění tabulek RRDM do Operátorské konzole DWH
  • Bude doplněna funkčnost Operátorského prostředí o DWH Archivaci
  • Pro optimalizaci plnění - L0 mohou být v DWH vytvářeny dočasné – stage tabulky
  • Externí číselníky klasifikací budou doplněny o nové typy

5. Požadavky na DaMiAs
Pro správnou práci s výstupními OUT tabulkami ve vrstvě L1 musí systém umožňovat tyto aktivity:
  • Správu partition v OUT tabulkách (přidání nové, smazání obsahu – truncate)
  • Správu indexů OUT tabulky (enable/disable/analyse)
V případě práce s daty – masivního vkládání nebo změny záznamů, se doporučuje nejprve provést zneplatnění indexů a jejich opětovné uvedení do provozu s přepočtem statistik, po dokončení změn v tabulce.
Rušení partition bude prováděno v rámci procesu Purge strategie RRDM.
V případě požadavku na změnu struktury OUT tabulky, bude postupována standardním změnovým řízením.
V rámci akceptačních testů musí proběhnout integrační testy s DaMiAs.
Mezi RRDM a „starou“ DaMiAs databází bude vytvořen veřejný databázový link Pro využívání tohoto linku musí být na cílové straně vytvořen uživatel se stejným jménem a heslem jako na straně RRDM.

6. Shrnutí řešení
Celá koncepce hybridního data martu je navržena tak, aby byla snadno rozšiřitelná o další zdrojové systémy, což se i v dalších inkrementech předpokládá. Pro zpětné ověření dat bude, po dobu než dojde k převedení agendy všech zdrojových systému, která reporting vyžaduje, do RRDM zpřístupněno původní „starý“ DaMiAs data mart to prostřednictvím databázového linku.

Obecné výhody navrženého řešení jsou:
  • Využití existujícího hardware, resp. jeho sdílení. Pokud bude nutné jeho posílení investice je provedena pouze na jednom místě
  • Standardizovaná platforma (Oracle / UNIX)
  • Je vyřešeno předání do provozu, zálohování a denní provoz
  • Je zajištěna produkční podpora závislé části


Jiří Zamouřil (Oracle Consulting)

čtvrtek 17. prosince 2009

Metadata a navsteva u zubara

Kazdy z nas vie, ze je treba chodit na pravidelne prehliadky k zubarovi, ale nie uplne vsetci to aj robime. Problem, ktory moze a v konecnom dosledku nemusi vzniknut za rok-dva nas malokedy trapi dnes - vzdy mame nieco urgentnejsie na programe.

To iste podla vyskumov Gavilan Research Associates plati aj o metadatach. Primarna uloha BI/DW projektov (tak isto ako lubovolneho ineho projektu ;) je “dodat” v definovanom case a rozpocte. V takom momente si casto povieme - naco mam robit logicky model, ked mozem nakreslit rovno fyzicky, preco sa tu mam rozpisovat v popisu tabulky, ked aj tak vsetci vedia, ze su tam zostatky na uctoch alebo naco mam pracne vyklikavat transformacie, ked SQL dotazom to urobim na dve doby!!!

Vsetkym tymto situacia a rozhodnutiam rozumiem, ale po par rokoch pouzivania riesenia sa zacnu ukazovat “kazy”. Konkretne sa objavuju v momente ked sa menia ludia, legislativa alebo systemy. V tom momente sa cas a energia usetrena na pociatku obrovskym sposobom negativne zuroci a napr. zmena sposobena patchom zdrojoveho systemu moze trvat mesiace kym sa vyhodnotenia mozne dopady na zavisle systemy, lebo je potrebne prechadzat SQL dotazy, ktorym nikto nerozumie nad tabulami, ktore netusime co znamenaju.

Problemy suviace s metadatami podla cetnosti vyskytu


Systemy alebo aplikacie najviac postihnute problemami s metadatami


Urcite nebudem nikoho presvedcat, ze ma od zajtra vsetko robit cisto a dokumentovat kazdu entitu, na ktoru narazi. Co moze uplne bohate stacit je naucit sa plnohodnotne pouzivat modelovacie nastroje. Vacsina z nich umoznuje automaticke generovanie dokumentacie, ale malokto si da tu pracu. A co je asi najcastejsi moment - nestiha sa jadro projektu a tak na jeho dopracovanie sa pouzije nielen kalkulovana rezerva, ale aj cas kedy sa malo dokumentovat a testovat t.j. myslite na metadata pri tvorbe projektoveho planu nech mozete za sebou nechat dielo, ktore moze zit dlhy a zdravy zivot.


BTW kedy ste boli naposledy u zubara? (^_^)


Peter Hora (Semanta)

pondělí 7. prosince 2009

Oracle University připravuje školení IMPLEMENT AND ADMINISTER DATA WAREHOUSE

Od 18.1.2010 pořádá Oracle University čtyř denní školení Oracle DB: IMPLEMENT AND ADMINISTER DATA WAREHOUSE.
Školení je určeno pro databázové a systémové administrátory a vývojáře BI aplikací, kteří navrhují a spravují datové sklady (přesnou agendu školení najdete zde).

Máte-li o školení zájem, pak přímo kontaktuje Oracle University na education_cz@oracle.com.



eec.

pondělí 23. listopadu 2009

4. Oracle Czech BI/DW Experts Bootcamp

V pátek 20.11.2009 proběhl již 4. Oracle Czech BI/DW Experts Bootcamp, kterého se zúčastnilo 14 vybraných konzultantů a architektů od 12 Oracle partnerů:
  • Jaroslav Vlček (Adastra)
  • Jan Jůza (CCA)
  • Karel Hübl (GEM system)
  • Michal Tomek (Neit Consulting)
  • Lukáš Hrnčíř (Neit Consulting)
  • Václav Bíba (Ness Logos)
  • Petr Zeman (OKsystem)
  • Jiří Doubravský (Pike Electronic)
  • Jakub Genža (CapGemini)
  • Jiří Zamouřil (Oracle Consulting)
  • Martin Gerneš (Oracle Consulting)
  • Michal Zima (Teura)
  • Martin Cabák (Reporters)
  • Peter Hora (Sementa)

Agenda setkání:

Prezentace z 1. workshopu - Tipy, triky a zkušenosti z BI/DW projektů:

Erik Eckhardt (Oracle)
  • Zvýšení produktivity vývoje s ODI - Tvorba, úpravy a spouštění více jak +900 datových přenosů
Karel Hubl (GEM System)
  • Efektivní datové integrace s ODI
  • OBI 10.1.3.4.1 – Problém s filtry pro numerické datové typy
Michal Tomek (NEIT Consulting)
  • Essbase - trigger pro instalaci HSS
  • Posílání reportů z linuxového Publisheru na windowsový fileserver
  • 64bitová Essbase pro Linux
Jan Jůza (CCA)
  • Tipy, triky a zkušenosti z projektu „Převod analýz z Excelu do Oracle BI”
Jiří Doubravský (PIKE)
  • Použití kombinace funkcí Time Series (AGO a TODATE)
  • Doplnění legendy do reportu přes XML
  • Vliv nevhodného pojmenování časového údaje na použití v promptu
Michal Zima (Teura)
  • Zkušenosti s implementací OBIEE v clusteru
Jakub Genža (Capgemini Sophias)
  • Jak v OBI změnit defaultní menu pomocí currencies.xml (zkusenost z BIAPPS)
  • Jak v BIAPPS/ODI resetovat/vymazat jen jeden z modulů, ne celý warehouse (není zdokumentováno)
  • Jak odstranit v Answers při filtrování odkaz "Omezené volby", který může vygenerovat dost narocný dotaz
Jaroslav Vlček (Adastra)
  • BI Delivers versus autentifikace proti DB
Lukáš Hrnčíř (NEIT Consulting)
  • Transformace datových a report požadavků do designu metadat a designu reportů
Martin Gerneš (Oracle Consulting)
  • Integrace OBI EE, SSO, OAM, OID
  • Operátorská konzole pro OWB a ODI
Peter Hora (Semanta)
  • Komentáře a diskuze pro Oracle BI

čtvrtek 12. listopadu 2009

Oracle 11gR2 - Hybrid columnar compression

Před několika týdny byla uvolněna nová verze databáze Oracle 11G R2 a ta, mimo jiná „vylepšení“, obsahuje jednu velmi zajímavou funkčnost, která se týká způsobu uložení dat. Na první pohled to vypadá jako převratná novinka ve světě uložení dat, ale Oracle není první, kdo se pustil do vertikálního konceptu. Na druhou stranu můžeme být jen rádi, že Oracle stále sleduje současné trendy vývoje v oblasti relačních databází pro systémy pro podporu rozhodování a v ničem nezůstává pozadu proti specializovaným produktům pro DWH/BI ostatních konkurentů. Prvním důkazem je nám všem dobře známá Exadata, která je pravou Datawarehouse Appliance, a samozřejmě její víc než zajímavé vylepšení, a to nejen technologické, tak zejména z hlediska poměru ceny za TB, v podobě Exadata 2. Druhým průlomovým krokem je funkcionalita, o které bych se rád zmínil v tomto článku, a to hybridní vertikální komprese.

Relační databáze, které jsou dnes dostupné na trhu, podporují vesměs jeden z následujících dvou konceptů uložení:
  • Řádkové uložení, neboli N-ary Storage Model (NSM)
  • Sloupcové uložení, neboli Decomposition Storage Model (DSM)
Řádkové uložení dat
Řádkové uložení je zřejmě nejvíce používaným způsobem uložení dat, tak jak jej známe ze všech verzí Oracle, MS SQL, PostgreSQL, MySQL a dalších. Data jsou ukládána po jednotlivých blocích a v rámci každého bloku jsou organizována po řádcích, stejně tak bloky jsou organizovány po řádcích. Každý řádek v rámci jednoho bloku obsahuje na začátku pointer, který označuje začátek řádku. To proto, protože řádky nemají fixní délku díky atributům s proměnnou délkou. Pokud je blok naplněn, další řádek se již zapisuje do dalšího volného bloku. Tento storage model je vhodný zejména pro OLTP systémy, kdy potřebujeme s vysokou selektivitou získat mnoho atributů z jednoho řádku. Pak se typicky provádí scan přes všechny řádky, případně indexy, filtruje se požadovaný záznam a vrací výsledek zpět. V případě OLAP/DSS systémů je výsledkem dotazu zpravidla restrikce (filtrování) dat, jejich následná agregace a projekce (vrácení pouze jednoho nebo několika atributů), jako např. aktuální počet zákazníků, nebo celkový objem transakcí za určité období. V tomto případě, i když potřebujeme z tabulky transakcí pouze datum a objem transakce, musíme projít všechny záznamy přes všechny atributy, což dotaz výrazně zpomaluje. Na druhou stranu čím více atributů z tabulky potřebujeme dostat, tím se řádkové uložení stává užitečnější.

Sloupcové uložení dat
Sloupcové, nebo také vertikální uložení dat, je koncept navržený výhradně pro DSS systémy. Místo toho, aby byly tabulky uloženy po jednotlivých řádcích, jsou uloženy po sloupcích. Hodnoty atributů jednotlivých řádků jsou tak uloženy vedle sebe, každá hodnota má navíc pointer, ukazující řádek, do kterého hodnota patří. Výhod tohoto způsobu uložení dat je hned několik – pokud použijeme v dotazu restrikci na určitý rozsah hodnot atributu (range restriction), pak se provádí nejprve scan jen jednoho atributu, po nalezení požadovaných hodnot se provádí tzv. rekonstrukce řádku, kdy se spojují nalezené hodnoty přes řádkový pointer na ostatní atributy a vrací se výsledek. V případě dotazů nad několika málo atributy je tento koncept vysoce efektivní proti řádkovému a přináší značné úspory v I/O operacích (čtení z disku). Problémy však nastanou, kdy je potřeba vrátit více atributů, pak se provádí nákladná rekonstrukce řádku přes více atributů a to zpracování velmi zpomaluje. Tento problém se však některé databáze snaží eliminovat pomocí tzv. „affinity graphs“, které seskupují atributy do skupin podle četnosti v dotazech. Další velkou výhodou vertikálního uložení dat je velmi rychlý update, pokud aktualizujeme jen jeden atribut přes všechny řádky. Poslední, ne nevýznamnou výhodou, je komprese, kdy pomocí vertikálního uložení dat můžeme dosáhnout mnohem vyššího kompresního poměru, proti řádkovému uložení. Důvodem je ukládání atributů po blocích a tím i možnost existence stejných hodnot v rámci jednoho bloku. Kompresí se také výrazně zrychluje čtení z disku, kdy se čte menší objem dat, tedy je menší náročnost na I/O a odpověď na dotaz je o to rychlejší. Tento koncept byl poprvé popsán již v roce 1979.

Příkladem relační databáze, používající vertikální koncept je Sybase IQ, která je na trhu už od 90 — tých let minulého století, dále pak novější a méně známé produkty, jako PARAccel, Infobright nebo Vertica.

PAX
Za tajemnou zkratkou PAX se skrývá název Partition Attributes Accross, což je koncept uložení dat, který byl poprvé popsán v roce 2001. Jedná se v podstatě o kombinaci dvou předchozích modelů, tedy řádkového a sloupcového s tím, že PAX eliminuje nevýhody obou a vytváří jakýsi hybrid, tedy „hybrid columnar storage“, na kterém je založena novinka v Oracle 11gR2.

Princip modelu spočívá v tom, že data jsou, podobně jako v případě řádkové uložení, ukládána po blocích, ale v rámci každého bloku jsou již organizována po sloupcích. V rámci bloku se vytváří tzv. minibloky, kde každý miniblok obsahuje hodnoty jednoho atributu pro řádky, které jsou součástí bloku. Tímto způsobem se eliminuje problém sloupcového uložení, kdy se musí provádět náročná rekonstrukce řádků při požadavku na větší počet atributů v dotazu, protože hodnoty atributu jsou uloženy spolu s ostatními atributy řádku v jednom bloku a tedy i rekonstrukce řádku je velmi jednoduchá. Při dotazu obsahujícím restrikci (filtr) na určitý sloupec jsou z disku čteny jen hodnoty tohoto sloupce, je provedena restrikce a následně rekonstrukce řádků. Neprovádí se tedy scan přes všechny atributy, jako v případě řádkového uložení, ale jen rychlý výběr hodnot jednoho sloupce. U tabulek s větším počtem atributů to může být velmi efektivní. Stejně tak zůstane zachována výhoda komprese u sloupcového uložení, kdy hodnoty atributu jsou uloženy vedle sebe. Teoreticky může být hodnota komprese zvýšena způsobem seřazení záznamů, kdy sloupec, podle kterého setřídíme data, bude mít nejspíše nejlepší kompresní poměr.

Oracle a PAX
V současné době existují pouze dohady, jakým způsobem je přesně implementován hybridní sloupcový model uložení v Oracle, pravděpodobně však inspirací je právě koncept PAX. Kompresí nad takto uloženými daty je pak možno dosáhnout 10x -40x kompresní poměr, podle charakteru dat (čím více opakujících se hodnot, tím vyšší kompresní poměr). Hovoří se také o možnosti vybrat si jen část dat, která bude uložena tímto způsobem a zbytek zůstane v klasickém řádkovém uložení. Zůstává otázkou, zda tento hybrid přinese i nějaký benefit v podobě zrychlení odezvy na některé typy dotazů. Z titulu komprese a tím menšího počtu I/O to pravděpodobné bude, z hlediska sloupcového uložení to záleží na skutečnosti, zda implementace je více sloupcová nebo více řádková. Více se snad dozvíme z dalších materiálů, které budou publikovány Oraclem k tomuto tématu.

V úvodu článku jsem se zmínil, že Oracle není jedinou databází, která přichází na trh s hybridní sloupcovou organizací dat. Dalším produktem, který se již brzy objeví na trhu je nová verze Vertica 3.5 a její koncept nazvaný Flex Store, který řeší něco podobného. Ovšem Vertica začala úplně z jiné strany než Oracle, jde od sloupcového uložení směrem k hybridnímu, Oracle od řádkového k hybridnímu. Budou tedy všechny databázové systémy pro podporu rozhodování v budoucnosti jen „hybridy“ ?


Radan Návrat (DWH architect v T-Systems)

pondělí 19. října 2009

Oracle Warehouse Builder 11gR2

Spolu s druhým releasem Oracle Database 11g byl v září uvolněn i druhý release Oracle Warehouse Builder 11g. Narozdíl od prvního release verze 11, která byla víceméně stejná jako verze OWB10gR2, je v současné verzi řada vylepšení a novinek (detailní seznam viz. níže).

Mezi ty nejdůležitější určitě bude patřit nativní podpora heterogenních zdrojů, Code-Template Mapping, webové služby a generování metadata repository pro Oracle Business Intelligence Enterprise Edition.

Tři výše uvedené jsou v současné chvíli prvním krokem integrace klasického OWB a ODI (v únoru 2009 jsem psal o vzniku nové edice s názvem Oracle Data Integrator Enterprise Edition, která licenčně spojuje Oracle Data Integrator a placenou DB Option OWB Enterprise ETL, která od té doby přestala být samostatně prodejná).

Zajímá-li vás roadmapa pro Oracle Warehouse Builder, pak ji najdete zde, Statement of Direction nejdete zde.

OWB11gR2 si můžete stáhnout z OTN
Bohužel stejně jako Oracle Database 11gR2 je i OWB11gR2 v současné době dostupné pouze na platformě Linux - tzn. chcete-li začít vyvíjet v novém OWB musíte mít jako OS klientské stanice Linux a nebo spustit OWB na některém z vašich Linux serverů a např. přes VNC nebo jiný remote desktop se k němu přihlásit.

Seznam nových vlastností OWB11gR2, seskupeno podle kategorií:
Upozornění: Z pohledu licencování mohou být některé nové vlastnosti použity pouze v případě, že vlastníte licenci Oracle Data Integrator Enterprise Edition. Seznam licencovaných vlastností najdete zde.

Native Support for Heterogeneous Databases

OWB now provides extensive built-in support for non-Oracle databases. JDBC connectivity is added alongside previous support for ODBC and database gateways, and OWB now supports in-database ELT operations on non-Oracle databases. Other enhancements improve access to data from non-Oracle sources such as mainframe and flat file data.

Features in this area include:

SOA Integration Enhancements for ETL and Data Quality

The ETL and data quality functionality in OWB can now be integrated into SOA-style architectures.

Features in this area include:

Data Warehousing and Business Intelligence Enhancements

The data warehousing-specific support in OWB has improved. These improvements provide smarter dimensional object operators for ETL and support for more storage types for dimensional objects.

Features in this area include:

Administrator Usability Enhancements

OWB administration tasks are simplified and improved by a number of features in this release. Administration has been extended to support new feature areas such as heterogeneous database support and Web services integration.

Features in this area include:

ETL Mapping Enhancements

ETL mappings have been enhanced to add new transformation capabilities and to improve the productivity of developers working with flat files and designing and debugging ETL mappings.

Features in this area include:

Process Flow Enhancements

OWB process flows have been enhanced to integrate with new activity types, out of the box, and to support integration of OWB ETL and data quality with SOA solutions.

Features that enhance process flows include:


Kompletní seznam nových vlastností OWB11gR2 je dostupný zde, dokumentaci najdete zde.



Erik Eckhardt.

čtvrtek 17. září 2009

EXADATA verze 2 je i pro OLTP




Představení a další informace najdete zde.

pátek 29. května 2009

První HP Oracle Database Machine / EXADATA v České republice

Dnes ve 13:00 dorazila první HP Oracle Database Machine / EXADATA do Kompetenčního centra pro Datové sklady a Business Intelligence (DWBICC) společnosti OKsystem. Její první a zatím jediné :) fotografie najdete níže.

Jde o konfiguraci v provedení Half Rack s následujícími parametry:
  • 4 x Database Server - HP Proliant DL360 G5 v konfiguraci:
    2 quad-core Intel Xeon Processor
    32 GB memory
    1– HP InfiniBand Dual Port HCA
    4 x 146GB SAS 10K hard disk drives

  • 7 x Exadata Storage Server - HP ProLiant DL180 G5 v konfiguraci:
    2 quad-core Intel Xeon Processor
    8 GB memory
    1 x HP InfiniBand Dual Port HCA
    12 x 450GB SAS disk drives












eec.

pondělí 16. března 2009

EXADATA - Inteligentní datové pole pro Váš DWH

Podívejte se na video ukazující sílu a inteligenci Oracle EXADATA Storage Serveru - diskové pole optimalizované pro úlohy řešené v Data Warehousingu a Business Intelligence.

Zajímají-li Vás reálné testy, pak si přečtěte tento dokument od společnosti Winter Corporation.