Mit ClickHouse die Kosten für BigQuery und Looker senken – Teil 1

Dies ist eine mehrteilige Serie zum Thema, gegliedert in die logischen Schritte, die für die Einrichtung dieses Prozesses nötig sind. Da das Ökosystem und die Technologie komplex sind und es entsprechend viele "Wenn-dann-sonst"-Bedingungen gibt, habe ich den Artikel aufgeteilt: Jeder Aspekt bekommt seinen eigenen Teil, damit nichts überfrachtet wird. Der erste Teil widmet sich überwiegend der Theorie, der zweite Teil konzentriert sich anschließend auf eine grundlegende Implementierung.

Vorab für alle, die ClickHouse noch nicht kennen: Es handelt sich um ein Data Warehouse, das BigQuery Konkurrenz macht. Sein Aushängeschild ist ein extrem performanter Datenspeicher, der Operationen deutlich schneller ausführt als andere Data Warehouses am Markt. Damit eignet er sich ideal, um Daten für workloads bereitzustellen, die ihn permanent abfragen – etwa BI-Tools wie Looker.

Dieser Artikel entstand mit technischer Unterstützung unseres Partners Aiven, dem führenden Anbieter von DBaaS-Lösungen, der unter anderem einen Managed-ClickHouse-Service betreibt. Der Vollständigkeit halber fließen auch Informationen von ClickHouse selbst ein, die einen eigenen Managed Service anbieten.

BigQuery ist eine hervorragende Plattform für umfangreiche Analysen oder ML-workloads und wird häufig an BI-Tools wie Looker zur Visualisierung oder zum Reporting angebunden. Bei dieser Art von Aufgaben kommt es allerdings oft zu Performance-Problemen aufgrund von Ressourcenbeschränkungen oder kostenbedingten Limits. Hinzu kommt der berühmte Elefant im Raum: die Kosten pro Abfrage, die BigQuery in Rechnung stellt.

Nach den jüngsten Preiserhöhungen pro Abfrage ist BigQuery zudem teurer geworden – besonders in Verbindung mit einem Tool, das ständig Daten abfragt. Deshalb suchen viele Kunden nach Möglichkeiten, ihre workload-Kosten zu senken, und stellen genau das fest, was die Customer Reliability Engineers von DoiT International seit Jahren predigen: BI-Tools gehören zu den größten Kostentreibern in BigQuery – wenn nicht sogar zum größten – und sind eines der lohnendsten Ziele für Kostenoptimierung.

Bei Google Next 2023 habe ich in meiner Präsentation (die Aufzeichnung wurde leider entfernt, die Folien sind aber weiterhin verfügbar) ein Konzept zur Kostenoptimierung vorgestellt, das zahlreiche unserer Kunden mit großem Erfolg umgesetzt haben: bestimmte teure workloads – insbesondere rechenintensive – von BigQuery auf andere Tools zu migrieren, die günstiger und besser für den jeweiligen Zweck geeignet sind.

Genau daran knüpft dieser Artikel an: Ich schlage eine alternative Methode der Datenbereitstellung vor und nutze das ClickHouse-Data-Warehouse als "Caching- und Bereitstellungsschicht" zwischen BigQuery und BI-Tools wie Looker. So lassen sich Reporting- und Visualisierungs-workloads von BigQuery auf eine günstigere und performantere Plattform verlagern.

Wichtiger Hinweis: Ich verwende hier exemplarisch ClickHouse, das Ganze ließe sich aber genauso gut mit anderen Tools und Datenbanken umsetzen. ClickHouse bietet sich an, weil es Daten erstaunlich schnell an Visualisierungstools liefert und mir dieser Anwendungsfall häufig genug begegnet, um diesen Artikel zu rechtfertigen.

In letzter Zeit sind Ihnen auf LinkedIn oder anderen Seiten womöglich etliche Anzeigen aufgefallen, in denen ClickHouse als günstiger oder schneller als BigQuery angepriesen wird. Die klugen Köpfe hinter dieser Werbekampagne setzen genau auf die Grundpfeiler des Konzepts, das ich in diesem Artikel vorstelle. Unsere Datenarchitekten bei DoiT International haben in großem Maßstab beobachtet, wie sich die Preisänderungen auf einen erheblichen Teil der GCP-Kunden auswirken, und kreative Wege gefunden, ihnen beim Sparen zu helfen.

ClickHouse ist ein Data Warehouse, das BigQuery in gewisser Weise ähnelt, sich aber durch einige zentrale architektonische Unterschiede abhebt. ClickHouse setzt auf eine eher monolithische Architektur, die sich um benutzerdefinierte "Module" dreht, mit denen sich die Performance massiv steigern lässt. Dank dieser modularen Infrastruktur kann es bei vielen Aufgaben deutlich performanter sein als BigQuery oder andere Data-Warehousing-Lösungen am Markt.

Dieses Zitat von PostHog bringt es treffend auf den Punkt:

"Der Performance-Unterschied zwischen BigQuery und ClickHouse kann gewaltig sein. BigQuery braucht für eine Abfrage mitunter Dutzende Sekunden. ClickHouse kann dieselbe Abfrage – richtig optimiert – auf Terabytes an Daten in unter einer Sekunde ausführen."

"Elementar, mein lieber Watson – wegen der Kostenersparnis" – Sherlock Holmes (mit modernem Cloud-Twist)

Die Antwort lautet: Kostenersparnis! Realistischer formuliert: potenzielle Kostenersparnis.

Sie ergibt sich daraus, dass Sie ein Data Warehouse abfragen, das nicht pro Abfrage abrechnet, sondern eine Pauschale verlangt – Sie können also so viel abfragen, wie es die Ressourcen zulassen, ohne nutzungsabhängig zu zahlen.

In diesem Artikel beziehe ich mich beim Pricing auf das Managed-ClickHouse-Angebot von Aiven. Mit diesem Service habe ich die hier beschriebenen Schritte getestet, und Aiven macht es sehr einfach, ClickHouse und seine weiteren Angebote an Ihre GCP-Umgebung anzubinden.

Die Business-Pläne von Aiven beginnen bei rund 500 USD/Monat für die Startup-Stufe und rund 2.000 USD/Monat für die Business-Stufe – das sind die Preisniveaus, an denen wir uns orientieren, um zu beurteilen, ob sich der Ansatz für Ihre Umgebung lohnt.

Damit diese Lösung aus Kostensicht sinnvoll ist, gibt es einige Break-even-Punkte zu beachten.

Hinweis: Wenn Sie weniger als 500 USD/Monat für BigQuery oder Ihr Visualisierungstool ausgeben, ist die Wahrscheinlichkeit hoch, dass Ihnen das keine Kostensenkung bringt. Andererseits stehen die Chancen sehr gut, dass Sie deutliche Performance-Verbesserungen erzielen.

Bezogen auf die Preispunkte 500 und 2.000 USD von Aiven entspricht das 1 TiB bzw. 321 TiB (320 TiB + 1 TiB Free Tier) verarbeiteter Daten pro Monat im On-Demand-Preismodell von BigQuery. Sie können diese Abfrage [1] auch gegen das Projekt laufen lassen, in dem die Jobs Ihres BI-Tools ausgeführt werden.

Zum Vergleich: ClickHouse bietet Pläne mit Autoscaling-Komponente und etwas größeren Instanzen zu sehr vergleichbaren Preisen. Je nach Dimensionierung sowie Entwicklungs- und Produktionsanforderungen können sie eine günstigere Alternative sein.

Für BigQuery Editions gibt es keinen klaren Wert für den Break-even, weil Editions einen Autoscaler nutzt – im Grunde eine gleitende Preisskala. Am einfachsten lassen sich die ungefähren Looker-Kosten ermitteln, indem Sie die oben verlinkte Abfrage [1] in dem Projekt ausführen, das Looker abfragt.

Hinweis zu dieser Abfrage:

Unter Umständen müssen Sie den Regex anpassen oder vollständig durch den Namen Ihres Looker-Servicekontos ersetzen, um genaue Kosten zu erhalten – insbesondere, wenn Sie ein nicht standardmäßiges Looker-Servicekonto oder mehrere davon verwenden.

Sobald Sie diesen Wert berechnet haben, können Sie feststellen, ob er über oder unter den oben genannten Schwellen von 500 und 2.000 USD liegt. Falls Performance ein Thema ist, können die Mehrkosten zudem die Investition wert sein – damit Sie nicht 20 Sekunden warten müssen, bis ein Looker-Dashboard Echtzeitdaten anzeigt.

Der Plan: Daten zwischen BigQuery und ClickHouse "replizieren" und anschließend alle abfrageintensiven BI-Tools – oder andere abfrageintensive Tools – an ClickHouse anbinden. Dadurch entfallen theoretisch die Kosten pro Abfrage in BigQuery, und Ihre Kosten sinken deutlich, da Sie für die Abfragen nun ein Asset zum Festpreis nutzen.

Genauso lässt sich der Ansatz einsetzen, wenn Sie Echtzeit- oder deutlich schnellere Abfragen benötigen. Denn ClickHouse kann – richtig getunt – eine WESENTLICH performantere Query-Engine sein.

Wenn etwas das Potenzial hat, Ihnen viel Geld zu sparen, gibt es immer ein paar erste Schritte – und dieser Prozess bildet keine Ausnahme.

Zunächst gilt es zu ermitteln, wie viele Daten Ihr BI-Tool aus BigQuery zieht und welche Tabellen es nutzt. Das ist eine sehr allgemeine Aussage, und die Frage lässt sich in BigQuery nicht trivial beantworten – aber wie schon in der Vergangenheit stelle ich Ihnen eine Abfrage zur Verfügung, die dabei hilft [2]. Hinweis: Diese Abfrage kann unter Umständen viel Geld kosten – prüfen Sie daher unbedingt die Schätzung in der BQ-UI, bevor Sie sie ausführen.

Der zweite Punkt ist der detailliertere von beiden: eine Bestandsaufnahme Ihres Ingestion-Prozesses. Sie müssen verstehen, wie er funktioniert, und sich ansehen, wie Daten derzeit in BigQuery aufgenommen werden. Der Grund: Wir werden diesen Prozess so anpassen, dass die Daten zwischen BigQuery und der neu erstellten ClickHouse-Instanz "aufgeteilt" und an beide Systeme propagiert werden.

Zum Abschluss dieses ersten Teils möchte ich noch eine Orientierungshilfe zur Dimensionierung und Erstellung der ClickHouse-Instanz geben, die wir im weiteren Verlauf der Serie verwenden werden.

Nach zahlreichen Migrationen von BigQuery zu anderen Datenbanksystemen werde ich oft gefragt, wie man die richtige Größe für das Zielsystem wählt. Die ernüchternde Antwort: Es gibt keine wirklich kugelsichere Methode dafür.

Ich habe analysiert, welche Daten BigQuery in Abfragen zieht, mir das Volumen der Cache-Treffer und die Slot-Nutzung angesehen – aber die Wahrheit ist: BigQuery unterscheidet sich derart von den meisten anderen Datenbanken, dass sich kein echter Eins-zu-eins-Vergleich anstellen lässt. Bei diesen Übungen habe ich festgestellt, dass es prinzipiell möglich wäre, BigQuery aber bestimmte erforderliche Metriken nicht ausgibt – etwa eindeutig abgefragte Daten oder die von Slots genutzte CPU/Memory.

Trotzdem haben mir diese Übungen eines gezeigt: Starten Sie immer mit mindestens 8 GB RAM, wenn Sie regelmäßig grundlegende Abfragen gegen die Datenbank fahren. Wenn Sie eine echte Produktions-Visualisierungsdatenbank mit mehr als 10 Nutzern betreiben, die tagsüber rechenintensive Abfragen ausführen, sind 16 GB das Minimum. Mit zunehmender Komplexität der Abfragen lohnt es sich, mehr CPUs hinzuzufügen – aber eine Maschine mit zwei CPUs ist unabhängig vom workload ein guter Ausgangspunkt, da Memory bei den meisten Abfrageszenarien weit wichtiger ist als CPU.

Ausgehend davon würde ich einen Proof of Concept mit einer sehr kleinen Instanz starten – etwa der Hobbyist-Stufe von Aiven oder der Development-Instanz von ClickHouse –, alles zum Laufen bringen und dann nach Bedarf per Right-Sizing nach oben skalieren.

Statt hier einen vollständigen Walkthrough zu liefern, der bei jeder UI-Änderung unweigerlich veraltet, verlinke ich direkt auf die Aiven-Dokumentation.

Im ersten Schritt erstellen Sie ein Aiven-Konto, wie hier beschrieben.

Im zweiten Schritt legen Sie eine Aiven-VPC an (siehe hier) und peeren sie mit Ihrer GCP-VPC (siehe hier).

Als Nächstes erstellen Sie den ClickHouse-Service (siehe hier). Das kann ein paar Minuten dauern – holen Sie sich also in der Zwischenzeit einen Kaffee oder Tee.

Verifizieren Sie das Ganze entweder mit dem Docker-Container oder dem CLI-Tool innerhalb Ihrer gepeerten VPC – dann kann es losgehen.

Wie zuvor verlinke ich nur auf die Anbieterdokumentation, da alles, was ich hier schreibe, irgendwann veraltet sein wird.

Hier finden Sie den Quickstart-Guide des Anbieters zum Erstellen einer Instanz.

Ich empfehle, GCP Private Service Connect zu Ihrer ClickHouse-Instanz einzurichten, wie hier beschrieben. Das gewährleistet höchste Sicherheit bei minimalem Konfigurationsaufwand für die Nutzung Ihrer Instanz.

Dieser Teil war eine grundlegende Einführung in unser Vorhaben. Im nächsten Abschnitt zeige ich Ihnen, wie Sie Ihre Daten in ClickHouse bringen und die Replikation zwischen ClickHouse und BigQuery einrichten.