Mitte 2019 war das Data Warehouse von SoundCloud das Ergebnis von sechs Jahren an Entscheidungen, die keinen Sinn mehr ergaben: Ein einziges kleines Team verantwortete mehr als 100 ETL-Pipelines auf Amazon Redshift, die meisten davon kaum dokumentiert und mit Unstimmigkeiten untereinander, sodass Business- und Produktteams Daten nicht zuverlässig selbst abrufen konnten. Ein Vertrag über den Wechsel zu Google BigQuery gab dem Team einen Anlass, von vorn zu beginnen, doch ein früherer „Lift-and-Shift“-Migrationsversuch Anfang 2018 war bereits einmal abgebrochen worden.

Das neue Data-Corpus-Team verfasste eine Missionserklärung und sechs Governance-Prinzipien, bevor es Tabellen neu aufbaute: Qualität, Compliance, Aktualität, Nutzbarkeit, Effizienz, Wartbarkeit – angelehnt an einen ISO-Standard. Qualität bedeutete ein Werkzeug, das eine neue ETL-Version mit der eingesetzten vergleicht, sodass nur die beabsichtigte Änderung sichtbar wird. Aktualität bedeutete, die Ankunftszeiten jeder ETL und ihrer Abhängigkeiten zu erfassen; die Entkopplung einer benötigten Tabelle von einer unabhängigen, langsameren Tabelle sparte vier Stunden in der Pipeline ein. Wartbarkeit bedeutete ein „80-Prozent-Prinzip“: für die Masse der Anfragen bauen, nicht für Sonderfälle.

Der Neuaufbau erfolgte in Etappen: Ein Zwischen-Release von Corpus im Dezember 2019 las noch aus dem alten Warehouse, Corpus Alpha im April 2020 war die erste Version, die vollständig unabhängig davon war, und Corpus 1.0 im Juli 2020 war das erste Release, das alle sechs Prinzipien erfüllte. Mit Corpus 2.2 im April 2021 verbrauchte das resultierende BigQuery-Projekt etwa 90 Prozent weniger Speicher als die Rohdaten, aus denen es las, während Stakeholder mit Grundkenntnissen in SQL die meisten Fragen über dokumentierte, beschriebene Tabellen selbst beantworten konnten.

Governance-Prinzipien schreiben, bevor eine einzige Tabelle geschrieben wird

Automatisierter Versionsvergleich verwandelt die Frage „Hat diese Änderung etwas nachgelagert kaputt gemacht?“ von einer Ermessensentscheidung im Code-Review in eine mechanische Prüfung, die bei jedem ETL-Update läuft.

Das 80-Prozent-Prinzip gab dem Team eine feste Antwort auf Debatten über Scope Creep, sodass Tabellen einfach genug blieben, um von Nicht-Experten abgefragt zu werden, statt Komplexität für Sonderfälle anzusammeln.

Die Erfassung von ETL-Abhängigkeiten und Ankunftszeiten verwandelte eine vage Beschwerde („Daten sind manchmal zu spät“) in eine konkrete Korrektur – die Entkopplung zweier Tabellen – mit einer gemessenen Verbesserung von vier Stunden.

Die Veröffentlichung in gestaffelten Versionen über rund 18 Monate, jede an denselben sechs Prinzipien gemessen, ermöglichte es dem Team, die Funktionen von BigQuery kennenzulernen, bevor es Designentscheidungen traf, die am schwersten rückgängig zu machen waren.

Wenn Sie ein System migrieren, das undokumentiert gewachsen ist, schreiben Sie die Prinzipien auf, die verhindern, dass das neue System auf dieselbe Weise verrottet, und machen Sie jedes davon zu einer automatisierten Prüfung statt zu einer Richtlinie, die niemand durchsetzt.

SoundCloud veröffentlichte nach 2.2 weitere Corpus-Versionen und erweiterte die Tabellenabdeckung, während sich das Produkt weiterentwickelte, statt das Governance-Modell als einmalige Migrationsleistung zu behandeln. Das Team beschreibt Corpus als ein sich kontinuierlich weiterentwickelndes Projekt und erwartet ausdrücklich, dass das aktuelle Design irgendwann so veraltet aussehen wird wie das Warehouse vor der Migration – wobei dieselben Prinzipien als ständiger Rahmen dafür dienen, wann es geändert werden sollte.

DEN BELEGEN FOLGEN

Die Quellen

  1. The Journey of Corpus SoundCloud Engineering · developers.soundcloud.com ·