Javaslom, hogy ismerkedjen meg Igor Sztirchar 2017-es előadásának átiratával: „ClickHouse – vizuálisan gyors és szemléletes adatvizsgálat a Tabix-ben.”
Webes felület a ClickHouse számára a Tabix projektben.
Főbb funkciók:
- Közvetlenül a ClickHouse-szal működik a böngészőből, anélkül, hogy további szoftvert kellene telepíteni;
- Lekérdezés szerkesztő szintaktikai kiemelésével;
- Parancsok automatikus kiegészítése;
- Grafikus elemzési eszközök a lekérdezések végrehajtásához;
- Választható színsémák.
Én vagyok a média2 technikai igazgatója. Mi híreket aggregáló szolgáltatás vagyunk. Nagy mennyiségű adatot tárolunk, amelyeket partnereinktől kapunk, és regisztráljuk őket a ClickHouse-ba – körülbelül 30 000 lekérdezés másodpercenként.
Ezek olyan adatok, mint:
- Kattintások a hírekre.
- Hírek megjelenítése az aggregátorban.
- Bannerek megjelenítése a hálózatunkban.
- És regisztráljuk az eseményeket a saját számlálónkból, amely hasonló a Yandex.Metrikához. Ez a saját mikroadat-analitikánk.
Nagyon mozgalmas életünk volt a ClickHouse előtt. Nagyon szenvedtünk, próbálva az adatokat valahova tárolni és analizálni azokat.
Élet ClickHouse előtt – infiniDB
Az első, amink volt, az infiniDB volt. Negyed évszázadon át élt nálunk. Nehezen indítottuk el.
- Nem támogatja a klaszterezést vagy a shardingot. Semmilyen ilyen okos dolog nem működött alapértelmezés szerint.
- Problémái voltak az adatok betöltésével. Csak egy speciális konzolos segédprogram volt, amely csak CSV fájlokat tudott betölteni, és csak nagyon érthetetlenül.
- Az adatbázis egy szálú. Csak írni vagy olvasni lehetett. De képes volt nagy mennyiségű adatot feldolgozni.
- És volt neki egy érdekes trükkje is. Minden éjjel újra kellett indítani a szervert, különben nem működött.
2016 végéig működött, amikor teljesen áttértünk a ClickHouse-ra.
Élet ClickHouse előtt – Cassandra
Mivel az infiniDB egy szálú volt, úgy döntöttünk, hogy szükségünk van egy többszálú adatbázisra, amelyben egyszerre nagyon sok szálat tudunk írni.
Sok érdekes dolgot kipróbáltunk. Aztán úgy döntöttünk, hogy megpróbáljuk a Cassandrát. A Cassandrával minden tökéletes volt. 10 000 lekérdezés másodpercenként. 2 000 lekérdezés körülbelül olvasáshoz.
De neki is voltak érdekes dolgain. Havonta egyszer vagy kétszer adatbázis-szinkronizálási probléma lépett fel, és fel kellett ébredni, és rohanni javítani a Cassandrát. Sorban újraindítottuk a szervereket. És minden sima és szép lett.
Élet a ClickHouse előtt – Druid
Aztán rájöttünk, hogy még több adatot kell írnunk. 2016-ban elkezdtük nézni a Druid-ot.
A Druid egy nyílt forráskódú adatbázis, amely Java nyelven készült. Nagyon specifikus, és jól megfelelt a clickstream számára, amikor eseményfolyamokat kellett tárolnunk, és utána aggregálni vagy analitikai riportokat készíteni róluk.
A Druid 0.9.X-es verziója létezett.
Magának az adatbázisnak a telepítése nagyon nehézkes. Ez az infrastruktúra bonyolultsága miatt van. Ahhoz, hogy telepíteni tudjuk, sok-sok hardvert kellett vásárolni. Minden egyes hardver külön szerepet látott el.
Adatok betöltéséhez valamilyen varázslatot kellett alkalmazni. Van egy OpenSource projekt – Tranquility, amely folyamatosan elvesztette az adatokat. Amikor adatokat töltöttünk bele, azok elvesztek.
De végül elkezdtük bevezetni. Olyanok voltunk, mint a sünök, akik megszúrták magukat, de továbbra is ették a kaktuszt; elkezdtük bevezetni. Körülbelül egy hónapra volt szükségünk, hogy felkészítsük az egész infrastruktúrát. Azaz szervereket rendelni, beállítani a szerepeket, teljes automatizálást végezni a telepítési folyamatban. Azaz ha a klaszter leomlott, automatikusan települjön egy második klaszter.
De itt történt egy csoda. Éppen szabadságon voltam, és kollégáim küldtek egy linket , amelyben arról van szó, hogy a Yandex úgy döntött, hogy megnyitja a ClickHouse-t. Mondtam, hogy próbáljuk meg.
És szó szerint 2 nap alatt telepítettük a ClickHouse teszt klasztert. Elkezdtek adatokat betölteni. Az InfiniDB-hez képest – ez elemi, a Druid-hoz képest – ez elemi. A Cassandraval is elemi. Mert ha PHP-ból kell adatokat betölteni a Cassandraba, az nem elemi.
Mit kaptunk? Teljesítménysebességben. Adattárolás teljesítményében. Azaz sokkal kevesebb lemezterületet használ. A ClickHouse gyors, sokkal gyorsabb, mint más termékek.
A ClickHouse nyílt forráskódú közzétételének pillanatában az egyetlen elérhető konzolos kliens volt. Mi a mi cégünknél, a Média2-nél úgy döntöttünk, hogy megpróbálunk egy natív webklienset készíteni, hogy a böngészőből megnyithassunk egy oldalt, beírhassunk egy lekérdezést, és megkaphassuk az eredményt, mert sok lekérdezést kezdtünk írni. Nehéz a konzolban írni. És elkészítettük az első verziónkat.
És körülbelül a múlt év téli hónapjaiban elkezdtek megjelenni harmadik féltől származó eszközök a ClickHouse használatához. Ilyen eszközök, mint:
- .
- .
- . (Most )
- .
- .
Néhány ilyen eszközt át fogok nézni, azokat, amelyeket használtam.
Jó eszköz, de Druidhoz való. Amikor a Druidot bevezettük, kipróbáltam a SuperSetet. Tetszett. Druidhoz nagyon gyorsan működik.
A ClickHouse számára nem alkalmas. Azaz alkalmas, elindul, de csak alapvető lekérdezéseket képes kezelni, mint például: SELECT event, GROUP BY event. Nem támogatja a ClickHouse bonyolultabb szintaxisát.
A következő eszköz az Apache Zeppelin. Ez egy jó és érdekes dolog. Működik. Támogatja a jegyzetfüzeteket, dashboardokat, támogatja a változókat. Tudom, hogy a ClickHouse közösségéből valaki használja.
De a ClickHouse szintaxisának támogatása nincs, azaz a lekérdéseket vagy konzolban, vagy máshol kell írni. Ezt követően ellenőrizni, hogy minden működik. Ez egyszerűen kényelmetlen. De a dashboard támogatása nagyon jó.
A következő eszköz a Redash.IO. A Redash az interneten érhető el. Azaz, ellentétben az előző eszközökkel, nem kell telepíteni. Ez egy dashboard, amely lehetővé teszi az adatok konszolidálását különböző adatforrásokból. Azaz, kinyerheti a ClickHouse-ból, MySQL-ből, PostgreSQL-ből és más adatbázisokból.
Pontosan egy hónappal ezelőtt (2017 márciusában) megjelent a támogatás a Grafana-ban. Amikor jelentéseket készít a Grafana-ban, például a hardver állapotáról vagy valamilyen metrikáról, akkor most ugyanez a grafikon vagy egy panel a ClickHouse-ból származó adatokkal közvetlenül is felépíthető. Ez nagyon kényelmes, és mi ezt használjuk. Ez lehetővé teszi az anomáliák felfedezését. Azaz, ha valami történik, és egy hardver összeomlik vagy túlterhelt, meg lehet nézni az okát, ha az adatok időben bekerültek a ClickHouse-ba.
Nagyon kényelmetlen volt ezekben az eszközökben vagy a konzolban írni. Így úgy döntöttem, hogy továbbfejlesztem az első felületünket. Az EventSQL, SeperSet, Zeppelin ötletét figyeltem meg.
Mit akartam? Olyan grafikonokat, egy fejlettebb szerkesztőt, a javaslatok szótárának támogatását. Mert a ClickHouse-nak van egy nagyszerű funkciója – a szótárak. De a szótárakkal nehéz dolgozni, mert emlékezni kell a tárolt értékek formátumára, azaz ez szám vagy szöveg stb. Mivel gyakran használjuk a szótárakat azok különböző változataiban, elég nehézkes volt a lekérdezések írása.
Három hónap telt el az első verziónk megjelenése óta. Kb. 330 elkötelezettséget végeztem egy zárt ágon, és így létrejött a Tabix.
A korábbi verziót, amelyet ClickHouse-Frontendnek hívtak, egyszerű névre változtattam. Így lett Tabix.
Mi újdonság van?
Grafikonokat rajzol. Támogatja a ClickHouse SQL szintaxist. Javaslatokat ad a funkciókról, és sok más érdekes funkcióval rendelkezik.
Így néz ki a Tabix általános séma. Balra látható a fa. Középen van a lekérdezés szerkesztő. Lent pedig a lekérdezés eredménye.
Most megmutatom, hogyan működik a lekérdezés szerkesztő.
Itt automatikusan működésbe lépett az automatikus kiegészítés a táblán, és javaslatokat ad a mezőkre. És javaslatokat a funkciókra. Ha megnyomja a ctrl + enter-t, a lekérdezés végrehajtódik vagy hibával megszakad. A legegyszerűbb lekérdezés a Tabixba kerül, és megkapjuk az eredményt, azaz gyorsan lehet dolgozni a ClickHouse-szal.
A szótárak, ahogyan már említettem, nagyon érdekes dolgok, amelyekkel sokat dolgozunk. És lehetővé tették sok dolog elvégzését. Például a szótárakban tároljuk az összes várost. A város azonosítóját és nevét, szélességét és hosszúságát tároljuk. És az adatbázisban csak a város azonosítóját tároljuk. Ennek következtében az adatokat nagyon erősen tömörítjük.
Ez elsőre egy egyszerű dolognak tűnik, de a ClickHouse-ban nagyon érdekes módon segít. Mivel a ClickHouse csak a beágyazott joinokat támogatja, a lekérdezés lefelé és szélességben eléggé megnő. Amikor egy zárójel megnyílik, és hosszú kifejezés következik, egy viszonylag egyszerű dolog, mint a lekérdezés összecsukása, segít könnyebben dolgozni magával a lekérdezéssel. Mert amikor a lekérdezés 200-300 soros és szélességben óriási, akkor nagyon megkönnyíti az összecsukás a keresést vagy a helyének eldöntését.
Objektumtárfa, több lekérdezés és lapok (Videó 13:46) )
A következőkben a fáról, lapokról fogok beszélni. Balra – ez a fa, felül pedig több lapot hozhatun k létre. A lapok mint workspace funkcionálnak. Különböző neveket adhatsz nekik. Ez egy mini rendszer a jelentés összeállításához.
A lapok automatikusan mentésre kerülnek. Ha újratölti a böngészőt, vagy bezárja, vagy megnyitja a Tabixot, minden megmarad.
Gyorsbillentyű – praktikus (Videó 14:39) )
Vannak gyorsbillentyűk, és ezekből sok van. Néhányat itt mutattam be példaként. Ezek lehetnek lapváltás, lekérdezés végrehajtása vagy több lekérdezés végrehajtása.
Megmutatom, hogyan kell dolgozni az eredménnyel. Küldjünk egy kérést. Itt ábrázolom a sin, cos és tg értékeket. Ki lehet emelni az eredményt, azaz létrehozni egy tipikus diagramot az oszlopon. Ki lehet emelni a pozitív vagy negatív értékeket, vagy egyszerűen színezni lehet egy adott táblázatelemet. Ez hasznos, amikor a táblázat hatalmas, és szemmel kell megtalálni egy anomáliát. Amikor anomáliákat kerestem, kiemeltem egyes sorokat vagy elemeket zöld vagy piros színnel.
Sok érdekes dolog van ott. Például, hogyan lehet átmásolni a Redmine-ba a Markdown szöveget. Ha valahova el kell másolni az eredményt, ez nagyon kényelmes. Csak ki kell választani egy területet, és mondani, hogy „Másolás a Redmine-ba”, és az átmásolja a Redmine Markdown formátumba, vagy létrehozza a Where kérést.
A következő lépés az optimalizálás a kérések során. Egyszer elfelejtettem megadni a „date” mezőt. A ClickHouse-ban lévő kérésem nem nagyon-nagyon gyorsan futott, de gyorsan, azaz kevesebb mint egy másodperc alatt. Amikor láttam, mennyi sort dolgoz fel, megijedtem. Egy nap alatt annyi sort nem írunk ebbe a táblázatba. Elkezdtem elemezni a kérést, és láttam, hogy egy helyen kihagytam a dátumot. Azaz elfelejtettem megadni, hogy az adatok nem az egész táblázatból kellenek, hanem egy konkrét időszakra.
A Tabixban van egy „Statisztikák” fül, ahol az összes elküldött kérés története tárolódik, azaz ott lehet megnézni, hány sort olvasott be az adott kérés, és mennyi időbe telt a végrehajtása. Ez lehetővé teszi az optimalizálást.
A kérés eredménye fölött létre lehet hozni egy összesítő táblázatot. Elküldted a kérést a ClickHouse-ba, kaptál valamilyen adatokat. Azután ezeket az adatokat meg lehet húzni az egérrel, és létrehozni egy összesítő táblázatot.
A következő érdekes dolog a grafikonok létrehozása. Tegyük fel, hogy a következő kérésünk van: sin, cos 0 és 299 között. És hogy ezt megrajzoljuk, ki kell választani a „Rajzolás” fület, és megkapod a grafikonodat a sin és cos értékekkel.
Ezt külön tengelyekre lehet bontani, azaz egyszerre két grafikon is ábrázolható egymás mellett. Egyszerűen csak meg kell írni egy parancsot és egy másikat.
Lehet hisztogramokat is rajzolni.
Ezt mátrixra is lehet bontani.
Létre lehet hozni hőtérképet.
Létre lehet hozni hőkalendáriumot. Egyébként nagyon hasznos dolog, amikor az anomáliák elemzése történik egy év alatt, azaz vagy a kiugrásokat, vagy a csökkenéseket kell megtalálni. Nekem segített ez az adatelemző vizualizáció.
A következő a Treemap.
Sankeys – egy érdekes grafikon. Ez vagy Streamgraph, vagy River. De én River-nek hívom. Ez is lehetővé teszi anomáliák keresését. Nagyon kényelmes. Ajánlom, hogy használd anomáliák keresésére.
A következő érdekes dolog egy dinamikus térkép rajzolása. Ha az adatbázisodban tárolt szélességi és hosszúsági adatok vannak, valamint például egy rendeltetés, ha mondjuk autó szállítással vagy repülőgépekkel dolgozol, akkor a célok útvonalait meg lehet rajzolni. Itt a sebességet, az objektumok méretét is meg lehet adni, amelyekbe érkeznek.
De a térképpel az a probléma, hogy csak a világ térképét rajzolja, nincs részletezés.
Később hozzáadtam a Google térképet. Ha tárolod a szélességet és hosszúságot, akkor a Google térképen meg lehet rajzolni az eredményt, de anélkül, hogy a kis repülőgépeket támogatnánk.
A fő funkciókat, amelyek a Tabix keresési eredményeivel foglalkoznak, már megbeszéltük.
A következő a ClickHouse szervered elemzése. Van egy külön fül a 'Metrikák'-kal, ahol megnézheted a tárolt adatok méretét minden oszlopban. A képernyőfelvételen látható, hogy ez a 'referrer' mező körülbelül 730 Gb-ot foglal el. Ha lemondunk erről a mezőről, akkor három 700 GB-os shardot spórolunk meg, azaz körülbelül 2 TB-ot, amire nincs szükségünk.
Van egy 'request_id' mezőnk is, amit szövegként tárolunk. De ha elkezdjük numerikus formában tárolni, akkor ez a mező óriásit zsugorodna.
Itt a szerver konfigurációja és a klasztered csomópontjainak listája is látható.
A következő fül a metrikák. Ezek valós időben kerülnek lekérdezésre a ClickHouse-ból, és egyszerűen lehetővé teszik a szerver állapotának elemzését és megértését. Ez nem helyettesíti a teljes funkcionalitású Grafanát. Erre azért van szükség, hogy gyorsan elemezni tudjuk.
A következő fül a folyamatok. Ezek segítségével megértheted, mi történik a szerveren. Megértheted, mi zajlik ott. Volt egy lekérdezésem, ami minden alkalommal 200 GB-ot fogyasztott olvasáskor. Ezt az interfésznek köszönhetően észleltem. Megtörtént a javítás, így körülbelül 30 GB-ra csökkent, azaz a teljesítmény többszörösére nőtt.
Köszönöm! És ez OpenSource.
Befejeztem. És egyébként ez OpenSource, ingyenes, és nem is kell letöltened. Csak nyisd meg a böngésződben, és minden működni fog.
Kérdések
Igor, mi a következő lépés? Hová szeretnéd tovább fejleszteni ezt az eszközt?
Hamarosan megjelenik a dashboard, azaz lehet, hogy megjelenik a dashboard. Integráció más adatbázisokkal. Ezt elkészítettem, de még nem publikáltam OpenSource-ban. Ez MySQL és valószínűleg PostgreSQL. Azaz lehet majd a Tabix-ból lekérdezéseket küldeni nemcsak a ClickHouse-ba, hanem más eszközökbe is.
Látható, hogy óriási mennyiségű munka készült el. Egy elég teljes ötletről van szó. A böngészőben készült, feltehetően azért, hogy kizárja a mentő megoldásokat, és gyorsan összerakja ezt az egészet. Azt hallottam, hogy önök a php dolgoznak, így a legkönnyebb a böngészőben összerakni, és mindenhol működni fog. Ezzel kapcsolatban nincsen kérdés. Az a kérdés, hogy tényleg nagyon sok minden készült el. Hány ember dolgozott ezen? És mennyi időt vett ez igénybe? Mert az eszközök általában nem rendelkeznek ilyen nagy funkcionalitással.
Nyáron ősszel egy ember dolgozott a csapatunkból. Ez volt az első verzió. Aztán 330 committet csináltam egyedül. Amit lát, azt a kollégámmal félig-meddig csináltuk. Három hónap alatt az első verziótól az utolsóig én csináltam a legtöbb részt. De nagyon rosszul ismerem a Javascriptet. Ez volt az egyetlen és, remélem, utolsó projektem a Javascripttel, amivel dolgoztam. Megkaptam, megnéztem – ó, borzalom. De nagyon szerettem volna befejezni a terméket, és így alakult.
Nagyon köszönöm az előadást! Ez egy nagyszerű eszköz. Összehasonlították? Tableau Köszönöm. Ezért is neveztem Tabixnak, mert az első betűk egybeesnek.
Mert versenyeznek?
Sok befektetés lesz, versenyezni fogunk.
Hogyan javasolja eladni a belső elemzőknek, hogy ez az eszköz teljesen helyettesíti a
*Tableau*-t Natívan működik a ClickHouse-szal. Kipróbáltam a Tableau-t, de ott nem lehet szótárak támogatását írni és hasonlókat.? Какие будут аргументы?
Tudom, hogyan dolgoznak a Tabix-szal az emberek. Lekérdezést írnak, CSV-be exportálnak, majd betöltik az BI-ba. Ott már valamit csinálnak. De nehezen tudom elképzelni, hogyan csinálják, mert – ez egy grafikus eszköz. Maximum 5 000 sort, legfeljebb 6 000 sort tud exportálni, de többet nem, különben a böngésző nem bírja. Azaz komoly korlátok vannak az adatmennyiség szempontjából, ugye?
Igen. Nem tudom elképzelni, hogy el akarná küldeni magának a 10 000 sort a böngésző képernyőjére. Minek?
Azt feltételezzük, hogy ez egy gyors adatmegtekintő felület? Kicsit megnézni, forgatni?
Igen, így van.
Igen, gyorsan meg lehet nézni, hogyan működik, és egyszerűen össze lehet állítani egy összefoglaló grafikont. Aztán tovább lehet adni valahová. Nálunk ez egy saját riportáló rendszer, ahonnan egyszerűen átveszem ezt a lekérdezést. Megrajzolom a Tabix-ben és elküldöm a riportunkba.
És még egy kérdés. Kohorszelemzés?
Ha lesznek kérések, hozzáadjuk.
Amikor csak kezdtük használni a ClickHouse-t, mennyi időbe került az implementálás clickhousedb_fdw és eljuttatás a production állapotáig?
Ahogy mondtam, a teszt klaszterünket nagyon rövid idő alatt implementáltuk. Két nap alatt beüzemeltük. És még pár hétig teszteltük. A production-hoz körülbelül 3 hónap alatt jutottunk el. De nekünk volt saját ETL-ünk, azaz adatfolyamtanító eszköz. Ez mindenhová írt, amire csak lehetett. Tud íni MongoDB-be, Cassandra-ba, MySQL-be. Megtanítani, hogy írjon ClickHouse-ba, egyszerű volt. Kész infrastruktúránk volt a gyors implementáláshoz. Másfél hónap alatt kezdtük el kidobni az első komponenst. Hat hónap alatt teljesen lemondtunk minden másról. Csak a ClickHouse maradt.
Igor, nagyon köszönöm az előadást. Nagyon tetszett a térképek útvonalainak felépítése. Tervezik az integrációt a Yandex.Maps-szel és különösen a testreszabott Yandex.Maps-szel?
Megpróbáltam integrálni a Google térkép helyett, de nem találtam sötét témát a Yandex.Térképeken. Egy dolgot nem meséltem el. Visszatekerem, hogy kiegészítsem.
Dia – Google térkép. Ott van a „DRAW_GMAPS” parancs, amely megrajzolja a térképet. Van egy „DRAW_YMAPS” parancs is, azaz képes megrajzolni a Yandex.Térképet. Valójában ezen a parancson belül Javascript található, tehát az adatokat, amelyeket a ClickHouse-ból nyer, át lehet adni a Javascriptnek, amit itt írhatsz. És van egy terület, ahol meg kell rajzolnia. Bármilyen grafikont meg lehet rajzolni, tehát bármilyen grafikont, térképet, saját komponenst is megrajzolhatsz. Korábban volt egy másik könyvtáram a grafikonszerkesztéshez.
Tehát van eszköz a megjelenítés funkciójának testreszabására?
Bármilyen. Lehet venni és átfesteni ezeket a pontokat, hogy ne pirosak legyenek, hanem kékek, zöldek.
Köszönöm az előadást! Volt egy diád, amely alternatív lekérdező eszközöket mutatott be clickhousedb_fdw a műszerfalak és analitikai jelentések létrehozására. Jól értettem, hogy abban az időben, amikor elkezdtél dolgozni A ClickHouse-hez nem írtak adaptereket ezekhez az eszközökhöz. Érdekes, hogy miért döntöttél úgy, hogy saját eszközt készítesz, ahelyett, hogy írtál volna egy adaptert valamilyen kész eszközhöz? Szerintem a tesztelő szerkesztő finomhangolása gyorsan megoldható. Miért döntöttél úgy, hogy ennyi munkát elvégzel?
Itt egy érdekes részlet – a lényeg az, hogy én technikai igazgató vagyok, nem pedig adatkutató. Abban az időszakban, amikor elkezdtük bevezetni a Druidet, a tervezési ütemtervemen körülbelül 50%-nyi feladat volt – számoljunk ki ezt, vagy azt, vagy elemezzük ezt. Így végül bevezettük a ClickHouse-t. Gyorsan elkezdtem mindent építeni, számolni, gyorsan lezártam a tervezési ütemtervemet. Ekkor észrevettem, hogy hiányzik a tudásom az Adatkutatás, adatvizualizáció terén. A Tabix egyfajta házi feladat számomra az adatvizualizáció tanulmányozásához. Néztem, hogyan lehet kiegészíteni a Zeppelint. Van egy enyhe ellenszenv hozzájáruláshoz. A Redash-t is megnéztem, hogyan lehet kiegészíteni, de nem volt jó szerkesztő. A SuperSet is azon a nyelven készült, ami nem tetszik annyira. Ezért döntöttem úgy, hogy sajátot készítek, és ez lett belőle.
Igor, fogadod a Pull Request-eket?
Igen.
Nagyon köszönöm az előadást! Két kérdésem van. Az első – nem nagyon dicséritek a Javascript-t. Nyílt Javascript-t használtál, vagy valamilyen keretrendszert?*
Jobb a nyílt Javascript.
Szóval, milyen keretrendszert használtál?
Angular.
Értem. A második kérdés. Nem fontolgattátok a R és *Shiny**?*
Néztem. Játszottam vele.
Ezt is egyszerűen lehetett volna egy adaptert írni.
Van. Azt hiszem, a közösség készítette, de, ahogy az előző kérdésre válaszoltam, szerettem volna saját magam kipróbálni.
*Nem, az adatvizualizációval kapcsolatban, ott van.
Azt mondod, van egy ilyen dolog, és az képes grafikonokat generálni. Megnyitottam egy könyvet az adatvizualizációról. És gondoltam: „Próbálom meg ezt az adatot vizualizálni. Magam készítem el, hogy felépítse az adatokat”. Így kezdtem jobban megérteni az adatok bemutatásának technológiáját. Ha egy kész komponenst használtam volna, személyesen rosszabbul tanultam volna meg használni, azaz az adatvizualizációt. De így – igen, az R tetszett, de még nem olvastam el az „R a kezdőknek” könyvet.
Köszönöm!
Egyszerű kérdés. Vannak lehetőségek gyorsan exportálni táblázatot, grafikont?
CSV-be, Excel-be exportálható.
Nem az adatokat, hanem egy kész táblázatot, kész grafikont? Például, hogy bemutassam a főnöknek.
Van egy "Kiexportálás" gomb, és van egy "Grafikon kiexportálása png, jpg formátumban" gomb.
Köszönöm!
P.S. Mini utasítás a tabix telepítéséhez
- Letöltés
- Kicsomagolni, másolni a könyvtárat
buildaz nginx root_path-jába - nginx beállítása
Forrás: habr.com
