Mit der ETL-Pipeline dachte ich, ich hätte ziemlich intestine verstanden, was Knowledge Engineering eigentlich ist. Sie extrahieren Daten von irgendwoher, bereinigen sie und laden sie an einen nützlichen Ort. ETL. Ganz einfach.
Zum Vergleich: Ich bin ein Datenanalyst, der versucht, in die Datentechnik überzugehen. Ich habe diese Reise öffentlich dokumentiert, angefangen mit a 12-monatige Roadmap für das Selbststudium Ich habe es Anfang des Jahres zusammengestellt. Der letzte Schritt auf dieser Reise battle Ich baue meine erste ETL-Pipeline von Grund auf auf Verwenden der GitHub-API, über die ich hier auf TDS geschrieben habe. Diese Pipeline hat funktioniert. Es hat Daten abgerufen, bereinigt und in einer CSV-Datei gespeichert. Ich battle damit zufrieden.
Additionally beschloss ich, es weiter voranzutreiben und es „produktionsreifer“ zu machen, wie das Web gerne sagt. Was dann geschah, überraschte mich wirklich. Nicht weil etwas kaputt ging, sondern wegen dem, was der Bruch offenbarte.
Die ursprüngliche Pipeline
Die ursprüngliche Pipeline battle einfach, was in Ordnung battle, denn genau darum ging es. Extrahieren Sie Daten aus der GitHub-API, führen Sie eine kleine Bereinigung durch und speichern Sie alles in einer CSV-Datei. Es funktionierte perfekt als das, was es battle: eine Lernübung. Aber mit einer CSV-Datei und einem einmaligen Skript funktioniert Knowledge Engineering in der realen Welt nicht. Ich wollte herausfinden, was „reale Welt“ in der Praxis tatsächlich bedeutet, additionally beschloss ich, die Pipeline weiter voranzutreiben und zu sehen, was passierte.
Hier ist die vollständige Unique-Pipeline für alle, die den vorherigen Artikel nicht gelesen haben:
import requests
from datetime import datetime, timedelta
url = "https://api.github.com/search/repositories"
params = {
"q": "language:python created:>2025-04-22",
"kind": "stars",
"order": "desc",
"per_page": 30
}
response = requests.get(url, params=params)
information = response.json()
import pandas as pd
repos = ()
for repo in information('gadgets'):
repos.append({
"identify": repo('identify'),
"proprietor": repo('proprietor')('login'),
"stars": repo('stargazers_count'),
"forks": repo('forks_count'),
"language": repo('language'),
"description": repo('description'),
"url": repo('html_url'),
"created_at": repo('created_at')
})
df = pd.DataFrame(repos)
df_clean = df.dropna(subset=('description'))
df_clean = df_clean.copy()
df_clean('viral') = df_clean('stars').apply(lambda x: 'Sure' if x > 50000 else 'No')
df_clean = df_clean.sort_values('stars', ascending=False).reset_index(drop=True)
df_clean.to_csv('github_trending_repos.csv', index=False)
print("Pipeline full. File saved.")Einfach, lesbar und es funktioniert. Aber sobald Sie versuchen, es mehr als einmal auszuführen oder am nächsten Tag darauf zurückzukommen, beginnen die Risse sichtbar zu werden.
Wand eins: Die Pipeline hatte kein Gedächtnis
Das erste Improve verlief unkompliziert. Anstatt sie in einer CSV-Datei zu speichern, habe ich die Daten in eine SQLite-Datenbank geladen. SQLite ist immer noch nur eine einzelne Datei, verhält sich aber wie eine echte Datenbank. Sie können es abfragen, überprüfen, was bereits darin enthalten ist, und ordnungsgemäß darauf aufbauen. Es fühlte sich wie eine kleine Veränderung an. Das battle es nicht.
Ich habe die Pipeline einmal ausgeführt und 22 Repos erhalten. Dann habe ich es ein zweites Mal ausgeführt, ohne etwas zu ändern, und die Datenbank überprüft.
Whole rows: 44 Distinctive repos: 22 Duplicates: 22Ehrlich gesagt habe ich es nicht erwartet. Ich vermutete, dass es passieren könnte, hätte aber nie wirklich gedacht, dass es passieren würde. Aber ich bin froh, dass es so battle, denn es battle das erste Mal, dass ich tatsächlich zusah, wie meine Pipeline kaputt ging. Und was dabei herauskam, battle einfach, aber wichtig: Das Drehbuch hatte kein Gedächtnis. Jedes Mal, wenn es ausgeführt wurde, startete es völlig neu und fügte blind alles hinzu, was es fand. Keine Warnung, kein Fehler. Einfach „Pipeline abgeschlossen“, als wäre alles in Ordnung.
Hier bin ich auf ein Konzept namens Idempotenz gestoßen.
Idempotenz ist ein schickes Wort für eine einfache Idee. Wenn etwas bereits passiert ist, sollte es nicht noch einmal passieren. Im Kontext einer Datenpipeline bedeutet dies, dass die einmalige oder zehnmalige Ausführung Ihrer Pipeline immer zum gleichen Ergebnis führen sollte. Keine zusätzlichen Zeilen, keine Duplikate, keine stille Beschädigung Ihrer Daten.
Die Lösung battle im Prinzip unkompliziert. Bevor etwas in die Datenbank eingefügt wird, prüft die Pipeline nun, ob dieser Datensatz bereits vorhanden ist. Wenn dies der Fall ist, wird es zuerst entfernt und dann die neue Model eingefügt. Eine kleine Änderung im Denken, aber sie verändert die Zuverlässigkeit Ihrer Pipeline völlig.
Und hier ist der Teil, der mir im Gedächtnis geblieben ist: Ein einfaches Drehbuch wird niemals alleine darüber nachdenken. Man muss es bewusst einbauen. Das ist kein Scripting mehr. Das ist Ingenieurskunst.
Wand zwei: Die Daten sind über Nacht verschwunden
Die zweite Wand battle weniger technisch und beunruhigender.
Als ich Colab für die Nacht schloss und am nächsten Tag zurückkam, hatte ich dieses ungute Gefühl. Ich musste alles noch einmal von Grund auf neu starten und hoffen, dass nichts kaputt ging, obwohl am Abend zuvor alles perfekt funktioniert hatte. Die Datenbank, die ich sorgfältig aufgebaut hatte, battle einfach weg. Und ich erinnerte mich, dass ich vor diesem Projekt tatsächlich Schwierigkeiten hatte, meine ursprüngliche ETL-Pipeline-Datei zu finden. Ich habe lange danach gesucht, bevor ich es endlich tat. Das Gefühl, die Arbeit quick zu verlieren, bleibt bestehen.
Ich wusste, dass es einen besseren Weg geben musste. Eine echte Pipeline kann nicht darauf angewiesen sein, dass jemand da ist, der sie jeden Morgen erneut laufen lässt. Die Daten müssen an einem Ort gespeichert sein, der über die Sitzung hinaus bestehen bleibt.
Die Lösung bestand darin, Google Drive direkt in Colab bereitzustellen und die Datenbankverbindung dorthin zu verweisen, anstatt auf die temporäre Colab-Umgebung. Eine Zeilenänderung:
conn = sqlite3.join('/content material/drive/MyDrive/github_repos.db')Jetzt befindet sich die Datenbank in Google Drive. Schließen Sie die Sitzung, starten Sie die Laufzeit neu und öffnen Sie ein neues Pocket book. Die Daten warten immer noch darauf.
Aber dieser Repair enthüllte etwas Größeres. Wenn die Speicherung von Daten bereits eine Überlegung darüber erfordert, wo Dinge leben und wie sie überleben, was passiert dann, wenn die Pipeline jeden Tag automatisch laufen soll, ohne dass Sie sie überhaupt berühren müssen?
Wand drei: Niemand kann „Für immer laufen“ drücken
Die dritte Wand battle diejenige, die mich am meisten begeisterte, was mich überraschte.
Auch wenn das Duplikatproblem gelöst ist und die Datenbank sicher in Google Drive gespeichert ist, muss noch jemand das Notizbuch öffnen und auf „Ausführen“ klicken. Colab ist kein Server. Es ist eine interaktive Umgebung. Es wacht nicht um 3 Uhr morgens auf, ruft keine neuen Daten von der GitHub-API ab und geht wieder in den Ruhezustand über. Dafür wurde es nicht gebaut.
Und als ich darüber aus der realen Perspektive nachdachte, hat es sofort Klick gemacht. In einem echten Unternehmen sitzt niemand um Mitternacht in Alarmbereitschaft und wartet darauf, ein Skript auszuführen. Die Pipeline muss selbst laufen. Nach einem Zeitplan. Zuverlässig. Ob jemand zuschaut oder nicht.
Hier kommen Instruments wie Apache Airflow, Prefect und cloudbasierte Cron-Jobs ins Spiel. Dabei handelt es sich nicht um Python-Skripte. Dabei handelt es sich um Systeme, die auf Servern laufen, Zeitpläne verwalten, Fehler behandeln, Warnungen senden, wenn etwas schief geht, und einen Verlauf aller Ausführungen führen.
Ehrlich gesagt ist die Terminplanung das Konzept, mit dem ich mich als nächstes am meisten befassen möchte, denn hier beginnt sich Knowledge Engineering wie echte Infrastrukturarbeit anzufühlen.
Durch die wichtigsten Veränderungen gehen
Lassen Sie mich durch die drei tatsächlichen Änderungen gehen, die ich an der Pipeline vorgenommen habe, und was jede einzelne davon bewirkt.
1. CSV gegen SQLite austauschen
# Earlier than
df_clean.to_csv('github_trending_repos.csv', index=False)
# After
conn = sqlite3.join('github_repos.db')
df_clean.to_sql('repos', conn, if_exists='append', index=False)
conn.shut()Für eine einmalige Analyse reicht das Speichern in einer CSV-Datei aus. Aber eine CSV ist nur eine Textdatei. Es lässt sich nicht einfach abfragen und es lässt sich nicht intestine skalieren, wenn Ihre Daten wachsen. SQLite ist eine echte Datenbank, was bedeutet, dass Sie SQL-Abfragen darauf ausführen, überprüfen können, was bereits darin enthalten ist, und ordnungsgemäß darauf aufbauen können. Gleiche Einfachheit, viel mehr Möglichkeiten.
2. Behebung des Duplikatproblems
cursor.execute('''
DELETE FROM repos WHERE url IN (SELECT url FROM repos_temp)
''')
cursor.execute('''
INSERT INTO repos SELECT * FROM repos_temp
''')Dies ist der Idempotenz-Repair. Bevor etwas eingefügt wird, prüft die Pipeline, ob dieses Repo bereits in der Datenbank vorhanden ist, indem es seine URL als eindeutige Kennung verwendet. Wenn dies der Fall ist, wird es zuerst gelöscht und dann die neue Model eingefügt. Unabhängig davon, wie oft die Pipeline ausgeführt wird, erhalten Sie am Ende immer saubere, nicht duplizierte Daten.
3. Persistierende Daten auf Google Drive
# Earlier than
conn = sqlite3.join('github_repos.db')
# After
conn = sqlite3.join('/content material/drive/MyDrive/github_repos.db')Das ist eine Zeile, aber sie verändert alles. Anstatt die Datenbank in der temporären Colab-Umgebung zu speichern, wo sie beim Schließen der Sitzung verschwindet, wird sie direkt in Google Drive gespeichert. Schließen Sie das Pocket book, starten Sie die Laufzeit neu und kommen Sie morgen wieder. Ihre Daten warten immer noch auf Sie.
Hier ist die vollständige aktualisierte Pipeline, die alle drei Änderungen zusammenfasst:
import requests
import pandas as pd
import sqlite3
from datetime import datetime, timedelta
# Extract
yesterday = (datetime.now() - timedelta(days=1)).strftime('%Y-%m-%d')
url = "https://api.github.com/search/repositories"
params = {
"q": f"language:python created:>{yesterday}",
"kind": "stars",
"order": "desc",
"per_page": 30
}
response = requests.get(url, params=params)
information = response.json()
# Rework
repos = ()
for repo in information('gadgets'):
repos.append({
"identify": repo('identify'),
"proprietor": repo('proprietor')('login'),
"stars": repo('stargazers_count'),
"forks": repo('forks_count'),
"language": repo('language'),
"description": repo('description'),
"url": repo('html_url'),
"created_at": repo('created_at')
})
df = pd.DataFrame(repos)
df_clean = df.dropna(subset=('description'))
df_clean = df_clean.copy()
df_clean('viral') = df_clean('stars').apply(lambda x: 'Sure' if x > 50000 else 'No')
df_clean = df_clean.sort_values('stars', ascending=False).reset_index(drop=True)
# Load
conn = sqlite3.join('/content material/drive/MyDrive/github_repos.db')
cursor = conn.cursor()
cursor.execute('''
CREATE TABLE IF NOT EXISTS repos (
identify TEXT, proprietor TEXT, stars INTEGER, forks INTEGER,
language TEXT, description TEXT, url TEXT,
created_at TEXT, viral TEXT, loaded_at TEXT
)
''')
df_clean('loaded_at') = datetime.now().strftime('%Y-%m-%d')
df_clean.to_sql('repos_temp', conn, if_exists='exchange', index=False)
cursor.execute('''
DELETE FROM repos WHERE url IN (SELECT url FROM repos_temp)
''')
cursor.execute('''
INSERT INTO repos SELECT * FROM repos_temp
''')
conn.commit()
conn.shut()
print("Pipeline full. Duplicates dealt with.")Was ist Knowledge Engineering eigentlich?
Wenn Sie mich gefragt hätten, was Knowledge Engineering ist, nachdem ich meine erste ETL-Pipeline erstellt habe, hätte ich gesagt, dass es hauptsächlich um das Schreiben von Skripten geht. Extrahieren, transformieren, laden. Wiederholen. So sah es von außen aus.
Aber nachdem ich diese Pipeline weiter vorangetrieben und beobachtet habe, wie sie auf drei verschiedene Arten zusammenbricht, denke ich jetzt anders darüber. Beim Knowledge Engineering geht es um den Aufbau zuverlässiger Systeme und nicht nur um die Ausführung von Skripten. Es gibt einen Unterschied. Ein Skript macht das, was Sie ihm sagen, einmal, wenn Sie es sagen. Ein System bewältigt Fehler, merkt sich, was es bereits getan hat, behält Daten über eine einzelne Sitzung hinaus bei und läuft nach einem Zeitplan, ohne dass jemand zuschaut.
Idempotenz, Beharrlichkeit, Terminplanung. Keines dieser Konzepte tauchte auf, als ich meine Pipeline einmal in einem Pocket book ausgeführt habe. Sie zeigten sich erst, als ich versuchte, es wie etwas Reales funktionieren zu lassen.
Und in einem echten Unternehmen können Sie es sich nicht leisten, so etwas falsch zu machen. Die von Ihrer Pipeline erzeugten Daten werden zur Entscheidungsfindung verwendet. Wenn es voller Duplikate ist, über Nacht verschwindet oder nur ausgeführt wird, wenn jemand daran denkt, eine Style zu drücken, handelt es sich nicht um eine Datenpipeline. Das ist eine Belastung.
Ich muss noch viel lernen. Die Terminplanung ist die nächste Wand, auf die ich zugehe. Aber ich gehe jetzt darauf zu und weiß, dass es beim Knowledge Engineering nie nur um das Schreiben von Skripten ging. Ich musste nur ein paar Dinge kaputt machen, um das zu sehen.
Dies ist eine fortlaufende Knowledge-Engineering-Reihe. Begleiten Sie mich, während ich jeden Schritt der Reise dokumentiere, einschließlich der Teile, die nicht reibungslos verlaufen.