Einleitung

In der heutigen datengesteuerten Landschaft erleben sowohl KMUs als auch große Unternehmen einen dramatischen Anstieg des Datenvolumens, was eine noch nie dagewesene Belastung für ältere analytische Datenbanken darstellt. Systeme wie Oracle und andere alte Datenbanken wie IBM DB2 und Sybase können die schiere Datenmenge nur schwer bewältigen, was zu Leistungsengpässen führt. Dies ist besonders problematisch, da Kundenanalysen für die Entscheidungsfindung von Unternehmen entscheidend geworden sind. Die Zunahme datengesteuerter Strategien erfordert robuste und leistungsstarke Analyse-Engines, die große Datenmengen effizient verarbeiten können. Darüber hinaus ist die Sicherstellung der Datenintegrität und -genauigkeit bei Migrationen angesichts der immer strengeren gesetzlichen Anforderungen und Compliance-Standards wichtiger denn je.

‍

Tools und Prozesse für eine reibungslose Datenbankmigration

Während eines kürzlich durchgeführten Datenbankmigrationsprojekts erwiesen sich mehrere Tools und Prozesse als hilfreich, um den Fokus aufrechtzuerhalten und eine nahtlose, rechtzeitige und effiziente Migration zu gewährleisten. Im Folgenden finden Sie eine Übersicht über die Methoden und Tools, die eine erfolgreiche Migration ermöglichten.

Vorlagenerstellung

Eines der wichtigsten Werkzeuge war eine Cookiecutter-Vorlage, mit der ein strukturierter Arbeitsablauf für jede zu migrierende Tabelle erstellt wurde. Diese Vorlage beinhaltete:

Dynamische Variablen sind wie folgt:

json

{
"uc_name": "default_migration_use_case",
"script_name": "default_script_name",
"hive_table_name": "standard_hive_table_name",
"hive_write_schema": "default_hive_write_schema",
"es_index_name": "default_es_index_name"
}

Verzeichnis für alten Code: (`sas_code`) Ein zentraler Ort, um die Legacy-Skripte zu speichern.

‍R-Shiny Server Integration: (`shiny_code_translator`) Dieses Skript startet einen R-Shiny Server, der den alten Code in überschaubare Teile zerlegt. Jeder Brocken wird dem Benutzer zur Überprüfung vorgelegt, mit der Möglichkeit, die Funktionalität des Codes zu erklären. Außerdem werden KI-generierte Codeübersetzungen zur Genehmigung durch den Entwickler bereitgestellt.

‍

proc sql ;
create table work.antragsparameter as select
a.* ,
b.parameter ,
b.wert ,
b.beginn ,
b.ende
from work.funksystem a left join daten.param_ubg b
on   a.ubg_id eq b.id
    and b.beginn le a.ne_ende
    and b.ende gt a.ne_start
    and b.ende gt today()
order by id, ne_start, ubg_id, parameter, beginn, ende ;
drop table work.funksystem ;
quit ;

data work.antragsparameter ;
set work.antragsparameter ;
by id ne_start ubg_id parameter ;
if first.id or first.ne_start or first.ubg_id or first.parameter ;
run ;

proc transpose data=work.antragsparameter out=work.funksystem_param ;
var wert ;
by id ne_start ubg_id funksystem_adr1;
id parameter ;
run ;
                    

‍

Skript-Kompilierung: Nach der Freigabe werden die übersetzten Code-Bausteine zu einem vollständigen Skript kompiliert.

Das Skript wird im Verzeichnis `src` abgelegt.

Bereitstellungsstruktur: Vorlagen für die Bereitstellung der neuen Skripte mithilfe von Tools wie Airflow, Ansible und der Einrichtung von Elasticsearch- und Kibana-Indexmustern.

Dieser Ansatz gewährleistet einen standardisierten Prozess für die Behandlung jeder Tabelle, wodurch die Migration besser verwaltbar und konsistent ist.

Deterministische Tests

Um die Genauigkeit der übersetzten Skripte zu gewährleisten, war das deterministische Testen ein entscheidender Schritt. Dies umfasste mehrere Komponenten:

SolarCube-Integration: Frühzeitiges Refactoring der übersetzten Skripte mit SolarCube, um die Codequalität und die Wartbarkeit zu verbessern.

Vergleichsskript: Es wurde ein Skript entwickelt, um die ursprünglichen und übersetzten Tabellen zu vergleichen. Für jede Zeile in der Originaltabelle generierte das Skript einen Bericht mit drei Spalten für jede Originalspalte:

Links: Der ursprüngliche Eintrag.

Rechts: Der übersetzte Eintrag.

Ergebnis: Ein Indikator dafür, ob die beiden Einträge identisch sind.

Pseudocodebeispiel auch für mrbean-Skript

Zusätzlich wurde ein Anti-Join-Skript erstellt, um fehlende Einträge in der übersetzten Tabelle zu identifizieren. Hier ist ein einfacher Pseudocode-Schnipsel für die Mismatch-Abfrage:

Durch diesen Vergleichsprozess wurden Unstimmigkeiten frühzeitig aufgedeckt, so dass rechtzeitige Korrekturen möglich waren.

Debugging-Sitzungen

Automatisierte Debugging-Sitzungen spielten eine wichtige Rolle bei der Identifizierung und Behebung von Problemen. Der Prozess umfasste:

Automatische Haltepunkte: Es wurden Haltepunkte in den Code eingefügt, zusammen mit Erwartungen für Zwischenergebnisse.

Vergleiche von Inhalt und Anzahl: An jedem Haltepunkt wurden der Inhalt und die Anzahl der Daten verglichen.

Feststellen von Problemen: Dieser Schritt half dabei, schnell zu erkennen, wo die Diskrepanzen auftraten.

Hier ist ein Beispiel für die Festlegung von Erwartungen mit Hilfe von SAS-Makros:

Diese automatisierten Prüfungen stellten sicher, dass Probleme sofort erkannt und behoben wurden, wodurch Ausfallzeiten minimiert und die Datenintegrität gewährleistet wurde.

Hier ist das vollständige Prozessablaufdiagramm:

flowchart TB
    B[Create Cookiecutter Template]
    subgraph templating
    direction TB
    B --> C[Store Old Code in Repository]
    end
    subgraph translator
    direction TB
    D[Spawn R-Shiny Server]
    D --> E[Separate Old Code into Chunks]
    E --> F[User Explains Code Chunks]
    F --> G[Generate AI Code Translations]
    G --> H[Developer Reviews and Approves Translations]
    end
    subgraph scripting
    direction TB
    I[Compile Approved Translations into New Script]
    I --> J[Deploy New Script using Deployment Templates]
    end
    subgraph debugging
    direction TB
    subgraph refactor
    direction TB
    L[Refactor Code with SolarCube]
    end
    subgraph table_comp
    direction TB
    M[Compare Original and Translated Tables]
    M --> N[Generate Comparison Report]
    N --> O[Identify Missing Entries with Anti-Join Script]
    end
    subgraph breakpoints
    direction TB
    P[Conduct Debugging Sessions]
    P --> Q[Insert Breakpoints and Set Expectations]
    Q --> R[Compare Content and Counts at Breakpoints]
    R --> S[Pinpoint Issues]
    end
    S --> T[Resolve Issues and Update Code]
    end
    templating --> translator
    translator --> scripting
    scripting --> debugging
    refactor --> table_comp
    table_comp --> breakpoints