Wie und warum ich eine Datenübermittlungsplattform aufgebaut habe

Über mich

Ich arbeite seit einigen Jahren für Deloitte Consulting – hauptsächlich im öffentlichen Sektor/Bildungsbereich

Das Problem, das ich lösen wollte

Sie haben 5600 Kundenseiten. Sie verteilen sich über eine Fläche von etwa 65.000 Quadratmeilen (die Größe von Wisconsin). Sie haben eine Mischung aus Konnektivität, die von Null bis Vollfaser reicht.

Jede dieser Sites muss Ihnen jeden Monat eine Datei von etwa 100 MB senden, und sie müssen es sein:

ein schneller
b) meldepflichtig
c) wiederholbar
d) einfach zu bedienen

Dies alles muss mit einer maximalen Zeit von 5 Minuten pro Übermittlung (vom Hochladen bis zum Import) in ein GIANT SQL Warehouse geladen werden.

Was ist die Datenübermittlungsplattform?

Ich habe eine Reihe von Tools gebaut:

  1. Submission – verarbeitet Authentifizierung, Uploads und Verifizierung
  2. Governor – Datenprüfungen, Validierung, Ablehnung und Warteschlangen
  3. Uploader – schneller Massenimport ins Data Warehouse

Tech-Stack

PHP/MySQL

C#/ASP.net und MS SQL

Der Prozess des Aufbaus einer Datenübermittlungsplattform

Zuerst wurde das PHP/MySQL-Einreichungssystem erstellt – dies war der anfängliche Entwurf für das System.

Als nächstes habe ich das Upload-Tool erstellt, das ebenfalls auf PHP/MySQL läuft. Dabei wurden das CodeIgniter-Framework und mehrere benutzerdefinierte PHP-Module verwendet, die ich für diesen Zweck erstellt habe. Die Authentifizierung wurde mit einem benutzerdefinierten Authentifizierungsmodul durchgeführt.

Als sich dies als zu langsam herausstellte, änderte ich das gesamte System wie folgt:

  1. Aufteilung der Funktionen in 3 vollständige Anwendungen (Submission, Governor, Uploader)
  2. Ändern des Tech-Stacks in C#/ASP.net/MSSQL
  3. Massive Überarbeitung des Upload-Tools auf Parallelverarbeitung und Asynchronität

Herausforderungen, denen ich mich gestellt habe

Mein erster Build hat alles in einem gemacht – eine PHP/MySQL-Monstrosität, die ständig aktualisiert und überwacht werden musste. Es hat auch die primäre Anforderung verletzt – Geschwindigkeit. Wenn 5600 Leute gleichzeitig versuchen, 100 Millionen hochzuladen, hat man neue und aufregende Probleme.

Wenn dann 5600 100MB-Dateien auf Ihrem Server landen und Sie diese so schnell wie möglich verarbeiten müssen, stellen Sie fest, dass Ihre aktuelle Geschwindigkeit bei 5 Minuten liegt pro Einreichung bedeutet 19 Tage solides Hochladen. Das wird nicht funktionieren.

Die vollständige Überarbeitung und Neuschreibung des gesamten technischen Systems verkürzte die Zeit auf ~ 30 Sekunden pro Einreichung. Viel gesünder.

Schlüsselqualifikationen

  1. Hören Sie nie auf, sich zu verbessern, hören Sie nie auf, neu zu programmieren
  2. Töte deine Lieblinge – nur weil dir eine Funktion oder Methode gefällt, bedeutet das nicht, dass sie leben sollte.
  3. In manchen Fällen ist Geschwindigkeit alles. Es spielt keine Rolle, ob die Benutzeroberfläche so hübsch ist, wie Sie möchten, ob sie funktional oder effizient ist.
  4. So gigantisch es auch scheinen mag, scheuen Sie sich nicht, Ihren Tech-Stack komplett zu ändern, wenn es nötig ist.

Tipps und Ratschläge

  1. Bulk Insert ist Ihr Freund – für Massentransaktionen in SQL Server ist es großartig.
  2. Die Parallelverarbeitung ist noch mehr Ihr Freund. Wenn Sie einen in 60s schaffen, können Sie einen Weg finden, zwei in 30s zu schaffen.
  3. Dokumentieren! Alles dokumentieren. Die ganze Zeit. Wenn ich mein anfängliches System nicht richtig dokumentiert hätte, wäre meine Zeit zum Pivotieren viel länger gewesen.

Abschließende Gedanken und nächste Schritte

Ich muss jetzt ein wirklich robustes Reporting-Framework um dieses System herum aufbauen und einige der aktuellen Prozesse in Node/React umrüsten. Zusätzlicher Spaß.

Similar Posts

Leave a Reply

Your email address will not be published.