Hendelsesdrevne data med Apache Druid

1. Introduksjon

I denne opplæringen vil vi forstå hvordan vi kan jobbe med hendelsesdata og Apache Druid. Vi vil dekke det grunnleggende om hendelsesdata og Druid-arkitektur. Som en del av det, vil vi lage en enkel datarørledning som utnytter forskjellige funksjoner i Druid som dekker ulike moduser for inntak av data og forskjellige måter å spørre de forberedte dataene på.

2. Grunnleggende konsepter

Før vi kaster oss inn i operasjonsdetaljene til Apache Druid, la oss først gå gjennom noen av de grunnleggende konseptene. Plassen vi er interessert i er sanntidsanalyser av hendelsesdata i massiv skala.

Derfor er det viktig å forstå hva vi mener med hendelsesdata og hva krever det for å analysere dem i sanntid i stor skala.

2.1. Hva er hendelsesdata?

Hendelsesdata refererer til et stykke informasjon om en endring som skjer på et bestemt tidspunkt. Hendelsesdata er nesten allestedsnærværende i dagens applikasjoner. Fra de klassiske applikasjonsloggene til moderne sensordata generert av ting, er det praktisk talt overalt. Disse er ofte preget av maskinlesbar informasjon generert i massiv skala.

De driver flere funksjoner som prediksjon, automatisering, kommunikasjon og integrering, for å nevne noen. I tillegg har de betydning i hendelsesdrevet arkitektur.

2.2. Hva er Apache Druid?

Apache Druid er en analysedatabase i sanntid designet for rask analyse over hendelsesorienterte data. Druid ble startet i 2011, åpen fra GPL-lisensen i 2012, og flyttet til Apache License i 2015. Den administreres av Apache Foundation med bidrag fra fellesskapet fra flere organisasjoner. Det gir sanntid svelging, rask søkeytelse og høy tilgjengelighet.

Navnet Druid refererer til det faktum at arkitekturen kan skifte for å løse forskjellige typer dataproblemer. Det brukes ofte i business intelligence-applikasjoner for å analysere et stort volum sanntid og historiske data.

3. Druid arkitektur

Druid er en kolonneorientert og distribuert datakilde skrevet i Java. Den er i stand til å innta store mengder hendelsesdata og tilby spørsmål med lav latens på toppen av disse dataene. Videre gir det muligheten til å skjære og skjære dataene vilkårlig.

Det er ganske interessant å forstå hvordan Druid-arkitektur støtter disse funksjonene. I denne delen vil vi gå gjennom noen av de viktige delene av Druid-arkitekturen.

3.1. Datalagringsdesign

Det er viktig å forstå hvordan Druid strukturerer og lagrer dataene sine, noe som muliggjør partisjonering og distribusjon. Druid partisjonerer dataene som standard under behandlingen og lagrer dem i biter og segmenter:

Druid lagrer data i det vi kjenner som "datakilde", som logisk sett ligner på tabeller i relasjonsdatabaser. En Druid-klynge kan håndtere flere datakilder parallelt, inntatt fra forskjellige kilder.

Hver datakilde er partisjonert - basert på tid, som standard, og videre basert på andre attributter hvis det er konfigurert. EN tidsområde med data er kjent som en "del" - for eksempel en times data hvis data er delt etter timen.

Hver klump er videre delt inn i ett eller flere "segmenter", som er enkeltfiler som består av mange datarader. En datakilde kan ha alt fra noen få segmenter til millioner av segmenter.

3.2. Druide prosesser

Druid har en flerprosessert og distribuert arkitektur. Derfor kan hver prosess skaleres uavhengig, slik at vi kan lage fleksible klynger. La oss forstå de viktige prosessene som er en del av Druid:

  • Koordinator: Denne prosessen er hovedsakelig ansvarlig for segmentadministrasjon og distribusjon og kommuniserer med historiske prosesser for å laste eller slippe segmenter basert på konfigurasjoner
  • Overlord: Dette er hovedprosessen som er ansvarlig for å akseptere oppgaver, koordinere oppgavefordeling, opprette låser rundt oppgaver og returnere status til innringere
  • Megler: Dette er prosessen som alle spørsmål sendes for å utføres i en distribuert klynge; den samler metadata fra Zookeeper og ruter spørsmål til prosesser som har de rette segmentene
  • Ruter: Dette er en valgfri prosess som kan brukes til å dirigere spørsmål til forskjellige meglerprosesser, og dermed gi spørringsisolering til spørsmål for viktigere data
  • Historisk: Dette er prosessene som lagrer data som kan spørres; de opprettholder en konstant forbindelse med Zookeeper og ser etter segmentinformasjon de må laste inn og servere
  • MiddleManager: Dette er arbeidsprosessene som utfører de innsendte oppgavene; de videresender oppgavene til Peons som kjører i separate JVM-er, og gir dermed ressurs- og loggisolasjon

3.3. Eksterne avhengigheter

Bortsett fra kjerneprosessene, Druid avhenger av flere eksterne avhengigheter for at klyngen skal fungere som forventet.

La oss se hvordan en Druid-klynge dannes sammen med kjerneprosesser og eksterne avhengigheter:

Druid bruker dyp lagring for å lagre data som er inntatt inn i systemet. Disse brukes ikke til å svare på spørsmålene, men brukes som sikkerhetskopi av data og for å overføre data mellom prosesser. Dette kan være alt fra et lokalt filsystem til en distribuert objektbutikk som S3 og HDFS.

De metadatalagring brukes til å holde metadata for delt system som segmentbruksinformasjon og oppgaveinformasjon. Imidlertid brukes den aldri til å lagre de faktiske dataene. Det er en relasjonsdatabase som Apache Derby, PostgreSQL eller MySQL.

Druid bruk Apache Dyrehage for styring av gjeldende klyngetilstand. Det letter en rekke operasjoner i en Druid-klynge som valg av koordinator / overordnet leder, segmentpubliseringsprotokoll og segmentbelastning / slipp-protokoll.

4. Druidoppsett

Druid er designet for å distribueres som en skalerbar, feiltolerant klynge. Derimot, å sette opp en Druid-klynge i produksjonsklasse er ikke trivielt. Som vi har sett tidligere, er det mange prosesser og eksterne avhengigheter å sette opp og konfigurere. Siden det er mulig å lage en klynge på en fleksibel måte, må vi ta hensyn til våre krav for å sette opp individuelle prosesser på riktig måte.

Også Druid støttes bare i Unix-lignende miljøer og ikke på Windows. Videre kreves Java 8 eller nyere for å kjøre Druid-prosesser. Det er flere enkeltserverkonfigurasjoner tilgjengelig for å konfigurere Druid på en enkelt maskin for å kjøre opplæringsprogrammer og eksempler. Imidlertid anbefales det å sette opp en fullverdig Druid-klynge med flere maskiner for å kjøre en produksjonsarbeidsbelastning.

For formålet med denne opplæringen, vil vi sette opp Druid på en enkelt maskin ved hjelp av det offisielle Docker-bildet publisert på Docker Hub. Dette gjør at vi også kan kjøre Druid på Windows, som, som vi har diskutert tidligere, ellers ikke støttes. Det er en Docker-komponentfil tilgjengelig, som lager en container for hver Druid-prosess og dens eksterne avhengigheter.

Vi må gi konfigurasjonsverdier til Druid som miljøvariabler. Den enkleste måten å oppnå dette på er å gi en fil kalt “miljø” i samme katalog som Docker-komponentfilen.

Når vi har komponenten Docker og miljøfilen på plass, er det å starte opp Druid så enkelt som å kjøre en kommando i samme katalog:

docker-komponere opp

Dette vil hente opp alle beholderne som kreves for et enkelt maskin-Druid-oppsett. Vi må være forsiktige med å skaffe nok minne til Docker-maskinen, siden Druid bruker en betydelig mengde ressurser.

5. Inntak av data

Det første trinnet mot å bygge en datarørledning med Druid er å laste inn data i Druid. Dette prosessen er referert til som datainntak eller indeksering i Druid-arkitektur. Vi må finne et passende datasett for å fortsette med denne veiledningen.

Nå som vi har samlet oss så langt, må vi plukke opp data som er hendelser og har noe tidsmessig karakter, for å få mest mulig ut av Druid-infrastrukturen.

Den offisielle guiden for Druid bruker enkle og elegante data som inneholder Wikipedia-sideredigeringer for en bestemt dato. Vi fortsetter å bruke det til opplæringen vår her.

5.1. Datamodell

La oss begynne med å undersøke strukturen til dataene vi har med oss. Det meste av datarørledningen vi lager, er ganske følsom for dataavvik, og det er derfor nødvendig å rydde opp i dataene så mye som mulig.

Selv om det er sofistikerte måter og verktøy for å utføre dataanalyse, begynner vi med visuell inspeksjon. En rask analyse avslører det inngangsdataene har hendelser fanget i JSON-format, med en enkelt hendelse som inneholder 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," lagt til ": 197," slettet ": 0}

Selv om det er ganske mange attributter som definerer denne hendelsen, er det noen få som er av spesiell interesse for oss når vi jobber med Druid:

  • Tidsstempel
  • Dimensjoner
  • Beregninger

Druid krever et bestemt attributt for å identifisere som en tidsstempelkolonne. I de fleste situasjoner er Druids dataparser i stand til automatisk å oppdage den beste kandidaten. Men vi har alltid et valg å velge mellom, spesielt hvis vi ikke har en passende egenskap i dataene våre.

Dimensjoner er attributtene som Druid lagrer som de er. Vi kan bruke dem til alle formål som gruppering, filtrering eller bruk av aggregatorer. Vi har et valg å velge dimensjoner i inntaksspesifikasjonen, som vi vil diskutere videre i opplæringen.

Beregninger er attributtene som, i motsetning til dimensjoner, lagres i aggregert form som standard. Vi kan velge en aggregeringsfunksjon for Druid som skal brukes på disse attributtene under inntak. Sammen med opprulling aktivert, kan disse føre til kompakte datarepresentasjoner.

5.2. Svelgingsmetoder

Nå skal vi diskutere forskjellige måter vi kan utføre datainntaket i Druid. Vanligvis strømmer hendelsesdrevne data i naturen, noe som betyr at de fortsetter å generere i forskjellige tempo over tid, som Wikipedia-redigeringer.

Imidlertid kan det hende vi har data samlet i en periode å gå over, der data er mer statiske i naturen, som alle Wikipedia-redigeringer som skjedde i fjor.

Vi kan også ha forskjellige databrukssaker å løse, og Druid har fantastisk støtte for de fleste av dem. La oss gå over to av de vanligste måtene å bruke Druid i en datarørledning:

  • Streaming Svelging
  • Batched Svelging

De vanligste måten å innta data i Druid er gjennom Apache Streaming-tjenesten, hvor Druid kan lese data direkte fra Kafka. Druid støtter også andre plattformer som Kinesis. Vi må starte veiledere på Overload-prosessen, som oppretter og administrerer Kafka-indekseringsoppgaver. Vi kan starte veilederen ved å sende inn en veileder-spesifikasjon som en JSON-fil over HTTP POST-kommandoen i Overload-prosessen.

Alternativt kan vi innta data i batch - for eksempel fra en lokal eller ekstern fil. Det tilbyr et valg for Hadoop-basert batchinntak for inntak av data fra Hadoop-filsystemet i Hadoop-filformatet. Oftere kan vi velge den innfødte batchinntaket enten sekvensielt eller parallelt. Det er en mer praktisk og enklere tilnærming da den ikke har noen eksterne avhengigheter.

5.3. Definere oppgavespesifikasjonen

For denne opplæringen, vil vi sette opp en opprinnelig batchinntaksoppgave for inndataene vi har. Vi har muligheten til å konfigurere oppgaven fra Druid-konsollen, noe som gir oss et intuitivt grafisk grensesnitt. Alternativt, vi kan definere oppgavespesifikasjonen som en JSON-fil og sende den til overlordprosessen ved hjelp av et skript eller kommandolinjen.

La oss først definere en enkel oppgavespesifikasjon for inntak av dataene våre i en fil som heter 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": "lagt til", "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}}}

La oss forstå denne oppgavespesifikasjonen med hensyn til det grunnleggende vi har gått gjennom i tidligere underavsnitt:

  • Vi har valgt indeks_parallell oppgave, som gir oss innfødte batchinntak parallelt
  • Datakilden vi skal bruke i denne oppgaven har navnet “wikipedia ”
  • Tidsstempelet for dataene våre kommer fra attributtet "tid"
  • Det er en rekke dataattributter vi legger til som dimensjoner
  • Vi bruker ingen beregninger for dataene våre i den aktuelle oppgaven
  • Roll-up, som er aktivert som standard, bør deaktiveres for denne oppgaven
  • Inndatakilden for oppgaven er en lokal fil som heter wikiticker-2015-09-12-sampled.json.gz
  • Vi bruker ikke noen sekundær partisjon, som vi kan definere i tuningConfig

Denne oppgaven spesifikasjon antar at vi har lastet ned datafilenwikiticker-2015-09-12-sampled.json.gz og holdt den på den lokale maskinen der Druid kjører. Dette kan være vanskeligere når vi kjører Druid som en Docker-container. Heldigvis Druid leveres med disse eksempeldataene som standard på stedet hurtigstart / opplæring.

5.4. Send inn oppgavespesifikasjonen

Til slutt kan vi sende denne oppgavespesifikasjonen til overlordprosessen gjennom kommandolinjen ved hjelp av et verktøy som krølle:

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

Normalt, kommandoen ovenfor returnerer ID-en til oppgaven hvis innsendingen er vellykket. Vi kan verifisere tilstanden til inntaksoppgaven vår gjennom Druid-konsollen eller ved å utføre spørsmål, som vi vil gå gjennom i neste avsnitt.

5.5. Avanserte svelgingskonsepter

Druid er best egnet når vi har en enorm skala av data å håndtere - absolutt ikke den typen data vi har sett i denne opplæringen! Nå, for å aktivere funksjoner i stor skala, må Druid-arkitektur gi passende verktøy og triks.

Selv om vi ikke bruker dem i denne opplæringen, la oss raskt diskutere opprulling og partisjonering.

Hendelsesdata kan snart vokse i størrelse til store volumer, noe som kan påvirke spørringsytelsen vi kan oppnå. I mange scenarier kan det være mulig for oss å oppsummere data over tid. Dette er det vi kjenner som roll-up i Druid. Når opprulling er aktivert, anstrenger Druid seg for å opprullende rader med identiske dimensjoner og tidsstempler under inntak. Selv om det kan spare plass, fører opprulling til tap av presisjon, derfor må vi bruke det rasjonelt.

En annen potensiell måte å oppnå bedre ytelse på grunn av økende datavolum er å distribuere dataene og dermed arbeidsmengden. Som standard er Druid partisjonerer dataene basert på tidsstempler i tidsbiter inneholder ett eller flere segmenter. Videre kan vi bestemme oss for å gjøre sekundær partisjonering ved hjelp av naturlige dimensjoner for å forbedre datalokaliteten. Videre sorterer Druid data innen hvert segment etter tidsstempel først og deretter etter andre dimensjoner som vi konfigurerer.

6. Spørring av data

Når vi har utført datainntaket, skal det være klart for oss å spørre. Det er flere måter å spørre om data i Druid. De Den enkleste måten å utføre et spørsmål i Druid er gjennom Druid-konsollen. Vi kan imidlertid også utføre spørsmål ved å sende HTTP-kommandoer eller bruke et kommandolinjeverktøy.

De to fremtredende måtene å lage spørsmål i Druid er innfødte spørsmål og SQL-lignende spørsmål. Dro til konstruer noen grunnleggende spørsmål på begge disse måtene og send dem via HTTP ved hjelp av krølle. La oss finne ut hvordan vi kan lage noen enkle spørsmål om dataene vi har inntatt tidligere i Druid.

6.1. Innfødte spørsmål

Innfødte spørsmål i Druid bruk JSON-objekter, som vi kan sende til en megler eller en ruter for behandling. Vi kan sende spørsmålene over HTTP POST-kommandoen, blant annet for å gjøre det samme.

La oss lage 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 et enkelt spørsmål som henter de ti beste sidene som mottok det høyeste antallet sideredigeringer mellom 12. og 13. september 2019.

La oss legge ut dette over HTTP ved hjelp av krølle:

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

Dette svaret inneholder detaljene på de ti beste sidene i JSON-format:

[{"tidsstempel": "2015-09-12T00: 46: 58.771Z", "resultat": [{"count": 33, "page": "Wikipedia: Vandalismusmeldung"}, {"count": 28, " side ":" Bruker: Cyde / Liste over kandidater for rask sletting / underside "}, {" count ": 27," page ":" Jeremy Corbyn "}, {" count ": 21," page ":" Wikipedia: Administratorens oppslagstavle / hendelser "}, {" count ": 20," page ":" Flavia Pennetta "}, {" count ": 18," page ":" Total Drama Presents: The Ridonculous Race "}, {" count ": 18," page ":" Brukerdiskusjon: Dudeperson176123 "}, {" count ": 18," page ":" Wikipedia: Le Bistro / 12 septembre 2015 "}, {" count ": 17," page ": "Wikipedia: I nyhetene / Kandidatene"}, {"count": 17, "page": "Wikipedia: Forespørsler om sidebeskyttelse"}]}]

6.2. Druid SQL

Druid har en innebygd SQL-lag, som gir oss friheten til å konstruere spørsmål i kjente SQL-lignende konstruksjoner. Den utnytter Apache Calcite til å analysere og planlegge spørsmålene. Druid SQL konverterer imidlertid SQL-spørringene til innfødte spørsmål på spørsmegleren før de sendes til dataprosesser.

La oss se hvordan vi kan opprette den samme spørringen som før, men ved hjelp av Druid SQL. Som før oppretter vi en JSON-fil med navnet simple_query_sql.json:

{"query": "VELG side, COUNT (*) SOM teller / FRA wikipedia HVOR \" __ tid \ "/ MELLOM TIMESTAMP '2015-09-12 00:00:00' OG TIMESTAMP '2015-09-13 00:00 : 00 '/ GRUPPER PÅ side BESTILLING VED redigeringer DESC LIMIT 10 "}

Vær oppmerksom på at spørringen er delt inn i flere linjer for lesbarhet, men den skal vises på en enkelt linje. Igjen, som før, POSTER vi denne spørringen over HTTP, men til et annet sluttpunkt:

krøll -X 'POST' -H 'Innholdstype: applikasjon / json' -d @ simple_query_sql.json // localhost: 8888 / druid / v2 / sql

Resultatet skal være veldig likt det vi oppnådde tidligere med den opprinnelige spørringen.

6.3. Spørringstyper

Vi så, i den tidligere delen, en type spørring der vi hentet de ti beste resultatene for beregningen "antall" basert på et intervall. Dette er bare en type spørsmål som Druid støtter, og den er kjent som TopN spørsmål. Selvfølgelig kan vi gjøre dette enkelt TopN spørring mye mer interessant ved å bruke filtre og aggregasjoner. Men det er ikke innenfor rammen av denne opplæringen. Imidlertid er det flere andre spørsmål i Druid som kan interessere oss.

Noen av de populære inkluderer Timeseries og GroupBy.

Tidsserier spørringer returnerer en rekke JSON-objekter, der hvert objekt representerer en verdi som beskrevet i tidsseriespørringen - for eksempel det daglige gjennomsnittet av en dimensjon for den siste måneden.

Gruppe av spørringer returnerer en matrise med JSON-objekter, der hvert objekt representerer en gruppering som beskrevet i gruppevis-spørringen. For eksempel kan vi søke etter det daglige gjennomsnittet av en dimensjon for den siste måneden gruppert etter en annen dimensjon.

Det er flere andre spørringstyper, inkludert Skann, Søk, TimeBoundary, SegmentMetadata, og DatasourceMetadata.

6.4. Avanserte spørrekonsepter

Druid tilbyr noen komplekse metoder for å lage sofistikerte spørsmål for å lage interessante dataprogrammer. Disse inkluderer forskjellige måter å skjære opp og skjære i terninger mens du fremdeles er i stand til å gi utrolige søkeytelser.

Mens en detaljert diskusjon av dem ligger utenfor omfanget av denne opplæringen, la oss diskutere noen av de viktige som Joins and Lookups, Multitenancy og Query Caching.

Druid støtter to måter å bli med på dataene. Den første er deltaoperatørene, og den andre er spørringstidsoppslag. For bedre søkeytelse er det imidlertid tilrådelig å unngå sammenkobling av spørringstid.

Multitenancy refererer til funksjonen ved å støtte flere leietakere på samme Druid-infrastruktur mens de fremdeles gir dem logisk isolasjon. Det er mulig å oppnå dette i Druid gjennom separate datakilder per leietaker eller datapartisjonering av leieren.

Og til slutt er spørringsbuffer nøkkelen til ytelse i datakrevende applikasjoner. Druid støtter hurtigbufring av spørringsresultater i segmentet og søkeresultatnivåene. Videre kan hurtigbufferdata ligge i minnet eller i ekstern vedvarende lagring.

7. Språkbindinger

Selv om Druid har utmerket støtte for å lage inntaksspesifikasjoner og definere spørsmål i JSON, er det kan være kjedelig noen ganger å definere disse spørsmålene i JSON, spesielt når spørsmål blir kompliserte. Dessverre tilbyr Druid ikke et klientbibliotek på noe spesifikt språk for å hjelpe oss i denne forbindelse. Men det er ganske mange språkbindinger som er utviklet av samfunnet. Et slikt klientbibliotek er også tilgjengelig for Java.

Vi får raskt se hvordan vi kan bygge TopN spørring vi brukte tidligere ved å bruke dette klientbiblioteket i Java.

La oss begynne med å definere den nødvendige avhengigheten i Maven:

 in.zapr.druid druidry 2.14 

Etter dette skal vi kunne bruke klientbiblioteket og lage vårt TopN spørsmål:

DateTime startTime = new DateTime (2015, 9, 12, 0, 0, 0, DateTimeZone.UTC); DateTime endTime = ny DateTime (2015, 9, 13, 0, 0, 0, DateTimeZone.UTC); Intervallintervall = nytt intervall (starttid, sluttid); Granularity granularity = ny SimpleGranularity (ForhåndsdefinertGranularity.ALL); DruidDimension dimensjon = ny SimpleDimension ("side"); TopNMetric metric = new SimpleMetric ("count"); DruidTopNQuery spørring = DruidTopNQuery.builder () .dataSource ("wikipedia"). Dimensjon (dimensjon). Terskel (10). TopNMetric (metrisk). Granularitet (granularitet). Filter (filter). Aggregatorer (Arrays.asList (ny LongSumAggregator) "count", "count"))). intervalls (Collections.singletonList (interval)). build ();

Etter dette kan vi ganske enkelt generere den nødvendige JSON-strukturen, som vi kan bruke i HTTP POST-samtalen:

ObjectMapper mapper = ny ObjectMapper (); Streng obligatoriskJson = mapper.writeValueAsString (spørring);

8. Konklusjon

I denne opplæringen gikk vi gjennom det grunnleggende om hendelsesdata og Apache Druid-arkitektur.

Videre setter vi opp en primær Druid-klynge ved hjelp av Docker-containere på vår lokale maskin. Deretter gikk vi også gjennom prosessen med å innta et prøvedatasett i Druid ved hjelp av den opprinnelige batchoppgaven. Etter dette så vi de forskjellige måtene vi har for å spørre om dataene våre i Druid. Til slutt gikk vi gjennom et klientbibliotek i Java for å konstruere Druid-spørsmål.

Vi har nettopp skrapet overflaten av funksjoner som Druid har å tilby. Det er flere muligheter der Druid kan hjelpe oss med å bygge datarørledningen vår og lage dataprogrammer. De avanserte inntaks- og spørringsfunksjonene er de åpenbare neste trinnene for å lære, for effektivt å utnytte kraften til Druid.

Videre bør det være målet å opprette en passende Druid-klynge som skalerer de enkelte prosessene etter behov, for å maksimere fordelene.


$config[zx-auto] not found$config[zx-overlay] not found