Data Mesh
Kreditt: Thoughtworks
For å sentralisere eller distribuere databehandling? Det spørsmålet har vært på forsiden helt siden avdelingsminidatamaskiner invaderte bedriften, fulgt enda mer subversivt av PC-er og LAN-er som gikk gjennom bakdøren. Og konvensjonell visdom har svingt frem og tilbake siden den gang. Arbeidsgruppe- eller avdelingssystemer for å gjøre data tilgjengelig, deretter konsolidering av bedriftsdatabaser for å bli kvitt all duplisering.
Husker du da datasjøen skulle være slutttilstanden? Akkurat som bedriftens datavarehus før det, viste forestillingen om at alle data kunne rulle inn på ett sted slik at det bare var én enkelt kilde til sannhet som alle samfunnslag på tvers av bedriften kunne få tilgang til, urealistisk. Internett-tilknytningen, den tilsynelatende billige lagringen og endeløse skalerbarheten til skyen, eksplosjonen av smartenheter og IoT-data truer med å overvelde datavarehusene og datasjøene som er så møysommelig satt opp. Datainnsjøhus har i det siste dukket opp for å bringe det beste fra begge verdener, mens datastrukturer og intelligente datahuber optimerer avveiningene mellom virtualisering og replikering av data.
Det ville være meningsløst å si at noen av disse alternativene tilbyr den definitive silver bullet.
Skriv inn datanettverket
I løpet av det siste året har det dukket opp en ny teori som anerkjenner nytteløsheten av top-down eller monolitiske tilnærminger til datahåndtering: datanettverket. Mens mye av søkelyset i det siste har vært på AI og maskinlæring, er det i dataverdenen færre emner som trekker mer diskusjon enn datanettverk. Bare se på Google Trends-data for de siste 90 dagene: søk etter Data Mesh er langt flere enn søk etter Data Lakehouse.
Det ble opprettet av Zhamak Dehghani, direktør for neste teknologiinkubasjon ved Thoughtworks North America, gjennom et omfattende sett med arbeider som begynner med en introduksjon tilbake i 2019, en drill-down på prinsipper og logisk arkitektur i slutten av 2020, som snart vil kulminere i en bok (hvis du er interessert, byr Starburst Data på en sniktitt). Datanettverk har ofte blitt sammenlignet med datastrukturer, men en nærlesing av Dehghanis arbeid avslører at dette handler mer om prosess enn teknologi, som James Serra, en arkitekturleder hos EY og tidligere hos Microsoft, korrekt påpekte i et blogginnlegg. Ikke desto mindre fortjener temaet datamasker (som er distribuerte visninger av dataområdet) kontra datastrukturer (som bruker mer sentraliserte tilnærminger) sitt eget innlegg, siden interessen for begge har vært ganske lik.
Enkelt sagt, hvis det er mulig, er datanettverk ikke en teknologistabel eller fysisk arkitektur. Data mesh er en prosess og arkitektonisk tilnærming som delegerer ansvaret for spesifikke datasett til domener, eller områder av virksomheten som har den nødvendige fagkompetansen for å vite hva dataene skal representere og hvordan de skal brukes.
Det er et arkitektonisk aspekt ved dette: i stedet for å anta at data vil ligge i en datainnsjø, vil hvert “domene” være ansvarlig for å velge hvordan de skal være vert for og betjene datasettene de eier.
Bortsett fra ekstern regulering eller corporate governance policy, er domenene grunnen til at spesifikke datasett samles inn. Men djevelen sitter i detaljene, og det er mange av dem.
Så datanettverket er ikke definert av datavarehuset, datainnsjøen eller datainnsjøen der dataene fysisk befinner seg. Det er heller ikke definert av dataføderasjonen, dataintegreringen, søkemotoren eller katalogiseringsverktøyene som fyller ut og merker disse datalagrene. Det har selvfølgelig ikke stoppet teknologileverandører fra å vaske produktene sine med datanettverk. I løpet av det neste året vil vi sannsynligvis se leverandører av kataloger, søkemotorer, datapipelines og styring male verktøyene eller plattformene sine i et datanettverk. Men når du ser markedsføringsbudskapene, husk at datanettverk handler om prosess og hvordan du implementerer teknologi. For eksempel er en forent spørringsmotor ganske enkelt en aktivator som kan hjelpe et team med implementering, men som i seg selv ikke plutselig forvandler et dataområde til et datanettverk.
Kjernepilarene
< p>Data Mesh er et komplekst konsept, men den beste måten å starte på er å forstå prinsippene bak det.
Det første prinsippet handler om dataeierskap – det skal være lokalt, bosatt hos teamet som er ansvarlig for å samle inn og/eller konsumere dataene. Hvis det er et sentralt prinsipp for datamasker, er dette det – det er at kontrollen av data skal overføres til domenet som eier dem. Tenk på et domene som en utvidelse av domenekunnskap – dette er den organisatoriske enheten eller gruppen av mennesker som forstår hva dataene er og hvordan de er relatert til virksomheten. Dette er enheten som vet hvorfor datasettet samles inn; hvordan det blir konsumert, og av hvem; og hvordan det bør styres gjennom livssyklusen.
Ting blir litt mer komplisert for data som deles på tvers av domener, eller hvor data under ett domene er avhengig av data eller APIer fra andre domener. Velkommen til den virkelige verden, hvor data sjelden er en øy. Dette er et av stedene der implementering av mesh kan bli klissete.
Det andre prinsippet er at data skal betraktes som et produkt. Det er faktisk et mer ekspansivt syn på hva som består av en dataenhet, ved at det er mer enn datastykket eller et spesifikt datasett og tar mer et livssyklussyn på hvordan data kan og bør serveres og konsumeres. Og en del av definisjonen av produktet er et formelt servicenivåmål, som kan gjelde faktorer som ytelse, pålitelighet og pålitelighet, datakvalitet, sikkerhetsrelaterte autorisasjonsregler og så videre. Det er et løfte som domenet som eier dataene gir til organisasjonen.
Spesifikt går et dataprodukt utover datasettet eller dataenheten for å inkludere koden for datarørledningene som er nødvendige for å generere og/eller transformere dataene; de tilhørende metadataene (som selvfølgelig kan omfatte alt fra skjemadefinisjon til relevante forretningsordlistebegreper, forbruksmodeller eller skjemaer som relasjonstabeller, hendelser, batchfiler, skjemaer, grafer, etc.); og infrastruktur (hvordan og hvor dataene lagres og behandles). Dette har betydelige organisatoriske konsekvenser, gitt at bygging av datarørledninger ofte er en usammenhengende aktivitet som håndteres uavhengig av spesialister som dataingeniører og utviklere. I det minste i en matrisesammenheng må de være en del av, eller assosiert med, domenet eller forretningsteamet som eier dataene.
På, og forresten, det dataproduktet må tilfredsstille noen nøkkelkrav. Dataene må være lett synlige; dette er antagelig hva kataloger er for. Den skal også være utforskbar, slik at brukerne kan se detaljer. Og det skal være adresserbart; her nevner Dehghani at data bør ha unike kanoniske adresser, noe som høres ut som en abstraksjon på høyere nivå av den semantiske nettresten, den klassiske Uri. Til slutt bør data være forståelige (Dehghani foreslår “selvbeskrivende semantikk og syntaks”); troverdig; og sikker. La oss ikke glemme at siden dette er ment å krysse flere domener, vil det være nødvendig med dataharmonisering.
Mens datanettverk ikke er definert av teknologi, vil spesifikke ingeniørgrupper i den virkelige verden eie den underliggende dataplattformen, enten det er en database, datainnsjø og/eller strømmemotor. Det gjelder uavhengig av om organisasjonen implementerer disse plattformene lokalt eller drar fordel av en administrert databasetjeneste i skyen, og mer sannsynlig begge steder. Noen må eie den underliggende plattformen, og disse plattformene vil også bli betraktet som produkter i det store og hele.
Selvbetjent dataplattform
Kreditt: Thoughtworks
Det tredje prinsippet er behovet for at data skal være tilgjengelig via en selvbetjent dataplattform som vist ovenfor. Selvbetjening har selvfølgelig blitt et stikkord for bredere datatilgang, da det er den eneste måten for data å bli forbrukbare ettersom dataområdet utvides, gitt at IT-ressursene er begrensede, spesielt med dataingeniører som er sjeldne og dyrebare. Det hun beskriver her må ikke forveksles med selvbetjente plattformer for datavisualisering eller dataforskere; denne er mer for infrastruktur- og produktutviklere.
Denne plattformen kan ha, hva Dehghani betegner, forskjellige fly (eller skinn) som betjener forskjellige streker av utøvere. Eksempler kan inkludere et infrastrukturklargjøringsplan, som tar for seg all den stygge fysiske mekanikken ved å samle data (som klargjøring av lagring, innstilling av tilgangskontroller, og søkemotoren); en produktutviklingsopplevelse som gir et deklarativt grensesnitt for å administrere datalivssyklusen; og et tilsynsplan som administrerer dataproduktene. Dehghani blir mye mer uttømmende om hva en selvbetjent dataplattform skal støtte, og her er listen.
Endelig er ingen tilnærming til å administrere data komplett uten styring. Det er det fjerde prinsippet, og Dehghani kaller det føderert beregningsstyring. Dette erkjenner realiteten at i et distribuert miljø vil det være flere, gjensidig avhengige dataprodukter som må fungere sammen, og på den måten støtte datasuverenitetsmandater og de medfølgende reglene for dataoppbevaring og tilgang. Det vil være behov for å fullt ut forstå og spore dataavstamning.
Et enkelt innlegg ville ikke yte dette emnet rettferdighet. Med fare for å bastardisere ideen betyr dette at en sammenslutning av dataprodukter og dataplattformprodukteiere oppretter og håndhever et globalt sett med regler som gjelder for alle dataprodukter og grensesnitt. Det som mangler her er at det må legges til rette for toppledelsen når det gjelder bedriftsdekkende retningslinjer og mandater; Dehghani utleder det (forhåpentligvis blir boken hennes mer spesifikk). I hovedsak uttaler Dehghani det som sannsynligvis vil være uformell praksis i dag, hvor mye ad hoc-beslutninger om styring allerede tas på lokalt nivå.
Federated Computational Governance
Kreditt: Thoughtworks
Så bør du prøve dette hjemme?
Få emner har vakt så mye oppmerksomhet i dataverdenen det siste året som datanettverket. En av triggerne er at i en stadig mer skybasert verden der applikasjoner og forretningslogikk blir dekomponert til mikrotjenester, hvorfor ikke behandle data på samme måte?
Svaret er lettere sagt enn gjort. For eksempel, mens monolittiske systemer kan være stive og uhåndterlige, introduserer distribuerte systemer sin egen kompleksitet, velkommen eller ikke. Det er risiko for å skape nye siloer, for ikke å snakke om kaos, når lokal styrking ikke er tilstrekkelig gjennomtenkt.
For eksempel skal utvikling av datarørledninger være en del av definisjonen av et dataprodukt, men når disse rørledningene kan gjenbrukes andre steder, må det legges til rette for at dataproduktteam kan dele IP-en sin. Ellers er det mye duplisert innsats. Dehghani ber om at lagene skal operere i et forbundsmiljø, men her er risikoen å tråkke på andres gress.
Distribuering av livssyklusadministrasjonen av data kan være styrkende, men i de fleste organisasjoner vil det sannsynligvis være mange tilfeller der eierskap til data ikke er entydig for scenarier der flere interessentgrupper enten deler bruk eller hvor data er hentet fra andres data . Dehghani erkjenner dette, og bemerker at domener vanligvis får data fra flere kilder, og i sin tur kan forskjellige domener duplisere data (og transformere dem på forskjellige måter) for eget forbruk.
Datamasker som konsepter er under arbeid. I sitt introduksjonsinnlegg refererer Dehghani til en nøkkeltilnærming for å gjøre data synlig: gjennom det hun kaller “selvbeskrivende semantikk.” Men beskrivelsen hennes er kort, og indikerer at bruk av “godt beskrevet syntaks” akkompagnert av eksempeldatasett og spesifikasjoner for skjema er gode utgangspunkt – for dataingeniøren, ikke forretningsanalytikeren. Det er et poeng vi ønsker å se hennes kropp ut i hennes kommende bok.
Et annet nøkkelkrav, for føderert “beregningsbasert” styring, kan være en munnfull å uttale, men det vil være enda mer av det å implementere, som en titt på diagrammet ovenfor illustrerer. Å lokalisere beslutninger så nærme kilden, mens globalisering av beslutninger angående interoperabilitet vil kreve mye prøving og feiling.
Når det er sagt, er det gode grunner til at vi har denne diskusjonen. Det er frakoblinger med data, og mange av problemene er neppe nye. Sentralisert arkitektur, for eksempel et datavarehus, datainnsjø eller datainnsjø, kan ikke yte rettferdighet i en polyglot-verden. På den annen side kan det argumenteres for datastrukturtilnærmingen som fastholder at en mer sentralisert tilnærming til metadatahåndtering og dataoppdagelse vil være mer effektiv. Det er også argumenter for at en hybrid tilnærming som utnytter kraften til enhetlig metadataadministrasjon av datastrukturen kan brukes som et logisk bakplan for domener til å bygge og eie dataproduktene sine.
Et annet smertepunkt er at prosessene for å håndtere data i hvert stadium av livssyklusen ofte er usammenhengende, der dataingeniører eller apputviklere som bygger pipelines kan bli skilt fra linjeorganisasjonene som dataene betjener. Selvbetjening har blitt populært blant forretningsanalytikere for visualisering, og for dataforskere i utvikling av ML-modeller og flytting av dem til produksjon. Det er gode argumenter for å utvide dette til å administrere datalivssyklusen til team som etter all logikk burde eie dataene.
Men la oss ikke gå i forkant. Dette er veldig ambisiøse greier. Når det gjelder fordeling av forvaltning og eierskap av dataressurser, som nevnt tidligere, er djevelen i detaljene. Og det er nok av detaljer som fortsatt må strykes ut. Vi er ennå ikke solgt over at slike nedenfra og opp-tilnærminger til å eie data vil skalere på tvers av hele bedriftsdataområdet, og at vi kanskje bør rette blikket mer beskjedent: begrense nettverket til deler av organisasjonen med relaterte eller gjensidig avhengige domener.< /p>
Vi ser flere innlegg der kunder erklærer seier for tidlig. Men som dette innlegget sier, bare fordi organisasjonen din har implementert et forent spørringslag eller segmenterer datainnsjøene, gjør ikke distribusjonen til et datanettverk. På dette tidspunktet bør implementering av et datanettverk med all distribuert styring behandles som proof of concept.
Big Data
Microsofts SQL Server 2022 rulles ut i privat forhåndsvisning EDB slipper løs BigAnimal i skyen Google Cloud Neste: Møt bedriften der den bor Microsoft forbedrer skydatabasen, lager- og innsjøtjenester Data Management | Digital transformasjon | Robotikk | Internet of Things | Innovasjon | Enterprise Software