Interview mit Thomas Scholz von Snowflake über Data Warehousing in der Cloud

Thomas Scholz ist Sales Engineer bei Snowflake und Experte für analytische Datenbank. Der studierte Informatiker befasst sich bereits seit dem Beginn seiner Karriere vor mehr als 10 Jahren mit den Herausforderungen und Potentialen des Datenwachstums. Heute berät Herr Scholz Kunden beim Weg in die Cloud und dem Einsatz analytischer Datenbanken zur Verbesserung der Möglichkeiten der Datennutzung. Snowflake ist führender Anbieter eines Cloud Services für Data Warehousing und Datenanalyse auf Plattformen wie AWS und MS Azure.
Data Science Blog: Herr Scholz, ohne Data Warehousing wären datenorientierte Geschäftsmodelle unmöglich und auch die Selbstoptimierung von Unternehmen über Datenanalysen nicht effizient. Wie vermitteln Sie die Prinzipien eines Data Warehouse (DWH) in wenigen Sätzen verständlich für Entscheider?
Ganz allgemein kann man sagen, dass ein DWH ein zentraler Datenspeicher im Unternehmen ist, der verschiedene Datenquellen vereinheitlicht und bereinigt zusammenbringt. Durch diese zentrale Rolle müssen Schnittstellen in die vielfältigen Softwarelösungen eines Unternehmens bereitgestellt werden, wobei sich die Fokussierung auf Industriestandards anbietet. Im Datenbankumfeld sind beispielsweise SQL, ODBC und JDBC aber immer mehr auch XML und JSON zu nennen.
In der Vergangenheit wurden DWHs primär zur Verarbeitung der sog. strukturierten Daten genutzt und für semi- oder unstrukturierte Daten wurde andere Konzepte wie beispielsweise Data Lakes eingesetzt. Diese Grenze verschwimmt nun allerdings vermehrt und man möchte idealerweise strukturierte und semi-strukturierte Daten in einem System verarbeiten.
Ein derartig zentraler Datenbestand ermöglicht es Unternehmen alle Geschäftsprozesse im Detail zu verstehen und entsprechend auch Erkenntnisse zur Optimierung zu gewinnen.
Data Science Blog: DWH erfolgt traditionell on-premise. Sie stehen für das DWH in der Cloud. Wo liegen die Vorteile gegenüber der traditionellen Variante?
Cloud Services zu nutzen ist ein breiter Trend und setzt sich nun auch verstärkt im DHW Bereich fort. Dies hat gute Gründe. Sehr oft werden beispielsweise Kosteneinsparpotentiale genannt. Dies ist dadurch möglich, dass man Ressourcen bedarfsgerecht dimensionieren kann und bei passender Architektur nur das bezahlen muss, was man letztlich auch genutzt hat. Kommerziell machbar ist das durch Ressourcenteilung. In einem Cloud-Rechenzentrum werden Rechner geteilt eingesetzt und zwar immer dort, wo sie gerade benötigt werden. Hierdurch werden Leerlaufzeiten vermieden und die Nutzung effizienter.
Aber auch die Skalierbarkeit spielt eine Rolle. Manche Ressourcen werden in der Cloud komplett bedarfsgerecht zur Verfügung gestellt. Beispielsweise Storage. Wenn ich viel benötige, kann ich viel nutzen – und zwar sofort. Praktisch relevante Grenzen existieren nicht. Auch die Skalierung von Rechenleistung ist ein wichtiger Aspekt und hierbei nicht nur nach oben sondern auch nach unten. Ich möchte idealerweise immer genau so viel Leistung bekommen, wie ich gerade benötige. Geschwindigkeit ist nicht mehr limitiert durch die Hardware, die ich im Hause habe. Wenn ich viel Leistung benötige, möchte ich diese auch abrufen können und da ich anschließend wieder kleiner skalieren kann, kann ich mir in intensiven Zeiten auch mehr Ressourcen leisten.
Auch der Aspekt der Agilität wird immer wieder genannt. Cloud-Services stehen mehr oder weniger auf Knopfdruck zur Verfügung. Möchte man eine neue Software im eigenen Rechenzentrum in Betrieb nehmen lassen oder Änderungen an der Konfiguration durchführen, so sind oft langwierige Prozesse erforderlich. Gerade in der schnelllebigen Zeit ist das ein nicht zu unterschätzender Aspekt.
Aber natürlich bringt Cloud auch Risiken und Herausforderungen mit sich, mit denen man sich auseinander setzen muss. So vertraut man seine Daten einem Dienstleister an. Daher muss sichergestellt sein, dass die Daten auch verschlüsselt und vor Zugriffen des Dienstleisters oder anderer unberechtigter Personen geschützt sind. Idealerweise kann der Dienstleister dies garantieren und die Sicherheit des Dienstes durch entsprechende unabhängige Zertifizierungen belegen.
Data Science Blog: Wieso und in welcher Hinsicht unterscheidet sich die Datenbankarchitektur für Clouddatenbanken von on-premise DBs?
Ein großer Vorteil der Cloud ist die elastische Skalierung von Ressourcen. Damit dieser Aspekt aber bei Datenbanken zum Tragen kommt, ist eine andersartige Architektur erforderlich. Klassische Datenbank haben eine recht starre Zuordnung von Daten und Rechenkapazitäten. Möchte man zusätzliche Recheneinheiten nutzen, so muss die Datenorganisation verändert werden, was insbesondere bei großen Datenvolumina nicht effizient ist. Snowflake setzt daher auf eine spezielle Architektur, die konkret für die Möglichkeiten in der Cloud entwickelt wurde. Kernidee ist die Trennung von Storage und Compute, also von Daten und Rechnern. Hierdurch können beide Ressourcen unabhängig voneinander skaliert werden und insbesondere Rechenkapazität bedarfsgerecht genutzt werden. In Zeiten hoher Last, möchte man mehr Ressourcen nutzen, wohingegen bei niedriger Last nur kleine Recheneinheiten oder teilweise gar keine Ressourcen benötigt werden. Da man dies bei Snowflake sekundengenau bezahlt, erkennt man schnell, die Attraktivität dieses Ansatzes. Wenn viel Leistung erforderlich ist, kann ich diese sehr schnell hinzufügen, für diesen Zeitraum bezahle ich das dann auch, aber im Mittel komme ich mit deutlich weniger Ressourcen aus und spare bares Geld.
Außerdem kann man durch die Trennung von Storage und Compute auch belieb Nutzergruppen auf dedizierte Recheneinheiten verteilen und sie somit unabhängig voneinander machen. Der Data Scientist beispielsweise erhält sein eigenes Cluster und beeinträchtigt keinen anderen Nutzer im Unternehmen. Dass die parallele Nutzung unterschiedlicher Cluster auf den gleichen Daten nicht zu Konflikten führt, regelt ein übergreifendes Transaktionsmanagement. Der Data Scientist kann also ein Cluster verwenden, dass für seine Bedürfnisse dimensioniert ist, andere Nutzergruppen erhalten eigene Systeme, die wiederum an deren Erfordernisse angepasst sind. Und aktiv muss ein Cluster nur sein, wenn die jeweilige Nutzergruppe ihr System gerade benötigt.
Data Science Blog: Wodurch grenzt sich Snowflake von anderen Cloud-Services wie von Microsoft, Amazon und Google ab?
Zunächst muss fest gehalten werden, dass Snowflake ein Dienst auf Cloud-Plattformen wie AWS oder MS Azure ist. Es handelt sich also eher um eine Partnerschaft zwischen Snowflake und den Betreibern dieser Plattformen. In einzelnen Bereichen gibt es aber tatsächlich auch Angebote der Plattformbetreiber die mit dem Leistungsangebot von Snowflake im Wettbewerb stehen. Hier gilt es, die eigenen Anforderungen genau zu definieren und die jeweilige Architektur damit abzugleichen. Neben reiner Funktionalität und Performance sollte man gerade Aspekte wie Elastizität und Nebenläufigkeit im Blick haben.
Data Science Blog: Für die erfahrenden Data Engineers, die dieses Interview lesen: Bitte hier nun einen kleinen Pitch für Snowflake!
Ich fasse mich kurz: Snowflake ist das DWH für die Cloud. Die gesamte Architektur wurde für die Cloud entwickelt, mit Snowflake kann man die vielfältigen Vorteile des Cloud Computings fürs DWH optimal nutzbar machen – und das für semi-strukturierte Daten genauso wie für klassische strukturierte Daten. Wer es nicht glaubt, kann es unkompliziert und kostenfrei ausprobieren: https://trial.snowflake.com/
Der Einsatz von Data Warehousing in der Cloud und von Künstlicher Intelligenz zur Auswertung von Geschäfts- oder Maschinendaten ist auch das Leit-Thema der zweitägigen Data Leader Days 2018 in Berlin. Am 14. November 2018 sprechen renommierte Data Leader über Anwendungsfälle, Erfolge und Chancen mit Geschäfts- und Finanzdaten. Der 15. November 2018 konzentriert sich auf Automotive- und Maschinendaten mit hochrangigen Anwendern aus der produzierenden Industrie und der Automobilzuliefererindustrie. Seien Sie dabei und nutzen Sie die Chance, sich mit führenden KI-Anwendern auszutauschen.