Von Data-Warehouses und Website-Statistiken

Schon vor längerer Zeit habe ich im Rahmen meiner damaligen Firma ein Analysewerkzeug für Website-Besuche geschrieben. Leider ist das ganze recht organisch gewachsen, so dass es heute schwer fällt die Software zu verbessern. Wie lässt sich eine belastbare Architektur entwickeln? Ein Stichwort, an dass ich im Zusammenhang mit großen Datenmengen stets denken muss: Data-Warehouses.

Data-Warehouse: Datenintegration und -separation

Ein Data-Warehouse ist eine Datenbank, die zwei grundlegende Ziele verfolgt:

1. Datenintegration aus heterogenen Quellen
2. Separation der Daten; das Data-Warehouse hat keinen Einfluss auf die operativen Daten

Datenintegration

Beide Aspekte sind für Website-Statistiken höchst relevant. Viele Web-Server stellen mehrere Websites mit unterschiedlichen Technologien bereit. Selbst wenn nicht, möchte ich als Admin die Möglichkeit haben, meinen Apache gegen ein Nginx oder mein Typo 3 gegen ein WordPress auszutauschen. Heterogene Quellen, in welchen die Daten auflaufen, sind somit zumindest potentiell immer gegeben. Ein weiterer Vorteil: Bin ich auf kein festes Format angewiesen, kann ich auch immer die nativen Mechanismen der verwendeten Software nutzen. Apache, Nginx und Co. loggen ohnehin jeden Besucher mit, eine zusätzliche Erfassung der Daten (wie zum Beispiel durch Piwik) ist oft gar nicht nötig. Ein Data-Warehouse kann diese selbstständig integrieren.

Datenseparation

Auch Punkt 2 ist wie fürs Web gemacht: Statistiken sind sicher wichtig, aber nie so, dass sie das eigentliche Webangebot behindern dürften. Ist der Server bereits ausgelastet, so kann ein Aufruf der Statistiken mit unzähligen Leseoperationen und Berechnungen zum großen Problem werden. Spätestes wenn der Speicher voll ist gehen bei kleinen Projekten wie diesem Blog die Lichter aus. Das Prinzip der Datenseparation bietet hier Abhilfe: Die Statistiken werden vollständig von den operativen Daten getrennt. Das Data-Warehouse kann bei Bedarf auf einem anderen Server liegen.

Hierfür müssen die operativen Daten zwar ebenfalls gelesen werden, dies kann in hohen Lastphasen aber einfach unterbunden werden. Der Webserver kann sich auf seinen eigentlichen Job konzentrieren und auch der Statistikaufrufer kriegt schnell und optimiert seine Zahlen. Lediglich Letzterer hat hierbei den Nachteil, dass die Daten nicht mehr ganz in Echtzeit bereitstehen – was wohl zu verkraften sein dürfte. Das Internet ist zwar schnelllebig, die Zugriffe von vor fünf Minuten sind für die meisten aber aktuell genug.

Nachteile

Der Data-Warehouse-Ansatz für die Website-Zugriffsanalyse birgt kaum Probleme. Zwei drängen sich zunächst auf:

• Keine Echtzeitdaten
• Erhöhter Speicherverbrauch durch Datenduplizierung

In meinen Augen sind beide Nachteile unkritisch. Die Aktualitätsspanne zwischen Echtzeit- und Data-Warehouse-Daten lässt sich je nach Kapazität beliebig verkleinern. Je öfter die Daten integriert werden, desto weniger Neuerungen sind zu verarbeiten. Selbst minütliche Syncs sind realistisch, wenn man seine Zugriffsspitzen im Blick hat und nach Bedarf das Intervall anpasst.

Der vermehrte Speicherverbrauch war selbst zu Zeiten der Festplattenkrise kein Problem. Wer jeden Tag gigabyteweise Zugriffsdaten wegschreibt hat sicher andere Sorgen als zehn Festplatten im Jahr…

Skalierbarkeit und Datenstrukturkonzeption

Das Konzept Data-Warehouse ist simpel und überzeugend. Für Website-Statistiken überzeugt vor allem die Skalierbarkeit: Vom kleinen PHP-Webspace mit My-SQL-Datenbank kann eine gut konzipierte Datensammlung mitwachsen und auf beliebig große und verteilte Systeme migriert werden.

Zudem bietet dieses Forschungsfeld interessante Ansätze, wie man Daten effizient an das Anwendungsfeld angepasst strukturiert. OLAP-Cubes und Sternschemas für relationale Datenbanken sind wichtige Stichwörter, die jedoch einen eigenen Artikel rechtfertigen.