7
MS SQL Datenbank Tool um verschieden strukturierte Quelldaten sequenziell zu importieren gesucht!
Ich suche ein Programm, das mir ermöglich, verschieden exportierte Textdateien von Produktionsmaschinen aus zu werten und in ein Tabellenfähiges Format zu wandeln. Derzeit über Batch, für jede Maschine neu.
Ich suche ein Programm, das mir ermöglich, verschieden exportierte Textdateien von Produktionsmaschinen verschiedener Hersteller aus zu werten und in ein Tabellenfähiges Format zu wandeln, um dieses vordefinierte Format dann in einen SQL Server ein zu spielen.
Derzeit entwickle ich für jede Maschine einen Batch, für jede Maschine neu, und spiele per bcp die Daten ein.
Da es sein kann, das die Textdateien von den Maschinen alle Minute ausgespuckt werden, und die Verzeichnisse überwacht werden (sollen), sind daher dauernd Scripte am laufen, die auch gerne mal gleichzeitig starten, oder stehen bleiben. Selbst wenn wir das script nur alle 24 Stunden laufen lassen
Ich hatte es mir so vorgestellt, das es ein Programm gibt, der sequenziell die Verzeichnisse abarbeitet, und dann die Dateien in das System hinterlegt.
Natürlich bekomme ich das auch mit Hilfe eines Batch-Containers hin, suche aber eine elegante, und fehlertolerantere Lösung.
Gerne auch eine kostenpflichtige Lösung, eine dementsprechende Schnittstelle jeder Maschine kostet zwischen 2500 und 10000€ Euro, da würde uns eine einmalige Ausgabe einer Software weniger kosten.
Nochmals Anforderungen:
- Willkürlich formatierte Textdateien in ein Datenbank kompatibles Format bringen
- Import in die Datenbank
- Bestandsprüfung bei Import, um doppelte Datensätze zu vermeiden
Ich weiss ich wünsche mir hier eine eierlegende Wollmilchsau, aber vieleicht gibt es ja sowas ;)
Danke für die Hilfe!
PS: Anbei ein Auszug einiger Daten, die veranschaulichen sollen, was importiert werden soll:
Maschine1.txt
Date :2013.1.4
Save Recording : 8.5.38 Clock
Automatik : T#4m18s
Aktiv : T#3m27s
Error : T#18s
Magazine : T#51s
Out trans. : T#0ms
Schnitte: 16
Teil abgeschoben: 14
Number of Parts: 13
Maschine2.txt
Datum: 20130312
Maschine: SE-2KPH-CNC, 5736
Herstellung: XXXX Maschinenbau GmbH
Kunde: XXXXXXXX, XXXXXXXXX
Zeit;ProOptID;Breite;Höhe;Stückzahl;Status
13:20:26;0;0;0;0;Maschine On
13:35:37;0;0;0;0;Maschine On
13:37:07;0;0;0;0;Automatik start
13:43:37;0;6500;4750;344812;
etc. Nicht auszuschließen das andere Formate dazu kommen.
Derzeit entwickle ich für jede Maschine einen Batch, für jede Maschine neu, und spiele per bcp die Daten ein.
Da es sein kann, das die Textdateien von den Maschinen alle Minute ausgespuckt werden, und die Verzeichnisse überwacht werden (sollen), sind daher dauernd Scripte am laufen, die auch gerne mal gleichzeitig starten, oder stehen bleiben. Selbst wenn wir das script nur alle 24 Stunden laufen lassen
Ich hatte es mir so vorgestellt, das es ein Programm gibt, der sequenziell die Verzeichnisse abarbeitet, und dann die Dateien in das System hinterlegt.
Natürlich bekomme ich das auch mit Hilfe eines Batch-Containers hin, suche aber eine elegante, und fehlertolerantere Lösung.
Gerne auch eine kostenpflichtige Lösung, eine dementsprechende Schnittstelle jeder Maschine kostet zwischen 2500 und 10000€ Euro, da würde uns eine einmalige Ausgabe einer Software weniger kosten.
Nochmals Anforderungen:
- Willkürlich formatierte Textdateien in ein Datenbank kompatibles Format bringen
- Import in die Datenbank
- Bestandsprüfung bei Import, um doppelte Datensätze zu vermeiden
Ich weiss ich wünsche mir hier eine eierlegende Wollmilchsau, aber vieleicht gibt es ja sowas ;)
Danke für die Hilfe!
PS: Anbei ein Auszug einiger Daten, die veranschaulichen sollen, was importiert werden soll:
Maschine1.txt
Date :2013.1.4
Save Recording : 8.5.38 Clock
Automatik : T#4m18s
Aktiv : T#3m27s
Error : T#18s
Magazine : T#51s
Out trans. : T#0ms
Schnitte: 16
Teil abgeschoben: 14
Number of Parts: 13
Maschine2.txt
Datum: 20130312
Maschine: SE-2KPH-CNC, 5736
Herstellung: XXXX Maschinenbau GmbH
Kunde: XXXXXXXX, XXXXXXXXX
Zeit;ProOptID;Breite;Höhe;Stückzahl;Status
13:20:26;0;0;0;0;Maschine On
13:35:37;0;0;0;0;Maschine On
13:37:07;0;0;0;0;Automatik start
13:43:37;0;6500;4750;344812;
etc. Nicht auszuschließen das andere Formate dazu kommen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 206071
Url: https://administrator.de/contentid/206071
Printed on: April 26, 2024 at 18:04 o'clock
7 Comments
Latest comment
PS: Man nennt so was ETL Tool , vieleicht kann damit dann mehr angefangen werden ;)
Mal zur Information, wer sowas auch sucht:
Ich habe hier sogar eine sehr interessantes Angebot von www.idl.eu bekommen, den IDLIMPORTER .
Vom Produktspektrum und Leistung von der Dokumentation recht gut, nur werden preislich die Kleinunternehmen nur wenig mit anfangen können. Der OVP liegt bei 6000 Euro (ohne Gewähr).
Wenn ich selbst weiteres finde, oder Informationen bekomme, werde ich das hier posten!
Mal zur Information, wer sowas auch sucht:
Ich habe hier sogar eine sehr interessantes Angebot von www.idl.eu bekommen, den IDLIMPORTER .
Vom Produktspektrum und Leistung von der Dokumentation recht gut, nur werden preislich die Kleinunternehmen nur wenig mit anfangen können. Der OVP liegt bei 6000 Euro (ohne Gewähr).
Wenn ich selbst weiteres finde, oder Informationen bekomme, werde ich das hier posten!
Moin Lyriker,
nur zur Sicherheit: du bist dir bewusst, dass du (mindestens) zwei ganz verschiedene Probleme hast.
a) da brauchst ein Konvertierungswerkzeug, um "lose strukturierte" oder Semi-strukturierte Maschinenlogs in strukturierte (=für relational DB-Welt geeignete, in Zeilen und Spalten abbildbare) Entitäten zu transformieren
b) du brauchst ein Tool, das dir die workflowgesteuerte und oder zeitgesteuerte Datenübernahme inclusive des ganzen Protokollierungskrams, Fehlerhandling und restartfähigen Jobs abnimmt und diese Importe auch noch kollisionsfrei bewältigen kann.
Bei Punkt a) wirst du auch mit einem ETL-Tool nur sehr begrenzt weit mit grafischen Zusammenklick-Mappings kommen. Die eigentliche Übersetzung des Quellzeilengestrukeles mit 137 verschiedenen Satz- und Wiederholblockarten per Quelldatei musst du auch über die mitgelieferte Skriptprache zusammenklöppeln - und das ist derselbe "Programmieraufwand" wie mit irgendwas in Richtung VBS/Batch/sonstige Leichtgewichte. Es sollte dir nur bewusst sein, dass du mit einem gekauften ETL-Tool auch nur ein "Werkzeug" hast, noch keine einsetzbare Lösung.
Bei Punkt b) solltest du vorher geklärt haben, ob du denn in deiner Rechnung berücksichtigt hast, das dieses Tool zur Datenbewirtschaftung evtl ein separtet Rechner sein sollte (soll ja rund um die Uhr diese Aufgabe übernehmen). Ein eigener Rechner dafür ist ja auch sinnvoll, keine Frage, aber ob sich der Einsatz eines der handelsüblichen ETL-Tools für deinen Krams lohnt -> ist wirklich noch zu klären.
Denn letzten Endes brauchst du wirklich kein Client/Server-Tool mit differenzierter User- und Rechteverwaltung und eigenem Repository zum Handling von 200000 Importen aus 138 verschiedenen Quellformaten in 78000 verschiedene Datenbankserver/Schemata, sondern in der Tendenz doch wohl eher 20 individuelle Quellformate, die als Ziel genau EINE MS-SQL-Datenbank haben (und da vielleicht 10 Tabellen in einem Schema).
In diesem Fall würde ich dir eher von einem Ankauf eines ETL-Tools (von wem auch immer) abraten und das Geld lieber anlegen für eine Individual-Applikationserstellung durch eine Software-Klitsche aus dem Nachbardorf, die euch ein wartbares und erweiterbares Grundgerüst hinterlääst.
Dürfte ebenfalls in der Größenordnung 6000 Ocken liegen.
Aber es deckt dann erstmal > 85% eurer real existierenden Anforderungen ab und nicht nur die durchschnittlichen 25% der Anforderungen, die ein xy-ETL-Tool im ersten Anlauf ohne Anpassungen schafft.
Grüße
Biber
nur zur Sicherheit: du bist dir bewusst, dass du (mindestens) zwei ganz verschiedene Probleme hast.
a) da brauchst ein Konvertierungswerkzeug, um "lose strukturierte" oder Semi-strukturierte Maschinenlogs in strukturierte (=für relational DB-Welt geeignete, in Zeilen und Spalten abbildbare) Entitäten zu transformieren
b) du brauchst ein Tool, das dir die workflowgesteuerte und oder zeitgesteuerte Datenübernahme inclusive des ganzen Protokollierungskrams, Fehlerhandling und restartfähigen Jobs abnimmt und diese Importe auch noch kollisionsfrei bewältigen kann.
Bei Punkt a) wirst du auch mit einem ETL-Tool nur sehr begrenzt weit mit grafischen Zusammenklick-Mappings kommen. Die eigentliche Übersetzung des Quellzeilengestrukeles mit 137 verschiedenen Satz- und Wiederholblockarten per Quelldatei musst du auch über die mitgelieferte Skriptprache zusammenklöppeln - und das ist derselbe "Programmieraufwand" wie mit irgendwas in Richtung VBS/Batch/sonstige Leichtgewichte. Es sollte dir nur bewusst sein, dass du mit einem gekauften ETL-Tool auch nur ein "Werkzeug" hast, noch keine einsetzbare Lösung.
Bei Punkt b) solltest du vorher geklärt haben, ob du denn in deiner Rechnung berücksichtigt hast, das dieses Tool zur Datenbewirtschaftung evtl ein separtet Rechner sein sollte (soll ja rund um die Uhr diese Aufgabe übernehmen). Ein eigener Rechner dafür ist ja auch sinnvoll, keine Frage, aber ob sich der Einsatz eines der handelsüblichen ETL-Tools für deinen Krams lohnt -> ist wirklich noch zu klären.
Denn letzten Endes brauchst du wirklich kein Client/Server-Tool mit differenzierter User- und Rechteverwaltung und eigenem Repository zum Handling von 200000 Importen aus 138 verschiedenen Quellformaten in 78000 verschiedene Datenbankserver/Schemata, sondern in der Tendenz doch wohl eher 20 individuelle Quellformate, die als Ziel genau EINE MS-SQL-Datenbank haben (und da vielleicht 10 Tabellen in einem Schema).
In diesem Fall würde ich dir eher von einem Ankauf eines ETL-Tools (von wem auch immer) abraten und das Geld lieber anlegen für eine Individual-Applikationserstellung durch eine Software-Klitsche aus dem Nachbardorf, die euch ein wartbares und erweiterbares Grundgerüst hinterlääst.
Dürfte ebenfalls in der Größenordnung 6000 Ocken liegen.
Aber es deckt dann erstmal > 85% eurer real existierenden Anforderungen ab und nicht nur die durchschnittlichen 25% der Anforderungen, die ein xy-ETL-Tool im ersten Anlauf ohne Anpassungen schafft.
Grüße
Biber
Hallo erstmal!
zur teilweisen Verwirrung bei zu tragen, werde ich dennoch einen Teil Deiner Fragen zitieren. Ich bitte dies zu entschuldigen!
nur zur Sicherheit: du bist dir bewusst, dass du (mindestens) zwei ganz verschiedene Probleme hast.
Das bin ich mir voll bewusst, bzw., ich weiß was wir genau brauchen ;)
zu a) richtig.
zu b1) Jain. Wir haben hier einen ausgezeichneten Serverpark, der viele der Dinge aus seinem Spektrum erledigen kann.
Was wir bekommen, sind reine Logs in txt Format(-en), die leider der allgemeinen Konformität abweichen, und eigener Form (siehe Beispiel oben) nicht einfach so in eine Datenbank verschoben werden kann. Dazu benötigen wir das ETL Tool (oder für jede Maschinen von mir gescriptete Batches). Natürlich haben wir ein gewisses Workflow bei dem abarbeiten dieser Logs, und auch eine gewisses Fehlerhandling wird voraus gesetzt, in dem restartfähige Jobs für mich in dem Fehlerhandling integral sind.
Kollisionsfrei ist natürlich ein Punkt, der grundlegend ist für die Funktionalität, denn die Daten bringen uns nichts, wenn Sie nicht in unsere Datenbank "Passen" ;)
Hier bist Du glaube ich im Irrtum, genau das muss/will ich mit diesem ETL nicht machen, das ist genau die Anforderung die ich an das Programm stelle!
Ich KANN wenn ich will, mit der von IDL gezeigten Lösung, gewisse Batches nochmals dazwischen schieben, oder nochmals zur Auswertung nutzen, doch das behandeln der Daten wird direkt vom Programm besorgt, was ich ja auch suche.
Im Moment baue >ich< für jede Maschine die es bei uns gibt, (oder auch dazu kommt) und für jeden Log / Export von Laufzeitdaten in Textform eine Batch Datei. Doch mit der Dauer wird das zu aufwendig, und auch undurchschaubarer, vor allem wenn es jemand dann mal fixen muss, der sich damit nicht aus kennt. Die Vorarbeiten zu dem ETL Programm, also eine "Matrix" erstellen, die dieses Textfile von der Maschine XX1 sauber erkennt, ist natürlich am Anfang meine Aufgabe, aber auch hier bin ich der Meinung, das ein solches Programm mir das erleichtert, vor allem wenn es um das wandeln von gewissen Werten geht.
(derzeit kämpfe ich in meinem Batch mit einem Datum das sich 1.1.2013 schreibt, aber die DB es unbedingt in 01.01.2013 haben möchte, das ist innerhalb des bestehenden Konstruktes nicht ganz so einfach....)
Eben ein solches suche ich ja ;). Nach oben genannten Beispielen wäre das IDL vom Start ab einsatzbereit und würde mir sofort das Datenbank konforme Ergebnis liefern... Zumindest nach Meinung des Herstellers / Technikers, der diesen Thread bestimmt mit verfolgt, weil ich ihm die Anforderungen darüber geschildert habe. Bisher ist nur der Preis der passus knackus ;)
Ja ist geklärt.. unser Serverpark hier in der Produktionsstätte (VMWare Cluster / Datacore kann das... und muss es auch, sollen die 400 Produktionsmaschinen (+ PCs, Hausinstallation etc.) überwacht werden ;)
Ähm.. doch? hatte ich das oben wohl nicht so ganz klar dargestellt?
Jede unserer 400 Maschinen produziert Täglich/Stündlich/Minütlich ein Logfile, das in eine Datenbank (jede Maschine mit eigener Tabelle) importiert werden solle, um dann in unserem Firmeneigenen Programm über eine Auswertung diese Daten zu konsolodisieren und an zu zeigen.
In diesem Fall würde ich dir eher.. ... Dürfte ebenfalls in der Größenordnung 6000 Ocken liegen.
Wir haben dazu die Maschinenhersteller angefragt, was es uns kosten würde, wenn diese uns diese Daten in der Form liefern würden...
Hatte pro Hersteller den Kostenfaktor nicht unter 2500 Euro. Da ein Hersteller, von denen wir verschiedene Maschinen haben, Ihr Datenformat auch unterschiedlich für jede Maschine ausspucken, kann es dann sogar teurer werden, hier waren 10k € Verhandlungsbasis.
Und: >> IDL ist die "Software-Klitsche aus dem Nachbardorf" ;)
Mir fehlt auch zu Deiner Ausführung etwas der Faktor Zeit in der Betrachtung. Ich befinde mich wohl in der Lage selbst ein solches Tool zu bauen, doch benötige ich da weit noch länger als mir ein (vielleicht standardisiertes) Tool zu holen, mit dem ich es in weitaus weniger Zeit umsetzen kann.... Und auch der Softwareklitsche traue ich es nicht zu innerhalb weniger Wochen dazu um zu setzen.
hm ok...
Sind die Erfahrung, zumindest bezüglich IDL dahingehend Deinerseits so prägnant, das man darüber Redebedarf hat/hätte? Würde mich auf eine PM / Mail Deinerseits darüber freuen!
Natürlich würde ich mich auch über eine andere Lösung, oder Lösungsvorschlag freuen.
zur teilweisen Verwirrung bei zu tragen, werde ich dennoch einen Teil Deiner Fragen zitieren. Ich bitte dies zu entschuldigen!
nur zur Sicherheit: du bist dir bewusst, dass du (mindestens) zwei ganz verschiedene Probleme hast.
Das bin ich mir voll bewusst, bzw., ich weiß was wir genau brauchen ;)
a) da brauchst ein Konvertierungswerkzeug ...
zu a) richtig.
b1) du brauchst ein Tool, das dir die workflowgesteuerte und oder zeitgesteuerte Datenübernahme inclusive des ganzen
Protokollierungskrams, Fehlerhandling und restartfähigen Jobs abnimmt und diese Importe auch noch kollisionsfrei
bewältigen kann.......
Protokollierungskrams, Fehlerhandling und restartfähigen Jobs abnimmt und diese Importe auch noch kollisionsfrei
bewältigen kann.......
zu b1) Jain. Wir haben hier einen ausgezeichneten Serverpark, der viele der Dinge aus seinem Spektrum erledigen kann.
Was wir bekommen, sind reine Logs in txt Format(-en), die leider der allgemeinen Konformität abweichen, und eigener Form (siehe Beispiel oben) nicht einfach so in eine Datenbank verschoben werden kann. Dazu benötigen wir das ETL Tool (oder für jede Maschinen von mir gescriptete Batches). Natürlich haben wir ein gewisses Workflow bei dem abarbeiten dieser Logs, und auch eine gewisses Fehlerhandling wird voraus gesetzt, in dem restartfähige Jobs für mich in dem Fehlerhandling integral sind.
Kollisionsfrei ist natürlich ein Punkt, der grundlegend ist für die Funktionalität, denn die Daten bringen uns nichts, wenn Sie nicht in unsere Datenbank "Passen" ;)
Bei Punkt a) wirst du auch mit einem ETL-Tool nur sehr begrenzt weit mit grafischen Zusammenklick-Mappings ... derselbe
"Programmieraufwand" wie mit irgendwas in Richtung VBS/Batch/sonstige Leichtgewichte.
"Programmieraufwand" wie mit irgendwas in Richtung VBS/Batch/sonstige Leichtgewichte.
Hier bist Du glaube ich im Irrtum, genau das muss/will ich mit diesem ETL nicht machen, das ist genau die Anforderung die ich an das Programm stelle!
Ich KANN wenn ich will, mit der von IDL gezeigten Lösung, gewisse Batches nochmals dazwischen schieben, oder nochmals zur Auswertung nutzen, doch das behandeln der Daten wird direkt vom Programm besorgt, was ich ja auch suche.
Im Moment baue >ich< für jede Maschine die es bei uns gibt, (oder auch dazu kommt) und für jeden Log / Export von Laufzeitdaten in Textform eine Batch Datei. Doch mit der Dauer wird das zu aufwendig, und auch undurchschaubarer, vor allem wenn es jemand dann mal fixen muss, der sich damit nicht aus kennt. Die Vorarbeiten zu dem ETL Programm, also eine "Matrix" erstellen, die dieses Textfile von der Maschine XX1 sauber erkennt, ist natürlich am Anfang meine Aufgabe, aber auch hier bin ich der Meinung, das ein solches Programm mir das erleichtert, vor allem wenn es um das wandeln von gewissen Werten geht.
(derzeit kämpfe ich in meinem Batch mit einem Datum das sich 1.1.2013 schreibt, aber die DB es unbedingt in 01.01.2013 haben möchte, das ist innerhalb des bestehenden Konstruktes nicht ganz so einfach....)
Es sollte dir nur bewusst sein,
dass du mit einem gekauften ETL-Tool auch nur ein "Werkzeug" hast, noch keine einsetzbare Lösung.
dass du mit einem gekauften ETL-Tool auch nur ein "Werkzeug" hast, noch keine einsetzbare Lösung.
Eben ein solches suche ich ja ;). Nach oben genannten Beispielen wäre das IDL vom Start ab einsatzbereit und würde mir sofort das Datenbank konforme Ergebnis liefern... Zumindest nach Meinung des Herstellers / Technikers, der diesen Thread bestimmt mit verfolgt, weil ich ihm die Anforderungen darüber geschildert habe. Bisher ist nur der Preis der passus knackus ;)
Bei Punkt b) solltest du vorher geklärt ..
Ja ist geklärt.. unser Serverpark hier in der Produktionsstätte (VMWare Cluster / Datacore kann das... und muss es auch, sollen die 400 Produktionsmaschinen (+ PCs, Hausinstallation etc.) überwacht werden ;)
Denn letzten Endes brauchst du wirklich kein Client/Server-Tool mit differenzierter User- und Rechteverwaltung und eigenem
Repository zum Handling von 200000 Importen aus 138 verschiedenen Quellformaten in 78000 verschiedene Datenbankserver/Schemata,
sondern in der Tendenz doch wohl eher 20 individuelle Quellformate, die als Ziel genau EINE MS-SQL-Datenbank haben (und da
vielleicht 10 Tabellen in einem Schema).
Repository zum Handling von 200000 Importen aus 138 verschiedenen Quellformaten in 78000 verschiedene Datenbankserver/Schemata,
sondern in der Tendenz doch wohl eher 20 individuelle Quellformate, die als Ziel genau EINE MS-SQL-Datenbank haben (und da
vielleicht 10 Tabellen in einem Schema).
Ähm.. doch? hatte ich das oben wohl nicht so ganz klar dargestellt?
Jede unserer 400 Maschinen produziert Täglich/Stündlich/Minütlich ein Logfile, das in eine Datenbank (jede Maschine mit eigener Tabelle) importiert werden solle, um dann in unserem Firmeneigenen Programm über eine Auswertung diese Daten zu konsolodisieren und an zu zeigen.
In diesem Fall würde ich dir eher.. ... Dürfte ebenfalls in der Größenordnung 6000 Ocken liegen.
Wir haben dazu die Maschinenhersteller angefragt, was es uns kosten würde, wenn diese uns diese Daten in der Form liefern würden...
Hatte pro Hersteller den Kostenfaktor nicht unter 2500 Euro. Da ein Hersteller, von denen wir verschiedene Maschinen haben, Ihr Datenformat auch unterschiedlich für jede Maschine ausspucken, kann es dann sogar teurer werden, hier waren 10k € Verhandlungsbasis.
Und: >> IDL ist die "Software-Klitsche aus dem Nachbardorf" ;)
Mir fehlt auch zu Deiner Ausführung etwas der Faktor Zeit in der Betrachtung. Ich befinde mich wohl in der Lage selbst ein solches Tool zu bauen, doch benötige ich da weit noch länger als mir ein (vielleicht standardisiertes) Tool zu holen, mit dem ich es in weitaus weniger Zeit umsetzen kann.... Und auch der Softwareklitsche traue ich es nicht zu innerhalb weniger Wochen dazu um zu setzen.
Aber es deckt dann erstmal > 85% eurer real existierenden Anforderungen ab und nicht nur die durchschnittlichen 25% der
Anforderungen, die ein xy-ETL-Tool im ersten Anlauf ohne Anpassungen schafft.
Anforderungen, die ein xy-ETL-Tool im ersten Anlauf ohne Anpassungen schafft.
hm ok...
Sind die Erfahrung, zumindest bezüglich IDL dahingehend Deinerseits so prägnant, das man darüber Redebedarf hat/hätte? Würde mich auf eine PM / Mail Deinerseits darüber freuen!
Natürlich würde ich mich auch über eine andere Lösung, oder Lösungsvorschlag freuen.
Moin Lyriker,
da ich (soweit ich mich einschätzen kann) in den nächsten Tagen eher nicht aus dem fahrenden Bollerwagen heraus PNs schreiben werde - ist nicht gegen dich gerichtet- möchte ich wenigstens noch einen Vorschlag für eine mögliche Entscheidungshilfe Indiviual-Lösung vs. ETL-Tool zur Auflösung von Maschinenlogs machen.
Wie angedeutet - bei halb und lose strukturierten Daten wie Maschinenlogs sehe ich den potentiellen Benefit von ETL-Tools eher gering an, weil du aus einem grossen Text-Datenumfang in mehr oder weniger stilisiertem Denglish die 10 oder 15% Daten rausflöhen musst, die für dich auswertungsrelevant/für Nachverarbeitung geeignet sind.
Diese 10-15% "interessanten" Rohdaten musst du sicherlich fast vollständug mit String-und typkonvertierungsfunktionen nachbehandeln (mit SUBSTRING()/TO_DATE/TO_NUMBER etc etc- dem, was die IDL-Anbieter als ihre "Skript- und Makro-Sprache" bezeichnen.
Geht sicherlich.
Aber dann mach doch mal eine Milchmädchenrechnung und einen proof of concept mit diesen IDL-Hansels.
Milchmädchenrechnung:
Für ein Skriptchen in Java/VB/VBS/whatever individuell zusammengeschrotet von einem Informatikstudenten im 6. Semester für EIN bestimmtes Logfileformat ( Annahme: dokumentiertes Quellformat; definiertes Zielformat) müsstet ihr 3 Tage bezahlen a 100 Euro. Und wüsstet allerdings nicht, ob das Stück Code wartbar ist von einem eurer Vor-Ort-Leute.
Wenn das Ziel sein soll, mit eigenen vorhanden Kapazitäten flankiert von dem ETL-Tool wenigstens zeitlich dasselbe Ergebnis zu schaffen (also 3 MT für EINE Maschinenlog-Konvertierung in DB-geeignet) UND zusätzlich etwas wartbares zu haben, dann ...
--> dann nimm an, du (als einer, der in der fachlichen Thematik ja tief drin steckt) solltest in 3 MT das erste Mapping/den ersten Workflow mit dem IDL-Tool zusammenschrubbeln. Allein und ohne Vorkenntnisse.
--> wenn das leistbar wäre, dann müsste ein Profi, einer, der sich mit diesem Tool auskennt, das in der halben Zeit schaffen, also in anderthalb Tagen
-> Dann lade ein IDL-Menschen für 2 Tage ein, der soll ein Notebook mit seinem installierten Tool mitbringen und dir in diesen zwei Tagen mal diesen EINEN Workflow für EIN Maschinenlog zusammenbraten (=1,5 Tage) und die dann in den Mappings zeigen, wo du etwas anpassen musst, wenn sich das Quellformat ändert (der restliche halbe Tag).
Wenn dieser POC klappt und so etwas in zwei Tagen abzufrühstücken ist, dann ziehe ich alle Bedenken zurück.
Ansonsten erstmal einen schönen freien Tag morgen
Biber
da ich (soweit ich mich einschätzen kann) in den nächsten Tagen eher nicht aus dem fahrenden Bollerwagen heraus PNs schreiben werde - ist nicht gegen dich gerichtet- möchte ich wenigstens noch einen Vorschlag für eine mögliche Entscheidungshilfe Indiviual-Lösung vs. ETL-Tool zur Auflösung von Maschinenlogs machen.
Wie angedeutet - bei halb und lose strukturierten Daten wie Maschinenlogs sehe ich den potentiellen Benefit von ETL-Tools eher gering an, weil du aus einem grossen Text-Datenumfang in mehr oder weniger stilisiertem Denglish die 10 oder 15% Daten rausflöhen musst, die für dich auswertungsrelevant/für Nachverarbeitung geeignet sind.
Diese 10-15% "interessanten" Rohdaten musst du sicherlich fast vollständug mit String-und typkonvertierungsfunktionen nachbehandeln (mit SUBSTRING()/TO_DATE/TO_NUMBER etc etc- dem, was die IDL-Anbieter als ihre "Skript- und Makro-Sprache" bezeichnen.
Geht sicherlich.
Aber dann mach doch mal eine Milchmädchenrechnung und einen proof of concept mit diesen IDL-Hansels.
Milchmädchenrechnung:
Für ein Skriptchen in Java/VB/VBS/whatever individuell zusammengeschrotet von einem Informatikstudenten im 6. Semester für EIN bestimmtes Logfileformat ( Annahme: dokumentiertes Quellformat; definiertes Zielformat) müsstet ihr 3 Tage bezahlen a 100 Euro. Und wüsstet allerdings nicht, ob das Stück Code wartbar ist von einem eurer Vor-Ort-Leute.
Wenn das Ziel sein soll, mit eigenen vorhanden Kapazitäten flankiert von dem ETL-Tool wenigstens zeitlich dasselbe Ergebnis zu schaffen (also 3 MT für EINE Maschinenlog-Konvertierung in DB-geeignet) UND zusätzlich etwas wartbares zu haben, dann ...
--> dann nimm an, du (als einer, der in der fachlichen Thematik ja tief drin steckt) solltest in 3 MT das erste Mapping/den ersten Workflow mit dem IDL-Tool zusammenschrubbeln. Allein und ohne Vorkenntnisse.
--> wenn das leistbar wäre, dann müsste ein Profi, einer, der sich mit diesem Tool auskennt, das in der halben Zeit schaffen, also in anderthalb Tagen
-> Dann lade ein IDL-Menschen für 2 Tage ein, der soll ein Notebook mit seinem installierten Tool mitbringen und dir in diesen zwei Tagen mal diesen EINEN Workflow für EIN Maschinenlog zusammenbraten (=1,5 Tage) und die dann in den Mappings zeigen, wo du etwas anpassen musst, wenn sich das Quellformat ändert (der restliche halbe Tag).
Wenn dieser POC klappt und so etwas in zwei Tagen abzufrühstücken ist, dann ziehe ich alle Bedenken zurück.
Ansonsten erstmal einen schönen freien Tag morgen
Biber
Zitat von @Biber:
Milchmädchenrechnung:
Wenn dieser POC klappt und so etwas in zwei Tagen abzufrühstücken ist, dann ziehe ich alle Bedenken zurück.
Ansonsten erstmal einen schönen freien Tag morgen
Biber
Milchmädchenrechnung:
Wenn dieser POC klappt und so etwas in zwei Tagen abzufrühstücken ist, dann ziehe ich alle Bedenken zurück.
Ansonsten erstmal einen schönen freien Tag morgen
Biber
Du hast fast treffend die Anforderungen an ein ETL Tool beschrieben, die ich(wir) hier dann für einen moderaten Preis (also weniger 2,5k) haben.
-- Zitat Biber:
Wenn das Ziel sein soll, mit eigenen vorhanden Kapazitäten flankiert von dem ETL-Tool wenigstens zeitlich dasselbe Ergebnis zu schaffen...
Wenn dieser POC klappt und so etwas in zwei Tagen abzufrühstücken ist, dann ziehe ich alle Bedenken zurück.
-- Zitat Ende
Deswegen suche ich ja auch dementsprechende Alternativen an "In The Box" Lösungen, die so was schaffen können, denn ich war der Meinung es gäbe hierzu einige, die das gleiche Problem herum tragen. Angebote von den "Profis" gibt es ja zur Genüge, wenn ich mir das so google. ;) Nur ob es was taugt, oder ob etwas zu empfehlen ist, kann ich nur von den Usern bekommen. Weshalb ich den Thread ja gestartet habe.
Ansonsten bleibt es dabei, das ich die Sachen weiterhin selbst schreibe, eben ohne ETL Tool, und das dementsprechende Geld für so ein Projekt, in anderes gesteckt wird.
Heißt natürlich das meine Ressource zeitlich um einiges beschnitten ist ;) Ich glaube ich bin teurer als die Anschaffung einer solchen Schnittstelle +deren Einarbeitung ;)
Ich meine das ist als wenn man Office kaufen könnte, aber mangels wissen trotzdem noch den Texteditor benutzt, weil man sich davor scheut sich in das Office ein zu arbeiten ;)
Danke den schönen freien Tag hatte ich, ich hoffe Du auch ;)
Viele Grüße
Lyk
Moin Lyriker,
wenn euer Streben ist, alle Logdateien in ausgedünnter Form in Richtung Datenbank zu ziehen, um es da zu aggregieren, zu clustern und auszuwerten empfehle ich das einzelfallspezifische Skriptkonvertieren in ein CSV-Format und anschliessenedes Lesen mit den dir bekannten Mitteln, die MSSSQL da bietet.
Also kein ETL-Tool für deinen Zweck.
Falls es auch denkbar wäre, die Auswertung NICHT über alle Daten/alle Logfiles zu machen, sondern ohne Umwandlung in Tabellenstrukturen direkt in dem schwach strukturierten Textgestrunkele nach "Auffälligkeiten" und bestimmten Fehlern zu suchen, dann wirf einen Blick auf das Nischenprogramm Splunk.
Ich weiss nicht wo du wohnst, aber die haben morgen in Hamburg und übermorgen in München eine ihrer Roadshows.
Deren Tool kann genau dieses: in wie-auch-immer-(un)strukturierten Daten (z.B. Mschinenlogs) mögliche Gemeinsamkeiten/Suchbegriffe/Muster zu erkennen, zu clustern und zu visualisieren - rattenscharfes Teil.
Und eine Probe-Lizenz für bis zu 10 GByte Daten ist m.W. auch nach wie vor für lau.
Ist ein anderer Ansatz als die übliche Quartalsfehlersummenstatistik, die du in der relationalen Welt dann am Ende des Weges als Benefit hast, aber vielleicht erwägenswert.
Grüße
Biber
wenn euer Streben ist, alle Logdateien in ausgedünnter Form in Richtung Datenbank zu ziehen, um es da zu aggregieren, zu clustern und auszuwerten empfehle ich das einzelfallspezifische Skriptkonvertieren in ein CSV-Format und anschliessenedes Lesen mit den dir bekannten Mitteln, die MSSSQL da bietet.
Also kein ETL-Tool für deinen Zweck.
Falls es auch denkbar wäre, die Auswertung NICHT über alle Daten/alle Logfiles zu machen, sondern ohne Umwandlung in Tabellenstrukturen direkt in dem schwach strukturierten Textgestrunkele nach "Auffälligkeiten" und bestimmten Fehlern zu suchen, dann wirf einen Blick auf das Nischenprogramm Splunk.
Ich weiss nicht wo du wohnst, aber die haben morgen in Hamburg und übermorgen in München eine ihrer Roadshows.
Deren Tool kann genau dieses: in wie-auch-immer-(un)strukturierten Daten (z.B. Mschinenlogs) mögliche Gemeinsamkeiten/Suchbegriffe/Muster zu erkennen, zu clustern und zu visualisieren - rattenscharfes Teil.
Und eine Probe-Lizenz für bis zu 10 GByte Daten ist m.W. auch nach wie vor für lau.
Ist ein anderer Ansatz als die übliche Quartalsfehlersummenstatistik, die du in der relationalen Welt dann am Ende des Weges als Benefit hast, aber vielleicht erwägenswert.
Grüße
Biber
Ebenso ein wunderschönen guten Morgen,
wenn euer Streben ist, alle Logdateien in ausgedünnter Form in Richtung Datenbank zu ziehen, um es da zu
aggregieren, zu clustern und auszuwerten empfehle ich das einzelfallspezifische Skriptkonvertieren in ein CSV-Format und
anschliessenedes Lesen mit den dir bekannten Mitteln, die MSSSQL da bietet.
Also kein ETL-Tool für deinen Zweck.
Siehe unten, das genau mache ich ja schon.
Ich weiss nicht wo du wohnst, aber die haben morgen in Hamburg und übermorgen in München eine ihrer Roadshows.
Deren Tool kann genau dieses: in wie-auch-immer-(un)strukturierten Daten (z.B. Mschinenlogs) mögliche
Gemeinsamkeiten/Suchbegriffe/Muster zu erkennen, zu clustern und zu visualisieren - rattenscharfes Teil.
Deren Tool kann genau dieses: in wie-auch-immer-(un)strukturierten Daten (z.B. Mschinenlogs) mögliche
Gemeinsamkeiten/Suchbegriffe/Muster zu erkennen, zu clustern und zu visualisieren - rattenscharfes Teil.
--> Heidelberg ;) Habe mir das Produktportfolio angesehen. Leider nicht das, was wir nutzen können, zumindest im Bereich Auswertung. Aber vielleicht ein Teilschritt um uns das Leben zu erleichtern. Mal ein neuer Ansatz und ein Vorschlag mit dem ich was tun kann, Yay.
Nochmals zur Anforderung:
Die Auswertung erfolgt in einem von unseren Systemen, weil dementsprechende Daten gegengestellt werden müssen. Wir benötigen nur die Daten aller Logfiles VOLLSTÄNDIG im richtigen Format in der Datenbank. An die MSSQL Tools (Enterprise Manager / Agent) haben wir natürlich auch gedacht, nur ist es uns nicht möglich 100% auf die Maschinendaten über das Tool zu zu greifen (zumal er die Daten auch nicht auslesen kann, wegen oben genannten desolaten Format).
Um es nochmals zu verdeutlichen:
Derzeit entwickle ich für jede Maschine und deren Log eine Batch Datei, die die Daten konsoldisiert und per bcp in die Datenbank schriebt. Das ist also nicht das "Problem".
Das Problem ist die Zeit, die wir brauchen, um ein solches Script fertig zu stellen!
Wir suchen eine Schnittstelle, die uns eine Textdatei auswertet, und durch wenige , ja sagen wir mal "Klicks" ruhig auch auf grafischer Ebene, das in eine von uns vorgegebene Tabelle importiert, um diese Zahlen dann auch auswerten zu >können<, nach einem Rahmen, den wir vorher festgelegt haben.
Die spätere Auswertung soll dann Laufzeiten von Maschinen, "echte" Arbeits- und Pausezeiten von Mitarbeitern, Übergabezeiten an nächsten Werkplatz, Auslieferungszeiten von fertigen Elementen miteinander vergleichen, und Schwachpunkte darstellen.
Frag mich nicht ob es sinnvoll ist (;)), es ist eine Anforderung die wir umsetzen müssen. Zumindest die Rohdaten zu liefern, in einem sauberen Format.
Eine Anforderung, die wir Informatiker doch oft genug bekommen, auch wenn uns der Sinn dahingehend etwas entbehrt ;)
Und eine Probe-Lizenz für bis zu 10 GByte Daten ist m.W. auch nach wie vor für lau.
Ist ein anderer Ansatz als die übliche Quartalsfehlersummenstatistik, die du in der relationalen Welt dann am Ende des Weges
als Benefit hast, aber vielleicht erwägenswert.
Grüße
Biber
Ist ein anderer Ansatz als die übliche Quartalsfehlersummenstatistik, die du in der relationalen Welt dann am Ende des Weges
als Benefit hast, aber vielleicht erwägenswert.
Grüße
Biber
Liegt leider nicht im Rahmen der Möglichkeiten, da die Daten der Auswertung im Auswerteverfahren im dementsprechenden System "vorgeneriert" werden, und auch im dementsprechenden System angezeigt werden sollen.
Saubere, integere Daten, in einer strukturierten Tabelle.
Aber wie oben schon geschrieben, vielleicht nützlich für den Zwischenschritt der Überarbeitung und Integritätsprüfung.
Kostenlos ist natürlich ein Wort ;)
Gruß zurück
Lyk