Vytvářejí vaše Qlik aplikace pořád syntetické klíče?

Syntetické klíče a cyklické reference jsou jen Qlik, který přesně asociuje to, co dostal. Vznikají, protože data přicházejí bez konformních dimenzí a skutečných klíčů, takže si je musí vymyslet každá aplikace.

Vytvářejí vaše Qlik aplikace pořád syntetické klíče?

Platforma pro automatizaci datových skladů, které důvěřují datové týmy napříč obory

Petr Beles Petr Beles Co-Founder · Publikováno v Řešení problémů s BI nástroji LinkedIn

Zní vám to povědomě?

  • Prohlížeč datového modelu je plný tabulek $Syn, které nikdo vytvořit nechtěl.
  • Reload varuje před cyklickou referencí a jedna tabulka skončí volně propojená.
  • Na začátku každého načítacího skriptu je blok přejmenování, příkazů QUALIFY a link tabulek.
  • Přidání jedné nové tabulky do aplikace rozbije asociace, které včera fungovaly.

Syntetický klíč je Qlik, který s tabulkami, jež dostal, dělá přesně to, co má. Když několik tabulek sdílí několik názvů polí, engine je musí nějak asociovat.

Co vám syntetické klíče říkají

  • Několik tabulek sdílí několik polí. Qlik pro každou kombinaci postaví tabulku $Syn a prohlížeč modelu se jimi zaplní.
  • Ke stejné tabulce vedou dvě cesty. To je cyklická reference a Qlik jednu tabulku volně propojí, aby smyčku přerušil.
  • Opravy jsou strukturální. Link tabulky, spojené tabulky faktů, QUALIFY, přejmenování pomocí AS, složené klíče postavené přes AutoNumber.
  • Každá oprava je lokální. Vyřeší tuto aplikaci a další aplikace nad stejnými zdroji začíná znovu.

Každý z nich je klíč, který měl existovat dřív, než data dorazila do Qliku.

Proč to dopadá na vás

  • Extrakty přišly s takovými názvy polí, jaké zrovna používal každý zdrojový systém.
  • Nikdo výše v řetězci nerozhodl, které CustomerID je ten zákazník, takže to musí rozhodnout načítací skript.
  • Pole v Qliku přejmenovat můžete. Dimenzi, ze které pochází, sjednotit nemůžete.

Práce se dělá na špatném místě

  • Rozhodnout, jak spolu tabulky souvisejí, je práce pro datový sklad. V Qliku se to dělá znovu v načítacím skriptu každé aplikace.
  • Patří na jedno centrální místo: do datového skladu nebo data hubu, který se postaví jednou a čte z něj každá aplikace.
  • Pokud to zní draze, odhad nejspíš počítá s tím, že se datové pipeline budou stavět ručně. Specializovaná automatizační platforma je generuje z modelu, a to mění náklady i čas, který to zabere.

Co se změní, když model přijde hotový

Datavault Builder generuje vault a dimenzionální vrstvu nativně v databázi, kterou už máte, ať je to Snowflake, Databricks, SQL Server, Fabric, Oracle nebo PostgreSQL.

  • Konformní dimenze znamenají jednu tabulku zákazníků a jeden zákaznický klíč, sdílený všemi fakty.
  • Surrogate klíče se joinují přes jediné pole, takže Qlik už nemá co syntetizovat.
  • Fakty s deklarovanou granularitou nahradí link tabulku, kterou jste udržovali ručně.
  • Z načítacího skriptu se stane obyčejný LOAD z hotových tabulek, bez bloku přejmenování na začátku.
  • Nová aplikace začíná z modelu, ne z kopie poslední opravy.

O co požádat

Ne “Qlik pořád vytváří syntetické klíče”, ale:

“Naše aplikace potřebují link tabulky a přejmenovaná pole, protože objednávky, faktury a zásilky nesou každá vlastní klíče pro zákazníka a pro datum. Může nám datový sklad dodat konformní dimenze se surrogate klíči, aby každá aplikace načítala stejné star schema?”

Pokud zazní, že sjednocení těchto dimenzí by zabralo čtvrtletí práce inženýrů, přesně tuto námitku Datavault Builder odstraňuje.

Podívejte se, jak to funguje na vašich vlastních datech

Rezervujte si bezplatné demo a přineste report, se kterým máte největší potíže.

Rezervovat bezplatné demo

Tři kroky k číslům, která sedí

  1. Vytáhněte stávající logiku

    Posbírejte výpočty, joiny a filtry, které dnes žijí ve vašich reportech.

  2. Centralizujte ji na jednom místě

    Logika se jednou přesune do modelu datového skladu, takže každý report čte stejnou definici.

  3. Čísla, která sedí

    Každý report ukazuje stejné číslo a “odkud se tohle číslo vzalo” má viditelnou odpověď.

Jak Datavault Builder předá vašemu reportu hotový model

  • Model přijde hotový

    Datavault Builder generuje vault a star schema tak, aby běžely nativně v databázi, kterou už máte: SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks nebo BigQuery.

  • Práce opustí report

    Žádný merge, žádné parsování, žádný fuzzy match. Tato práce z reportu zmizela.

  • Zdroje přicházejí integrované

    Zákazníci z ERP, CRM a e-shopu se spárují do jedné sady konformních dimenzí. Join proběhne jednou v datovém skladu, ne znovu v každém reportu.

  • Historie, na kterou se lze dotázat

    Každá změna se uchová tak, jak přijde, takže můžete reportovat stav tehdy i stav nyní, i tam, kde zdrojový systém přepisuje vlastní záznamy.

  • Každé číslo má lineage

    Logika získá lineage, takže otázka “odkud se tohle číslo vzalo” má viditelnou odpověď.

  • Změny řešené výše v řetězci

    Pomalu se měnící dimenze se řeší výše v řetězci jako vault satelity, místo aby se jen aproximovaly.

Oceněno společností BARC v The Data Fabric Survey 26

Seznamte se s naším expertem

Dvacet minut s naším obchodním ředitelem a upřímná odpověď, zda se to hodí do vaší situace.

Matt Collett

Matt Collett

Sales Director

Co hledáte?

Odesláním souhlasíte s našimi Zásadami ochrany osobních údajů.

Další problémy, které tato série řeší

  • Ukazují vaše Qlik aplikace a Power BI reporty různá čísla?

    Chybu nemá Qlik ani Power BI. Každý má vlastní logiku načítání, vlastní definice a vlastní lineage, takže se stejná metrika počítá dvakrát a nikdo je nedokáže sladit. Pravidla patří do jednoho spravovaného modelu v datovém skladu, ze kterého čtou oba nástroje.

  • Čistíte stejná data znovu v každém načítacím skriptu v Qliku?

    Stejné mapovací loady, opravy textových řetězců a deduplikace se znovu píšou v každé aplikaci a každé vrstvě QVD a jejich kopie se rozcházejí. Čištění se opakuje v každém skriptu, protože ho žádná integrovaná vrstva datového skladu neudělá jednou.

  • Jsou vaše výrazy Set Analysis v Qliku příliš dlouhé a pomalé?

    Set Analysis je přesný nástroj pro skutečná srovnání. Většina dlouhých výrazů ve vaší aplikaci tam je, protože model nikdy nedodal historii, příznaky ani jednu granularitu, takže je graf skládá znovu při každém výběru.