Vision und Machbarkeit des „Logical Data Warehouse“
Werbung
Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen Vision und Machbarkeit des „Logical Data Warehouse“ 1 Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 2 Die Motivation ............................................................................................................. 4 Lösungskonzepte ......................................................................................................... 5 Evolution statt Revolution ........................................................................................... 6 Aspekte des Logical Data Warehouse (LDW) .............................................................. 8 1. Technische Sourcen ..................................................................................... 8 2. Zugriffsverfahren ......................................................................................... 8 3. Zugriffstechnik ............................................................................................. 9 4. Formate ....................................................................................................... 9 5. Metadaten ................................................................................................... 9 6. Security ...................................................................................................... 10 7. Konsumenten............................................................................................. 10 Wie unterstützt das Oracle Data Warehouse das Konzept des LDW ........................ 11 1. Welche technischen Sourcen lassen sich anbinden? ................................ 11 2. Welches Zugriffsverfahren steht zur Verfügung........................................ 12 3. Welche Zugriffstechniken stehen zur Verfügung ...................................... 12 4. Formate und Oracle ................................................................................... 14 5. LDW-Metadaten mit Oracle ...................................................................... 15 6. Security im LDW-Konzept mit Oracle ........................................................ 16 7. Nutzer- (Konsumenten-) Neutralität / Virtualisierung der Nutzermodelle 17 Resümee .................................................................................................................... 18 Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 3 Bereits seit einigen Jahren (verstärkt seit 2011) wird das Konzept des „Logical Data Warehouse“ besprochen, und vorgestellt.. Die aktuelle Diskussion rund um Big Data, aber auch die vielen neuen technischen Möglichkeiten, die heute bereitstehen, machen diese Diskussion interessanter denn je. Es sind Lösungskonzepte möglich, deren Problemstellung wir vor Jahren noch gar nicht gesehen haben. Allerdings fasst der Begriff auch schon längst bestehende Technologien unter einem neuen Schlagwort zusammen. Kurz zu dem Stichwort: Logical Data Warehouse (LDW. Ein „Logisches Data Warehouse“ stellt Unternehmensdaten bereit, ohne diese zuvor physikalisch an einen zentralen Ort in dem Data Warehouse zu bewegen. Wie in einem klassischen Data Warehouse werden einheitliche Sichten für Analysezwecke bereitgestellt. Während die Daten des klassischen Data Warehouse aus einer „wohldefinierten“ physikalisch einheitlichen Datenbank stammen, zieht sich das „Logische Data Warehouse“ Daten zum Abfragezeitpunkt aus diversen Quellen zusammen. Die eigentlichen Ablageorte werden virtualisiert. In diesem Artikel wird der Begriff noch etwas weiter gefasst: Die neuen In-Memory Technologien erlauben auch das Virtualisieren von Strukturen innerhalb des Data Warehouse. In jedem Fall bietet das System den Benutzern Daten an, die in der ihm präsentierten Form nicht physikalisch als Tabellen in einer Data Warehouse – Datenbank liegen. Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 4 Die Motivation Es gibt in einigen Unternehmen eine wachsende Motivation bei den WarehouseArchitekten sich mit diesem Konzept zu beschäftigen: 1. Es werden immer noch nicht alle im Unternehmen existierenden Daten in die Analyseprozesse mit einbezogen. D. h., Opportunities gehen verloren, weil Informationen nicht da sind.1 2. Eine Ursache liegt darin, dass nicht alle wichtigen Daten-Ressourcen über recht schwerfällige Warehouse-Projekte mit der Entwicklung von aufwendigen ETL-Strecken, in das Warehouse integriert sind. Hohe Entwicklungskosten, fehlendes Personal aber fehlendes Bewusstsein für Synergie-Effekte zentraler Analyseprozesse im Management mögen Gründe sein. 3. Ein weiterer Grund ist sicher der Umstand, dass in immer kürzeren Zeitabständen neue Daten-Ressourcen von den Fachabteilungen angefordert werden. 4. Wir haben das zunehmend deutlicher spürbare Latenzproblem. D. h., die Beschaffungszeiten mittels traditioneller ETL-Batch-Prozesse sind bei einer wachsenden Zahl von Analyseanforderungen zu lang. 5. Manche Datenquellen sind in Struktur und Inhalt derart volatil, sodass man sie kaum noch mit klassischen Warehouse Konzepten (z. B. konventionellem Batch-ETL) einfangen kann. 6. Unternehmen richten heute zunehmend Ihr Augenmerk auch auf nichttraditionelle Unternehmensdaten. Sie kaufen externe Daten zu, sie zapfen öffentlich zur Verfügung stehende Datentöpfe an, sie erschließen zusätzliche Datenquellen, an die vor Jahren noch niemand gedacht hat, z. B. Maschinendaten, Mail-Verkehre, Telefondaten usw. Solche Daten waren zwar immer schon vorhanden. Doch nun beginnt man, angeheizt durch die Big Data Diskussion, die Daten zu kombinieren und versucht aus möglichen Zusammenhängen Nutzen zu ziehen. Bei diesen Datenarten besteht die berechtigte Frage, ob sie überhaupt in ein Data Warehouse geladen werden sollten. 1 Siehe hierzu z. B. Umfrage in US: “From Overload to Impact: An Industry Scorecard on Big Data Business Challenges” Link Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 5 Lösungskonzepte Als technische Lösung stehen und standen sich zwei Lösungsvarianten gegenüber. a) Verteilte Datenhaltung, die durch eine Metadaten-Schicht virtuell zusammengefasst werden. Daten verbleiben in ihren jeweiligen Anwendungen oder werden in zusätzliche (aber verteilte) Datentöpfe abgelegt. Solche sog. „Distributed Warehouse Solutions“ werden von einigen DB-Herstellern, mit mehreren (zugekauften) DB-Systemen angeboten. Solche Konzepte sind jedoch schon bei den ersten Gehversuchen in frühen Projekten (2008 / 2009) an der Komplexität der vielen unterschiedlichen Strukturen gescheitert.2 b) Erweiterung eines bestehenden zentralen Warehouse-Systems um die Möglichkeit des Zugriffs auf externe Datenquellen bzw. der Möglichkeit der Steuerung externer Prozesse. Das Oracle Data Warehouse fällt eindeutig zur Gruppe unter b). Auch schon vor der Diskussion um das Logische Data Warehouse Konzept, hat Oracle in den letzten Jahrzehnten Kommunikationswege und Schnittstellen in die Unternehmens-ITInfrastruktur in der Datenbank implementiert. Schon seit mehr als 15 Jahren reden wir bei der Oracle Datenbank, nicht nur über ein nacktes Datenhaltungssystem, sondern von einer Art Datendrehscheibe, die kaum Hürden bei dem Zugriff auf Unternehmensdaten kennt. (In vielen Unternehmen sind diese Techniken auch im Einsatz, ohne dass man den Namen „Logisches Data Warehouse“ verwendet.) 2 Vgl. Gartner „Hype Cycle for Business Intelligence and Analytics, 2013” Mark A. Beyer Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 6 Evolution statt Revolution Die Variante b) macht eine evolutionäre Weiterentwicklung vieler bestehender Warehouse-System möglich, denn es ist kaum anzunehmen, dass Unternehmen ihre Warehouse-Systeme regelmäßig mal eben so neu konzipieren. Mann wird sie „auf kleiner Flamme“ in Versuchs-Labors Stück für Stück weiter entwickeln und für bestimmte Datenquellen „virtuelle“ Zugriffsmöglichkeiten einbauen. Es gibt noch einen zweiten sehr wichtigen Punkt, der für die Variante b) spricht. Das sind die 4 klassischen Hauptaufgaben eines Data Warehouse: 1. Das sachgebietsübergreifende Integrieren von sachgebietsbezogenen Daten an zentraler Stelle mit der Notwendigkeit zu Harmonienieren. 2. Das Anreichern von Daten mit Erklärungen und zusätzlicher Semantik. 3. Das Historisieren von Daten als Grundlage für Trenderkennung. 4. Das Separieren von Daten aus dem operativen Kontext zum Zweck der Simulation und der Möglichkeit zusätzliche Informationen aus im Data Warehouse neu entstandenen Querbezügen zu anderen Daten zu gewinnen. Diese 4 Punkte sind an anderer Stelle schon oft ausgeführt worden und sollten daher hier nur kurz erwähnt bleiben. Das sind aber oft diejenigen Punkte, die man bei Diskussionen rund um Hype-Themen gerne vergisst. Ein Warehouse, dessen Datenbeschaffungsfunktionen komplett virtualisiert wären, müsste die 4 genannten Aufgabenstellungen auch komplett virtuell lösen. Bei jeder vernünftigen Betrachtung: unmöglich!3 Das bedeutet: Für die Masse der Warehouse Daten bleibt eine konventionelle Batch-Verarbeitung sinnvoll, nicht aus Performance oder technischen Gründen, sondern weil pragmatischerweise konsolidierende, harmonisierende Tätigkeiten einfacher zu lösen sind. 3 Es ist das gleiche „aufgesetzt“ Vorhaben, das mancher Hersteller von reinen In-MemoryDatenbanken in seinen Marketing-Unterlagen als zukunftsweisend bewirbt, um dann doch wieder in den Projekten auf die klassischen Warehouse-Prizipien mit persistierten Datentabellen zurückzukommen. Dann aber mit einer sehr komplexen Ausgangslage und zusätzlichen Datenhaltungskrücken. Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 7 Wir sollten uns also mit einer Lösung beschäftigen, die ein bestehendes Data Warehouse in der oft praktizierten Schichten-Architektur (Stage/Core Warehouse/Marts) als Ausgangspunkt nimmt, und dieses in evolutionärer Weise Stück für Stück um virtuelle Zugriffs- und Bereitstellungstechniken erweitert. Das klassische 3-Schichtenmodell nach Inmon Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 8 Aspekte des Logical Data Warehouse (LDW) Der konsequente Aufbau von logischen (virtuellen) Strukturen in einem Data Warehouse umfasst eine Reihe von Aspekten und Komponenten, wie sie in der folgenden Tabelle dargestellt sind. Technische Sourcen noSQL Hadoop (HDFS) RDBMS Files Web ZugriffsVerfahren Batch Direkt Message ZugriffsTechnik APIs MapReduce SQL, Proprietär, Formate Metadaten Security XML JSON CSV KeyValue, ER Fundorte Struktur Inhalte Zugriffsdaten Objektbezogen Toolbezogen, Quellsystem bezogen Konsumenten Modellflexibilität Beliebige BI-Tools native Allgemeine Aspekte in dem Konzept des „Logical Data Warehouse“ 1. Technische Sourcen Die klassischen technischen Datenquellen sind sicherlich Datenbanksysteme (relational, hierarchisch) und Flatfiles. Bereits in den frühen 2000er Jahren sind WebSourcen hinzugekommen, also Daten, die remote über Internet-Dienste angeboten wurden. Warehouse-System erfüllten damit ihre althergebrachte Aufgabe des ErfolgsMonitorings bestehender, bekannter Prozesse. Heute sind auf der Suche nach neuen Opportunities und Wettbewerbsvorteilen bislang unberücksichtigte Daten in den Fokus gerückt (externe Daten, Daten aus sozialen Medien, Maschinendaten, Log-Daten, Wetterdaten, Bewegungsdaten usw.). Aufgrund ihrer Strukturierung aber auch aufgrund der Art der Datenentstehung will man sie oft nicht mehr klassisch speichern und sucht nach neuen Wegen. Die technische Innovation hat Hadoop/HDFS oder auch die noSQL-Datenbanken für solche Daten bereitgestellt. Das LDW muss mit all diesen technischen Sourcen umgehen können. (Aber Achtung: Wir reden heute nicht deshalb über das Konzept des Logical Data Warehouse, nur weil es die Big Data Diskussion gibt. Auch ohne diese Entwicklung und diese „neuen“ Datenobjekte ist Konzept überlegenswert.) 2. Zugriffsverfahren a) Das ursprüngliche Batch-Verfahren zum monatlichen / wöchentlichen / täglichen / untertägigen Updaten und Bereitstellen von Daten ist in seiner Struktur periodisch. Technisch gesehen ist es gleichgültig, ob man täglich oder stündlich ein Warehouse befüllt. Das, was manchmal Realtime genannt wird, ist nach wie vor ein Batch-Load, auch wenn dieser Batch-Load im 10Sekunden-Takt erfolgt. Wesentlich für den Begriff „Batch“ ist der Umstand, dass eine gewisse Anzahl von Daten aus einem Quell-System gelesen und in ein Zielsystem geschrieben werden.. Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 9 b) Anders verhält es sich, wenn zu analysierende Daten aus einem Quellsystem zum Zeitpunkt der Analyse direkt aus dem Vorsystem gelesen werden (DirektLeseverfahren). Dieses Verfahren macht keine Aussage über die Aktualität der Quelldaten und hat auch keinen Transaktionsbezug auf das OLTP-System. Wichtig ist allein die Abfrage des Analysten, der zum Zeitpunkt der Abfrage in den operativen Datenbestand hineingreift, ob mit Filter oder ohne. c) Die 3. Variante ist das aktive Befüllen des Warehouse über einen permanenten Kommunikationsprozess zwischen Warehouse und operativen Systemen, indem Nachrichten (Messages) hin- und her fließen, entweder im Push oder im Pull-Verfahren. Alle drei Verfahren sollten in dem LDW machbar sein. Es wäre ein Trugschluss, das klassische DWH als Batch-orientiert und das LDW mit dem Direkt-Leseverfahren zu assoziieren. Ein virtualisierter Zugriff auf ein operatives System ist technisch auch als spontan gestarteter Batch-Aufruf oder als Message-Abruf über einen SOA-Bus denkbar. Entscheidend ist der Punkt, dass die Warehouse-Datenbasis im Bedarfsfall spontan erweitert werden kann. 3. Zugriffstechnik Unterschiedliche technische Sourcen erfordern spezifische Zugriffstechniken, die mit den Besonderheiten der jeweiligen Datenhaltung umgehen können. Für RDBMSSysteme hat sich SQL etabliert. Für ein Hadoop-System wird MapReduce angeboten. Das LDW muss auf die Datenhaltungen zum Zeitpunkt X spontan zugreifen können. Es wird aber zu klären sein, ob das LDW jede spezifische Zugriffstechnik adaptieren muss. Einfacher wäre ein einziger standardisierter Zugriff, bei dem man nur einen Adapter austauschen muss, wenn es sich um eine andere Datenhaltung handelt, aber die Art des Zugriffs gleich bleibt. 4. Formate Die technische Datenablage ist das eine, die Art, wie diese Information abgelegt ist, und beim Lesen interpretiert werden muss (Format) ist das andere. Hier wird noch nicht die Frage nach der Strukturierung von Daten angesprochen (strukturiert, unstrukturiert, multi-strukturiert etc.). In einem HADOOP-HDFS-System können sowohl Fließtexte, XML-Strukturen, CSV-Objekte, JSON-Files liegen. Das Gleiche gilt für das klassische File-System. Das LDW muss formatunabhängig Zugriffe realisieren können. 5. Metadaten Einer der heikelsten Punkte des LDW ist sein Metadatenbereich. Wie soll man auf Daten zugreifen, wenn man nicht einmal weiß, ob diese überhaupt existieren? Das klassische Warehouse bietet hierfür z. B. den Datenbank-Katalog an. Und wenn es nur Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 10 ein einfaches „SELECT * FROM TAB“, (Oracle-Variante) ist, man erhält eine erste Übersicht über die Existenz bestimmter Objekte.4 Ein LDW muss über eine Metadaten-Komponente verfügen, in der für die nicht in dem Warehouse liegenden Daten neben den Fundorten auch die Struktur und die Semantik (Beschreibung der Inhalte) erfasst sind. Für den Nutzer des Systems muss eine durchgängige Sicht sowohl über die lokalen Warehouse-Daten als auch über die nicht in dem System physisch gespeicherten aber zugreifbaren Daten angeboten werden. 6. Security Man stelle sich ein Logisches Data Warehouse vor, das in Ergänzung zu den bestehenden Warehouse-Daten immer mal wieder zusätzlich in das eine oder andere Quellsystem hineingreift um dort spontan, meist operative Daten, abzugreifen. Die Benutzer dieser Daten werden, wenn sie über ein Data Warehouse zugreifen, meist nicht dieselben sein, wie die Benutzer, die in den Quellsystemen für Datenzugriffe berechtigt sind. Es muss also für das LDW ein zusätzliches Berechtigungsverfahren implementiert werden, das sich an den Richtlinien der Sourcen orientiert. 7. Konsumenten In vielen Betrachtungen des LDW kommt dieser Aspekt nicht vor. Es ist aber nur konsequent, wenn auch die Konsumentenseite, spricht, die Art der Verwendung virtuell, also frei wählbar ist. Dies meint z. B. die Austauschbarkeit von BI-Tools und Analyse-Verfahren, meint aber auch die Flexibilität der Auswertedatenmodelle. Es handelt sich bei dem LDW um die Virtualisierung von Datenzugriffen, also das Lesen von Informationen auf so nicht vorhandene Daten, ob die Daten nun außerhalb des Warehouse-Systems liegen oder innerhalb. Abhängig von dem Informationsbedarf legt man eine passende Virtualisierung auf. Mit virtuellen Sichten schafft man passende Auswertemodelle, ohne die physikalische Datenbasis im Data Warehouse zu verändern. Die potenzielle Austauschbarkeit von Analysewerkzeugen ist dann ein Selbstläufer. Ein LDW sollte nicht für eine bestimmte Verwendung hin entwickelt werden, denn auch die Art der Verwendung kann sich spontan ändern.5 4 Wenn auch beschränkt: In den meisten bestehenden Warehouse-Systemen fehlen echte Metadaten-Auskünfte. Also z. B. die Information welche Tabellen mit welchen anderen Tabellen gemeinsam sinnvo9ll abfragbar sind, welche Tabellen Fakten enthalten und welche Tabellen Dimensionen mit entsprechenden Hierarchien. 5 Dies gilt auch schon für das klassische Data Warehouse, denn die Informationen eines Warehouse-Systems sind meist langlebiger als ein konkreter Analysebedarf, der über eine spezifische Technologie (Tool) abgedeckt wird. Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 11 Wie unterstützt das Oracle Data Warehouse das Konzept des LDW Ein erster wichtiger Punkt in der Philosophie des Oracle Data Warehouse, auch bzgl. des LDW-Konzeptes, ist die Standardisierung mittels SQL. D. h. alle Daten, ob sie im zentralen Data Warehouse oder außerhalb liegen, sollten mittels SQL zugreifbar sein. Das gilt ebenso für die Konsumenten. Diese sollten mittels SQL abfragen können. Das bedeutet, dass im Oracle Data Warehouse eine Transformation der Formate stattfindet. Mit dieser Transformation sind dann auch weitere Anforderungen leicht lösbar, z. B. die Metadaten-Abbildung oder Teile der Security-Anforderung. Die zentrale Rolle von SQL bei der Virtualisierung von Vereinheitlichung von Zugriffen durch das Oracle Warehouse und anschließbare Systeme Der zweite Aspekt ist die Vermeidung von unnötigen Datentransporten. D. h., Daten sollten an Ort und Stelle analysiert werden, wenn dies möglich ist. Das ist nicht möglich, wenn Daten aus unterschiedlichen Quellen über einen Join zusammengeführt werden sollen. Die einzelnen Anforderungen des LDW-Konzeptes werden in der Folge beschrieben. 1. Welche technischen Sourcen lassen sich anbinden? Alle oben genannten technischen Source-Systeme lassen sich anbinden. Daten können an ihren Orten und in ihren Systemen bleiben. Der Zugriff erfolgt in nahezu allen Fällen, von der Position der Oracle Datenbank aus. D. h., es müssen keine Prozesse oder Vorkehrungen in den jeweiligen Quellsystemen erfolgen. (Auf die technische Umsetzung wird weiter unten eingegangen). Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 12 Oracle Warehouse und anschließbare Systeme 2. Welches Zugriffsverfahren steht zur Verfügung Alle besprochen Verfahren sind möglich. Alles, was direkt zugegriffen werden kann, ist auch im Batch möglich und umgekehrt. Ist eine Fremd-Datenbank z. B. über einen Select-ODBC-Zugriff erreichbar, so gelingt dies natürlich auch im Batch-Verfahren, weil man in einem Batch-Job genauso mit Kommandos agieren kann, als wäre man online.6 Darüber hinaus erlaubt die Datenbank Optimierungen, um große Datenmengen zu bewegen, wenn dies nötig ist. Durch das Verwenden von passenden Adaptern oder auch durch Webservice-Zugriffe kann man zu jedem Zeitpunkt und beliebig häufig auf Remote-Daten aus der Datenbank heraus zugreifen. Auch umgekehrt lässt sich die Datenbank remote ansteuern, um diese als „Senke“ für Nachrichten zu nutzen. Das Oracle Data Warehouse mit der Datenbank ist also an sich Batch-, Online- und Realtime-fähig. 3. Welche Zugriffstechniken stehen zur Verfügung Hier muss man zwischen den unterschiedlichen technischen Sourcen unterscheiden. a) Für Flat Files gibt seit den frühen 2000er Jahren External Tables. Die Textdaten, welcher Art auch immer (beliebige Formate und Zeichensätze), verbleiben außerhalb der Datenbank. Sie können aber mittels SQL aus der Datenbank heraus so behandelt werden, als wären es Datenbanktabellen.7. Wir werden noch sehen, dass das External Table Konzept auch für andere technische Sourcen verwendet wird. 6 Im Batch-Verfahren wird ebenso eine Datenbank-Session eröffnet, wie in einem OnlineZugriff. Es stehen die gleichen Kommandos zur Verfügung. 7 Mehr Informationen zu External Tables in der Oracle Dokumentation oder auch in diesem Whitepaper http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-dataloading-oracle-db-12c-2189777.pdf Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 13 b) Auf Oracle-DBs greift man mit dem altbekannten Database-Link-Mechanismus zu. Auch diese Technik erlaubt Zugriffe mittels SQL. Tabellen in einer RemoteOracle-Datenbank erscheinen wie lokale Tabellen im Data Warehouse.8 c) Für Nicht-Oracle-DBs gibt es die (bei einigen gar nicht mehr bekannten) Gateways. Anders als die heute oft favorisierten Replikationsmechanismen wie GoldenGate, verbleiben die Daten, wie bei dem LDW-Konzept gefordert, in dem Quellsystem. Es werden nur diejenigen Daten abgegriffen, die nach einem auf dem Quellsystem stattgefundenen Filter- und Selektionsvorgang übrig bleiben. Man muss also nicht erst Daten bewegen, um festzustellen, ob man sie braucht. Der Zugriffsmechanismus über Gateway erfolgt analog zur Database Link Mechanik. Auch für die Gateway-Technik ist SQL das Zugriffsmittel. d) Informationen über das World Wide Web abzurufen ist heute Standard. Ob man direkt aus der Datenbank zugreift oder über eine Middleware-Apparatur mit noch mehr flexiblen Möglichkeiten, muss man separat entscheiden. Aber auch hier ist der Einsatz von SQL möglich.9 e) Auch auf HDFS-Files (Hadoop) kann man seit Sommer 2014 direkt aus der Datenbank heraus mit SQL zugreifen. Ähnlich wie bei den Storage-Zellen einer Exadata-Maschine, hat man auf jeden Knoten eines Hadoop-Clusters eine Scan-Software gebracht, die die einzelnen Blöcke einer Hadoop-Datei parallel lesen und analysieren kann. Auch hier spielen External Tables in der Oracle Datenbank eine zentrale Rolle. Sie verfügen über einen Oracle_HADOOP- und alternativ einen ORACLE_HIVE-Adapter, der mit den Scan-Prozessen auf den Hadoop-Clustern kommuniziert. Die Strukturbeschreibung zum Erstellen der External Tables bezieht während der Definition der External Table aus dem Hive-Metastore über einen automatisierten Extrakt-Porzess10. f) Analoges gilt für die noSQL-Datenbank von Oracle. Für weitere noSQLDatenbanken anderer Hersteller sind ebenfalls External-Table Adapter geplant. g) Mit der R-Schnittstelle ORE (Oracle R Enterprise) gibt es Möglichkeiten, die bislang recht unbekannt sind. Zum einen verfügt die Open Source-Sprache R Zugriffspakte auf nahezu alle Datenarten (auch Hadoop). Zum anderen können gelesene Daten, die R als sog. R-Objekt im Hauptspeicher hält sofort und 1:1 in Datenbanktabellen oder Views umgewandelt werden. Solche RZugriffe auf Daten sind als Script verpackt auch über SQL direkt aus der Datenbank heraus aufrufbar. Man kann also von einem Direkt-Zugriff auf Daten sprechen. Ein Batch–Lauf ist nicht nötig. 8 Siehe Oracle –Doku: https://docs.oracle.com/database/121/SQLRF/statements_5006.htm#SQLRF01205 9 https://docs.oracle.com/middleware/1212/owsm/ 10 Siehe http://www.oracle.com/us/products/database/big-data-sql/overview/index.html Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 14 h) ODI (Oracle Data Integrator und Golden Gate sollten hier nur kurz erwähnt werden. Sie liefern zwar zu allen denkbaren technischen Source-Systemen passende Schnittstellen. Der Einsatz läuft aber in der Regel entweder auf eine Batch-Verarbeitung oder permanentes Replizieren hinaus. Das sind sicherlich machbare Verfahren, zumal man Batch-Laufzeiten auch auf weniger Sekunden reduzieren kann. Aber das Herbeischaffen von Daten mittels spontanem SQLAufruf, während die Quelldaten in dem Source-System verbleiben, ist ein anderes Konzept. Zugriffstechniken des Oracle Data Warehouse auf remote liegende Datenobjekte 4. Formate und Oracle Remote liegende Datenbestände können, wie oben beschrieben, in unterschiedlichen Formaten vorliegen. Aufgrund der in dem Abschnitt zuvor beschriebenen Zugriffstechniken muss man sich um diese Formate nicht kümmern, da die Formatumwandlung (XML -> relationale Struktur, JSON -> relationale Struktur, CSV -> relationale Struktur, KeyValue -> relationale Struktur) bereits in den jeweiligen Adaptern erfolgt. Es gibt jedoch eine Variante, bei der man sich um Formate Gedanken machen muss, und zwar in dem Fall, in dem man remote liegende Daten temporär in eine Art operational Datastore innerhalb des Data Warehouse kopiert. In diesem Fall repliziert man operative Daten in das Warehouse, um Analysezugriffe zu vereinfachen. a) CSV-Objekte liest man über External Tables direkt in relationale Tabellen. b) Ebenso KeyValue Store Objekte mit dem Loader for Hadoop.. Auch hier finden wieder External Tables Verwendung und das Ergebnis sind relationale Tabellen. Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 15 c) XML-Objekte werden in XML-Tabellen innerhalb der Datenbank geladen. Mit den Möglichkeiten der XML-DB greift man auf hier mit SQL relational zu.11 d) Ähnlich verfährt man mit JSON-Objekten. Auch dieses Format kann man wie XML in die Datenbank legen, und es mit SQL abfragen.. Bei allen genannten Verfahren kann man ODI oder Golden Gate als Tools und zur Vereinfachung einsetzen. Der Aufbau eines operational Data Stores als temporärer Hilfsdatenbestand Es sollte noch einmal erwähnt werden, dass aus Sicht des LDW-Konzeptes die Einrichtung eines Operational Data Stores nur eine Hilfskonstruktion darstellt, wenn ein direkter Zugriff auf Daten in den Quellsystemen nicht möglich ist. Denn ein Operational Data Store muss zusätzlich durch eine Kopie mit Daten gefüllt werden. 5. LDW-Metadaten mit Oracle Aufgrund des SQL-Zugriffs auf die meisten Objekte ist das Datenbank-Dictionary ein einfaches und praktisches Hilfsmittel. Es dient als Metadatensystem. Hier sind Tabellen mit ihren Spalten dokumentiert. Sobald External Tables existieren, existieren auch Metadaten für alle Objekte, auf die man mit External Tables zugreift: a) Tabellen aus fremden Datenbanksystemen mit Oracle-konformen Feldtypen b) Datei-Strukturen (CSV und Fixed Length) c) HDSF, Hive-Objekte, Übernahme der Metadaten des Hive Metastore Für andere Objekte wie JSON-/XML-Strukturen oder den „Value-Part“ bei Key Value Objekten sind Metadaten nur über einen expliziten Beschreibungsvorgang, verbal oder über einen Pseudo-Code erhältlich. JSON- und XML-Objekte führen ihre eigenen 11 Siehe hierzu http://www.oracle.com/technetwork/database/databasetechnologies/xmldb/overview/index.html Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 16 Metadaten in dem Objekt selbst mit sich, die aufgrund ihrer Vielfältigkeit nicht generisch (im Sinne eines Metadaten-Repositories, oder des Oracle DatenbankDictionaries) beschreibbar sind. Bezüglich der Metadatenanforderung des LDW sind die größten Herausforderungen zu lösen. Metadaten entstehen auch in dem Oracle Data Warehouse erst durch einen Definitionsprozess der jeweiligen Objekte. D. h., es muss zunächst ein Objekt, z. B. eine External Table zum Lesen einer HDFS-Datei, mittels der DDL-Anweisung CREATE erstellt werden, damit auch Metadaten zur Verfügung stehen. Dies setzt bereits besondere Kenntnisse über die Objektstruktur und den technischen Zugriffsweg auf das Objekt voraus. Eine generische, allgemeine oder rein fachliche Beschreibung der Objekte reicht nicht aus. Um die Problematik zu verdeutlichen, stelle man sich den Alltag der heute oft diskutierten Rolle des „Data Scientist“ vor. Er hat es mit einer Vielzahl von Objekten, vor allem jenseits der bekannten und einfach zu bedienenden SQL-Datenbanken zu tun. Bevor er die Qualität und Zweckdienlichkeit der Inhalte von Daten bewerten kann, muss er technische Zugänge definieren, um diese Daten überhaupt zu lesen. An dieser Stelle bewährt sich Oracles Weg, SQL als Zugriffs- und Beschreibungssprache für die vielen unterschiedlichen technischen Daten-Sourcen und Formate zu nutzen. Für SQL gibt es schon seit Jahren sehr weit entwickelte Werkzeuge, die auch für die Metadaten-Beschaffung eine Reihe von Wizards anbieten. Oracle hat in den letzten Jahren den SQL-Developer für diesen Zweck kontinuierlich weiter entwickelt.12 a) Die Datenbank Dictionaries vieler Nicht-Oracle Datenbanken lassen sich direkt auslesen. b) Das Format von beliebigen Textdaten lässt sich bestimmen. External Tables werden automatisch generiert. c) Die Struktur von HDFS- und Hive-Objekten kann mit Hilfe der Revers Engineering-Funktion des Data Modeler (eine DatenmodellierungsKomponente des SQL Developer) aus dem Hive Metastore ausgelesen werden. Aus diesen Metadaten generiert der SQL Developer schließlich die External Tables, mit denen man HDFS- oder Hive-Objekte lesen kann. 6. Security im LDW-Konzept mit Oracle Auch der Security-Aspekt des LDW wird entsprechend abgedeckt. Bei virtuellen Zugriffen auf verteilte Daten müssen die Zugriffsschutzeinrichtungen der jeweiligen Quelldatensysteme mit in die Datenbank hinein übernommen werden. Wird z. B. ein unternehmensweites LDAP-Verzeichnis zur zentralen Benutzerverwaltung eingesetzt, so kann man solche Security-Informationen in ein Rollenkonzept in der Datenbank übernehmen. Gerade bei Daten aus operativen Systemen ist dann eine gezielte Maskierung von Teilen der Informationen (bestimmte Spalten oder Zeilen) nötig.. Es 12 Siehe hierzu http://www.oracle.com/technetwork/developer-tools/sql-developer/what-issqldev-093866.html Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 17 reicht also völlig aus, tabellenartige Objekte zu schützen, die in dem DatenbankDictionary dokumentiert sind. 7. Nutzer- (Konsumenten-) Neutralität / Virtualisierung der Nutzermodelle Der Titel dieses Punktes ist etwas irreführend. Im Gegensatz zu den vorgenannten 6 Aspekten, bei denen es um die Zugriffe auf außerhalb des Data Warehouse liegende Daten-Sourcen geht, befasst sich dieser Punkt mit der Verwendung der Daten innerhalb des Data Warehouse. Die Informationsbedürfnisse der Benutzer können sich ändern. In der Folge ändern sich auch die abgefragten Datenobjekte oder auch sogar die Werkzeuge, mit denen die Benutzer zugreifen. Bislang sind in solchen Fällen neue Auswertemodelle zu entwerfen und die entstehenden neuen Tabellen sind mit ETL-Aufwand zu befüllen. Auch hier zieht das Konzept der Virtualisierung, nur dass die Datenobjekte innerhalb des Warehouse und nicht außerhalb liegen. Auswertemodelle entstehen nur auf einer logischen Ebene und nicht als Tabellenwerk in einer Datenbank. Des Oracle Data Warehouse nutzt in der aktuellen Version (12.1.0.2) hierfür die neue In-Memory Option. Das Prinzip ist sehr einfach: Star Schemen, als die dem Endbenutzer zugewandten multidimensionalen Modelle, werden nicht mehr persistent und „hart modelliert“. Sondern sie bestehen aus einer Ansammlung von Datenbank-Views. Deren Basistabellen befinden sich im Hauptspeicher der Datenbank und die Views sind somit extrem schnell abfragbar. Die SQL-Selects hinter den Views werden erst zum Abfragezeitpunkt auf das Star Schema aufgelöst. Der Vorteil dieser Vorgehensweise liegt in der Möglichkeit, die Struktur von Dimensionen und Fakten schnell zu ändern. Konzept der Virtualisierung von Star Schemen Das Konzept des „Logical Data Warehouse“ im Oracle Data Warehouse nutzen 18 Resümee Es wird hoffentlich jetzt niemand sein bestehendes Warehouse wegwerfen oder auf den Kopf stellen, nur um sich ein modernes Look and Feel des „Logical Data Warehouse“ zuzulegen. Aber die Ausführungen haben gezeigt, dass es eine Reihe von Stellen gibt, an denen heute mehr Flexibilität machbar ist. Immer häufiger stehen wir aber auch schon „mit dem Rücken an der Wand“, d. h., die Anforderungen aus den Fachabteilungen überrollen die Möglichkeiten und Ressourcen der WarehouseAbteilung. Es wurde gezeigt, wie mit einfachen Mitteln die Situation etwas entschärft werden kann: Einen neuen technischen Zugriff auf remote liegende Daten zu legen, diese dann über eine View-Definition zu kapseln und als „lokal“ zu präsentieren, ist sicher schneller umgesetzt und mit weniger Kostenrisiko verbunden, als eine weitere ETL-Strecke über ein Projekt zu implementieren. Man sollte sich dennoch darüber bewusst sein, dass ein Remote-Zugriff noch keine echte Integration darstellt. Integration ist erst dann erreicht, wenn die Remote-Daten mit anderen Daten fachlich und strukturell verzahnt sind. Die Vorteile des LDW-Konzeptes sind: Verminderter ETL – Aufwand und damit höhere Reaktionsfähigkeit. Schnelleres Umsetzen von Modelländerungen. Verminderung des Datenvolumens im zentralen Warehouse. Erhöhung der Reichweite eines Data Warehouse, weil ein breiteres Spektrum an Daten zur Verfügung steht. Höhere Aktualität von einigen Daten, da operative Daten unmittelbar einbezogen werden können. Die neuen technischen Möglichkeiten in der Oracle Datenbank, Big Data SQL und die Column-Store In-Memory Option befördern die Diskussion rund um das Logical Data Warehouse. Alfred Schlaucher, Oracle, Januar 2015
