Contenu connexe Similaire à Historisierung und Analyse von Daten aus Oracle Enterprise Manager Cloud Control in Hadoop (20) Plus de OPITZ CONSULTING Deutschland (20) Historisierung und Analyse von Daten aus Oracle Enterprise Manager Cloud Control in Hadoop1. Oracle® Enterprise Manager 12c:
Historisierung und Analyse von Daten aus OEM
Cloud Control in Hadoop
Ingo Reisky
Senior Consultant
OPITZ CONSULTING Deutschland GmbH
Matthias Fuchs
Solutions Architect
ISE Information Systems Engineering GmbH
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 1
Nürnberg, 19.11.2014
2. Vorstellung OPITZ CONSULTING
Mission
Wir entwickeln gemeinsam mit allen
Branchen Lösungen, die dazu führen, dass
sich diese Organisationen besser entwickeln
als ihr Wettbewerb.
Unsere Dienstleistung erfolgt
partnerschaftlich und ist auf eine langjährige
Zusammenarbeit angelegt.
Leistungsangebot
Application Lifecycle Management
IT-Beratung
Business-Lösungen
Managed Services
Training und Coaching
IT-Trends
Märkte
Branchenübergreifend
Über 600 Kunden
29%
Industrie / Versorger /
Telekommunikation
29%
Handel / Logistik /
Dienstleistungen
42%
Öffentliche Auftraggeber / Banken und
Versicherungen / Vereine und Verbände
Eckdaten
Gründung 1990
400 Mitarbeiter
9 Standorte
DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop © OPITZ CONSULTING, © OPITZ I.CONSULTING S.E. GmbH 2014 GmbH 2014
Seite 2
3. Wie OPITZ CONSULTING Big Data versteht
Wir helfen Kunden,
die Möglichkeiten von Big Data zu verstehen
Business Cases in ihrem Unternehmen zu erkennen und ganzheitlich unter
Berücksichtigung bestehender Architekturen zu bewerten
Projekte zielorientiert aufzusetzen und erfolgreich durchzuführen
Business Cases anhand von Proof of Concepts zu verifizieren.
Big Data ist bei OPITZ CONSULTING eines der TOP 3
Zukunftsthemen!
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 3
Big Data = Alter Hut
• IT-Durchdringung der
Geschäftswelt steigt seit
Beginn
• Mooresche Gesetz gilt
immer noch
OPITZ CONSULTING1990
• Database-focused
Company
• große Datenmengen &
komplexe
Anforderungen
OPITZ CONSULTINGt+25
• Individuallösungen,
wenn Standard nicht
ausreicht
• Kontinuierliche Adaption
neuer IT-Trends
Big Data = Chance
• Prozess- und
Interessenstransparenz
dank MachineData
• Wettbewerbsvorteile
dank Kombination
(Mobile+ Big Data +
Cloud + Analytics) 25
4. Enable
eXtreme
Performance.
www.ise-informatik.de
ISE Information Systems Engineering
Copyright (C) ISE GmbH - All Rights Reserved 4
Gegründet 1991
Mitarbeiteranzahl: 50
Hauptsitz in Gräfenberg, Niederlassungen in München und Nürnberg
Schwerpunkte:
Oracle Engineered Systems (Exadata / Exalogic / Exalytics)
Data Warehousing & Business Intelligence
Oracle DB – Migrationen, Optimierungen, Hochverfügbarkeit
Managed Service für Datenbanken, BI und Middlewareapplikationen
Oracle Partner Engineered Systems Award 2013
5. Enable
eXtreme
Performance.
www.ise-informatik.de
ISE Oracle Technology Center
Erstes und einziges Exastack Technology Center in
Deutschland in Nürnberg
Copyright (C) ISE GmbH - All Rights Reserved 5
6. © OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 6
Agenda
1. Big Data aus dem Enterprise Manager?
2. Lösungsansätze im OEM
3. Lösungsansätze in Apache Hadoop
4. Praktischer Lösungsvorschlag
5. Zusammenfassung & Ausblick
7. 1 Big Data aus dem Enterprise Manager?
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 7
8. Das Innovationspotential von Big Data
Mehr speichern
• Rohdaten müssen nicht
mehr gelöscht werden
• Längere Historien
Complex Event
Recognition
• Mehr beobachten
• Schneller erkennen
• Informationsvorsprung
nutzen
Prädikative Analytik
• Prognosen
• Simulationen
Produktverbesserung Betrugserkennung
Erkennung von Attacken
Marktmonitoring für Verkaufschancen
Absatzprognose
Mitarbeitergewinnung
Personalisierte Produktempfehlung Kündigerfrüherkennung
Umsichtige Steuerung Finanzielle Risikoabschätzung
Vorausschauende Instandhaltung
Chancen steigern Risiken minimieren
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 8
9. Der OEM als willkommener Datenstaubsauger
Oracle Enterprise Manager 12c (OEM) sammelt zahlreiche
Kennzahlen (Metriken) auf fast allen Ebenen der IT-Infrastruktur
OEM unterstützt zahlreiche unterschiedliche Zieltypen:
OS-Metriken (Windows, Linux, Unix, …)
Oracle DB-Ziele: DB, GI, RAC, DG, …
Oracle FMW-Ziele: WLS Cluster, OSB, SOA, WCP, WCC, OAM, OVD, …
Non-Oracle DB und MW (z.B. MYSQL DB und Tomcat AS)
Weitere Zieltypen (z.B. HW-LB via snmp)
… bis hin zu Oracle Engineered Systems (z.B. Exadata)
Standardmetriken unterschiedlich je Zieltyp, erweiterbar mit
Metric Extensions oder eigenen Agent Plug-ins
Zusätzlich On-Demand-Funktionen (z.B. Logfile-Viewing)
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 9
10. Beteiligte Systemkomponenten im OEM 12c R4
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 10
11. Rolle des OEM in der Praxis
Oft steht in der Praxis der Einsatz als Monitoring-Werkzeug
im Vordergrund:
Hauptfunktion Überwachung/Alarmierung im Fokus
Nebenfunktionen Kapazitätsplanung, Reporting, … nicht im Fokus
Alte Metrikdaten werden oft zeitnah aggregiert und später
ganz gelöscht, da sie für Überwachung und Alarmierung
nicht mehr relevant sind
Frische Incidents und Problems, also junge Metriken, am interessantesten
1-2 Wochen alte Metriken nur noch für z.B. Ursachenforschung gebraucht
Danach Schnee von gestern
Damit stehen die Metrikdaten aber nicht in Rohform und
nicht dauerhaft für eigene Auswertungen zur Verfügung
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 11
12. Der Lebenszyklus der OEM Metrikdaten
Vier zentrale DB-Views im OEM Repository (SYSMAN):
MGMT$METRIC_CURRENT: jüngster Metrikwert
MGMT$METRIC_DETAILS: gesammelte Rohdaten
MGMT$METRIC_HOURLY: Stundenwerte
MGMT$METRIC_DAILY: Tageswerte
Reduktion des Datenvolumens durch Aggregation:
Standardwerte Aufbewahrungszeit: Rohdaten für 7 Tage; Stunden-Daten für
31 Tage; Tages-Daten für 1 Jahr (keine Monats-/Jahres-Daten)
Konfigurierbar (MOS Doc ID 1405036.1 => Änderung Partitionierung)
Kompromiss zwischen Datenwachstum im Repo und
Aufbewahrungszeit (retention times)
Rohdaten (höchster Detaillierungsgrad) sind also in der
Standardkonfiguration schon nach einer Woche weg!
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 12
13. OEM Reporting-Werkzeuge & Datenmodell
Oracle Information Publisher (IP):
Integriert in OEM 11g und 12c, bewährte Reports
Produkt schon länger abgekündigt, keine langfristige Lösung
Oracle Business Intelligence Publisher (BIP):
In OEM 12c integriert, für Reports mit begrenzter Komplexität gut geeignet
Komplexe Abfragen mit dem BIP auf das OEM Repo dauern zu lange für
interaktives Online-Reporting und können hohe DB Last verursachen
Bugs: Seit OEM 12c R4 nun BIP 11.1.1.7 möglich plus Bundle Patches
SQL Zugriff auf Repository, SQL Developer: MGMT$ Views
Grundsätzlich gelten für diese die Einschränkungen des
OEM Datenmodells:
Aufbewahrungsfristen der Metrikdaten (Purging Policies)
Auf effektives Schreiben der vom OMS empf. Agent-Uploads hin optimiert
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 13
14. Alternativen zu den OEM Reporting-Werkzeugen?
Aufbewahrungsfristen der Metrikdaten im OEM Repository
könnten erhöht werden, aber:
Performance des OEM muss gewährleistet bleiben und hohe
Kosten der Datenhaltung stehen dem entgegen…
Kostenargument gilt auch bei Transfer der Metrikdaten in dediziertes, hoch-performantes
DWH/RDBMS
Datenmengen können ziemlich groß werden… (in der Praxis zusätzliche
Metrik-Rohdaten in Größenordnung 50-100 GB/Monat gesehen)
Lösungsvorschlag: Verwendung von Commodity Hardware
und Open Source Software: Apache Hadoop
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 14
15. 2 Lösungsansätze im OEM
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 15
16. Ansatzpunkte im OEM im Überblick
An welchen Stellen im OEM System können Metrikdaten
abgegriffen werden?
Zentrale Ansatzpunkte:
Direkte Datenübernahme aus der OEM Repository DB
SQL Zugriff, DB Link, Export, …
Verwendung von OEM Data Exchange Connectors
Spezieller Typ von Konnektor für Datenaustausch, JMS-basiert
Dezentrale Ansatzpunkte:
OEM Management Agents auf den Zielsystemen
Verwendung von OEM Metric Extensions (früher: „User-Defined Metrics“)
Verwendung von Custom Agent Plug-ins (Hardcore)
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 16
17. Ansatzpunkte für den Datentransfer im OEM 12c
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 17
18. Direkte Datenübernahme aus OEM Repository DB
Haupt-Views können ausgelesen werden: MGMT$...
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 18
19. Direkte Datenübernahme aus OEM Repository DB
DDL von View MGMT$METRIC_HOURLY (Beispiel):
Leider kein Primary Key…
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 19
20. Verwendung von Data Exchange Connectors
Data Exchange-Konnektoren sind eine Funktionalität im
OEM 12c, um externe Systeme per Java Messaging Service
(JMS) anzubinden, eingehend oder ausgehende Nachrichten
Es gibt Werkzeuge im Hadoop-Ökosystem, die eingehende
JMS-Nachrichten aufnehmen können (z.B. Apache Flume)
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 20
21. Verwendung von Metric Extensions (ME)
ME werden zentral im OMS gepflegt, dezentral auf die
Agenten deployed und können dort beliebige Skripte
ausführen => möglicher Weg, Hadoop direkt anzusprechen?
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 21
22. Verwendung von Custom Agent Plug-ins
Falls die Möglichkeiten von Metric Extensions den
Anforderungen nicht genügen, können via Oracle
Extensibility Development Kit (EDK) eigene Agent Plug-ins
entwickelt werden.
Sind Java-basiert => Möglichkeit, den Hadoop Cluster direkt
per Webservice Call anzusprechen?
Näheres siehe „Cloud Control Extensibility Programmer's
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 22
Guide “.
Analog zu Metric Extensions sind auch hier ggf. Netzwerk-
/Firewall-Freischaltungen für die Kommunikation Host
Target – Hadoop erforderlich.
23. 3 Lösungsansätze in Hadoop
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 23
24. Bestandteile von Apache Hadoop
Hadoop Common:
enthält von den Komponenten gemeinsam genutzte Utilities
Hadoop HDFS (“Hadoop Distributed File System”):
ein verteiltes, hochverfügbares Datei-System, welches auf
Schreibzugriff und große Dateien hin optimiert ist
Hadoop YARN (“Yet Another Resource Negotiator”):
Ressourcen-Manager
Hadoop MapReduce (MR):
der ursprüngliche Map-and-Reduce Algorithmus
Zweck: Parallele Ausführung von Java-Programmen auf
großen Filesystem-Daten, die verteilt über Daten-Knoten mit
rel. kostengünstiger Hardware „von der Stange“ erfolgt
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 24
25. Wo ist die Brücke zwischen den Welten?
Problem: Strukturierte
Daten aus RDBMS lassen
sich nicht einfach mit
unstrukturierten Daten in
HDFS kombinieren…
Lösung: Apache Squoop
SQL-nach-Hadoop (ETL), leichter
Import aus RDBMS nach Hadoop,
erzeugt MapReduce Code,
Integration mit Apache Hive
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 25
26. Übersicht Hadoop Ökosystem
Die vier Kernkomponenten werden durch einen bunten
Blumenstrauß an Bearbeitungswerkzeugen ergänzt!
Processing Layer
Stinger
Resource Management YARN + MapReduce
Storage Layer
Filesystem (HDFS)
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 26
27. Hadoop Processing Layer und Daten-Basis
Basis kann jegliche Art von unstrukturierten Daten sein,
Nutzung ist abhängig von der Processing Layer Erweiterung
Bilder
Logfiles
Filme
Dokumente
Die Analyse der Daten erfolgt über YARN Ressourcen-
Management verteilt im Cluster
Die Geschwindigkeit ist somit nur noch von der Anzahl der
Datenverarbeitungsknoten und dem Storagesystem
abhängig
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 27
29. Gewählter Architekturansatz
SQL-Import von OEM Metrikdaten
Datei-Import aus Filesystemen (Logfiles von OEM-Zielen)
Auswertung mit ausgewählten Werkzeugen
Analytic
output
HDFS
Weblogs
CC
RDBMS
Flume
Elasticsearch
YARN/MR
SQOOP
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 29
30. Verwendete Werkzeuge
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 30
Sqoop
SQL to Hadoop – Integration in Hadoop um Daten als
relationalen DBs in HDFS zu laden
Flume
Tool zum einsammeln von Logs
verteilt, hochverfügbar
Elasticsearch
Server für Enterprise-Suche
(mandantenfähig, volltextfähig),
basierend auf JSON-Dokumenten
31. Sqoop Daten-Import
Abfrage der Metadaten in der Oracle DB zur Partitionierung
der MapReduce Jobs
Übergabe der Jobs an YARN
Start der Jobs
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 31
32. Sqoop Workflow
Sqoop DB Load
Store Data in HDFS
Load Data into HIVE
Analytic Queries mit
Impala oder Big Data SQL
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 32
33. Ergebnis: Sqoop Job erfolgreich
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 33
34. Ergebnis: Dateien im Sqoop Ausgabe-Verzeichnis
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 34
35. Ergebnis: Externe Tabelle in Hive anlegen
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 35
36. Ergebnis: Tabelle in Hue
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 36
37. Ergebnis: Beispieldaten in Hue
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 37
38. Nächste Schritte
Automatisierung mit Oozie:
Workflow anlegen, um die zuvor gezeigten manuellen
Schritte zu automatisieren
Auswertung der Daten in Hive mit Standard-BI-Tools
Echtzeit-Abfragen über z.B. Cloudera Impala
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 38
39. Flume Integration
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 39
Weblogs
Flume
Weblogs
Flume HDFS
Elastic Search
Kopieren der
Logs,
komprimieren
Weitere
Auswertung mit
z.B. PIG
Speichern der
Logdaten als
Jason, Real Time
Index,
Auswertung mit
Kibana
40. Konfiguration Flume-Agent für Log-Kopie
<…>
source_agent.sources = wls_server</pre>
source_agent.sources.wls_server.type = spooldir
source_agent.sources.wls_server.channels = memoryChannel
source_agent.sources.wls_server.fileHeader = true
source_agent.sources.wls_server.deletePolicy = immediate
source_agent.sources.wls_server.spoolDir =
/.../user_projects/domains/base_domain/logrotate
#source_agent.sources.wls_server.ignorePattern =
soa_server1.log
<…>
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 40
41. Log Files in Hue
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 41
42. Inhalt der Logs
Weiterverarbeitung mit z.B. R oder PIG
Und laden in Elasticsearch
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 42
43. Flume nach Elasticsearch
Weitere Konfiguration Flume-Agent
<…>
e_agent.sources.tail.type = exec
e_agent.sources.tail.command = tail -f --retry /u01/12.1/oracle/middleware/
user_projects/domains/base_domain/servers/soa_server1/logs/soa_server1-diagnostic.log
e_agent.sources.tail.interceptors=i1 i2 i3
e_agent.sources.tail.interceptors.i1.type=regex_extractor
e_agent.sources.tail.interceptors.i1.regex = [(.*)] [(.*)] [(.*)] [(.*)] [(.*)]
[(.*)] [(.*)] [(.*)] [(.*)] (.*)
e_agent.sources.tail.interceptors.i1.serializers = s1 s2 s3 s4 s5 s6 s7 s8
e_agent.sources.tail.interceptors.i1.serializers.s1.name = date
e_agent.sources.tail.interceptors.i1.serializers.s2.name = mangedserver
e_agent.sources.tail.interceptors.i1.serializers.s3.name = type
e_agent.sources.tail.interceptors.i1.serializers.s4.name = addon
e_agent.sources.tail.interceptors.i1.serializers.s5.name = ComponentID
e_agent.sources.tail.interceptors.i1.serializers.s6.name = tid
e_agent.sources.tail.interceptors.i1.serializers.s7.name = userID
e_agent.sources.tail.interceptors.i1.serializers.s8.name = ecid
<…>
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 43
44. Flume-Meldungen in Kibana
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 44
45. Kibana Analytics
Visual Analytics
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 45
in Kibana
Beispiel
Fehlerklassen
46. 5 Zusammenfassung und Ausblick
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 46
47. Zusammenfassung
Oracle Enterprise Manager 12c sammelt bereits im Standard
eine große Vielfalt von Metriken für heterogene Arten von
Zielen (DB, Middleware, Apps, Engineered Systems, …)
Datenmodell des OEM ist historisch auf Monitoring &
Alarmierung ausgerichtet, Repository hat Einschränkungen
bzgl. Online-Auswertungen / Information Discovery
Durch den Transfer der Metrik-Daten in einen Hadoop
Cluster können diese Einschränkungen umgangen werden:
Rohdaten speicherbar, eigene Datenmodelle verwendbar
Sind die Metrikdaten in Hadoop verfügbar, bieten sich dort
alle bekannten Möglichkeiten der Werkzeuge des Hadoop-Ökosystems:
Schema-on-Read, Suche, Visualisierung,…
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 47
48. © OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 48
Ausblick
Rolle des OEM wird durch Engineered Systems wichtiger,
zukünftig noch höheres Volumen und Vielfalt der
Metrikdaten zu erwarten. Mehr Mehrwert!
Oracle trägt dem Rechnung: „Oracle Analytics Cloud “
kürzlich angekündigt. Big data as a service – BDaaS
https://www.oracle.com/corporate/pressrelease/analytics-cloud-092914.html
„Leveraging Oracle Big Data SQL, Hadoop, and Oracle Database as a
Service together”
Partnerschaft zwischen Oracle und Cloudera, einer der
führenden Hadoop-Distributionen:
Cloudera in Oracle Big Data Appliance enthalten (Engineered System)
“Oracle Big Data Lite Virtual Machine” ausprobieren, VBox VM enthält in
aktueller Version 4.0.1 u.a. Cloudera CDH 5.1.2 – viel Spass beim Testen!
49. Oracle Unified Query
Oracle Integration Hadoop
Abfrage der Daten über SQL
Die Daten können in Hadoop
oder einer Oracle DB liegen
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 49
50. Oracle Hadoop Integration
Oracle Hadoop Erweiterung
Query Offloading to Hadoop
SparkSQL Hive Impala
Hive Metastore
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 50
Oracle Big
Data SQL
…
Table Definitions:
movieapp_log_json
Tweets
avro_log
Metastore maps DDL to Java access classes
51. Ansprechpartner bei OPITZ CONSULTING
Ingo Reisky
Senior Consultant, Infrastructure Consulting
OPITZ CONSULTING Deutschland GmbH
ingo.reisky@opitz-consulting.com
Telefon +49 89 680 098 -1489
Mobil +49 172 204 8789
youtube.com/opitzconsulting
@OC_WIRE
slideshare.net/opitzconsulting
xing.com/net/opitzconsulting
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 51
52. Ansprechpartner bei ISE
Matthias Fuchs
Solutions Architect
ISE Information Systems Engineering GmbH
matthias.fuchs@ise-informatik.de
Telefon +49 9192 9929 505
Mobil +49 172 8288 751
Blog - http://hias222.wordpress.com
LinkedIn - https://www.linkedin.com/pub/matthias-fuchs/2/6a6/620
Xing - https://www.xing.com/profile/Matthias_Fuchs17
Twitter - https://twitter.com/Hias222
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 52
Notes de l'éditeur Discuss Oracle’s Experience with Exadata to show continuity
Tested the waters with data warehousing appliance
We were very successful with HP
Found it was very appropriate for OLTP in addition to data warehousing. We have now come back to the market with Exadata V2 with SUN as a hardware partner. This was tremendously successful as well
Many customers told us that their interested was not only in OLTP and DW but also in database consolidation and this was a big part of what they saw in Exadata V2
Customers would ask about the rest of the infrastructure – what about the middle tier?
Oracle is in a position to have conversations with customers - Not just a Data Warehousing, OLTP or Middleware appliance
Question from customers: What about enterprise-wide standardization, consolidation, PaaS and (ultimately) Private cloud?
This is where Exalogic fits in
Not just another product
Not just an appliance
Exalogic is the next step in Oracles vision for the data center of the 21st century!
We are talking about something much bigger than appliances
Exalogic/Exadata are not solution building blocks, they are datacenter building blocks
Kernaussage: Motivation für den Vortrag schildern Kernaussage 1: Heterogene Vielfalt der Ziel-Typen! DB, MW, App Mgt., bis hin zu Engineered Systems…
Kernaussage 2: Heterogene Metric Daten laufen zentral im Repo zusammen https://docs.oracle.com/cd/E24628_01/doc.121/e24473/repository.htm#EMADM12782 Hadoop Common: The common utilities that support the other Hadoop modules.
Hadoop Distributed File System (HDFS™): A distributed file system that provides high-throughput access to application data.
Hadoop YARN: A framework for job scheduling and cluster resource management.
Hadoop MapReduce: A YARN-based system for parallel processing of large data sets.