Die Datenanalyse ist oft so organisiert: Hier haben wir die Entwickler des Repositorys und hier haben wir die Analysten. In DWH (Data Warehouse, Speicher) können sie SQL ausführen, und unsere Analysten können mit Excel arbeiten. Wenn wir etwas analysieren müssen, gehen Sie zu den Analysten, und sie holen Daten an DWH, um Daten zu erhalten. Es scheint logisch zu sein. Und viele nehmen wahr, dass dies eine normale Arbeitsteilung ist. In diesem Artikel möchte ich die Idee vermitteln, dass diese Arbeitsteilung fehlerhaft ist und die Effizienz und Produktivität des gesamten Prozesses der Datenanalyse drastisch verringert.
Ein typischer Arbeitszyklus für ein analytisches Problem sieht folgendermaßen aus:
- Ein Unternehmen hat ein Problem und bittet um eine Antwort.
- Analysten diskutieren mit dem Unternehmen, was zu tun ist.
- Analysten haben erkannt, dass sie Geschäfte von ihnen wollen und verstehen, was sie ungefähr in den Daten benötigen.
- Analysten schreiben eine Abfrage in DWH, um die Daten abzurufen.
- DWH nimmt eine Anfrage entgegen, liest, fragt, klärt, ruft Daten ab, gibt.
- Analysten verstehen, dass sie nicht alles genommen oder missverstanden haben. Sie schreiben die Anfrage erneut in DWH, um die Daten abzurufen.
- DWH nimmt eine Anfrage entgegen, liest, fragt, klärt, ruft Daten ab, gibt.
- Analysten verstehen, dass sie nicht alles genommen oder missverstanden haben. Sie schreiben die Anfrage erneut in DWH, um die Daten abzurufen.
- Wiederholen Sie die Schritte 7 und 8
Einmal sagen die Mitarbeiter von DWH, dass sie keine Daten angeben können oder nicht bereit sind, so viele Anfragen von Analysten zu bearbeiten. Als Reaktion darauf sammeln Analysten ihre Daten außerhalb von DWH in einer Art Excel. Dort beginnen sie, ihre ETL-Prozesse so zu sammeln, wie sie können, basierend auf dem, was sie „kampflos“ von DWH erhalten können.
Was haben wir als Ergebnis:
- DWH deckt die Bedürfnisse der Verbraucher nicht angemessen ab (nun, seitens DWH scheinen die Benutzer nicht zu wissen, was sie wollen).
- Analysten beginnen, schlechte ETL-Prozesse zu schreiben und Pseudo-DWHs entsprechend ihrem Datenvolumen zu erstellen, jedoch ohne Reserve, Zugriffskontrolle, geringe Leistung usw.
- Das Zusammenspiel von DWH und Analysten leidet darunter Man kümmert sich nicht ums Geschäft, und der zweite versteht comme il faut "Vogelsprache" nicht.
- Der Prozess des Erhaltens einer Antwort auf eine Geschäftsfrage wird verzögert, da der Datenverarbeitungsprozess jetzt eine Menge manueller Arbeit außerhalb von DWH ist. Und warum haben wir DWH erstellt, bis auf ein einziges Repository?
- Kleinere Änderungen in der Erklärung des Problems aus dem Geschäft starten den Datenanalysezyklus von fast Null, weil DWH wird wieder keine Flexibilität zeigen und Analysten werden keine Daten in einem neuen Kontext haben.
Was könnte die Lösung sein? Wenn Sie das Problem der Interaktion zwischen DWH und Analysten beseitigen möchten, müssen Sie die Kompetenzen von DWH und Analysten näher bringen. Eine Person, die diese Kompetenzen kombiniert, kann als Datenanalyst bezeichnet werden.
Was sollte ein solcher Full Stack Data Analyst können?
- Arbeiten Sie mit Rohdatenquellen und verstehen Sie, wie die Datenspeicherung funktioniert.
- Um zu formulieren, was im Repository in Bezug auf Dateninhalt geändert werden muss, welche Daten hinzugefügt werden müssen und wie sie methodisch verarbeitet werden müssen, damit Hardcore-DWH-Entwickler sie implementieren können.
- Verstehen Sie die Anforderungen des Unternehmens, besprechen Sie die Anforderungen und helfen Sie Ihrem Kunden, intern oder extern, ein Problem und eine Lösung dafür zu formulieren.
- In der Lage sein, eine analytische Lösung zu entwerfen, d.h. Verstehen, wie das Problem gelöst werden kann, welche Daten benötigt werden, was „erfunden“ werden muss, welche Annahmen getroffen werden müssen
- Sie können Ihre Ergebnisse visualisieren und Ihren Kunden (intern oder extern) Bericht erstatten.
- Um eine „reproduzierbare“ Studie durchführen zu können, ist dies eine Analyse, die immer mit denselben Daten wiederholt werden kann und dasselbe Ergebnis liefert. Dazu müssen Sie in der Lage sein, mit R / Python oder Systemen zu arbeiten, mit denen Sie den Analyseprozess formalisieren können.
Wenn Sie technische und analytische Kompetenzen in einer Analyse kombinieren, erhalten Sie einen wirklich integralen Mitarbeiter, der das End-to-End-Problem lösen kann. Und das ist sehr wichtig für analytische Aufgaben, wie Nur dieser Analytiker hat ein Verständnis dafür, was er tut und warum. Die Aufteilung in diejenigen, die „analysieren“ und diejenigen, die „die Daten verarbeiten“, führt dazu, dass jeder dieser Mitarbeiter behindert ist: Der Analyst ist ohne Hände, weil kann nichts auf einer Skala bekommen und verarbeiten, und der Dateningenieur ist sozusagen „ohne Verstand“. Er glaubt nicht, wie es verwendet wird und welche Hypothesen es gibt.
Die Arbeitsteilung ist sehr wichtig, muss aber auf einer etwas anderen Ebene stattfinden. Der Analyst sollte in der Lage sein, alles zu erhalten, was er für die Analyse benötigt, und die Aufgabe des Data Engineer besteht darin, Systeme zu erstellen, die effektiv Daten in allen für den Analysten interessanten Abschnitten bereitstellen. Für Data Engineer bedeutet dies, dass die Daten in einer recht flexiblen Form gespeichert werden sollten, gleichzeitig jedoch in einer für die Verwendung geeigneten Form: teilweise denormalisiert, teilweise mit Zugriff über Cubes, teilweise voraggregiert und berechnet.
Wenn Sie den Full Stack Analyst nicht selbst finden können, nehmen Sie zumindest Data Engeneer in das Analyseteam auf, damit die Kompetenz im Umgang mit Daten nicht von der Analyse auf einen externen Service übertragen wird.
Es ist nicht die Aufgabe des Datenanalysten, das Abrufen von Daten aus der Google AdWords-API zu unterstützen, aber es ist nicht die Aufgabe von Data Engeneer, eine Auswahl zu schreiben, um Daten zum Umsatz des letzten Monats abzurufen.