Microsoft Fabric, kunnuglegt og byltingarkennt

Ef þú hefur misst söguþráðinn í gagnaumsýslulausnum Microsoft, þá gæti þessi lesning hjálpað. Hún byrjar á smá söguskýringu, borar ofan í nokkra lykilþætti Fabric og endar svo með að loka hringnum.

Einu sinni var... on-prem

Þeir sem hafa sýslað með gögn lengur en síðustu fimm til tíu árin muna að einu sinni voru allir gagnagrunnar á vélum sem voru beint eða óbeint á ábyrgð eigenda gagnanna. Það fór svo eftir þroska fyrirtækja hvort sú vél var á borði gagnamannsins eða í hýsingu einhvers staðar. Á þessari vél keyrði oft hinn vinsæli Microsoft SQL Server, stundum með fylgiþjónustum eins og SQL Server Integration Services, SQL Server Analytical Services og SQL Server Reporting Services.

Meðhöndlun gagna var gjarnan útfærð í T-SQL kóða, með Integration Services pökkum, blöndu af hvoru tveggja eða með úrvali lausna frá 3ju aðilum.

SQL Server er row-oriented útfærsla á geymslu gagna og fyrst og fremst hugsaður fyrir OLTP kerfi, t.d. viðskiptalausnir þar sem stöðugt er verið að breyta gögnum. Ef gagnagrunnar eru ekki mjög stórir og vel indexaðir, þá dugar þessi högun sæmilega fyrir vöruhús gagna.

Þegar OLAP kom til sögunnar, þ.e. gögn framreidd á einhverju formi sem er fyrst og fremst til greiningar, kynnti Microsoft til sögunnar OLAP Services, forvera Analytical Services, sem kunni að draga upplýsingar úr vensluðum töflum og hnoða í fjölvíða teninga, og gerði þannig ákveðnar tegundir fyrirspurna, úr greiningartólum sem kunnu að tala við teninga, mjög hraðvirkar.

Eitt af þessum greiningartólum var Excel og hugmyndafræði fjölvíðra teninga passaði ágætlega við pivot töflur sem öðluðust talsverðar vinsældir. Á öðrum áratug þessarar aldar kröfðust pivot töflur sjálfstæðis frá Excel og klufu sig út í sína eigin lausn, og kölluðu sig Power BI. Power BI stal þrumunni frá fjölvíðum teningum með sinni eigin minnislægu gagnavél sem kallast VertiPaq. Með því að setja upp Power BI forritið gátu notendur sótt alls kyns gögn í venslaðar töflur, tengt þau saman og fengið áður óþekkt afköst á einfaldan hátt.

Eins spennandi og þessi nálgun var, þá hentar hún ekki vel fyrir miðlæga stýringu á gagnalíkönum og túlkun gagna. Verklagið var að deila Power BI skrám, sem innihéldu skilgreiningar a líkönum og skýrslum, sækja ný gögn og byrja að greina. Innan 10 mínútna varstu búinn að gera smá breytingu, sem þýddi að nú voru til tvær útgáfur af sömu greiningunni.

Þá kemur Analytical Services aftur til sögunnar og Microsoft bætir VertiPaq gagnagrunnsvélinni við Analytical Services. Gagnalíkön sem eru keyrð í VertiPaq í Analytical Services eru kölluð Tabular Model og byggja á column-oriented geymslu gagna. Fjölvíðu teningarnir eru enn studdir í Analytical Services, en þykja gamaldags. Analytical Services getur einungis stutt aðra af þessum tegundum líkana í hverri uppsetningu.

Skýjalausnir í himinbláu Azure

Við lok fyrsta áratugar þessarar aldar hófst skýjavegferð Microsoft. Hægt en ákveðið hefur skýjahögun tekið yfir í flestum tegundum fyrirtækja og stofnana í stað beinnar fjárfestingar í vélarýmum, eða plássi í gagnaverum, og vélbúnaði. Á sama tíma er orðið fáheyrt að tala um að eiga leyfisskyldan hugbúnað til ótakmarkaðrar notkunar, en í stað þess er greitt fyrir notkun eða áskrift.

Að leysa viðfangsefni í "skýinu" er því orðið fyrsta val og það þarf sterk rök til að réttlæta staðbundinn rekstur. En hvað er átt við með "í skýinu"? Allir vita að það þarf að velja á milli Amazon, Microsoft og Google. Það eitt og sér er risaákvörðun og mótar alla framþróun í framhaldinu. En hvaða þjónustuform er sótt í skýið er einnig stór ákvörðun sem ákvarðar sveigjanleika lausna og flækjustig í notkun og rekstri.

Hvað er þjónustuform? Helstu þrír valkostirnir eru IaaS (Innviðir sem þjónusta), PaaS (Umhverfi sem þjónusta) og SaaS (Hugbúnaður sem þjónusta).

Ókei, gott og blessað, en er þessi grein ekki um meðhöndlun gagna? Jú, en umræða um ólík þjónustuform á gagnameðhöndlunarlausnum Microsoft geta sannarlega leitt til misskilnings og ákvarðana sem geta leitt til mjög ólíkra niðurstaðna, þrátt fyrir að ekki sé augljós munur á forsendum.

Kjarni málsins er sá að gagnameðhöndlunarlausnir sem heita Azure Þetta eða Hitt falla undir PaaS þjónustuformið, sem þýðir að sá sem rekur til dæmis vöruhús gagna ber ábyrgð á að tína til þær lausnir sem hann ætlar að nota fyrir gagngeymslu, gagnameðhöndlun, gagnagreiningu, o.s.frv. Svo þarf að tengja lausnirnar saman og stilla þær.

Azure var ekki einn í skýjunum

Flest öll fyrirtæki sem reka hefðbundin viðskiptakerfi og fjárhagskerfi komast auðveldlega af með að nota hefðbundnar aðferðir við meðhöndlun og greiningu gagna, t.d. byggja vöruhús gagna með SQL Server og tengdum verkfærum. Þær aðferðir duga þó ekki til ef sækja á innsæi í gögn sem eru í einhverjum skilningi erfiðari viðfangs.

Um aldamótin hófu aðferðir kenndar við Big Data að komast í sviðsljósið. Þessar aðferðir eru notaðar til að greina mjög stór gagnasett sem voru í besta falli "semi-structured", helst í næstum rauntíma. Allt eitthvað sem eldri aðferðir réðu illa eða ekki við. Hér á landi voru mjög fáir aðilar sem sáu tækifæri í nýtingu þessara aðferða fyrst um sinn og enn í dag eru margir sem líta svo á (og oft með réttu) að þessarar aðferðir séu óþarflega mikið vélarafl fyrir strandveiðibáta.

En hægt og rólega þróast þessar aðferðir, og allt í einu eru komnar á markaðinn notendavænar lausnir sem henta fleiri og minni aðilum, sem eiga rætur að rekja til Big Data aðferða. Í mörgum tilfellum er undirliggjandi tækni aðgengileg en erfið í útfærslu í open source verkefnum. Þegar tækninni er svo pakkað inn í notendavæn viðmót sem auðvelt er að tengja við fyrirliggjandi umhverfi og gögn, er allt í einu orðin bylting í meðhöndlun gagnanna. Sem dæmi er hægt að nefna DataBricks og Snowflake, sem byggja á sitt hvorri hugmyndafræðinni, en eiga sameiginlega ættfeður.

Hugmyndafræðilegur munur á DataBricks og Snowflake er sá helstur að DataBricks byggir á að keyra Spark fyrirspurnarvél ofan á dreifðar skrár á Delta Lake formi, sem hentar vel fyrir gagnavísindi og flóknar greiningar með Python. Hins vegar er Snowflake upphaflega SQL fyrirspurnarvél sem keyrir á Iceberg gagnageymslu. Með tímanum hefur skörun í eiginleikum lausnanna aukist, en gott er að hafa þessa aðgreiningu í huga, hvort unnið er með Spark greiningarvél eða SQL greiningarvél.

Fabric - afsakið hvað ég er seinn

