Onelake Storage Report

Tento problém je v Microsoft Fabric Warehouse velmi dobře známý – jde o důsledek architektury transakčního enginu DW a způsobu, jakým Fabric ukládá intermediate (dočasné) a transakční artefakty.Proč složka /Files narostla na 800 GB?Fabric Synapse Data Warehouse nepoužívá Apache Spark pro zápis, ale vlastní distribuovaný SQL engine. Na rozdíl od Lakehouse, kde data žijí čistě v Delta formátu pod /Tables, Warehouse ukládá transakční a staging struktury do /Files:KomponentaCo se děje pod kapotouSQL Staging & SpillingSložité uložené procedury, vícenásobné UPDATE, MERGE a dočasné tabulky odkládají mezivýsledky do OneLake /Files namísto lokálního SSD uzlu.Delta Write StagingTransakční zápisy připravují Parquet soubory nejprve do interních staging složek v /Files, než jsou commitnuty a zalogovány do Delta logu pod /Tables.Orphaned / Stale filesPokud selže transakce, engine spadne nebo běží stovky inkrementálních DML operací, generují se gigabajty dat, které automatický engine cleaner často neodstraní včas.time_travel_retention_cutoff_date (a příkaz VACUUM) operuje výhradně nad Delta logy pod složkou /Tables. Na interní storage engine pod /Files nemá vůbec žádný vliv.1. Existuje způsob, jak toto nastavení změnit?Ne na úrovni uživatelského nastavení retenční politiky.Microsoft zatím neposkytuje pro Fabric Warehouse přímé T-SQL konfigurační tlačítko ani systémovou proceduru pro nastavení retence složky /Files.Kritické varování: Nikdy nemažte soubory v /Files ručně přes OneLake File Explorer, Azure Storage Explorer ani přes REST API. Tato složka obsahuje aktivní metadata, transakční checkpointy a systémové katalogy skladu. Smazáním souborů s vysokou pravděpodobností nenávratně poškodíte metadata skladu (Warehouse corruption).Jediná přímá oprava pro okamžité uvolnění místa:Vytvořit nový Warehouse (nebo Lakehouse).Překopírovat čistá data (CTAS – CREATE TABLE AS SELECT).Původní Warehouse smazat. (Tím se okamžitě uvolní celých 800 GB).2. Jak radikálně snížit objem a počet zapisovaných souborů?Problém téměř jistě nepůsobí objem dat (1,9 milionu řádků je v analytickém světě zanedbatelné množství, mělo by mít desítky až stovky megabajtů), ale způsob provádění aktualizací.Eliminujte časté a řádkové UPDATE / MERGEDelta Lake a Fabric nepodporují in-place přepisování. Každý UPDATE znamená přečtení celého Parquet souboru, zápis nové verze s modifikovanými řádky a vytvoření nového stavu.Pokud procedura dělá aktualizace v cyklu, po malých dávkách nebo opakovaně v několika krocích za sebou, generuje desítky tisíc mikro-souborů a stovek gigabajtů odpadu.Přepište proceduru na staging vzor (Partition/Batch Overwrite)Namísto sekvence UPDATE tabulka SET ... WHERE ... připravte finální sadu dat do dočasné podoby a proveďte atomický přepis:SQL-- Vzor: Minimalizace transakčního churnu

CREATE TABLE dbo.Target_New AS

SELECT ... FROM dbo.Source JOIN ...;

-- Následná výměna tabulek / partition overwrite

Zvažte Lakehouse místo Warehouse pro ETL transformacePokud jsou transformace procedurální a náročné na zápisy, Fabric Lakehouse (pomocí PySpark / Spark SQL) nabízí plnou kontrolu nad údržbou:Přímý přístup k příkazům OPTIMIZE (compaction malých souborů).Přímý přístup k VACUUM tabulka RETAIN 0 HOURS (s potlačením safety checku).