Voordelen van Azure Synapse Analytics voor je eerste query en notebook

• Maak eerst een Synapse-workspace met gekoppelde Azure Data Lake Storage.
• Gebruik Serverless SQL Pool om snel bestanden in het lake te bevragen zonder een datawarehouse te provisionen.
• Start daarna een Spark-notebook wanneer transformaties, Delta Lake of grotere ETL-stappen nodig zijn.
• Beperk kosten en risico’s vanaf het begin met kolomselectie, Parquet of Delta, Managed Identity en gescheiden dev-, test- en productieomgevingen.

Azure Synapse Analytics is een geïntegreerd analyseplatform waarin datawarehousing, lake-query’s, Spark-verwerking en pipeline-orchestratie samenkomen in Synapse Studio. Voor beginners lost dat versnippering op, maar het roept ook keuzes op: dezelfde dataset kan vaak op meerdere manieren worden benaderd, met andere gevolgen voor prestaties, kosten en beheer.

Deze gids is geschreven voor data-analisten, BI-specialisten en startende data-engineers die snel iets werkends willen bouwen zonder meteen een volledig productieplatform te ontwerpen. De voorbeelden gebruiken de huidige Synapse Studio-ervaring in de Azure-portalcontext. Laatst bijgewerkt: 2026, met nadruk op correcte Synapse-termen, Serverless SQL Pool, Dedicated SQL Pool, Spark pools, Delta Lake en actuele leerpaden zoals DP-900 en DP-203.

Wat Azure Synapse Analytics oplost

Azure Synapse Analytics is een Microsoft Azure-service voor analytische workloads over datawarehouses en data lakes. Het platform laat gebruikers SQL-query’s uitvoeren, Spark-notebooks draaien, pipelines bouwen en data voorbereiden voor rapportering of machine learning.

De belangrijkste waarde zit in de combinatie van werkvormen. Een analist kan met SQL snel bestanden in een data lake verkennen, terwijl een data-engineer dezelfde bron kan opschonen met Spark en daarna beschikbaar maken voor Power BI, downstream dashboards of een relationeel warehouse. In praktijk werkt Synapse vooral goed wanneer organisaties al data in Azure Data Lake Storage plaatsen of van plan zijn hun analytische platform rond Azure te organiseren.

Synapse is geen vervanging voor goed datamodelleerwerk. CSV-bestanden zonder duidelijke datatypes, mappen zonder consistente structuur en pipelines zonder eigenaarschap blijven problemen veroorzaken, ongeacht het platform. Een verstandige start bestaat daarom uit een kleine, reproduceerbare proefopstelling: één storage-account, één workspace, één dataset, één query en één transformatie.

Serverless SQL, Dedicated SQL Pool of Spark kiezen

Beginners lopen vaak vast omdat Synapse meerdere compute-opties aanbiedt. De keuze is minder een kwestie van voorkeur dan van workload. Serverless SQL Pool is geschikt voor ad-hoc analyse en BI over bestanden in een data lake. Dedicated SQL Pool past beter bij voorspelbare MPP-datawarehousing met vaste performance-eisen. Spark is de logische optie voor zware transformaties, notebooks, machine learning-voorbereiding en werken met Delta Lake-tabellen op schaal.

Een praktische vuistregel helpt dure missers voorkomen. Ad-hoc BI over het lake begint meestal met Serverless SQL. Gestructureerde warehousing met serviceafspraken hoort eerder bij Dedicated SQL Pool. Zware ETL, data science-voorbereiding en Delta Lake-bewerkingen passen meestal bij Spark.

Een eerste Synapse-workspace opzetten

Een minimale start begint in de Azure-portal met een resourcegroep, een Synapse-workspace en een gekoppeld Azure Data Lake Storage Gen2-account. Bij het aanmaken kiest de gebruiker een regio, een workspace-naam, een storage-account en een standaardbestandssysteem. Voor Belgische en Europese organisaties verdient de regio extra aandacht, omdat dataresidentie, contractuele afspraken en toegangsbeleid niet achteraf als detail mogen worden behandeld.

Na het aanmaken opent Synapse Studio vanuit de workspace. Daar staan de belangrijkste onderdelen bij elkaar: Data voor gekoppelde bronnen, Develop voor SQL-scripts en notebooks, Integrate voor pipelines, Monitor voor runs en Manage voor pools, linked services en security-instellingen. Microsoft-documentatie beschrijft deze configuratiestappen in detail; gebruik die documentatie als bron van waarheid wanneer de portalweergave verandert.

Voor een veilige eerste opzet is het verstandig om geen persoonlijke sleutels of gedeelde geheimen in scripts te gebruiken. Managed Identity kan toegang geven tot storage zonder credentials in notebooks of SQL-scripts te plaatsen. In strengere omgevingen komen daar Managed Virtual Network, Private Endpoints en storage firewalls bij om publiek netwerkverkeer en data-exfiltratie te beperken. Dat garandeert geen GDPR-conformiteit, maar ondersteunt wel een verdedigbaar technisch ontwerp binnen EU- en Belgische governance-eisen.

Je eerste Serverless SQL-query

Serverless SQL Pool is standaard beschikbaar in Synapse en vereist geen vooraf ingerichte dedicated warehousecapaciteit. De pool leest bestanden rechtstreeks uit het data lake. Dat maakt de eerste query eenvoudig, maar het kostenmodel vraagt aandacht: elke query scant onderliggende bestanden, waardoor bestandsformaat, kolomselectie en mapstructuur belangrijk zijn.

Onderstaand voorbeeld toont het patroon voor een eerste verkennende query op Parquet-bestanden in een lake-map. De URL moet in een echte omgeving verwijzen naar het eigen storage-account en bestandssysteem. Gebruik Parquet of Delta waar mogelijk, omdat kolomgebaseerde formaten efficiënter zijn voor analytische queries dan ruwe CSV-bestanden.

Example — Serverless SQL-query over Parquet

SELECT TOP 100
    SalesOrderNumber,
    OrderDate,
    CustomerKey,
    SalesAmount
FROM OPENROWSET(
    BULK 'https://contosolake.dfs.core.windows.net/raw/sales/*.parquet',
    FORMAT = 'PARQUET'
) AS sales
WHERE OrderDate >= '2026-01-01';

Deze query leest alleen de gevraagde kolommen uit Parquet-bestanden en beperkt de rijen met een datumfilter. De belangrijkste les is dat queryontwerp direct invloed heeft op scanvolume. Een snelle SELECT * op een brede map lijkt onschuldig tijdens een test, maar wordt een kosten- en performanceprobleem wanneer de dataset groeit.

Een goede volgende stap is het maken van een view boven de bestanden. BI-rapporten hoeven dan niet telkens de onderliggende padstructuur te kennen. In veel teams wordt dit de eerste governance-laag: ruwe bestanden blijven in het lake, terwijl views duidelijke kolomnamen, datatypes en filters aanbieden aan rapportbouwers.

Een eenvoudige Spark-notebook bouwen

Spark komt in beeld wanneer data eerst moet worden opgeschoond, verrijkt of weggeschreven in een beter analytisch formaat. In Synapse Studio maakt de gebruiker een Spark pool aan, opent een notebook en kiest die pool als compute. Voor kleine tests volstaat een bescheiden configuratie; voor productie telt vooral dat clusterduur, bestandsgrootte en partitionering bewust worden beheerd.

Onderstaand PySpark-voorbeeld leest ruwe verkoopdata, filtert ongeldige records en schrijft de output als Delta Lake. Delta Lake helpt bij schema-evolutie, transacties en time travel, maar lost slecht bestandsbeheer niet automatisch op. Te veel kleine bestanden blijven een bekend knelpunt; compaction en een doordachte partitioneringsstrategie horen daarom bij het ontwerp.

Example — PySpark-transformatie naar Delta

from pyspark.sql.functions import col, to_date

source_path = "abfss://raw@contosolake.dfs.core.windows.net/sales/"
target_path = "abfss://curated@contosolake.dfs.core.windows.net/sales_delta/"

sales = spark.read.option("header", "true").csv(source_path)

clean_sales = (
    sales
    .withColumn("OrderDate", to_date(col("OrderDate"), "yyyy-MM-dd"))
    .withColumn("SalesAmount", col("SalesAmount").cast("decimal(18,2)"))
    .filter(col("SalesAmount") > 0)
)

clean_sales.write.format("delta").mode("overwrite").save(target_path)

Het notebook zet een ruwe CSV-zone om naar een gecureerde Delta-zone met explicietere datatypes. Controleer daarna in Synapse Studio of de bestanden correct zijn geschreven en of downstream SQL- of Spark-jobs hetzelfde pad kunnen lezen. In een echte omgeving hoort deze stap in een pipeline met logging, foutafhandeling en scheiding tussen ontwikkel-, test- en productiegegevens.

Kosten, prestaties en veelvoorkomende beginnersfouten

De meeste vroege Synapse-problemen ontstaan niet door het ontbreken van geavanceerde kennis, maar door kleine ontwerpkeuzes die op schaal duur worden. Serverless SQL scant per query data uit storage. CSV’s zonder schema dwingen extra interpretatie af. Spark-jobs verliezen tijd aan duizenden kleine bestanden. Dedicated SQL Pool vraagt aandacht voor distributie, laden en pauzeren van compute.

Een praktische aanpak is om vanaf de eerste proef drie gewoontes in te bouwen. Schrijf analytische datasets bij voorkeur naar Parquet of Delta. Projecteer alleen kolommen die nodig zijn in SQL-queries. Houd ruwe, opgeschoonde en gepubliceerde datazones gescheiden, zodat gebruikers niet rechtstreeks rapporteren op onstabiele bronbestanden.

Ook operationeel beheer hoort vroeg op tafel. Dev, test en productie in één workspace lijken eenvoudiger, maar verhogen het risico op onbedoelde wijzigingen en onduidelijke kosten. Teams die Synapse serieus gebruiken, automatiseren workspace-artifacten met ARM, Bicep of Terraform en gebruiken CI/CD voor notebooks, SQL-scripts en pipelines. Dat voelt misschien zwaar voor een eerste test, maar het voorkomt dat een succesvolle proof of concept later handmatig moet worden herbouwd.

Security en governance in een Belgische en EU-context

Synapse-projecten verwerken vaak klant-, financiële of operationele data. Daarom moeten toegang, netwerkpad en datalocatie vanaf het begin worden ontworpen. Role-based access control in Azure, Synapse-rollen en rechten op Azure Data Lake Storage moeten samen worden bekeken; een gebruiker kan in Synapse Studio zichtbaar toegang lijken te hebben, maar alsnog falen op storage-permissies.

Managed Identity is meestal de voorkeursroute voor service-to-service toegang. Private Endpoints en Managed Virtual Network beperken blootstelling aan publieke netwerken. Storage firewalls kunnen afdwingen welke workloads data mogen bereiken. In combinatie met logging en monitoring ontstaat een beter controleerbare omgeving voor audits en interne governance.

Deze maatregelen zijn technische bouwstenen, geen juridisch advies. GDPR- en contractuele verplichtingen hangen ook af van verwerkingsdoelen, bewaartermijnen, rollen van verwerkers en organisatiebeleid. Vanuit data-engineeringperspectief is het vooral belangrijk dat de gekozen regio, toegangsmodellen en netwerkgrenzen aantoonbaar aansluiten bij de afspraken van de organisatie.

Welke voorkennis en certificeringen passen hierbij?

Voor een eerste Synapse-project is basiskennis van SQL, data lakes en Azure-identiteit belangrijker dan een lange lijst certificeringen. Wie helemaal nieuw is in Azure-dataworkloads kan beginnen met Microsoft Azure Data Fundamentals, vaak gekoppeld aan DP-900. Dat helpt om begrippen zoals relationele data, analytische workloads en Azure-datadiensten op hun plaats te zetten; de Microsoft Azure Data Fundamentals (DP-900) – training biedt daarvoor een gestructureerd startpunt.

Voor wie verder wil richting pipelines, Spark, lakehouse-ontwerp en productiegerichte data-engineering sluit DP-203 beter aan. De Data Engineering on Microsoft Azure (DP-203) – training past bij professionals die Synapse, Azure Data Lake Storage, Databricks-achtige patronen, pipelines en transformaties in samenhang willen begrijpen. Niet-standaard examencodes horen hier niet thuis; DP-900 en DP-203 zijn de relevante Microsoft-leerpaden voor respectievelijk fundamenten en data engineering.

Van eerste query naar bruikbaar dataplatform

Een geslaagde eerste Synapse-ervaring eindigt niet bij een query die resultaat geeft. De waarde ontstaat wanneer data betrouwbaar vindbaar, herhaalbaar verwerkbaar en veilig bruikbaar wordt voor analyse. Dat vraagt om duidelijke zones in het lake, consistente naamgeving, logging van pipeline-runs en afspraken over wie data mag publiceren naar BI of downstream systemen.

Readynez kan in dit leerpad een rol spelen wanneer teams gestructureerd willen oefenen met Azure-datafundamenten of data-engineeringtaken, maar de technische basis blijft dezelfde: klein beginnen, de juiste compute-optie kiezen en ontwerpkeuzes documenteren voordat datasets groeien. Wie vragen heeft over een passend vervolg kan ook contact opnemen.

De belangrijkste stap is om Synapse niet als één grote knop voor analyse te behandelen. Serverless SQL, Dedicated SQL Pool en Spark lossen verschillende problemen op. Wie dat onderscheid vroeg maakt, voorkomt onnodige scans, overgedimensioneerde compute en data die wel beschikbaar is, maar moeilijk te beheren blijft.

Opmerking bij bestaande trainingsverwijzingen: de oorspronkelijke pagina bevatte ook een verwijzing naar een Microsoft 365 Copilot-cursus. Die link is hier bewaard voor URL-continuïteit, maar inhoudelijk is DP-900 of DP-203 relevanter voor Azure Synapse Analytics.

FAQ

Wat is Azure Synapse Analytics?

Azure Synapse Analytics is een Azure-service voor analytische workloads over data lakes en datawarehouses. Gebruikers kunnen er SQL-query’s, Spark-notebooks, pipelines en integraties mee bouwen voor rapportering, data-engineering en geavanceerde analyse.

Is Serverless SQL Pool gratis?

Nee. Serverless SQL Pool vereist geen vooraf ingerichte dedicated compute, maar queries brengen kosten met zich mee op basis van het datavolume dat wordt verwerkt. Kolomselectie, Parquet of Delta en gerichte mapstructuren helpen om onnodige scans te beperken.

Wanneer gebruik je Spark in plaats van SQL?

Spark is geschikt wanneer data op schaal moet worden getransformeerd, verrijkt of voorbereid in notebooks of jobs. SQL is vaak sneller en eenvoudiger voor ad-hoc analyse, views en BI-query’s boven gestructureerde bestanden of warehouse-tabellen.

Moet een beginner starten met Dedicated SQL Pool?

Meestal niet. Voor verkenning en eerste BI-scenario’s is Serverless SQL Pool vaak eenvoudiger. Dedicated SQL Pool wordt interessanter wanneer er een voorspelbaar warehouse nodig is met duidelijke performance-eisen, laadroutines en beheer van geprovisioneerde capaciteit.

Welke certificering past bij Azure Synapse Analytics?

DP-900 past bij beginners die Azure-datafundamenten willen begrijpen. DP-203 past bij data-engineers die pipelines, storage, transformaties en analytische oplossingen op Azure willen ontwerpen en bouwen.