SAP BW Apache Hadoop-Big Data-System

Das Internet der Dinge, Big Data und eine Fischertechnik-Fabrik
Jan Wiesemann
Architect

Die Herausforderung

Das Internet der Dinge (IoT) ist einer jener Begriffe, die sich inflationär in Nachrichten, Vorträgen und Veröffentlichungen finden und deren häufige Verwendung zum schnellen Überdruss beim geneigten Leser führen. Die natürliche Reaktion auf das Auftreten solcher Modebegriffe ist das Abwarten, ob die Welle nicht genauso schnell abklingt wie sie aufgekommen ist. Wiewohl einzelne Begriffe und Schlagwörter wieder zu Recht im Orkus des Vergessens verschwinden werden, so ist doch mit an Sicherheit grenzender Wahrscheinlichkeit davon auszugehen, dass die hinter den Begriffen stehende Problematik bestehen bleibt, ja sogar immens an Grösse und Bedeutung gewinnen wird:

1. Die Datenmengen werden immer grösser.

Zu dieser Behauptung werden jedem Einzelnen sicherlich genügend Beispiele der letzten Zeit einfallen. Ob es nun selbstfahrende Autos sind, die einen Strom an Daten aussenden und empfangen, ob es die Supermarkt-Sparkarten sind, die unser Konsumverhalten nicht nur verbilligen, sondern auch registrieren, ob es neue Apps auf den Smartphones oder Smartwatches sind, die uns nicht nur unterstützen, sondern auch kategorisieren, die Liste an Beispielen ist nicht nur bereits lang, sie scheint auch mit immer höherer Geschwindigkeit an Länge zu gewinnen.

Gelegentlich fällt einem diese Entwicklung an einzelnen Beispielen besonders auf. So stach mir ein Bericht auf SPIEGEL ONLINE vom 15.11.2017 ins Auge, in dem von einer Pille berichtet wurde, die ihre Einnahme meldet und die Daten in die Cloud sendet: Sinn und Zweck dieser Pille mit Daten ist die Überwachung der regelmässigen Einnahme von Medikamenten. Sofort stellen sich weitere Fragen: meldet die Pille auch, wenn sie z.B. innerhalb einer Stunde den Körper wieder verlassen hat (das lässt auf Erbrechen schliessen, damit zählt die Pille als nicht eingenommen)? Meldet sie weitere Zwischenstationen auf dem Weg durch den Körper? Dieses Beispiel zeigt sehr deutlich, wie wir als Personen zur Quelle eines Datenstroms werden, der in seinen Ausmassen ins Ungeheure anwachsen kann.

2. Die Datenqualität ist eher mässig gut.

In der Masse von Daten und Meldungen sind Fehler mit grösserer Häufigkeit vertreten. Es kommt nun mal zu temporären Falschmeldungen (Sensor defekt, die Smartwatch kann aufgrund von körperlicher Bewegung mal für eine Zeit die Herzfrequenz nicht ermitteln, usw.) und aufgrund der Masse an Daten ist es nicht möglich, sich die Zeit zu nehmen, alle falschen Daten zu finden und zu eliminieren. Sind falsche Daten systematisch erkennbar, so können sie sicherlich ausgefiltert werden und bei grösserer Zahl lohnt es sich dann auch zu versuchen, die Ursache zu beseitigen. Aber allein aufgrund der grossen Zahl an Datenlieferanten muss man einen Bodensatz an falschen Werten akzeptieren und in Kauf nehmen.

Aus der Sicht eines Enterprise Data Warehouse ergeben sich damit neue Herausforderungen:

Konsequenzen für die Architektur

Im ersten Teil dieses Blogs habe ich die Herausforderungen benannt, die Big Data für ein Data Warehouse darstellt.Für die Big Data-Architektur eines solchen EDW im konkreten Fall eines SAP BW on HANA oder SAP BW/4HANA ergeben sich damit bereits einfache Schlussfolgerungen:

All diese Überlegungen sind doch immer wieder recht abstrakt. CubeServ hat daher eine Fabriksimulation der Firma Fischertechnik erworben, um einmal ganz konkret eine solche Architektur aufzubauen und zu demonstrieren. Die Fabrik besteht aus einem Hochregallager, aus einem zentralen Kran, aus einem Brennofen und einer Sortieranlage. Die Güter der Fabrik sind weisse, rote und blaue Plastikzylinder, die im Hochregal jeweils noch in rechteckigen schwarzen Boxen liegen.

Die Fabrik in Aktion

Ein farbiges Gut wird aus der Sortierrutsche für Weiss genommen (wo es fälschlicherweise liegt), vom Kran zum Brennofen gebracht, von dort zum Sortierband und dort dann in die richtige Rutsche einsortiert.

Die einzelnen Bereiche werden separat gesteuert, aber ein kompletter Kreislauf kann so aussehen: ein Gut wird aus dem Hochregal entnommen, der zentrale Kran bringt es zum Brennofen, dort wird es (symbolisch durch blitzende Lichter) bearbeitet. Aus dem Brennofen kommt es zur Sortieranlage, eine Fotozelle erkennt die Farbe und entsprechend wird es in eines von drei Rutschen einsortiert. Von dort wird es wieder vom Kran entnommen und zum Hochregal gebracht, wo es wieder einsortiert wird. Die einzelnen Bereiche verfügen zum Teil über Sensoren wie Lichtschranken oder Fotozelle zur Farberkennung und über Motoren.

Die Fabrik wird bereits komplett montiert geliefert, allerdings ohne Steuergeräte und demzufolge auch ohne entsprechende Programmierung. Um die Fabrik zu steuern, wurden acht Siemens Logo 8 Steuergeräte an die entsprechenden Sensoren und Motoren angeschlossen. Die Steuerung in der Logo-Sprache wurde dann von unserem Basis-Experten, Peter Straub, vorgenommen. Diese Programmierung ist recht aufwändig, die zur Verfügung gestellten Bestandteile von Sprache und Fabrik sind sehr einfach gehalten. Es gibt wenige Sensoren. Soll z.B. der zentrale Kran in Grundstellung gedreht werden, so wird er einfach eine bestimmte Zeit in eine bestimmte Richtung gedreht. Da er nicht über einen festmontierten Anschlag hinausdrehen kann, ist er damit in 0-Stellung. Die Bestandteile der LOGO-Sprache sind ebenfalls sehr elementar (UND-Gatter, ODER-Gatter, Zeitverzögerung und ähnliches). Es gibt z.B. keine komfortablen Variablen, die man z.B. für die Lagerhaltung nutzen könnte. Für die Verdrahtung der Geräte und der Programmierung der Fabrik kamen dann doch in etwa vier Wochen Aufwand zusammen.

Der Big Data-Cluster

In den ersten beiden Teilen dieses Blogs haben wir die Fischertechnik Fabriksimulation gezeigt. Diese Fabriksimulation soll nun kontinuierlich Daten erzeugen, die einerseits in einem Big Data-Cluster landen sollen, andererseits mit Mitteln des SAP BW oder mit SAP Analytics for Cloud reportbar sein sollen.

Als Big Data-Cluster wurde bei uns eine Cloudera-Installation aufgebaut. Ähnlich wie bei Linux, dem kostenlosen open-Source-Betriebssystem, das man in vorkonfigurierten und dann kostenpflichtigen Versionen erwerben kann (z.B. Suse Linux, RedHat,…), gibt es von Apache Hadoop ebenfalls vorkonfigurierte Installation wie z.B. von Hortonworks oder von Cloudera. Wir haben uns für Cloudera entschieden und haben eine 60-Tage-kostenlose Enterprise Edition installiert. Da es sich nur um eine Demoanwendung handelt, ist es auch ein einfacher Cluster mit nur einem Knoten geworden.

