The default lakehouse syndrome (NL)

Heb jij dit ook wel eens gehad?

Je bent lekker bezig in een notebook in Fabric, je hebt al flink wat ontwikkeld, en ineens krijg je een error die je totaal niet begrijpt.

Bijvoorbeeld:

“The table or view lakehouse.`dim_date` cannot be found.”

Maar je weet het zeker: je hebt die tabel aangemaakt in je Lakehouse. Dus hoe kan dat dan?

Of je krijgt een waarschuwing zoals:

“Warning: In reference notebook run, the default lakehouse of the main notebook will be the effective default lakehouse of the session during reference run.”

En je vraagt je af: wat is er mis met het Lakehouse dat ik heb gekozen?

Nou, in beide gevallen is de oorzaak vaak hetzelfde. Je Lakehouse bestaat, en je tabel ook. Maar… ze bestaan waarschijnlijk in een Lakehouse dat zich in een totaal andere werkruimte bevindt.

Je bent dus ten prooi gevallen aan het Default Lakehouse Syndrome. Super frustrerend! Gelukkig zijn er manieren om dit te voorkomen. De meest eenvoudige is om je Lakehouse direct te configureren in je notebook:

%%configure -f

{

"defaultLakehouse": {

"name": "LakehouseNaam",

"id": "Lakehouse-ID",

"workspaceId": "Workspace-ID"

}

}

Dit heeft als voordeel dat je Lakehouse voor elke sessie direct goed wordt ingesteld.

Echter, deze configuratie moet altijd in de eerste cel van je notebook staan, anders werkt het niet correct. Daarnaast kun je geen variabelen gebruiken in de JSON, waardoor je de configuratie hardcoded moet invoeren. Dat maakt het minder flexibel en niet ideaal voor herbruikbare of dynamische notebooks.

Een alternatief is om het Lakehouse handmatig te configureren via de GUI. Dit is erg gebruiksvriendelijk en werkt bijzonder stabiel. Bovendien worden relatieve paden automatisch herkend, wat het werken in notebooks een stuk eenvoudiger maakt.

och voorkomt dit niet dat je altijd de juiste werkruimte gebruikt. Zelfs als de naam van je Lakehouse klopt, zie je niet direct uit welke werkruimte het komt. Dat ontdek je pas wanneer je met je muis over het Lakehouse hovert.

En dat kan problemen opleveren. Bijvoorbeeld bij een CI/CD-release van je notebook: je denkt dat alles goed staat, maar in je nieuwe omgeving blijkt het verkeerde Lakehouse gekoppeld te zijn. En voilà, je bent opnieuw slachtoffer van het Default Lakehouse Syndrome.

Gelukkig is Fabric continu in ontwikkeling, en inmiddels kunnen we dit ook aanpakken via notebookutils. Daarmee kun je het proces scripten en integreren in je CI/CD-pijplijn, zodat notebooks in elke omgeving automatisch naar het juiste Lakehouse verwijzen. Zo voorkom je mismatches en houd je je notebooks consistent en betrouwbaar.

Dat kan heel eenvoudig met onderstaande code, waarmee je per notebook in een workspace de volledige definitie kunt ophalen:

import sempy.fabric as fabric
import notebookutils
import json
workspace_id = fabric.get_notebook_workspace_id()
response = notebookutils.notebook.getDefinition(
    'NB_Semantic_Model',  # Use the display name of the notebook
    workspace_id  # Use the workspace GUID
)

Deze response is te groot om te delen, maar als je in demetadatainzoomt komt je vanuit dedependenciesbij delakehouseinformatie uit.

nb_json= json.loads(response)
lakehouse_info = nb_json["metadata"]["dependencies"]["lakehouse"]