streamalism.org

1. Introduktion

I denne vejledning forstår vi, hvordan vi arbejder med begivenhedsdata og Apache Druid. Vi vil dække det grundlæggende i begivenhedsdata og Druid-arkitektur. Som en del heraf opretter vi en simpel datapipeline, der udnytter forskellige funktioner i Druid, der dækker forskellige tilstande for dataintagelse og forskellige måder at forespørge på de forberedte data på.

2. Grundlæggende begreber

Før vi springer ind i operationens detaljer om Apache Druid, lad os først gennemgå nogle af de grundlæggende koncepter. Det rum, vi er interesseret i, er realtidsanalyser af begivenhedsdata i massiv skala.

Derfor er det bydende nødvendigt at forstå, hvad vi mener med begivenhedsdata, og hvad kræver det at analysere dem i realtid i skala.

2.1. Hvad er begivenhedsdata?

Begivenhedsdata refererer til et stykke information om en ændring, der sker på et bestemt tidspunkt. Begivenhedsdata er næsten allestedsnærværende i nutidige applikationer. Fra de klassiske applikationslogfiler til moderne sensordata genereret af ting, det er praktisk talt overalt. Disse er ofte karakteriseret ved maskinlæsbar information genereret i massiv skala.

De styrer flere funktioner som forudsigelse, automatisering, kommunikation og integration for at nævne nogle få. Derudover er de af betydning i hændelsesdrevet arkitektur.

2.2. Hvad er Apache Druid?

Apache Druid er en realtidsanalysedatabase designet til hurtig analyse over hændelsesorienterede data. Druid blev startet i 2011, open source under GPL-licensen i 2012 og flyttet til Apache-licens i 2015. Det administreres af Apache Foundation med samfundsbidrag fra flere organisationer. Det giver indtagelse i realtid, hurtig forespørgsel og høj tilgængelighed.

Navnet Druid refererer til det faktum, at dets arkitektur kan skifte for at løse forskellige typer dataproblemer. Det bruges ofte i business intelligence-applikationer til at analysere en stor mængde realtids- og historiske data.

3. Druid arkitektur

Druid er en kolonneorienteret og distribueret datakilde skrevet i Java. Det er i stand til at indtage store mængder hændelsesdata og tilbyde forespørgsler med lav latenstid oven på disse data. Desuden giver det muligheden for at skære og skære data vilkårligt.

Det er ret interessant at forstå, hvordan Druid-arkitektur understøtter disse funktioner. I dette afsnit gennemgår vi nogle af de vigtige dele af Druid-arkitekturen.

3.1. Design af datalagring

Det er vigtigt at forstå, hvordan Druid strukturer og lagrer sine data, hvilket giver mulighed for partitionering og distribution. Druid partitionerer dataene som standard under behandlingen og gemmer dem i klumper og segmenter:

Druid gemmer data i det, vi kender som "datakilde", som logisk ligner tabeller i relationsdatabaser. En Druid-klynge kan håndtere flere datakilder parallelt og indtages fra forskellige kilder.

Hver datakilde er opdelt - baseret på tid, som standard og yderligere baseret på andre attributter, hvis det er konfigureret. EN tidsinterval med data er kendt som en "klump" - for eksempel en times data, hvis data er opdelt efter timen.

Hver klump er yderligere opdelt i et eller flere "segmenter", som er enkeltfiler, der består af mange datarækker. En datakilde kan have alt fra et par segmenter til millioner af segmenter.

3.2. Druide processer

Druid har en multi-proces og distribueret arkitektur. Derfor kan hver proces skaleres uafhængigt, så vi kan skabe fleksible klynger. Lad os forstå de vigtige processer, der er en del af Druid:

• Koordinator: Denne proces er primært ansvarlig for segmentadministration og distribution og kommunikerer med historiske processer for at indlæse eller slippe segmenter baseret på konfigurationer
• Overlord: Dette er den vigtigste proces, der er ansvarlig for at acceptere opgaver, koordinere opgavefordeling, skabe låse omkring opgaver og returnere status til opkaldere
• Mægler: Dette er den proces, som alle forespørgsler sendes til for at blive udført i en distribueret klynge; det samler metadata fra Zookeeper og dirigerer forespørgsler til processer med de rigtige segmenter
• Router: Dette er en valgfri proces, der kan bruges til at dirigere forespørgsler til forskellige mæglerprocesser, hvilket giver forespørgselsisolering til forespørgsler for vigtigere data
• Historisk: Dette er de processer, der lagrer data, der kan spørges; de opretholder en konstant forbindelse med Zookeeper og ser efter segmentoplysninger, som de skal indlæse og tjene
• MiddleManager: Dette er arbejdsprocesserne, der udfører de indsendte opgaver; de videresender opgaverne til Peons, der kører i separate JVM'er, hvilket giver ressource- og logisolering

3.3. Eksterne afhængigheder

Bortset fra kerneprocesserne, Druid afhænger af flere eksterne afhængigheder for at klyngen fungerer som forventet.

Lad os se, hvordan en Druid-klynge dannes sammen med kerneprocesser og eksterne afhængigheder:

Druid bruger dyb lagring for at gemme alle data, der er blevet indtaget ind i systemet. Disse bruges ikke til at svare på forespørgslerne, men bruges som sikkerhedskopi af data og til at overføre data mellem processer. Disse kan være alt fra et lokalt filsystem til en distribueret objektbutik som S3 og HDFS.

Det metadatalagring bruges til at holde metadata for delt system ligesom oplysninger om segmentbrug og opgaveoplysninger. Det bruges dog aldrig til at gemme de faktiske data. Det er en relationsdatabase som Apache Derby, PostgreSQL eller MySQL.

Druid brug Apache Zookeeper til styring af den aktuelle klyngetilstand. Det letter en række operationer i en Druid-klynge som valg af koordinator / overlordleder, segmentpubliceringsprotokol og segment load / drop-protokol.

4. Druid-opsætning

Druid er designet til at blive implementeret som en skalerbar, fejltolerant klynge. Imidlertid, opsætning af en Druid-klynge af produktionskvalitet er ikke trivielt. Som vi har set tidligere, er der mange processer og eksterne afhængigheder at konfigurere og konfigurere. Da det er muligt at oprette en klynge på en fleksibel måde, skal vi være opmærksomme på vores krav for at indstille individuelle processer korrekt.

Også Druid understøttes kun i Unix-lignende miljøer og ikke i Windows. Desuden kræves Java 8 eller nyere for at køre Druid-processer. Der er flere konfigurationer af en enkelt server til rådighed til opsætning af Druid på en enkelt maskine til at køre selvstudier og eksempler. For at køre en produktionsarbejdsbelastning anbefales det imidlertid at oprette en fuldgyldig Druid-klynge med flere maskiner.

Med henblik på denne vejledning skal vi opsæt Druid på en enkelt maskine ved hjælp af det officielle Docker-billede offentliggjort på Docker Hub. Dette giver os også mulighed for at køre Druid på Windows, som, som vi har diskuteret tidligere, ellers ikke understøttes. Der er en Docker-komponentfil tilgængelig, som opretter en container til hver Druid-proces og dens eksterne afhængigheder.

Vi skal give Druid konfigurationsværdier som miljøvariabler. Den nemmeste måde at opnå dette på er at give en fil kaldet “miljø” i samme bibliotek som Docker-komponentfilen.

Når vi først har Docker-komponenten og miljøfilen på plads, er det at starte Druid så simpelt som at køre en kommando i samme bibliotek:

docker-komponere op

Dette åbner alle de containere, der kræves til en enkelt maskindruidopsætning. Vi skal være forsigtige med at give nok hukommelse til Docker-maskinen, da Druid bruger en betydelig mængde ressourcer.

5. Indtagelse af data

Det første skridt i retning af at opbygge en datarørledning ved hjælp af Druid er at indlæse data i Druid. Det her proces kaldes dataindtagelse eller indeksering i Druid-arkitektur. Vi er nødt til at finde et passende datasæt for at fortsætte med denne vejledning.

Nu, som vi har samlet indtil videre, skal vi samle data, der er begivenheder og har en vis tidsmæssig karakter, for at få mest muligt ud af Druid-infrastrukturen.

Den officielle guide til Druid bruger enkle og elegante data, der indeholder Wikipedia-sidedigeringer til en bestemt dato. Vi fortsætter med at bruge det til vores tutorial her.

5.1. Datamodel

Lad os begynde med at undersøge strukturen på de data, vi har med os. Det meste af den datarørledning, vi opretter, er ret følsom over for dataanomalier, og det er derfor nødvendigt at rydde op i dataene så meget som muligt.

Selvom der er sofistikerede måder og værktøjer til at udføre dataanalyse, begynder vi med visuel inspektion. En hurtig analyse afslører det inputdataene har hændelser fanget i JSON-format med en enkelt begivenhed, der indeholder typiske attributter:

