Leistung
Power Query und Datenaufbereitung
Power Query ist die ehrlichste ETL-Schicht, die in jeder Office-Lizenz steckt. Ich baue Pipelines, die Query Folding nicht brechen, Parameter sauber durch das Modell durchreichen und mit aussagekräftigen Fehlern abbrechen, statt stillschweigend Datenmüll zu produzieren.
Das Problem
Was ich häufig vorfinde: 30 Schritte pro Abfrage, davon 14 mit dem Namen 'Changed Type1' bis 'Changed Type14'. Jeder Schritt bricht das Query Folding und holt die komplette Tabelle in den lokalen Speicher. Das Refresh dauert 18 Minuten, obwohl die Datenquelle eine SQL-Datenbank ist, die in 200 Millisekunden antworten könnte.
Datenquellen sind hartcodiert auf C:\Users\Maria\Desktop\Export.csv. Wenn Maria krank ist, läuft nichts. Plausibilitäts-Checks fehlen komplett: wenn der Export einen Tag alte Daten hat oder die Spalte 'Umsatz' plötzlich Text statt Zahl ist, fällt das niemand vor dem Versand auf.
Mit Power Query lassen sich diese Probleme schichten und beheben. Aber nur, wenn man weiß, was M tatsächlich tut und wo es Query Folding noch oder nicht mehr unterstützt.
Die Lösung
Ich baue Power-Query-Pipelines mit dem Anspruch, dass jede Quelle so weit wie möglich serverseitig verarbeitet wird: Filter, Joins, Aggregationen werden so platziert, dass Query Folding bis zur Quelle durchläuft. Bei großen SQL-Quellen reduziert das die Refresh-Zeit oft um Faktor 10-30.
Pfade und Filter werden in eine Parameter-Tabelle ausgelagert, nicht in den M-Code hartcodiert. Custom-Funktionen für wiederkehrende Cleansing-Schritte (Datums-Parsing, Trim+Clean, Spalten-Normalisierung) leben in einer Bibliotheks-Abfrage. Schema-Validierung erfolgt mit Try/Otherwise und klaren Fehler-Auslösern.
Lieferumfang: dokumentierte M-Code-Abfragen mit klaren Schritt-Namen, eine Parameter-Tabelle, eine Validierungs-Schicht, optional Versionierung der Abfragen als .pq-Dateien für Git. Plus ein README mit Connector-Anforderungen, OAuth-Setup falls relevant, und Wartungs-Konventionen.
Typische Anwendungsfälle
- Konsolidierung von 5-20 CSV/XLSX aus einem Ordner mit Schema-Validierung und klaren Fehler-Logs bei abweichenden Strukturen
- Anbindung an SQL Server, PostgreSQL, MySQL, Oracle mit Query Folding bis zur Quelle, statt naive Volltabellen-Importe
- API-Anbindung an REST-Services (Salesforce, Microsoft Graph, Custom-APIs) mit Pagination, Throttling und OAuth-Handling
- Migration einer Copy-Paste-ETL-Strecke aus VBA in saubere Power-Query-Schritte mit deutlicher Performance-Verbesserung
- Konsolidierung mehrerer Mandanten-Daten mit Tochter-Spezifischer Eliminierungslogik und auditierbarem Transformations-Log
- Aufbau einer Power-Query-Funktionsbibliothek (Datums-Helpers, Spalten-Normalisierung, Fehler-Handler) für teamweite Wiederverwendung
Konkreter Nutzen
- Refresh-Zeit oft Faktor 5-30 schneller, weil Query Folding wieder funktioniert
- Reproduzierbarkeit: jede Transformation ist M-Code, versionierbar, code-reviewbar
- Robustheit: strukturelle Quellen-Änderungen brechen mit klarer Fehlermeldung, nicht stillschweigend
- Wartbarkeit: ein zweiter Analyst übernimmt eine durchgemeinte PQ-Pipeline in 1-2 Tagen
- Skalierbarkeit nach Power BI: dieselben Abfragen laufen in Power BI Desktop und Service ohne Umbau
So läuft die Zusammenarbeit
Audit der bestehenden Abfragen (1-2 Tage)
Welche Schritte brechen Query Folding? Wo sind ineffiziente Joins? Welche Quellen sind hartcodiert? Output ist ein priorisierter Refactor-Plan mit erwarteten Performance-Gewinnen.
Refactor in 1-Wochen-Inkrementen
Pipeline für Pipeline: Schritte umsortieren, Custom-Funktionen extrahieren, Parameter-Tabelle aufsetzen. Jeder Schritt wird gegen die alte Version verifiziert.
Validierungs-Schicht ergänzen
Schema-Checks, Bereichs-Validierungen, Konsistenz-Tests vor der Übergabe an Excel/PowerBI. Bei Fehlern bricht die Pipeline mit aussagekräftiger Meldung statt Müll zu produzieren.
Übergabe mit Doku und Walkthrough
README mit Connector-Anforderungen, Wartungs-Konventionen, Erweiterungs-Patterns. 60-90 min Live-Walkthrough mit Aufzeichnung.
Häufige Fragen
Power Query vs. SQL vs. Python: wann was?
Power Query wenn die Quelle Excel- oder Power-BI-kompatibel ist und die Datenmenge ins Modell passt (<10 Mio Zeilen üblicherweise). SQL wenn mehrere Reports auf dieselben transformierten Daten zugreifen oder Sie ein DWH haben. Python wenn Sie Bibliotheken brauchen (Statistik, NLP, ML) oder die Pipeline außerhalb von Microsoft-Stack laufen muss. Entscheidung im Audit.
Was passiert, wenn sich Spalten in der Quelle ändern?
Mit korrekt aufgesetzter Pipeline bricht der Refresh mit klarer Fehlermeldung: 'Spalte XY wurde nicht gefunden, erwartete Typ Number'. Statt stillschweigender Müll-Produktion. Schema-Validierung als erste Stufe der Pipeline ist Pflicht, nicht optional.
Wir haben Abfragen mit 18 Minuten Refresh-Zeit. Schaffen Sie schneller?
Fast immer. 18 Minuten sind in 95% der Fälle Query-Folding-Probleme oder ineffiziente Joins. Typische Verbesserung auf 30-90 Sekunden. Wenn die Datenmenge fundamental zu groß für Excel ist, schlage ich SQL-Stage oder Power BI vor.
Funktioniert das mit unserer Power-BI-Lizenz oder brauchen wir mehr?
Power Query ist in Excel 365 und Power BI Free enthalten. Sie brauchen Power BI Pro nur, wenn Sie Reports im Service teilen wollen. Für reine Excel-basierte Pipelines: keine Zusatzkosten.
Können wir die Pipelines selbst weiterentwickeln?
Ja. Klare Schritt-Namen, Custom-Funktionen mit Inline-Dokumentation, Parameter-Tabelle, README. Ein Mitarbeiter mit Power-Query-Grundkenntnissen erweitert in 1-2 Tagen. Bei tieferen M-Sprache-Fragen (komplexe List-Funktionen, dynamische Spalten) sinnvoll im Retainer.
Passende weitere Leistungen
Power-Query-Pipelines auditieren lassen?
Nennen Sie Quellen, Refresh-Zeit und kritische Pain Points. Sie bekommen innerhalb von zwei Werktagen eine Einschätzung: wo Query Folding bricht, was realistisch beschleunigbar ist, in welcher Reihenfolge ich vorgehen würde.