2023 sér Microsoft markaðinn fyrir notendavænar gagnagreiningarlausnir í skýinu fljúga fram hjá sér á fullri ferð og bregst við með kunnuglegum hætti. Byrjar á að búa til flott vörumerki og framtíðarsýn og selja svo hugmyndina frá fyrsta degi til að grugga vatnið. Sækir það besta úr hugmyndum og tækni sem samkeppnin byggir á, endurvinnur gamlar vörur úr eigin safni og byrjar að henda peningum í vandamálið.

Vörumerkið er Microsoft Fabric, endurunna tæknin er meðal annars Power BI, Azure Data Factory, SQL Server og Azure Synapse Analytics, tækni sem er sótt annað er t.d. Parquet skráarsniðið og Delta table metadata lagið. Síðustu tvö árin hefur verið hröð þróun í Fabric, en við fyrstu sýn er ekki endilega augljóst hvað er undir þessari regnhlíf, hvernig hún skarast við núverandi lausnir í Azure og hvernig Microsoft gagnalandslagið muni líta út eftir ár eða svo.

Grundvallarmunurinn á Microsoft Fabric og (gagnalausnum í) Microsoft Azure, er þjónustuformið. Azure er PaaS þar sem tíndar eru til lausnir sem á að nota, Fabric er SaaS þar sem búið er að setja saman í pakka allt sem þarf til að leysa viðfangsefnið. Þetta auðveldar uppsetningu og rekstur en takmarkar sveigjanleika.

Fabric SaaS lausnin er tvíeggja tvíburi Power BI SaaS lausnarinnar. Þær byggja á sömu hugmyndum, tengjast vel og er ætlað að leysa sitt hvora hliðina á gagnagreiningarpeningnum, Fabric safnar, geymir og umbreytir, Power BI birtir og greinir.

Þróunin á Fabric er mjög hröð, bæði lausninni sjálfri, en líka staðsetningu á markaði og áhrifum á tilteknar lausnir í Azure. Hér eru nokkur dæmi um áhrif þess að breyta Azure í Fabric í nöfnum lausna og aðferða, og það svigrúm sem þessi breyting skapar fyrir ólíkar túlkanir.

Dæmi 1: Ef skoðað er hvað þarf að læra sem undirbúning fyrir að geta kallað sig Microsoft Data Engineer er vísað á kennsluplan fyrir Azure Data Engineer Associate vottun. Þetta kennsluplan á að enda með prófinu DP-203 sem veitir réttinn til að kalla sig Microsoft Certified: Azure Data Engineer Associate. Þarna er kennt á hin ýmsu Azure verkfæri. En þetta próf og tilheyrandi vottun er búið að úrelda án frekari skýringa. Í yfirliti yfir virk próf og vottanir er hins vegar DP-700, sem er Fabric Data Engineer Associate vottun sem vísar á annað kennsluplan með Fabric í forgrunni. Hvað er hægt að lesa úr þessu? Ekki gott að segja, en þó að minnsta kosti að skilaboðin frá Microsoft eru ekki skýr. Verður hægt að fá vottun sem Data Engineer í Azure PaaS umhverfi? Eða er það orðið afgangsstærð og verður reynt að koma öllu og öllum í Fabric SaaS umhverfi?

Dæmi 2: Azure Data Factory og Data Factory í Microsoft Fabric (líka kallað Fabric Data Factory). Á lærdómsvef Microsoft má finna mikið efni um Data Factory... en hvaða Data Factory? Á vefnum kemur fram að hægt er að færa SSIS pakka beint (lift and shift) inn í Azure Data Factory. Þar kemur líka fram að hægt er að flytja vinnslur úr Azure Data Factory inn í Fabric Data Factory, en þá er um að ræða migration og huga þarf að nokkrum grundvallaratriðum sem munar í arkitektúr ADF og FDF. Úr þessu má lesa að þó að viðmót og notendaupplifun af notkun ADF og FDF sé sambærileg þá er það sem gerist undir húddinu og virkniþekja ólík. Í texta um virkniþekju er sett fram sú staðhæfing að FDF sé næsta kynslóð af ADF og þá væntanlega arftaki, sem bendir til að dagar (já eða ár) ADF séu taldir.

Dæmi 3: Azure SQL Database og SQL Database í Fabric (líka kallað Fabric SQL Database). Þetta er mögulega skýrasta dæmið um að skoða þurfi Fabric sem einhvers konar yfirtöku á gagnameðhöndlunarhluta Azure, frekar en bara SaaS þjónustu fyrir greiningu gagna. Fabric SQL Database er "byggður á" Azure SQL Database og báðir þjónarnir eru fyrir OLTP gögn (transactional), á meðan Fabric er í almennt hugsað sem greiningarumhverfi fyrir gögn, sem sagt OLAP. Þarna er sem sagt búið að bæta "hefðbundnum" vensluðum gagnagrunni inn í Fabric vöndulinn.

Disclaimer: Vefsíður sem vísað er í hér að ofan eru í hraðri þróun og stundum í mótsögn hver við aðra og því afar líklegt að þær muni breytast eða hverfa.

Fabric vex upp úr vatninu eina

Dæmin hér að ofan gefa sterka vísbendingu um að Fabric sé eitthvað annað og meira (og minna) en það sem hægt er að púsla saman úr Azure lausnum. Hér að neðan verður samt reynt að halda umfjölluninni við lykilatriði í Fabric sem greiningarlausn, en ekki spá of mikið í samhengi við Azure.

Fabric, líkt og DataBricks, Snowflake og fleiri sambærilegar lausnir aðskilja geymslu gagna og úrvinnslu gagna. Það sem kann að koma á óvart er hversu ákveðin/einsleit nálgun varðandi geymslu gagna er í Fabric. Það er bara ein ríkis gagnageymsla, Microsoft OneLake.

OneLake er sem sagt datalake útfærsla Microsoft. Hver Fabric tenant (t.d. eitt fyrirtæki sem notar Fabric) hefur aðgang að einu og aðeins einu OneLake. Hægt er að sjá fyrir sér samanburð við OneDrive. Hugsunin er að öll gögn séu á einum stað og mismunandi greiningarvélar tengist allar sömu gögnunum. Skipulagningu og aðgangsstýringu er svo hægt að útfæra með "workspace" sem dregur saman ólíkar auðlindir í eitt vinnusvæði.

Þetta er að sjálfsögðu ekki svona einfalt, hvað með SQL Database for Fabric og Cosmos DB for Fabric? Jú sjáðu til, gögn í þessum grunnum eru "spegluð" sjálfkrafa yfir í OneLake. Síðan er ætlast til að greining og frekari úrvinnsla eigi sér stað í Fabric og Power BI með því að horfa á gögnin í OneLake... Þetta er að sjálfsögðu ekki svona einfalt, en meira um það síðar.

OneLake er útfært í Azure Data Lake Storage (ADLS) Gen2 og getur geymt skrár á hvaða formi sem er. Fjöldi lausna, bæði frá Microsoft og öðrum, getur notað OneLake sem gagnageymslu. Og á hinn bóginn er hægt að skilgreina flýtileiðir (shortcut) úr OneLake yfir í önnur OneLake (hjá öðrum tenants), S3, Dataverse og fleira. Möppur í öðrum gagnageymslur birtast þannig sem möppur í því OneLake sem skilgreinir flýtileiðina.

Með nokkurri einföldun má líkja OneLake við skráasafn á nettengdu drifi. Og þó við getum geymt skrár á hvaða formi sem er þá henta þau misvel fyrir geymslu og greiningu gagna.

Húsin á vatnsbakkanum

Við höldum okkur við mishjálplegar myndlíkingar, því hvernig er betra að tengja saman vöruhús gagna og datalake en með húsi við vatnið, Microsoft Fabric Lakehouse er því næsti viðkomustaður.

Lakehouse gerir okkur auðvelt að vinna með skrár af ákveðinni gerð eins og töflur í gagnagrunni. Hægt er að horfa á tiltekna tegund og samhengi skráa annað hvort sem töflur eða sem skráastrúktúr/skrár. Með Lakehouse fylgir líka SQL greiningarvél, svokallaður Lakehouse SQL analysis endpoint, sem gerir auðvelt að keyra T-SQL fyrirspurnir á gögnin/skrárnar. Þessar fyrirspurnir geta ekki bætt við eða breytt, eru bara til að lesa.

Fabric Lakehouse er (miðað við lýsingar sem eiga við um Azure Synapse Analytics) byggt á Delta Lake verkefninu sem er undir hatti The Linux Foundation. Delta Lake tengist núorðið fleiri sambærilegum "vistkerfum" (Iceberg og Hudi). Undirliggjandi í Delta Lake eru svokallaðar Delta Lake tables (líka kallaðar Delta tables eða tables in Delta format). Delta tables er hægt að líta á sem hjúp eða viðbótarvirkni við það geyma gögn í skrám á Apache Parquet formi.

Rekjum okkur til baka upp þessa keðju.

Parquet skráarsniðið er hannað til að geyma dreifð gögn í dálkauppröðun (column-oriented). Það er skilvirk leið til að geyma og sækja gögn til greiningar. Hægt er að kóða svæði í gögnunum á formi sem er viðeigandi fyrir viðkomandi gagnatýpu. Parquet skrár innihalda lýsigögn um innihaldið í skránni til að auðvelda bestun fyrirspurna. Dæmigerð stærð á Parquet skrá er 128 MB til 1 GB. Parquet skrár sem lifa saman í möppu mynda saman gagnasett. Uppröðun gagna í skrár og röðun gagna innan skrár getur haft töluverð áhrif á afköst og kostnað við fyrirspurnir í gögnin. Þetta skráarsnið er hannað til að vinna með stór gagnasett í dreifðri vinnslu og kallar á sérstök verkfæri til að vinna beint á það.

Delta Lake og undirliggjandi Delta tables bæta við þáttum sem meðal annars gera okkur kleift að ganga um gagnasafn í Parquet skrám að miklu leyti eins og töflu í vensluðum gagnagrunni. Meðal annars ACID fyrir gagnaheilindi, insert, update, delete og merge aðgerðir, skilyrt skema, aukin stjórn á röðun í undirliggjandi skrám, audit loggun, bættur stuðningur við streymandi gögn og hið stórskemmtilega tímaflakk, sem gerir kleift að skoða hvernig tafla leit út á tilteknum tímapunkti. Þetta er útfært með möppum og skrám sem eru settar í nágrenni við sjálfar gagnaskrárnar. Í sinni einföldustu mynd er hægt að hugsa um þessar viðbótar skrár sem færslulogga.

LakeHouse er svo útfærslan á þeirri virkni sem þarf til að lesa og skrifa gagnaskrár og lýsigagnaskrár samkvæmt ofan sögðu.

Greiningarvélar og gagnaþjónustur

Eins og áður segir og samkvæmt Microsoft eiga öll gögn að vera lent í OneLake áður en byrjað er að greina þau og möndla meira með þau. Það segir auðvitað ekki mikið. Í raun bara, gögn eiga að vera á diski. Það er auðvelt að mistúlka þetta þannig að öll gögn eigi að vera á Parquet/Delta table formi. Það er þó ekki svo, því Microsoft hefur sett fram leiðbeiningar um hvernig velja eigi viðeigandi "gagnaþjónustu" eftir eðli verkefnis, þ.e. þann hugbúnað sem túlkar og viðheldur gögnunum í OneLake. Stutta útgáfan er cirka svona:

Jafnframt er tekið fram í öllu tilvikum að "Data available in OneLake in open table format by default". Miðað við skjölun á SQL database og Cosmos DB erOneLake aðgengi að gögnum úr þeim þjónustum útfært með speglun gagna.

Þessi lýsing er mögulega sterkasta vísbendingin hingað til um að Fabric verði alfa og ómega í gagnameðhöndlunarlausnum Microsoft, en ekki afmarkað við hefðbundnar gagnagreiningar og tengingu við Power BI.

Vöruhús við vatnið

Við höfum lýst Lakehouse, og það lofaði góðu fyrir vöruhús gagna, en í töflunni hér að ofan er talað um Fabric Data Warehouse, hvað er það þá? Til að átta sig á því er rétt að kynna til sögunnar Azure Synapse Analytics. Kannski er einfaldast að lýsa Synapse sem PaaS forvera Fabric (sem er SaaS). Synapse er fjölþætt greiningarumhverfi og virkniþekjan mjög lík greiningarvélunum í Fabric, skoðum upptalningu á nokkrum sambærilegum þáttum í Synapse og Fabric.

Efstu þrjú atriðin eru dæmi um ólíkar greiningarvélar sem vinna ofan á gögnum í OneLake. SQL Analytics Endpoint er búið að minnast á, sem léttan T-SQL lesaðgang ofan á LakeHouse.

Fabric Data Warehouse (eða bara Fabric Warehouse) er hannað til að líta út nákvæmlega eins og SQL Server gagnvart notendum, en klýfur gagnageymsluna frá greiningarvélinni á bak við tjöldin. Það þýðir meðal annars fullan T-SQL stuðning, með stefjum, CRUD aðgerðum og skema meðhöndlun. Undirliggjandi skrár og möppur í LakeHouse er ekki sýnilegar, heldur eru þær eingöngu túlkaðar og meðhöndlaðar eins og töflur. Hægt er að láta fyrirspurnir tengja saman gögn yfir flýtileiðir (shortcut), sem geta verið í öðrum OneLake eða í öðru skýjaumhverfi.

Rétt er að undirstrika mikilvægi þessarar lýsingar. þessi virkni er alveg mögnuð og kjarni málsins í að nútímavæða vöruhús gagna sem byggja á hefðbundnum SQL Server.

Út fyrir SQL rammann

Hér að ofan var upptalning á því hvaða Fabric lausn henti best eftir viðfangsefni. Glöggir lesendur hafa kannski tekið eftir valkostinum Lakehouse í þeirri töflu fyrir Big Data og Data Engineering. Þetta er tekið beint af vefsíðu Microsoft. Það sem raunverulega er átt við er greiningarvél sem byggir á Apache Spark. Hvað þetta endar með að kallast í markaðssetningu Microsoft virðist eitthvað á reiki, kannski bara Fabric Spark. Þessi vél er það sem kallast á nútíma slangri OG. Hún er þróuð af þeim sem bjuggu til DataBricks og er kjarninn í fjölmörgum Big Data greiningarumhverfum. Algengast virðist vera að nota Spark með Python klösum. Spark notar meðal annars þá gagnahögun sem OneLake byggir á.

Spark á skilið sýna eigin grein, kannski verður hún skrifuð siðar.

Loks er rétt að nefna lausnirnar tvær sem að því er best séð byggja á öðrum gagnagrunnum en OneLake við greiningar. Gögn eru hins vegar líka spegluð í OneLake. Annars vegar Eventhouse sem er ætlað að vinna með gagnastrauma sem hafa ekki skilgreint upphaf eða endi. Hér er hægt að nefna Kafka sem skilda lausn. Til að gera fyrirspurnir í streymandi gögn þegar þau flæða fram hjá þarf að beita sérhæfðum aðferðum til að meðhöndla t.d. tímaglugga. Eventhouse vinnur með gögn í KQL grunni, þar sem fyrirspurnarmálið KQL er notað.

Hin sérhæfða greiningarlausnin er Cosmos DB. Undirliggjandi eru nokkur ólík módel, fyrir NoSQL, vektor fyrirspurnir, o.fl. Hér eru staðsettar þær tegundir gagnamódela sem ekki passa annars staðar.

Eldri tvíburinn, Power BI

Ein leið til að sjá samhengi milli Fabric og Power BI er að hugsa um Fabric sem þau 90% ísjakans sem eru ofan í sjónum og Power BI það sem stendur upp úr. Í Fabric á að nálgast gögn úr grunnkerfum, umbreyta þeim og geyma, framkvæma flóknari greiningar, stýra aðgangi, vakta gæði, o.fl. Í Power BI eru síðustu skrefin tekin, gögn og niðurstöður settar skilmerkilega fram og boðið upp á sjálfsafgreiðslu upp að einhverju marki.

Lykilatriði í samþættingu Fabric og Power BI er svokallað Direct Lake. Direct Lake er á vissan hátt næsta kynslóð af SSAS (Analytical þjónustan í SQL Server) en samt bara forritaskilin og greiningarvélin. Direct Lake lítur eins út og SSAS séð frá sjónarhorni verkfæra eins og Power BI. Það býður upp á "semantic model", skilur DAX forritunarmálið og fleira. En geymsla og uppfærsla gagna er gjörbreytt og byggir á OneLake aðferðum. Þannig er hægt að fyrirspurnir á gögn í nærri rauntíma beint ofan á OneLake og ekki þarf reglulega að uppfæra gagnamódel sem liggja í minni á bakvið SSAS þjónustu. Þetta gerir jafnframt kleift að vinna með gagnasett af annarri stærðargráðu en hægt hefur verið í SSAS.

Að færa hefðbundið vöruhús yfir í nútímann

Það er í mörgum tilfellum skýr samsvörun á milli þátta í Fabric og þátta í hefðbundnu SQL Server eða Azure SQL Database umhverfi.

Fabric (Data) Warehouse er í hlutverki fyrirspurnarvélarinnar í SQL Server. OneLake er tekur yfir gagnageymsluhlutann í SQL Server. Direct Lake tekur við keflinu af SQL Server Analytical Services. Power BI stendur sterkara eftir (caveat: Direct Lake styður ekki alla virkni sem er í SSAS). Fabric Data Factory tekur við af Azure Data Factory sem áður leysti af hólmi SQL Server Integration Services (caveat: beinn flutningur á SSIS pökkum inn í ADF er ekki mögulegur). Scheduling og Orchestration getur farið fram í ADF eða öðrum verkfærum.

Stóra stökkið, tæknilega og heimspekilega, er sú áhersla sem er lögð á OneLake og undirliggjandi tækni. Notendur geta valið að setja kíkinn fyrir blinda augað og spá ekkert í það, eða tekið breytingunni fagnandi og notað gögnin á formi sem hentar verkfærum eins og Spark.

Þeir sem hafa verið lengi í bransanum fá kannski smá hland fyrir hjartað og vilja leyfa öðrum að hjálpa Microsoft að hrista hrollinn úr Fabric, en það er sannarlega full ástæða til að setja sig strax inn í þessa lausn og skoða hvað hún getur gert fyrir þig, núna eða í framtíðinni.

Kjarni málsins

Breytingarnar sem Microsoft boðar með Fabric verður að lýsa sem byltingu. Rauði þráðurinn er kannski sá, að viðmót notenda, forritara og greinenda þar með talið, getur haldist óbreytt ef þess er óskað. Hægt er að vinna með gögn eins og þau séu í vel skilgreindum töflum í vensluðum gagnagrunni með hinu gamalreynda T-SQL forritunarmáli. Hægt verður að nota Power BI með tiltölulega litlum breytingum. En jafnframt verður auðveldara að nota Python og tilheyrandi verkfæri, vinna með rauntímagögn og margt fleira.

Byltingin liggur í gagnamódelinu og því að aðskilja greiningarvélar frá gögnunum. þetta kallar á mikla vinnu og hugvitssemi hjá Microsoft, t.d. í að gera örar breytingar á gögnum í OneLake praktískar. En gleðin er að kaupendur Fabric þjónustunnar eiga ekki að þurfa að spá í það. Spurningar um hvernig á að skipta upp og raða gögnum í Parquet skrár eru teknar af borðinu.

Svo er annað mál hversu langt þessi þróun er komin og hversu vel hefur tekist til. Trúlega eru ákveðnir þættir tilbúnir til notkunar án þess að tekin sé mikil áhætta, en á hinn bóginn eru væntanlega einhver atriði sem ekki virka eins og til er ætlast, jafnvel bregðast þegar síst skyldi. Þetta er jú Microsoft, ekki satt.