Jeg vil gerne præsentere transkriptet af Igor Strikhar's præsentation fra 2017 «ClickHouse – visuel hurtig og overskuelig dataanalyse i Tabix».
Webgrænsefladen til ClickHouse i projektet Tabix.
Hovedfunktioner:
- Fungerer med ClickHouse direkte fra browseren, uden behov for installation af ekstra software;
- Forespørgselseditor med syntaksfremhævning;
- Automatisk fuldførelse af kommandoer;
- Værktøjer til grafisk analyse af udførelsesforespørgsler;
- Farveskemaer at vælge imellem.



Jeg er teknisk direktør for СМИ2. Vi er en nyhedsudvekslingsaggregator. Vi gemmer mange data, som vi modtager fra vores partnere og registrerer dem i ClickHouse – omkring 30.000 forespørgsler per sekund.
Det drejer sig om data såsom:
- Klik på nyheder.
- Visninger af nyheder i aggregatoren.
- Visninger af bannere i vores netværk.
- Og vi registrerer begivenheder fra vores egen tæller, der ligner Yandex.Metrica. Det er vores egen mikroanalytik.

Vi havde et meget turbulente liv før ClickHouse. Vi kæmpede virkelig med at lagre disse data et eller andet sted og analysere dem.
Livet før ClickHouse – infiniDB
Det første, vi havde, var infiniDB. Den var hos os i 4 år. Vi lancerede den med vanskeligheder.
- Den understøtter ikke clustering eller sharding. Ingen af de smarte funktioner blev installeret som standard.
- Den har problemer med at indlæse data. Kun et specifikt kommandolinjeværktøj, der kun kunne indlæse CSV-filer og på en meget uklar måde.
- Databasen var enkelttrådet. Man kunne kun skrive eller læse. Men den kunne behandle store mængder data.
- Og den havde også en interessant løsning. Hver nat skulle serveren genstartes, ellers fungerede den ikke.
Den fungerede for os indtil slutningen af 2016, da vi helt skiftede til ClickHouse.
Livet før ClickHouse – Cassandra
Da infiniDB var enkelttrådet, besluttede vi, at vi havde brug for en eller anden flertrådet database, hvor vi kunne skrive mange tråde samtidig.
Vi prøvede mange interessante ting. Så besluttede vi at prøve Cassandra. Med Cassandra havde vi alt på plads. 10.000 forespørgsler per sekund til indsættelse. 2.000 forespørgsler cirka til læsning.
Men den havde også sine interessante aspekter. En gang om måneden eller hver anden måned skete der en desynkronisering af databasen. Og så måtte man vågne op, og løbe for at reparere Cassandra. Vi genstartede serverne én efter én. Og alt blev glat og smukt.
Livet før ClickHouse – Druid
Senere indså vi, at vi havde brug for at skrive endnu mere data. I 2016 begyndte vi at kigge på Druid.
Druid er en open source-database skrevet i Java. Meget speciel. Den passende til clickstream, når vi skal gemme en form for begivenhedsstrøm og derefter lave aggregering eller lave analytiske rapporter baseret på dem.
Druid havde version 0.9.X.
Selve databasen er meget vanskelig at implementere. Det er en kompleksitet af infrastrukturen. For at implementere den skulle vi sætte mange maskiner op. Hver maskine havde sin egen rolle.
For at indlæse data i den skulle vi bruge en slags magi. Der er et open source-projekt - Tranquility, som mistede data i strømmen. Når vi indlæste data i det, tabte det dem.
Men vi begyndte på en eller anden måde at implementere det. Vi, ligesom pindsvin der bliver stikket, men fortsætter med at spise kaktus, begyndte at implementere det. Det tog os omkring en måned at forberede hele infrastrukturen til det. Altså bestille servere, konfigurere roller, udføre fuld automatisering af implementeringen. Altså i tilfælde af sammenbrud af klyngen, så skulle en anden klynge automatisk implementeres.

