Große Pläne: warum sich Ricardo für Bigtable als Ergänzung zu BigQuery entschied

Mit über 3,7 Millionen Mitgliedern ist Ricardo der größte Online-Marktplatz der Schweiz. 2019 haben wir unsere lokalen Arbeitslasten erfolgreich zu Google Cloud migriert – ein Schritt, mit dem auch die Herausforderungen einiger neuer Anwendungsfälle auf uns zukamen. Da unser lokales Rechenzentrum bereits nicht mehr verfügbar war, standen wir bei der Suche einer Lösung für diese Anwendungsfälle unter Zeitdruck. Unser Schwerpunkt lag dabei in erster Linie auf der Verarbeitung von Datenstreams. Die von uns gewählte Lösung umfasst sowohl Cloud Bigtable als auch Dataflow von Google Cloud. Im Folgenden werfen wir einen Blick darauf, warum wir uns für diese Lösung entschieden und wie wir sie umgesetzt haben. Außerdem betrachten wir zukünftige Anwendungsfälle in unserer Roadmap. 

Die Herausforderungen im Detail 

Für Analysen hatten wir ursprünglich das Microsoft SQL Data Warehouse verwendet und uns dann für einen Wechsel zu BigQuery entschieden, dem Enterprise Data Warehouse von Google Cloud. Das zog auch die Verlagerung all unserer Workloads dorthin nach sich. Für die Importe und Batch-Loads von Kafka in BigQuery setzten wir Apache Beam ein.

Wir wollten unseren internen Teams die Möglichkeit geben, über unser Informationsportal Aufgaben zur Betrugserkennung durchzuführen. Auf diese Weise können unsere Kundinnen und Kunden besser vor betrügerischen Warenangeboten und Personen geschützt werden, die gestohlene Identitäten verwenden. 

Außerdem mussten sich unsere Entwicklerinnen und Entwickler zügig mit der Frage befassen, wie wir unsere beiden Hauptdatenstreams zusammenführen können, da diese bisher in getrennten Systemen gespeichert waren. Der eine ist für Artikel, also im Wesentlichen für die Verkaufsangebote auf unserer Plattform. Der andere ist für Assets, die verschiedene Beschreibungen zu den Artikeln enthalten. Zunächst haben wir die Datenstreams in BigQuery eingefügt und dann einen JOIN durchgeführt. Eine der Herausforderungen liegt darin, dass Ricardo schon ziemlich lange besteht. So kann es vorkommen, dass ein Artikel seit 2006 nicht mehr gespeichert wurde oder neu gelistet wird, wodurch eventuell Daten im Asset-Stream fehlen.

Ein Problem, mehrere Lösungswege

Bei der Suche nach Lösungen für unsere Problematik mit den Datenstreams stieß ich auf einen Beitrag im Google Cloud Blog mit einer Anleitung für gängige Anwendungsmuster in Dataflow (dem einheitlichen Stream- und Batch-Verarbeitungsdienst von Google Cloud) und einem Abschnitt zu großen Suchtabellen im Streamingmodus. Zusätzlich zu unserem Artikel-Stream verfügen wir über eine etwa 400 GB große Suchtabelle mit Assets. Wir mussten aber auch in der Lage sein, das entsprechende Asset für einen Artikel nachzuschlagen. Laut Anleitung könnte ein spaltenorientiertes System diese Art von Abfrage in Millisekunden beantworten. Außerdem ließe es sich in einer Dataflow-Pipeline für Suchabfragen und zum Aktualisieren der Tabelle verwenden. 

Wir hatten demnach zwei Optionen, um den Anwendungsfall zu lösen. Einen Versuch starteten wir mit einem Prototyp auf Basis von Apache Cassandra, der quelloffenen spaltenorientierten NoSQL-Datenbank. Hierbei sollte von BigQuery aus mit Apache Beam gestreamt werden, um Verlaufsdaten vorab zu laden.

Wir erstellten einen neuen Cassandra-Cluster auf Google Kubernetes Engine (GKE) und verwendeten dabei den von Datastax als Open Source veröffentlichten CASS Operator. Anschließend bauten wir eine Indexstruktur auf, optimierten das Ganze, führten einige Benchmarks durch und stellten erfreut fest, dass alles funktionierte. Damit besaßen wir nun also einen funktionsfähigen Cassandra-Cluster – die Pipeline nahm Assets und Artikel auf, und die Assets wurden aus dem Cassandra-Speicher abgerufen, wo sie auch gespeichert waren. 

Was aber war mit den alltäglichen Aufgaben und Herausforderungen des Betriebs? Unser Data-Intelligence-Team (DI) beispielsweise muss völlig autark sein. Wir sind ein kleines Unternehmen. Daher müssen wir schnell handeln und möchten kein System aufbauen, das schon bald wieder veraltet ist. 

Die verwalteten Dienste von BigQuery nutzten wir bereits und waren auch sehr zufrieden mit ihnen. Es war daher naheliegend, den vollständig verwalteten, spaltenorientierten NoSQL-Datenbankdienst Bigtable mit niedriger Latenz zu nutzen. 

13-prozentige Netto-Kostenersparnis mit Bigtable

Was die laufenden Kosten betrifft, konnte Cassandra mit Bigtable jedoch nicht ganz mithalten. Wir stellten fest, dass Cassandra für die Verfügbarkeitsgarantien drei Knoten benötigt. Mit Bigtable hingegen konnten wir eine fehlertolerante Datenpipeline beziehungsweise Apache Beam-Pipeline einsetzen, die auf Apache Flink läuft. Selbst bei geringer Verfügbarkeit bestand Fehlertoleranz, sodass wir keine drei Knoten betreiben mussten. Für die Aufnahme der Verlaufsdaten aus BigQuery in die Suchtabelle in Bigtable verwendeten wir 18 Knoten. Nach der Übertragung konnten wir diese dann problemlos auf einen oder zwei Knoten herunterskalieren, da jeder von ihnen bis zu 10.000 Zeilen pro Sekunde einlesen kann. Bigtable kümmert sich im Hintergrund um Verfügbarkeit und Stabilität und kann daher sogar mit nur einem Knoten eine garantierte Leistung bieten.

Diese Tatsache hat ganz deutlich werden lassen, dass die Bigtable-Lösung nicht nur einfacher zu verwalten ist als Cassandra, sondern auch kostengünstiger. Wenn wir als kleines Team die laufenden Schulungskosten, die Ausfallzeiten und den für die Cassandra-on-GKE-Lösung erforderlichen technischen Support einkalkulieren, war es schon allein deshalb naheliegender, für den Anfang 1 TB in einer Bigtable-Instanz statt in der Cassandra-on-GKE-Lösung zu verwenden, für die ein dreifacher E2-Knoten-Cluster erforderlich ist - auch wenn die einzelnen Knoten mit einer 8-CPU-VM ziemlich klein sind. Bigtable war die einfachere, schnellere und kostengünstigere Lösung. Durch die Verlagerung solcher Suchabfragen auf Bigtable konnten wir letztendlich 13 % der BigQuery-Kosten einsparen. (Bitte beachten Sie, dass es sich hierbei um Nettoeinsparungen handelt – die zusätzlichen Kosten für den Betrieb von Bigtable sind also bereits eingerechnet).

Nachdem diese neue Lösung erst einmal angelaufen war, verlagerten wir eine weitere Arbeitslast zu Bigtable: die Einbindung von Daten aus Zendesk-Tickets für unser Serviceteam. Wir haben Informationen von Kundinnen und Kunden in Bigtable verfügbar gemacht und die Produktschlüsselsuche mit den Zendesk-Daten verknüpft, damit den betreuenden Mitarbeiter:innen die Informationen unserer Kund:innen sofort angezeigt werden konnten.

Vorteile der nahtlosen Einbindung von Google Cloud-Tools  

Für ein kleines Unternehmen wie wir es sind, hat der Aufbau einer leicht zugänglichen Dateninfrastruktur eine hohe Priorität. Für uns ist Bigtable unser Speicher, in dem verarbeitete Daten für unsere Dienste zur Verwendung bereitstehen. Die Einbindung der Dienste in Bigtable, BigQuery und Dataflow macht es für uns so einfach, diese Daten verfügbar zu halten. 

Ein weiterer Grund, der für die Google Cloud Platform spricht, ist aus unserer Sicht das Tempo, mit dem wir Anpassungen an Dataflow und BigQuery vornehmen können. Als ich zum Beispiel eines Morgens über ein laufendes Projekt nachdachte, wurde mir klar, dass wir die Artikel-ID hätten umkehren sollen. Sie sollte besser in umgekehrter Reihenfolge gespeichert werden, um ein Heißlaufen zu verhindern. Dafür konnten wir mühelos und schnell auf 20 Bigtable-Knoten und 50 Dataflow-Worker hochskalieren. Die Batch-Jobs lasen die Daten aus BigQuery aus und schrieben sie mit Bigtable in das neu erstellte Schema. Das Ganze hat gerade einmal 25 Minuten gedauert. Vor dem Umstieg auf Bigtable hätte uns eine solche Anpassung mehrere Tage gekostet.

Key Visualizer von Bigtable eröffnet neue Möglichkeiten

Die Idee zum Umkehren der Artikel-ID kam mir beim Nachdenken über den Key Visualizer von Bigtable, der im Vergleich zu unserem vorherigen Setup sehr übersichtlich gestaltet und einfach zu bedienen ist. Die Einbindung ist absolut nahtlos und einfach zu erklären.

Wir verwenden SSD-Knoten und müssen uns bei der Konfiguration nur um die Anzahl der Knoten kümmern und darum, ob wir eine Replikation wollen oder nicht. Das ist so einfach wie den Lautstärkeregler an einer Stereoanlage zu drehen – und eine Sache, die mich wirklich beeindruckt hat. Die Skalierung nach oben und unten geht enorm schnell. Mit Dataflow gehen keine Daten verloren, es muss nichts vorgewärmt werden, wir erstellen einfach einen Zeitplan und verteilen die Ressourcen während des Betriebs. So eine einfache Skalierung haben wir noch nie erlebt.

Mögliche zukünftige Anwendungsfälle für Bigtable

Was zukünftige Anwendungsfälle betrifft, arbeiten wir an einem Projekt zur besseren Betrugserkennung mit Machine Learning (ML), das wir später zu Bigtable migrieren möchten. Derzeit haben wir einen Prozess, der über Airflow einmal pro Stunde den Python-basierten Cloud Composer auslöst. Dieser nimmt die Daten der letzten Stunde aus BigQuery und geht sie durch. Dabei wird der Python-Container mit dem ML-Modell ausgeführt, das geladen wird und die Daten als Eingabe verwendet. Wenn der Algorithmus einen Artikel mit hundertprozentiger Sicherheit als betrügerisch einstuft, wird das Produkt gesperrt. Um die Sperrung wieder aufzuheben, ist eine manuelle Anfrage des Serviceteams erforderlich. Wenn der Algorithmus nicht ganz sicher ist, landet der Artikel im Posteingang der Abteilung und wird markiert, sodass das Team ihn überprüfen kann.

Was derzeit im Prozess fehlt, ist eine automatisierte Feedbackschleife, eine Lernanpassung, wenn das Serviceteam antwortet: „Das ist kein Betrug.“ Wir könnten zwar etwas Passendes für diese Aktion programmieren, aber wir benötigen eine schnellere Lösung. Es wäre sinnvoller, dies direkt über die Pipeline aus Bigtable in die Lernmodelle zu übertragen. 

In Zukunft würden wir auch gerne die Dataflow-Pipeline für alle wichtigen Themen gleichzeitig in BigQuery und Bigtable schreiben lassen. Dann könnten wir diese Art von Anwendungsfällen direkt aus Bigtable statt aus BigQuery heraus bearbeiten und so annähernd in Echtzeit reagieren.

Dank der 13-prozentigen Einsparungen bei den BigQuery-Kosten und der nahtlosen Einbindung aller verwalteten Google Cloud-Dienste, wie Bigtable, ist unser kleines (aber tatkräftiges) DI-Team von den lästigen Aufgaben befreit, die auf unserer Datenplattform anfallen. Wir können diese Zeit in die Lösungsentwicklung für zukünftige Anwendungsfälle und weitere Projekte investieren. 

Wenn Sie mehr über uns erfahren möchten, sehen Sie sich unsere Angebote auf Ricardo.ch an oder finden Sie weitere Informationen über den cloudnativen Schlüssel-Werte-Speicher Bigtable auf der Google Cloud-Website.