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

Trotz der Tatsache, dass es mittlerweile fast überall viele Daten gibt, sind analytische Datenbanken immer noch recht exotisch. Sie sind kaum bekannt und noch schlechter in der Lage, sie effektiv zu nutzen. Viele „essen weiterhin Kakteen“ mit MySQL oder PostgreSQL, die für andere Szenarien konzipiert sind, leiden unter NoSQL oder zahlen zu viel für kommerzielle Lösungen. ClickHouse ändert die Spielregeln und senkt die Schwelle für den Einstieg in die Welt des analytischen DBMS deutlich.

Bericht von der BackEnd Conf 2018, der mit Genehmigung des Redners veröffentlicht wird.

Wer bin ich und warum spreche ich von ClickHouse? Ich bin Entwicklungsleiter bei LifeStreet, das ClickHouse verwendet. Außerdem bin ich der Gründer von Altinity. Es handelt sich um einen Yandex-Partner, der ClickHouse bewirbt und Yandex dabei hilft, ClickHouse erfolgreicher zu machen. Auch bereit, Wissen über ClickHouse zu teilen.

Und ich bin nicht der Bruder von Petya Zaitsev. Ich werde oft danach gefragt. Nein, wir sind keine Brüder.

„Jeder weiß“, dass ClickHouse:

• Sehr schnell,
• Sehr bequem
• Wird in Yandex verwendet.

Etwas weniger ist bekannt, in welchen Unternehmen und wie es eingesetzt wird.

Ich erzähle Ihnen, warum, wo und wie ClickHouse verwendet wird, außer bei Yandex.

Ich erzähle Ihnen, wie konkrete Aufgaben mit Hilfe von ClickHouse in verschiedenen Unternehmen gelöst werden, welche ClickHouse-Tools Sie für Ihre Aufgaben nutzen können und wie diese in verschiedenen Unternehmen eingesetzt wurden.

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

Die erste Frage lautet: „Warum brauchen wir ClickHouse?“ Es scheint eine ziemlich offensichtliche Frage zu sein, aber es gibt mehr als eine Antwort darauf.

• Die erste Antwort betrifft die Leistung. ClickHouse ist sehr schnell. Auch die Analyse auf ClickHouse ist sehr schnell. Es kann oft dort eingesetzt werden, wo etwas anderes sehr langsam oder sehr schlecht ist.
• Die zweite Antwort sind die Kosten. Und zunächst einmal die Kosten der Skalierung. Vertica zum Beispiel ist eine absolut tolle Datenbank. Es funktioniert sehr gut, wenn Sie nicht über viele Terabytes an Daten verfügen. Aber wenn es um Hunderte von Terabyte oder Petabyte geht, belaufen sich die Kosten für Lizenz und Support auf einen recht hohen Betrag. Und es ist teuer. Und ClickHouse ist kostenlos.
• Die dritte Antwort sind die Betriebskosten. Dies ist ein etwas anderer Ansatz. RedShift ist ein großartiges Analogon. Auf RedShift können Sie sehr schnell eine Entscheidung treffen. Es wird gut funktionieren, aber gleichzeitig zahlen Sie Amazon jede Stunde, jeden Tag und jeden Monat ziemlich viel, da es sich um einen erheblich teuren Service handelt. Auch Google BigQuery. Wenn jemand es verwendet hat, weiß er, dass man dort mehrere Anfragen stellen kann und plötzlich eine Rechnung über Hunderte von Dollar erhält.

ClickHouse hat diese Probleme nicht.

Wo wird ClickHouse jetzt eingesetzt? Zusätzlich zu Yandex wird ClickHouse in einer Reihe verschiedener Unternehmen und Unternehmen eingesetzt.

• Zunächst einmal handelt es sich um Webanwendungsanalysen, d. h. es handelt sich um einen Anwendungsfall, der von Yandex stammt.
• Viele AdTech-Unternehmen nutzen ClickHouse.
• Zahlreiche Unternehmen, die Transaktionsprotokolle aus verschiedenen Quellen analysieren müssen.
• Mehrere Unternehmen verwenden ClickHouse zur Überwachung von Sicherheitsprotokollen. Sie laden sie auf ClickHouse hoch, erstellen Berichte und erhalten die benötigten Ergebnisse.
• Unternehmen beginnen, es in der Finanzanalyse einzusetzen, d. h. nach und nach wenden sich auch große Unternehmen an ClickHouse.
• Wolkenflare. Wenn jemand ClickHouse folgt, hat er wahrscheinlich schon den Namen dieses Unternehmens gehört. Dies ist einer der wesentlichen Mitwirkenden der Community. Und sie haben eine sehr seriöse ClickHouse-Installation. Sie haben zum Beispiel die Kafka Engine für ClickHouse entwickelt.
• Telekommunikationsunternehmen begannen mit der Nutzung. Mehrere Unternehmen nutzen ClickHouse entweder als Proof-on-Concept oder bereits in der Produktion.
• Ein Unternehmen nutzt ClickHouse zur Überwachung von Produktionsprozessen. Sie testen Mikroschaltungen, schreiben eine Reihe von Parametern ab, es gibt etwa 2 Eigenschaften. Und dann analysieren sie, ob das Spiel gut oder schlecht ist.
• Blockchain-Analyse. Es gibt so ein russisches Unternehmen wie Bloxy.info. Dies ist eine Analyse des Ethereum-Netzwerks. Das haben sie auch auf ClickHouse gemacht.

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

Und wenn Sie sich die Aufzeichnungen ansehen, dann:

• Yandex: Über 500 Server speichern dort täglich 25 Milliarden Datensätze.
• LifeStreet: 60 Server, etwa 75 Milliarden Datensätze pro Tag. Es gibt weniger Server und mehr Datensätze als in Yandex.
• CloudFlare: 36 Server, sie speichern täglich 200 Milliarden Datensätze. Sie haben noch weniger Server und speichern noch mehr Daten.
• Bloomberg: 102 Server, etwa eine Billion Einträge pro Tag. Rekordhalter.

Geografisch ist das auch viel. Diese Karte hier zeigt eine Heatmap der Einsatzorte von ClickHouse auf der Welt. Russland, China, Amerika stechen hier deutlich hervor. Es gibt nur wenige europäische Länder. Und es gibt 4 Cluster.

Es handelt sich um eine vergleichende Analyse, es besteht keine Notwendigkeit, nach absoluten Zahlen zu suchen. Dies ist eine Analyse von Besuchern, die englischsprachige Materialien auf der Altinity-Website lesen, da es dort keine russischsprachigen gibt. Und Russland, die Ukraine, Weißrussland, also der russischsprachige Teil der Community, das sind die zahlreichsten Nutzer. Dann kommen die USA und Kanada. China holt stark auf. Vor einem halben Jahr gab es dort fast kein China, mittlerweile hat China Europa bereits überholt und wächst weiter. Auch das alte Europa liegt nicht weit dahinter, und der Spitzenreiter bei der Nutzung von ClickHouse ist seltsamerweise Frankreich.

Warum erzähle ich das alles? Um zu zeigen, dass ClickHouse zur Standardlösung für Big-Data-Analysen wird und bereits vielerorts im Einsatz ist. Wenn Sie es nutzen, liegen Sie im richtigen Trend. Wenn Sie es noch nicht nutzen, können Sie keine Angst haben, dass Sie allein gelassen werden und Ihnen niemand helfen wird, denn viele tun dies bereits.

Dies sind Beispiele für den echten ClickHouse-Einsatz in mehreren Unternehmen.

• Das erste Beispiel ist ein Werbenetzwerk: Migration von Vertica zu ClickHouse. Und ich kenne einige Unternehmen, die von Vertica umgestiegen sind oder sich gerade im Umstellungsprozess befinden.
• Das zweite Beispiel ist die Transaktionsspeicherung auf ClickHouse. Dies ist ein Beispiel, das auf Antimustern basiert. Alles, was in ClickHouse auf Anraten der Entwickler nicht getan werden sollte, wird hier erledigt. Und es ist so effektiv gemacht, dass es funktioniert. Und es funktioniert viel besser als die typische Transaktionslösung.
• Das dritte Beispiel ist verteiltes Rechnen auf ClickHouse. Es stellte sich die Frage, wie ClickHouse in das Hadoop-Ökosystem integriert werden kann. Ich werde ein Beispiel zeigen, wie ein Unternehmen etwas Ähnliches wie einen Kartenreduzierungscontainer auf ClickHouse durchgeführt hat, um die Datenlokalisierung usw. zu verfolgen und eine sehr nicht triviale Aufgabe zu berechnen.

• LifeStreet ist ein Ad-Tech-Unternehmen, das über die gesamte Technologie eines Werbenetzwerks verfügt.
• Sie beschäftigt sich mit Anzeigenoptimierung und Programmatic Bidding.
• Viele Daten: etwa 10 Milliarden Ereignisse pro Tag. Dabei können die dortigen Veranstaltungen in mehrere Teilveranstaltungen unterteilt werden.
• Es gibt viele Kunden dieser Daten, und das sind nicht nur Menschen, sondern vielmehr verschiedene Algorithmen, die sich mit programmatischen Geboten befassen.

Das Unternehmen hat einen langen und steinigen Weg zurückgelegt. Und ich habe auf HighLoad darüber gesprochen. Zunächst wechselte LifeStreet von MySQL (mit einem kurzen Zwischenstopp bei Oracle) zu Vertica. Und Sie können eine Geschichte dazu finden.

Und alles war sehr gut, aber es wurde schnell klar, dass die Daten wachsen und Vertica teuer ist. Daher wurde nach verschiedenen Alternativen gesucht. Einige davon sind hier aufgelistet. Und tatsächlich haben wir fast alle Datenbanken, die vom 13. bis zum 16. Jahr auf dem Markt waren und hinsichtlich der Funktionalität annähernd geeignet waren, einem Proof of Concept oder manchmal auch einem Leistungstest unterzogen. Und über einige davon habe ich auch auf HighLoad gesprochen.

Die Aufgabe bestand zunächst darin, von Vertica zu migrieren, da die Datenmengen wuchsen. Und sie sind im Laufe der Jahre exponentiell gewachsen. Dann landeten sie im Regal, aber trotzdem. Und angesichts der Vorhersage dieses Wachstums und der geschäftlichen Anforderungen an die Datenmenge, die analysiert werden musste, war klar, dass bald über Petabytes gesprochen werden würde. Da die Bezahlung von Petabyte bereits sehr teuer ist, suchten wir nach einer Alternative.

Wo hin? Und es war lange Zeit überhaupt nicht klar, wohin man gehen soll, denn einerseits gibt es kommerzielle Datenbanken, die scheinen gut zu funktionieren. Einige funktionieren fast genauso gut wie Vertica, andere schlechter. Aber sie sind alle teuer, es gibt nichts billigeres und besseres.

Andererseits gibt es Open-Source-Lösungen, die nicht sehr zahlreich sind, d. h. für die Analyse kann man sie an den Fingern abzählen. Und sie sind kostenlos oder günstig, aber langsam. Und ihnen fehlt oft die nötige und nützliche Funktionalität.

Und es gab nichts, was die Vorteile kommerzieller Datenbanken mit all dem kostenlosen Angebot von Open Source vereinen konnte.

Es gab nichts, bis Yandex ClickHouse unerwartet hervorholte, wie ein Zauberer aus dem Hut, wie ein Kaninchen. Und es war eine unerwartete Entscheidung, sie stellen immer noch die Frage: „Warum?“, aber trotzdem.

Und gleich im Sommer 2016 begannen wir, uns mit ClickHouse auseinanderzusetzen. Und es stellte sich heraus, dass es manchmal schneller sein kann als Vertica. Wir haben verschiedene Szenarien auf unterschiedliche Anfragen getestet. Und wenn die Abfrage nur eine Tabelle verwendete, also ohne jegliche Verknüpfungen (Join), dann war ClickHouse doppelt so schnell wie Vertica.

Ich war nicht zu faul und habe mir neulich die Yandex-Tests angesehen. Dort ist es das Gleiche: ClickHouse ist doppelt so schnell wie Vertica, daher wird oft darüber gesprochen.

Wenn die Abfragen jedoch Verknüpfungen enthalten, ist alles nicht ganz eindeutig. Und ClickHouse kann doppelt so langsam sein wie Vertica. Und wenn Sie die Anfrage leicht korrigieren und umschreiben, sind sie ungefähr gleich. Nicht schlecht. Und frei.

Nachdem LifeStreet die Testergebnisse erhalten und aus verschiedenen Blickwinkeln betrachtet hatte, wandte es sich an ClickHouse.

Ich erinnere Sie daran, dass dies das 16. Jahr ist. Es war wie ein Witz über Mäuse, die weinten und sich stachen, aber weiterhin den Kaktus fraßen. Und das wurde ausführlich beschrieben, es gibt ein Video dazu usw.

Deshalb werde ich nicht im Detail darauf eingehen, sondern nur auf die Ergebnisse und ein paar interessante Dinge eingehen, über die ich damals noch nicht gesprochen habe.

Die Ergebnisse sind:

• Erfolgreiche Migration und mehr als ein Jahr läuft das System bereits in der Produktion.
• Produktivität und Flexibilität sind gestiegen. Von den 10 Milliarden Datensätzen, die wir uns leisten könnten, pro Tag und auch dann nur für kurze Zeit zu speichern, speichert LifeStreet jetzt 75 Milliarden Datensätze pro Tag und kann dies für 3 Monate oder länger tun. Zählt man in der Spitze, dann sind es bis zu eine Million Ereignisse pro Sekunde. In diesem System gehen täglich mehr als eine Million SQL-Anfragen ein, meist von verschiedenen Robotern.
• Obwohl für ClickHouse mehr Server verwendet wurden als für Vertica, wurde auch Hardware gespart, da in Vertica recht teure SAS-Festplatten verwendet wurden. ClickHouse verwendete SATA. Und warum? Denn in Vertica erfolgt die Einfügung synchron. Und die Synchronisierung erfordert, dass die Festplatten nicht zu sehr langsam werden und auch das Netzwerk nicht zu sehr langsam wird, was ein ziemlich kostspieliger Vorgang ist. Und in ClickHouse ist das Einfügen asynchron. Darüber hinaus können Sie immer alles lokal schreiben, es fallen hierfür keine zusätzlichen Kosten an, sodass Daten auch auf langsameren Laufwerken viel schneller in ClickHouse eingefügt werden können als in Vertika. Und beim Lesen ist es ungefähr das Gleiche. Beim Lesen auf SATA ist alles schnell genug, wenn sie sich im RAID befinden.
• Keine Lizenzbeschränkung, d. h. 3 Petabyte Daten auf 60 Servern (20 Server sind ein Replikat) und 6 Billionen Datensätze in Fakten und Aggregationen. Bei Vertica konnte man sich so etwas nicht leisten.

In diesem Beispiel wende ich mich nun den praktischen Dingen zu.

• Das erste ist ein effizientes Schema. Viel hängt vom Schema ab.
• Die zweite Möglichkeit ist die effiziente SQL-Generierung.

Eine typische OLAP-Abfrage ist eine Auswahl. Einige der Spalten gehen in die Gruppierung nach, andere in Aggregatfunktionen. Es gibt ein Wo, das als Würfelscheibe dargestellt werden kann. Die gesamte Gruppe kann als Projektion betrachtet werden. Und deshalb nennt man es multivariate Datenanalyse.

Und oft wird dies in Form eines Sternschemas modelliert, wenn es eine zentrale Tatsache und Merkmale dieser Tatsache entlang der Seiten, entlang der Strahlen gibt.

Und was das physische Design angeht, wie es auf den Tisch passt, erfolgt normalerweise eine normalisierte Darstellung. Sie können denormalisieren, aber es ist auf der Festplatte teuer und bei Abfragen nicht sehr effizient. Daher erstellen sie normalerweise eine normalisierte Darstellung, d. h. eine Faktentabelle und viele, viele Dimensionstabellen.

Aber in ClickHouse funktioniert es nicht gut. Es gibt zwei Gründe:

• Der erste Grund liegt darin, dass ClickHouse keine sehr guten Verknüpfungen hat, d. h. es gibt Verknüpfungen, aber sie sind schlecht. Während schlecht.
• Der zweite Grund ist, dass die Tabellen nicht aktualisiert werden. Normalerweise muss an diesen Platten, die sich rund um die Sternschaltung befinden, etwas geändert werden. Zum Beispiel Kundenname, Firmenname usw. Und es funktioniert nicht.

Und in ClickHouse gibt es einen Ausweg. sogar zwei:

• Das erste ist die Verwendung von Wörterbüchern. Externe Wörterbücher helfen zu 99 % bei der Lösung des Problems mit dem Sternschema, mit Aktualisierungen usw.
• Die zweite Möglichkeit besteht in der Verwendung von Arrays. Arrays helfen auch dabei, Joins und Probleme mit der Normalisierung zu beseitigen.

• Kein Beitritt erforderlich.
• Aufrüstbar. Seit März 2018 gibt es eine undokumentierte Möglichkeit (diese finden Sie in der Dokumentation nicht), Wörterbücher teilweise, d. h. die Einträge, die sich geändert haben, zu aktualisieren. Praktisch ist es wie ein Tisch.
• Immer im Speicher, daher funktionieren Verknüpfungen mit einem Wörterbuch schneller, als wenn es sich um eine Tabelle auf der Festplatte handeln würde und es noch keine Tatsache ist, dass sie sich im Cache befindet, höchstwahrscheinlich nicht.

• Sie benötigen auch keine Verknüpfungen.
• Dies ist eine kompakte 1-zu-viele-Darstellung.
• Und meiner Meinung nach sind Arrays für Geeks gemacht. Dies sind Lambda-Funktionen und so weiter.

Das ist nichts für rote Worte. Dies ist eine sehr leistungsstarke Funktionalität, mit der Sie viele Dinge auf sehr einfache und elegante Weise erledigen können.

Typische Beispiele, die beim Lösen von Arrays helfen. Diese Beispiele sind einfach und klar genug:

• Suche nach Tags. Wenn Sie dort Hashtags haben und einige Beiträge nach Hashtag finden möchten.
• Suche nach Schlüssel-Wert-Paaren. Es gibt auch einige Attribute mit einem Wert.
• Speichern von Schlüssellisten, die Sie in etwas anderes übersetzen müssen.

Alle diese Aufgaben können ohne Arrays gelöst werden. Tags können in eine Zeile eingefügt und mit einem regulären Ausdruck oder in einer separaten Tabelle ausgewählt werden, aber dann müssen Sie Verknüpfungen durchführen.

Und in ClickHouse müssen Sie nichts tun, es reicht aus, das String-Array für Hashtags zu beschreiben oder eine verschachtelte Struktur für Schlüsselwertsysteme zu erstellen.

Verschachtelte Struktur ist möglicherweise nicht der beste Name. Hierbei handelt es sich um zwei Arrays, die einen gemeinsamen Namensbestandteil und einige verwandte Merkmale haben.

Und es ist sehr einfach, nach Tags zu suchen. Habe eine Funktion has, wodurch überprüft wird, ob das Array ein Element enthält. Alle haben alle Einträge gefunden, die sich auf unsere Konferenz beziehen.

Die Suche per Subid ist etwas komplizierter. Wir müssen zuerst den Index des Schlüssels finden, dann das Element mit diesem Index nehmen und prüfen, ob dieser Wert unseren Anforderungen entspricht. Es ist jedoch sehr einfach und kompakt.

Der reguläre Ausdruck, den Sie schreiben möchten, wäre, wenn Sie alles in einer Zeile halten würden, erstens umständlich. Und zweitens funktionierte es viel länger als zwei Arrays.

Ein anderes Beispiel. Sie haben ein Array, in dem Sie die ID speichern. Und Sie können sie in Namen übersetzen. Funktion arrayMap. Dies ist eine typische Lambda-Funktion. Dort übergeben Sie Lambda-Ausdrücke. Und sie ruft den Wert des Namens für jede ID aus dem Wörterbuch ab.

Die Suche kann auf die gleiche Weise erfolgen. Es wird eine Prädikatfunktion übergeben, die prüft, welche Elemente übereinstimmen.

Diese Dinge vereinfachen die Schaltung erheblich und lösen eine Reihe von Problemen.

Aber das nächste Problem, mit dem wir konfrontiert sind und das ich gerne erwähnen möchte, sind effiziente Abfragen.

• ClickHouse verfügt über keinen Abfrageplaner. Absolut nicht.
• Dennoch müssen auch komplexe Abfragen geplant werden. In welchen Fällen?
• Wenn die Abfrage mehrere Joins enthält, packen Sie sie in Unterauswahlen ein. Und die Reihenfolge, in der sie ausgeführt werden, ist wichtig.
• Und das zweite - wenn die Anfrage verteilt wird. Denn bei einer verteilten Abfrage wird nur die innerste Unterauswahl verteilt ausgeführt und alles andere wird an einen Server übergeben, mit dem Sie eine Verbindung hergestellt und dort ausgeführt haben. Wenn Sie also verteilte Abfragen mit vielen Joins (Join) haben, müssen Sie die Reihenfolge auswählen.

Und selbst in einfacheren Fällen ist es manchmal notwendig, die Arbeit des Schedulers zu übernehmen und Abfragen ein wenig umzuschreiben.

Hier ist ein Beispiel. Auf der linken Seite befindet sich eine Abfrage, die die Top-5-Länder anzeigt. Und meiner Meinung nach dauert es 2,5 Sekunden. Und auf der rechten Seite die gleiche Abfrage, jedoch leicht umgeschrieben. Anstatt nach String zu gruppieren, haben wir begonnen, nach Schlüssel (int) zu gruppieren. Und es ist schneller. Und dann haben wir ein Wörterbuch mit dem Ergebnis verknüpft. Statt 2,5 Sekunden dauert die Anfrage 1,5 Sekunden. Das ist gut.

Ein ähnliches Beispiel mit Umschreibfiltern. Hier ist eine Anfrage für Russland. Es läuft 5 Sekunden lang. Wenn wir es so umschreiben, dass wir erneut keine Zeichenfolge, sondern Zahlen mit einem Satz dieser Schlüssel vergleichen, die sich auf Russland beziehen, wird es viel schneller gehen.

Es gibt viele solcher Tricks. Und sie ermöglichen es Ihnen, Abfragen, von denen Sie glauben, dass sie bereits schnell oder umgekehrt langsam ausgeführt werden, erheblich zu beschleunigen. Sie können noch schneller gemacht werden.

• Maximale Arbeit im verteilten Modus.
• Sortieren nach Mindesttypen, wie ich es nach Ints getan habe.
• Wenn Verknüpfungen (Join) oder Wörterbücher vorhanden sind, ist es besser, diese als letzten Ausweg durchzuführen. Wenn die Daten bereits zumindest teilweise gruppiert sind, wird der Verknüpfungsvorgang oder der Wörterbuchaufruf weniger oft aufgerufen und ist schneller .
• Austausch von Filtern.

Es gibt noch andere Techniken und nicht nur die, die ich demonstriert habe. Und alle können die Ausführung von Abfragen teilweise deutlich beschleunigen.

Kommen wir zum nächsten Beispiel. Firma X aus den USA. Was macht sie?

Es gab eine Aufgabe:

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

Was ist das Szenario?

Ein gewöhnlicher Besucher kommt beispielsweise 20 Mal im Monat über verschiedene Anzeigen auf die Seite oder kommt einfach so manchmal ohne Werbung, weil er sich an diese Seite erinnert. Sieht sich einige Produkte an, legt sie in den Warenkorb und nimmt sie aus dem Warenkorb. Und am Ende kauft sich etwas.

Sinnvolle Fragen: „Wer soll ggf. Werbung bezahlen?“ und „Welche Werbung hat ihn gegebenenfalls beeinflusst?“ Das heißt, warum hat er gekauft und wie kann man Leute wie diese Person dazu bringen, auch zu kaufen?

Um dieses Problem zu lösen, müssen Sie die auf der Website auftretenden Ereignisse auf die richtige Weise verbinden, das heißt, irgendwie eine Verbindung zwischen ihnen herstellen. Anschließend werden sie zur Analyse an das DWH gesendet. Erstellen Sie auf der Grundlage dieser Analyse Modelle dafür, wer und welche Anzeigen geschaltet werden sollen.

Eine Anzeigentransaktion ist eine Reihe zusammenhängender Benutzerereignisse, die mit der Anzeige einer Anzeige beginnen, dann etwas passiert, dann vielleicht ein Kauf und dann kann es innerhalb eines Kaufs zu Käufen kommen. Wenn es sich beispielsweise um eine mobile Anwendung oder ein mobiles Spiel handelt, erfolgt die Installation der Anwendung in der Regel kostenlos, und wenn dort etwas unternommen wird, kann es sein, dass dafür Geld verlangt wird. Und je mehr jemand in die Bewerbung investiert, desto wertvoller ist sie. Aber dafür müssen Sie alles verbinden.

Es gibt viele Bindungsmodelle.

Die beliebtesten sind:

• Letzte Interaktion, wobei die Interaktion entweder ein Klick oder eine Impression ist.
• Erste Interaktion, d. h. das erste, was eine Person auf die Seite geführt hat.
• Linearkombination - alles gleich.
• Dämpfung.
• Und so weiter.

Und wie hat das überhaupt funktioniert? Es gab Runtime und Cassandra. Cassandra wurde als Transaktionsspeicher verwendet, d. h. alle zugehörigen Transaktionen wurden darin gespeichert. Und wenn zur Laufzeit ein Ereignis eintritt, zum Beispiel das Anzeigen einer Seite oder etwas anderes, dann wurde eine Anfrage an Cassandra gestellt – gibt es eine solche Person oder nicht? Dann wurden die damit verbundenen Transaktionen eingeholt. Und die Verbindung wurde hergestellt.

Und wenn man Glück hat, dass die Anfrage eine Transaktions-ID hat, dann ist es ganz einfach. Aber normalerweise kein Glück. Daher war es notwendig, die letzte Transaktion oder die Transaktion mit dem letzten Klick usw. zu finden.

Und es hat alles sehr gut funktioniert, solange die Bindung bis zum letzten Klick bestand. Denn es gibt beispielsweise 10 Millionen Klicks pro Tag, 300 Millionen pro Monat, wenn wir ein Zeitfenster für einen Monat festlegen. Und da sich in Cassandra alles im Speicher befinden muss, um schnell zu laufen, weil die Laufzeit schnell reagieren muss, waren dafür etwa 10–15 Server erforderlich.

Und als sie eine Transaktion mit der Anzeige verknüpfen wollten, stellte sich sofort heraus, dass es nicht so viel Spaß machte. Und warum? Es ist ersichtlich, dass 30-mal mehr Ereignisse gespeichert werden müssen. Und dementsprechend benötigen Sie 30-mal mehr Server. Und es stellt sich heraus, dass es sich hierbei um eine Art astronomische Figur handelt. Bis zu 500 Server für die Anbindung vorzuhalten, obwohl in der Runtime deutlich weniger Server vorhanden sind, ist eine falsche Zahl. Und sie begannen darüber nachzudenken, was sie tun sollten.

Und wir gingen zu ClickHouse. Und wie geht das auf ClickHouse? Auf den ersten Blick scheint es, dass es sich hierbei um eine Reihe von Anti-Mustern handelt.

• Die Transaktion wächst, wir verknüpfen immer mehr Ereignisse mit ihr, d. h. sie ist veränderbar, und ClickHouse funktioniert nicht sehr gut mit veränderlichen Objekten.
• Wenn ein Besucher zu uns kommt, müssen wir seine Transaktionen anhand seines Schlüssels und seiner Besuchs-ID ermitteln. Auch das ist eine Punktabfrage, das gibt es in ClickHouse nicht. Normalerweise führt ClickHouse umfangreiche Scans durch, aber hier müssen wir einige Datensätze besorgen. Auch ein Antimuster.
• Darüber hinaus war die Transaktion in JSON, aber sie wollten sie nicht neu schreiben, also wollten sie JSON unstrukturiert speichern und bei Bedarf etwas daraus extrahieren. Und das ist auch ein Antimuster.

Das heißt, eine Reihe von Antimustern.

Dennoch ist es gelungen, ein System zu schaffen, das sehr gut funktioniert.

Was getan wurde? Es erschien ClickHouse, in das Protokolle eingeworfen wurden, aufgeteilt in Datensätze. Es ist ein zugeordneter Dienst aufgetaucht, der Protokolle von ClickHouse empfangen hat. Danach erhielt ich für jeden Eintrag pro Visit-ID Transaktionen, die möglicherweise noch nicht verarbeitet wurden, und dazu noch Snapshots, also bereits verbundene Transaktionen, nämlich das Ergebnis früherer Arbeiten. Ich habe bereits eine Logik daraus gemacht, die richtige Transaktion ausgewählt und neue Ereignisse verknüpft. Erneut angemeldet. Das Protokoll ging an ClickHouse zurück, d. h. es handelt sich um ein ständig zyklisches System. Und außerdem bin ich zum DWH gegangen, um es dort zu analysieren.

In dieser Form funktionierte es nicht besonders gut. Und um es ClickHouse einfacher zu machen, gruppierten sie bei einer Anfrage nach Besuchs-ID diese Anfragen in Blöcke von 1–000 Besuchs-IDs und zogen alle Transaktionen für 2–000 Personen heraus. Und dann hat alles funktioniert.

Wenn Sie sich ClickHouse ansehen, dann gibt es nur drei Haupttabellen, die all dies bedienen.

Die erste Tabelle, in die Protokolle hochgeladen werden, und die Protokolle werden fast ohne Verarbeitung hochgeladen.

Zweiter Tisch. Durch die materialisierte Sichtweise wurden Ereignisse, die noch nicht zugeordnet wurden, d. h. Ereignisse, die nichts miteinander zu tun hatten, aus diesen Protokollen entfernt. Und durch die materialisierte Ansicht wurden Transaktionen aus diesen Protokollen abgerufen, um einen Snapshot zu erstellen. Das heißt, eine spezielle materialisierte Ansicht erstellt einen Snapshot, nämlich den letzten akkumulierten Status der Transaktion.

Hier ist der in SQL geschriebene Text. Ich möchte darin einige wichtige Dinge kommentieren.

Der erste wichtige Punkt ist die Möglichkeit, in ClickHouse Spalten und Felder aus JSON abzurufen. Das heißt, ClickHouse verfügt über einige Methoden für die Arbeit mit JSON. Sie sind sehr, sehr primitiv.

Mit visitParamExtractInt können Sie Attribute aus JSON extrahieren, d. h. der erste Treffer funktioniert. Und auf diese Weise können Sie die Transaktions-ID oder die Besuchs-ID abrufen. Diesmal.

Zweitens wird hier ein kniffliges materialisiertes Feld verwendet. Was bedeutet das? Dies bedeutet, dass Sie es nicht in die Tabelle einfügen können, d. h. es wird nicht eingefügt, sondern beim Einfügen berechnet und gespeichert. Beim Einfügen übernimmt ClickHouse die Arbeit für Sie. Und was Sie später brauchen, ist bereits aus JSON entnommen.

In diesem Fall gilt die materialisierte Ansicht für Rohzeilen. Und die erste Tabelle mit praktisch rohen Protokollen wird gerade verwendet. Und was macht er? Erstens ändert es die Sortierung, d. h. die Sortierung erfolgt jetzt nach Besuchs-ID, da wir seine Transaktion für eine bestimmte Person schnell abrufen müssen.

Die zweite wichtige Sache ist index_granularity. Wenn Sie MergeTree gesehen haben, ist die index_granularity standardmäßig 8. Was ist das? Dies ist der Parameter für die Indexsparseness. In ClickHouse ist der Index spärlich, es indiziert nie jeden Eintrag. Dies geschieht alle 192. Und das ist gut, wenn viele Daten berechnet werden müssen, aber schlecht, wenn nur wenige Daten berechnet werden müssen, weil der Overhead groß ist. Und wenn wir die Indexgranularität reduzieren, reduzieren wir den Overhead. Es kann nicht auf eins reduziert werden, da möglicherweise nicht genügend Speicher vorhanden ist. Der Index wird immer im Speicher gespeichert.

Snapshot verwendet auch einige andere interessante ClickHouse-Funktionen.

Erstens ist es AggregatingMergeTree. Und AggregatingMergeTree speichert argMax, d. h. dies ist der Status der Transaktion, der dem letzten Zeitstempel entspricht. Für einen bestimmten Besucher werden ständig Transaktionen generiert. Und im allerletzten Zustand dieser Transaktion haben wir ein Ereignis hinzugefügt und wir haben einen neuen Zustand. Es traf erneut ClickHouse. Und über argMax können wir in dieser materialisierten Ansicht immer den aktuellen Status abrufen.

• Die Anbindung ist von der Runtime „entkoppelt“.
• Bis zu 3 Milliarden Transaktionen pro Monat werden gespeichert und verarbeitet. Das ist eine Größenordnung mehr als in Cassandra, also in einem typischen Transaktionssystem.
• Cluster aus 2x5 ClickHouse-Servern. 5 Server und jeder Server verfügt über eine Replik. Dies ist sogar weniger als bei Cassandra, um eine klickbasierte Attribution durchzuführen, und hier haben wir eine auf Impressionen basierende Attribution. Das heißt, anstatt die Anzahl der Server um das 30-fache zu erhöhen, gelang es ihnen, sie zu reduzieren.

Und das letzte Beispiel ist das Finanzunternehmen Y, das die Korrelationen von Aktienkursänderungen analysiert hat.

Und die Aufgabe war:

• Es gibt etwa 5 Aktien.
• Bekannt sind Quotes alle 100 Millisekunden.
• Die Daten wurden über einen Zeitraum von 10 Jahren gesammelt. Offenbar bei manchen Unternehmen mehr, bei manchen weniger.
• Insgesamt gibt es etwa 100 Milliarden Zeilen.

Und es war notwendig, die Korrelation der Änderungen zu berechnen.

Hier sind zwei Aktien und ihre Kurse. Wenn einer steigt und der andere steigt, dann handelt es sich um einen positiven Zusammenhang, d. h. der eine steigt und der andere steigt. Wenn einer steigt, wie am Ende der Grafik, und der andere sinkt, dann handelt es sich um einen negativen Zusammenhang, d. h. wenn einer steigt, fällt der andere.

Durch die Analyse dieser gegenseitigen Veränderungen lassen sich Prognosen für den Finanzmarkt treffen.

Aber die Aufgabe ist schwierig. Was wird dafür getan? Wir haben 100 Milliarden Datensätze mit: Zeit, Bestand und Preis. Wir müssen zunächst das 100-Milliarden-fache der laufenden Differenz aus dem Preisalgorithmus berechnen. RunningDifference ist eine Funktion in ClickHouse, die nacheinander die Differenz zwischen zwei Zeichenfolgen berechnet.

Anschließend müssen Sie die Korrelation berechnen, und zwar für jedes Paar. Für 5 Aktien ergeben sich Paare von 000 Millionen. Und das ist eine Menge, nämlich das 12,5-fache, um eine solche Korrelationsfunktion zu berechnen.

Und wenn jemand es vergessen hat, dann sind ͞x und ͞y ein Schachmatt. Stichprobenerwartung. Das heißt, es müssen nicht nur die Wurzeln und Summen berechnet werden, sondern auch eine weitere Summe innerhalb dieser Summen. Eine Reihe von Berechnungen müssen 12,5 Millionen Mal durchgeführt und sogar nach Stunden gruppiert werden. Wir haben auch viele Stunden. Und Sie müssen es in 60 Sekunden schaffen. Das ist ein Witz.

Es war notwendig, zumindest irgendwie Zeit zu haben, denn das alles funktionierte sehr, sehr langsam, bevor ClickHouse kam.

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

Und dann kam ClickHouse und die Dinge wurden viel besser.

Ich erinnere Sie daran, dass wir ein Problem mit der Datenlokalität haben, weil Korrelationen nicht lokalisiert werden können. Wir können nicht einige der Daten auf einem Server, andere auf einem anderen ablegen und berechnen, wir müssen alle Daten überall haben.

Was haben Sie gemacht? Zunächst werden die Daten lokalisiert. Jeder Server speichert Daten über den Preis einer bestimmten Aktiengruppe. Und sie überschneiden sich nicht. Daher ist es möglich, logReturn parallel und unabhängig zu berechnen, alles geschieht bisher parallel und verteilt.

Dann haben wir beschlossen, diese Daten zu reduzieren, ohne dabei an Aussagekraft zu verlieren. Reduzieren Sie die Verwendung von Arrays, d. h. erstellen Sie für jeden Zeitraum ein Array von Beständen und ein Array von Preisen. Daher nimmt es viel weniger Datenraum ein. Und es ist etwas einfacher, mit ihnen zu arbeiten. Dabei handelt es sich um nahezu parallele Vorgänge, d.h. wir lesen teilweise parallel und schreiben dann auf den Server.

Danach kann es repliziert werden. Der Buchstabe „r“ bedeutet, dass wir diese Daten repliziert haben. Das heißt, wir haben auf allen drei Servern die gleichen Daten – das sind die Arrays.

Und dann können Sie mit einem speziellen Skript aus diesem Satz von 12,5 Millionen Korrelationen, die berechnet werden müssen, Pakete erstellen. Das sind 2 Aufgaben mit 500 Korrelationspaaren. Und diese Aufgabe soll auf einem bestimmten ClickHouse-Server berechnet werden. Er hat alle Daten, weil die Daten gleich sind und er sie nacheinander berechnen kann.

Wieder einmal sieht es so aus. Zunächst haben wir alle Daten in dieser Struktur: Zeit, Anteile, Preis. Dann haben wir logReturn berechnet, also Daten gleicher Struktur, aber anstelle des Preises haben wir bereits logReturn. Dann wurden sie erneuert, d. h. wir bekamen das Zeit- und Gruppenarray für Bestände und Preise. Neu repliziert. Und danach haben wir eine Reihe von Aufgaben generiert und sie an ClickHouse weitergeleitet, damit es sie zählen kann. Und es funktioniert.

Beim Proof of Concept handelte es sich bei der Aufgabe um eine Unteraufgabe, d. h. es wurden weniger Daten erfasst. Und nur drei Server.

Die ersten beiden Phasen: Berechnen von Log_return und Einschließen in Arrays dauerten etwa eine Stunde.

Und die Berechnung der Korrelation beträgt etwa 50 Stunden. Aber 50 Stunden reichen nicht aus, denn früher wurde wochenlang gearbeitet. Es war ein großer Erfolg. Und wenn man zählt, dann wurde in diesem Cluster 70 Mal pro Sekunde alles gezählt.

Aber das Wichtigste ist, dass dieses System praktisch ohne Engpässe ist, also nahezu linear skaliert. Und sie haben es überprüft. Es wurde erfolgreich vergrößert.

• Das richtige Schema ist die halbe Miete. Und das richtige Schema ist der Einsatz aller notwendigen ClickHouse-Technologien.
• Summing/AggregatingMergeTrees sind Technologien, die es Ihnen ermöglichen, einen Zustands-Snapshot zu aggregieren oder als Sonderfall zu betrachten. Und es vereinfacht viele Dinge enorm.
• Mit materialisierten Ansichten können Sie die Beschränkung auf einen Index umgehen. Vielleicht habe ich es nicht sehr deutlich gesagt, aber als wir die Protokolle geladen haben, waren die Rohprotokolle mit einem Index in der Tabelle und die Attributprotokolle waren in der Tabelle, d. h. dieselben Daten, nur gefiltert, aber der Index war vollständig Andere. Es scheinen die gleichen Daten zu sein, aber unterschiedliche Sortierung. Und mit Materialized Views können Sie bei Bedarf eine solche ClickHouse-Einschränkung umgehen.
• Reduzieren Sie die Indexgranularität für Punktabfragen.
• Und verteilen Sie die Daten intelligent und versuchen Sie, die Daten so weit wie möglich auf dem Server zu lokalisieren. Und versuchen Sie sicherzustellen, dass bei Anfragen möglichst auch die Lokalisierung zum Einsatz kommt.

Und zusammenfassend können wir diese kurze Rede zusammenfassen: ClickHouse hat mittlerweile sowohl das Gebiet der kommerziellen Datenbanken als auch der Open-Source-Datenbanken, also speziell für die Analyse, fest besetzt. Er passt perfekt in diese Landschaft. Und außerdem beginnt es langsam, andere zu verdrängen, denn wenn Sie ClickHouse haben, brauchen Sie InfiniDB nicht. Vertika wird möglicherweise nicht bald benötigt, wenn sie normale SQL-Unterstützung bieten. Genießen!

-Danke für den Bericht! Sehr interessant! Gab es Vergleiche mit Apache Phoenix?

Nein, ich habe noch niemanden vergleichen hören. Wir und Yandex versuchen, alle ClickHouse-Vergleiche mit verschiedenen Datenbanken im Auge zu behalten. Denn wenn sich plötzlich herausstellt, dass etwas schneller ist als ClickHouse, kann Lesha Milovidov nachts nicht schlafen und beginnt, es schnell zu beschleunigen. Von einem solchen Vergleich habe ich noch nichts gehört.

• (Aleksey Milovidov) Apache Phoenix ist eine SQL-Engine, die von Hbase unterstützt wird. Hbase dient hauptsächlich für Schlüsselwert-Arbeitsszenarien. Dabei kann es in jeder Zeile beliebig viele Spalten mit beliebigen Namen geben. Dies gilt für Systeme wie Hbase und Cassandra. Und es sind gerade schwere analytische Abfragen, die für sie nicht normal funktionieren. Oder Sie denken vielleicht, dass sie gut funktionieren, wenn Sie noch keine Erfahrung mit ClickHouse haben.

• Danke

  • Guten Tag! Ich interessiere mich bereits sehr für dieses Thema, da ich über ein analytisches Subsystem verfüge. Aber wenn ich mir ClickHouse ansehe, habe ich das Gefühl, dass ClickHouse sehr gut für die Ereignisanalyse geeignet ist, veränderbar. Und wenn ich viele Geschäftsdaten mit vielen großen Tabellen analysieren muss, ist ClickHouse meines Wissens nicht sehr geeignet für mich? Vor allem, wenn sie sich ändern. Ist das richtig oder gibt es Beispiele, die dies widerlegen können?

  • Das ist richtig. Und das gilt für die meisten spezialisierten analytischen Datenbanken. Sie sind auf die Tatsache zugeschnitten, dass es eine oder mehrere große Tabellen gibt, die veränderbar sind, und auf viele kleine, die sich langsam ändern. Das heißt, ClickHouse ist nicht wie Oracle, wo Sie alles ablegen und einige sehr komplexe Abfragen erstellen können. Um ClickHouse effektiv nutzen zu können, müssen Sie ein Schema erstellen, das in ClickHouse gut funktioniert. Das heißt, vermeiden Sie übermäßige Normalisierung, verwenden Sie Wörterbücher und versuchen Sie, weniger lange Links zu erstellen. Und wenn das Schema auf diese Weise aufgebaut ist, können ähnliche Geschäftsaufgaben mit ClickHouse viel effizienter gelöst werden als mit einer herkömmlichen relationalen Datenbank.

Danke für den Bericht! Ich habe eine Frage zum neuesten Finanzfall. Sie hatten Analysen. Es war notwendig zu vergleichen, wie sie auf und ab gehen. Und ich verstehe, dass Sie das System speziell für diese Analyse entwickelt haben? Wenn sie morgen beispielsweise einen anderen Bericht zu diesen Daten benötigen, müssen sie dann das Schema neu erstellen und die Daten hochladen? Das heißt, eine Art Vorverarbeitung durchzuführen, um die Anfrage zu erhalten?

Dabei handelt es sich natürlich um den Einsatz von ClickHouse für eine ganz bestimmte Aufgabe. Es könnte auf traditionellere Weise innerhalb von Hadoop gelöst werden. Für Hadoop ist dies eine ideale Aufgabe. Aber auf Hadoop ist es sehr langsam. Und mein Ziel ist es zu zeigen, dass ClickHouse Aufgaben lösen kann, die normalerweise mit ganz anderen Mitteln gelöst werden, aber gleichzeitig viel effizienter. Dies ist auf eine bestimmte Aufgabe zugeschnitten. Es ist klar, dass, wenn es ein Problem mit etwas Ähnlichem gibt, es auf ähnliche Weise gelöst werden kann.

Es ist klar. Sie sagten, dass 50 Stunden bearbeitet wurden. Ist es von Anfang an, wann haben Sie die Daten geladen oder die Ergebnisse erhalten?

Ja Ja.

Okay, vielen Dank.

Dies ist auf einem 3-Server-Cluster.

Grüße! Danke für den Bericht! Alles ist sehr interessant. Ich werde nicht ein wenig nach der Funktionalität fragen, sondern nach der Verwendung von ClickHouse im Hinblick auf die Stabilität. Das heißt, hatten Sie welche, mussten Sie sie wiederherstellen? Wie verhält sich ClickHouse in diesem Fall? Und kam es vor, dass Sie auch eine Replik hatten? Wir sind beispielsweise auf ein Problem mit ClickHouse gestoßen, als es immer noch seine Grenzen überschreitet und abstürzt.

Natürlich gibt es keine idealen Systeme. Und ClickHouse hat auch seine eigenen Probleme. Aber haben Sie schon davon gehört, dass Yandex.Metrica schon lange nicht mehr funktioniert? Wahrscheinlich nicht. Es funktioniert seit 2012-2013 zuverlässig auf ClickHouse. Das Gleiche kann ich über meine Erfahrung sagen. Wir hatten noch nie Totalausfälle. Es konnten zwar teilweise Vorkommnisse eintreten, diese waren jedoch nie kritisch genug, um das Geschäft ernsthaft zu beeinträchtigen. Es ist nie passiert. ClickHouse ist recht zuverlässig und stürzt nicht zufällig ab. Sie müssen sich darüber keine Sorgen machen. Es ist keine rohe Sache. Das haben viele Unternehmen bewiesen.

Guten Tag! Sie sagten, dass Sie sofort über das Datenschema nachdenken müssen. Was wäre, wenn es passiert wäre? Meine Daten strömen und strömen. Es vergehen sechs Monate und mir ist klar, dass es unmöglich ist, so zu leben. Ich muss die Daten erneut 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. Sie können beispielsweise eine materialisierte Ansicht erstellen, in der Sie eine andere Datenstruktur erstellen können, wenn diese eindeutig zugeordnet werden kann. Das heißt, wenn es die Zuordnung mit ClickHouse ermöglicht, d. h. einige Dinge extrahieren, den Primärschlüssel ändern, die Partitionierung ändern, dann können Sie eine materialisierte Ansicht erstellen. Überschreiben Sie dort Ihre alten Daten, neue werden automatisch geschrieben. Und dann wechseln Sie einfach zur Verwendung der materialisierten Ansicht, wechseln dann den Datensatz und löschen die alte Tabelle. Dies ist im Allgemeinen eine Non-Stop-Methode.

Vielen Dank.

Source: habr.com