Men så skete der et mirakel. Jeg var på ferie, og mine kolleger sendte mig et link til , hvor det blev sagt, at Yandex besluttede at åbne ClickHouse. Jeg sagde, lad os prøve.
Og bogstaveligt talt på 2 dage havde vi implementeret en testklynge af ClickHouse. Vi begyndte at indlæse data i det. Sammenlignet med infiniDB – dette er elementært, sammenlignet med Druid – dette er elementært. Sammenlignet med Cassandra er det også elementært. For det er ikke elementært at indlæse data i Cassandra fra PHP.

Hvad fik vi? Performance i hastighed. Performance i datalagring. Altså bruges der meget mindre diskplads. ClickHouse er hurtig, den er meget hurtigere i forhold til andre produkter.

På tidspunktet for lanceringen, da Yandex offentliggjorde ClickHouse som open source, var der kun en konsolklient. Vi i vores virksomhed, СМИ2, besluttede at prøve at lave en nativ klient til web, så man kunne åbne en side i en browser, skrive en forespørgsel og få resultater, fordi vi begyndte at skrive mange forespørgsler. Det er svært at skrive i konsollen. Og vi lavede vores første version.

Og tættere på vinteren sidste år begyndte der at dukke eksterne værktøjer til at arbejde med ClickHouse op. Disse værktøjer inkluderer:
- .
- .
- . (Nu )
- .
- .
Jeg vil gennemgå nogle af disse værktøjer, dvs. dem jeg har arbejdet med.

Et godt værktøj, men til Druid. Da vi implementerede Druid, testede jeg SuperSet. Jeg kunne lide det. Det fungerer meget hurtigt til Druid.
Det er ikke egnet til ClickHouse. Altså, det virker, men det kan kun håndtere grundlæggende forespørgsler som: SELECT event, GROUP BY event. Det understøtter ikke mere kompleks ClickHouse-syntaks.

Det næste værktøj er Apache Zeppelin. Det er en god og interessant ting. Det fungerer. Det understøtter notesbøger, dashboards og understøtter variabler. Jeg ved, at nogen i ClickHouse-fællesskabet bruger det.
Men der er ikke støtte til ClickHouse-syntaks, dvs. man skal skrive forespørgsler enten i konsollen eller et andet sted. Derefter skal man kontrollere, at alt fungerer. Det er simpelthen ubelejligt. Men understøttelsen af dashboards er rigtig god.

Det næste værktøj er Redash.IO. Redash hostes online. Dvs. i modsætning til de tidligere værktøjer skal det ikke installeres. Det er et dashboardværktøj med mulighed for datakonsolidering fra forskellige datakilder. Dvs. du kan trække data fra ClickHouse, MySQL, PostgreSQL og andre databaser.

For præcis en måned siden (i marts 2017) blev der tilføjet støtte i Grafana. Når du bygger rapporter i Grafana, for eksempel om tilstanden af dit udstyr eller nogle målinger, kan du nu bygge en tilsvarende graf eller panel med data fra ClickHouse direkte. Det er meget praktisk, og vi bruger det internt. Det gør det muligt at finde anomalier. Altså, hvis der sker noget, og en enhed falder ud eller bliver belastet, så kan man se årsagen, hvis disse data har nået at komme ind i ClickHouse.

Det var meget ubehageligt for mig at skrive i disse værktøjer eller i konsollen. Så jeg besluttede at forbedre vores første interface. Og jeg fik inspiration fra EventSQL, SuperSet og Zeppelin.

Hvad ønskede jeg? Jeg ønskede at få grafer, en forbedret editor og implementere støtte til ordlister med forslag. Fordi ClickHouse har en fantastisk funktion – ordlister. Men det er vanskeligt at arbejde med ordlister, fordi man skal huske formatet på de gemte værdier, dvs. om det er et tal eller en streng osv. Og da vi ofte bruger ordlister i deres forskellige varianter, var det ret svært at skrive forespørgsler.

Der er gået 3 måneder siden frigivelsen af vores første version. Jeg har lavet omkring 330 commits i den lukkede gren, og det blev til Tabix.
I modsætning til den tidligere version, der hed ClickHouse-Frontend, har jeg besluttet at omdøbe den til et simpelt navn. Og det blev Tabix.
Hvad er der kommet?
Tegner grafer. Understøtter SQL-syntaksen for ClickHouse. Giver forslag til funktioner og kan meget mere.

Sådan ser den samlede skema for Tabix ud. Til venstre er træet præsenteret. I midten – dét er forespørgselseditoren. Og nederst – er resultatet af denne forespørgsel.

Jeg vil nu vise, hvordan forespørgselseditoren fungerer.

Her aktiveredes autocompletion automatisk på tabellen og giver forslag, svarende til autocompletion på felterne. Og forslag til funktionerne. Hvis man trykker ctrl enter, vil forespørgslen blive udført eller falde med en fejl. Den enkleste forespørgsel sendes til Tabix, og man får et resultat, dvs. man kan hurtigt arbejde med ClickHouse.

Ordbøger, som jeg allerede har nævnt, er en meget interessant ting, som vi arbejder meget med. Og som har gjort det muligt at lave mange ting. I ordbøgerne gemmer vi alle byer. Vi opbevarer identifikatoren for byen og navnet på byen, dens bredde- og længdegrad. I databasen gemmer vi kun identifikatoren for byen. Så vi komprimerer data meget effektivt.

Det er, tilsyneladende, en simple ting, men i ClickHouse hjælper den meget interessant. Fordi ClickHouse kun understøtter indlejret join, vokser forespørgslen nedad og i bredden ret meget. Og når en parentes åbnes, og der er et langt udtryk, så hjælper en så relativt simpel ting som at folde forespørgslen sammen, med at arbejde lettere med selve forespørgselen. For når forespørgselen er 200-300 linjer og i bredden meget stor, er det en stor hjælp at folde forespørgselen sammen og derefter finde et sted eller på en eller anden måde lokalisere den.
Objektræ, multipurpose forespørgsler og faner (Video 13:46) )

Jeg vil næste vise om træet, fanerne. Til venstre – er træet, og ovenfor kan man oprette flere faner. Faner fungerer som et arbejdsområde. Du kan oprette flere faner og navngive hver enkelt efter eget valg. Det fungerer som et minissystem til at opbygge rapporter.
Faner gemmes automatisk. Hvis du genindlæser browseren, lukker den eller åbner Tabix igen, så vil alt dette blive gemt.
Genvejstast – praktisk (Video 14:39) )
Der findes genvejstaster, og der er ret mange af dem. Jeg har fremhævet nogle af dem her som eksempler. Dette er skift af fane, udfør forespørgsel eller udfør flere forespørgsler.

Jeg vil vise, hvordan man arbejder med resultatet. Vi sender en forespørgsel. Her tegner jeg sin, cos og tg. Man kan fremhæve resultatet, dvs. tegne en typisk kort på kolonnen. Man kan fremhæve positive eller negative værdier. Eller bare farve et specifikt element i tabellen. Det er praktisk, når tabellen er enorm, og man skal finde en bestemt anomalie med det blotte øje. Da jeg søgte efter anomalier, fremhævede jeg nogle rækker og nogle elementer med grøn eller rød farve.

Der er mange interessante ting der. For eksempel hvordan man kopierer til Redmine Markdown. Hvis man har brug for at kopiere resultatet et sted hen, er det meget praktisk. Man kan blot vælge et område, sige 'Copy to Redmine', og det vil kopiere til Redmine Markdown eller oprette en forespørgsel Where.

Dernæst er der optimering af forespørgsler. Jeg glemte én gang at angive feltet 'date'. Og min forespørgsel i ClickHouse blev ikke behandlet meget hurtigt, men hurtigt, dvs. på mindre end et sekund. Da jeg så, hvor mange rækker den gennemgik, blev jeg bange. Vi skriver ikke så mange rækker i denne tabel på en dag. Jeg begyndte at analysere forespørgslen og så, at jeg havde glemt at angive datoen et sted. Dvs. jeg glemte at angive, at jeg kun havde brug for data for en bestemt periode og ikke for hele tabellen.
I Tabix er der en fane 'Stats', hvor al historik for sendte forespørgsler gemmes, så man kan se, hvor mange rækker der blev læst af denne forespørgsel og hvor lang tid den tog at udføre. Det gør det muligt at optimere.
Man kan bygge en pivottabel over resultatet af forespørgslen. Du sendte en forespørgsel til ClickHouse og fik nogle data. Og derefter kan disse data trækkes med musen for at bygge en pivottabel.

