Dremio: Enklere og raskere dataanalyse

Jacques Nadeau er CTO og medstifter av Dremio.

Nå er det en flott tid å være utvikler. I løpet av det siste tiåret har beslutninger om teknologi flyttet fra styrerommet til innovative utviklere, som bygger med åpen kildekode og tar beslutninger basert på fordelene ved det underliggende prosjektet i stedet for de kommersielle forholdene som tilbys av en leverandør. Nye prosjekter har dukket opp som fokuserer på å gjøre utviklere mer produktive, og som er lettere å administrere og skalere. Dette gjelder nesten alle lag i teknologibakken. Resultatet er at utviklere i dag har nesten ubegrensede muligheter til å utforske ny teknologi, nye arkitekturer og nye distribusjonsmodeller.

Ser vi spesielt på datalaget, har NoSQL-systemer som MongoDB, Elasticsearch og Cassandra presset konvolutten når det gjelder smidighet, skalerbarhet og ytelse for operasjonelle applikasjoner, hver med en annen datamodell og tilnærming til skjema. Underveis flyttet mange utviklingsteam til en mikroservicemodell, og spredte applikasjonsdata over mange forskjellige underliggende systemer.

Når det gjelder analyser, har gamle og nye datakilder funnet veien inn i en blanding av tradisjonelle datalager og datasjøer, noen på Hadoop, andre på Amazon S3. Og fremveksten av Kafka datastreamingsplattform skaper en helt annen måte å tenke på databevegelse og analyse av data i bevegelse.

Med data i så mange forskjellige teknologier og underliggende formater er analyse av moderne data vanskelig. BI- og analyseverktøy som Tableau, Power BI, R, Python og maskinlæringsmodeller ble designet for en verden der data lever i en enkelt, høyytelses relasjonsdatabase. I tillegg ønsker brukere av disse verktøyene - forretningsanalytikere, dataforskere og maskinlæringsmodeller - muligheten til å få tilgang til, utforske og analysere data på egenhånd uten avhengighet av IT.

Vi presenterer Dremio-datastoffet

BI-verktøy, data science-systemer og maskinlæringsmodeller fungerer best når data lever i en enkelt, høyytelses relasjonsdatabase. Dessverre er det ikke der data lever i dag. Som et resultat har IT ikke annet valg enn å bygge bro over gapet gjennom en kombinasjon av tilpasset ETL-utvikling og proprietære produkter. I mange selskaper inkluderer analysestakken følgende lag:

• Datastaging. Dataene blir flyttet fra forskjellige operasjonelle databaser til et enkelt iscenesettelsesområde, for eksempel en Hadoop-klynge eller skylagringstjeneste (f.eks. Amazon S3).
• Datavarehus. Selv om det er mulig å utføre SQL-spørringer direkte på Hadoop og skylagring, er disse systemene ganske enkelt ikke designet for å levere interaktiv ytelse. Derfor blir et delsett av dataene vanligvis lastet inn i et relasjonelt datalager eller MPP-database.
• Kuber, aggregeringstabeller og BI-utdrag. For å gi interaktiv ytelse på store datasett, må dataene forhåndsaggregeres og / eller indekseres ved å bygge kuber i et OLAP-system eller materialiserte aggregeringstabeller i datalageret.

Denne flerlagsarkitekturen introduserer mange utfordringer. Det er komplekst, skjørt og sakte, og skaper et miljø der dataforbrukere er helt avhengige av IT.

Dremio introduserer et nytt nivå i dataanalyse vi kaller et selvbetjent datastoff. Dremio er et open source-prosjekt som gjør det mulig for forretningsanalytikere og dataforskere å utforske og analysere data når som helst, uavhengig av beliggenhet, størrelse eller struktur. Dremio kombinerer en skaleringsarkitektur med søyleutførelse og akselerasjon for å oppnå interaktiv ytelse på ethvert datavolum, samtidig som IT, dataforskere og forretningsanalytikere kan sømløst forme dataene etter virksomhetens behov.

Bygget på Apache Arrow, Apache Parkett og Apache Calcite

Dremio benytter høy ytelse kolonnelagring og utførelse, drevet av Apache Arrow (søyle i minnet) og Apache Parquet (søyle på disk). Dremio bruker også Apache Calcite for SQL-parsing og spørringsoptimalisering, og bygger på de samme bibliotekene som mange andre SQL-baserte motorer, for eksempel Apache Hive.

Apache Arrow er et åpen kildekode-prosjekt som gjør det mulig å behandle og utveksle søyle i minnet. Arrow ble opprettet av Dremio, og inkluderer forpliktelser fra forskjellige selskaper, inkludert Cloudera, Databricks, Hortonworks, Intel, MapR og Two Sigma.

Dremio er den første utførelsesmotoren bygget fra grunnen av på Apache Arrow. Internt holdes dataene i minnet utenfor heap i pilformatet, og det vil snart være et API som returnerer spørreresultater som pilminnebuffere.

