Teoria i praktyka wykorzystania ClickHouse w rzeczywistych aplikacjach. Aleksander Zajcew (2018)

Pomimo tego, że danych jest teraz bardzo dużo, niemal wszędzie, analityczne bazy danych są nadal dość egzotyczne. Są słabo poznane, a co gorsza potrafią je efektywnie wykorzystać. Wielu nadal „je kaktusa” z MySQL lub PostgreSQL, które są przeznaczone do innych scenariuszy, cierpi z powodu NoSQL lub przepłaca za rozwiązania komercyjne. ClickHouse zmienia reguły gry i znacznie obniża próg wejścia w świat analitycznego DBMS.

Relacja z BackEnd Conf 2018 i została opublikowana za zgodą prelegenta.

Kim jestem i dlaczego mówię o ClickHouse? Jestem dyrektorem ds. rozwoju w firmie LifeStreet, która korzysta z ClickHouse. Jestem także założycielem Altinity. Jest partnerem Yandex, który promuje ClickHouse i pomaga Yandex uczynić ClickHouse bardziej skutecznym. Gotowy również do dzielenia się wiedzą o ClickHouse.

I nie jestem bratem Pietii Zajcewa. Często jestem o to pytany. Nie, nie jesteśmy braćmi.

„Wszyscy wiedzą”, że ClickHouse:

• Bardzo szybki,
• Bardzo wygodny
• Używany w Yandexie.

Nieco mniej wiadomo, w jakich firmach i jak jest wykorzystywana.

Powiem ci, dlaczego, gdzie i jak jest używany ClickHouse, z wyjątkiem Yandex.

Opowiem Ci, jak rozwiązuje się konkretne zadania z pomocą ClickHouse w różnych firmach, jakich narzędzi ClickHouse możesz użyć do swoich zadań i jak zostały one wykorzystane w różnych firmach.

Wybrałem trzy przykłady pokazujące ClickHouse pod różnymi kątami. Myślę, że będzie ciekawie.

Pierwsze pytanie brzmi: „Po co nam ClickHouse?”. Wydaje się, że to dość oczywiste pytanie, ale jest na nie więcej niż jedna odpowiedź.

• Pierwsza odpowiedź dotyczy wydajności. ClickHouse jest bardzo szybki. Analityka w ClickHouse jest również bardzo szybka. Często można go użyć, gdy coś innego działa bardzo wolno lub bardzo źle.
• Druga odpowiedź to koszt. A przede wszystkim koszt skalowania. Na przykład Vertica to absolutnie świetna baza danych. Działa bardzo dobrze, jeśli nie masz dużo terabajtów danych. Ale jeśli chodzi o setki terabajtów lub petabajtów, koszt licencji i wsparcia idzie w dość znaczną kwotę. I to jest drogie. A ClickHouse jest darmowy.
• Trzecia odpowiedź to koszty operacyjne. To jest trochę inne podejście. RedShift to świetny analog. Na RedShift możesz bardzo szybko podjąć decyzję. Będzie działać dobrze, ale jednocześnie co godzinę, codziennie i co miesiąc, zapłacisz Amazonowi dość drogo, ponieważ jest to znacznie droga usługa. Google BigQuery też. Jeśli ktoś z tego korzystał, to wie, że można tam uruchomić kilka próśb i nagle dostać rachunek na setki dolarów.

ClickHouse nie ma tych problemów.

Gdzie jest teraz używany ClickHouse? Oprócz Yandex, ClickHouse jest używany w wielu różnych firmach i firmach.

• Przede wszystkim jest to analityka aplikacji internetowych, tj. jest to przypadek użycia, który pochodzi z Yandex.
• Wiele firm AdTech korzysta z ClickHouse.
• Wiele firm, które muszą analizować dzienniki transakcji z różnych źródeł.
• Kilka firm używa ClickHouse do monitorowania dzienników bezpieczeństwa. Przesyłają je do ClickHouse, tworzą raporty i uzyskują wyniki, których potrzebują.
• Firmy zaczynają wykorzystywać go w analizie finansowej, czyli stopniowo do ClickHouse zbliżają się także duże firmy.
• Rozbłysk chmur. Jeśli ktoś śledzi ClickHouse, to zapewne słyszał nazwę tej firmy. Jest to jeden z najważniejszych współpracowników społeczności. I mają bardzo poważną instalację ClickHouse. Na przykład stworzyli Kafka Engine dla ClickHouse.
• Firmy telekomunikacyjne zaczęły używać. Kilka firm korzysta z ClickHouse albo jako dowód koncepcji, albo już w produkcji.
• Jedna firma wykorzystuje ClickHouse do monitorowania procesów produkcyjnych. Testują mikroukłady, odpisują kilka parametrów, jest około 2 cech. A potem analizują, czy gra jest dobra, czy zła.
• Analityka łańcucha bloków. Jest taka rosyjska firma jak Bloxy.info. To jest analiza sieci ethereum. Zrobili to również w ClickHouse.

I rozmiar nie ma znaczenia. Istnieje wiele firm, które korzystają z jednego małego serwera. I pozwala im rozwiązywać swoje problemy. A jeszcze więcej firm korzysta z dużych klastrów wielu serwerów lub kilkudziesięciu serwerów.

A jeśli spojrzeć na zapisy, to:

• Yandex: ponad 500 serwerów, przechowują tam 25 miliardów rekordów dziennie.
• LifeStreet: 60 serwerów, około 75 miliardów rekordów dziennie. Jest mniej serwerów, więcej rekordów niż w Yandex.
• CloudFlare: 36 serwerów, oszczędzają 200 miliardów rekordów dziennie. Mają jeszcze mniej serwerów i przechowują jeszcze więcej danych.
• Bloomberg: 102 serwery, około biliona wpisów dziennie. Rekordzista.

Geograficznie to też dużo. Ta mapa pokazuje mapę cieplną miejsc, w których ClickHouse jest używany na świecie. Rosja, Chiny, Ameryka wyraźnie się tutaj wyróżniają. Niewiele jest krajów europejskich. I są 4 klastry.

To jest analiza porównawcza, nie ma potrzeby szukać liczb bezwzględnych. Jest to analiza odwiedzających, którzy czytają anglojęzyczne materiały na stronie Altinity, ponieważ nie ma tam rosyjskojęzycznych. A Rosja, Ukraina, Białoruś, czyli rosyjskojęzyczna część społeczności, to najliczniejsi użytkownicy. Potem są Stany Zjednoczone i Kanada. Chiny bardzo nadrabiają zaległości. Sześć miesięcy temu prawie nie było tam Chin, teraz Chiny już wyprzedziły Europę i nadal rosną. Stara Europa również nie pozostaje daleko w tyle, a liderem w wykorzystaniu ClickHouse jest, o dziwo, Francja.

Dlaczego to wszystko opowiadam? Pokazać, że ClickHouse staje się standardowym rozwiązaniem do analizy big data i jest już używany w wielu miejscach. Jeśli go używasz, jesteś we właściwym trendzie. Jeśli jeszcze z tego nie korzystasz, to nie możesz się obawiać, że zostaniesz sam i nikt Ci nie pomoże, bo wielu już to robi.

To przykłady realnego wykorzystania ClickHouse w kilku firmach.

• Pierwszy przykład to sieć reklamowa: migracja z Vertica do ClickHouse. Znam też kilka firm, które przeniosły się z Vertica lub są w trakcie przechodzenia.
• Drugim przykładem jest transakcyjny storage na ClickHouse. To jest przykład zbudowany na antywzorcach. Wszystko, czego nie powinno się robić w ClickHouse za radą programistów, odbywa się tutaj. I jest to zrobione tak skutecznie, że działa. I działa znacznie lepiej niż typowe rozwiązanie transakcyjne.
• Trzecim przykładem jest przetwarzanie rozproszone w ClickHouse. Pojawiło się pytanie, w jaki sposób ClickHouse można zintegrować z ekosystemem Hadoop. Pokażę przykład jak firma zrobiła coś na wzór mapy redukuj kontener na ClickHouse, śledząc lokalizację danych itp., aby obliczyć bardzo nietrywialne zadanie.

• LifeStreet to firma zajmująca się technologią reklamową, która dysponuje wszystkimi technologiami związanymi z siecią reklamową.
• Zajmuje się optymalizacją reklam, programmatic bidding.
• Mnóstwo danych: około 10 miliardów zdarzeń dziennie. Jednocześnie wydarzenia można podzielić na kilka pod-wydarzeń.
• Klientów tych danych jest wielu i nie są to tylko ludzie, dużo więcej – to różne algorytmy, które zajmują się programmatic bidding.

Firma przeszła długą i ciernistą drogę. Mówiłem o tym w HighLoad. Najpierw LifeStreet przeniósł się z MySQL (z krótkim postojem w Oracle) do Vertica. I możesz znaleźć historię na ten temat.

I wszystko było bardzo dobrze, ale szybko stało się jasne, że danych przybywa, a Vertica jest droga. Dlatego szukano różnych alternatyw. Niektóre z nich są tutaj wymienione. W rzeczywistości przeprowadziliśmy weryfikację koncepcji lub czasami testy wydajności prawie wszystkich baz danych, które były dostępne na rynku od 13 do 16 roku i były w przybliżeniu odpowiednie pod względem funkcjonalności. Mówiłem też o niektórych z nich na HighLoad.

Zadaniem była przede wszystkim migracja z Vertica, ponieważ dane rosły. I przez lata rosły wykładniczo. Potem poszły na półkę, ale jednak. A przewidując ten wzrost, wymagania biznesowe dotyczące ilości danych, na których trzeba było przeprowadzić jakąś analizę, było jasne, że wkrótce będzie mowa o petabajtach. A płacenie za petabajty jest już bardzo drogie, więc szukaliśmy alternatywy, gdzie się udać.

Gdzie iść? I przez długi czas wcale nie było wiadomo, dokąd się udać, bo z jednej strony są komercyjne bazy danych, które wydają się działać dobrze. Niektóre działają prawie tak dobrze jak Vertica, niektóre gorzej. Ale wszystkie są drogie, nic tańszego i lepszego nie można było znaleźć.

Z drugiej strony istnieją rozwiązania open source, których nie ma zbyt wiele, czyli w przypadku analityki można je policzyć na palcach. I są bezpłatne lub tanie, ale powolne. I często brakuje im niezbędnej i przydatnej funkcjonalności.

I nie było nic, co łączyłoby dobro, które jest w komercyjnych bazach danych i wszystko, co jest darmowe, co jest w open source.

Nie było nic, dopóki niespodziewanie Yandex wyciągnął ClickHouse, jak magik z kapelusza, jak królik. I to była nieoczekiwana decyzja, wciąż zadają pytanie: „Dlaczego?”, Ale mimo to.

I od razu, latem 2016 roku, zaczęliśmy się przyglądać, czym jest ClickHouse. I okazało się, że czasami potrafi być szybszy niż Vertica. Testowaliśmy różne scenariusze na różnych zapytaniach. A jeśli zapytanie korzystało tylko z jednej tabeli, czyli bez żadnych łączeń (join), to ClickHouse był dwa razy szybszy niż Vertica.

Nie byłem zbyt leniwy i pewnego dnia spojrzałem na testy Yandex. Tam jest tak samo: ClickHouse jest dwa razy szybszy od Vertica, więc często o tym mówią.

Ale jeśli w zapytaniach są sprzężenia, wszystko okazuje się niezbyt jednoznaczne. A ClickHouse może być dwa razy wolniejszy niż Vertica. A jeśli nieznacznie poprawisz prośbę i przepiszesz ją, to są one w przybliżeniu równe. Nie jest zły. I wolne.

Po otrzymaniu wyników testów i spojrzeniu na to z różnych punktów widzenia, LifeStreet udał się do ClickHouse.

To już szesnasty rok, przypominam. To było jak żart o myszach, które płakały i kłuły się, ale nadal zjadały kaktusa. Zostało to szczegółowo opisane, jest o tym wideo itp.

Dlatego nie będę o tym szczegółowo mówić, opowiem tylko o wynikach i kilku ciekawych rzeczach, o których wtedy nie mówiłem.

Wyniki są następujące:

• Pomyślna migracja i ponad rok system działa już w produkcji.
• Wzrosła produktywność i elastyczność. Z 10 miliardów rekordów, które mogliśmy sobie pozwolić na przechowywanie dziennie i przez krótki czas, LifeStreet przechowuje obecnie 75 miliardów rekordów dziennie i może to robić przez 3 miesiące lub dłużej. Jeśli liczyć w szczycie, jest to do miliona zdarzeń na sekundę. Do tego systemu dociera dziennie ponad milion zapytań SQL, głównie z różnych robotów.
• Pomimo tego, że dla ClickHouse użyto więcej serwerów niż dla Vertica, oszczędzono również na sprzęcie, ponieważ w Vertica zastosowano dość drogie dyski SAS. ClickHouse używał SATA. I dlaczego? Bo w Vertica insert jest synchroniczny. A synchronizacja wymaga, aby dyski nie spowalniały zbytnio, a także, aby sieć nie spowalniała zbytnio, czyli dość kosztowna operacja. A w ClickHouse insert jest asynchroniczny. Co więcej, zawsze możesz zapisać wszystko lokalnie, nie ma za to żadnych dodatkowych kosztów, więc dane można wstawiać do ClickHouse znacznie szybciej niż do Vertiki, nawet na wolniejszych dyskach. A czytanie to prawie to samo. Czytanie na SATA, jeśli są w RAID, to wszystko jest wystarczająco szybkie.
• Brak ograniczeń licencyjnych, czyli 3 petabajty danych na 60 serwerach (20 serwerów to jedna replika) i 6 bilionów rekordów w faktach i agregacjach. Na coś takiego nie można było sobie pozwolić w Vertica.

W tym przykładzie przejdę teraz do rzeczy praktycznych.

• Pierwszy to skuteczny schemat. Dużo zależy od schematu.
• Drugi to wydajne generowanie SQL.

Typowe zapytanie OLAP to selekcja. Niektóre kolumny przechodzą do grupowania według, inne do funkcji agregujących. Jest gdzie, co można przedstawić jako kawałek sześcianu. Cała grupa może być traktowana jako projekcja. I dlatego nazywa się to wielowymiarową analizą danych.

I często jest to modelowane w formie schematu gwiazdy, gdy istnieje centralny fakt i cechy tego faktu wzdłuż boków, wzdłuż promieni.

A jeśli chodzi o projekt fizyczny, jak to pasuje do stołu, zwykle robią znormalizowaną reprezentację. Możesz zdenormalizować, ale jest to drogie na dysku i niezbyt wydajne w przypadku zapytań. Dlatego zwykle tworzą znormalizowaną reprezentację, czyli tabelę faktów i wiele, wiele tabel wymiarów.

Ale nie działa dobrze w ClickHouse. Istnieją dwa powody:

• Po pierwsze dlatego, że ClickHouse ma niezbyt dobre łączenia, tzn. są łączenia, ale są złe. Podczas gdy źle.
• Po drugie, tabele nie są aktualizowane. Zwykle w tych płytach, które są wokół obwodu gwiazdy, coś trzeba zmienić. Na przykład imię i nazwisko klienta, nazwa firmy itp. I to nie działa.

A wyjście z tego jest w ClickHouse. nawet dwa:

• Pierwszym z nich jest korzystanie ze słowników. Zewnętrzne słowniki pomagają w 99% rozwiązać problem ze schematem gwiazdy, aktualizacjami i tak dalej.
• Drugi to użycie tablic. Tablice pomagają również pozbyć się złączeń i problemów z normalizacją.

• Nie trzeba dołączać.
• Możliwość rozbudowy. Od marca 2018 pojawiła się nieudokumentowana możliwość (w dokumentacji tego nie znajdziecie) częściowej aktualizacji słowników, czyli tych wpisów, które uległy zmianie. W praktyce przypomina stół.
• Zawsze w pamięci, więc połączenia ze słownikiem działają szybciej, niż gdyby to była tabela, która jest na dysku i nie jest jeszcze faktem, że jest w pamięci podręcznej, najprawdopodobniej nie.

• Nie potrzebujesz też złączeń.
• Jest to zwarta reprezentacja 1-do-wielu.
• A moim zdaniem tablice są dla maniaków. Są to funkcje lambda i tak dalej.

To nie jest dla czerwonych słów. Jest to bardzo potężna funkcjonalność, która pozwala robić wiele rzeczy w bardzo prosty i elegancki sposób.

Typowe przykłady pomagające rozwiązywać tablice. Te przykłady są proste i wystarczająco jasne:

• Wyszukiwanie po tagach. Jeśli masz tam hashtagi i chcesz znaleźć posty według hashtagu.
• Szukaj według par klucz-wartość. Istnieją również atrybuty z wartością.
• Przechowywanie list kluczy, które trzeba przetłumaczyć na coś innego.

Wszystkie te zadania można rozwiązać bez tablic. Tagi można umieścić w jakiejś linii i wybrać za pomocą wyrażenia regularnego lub w osobnej tabeli, ale wtedy trzeba zrobić łączenia.

A w ClickHouse nie trzeba nic robić, wystarczy opisać tablicę ciągów dla hashtagów lub zrobić zagnieżdżoną strukturę dla układów klucz-wartość.

Zagnieżdżona struktura może nie być najlepszą nazwą. Są to dwie tablice, które mają część wspólną w nazwie i pewne powiązane cechy.

Wyszukiwanie według tagów jest bardzo łatwe. Mieć funkcję has, który sprawdza, czy tablica zawiera element. Wszyscy, znaleźliśmy wszystkie wpisy, które dotyczą naszej konferencji.

Wyszukiwanie według subid jest nieco bardziej skomplikowane. Musimy najpierw znaleźć indeks klucza, a następnie wziąć element z tym indeksem i sprawdzić, czy ta wartość jest tym, czego potrzebujemy. Jest jednak bardzo prosty i kompaktowy.

Wyrażenie regularne, które chciałbyś napisać, gdybyś trzymał je w jednym wierszu, byłoby po pierwsze niezgrabne. Po drugie, działał znacznie dłużej niż dwie tablice.

Inny przykład. Masz tablicę, w której przechowujesz identyfikator. I możesz przetłumaczyć je na nazwy. Funkcjonować arrayMap. Jest to typowa funkcja lambda. Przekazujesz tam wyrażenia lambda. I wyciąga ze słownika wartość nazwy dla każdego identyfikatora.

Wyszukiwanie można przeprowadzić w ten sam sposób. Przekazywana jest funkcja predykatu, która sprawdza dopasowanie elementów.

Te rzeczy znacznie upraszczają obwód i rozwiązują wiele problemów.

Ale kolejnym problemem, przed którym stoimy i o którym chciałbym wspomnieć, są wydajne zapytania.

• ClickHouse nie ma narzędzia do planowania zapytań. Absolutnie nie.
• Niemniej jednak złożone zapytania nadal wymagają planowania. w jakich przypadkach?
• Jeśli w zapytaniu występuje wiele sprzężeń, umieszczasz je w podselekcjach. A kolejność ich wykonania ma znaczenie.
• A drugi - jeśli prośba zostanie rozesłana. Ponieważ w zapytaniu rozproszonym wykonywana jest tylko najbardziej wewnętrzna selekcja podrzędna, a cała reszta jest przekazywana do jednego serwera, z którym się łączysz i który tam jest wykonywany. Dlatego jeśli masz rozproszone zapytania z wieloma sprzężeniami (join), musisz wybrać kolejność.

A nawet w prostszych przypadkach czasami konieczne jest również wykonanie pracy harmonogramu i trochę przepisanie zapytań.

Oto przykład. Po lewej stronie znajduje się zapytanie, które pokazuje 5 najlepszych krajów. I moim zdaniem zajmuje to 2,5 sekundy. A po prawej to samo zapytanie, ale trochę przepisane. Zamiast grupować według łańcucha, zaczęliśmy grupować według klucza (int). I to szybciej. A następnie podłączyliśmy słownik do wyniku. Zamiast 2,5 sekundy żądanie zajmuje 1,5 sekundy. To jest dobre.

Podobny przykład z przepisywaniem filtrów. Oto prośba do Rosji. Działa przez 5 sekund. Jeśli przepiszemy to w taki sposób, że ponownie porównamy nie ciąg, ale liczby z jakimś zestawem tych kluczy, które odnoszą się do Rosji, to będzie znacznie szybciej.

Takich sztuczek jest wiele. Pozwalają też znacznie przyspieszyć zapytania, które Twoim zdaniem już działają szybko lub odwrotnie. Można je zrobić jeszcze szybciej.

• Maksymalna praca w trybie rozproszonym.
• Sortowanie według typów minimalnych, tak jak zrobiłem to według ints.
• Jeśli są jakieś łączenia (join), słowniki to lepiej zrobić je w ostateczności, gdy masz już dane przynajmniej częściowo pogrupowane wtedy operacja łączenia lub wywołanie słownika będzie wywoływana mniej razy i będzie szybsza .
• Wymiana filtrów.

Istnieją inne techniki, i to nie tylko te, które zademonstrowałem. A wszystkie z nich mogą czasem znacznie przyspieszyć wykonywanie zapytań.

Przejdźmy do następnego przykładu. Firma X z USA. Co ona robi?

Było zadanie:

• Łączenie offline transakcji reklamowych.
• Modelowanie różnych modeli wiązań.

Jaki jest scenariusz?

Zwykły użytkownik wchodzi na stronę np. 20 razy w miesiącu z różnych reklam, albo tak po prostu czasem przychodzi bez reklam, bo pamięta tę stronę. Ogląda niektóre produkty, wkłada je do koszyka, wyciąga z koszyka. I w końcu coś się kupuje.

Rozsądne pytania: „Kto powinien płacić za reklamę, jeśli to konieczne?” oraz „Jaka reklama miała na niego wpływ, jeśli w ogóle?”. To znaczy, dlaczego kupił i jak sprawić, by ludzie tacy jak ta osoba też kupili?

Aby rozwiązać ten problem, trzeba w odpowiedni sposób powiązać zdarzenia zachodzące na stronie, czyli jakoś zbudować między nimi powiązanie. Następnie przesyłane są do analizy do DWH. Na podstawie tej analizy stwórz modele pokazujące, komu i jakie reklamy wyświetlać.

Transakcja reklamowa to zestaw powiązanych zdarzeń użytkownika, które zaczynają się od wyświetlenia reklamy, potem coś się dzieje, potem może zakup, a potem mogą być zakupy w ramach zakupu. Na przykład, jeśli jest to aplikacja mobilna lub gra mobilna, to zwykle instalacja aplikacji odbywa się za darmo, a jeśli coś tam zostanie zrobione, mogą być na to potrzebne pieniądze. A im więcej dana osoba wydaje w aplikacji, tym jest ona cenniejsza. Ale w tym celu musisz wszystko połączyć.

Istnieje wiele wiążących modeli.

Najpopularniejsze to:

• Ostatnia interakcja, gdzie interakcja polega na kliknięciu lub wyświetleniu.
• Pierwsza interakcja, czyli pierwsza rzecz, która sprowadziła osobę na stronę.
• Kombinacja liniowa - wszystkie po równo.
• Osłabienie.
• I tak dalej.

I jak to wszystko działało na początku? Był Runtime i Cassandra. Cassandra służyła jako magazyn transakcji, czyli wszystkie powiązane transakcje były w niej przechowywane. A kiedy w Runtime pojawia się jakieś zdarzenie, na przykład pokazanie jakiejś strony lub czegoś innego, wówczas do Cassandry wysłano prośbę - czy jest taka osoba, czy nie. Następnie uzyskano transakcje, które go dotyczą. I połączenie zostało wykonane.

A jeśli to szczęście, że żądanie ma identyfikator transakcji, to jest to łatwe. Ale zwykle nie ma szczęścia. Dlatego konieczne było znalezienie ostatniej transakcji lub transakcji z ostatnim kliknięciem itp.

I wszystko działało bardzo dobrze, dopóki wiązanie było do ostatniego kliknięcia. Ponieważ jest, powiedzmy, 10 milionów kliknięć dziennie, 300 milionów miesięcznie, jeśli ustawimy okno na miesiąc. A ponieważ w Cassandrze wszystko musi być w pamięci, aby działać szybko, ponieważ Runtime musi szybko reagować, zajęło to około 10-15 serwerów.

A kiedy chcieli powiązać transakcję z wyświetlaczem, od razu okazało się, że nie jest to takie zabawne. I dlaczego? Można zauważyć, że trzeba zapisać 30 razy więcej zdarzeń. W związku z tym potrzebujesz 30 razy więcej serwerów. I okazuje się, że jest to jakaś postać astronomiczna. Utrzymywanie do 500 serwerów w celu łączenia, pomimo faktu, że w Runtime jest znacznie mniej serwerów, jest to jakaś błędna liczba. I zaczęli myśleć, co robić.

I poszliśmy do ClickHouse. A jak to zrobić na ClickHouse? Na pierwszy rzut oka wydaje się, że jest to zestaw antywzorców.

• Transakcja rośnie, podpinamy do niej coraz więcej zdarzeń, czyli jest zmienna, a ClickHouse nie radzi sobie zbyt dobrze ze zmiennymi obiektami.
• Kiedy przychodzi do nas gość, musimy wyciągnąć jego transakcje według klucza, według jego identyfikatora wizyty. Jest to również zapytanie punktowe, nie robią tego w ClickHouse. Zwykle ClickHouse ma duże…skany, ale tutaj musimy zdobyć trochę rekordów. Również antywzorzec.
• Dodatkowo transakcja była w jsonie, ale nie chcieli jej przepisywać, więc chcieli przechowywać jsona w nieustrukturyzowany sposób i w razie potrzeby coś z tego wyciągnąć. I to też jest antywzorzec.

Czyli zbiór antywzorców.

Niemniej jednak okazało się, że stworzył system, który działał bardzo dobrze.

Co było zrobione? Pojawił się ClickHouse, do którego wrzucano logi podzielone na rekordy. Pojawiła się przypisana usługa, która otrzymała logi z ClickHouse. Następnie dla każdego wpisu, po identyfikatorze wizyty, otrzymywałem transakcje, które być może nie zostały jeszcze przetworzone oraz plus snapshoty, czyli transakcje już połączone, czyli efekt poprzedniej pracy. Ułożyłem już z nich logikę, wybrałem właściwą transakcję, połączyłem nowe zdarzenia. Zalogowano ponownie. Log wrócił do ClickHouse, czyli jest to system stale cykliczny. A poza tym poszedłem do DWH, żeby tam to przeanalizować.

W tej formie nie funkcjonowało to zbyt dobrze. Aby ułatwić ClickHouse, gdy pojawiła się prośba według identyfikatora wizyty, pogrupowali te żądania w bloki po 1-000 identyfikatorów wizyt i wyciągnęli wszystkie transakcje dla 2-000 osób. A potem wszystko zadziałało.

Jeśli zajrzysz do ClickHouse, zobaczysz tylko 3 główne stoły, które to wszystko obsługują.

Pierwsza tabela, do której przesyłane są logi, a logi są przesyłane prawie bez przetwarzania.

Drugi stół. Poprzez zmaterializowany widok zdarzenia, które nie zostały jeszcze przypisane, tj. niepowiązane, zostały wygryzione z tych dzienników. Dzięki zmaterializowanemu widokowi transakcje zostały wyciągnięte z tych dzienników, aby utworzyć migawkę. Oznacza to, że specjalny zmaterializowany widok zbudował migawkę, czyli ostatni skumulowany stan transakcji.

Oto tekst napisany w języku SQL. Chciałbym w nim skomentować kilka ważnych rzeczy.

Pierwszą ważną rzeczą jest możliwość wyciągania kolumn i pól z jsona w ClickHouse. Oznacza to, że ClickHouse ma kilka metod pracy z jsonem. Są bardzo, bardzo prymitywne.

visitParamExtractInt pozwala na wydobycie atrybutów z json, czyli pierwsze trafienie działa. W ten sposób możesz wyciągnąć identyfikator transakcji lub identyfikator wizyty. Tym razem.

Po drugie, zastosowano tu trudne zmaterializowane pole. Co to znaczy? Oznacza to, że nie można go wstawić do tabeli, tzn. nie jest wstawiany, jest obliczany i zapisywany po wstawieniu. Podczas wklejania ClickHouse wykonuje pracę za Ciebie. A to, czego potrzebujesz później, jest już wyciągnięte z json.

W tym przypadku widok zmaterializowany dotyczy nieprzetworzonych wierszy. A pierwsza tabela z praktycznie surowymi logami jest właśnie używana. A co on robi? Po pierwsze zmienia to sortowanie, tzn. sortowanie odbywa się teraz po identyfikatorze wizyty, ponieważ musimy szybko wyciągnąć jego transakcję dla konkretnej osoby.

Drugą ważną rzeczą jest index_granularity. Jeśli widziałeś MergeTree, domyślnie jest to zwykle 8 index_granularity. Co to jest? Jest to parametr rzadkości indeksu. W ClickHouse indeks jest rzadki, nigdy nie indeksuje każdego wpisu. Robi to co 192. Jest to dobre, gdy do obliczenia jest wymagane dużo danych, ale złe, gdy jest ich mało, ponieważ wiąże się to z dużym narzutem. A jeśli zmniejszymy ziarnistość indeksu, zmniejszymy koszty ogólne. Nie można go zredukować do jednego, ponieważ może być za mało pamięci. Indeks jest zawsze przechowywany w pamięci.

Snapshot wykorzystuje również kilka innych interesujących funkcji ClickHouse.

Po pierwsze, jest to AggregatingMergeTree. A AggregatingMergeTree przechowuje argMax, czyli jest to stan transakcji odpowiadający ostatniemu znacznikowi czasu. Transakcje generowane są cały czas dla danego odwiedzającego. A w ostatnim stanie tej transakcji dodaliśmy zdarzenie i mamy nowy stan. Ponownie uderzył w ClickHouse. A poprzez argMax w tym zmaterializowanym widoku zawsze możemy uzyskać aktualny stan.

• Wiązanie jest „oddzielone” od środowiska wykonawczego.
• Miesięcznie przechowywanych i przetwarzanych jest do 3 miliardów transakcji. To o rząd wielkości więcej niż było w Cassandrze, czyli w typowym systemie transakcyjnym.
• Klaster serwerów ClickHouse 2x5. 5 serwerów i każdy serwer ma replikę. To nawet mniej niż w przypadku Cassandry w przypadku atrybucji opartej na kliknięciach, a tutaj mamy opartą na wyświetleniach. Oznacza to, że zamiast zwiększyć liczbę serwerów 30-krotnie, udało im się je zmniejszyć.

A ostatnim przykładem jest firma finansowa Y, która analizowała korelacje zmian cen akcji.

A zadaniem było:

• Istnieje około 5 akcji.
• Znane są notowania co 100 milisekund.
• Dane były gromadzone przez 10 lat. Podobno dla jednych firm więcej, dla innych mniej.
• W sumie jest około 100 miliardów wierszy.

I trzeba było obliczyć korelację zmian.

Oto dwie akcje i ich notowania. Jeśli jeden idzie w górę, a drugi w górę, to jest to dodatnia korelacja, tj. jeden idzie w górę, a drugi w górę. Jeśli jeden idzie w górę, jak na końcu wykresu, a drugi spada, to jest to korelacja ujemna, tj. gdy jeden rośnie, drugi spada.

Analizując te wzajemne zmiany, można dokonywać prognoz na rynku finansowym.

Ale zadanie jest trudne. Co się w tym celu robi? Mamy 100 miliardów rekordów, które mają: czas, stan magazynowy i cenę. Musimy obliczyć najpierw 100 miliardów razy bieżącą różnicę z algorytmu cenowego. RunningDifference to funkcja w ClickHouse, która sekwencyjnie oblicza różnicę między dwoma łańcuchami.

Następnie musisz obliczyć korelację, a korelację należy obliczyć dla każdej pary. Za 5 akcji pary to 000 miliona. A to dużo, tj. 12,5 razy trzeba obliczyć właśnie taką funkcję korelacji.

A jakby ktoś zapomniał, to ͞x i ͞y to mat. oczekiwanie na pobieranie próbek. Oznacza to, że konieczne jest nie tylko obliczenie pierwiastków i sum, ale także jeszcze jedna suma wewnątrz tych sum. Kilka obliczeń trzeba wykonać 12,5 miliona razy, a nawet pogrupować według godzin. Mamy też dużo godzin. I musisz to zrobić w 60 sekund. To żart.

