Wie nähert man sich einer ETL-Mission?

Einige allgemeine ETL-Tipps

1. Erwägen Sie eine Organisation nach Ziel (z. B. befindet sich der gesamte Code zur Erstellung der Customer-Dimension im selben Modul, unabhängig von der Quelle). Dies wird manchmal als subjektorientierte ETL bezeichnet. Es macht das Auffinden von Dingen viel einfacher und erhöht die Wartbarkeit Ihres Codes.

2. Wenn die SQL2000-Datenbank ein Durcheinander ist, werden Sie wahrscheinlich feststellen, dass SSIS-Datenflüsse eine ungeschickte Art sind, mit den Daten umzugehen. ETL-Tools skalieren in der Regel schlecht mit Komplexität; etwa die Hälfte aller Datawarehouse-Projekte in Finanzunternehmen werden mit Stored Procedure Code als explizite Architekturentscheidung durchgeführt – genau aus diesem Grund. Wenn Sie eine große Menge an Code-Insprocs einfügen müssen, sollten Sie all verwenden des Codes in Sprocs.
   
   Für ein System, das viele komplexe Bereinigungen oder Transformationen erfordert, ist ein 100-prozentiger Sproc-Ansatz weitaus wartungsfreundlicher, da dies der einzig praktikable Weg ist, alle Transformationen und Geschäftslogik an einem Ort zu platzieren. Bei gemischten ETL/sproc-Systemen müssen Sie an mehreren Stellen suchen, um die gesamte Transformation zu verfolgen, zu beheben, zu debuggen oder zu ändern.

3. Der Sweet Spot von ETL-Tools liegt auf Systemen, auf denen Sie eine größere Anzahl von Datenquellen mit relativ einfachen Transformationen haben.

4. Machen Sie den Code testbar, damit Sie die Komponenten auseinandernehmen und isoliert testen können. Code, der nur innerhalb eines komplexen Datenflusses in einem ETL-Tool ausgeführt werden kann, ist viel schwieriger zu testen.

5. Machen Sie den Datenextrakt mit Nobusiness-Logik dumm und kopieren Sie ihn in einen Staging-Bereich. Wenn Ihre Geschäftslogik über die Extraktions- und Transformationsschichten verteilt ist, werden Sie Transformationen haben, die nicht isoliert getestet werden können, und die das Aufspüren von Fehlern erschweren. Wenn die Transformation von einem Staging-Bereich aus ausgeführt wird, reduzieren Sie die harte Abhängigkeit vom Quellsystem, was wiederum die Testbarkeit verbessert. Dies ist ein besonderer Gewinn für sproc-basierte Architekturen, da es eine nahezu vollständig homogene Codebasis ermöglicht.

6. Erstellen Sie einen generischen Handler für langsam veränderliche Dimensionen oder verwenden Sie einen handelsüblichen, falls verfügbar. Dies macht es einfacher, diese Funktionalität zu testen. Wenn dies einheitsgetestet werden kann, muss der Systemtest nicht alle Eckfälle testen, sondern lediglich, ob die ihm präsentierten Daten korrekt sind. Das ist nicht so komplex, wie es sich anhört - Das letzte, das ich geschrieben habe, umfasste etwa 600 oder 700 Zeilen T-SQL-Code. Dasselbe gilt für alle generischen Scrubbing-Funktionen.

7. Laden Sie inkrementell, wenn möglich.

8. Instrumentieren Sie Ihren Code – lassen Sie ihn Protokolleinträge erstellen und möglicherweise Diagnosen wie Prüfsummen oder Zählungen aufzeichnen. Ohne dies ist eine Fehlersuche nahezu unmöglich. Außerdem ist die Assertion-Überprüfung eine gute Möglichkeit, an die Fehlerbehandlung zu denken (zählt die Zeile in einer gleichen Zeilenanzahl in b, ist die A:B-Beziehung wirklich 1:1).

9. Verwenden Sie synthetische Schlüssel. Die Verwendung natürlicher Schlüssel aus den Quellsystemen bindet Ihr System an die Datenquellen und erschwert das Hinzufügen zusätzlicher Quellen. Die Schlüssel und Beziehungen im System sollten immer übereinstimmen - keine Nullen. Machen Sie für Fehler „nicht erfasst“ einen spezifischen „Fehler“- oder „nicht erfasst“-Eintrag in der Maßtabelle und passen Sie diese an.

10. Wenn Sie einen Betriebsdatenspeicher aufbauen (der Gegenstand vieler Religionskriege ist), recyceln Sie die ODS-Schlüssel in den Sternschemata nicht. Verbinden Sie sich auf jeden Fall mit ODS-Schlüsseln, um Dimensionen zu erstellen, passen Sie jedoch mit einem natürlichen Schlüssel zusammen. Auf diese Weise können Sie das ODS beliebig löschen und neu erstellen – möglicherweise durch Ändern seiner Struktur – ohne die Star-Schemata zu stören. Diese Funktion ist ein echter Wartungsgewinn, da Sie die ODS-Struktur jederzeit ändern oder eine Brute-Force-Neubereitstellung des ODS durchführen können.

Die Punkte 1-2 und 4-5 bedeuten, dass Sie ein System bauen können, in dem alle des Codes für ein bestimmtes Subsystem (z. B. eine einzelne Dimensions- oder Faktentabelle) befindet sich an einem und nur einem Ort im System. Diese Art von Architektur eignet sich auch besser für eine größere Anzahl von Datenquellen.

Punkt 3 ist ein Kontrapunkt zu Punkt 2. Grundsätzlich ist die Wahl zwischen SQL- und ETL-Werkzeugen eine Funktion der Transformationskomplexität und der Anzahl der Quellsysteme. Je einfacher die Daten und je größer die Anzahl der Datenquellen, desto stärker spricht ein werkzeugbasierter Ansatz. Je komplexer die Daten sind, desto mehr spricht für den Wechsel zu einer Architektur, die auf gespeicherten Prozeduren basiert. Im Allgemeinen ist es besser, ausschließlich oder fast ausschließlich das eine oder das andere zu verwenden, aber nicht beide.

Punkt 6 erleichtert das Testen Ihres Systems. Das Testen von SCDs oder anderen änderungsbasierten Funktionen ist umständlich, da Sie in der Lage sein müssen, dem System mehr als eine Version der Quelldaten zu präsentieren. Wenn Sie die Änderungsverwaltungsfunktionalität in den Infrastrukturcode verschieben, können Sie sie isoliert mit Testdatensätzen testen. Dies ist ein Gewinn beim Testen, da es die Komplexität Ihrer Systemtestanforderungen reduziert.

Punkt 7 ist ein allgemeiner Performance-Tipp, den Sie bei großen Datenmengen beachten sollten. Beachten Sie, dass Sie möglicherweise nur für einige Teile eines Systems inkrementelles Laden benötigen; für kleinere Referenztabellen und Abmessungen benötigen Sie es möglicherweise nicht.

Punkt 8 ist relevant für jeden Headless-Prozess. Wenn es in der Nacht schief geht, möchten Sie am nächsten Tag eine Chance haben, zu sehen, was schief gelaufen ist. Wenn der Code nicht richtig protokolliert, was vor sich geht, und Fehler abfängt, haben Sie es viel schwerer, ihn zu beheben.

Punkt 9 gibt dem Data Warehouse ein Eigenleben. Sie können Quellsysteme einfach hinzufügen und entfernen, wenn das Lager über eigene Schlüssel verfügt. Warehouse Keys sind auch notwendig, um sich langsam ändernde Dimensionen zu implementieren.

Punkt 10 ist ein Gewinn für Wartung und Bereitstellung, da das ODS neu strukturiert werden kann, wenn Sie neue Systeme hinzufügen oder die Kardinalität eines Datensatzes ändern müssen. Es bedeutet auch, dass eine Dimension ohne Abhängigkeit von den ODS-Schlüsseln von mehr als einer Stelle im ODS geladen werden kann (denken Sie an das Hinzufügen manueller Buchhaltungsanpassungen).