streamalism.org

1. Bemutatkozás

Ebben az oktatóanyagban megértjük, hogyan kell dolgozni az eseményadatokkal és az Apache Druiddal. Kitérünk az eseményadatok alapjaira és a Druid architektúrára. Ennek részeként létrehozunk egy egyszerű adatcsatornát, amely kihasználja a Druid különféle funkcióit, és amely az adatgyűjtés különböző módjait és az előkészített adatok lekérdezésének különböző módjait fedi le.

2. Alapfogalmak

Mielőtt belevetnénk magunkat az Apache Druid működési részleteibe, először nézzünk át néhány alapfogalmat. A minket érdeklő tér az eseményadatok valós idejű, nagyméretű elemzése.

Ezért elengedhetetlen megérteni, hogy mit értünk eseményadatok alatt, és mi szükséges ahhoz, hogy valós időben, skálán elemezzük őket.

2.1. Mi az eseményadat?

Az eseményadatok erre utalnak egy információ egy adott időpontban bekövetkező változásról. Az eseményadatok szinte mindenütt jelen vannak a mai alkalmazásokban. A klasszikus alkalmazásnaplóktól kezdve a dolgok által generált modern szenzoradatokig gyakorlatilag mindenhol. Ezeket gyakran a géppel olvasható, tömegesen generált információk jellemzik.

Számos olyan funkciót hajtanak végre, mint az előrejelzés, az automatizálás, a kommunikáció és az integráció. Ezenkívül jelentősek az eseményvezérelt architektúrában.

2.2. Mi az Apache Druid?

Apache Druid az valós idejű elemzési adatbázis, amelyet az eseményorientált adatok feletti gyors elemzéshez terveztek. A Druid 2011-ben indult, 2012-ben nyílt forrásból, a GPL licenc alatt, 2015-ben költözött az Apache License-re. Ezt az Apache Alapítvány kezeli több szervezet közösségi hozzájárulásával. Valós idejű bevitelt, gyors lekérdezési teljesítményt és magas rendelkezésre állást biztosít.

A Druid név arra a tényre utal, hogy architektúrája megváltozhat a különféle típusú adatproblémák megoldása érdekében. Gyakran üzleti intelligencia alkalmazásokban használják, hogy nagy mennyiségű valós idejű és történelmi adatot elemezzenek.

3. Druida építészet

Druid az oszloporientált és elosztott adatforrás Java-ban írva. Képes hatalmas mennyiségű eseményadat befogadására, és alacsony késleltetésű lekérdezésekre. Ezenkívül lehetőséget nyújt az adatok önkényes szeletelésére és feldarabolására.

Nagyon érdekes megérteni, hogy a druid építészet miként támogatja ezeket a funkciókat. Ebben a részben áttekintjük a Druid architektúra néhány fontos részét.

3.1. Adattárolási tervezés

Fontos megérteni, hogy a Druid hogyan strukturálja és tárolja az adatait, ami lehetővé teszi a particionálást és a terjesztést. druida az adatokat alapértelmezés szerint felosztja a feldolgozás során, és darabokra tárolja és szegmensek:

druida adatokat tárol úgynevezett „adatforrásként”, amely logikailag hasonló a relációs adatbázisok tábláihoz. A druida fürt több adatforrást képes párhuzamosan kezelni, különféle forrásokból beolvasva.

Minden adatforrás fel van osztva - alapértelmezés szerint idő alapján, és további konfiguráció esetén további attribútumok alapján. A az adatok időtartama „darabként” ismert - például egy óra adatai, ha az adatokat órára osztjuk.

Minden a darabot tovább osztjuk egy vagy több „szegmensbe”, amelyek egyetlen fájl, sok adatsorból állnak. Az adatforrás néhány szegmenstől több millió szegmensig terjedhet.

3.2. Druida folyamatok

Druidnak van többfolyamatos és elosztott architektúra. Ezért minden folyamat függetlenül méretezhető, lehetővé téve számunkra, hogy rugalmas klasztereket hozzunk létre. Értsük meg a Druid részét képező fontos folyamatokat:

• Koordinátor: Ez a folyamat elsősorban a szegmensek kezeléséért és disztribúciójáért felel, és kommunikál a korábbi folyamatokkal a szegmensek konfigurációk alapján történő betöltéséhez vagy eldobásához
• Hűbérúr: Ez a fő folyamat, amely felelős a feladatok elfogadásáért, a feladatok terjesztésének koordinálásáért, a feladatok körüli zárak létrehozásáért és az állapot visszaadásáért a hívóknak.
• Bróker: Ez az a folyamat, amelyre az összes lekérdezést elküldik végrehajtani egy elosztott fürtben; metaadatokat gyűjt a Zookeeper-től és a lekérdezéseket a megfelelő szegmensekkel rendelkező folyamatokhoz irányítja
• Router: Ez egy opcionális folyamat, amely felhasználható a lekérdezések különböző közvetítői folyamatokhoz történő továbbítására, így biztosítva a lekérdezések elkülönítését a fontosabb adatok lekérdezéseihez
• Történelmi: Ezek azok a folyamatok, amelyek lekérdezhető adatokat tárolnak; állandó kapcsolatot tartanak fenn a Zookeeper-rel, és figyelik a szegmensinformációkat, amelyeket be kell tölteniük és kiszolgálniuk
• Középvezető: Ezek azok a dolgozói folyamatok, amelyek végrehajtják a beküldött feladatokat; továbbítják a feladatokat a külön JVM-ekben futó Peons-nek, ezáltal biztosítva az erőforrások és a naplók elkülönítését

3.3. Külső függőségek

Az alapvető folyamatokon kívül Druid számos külső függéstől függ, hogy a klaszter a várt módon működjön-e.

Lássuk, hogyan alakul ki egy druida fürt az alapvető folyamatokkal és a külső függőségekkel együtt:

Druid használja mély tárhely a bekerült adatok tárolására a rendszerbe. Ezeket nem a lekérdezések megválaszolására, hanem az adatok biztonsági másolatára és a folyamatok közötti adatátvitelre használják. Ezek bármi lehetnek, a helyi fájlrendszertől az elosztott objektumtárolóig, például az S3 és a HDFS.

A a metaadat-tároló a megosztott rendszer metaadatainak tárolására szolgál mint a szegmens használati információk és a feladatok információi. Azonban soha nem használják a tényleges adatok tárolására. Olyan relációs adatbázisról van szó, mint az Apache Derby, a PostgreSQL vagy a MySQL.

Druida használat Apache Zookeeper a klaszter jelenlegi állapotának kezeléséhez. Számos műveletet megkönnyít egy Druid klaszterben, mint például a koordinátor / overlord vezető választása, a szegmens közzétételi protokoll és a segment load / drop protokoll.

4. Druida beállítás

A Druid méretezhető, hibatűrő fürtként történő telepítésre készült. Azonban, gyártási szintű Druida klaszter felállítása nem triviális. Mint korábban láthattuk, sok folyamatot és külső függőséget kell beállítani és konfigurálni. Mivel klasztert rugalmasan lehet létrehozni, figyelnünk kell az egyes folyamatok megfelelő beállításához szükséges követelményeinkre.

Druid is csak Unix-szerű környezetekben támogatott, Windows rendszeren nem. Ezenkívül a Druid folyamatok futtatásához Java 8 vagy újabb szükséges. Számos egykiszolgálós konfiguráció áll rendelkezésre a Druid egyetlen gépen történő beállításához oktatóanyagok és példák futtatásához. A termelési terhelés futtatásához azonban ajánlott egy teljes értékű Druid-fürt felállítása több géppel.

A bemutató céljára meg fogjuk tenni állítsa be a Druidot egyetlen gépre a hivatalos Docker-kép segítségével megjelent a Docker Hub-on. Ez lehetővé teszi számunkra a Druid futtatását a Windows rendszeren is, amelyet egyébként nem támogatunk, amint azt korábban említettük. Elérhető egy Docker írási fájl, amely tárolót hoz létre minden Druid folyamathoz és annak külső függőségeihez.

Nekünk kell konfigurációs értékeket adjon a Druidnak mint környezeti változóknak. Ennek legegyszerűbb módja, ha egy „környezet” nevű fájlt ad meg ugyanabban a könyvtárban, mint a Docker írási fájlja.

