Handfestes Know-how, Tipps & Tricks und die Insights unserer Daten- und KI-Profis findest Du hier in unseren Blogbeiträgen
Die Partnerschaft zwischen SAP und Snowflake gibt es schon länger. Jetzt wachsen die SAP Business Data Cloud (BDC) und Snowflake noch enger zusammen. Möglich wird das, wovon viele schon lange träumen: Datenaustausch inklusive SAP-Semantik als Grundlage für Analytics und AI. Wir erklären die wichtigsten Basics, zeigen, wie die Hyperscaler mitspielen, welche Modelle es gibt und wie die technische Umsetzung funktioniert. Vor allem aber zeigen wir, welche Möglichkeiten sich dadurch eröffnen.
Nachdem im ersten Beitrag dieser Blogreihe die herkömmlichen Wege zur Aufbewahrung historischer Daten dargestellt wurden, möchte ich in diesem zweiten Teil eine weitere, effektivere Möglichkeit zur Partitionierung einer historischen Tabelle vorstellen.
R ist eine der populärsten Open-Source-Programmiersprachen für Predictive Analytics. Ihr großer Vorteil ist das Comprehensive R Archive Network (CRAN) mit über 10.000 Paketen für verschiedenste Modelllösungen. Ein Hindernis ihrer Anwendung besteht jedoch in der häufig paketspezifischen Syntax (im Gegensatz zu z. B. Python). Das Paket Caret versucht, durch ein einheitliches Interface auf verschiedene Trainings- und Vorhersagefunktionen den Modellierungsprozess zu vereinfachen. Durch seine Datenvorbereitungs-, Merkmalsselektions- und Modell-Tuning-Funktionalität erleichtert Caret die Bildung und Evaluierung von prädiktiven Modellen. Dieser Blogeintrag zeigt auf, wie wir mit Caret verschiedenen Herausforderungen des Modellierungsprozesses begegnen können, insbesondere bei der Selektion und dem Tuning von Modellen.
Die Automatisierung von immer wiederkehrenden Aufgabenstellungen gehört zu den grundlegendsten Prinzipien der modernen Welt. Bereits Henry Ford erkannte daraus resultierende Vorteile, wie sinkende Fehleranfälligkeit, kürzere Fertigungszyklen und eine gleichbleibende, einheitliche Qualität. Eben diese Vorteile lassen sich bei Data-Warehouse-Initiativen anwenden.
Wir wissen jetzt, wie wir die Daten richtig selektieren, welche Tabellenart wir bei Lookups nutzen sollten und wie wir sicherstellen können, dass wir nur relevante Datensätze durchlesen.
In der Praxis ist es aber oft so, dass man erstmals eine größere und/oder nicht eindeutige Datenmenge von der Datenbank selektieren muss, die dann nach bestimmten Regeln fürs performante Nachlesen aggregiert werden sollte.
Der Oracle Data Integrator (ODI) bietet eine eingebaute Lösung, um Daten mit der SCD-Methodik (Slowly Changing Dimension) zu historisieren. Bei näherer Betrachtung und der praktischen Beladung einer Integrationsmenge in eine Zieltabelle mithilfe des Integration Knowledge Modules (IKM) SCD fällt auf, dass der ODI gewisse "Default Values" für das Gültigkeitsende des Datensatzes verwendet.
Data Warehouses nehmen im Zuge der digitalen Transformation von Unternehmen eine immer zentralere Rolle ein. Denn im Zuge der Entscheidungsfindung hält ein gutes Data Warehouse für jegliche Fragestellung entscheidungsrelevante Informationen bereit. Ein DWH kann also als ein strategisches Management-Instrument gesehen werden, dessen reibungslose Funktionsweise essentiell für den zukünftigen Unternehmenserfolg ist. In diesem Blogbeitrag wird auf eines der wichtigsten Performancefeatures eingegangen, das Partition Pruning.
Nachdem wir uns mit relevanten Selektionstechniken und mit den unterschiedlichen Arten von internen Tabellen auseinandergesetzt haben, sind die wichtigsten Performanceoptimierungen für die Lookups in unseren BW-Transformationen zunächst einmal sichergestellt.
Hiermit ist das Thema jedoch nicht komplett abgedeckt. Denn bis jetzt sind wir davon ausgegangen, dass nur die relevanten Informationen in unseren Lookup-Tabellen durchsucht werden. Wie können wir dies aber sicherstellen?
Die gute Performance einer HANA-Datenbank kommt von der konsequenten Orientierung auf eine hauptspeicherbasierte Datenhaltung sowie durch die Nutzung moderner Kompressions- und ColumnStore-Algorithmen. Somit muss die Datenbank bei Aggregationen über große Datenmengen vergleichsweise wenige Daten lesen und kann dies im Hauptspeicher auch noch außerordentlich schnell erledigen. Jedoch kann bei einem suboptimalen Design des Datenmodells einer dieser Vorteile sehr schnell hinfällig werden. So gehen sowohl der HANA-Datenbank als auch den Anwendern große Vorteile hinsichtlich der Laufzeit und Agilität während der Nutzung verloren.
Dies ist vielleicht die grundlegendste aller ABAP-Fragen, und zwar nicht nur, wenn man sich mit performanten Lookups auseinandersetzt. Sobald man etwas in ABAP macht, wird man auf diese Frage stoĂźen.
In dieser Serie wollen wir uns mit Implementierungstechniken für Lookups auseinandersetzen, bei denen jeder Datensatz der zu durchsuchenden Tabelle überprüft werden sollte. Je größer unsere Datenpakete und unsere Lookup-Tabellen, desto wichtiger ist eine performante Implementierung.
‍
Die Ausnutzung des Hauptspeichers ist bei SAP-HANA- und Data-Warehouse-Szenarien immer ein spannendes Thema im Vergleich zu ERP-Anwendungen bzw. Anwendungen mit einem sich gering verändernden Datenvolumen. Somit muss man eines im Hinterkopf behalten: Lasse niemals den freien Hauptspeicher ausgehen.
Performanceoptimierungen können nicht in Stein gemeißelt werden. Denn Optimierungen, die bei einem Unternehmen mit bestimmter Systemarchitektur und bei gewissem Datenvolumen super funktioniert haben, müssen nicht zwingend an einer anderen Stelle genauso gut klappen. Kurzum: Es müssen individuelle Lösungen erarbeitet werden. Prinzipiell geht es aber immer darum, die Balance zwischen Arbeitsspeicherauslastung und Datenbankauslastung sowie zwischen Implementierungskomplexität und Wartbarkeit zu finden. Dabei steht die Verarbeitungszeit stets im Zentrum.
