Vytvoříte vlastní server s překladačem SQL a místo provádění příkazů vytváříte schéma popisující datové toky. Pokud budete dále SQL příkazy posílat do reálné databáze, vznikne vám mezistupeň, kterým můžete sledovat datové toky přímo v reálném čase a na základě reálných dat ještě schéma datových toků doladit o statistické údaje ukryté v reálných datech.
V podstatě na to můžete použít PEG gramatiku, která vám umožní analyzovat jen potřebné části SQL příkazů, použijete-li k tomu ještě "pancrat parsing", tak použitý koš frází bude přirozeným kolektorem statistických dat a bude přímo odrážet datové toky.
Tak SQL compiler samozřejmě musí někdy přeložit i tuto uloženou proceduru, nebo předkompilovaný příkaz, takže zachytí a analyzuje i obsah. Takže budete vědět zda se někam zapisuje, odkud se čte atp. Samotné volání vám pak řekne, kdy se to někam zapisuje resp. čte. Jinak co nepotřebujete, můžete ignorovat a bez statistického zpracování poslat na reálný server. Pokud se vyvolá něco napsaného v jiném jazyce, tak se to může projevit voláním zase jiných SQL příkazů, které se zase někdy musely zkompilovat a jsou tedy podchyceny a nebo se pracuje přímo s interním formátem dat, ale to je prasečina sama o sobě a na tu samozřejmě neplatí vůbec nic, ale aspoň se odchytí informace o ní.
SP, funkci nebo ETL package muzete v pripade MS SQL serveru napsat v libovolnem .NETovem jazyce, protoze server podporuje tyto databazove objekty nejen v SQL ale i CLR.
Uz vidim, jak nekdo pise "SQL interpreter" ktery bude plne simulovat nejen konkretni podobu SQL jazyka daneho serveru, ale i vsechny jeho systemove ulozene procedury/funkce/views (a tim interni tabulky ktere udrzuji stav), ktere se opet bezne pouzivaji z aplikacni urovne.
Jestli je tu neco "prasecina", je to prave cely ten pochybny nastroj :-)
SQLDep není nástroj na záchranu jakékoli aplikace. Myslím že v článku bylo, že to je na analýzu datových toků v datovém skladě. Pro OLTP si to ani neumím moc představit, ale DWH jede celý dávkově, jednotlivé SQL příkazy pracují vždy s celou sadou dat a nikoli s jednoltivými klienty či dealy. S ad-hoc SQL příkazy se u DWH moc nepracuje kromě sandboxů (data labů), ale tam zase nepotřebujete dělat dopadové analýzy.
Pokud má DWH nějaké GUI, tak maximálně pro monitoring běhu jednotlivých ETL procesů.
Klíčová informace pro analytiky datového skladu je odkud kam v rámci DWH data tečou - když se na začátku stane změna/chyba, tak chci vědět kam se zpropaguje nebo naopak, když je mi podezřelá nějaká hodnota ve výsledném exportu/reportu, tak kde se pro ni posbíraly data. Neviděl jsem nikde takovou (dopřednou) dokumentaci datového skladu, která by umožnila rekurzivně takovéto analýzy provádět.
Samozřejmě záleží na tom, jak a v čem máte DWH implementován. Pokud jsou to z 99% databázové set-based SQL příkazy, obalené nějakým frameworkem jako (nejen) v mém případě, tak tento nástroj prostě má popsanou přidanou hodnotu. Pokud kompletní ETL mapping máte v SSIS nebo IBM DataStage nebo Informatice (upřímnou soustrast), tak pro výše popsanou analýzu použijete právě SSIS, IBM DataStage nebo nebo Informatiku. Pokud se jedná o kombinaci obou přístupů, tak SQLDep lze nakrmit i "simulacemi" resp. vygenerovanými SQL příkazy, akorát se v nich pak musí analytik vyznat.
Výhodu SQLDep vidím v agilním přístupu, že smysluplnou poptávku po nové funkcinoalitě analyzátoru kluci v Praze opravdu celkem flexibilně doplní, což se u kluků z IBM nebo Microsoftu spíš nestane.
Můžete to prosím upřesnit? Rád bych věděl, jaké vlastnosti DWH jsou natolik chybné, že by kvůli nim neměl být provozován.
Pokud máte na mysli implementaci formou ručně vytořených SQL příkazů mimo komerční ETL nástroj, tak to je nejen v ČR celkem rozšířený přístup, anebo minimálně se používá kombinace části logiky v ETL nástroji a částečně mimo něj. Také jsem viděl několik custom developed ETL nástrojů. Naopak u praktických nasazení ETL nástrojů se setkávám spíš s přístupem, kdy si zákazníci vyvíjejí robustní nadstavby a generátory mappingů nebo workflows do ETL nástroje. Máte tedy s některým komerčním ETL nástrojem tak dobré zkušenosti, že byste ho doporučil pro efektivní výhradní použití?
Pokud máte na mysli způsob dokumentace source-to-target mapování, též by mě velmi zajímal takový nástroj nebo metodika, která by 100% a efektivně pokryla všechny relevantní datové toky a uměla je trackovat (ideálně rovnou s propojením na cílový zdrojový kód), a zároveň by existoval proces, který by zajistil, že se dokument a realita nerozjede. Dost se touto tematikou teď zabývám a hledám optimální přístup. Ale ve využití klasických ETL nástrojů jsem ho zatím nenašel, tak třeba mě přesvědčíte.
Tak to není náš případ. Na dokumentaci máme celkem striktní metodiku jak co do formy, tak i do procesu (je i podrobena QA, slouží jako zadání pro vývojáře i testera) a bílých míst máme velmi málo - u našich dodávek používáme z 95% waterfall approach. Totéž pokud vím, platí i u několika dalších firem, kde se manta nebo sqldep používají.
Problém je, že naše forma dopředné dokumentace prostě neumožňuje automatizované trasování datových toků v rámci dopadových analýz - prostě technicky nejsou na úrovni metadat propojeny zdrojové sloupečky s cílovými - i když ze sémantiky srozumitelné člověku to jde. Ale i kdyby to šlo automaticky, tak velice rád použiju takovýto analyzátor pro rekonciliaci, že dokumentace odpovídá tomu, co je reálně naprogramováno - byla by to levná a relativně spolehlivá cesta (doplňujícího) testu a jen jeden z mnoha možných use cases takového nástroje.
Jinak v článku se píše, že takovýto nástroj je celkem ojedinělý, ale není to pravda - existuje řada komerčních nástrojů, které zapadají do konceptu metadata managementu, viz např. zde https://www.capgemini.com/insights-data/data/metadata-management
Akorát tyto nástroje postihují metadata management komplexněji, obsahují např. i business glossary (sql parsery jsou jejich klíčovou součástí, ale je tam i parsing dalších jazyků, s cílem právě vytvořit data lineage) a jsou podstatně dražší.
Zakladem kazdeho takoveho procesu je, ze by mel byt nekde zdokumentovan a nekdo jej urcite nekdy zadal. Cely ten nastroj na mne pusobi dojmem, ze se snazi hasit jiz dohorely pozar. Zkratka to, kdyz maji nekde ve vsem bordel, ten kdo dany proces vytvoril uz tam davno neni a ted se tezce snazi zpetne zjistit, co to vlastne presne dela.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).