Trzeba było jakoś mieć czas, bo to wszystko działało bardzo, bardzo wolno, zanim przyszedł ClickHouse.

Próbowali to obliczyć na Hadoop, na Spark, na Greenplum. A wszystko to było bardzo powolne lub drogie. Oznacza to, że można było jakoś obliczyć, ale wtedy było drogo.

A potem pojawił się ClickHouse i sprawy potoczyły się znacznie lepiej.

Przypominam, że mamy problem z lokalnością danych, bo korelacji nie da się zlokalizować. Nie możemy umieścić niektórych danych na jednym serwerze, niektórych na innym i kalkulować, musimy mieć wszystkie dane wszędzie.

Co oni zrobili? Początkowo dane są zlokalizowane. Każdy serwer przechowuje dane dotyczące wyceny określonego zestawu akcji. I nie nakładają się. Dlatego możliwe jest obliczanie logReturn równolegle i niezależnie, wszystko to dzieje się do tej pory równolegle i rozproszone.

Następnie postanowiliśmy zredukować te dane, nie tracąc przy tym wyrazistości. Zredukuj za pomocą tablic, tj. dla każdego okresu utwórz tablicę zapasów i tablicę cen. Dlatego zajmuje znacznie mniej miejsca na dane. I trochę łatwiej się z nimi pracuje. Są to operacje prawie równoległe, tzn. częściowo równolegle czytamy, a następnie zapisujemy na serwer.

Po tym można go powielić. Litera „r” oznacza, że ​​zreplikowaliśmy te dane. Oznacza to, że mamy te same dane na wszystkich trzech serwerach - są to tablice.

Następnie za pomocą specjalnego skryptu z tego zestawu 12,5 miliona korelacji, które należy obliczyć, można tworzyć pakiety. To znaczy 2 zadań z 500 par korelacji. A to zadanie ma być rozliczone na konkretnym serwerze ClickHouse. Ma wszystkie dane, ponieważ dane są takie same i może je obliczyć sekwencyjnie.

Po raz kolejny tak to wygląda. Po pierwsze mamy wszystkie dane w tej strukturze: czas, akcje, cenę. Następnie obliczyliśmy logReturn, czyli dane o tej samej strukturze, ale zamiast ceny mamy już logReturn. Potem zostały przerobione, czyli mamy czas i groupArray na akcje i ceny. Replikowane. Następnie wygenerowaliśmy kilka zadań i wrzuciliśmy je do ClickHouse, aby je policzył. I to działa.

W ramach weryfikacji koncepcji zadanie było podzadaniem, tj. Pobrano mniej danych. I tylko trzy serwery.

Pierwsze dwa etapy: obliczenie Log_return i zawijanie w tablice zajęły około godziny.

A obliczenie korelacji to około 50 godzin. Ale 50 godzin to za mało, bo kiedyś pracowali tygodniami. To był duży sukces. A jeśli policzysz, to 70 razy na sekundę wszystko zostało policzone na tym klastrze.

Ale najważniejsze jest to, że ten system praktycznie nie ma wąskich gardeł, czyli skaluje się prawie liniowo. I sprawdzili to. Udało się zwiększyć skalę.

• Właściwy schemat to połowa sukcesu. A właściwym schematem jest wykorzystanie wszystkich niezbędnych technologii ClickHouse.
• Summing/AggregatingMergeTrees to technologie, które umożliwiają agregację lub traktowanie migawki stanu jako szczególnego przypadku. I znacznie upraszcza wiele rzeczy.
• Widoki zmaterializowane pozwalają ominąć limit jednego indeksu. Może nie wyraziłem się zbyt jasno, ale gdy ładowaliśmy logi, to surowe logi były w tabeli z jednym indeksem, a logi atrybutów były w tabeli, czyli te same dane, tylko przefiltrowane, ale indeks był całkowicie inni. Wydaje się, że są to te same dane, ale inne sortowanie. Zmaterializowane widoki pozwalają, jeśli tego potrzebujesz, ominąć takie ograniczenie ClickHouse.
• Zmniejsz ziarnistość indeksu dla zapytań punktowych.
• I inteligentnie dystrybuuj dane, staraj się w jak największym stopniu zlokalizować dane na serwerze. Postaraj się również, aby żądania w miarę możliwości korzystały również z lokalizacji.

I podsumowując to krótkie wystąpienie, możemy powiedzieć, że ClickHouse obecnie mocno zajęło terytorium zarówno komercyjnych baz danych, jak i baz open source, czyli specjalnie dla analityki. Idealnie wpasowuje się w ten krajobraz. Co więcej, powoli zaczyna wypierać innych, bo mając ClickHouse nie potrzebujesz InfiniDB. Vertika może wkrótce nie być potrzebna, jeśli zapewnią normalne wsparcie SQL. Cieszyć się!

-Dzięki za raport! Bardzo interesujące! Czy były jakieś porównania z Apache Phoenix?

Nie, nie słyszałem, żeby ktoś porównywał. My i Yandex staramy się śledzić wszystkie porównania ClickHouse z różnymi bazami danych. Bo jeśli nagle okaże się, że coś jest szybsze niż ClickHouse, to Lesha Milovidov nie może spać po nocach i szybko zaczyna to przyspieszać. Nie słyszałem o takim porównaniu.

• (Aleksey Milovidov) Apache Phoenix to silnik SQL oparty na Hbase. Hbase jest przeznaczony głównie do scenariuszy pracy typu klucz-wartość. Tam w każdym wierszu może znajdować się dowolna liczba kolumn o dowolnych nazwach. Można to powiedzieć o takich systemach jak Hbase, Cassandra. I to właśnie ciężkie zapytania analityczne nie będą dla nich działać normalnie. Możesz też pomyśleć, że działają dobrze, jeśli nie miałeś żadnego doświadczenia z ClickHouse.

• Dzięki

  • Dzień dobry Jestem już dość zainteresowany tym tematem, ponieważ mam podsystem analityczny. Ale kiedy patrzę na ClickHouse, mam wrażenie, że ClickHouse bardzo dobrze nadaje się do analizy zdarzeń, mutable. A jeśli muszę analizować wiele danych biznesowych za pomocą wielu dużych tabel, to ClickHouse, o ile rozumiem, nie jest dla mnie odpowiedni? Zwłaszcza jeśli się zmienią. Czy to prawda, czy też istnieją przykłady, które mogą to obalić?

  • To prawda. Dotyczy to większości wyspecjalizowanych analitycznych baz danych. Są one dostosowane do faktu, że istnieje jedna lub więcej dużych tabel, które można modyfikować, oraz wiele małych, które zmieniają się powoli. Oznacza to, że ClickHouse nie jest jak Oracle, w którym można umieścić wszystko i zbudować bardzo złożone zapytania. Aby skutecznie korzystać z ClickHouse, musisz zbudować schemat w sposób, który dobrze działa w ClickHouse. To znaczy unikaj nadmiernej normalizacji, używaj słowników, staraj się tworzyć mniej długich linków. A jeśli schemat jest zbudowany w ten sposób, to podobne zadania biznesowe można rozwiązywać na ClickHouse znacznie wydajniej niż na tradycyjnej relacyjnej bazie danych.

Dzięki za raport! Mam pytanie dotyczące ostatniej sprawy finansowej. Mieli analitykę. Trzeba było porównać, jak idą w górę iw dół. Rozumiem, że zbudowałeś system specjalnie do tej analizy? Jeśli na przykład jutro będą potrzebować innego raportu na temat tych danych, czy muszą przebudować schemat i przesłać dane? To znaczy, aby wykonać jakieś wstępne przetwarzanie, aby uzyskać żądanie?

Oczywiście jest to użycie ClickHouse do bardzo konkretnego zadania. Można to bardziej tradycyjnie rozwiązać w Hadoop. Dla Hadoop jest to idealne zadanie. Ale na Hadoop jest bardzo wolny. A moim celem jest pokazanie, że ClickHouse potrafi rozwiązywać zadania, które zwykle rozwiązuje się zupełnie innymi sposobami, ale jednocześnie robić to znacznie wydajniej. Jest dostosowany do konkretnego zadania. Oczywiste jest, że jeśli istnieje problem z czymś podobnym, można go rozwiązać w podobny sposób.

Jest jasne. Powiedziałeś, że przetworzono 50 godzin. Czy od samego początku, kiedy wczytałeś dane lub otrzymałeś wyniki?

Tak tak.

Ok, bardzo dziękuję.

To jest w klastrze z 3 serwerami.

Pozdrowienia! Dzięki za raport! Wszystko jest bardzo interesujące. Nie zapytam trochę o funkcjonalność, ale o wykorzystanie ClickHouse pod kątem stabilności. To znaczy, czy miałeś jakieś, czy musiałeś przywrócić? Jak w tym przypadku zachowuje się ClickHouse? A czy zdarzyło się, że mieliście też replikę? Na przykład napotkaliśmy problem z ClickHouse, gdy wciąż przekraczał swój limit i spadał.

Oczywiście nie ma systemów idealnych. A ClickHouse ma też swoje własne problemy. Ale czy słyszałeś o tym, że Yandex.Metrica nie działa od dłuższego czasu? Prawdopodobnie nie. Działa niezawodnie od 2012-2013 na ClickHouse. To samo mogę powiedzieć o swoim doświadczeniu. Nigdy nie mieliśmy kompletnych porażek. Niektóre częściowe rzeczy mogły się wydarzyć, ale nigdy nie były na tyle krytyczne, aby poważnie wpłynąć na działalność firmy. To nigdy się nie stało. ClickHouse jest dość niezawodny i nie ulega przypadkowym awariom. Nie musisz się tym martwić. To nie jest surowa rzecz. Zostało to udowodnione przez wiele firm.

Cześć! Powiedziałeś, że musisz od razu przemyśleć schemat danych. A co jeśli to się stało? Moje dane leją się i leją. Mija sześć miesięcy i rozumiem, że nie da się tak żyć, muszę ponownie przesłać dane i coś z nimi zrobić.

Zależy to oczywiście od twojego systemu. Można to zrobić na kilka sposobów, praktycznie bez przerwy. Na przykład możesz utworzyć widok zmaterializowany, w którym można utworzyć inną strukturę danych, jeśli można ją jednoznacznie odwzorować. To znaczy, jeśli pozwala na mapowanie za pomocą ClickHouse, tj. Wyodrębnij niektóre rzeczy, zmień klucz podstawowy, zmień partycjonowanie, to możesz zrobić widok zmaterializowany. Zastąp tam swoje stare dane, nowe zostaną zapisane automatycznie. A potem po prostu przełącz się na korzystanie z widoku zmaterializowanego, a następnie przełącz rekord i zabij starą tabelę. Jest to na ogół metoda non-stop.

Dziękuję.

Źródło: www.habr.com