Vorgehensweise #2
Comments
|
Ich habe beschlossen, die Übertragung der Tabellen in .csv-Files mit MySQL-Workbench manuell zu machen (also, wenn man die Resultat-Tabelle eines SQL-Kommandos hat, gibt es einen Button mit dem man den Export als .csv-Datei vornehmen kann). |
|
siehe Commit 360e419 |
|
ich werde die .csv-Files später auch noch "schlanker" machen, indem die nicht benötigten Variablen weggelassen werden |
|
Zur Erklärung, was ich gestern gemacht habe: In Commit 34a9820 verwende ich PDI, um die Daten aus den .csv-Files zu lesen. Ich nenne dieses File "staging-area", weil ich denke, dass es irgendwie schon gerechtfertigt ist, es als das zu bezeichnen, weil es sowohl von der ursprünglichen Datenbank als auch von der Zieldatenbank getrennt ist. Weiter in diesem Commit werden die Daten aus den Tabellen "products" und "order_details" repariert und zunächst mal als .csv-Files in einem Ordner "corrected-data" abgelegt. Diese Daten landen vermutlich noch nicht da, wo sie endgültig hinsollen, aber zumindest funktionieren schon mal die Transformationen korrekt. Der andere Commit 07640c1 ist ein R-Code, mit dem man herausfindet, dass in der Tabelle "products" bei den doppelten Einträgen wirklich nur die Spalte "id" verschieden ist. |
|
Bin nun endlich auch dazu gekommen, mich dem Projekt zu widmen. Ich habe ein Word-File hochgeladen, in dem drei Auswertungen definiert sind und die benötigten Tabellen und Attribute. Nach meinem Verständnis ist die Staging Area nichts weiter als einfache DB Tabellen, die die csv Files repräsentieren. Wir könnten nun also die Tabellen kreieren (z.B. orders_stg) und die csv-Files mit allen Attributen einlesen und PDI die benötigten Attribute lesen lassen und in die Staging Tabellen schreiben. PDI würde wohl auch erlauben, die Tabellen mit SQL Befehlen direkt zu generieren. Das habe ich aber noch nicht probiert. |
|
Ich habe ein File ("create_staging_area_schema.sql") hochgeladen, das die leere "staging area" Datenbank erzeugt, im Commit: a8d8a20 Das Spoon-File "add_data_to_staging_area.ktr" aus dem Commit c00035a fügt die Daten zu den entsprechenden Tabellen in der staging area hinzu. Das Spoon-File "transform.ktr" aus dem Commit 3e62b23 liest alle Daten aus allen Tabellen und repariert die fehlerhaften Daten (negative "discounts" aus "order_details" und doppelte Produkte in aus "products"). Bisher werden diese Daten nirgendwohin geschrieben. Was meint Ihr: sollen die Daten direkt im Transform-Schritt (also im File "transform.ktr") zum Stern-Schema umgeformt und in die DWH-Datenbank geschrieben werden, oder zunächst mal in reparierter Form zurück in die staging area geschrieben werden? Ich finde beides vertretbar. |
|
Hallo Tobias. Im Moment ist es für mich gut, wenn ich mit Deiner Transformation die korrigierten CSV-Files einlesen kann. Ich habe das erfolgreich bei mir hinbekommen, Dein Skript laufen zu lassen. Danach habe ich die korrigierten CSV-Files wieder eingelesen und bin nun soweit gekommen, dass ich eine der Dimensionstabellen füllen konnte. War aber noch etwas trial and error. Ich werde das morgen nochmal in Ruhe anschauen und für die anderen Dimensionstabellen und vor allem für die Faktentabelle machen. Dann lade ich DB Skript und PDI Skript hoch. |
|
@Eckeau ich hatte gestern Abend die "corrected.csv"-Dateien gelöscht, dann aber in Deiner Message gesehen, dass Du sie verwendet hast. Ich habe sie jetzt wiederhergestellt, d.h., wenn Du bei Dir die Änderungen aus github holst, um die Commits bezüglich der staging area zu bekommen, die ich auch gestern commited habe, bleiben die csv-Dateien erhalten. |
|
@TSchiefer Jetzt habe ich ein lauffähiges Set von Dateien, mit denen ich das Star-Schema erstellen und füllen konnte.
Ich habe mich im Wesentlichen an der Anleitung unter https://holowczak.com/building-etl-transformations-in-pentaho-data-integration-kettle/ orientiert. Am besten erst mal das in Ruhe durchlesen und die Anpassungen machen. Dann sollte man es zum laufen bringen. Nun fehlen noch gescheite Abfragen auf dem Stern-Schema. Wenn Du was hast, bin ich dankbar. |
|
Nachtrag: die Dimension Bestellung habe ich weggelassen, da sie nicht ganz einfach zu füllen ist. Ich denke, die können wir auch ganz lassen für die Lösung der Aufgabe. Wichtiger sind nun drei schlaue Auswertungen. |
|
@TSchiefer Wie siehst du das mit der "staging area", die ja bereits in der Aufgabenstellung in Anführungszeichen steht? Aus meiner Sicht kann man die ETL Transformationen in Pentaho als Staging betrachten. Wir lesen die csv Dateien dort ein und machen die Transformationen. Es steht nirgends dass die Daten persistent in einer Staging Area gespeichert werden müssen. |
|
@FischerAndi Wo stehen wir eigentlich mit Aufgabe 3? Ich habe gerade mit erschrecken festgestellt, dass das ja auch noch Implementationsarbeit beinhaltet. |
|
Ich komme gerade aus Köln. Werde heute abend Diagramm verteilen. Morgen sollte ich die Batchfiles haben. Wird diese DB mit eurem Teil verbunden? Ich dachte nicht.Von meinem Samsung Gerät gesendet.
…-------- Ursprüngliche Nachricht --------
Von: Eckeau <[email protected]>
Datum: 14.11.2018 12:24 (GMT+01:00)
An: TSchiefer/CAS_InfEng_DB_DWH <[email protected]>
Cc: Andi Fischer <[email protected]>, Mention <[email protected]>
Betreff: Re: [TSchiefer/CAS_InfEng_DB_DWH] Vorgehensweise (#2)
@FischerAndi Wo stehen wir eigentlich mit Aufgabe 3? Ich habe gerade mit erschrecken festgestellt, dass das ja auch noch Implementationsarbeit beinhaltet.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/TSchiefer/CAS_InfEng_DB_DWH","title":"TSchiefer/CAS_InfEng_DB_DWH","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/TSchiefer/CAS_InfEng_DB_DWH"}},"updates":{"snippets":[{"icon":"PERSON","message":"@Eckeau in #2: @FischerAndi Wo stehen wir eigentlich mit Aufgabe 3? Ich habe gerade mit erschrecken festgestellt, dass das ja auch noch Implementationsarbeit beinhaltet."}],"action":{"name":"View Issue","url":"#2 (comment)"}}}
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "#2 (comment)",
"url": "#2 (comment)",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [TSchiefer/CAS_InfEng_DB_DWH] Vorgehensweise (#2)",
"sections": [
{
"text": "",
"activityTitle": "**Eckeau**",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": "@Eckeau",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"TSchiefer/CAS_InfEng_DB_DWH\",\n\"issueId\": 2,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\": \"TSchiefer/CAS_InfEng_DB_DWH\",\n\"issueId\": 2\n}"
},
{
"targets": [
{
"os": "default",
"uri": "#2 (comment)"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 408952585\n}"
}
],
"themeColor": "26292E"
}
]
|
|
@FischerAndi Nein, das wird nicht verbunden. Ist eine völlig separate Aufgabe. |
|
Danke schon mal, Bernd, für all die investierte Arbeit und Zeit! Schaut m.E. gut aus. Eine Sache, bei der ich mir nicht ganz sicher bin ist, ob wir allgemein die zwei verschiedenen ID-Nummern brauchen. Hauptsächlich in der Tabelle "zeit_dim" ist das denke ich eher hinderlich, da bei ihrer Erstellung ja eine gewisse Anzahl aufeinanderfolgender Tage ab dem 1.1.2006 verwendet werden und die ID angefangen von 1 an mitläuft. Allgemein ist auch das Füllen des Star-Schemas bei mir aus irgendeinem Grund fehlgeschlagen. Ich habe dann mal anstelle des "Dimension lookup/update" Schrittes "insert / update"-Schritte verwendet. Das hat bei allen funktioniert bis auf bei der "zeit_dim"-Tabelle. Nachdem ich diese ohne die Spalte "ZEIT_ID" erzeugt habe, hat das dann auch funktioniert. Bernd, vielleicht kannst Du mir noch einen Tipp geben, was ich vielleicht falsch gemacht haben könnte, so dass Deine Methode bei mir nicht funktioniert hat. Aber ich bin zumindest froh, dass es auf diese Weise bei mir auch funktioniert. Zu den weiteren Schritten und Punkten schreibe ich dann noch später etwas. |
|
@Eckeau Müssen die Tabellen "bezahlung_dim" und "region_dim" eigentlich nicht noch auf die unique-Einträge reduziert werden? Ich könnte das morgen am Nachmittag machen, da habe ich Zeit. |
|
@Eckeau bezüglich Deiner Frage nach der staging-area: es heisst ja in der Aufgabenstellung: Ich meine, dass selbst, wenn wir die Trafos ausserhalb der staging area durchführen, es in Ordnung ist. |
|
@TSchiefer DIe Reduktion der Dimensionen auf unique Einträge konnte ich nun machen. Die künstlichen Schlüssel bei Zeit, Region und Bezahlung habe ich entfernt. Bei den anderen beiden braucht es die für's Mapping, wenn die Fakten-Tabelle erstellt wird. Allerdings hat es irgendwo noch einen Fehler beim Mapping auf die Dimensionen Bezahlungsart und Region. Da stimmen die Werte in der Faktentabelle nicht. Muss hier noch nach dem Fehler suchen. Generell scheint der Dimension Lookup Step für DWH Schemas gedacht zu sein, nicht der insert/update Schritt. Ich habe mich jetzt aber nicht mit dem Unterschied befasst. Ziemlich sicher hat es aber mit den Slowly Changing Dimensions zu tun. Die bekommst Du vermutlich auf die andere Art nicht hin. Bei den ersten Test-Queries musste ich zudem feststellen, dass sich in den Produktnamen am Ende Blanks eingeschlichen haben. Das muss auch noch weg. Aus der Ferne schwer zu sagen, was bei Dir nicht ging. Geben die Fehlermeldungen Hinweise? Unbedingt immer den SQL Button klicken und danach Execute. Muss man leider nach jedem Durchgang machen. Und den Cache leere ich auch immer. |
|
@TSchiefer Das Problem mit den Blanks in der Query konnte ich lösen. Es gibt einen trim Parameter beim import. Ich vermute mal dass die Blanks auch die Probleme bei den beiden Dimensionstabellen verursachen. Dort mappe ich im Gegensatz zu den anderen Dimensionen über Felder vom Typ String. Das scheint nicht zu klappen. Ein weiterer Verdächtiger sind NULL Werte, die es zumindest bei payment_type gibt. Die behandle ich nicht explizit was ich womöglich müsste. |
|
So, die Pentaho-Files sind jetzt auch bei mir durchgelaufen. Ich hatte tatsächlich nicht auf den SQL-Button geklickt, aber nachdem ich das gemacht habe, hat es funktioniert. Die Faktentabelle sieht aber nach Laufenlassen aller Files bei mir so aus, wie im folgenden Screenshot, also mit zuvielen Spalten, und BEZ_ID_DIM und REGION_ID_DIM scheinen mir nicht zu stimmen. Habe eigentlich nur Deine Pfade durch meine lokalen ersetzt und sonst denke ich nichts Schlimmes getan.
Ich würde jetzt jedenfalls mal anfangen, etwas zum ersten Teil des Projekts in Word aufzuschreiben. Wir können ja alle an unterschiedlichen Word-Dateien arbeiten und dann einen "Freiwilligen" dazu verdonnern, das am Ende zusammenzufügen. Ich melde mich schonmal freiwillig :) Wenn ich noch an einer anderen Sache arbeiten soll, bitte Bescheid geben! |
![https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open](https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open){kind=link}
|
@TSchiefer Nun funktioniert bei mir alles, nachdem ich konsequent bei allen String Elementen vorne und hinten Blanks abschneide (in Pentaho mit "Trim Type" = "both"). Ich habe noch ein paar Queries eingefügt, die aber noch nicht dem entsprechen, was wir definiert hatten. Mit der kleinen Datenmenge ist es etwas schwierig, Queries zu finden, die interessante Ergebnisse liefern. Warum es bei Dir alle Spalten in die DB schreibt, ist mir nicht klar. Schau doch mal im letzten Step der facts-table Transformation nach was dort unter "Database Fields" steht. Vor einem vollständigen Run unbedingt das Star Schema sql Skript nochmal ausführen und im Pentaho unter Tools -> Database -> Clear Cache aufrufen. Die Facts-Table muss 58 Einträge haben, sonst war was nicht gut. Bitte schaue Dir die Transformationen auch inhaltlich an, ob das für Dich alles Sinn macht. |
|
@TSchiefer Neue Files sind natürlich hochgeladen :-) |
|
Im Commit 36d63a0 habe ich mal eine erste Version des Reports hochgeladen. Ist es mit Euren Word-Versionen kompatibel? Schaut Euch bitte mal das Inhaltsverzeichnis an, ob es Euch zusagt. Ich meine, es macht Sinn, wenn die Übersetzung in den uns bekannten ERM-Dialekt an den Anfang kommt. |
|
Danke für Deine Arbeit. Wann ist die Deadline für die Eingabe? Sonntag um 11:00 Uhr? |
|
Deadline ist morgen um 18:00 Uhr laut Angabe.
… On 17 Nov 2018, at 12:21, Andi Fischer ***@***.***> wrote:
Danke für Deine Arbeit.
Ich kann den Report ohne Probleme lesen und passt für mich sehr gut so.
Wann ist die Deadline für die Eingabe? Sonntag um 11:00 Uhr?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALDxewA1L0LgAem26qW9PVYL6b1igZS7ks5uv_EmgaJpZM4YYB8J>.
|
|
Danke! Funktioniert bei mir auch. Für mich macht das in der Struktur Sinn. Ich sollte ab späten Nachmittag genug Zeit haben, meine Kapitel zu füllen. |
|
@TSchiefer Ich habe noch eine leicht angepasste Version der staging Transformation abgelegt. Die musst Du nicht laufen lassen, aber für die Screenshot wären die Lookup Steps besser benannt. Inhaltlich sollte sich in dern Schritten nichts mehr geändert haben, aber wenn Du sicher gehen willst nimmst Du auch dort die Screenshots von der neuen Version. |
|
18:00 Uhr muss es eingegeben sein. Mit Deadline meinte ich eigentlich, dass alles bereit zum Zusammenführen sein muss. Ich denke, dass Git nicht die verschiedenen Word-Beiträge mergen kann. |
|
Aha, ja, ich würde sagen, 11 Uhr oder spätestens 12 Uhr für die verschiedenen Beiträge klingt vernünftig. Wie gesagt übernehme ich dann gerne das Zusammenführen. |
|
Das Zip-File kann ich dann auch erstellen. Ich würde vorschlagen, dass wir ein spezielles Verzeichnis erstellen (z.B. "Dateien_für_ZIP-File"), in dem wir alle relevanten Dateien ablegen, nicht dass es da noch Verwechslungen gibt. |
|
Ach so, und bitte Eure Teile des Reports jeweils in einem Word-Dokument anderen Namens hochladen... |
|
Habe im Commit 33b770d die Dateien Dazu möchte ich Euch auch bitten, mal den im Commit 6709859 upgedateten Report anzusehen. Was meinst Du, Bernd, könntest Du eventuell noch den Input aus der staging-area DB machen und auch nach dem reparieren dort rein schreiben (wahrscheinlich wäre überschreiben der fehlerhaften Daten ok)? In dem Fall würde ich die oben erwähnten noch in der staging-area DB fehlenden Daten schnell ergänzen. Andernfalls lassen wir es einfach so, wie es jetzt ist. Wenn Ihr in dem Fall Ideen für positiver klingende Formulierungen im Kapitel "3. Erstellung der staging-area" habt, nehme ich diese gerne und dankend an. |
|
@TSchiefer Ich finde das gut, wenn wir das im Report so beschreiben, dass wir mit den csv-Files gearbeitet haben, zugleich aber im Report prinzipiell aufzeigen, wie eine Integration über eine Staging DB ausgesehen hätte. Man kann auch durchaus explizit sagen, dass es wir zur besseren Aufteilung der Arbeit den einfachen Ansatz gewählt haben und für eine Integration über die DB dann nicht mehr Zeit übrig war. Ich habe übrigens auch grosse Probleme mit Foreign Key Constraints gehabt. Die habe ich dann weggelassen, dann lief es jeweils gut. Das war jetzt auch mit Deinen neuen Transformationen so. Dann ist auch die Reihenfolge egal. Ganz sauber ist es vermutlich nicht, aber was soll's. |
|
klingt vernünftig, machen wir so! Ich formuliere das dann noch entsprechend um. @Eckeau Nur zur besseren Absprache: ich bin momentan in der Mitte von Kapitel "4. Reparieren der korrupten Daten" und würde das zuende schreiben. Ich denke, Kapitel 5, 6 und 7 hast Du bei weitem die bessere Expertise. Was Kapitel 8 angeht, sollen wir da alle drei vielleicht ein paar Worte schreiben? Wir können auch hier in github noch ein wenig brainstormen, was wir da noch erzählen wollen. |
|
@TSchiefer Damit der Staging-DB Ansatz funktionieren würde, müsste in die customer Tabelle noch first_name und last_name. Wenn Du das noch ändern kannst, dann wäre es zumindest konsistent und glaubwürdig, dass wir das hätten so noch umbauen können. Ich werde das zeitlich nicht mehr schaffen. Mir ist es wichtiger, dass wir ein paar gescheite Auswertungen haben. Da fühle ich mich noch nicht ganz komfortabel. |
|
und ja, ich bin mit Kapitel 5 bis 7 dran. 5 und 6 sind weitgehend fertig. 7 fehlt noch. |
|
ok, bin dran mit der Umstellung der Staging-Area-DB. |
|
Mein Input für den Report liegt nun im Report Verzeichnis. Ausserdem habe ich wie vorgeschlagen den ZIP Files Ordner erstellt und meine Dateien abgelegt. Sorry, ich habe vergessen eine gescheite Beschreibung anzugeben und weiss nun nicht, wie man das nachträglich ändert. Wir könnten das Problem mit den Foreign Key Constraints unter Kapitel 8 las Verbesserung erwähnen. Also Foreign-Keys definieren und die Reihenfolge der Ausführung in Pentaho darauf abstimmen. |
|
Super, danke! Eine kleine Frage noch: bin gerade bei der Beschreibung von "staging_area-v2.ktr". Im zweiten Schritt des "order_details"-Astes habe ich gerade gesehen, dass auch "employee_id" hinzugefügt wird. Wird das später gebraucht? Ich habe jetzt nämlich die staging-area DB aktualisiert, aber diese Variable habe ich nicht drin. |
|
Wird glaube ich nicht gebraucht. |
|
wenn Du magst, kannst Du sie rauslöschen, ist aber nicht wichtig. Ich habe eine kleine Bemerkung in meinen Teil des Reports geschrieben, dass sie zwar zum Stream hinzugefügt wird, aber im Folgenden nicht verwendet wird und dass sie auch nicht in der staging-area Datenbank vorkommt. |
|
ich bin noch nicht fertig mit dem Report. Z.B. habe ich Deinen Kommentar von vorhin noch nicht eingebaut, Bernd, aber ich habe jetzt doch mal einen Commit (c670a1f) hochgeladen, da ich den Rest morgen Früh mache. |
|
Danke! Ich schaue dann morgen Vormittag wieder rein. Lass uns da nicht perfektionieren, sondern im 80:20 Sinne lösen. Ich habe alleine schon fast 20 Seiten mit Screenshots und etwas Text gefüllt... |
|
Mir wäre es noch wichtig, dass Ihr Euch die Auswertungen anschaut, ob die Sinn machen. Da habe ich nicht wahnsinnig viel Überlegungen hineingesteckt. Die Queries scheinen immerhin das zu liefern, was eine manuelle Überprüfung mich hat erwarten lassen, also sie sind mit etwas Glück nicht völlig falsch. |
|
Hehe, der arme Dr. Aebi... wird viel zu tun haben mit der Korrektur! Aber er hat uns ja auch immer mit 100 Seiten pro Nachmittag getriezt. Queries anschauen mache ich dann morgen als Erstes. |
Hier könnt Ihr Erklärungen, Fragen, oder einfach Kommentare zu Vorgehensweisen bei Teilaspekten der Aufgaben loswerden.
The text was updated successfully, but these errors were encountered: