Převyšuje počet vašich balíčků SSIS počet lidí, kteří jim rozumí?

SSIS byl dvě desetiletí správnou odpovědí pro sklady na SQL Serveru a zralé prostředí to dokládá: stovky balíčků postavené mnoha rukama v průběhu mnoha let, z nichž každý se otevírá ve Visual Studiu samostatně. Balíčky stále běží. Problémem je jejich změna.

Proč se stávající prostředí těžko mění

• Jeden balíček na tabulku, každý postavený ručně. Stejný řídicí a datový tok sestavovaný znovu pro každý zdroj, ve stylu kohokoli, kdo daný úkol v daném týdnu řešil.
• Starší balíčky nesou vlastní konfiguraci. Projektové parametry a sdílení správci připojení existují od verze 2012; zděděné balíčky vytvořené předtím nebo bez nich stále drží připojovací řetězce a cesty uvnitř sebe.
• Změna schématu znamená okružní jízdu po balíčcích. Přidání sloupce do skladu znamená otevřít každý balíček, který se ho dotýká. Odhad je v týdnech, protože úprava se týká stovek datových toků.
• Širší sloupec znamená rozbitý datový tok. Metadata datového toku jsou typována a pevně určena v době návrhu, takže zdrojový sloupec, který se zvětší nebo změní typ, způsobí selhání komponenty, dokud jej někdo ve Visual Studiu znovu nepřemapuje.
• Nikdo přesně neví, co je v produkci živé. Balíčky jsou plánovány z SQL Agentu, z katalogu SSISDB i z jiných balíčků a nikdo nechce být tím, kdo omylem smaže ten nepravý.

Nic z toho není chybou SSIS jako takového. Balíček je dobrý způsob, jak postavit jedno nahrávání, ale špatný způsob, jak držet celý sklad.

Kam struktura patří

• Do modelu, nikoli do balíčků. Obchodní klíče, vztahy a atributy deklarované jednou, s nahráváními odvozenými z nich.
• Generovaná, aby každé nahrávání mělo jednotný tvar. Žádný individuální styl vývojáře, žádný balíček, kterému rozumí jen jeho autor.
• Na platformě, kterou již provozujete. SQL Server a Azure SQL jsou plnohodnotné cíle a Fabric je k dispozici, až nadejde čas na přesun.

Co se mění s Datavault Builderem

Datavault Builder drží datový sklad ve vizuálním modelu a generuje z něj stagingová, historizační i dodávková nahrávání, nativně pro SQL Server, Azure SQL i Fabric.

• Balíček pro každou tabulku odpadá. Huby, linky, satelity i jejich nahrávání se generují z modelu. Není nic, co by bylo třeba otevírat ve Visual Studiu.
• Změna sloupce je otázkou mapování. Namapujte jej, přegenerujte a každá závislá struktura se konzistentně aktualizuje. Chybějící sloupce se nahrávají jako null s varováním; rozšiřující se sloupce se rozšíří.
• Každé nahrávání má stejnou podobu. Píše je generátor, takže nedochází k odchylkám ve stylu a nevzniká žádný balíček, kterému rozumí jen jeho tvůrce.
• Model je zároveň inventářem. Co se nahrává, odkud, kam a s jakou návazností (lineage), je viditelné na jednom místě. Žádné pátrání v úlohách SQL Agentu.
• Nic nemusí opustit SQL Server. Vygenerovaný sklad běží tam, kde běžely balíčky, a přechod na Fabric je pouze změnou cíle, jakmile se pro něj rozhodnete.

Jak rozhodnout

Proveďte audit svého balíčkového prostředí a spočítejte balíčky, které existují pouze proto, aby načetly jednu tabulku ze zdroje do stagingu nebo do skladu. Tento počet odpovídá velikosti vrstvy, kterou by měl generovat model. Seřazený podle zdrojů vám tentýž seznam dá přesné pořadí, v jakém můžete balíčky postupně vyřazovat.