Marie heeft het notitieboekje dat “thuis werkt”. Thomas opent het: de kernel crasht - onvoldoende geheugen, andere pandaversie, hardgecodeerd pad /Users/marie/.... De CTO ontdekt een klantexport in een openbare Git-repository. Jupyter verzendt als team geen .ipynb-bestand via Slack: het is een platform met identiteit, bronnen en bestuur.
Een lokale notebook met 32 GB RAM is geen teaminfrastructuur. Zodra drie mensen data, GPU’s of gereguleerde omgevingen delen, moet de authenticatie gecentraliseerd worden, bronnen geïsoleerd en de toegang getraceerd worden. Bij onjuiste inzet wordt JupyterHub een VPS waar iedereen dezelfde rechten heeft. Als het goed wordt ingezet, vormt het de brug tussen exploratie- en productiepijplijnen.
Minimaal haalbare architectuur
Een teamopstelling is afhankelijk van een aantal niet-onderhandelbare componenten:
| Onderdeel | Rol |
|---|---|
| JupyterHub | SSO/LDAP-verbinding, lancering van een notebook per gebruiker |
| Spawner | Docker of Kubernetes — reproduceerbare afbeelding |
| Persistente opslag | Ruimte per gebruiker of per project, niet alleen een kortstondige schijf |
| Geheimen | Veilige of geïnjecteerde omgevingsvariabelen – nooit API-sleutels in de notebook |
| Bronnenquotum | Maximale CPU, RAM, GPU per gebruiker of groep |
De hosting varieert afhankelijk van de belasting: solide VPS voor CPU-verkenning, GPU-machine voor training (zie GPU-verhuur), of Kubernetes als het team de orkestratie al onder de knie heeft. Vergelijk aanbiedingen met GPU-toegang en EU-regio's via de overzicht en de vergelijker.
Delen zonder datalekken
Versie de notebooks in Git, maar strip de uitvoer vóór elke commit (nbstripout of hook pre-commit). Een geëxporteerd notitieboekje met klantgegevens in platte tekst in een cel is een AVG-lek dat nog moet gebeuren.
Beperk de toegang tot gegevens: alleen-lezen rollen in productiedatabases, geanonimiseerde weergaven, geen volledige dump “om te testen”. Schakel bulkdownload uit als de gegevens gevoelig zijn; log exports met tijdstempel en gebruikersidentiteit.
Snijd inactieve kernen ("idle culler") om GPU en RAM vrij te maken - een vergeten notebook die sinds vrijdag open is, mag de wachtrij van het team niet blokkeren.
Voor interne LLM's mag u vertrouwelijke aanwijzingen en gedeelde notitieblokken niet door elkaar gebruiken — zie hosting an LLM.
Veelvoorkomende fouten die schaduw-IT versnellen
Vier patronen komen in bijna elke autopsie terug:
- Eén gedeeld SSH-account — hetzelfde probleem als SFTP-teamtoegang: niemand is verantwoordelijk, iedereen is root.
- Notebook = productie — een cron die 's nachts een niet-geteste
.ipynbuitvoert, vervangt een niet-waarneembare pijplijn. - GPU 24 uur per dag voor panda-verkenning waarbij alleen de CPU wordt gebruikt.
- Geen back-up van de gebruikersmap naar één lokale schijf.
Elk van deze fouten kan worden gecorrigeerd zonder Jupyter te verbieden – door dezelfde vereisten toe te passen als voor een API: identiteit, logs, limieten.
GPU, quota's en gecontroleerde kosten
Zelden heb je per datawetenschapper een GPU nodig. JupyterHub plant taken, past quota's toe per groep en geeft de bron vrij na inactiviteit. Reserveer dure GPU-instances voor zware training; Datamining (EDA) werkt vaak erg goed op de CPU.
Voor intensieve training kunt u ter plaatse of op aanvraag de Hub voltooien zonder apparatuur 24 uur per dag te immobiliseren. Documenteer wie een GPU-taak kan starten, voor hoe lang, en hoe u kunt waarschuwen als de wachtrij een drempel overschrijdt.
De top: gedeelde Jupyter zonder governance = versnelde schaduw-IT
Dit is wat het enthousiasme voor notebooks vergeet te formaliseren.
Vergelijk hosts met GPU-toegang en hosting in de EU-regio in de overzicht voordat u hardware “voor Jupyter” aanschaft.
Beslis en ga vooruit zonder blinde vlek
Voordat u een GPU aanschaft of een hub implementeert:
- Tel hoeveel notebooks tegelijkertijd moeten draaien, op welke gegevens, met welke traceerbaarheid.
- Kies JupyterHub + Docker zodra drie reguliere datagebruikers bronnen of gereguleerde data delen.
- Repareer een vergrendelde basisimage en Git-beleid (uitvoer verwijderd vóór commit).
- Configureer CPU/RAM/GPU-quota en automatisch afsluiten van inactieve kernels.
- Controleer gegevenstoegang zoals bij elk gevoelig systeem: logbestanden, rollen, EU-regio.
- Test bij het herstellen van permanente gebruikersopslag voordat kritieke datasets worden vastgelegd.
Zonder een duidelijk antwoord op de eerste vraag financier je chaos – en niet de wetenschap.
Veelgestelde vragen
Lokaal JupyterLab of gehoste JupyterHub?
Ruimte voor solo-verkenning. Gehoste hub zodra meerdere mensen GPU, gereguleerde gegevens of behoefte aan traceerbaarheid delen. Anders kopieert iedereen CSV's per e-mail en lopen de versies binnen een week uiteen.
Hoe voorkom ik dat een notebook de productie overschrijft?
Afzonderlijke omgevingen (staginggegevens), standaard alleen-lezen databasetoegang, niet-notebookgeheimen (veilig, omgevingsvariabelen), verplichte beoordeling vóór elke geplande taak in cron.
Heeft u per datawetenschapper een GPU nodig?
Zelden. Hubplanning, GPU-quota, spotinstances voor zware training: de CPU is voldoende voor het merendeel van de datamining. Zie onze gids GPU-verhuur.
Notebooks en AVG: welke voorzorgsmaatregelen?
Geen duidelijke persoonlijke gegevens in geëxporteerde cellen, toegangslogboeken, hosting in de EU-regio, opschonen van per ongeluk vastgelegde uitvoer in Git. Behandel een notitieboekje als een gevoelig document en niet als een wegwerpconcept.
Voordat u een GPU “voor Jupyter” koopt, vraagt u zich af: hoeveel notebooks moeten tegelijkertijd draaien, op welke gegevens, met welk spoor? Zonder antwoord financiert u chaos – en niet de wetenschap.