{"time": "2015-09-12T02: 10: 26.679Z", "channel": "# pt.wikipedia", "cityName": null, "comment": "Houveram problemas na última edição e tive de refazê- las, junto com som atualizações da página. "," countryIsoCode ":" BR "," countryName ":" Brazil "," isAnonymous ": true," isMinor ": false," isNew ": false," isRobot ": false , "isUnpatrolled": true, "metroCode": null, "namespace": "Main", "page": "Catarina Muniz", "regionIsoCode": null, "regionName": null, "user": "181.213.37.148 "," delta ": 197," tilføjet ": 197," slettet ": 0}

Mens der er en række attributter, der definerer denne begivenhed, er der et par, der er af særlig interesse for os, når vi arbejder med Druid:

• Tidsstempel
• Dimensioner
• Metrics

Druid kræver en bestemt attribut, der skal identificeres som en tidsstempelkolonne. I de fleste situationer er Druids dataparser i stand til automatisk at registrere den bedste kandidat. Men vi har altid et valg at vælge imellem, især hvis vi ikke har en passende attribut i vores data.

Dimensioner er de attributter, som Druid gemmer som de er. Vi kan bruge dem til ethvert formål som at gruppere, filtrere eller anvende aggregatorer. Vi har et valg at vælge dimensioner i indtagelsesspecifikationen, som vi diskuterer yderligere i vejledningen.

Metrikker er de attributter, der i modsætning til dimensioner lagres i aggregeret form som standard. Vi kan vælge en aggregeringsfunktion, som Druid skal anvende på disse attributter under indtagelse. Sammen med oprulning aktiveret kan disse føre til kompakte datarepræsentationer.

5.2. Indtagelsesmetoder

Nu vil vi diskutere forskellige måder, hvorpå vi kan udføre dataindtagelsen i Druid. Typisk streamer begivenhedsdrevne data i naturen, hvilket betyder, at de fortsætter med at generere i forskellige tempo over tid, som Wikipedia-redigeringer.

Vi kan dog have data, der er batchet i en periode, hvor data er mere statiske, som alle Wikipedia-redigeringer, der skete sidste år.

Vi kan også have forskellige dataanvendelsessager at løse, og Druid har fantastisk support til de fleste af dem. Lad os gå over to af de mest almindelige måder at bruge Druid i en datapipeline:

• Streaming Indtagelse
• Partiindtagelse

Det mest almindelige måde at indtage data på Druid på er Apache Streaming-tjenesten, hvor Druid kan læse data direkte fra Kafka. Druid understøtter også andre platforme som Kinesis. Vi er nødt til at starte vejledere på Overload-processen, som opretter og administrerer Kafka-indekseringsopgaver. Vi kan starte supervisoren ved at indsende en supervisor-specifikation som en JSON-fil over HTTP POST-kommandoen i Overload-processen.

Alternativt kan vi indtage data i batch - for eksempel fra en lokal eller ekstern fil. Det giver et valg til Hadoop-baseret batchindtagelse til indtagelse af data fra Hadoop-filsystemet i Hadoop-filformatet. Mere almindeligt kan vi vælge den oprindelige batchindtagelse enten sekventielt eller parallelt. Det er en mere bekvem og enklere tilgang, da den ikke har nogen eksterne afhængigheder.

5.3. Definition af opgavespecifikation

Til denne vejledning skal vi oprette en oprindelig batchindtagelsesopgave for inputdataene vi har. Vi har mulighed for at konfigurere opgaven fra Druid-konsollen, hvilket giver os en intuitiv grafisk grænseflade. Alternativt, vi kan definere opgavespecifikationen som en JSON-fil og sende den til overlordsprocessen ved hjælp af et script eller kommandolinjen.

Lad os først definere en simpel opgave spec til indtagelse af vores data i en fil kaldet wikipedia-index.json:

{"type": "index_parallel", "spec": {"dataSchema": {"dataSource": "wikipedia", "dimensionsSpec": {"dimensions": ["channel", "cityName", "comment", " countryIsoCode "," countryName "," isAnonymous "," isMinor "," isNew "," isRobot "," isUnpatrolled "," metroCode "," namespace "," page "," regionIsoCode "," regionName "," user " , {"name": "tilføjet", "type": "long"}, {"name": "slettet", "type": "long"}, {"name": "delta", "type": "long"}]}, "timestampSpec": {"column": "time", "format": "iso"}, "metricsSpec": [], "granularitySpec": {"type": "uniform", " segmentGranularity ":" day "," queryGranularity ":" none "," intervals ": [" 2015-09-12 / 2015-09-13 "]," rollup ": false}}," ioConfig ": {" type ":" index_parallel "," inputSource ": {" type ":" local "," baseDir ":" quickstart / tutorial / "," filter ":" wikiticker-2015-09-12-sampled.json.gz "} , "inputFormat": {"type": "json"}, "appendToExisting": false}, "tuningConfig": {"type": "index_parallel", "maxRowsPerSegment": 5000000, "maxRo wsInMemory ": 25000}}}

