Dremio: Yksinkertainen ja nopea data-analyysi

Jacques Nadeau on Dremion teknologiajohtaja ja perustaja.

Nyt on hyvä aika olla kehittäjä. Viimeisen vuosikymmenen aikana tekniikkaa koskevat päätökset ovat siirtyneet neuvotteluhuoneesta innovatiivisille kehittäjille, jotka rakentavat avoimen lähdekoodin kanssa ja tekevät päätöksiä taustalla olevan projektin ansioiden eikä toimittajan tarjoamien kaupallisten suhteiden perusteella. On syntynyt uusia hankkeita, jotka keskittyvät kehittäjien tuottavuuden parantamiseen ja joita on helpompi hallita ja laajentaa. Tämä pätee melkein jokaiseen tekniikkapinon kerrokseen. Tuloksena on, että kehittäjillä on nykyään lähes rajattomat mahdollisuudet tutkia uutta tekniikkaa, uusia arkkitehtuureja ja uusia käyttöönottomalleja.

Tarkasteltaessa erityisesti tietokerrosta, NoSQL-järjestelmät, kuten MongoDB, Elasticsearch ja Cassandra, ovat työntäneet kirjekuorta ketteryyden, skaalautuvuuden ja suorituskyvyn suhteen operatiivisille sovelluksille, joilla kaikilla on erilainen tietomalli ja lähestymistapa skeemaan. Matkan varrella monet kehitystiimit siirtyivät mikropalvelumalliin ja levittivät sovellustietoja moniin eri taustajärjestelmiin.

Analyysin osalta vanhat ja uudet tietolähteet ovat löytäneet tiensä perinteisten tietovarastojen ja tietojärvien sekoitukseen, jotkut Hadoopilla, toiset Amazon S3: lla. Ja Kafka-tiedonsiirtofoorumin nousu luo aivan toisenlaisen ajattelutavan tiedon liikkumisesta ja liikkuvan datan analysoinnista.

Koska dataa on niin monessa eri tekniikassa ja taustamuodossa, modernin datan analyysi on vaikeaa. BI- ja analyysityökalut, kuten Tableau, Power BI, R, Python ja koneoppimismallit, on suunniteltu maailmalle, jossa data elää yhdessä, tehokkaassa relaatiotietokannassa. Lisäksi näiden työkalujen käyttäjät - yritysanalyytikot, datatutkijat ja koneoppimismallit - haluavat kyvyn päästä käsiksi, tutkia ja analysoida tietoja itse ilman mitään riippuvuutta IT: stä.

Esittelyssä Dremio-tietokangas

BI-työkalut, tietojenkäsittelyjärjestelmät ja koneoppimismallit toimivat parhaiten, kun data elää yhdessä, tehokkaassa relaatiotietokannassa. Valitettavasti data ei asu tänään. Tämän seurauksena IT: llä ei ole muuta vaihtoehtoa kuin korjata tämä kuilu yhdistämällä mukautettuja ETL-kehitystuotteita ja omia tuotteita. Monissa yrityksissä analytiikkapino sisältää seuraavat kerrokset:

• Tietojen vaiheistus. Tiedot siirretään erilaisista operatiivisista tietokannoista yhdelle pysähdysalueelle, kuten Hadoop-klusteriin tai pilvivarastopalveluun (esim. Amazon S3).
• Tietovarasto. Vaikka SQL-kyselyitä on mahdollista suorittaa suoraan Hadoop- ja pilvitallennustiloissa, näitä järjestelmiä ei yksinkertaisesti ole suunniteltu tarjoamaan vuorovaikutteista suorituskykyä. Siksi osajoukko tiedoista ladataan yleensä relaatiotietovarastoon tai MPP-tietokantaan.
• Kuutiot, aggregaatiotaulukot ja BI-otteet. Interaktiivisen suorituskyvyn tarjoamiseksi suurille tietojoukoille tiedot on koottava valmiiksi ja / tai indeksoitava rakentamalla kuutioita OLAP-järjestelmään tai toteutuneita koontitaulukoita tietovarastoon.

Tämä monikerroksinen arkkitehtuuri tuo mukanaan monia haasteita. Se on monimutkainen, hauras ja hidas ja luo ympäristön, jossa datan kuluttajat ovat täysin riippuvaisia ​​tietotekniikasta.

Dremio esittelee uuden tason analytiikassa, jota kutsumme itsepalveludatakudokseksi. Dremio on avoimen lähdekoodin projekti, jonka avulla yritysanalyytikot ja datatutkijat voivat tutkia ja analysoida tietoja milloin tahansa niiden sijainnista, koosta tai rakenteesta riippumatta. Dremio yhdistää laajennettavan arkkitehtuurin pylvässuorituskykyyn ja kiihdytykseen interaktiivisen suorituskyvyn saavuttamiseksi kaikilla tietomäärillä samalla, kun IT, tiedetieteilijät ja liiketoiminta-analyytikot voivat muokata tietoja saumattomasti yrityksen tarpeiden mukaan.

Rakennettu Apache Arrow, Apache Parketti ja Apache Calcite

Dremio hyödyntää korkean suorituskyvyn pylvästallennusta ja suoritusta Apache Arrow (muistipylväs) ja Apache Parquet (pylväs levyllä). Dremio käyttää Apache Calcitea myös SQL-jäsentämiseen ja kyselyjen optimointiin rakentamalla samat kirjastot kuin monet muut SQL-pohjaiset moottorit, kuten Apache Hive.

Apache Arrow on avoimen lähdekoodin projekti, joka mahdollistaa sarakkeen sisäisen muistin tietojen käsittelyn ja vaihdon. Arrow on Dremion luoma, ja siihen kuuluu sitoutuneita yrityksiä useista yrityksistä, kuten Cloudera, Databricks, Hortonworks, Intel, MapR ja Two Sigma.

Dremio on ensimmäinen toteutusmoottori, joka on rakennettu alusta alkaen Apache Arrow'lle. Sisäisesti muistissa olevat tiedot ylläpidetään Arrow-muodossa, ja pian on olemassa API, joka palauttaa kyselytulokset Arrow-muistipuskureina.

Myös monet muut projektit ovat omaksuneet Arrow'n. Python (Pandas) ja R ovat näiden hankkeiden joukossa, mikä antaa tutkijoille mahdollisuuden työskennellä tehokkaammin datan kanssa. Esimerkiksi Wes McKinney, suositun Pandas-kirjaston luoja, osoitti äskettäin, kuinka Arrow antaa Python-käyttäjille mahdollisuuden lukea tietoja pandoiksi yli 10 Gt / s.

Kuinka Dremio mahdollistaa itsepalveludatan

Sen lisäksi, että datainsinöörit, liike-analyytikot ja datatutkijat voivat työskennellä vuorovaikutteisesti tietojoukkojensa kanssa, he tarvitsevat myös tapaa kuratoida tiedot niin, että ne soveltuvat tietyn projektin tarpeisiin. Tämä on perustavanlaatuinen muutos IT-keskitetystä mallista, jossa tietojen kuluttajat aloittavat tietojoukon pyynnön ja odottavat, että tietotekniikka täyttää pyyntönsä viikkoja tai kuukausia myöhemmin. Dremio mahdollistaa itsepalvelumallin, jossa datan kuluttajat käyttävät Dremion datakuraatiokykyjä etsimään, kuratoimaan, nopeuttamaan ja jakamaan tietoja yhteistyössä tietotekniikkaan turvautumatta.

Kaikki nämä ominaisuudet ovat käytettävissä modernin, intuitiivisen, verkkopohjaisen käyttöliittymän kautta:

• Löydä. Dremio sisältää yhtenäisen tietoluettelon, josta käyttäjät voivat löytää ja tutkia fyysisiä ja virtuaalisia aineistoja. Tietoluettelo päivitetään automaattisesti, kun uusia tietolähteitä lisätään ja kun tietolähteet ja virtuaaliset tietojoukot kehittyvät. Kaikki metatiedot on indeksoitu tehokkaaseen hakukelpoiseen hakemistoon ja altistettu käyttäjille Dremio-käyttöliittymän kautta.
• Kuratoi. Dremio antaa käyttäjien kuratoida tietoja luomalla virtuaalisia aineistoja. Erilaisia ​​pisteiden ja napsautusten muunnoksia tuetaan, ja kokeneet käyttäjät voivat käyttää monimutkaisempia muunnoksia SQL-syntaksin avulla. Kun kyselyt toteutetaan järjestelmässä, Dremio oppii tiedoista, minkä ansiosta se voi suositella erilaisia ​​muunnoksia, kuten liitoksia ja tietotyyppisiä muunnoksia.
• Dremio pystyy kiihdyttämään tietojoukkoja jopa 1000x lähdejärjestelmän suorituskykyyn nähden. Käyttäjät voivat äänestää tietojoukkojen puolesta, joiden heidän mielestään pitäisi olla nopeampia, ja Dremion heuristiikka ottaa nämä äänet huomioon päättäessään, mitkä aineistot nopeutetaan. Vaihtoehtoisesti järjestelmänvalvojat voivat manuaalisesti määrittää, mitkä tietojoukot nopeutetaan.
• Dremion avulla käyttäjät voivat jakaa tietoja turvallisesti muiden käyttäjien ja ryhmien kanssa. Tässä mallissa käyttäjäryhmä voi tehdä yhteistyötä virtuaalisen aineiston kanssa, jota käytetään tietyssä analyyttisessä työssä. Vaihtoehtoisesti käyttäjät voivat ladata omia tietojaan, kuten Excel-laskentataulukoita, liittyäksesi muihin yritystietoluetteloon. Virtuaalisten tietojoukkojen luojat voivat määrittää, mitkä käyttäjät voivat tehdä kyselyjä tai muokata virtuaalisia aineistojaan. Se on kuin Google-dokumentit tiedoillesi.

Kuinka Dremio-datakiihdytys toimii

Dremio hyödyntää lähdetietojen erittäin optimoituja fyysisiä esityksiä nimeltä Data Reflections. Reflection Store voi elää HDFS: ssä, MapR-FS: ssä, pilvivarastossa, kuten S3, tai suoraan liitetyssä tallennustilassa (DAS). Reflection Storen koko voi ylittää fyysisen muistin koon. Tämän arkkitehtuurin avulla Dremio voi nopeuttaa enemmän dataa pienemmillä kustannuksilla, mikä johtaa paljon korkeampaan välimuistin osumissuhteeseen verrattuna perinteisiin vain muistia koskeviin arkkitehtuureihin. Kustannuspohjainen optimoija käyttää tietoheijastuksia automaattisesti kyselyhetkellä.

Tietoheijastukset ovat näkymättömiä loppukäyttäjille. Toisin kuin OLAP-kuutiot, koontitaulukot ja BI-otteet, käyttäjä ei nimenomaisesti muodosta yhteyttä tietojen heijastukseen. Sen sijaan käyttäjät lähettävät kyselyjä loogisesta mallista, ja Dremion optimoija nopeuttaa kyselyä automaattisesti hyödyntämällä kyselyyn sopivia tietojen pohdintoja optimoijan kustannusanalyysin perusteella.

Kun optimoija ei pysty nopeuttamaan kyselyä, Dremio hyödyntää korkean suorituskyvyn hajautettua suoritusmoottoriaan, hyödyntämällä sarakkeista muistin sisäistä käsittelyä (Apache Arrow -nuolen kautta) ja edistyneitä pudotuksia alaspäin tietolähteisiin (käsitellessään RDBMS- tai NoSQL-lähteitä).

Kuinka Dremio käsittelee SQL-kyselyitä

Asiakassovellukset lähettävät SQL-kyselyjä Dremioon ODBC: n, JDBC: n tai REST: n kautta. Kyselyyn voi liittyä yksi tai useampi tietojoukko, joka voi sijaita eri tietolähteissä. Esimerkiksi kysely voi olla liitos Hive-taulukon, Elasticsearchin ja useiden Oracle-taulukoiden välillä.

Dremio käyttää kahta ensisijaista tekniikkaa kyselyyn tarvittavan käsittelyn vähentämiseksi:

• Push-downs taustalla olevaan tietolähteeseen. Optimoija ottaa huomioon taustalla olevan tietolähteen ominaisuudet ja suhteelliset kustannukset. Sitten se luo suunnitelman, joka suorittaa kyselyn vaiheet joko lähteessä tai Dremion hajautetussa suoritusympäristössä, jotta saavutetaan mahdollisimman tehokas kokonaissuunnitelma.
• Kiihtyvyys tietojen heijastusten avulla. Optimoija käyttää Datan heijastuksia kyselyn osiin, kun se tuottaa tehokkaimman kokonaissuunnitelman. Monissa tapauksissa koko kysely voidaan palvella Data Reflections -sovelluksen kautta, koska ne voivat olla suuruusluokkaa tehokkaampia kuin kyselyjen käsittely taustalla olevassa tietolähteessä.

Kyselyn pudotukset

Dremio pystyy työntämään prosessoinnin relaatio- ja ei-relaatiolähteiksi. Ei-relaatiolähteet eivät yleensä tue SQL: ää ja niillä on rajoitetut toteutusominaisuudet. Esimerkiksi tiedostojärjestelmä ei voi käyttää predikaatteja tai aggregaatteja. MongoDB puolestaan ​​voi soveltaa predikaatteja ja aggregaatteja, mutta ei tue kaikkia liittymiä. Dremio-optimoija ymmärtää jokaisen tietolähteen ominaisuudet. Kun se on tehokkainta, Dremio työntää niin paljon kyselyä taustalähteeseen kuin mahdollista ja suorittaa loput omassa hajautetussa suoritusmoottorissaan.

