Dremio: Enklere og hurtigere dataanalyse

Jacques Nadeau er CTO og medstifter af Dremio.

Det er nu en god tid at være udvikler. I løbet af det sidste årti er beslutninger om teknologi flyttet fra bestyrelseslokalet til innovative udviklere, der bygger med open source og træffer beslutninger baseret på fordelene ved det underliggende projekt snarere end de kommercielle forhold, der leveres af en leverandør. Der er opstået nye projekter, der fokuserer på at gøre udviklere mere produktive, og som er lettere at styre og skalere. Dette gælder næsten alle lag i teknologistakken. Resultatet er, at udviklere i dag næsten har ubegrænsede muligheder for at udforske nye teknologier, nye arkitekturer og nye implementeringsmodeller.

Ser man især på datalaget, har NoSQL-systemer som MongoDB, Elasticsearch og Cassandra skubbet konvolutten med hensyn til smidighed, skalerbarhed og ydeevne til operationelle applikationer, hver med en anden datamodel og tilgang til skema. Undervejs flyttede mange udviklingsteam til en mikroservicemodel, der spredte applikationsdata på mange forskellige underliggende systemer.

Med hensyn til analyse har gamle og nye datakilder fundet vej ind i en blanding af traditionelle datalagre og datasøer, nogle på Hadoop, andre på Amazon S3. Og stigningen i Kafka-datastreamingsplatformen skaber en helt anden måde at tænke på dataflytning og analyse af data i bevægelse.

Med data i så mange forskellige teknologier og underliggende formater er det svært at analysere moderne data. BI- og analyseværktøjer som Tableau, Power BI, R, Python og machine learning-modeller blev designet til en verden, hvor data lever i en enkelt relationsdatabase med høj ydeevne. Derudover vil brugere af disse værktøjer - forretningsanalytikere, dataforskere og machine learning-modeller - have mulighed for at få adgang til, udforske og analysere data på egen hånd uden nogen afhængighed af IT.

Introduktion til Dremio-datastoffet

BI-værktøjer, datavidenskabssystemer og maskinindlæringsmodeller fungerer bedst, når data lever i en enkelt, højtydende relationsdatabase. Desværre er det ikke her, data lever i dag. Som et resultat har IT intet andet valg end at bygge bro over dette hul gennem en kombination af brugerdefineret ETL-udvikling og proprietære produkter. I mange virksomheder inkluderer analysestakken følgende lag:

• Data iscenesættelse. Dataene flyttes fra forskellige operationelle databaser til et enkelt iscenesættelsesområde, såsom en Hadoop-klynge eller cloud-opbevaringstjeneste (f.eks. Amazon S3).
• Data varehus. Mens det er muligt at udføre SQL-forespørgsler direkte på Hadoop og cloud storage, er disse systemer simpelthen ikke designet til at levere interaktiv ydeevne. Derfor indlæses et undersæt af data normalt i et relationelt datalager eller MPP-database.
• Kuber, aggregeringstabeller og BI-uddrag. For at give interaktiv ydeevne på store datasæt skal dataene aggregeres og / eller indekseres forud ved at bygge kuber i et OLAP-system eller materialiserede aggregeringstabeller i datalageret.

Denne flerlagsarkitektur introducerer mange udfordringer. Det er komplekst, skrøbeligt og langsomt og skaber et miljø, hvor dataforbrugere er helt afhængige af IT.

Dremio introducerer et nyt niveau inden for dataanalyse, vi kalder et selvbetjeningsdatastof. Dremio er et open source-projekt, der gør det muligt for forretningsanalytikere og dataforskere at udforske og analysere alle data til enhver tid, uanset placering, størrelse eller struktur. Dremio kombinerer en opskaleret arkitektur med søjleudførelse og acceleration for at opnå interaktiv ydeevne på ethvert datavolumen, samtidig med at it, dataforskere og forretningsanalytikere problemfrit kan forme dataene efter forretningens behov.

Bygget på Apache Arrow, Apache Parket og Apache Calcite

Dremio bruger højtydende søjleopbevaring og udførelse, drevet af Apache Arrow (søjle i hukommelsen) og Apache Parquet (søjle på disk). Dremio bruger også Apache Calcite til SQL-parsing og optimering af forespørgsler, og bygger på de samme biblioteker som mange andre SQL-baserede motorer, såsom Apache Hive.

Apache Arrow er et open source-projekt, der muliggør kolonneformat databehandling og udveksling af hukommelse. Arrow blev oprettet af Dremio og inkluderer forpligtelser fra forskellige virksomheder, herunder Cloudera, Databricks, Hortonworks, Intel, MapR og Two Sigma.

Dremio er den første udførelsesmotor bygget fra bunden på Apache Arrow. Internt holdes dataene i hukommelsen off-heap i pilformatet, og der vil snart være en API, der returnerer forespørgselsresultater som pilhukommelsesbuffere.

