Databricks: realtime modus voor Spark pipelines nu beschikbaar

Samenvatting

Databricks maakt Real-Time Mode voor Spark Declarative Pipelines algemeen beschikbaar, met verwerking in milliseconden voor operationele streaming.

Databricks Real-Time Mode voor Spark Declarative Pipelines

Databricks brengt Real-Time Mode (RTM) naar de algemeen beschikbare versie van Spark Declarative Pipelines (SDP). De modus verwerkt streamingdata continu, voert queryfasen gelijktijdig uit en geeft data door zodra die beschikbaar is. Daardoor haalt RTM end-to-end-latenties in het millisecondenbereik.

RTM schrijft resultaten via ForEach sinks direct naar operationele stores. Dat ondersteunt toepassingen zoals fraudedetectie, realtime-alertering, live personalisatie, aanbevelingssystemen en realtime featureberekening. In een benchmark op klantwerklasten was RTM tot 92 procent sneller dan Apache Flink.

SDP verzorgt daarnaast afhankelijkheden, incrementele verwerking, orkestratie, fout herstel en kwaliteitscontroles. Die functies blijven beschikbaar wanneer teams RTM gebruiken.

Waarom Databricks Real-Time Mode relevant is

Databricks positioneert SDP als de standaardmanier om streaming- en ETL-pipelines te bouwen. Met RTM vallen ook operationele workloads met lage latentie binnen hetzelfde framework. Teams hoeven daardoor volgens Databricks geen aparte gespecialiseerde engine zoals Apache Flink naast Spark te beheren.

De technische keuze verschuift daarmee van een combinatie van Spark voor batchverwerking en Flink voor lage latentie naar één pipelineframework. Dat raakt niet alleen de verwerking zelf. Eén framework betekent ook één observability-stack, één factureringsmodel en geen versnippering tussen verschillende API’s.

De benchmarkclaim vraagt wel om een technische vergelijking per workload. RTM was tot 92 procent sneller op specifieke klantwerklasten voor featureberekening; dat resultaat zegt niet automatisch hetzelfde over elke pipeline.

Concrete takeaway voor Databricks Real-Time Mode

Breng bestaande streamingpipelines in kaart en markeer waar milliseconde-latentie, directe writes naar operationele stores of een aparte Flink-engine nodig zijn. Test die workloads vervolgens met SDP en RTM, en vergelijk latency, foutafhandeling en operationele inrichting met de huidige architectuur.