Snowflake Openflow: Et teknisk overblik

Estimated reading time: 6 minutes

Snowflake Openflow blev afsløret på Snowflake Summit i San Francisco den 3. juni 2025. Det er positioneret som en åben, udvidelig og sikker dataintegrationsplatform. Den er designet til realtids-, skalerbar og tovejs databevægelse. Platformen understøtter både strukturerede og ustrukturerede data samt streaming og batch-behandling. Den sigter mod at være en universel tjeneste, der forbinder enhver kilde med enhver destination.

Openflow er baseret på den velansete open source-løsning Apache NiFi, som oprindeligt blev udviklet af NSA, og arver NiFi’s styrker i håndteringen af forskellige datatyper og dens grundlæggende principper om observerbarhed og sikkerhed. Snowflake bidrager til open source NiFi-fællesskabet og har til hensigt at levere fremtidige forbedringer til rammen. Openflow bygger på NiFi, forbedrer dets muligheder og præsenterer det som en ren cloud-native-løsning med en forenklet implementerings- og administrationsoplevelse gennem Snowflake-grænsefladen, Snowsight.

Arkitektur

Openflow-arkitekturen er designet omkring to vigtige hovedkomponenter:

Kontrolplan: Denne komponent er ansvarlig for at kontrollere implementeringen, overvåge aktiviteter og give indsigt i datastrømme. Den indeholder også Connector Catalog, der giver brugerne mulighed for at gennemse tilgængelige connectorer, og inkluderer observationslag for at forstå dataflowets ydeevne. Control Plane er implementeret i Snowflake, og dens brugergrænseflade er integreret i Snowsight-brugergrænsefladen.

Implementering: Det er her, den faktiske databehandling og -bevægelse finder sted. Den kan implementeres enten i kundens Virtual Private Cloud (VPC) eller som en containeriseret tjeneste i Snowflake-infrastrukturen ved hjælp af SnowPark Container Service (SPCS). Når den implementeres i kundens VPC, sker dataadgangen bag deres firewalls. Implementeringen er vært for runtime, hvor connectorer henter data fra kilder.

Denne arkitektur på højt niveau har til formål at forenkle implementeringen og konfigurationen af NiFi ved at udnytte Snowflakes brugervenlighed. Traditionelt kræver opsætning af et kraftfuldt system som NiFi betydelig ekspertise og indsats.

Implementeringsmuligheder og fremtidsplaner

Ved lanceringen understøtter Openflow hybride implementeringer med både Snowflake-hosting og BYOC-muligheder (Bring Your Own Cloud). Der er også planer om eventuel lokal understøttelse. Containerisering leveres naturligt som en administreret tjeneste. Dette giver mulighed for implementering i enten kundens egen VPC eller i en Snowflake Container Service.

Med hensyn til regional og cloud-support ved lanceringen kræver Snowflake Control Plane en Snowflake-konto i en af de globale AWS kommercielle regioner (dvs. Canada (Central), Sydamerika (Sao Paulo), US West (Oregon), EU (Frankfurt) osv.) Flere AWS-regioner, Azure-support og Google Cloud Platform (GCP)-support forventes henholdsvis snart og senere på året.

Openflow Deployment kan dog køres i enhver AWS-region ved lanceringen. Målet er at muliggøre administration af Openflow-infrastruktur på tværs af alle regioner fra en enkelt administrationsrude i Snowflake Snowsight.

Tekniske krav til implementering

Forudsætninger for Snowflake-konto:

• En eksisterende Snowflake-implementering er påkrævet.
• Der skal oprettes en ekstra Snowflake-konto i en af de understøttede kommercielle AWS-regioner til Control Plane. Opsætning af en ekstra konto medfører ikke i sig selv ekstra omkostninger; omkostningerne er forbundet med brug af computere.
• Brugeren, der opsætter Openflow, skal have ORGADMIN-rettigheder (til at acceptere vilkår og betingelser) og ACCOUNTADMIN-rettigheder (til grundlæggende Snowflake-opsætning).
• Opsætning af Openflow indebærer, at der defineres nye rettigheder på Snowflake-kontoniveau, som som standard er tildelt ACCOUNTADMIN-rollen. Disse omfatter CREATE Deployment INTEGRATION til at oprette og slette Deployment-integrationsobjekter og CREATE RUNTIME INTEGRATION (sammen med OWNERSHIP på det overordnede Deployment-integrationsobjekt) til at oprette runtime-integrationsobjekter. Yderligere rettigheder som OWNERSHIP og USAGE kan tildeles til Deployment-integrations- og runtime-objekter for detaljeret adgangskontrol.

Forudsætninger for AWS-konto (til implementering i kundens VPC):

• En AWS-konto i en hvilken som helst region er påkrævet for at implementere implementeringskomponenterne.
• Adgang til AWS CloudFormation, EC2 og ECS er nødvendig med tilladelser til at oprette og administrere VPC’er og opsætte infrastruktur.
• Openflow-agenten letter kommunikationen og administrationen mellem Snowflake og AWS-infrastrukturen. Den er som standard installeret på en t3.medium EC2-instans (2 vCPU’er, 4 GB RAM).

Generel implementeringsproces

Implementeringen af Openflow styres af en guide i Snowflake Snowsight UI. Brugere kan få adgang til Openflow-sektionen under Data-sektionen i Snowsight.

Processen begynder med at oprette en udrulning. Guiden guider brugeren gennem trin som f.eks. at kontrollere forudsætninger, angive udrulningsplaceringen (oprindeligt AWS, med Azure og GCP på køreplanen) og navngive udrulningen.

Et vigtigt trin er at vælge udrulningsmulighed for udrulningen. Brugere kan vælge en administreret VPC-mulighed, hvor en Snowflake-agent opretter og administrerer VPC’en (den enkleste mulighed), eller Bring Your Own VPC-muligheden for mere kontrol og tilpasset konfiguration.

Resultatet af denne guidedrevne proces er en CloudFormation-skabelon (en YAML-fil). Denne skabelon kan downloades og gives til en AWS-administrator for at automatisere opsætningen af den nødvendige AWS-infrastruktur, herunder VPC’er, subnet og Openflow-agenten på en EC2-instans. Openflow-agenten henter derefter billeder, der indeholder forskellige versioner af Openflow og connectorer, fra Snowflake Image Repository. Det forenkler både softwarestyring og opgraderinger.

Når implementeringen er klar, og agenten kører, vender brugerne tilbage til Snowflake Control Plane i Snowsight for at styre tingene via brugergrænsefladen. Herfra kan de oprette runtimes, som repræsenterer klynger af Openflow runtime-servere til udførelse af flowdefinitioner. For Kubernetes-baserede implementeringer repræsenterer runtimes et statsligt sæt af Openflow Runtime-containere og understøttende komponenter, der er implementeret i et navneområde.

Runtime-konfigurationen omfatter valg af nodetyper (små, mellemstore, store) med varierende CPU- og hukommelsesressourcer og definition af skalerbarhedsindstillinger med minimums- og maksimumsnodeområder (op til 50 noder) for at håndtere varierende datamængder. Guiden og den automatiserede opsætningsproces har til formål at reducere den tid og ekspertise, der traditionelt kræves for at implementere og konfigurere kompleks dataintegrationsinfrastruktur.

Find ud af, hvordan OpenFlow kan hjælpe dig med at frigøre det fulde potentiale i dine data med Snowflake i vores artikel om frigørelse af datahastighed.

Hvorfor er Devoteam så begejstret for Snowflake Openflow?

En stor del af min professionelle karriere har jeg tilbragt som dataingeniør, og jeg har brugt en lang række integrationsværktøjer. Men de sidste tre år har jeg beskæftiget mig med Snowflakes AI Data Platform. Selv om jeg straks blev imponeret over dens brugervenlighed, styrke og løbende nye funktioner, har denne sætning altid strejfet mig: »Den behøver kun sit eget integrationsværktøj for at være perfekt«. Det er stadig for tidligt at sige, om det er perfekt, men for mig føles det meget tæt på. Og det er Open Source, så jeg kan ikke vente med at se, hvordan fællesskabet begynder at udvikle sine egne connectorer.

For flere detaljer om partnerskabet bag OpenFlow, læs vores nyhedsmeddelelse om Devoteams samarbejde med Snowflake.

Udforsk yderligere, hvordan dette tekniske fundament gør det muligt for Snowflake OpenFlow at fungere som en kraftfuld, AI- og agentic-klar dataplatform.