En rekke andre prosjekter har også omfavnet Arrow. Python (Pandas) og R er blant disse prosjektene, slik at dataforskere kan jobbe mer effektivt med data. For eksempel demonstrerte Wes McKinney, skaper av det populære Pandas-biblioteket, nylig hvordan Arrow gjør det mulig for Python-brukere å lese data i Pandas på over 10 GB / s.

Hvordan Dremio muliggjør selvbetjeningsdata

I tillegg til muligheten til å jobbe interaktivt med datasettene deres, trenger dataingeniører, forretningsanalytikere og dataforskere også en måte å kuratere dataene slik at de er egnet for behovene til et bestemt prosjekt. Dette er et grunnleggende skifte fra den IT-sentriske modellen, der forbrukere av data starter en forespørsel om et datasett og venter på at IT skal oppfylle forespørselen uker eller måneder senere. Dremio muliggjør en selvbetjeningsmodell, der forbrukere av data bruker Dremios evner for datakurering for å samarbeide oppdage, kurere, akselerere og dele data uten å stole på IT.

Alle disse funksjonene er tilgjengelige gjennom et moderne, intuitivt, nettbasert brukergrensesnitt:

• Oppdage. Dremio inkluderer en enhetlig datakatalog der brukere kan oppdage og utforske fysiske og virtuelle datasett. Datakatalogen oppdateres automatisk når nye datakilder legges til, og når datakilder og virtuelle datasett utvikler seg. Alle metadata er indeksert i en høyytelses, søkbar indeks og eksponert for brukere i hele Dremio-grensesnittet.
• Curate. Dremio gjør det mulig for brukere å kuratere data ved å lage virtuelle datasett. En rekke pek-og-klikk-transformasjoner støttes, og avanserte brukere kan bruke SQL-syntaks for å definere mer komplekse transformasjoner. Etter hvert som spørsmål utføres i systemet, lærer Dremio om dataene, slik at den kan anbefale forskjellige transformasjoner som sammenføyninger og datatypekonverteringer.
• Dremio er i stand til å akselerere datasett med opptil 1000 ganger over ytelsen til kildesystemet. Brukere kan stemme på datasett de mener skal være raskere, og Dremios heuristikk vil vurdere disse stemmene ved å bestemme hvilke datasett som skal akselerere. Alternativt kan systemadministratorer manuelt bestemme hvilke datasett som skal akselerere.
• Dremio gjør det mulig for brukere å dele data sikkert med andre brukere og grupper. I denne modellen kan en gruppe brukere samarbeide om et virtuelt datasett som skal brukes til en bestemt analytisk jobb. Alternativt kan brukere laste opp egne data, for eksempel Excel-regneark, for å bli med i andre datasett fra bedriftskatalogen. Skaperne av virtuelle datasett kan bestemme hvilke brukere som kan spørre eller redigere virtuelle datasett. Det er som Google Dokumenter for dataene dine.

Hvordan fungerer Dremio-dataakselerasjon

Dremio bruker svært optimaliserte fysiske representasjoner av kildedata kalt Data Reflections. Reflection Store kan leve på HDFS, MapR-FS, skylagring som S3 eller direkte tilknyttet lagring (DAS). Reflection Store-størrelsen kan overstige størrelsen på det fysiske minnet. Denne arkitekturen gjør det mulig for Dremio å akselerere mer data til en lavere kostnad, noe som resulterer i et mye høyere cache-treffforhold sammenlignet med tradisjonelle minnearkitekturer. Datarefleksjoner brukes automatisk av den kostnadsbaserte optimalisereren ved spørringstidspunktet.

Datarefleksjoner er usynlige for sluttbrukere. I motsetning til OLAP-kuber, aggregeringstabeller og BI-utdrag, kobler brukeren ikke eksplisitt til en datarefleksjon. I stedet utsteder brukere spørringer mot den logiske modellen, og Dremios optimizer akselererer automatisk spørringen ved å dra nytte av datarefleksjonene som passer for spørringen, basert på optimaliserings kostnadsanalyse.

Når optimalisereren ikke kan akselerere spørringen, bruker Dremio sin høytytende distribuerte kjøringsmotor, ved å utnytte kolonneformet minnehåndtering (via Apache Arrow) og avanserte push-downs i de underliggende datakildene (når det gjelder RDBMS- eller NoSQL-kilder).

Hvordan Dremio håndterer SQL-spørsmål

Klientapplikasjoner utsteder SQL-spørsmål til Dremio over ODBC, JDBC eller REST. Et spørsmål kan involvere ett eller flere datasett, potensielt bosatt i forskjellige datakilder. For eksempel kan et spørsmål være en sammenkobling mellom en Hive-tabell, Elasticsearch og flere Oracle-tabeller.

Dremio bruker to primære teknikker for å redusere mengden prosessering som kreves for et spørsmål:

• Push-downs i den underliggende datakilden. Optimalisereren vil vurdere funksjonene til den underliggende datakilden og de relative kostnadene. Deretter vil den generere en plan som utfører trinn i spørringen enten i kilden eller i Dremios distribuerte kjøringsmiljø for å oppnå en mest mulig effektiv totalplan.
• Akselerasjon via datarefleksjoner. Optimizer vil bruke datarefleksjoner for deler av spørringen når dette gir den mest effektive overordnede planen. I mange tilfeller kan hele spørringen betjenes fra datarefleksjoner, da de kan være størrelsesordener mer effektive enn å behandle spørsmål i den underliggende datakilden.

Spørring-nedtrappinger

Dremio er i stand til å presse ned behandlingen til relasjonelle og ikke-relasjonelle datakilder. Ikke-relasjonelle datakilder støtter vanligvis ikke SQL og har begrensede kjøringsmuligheter. Et filsystem kan for eksempel ikke bruke predikater eller aggregeringer. MongoDB, derimot, kan bruke predikater og aggregeringer, men støtter ikke alle sammenføyninger. Dremio optimizer forstår funksjonene til hver datakilde. Når det er mest effektivt, vil Dremio skyve så mye av et spørsmål til den underliggende kilden som mulig, og utfører resten i sin egen distribuerte kjøringsmotor.

Laster ut operative databaser

De fleste operative databaser er designet for skriveoptimaliserte arbeidsmengder. Videre må disse distribusjonene adressere strenge SLA-er, ettersom nedetid eller svekket ytelse kan påvirke virksomheten betydelig. Som et resultat blir operasjonelle systemer ofte isolert fra behandling av analytiske spørsmål. I disse tilfellene kan Dremio utføre analytiske spørsmål ved hjelp av datarefleksjoner, som gir den mest effektive spørringsbehandlingen mulig, samtidig som effekten av operativsystemet minimeres. Datarefleksjoner oppdateres med jevne mellomrom basert på policyer som kan konfigureres på en tabell for en tabell.

Spørringsutførelsesfaser

Levetiden til en forespørsel inkluderer følgende faser:

1. Kunden sender forespørsel til koordinator via ODBC / JDBC / REST
2. Planlegger
1. Koordinator analyserer forespørsel om Dremios universelle relasjonsmodell
2. Koordinator vurderer tilgjengelig statistikk om datakilder for å utvikle spørringsplan, samt kildens funksjonelle evner
3. Koordinator skriver om en plan for bruk
1. tilgjengelige datarefleksjoner, vurderer bestilling, partisjonering og distribusjon av datarefleksjonene og
2. tilgjengelige datakildens muligheter
4. Henrettelse

1. Eksekutører leser data i pilbuffere fra kilder parallelt

1. Utførere utfører den omskrevne spørringsplanen.
2. Én utfører slår sammen resultatene fra en eller flere utførere og strømmer de endelige resultatene til koordinatoren
1. Kunden mottar resultatene fra koordinatoren

Merk at dataene kan komme fra datarefleksjoner eller den underliggende datakilden (e). Når du leser fra en datakilde, sender utføreren de innfødte spørringene (f.eks. MongoDB MQL, Elasticsearch Query DSL, Microsoft Transact-SQL) som bestemt av optimalisereren i planleggingsfasen.

Alle datahandlinger utføres på eksekverandernoden, slik at systemet kan skaleres til mange samtidige klienter ved hjelp av bare noen få koordinatornoder.

Eksempel på nedtrekksspørring

For å illustrere hvordan Data Fabric passer inn i dataarkitekturen din, la oss se nærmere på å kjøre et SQL-spørsmål på en kilde som ikke støtter SQL.

En av de mer populære moderne datakildene er Elasticsearch. Det er mye å like med Elasticsearch, men når det gjelder analyse, støtter det ikke SQL (inkludert SQL-sammenkoblinger). Det betyr at verktøy som Tableau og Excel ikke kan brukes til å analysere data fra applikasjoner som er bygd på dette datalageret. Det er et visualiseringsprosjekt kalt Kibana som er populært for Elasticsearch, men Kibana er designet for utviklere. Det er egentlig ikke for forretningsbrukere.

Dremio gjør det enkelt å analysere data i Elasticsearch med ethvert SQL-basert verktøy, inkludert Tableau. La oss ta for eksempel følgende SQL-spørring for Yelp-forretningsdata, som er lagret i JSON:

VELG stat, by, navn, anmeldelse_antall

FRA elastisk.hjelp.virksomhet

HVOR

oppgi IKKE INN (‘TX’, ‘UT’, ‘NM’, ‘NJ’) OG

review_count> 100

BESTIL MED BY_telling DESC, delstat, by

GRENSE 10

Dremio kompilerer spørringen til et uttrykk som Elasticsearch kan behandle: