Data Mesh
Kredit: Thoughtworks
Att centralisera eller distribuera datahantering? Den frågan har legat på den främre brännaren ända sedan avdelningens minidatorer invaderade företaget, följt ännu mer subversivt av datorer och LAN som gick genom bakdörren. Och konventionell visdom har svängt fram och tillbaka sedan dess. Arbetsgrupps- eller avdelningssystem för att göra data tillgänglig, sedan konsolidering av företagsdatabas för att bli av med all dubbelarbete.
Kommer du ihåg när datasjön skulle vara sluttillståndet? Precis som företagets datalager innan dess, visade sig uppfattningen att all data kunde rullas till ett ställe så att det bara fanns en enda källa till sanning som alla samhällsskikt i företaget kunde komma åt orealistisk. Internets uppkoppling, den till synes billiga lagringen och molnets oändliga skalbarhet, explosionen av smarta enheter och IoT-data hotar att överväldiga datalager och datasjöar som är så mödosamt inrättade. Datasjöhus har på sistone dykt upp för att ge det bästa av två världar, medan dataväv och intelligenta datahubbar optimerar avvägningarna mellan virtualisering och replikering av data.
Det skulle vara meningslöst att påstå att något av dessa alternativ erbjuder den definitiva silver bullet.
Ange datanätet
Under det senaste året har en ny teori dykt upp som erkänner meningslösheten i top-down eller monolitiska tillvägagångssätt för datahantering: datanätet. Även om mycket av rampljuset den senaste tiden har legat på AI och maskininlärning, finns det i datavärlden färre ämnen som drar mer diskussion än datanät. Titta bara på Google Trends-data för de senaste 90 dagarna: sökningar efter Data Mesh är långt fler än de för Data Lakehouse.
Det skapades av Zhamak Dehghani, chef för nästa tekniska inkubation på Thoughtworks North America, genom en omfattande uppsättning arbeten som börjar med en introduktion tillbaka 2019, en detaljerad beskrivning av principer och logisk arkitektur i slutet av 2020, som snart kommer att kulminera i en bok (om du är intresserad erbjuder Starburst Data en tjuvtitt). Datanät har ofta jämförts med datatyger, men en noggrann läsning av Dehghanis arbete avslöjar att detta handlar mer om process än teknik, som James Serra, en arkitekturledare på EY och tidigare med Microsoft, korrekt påpekade i ett blogginlägg. Ändå förtjänar ämnet datanät (som är distribuerade vyer av dataområdet) kontra dataväv (som tillämpar mer centraliserade tillvägagångssätt) ett eget inlägg, eftersom intresset för båda har varit ganska lika.
Enkelt uttryckt, om det är möjligt är datanät inte en teknikstack eller fysisk arkitektur. Datamesh är ett process- och arkitektoniskt tillvägagångssätt som delegerar ansvaret för specifika datamängder till domäner eller delar av verksamheten som har den erforderliga sakkunskapen för att veta vad datan ska representera och hur den ska användas.
Det finns en arkitektonisk aspekt av detta: istället för att anta att data kommer att finnas i en datasjö, kommer varje “domän” att vara ansvarig för att välja hur de ska vara värd för och betjäna de datamängder som de äger.
Bortsett från extern reglering eller bolagsstyrningspolicy är domänerna anledningen till att specifika datamängder samlas in. Men djävulen ligger i detaljerna, och det finns många av dem.
Så, datanätet definieras inte av datavarehuset, datasjön eller datasjöhuset där data fysiskt finns. Det är inte heller definierat av datafederationen, dataintegrationen, frågemotorn eller katalogiseringsverktygen som fyller och kommenterar dessa datalagrar. Naturligtvis har det inte hindrat teknikleverantörer från att datamesh-tvätta sina produkter. Under nästa år kommer vi sannolikt att se leverantörer av kataloger, frågemotorer, datapipelines och styrning måla upp sina verktyg eller plattformar i ett datanät. Men när du ser marknadsföringsbudskapen, kom ihåg att datanät handlar om process och hur du implementerar teknik. Till exempel är en federerad frågemotor helt enkelt en möjliggörare som kan hjälpa ett team med implementeringen, men som i sig inte plötsligt förvandlar ett dataområde till ett datanät.
Kärnpelarna
< p>Data Mesh är ett komplext koncept, men det bästa sättet att börja är att förstå principerna bakom det.
Den första principen handlar om dataägande – det ska vara lokalt, bosatt hos teamet som ansvarar för att samla in och/eller konsumera data. Om det finns en central princip för datanät, så är det den – det är att kontrollen av data ska överlåtas till domänen som äger den. Tänk på en domän som en förlängning av domänkunskap – det här är den organisatoriska enhet eller grupp människor som förstår vad data är och hur det relaterar till verksamheten. Det här är entiteten som vet varför datamängden samlas in; hur det konsumeras och av vem; och hur det ska styras genom sin livscykel.
Saker och ting blir lite mer komplicerade för data som delas mellan domäner, eller där data under en domän är beroende av data eller API:er från andra domäner. Välkommen till den verkliga världen, där data sällan är en ö. Det här är en av platserna där implementering av mesh kan bli klibbig.
Den andra principen är att data ska betraktas som en produkt. Det är i själva verket en mer expansiv bild av vad som utgör en dataenhet, i det att den är mer än en del av data eller en specifik datamängd och tar mer av en livscykelvy av hur data kan och bör serveras och konsumeras. Och en del av definitionen av produkten är ett formellt servicenivåmål, som kan hänföra sig till faktorer som prestanda, pålitlighet och tillförlitlighet, datakvalitet, säkerhetsrelaterade auktoriseringsregler och så vidare. Det är ett löfte som domänen som äger data ger till organisationen.
Specifikt går en dataprodukt utöver datamängden eller dataenheten för att inkludera koden för de datapipelines som är nödvändiga för att generera och/eller transformera data; tillhörande metadata (som naturligtvis kan omfatta allt från schemadefinition till relevanta affärsordlista, konsumtionsmodeller eller formulär som relationstabeller, händelser, batchfiler, formulär, grafer, etc.); och infrastruktur (hur och var data lagras och bearbetas). Detta har betydande organisatoriska konsekvenser, med tanke på att byggandet av datapipelines ofta är en osammanhängande aktivitet som hanteras oberoende av specialister som dataingenjörer och utvecklare. Åtminstone i ett matrissammanhang måste de vara en del av, eller associerade med, domänen eller affärsteamet som äger data.
På, och förresten, den dataprodukten måste uppfylla några nyckelkrav. Uppgifterna måste vara lätta att upptäcka; det är förmodligen vad kataloger är till för. Det bör också vara utforskbart, så att användarna kan gå igenom dem. Och det ska vara adresserbart; Här nämner Dehghani att data bör ha unika kanoniska adresser, vilket låter som en abstraktion på högre nivå av den semantiska webbresten, den klassiska Uri. Slutligen bör data vara begripliga (Dehghani föreslår “självbeskrivande semantik och syntax”); pålitlig; och säker. Låt oss inte glömma att eftersom detta är avsett att korsa flera domäner kommer det att behövas ansträngningar för dataharmonisering.
Även om datanät inte definieras av teknik, i den verkliga världen kommer specifika ingenjörsgrupper att äga den underliggande dataplattformen, oavsett om det är en databas, datasjö och/eller streamingmotor. Det gäller oavsett om organisationen implementerar dessa plattformar på plats eller drar fördel av en hanterad databastjänst i molnet, och mer troligt på båda ställena. Någon måste äga den underliggande plattformen, och dessa plattformar kommer också att betraktas som produkter i det stora hela.
Självbetjäningsdataplattform
Kredit: Thoughtworks
Den tredje principen är behovet av att data ska vara tillgänglig via en självbetjäningsdataplattform som visas ovan. Självbetjäning har naturligtvis blivit ett ledord för bredare dataåtkomst eftersom det är det enda sättet för data att bli förbrukningsbara när dataområdet expanderar, med tanke på att IT-resurserna är begränsade, särskilt med dataingenjörer som är sällsynta och värdefulla. Det hon beskriver här ska inte förväxlas med självbetjäningsplattformar för datavisualisering eller datavetare; den här är mer för infrastruktur- och produktutvecklare.
Den här plattformen kan ha, vad Dehghani uttrycker, olika plan (eller skinn) som servar olika delar av utövare. Exempel kan inkludera ett infrastrukturförsörjningsplan, som hanterar all den fula fysiska mekaniken för att samla data (som provisionering av lagring, inställning av åtkomstkontroller, och frågemotorn); en produktutvecklingsupplevelse som ger ett deklarativt gränssnitt för att hantera datalivscykeln; och ett övervakningsplan som hanterar dataprodukterna. Dehghani blir mycket mer uttömmande om vad en självbetjäningsdataplattform ska stödja, och här är listan.
Slutligen, ingen metod för att hantera data är komplett utan styrning. Det är den fjärde principen, och Dehghani kallar det för federerad beräkningsstyrning. Detta erkänner verkligheten att i en distribuerad miljö kommer det att finnas flera, ömsesidigt beroende dataprodukter som måste samverka, och på så sätt stödja datasuveränitetsmandat och de medföljande reglerna för datalagring och åtkomst. Det kommer att finnas ett behov av att helt förstå och spåra datalinje.
Ett enda inlägg skulle inte göra detta ämne rättvisa. Med risk för att bastardisera idén innebär detta att en federation av dataprodukter och dataplattformsproduktägare skapar och upprätthåller en global uppsättning regler som gäller för alla dataprodukter och gränssnitt. Vad som saknas här är att det måste finnas bestämmelser för högsta ledningen när det kommer till företagsomfattande policyer och mandat; Dehghani härleder det (förhoppningsvis blir hennes bok mer specifik). I huvudsak anger Dehghani vad som sannolikt kommer att vara informell praxis idag, där mycket ad hoc-beslut om styrning redan fattas på lokal nivå.
Federated Computational Governance
Kredit: Thoughtworks
Så bör du prova det här hemma?
Få ämnen har dragit så mycket uppmärksamhet i datavärlden under det senaste året som datanätet. En av triggerna är att i en alltmer molnbaserad värld där applikationer och affärslogik bryts ner till mikrotjänster, varför inte behandla data på samma sätt?
Svaret är lättare sagt än gjort. Till exempel, medan monolitiska system kan vara stela och svårhanterliga, introducerar distribuerade system sina egna komplexiteter, välkomna eller inte. Det finns risk för att nya silos skapas, för att inte tala om kaos, när lokal egenmakt inte är tillräckligt genomtänkt.
Till exempel ska utveckling av datapipelines vara en del av definitionen av en dataprodukt, men när dessa pipelines kan återanvändas någon annanstans måste det finnas bestämmelser för dataproduktteam att dela sin IP. Annars finns det många dubbla ansträngningar. Dehghani uppmanar lag att verka i en federerad miljö, men här är risken att trampa på någon annans gräsmatta.
Att distribuera livscykelhanteringen av data kan vara bemyndigande, men i de flesta organisationer finns det sannolikt många fall där ägandet av data inte är entydigt för scenarier där flera intressentgrupper antingen delar användning eller där data härrör från någon annans data . Dehghani erkänner detta och noterar att domäner vanligtvis får data från flera källor, och i sin tur kan olika domäner duplicera data (och omvandla dem på olika sätt) för egen konsumtion.
Datanät som koncept är pågående arbeten. I sitt inledande inlägg hänvisar Dehghani till ett nyckelsätt för att göra data upptäckbar: genom vad hon kallar “självbeskrivande semantik.” Men hennes beskrivning är kort, vilket indikerar att användning av “välbeskriven syntax” tillsammans med exempeldatauppsättningar och specifikationer för schema är bra utgångspunkter – för dataingenjören, inte affärsanalytikern. Det är en punkt vi skulle vilja se henne i hennes kommande bok.
Ett annat nyckelkrav, för federerad “beräkningsbaserad” styrning, kan vara en munfull att uttala, men det kommer att bli ännu mer av det att implementera, som en titt på diagrammet ovan illustrerar. Att lokalisera beslut så nära källan samtidigt som man globaliserar beslut om interoperabilitet kommer att kräva mycket försök och misstag.
Allt som sagt, det finns goda skäl till varför vi för den här diskussionen. Det finns avbrott med data, och många av problemen är knappast nya. Centraliserad arkitektur, som ett företagsdatalager, datasjö eller datasjöhus, kan inte göra rättvisa i en polyglot-värld. Å andra sidan kan argument föras för datavävsmetoden som hävdar att en mer centraliserad metod för metadatahantering och dataupptäckt kommer att vara effektivare. Det finns också ett fall att göra att en hybrid metod som utnyttjar kraften i enhetlig metadatahantering av dataväven skulle kunna användas som ett logiskt bakplan för domäner att bygga och äga sina dataprodukter.
En annan smärtpunkt är att processerna för att hantera data i varje skede av dess livscykel ofta är osammanhängande, där dataingenjörer eller apputvecklare som bygger pipelines kan skiljas från linjeorganisationerna som data betjänar. Självbetjäning har blivit populärt bland affärsanalytiker för visualisering och för datavetare för att utveckla ML-modeller och flytta dem till produktion. Det finns goda skäl att göra för att bredda detta till att hantera datalivscykeln till team som enligt all logik borde äga datan.
Men låt oss inte gå före oss själva. Det här är väldigt ambitiösa saker. När det gäller att fördela förvaltningen och ägandet av datatillgångar, som tidigare nämnts, ligger djävulen i detaljerna. Och det finns massor av detaljer som fortfarande behöver strykas ut. Vi är ännu inte sålda att sådana nedifrån-och-upp-metoder för att äga data kommer att skala över hela företagets dataområde, och att vi kanske borde sikta mer blygsamt: begränsa nätet till delar av organisationen med relaterade eller ömsesidigt beroende domäner.< /p>
Vi ser flera inlägg där kunder i förtid utropar seger. Men som det här inlägget säger, bara för att din organisation har implementerat ett federerat frågelager eller segmenterat dess datasjöar, gör inte implementeringen till ett datanät. Vid denna tidpunkt bör implementering av ett datanät med all dess distribuerade styrning behandlas som proof of concept.
Big Data
Microsofts SQL Server 2022 rullas ut i privat förhandsvisning EDB släpper lös BigAnimal i molnet Google Cloud Nästa: Mötet med företaget där det bor Microsoft förbättrar sin molndatabas, lager och sjötjänster Data Management | Digital transformation | Robotik | Internet of Things | Innovation | Företagsprogramvara