Hadoop kommt mit einer ganzen Reihe von Services daher, die dem Laien erstmal wenig sagen und in ihrer Anzahl und Bedeutung zunächst sehr verwirrend sind.

Hadoop kommt mit einer ganzen Reihe von Services daher, die dem Laien erstmal wenig sagen und in ihrer Anzahl und Bedeutung zunächst sehr verwirrend sind.

Die Fischertechnik Fabrik wird ja über die Siemens Logo Steuergeräte gesteuert. Die Steuergeräte bzw. ihre Programmieroberfläche bietet nun die Möglichkeit, die Zustände aller vorhandenen Eingänge und Ausgänge in periodischen Abständen (z.B. 1s) in ein Protokollfile wie z.B. Log.csv zu schreiben. 

Es werden immer alle Ein- und Ausgänge geschrieben, wir haben uns zunächst aber nur auf drei beschränkt, und zwar die Steuerungen für die Sortier-Rutschen, die weisse, rote und blaue Plastikzylinder voneinander trennen, abhängig von der erkannten Farbe in der Photozelle.

Damit wurde ein möglichst einfacher Bericht aufgebaut, nämlich ein einfacher Zähler, der gezählt hat, wie oft eine 1 vom Motor Q2 (weiss), Q3 (rot) oder Q4 (blau) gemeldet wurde. Dies entsprach dann der entsprechenden Anzahl an durchgelaufenen Plastikgütern.

Die Siemens-Steueroberfläche schreibt also permanent in ein lokales CSV-File auf dem Laptop, mit dem die kleine Anlage gesteuert wird. Dies ist also die Quelle unserer Sensordaten. Auf dem Cloudera-System wurde nun per Samba das Directory, in dem dieses Protokollfile geschrieben wird, gemountet. Damit war aus Sicht des Cloudera-Systems lokal ein CSV-File vorhanden. Gleichzeitig bestand keine Gefahr, dass eine kurzzeitige Unterbrechung der Verbindung zum Abbruch des Schreibvorgangs führt. Das Schreiben lief permanent weiter und sollte die Verbindung via Internet einmal unterbrochen sein, so würden die neuen Daten mit der nächsten Wiederverbindung wieder abholbar sein.

Dieses lokal sichtbare CSV-File, das LogFile.csv, wird nun mit Hilfe eines Flume-Agenten permanent auf ein Ziel in Kafka geschrieben. Die entsprechende Konfigurationsanweisung, die eine Quelle, ein Ziel (Senke) und einen Kanal definiert, lautet wie folgt:

#————————————
tier1.sources = r1
tier1.sinks = k1
tier1.channels = c1
# Describe/configure the source
tier1.sources.r1.type = TAILDIR
tier1.sources.r1.filegroups = f1
tier1.sources.r1.filegroups.f1 = /samba/FischerTechnik/LOG/LogFile.csv
tier1.sources.r1.positionFile = /tmp/flume-position_3.json
# Describe the sink
tier1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink
tier1.sinks.k1.topic = sensor_csv
tier1.sinks.k1.brokerList = quickstart.cloudera:9092
tier1.sinks.k1.batchSize = 1
# Use a channel which buffers events in memory
tier1.channels.c1.type = memory
tier1.channels.c1.capacity = 100000
tier1.channels.c1.transactionCapacity = 10000
# Bind the source and sink to the channel
tier1.sources.r1.channels = c1
tier1.sinks.k1.channel = c1
#————————————

Für die Einrichtung dieser Konfiguration nochmal herzlichen Dank an die Experten unserer Partnerfirma für Hadoop-Systeme, die Ultra Tendency GmbH (www.ultratendency.com), und hier speziell an Matthias Baumann, der uns mit seiner Hadoop-Expertise schon einige Mal weitergeholfen hat.