Den næste interessante ting er grafopbygning. Antag, at vi har en sådan forespørgsel: på sin, cos fra 0 til 299. For at tegne den skal du vælge fanen 'Draw', og du vil få en graf med dine sin og cos.

Man kan opdele dette på forskellige akser, dvs. man kan tegne to grafer ved siden af hinanden. Skriv én kommando og derefter en anden kommando.

Man kan tegne histogrammer.

Man kan opdele dette i et matrix af grafer.

Man kan bygge et varme kort.

Man kan bygge en varmekalender. I øvrigt en meget praktisk ting, når man skal analysere anomalier over et år, dvs. finde enten spidser eller fald. Denne datavisualisering hjalp mig med dette.

Den næste er Treemap.


Sankeys – en interessant graf. Det er enten Streamgraphs eller River. Men jeg kalder det River. Det giver også mulighed for at søge efter anomalier. Det er meget praktisk. Jeg anbefaler at bruge det til at finde.

Den næste interessante ting er visualisering af et dynamisk kort. Hvis du har breddegrad, længdegrad og, lad os sige, destinationer i din database, for eksempel hvis du har lastbiler eller fly, kan du visualisere ruterne til destinationerne. Du kan også angive hastighed, størrelse på objekterne, som de ankommer til.
Men problemet med dette kort er, at det kun viser et verdenskort, der mangler detaljer.

Senere tilføjede jeg Google Maps. Hvis du gemmer breddegrad og længdegrad, kan du visualisere resultatet på Google Maps, men uden støtte til flyene.
De grundlæggende funktioner til arbejde med resultatet, med forespørgslen i Tabix, har vi diskuteret.

Næste er analysen af din ClickHouse-server. Der er en separat fane 'Metrikker', hvor du kan se størrelsen på de gemte data pr. kolonne. På skærmbilledet kan du se, at feltet 'referrer' fylder omkring 730 Gb. Hvis vi dropper dette felt, vil vi spare tre shards på 700 GB, dvs. omkring 2 TB, som vi ikke har brug for.
Vi har også et felt 'request_id', som vi gemmer som tekst. Men hvis vi begynder at gemme det som tal, vil dette felt blive komprimeret betydeligt.
Her er også serverkonfigurationen og listen over noder i din klynge.

Den næste fane er metrikker. De hentes i realtid fra ClickHouse og giver mulighed for at analysere serverens tilstand og forstå, hvad der sker. Det er ikke en fuld erstatning for Grafana. Det bruges til hurtig analyse.

Den næste fane er processer. Her kan man forstå, hvad der sker på serveren. Forstå, hvad der foregår. Jeg havde en forespørgsel, der krævede 200 GB læsning hver gang. Jeg opdagede det takket være dette interface. Jeg fangede det og justerede det, og det blev til omkring 30 GB, dvs. ydeevnen blev forbedret betydeligt.

Tak! Og det er OpenSource.
Jeg er færdig. Og for øvrigt er det OpenSource, det er gratis og kræver ikke download. Åbn det i din browser, så virker det.
Spørgsmål
Igor, hvad er næste skridt? Hvordan vil du udvikle dette værktøj?
Senere vil dashboardet blive præsenteret, dvs. det er muligt, at der vil være et dashboard. Integration med andre databaser. Det har jeg gjort, men har endnu ikke offentliggjort det i OpenSource. Dette er MySQL og måske PostgreSQL. Det vil sige, man vil kunne sende forespørgsler fra Tabix ikke kun til ClickHouse, men også til andre værktøjer.
Det er tydeligt, at der er lavet et enormt arbejde. Det blev en ret fuldendt idé. Det er lavet i browseren, sandsynligvis for at undgå midlertidige løsninger på forskellige akser og hurtigt få dette op at køre. Jeg har hørt, at du arbejder på det, så det er simpelthen nemmere at lave det i browseren, og så vil det fungere overalt. Der er ikke nogen spørgsmål til det. Spørgsmålet er så: hvor mange mennesker har arbejdet på dette? Og hvor lang tid tog det hele? Fordi værktøjer til ens egne behov har normalt ikke så meget funktionalitet. php Fra sommeren til efteråret arbejdede én person fra vores team. Det var den første version. Derefter lavede jeg 330 commits alene. Det, du ser, er noget, vi har lavet sammen. I løbet af de 3 måneder fra den første version til den sidste, har jeg for det meste gjort det alene. Men jeg kender meget lidt til Javascript. Dette var mit eneste og, håber jeg, sidste projekt med Javascript, som jeg har arbejdet med. Det blev overgivet til mig, og jeg tænkte – åh, rædsel. Men jeg havde virkelig lyst til at fuldføre produktet, og således blev det til.
Tusind tak for præsentationen! Det er et fremragende værktøj. Har I sammenlignet det?
Tak. Derfor kaldte jeg det Tabix, fordi de første bogstaver stemmer overens. Tableau Fordi I konkurrerer?
Der vil være mange investeringer, og vi vil konkurrere.
Hvordan vil du foreslå at sælge til de interne analytikere, at dette værktøj fuldstændig erstatter *Tableau*?
Det fungerer nativt med ClickHouse. Jeg har prøvet Tableau, men der kan man ikke skrive støtte til ordbøger og sådan.
Jeg ved, hvordan folk arbejder med Tabix. De skriver forespørgsler, eksporterer til CSV og importerer det til BI. Og der gør de så noget. Men jeg har svært ved at forestille mig, hvordan de gør det, fordi – det er et grafisk værktøj. Det kan eksportere 5.000 rækker, maksimalt 6.000 rækker, men ikke mere; ellers tåler browseren det ikke.? Какие будут аргументы?
Det vil sige, der er nogle alvorlige begrænsninger på datavolumen, ikke? Ja. Jeg kan ikke forestille mig, at du vil have 10.000 rækker vist på din browser-skærm. Hvorfor? Det underst forstås, at dette er et interface til hurtigt at se data? Dreje lidt rundt, vende lidt rundt?
Ja. Jeg kan ikke forestille mig, at du vil have 10.000 rækker vist på din browser-skærm. Hvorfor?
Som det er forstået, er dette et interface til hurtigt at gennemse data? At rotere lidt, at se lidt nærmere?
Ja. Jeg vil ikke forestille mig, at du ønsker at få 10.000 rækker vist på din browser-skærm. Hvorfor?
Ja, hurtigt se, hvordan det fungerer, og bare opbygge et samlet diagram. Og så sende det videre et sted hen. Vi har vores eget rapporteringssystem, hvorfra jeg blot henter denne forespørgsel. Tegner i Tabix og sender til vores rapportering.
Og et spørgsmål mere. Kohortanalyse?
Hvis der er ønsker, tilføjer vi dem.
Da vi lige var begyndt at bruge ClickHouse, hvor lang tid tog det at implementere ClickHouse og bringe det til produktionsstatus?
Som jeg sagde, implementerede vi et testkluster på meget kort tid. Vi satte det op på to dage. Og i et par uger testede vi det. Og vi nåede til produktion på cirka 3 måneder. Men vi havde vores eget ETL, dvs. et værktøj til at indsamle data. Og det kunne skrive til alt, hvad der var muligt. Det kan skrive til MongoDB, Cassandra, MySQL. At lære det at skrive til ClickHouse var let. Vi havde en klar infrastruktur til hurtig implementering. Efter cirka 3 måneder begyndte vi at udskille den første komponent. Efter 6 måneder havde vi helt opgivet alt andet. Vi har kun ClickHouse tilbage.
Igor, tusind tak for dit foredrag. Jeg kunne virkelig godt lide funktionen til at bygge ruter på kort. Er der planer om integration med Yandex.Maps, især med tilpassede Yandex.Maps?
Jeg prøvede at integrere i stedet for Google Maps, men jeg kunne ikke finde en mørk tema på Yandex.Maps. Jeg glemte en del. Lad mig spole tilbage for at supplere.
Slide – Google Maps. Der er en kommando «DRAW_GMAPS», der tegner kortet. Der er en kommando «DRAW_YMAPS», dvs. det kan tegne et Yandex-kort. Og faktisk bag denne kommando ligger der Javascript, dvs. de data, du får fra ClickHouse, kan overføres til det Javascript, du her skriver. Og du har et område, hvor det skal tegnes. Du kan tegne enhver grafik, dvs. enhver grafik, kort, du kan tegne din egen komponent. Jeg havde før en anden bibliotek til at tegne selve grafikken.
Dvs. der findes et værktøj til at tilpasse funktionen af visningen?
Enhver. Man kan tage disse punkter og ændre farven, så de ikke er røde, men blå, grønne.
Tak for dit foredrag! Du havde en slide, hvor alternative værktøjer til forespørgsler blev præsenteret ClickHouse til opbygning af dashboards, analytiske rapporter. Forstod jeg det korrekt, at på det tidspunkt, hvor du begyndte at arbejde med ClickHouse, der var ikke skrevet nogle adaptere til disse værktøjer. Og jeg undrer mig over, hvorfor du besluttede at lave dit eget værktøj i stedet for at skrive en adapter til et eksisterende værktøj? Jeg synes, at det er hurtigt at tune en testredigerer. Hvorfor besluttede du at lave så meget arbejde?
Der er en interessant detalje – pointen er, at jeg er teknisk direktør, ikke data scientist. På det tidspunkt, hvor vi begyndte at implementere Druid, havde jeg omkring 50 % af opgaverne i min roadmap – lad os beregne dette eller lad os analysere det der. Og det endte med, at vi implementerede ClickHouse. Jeg begyndte hurtigt at bygge alt op, beregne, og lukkede hurtigt min roadmap. Og på det tidspunkt indså jeg, at jeg manglede viden om Data Science og datavisualisering. Tabix er min egen form for hjemmearbejde i datavisualisering. Jeg kiggede på, hvordan jeg kunne supplere Zeppelin. Jeg har en svag modvilje mod dens programmering. Jeg kiggede på, hvordan jeg kunne supplere Redash, men jeg manglede en ordentlig redigerer der. Og SuperSet er også skrevet på det sprog, jeg ikke er særlig glad for. Så jeg besluttede at lave det selv, og sådan blev det.
Igor, accepterer I pull requests?
Ja.
Tusind tak for præsentationen! Og to spørgsmål. For det første – du taler ikke særlig rosende om Javascript. Har du skrevet i ren Javascript eller var det en form for framework?
Bedre i ren Javascript.
Så hvilket framework?
Angular.
Jeg forstår. Og det andet spørgsmål. Har I overvejet R og *Shiny?*
Jeg har overvejet det. Leget med det.
Man kunne også bare have skrevet en adapter.
Der er en. Det ser ud til, at fællesskabet har lavet det, men som jeg svarede på det tidligere spørgsmål, ønskede jeg at prøve det selv.
Nej, vedrørende visualiseringen, der er.
Du siger, at der findes noget, der tegner en graf for dig. Jeg åbnede en bog om datavisualisering. Og tænkte: «Lad mig prøve at visualisere disse data. Jeg skriver det selv, så det kan bygge dataene op». Og jeg begyndte at forstå teknologien til data levering bedre. Hvis jeg havde taget en færdig komponent, ville jeg personligt have lært at bruge det dårligere, altså specifikt visualiseringen. Men sådan – ja, jeg kunne godt lide R, men jeg har ikke læst bogen «R for dummies» endnu.
Tak!
Et simpelt spørgsmål. Er der nogen muligheder for hurtigt at eksportere en tabel, en graf?
Man kan eksportere til CSV, til Excel.
Ikke dataene, men en færdig tabel, en færdig graf? For eksempel for at vise det til ledelsen.
Der er en knap "Eksporter" og en knap "Eksporter grafik i png, i jpg".
Tak!
P.S. Mini-instruktion til installation af tabix
- Download
- Udpak, kopier biblioteket
buildtil nginx root_path - Konfigurer nginx
Kilde: habr.com