Miután megvan a Docker írása és a környezeti fájl, a Druid elindítása olyan egyszerű, mint egy parancs futtatása ugyanabban a könyvtárban:

dokkoló-összeáll

Ez felhozza az egygépes Druid beállításához szükséges összes tárolót. Vigyáznunk kell, hogy elegendő memóriát biztosítsunk a Docker gép számára, mivel a Druid jelentős mennyiségű erőforrást fogyaszt.

5. Adatok bevitele

Az első lépés egy adatvezeték építése felé a Druid segítségével az adatok betöltése a Druidba. Ez A folyamatot a Druid architektúrában adatfogyasztásnak vagy indexelésnek nevezik. Meg kell találnunk egy megfelelő adatkészletet az oktatóanyag folytatásához.

Most, ahogy eddig összegyűltünk, muszáj olyan eseményeket gyűjtsön össze, amelyek valamilyen időbeli jellegűek, hogy a legtöbbet hozza ki a Druid infrastruktúrából.

A Druid hivatalos útmutatója egyszerű és elegáns adatokat tartalmaz, amelyek a Wikipedia oldal szerkesztését tartalmazzák egy adott dátumra. Ezt továbbra is itt használjuk oktatóanyagunkhoz.

5.1. Adatmodell

Kezdjük azzal, hogy megvizsgáljuk a nálunk lévő adatok szerkezetét. Az általunk létrehozott adatvezeték nagy része meglehetősen érzékeny az adatok rendellenességeire, ezért szükséges az adatokat a lehető legnagyobb mértékben megtisztítani.

Bár vannak kifinomult módszerek és eszközök az adatelemzés elvégzésére, szemrevételezéssel kezdjük. Egy gyors elemzés azt tárja fel a bemeneti adatok JSON formátumban rögzített eseményeket tartalmaznak, egyetlen esemény tipikus attribútumokat tartalmaz:

{"time": "2015-09-12T02: 10: 26.679Z", "channel": "# pt.wikipedia", "cityName": null, "comment": "Houveram problémák na última edição e tive de refazê- las, junto com as 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," hozzáadott ": 197," törölve ": 0}

Noha meglehetősen sok attribútum határozza meg ezt az eseményt, van néhány, ami különös érdeklődésre tart számunkra, amikor Druiddal dolgozunk:

• Időbélyeg
• Méretek
• Metrikák

Druid megköveteli egy adott attribútum, amelyet időbélyeg oszlopként kell azonosítani. A legtöbb helyzetben Druid adatelemzője képes automatikusan felismerni a legjobb jelöltet. De mindig van választási lehetőségünk, különösen akkor, ha az adatainkban nincs megfelelő tulajdonság.

A dimenziók azok az attribútumok, amelyeket a druida tárol. Bármilyen célra felhasználhatjuk őket, például csoportosításra, szűrésre vagy összesítők alkalmazására. Választhatunk, hogy kiválasszuk a dimenziókat a felvételi specifikációban, amelyeket az oktatóanyagban tovább megvitatunk.

A mutatók azok az attribútumok, amelyeket a dimenzióktól eltérően összesített formában tárolnak alapértelmezés szerint. Kiválaszthatunk egy összesítési függvényt, amellyel a Druid alkalmazható ezekre az attribútumokra a bevitel során. Az összesítés engedélyezésével együtt kompakt adatábrázolásokhoz vezethetnek.

5.2. Lenyelési módszerek

Most megvitatjuk a Druidban az adatok bevitelének különféle módjait. Általában az eseményvezérelt adatok streaming jellegűek, ami azt jelenti, hogy az idő előrehaladtával különböző ütemben generálódnak, például a Wikipédia szerkesztései.

Előfordulhat azonban, hogy egy időre átkötjük az adatokat, ahol az adatok statikusabbak, mint a Wikipédia minden tavalyi szerkesztése.

Lehet, hogy megoldunk különféle adatfelhasználási eseteket is, és Druid fantasztikus támogatást nyújt a legtöbbjük számára. Vizsgáljuk meg a Druid adatcsatornában történő felhasználásának két leggyakoribb módját:

• Streaming lenyelés
• Kötegelt lenyelés

A A Druidban az adatok bevitelének leggyakoribb módja az Apache Streaming szolgáltatás, ahol Druid közvetlenül Kafkától olvashat adatokat. A Druid más platformokat is támogat, például a Kinesist. El kell indítanunk a túlterhelés folyamat felügyelőit, amely létrehozza és kezeli a Kafka indexelési feladatokat. A felügyelőt úgy indíthatjuk, hogy JSON fájlként egy felügyeleti specifikációt küldünk be a Túlterhelés folyamat HTTP POST parancsán keresztül.

Alternatív megoldásként megtehetjük tételesen beveheti az adatokat - például egy helyi vagy távoli fájlból. Lehetőséget kínál Hadoop-alapú kötegelt bevitelre, ha a Hadoop fájlrendszerből Hadoop fájlformátumban szeretne adatokat bevinni. Gyakrabban választhatjuk a natív kötegfogyasztást szekvenciálisan vagy párhuzamosan. Kényelmesebb és egyszerűbb megközelítés, mivel nincsenek külső függőségei.

5.3. A feladat specifikáció meghatározása

Ehhez az oktatóanyaghoz állítson be natív kötegelt beviteli feladatot a bemeneti adatokhoz nekünk van. Lehetőségünk van a feladat konfigurálására a Druid konzolról, amely intuitív grafikus felületet ad nekünk. Felváltva mi meghatározhatja a feladat specifikációt JSON fájlként, és elküldheti az overlord folyamatnak parancsfájl vagy parancssor használatával.

Először határozzunk meg egy egyszerű feladatleírást az adataink bevitelére egy úgynevezett fájlban wikipedia-index.json:

{"type": "index_parallel", "spec": {"dataSchema": {"dataSource": "wikipedia", "dimensionSpec": {"dimenziók": ["csatorna", "városnév", "megjegyzés", " countryIsoCode "," countryName "," isAnonymous "," isMinor "," isNew "," isRobot "," isUnpatrolled "," metroCode "," namespace "," page "," regionIsoCode "," regionName "," user " , {"név": "hozzáadva", "típus": "hosszú"}, {"név": "törölt", "típus": "hosszú"}, {"név": "delta", "típus": "long"}]}, "timestampSpec": {"oszlop": "idő", "format": "iso"}, "metricsSpec": [], "granularitySpec": {"type": "uniform", " segmentGranularity ":" nap "," queryGranularity ":" nincs "," intervallum ": [" 2015-09-12 / 2015-09-13 "]," összesítés ": 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}}}

Értsük meg ezt a feladatot, tekintetbe véve az előző alfejezetekben bemutatott alapokat:

• Mi választottuk a index_parallel feladat, amely párhuzamosan biztosítja számunkra a natív kötegfogyasztást
• A feladatban használni kívánt adatforrás neve „wikipédia ”
• Adataink időbélyegzője az „idő” attribútumból származik
• Számos adatattribútumot adunk hozzá dimenzióként
• Az aktuális feladatban semmilyen mutatót nem használunk az adatainkra
• Az alapértelmezés szerint engedélyezett összesítést le kell tiltani ennél a feladathoz
• A feladat bemeneti forrása egy helyi fájl wikiticker-2015-09-12-sampled.json.gz
• Nem használunk egyetlen másodlagos partíciót sem, amelyet a tuningConfig

Ez a feladat spec feltételezi, hogy letöltöttük az adatfájltwikiticker-2015-09-12-sampled.json.gz és a helyi gépen tartotta, ahol Druid fut. Ez bonyolultabb lehet, ha a Druidot Docker konténerként futtatjuk. Szerencsére Druid ezzel a mintaadattal érkezik alapértelmezés szerint a helyszínen gyors útmutató / bemutató.

5.4. A feladat specifikáció benyújtása

Végül elküldhetjük ezt a feladatspecifikus parancsot az overlord folyamathoz a parancssoron keresztül, például egy eszköz segítségével becsavar:

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

Normális esetben, a fenti parancs visszaadja a feladat azonosítóját ha a benyújtás sikeres. A beviteli feladat állapotát a Druid konzolon vagy lekérdezések végrehajtásával ellenőrizhetjük, amelyeket a következő szakaszban ismertetünk.

5.5. Haladó lenyelési koncepciók

A Druid a legalkalmasabb arra az esetre, amikor hatalmas mennyiségű adattal kell foglalkoznunk - természetesen nem azokkal, amelyeket ebben az oktatóanyagban láttunk! Most, hogy a funkciókat méretben lehessen engedélyezni, a Druid architektúrának megfelelő eszközöket és trükköket kell biztosítania.

Bár nem használjuk őket ebben az oktatóanyagban, gyorsan beszéljük meg az összesítést és a particionálást.

Az eseményadatok hamarosan nagyméretűvé válhatnak, ami befolyásolhatja az általunk elérhető lekérdezés teljesítményét. Sok esetben ez lehet lehetséges az adatok időbeli összefoglalása. Ez az, amit a Druidban roll-up néven ismerünk. Ha az összesítés engedélyezve van, Druid arra törekszik azonos méretekkel és időbélyegekkel rendelkező összesítő sorok lenyelés közben. Bár helyet takaríthat meg, az összesítés a lekérdezés pontosságának elvesztéséhez vezet, ezért racionálisan kell használnunk.

A növekvő adatmennyiséggel szembeni jobb teljesítmény elérésének másik lehetséges módja az adatok és így a munkaterhelés terjesztése. Alapértelmezés szerint Druid az időbélyegek alapján az adatokat darabokra osztja egy vagy több szegmenst tartalmaz. Továbbá dönthetünk úgy, hogy másodlagos particionálást végzünk természetes dimenziókkal az adatok lokalitásának javítása érdekében. Ezenkívül Druid minden szegmensen belül először időbélyeg szerint rendezi az adatokat, majd az általunk konfigurált egyéb dimenziók szerint.

6. Adatok lekérdezése

Miután sikeresen végrehajtottuk az adatok bevitelét, készen kell állnunk a lekérdezésre. Többféle módon lehet lekérdezni az adatokat a Druidban. A A lekérdezés Druidban történő végrehajtásának legegyszerűbb módja a Druid konzol. A lekérdezéseket azonban HTTP parancsok küldésével vagy parancssori eszköz használatával is végrehajthatjuk.

A Druidban a lekérdezések összeállításának két kiemelkedő módja a natív és az SQL-szerű lekérdezések. Mi fogunk készítsen néhány alapvető lekérdezést mindkét módon, és küldje el HTTP-n keresztül felhasználásával becsavar. Megtudhatjuk, hogyan hozhatunk létre néhány egyszerű lekérdezést azokról az adatokról, amelyeket korábban bevettünk a Druidba.

6.1. Natív lekérdezések

Natív lekérdezések Druidban használjon JSON objektumokat, amelyeket elküldhetünk egy brókernek vagy egy útválasztónak feldolgozásra. Küldhetjük a lekérdezéseket a HTTP POST paranccsal, többek között, hogy ugyanezt tegyük.

Hozzunk létre egy JSON fájlt név szerint simple_query_native.json:

{"queryType": "topN", "dataSource": "wikipedia", "intervals": ["2015-09-12 / 2015-09-13"], "részletesség": "all", "dimension": " oldal "," metrika ":" szám "," küszöb ": 10," összesítések ": [{" type ":" count "," name ":" count "}]}

Ez egy egyszerű lekérdezés, amely beolvassa a tíz olyan oldalt, amelyre a legtöbb oldalszerkesztést kapták 2019. szeptember 12. és 13. között.

Tegyük közzé ezt HTTP-n keresztül a becsavar:

curl -X 'POST' -H 'Tartalomtípus: application / json' -d @ simple_query_native.json // localhost: 8888 / druid / v2? pretty

Ez a válasz az első tíz oldal részleteit tartalmazza JSON formátumban:

[{"időbélyeg": "2015-09-12T00: 46: 58.771Z", "result": [{"count": 33, "page": "Wikipedia: Vandalismusmeldung"}, {"count": 28 " oldal ":" Felhasználó: Cyde / Jelöltek listája a gyors törléshez / Aloldal "}, {" count ": 27," page ":" Jeremy Corbyn "}, {" count ": 21," page ":" Wikipédia: A rendszergazdák hirdetőtáblája / események "}, {" count ": 20," page ":" Flavia Pennetta "}, {" count ": 18," page ":" Total Drama Presents: The Ridonculous Race "}, {" count ": 18," page ":" Felhasználói beszélgetés: Dudeperson176123 "}, {" count ": 18," page ":" Wikipédia: Le Bistro / 12 septembre 2015 "}, {" count ": 17," page ": "Wikipédia: A hírekben / Jelöltekben"}, {"count": 17, "page": "Wikipédia: Oldalvédelmi kérelmek"}]}]

6.2. Druida SQL

Druidnak van egy beépített SQL réteg, amely lehetővé teszi számunkra, hogy lekérdezéseket készítsünk ismert SQL-szerű konstrukciókban. Az Apache Calcite felhasználásával elemzi és megtervezi a lekérdezéseket. A Druid SQL azonban az SQL-lekérdezéseket natív lekérdezésekké alakítja át a lekérdezésközvetítőn, mielőtt azokat adatfolyamatokba küldené.

Nézzük meg, hogyan hozhatunk létre ugyanazt a lekérdezést, mint korábban, de a Druid SQL használatával. A korábbiakhoz hasonlóan létrehozunk egy JSON fájlt név szerint simple_query_sql.json:

{"query": "SELECT page, COUNT (*) AS count / FROM wikipedia WHERE \" __ time \ "/ BETWEEN TIMESTAMP '2015-09-12 00:00:00' AND TIMESTAMP '2015-09-13 00:00 : 00 '/ CSOPORT SZERINT SORRENDEZÉS SZERKESZTÉSEK DESC LIMIT 10 "}

Kérjük, vegye figyelembe, hogy a lekérdezést több sorra bontották az olvashatóság érdekében, de egy sorban kell megjelennie. Ismét, mint korábban, ezt a lekérdezést HTTP-n keresztül küldjük el, de egy másik végpontra:

curl -X 'POST' -H 'Tartalomtípus: application / json' -d @ simple_query_sql.json // localhost: 8888 / druid / v2 / sql

A kimenetnek nagyon hasonlónak kell lennie ahhoz, amit korábban a natív lekérdezéssel értünk el.

6.3. Lekérdezés típusai

A korábbi szakaszban láttuk, egy olyan típusú lekérdezés, ahol a metrika „számlálásának” tíz legjobb eredményét hoztuk meg egy intervallum alapján. Ez csak egy típusú lekérdezés, amelyet a Druid támogat, és az úgynevezett TopN lekérdezés. Természetesen ezt egyszerűvé tehetjük TopN sokkal érdekesebb lekérdezés szűrők és összesítések használatával. De ez nem tartozik az oktatóanyag körébe. A Druidban azonban számos más kérdés is felkelthet minket.

Néhány népszerű a Timeseries és a GroupBy.

Idősorok a lekérdezések egy JSON objektum tömböt adnak vissza, ahol minden objektum az idősor lekérdezésben leírt értéket képviseli - például egy dimenzió napi átlagát az elmúlt egy hónapban.

Csoportosít a lekérdezések egy JSON-objektum tömböt adnak vissza, ahol minden objektum egy csoportosítást képvisel, a csoportonkénti lekérdezésben leírtak szerint. Például lekérdezhetjük az elmúlt hónap dimenziójának napi átlagát egy másik dimenzió szerint csoportosítva.

Számos más típusú lekérdezés létezik, többek között Letapogatás, Keresés, TimeBoundary, SegmentMetadata, és DatasourceMetadata.

6.4. Haladó lekérdezési fogalmak

Druid kínál néhányat összetett módszerek kifinomult lekérdezések létrehozására érdekes adatalkalmazások létrehozásához. Ezek magukban foglalják az adatok szeletelésének és feldarabolásának különféle módjait, miközben továbbra is hihetetlen lekérdezési teljesítményt tudnak nyújtani.

Noha ezek részletes megvitatása meghaladja az oktatóanyag kereteit, beszéljük meg néhány olyan fontos, mint a Csatlakozások és keresések, a Multitenancy és a Query Caching.

Druid két módon támogatja az adatok összekapcsolását. Az első a csatlakozás operátor, a második pedig a lekérdezés idejű keresés. A jobb lekérdezési teljesítmény érdekében azonban célszerű elkerülni a lekérdezés idejével való összekapcsolódást.

A multitenancy arra a tulajdonságra utal, hogy több bérlőt támogat ugyanazon a Druid infrastruktúrán, miközben továbbra is logikus elszigetelést kínál számukra. Ezt Druid-ban el lehet érni bérlőnként külön adatforrásokkal, vagy a bérlő által megosztott adatokkal.

És végül: a lekérdezés gyorsítótárazása az adatigényes alkalmazások teljesítményének kulcsa. A Druid támogatja a lekérdezés eredményeinek gyorsítótárazását a szegmens és a lekérdezés eredményeinek szintjén. Ezenkívül a gyorsítótár adatai a memóriában vagy a külső, állandó tárolóban helyezkedhetnek el.

7. Nyelvkötések

Bár a Druid kiválóan támogatja a bevitel specifikációinak létrehozását és a lekérdezések meghatározását a JSON-ban, ez néha unalmas lehet ezeket a lekérdezéseket a JSON-ban meghatározni, különösen, ha a lekérdezések összetettek. Sajnos a Druid nem kínál kliens könyvtárat egyetlen konkrét nyelven sem, hogy segítsen nekünk ebben a tekintetben. De vannak jó néhány nyelvi kötést, amelyet a közösség fejlesztett ki. Az egyik ilyen ügyfélkönyvtár Java számára is elérhető.

Gyorsan meglátjuk, hogyan lehet felépíteni a TopN korábban ezt a kliens könyvtárat használva használtuk a Java-ban.

Kezdjük azzal, hogy meghatározzuk a szükséges függőséget Mavenben:

 in.zapr.druid druidry 2.14 

Ezt követően képesnek kell lennünk az ügyfélkönyvtár használatára és a saját könyvtár létrehozására TopN lekérdezés:

DateTime startTime = new DateTime (2015, 9, 12, 0, 0, 0, DateTimeZone.UTC); DateTime endTime = new DateTime (2015, 9, 13, 0, 0, 0, DateTimeZone.UTC); Intervallum intervallum = új intervallum (startTime, endTime); Granularity granularity = új SimpleGranularity (PredefinedGranularity.ALL); DruidDimension dimenzió = new SimpleDimension ("oldal"); TopNMetric metrika = új SimpleMetric ("count"); DruidTopNQuery query = DruidTopNQuery.builder () .dataSource ("wikipedia") .dimension (dimension) .threshold (10) .topNMetric (metric) .granularity (granularity) .filter (filter) .aggregators (Arrays.asList (new LongSumAgeg) "count", "count"))) .intervals (Collections.singletonList (intervallum)). build ();

Ezek után egyszerűen létrehozhatjuk a szükséges JSON struktúrát, amelyet felhasználhatunk a HTTP POST hívásban:

ObjectMapper mapper = új ObjectMapper (); Karaktersorozat szükségesJson = mapper.writeValueAsString (lekérdezés);

8. Következtetés

Ebben az oktatóanyagban áttekintettük az eseményadatok és az Apache Druid architektúra alapjait.

Ezenkívül a helyi gépünkön Docker konténerek segítségével létrehoztunk egy elsődleges Druid klasztert. Ezután a natív kötegelt feladat segítségével végigvittük a Druid mintadatkészletének beolvasását is. Ezek után láttuk, hogy milyen módon kell lekérdeznünk adatainkat a Druidban. Végül átmentünk egy Java-kliens könyvtáron Druid-lekérdezések összeállításához.

Nemrégiben megvakartuk a Druid által kínált funkciók felületét. Számos lehetőség kínálkozik arra, hogy a Druid segítsen nekünk adatcsatornánk kiépítésében és adatalkalmazások létrehozásában. A fejlett beviteli és lekérdezési funkciók a következő nyilvánvaló tanulási lépések a Druid erejének hatékony kihasználásához.

Ezen túlmenően az előnyök maximalizálása érdekében célszerű egy megfelelő Druid klaszter létrehozása, amely az egyes folyamatokat a szükségletek szerint méretezi.