Blog

GoDataDriven Open Source Beitrag für Q4 2019

Aktualisiert Oktober 21, 2025

5 Minuten

Im letzten Quartal 2019 hat das GoDataDriven-Team wieder zu vielen Open-Source-Projekten beigetragen. Bei GoDataDriven lieben wir Open Source. Offene Quellen ermöglichen es uns, Fehler selbst zu beheben und den Code zu durchforsten, wenn wir in der Dokumentation nichts finden können (ich schaue Sie an, Airflow). Dies beseitigt Hindernisse für unsere Kunden und ermöglicht es ihnen, ihr Streben nach mehr Datenorientierung fortzusetzen. Gleichzeitig versuchen wir, die Welt zu verbessern, indem wir Bugs patchen, Sicherheitsprobleme beheben und Funktionen implementieren.

Start

Takeoff ist ein Deployment-Tool, das ursprünglich am Flughafen Schiphol entwickelt wurde und vollständig Open Source ist. Es hilft Ihnen bei der Automatisierung und Erstellung vollständig reproduzierbarer Bereitstellungen in Ihrer bevorzugten Cloud. Weitere Informationen finden Sie in dem hervorragenden Blog der Autoren.

Unser neuer Mitarbeiter Daniel Heres hat Takeoff unter die Lupe genommen und ist dabei auf einige Tippfehler in der Dokumentation gestoßen, die er nun behoben hat:

Landebahn umbenennen -> Takeoff
Link in der Dokumentation korrigieren
Einige Umbenennungen, Änderungen im Schema
azure_service_principal -> service_principal
Tippfehler korrigieren
Korrektur für Beispielcode in der Dokumentation der Takeoff-Plugins

Daniel van der Ende hat sich auch die Zeit genommen, die Dokumente zu verbessern:

Korrigieren Sie defekte Links in den Github-Seiten-Dokumenten
Fantastische Ascii-Kunst hinzufügen
Fehlerhafte Startkonfiguration in der Dokumentation korrigiert

Schließlich fand er auch noch die Zeit, ein paar Bugs zu beseitigen und einige Funktionen hinzuzufügen:

Fehler im neuesten Docker-Tag behoben
Bugfix: Verwendung des richtigen Clients für Azure-Provider
Base64-Kodierung von k8s-Vorlagenwerten korrigiert
Hinzufügen der Möglichkeit, benutzerdefinierte Werte an k8s jinja zu übergeben

Datenerstellungs-Tool (DBT)

Als ich mich mit der Codebasis von DBT vertraut machte, stieß ich auf einige kleinere Codegerüche und beschloss, einige Anmerkungen hinzuzufügen, um den Code lesbarer zu machen:

Verwenden Sie generated_at anstelle von datetime.utcnow()
Entfernen Sie das Duplikat get_context_modules
Hinzufügen von Anmerkungen zum Code

Als Apache Spark-Liebhaber haben wir uns außerdem die Zeit genommen, die Unterstützung für Spark zu erweitern:

Unterstützung für das Extrahieren von Statistiken hinzufügen
Unterstützung für das Erstellen/Löschen von Schemas hinzufügen
Ziehen Sie den Eigentümer aus dem Feld DESCRIBE EXTENDED
Apache Spark Unterstützung

Apache Airflow

Viele unserer Kunden verwenden Airflow, um ihre Datenpipelines zu orchestrieren. In letzter Zeit gab es Bemühungen, die Speicherung des Status auf Aufgabenebene zu ermöglichen. Die erste Idee war, dies in der xcom-Tabelle zu speichern. Xcom steht für Cross-Communication und wird für den Austausch von Zuständen zwischen Aufgaben verwendet. Mit ein paar kleinen Änderungen könnten wir dies auch für die gemeinsame Nutzung von Zuständen innerhalb einer Aufgabe verwenden. Das Hauptproblem mit dem Status ist, dass einige Ausführungen per Definition nicht-idempotent sind. Daran arbeiten wir noch. Einzelheiten finden Sie in der AIP.

[AIRFLOW-5806] Vereinfachen Sie die xcom-Tabelle
[AIRFLOW-5804] Stapeln Sie den xcom Pull-Vorgang
[AIRFLOW-5688] Zusammenführen von alembischen Migrationen
[AIRFLOW-5792] Begradigen Sie die Migrationen
[AIRFLOW-5771] Begradigen Sie Alembic-Migrationen
AIRFLOW-5701: Löschen Sie xcom nicht explizit vor der Ausführung

Apache Parkett

Parquet ist das De-facto-Dateiformat für OLAP-Workloads in Data Lakes. Wir arbeiten daran, uns auf Java 11 vorzubereiten, daher wurden einige Abhängigkeiten aktualisiert:

PARQUET-1496: Scala auf 2.12 aktualisieren
PARQUET-1673: Aktualisieren Sie die Version des parquet-mr Formats auf 2.7.0

Apache Avro

In Avro haben wir einen Regressionsfehler entdeckt, der durch die Integrationstests von Apache Iceberg aufgedeckt wurde. Er wurde nach dem großen Refactor der Schemaauflösungslogik eingeführt. Ich habe etwa drei Tage gebraucht, um diesen Fehler zu finden, und er wurde in einer einzigen Zeile behoben:

AVRO-2663: Datensatz innerhalb von Union wird nicht richtig aufgelöst

Nachdem wir diesen Fehler behoben haben, beginnen wir mit der Veröffentlichung von Avro 1.9.2. Dazu gehört auch die Aktualisierung einiger Abhängigkeiten auf die neueste Version, um sicherzustellen, dass wir auf dem neuesten Stand sind:

Reparieren Sie das CI:

AVRO-2664: Pin Ruby rdoc auf <=6.2.0

Apache Spark

Für Apache Spark haben wir einige Sicherheits-Patches durchgeführt:

[SPARK-29445][CORE] Bump netty-all von 4.1.39.Final auf 4.1.42.Final
[SPARK-29483][BUILD] Bump Jackson auf 2.10.0
[SPARK-27506][SQL] Erlaubt die Deserialisierung von Avro-Daten unter Verwendung kompatibler Schemata. Ich habe einen veralteten PR aufgegriffen, um Avro-Dateien mit einem benutzerdefinierten Schema zu lesen.

Und GoDataDriven wird jetzt im Abschnitt Powered By auf der Spark-Website erwähnt:

GoDataDriven zu der Liste hinzufügen

Apache Iceberg (Inkubierend)

Als ich mit Iceberg herumspielte und mich mit dem Programm vertraut machte, fiel mir auf, dass die Dokumentation unvollständig war. Dies führte natürlich zu einem PR: