„Dremio“: paprastesnė ir greitesnė duomenų analizė

Jacques Nadeau yra „Dremio“ CTO direktorius ir vienas iš įkūrėjų.

Dabar puikus laikas būti kūrėju. Per pastarąjį dešimtmetį sprendimai dėl technologijų perėjo iš posėdžių salės į naujoviškus kūrėjus, kurie kuria atvirą šaltinį ir sprendimus priima atsižvelgdami į pagrindinio projekto nuopelnus, o ne į pardavėjo teikiamus komercinius santykius. Atsirado nauji projektai, kurių pagrindinis tikslas yra padaryti kūrėjus produktyvesnius ir kuriuos lengviau valdyti bei išplėsti. Tai galioja praktiškai kiekvienam technologijos kamino sluoksniui. Rezultatas yra tas, kad kūrėjai šiandien turi beveik neribotas galimybes tyrinėti naujas technologijas, naujas architektūras ir naujus diegimo modelius.

Ypač žvelgiant į duomenų sluoksnį, „NoSQL“ sistemos, tokios kaip „MongoDB“, „Elasticsearch“ ir „Cassandra“, pastūmėjo operatyvių programų lankstumą, mastelį ir našumą, kurių kiekviena turi skirtingą duomenų modelį ir požiūrį į schemą. Kelyje daugelis kūrėjų komandų perėjo prie mikro paslaugų modelio, skleisdami programos duomenis daugelyje skirtingų pagrindinių sistemų.

Kalbant apie analizę, seni ir nauji duomenų šaltiniai pateko į tradicinių duomenų saugyklų ir duomenų ežerų derinį, vieni - „Hadoop“, kiti - „Amazon S3“. O „Kafka“ duomenų perdavimo platformos pakilimas sukuria visiškai kitokį mąstymo būdą apie duomenų judėjimą ir judančių duomenų analizę.

Turint tiek daug skirtingų technologijų ir pagrindinių formatų duomenis, sudėtinga analizuoti šiuolaikinius duomenis. BI ir analizės įrankiai, tokie kaip „Tableau“, „Power BI“, „R“, „Python“ ir mašininio mokymosi modeliai, buvo sukurti pasauliui, kuriame duomenys gyvena vienoje didelio našumo reliacinėje duomenų bazėje. Be to, šių įrankių vartotojai - verslo analitikai, duomenų mokslininkai ir mašininio mokymosi modeliai - nori galimybės savarankiškai pasiekti, tyrinėti ir analizuoti duomenis, nepriklausydami nuo IT.

Pristatome „Dremio“ duomenų audinį

BI įrankiai, duomenų mokslo sistemos ir mašininio mokymosi modeliai geriausiai veikia, kai duomenys gyvena vienoje didelio našumo reliacinėje duomenų bazėje. Deja, šiandien duomenys ten negyvena. Todėl IT neturi kito pasirinkimo, kaip tik užpildyti šią spragą derinant individualų ETL kūrimą ir patentuotus produktus. Daugelyje įmonių analizės rinkinys apima šiuos sluoksnius:

• Duomenų išdėstymas. Duomenys iš įvairių operatyvinių duomenų bazių perkeliami į vieną sustojimo sritį, pvz., „Hadoop“ grupę arba debesies saugojimo paslaugą (pvz., „Amazon S3“).
• Duomenų saugyklos. Nors SQL užklausas įmanoma vykdyti tiesiogiai „Hadoop“ ir debesies saugyklose, šios sistemos tiesiog nėra skirtos interaktyviam našumui užtikrinti. Todėl duomenų pogrupis paprastai įkeliamas į reliacinių duomenų sandėlį arba MPP duomenų bazę.
• Kubai, kaupimo lentelės ir BI ištraukos. Norint užtikrinti interaktyvų didelių duomenų rinkinių našumą, duomenys turi būti iš anksto kaupiami ir (arba) indeksuojami kuriant kubus OLAP sistemoje arba materializuotose kaupimo lentelėse duomenų saugykloje.

Ši daugiasluoksnė architektūra kelia daug iššūkių. Jis yra sudėtingas, trapus ir lėtas ir sukuria aplinką, kurioje duomenų vartotojai yra visiškai priklausomi nuo IT.

„Dremio“ pristato naują duomenų analizės pakopą, kurią vadiname savitarnos duomenų audiniu. „Dremio“ yra atviro kodo projektas, leidžiantis verslo analitikams ir duomenų mokslininkams bet kada ištirti ir išanalizuoti bet kokius duomenis, neatsižvelgiant į jų vietą, dydį ar struktūrą. „Dremio“ sujungia išplėstinę architektūrą su stulpelių vykdymu ir pagreitėjimu, kad pasiektų interaktyvų bet kokio duomenų kiekio našumą, tuo pačiu leidžiant IT, duomenų mokslininkams ir verslo analitikams sklandžiai formuoti duomenis pagal verslo poreikius.

Sukurta ant „Apache“ rodyklės, „Apache“ parketo ir „Apache Calcite“

„Dremio“ naudoja didelio našumo stulpelių saugojimą ir vykdymą, kurį teikia „Apache Arrow“ (atminties stulpelis) ir „Apache Parquet“ (stulpelio diske). „Dremio“ taip pat naudoja „Apache Calcite“ SQL analizavimui ir užklausų optimizavimui, remdamasis tomis pačiomis bibliotekomis, kaip ir daugelis kitų SQL pagrįstų variklių, tokių kaip „Apache Hive“.

„Apache Arrow“ yra atviro kodo projektas, įgalinantis atminties duomenų stulpelių apdorojimą ir keitimąsi jais. „Arrow“ sukūrė „Dremio“. Jame yra įvairių bendrovių, įskaitant „Cloudera“, „Databricks“, „Hortonworks“, „Intel“, „MapR“ ir „Two Sigma“, įsipareigojimus.

„Dremio“ yra pirmasis vykdymo variklis, pastatytas iš pagrindų „Apache Arrow“. Viduje atmintyje esantys duomenys yra saugomi „Arrow“ formatu, ir netrukus atsiras API, kuri grąžins užklausos rezultatus kaip „Arrow“ atminties buferius.

„Arrow“ taip pat apėmė įvairūs kiti projektai. Tarp šių projektų yra „Python“ („Pandas“) ir „R“, leidžiantys duomenų mokslininkams efektyviau dirbti su duomenimis. Pavyzdžiui, Wesas McKinney, populiarios „Pandas“ bibliotekos kūrėjas, neseniai pademonstravo, kaip „Arrow“ leidžia „Python“ vartotojams nuskaityti duomenis į „Pandas“ daugiau nei 10 GB / s.

Kaip „Dremio“ įgalina savitarnos duomenis

Be galimybės dirbti interaktyviai su savo duomenų rinkiniais, duomenų inžinieriams, verslo analitikams ir duomenų mokslininkams taip pat reikalingas būdas sutvarkyti duomenis taip, kad jie būtų tinkami konkretaus projekto poreikiams. Tai yra esminis perėjimas nuo į IT orientuoto modelio, kai duomenų vartotojai inicijuoja duomenų rinkinio užklausą ir laukia, kol IT įvykdys jų prašymą po kelių savaičių ar mėnesių. „Dremio“ įgalina savitarnos modelį, kai duomenų vartotojai naudojasi „Dremio“ duomenų apdorojimo galimybėmis, kad galėtų drauge atrasti, kuruoti, spartinti ir dalytis duomenimis, nepasikliaudami IT.

Visas šias galimybes galite pasiekti naudodamiesi modernia, intuityvia žiniatinklio sąsaja:

• Atrasti. „Dremio“ apima vieningą duomenų katalogą, kuriame vartotojai gali atrasti ir tyrinėti fizinius ir virtualius duomenų rinkinius. Duomenų katalogas automatiškai atnaujinamas, kai pridedami nauji duomenų šaltiniai ir vystosi duomenų šaltiniai ir virtualūs duomenų rinkiniai. Visi metaduomenys yra indeksuojami didelio našumo, ieškomose rodyklėse ir yra rodomi vartotojams visoje „Dremio“ sąsajoje.
• Kuruoti. „Dremio“ leidžia vartotojams tvarkyti duomenis kuriant virtualius duomenų rinkinius. Palaikomos įvairios taškų ir paspaudimų transformacijos, o patyrę vartotojai gali naudoti SQL sintaksę, kad apibrėžtų sudėtingesnes transformacijas. Vykdant užklausas sistemoje, „Dremio“ sužino apie duomenis, leidžiančius rekomenduoti įvairias transformacijas, tokias kaip sujungimai ir duomenų tipo konversijos.
• „Dremio“ gali pagreitinti duomenų rinkinius iki 1000 kartų viršydama šaltinio sistemos našumą. Vartotojai gali balsuoti už duomenų rinkinius, kurie, jų manymu, turėtų būti greitesni, o Dremio euristika atsižvelgs į šiuos balsus nustatydama, kuriuos duomenų rinkinius paspartinti. Pasirinktinai sistemos administratoriai gali rankiniu būdu nustatyti, kuriuos duomenų rinkinius paspartinti.
• „Dremio“ suteikia vartotojams galimybę saugiai dalytis duomenimis su kitais vartotojais ir grupėmis. Šiame modelyje vartotojų grupė gali bendradarbiauti kuriant virtualų duomenų rinkinį, kuris bus naudojamas konkrečiam analitiniam darbui. Arba vartotojai gali įkelti savo duomenis, pvz., „Excel“ skaičiuokles, kad prisijungtų prie kitų duomenų rinkinių iš įmonės katalogo. Virtualių duomenų rinkinių kūrėjai gali nustatyti, kurie vartotojai gali pateikti užklausą ar redaguoti savo virtualius duomenų rinkinius. Tai panašu į „Google“ dokumentus jūsų duomenims.

Kaip veikia „Dremio“ duomenų pagreitis

„Dremio“ naudoja labai optimizuotą fizinį šaltinių duomenų vaizdavimą, vadinamą „Data Reflections“. „Reflection Store“ gali gyventi HDFS, „MapR-FS“, debesų saugyklose, tokiose kaip S3, arba tiesiogiai prijungtose saugyklose (DAS). „Reflection Store“ dydis gali viršyti fizinės atminties dydį. Ši architektūra leidžia „Dremio“ paspartinti daugiau duomenų už mažesnę kainą, todėl kur kas didesnis talpyklos įvykių santykis, palyginti su tradicinėmis tik atminties architektūromis. Duomenų atspindžius užklausos metu automatiškai naudoja sąnaudomis pagrįstas optimizatorius.

Duomenų atspindžiai galutiniams vartotojams nematomi. Skirtingai nuo OLAP kubų, kaupimo lentelių ir BI ištraukų, vartotojas tiesiogiai neprisijungia prie duomenų atspindžio. Vietoj to, vartotojai pateikia užklausas pagal loginį modelį, o „Dremio“ optimizavimo priemonė automatiškai pagreitina užklausą, pasinaudodama duomenų atspindžiais, kurie yra tinkami užklausai, remiantis optimizatoriaus išlaidų analize.

Kai optimizatorius negali pagreitinti užklausos, „Dremio“ naudoja savo didelio našumo paskirstytą vykdymo variklį, pasitelkdamas stulpelinį atminties apdorojimą (naudodamas „Apache“ rodyklę) ir išplėstinius nuspaudimus į pagrindinius duomenų šaltinius (dirbdamas su RDBMS arba NoSQL šaltiniais).

Kaip „Dremio“ tvarko SQL užklausas

Kliento programos išduoda SQL užklausas „Dremio“ per ODBC, JDBC ar REST. Užklausa gali apimti vieną ar daugiau duomenų rinkinių, kurie gali būti skirtinguose duomenų šaltiniuose. Pavyzdžiui, užklausa gali būti „Hive“ lentos, „Elasticsearch“ ir kelių „Oracle“ lentelių sujungimas.

„Dremio“ naudoja du pagrindinius metodus, kad sumažintų užklausai reikalingą apdorojimo kiekį:

• Atsispaudimai į pagrindinį duomenų šaltinį. Optimizatorius atsižvelgs į pagrindinio duomenų šaltinio galimybes ir santykines išlaidas. Tada jis sugeneruos planą, kuris atliks užklausos etapus šaltinyje arba paskirstytoje „Dremio“ vykdymo aplinkoje, kad būtų pasiektas kuo efektyvesnis bendras planas.
• Pagreitis per duomenų atspindžius. Optimizatorius naudos duomenų atspindžius užklausos dalims, kai tai sudarys efektyviausią bendrą planą. Daugeliu atvejų visą užklausą galima aptarnauti iš duomenų atspindžių, nes jos gali būti didesnėmis eilėmis efektyvesnės nei užklausų apdorojimas pagrindiniame duomenų šaltinyje.

Užklausos nuleidimai

„Dremio“ gali perduoti apdorojimą į reliacinius ir nereliacinius duomenų šaltinius. Nesusiję duomenų šaltiniai paprastai nepalaiko SQL ir turi ribotas vykdymo galimybes. Pvz., Failų sistema negali taikyti predikatų ar agregatų. Kita vertus, „MongoDB“ gali taikyti predikatus ir agregacijas, tačiau nepalaiko visų prisijungimų. „Dremio“ optimizavimo priemonė supranta kiekvieno duomenų šaltinio galimybes. Kai tai bus efektyviausia, „Dremio“ persiųs kuo daugiau užklausų į pagrindinį šaltinį, o likusią dalį atliks savo paskirstytojo vykdymo variklyje.

Operatyvinių duomenų bazių iškrovimas

Dauguma operatyvinių duomenų bazių yra skirtos rašymui optimizuotiems darbo krūviams. Be to, šie diegimai turi būti nukreipti į griežtus SLA, nes bet koks prastovos laikas arba pablogėjęs našumas gali reikšmingai paveikti verslą. Todėl operacinės sistemos dažnai yra izoliuotos nuo analitinių užklausų apdorojimo. Tokiais atvejais „Dremio“ gali atlikti analitines užklausas naudodamas duomenų atspindžius, kurie užtikrina kuo efektyvesnį užklausų apdorojimą, tuo pačiu sumažinant poveikį operacinei sistemai. Duomenų atspindžiai yra periodiškai atnaujinami pagal strategijas, kurias galima sukonfigūruoti lentelėje pagal lentelę.

Užklausos vykdymo etapai

Užklausos trukmė apima šiuos etapus:

1. Klientas pateikia užklausą koordinatoriui per ODBC / JDBC / REST
2. Planavimas
1. Koordinatorius analizuoja užklausą pagal universalų Dremio santykių modelį
2. Koordinatorius atsižvelgia į turimą duomenų šaltinių statistiką, kad galėtų sukurti užklausos planą, taip pat į šaltinio funkcinius gebėjimus
3. Koordinatorius perrašo užklausos planą, kurį reikia naudoti
1. - turimus duomenų atspindžius, atsižvelgiant į duomenų atspindžių užsakymą, skaidymą ir paskirstymą bei
2. turimas duomenų šaltinio galimybes
4. Vykdymas

1. Vykdytojai lygiagrečiai skaito duomenis į „Arrow“ buferius iš šaltinių

1. Vykdytojai vykdo perrašytą užklausos planą.
2. Vienas vykdytojas sujungia vieno ar daugiau vykdytojų rezultatus ir perduoda galutinius rezultatus koordinatoriui
1. Klientas gauna rezultatus iš koordinatoriaus

Atminkite, kad duomenys gali būti gaunami iš duomenų atspindžių arba pagrindinio (-ių) duomenų šaltinio (-ių). Skaitant iš duomenų šaltinio, vykdytojas pateikia savąsias užklausas (pvz., „MongoDB MQL“, „Elasticsearch Query DSL“, „Microsoft Transact-SQL“), kurias planavimo etape nustatė optimizatorius.

Visos duomenų operacijos atliekamos vykdytojo mazge, leidžiančios sistemai pritaikyti mastelį daugeliui vienu metu esančių klientų naudojant tik kelis koordinatoriaus mazgus.

Užklausos pavyzdys

Norėdami iliustruoti, kaip „Data Fabric“ tinka jūsų duomenų architektūrai, atidžiau panagrinėkime SQL užklausos vykdymą šaltinyje, kuris nepalaiko SQL.

Vienas iš populiariausių šiuolaikinių duomenų šaltinių yra „Elasticsearch“. „Elasticsearch“ gali patikti daug, tačiau analizės požiūriu jis nepalaiko SQL (įskaitant SQL prisijungimus). Tai reiškia, kad tokie įrankiai kaip „Tableau“ ir „Excel“ negali būti naudojami analizuojant duomenų, gautų iš šiame duomenų saugykloje sukurtų programų, duomenis. Yra vizualizacijos projektas „Kibana“, populiarus „Elasticsearch“, tačiau „Kibana“ skirtas kūrėjams. Tai tikrai nėra skirta verslo vartotojams.

„Dremio“ leidžia lengvai analizuoti „Elasticsearch“ duomenis naudojant bet kurį SQL pagrįstą įrankį, įskaitant „Tableau“. Paimkime, pavyzdžiui, šią SQL užklausą „Yelp“ verslo duomenims, kurie saugomi JSON:

PASIRINKITE valstiją, miestą, pavadinimą, atsiliepimų skaičių

IŠ elastingos.pagalbos.darbo

KUR

būsena NĖRA („TX“, „UT“, „NM“, „NJ“) IR

apžvalgos_skaičius> 100

UŽSAKYTI pagal atsiliepimo_skaičius DESC, valstija, miestas

10 RIBOS

„Dremio“ surenka užklausą į išraišką, kurią „Elasticsearch“ gali apdoroti: