Programmering

Forståelse af Microsofts grafdatabasestrategi

Det har taget noget tid, men Microsofts 26 milliarder dollars køb af LinkedIn begynder endelig at vise nogle interessante resultater, hvor LinkedIn-data begynder at dukke op i værktøjer som Outlook. Det er det første tegn på, at Microsoft bruger det sociale netværks forholdsgraf, det komplekse datasæt, der var årsagen til en af ​​Microsofts største Silicon Valley-opkøb.

Under hætten er et socialt netværk som LinkedIn intet andet end en enorm NoSQL-grafdatabase, der bruger en skemafri tilgang til styring af semistrukturerede data. Hver knude i grafen er et individ med alle hans eller hendes profildata. Hver knude er knyttet til andre, tiere eller hundreder for mennesker med et par forbindelser, tusinder for stærkt forbundne personer. Forespørgsler krydser disse forbindelser, så du kan finde alle de mennesker, du kender, der arbejder med AI, eller som er baseret i Ontario, eller som tidligere arbejdede hos LinkedIn.

Grafdatabaser overalt: Microsoft Graph, Common Data Service, Cosmos DB og Security Graph

Microsofts interesse for grafbaserede data er tydelig. Administrerende direktør Satya Nadella beskrev Office 365 API'er, grundlaget for det, der nu kaldes Microsoft Graph, som virksomhedens "vigtigste" indsats. Det er bestemt et meget kraftfuldt værktøj, og åbning af det for alle giver organisationer mulighed for at undersøge, hvordan deres interne teams udvikler sig, og hvordan virksomhedskendskab gemmes i dokumenter og samtaler - sammen med værktøjerne til at eksponere disse oplysninger og gøre dem brugbare.

Der er mange data i Microsoft Graph med værktøjer til både forbrugerinformation og forretningsinformation. Elementer, der er knyttet til Microsoft-konti, som den nye Activity Stream og Device Graph, er grundlaget for enhedsroamingfunktioner som Fortsæt på My PC-værktøjer, der for nylig blev frigivet til iOS og Android (svarende til Apples iCloud-kontobaserede Handoff-funktion i iOS) , og som Microsoft opfordrer Universal Window Platform (UWP) -udviklere til at indbygge i deres kode som en del af Project Rome og den kommende Windows-tidslinjefunktion.

Men Microsoft Graph og LinkedIn er ikke Microsofts eneste grafer med API'er:

  • Dynamics 365 har Common Data Service, en måde at beskrive standardelementer i en virksomhed på. Med Common Data Service kan du udvide et standardskema med din kundemodel eller dine produkter.
  • Så er der den skyomspændende Cosmos DB, der bygger på en JSON-dokumentdatabase med forskellige API-sæt, herunder et til udvikling og styring af dine egne grafdatabaser i målestok.
  • Selvom det ikke er helt offentligt, bruges Microsofts sikkerhedsgraf til at vurdere og administrere trusler, der udsættes for dine apps gennem værktøjer som Azure Active Directory's funktion med betinget adgang.

Microsofts forskellige tilgang: Forespørgsel på flere grafer

Hvor ting bliver interessante, er at bruge grafforespørgsler på tværs af flere grafer og bruge dem til at udtrække indsigt, der kan hjælpe med at få forretningsbeslutninger. Jeg har ofte talt om ideen om "informationer i rette tid": de rigtige oplysninger på det rigtige tidspunkt leveret til de rigtige mennesker, så de kan træffe den rigtige beslutning for det rigtige forretningsresultat. At være i stand til at forespørge kanterne på en graf i stedet for på noden, giver dig mulighed for at forstå forholdet mellem emner, en nøglefaktor til at levere den type informationsstøtte, som en moderne virksomhed har brug for.

Ved at understøtte flere grafer tilbyder Microsoft et alternativ til traditionelle databasestyrede beslutningsstøtteværktøjer. Ved at blande internt personale og dokumentdata på Microsoft Graph, eksterne relationer via LinkedIn, kerneforretningsoplysninger i Dynamics 365 Common Data Service og brugerdefineret skema i den cloudhostede Cosmos DB, kan du lave komplekse tværgående forespørgsler med fokus på ikke lige end individuelle noder i disse grafer, men også på forbindelserne mellem noder. Det giver dig mulighed for at arbejde med meget mere komplekse forhold end dem, der er eksponeret i relationsdatabaser.

En måde, hvorpå dette eksponeres, er i det nye Bing for Business-værktøj, der tilføjer oplysninger fra en virksomheds Active Directory og andre kilder til Bing-søgninger, når en bruger er logget ind på en Azure Active Directory-konto. Resultater genereres dynamisk fra forespørgsler fra Microsoft Graph, der returnerer detaljer om for eksempel hvor nogen er i organisationsskemaet sammen med relateret indhold fra det bredere web og fra dokumenter, de har delt internt.

Det er en anden måde at eksponere de oplysninger, der har været tilgængelige i Microsofts Delve-værktøj, og tage det fra et program, der skulle lanceres, før du kunne stille en forespørgsel til den browser, der altid er åben. Som industri har vi bagt søgning i browseren, så det er logisk at gøre det til et af de værktøjer, vi bruger til at udforske de grafer, der ligger til grund for vores virksomheder.

Den første frigivelse af Bing for Business fokuserer på Microsoft Graph sammen med værktøjer, der lader administratorer tilføje specifikke intranetlinks til specifikke forespørgsler. Så når du søger efter den aktuelle udgiftspolitik, bliver du sendt til de relevante selvbetjeningsværktøjer. Fremtidige udgivelser vil bringe flere af Microsofts grafer ind, låse søgningsbaseret betinget adgangsfunktion og eksponere eksterne relationer via LinkedIn.

Microsoft-grafernes fejl: De bruger forskellige forespørgselsgrammatikker

Selv om den overordnede vision for Microsofts forskellige grafbaserede egenskaber begynder at blive klar, er der stadig nogle problemer med forespørgsel på tværs af flere kilder. Selvom de alle tilbyder REST API'er, kan de underliggende forespørgselssprog variere. For eksempel bruger Microsoft Graph sin egen forespørgselsgrammatik i sine API'er, mens CosmosDB bygger på det udbredte Apache Gremlin-grafforespørgselssprog.

API-baserede forespørgsler har en tendens til at være relativt enkle og fokuseret på specifikke søgninger. Mere komplekse forespørgsler har tendens til at blive håndteret ved hjælp af domænespecifikke sprog som Gremlin, der er designet til brug med grafdatabaser. En af Gremlins mere interessante funktioner er dens evne til at generere nye kort fra de underliggende data, som du kan analysere og bruge i dine applikationer. Gremlin kan også håndtere mønstermatchning samt arbejde med store dataanalyseværktøjer som Hadoop; så du kan bruge den til at levere forespørgsler fra Azures HDInsight big data-værktøj sammen med dine Cosmos DB-hostede grafer.

Hvis vi skal få fordel af alle de forskellige Microsoft-grafegenskaber, har vi brug for en fælles forespørgselsplatform, der kan tage forespørgsler og blæse dem ud på tværs af forskellige kilder, asynkront håndtere svar og sikre, at forespørgslerne er konstrueret korrekt til målrette mod specifikke API'er.

Du kan opbygge din egen multigraf-forespørgselsmotor, men dette er virkelig noget, som Microsoft har brug for at levere, måske som en Azure-tjeneste. På den måde kan den integreres med eksisterende abonnementer og med velkendte godkendelsesmetoder, enten for brugere eller apps.