Damit liegt nun im Cloudera im HDFS-Filesystem die Datei sensor_csv vor, die im Sekundentakt neue Daten erhält. Um dieses CSV-File für SQL-Abfragen verfügbar zu machen, wird in Hive folgendes Kommando abgesetzt:

CREATE EXTERNAL TABLE sapt90.zcssensorq (
      key varchar(6),
      time VARCHAR(8),
      value VARCHAR(4),
      sensor VARCHAR(20)
    )
STORED BY “org.apache.hadoop.hive.hbase.HBaseStorageHandler”
WITH SERDEPROPERTIES (
       “hbase.columns.mapping” =
       “:key,default:time,default:value,default:sensor”
    )
    TBLPROPERTIES(“hbase.table.name” = “sensor_csv”)

Dieses Kommando erzeugt eine leere Tabellenhülle zcssensorq (in einem Schema mit dem Namen sapt90) mit 4 Spalten (key, time, value, sensor) und teilt dem System mit, dass der Inhalt dieser Tabelle sich in einer hbase-Tabelle mit dem Namen sensor_csv befindet. Auf diese Weise können nun im Hue-Service einfache Hive- oder Impala-Abfragen gestartet werden, z.B. select * from zcssensorq;:

Die Sensordaten der Fischertechnik-Fabrik werden damit kontinuierlich geschrieben und liegen als File bzw. als Tabelle im Hadoop System verfügbar vor. Wie können diese Daten nun für ein Reporting verfügbar gemacht werden? Darum geht es im nächsten Teil dieses Blogs.

Zugriff von einer SAP HANA aus via Smart Data Integration (SDI)

In den beiden vorherigen Teilen dieses Blogs habe ich beschrieben, wie die Fischertechnik-Fabriksimulation Daten in Form eines CSV-Files erzeugt und wie diese Daten in das Hadoop Cluster gelangen und dort sogar als Tabelle zur Verfügung stehen. In diesem Teil geht es nun um die verschiedenen Möglichkeiten, wie nun über den Inhalt dieser Tabelle berichtet werden kann. Es gibt zwei relativ einfache Möglichkeiten, wie die Daten dieser Hadoop-Tabelle für SAP Tools zur Verfügung gestellt werden können:

1. In einer HANA-Datenbank via SDA (Smart Data Access) bzw. SDI (Smart Data Integration). Die Daten können dann z.B. in einer SAP Analytics for Cloud konsumiert werden (hierzu ist dann kein SAP BW-System nötig) oder in einem SAP BW-System konsumiert werden.

2. Mit Hilfe der Middleware GLUE unserer Partnerfirma Datavard ist es sehr einfach, mit ABAP-Transaktionen Tabellen in Hadoop zu erzeugen, sie auszulesen oder Inhalte zwischen in Hadoop liegenden Tabellen und ABAP-Tabellen hin- oder herzuschieben. Dazu ist nicht zwingend eine HANA-Datenbank nötig, aber ein ABAP-Application Server. Ich möchte beide Möglichkeiten hier vorstellen.

SDA / SDI

SDA / SDI SDA bzw. SDI sind von der SAP ausgelieferte Konnektor-Bibliotheken. Sie ermöglichen, eine remote-Datenbank anzuschliessen und zu den Tabellen dieser remote Datenbank virtuelle Links zu generieren. Auf diese virtuellen Links kann dann zugegriffen werden, als würde es sich um lokale Tabellen in der HANA Datenbank handeln. Die SDI-Adapter sind dabei technologisch weiter fortentwickelt und verfügen über zusätzliche Fähigkeiten im Vergleich zu den SDA-Adaptern. Z.T. sind sie z.B. fähig, nur die Delta-Änderungen zu extrahieren, indem sie nicht die Tabellen, sondern die Changelogs auswerten. Ob und über welche Fähigkeiten die Adapter verfügen, muss man im Einzelfalle prüfen, z.B. im Hadoop-Fall verfügen die Adapter über diese Delta-Fähigkeit nicht. Des Weiteren sind die SDI-Adapter im Gegensatz zu SDA zusätzlich kostenpflichtig.

Wir haben unsere HANA-Datenbank (HA4) zu Testzwecken sogar mit zwei verschiedenen SDI-Adapter angeschlossen, einmal über den SDI-HiveAdapter und einmal über den SDI-ImpalaAdapter.

Damit ist kann man nun leicht virtuelle Tabellenlinks (hier im Schema DATA_EXTERN) anlegen, mit deren Hilfe auf die Originaltabelle zugegriffen werden kann.

Dies funktioniert auch ganz wunderbar, wie z.B. folgende Abfrage zeigt:

Visualisierung mittels CalculationView und SAP Analytics Cloud

In den vorherigen Teilen dieses Blogs wurde gezeigt, wie die Sensordaten der Fabriksimulation schliesslich als Tabelle (genauer: als Tabellenlink) in der SAP HANA verfügbar gemacht wurde. Der nächste Schritt wäre nun beispielsweise in der HANA einen gescripteten (oder alternativ auch graphischen) CalculationView anzulegen, der die Meldungen der Motoren Q2, Q3 und Q4 in etwa wie folgt liest (am Beispiel Q2):

SELECT count(*) FROM “DATA_EXTERN”.”IMPALA_ZCSSENSORQ” where “sensor” = ‘Q2’ and “value” = ‘1’;

Leider sind wir dabei aber gegen einen Bug im SAP-Adapter gelaufen, der Adapter produziert eine fehlerhafte Abfrage mit unsinnigen „N“-Literalen in der Query:

Could not execute ‘SELECT count(*) FROM “DATA_EXTERN”.”IMPALA_ZCSSENSORQ” where “sensor” = ‘Q2’ and “value” = ‘1” in 89 ms 673 µs . SAP DBTech JDBC: [403]: internal error: Error opening the cursor for the remote database Failed to execute query [SELECT COUNT(*) FROM `sapt90`.`zcssensorq` `IMPALA_ZCSSENSORQ` WHERE (`IMPALA_ZCSSENSORQ`.`sensor` = N’Q2′) AND (`IMPALA_ZCSSENSORQ`.`value` = N’1’)]. for query “SELECT COUNT(*) FROM “””sapt90″”.””zcssensorq””” “IMPALA_ZCSSENSORQ” WHERE “IMPALA_ZCSSENSORQ”.”sensor” = ‘Q2’ AND “IMPALA_ZCSSENSORQ”.”value” = ‘1’ “

Dieser Fehler im Impala-Adapter wird bereits im SAP-Hinweis „2562391 – Keine SQL-Abfrage gegen eine virtuelle Impala-Tabelle mit Literalzeichenfolge in der WHERE-Bedingung“ beschrieben. Die Lösung besteht leider in keinem einfachen Patch, sondern der benutze SDI-Agent vom Release 1.0 muss durch eine 2.0-Installation ersetzt werden. Da vorhandene Verbindungen, die diesen Agenten benutzen, dabei verloren gehen und neu angelegt werden müssen, wurde die Installation eines neuen 2.0-Agenten separat vorangetrieben, die Modellierung aber mit dem fehlerhaften 1.0-Agenten fortgesetzt, um doch möglichst schnell einen funktionierenden Prototypen zu erhalten. Da nun gegen die Impala-Adapter keine WHERE-Bedingungen gefeuert werden dürfen und doch Impala wegen der besseren Geschwindigkeit im Vergleich zu Hive verwendet werden sollte, wurde folgendes gemacht:

1. Bereits auf der Hadoop-Seite wurde neben der Tabelle zcssensorq auch die Tabellen zcssensorq2, zcssensorq3 und zcssensorq4 gefüllt, und zwar nur für die Tabellenzeilen, bei denen der Sensorwert = 1 war. Die Tabellen enthalten also nur die Aktiv-Meldungen des entsprechenden Q-Sensors und sonst nichts. Damit müssen nur die Zeilen der Tabelle gezählt werden ohne jede WHERE-Bedingung.

2. Es wurde in der HANA ein CalculationView angelegt, der folgendes Zählen durchführt:

   tmp1 = select count( * ) as “COUNT_Q2” from    “DATA_EXTERN”.”IMPALA_ZCSSENSORQ2″;
   tmp2 = select count( * ) as “COUNT_Q3” from    “DATA_EXTERN”.”IMPALA_ZCSSENSORQ3″;
   tmp3 = select count( * ) as “COUNT_Q4” from    “DATA_EXTERN”.”IMPALA_ZCSSENSORQ4″;
   var_out = select “COUNT_Q2”, “COUNT_Q3”, “COUNT_Q4” from :tmp1, :tmp2, :tmp3;

Leider führt aber selbst dieses WHERE-freie Coding zu einem Abfragefehler aufgrund des Bugs im Impalaadapter. Grund ist, dass die HANA diese Abfrage optimiert und dabei dich wieder WHERE-Bedingungen entstehen. Als Workaround wurde das System gezwungen, diese Optimierung sein zu lassen und die Abarbeitung wirklich sequentiell vorzunehmen. Dies gelang durch die folgenden Befehle, die die entscheidenden Worte „SEQUENTIAL EXECUTION“ enthalten:

drop procedure “_SYS_BIC”.”pg.ccedw.sfb18/ZTS1_CV_SFB_COUNTER_Q24/proc”;
create procedure “_SYS_BIC”.”pg.ccedw.sfb18/ZTS1_CV_SFB_COUNTER_Q24/proc” ( OUT var_out
_SYS_BIC”.”pg.ccedw.sfb18/ZTS1_CV_SFB_COUNTER_Q24/proc/tabletype/VAR_OUT” )
language sqlscript sql security definer reads sql data
as 
 /********* Begin Procedure Script ************/

 BEGIN SEQUENTIAL EXECUTION
     tmp1 = select count( * ) as “COUNT_Q2” from “DATA_EXTERN”.”IMPALA_ZCSSENSORQ2″;
     tmp2 = select count( * ) as “COUNT_Q3” from “DATA_EXTERN”.”IMPALA_ZCSSENSORQ3″;
     tmp3 = select count( * ) as “COUNT_Q4” from “DATA_EXTERN”.”IMPALA_ZCSSENSORQ4″;   
     var_out = select “COUNT_Q2”, “COUNT_Q3”, “COUNT_Q4” from :tmp1, :tmp2, :tmp3;
END /********* End Procedure Script ************/

Dieser Trick ist natürlich nur ein temporärer Workaround und z.B. nicht stabil gegen die erneute Aktivierung des CalculationViews. Als Notlösung zählt aber nun dieser gescriptete CalculationView wie gewünscht die Tabelleneinträge:

Die Dauer zwischen Auslösen des entsprechenden Motors und dem Hochzählen des Zählers beträgt dabei ca. 4 Sekunden. Dieser View wurde nun in SAP Analytics for Cloud eingebunden. Leider gibt es dort keine Darstellung, die sich selbständig periodisch aktualisiert, daher muss man leider aktuell immer wieder die Darstellung auffrischen, um die Veränderung der Zähler zu sehen.

Insgesamt sieht die Architektur also folgendermassen aus: Sensordaten werden von den Steuergeräten in ein CSV-File geschrieben, dieses wird via Kafka in Cloudera importiert, über Adapter der HANA-Datenbank sind diese in einer HANA verfügbar und SAP Analytics for Cloud bringt diese Daten zur Anzeige. In dieser Architektur ist kein SAP BW beteiligt. Im nächsten Teil dieses Blogs werde ich noch darauf eingehen, wie es möglich ist, solche Daten zwischen Hadoop und SAP BW einfach hin- und herzuschieben.

sap-hana-blog-10

Hadoop vom ABAP aus ansprechen: die GLUE-Middleware von Datavard

Im vorherigen Teil wurden Daten von Steuergeräten in ein CSV-File geschrieben, dies wurde per Kafka in Hadoop importiert und via Hive-Adapter bzw. Impala-Adpater in einer HANA-Datenbank gelesen. Diese Adapter stellen eine komfortable Möglichkeit dar, um auf die Hadoop-Daten lesend zuzugreifen. Diese Adapter ermöglichen allerdings nicht einen schreibenden Zugriff auf die Tabellen. Will man z.B. Daten, die nicht mehr besonders wichtig sind, aber dennoch nicht gelöscht werden sollen („cold data“) in das Hadoop verschieben, so geht das nicht über diese Adapter.

Eine einfache Möglichkeit, Daten zwischen einem ABAP-System und Hadoop hin- oder herzuverschieben, bietet die Middleware GLUE, die von unserer Partnerfirma Datavard entwickelt und vertrieben wird. Sie bietet die Möglichkeit, vom ABAP aus Tabellen in Hadoop zu definieren (diese heissen dann GLUE-Tabellen) und zwar so ähnlich wie man das in der SE11 macht. Der Inhalt dieser Tabellen lässt sich so einfach wie mit der SE16 anzeigen, und auch das Schreiben in diese Tabellen ist sehr einfach. Die GLUE-Software setzt einen Applikationsserver auf Linux voraus, es ist aber keine HANA-Datenbank zwingend vorausgesetzt, die Software funktioniert auch auf klassischen Datenbanken.

Ein Beispiel: nach erfolgreichem Import per ABAP-Transportaufträge und nach entsprechender Konfiguration, steht die Transaktion /DVD/GLUE als zentraler Einstiegspunkt zur Verfügung.

Im Data Dictionara lässt sich z.B. eine Tabelle ZCSSENSOR definieren.

Nach Aktivierung findet sich diese Tabelle dann im Hadoop wieder.

Ebenso einfach kann der Inhalt dieser Tabelle im ABAP zur Anzeige gebracht werden.

Wie wurden nun diese Daten, die man hier sieht, in diese Tabelle gebracht? In /DVD/GLUE findet sich die Extraktor-Workbench. Hier kann man eine Art Transformation z.B. zwischen einer ABAP-Tabelle aus dem DDIC und einer GLUE-Tabelle definieren.

Zusätzlich zu diesem Extraktor (er entspricht in etwa einer Transformation) wird eine Variante definiert (sie entspricht in etwa einem DTP). Diese Variante kann dann als Job eingeplant werden und führt dann den Datentransfer durch. Nach der Durchführung kann man im entsprechenden Job-Log sehen, wie der Transfer durchgeführt wurde (hier am Beispiel der Tabelle zcssensorl).

Wie früher im Blog bereits erwähnt, benötigt man im Allgemeinen nicht nur einen Austausch von Daten, sondern auch eine Orchestrierung von Ereignissen. GLUE bietet dabei die Steuerung zentral aus dem ABAP heraus an. Mit Hilfe des Script Editors können im ABAP Befehle an das Hadoop definiert werden.

Und diese Befehle dann auch aus dem ABAP heraus gestartet werden:

Insgesamt bietet GLUE einen komfortablen Weg, aus dem ABAP heraus Hadoop anzusprechen und zu benutzen. Dem Anwender eröffnet sich damit die Hadoop-Welt, ohne dass er sich tief in die Einzelheiten dieser Technik einarbeiten muss.

Unser Angebot

Any questions or require further information, please contact our Expert

Thorsten Stossmeister

Competency Lead EDW/HANA with sometimes old-fashioned preferences for backend and ABAP