Lad os forstå denne opgave spec med hensyn til de grundlæggende, vi har gennemgået i tidligere underafsnit:

• Vi har valgt indeks_parallel opgave, som giver os indfødt batchindtagelse parallelt
• Datakilden, vi bruger i denne opgave, har navnet “wikipedia ”
• Tidsstemplet for vores data kommer fra attributten "tid"
• Der er et antal dataattributter, vi tilføjer som dimensioner
• Vi bruger ikke nogen metrics til vores data i den aktuelle opgave
• Roll-up, som er aktiveret som standard, skal deaktiveres for denne opgave
• Inputkilden til opgaven er en lokal fil med navnet wikiticker-2015-09-12-sampled.json.gz
• Vi bruger ikke nogen sekundær partition, som vi kan definere i tuningConfig

Denne opgave spec antager, at vi har downloadet datafilenwikiticker-2015-09-12-sampled.json.gz og holdt den på den lokale maskine, hvor Druid kører. Dette kan være vanskeligere, når vi kører Druid som en Docker-container. Heldigvis Druid leveres med disse eksempeldata til stede som standard på stedet hurtigstart / tutorial.

5.4. Aflevering af opgavespecifikationen

Endelig kan vi sende denne opgavespecifikation til overlordsprocessen via kommandolinjen ved hjælp af et værktøj som krølle:

curl -X 'POST' -H 'Content-Type: application / json' -d @ wikipedia-index.json // localhost: 8081 / druid / indexer / v1 / task

Normalt, ovenstående kommando returnerer ID'et for opgaven hvis indsendelsen er vellykket. Vi kan kontrollere tilstanden for vores indtagelsesopgave gennem Druid-konsollen eller ved at udføre forespørgsler, som vi gennemgår i næste afsnit.

5.5. Avancerede indtagelseskoncepter

Druid er bedst egnet til, når vi har en massiv skala af data at håndtere - bestemt ikke den slags data, vi har set i denne vejledning! For at aktivere funktioner i skala skal Druid-arkitektur nu give passende værktøjer og tricks.

Mens vi ikke bruger dem i denne vejledning, så lad os hurtigt diskutere oprulning og partitionering.

Begivenhedsdata kan snart vokse i størrelse til massive volumener, hvilket kan påvirke den forespørgsel, vi kan opnå. I mange scenarier kan det være muligt for os at opsummere data over tid. Dette er, hvad vi kender som roll-up i Druid. Når oprulning er aktiveret, gør Druid en indsats for at oprulningsrækker med identiske dimensioner og tidsstempler under indtagelse. Selvom det kan spare plads, fører oprulning til et tab af forespørgselspræcision, og derfor skal vi bruge det rationelt.

En anden potentiel måde at opnå bedre ydeevne i lyset af stigende datamængde er at distribuere dataene og dermed arbejdsbyrden. Som standard Druid partitionerer dataene baseret på tidsstempler i tidsstykker indeholdende et eller flere segmenter. Desuden kan vi beslutte at udføre sekundær partitionering ved hjælp af naturlige dimensioner for at forbedre datalokaliteten. Desuden sorterer Druid data inden for hvert segment efter tidsstempel først og derefter efter andre dimensioner, som vi konfigurerer.

6. Forespørgsel om data

Når vi har udført dataindtagelsen, skal den være klar til os. Der er flere måder at forespørge på data i Druid. Det den enkleste måde at udføre en forespørgsel i Druid på er via Druid-konsollen. Vi kan dog også udføre forespørgsler ved at sende HTTP-kommandoer eller ved hjælp af et kommandolinjeværktøj.

De to fremtrædende måder at konstruere forespørgsler i Druid er indfødte forespørgsler og SQL-lignende forespørgsler. Vi skal til konstruer nogle grundlæggende forespørgsler på begge disse måder og send dem via HTTP ved brug af krølle. Lad os finde ud af, hvordan vi kan oprette nogle enkle forespørgsler om de data, vi har indtaget tidligere i Druid.