Operatiivisten tietokantojen purkaminen

Suurin osa operatiivisista tietokannoista on suunniteltu kirjoitusoptimoiduille kuormille. Lisäksi näiden käyttöönottojen on käsiteltävä tiukkoja palvelutasosopimuksia, koska mahdolliset seisokit tai heikentynyt suorituskyky voivat vaikuttaa merkittävästi liiketoimintaan. Tämän seurauksena operatiiviset järjestelmät eristetään usein analyyttisten kyselyjen käsittelystä. Näissä tapauksissa Dremio voi suorittaa analyyttiset kyselyt Data Reflections -ohjelman avulla, joka tarjoaa tehokkaimman mahdollisen kyselyjen käsittelyn ja minimoi vaikutukset käyttöjärjestelmään. Tietoheijastuksia päivitetään säännöllisesti käytäntöjen perusteella, jotka voidaan määrittää taulukoittain.

Kyselyn suoritusvaiheet

Kyselyn käyttöikä sisältää seuraavat vaiheet:

1. Asiakas lähettää kyselyn koordinaattorille ODBC / JDBC / REST-yhteyden kautta
2. Suunnittelu
1. Koordinaattori jäsentää kyselyn Dremion yleiseen relaatiomalliin
2. Koordinaattori ottaa huomioon käytettävissä olevat tilastotiedot tietolähteistä kyselysuunnitelman kehittämiseksi sekä lähteen toiminnalliset kyvyt
3. Koordinaattori kirjoittaa kyselysuunnitelman käytettäväksi
1. käytettävissä olevat tietoheijastukset ottaen huomioon tietojen heijastusten tilaamisen, jakamisen ja jakamisen
2. tietolähteen käytettävissä olevat ominaisuudet
4. Suoritus

1. Suorittajat lukevat tietoja Arrow-puskureihin lähteistä samanaikaisesti

1. Suorittajat suorittavat uudelleenkirjoitetun kyselysuunnitelman.
2. Yksi toteuttaja yhdistää yhden tai useamman toteuttajan tulokset ja suoratoistaa lopulliset tulokset koordinaattorille
1. Asiakas saa tulokset koordinaattorilta

Huomaa, että tiedot voivat olla peräisin Tietojen heijastuksista tai taustalla olevista tietolähteistä. Kun lukee tietolähteestä, toteuttaja lähettää natiivikyselyt (esim. MongoDB MQL, Elasticsearch Query DSL, Microsoft Transact-SQL) optimoijan määrittelemänä suunnitteluvaiheessa.

Kaikki datatoiminnot suoritetaan toteuttajasolmussa, jolloin järjestelmä voi skaalata monille samanaikaisille asiakkaille vain muutaman koordinaattorin solmun avulla.

Esimerkki kyselypainikkeesta

Tarkastelemme tarkemmin SQL-kyselyn suorittamista lähteessä, joka ei tue SQL: ää, jotta voimme havainnollistaa, kuinka Data Fabric sopii tietorakenneosi.

Yksi suosituimmista nykyaikaisista tietolähteistä on Elasticsearch. Elasticsearchista on paljon pidettävää, mutta analyysin kannalta se ei tue SQL: ää (mukaan lukien SQL-liittymät). Tämä tarkoittaa, että työkaluja, kuten Tableau ja Excel, ei voida käyttää analysoimaan tietoja tähän tietovarastoon rakennetuista sovelluksista. On olemassa visualisointiprojekti nimeltä Kibana, joka on suosittu Elasticsearchille, mutta Kibana on suunniteltu kehittäjille. Se ei ole oikeastaan ​​yrityskäyttäjille.

Dremion avulla on helppo analysoida tietoja Elasticsearchissa millä tahansa SQL-pohjaisella työkalulla, mukaan lukien Tableau. Otetaan esimerkiksi seuraava SQL-kysely Yelp-yritystiedoille, joka on tallennettu JSON: iin:

VALITSE osavaltio, kaupunki, nimi, arvostelu_luku

ELEKTRONIIKKAA.EITÄ. LIIKETOIMINTA

MISSÄ

tila EI OLE (’TX’, ’UT’, ’NM’, ’NJ’) JA

arvostelu_määrä> 100

TILAA MÄÄRITTELY_määrä DESC, osavaltio, kaupunki

RAJA 10

Dremio kokoaa kyselyn lausekkeeksi, jonka Elasticsearch voi käsitellä: