Data Mesh
Kredit: Thoughtworks
At centralisere eller distribuere datahåndtering? Det spørgsmål har været på forbrændingen lige siden afdelingsminicomputere invaderede virksomheden, efterfulgt endnu mere subversivt af pc'er og LAN'er, der gik gennem bagdøren. Og konventionel visdom har svinget frem og tilbage lige siden. Arbejdsgruppe- eller afdelingssystemer for at gøre data tilgængelige, derefter konsolidering af virksomhedsdatabaser for at slippe af med al duplikeringen.
Kan du huske, da datasøen skulle være sluttilstanden? Ligesom virksomhedens datavarehus før det, viste tanken om, at alle data kunne rulle til ét sted, så der kun var en enkelt kilde til sandhed, som alle samfundslag på tværs af virksomheden kunne få adgang til, urealistisk. Internettets forbindelse, den tilsyneladende billige opbevaring og endeløse skalerbarhed i skyen, eksplosionen af smartenheder og IoT-data truer med at overvælde datavarehusene og datasøerne, der er så møjsommeligt opsat. Data lakehouses er på det seneste dukket op for at bringe det bedste fra begge verdener, mens datastrukturer og intelligente datahubs optimerer afvejningen mellem virtualisering og replikering af data.
Det ville være meningsløst at sige, at et hvilket som helst af disse alternativer tilbyder den definitive silver bullet.
Indtast Data Mesh
I løbet af det seneste år er der dukket en ny teori op, der anerkender nytteløsheden af top-down eller monolitiske tilgange til datastyring: datanettet. Mens meget af søgelyset på det seneste har været på AI og maskinlæring, er der i dataverdenen færre emner, der trækker mere diskussion end datanetværk. Se bare på Google Trends-data for de seneste 90 dage: søgninger efter Data Mesh er langt flere end søgninger efter Data Lakehouse.
Det blev skabt af Zhamak Dehghani, direktør for næste tech-inkubation hos Thoughtworks North America, gennem et omfattende sæt værker, der begynder med en introduktion tilbage i 2019, en drill-down på principper og logisk arkitektur i slutningen af 2020, som snart vil kulminere i en bog (hvis du er interesseret, giver Starburst Data et smugkig). Datamasker er ofte blevet sammenlignet med datavæv, men en nærlæsning af Dehghanis arbejde afslører, at dette handler mere om proces end teknologi, som James Serra, en arkitekturleder hos EY og tidligere hos Microsoft, korrekt påpegede i et blogindlæg. Ikke desto mindre fortjener emnet datamasker (som er distribuerede visninger af dataejendommen) vs. datastrukturer (som anvender mere centraliserede tilgange) sit eget indlæg, da interessen for begge har været ret ens.
Enkelt sagt, hvis det er muligt, er datamesh ikke en teknologistack eller fysisk arkitektur. Datamesh er en proces- og arkitektonisk tilgang, der uddelegerer ansvaret for specifikke datasæt til domæner eller områder af virksomheden, der har den nødvendige ekspertise til at vide, hvad dataene skal repræsentere, og hvordan de skal bruges.
Der er et arkitektonisk aspekt ved dette: i stedet for at antage, at data vil ligge i en datasø, vil hvert “domæne” være ansvarligt for at vælge, hvordan de skal hoste og betjene de datasæt, de ejer.
Udover ekstern regulering eller corporate governance-politik er domænerne årsagen til, at specifikke datasæt indsamles. Men djævelen er i detaljerne, og dem er der mange af.
Så datanettet er ikke defineret af datavarehuset, datasøen eller datasøen, hvor dataene fysisk befinder sig. Det er heller ikke defineret af dataføderationen, dataintegrationen, forespørgselsmotoren eller katalogiseringsværktøjer, der udfylder og annoterer disse datalagre. Det har selvfølgelig ikke forhindret teknologileverandører i at datamesh-vaske deres produkter. I løbet af det næste år vil vi sandsynligvis se udbydere af kataloger, forespørgselsmotorer, datapipelines og styring male deres værktøjer eller platforme i et datamesh-lys. Men som du ser markedsføringsbudskaberne, så husk, at datamasker handler om proces og hvordan du implementerer teknologi. For eksempel er en fødereret forespørgselsmotor simpelthen en aktiverer, der kan hjælpe et team med implementering, men som i sig selv ikke pludselig forvandler et dataområde til et datanet.
Kernesøjlerne
< p>Data Mesh er et komplekst koncept, men den bedste måde at starte på er ved at forstå principperne bag det.
Det første princip handler om dataejerskab – det skal være lokalt og være hjemmehørende hos det team, der er ansvarligt for at indsamle og/eller forbruge dataene. Hvis der er et centralt princip for datamasker, er det det – det er, at kontrollen med data skal overdrages til det domæne, der ejer dem. Tænk på et domæne som en forlængelse af domæneviden – dette er den organisatoriske enhed eller gruppe af mennesker, der forstår, hvad data er, og hvordan det relaterer til virksomheden. Dette er den enhed, der ved, hvorfor datasættet bliver indsamlet; hvordan det forbruges, og af hvem; og hvordan det skal styres gennem dets livscyklus.
Tingene bliver en smule mere komplicerede for data, der deles på tværs af domæner, eller hvor data under ét domæne er afhængige af data eller API'er fra andre domæner. Velkommen til den virkelige verden, hvor data sjældent er en ø. Dette er et af de steder, hvor implementering af mesh kan blive klistret.
Det andet princip er, at data skal betragtes som et produkt. Det er i virkeligheden et mere ekspansivt syn på, hvad der omfatter en dataentitet, idet det er mere end stykket data eller et specifikt datasæt og i højere grad tager et livscyklussyn på, hvordan data kan og bør serveres og forbruges. Og en del af definitionen af produktet er et formelt serviceniveaumål, som kan vedrøre faktorer som ydeevne, troværdighed og pålidelighed, datakvalitet, sikkerhedsrelaterede autorisationsregler og så videre. Det er et løfte, som domænet, der ejer dataene, giver organisationen.
Specifikt går et dataprodukt ud over datasættet eller dataenheden til at inkludere koden til de datapipelines, der er nødvendige for at generere og/eller transformere dataene; de tilknyttede metadata (som selvfølgelig kunne omfatte alt fra skemadefinition til relevante forretningsordlisteudtryk, forbrugsmodeller eller formularer såsom relationelle tabeller, begivenheder, batchfiler, formularer, grafer osv.); og infrastruktur (hvordan og hvor dataene opbevares og behandles). Dette har betydelige organisatoriske konsekvenser, eftersom bygningen af datapipelines ofte er en usammenhængende aktivitet, der håndteres uafhængigt af specialister som f.eks. dataingeniører og udviklere. I det mindste i en matrixsammenhæng skal de være en del af eller associeret med domænet eller forretningsteamet, der ejer dataene.
På og i øvrigt skal det dataprodukt opfylde nogle nøglekrav. Dataene skal være let opdagelige; det er formentlig hvad kataloger er til. Det skal også være udforskeligt, så brugerne kan gå i detaljer. Og det skal kunne adresseres; her nævner Dehghani, at data skal have unikke kanoniske adresser, hvilket lyder som en abstraktion på højere niveau af den semantiske webrest, den klassiske Uri. Endelig bør data være forståelige (Dehghani foreslår “selv-beskrivende semantik og syntaks”); troværdig; og sikker. Lad os ikke glemme, at da dette er beregnet til at krydse flere domæner, vil det være nødvendigt med dataharmonisering.
Selvom datamesh ikke er defineret af teknologi, vil specifikke ingeniørgrupper i den virkelige verden eje den underliggende dataplatform, uanset om det er en database, datasø og/eller streamingmotor. Det gælder, uanset om organisationen implementerer disse platforme på stedet eller udnytter en administreret databasetjeneste i skyen, og mere sandsynligt begge steder. Nogen skal eje den underliggende platform, og disse platforme vil også blive betragtet som produkter i den store sammenhæng.
Selvbetjeningsdataplatform
Kredit: Thoughtworks
Det tredje princip er behovet for, at data er tilgængelige via en selvbetjeningsdataplatform som vist ovenfor. Selvfølgelig er selvbetjening blevet et kodeord for bredere dataadgang, da det er den eneste måde for data at blive forbrugsdygtige, efterhånden som dataområdet udvides, givet at it-ressourcerne er begrænsede, især med dataingeniører, der er sjældne og dyrebare. Det, hun beskriver her, må ikke forveksles med selvbetjeningsplatforme til datavisualisering eller dataforskere; denne er mere til infrastruktur- og produktudviklere.
Denne platform kan have, hvad Dehghani betegner, forskellige fly (eller skins), der betjener forskellige dele af udøvere. Eksempler kunne omfatte et infrastrukturklargøringsplan, der håndterer al den grimme fysiske mekanik ved at samle data (såsom klargøring af lager, indstilling af adgangskontrol og forespørgselsmotoren); en produktudviklingsoplevelse, der giver en deklarativ grænseflade til styring af datalivscyklussen; og et supervisionsplan, der styrer dataprodukterne. Dehghani bliver meget mere udtømmende om, hvad en selvbetjent dataplatform skal understøtte, og her er listen.
Endelig er ingen tilgang til håndtering af data komplet uden styring. Det er det fjerde princip, og Dehghani betegner det som fødereret beregningsstyring. Dette anerkender den virkelighed, at der i et distribueret miljø vil være flere, indbyrdes afhængige dataprodukter, der skal fungere sammen, og derved understøtter datasuverænitetsmandater og de medfølgende regler for dataopbevaring og -adgang. Der vil være behov for fuldt ud at forstå og spore dataafstamning.
Et enkelt indlæg ville ikke yde dette emne retfærdighed. Med fare for at bastardisere ideen betyder det, at en sammenslutning af dataprodukter og dataplatformsproduktejere skaber og håndhæver et globalt sæt regler, der gælder for alle dataprodukter og grænseflader. Det, der mangler her, er, at der skal være mulighed for topledelse, når det kommer til virksomhedsdækkende politikker og mandater; Dehghani udleder det (forhåbentlig bliver hendes bog mere specifik). I bund og grund udtaler Dehghani, hvad der sandsynligvis vil være uformel praksis i dag, hvor en masse ad hoc-beslutninger om styring allerede træffes på lokalt niveau.
Federated Computational Governance
Kredit: Thoughtworks
Så bør du prøve dette derhjemme?
Få emner har trukket så meget opmærksomhed i dataverdenen i løbet af det seneste år som datanettet. En af triggerne er, at i en stadig mere cloud-native verden, hvor applikationer og forretningslogik bliver dekomponeret til mikrotjenester, hvorfor så ikke behandle data på samme måde?
Svaret er lettere sagt end gjort. Mens monolitiske systemer kan være stive og uhåndterlige, introducerer distribuerede systemer deres egne kompleksiteter, velkomne eller ej. Der er risiko for at skabe nye siloer, for ikke at tale om kaos, når lokal empowerment ikke er tilstrækkeligt gennemtænkt.
For eksempel formodes udvikling af datapipelines at være en del af definitionen af et dataprodukt, men når disse pipelines kan genbruges andre steder, skal der sørges for, at dataproduktteams deler deres IP. Ellers er der masser af dobbeltarbejde. Dehghani opfordrer hold til at operere i et forbundsmiljø, men her er risikoen at træde på andres græs.
Distribution af livscyklusstyringen af data kan være styrkende, men i de fleste organisationer vil der sandsynligvis være masser af tilfælde, hvor ejerskab af data ikke er entydigt for scenarier, hvor flere interessentgrupper enten deler brug, eller hvor data er afledt af andres data . Dehghani anerkender dette og bemærker, at domæner typisk får data fra flere kilder, og til gengæld kan forskellige domæner duplikere data (og transformere dem på forskellige måder) til deres eget forbrug.
Datamasker som koncepter er igangværende arbejde. I sit indledende indlæg refererer Dehghani til en nøgletilgang til at gøre data synlige: gennem det, hun kalder “selvbeskrivende semantik.” Men hendes beskrivelse er kort, hvilket indikerer, at brug af “velbeskrevet syntaks” ledsaget af eksempeldatasæt og specifikationer for skema er gode udgangspunkter – for dataingeniøren, ikke forretningsanalytikeren. Det er et punkt, vi gerne vil se hendes kød ud i hendes kommende bog.
Et andet nøglekrav, for fødereret “beregningsmæssig” styring, kan være en mundfuld at udtale, men det vil være endnu mere af det at implementere, som et kig på diagrammet ovenfor illustrerer. At lokalisere beslutninger så tæt på kilden, mens globalisering af beslutninger vedrørende interoperabilitet vil kræve betydelige forsøg og fejl.
Når det er sagt, er der gode grunde til, at vi har denne diskussion. Der er afbrydelser med data, og mange af problemerne er næppe nye. Centraliseret arkitektur, såsom et virksomhedsdatavarehus, datasø eller datasøhus, kan ikke yde retfærdighed i en polyglot-verden. På den anden side kan der argumenteres for datastrukturtilgangen, der fastholder, at en mere centraliseret tilgang til metadatastyring og dataopdagelse vil være mere effektiv. Der er også et argument for, at en hybrid tilgang, der udnytter kraften i unified metadata management af datastrukturen, kunne bruges som en logisk backplane for domæner til at bygge og eje deres dataprodukter.
Et andet smertepunkt er, at processerne til håndtering af data på hvert trin af dets livscyklus ofte er usammenhængende, hvor dataingeniører eller app-udviklere, der bygger pipelines, kan være adskilt fra de linjeorganisationer, som dataene betjener. Selvbetjening er blevet populært blandt forretningsanalytikere til visualisering og for dataforskere til at udvikle ML-modeller og flytte dem i produktion. Der er gode argumenter for at udvide dette til at administrere datalivscyklussen til teams, der efter al logik burde eje dataene.
Men lad os ikke komme os selv foran. Det er meget ambitiøse ting. Når det kommer til at fordele forvaltningen og ejerskabet af dataaktiver, som tidligere nævnt, er djævelen i detaljerne. Og der er masser af detaljer, der stadig skal stryges ud. Vi er endnu ikke solgte til, at sådanne bottom-up-tilgange til at eje data vil skalere på tværs af hele virksomhedens dataområde, og at vi måske bør rette vores blikke mere beskedent: begrænse masken til dele af organisationen med relaterede eller indbyrdes afhængige domæner.< /p>
Vi ser flere indlæg, hvor kunder erklærer sejr i utide. Men som det står i dette indlæg, gør bare fordi din organisation har implementeret et fødereret forespørgselslag eller segmenterer dets datasøer ikke dens implementering til et datanet. På dette tidspunkt bør implementering af et datanet med hele dets distribuerede styring behandles som proof of concept.
Big Data
Microsofts SQL Server 2022 rulles ud i privat preview EDB frigiver BigAnimal i skyen Google Cloud Næste: Mød virksomheden, hvor den bor Microsoft forbedrer sin clouddatabase, lager og søtjenester Data Management | Digital transformation | Robotik | Internet of Things | Innovation | Enterprise Software