Theorie und Praxis der Verwendung von ClickHouse in realen Anwendungen. Alexander Zaitsev (2018)

Trotz der Tatsache, dass es jetzt fast überall viele Daten gibt, sind analytische Datenbanken immer noch ziemlich exotisch. Sie sind schlecht bekannt und noch schlechter effizient zu nutzen. Viele kämpfen weiterhin mit MySQL oder PostgreSQL, die für andere Szenarien entworfen wurden, quälen sich mit NoSQL oder zahlen zu viel für kommerzielle Lösungen. ClickHouse verändert die Spielregeln und senkt die Einstiegshürde in die Welt der analytischen DBMS erheblich.

Der Bericht von der BackEnd Conf 2018 und er wurde mit Erlaubnis des Referenten veröffentlicht.

Wer bin ich und warum erzähle ich von ClickHouse? Ich bin Direktor für Entwicklung bei LifeStreet, einem Unternehmen, das ClickHouse verwendet. Außerdem bin ich Gründer von Altinity. Das ist ein Partner von Yandex, der ClickHouse fördert und Yandex hilft, ClickHouse erfolgreicher zu machen. Ich bin auch bereit, Wissen über ClickHouse zu teilen.

Und ich bin nicht Petja Zaitsev's Bruder. Oft werde ich danach gefragt. Nein, wir sind keine Brüder.

„Es ist allgemein bekannt“, dass ClickHouse:

• Sehr schnell ist,
• Sehr benutzerfreundlich ist,
• In Yandex verwendet wird.

Es ist weniger bekannt, in welchen Unternehmen und wie es verwendet wird.

Ich werde Ihnen erzählen, wofür, wo und wie ClickHouse verwendet wird, abgesehen von Yandex.

Ich werde erläutern, wie spezifische Aufgaben mit ClickHouse in verschiedenen Unternehmen gelöst werden, welche Möglichkeiten ClickHouse für Ihre Aufgaben bietet und wie sie in verschiedenen Unternehmen eingesetzt wurden.

Ich habe drei Beispiele ausgewählt, die ClickHouse aus verschiedenen Perspektiven zeigen. Ich denke, das wird interessant sein.

Die erste Frage: „Warum ist ClickHouse nötig?“. Es scheint, die Frage sei offensichtlich, aber es gibt mehr als eine Antwort darauf.

• Die erste Antwort – wegen der Leistung. ClickHouse ist sehr schnell. Analysen mit ClickHouse sind ebenfalls sehr schnell. Es kann oft dort verwendet werden, wo etwas anderes sehr langsam oder sehr schlecht funktioniert.
• Die zweite Antwort – es sind die Kosten. Und vor allem die Kosten für die Skalierung. Zum Beispiel ist Vertica eine völlig andere Datenbank. Sie funktioniert sehr gut, wenn Sie nicht sehr viele Terabyte Daten haben. Aber wenn es um Hundert Terabyte oder Petabyte geht, werden die Kosten für Lizenzen und Support ziemlich erheblich. Und das ist teuer. ClickHouse ist hingegen kostenlos.
• Die dritte Antwort sind die Betriebskosten. Dies ist ein Ansatz aus einer etwas anderen Perspektive. RedShift ist ein hervorragendes Pendant. Mit RedShift kann man sehr schnell eine Lösung erstellen. Sie wird gut funktionieren, aber jeden Stunde, jeden Tag und jeden Monat werden Sie ziemlich viel an Amazon zahlen, da es ein deutlich teurerer Service ist. Google BigQuery ebenfalls. Wer es genutzt hat, weiß, dass man dort mehrere Abfragen starten kann und plötzlich eine Rechnung in Höhe von Hunderten Dollar erhält.

In ClickHouse gibt es diese Probleme nicht.

Wo wird ClickHouse derzeit verwendet? Neben Yandex wird ClickHouse in einer Vielzahl von verschiedenen Unternehmen eingesetzt.

• In erster Linie handelt es sich um die Analyse von Webanwendungen, d. h. es ist ein Anwendungsfall, der von Yandex stammt.
• Viele AdTech-Unternehmen nutzen ClickHouse.
• Zahlreiche Unternehmen, die betriebliche Protokolle aus verschiedenen Quellen analysieren müssen.
• Einige Unternehmen verwenden ClickHouse zur Überwachung von Sicherheitsprotokollen. Sie laden diese in ClickHouse hoch, erstellen Berichte und erhalten die benötigten Ergebnisse.
• Unternehmen beginnen, es in der Finanzanalyse zu verwenden, d. h. schrittweise wird auch der große Business-Sektor auf ClickHouse aufmerksam.
• CloudFlare. Wer ClickHouse verfolgt, hat sicherlich den Namen dieses Unternehmens gehört. Es ist einer der bedeutenden Mitwirkenden aus der Community. Und sie haben eine sehr ernsthafte ClickHouse-Installation. Zum Beispiel haben sie einen Kafka Engine für ClickHouse entwickelt.
• Telekommunikationsunternehmen haben begonnen, es zu verwenden. Mehrere Unternehmen nutzen ClickHouse entweder als Proof of Concept oder bereits in der Produktion.
• Ein Unternehmen verwendet ClickHouse zur Überwachung von Produktionsprozessen. Sie testen Chips, erfassen viele Parameter, etwa 2000 Eigenschaften, und analysieren dann – ob es sich um eine gute oder eine schlechte Charge handelt.
• Blockchain-Analyse. Es gibt ein russisches Unternehmen wie Bloxy.info. Das ist die Analyse des Ethereum-Netzes. Auch das haben sie mit ClickHouse umgesetzt.

Und die Größe spielt keine Rolle. Es gibt viele Unternehmen, die einen kleinen Server nutzen. Und dieser ermöglicht es ihnen, ihre Probleme zu lösen. Und noch mehr Unternehmen nutzen große Cluster aus vielen Server oder Dutzenden von Servern.

Und wenn man sich die Rekorde anschaut, dann:

• Yandex: Über 500 Server, 25 Milliarden Einträge pro Tag werden dort gespeichert.
• LifeStreet: 60 Server, etwa 75 Milliarden Einträge pro Tag. Weniger Server, mehr Einträge als bei Yandex.
• CloudFlare: 36 Server, sie speichern 200 Milliarden Einträge pro Tag. Sie haben sogar noch weniger Server und speichern noch mehr Daten.
• Bloomberg: 102 Server, etwa eine Billion Einträge pro Tag. Rekordhalter bei den Einträgen.

Geografisch gesehen ist das auch viel. Diese Karte zeigt die Heatmap, wo ClickHouse weltweit verwendet wird. Hier stechen Russland, China und Amerika hervor. Es gibt nur wenige europäische Länder. Man kann 4 Cluster herausstellen.

Dies ist eine vergleichende Analyse, hier braucht man keine absoluten Zahlen zu suchen. Es handelt sich um die Analyse von Besuchern, die englischsprachige Inhalte auf der Altinity-Website lesen, da es dort keine russischsprachigen Inhalte gibt. Russland, die Ukraine und Weißrussland, d.h. der russischsprachige Teil der Community, sind die zahlreichsten Nutzer. Danach folgen die USA und Kanada. China holt stark auf. Vor einem halben Jahr war China fast nicht vertreten, jetzt hat China bereits Europa überholt und wächst weiter. Auch die alte Dame Europa bleibt nicht zurück, und zwar ist Frankreich, erstaunlicherweise, der führende Nutzer von ClickHouse.

Warum erzähle ich das alles? Um zu zeigen, dass ClickHouse eine Standardlösung für die Analyse großer Datenmengen wird und bereits in vielen Bereichen eingesetzt wird. Wenn Sie es verwenden, sind Sie im richtigen Trend. Wenn Sie es noch nicht verwenden, brauchen Sie keine Angst haben, dass Sie allein dastehen und Ihnen niemand hilft, denn viele sind bereits dabei.

Dies sind Beispiele für die reale Nutzung von ClickHouse in mehreren Unternehmen.

• Das erste Beispiel ist ein Werbenetzwerk: Migration von Vertica zu ClickHouse. Ich kenne mehrere Unternehmen, die von Vertica gewechselt sind oder sich im Prozess des Wechsels befinden.
• Das zweite Beispiel ist ein transaktionales Data Warehouse auf ClickHouse. Dies ist ein Beispiel, das auf Anti-Pattern aufgebaut ist. Alles, was man laut den Entwicklern in ClickHouse nicht tun sollte, ist hier gemacht worden. Und dennoch wurde es so effektiv umgesetzt, dass es funktioniert. Und es funktioniert viel besser als eine typische transaktionale Lösung.
• Das dritte Beispiel sind verteilte Berechnungen auf ClickHouse. Es gab die Frage, wie ClickHouse in das Hadoop-Ökosystem integriert werden kann. Ich werde ein Beispiel zeigen, wie ein Unternehmen mit ClickHouse etwas Ähnliches wie einen Map-Reduce-Container erstellt hat, wobei die Lokalisierung der Daten usw. berücksichtigt wurde, um eine sehr nicht triviale Aufgabe zu berechnen.

• LifeStreet – Das ist ein Ad-Tech-Unternehmen, das alle Technologien hat, die mit einem Werbenetzwerk verbunden sind.
• Es beschäftigt sich mit der Optimierung von Anzeigen und programmatischem Bietverfahren.
• Viele Daten: etwa 10 Milliarden Ereignisse pro Tag. Dabei können Events in mehrere Unterereignisse unterteilt werden.
• Viele Kunden dieser Daten, und das sind nicht nur Menschen, sondern viel mehr – verschiedene Algorithmen, die sich mit programmatic bidding beschäftigen.

Das Unternehmen hat einen langen und steinigen Weg hinter sich. Und ich habe darüber auf HighLoad gesprochen. Zunächst wechselte LifeStreet von MySQL (mit einem kurzen Halt bei Oracle) zu Vertica. Darüber kann man Berichte finden.

Und alles lief sehr gut, aber es wurde ziemlich schnell klar, dass die Daten wachsen und dass Vertica teuer ist. Daher wurden verschiedene Alternativen gesucht. Einige von ihnen sind hier aufgelistet. Tatsächlich haben wir fast alle Datenbanken, die von 2013 bis 2016 auf dem Markt verfügbar waren und in etwa die richtige Funktionalität hatten, in einem Proof of Concept oder manchmal Performance-Tests geprüft. Über einige davon habe ich auch auf HighLoad gesprochen.

Die Aufgabe bestand darin, zuerst von Vertica zu migrieren, weil die Daten wuchsen. Und sie wuchsen über mehrere Jahre exponentiell. Später stagnierte das Wachstum, aber trotzdem. Und mit Blick auf dieses Wachstum war es klar, dass die Anforderungen des Unternehmens bezüglich des Datenvolumens, für das eine Analyse erforderlich war, bald zu Gesprächen über Petabytes führen würden. Und für Petabytes zu zahlen, ist schon sehr teuer, daher suchten wir nach Alternativen, wohin man wechseln könnte.

Wohin wechseln? Lange Zeit war völlig unklar, wohin man wechseln könnte, denn auf der einen Seite gibt es kommerzielle Datenbanken, die anscheinend gut funktionieren. Einige funktionieren fast so gut wie Vertica, andere schlechter. Aber sie sind alle teuer, nichts Besseres und Günstigeres ließ sich finden.

Auf der anderen Seite gibt es Open-Source-Lösungen, von denen es nicht viele gibt, d. h. für Analytik kann man sie an einer Hand abzählen. Und sie sind kostenlos oder günstig, aber sie arbeiten langsam. Oft fehlt es ihnen an der benötigten und nützlichen Funktionalität.

Es gab nichts, was das Gute aus kommerziellen Datenbanken mit all dem Kostenlosen aus Open Source kombinierte.

Es gab nichts, bis plötzlich Yandex ClickHouse wie ein Kaninchen aus dem Hut eines Zauberers zog. Und das war eine unerwartete Lösung, und bis heute wird die Frage gestellt: "Warum?", aber dennoch.

Und sofort im Sommer 2016 begannen wir zu schauen, was ClickHouse ist. Und es stellte sich heraus, dass es manchmal schneller als Vertica sein kann. Wir testeten verschiedene Szenarien mit unterschiedlichen Abfragen. Und wenn die Abfrage nur eine Tabelle verwendete, d. h. ohne irgendwelche Joins, war ClickHouse doppelt so schnell wie Vertica.

Ich habe mich nicht gescheut und mir die Tests von Yandex in den letzten Tagen angesehen. Dort dasselbe: ClickHouse ist doppelt so schnell wie Vertica, daher reden sie oft darüber.

Aber wenn in den Abfragen Joins enthalten sind, wird alles nicht so eindeutig. Und ClickHouse kann langsamer als Vertica sein, und zwar um das Doppelte. Wenn die Abfrage etwas angepasst und umgeschrieben wird, ist es ungefähr gleich. Nicht schlecht. Und kostenlos.

Nachdem wir die Testergebnisse erhalten und die Situation aus verschiedenen Blickwinkeln betrachtet hatten, entschied sich LifeStreet für ClickHouse.

Das ist das Jahr 2016, ich erinnere daran. Es war wie in dem Witz über die Mäuse, die weinten und sich stachen, aber weiter Kaktus aßen. Und darüber wurde ausführlich berichtet, es gibt ein Video darüber usw.

Ich werde also nicht ausführlich darüber berichten, sondern nur die Ergebnisse und einige interessante Dinge erzählen, über die ich damals nicht gesprochen habe.

Die Ergebnisse sind:

• Erfolgreiche Migration und seit über einem Jahr läuft das System bereits in der Produktion.
• Die Leistung und Flexibilität haben zugenommen. Von 10 Milliarden Datensätzen, die wir uns früher erlauben konnten, wurden nun täglich 75 Milliarden Datensätze für LifeStreet gespeichert und dies kann über 3 Monate und mehr erfolgen. In Spitzenzeiten werden bis zu einer Million Ereignisse pro Sekunde gespeichert. Mehr als eine Million SQL-Abfragen pro Tag gelangen in dieses System, hauptsächlich von verschiedenen Bots.
• Obwohl für ClickHouse mehr Server als für Vertica verwendet werden, gab es auch eine Einsparung bei der Hardware, da in Vertica ziemlich teure SAS-Festplatten verwendet wurden. In ClickHouse wurden SATA verwendet. Warum? Weil in Vertica Inserts synchron sind. Und die Synchronisation erfordert, dass die Festplatten nicht zu stark ausgebremst werden, ebenso wie das Netzwerk, d. h. es ist eine ziemlich teure Operation. In ClickHouse sind die Inserts asynchron. Darüber hinaus kann immer alles lokal geschrieben werden, es fallen keine zusätzlichen Kosten dafür an, weshalb die Daten in ClickHouse viel schneller als in Vertica selbst auf nicht den schnellsten Festplatten eingefügt werden können. Beim Lesen ist es ungefähr gleich. Das Lesen auf SATA, wenn sie in RAID sind, erfolgt ziemlich schnell.
• Nicht durch Lizenzen eingeschränkt, d. h. 3 Petabyte Daten in 60 Servern (20 Server sind ein Replikat) und 6 Billionen Datensätze in Fakten und Aggregaten. So etwas konnte man sich bei Vertica nicht leisten.

Jetzt komme ich zu den praktischen Dingen in diesem Beispiel.

• Das Erste ist ein effektives Schema. Vom Schema hängt sehr viel ab.
• Das Zweite ist die Generierung von effektivem SQL.

Eine typische OLAP-Abfrage ist ein Select. Ein Teil der Spalten geht in die Group By-Klausel, ein Teil der Spalten in die Aggregatfunktionen. Es gibt eine Where-Klausel, die man sich als Schnitt aus dem Würfel vorstellen kann. Die gesamte Group By-Klausel kann als Projektion betrachtet werden. Daher wird das auch als multidimensionale Datenanalyse bezeichnet.

Und oft wird das in Form eines Star-Schemas modelliert, bei dem es eine zentrale Tatsache und Charakteristika dieser Tatsache an den Seiten, an den Strahlen gibt.

Und aus Sicht des physischen Designs, wie das auf die Tabelle fällt, wird normalerweise eine normalisierte Darstellung erstellt. Man kann es denormalisieren, aber das ist auf der Festplatte teuer und nicht sehr effizient bei Abfragen. Daher wird normalerweise eine normalisierte Darstellung gemacht, d. h. eine Faktentabelle und viele, viele Dimensionstabellen.

Aber in ClickHouse funktioniert das schlecht. Es gibt zwei Gründe dafür:

• Erstens liegt es daran, dass ClickHouse keine besonders guten Joins hat, d. h. es gibt Joins, aber sie sind schlecht. Bis jetzt schlecht.
• Der zweite Grund ist, dass die Tabellen nicht aktualisiert werden. Normalerweise muss man in diesen Tabellen, die um das Star-Schema herum angeordnet sind, etwas ändern. Zum Beispiel den Namen des Kunden, den Namen des Unternehmens usw. Und das funktioniert nicht.

Und es gibt einen Ausweg aus diesem Dilemma in ClickHouse. Sogar gleich zwei:

• Erstens ist die Verwendung von Dictionaries. External Dictionaries helfen zu 99 %, das Problem mit dem Star-Schema, mit Updates und anderem zu lösen.
• Zweitens die Verwendung von Arrays. Arrays helfen auch, die Joins zu vermeiden und die Probleme mit der Normalisierung zu beseitigen.

• Joins sind nicht nötig.
• Aktualisierbar. Seit März 2018 gibt es eine undocumented Möglichkeit (Sie finden es nicht in der Dokumentation), Dictionaries teilweise zu aktualisieren, d. h. die Datensätze, die sich geändert haben. Praktisch ist es wie eine Tabelle.
• Immer im Speicher, deshalb funktionieren Joins mit dem Dictionary schneller, als wenn es sich um eine Tabelle handelt, die auf der Festplatte liegt und wahrscheinlich nicht im Cache ist.

• Joins sind auch nicht nötig.
• Das ist eine kompakte Darstellung von 1 zu vielen.
• Und meiner Meinung nach sind Arrays für Nerds gemacht. Das sind Lambda-Funktionen und Ähnliches.

Das ist nicht nur leeres Geschwätz. Es handelt sich um eine sehr leistungsfähige Funktionalität, die es ermöglicht, viele Dinge sehr einfach und elegant zu erledigen.

Typische Beispiele, die helfen, Arrays zu lösen. Diese Beispiele sind einfach und sehr anschaulich:

• Suche nach Tags. Wenn Sie dort Hashtags haben und einige Einträge nach einem Hashtag finden möchten.
• Suche nach Key-Value-Paaren. Auch dort gibt es bestimmte Attribute mit Werten.
• Speicherung von Schlüssellisten, die Sie in etwas anderes umwandeln möchten.

Alle diese Aufgaben können ohne Arrays gelöst werden. Tags können in eine bestimmte Zeile eingefügt und mit regulären Ausdrücken ausgewählt oder in eine separate Tabelle gelegt werden, aber dann müssen Sie Joins machen.

In ClickHouse muss man jedoch gar nichts tun, es reicht aus, ein Array von Strings für Hashtags zu beschreiben oder eine geschachtelte Struktur für Systeme wie Key-Value zu erstellen.

Eine geschachtelte Struktur ist vielleicht nicht der beste Begriff. Es sind zwei Arrays, die einen gemeinsamen Teil im Namen haben und einige verbundene Eigenschaften.

Und die Suche nach Tags ist sehr einfach. Es gibt eine Funktion has, die überprüft, ob ein Element im Array vorhanden ist. Das ist alles, wir haben alle Einträge gefunden, die zu unserer Konferenz gehören.

Die Suche nach subid ist etwas komplizierter. Wir müssen zuerst den Index des Schlüssels finden und dann das Element mit diesem Index nehmen und überprüfen, ob der Wert den erforderlichen Kriterien entspricht. Dennoch ist es sehr einfach und kompakt.

Das reguläre Ausdruck, das Sie geschrieben hätten, wenn Sie all dies in einer Zeile gespeichert hätten, wäre erstens unschön und zweitens würde es viel länger dauern als zwei Arrays.

Ein weiteres Beispiel. Sie haben ein Array, in dem Sie IDs speichern. Und Sie können diese in Namen umwandeln. Die Funktion arrayMap. Das ist eine typische Lambda-Funktion. Sie übergeben dort Lambda-Ausdrücke. Und sie zieht für jede ID aus dem Wörterbuch den entsprechenden Namen heraus.

Auf ähnliche Weise kann auch die Suche erfolgen. Es wird eine Prädikatsfunktion übergeben, die überprüft, welchen Bedingungen die Elemente entsprechen.

Diese Dinge erleichtern das Schema erheblich und lösen viele Probleme.

Aber das nächste Problem, mit dem wir konfrontiert sind und das ich erwähnen wollte, sind effektive Anfragen.

• In ClickHouse gibt es keinen Abfrageplaner. Überhaupt keinen.
• Dennoch müssen komplexe Abfragen geplant werden. In welchen Fällen?
• Wenn es in der Anfrage mehrere Joins gibt, die Sie in Unterabfragen verpacken. Und die Reihenfolge, in der sie ausgeführt werden, ist wichtig.
• Und zweitens – wenn die Anfrage verteilt ist. Denn in einer verteilten Anfrage wird nur die innerste Unterabfrage verteilt ausgeführt, während alles andere an einen Server übergeben wird, mit dem Sie verbunden sind, und dort ausgeführt wird. Daher müssen Sie die Reihenfolge wählen, wenn Sie verteilte Anfragen mit vielen Joins haben.

Und selbst in einfacheren Fällen ist es manchmal sinnvoll, die Arbeit des Planers auszuführen und die Anfragen ein wenig umzuschreiben.

Hier ist ein Beispiel. Auf der linken Seite die Anfrage, die die Top-5-Länder zeigt. Und sie wird, glaube ich, in 2,5 Sekunden ausgeführt. Auf der rechten Seite dieselbe Anfrage, aber ein wenig umgeschrieben. Anstatt nach dem String zu gruppieren, gruppieren wir nach dem Schlüssel (int). Und das ist schneller. Danach haben wir dem Ergebnis ein Wörterbuch hinzugefügt. Anstatt 2,5 Sekunden dauert die Anfrage 1,5 Sekunden. Das ist gut.

Ein ähnliches Beispiel mit dem Umschreiben von Filtern. Hier ist die Anfrage für Russland. Sie dauert 5 Sekunden. Wenn wir sie so umschreiben, dass wir wieder nicht den String, sondern Zahlen mit einem Set von Schlüsseln vergleichen, die zu Russland gehören, wird es viel schneller sein.

Es gibt viele solcher Tricks. Und sie ermöglichen es, die Anfragen erheblich zu beschleunigen, von denen Sie denken, dass sie bereits schnell laufen, oder umgekehrt, langsam laufen. Man kann sie noch schneller machen.

• Maximaler Arbeitsaufwand im verteilten Modus.
• Sortierung nach minimalen Typen, wie ich es mit Integers gemacht habe.
• Wenn es Joins oder Wörterbücher gibt, ist es am besten, diese ganz zuletzt zu machen, wenn Sie die Daten zumindest teilweise gruppiert haben, dann wird die Join-Operation oder der Wörterbuchaufruf weniger oft aufgerufen und das wird schneller.
• Ersetzen von Filtern.

Es gibt auch andere Techniken, nicht nur die, die ich demonstriert habe. Und all dies ermöglicht es manchmal, die Ausführung von Anfragen erheblich zu beschleunigen.

Kommen wir zum nächsten Beispiel. Unternehmen X aus den USA. Was macht es?

Es gab eine Aufgabe:

• Offline-Verknüpfung von Werbetransaktionen.
• Modellierung verschiedener Bindungsmodelle.

Worin besteht das Szenario?

Ein typischer Besucher besucht die Website zum Beispiel 20 Mal im Monat über verschiedene Anzeigen oder kommt manchmal einfach so ohne jegliche Werbung, weil er sich an diese Website erinnert. Er schaut sich einige Produkte an, legt sie in den Warenkorb und nimmt sie wieder heraus. Und schließlich kauft er etwas.

Vernünftige Fragen sind: „Wem muss man für die Werbung bezahlen, wenn es nötig ist?“ und „Welche Werbung hat ihn beeinflusst, wenn sie ihn beeinflusst hat?“. Das heißt, warum hat er gekauft und wie kann man es anstellen, dass auch ähnliche Leute wie dieser Mensch kaufen?

Um diese Aufgabe zu lösen, müssen die Ereignisse, die auf der Website stattfinden, auf die richtige Weise miteinander verknüpft werden, das heißt, eine Verbindung zwischen ihnen hergestellt werden. Diese Daten müssen dann zur Analyse in das DWH übertragen werden. Auf der Grundlage dieser Analyse werden Modelle erstellt, um zu entscheiden, wem und welche Werbung gezeigt werden soll.

Eine Werbetransaktion ist eine Reihe von miteinander verbundenen Benutzerereignissen, die mit der Anzeige einer Werbung beginnen, dann geschieht etwas, dann kann es zu einem Kauf kommen, und anschließend zu weiteren Käufen innerhalb des Kaufs. Zum Beispiel, wenn es sich um eine mobile App oder ein mobiles Spiel handelt, erfolgt die Installation der App normalerweise kostenlos, aber wenn dort etwas weiter gemacht wird, können dafür Kosten anfallen. Je mehr eine Person in der App ausgibt, desto wertvoller ist sie. Aber dafür muss alles miteinander verbunden werden.

Es gibt viele Modelle zur Verknüpfung.

Die beliebtesten sind:

• Last Interaction, wobei Interaction entweder ein Klick oder eine Anzeige ist.
• First Interaction, d. h. das Erste, was den Menschen auf die Website gebracht hat.
• Lineare Kombination – allen gleich.
• Abklingen.
• Und anderes.

Und wie hat das alles ursprünglich funktioniert? Es gab Runtime und Cassandra. Cassandra wurde als Transaktionsspeicher verwendet, d. h. darin wurden alle verbundenen Transaktionen gespeichert. Wenn ein Ereignis in der Runtime eintritt, beispielsweise die Anzeige einer bestimmten Seite oder etwas anderes, wurde eine Anfrage an Cassandra gestellt – gibt es diese Person oder nicht. Dann wurden die zugehörigen Transaktionen abgerufen. Und es erfolgte die Verknüpfung.

Und wenn man Glück hat, dass die Anfrage eine transaction id enthält, ist das einfach. Aber normalerweise hat man kein Glück. Deshalb musste man die letzte Transaktion oder die Transaktion mit dem letzten Klick finden usw.

Und das hat alles sehr gut funktioniert, solange die Bindung an den letzten Klick gebunden war. Weil es zum Beispiel 10 Millionen Klicks pro Tag, 300 Millionen pro Monat gibt, wenn man das Monatsfenster betrachtet. Und da in Cassandra dies alles im Speicher sein muss, um schnell zu arbeiten, da es erfordert, dass die Laufzeit schnell antwortet, waren etwa 10-15 Server erforderlich.

Als man jedoch die Transaktion an die Anzeige binden wollte, wurde es sofort nicht mehr so lustig. Warum? Es ist offensichtlich, dass 30 Mal mehr Ereignisse gespeichert werden müssen. Und entsprechend müssen 30 Mal mehr Server vorhanden sein. Das ergibt eine astronomische Zahl. Bis zu 500 Server zu halten, um die Bindung durchzuführen, während es in der Laufzeit erheblich weniger Server gibt, ist eine völlig unrealistische Zahl. Also begann man zu überlegen, was zu tun ist.

Und so sind wir auf ClickHouse gestoßen. Aber wie macht man das mit ClickHouse? Auf den ersten Blick scheint es, als wäre es eine Ansammlung von Antipatterns.

• Die Transaktion wächst, wir binden immer neue und neue Ereignisse daran, d.h. sie ist veränderlich, und ClickHouse arbeitet nicht besonders gut mit veränderlichen Objekten.
• Wenn ein Besucher zu uns kommt, müssen wir seine Transaktionen anhand des Schlüssels, seines Besuchs-IDs, abrufen. Das ist ebenfalls eine Punktabfrage, so macht man das in ClickHouse nicht. Normalerweise gibt es in ClickHouse große Scans, aber hier müssen wir einige Aufzeichnungen abrufen. Auch ein Antipattern.
• Darüber hinaus war die Transaktion im JSON-Format, aber wir wollten sie nicht umschreiben, daher wollten wir JSON unstrukturiert speichern, und wenn nötig, etwas daraus extrahieren. Auch das ist ein Antipattern.

Das heißt, es handelt sich um eine Ansammlung von Antipatterns.

Trotzdem gelang es uns, ein System zu schaffen, das sehr gut funktionierte.

Was wurde getan? ClickHouse wurde implementiert, in das die Protokolle, aufgespalten in Datensätze, hineingepackt wurden. Es gab einen attribuierten Service, der die Protokolle aus ClickHouse abrief. Danach erhielt man für jeden Datensatz anhand der Besuchs-ID die Transaktionen, die möglicherweise noch nicht verarbeitet waren, sowie Snapshots, also bereits verknüpfte Transaktionen, also das Ergebnis der vorherigen Arbeit. Aus ihnen wurde die Logik erstellt, die richtige Transaktion ausgewählt und neue Ereignisse verbunden. Wieder in die Protokolle geschrieben. Die Protokolle gingen zurück nach ClickHouse, das heißt, es ist ein ständig zyklisches System. Außerdem gingen sie in das DWH, um dort zu analysieren.

In dieser Form funktionierte es nicht besonders gut. Um es ClickHouse leichter zu machen, wenn eine Abfrage nach dem Besuchs-ID erfolgte, wurden diese Abfragen in Blöcke von 1.000 bis 2.000 Besuchs-IDs gruppiert und für 1.000 bis 2.000 Personen wurden alle Transaktionen abgerufen. Und dann funktionierte das Ganze.

Wenn man in ClickHouse hineinblickt, gibt es dort nur 3 Haupttabellen, die all dies verwalten.

Die erste Tabelle, in die die Logs geladen werden, wobei die Logs praktisch ohne Bearbeitung geladen werden.

Die zweite Tabelle. Über eine materialisierte Sicht wurden aus diesen Logs die noch nicht zugeordneten Events herausgefiltert, d. h. nicht miteinander verbundene. Und über eine materialisierte Sicht wurden aus diesen Logs die Transaktionen abgerufen, um einen Snapshot zu erstellen. D. h. eine spezielle materialisierte Sicht stellt den Snapshot dar, genau genommen den letzten kumulierten Zustand der Transaktion.

Hier ist ein Text in SQL geschrieben. Ich möchte darin einige wichtige Punkte kommentieren.

Der erste wichtige Punkt ist die Möglichkeit, in ClickHouse aus JSON Spalten, Felder herauszuziehen. D. h. ClickHouse hat einige Methoden zur Arbeit mit JSON. Diese sind sehr, sehr primitiv.

visitParamExtractInt ermöglicht es, Attribute aus JSON herauszuziehen, d. h. das erste Auftreten wird erfasst. So kann man die Transaktions-ID oder die Besuchs-ID herausziehen. Das ist Punkt eins.

Zweitens – hier wird ein cleveres materialisiertes Feld verwendet. Was bedeutet das? Das bedeutet, dass Sie es nicht in die Tabelle einfügen können, d. h. es wird nicht eingefügt, sondern berechnet und bei der Einfügung gespeichert. Bei der Einfügung übernimmt ClickHouse die Arbeit für Sie. Und es wird aus JSON herausgezogen, was Sie später benötigen werden.

In diesem Fall ist die materialisierte Sicht für unbearbeitete Zeilen. Und es wird genau die erste Tabelle mit praktisch rohen Logs genutzt. Und was macht sie? Sie ändert zuerst die Sortierung, d. h. die Sortierung erfolgt jetzt nach Besuchs-ID, da wir schnell die Transaktion einer bestimmten Person abfragen müssen.

Der zweite wichtige Punkt ist die index_granularity. Wenn Sie MergeTree gesehen haben, steht die index_granularity normalerweise standardmäßig auf 8.192. Was ist das? Das ist ein Parameter der Indexpunktdichte. In ClickHouse ist der Index dünn; er indiziert niemals jeden Datensatz. Das geschieht alle 8.192. Das ist gut, wenn viele Daten gezählt werden müssen, aber schlecht, wenn nur wenige, weil es einen großen Overhead verursacht. Und wenn man die index granularity verringert, vermindert man den Overhead. Man kann sie jedoch nicht auf eins reduzieren, da es möglicherweise an Speicher mangelt. Der Index wird immer im Speicher aufbewahrt.

Ein Snapshot nutzt noch einige interessante Funktionen von ClickHouse.

Zuerst ist da der AggregatingMergeTree. Im AggregatingMergeTree wird argMax gespeichert, das heißt, es ist der Zustand der Transaktion, der dem letzten Zeitstempel entspricht. Transaktionen werden ständig neu generiert für diesen Besucher. Und in den allerneuesten Zustand dieser Transaktion haben wir ein Ereignis hinzugefügt und haben einen neuen Zustand erhalten. Dieser geht wieder in ClickHouse. Und über argMax in dieser materialisierten Ansicht können wir immer den aktuellen Zustand abrufen.

• Die Bindung ist "entkoppelt" vom Runtime.
• Bis zu 3 Milliarden Transaktionen pro Monat werden gespeichert und verarbeitet. Das ist um ein Vielfaches mehr, als es bei Cassandra war, also in einem typischen Transaktionssystem.
• Cluster aus 2x5 ClickHouse-Servern. 5 Server, und jeder Server hat eine Replik. Das ist sogar weniger, als es bei Cassandra war, um eine Click-basierten Attribution zu machen, hier haben wir jedoch eine Impression-basierte. Das heißt, anstatt die Anzahl der Server um das 30-fache zu erhöhen, ist es gelungen, sie zu reduzieren.

Und das letzte Beispiel ist das Finanzunternehmen Y, das die Korrelationen der Veränderungen der Aktienkurse analysierte.

Die Aufgabe war folgende:

• Es gibt etwa 5.000 Aktien.
• Die Kursdaten werden alle 100 Millisekunden bekannt.
• Die Daten haben sich über 10 Jahre angesammelt. Offensichtlich haben einige Unternehmen mehr, andere weniger.
• Insgesamt etwa 100 Milliarden Zeilen.

Und es musste die Korrelation der Änderungen berechnet werden.

Hier gibt es zwei Aktien und ihre Kurse. Wenn eine steigt und die andere auch steigt, dann ist das eine positive Korrelation, das heißt, wenn eine wächst, wächst die andere. Wenn eine steigt, wie am Ende des Diagramms, und die andere fällt, dann ist das eine negative Korrelation, das heißt, wenn eine wächst, sinkt die andere.

Durch die Analyse dieser wechselseitigen Veränderungen können Vorhersagen auf dem Finanzmarkt getroffen werden.

Aber die Aufgabe ist komplex. Was wird dazu gemacht? Wir haben 100 Milliarden Datensätze, in denen Zeit, Aktie und Preis enthalten sind. Zuerst müssen wir 100 Milliarden Mal den RunningDifference des Preisalgorithmus berechnen. Der RunningDifference ist eine Funktion in ClickHouse, die die Differenz zwischen zwei Zeilen sequenziell berechnet.

Nachdem das geschehen ist, muss die Korrelation berechnet werden, und zwar für jedes Paar. Bei 5.000 Aktien gibt es 12,5 Millionen Paare. Und das ist viel, das heißt, 12,5 Mal muss so eine Korrelationsfunktion berechnet werden.

Und falls jemand es vergessen hat, ͞x und ͞y sind die mathematischen Erwartungen der Stichprobe. Das heißt, man muss nicht nur die Wurzeln und Summen berechnen, sondern auch innerhalb dieser Summen weitere Summen. Eine Menge an Berechnungen muss 12,5 Millionen Mal durchgeführt und zudem stündlich gruppiert werden. Und die Stunden haben wir auch nicht gerade wenig. Und das alles muss in 60 Sekunden erledigt sein. Das ist ein Scherz.

Es musste irgendwie schnell gehen, denn alles arbeitete sehr, sehr langsam, bevor ClickHouse kam.

Sie versuchten, das auf Hadoop, auf Spark, auf Greenplum zu berechnen. Und all das war sehr langsam oder teuer. Das heißt, man konnte es irgendwie berechnen, aber es war dann teuer.

Und dann kam ClickHouse und alles wurde viel besser.

Ich erinnere daran, dass wir ein Problem mit der Datenlokalität haben, daher können die Korrelationen nicht lokalisiert werden. Wir können einen Teil der Daten auf einen Server und einen anderen Teil auf einen anderen verschieben und nicht berechnen; wir müssen alle Daten überall haben.

Was haben sie gemacht? Zunächst einmal sind die Daten lokalisiert. Auf jedem der Server werden die Daten zur Preisgestaltung eines bestimmten Aktiensets gespeichert. Und sie überschneiden sich nicht. Daher kann logReturn parallel und unabhängig berechnet werden. Das geschieht alles parallel und verteilt.

Dann beschlossen sie, diese Daten zu reduzieren, ohne dabei Ausdruckskraft zu verlieren. Sie sollten durch Arrays reduziert werden, d.h. für jeden Zeitabschnitt ein Array von Aktien und ein Array von Preisen erstellen. Auf diese Weise nehmen die Daten viel weniger Platz ein. Und es ist etwas einfacher, mit ihnen zu arbeiten. Es sind fast parallele Operationen, d.h. wir berechnen teilweise parallel und schreiben dann auf den Server.

Danach können sie repliziert werden. Der Buchstabe „r“ bedeutet, dass diese Daten repliziert wurden. Das heißt, wir haben auf allen drei Servern dieselben Daten – diese Arrays.

Und dann kann man mit einem speziellen Skript aus diesem Satz von 12,5 Millionen Korrelationen, die berechnet werden müssen, Pakete erstellen. Das heißt, 2.500 Aufgaben mit 5.000 Paar Korrelationen. Und diese Aufgaben können auf einem bestimmten ClickHouse-Server berechnet werden. Alle Daten sind vorhanden, da die Daten identisch sind und er sie nacheinander berechnen kann.

Noch einmal, wie das aussieht. Zunächst haben wir alle Daten in dieser Struktur: Zeit, Aktien, Preis. Dann haben wir den logReturn berechnet, d. h. Daten in derselben Struktur, nur anstelle des Preises haben wir jetzt den logReturn. Danach haben wir sie umstrukturiert, d. h. wir haben Zeit und groupArray nach Aktien und Preisen erhalten. Wir haben sie repliziert. Und danach haben wir eine Menge Aufgaben generiert und ClickHouse verfüttert, damit er sie berechnet. Und das funktioniert.

Beim Proof of Concept war die Aufgabe eine Unteraufgabe, d. h. wir haben weniger Daten verwendet. Und das auf drei Servern.

Die ersten beiden Phasen: Berechnung des Log_return und das Umwickeln in Arrays dauerte jeweils etwa eine Stunde.

Die Berechnung der Korrelation dauerte etwa 50 Stunden. Aber 50 Stunden sind wenig, denn früher hat das Wochen gebraucht. Das war ein großer Erfolg. Und wenn man es berechnet, wurde in diesem Cluster 70 Mal pro Sekunde alles gerechnet.

Aber das Wichtigste ist, dass dieses System praktisch ohne Engpässe funktioniert, d. h. es ist nahezu linear skalierbar. Und das haben sie überprüft. Sie haben es erfolgreich skaliert.

• Das richtige Schema ist die halbe Miete. Und das richtige Schema ist die Nutzung aller notwendigen Technologien von ClickHouse.
• Summing/AggregatingMergeTrees sind Technologien, die es ermöglichen, zu aggregieren oder den Snapshots-Zustand als Sonderfall zu berechnen. Und das vereinfacht vieles erheblich.
• Materialisierte Ansichten ermöglichen es, die Einschränkung auf einen Index zu umgehen. Vielleicht habe ich das nicht ganz klar erklärt, aber als wir die Logs geladen haben, waren die Rohlogs in einer Tabelle mit einem Index, während die Attribut-Logs in einer anderen Tabelle waren, d. h. dieselben Daten, nur gefiltert, aber der Index war völlig anders. Es sind zwar die gleichen Daten, aber eine andere Sortierung. Und materialisierte Ansichten erlauben es, wenn Sie das möchten, eine solche Einschränkung von ClickHouse zu umgehen.
• Verringern Sie die Granularität des Index für punktuelle Abfragen.
• Und verteilen Sie die Daten intelligent, versuchen Sie, die Daten innerhalb des Servers maximal zu lokalisieren. Und streben Sie an, dass auch die Abfragen dort, wo es möglich ist, eine maximale Lokalisierung nutzen.

Zusammenfassend lässt sich sagen, dass ClickHouse inzwischen sowohl im Bereich kommerzieller Datenbanken als auch bei Open-Source-Datenbanken, d. h. insbesondere für Analysen, fest etabliert ist. Er hat sich hervorragend in diese Landschaft integriert. Darüber hinaus beginnt er schrittweise, andere abzudrängen, denn wenn Sie ClickHouse haben, benötigen Sie InfiniDB nicht mehr. Veritik könnte bald ebenfalls nicht mehr benötigt werden, wenn sie eine ordentliche SQL-Unterstützung bieten. Nutzen Sie es!

—Vielen Dank für den Vortrag! Sehr interessant! Gab es Vergleiche mit Apache Phoenix?

-Nein, ich habe nicht gehört, dass jemand einen Vergleich gezogen hat. Wir und Yandex versuchen, alle Vergleiche von ClickHouse mit verschiedenen Datenbanken zu verfolgen. Denn wenn etwas schneller als ClickHouse ist, kann Alexey Milovidov nachts nicht schlafen und beginnt, es schnell zu beschleunigen. Ich habe von einem solchen Vergleich nichts gehört.

• (Alexey Milovidov) Apache Phoenix ist eine SQL-Engine auf HBase. HBase ist hauptsächlich für Szenarien mit key-value-Betrieb gedacht. In jeder Zeile kann es eine beliebige Anzahl von Spalten mit beliebigen Namen geben. Das kann man auch von Systemen wie HBase, Cassandra sagen. Und auf diesen wird es schwierig sein, mit schweren analytischen Abfragen normal zu arbeiten. Oder man könnte glauben, dass sie normal funktionieren, wenn man keine Erfahrung mit ClickHouse hat.

• Danke

  • Guten Tag! Ich interessiere mich schon eine ganze Weile für dieses Thema, weil ich ein analytisches Teilsystem habe. Aber wenn ich auf ClickHouse schaue, habe ich das Gefühl, dass ClickHouse sehr gut für die Analyse von Events und Mutable geeignet ist. Und wenn ich viele Geschäftsdaten mit einer Menge großer Tabellen analysieren muss, dann ist ClickHouse, soweit ich verstehe, nicht wirklich geeignet für mich? Besonders, wenn sie sich verändern. Ist das korrekt oder gibt es Beispiele, die das widerlegen können?

  • Das ist richtig. Und es stimmt für die meisten spezialisierten analytischen Datenbanken. Sie sind darauf optimiert, dass es eine oder mehrere große, veränderbare Tabellen gibt und viele kleine, die sich langsam ändern. Das heißt, ClickHouse ist nicht wie Oracle, wo man alles ablegen und sehr komplexe Abfragen erstellen kann. Um ClickHouse effektiv zu nutzen, sollte man das Schema in einer Weise aufbauen, die in ClickHouse gut funktioniert. Das bedeutet, übermäßige Normalisierung zu vermeiden, Wörterbücher zu verwenden und zu versuchen, weniger lange Verknüpfungen zu machen. Wenn das Schema auf diese Weise aufgebaut wird, können ähnliche Geschäftsanforderungen in ClickHouse viel effizienter gelöst werden als in einer traditionellen relationalen Datenbank.

Vielen Dank für den Vortrag! Ich habe eine Frage zu dem letzten finanziellen Fall. Sie hatten eine Analyse. Es musste verglichen werden, wie es auf und ab geht. Und ich verstehe, dass Sie das System genau für diese Analyse eingerichtet haben? Wenn sie morgen beispielsweise einen anderen Bericht über diese Daten benötigen, muss das Schema dann neu aufgebaut und die Daten erneut geladen werden? Das heißt, es muss eine Vorverarbeitung gemacht werden, um die Anfrage zu erhalten?

Natürlich ist das die Nutzung von ClickHouse für eine ganz konkrete Aufgabe. Diese könnte traditionell im Rahmen von Hadoop gelöst werden. Für Hadoop ist das eine ideale Aufgabe. Aber bei Hadoop ist es sehr langsam. Mein Ziel ist es, zu demonstrieren, dass man mit ClickHouse Aufgaben lösen kann, die normalerweise mit völlig anderen Mitteln gelöst werden, wobei es dabei viel effizienter geht. Es ist für eine konkrete Aufgabe optimiert. Es ist klar, dass man eine ähnliche Aufgabenstellung auf ähnliche Weise lösen kann.

Verstehe. Sie sagten, dass es 50 Stunden gedauert hat. Fängt das von Anfang an an, wenn man die Daten geladen hat, oder geht es um die Erzielung der Ergebnisse?

Ja, ja.

Gut, vielen Dank.

Das läuft auf einem 3-Server-Cluster.

Hallo! Vielen Dank für den Vortrag! Das ist alles sehr interessant. Ich möchte nicht über die Funktionalität fragen, sondern über die Verwendung von ClickHouse in Bezug auf die Stabilität. Gab es bei Ihnen irgendwelche Vorfälle, bei denen Sie wiederherstellen mussten? Wie verhält sich ClickHouse dabei? Und kam es vor, dass auch Ihre Replikation ausgefallen ist? Wir sind bei ClickHouse beispielsweise auf das Problem gestoßen, dass es letztendlich seine Grenze überschreitet und abstürzt.

Natürlich gibt es keine perfekten Systeme. Auch ClickHouse hat seine eigenen Probleme. Aber haben Sie jemals gehört, dass Yandex.Metrica länger nicht funktioniert hat? Vermutlich nicht. Sie funktioniert seit etwa 2012-2013 zuverlässig mit ClickHouse. Auch über meine Erfahrungen kann ich sagen, dass wir nie vollständige Ausfälle hatten. Einige partielle Probleme konnten auftreten, aber sie waren nie kritisch genug, um das Geschäft ernsthaft zu beeinträchtigen. So etwas gab es nie. ClickHouse ist ziemlich zuverlässig und stürzt nicht willkürlich ab. Darüber kann man sich keine Gedanken machen. Es ist kein unausgerechtes Produkt. Viele Unternehmen haben dies bewiesen.

Hallo! Sie sagten, dass man das Datenschema gleich gut durchdenken muss. Und was passiert, wenn das nicht der Fall ist? Bei mir fließen die Daten und fließen. Nach sechs Monaten merke ich, dass ich so nicht weitermachen kann, ich muss die Daten neu hochladen und etwas damit machen.

Das hängt natürlich von Ihrem System ab. Es gibt mehrere Möglichkeiten, dies praktisch ohne Unterbrechung zu tun. Zum Beispiel können Sie eine Materialisierte Sicht erstellen, in der Sie eine andere Datenstruktur machen, wenn diese eindeutig abgebildet werden kann. D. h. wenn sie mithilfe von ClickHouse abgebildet werden kann, also einige Dinge extrahiert, den Primärschlüssel geändert und die Partitionierung verändert werden kann, dann können Sie eine Materialisierte Sicht erstellen. Dort können Sie Ihre alten Daten umschreiben, neue werden automatisch geschrieben. Und dann einfach auf die Nutzung der Materialisierten Sicht umschalten, danach die Schreibweise umschalten und die alte Tabelle löschen. Das ist eine Möglichkeit, das ganz ohne Unterbrechung zu tun.

Danke.

Quelle: habr.com