6.1. Indfødte forespørgsler

Indfødte forespørgsler i Druid bruge JSON-objekter, som vi kan sende til en mægler eller en router til behandling. Vi kan sende forespørgslerne via HTTP POST-kommandoen blandt andet for at gøre det samme.

Lad os oprette en JSON-fil med navnet simple_query_native.json:

{"queryType": "topN", "dataSource": "wikipedia", "intervals": ["2015-09-12 / 2015-09-13"], "granularity": "all", "dimension": " side "," metric ":" count "," threshold ": 10," aggregations ": [{" type ":" count "," name ":" count "}]}

Dette er en simpel forespørgsel, der henter de ti største sider, der modtog det øverste antal sideredigeringer mellem den 12. og 13. september 2019.

Lad os sende dette via HTTP ved hjælp af krølle:

curl -X 'POST' -H 'Content-Type: application / json' -d @ simple_query_native.json // localhost: 8888 / druid / v2? smuk

Dette svar indeholder detaljerne om de ti største sider i JSON-format:

[{"tidsstempel": "2015-09-12T00: 46: 58.771Z", "resultat": [{"count": 33, "page": "Wikipedia: Vandalismusmeldung"}, {"count": 28, " side ":" Bruger: Cyde / Liste over kandidater til hurtig sletning / underside "}, {" count ": 27," page ":" Jeremy Corbyn "}, {" count ": 21," page ":" Wikipedia: Administrators opslagstavle / hændelser "}, {" count ": 20," page ":" Flavia Pennetta "}, {" count ": 18," page ":" Total Drama Presents: The Ridonculous Race "}, {" count ": 18," page ":" Brugerdiskussion: Dudeperson176123 "}, {" count ": 18," page ":" Wikipedia: Le Bistro / 12 septembre 2015 "}, {" count ": 17," page ": "Wikipedia: I nyhederne / kandidaterne"}, {"count": 17, "page": "Wikipedia: Anmodninger om sidebeskyttelse"}]}]

6.2. Druid SQL

Druid har en indbygget SQL-lag, som giver os friheden til at konstruere forespørgsler i velkendte SQL-lignende konstruktioner. Det udnytter Apache Calcite til at analysere og planlægge forespørgslerne. Druid SQL konverterer dog SQL-forespørgsler til oprindelige forespørgsler på forespørgselsmægleren, inden de sendes til dataprocesser.

Lad os se, hvordan vi kan oprette den samme forespørgsel som før, men ved hjælp af Druid SQL. Som før opretter vi en JSON-fil med navnet simple_query_sql.json:

{"forespørgsel": "VÆLG side, COUNT (*) SOM tæller / FRA wikipedia HVOR \" __ tid \ "/ MELLEM TIMESTAMP '2015-09-12 00:00:00' OG TIMESTAMP '2015-09-13 00:00 : 00 '/ GRUPPE PÅ side BESTILLING VED redigeringer DESC LIMIT 10 "}

Bemærk, at forespørgslen er opdelt i flere linjer for læsbarhed, men den skal vises på en enkelt linje. Igen, som før, POSTER vi denne forespørgsel over HTTP, men til et andet slutpunkt:

curl -X 'POST' -H 'Content-Type: application / json' -d @ simple_query_sql.json // localhost: 8888 / druid / v2 / sql

Outputtet skal være meget lig det, vi opnåede tidligere med den oprindelige forespørgsel.

6.3. Forespørgselstyper

Vi så i det tidligere afsnit en type forespørgsel, hvor vi hentede de ti bedste resultater for metricen "count" baseret på et interval. Dette er kun en type forespørgsel, som Druid understøtter, og den er kendt som TopN forespørgsel. Selvfølgelig kan vi gøre dette enkelt TopN forespørgsel meget mere interessant ved hjælp af filtre og aggregeringer. Men det er ikke inden for denne tutorial. Der er dog flere andre forespørgsler i Druid, der kan interessere os.

Nogle af de populære inkluderer Timeseries og GroupBy.

Tidsserier forespørgsler returnerer et array med JSON-objekter, hvor hvert objekt repræsenterer en værdi som beskrevet i tidsserieforespørgslen - for eksempel det daglige gennemsnit af en dimension i den sidste måned.

GroupBy forespørgsler returnerer et array med JSON-objekter, hvor hvert objekt repræsenterer en gruppering som beskrevet i gruppe-for-forespørgslen. For eksempel kan vi forespørge efter det daglige gennemsnit af en dimension for den sidste måned grupperet efter en anden dimension.

Der er flere andre forespørgselstyper, herunder Scanning, Søg, TimeBoundary, SegmentMetadataog DatakildeMetadata.

6.4. Avancerede forespørgselskoncepter

Druid tilbyder nogle komplekse metoder til at skabe sofistikerede forespørgsler til oprettelse af interessante dataprogrammer. Disse inkluderer forskellige måder at skære og skære data på, mens de stadig er i stand til at levere utrolig forespørgsel.

Mens en detaljeret diskussion af dem ligger uden for omfanget af denne vejledning, lad os diskutere nogle af de vigtige som Joins and Lookups, Multitenancy og Query Caching.

Druid understøtter to måder at slutte sig til dataene på. Den første er tilslutningsoperatørerne, og den anden er forespørgselstidsopslag. For bedre forespørgselsydeevne anbefales det dog at undgå sammenføjninger med forespørgselstid.

Multitenancy refererer til funktionen ved at understøtte flere lejere på den samme Druid-infrastruktur, mens de stadig tilbyder dem logisk isolation. Det er muligt at opnå dette i Druid gennem separate datakilder pr. Lejer eller datadeling af lejeren.

Og endelig er caching af forespørgsler nøglen til ydeevne i datakrævende applikationer. Druid understøtter caching af forespørgselsresultater i segmentet og forespørgselsresultatniveauer. Yderligere kan cachedataene findes i hukommelsen eller i ekstern vedvarende lagring.

7. Sprogbindinger

Selvom Druid har fremragende support til at oprette indtagelsesspecifikationer og definere forespørgsler i JSON, er det kan være kedeligt nogle gange at definere disse forespørgsler i JSON, især når forespørgsler bliver komplekse. Desværre tilbyder Druid ikke et klientbibliotek på noget specifikt sprog, der kan hjælpe os i denne henseende. Men der er en hel del sprogbindinger, der er udviklet af samfundet. Et sådant klientbibliotek er også tilgængeligt til Java.

Vi ser hurtigt, hvordan vi kan bygge TopN forespørgsel, vi tidligere brugte ved hjælp af dette klientbibliotek i Java.

Lad os begynde med at definere den krævede afhængighed i Maven:

 in.zapr.druid druidry 2.14 

Herefter skal vi kunne bruge klientbiblioteket og oprette vores TopN forespørgsel:

DateTime startTime = ny DateTime (2015, 9, 12, 0, 0, 0, DateTimeZone.UTC); DateTime endTime = ny DateTime (2015, 9, 13, 0, 0, 0, DateTimeZone.UTC); Intervalinterval = nyt Interval (startTime, endTime); Granularitet granularitet = ny SimpleGranularity (ForuddefineretGranularity.ALL); DruidDimension dimension = ny SimpleDimension ("side"); TopNMetric metric = ny SimpleMetric ("count"); DruidTopNQuery-forespørgsel = DruidTopNQuery.builder () .dataSource ("wikipedia"). Dimension (dimension). Tærskel (10). TopNMetric (metrisk). Granularitet (granularitet). Filter (filter). Aggregater (Arrays.asList (ny LongSumAggregator) "count", "count"))) .intervals (Collections.singletonList (interval)). build ();

Efter dette kan vi simpelthen generere den krævede JSON-struktur, som vi kan bruge i HTTP POST-opkaldet:

ObjectMapper-kortlægger = ny ObjectMapper (); Streng krævetJson = mapper.writeValueAsString (forespørgsel);

8. Konklusion

I denne vejledning gennemgik vi det grundlæggende i begivenhedsdata og Apache Druid-arkitektur.

Desuden oprettede vi en primær Druid-klynge ved hjælp af Docker-containere på vores lokale maskine. Derefter gennemgik vi også processen med at indtage et prøvedatasæt i Druid ved hjælp af den oprindelige batchopgave. Efter dette så vi de forskellige måder, vi har til at forespørge vores data i Druid. Endelig gik vi gennem et klientbibliotek i Java for at konstruere Druid-forespørgsler.

Vi har lige skrabet overfladen af ​​funktioner, som Druid har at tilbyde. Der er flere muligheder, hvor Druid kan hjælpe os med at opbygge vores datapipeline og oprette dataprogrammer. De avancerede indtagelses- og forespørgselsfunktioner er de åbenlyse næste trin at lære for effektivt at udnytte kraften fra Druid.

Desuden skal oprettelse af en passende Druid-klynge, der skalerer de enkelte processer efter behov, være målet for at maksimere fordelene.