Gå till innehållet

Funktioner

Designern

  • SVG-designyta — dra tabeller till ytan, dra pilar från källkolumner till målkolumner.
  • Flera källtabeller → en: lägg till flera SQL-tabeller och dra en linje mellan nyckelkolumner för JOIN (INNER/LEFT). Verktyget genererar SELECT-frågan.
  • Transformationer per kolumn: Trim, UpperCase, LowerCase, EmptyToNull.
  • Draft-mål: skapa en ny måltabell direkt på ytan — dra källkolumner till målsidan så byggs schemat upp, skapa sedan tabellen i databasen med ett klick.
  • C#- och Python-skript i transformationssteget (efter mappningar, innan laddning).
  • Post-load-SQL körs på målservern efter laddningen (UPDATE, MERGE, EXEC …).
  • Variabler / parametrisering — deklarera {{namn}}-variabler och referera dem i extract-SQL, post-load-SQL, måltabellnamn eller en request-body, så att en pipeline blir konfigurationsstyrd i stället för hårdkodad. Inbyggda makron {{run_date}}, {{run_timestamp}} och {{watermark}} finns alltid; {{watermark}} motsvarar senaste lyckade high-watermark-värdet, vilket är så en inkrementell extract filtrerar på det (WHERE ModifiedDate > '{{watermark}}'). En odeklarerad referens avbryter körningen innan någon I/O.
  • Metadatadriven generering — använd en mall-pipeline (en med {{variabler}}) som stencil och skapa en pipeline per rad i en bindningsmängd: klistra in rader, eller peka på en kontrolltabell (SELECT table_name AS table, schema_name AS schema FROM etl_config WHERE enabled = 1) där varje rads kolumner blir variabelvärdena. Förhandsgranska, generera sedan; kopiorna grupperas ihop i Arbetsflödesvyn. Bygg en laddning, kör den för femtio tabeller.

Körning och observabilitet

  • Realtidsstatus via SignalR — progress per steg utan polling.
  • Tidtagning per steg (Extract, Transform, Script, Load, Post-load SQL).
  • Felhantering — skipBadRows: provladdning med SqlBulkCopy, fallback rad-för-rad vid fel utan att stoppa körningen.
  • Karantän (dead-letter) — med quarantineBadRows skrivs varje rad som skipBadRows hoppar över (tillsammans med laddningsfelet, en UTC-tidsstämpel och pipeline-etiketten) till en karantäntabell som skapas vid körning första gången och behålls mellan körningar, så att inget tappas tyst. Standardnamn är <mål>_Quarantine; ändra med quarantineTable.
  • Datakvalitetsregler (expectations) — regler per kolumn (NotNull, NotBlank, Regex, Range, InSet, MaxLength) som kontrolleras mot målets mappade rader innan de laddas. En bruten Fail-regel avbryter körningen innan den felaktiga chunken laddas (en icke-strömmande laddning rullas då tillbaka helt); Warn-regler räknar bara överträdelserna på körningen och i notiser.
  • Transaktion runt DELETE/bulk load med TRUNCATE-fallback.

Arbetsflöden och schemaläggning

  • Arbetsflödesvyn listar alla sparade pipelines med cron-schema och enable-toggle.
  • Schemaläggaren (Quartz.NET) körs i servern — pipelines körs även utan öppen webbläsare.
  • Körhistorik med per-steg-detaljer i Runs-vyn.

Data Vault-automation

Data Vault-vyn är en visuell modellerare: dra in flera källtabeller på en yta och designa hela valvet på en gång.

  1. Anslut och dra in tabeller — dubbelklicka på källtabeller för att lägga dem på ytan. Varje kolumn klassas automatiskt som business key (primärnyckel) eller deskriptor; klicka på rollrutan (BK/D/—) för att ändra.
  2. Dra relationer — dra från en kolumn till en annan tabell för att skapa en länk; verktyget föreslår även länkar automatiskt utifrån lika nyckelnamn. Varje relation blir en Lnk_ mellan de två hubbarna.
  3. Generera — för varje tabell bygger verktyget:
    • stg_<Entitet> — en stage-tabell med källkolumnerna plus persisted computed hash-kolumner (hash-nyckel, hash-diff, länk-hashar) och LoadDate/RecordSource
    • Hub_<Entitet> med hash-nyckel, business key(s), LoadDate, RecordSource
    • Sat_<Entitet> med HashDiff för CDC av deskriptorerna
    • Lnk_<Entitet>_<Ref> för varje ritad relation
    • en stage-laddning (källa → stage) plus en körbar Hodor-pipeline per vault-tabell
  4. Tillämpa — skapar scheman och tabeller och sparar pipelines som dyker upp i Workflows-vyn (grupperade per entitet), redo att köras eller schemaläggas.

Hashningen sker i stage-lagret (DV 2.0 "hash in stage"). Eftersom hub-, sat- och link-laddningarna läser från stage-tabellen är de insert-only, idempotenta och oberoende av varandra och av laddningsordning — de kan köras när som helst och parallellt. Endast stage och vault behöver dela databas; källan kan ligga var som helst (en lake, CSV, REST-API, en annan server), eftersom bara stage-laddningen rör källan.