TECHNISCHES MEMORANDUMTM-26-010
ZUSAMMENFASSUNG. 2012 wollten wir einem Anbieter für Predictive Targeting zeigen, dass wir seinen vollständigen Datenstrom live analysieren können: 20.000 Events pro Sekunde auf einer Maschine. Dafür reichte kein schneller Algorithmus. Ich implementierte das LMAX-Disruptor-Design, stimmte den Datenpfad auf die Hardware ab und passte unter Linux die Puffer der Netzwerkkarte an. Mikios Decaying-Counter-Implementierung hielt Interessenprofile über mehrere Zeitfenster aktuell. Außerdem mussten wir die Administratoren des potenziellen Kunden überzeugen, uns in ihrer virtualisierten Infrastruktur einen physischen Server zu überlassen. Es funktionierte. Aber es war eher eine technische Demo als ein Produkt.
1. HINTERGRUND. Mikio Braun und ich gründeten TWIMPACT 2009 an der TU Berlin; aus dem Produkt wurde später streamdrill. Wir entwickelten eine In-Memory-Analyse-Engine, die Trends, Ranglisten und Profile aktualisierte, während neue Ereignisse eintrafen. Der potenzielle Kunde hatte eine nützliche Frage: Ließen sich für jeden Nutzer kurzfristige Kaufabsicht und längerfristiges Interesse unterscheiden – über den gesamten Datenstrom hinweg?
Zur Einordnung: Twitter meldete 2012 zwischen 340 und mehr als 400 Millionen Tweets pro Tag. Der 10-Prozent-Datenstrom Gardenhose lieferte damit durchschnittlich etwa 390 bis 460 Tweets pro Sekunde. Schon dessen Analyse galt als Big Data. Unser potenzieller Kunde lieferte 20.000 Events pro Sekunde. Vor allem hatte er einen besseren Anwendungsfall. Die Ereignisrate war deutlich höher. Im Gegensatz dazu mussten Tweets aufwendiger geparst werden. Die Zahlen ordnen die Zeit ein; sie vergleichen nicht den Rechenaufwand.
2. FESTSTELLUNGEN.
2.1 Der vollständige Kundendatenstrom umfasste 20.000 Events pro Sekunde. Wir verarbeiteten ihn live auf einem Bare-Metal-Server.
2.2 Die Administratoren des Kunden betrieben eine virtualisierte Infrastruktur. Bare Metal passte nicht in ihren Betrieb und machte ihnen zusätzliche Arbeit. Wir mussten ihnen die Maschine regelrecht abringen.
2.3 Ich implementierte das LMAX-Disruptor-Design und passte unter Linux die Puffer der Netzwerkkarte an. Netzwerk, Cache und CPU mussten zusammenspielen. Normaler Anwendungscode war das nicht.
2.4 Mit Mikios Decaying-Counter-Implementierung ließen sich Interessenprofile für mehrere Zeitfenster führen. Eine Waschmaschine kann heute eine Kaufabsicht signalisieren. Nach dem Kauf ist sie womöglich für die nächsten zehn Jahre irrelevant.
2.5 Der Kern dieser Implementierung ist seit 2015 als BSD-lizenzierter Scala-Code öffentlich. Damit lassen sich Zähler für Millionen von Objekten mit konfigurierbaren Halbwertszeiten verwalten. Sekundärindizes zeigen die Untertrends. Im Code ist Mikio als Autor genannt:
https://github.com/streamdrill/streamdrill-core
2.6 Wir zeigten die Anwendungen auf der Konferenz des potenziellen Kunden. Kurz danach wurde das Unternehmen übernommen. Damit war auch das Geschäft vom Tisch.
3. SCHLUSSFOLGERUNGEN. Wir hatten gezeigt: Der gesamte Datenstrom ließ sich live auf einer Maschine analysieren. Ein Produkt hatten wir damit noch nicht. Möglich wurde das Ergebnis durch ein bewusst hardwarenahes Gesamtkonzept: ein Algorithmus für die konkrete Frage, ein auf die Maschine abgestimmter Datenpfad und ein Bare-Metal-Server, den wir den Administratoren hatten abringen müssen.
Als Nächstes hätten wir dieselbe Leistung in die virtualisierte Umgebung des Kunden bringen müssen. Dazu kam es nicht mehr. Der Kunde wurde übernommen.
4. MASSNAHMEN.
4.1 Genau festhalten, was die Demo beweist und was nicht.
4.2 Alle Bedingungen dokumentieren, die das Ergebnis möglich machen.
4.3 Jede Abweichung vom normalen Kundenbetrieb als offene Produktarbeit behandeln.
4.4 Algorithmus, Datenpfad und Hardware gemeinsam optimieren.
4.5 Den Weg von der Demo in den Regelbetrieb von Anfang an mitplanen.