Zachęcam do zapoznania się z transkrypcją raportu z 2017 roku Igora Strycharya "ClickHouse – wizualnie szybka i czytelna analiza danych w Tabix."
Interfejs webowy dla ClickHouse w projekcie Tabix.
Podstawowe funkcje:
- Działa z ClickHouse bezpośrednio z przeglądarki, bez potrzeby instalacji dodatkowego oprogramowania;
- Edytor zapytań z podświetlaniem składni;
- Autouzupełnianie poleceń;
- Narzędzia do graficznej analizy wykonania zapytań;
- Schematy kolorów do wyboru.
Jestem dyrektorem technicznym w СМИ2. Jesteśmy agregatorem wiadomości. Przechowujemy dużą ilość danych, które otrzymujemy od naszych partnerów i rejestrujemy je w ClickHouse – około 30 000 zapytań na sekundę.
To takie dane, jak:
- Kliknięcia w wiadomości.
- Wyświetlenia wiadomości w agregatorze.
- Wyświetlenia bannerów w naszej sieci.
- I rejestrujemy wydarzenia z naszego własnego licznika, który działa jak Yandex.Metrica. To nasza własna mikroanaliza.
Mieliśmy bardzo burzliwe życie przed ClickHouse. Mieliśmy ogromne trudności z przechowywaniem tych danych oraz ich analizowaniem.
Życie przed ClickHouse – infiniDB
Pierwsze, co mieliśmy, to infiniDB. Używaliśmy jej przez 4 lata. Uruchomiliśmy ją z ogromnym trudem.
- Nie obsługiwała klasteryzacji ani shardingu. Żadne z takich inteligentnych rozwiązań nie działały od razu z pudełka.
- Miała trudności z załadowaniem danych. Tylko specyficzna konsolowa użyteczność, która potrafiła ładować tylko pliki CSV i to w bardzo niejasny sposób.
- Baza danych była jednoprotokółowa. Można było albo pisać, albo czytać. Ale pozwalała przetwarzać duże ilości danych.
- I miała jeszcze interesujący błąd. Każdej nocy trzeba było restartować serwer, inaczej przestawał działać.
Działała do końca 2016 roku, kiedy w pełni przeszliśmy na ClickHouse.
Życie przed ClickHouse – Cassandra
Ponieważ infiniDB była jednoprotokółowa, postanowiliśmy, że potrzebujemy jakiejś wielowątkowej bazy, w której możemy jednocześnie pisać bardzo wiele wątków.
Wypróbowaliśmy wiele interesujących rozwiązań. Następnie postanowiliśmy spróbować Cassandry. Z Cassandrą wszystko szło świetnie. 10 000 zapytań na sekundę przy zapisie, 2 000 zapytań gdzieś przy odczycie.
Ale miała też swoje ciekawostki. Raz w miesiącu lub co dwa miesiące dochodziło do desynchronizacji bazy danych. I trzeba było wstawać i biec naprawiać Cassandrę. Restartowaliśmy serwery po kolei. I wszystko stawało się gładkie i ładne.
Życie przed ClickHouse - Druid
Potem zrozumieliśmy, że musimy jeszcze więcej pisać danych. W 2016 roku zaczęliśmy przyglądać się Druid.
Druid to otwarta baza danych napisana w Javie. Bardzo specyficzna. Idealnie pasowała do clickstream, gdy potrzebowaliśmy przechowywać pewien strumień zdarzeń, a następnie wykonywać na nich agregacje lub tworzyć raporty analityczne.
Druid miał wersję 0.9.X.
Sama baza danych rozkłada się bardzo ciężko. To złożoność infrastruktury. Aby ją uruchomić, trzeba było postawić bardzo dużo sprzętu. A każdy sprzęt odpowiadał za swoją odrębną rolę.
Aby załadować do niej dane, trzeba było stosować jakieś czary. Istnieje projekt OpenSource - Tranquility, który w strumieniu tracił nasze dane. Kiedy ładowaliśmy do niego dane, je gubił.
Ale jakoś zaczęliśmy go wdrażać. Jak jeże, które się kłują, ale dalej jedzą kaktus, zaczęliśmy go wprowadzać. Zajęło nam to około miesiąca, aby przygotować całą infrastrukturę pod niego. Tzn. zamówić serwery, skonfigurować role, przeprowadzić pełną automatyzację rozkładania. Tzn. w przypadku awarii klastra, aby automatycznie uruchomił się drugi klaster.
Ale tu zdarzyło się cud. Byłem na urlopie, a moi koledzy przesyłają mi link do , w którym mówi się, że Yandex postanowił otworzyć ClickHouse. Mówię, spróbujmy.
I dosłownie w ciągu 2 dni uruchomiliśmy testowy klaster ClickHouse. Zaczęliśmy ładować do niego dane. W porównaniu do infiniDB - to elementarne, w porównaniu do Druid - to elementarne. W porównaniu do Cassandry również elementarne. Ponieważ, jeśli ładować dane z php do Cassandry, to nie jest elementarne.
Co zyskaliśmy? Wydajność w prędkości. Wydajność w przechowywaniu danych. Tzn. używa znacznie mniej miejsca na dysku. ClickHouse - jest szybki, naprawdę szybki w porównaniu do innych produktów.
W momencie uruchomienia, gdy Yandex opublikował ClickHouse w OpenSource, istniał tylko klient konsolowy. W naszej firmie MEDIA2 postanowiliśmy spróbować stworzyć natywny klient webowy, aby można było otworzyć stronę w przeglądarce, napisać zapytanie i uzyskać wynik, ponieważ zaczęliśmy pisać dużo zapytań. Pisanie w konsoli jest trudne. I zrobiliśmy naszą pierwszą wersję.
I gdzieś bliżej zimy zeszłego roku zaczęły pojawiać się zewnętrzne narzędzia do pracy z ClickHouse. To takie narzędzia, jak:
- .
- .
- . (Teraz )
- .
- .
Przedstawię kilka z tych narzędzi, tzn. tych, z którymi pracowałem.
Dobre narzędzie, ale dla Druid. Kiedy wdrażaliśmy Druid, testowałem SuperSet. Spodobał mi się. Działa bardzo szybko dla Druid.
Nie nadaje się dla ClickHouse. Tzn. działa, ale obsługuje tylko podstawowe zapytania, takie jak: SELECT event, GROUP BY event. Nie wspiera bardziej złożonej składni ClickHouse.
Następne narzędzie – Apache Zeppelin. To dobre i ciekawe rozwiązanie. Działa. Obsługuje notatniki, pulpity nawigacyjne i zmienne. Wiem, że ktoś z społeczności ClickHouse go używa.
Ale nie ma wsparcia dla składni ClickHouse, tzn. będzie trzeba pisać zapytania albo w konsoli, albo gdzie indziej. Następnie trzeba sprawdzić, czy wszystko działa. To po prostu niewygodne. Ale wsparcie dla dashboardów jest bardzo dobre.
Kolejnym narzędziem jest Redash.IO. Redash jest hostowane w internecie. Tzn. w przeciwieństwie do poprzednich narzędzi, nie ma potrzeby go instalować. To takie rozwiązanie do tworzenia pulpitów nawigacyjnych z możliwością konsolidacji danych z różnych źródeł danych. Tzn. możesz wydobywać dane z ClickHouse, MySQL, PostgreSQL i innych baz danych.
Zaledwie miesiąc temu (w marcu 2017 roku) dodano wsparcie w Grafana. Kiedy budujesz raporty w Grafana, powiedzmy, dotyczące stanu twojego sprzętu lub jakichś metryk, teraz można tworzyć taki sam wykres lub jakiś panel z danych z ClickHouse bezpośrednio. To bardzo wygodne, i my to u siebie wykorzystujemy. To pozwala na wykrywanie anomalii. Tzn. jeśli coś się dzieje i jakiś sprzęt zawodzi lub jest obciążony, można przeanalizować przyczynę, jeśli te dane zdążyły trafić do ClickHouse.
Pisanie w tych narzędziach lub w konsoli było dla mnie bardzo niewygodne. Postanowiłem więc poprawić nasz pierwszy interfejs. Zainspirowałem się pomysłem z EventSQL, SuperSet, Zeppelin.
Czego chciałem? Chciałem uzyskać wykresy, lepszy edytor, wdrożyć wsparcie dla słowników podpowiedzi. Ponieważ ClickHouse ma świetną funkcję – słowniki. Ale praca ze słownikami jest trudna, ponieważ trzeba pamiętać format przechowywanych wartości, tzn. czy to liczba, czy ciąg tekstowy itd. A ponieważ często używamy słowników w różnych wariantach, pisanie zapytań było dosyć trudne.
Minęły 3 miesiące od wydania naszej pierwszej wersji. Zrobiłem około 330 commitów w zamkniętej gałęzi i powstał Tabix.
W przeciwieństwie do poprzedniej wersji o nazwie ClickHouse-Frontend, postanowiłem nadać jej prostą nazwę. Tak powstał Tabix.
Co nowego?
Rysuje wykresy. Obsługuje składnię SQL ClickHouse. Podpowiada funkcje i posiada wiele innych interesujących możliwości.
Oto jak wygląda ogólny schemat Tabix. Po lewej stronie znajduje się drzewo. Na środku – to edytor zapytań. A na dole – to wynik tego zapytania.
Pokażę teraz, jak działa edytor zapytań.
Tutaj automatyczne uzupełnienie zadziałało na tabeli i odpowiednio podpowiada uzupełnianie pól oraz funkcje. Jeśli naciśniesz Ctrl + Enter, zapytanie zostanie wykonane lub zakończy się błędem. Najprostsze zapytanie wysyła się do Tabix, a wynik otrzymujemy, czyli można szybko pracować z ClickHouse.
Słowniki, jak już wspomniałem, to bardzo interesująca rzecz, z którą wiele pracujemy. Umożliwiły one zrealizowanie wielu rzeczy. Na przykład w słownikach przechowujemy wszystkie miasta. Przechowujemy identyfikator miasta oraz jego nazwę, szerokość i długość geograficzną. A w bazie danych trzymamy tylko identyfikator miasta. Dzięki temu znacznie kompresujemy dane.
To wydaje się prostą rzeczą, ale w ClickHouse naprawdę dobrze się sprawdza. Ponieważ ClickHouse obsługuje tylko zagnieżdżone złączenia, zapytanie rośnie w dół i w szerokości dość mocno. Gdy otwierasz nawias i pojawia się długie wyrażenie, to taka dość prosta rzecz, jak zwijanie zapytania, pozwala łatwiej pracować z samym zapytaniem. Bo gdy zapytanie ma 200-300 linii i jego szerokość jest ogromna, zwijanie zapytania bardzo pomaga znaleźć konkretne miejsce lub w inny sposób je zlokalizować.
Drzewo obiektów, wiele zapytań i karty (Wideo 13:46 )
Następnie pokażę o drzewie, kartach. Po lewej stronie znajduje się drzewo, na górze możesz tworzyć kilka kart. Karty to jak obszar roboczy. Możesz stworzyć kilka kart i nazwać je według własnych preferencji. To jak mini-system do tworzenia raportów.
Karty są automatycznie zapisywane. Jeśli odświeżysz przeglądarkę lub zamkniesz, lub otworzysz Tabix, wszystko to pozostanie.
Skrót klawiszowy – wygodne (Wideo 14:39 )
Są skróty klawiszowe i jest ich całkiem sporo. Wypisałem niektóre z nich tutaj jako przykład. To przełączanie kart, wykonanie zapytania lub wykonanie kilku zapytań.
Pokażę, jak pracować z wynikiem. Wysyłamy zapytanie. Tutaj rysuję sin, cos i tg. Można podświetlić wynik, tzn. stworzyć typową mapę kolumnową. Można podświetlić dodatnie lub ujemne wartości. Albo po prostu pokolorować konkretny element tabeli. To jest wygodne, gdy tabela jest ogromna i trzeba na oko znaleźć jakąś anomalię. Gdy szukałem anomalii, podświetlałem niektóre wiersze, pewne elementy na zielono lub czerwono.
Jest tam wiele interesujących rzeczy. Na przykład, jak skopiować do Redmine w Markdown. Jeśli trzeba przekopiować gdzieś wynik, to jest to bardzo wygodne. Można po prostu zaznaczyć obszar, powiedzieć „Kopiuj do Redmine”, a on skopiuje do Markdown Redmine lub stworzy zapytanie Where.
Dalej - to optymalizacja zapytań. Raz zapomniałem wskazać pole „data”. I moje zapytanie w ClickHouse było przetwarzane nie bardzo szybko, ale szybko, tzn. w mniej niż sekundę. Gdy zobaczyłem, ile on danych przetwarza, przeraziłem się. Nie piszemy w tej tabeli tyle w ciągu dnia. Zacząłem analizować zapytanie i zauważyłem, że w jednym miejscu pominąłem datę. Tzn. zapomniałem wskazać, że potrzebne mi dane nie z całej tabeli, a za jakiś konkretny okres.
W Tabix jest zakładka „Statystyki”, w której przechowywana jest cała historia wysłanych zapytań, tzn. można tam zobaczyć, ile wierszy zostało odczytanych tym zapytaniem i ile czasu trwało jego wykonanie. To pozwala na optymalizację.
Na podstawie wyniku zapytania można zbudować tabelę przestawną. Wysłałeś zapytanie do ClickHouse, otrzymałeś jakieś dane. A następnie te dane można przeciągać myszką i stworzyć jakąś tabelę przestawną.
Następną interesującą rzeczą jest budowanie wykresów. Załóżmy, że mamy takie zapytanie: dla sin, cos od 0 do 299. Aby go narysować, należy wybrać zakładkę „Rysuj” i otrzymasz wykres z twoimi sin i cos.
Można podzielić to na różne osie, tzn. można narysować od razu dwa wykresy obok siebie. Napisać jedną komendę i drugą komendę.
Można narysować histogramy.
Można podzielić to na matrycę wykresów.
Można zbudować mapę cieplną.
Można zbudować cieplny kalendarz. Nawiasem mówiąc, to bardzo wygodne, gdy trzeba przeanalizować anomalie za rok, tzn. znaleźć albo wzrosty, albo spadki. Ta wizualizacja danych bardzo mi w tym pomogła.
Następny – to Treemap.
Sankeys – interesujący diagram. To albo Streamgraph, albo River. Ja nazywam to River. Umożliwia także wyszukiwanie pewnych anomalii. Jest bardzo wygodny. Polecam jego użycie do wyszukiwania.
Następną interesującą rzeczą jest rysowanie dynamicznej mapy. Jeśli w twojej bazie danych przechowywana jest szerokość, długość geograficzna i, powiedzmy, cel, na przykład, transporty drogowe lub loty samolotowe, to można narysować trasy do celu. Tam można również ustawić prędkość, rozmiar tych obiektów, do których przylatują.
Jednak problem z tą mapą polega na tym, że rysuje tylko mapę świata, brakuje szczegółowości.
Później dodałem Google map. Jeśli przechowujesz szerokość, długość geograficzną, możesz narysować wynik na Google mapie, ale bez wsparcia dla samolotów.
Podstawowe funkcje pracy z wynikiem, z zapytaniem w Tabix, omówiliśmy.
Kolejny krok – analiza twojego serwera ClickHouse. Jest osobna zakładka „Metryki”, w której można zobaczyć rozmiar przechowywanych danych dla każdej kolumny. Na zrzucie ekranu pokazano, że to pole „referrer” zajmuje około 730 GB. Jeśli zrezygnujemy z tego pola, zaoszczędzimy trzy shard'y po 700 GB, czyli około 2 TB, które nie są nam potrzebne.
Mamy też pole „request_id”, które przechowujemy w postaci tekstowej. Ale jeśli zaczniemy je przechowywać w formie numerycznej, to znacznie je skompresuje.
Tutaj pokazana jest również konfiguracja serwera i lista węzłów twojego klastra.
Kolejna zakładka – to metryki. Są pobierane w czasie rzeczywistym z ClickHouse i po prostu pozwalają przeanalizować stan serwera i zrozumieć, co się z nim dzieje. To nie zastępuje pełnoprawnej Grafany. To potrzebne, aby szybko przeanalizować.
Kolejna zakładka – to procesy. Dzięki nim można zrozumieć, co dzieje się na serwerze. Zrozumieć, co tam się dzieje. Miałem zapytanie, które za każdym razem brało 200 GB do odczytu. Zobaczyłem to dzięki temu interfejsowi. Złapałem to i poprawiłem. I wyszło około 30 GB, czyli wydajność jest o wiele lepsza.
Dziękuję! A to jest w OpenSource
Skończyłem. I, nawiasem mówiąc, to w OpenSource, jest darmowe i nawet nie trzeba pobierać. Otwieraj w przeglądarce i wszystko będzie działać.
Pytania
Igor, co dalej? Gdzie zamierzasz rozwijać to narzędzie?
Wkrótce pojawi się panel sterowania, tzn. być może pojawi się panel sterowania. Integracja z innymi bazami danych. Zrobiłem to, ale jeszcze nie opublikowałem w OpenSource. To MySQL i być może PostgreSQL. Tzn. będzie można wysyłać zapytania z Tabix nie tylko do ClickHouse, ale także do innych narzędzi.
Widać, że zrobiono ogromną pracę. Powstała dość kompletna idea. Zrobiono to w przeglądarce, najwyraźniej, aby wykluczyć obejścia na różnych osiach i szybko to wszystko zrealizować. Słyszałem, że pracujecie nad tym, więc najłatwiej jest to zrobić w przeglądarce, i wszędzie to będzie działać. Nie ma z tym pytań. Pytanie brzmi: ile osób nad tym pracowało? Ile czasu to zajęło? Bo zwykle narzędzia dostosowane do siebie nie mają takiego dużego funkcjonalności. php Od lata do jesieni pracował nad tym jeden człowiek z naszego zespołu. To była pierwsza wersja. Potem 330 commitów zrobiłem sam. To, co widzicie, zrobiliśmy z kolegą po równo. W ciągu 3 miesięcy z pierwszej wersji do ostatniej w większości zrobiłem to sam. Ale bardzo słabo znam Javascript. To był mój jedyny i, mam nadzieję, ostatni projekt w Javascript, nad którym pracowałem. Dostałem go, spojrzałem – o zgrozo. Ale bardzo chciałem doprowadzić produkt do końca i oto co wyszło.
Bardzo dziękuję za prezentację! To doskonałe narzędzie. Czy porównywaliście z *Tableau*?
Dziękuję. Dlatego nazwałem to Tabix, ponieważ pierwsze litery się zgadzają. Bo konkurujecie? Będzie dużo inwestycji, będziemy konkurować.
Jak proponujecie sprzedać to wewnętrznym analitykom, że to narzędzie w pełni zastąpi *Tableau*?
Działa natywnie z ClickHouse. Próbowałem *Tableau*, ale tam nie można pisać wsparcia dla słowników i tym podobnych rzeczy.
Wiem, jak pracują z Tabix ludzie. Piszą zapytania, eksportują do CSV i ładują do BI.
I tam już coś robią. Ale trudno mi wyobrazić sobie, jak to robią, bo to jest narzędzie graficzne. Może wyeksportować maksymalnie 5 000 wierszy, maksymalnie 6 000 wierszy, ale nie więcej, w przeciwnym razie przeglądarka nie wytrzyma. Tzn. są jakieś poważne ograniczenia co do objętości danych, tak?? Какие будут аргументы?
Tak. Nie wyobrażam sobie, że zechcesz wyeksportować 10 000 wierszy na ekran przeglądarki. Po co? Domyślnie to interfejs do szybkiego przeglądania danych? Trochę pokręcić, powertować? Czy to jest zamysłem?
No, tak!.
Tu chodzi o to, aby szybko zorientować się w danych. Dobrze, że podzieliłem się tym z wami.
Czy to nie jest pomyłka?
Tak, szybko zobaczyć, jak to działa i po prostu stworzyć zbiorczy wykres. A potem przekazać gdzie indziej. Mamy nasz własny system raportowania, z którego po prostu biorę to zapytanie. Rysuję w Tabix i wysyłam do naszego raportowania.
I jeszcze jedno pytanie. Analiza kohortowa?
Jeśli będą sugestie, dodamy.
Kiedy dopiero zaczynaliśmy korzystać ClickHouse, ile czasu zajęło wdrożenie ClickHouse i doprowadzenie do stanu produkcyjnego?
Jak powiedziałem, wdrożyliśmy testowy klaster w bardzo krótkim czasie. W dwa dni go uruchomiliśmy. A przez kolejne kilka tygodni go testowaliśmy. Do stanu produkcyjnego dotarliśmy w około 3 miesiące. Mieliśmy własny ETL, tzn. narzędzie do ładowania danych. I pisał on do wszystkiego, co tylko można. Umiemy pisać do MongoDB, Cassandra, MySQL. Nauczenie go pisania do ClickHouse było proste. Mieliśmy gotową infrastrukturę do szybkiego wdrożenia. W ciągu około 3 miesięcy zaczęliśmy wycofywać pierwszy komponent. Po 6 miesiącach całkowicie zrezygnowaliśmy ze wszystkiego innego. Został nam tylko ClickHouse.
Igor, bardzo dziękuję za prezentację. Bardzo podobała mi się funkcjonalność budowania ścieżek na mapach. Czy planowana jest integracja z Yandex.Maps, a konkretnie z niestandardowymi mapami Yandex?
Próbowałem zintegrować się zamiast Google map, ale nie znalazłem ciemnego motywu na Yandex.Maps. Nie powiedziałem jednego fragmentu. Cofnę się, aby uzupełnić.
Slajd – Google map. Tam jest polecenie „DRAW_GMAPS”, które rysuje mapę. Jest polecenie „DRAW_YMAPS”, co oznacza, że może narysować mapę Yandex. A tak naprawdę pod tym poleceniem znajduje się JavaScript, tzn. dane, które otrzymujecie z ClickHouse, można przekazać do JavaScript, który napiszecie tutaj. I macie na wyjściu obszar, w którym powinna zostać narysowana. Można narysować dowolny wykres, tzn. każdy wykres, mapę, możecie narysować swój własny komponent. Wcześniej miałem inną bibliotekę do rysowania samych wykresów.
Tzn. jest tam narzędzie do dostosowywania funkcjonalności wyświetlania?
Jakiekolwiek. Można wziąć i przebarwić te punkty, uczyniwszy je nie czerwonymi, a niebieskimi, zielonymi.
Dziękuję za prezentację! Mieliście slajd, na którym przedstawione były alternatywne narzędzia do zapytań ClickHouse do budowania pulpitów nawigacyjnych, raportów analitycznych. Zrozumiałem, że w momencie, gdy zaczęliście pracować z ClickHouse, dla tych narzędzi nie były napisane adaptery. Ciekawe, dlaczego zdecydowaliście się stworzyć własne narzędzie, zamiast napisać adapter do jakiegoś gotowego rozwiązania? Myślę, że dostrojenie edytora testowego to szybka sprawa. Dlaczego zdecydowaliście się na tyle pracy?
Tu jest ciekawy moment – bowiem jestem CTO, a nie data scientist. W momencie, gdy zaczęliśmy wdrażać Druid, w moim planie było gdzieś 50% zadań – policzmy to lub to, albo to przeanalizujmy. I wyszło tak, że wdrożyliśmy ClickHouse. Szybko wszystko zbudowałem, policzyłem, szybko zamknąłem mój plan. I w tamtym momencie zrozumiałem, że brakuje mi wiedzy w zakresie Data Science, w zakresie wizualizacji danych. Tabix – to trochę moje domowe zadanie w zakresie uczenia się wizualizacji danych. Patrzyłem, jak dodać Zeppelin. Mam niewielką niechęć do jego programowania. Redash też zobaczyłem, jak wzbogacić, ale brakowało mi tam normalnego edytora. A SuperSet też jest napisany w języku, którego zbytnio nie lubię. Dlatego zdecydowałem się na zbudowanie własnego rozwiązania, i oto, co z tego wyszło.
Igor, przyjmujesz pull requesty?
Tak.
Dziękuję bardzo za prezentację! I dwa pytania. Po pierwsze – nie bardzo pochlebnie wyrażasz się o Javascript. Pisałeś w czystym Javascript, czy jednak używałeś jakiegoś frameworka?*
Lepiej w czystym Javascript.
Więc jaki framework?
Angular.
Rozumiem. A drugie pytanie. Czy rozważałeś R i *Shiny**?*
Rozważałem. Bawiłem się tym.
Można było też po prostu napisać adapter.
Jest. Chyba społeczność go zrobiła, ale tak jak odpowiadałem na poprzednie pytanie, chciałem osobiście spróbować.
*Nie, jeśli chodzi o wizualizację, tam to już jest.
Mówisz, że jest coś takiego i to narysuje ci wykres. Otworzyłem książkę o wizualizacji danych. I pomyślałem: „Spróbuję to zwizualizować. Sam napiszę, żeby to odtworzyło dane”. I zacząłem lepiej rozumieć technologię podawania danych. A gdybym wziął gotowy komponent, osobiście gorzej bym nauczył się go używać, tzn. dokładnie wizualizacji. Ale tak – tak, R mi się spodobał, ale jeszcze nie czytałem książki „R dla dążących do przodujących”
Dziękuję!
Proste pytanie. Czy są jakieś możliwości szybkiego wyeksportowania tabeli, wykresu?
Można wyeksportować do CSV, do Excela.
Nie danych, a gotowej tabeli, gotowego wykresu? Na przykład, aby pokazać kierownictwu.
Jest przycisk „Eksportuj” oraz przycisk „Eksportuj wykres do png, jpg”.
Dziękuję!
P.S. Krótka instrukcja instalacji tabix
- Pobierz
- Rozpakować, skopiować katalog
builddo nginx root_path - Skonfigurować nginx
Źródło: habr.com