En række andre projekter har også taget Arrow til sig. Python (Pandas) og R er blandt disse projekter, der gør det muligt for dataforskere at arbejde mere effektivt med data. For eksempel demonstrerede Wes McKinney, skaberen af ​​det populære Pandas-bibliotek, for nylig, hvordan Arrow gør det muligt for Python-brugere at læse data i Pandas med over 10 GB / s.

Hvordan Dremio muliggør selvbetjeningsdata

Ud over evnen til at arbejde interaktivt med deres datasæt har dataingeniører, forretningsanalytikere og dataforskere også brug for en måde at kuratere dataene på, så de er egnede til et specifikt projekts behov. Dette er et grundlæggende skift fra den IT-centrerede model, hvor forbrugere af data initierer en anmodning om et datasæt og venter på, at IT opfylder deres anmodning uger eller måneder senere. Dremio muliggør en selvbetjeningsmodel, hvor forbrugere af data bruger Dremios datakurationsfunktioner til at samarbejde, opdage, kurere, fremskynde og dele data uden at stole på IT.

Alle disse muligheder er tilgængelige via et moderne, intuitivt, webbaseret brugergrænseflade:

• Opdage. Dremio inkluderer et samlet datakatalog, hvor brugere kan opdage og udforske fysiske og virtuelle datasæt. Datakataloget opdateres automatisk, når nye datakilder tilføjes, og når datakilder og virtuelle datasæt udvikler sig. Alle metadata indekseres i et højtydende, søgbart indeks og udsættes for brugere i hele Dremio-grænsefladen.
• Kurer. Dremio giver brugerne mulighed for at kuratere data ved at oprette virtuelle datasæt. En række peg-og-klik-transformationer understøttes, og avancerede brugere kan bruge SQL-syntaks til at definere mere komplekse transformationer. Når forespørgsler udføres i systemet, lærer Dremio om dataene, hvilket gør det muligt for den at anbefale forskellige transformationer såsom sammenføjninger og datatypekonverteringer.
• Dremio er i stand til at accelerere datasæt med op til 1000 gange over kildesystemets ydeevne. Brugere kan stemme på datasæt, som de synes skal være hurtigere, og Dremios heuristik vil overveje disse stemmer ved at bestemme, hvilke datasæt der skal accelereres. Eventuelt kan systemadministratorer manuelt bestemme, hvilke datasæt der skal accelereres.
• Dremio gør det muligt for brugere at dele data sikkert med andre brugere og grupper. I denne model kan en gruppe brugere samarbejde om et virtuelt datasæt, der skal bruges til et bestemt analytisk job. Alternativt kan brugerne uploade deres egne data, såsom Excel-regneark, for at slutte sig til andre datasæt fra virksomhedskataloget. Skabere af virtuelle datasæt kan bestemme, hvilke brugere der kan spørge eller redigere deres virtuelle datasæt. Det er som Google Docs til dine data.

Sådan fungerer Dremio-dataacceleration

Dremio bruger meget optimerede fysiske repræsentationer af kildedata kaldet Data Reflections. Reflection Store kan leve på HDFS, MapR-FS, cloud storage såsom S3 eller direct-attached storage (DAS). Reflection Store-størrelsen kan overstige størrelsen på den fysiske hukommelse. Denne arkitektur gør det muligt for Dremio at fremskynde flere data til en lavere pris, hvilket resulterer i et langt højere cache-hit-forhold sammenlignet med traditionelle kun hukommelsesarkitekturer. Datareflektioner bruges automatisk af den omkostningsbaserede optimering på forespørgselstidspunktet.

Datareflektioner er usynlige for slutbrugere. I modsætning til OLAP-terninger, aggregeringstabeller og BI-ekstrakter forbinder brugeren ikke eksplicit til en datareflektion. I stedet udsender brugerne forespørgsler mod den logiske model, og Dremios optimizer fremskynder automatisk forespørgslen ved at udnytte de datareflektioner, der er egnede til forespørgslen, baseret på optimeringsomkostningsanalysen.

Når optimeringsprogrammet ikke kan fremskynde forespørgslen, bruger Dremio sin højtydende distribuerede eksekveringsmotor, der udnytter søjleformet in-memory-behandling (via Apache Arrow) og avancerede push-downs til de underliggende datakilder (når det drejer sig om RDBMS eller NoSQL-kilder).

Hvordan Dremio håndterer SQL-forespørgsler

Klientapplikationer udsteder SQL-forespørgsler til Dremio over ODBC, JDBC eller REST. En forespørgsel kan involvere et eller flere datasæt, der potentielt findes i forskellige datakilder. For eksempel kan en forespørgsel være en sammenføjning mellem en Hive-tabel, Elasticsearch og flere Oracle-tabeller.

Dremio bruger to primære teknikker til at reducere den mængde behandling, der kræves til en forespørgsel:

• Push-downs til den underliggende datakilde. Optimizer vil overveje mulighederne for den underliggende datakilde og de relative omkostninger. Derefter genereres en plan, der udfører trin i forespørgslen enten i kilden eller i Dremios distribuerede eksekveringsmiljø for at opnå den mest effektive overordnede plan.
• Acceleration via datareflektioner. Optimizer bruger datareflektioner til dele af forespørgslen, når dette giver den mest effektive overordnede plan. I mange tilfælde kan hele forespørgslen serviceres fra datareflektioner, da de kan være størrelsesordener mere effektive end behandling af forespørgsler i den underliggende datakilde.

Forespørgsel push-downs

Dremio er i stand til at skubbe ned behandling til relationelle og ikke-relationelle datakilder. Ikke-relationelle datakilder understøtter typisk ikke SQL og har begrænsede eksekveringsfunktioner. Et filsystem kan for eksempel ikke anvende prædikater eller aggregeringer. MongoDB kan på den anden side anvende prædikater og aggregeringer, men understøtter ikke alle sammenføjninger. Dremio optimizer forstår hver datakildes muligheder. Når det er mest effektivt, vil Dremio skubbe så meget af en forespørgsel til den underliggende kilde som muligt og udfører resten i sin egen distribuerede eksekveringsmotor.

Aflæsning af operationelle databaser

De fleste operationelle databaser er designet til skriveoptimerede arbejdsbelastninger. Desuden skal disse implementeringer adressere strenge SLA'er, da enhver nedetid eller forringet ydeevne kan påvirke forretningen betydeligt. Som et resultat isoleres driftssystemer ofte fra behandling af analytiske forespørgsler. I disse tilfælde kan Dremio udføre analytiske forespørgsler ved hjælp af datareflektioner, som giver den mest effektive forespørgsel, der er mulig, samtidig med at indvirkningen på det operationelle system minimeres. Datareflektioner opdateres med jævne mellemrum baseret på politikker, der kan konfigureres tabel for tabel.

Forespørgselseksekveringsfaser

Forespørgslens levetid inkluderer følgende faser:

1. Kunden sender forespørgsel til koordinatoren via ODBC / JDBC / REST
2. Planlægning
1. Koordinator analyserer forespørgsel i Dremios universelle relationelle model
2. Koordinator overvejer tilgængelig statistik om datakilder for at udvikle forespørgselsplan samt kildens funktionelle evner
3. Koordinator omskriver forespørgselsplan, der skal bruges
1. de tilgængelige datareflektioner under hensyntagen til bestilling, partitionering og distribution af datareflektionerne og
2. de tilgængelige kapaciteter i datakilden
4. Udførelse

1. Eksekutører læser parallelt data i pilbuffere fra kilder

1. Eksekutører udfører den omskrevne forespørgselsplan.
2. En eksekutor fletter resultaterne fra en eller flere eksekutorer og streamer de endelige resultater til koordinatoren
1. Kunden modtager resultaterne fra koordinatoren

Bemærk, at dataene kan komme fra datareflektioner eller den underliggende datakilde (r). Når man læser fra en datakilde, sender eksekutoren de oprindelige forespørgsler (f.eks. MongoDB MQL, Elasticsearch Query DSL, Microsoft Transact-SQL) som bestemt af optimeringsprogrammet i planlægningsfasen.

Alle datahandlinger udføres på eksekutorknudepunktet, hvilket gør det muligt for systemet at skalere til mange samtidige klienter ved hjælp af kun få koordinatorknudepunkter.

Eksempel på forespørgsel

For at illustrere, hvordan Data Fabric passer ind i din dataarkitektur, skal vi se nærmere på at køre en SQL-forespørgsel på en kilde, der ikke understøtter SQL.

En af de mere populære moderne datakilder er Elasticsearch. Der er meget at lide ved Elasticsearch, men med hensyn til analyse understøtter det ikke SQL (inklusive SQL-sammenføjninger). Det betyder, at værktøjer som Tableau og Excel ikke kan bruges til at analysere data fra applikationer, der er bygget på dette datalager. Der er et visualiseringsprojekt kaldet Kibana, der er populært for Elasticsearch, men Kibana er designet til udviklere. Det er ikke rigtig for forretningsbrugere.

Dremio gør det let at analysere data i Elasticsearch med ethvert SQL-baseret værktøj, inklusive Tableau. Lad os f.eks. Tage følgende SQL-forespørgsel til Yelp-forretningsdata, som er gemt i JSON:

VÆLG stat, by, navn, anmeldelse_antal

FRA elastic.yelp.business

HVOR

angiv IKKE IN ('TX', 'UT', 'NM', 'NJ') OG

review_count> 100

BESTIL VED review_count DESC, stat, by

GRÆNSE 10

Dremio kompilerer forespørgslen til et udtryk, som Elasticsearch kan behandle: