Interviewfragen für Datenarchitekten, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Antworte mit einem Entwurf, den du gemacht hast: das fachliche Problem, das Modell oder die Plattform, die du gewählt hast, die Alternative, die du verworfen hast, und warum, und was ein Jahr später daraus geworden ist. Interviewer vertrauen einem Architekten, der eine Entscheidung nennen kann, die schiefging, und was er daraufhin geändert hat.

Was ein Datenarchitekt können muss

• Modellierung: DatenmodellierungKonzeptionelle, logische und physische Modelle; dimensionale Modelle fürs Reporting; Namen und Schlüssel, die Jahre halten. von konzeptionell bis physisch, Normalformen, dimensionale Modelle und Data Vault, getestet mit SQLSQL so sicher lesen und schreiben, dass du ein Modell testest, eine Quelle profilierst und die Abfragen der Teams prüfst..
• Plattformen: das Data WarehouseSchichten von roh bis kuratiert, Historie mit Absicht und ein Entwurf, der die Fragen des Fachbereichs schnell beantwortet., Data Lakes und Lakehouses, Batch-Ladungen per ETLWie Daten von der Quelle ins Data Warehouse kommen, voll oder per Änderung geladen, und wie man eine fehlgeschlagene Ladung repariert. und Streams in KafkaEvent-Streams, Topics und ihre Verträge; wann ein Stream dem Fachbereich besser dient als eine nächtliche Ladung., auf AWSObjektspeicher, Identitäten, verwaltete Datenbanken und die Analysedienste, auf denen Teams bauen, und ihre Rechnungen. je nach Anbieter, AzureSpeicher, Identitäten und die Datendienste, auf denen Teams in einer Microsoft-Umgebung bauen, und was jeder kostet. je nach Anbieter oder Google CloudBigQuery, Speicher und Identitäten in Google Cloud und wie das Preismodell einen Entwurf prägt. je nach Anbieter.
• Governance: Verantwortliche, Definitionen und ZugriffeVerantwortliche und Data Stewards für jede Domäne, abgestimmte Definitionen, Zugriffsregeln und ein Katalog, den man wirklich nutzt., Datenqualität, Stammdaten, Metadaten und Lineage sowie die Integration zwischen Systemen.
• Recht und Geld: personenbezogene Daten nach der DSGVOPersonenbezogene Daten auf der Datenplattform (DSGVO): Zweck, Datensparsamkeit, Speicherdauer, Zugriff und nachweisbare Löschung. der EU und lokalen Gesetzen, Sicherheit und was jeder Entwurf im Betrieb kostet.

Modelle: konzeptionell, logisch, physisch und dimensional

Erklär uns konzeptionelle, logische und physische Datenmodelle: Wofür ist jedes da, und wer liest es?

Worauf sie achten: dass du von den Worten des Fachbereichs zu Tabellen kommst, ohne eines von beiden zu verlieren.

Kurze Antwort: „Ein konzeptionelles Modell benennt die wichtigsten Dinge, über die das Geschäft spricht, etwa Kunde, Vertrag und Produkt, und wie sie zusammenhängen; Führungskräfte können es lesen. Ein logisches Modell ergänzt Attribute, Schlüssel und Regeln, noch unabhängig von einer Datenbank; Analysten und Engineers einigen sich darauf. Ein physisches Modell zeigt, wie es in einer bestimmten Datenbank gebaut wird: Tabellen, Datentypen, Indizes und Partitionen.“

Die ausführliche Antwort: Im konzeptionellen Modell sollten die meisten Diskussionen stattfinden, denn ein Wort wie Kunde bedeutet in drei Abteilungen oft drei Dinge. Das logische Modell ist der Vertrag, gegen den die Teams bauen. Das physische Modell ändert sich mit der Plattform: Ein spaltenorientierter Speicher fürs Reporting ist anders aufgebaut als eine Datenbank hinter einer Bestellmaske. Halte die drei im Gleichschritt, sonst vertraut niemand mehr den Zeichnungen.

Schwache Antwort: „Ich gehe direkt zu den Tabellen, der Rest ist Papierkram.“ Nachfrage: „Vertrieb und Finanzen zählen Kunden verschieden.“ Erkläre, wie das konzeptionelle Modell die beiden Bedeutungen sichtbar macht und jeder einen Namen gibt.

Wann normalisierst du ein Modell, und wann denormalisierst du es mit Absicht?

Worauf sie achten: dass du weißt, warum es Normalformen gibt und wann man sie bricht.

Kurze Antwort: „Ich normalisiere dort, wo Daten geschrieben werden, damit jede Tatsache einmal gespeichert ist und sich nicht widersprechen kann: im Bestellsystem, bei Stammdaten. Ich denormalisiere dort, wo Daten in großen Mengen gelesen werden, etwa im Reporting, denn weniger Joins machen Abfragen einfacher und schneller, und die Kopien werden aus der normalisierten Quelle neu aufgebaut.“

Die ausführliche Antwort: Normalisieren, meist bis zur dritten Normalform, entfernt wiederholte Daten und die Fehler beim Ändern, die damit einhergehen. Modelle fürs Reporting tauschen das gegen Tempo und Lesbarkeit, was sicher ist, wenn die Daten geladen und nicht von Hand bearbeitet werden. Moderne spaltenorientierte Speicher machen breite Tabellen günstig, aber eine breite Tabelle, die niemand erklären kann, ist trotzdem ein Problem.

Schwache Antwort: „Immer normalisieren, so ist es richtig.“ Nachfrage: „Ein Bericht verknüpft zwölf Tabellen und bricht wegen Zeitüberschreitung ab.“ Sprich über eine Schicht fürs Reporting und was es kostet, sie im Gleichschritt zu halten.

Entwirf ein Sternschema für das Vertriebsreporting. Wie behältst du die Historie mit Slowly Changing Dimensions?

Worauf sie achten: dimensionale Modellierung und eine klare Granularität.

Kurze Antwort: „Ein Sternschema hat eine Faktentabelle mit einer festgelegten Granularität, hier eine Zeile pro Bestellposition, mit Kennzahlen wie Menge und Betrag, umgeben von Dimensionstabellen: Datum, Kunde, Produkt, Filiale. Zieht ein Kunde in eine andere Region, legt eine Slowly Changing Dimension eine neue Zeile mit Gültig-ab- und Gültig-bis-Datum an, damit alte Verkäufe bei der alten Region bleiben.“

Die ausführliche Antwort: Leg zuerst die Granularität fest, denn jeder spätere Streit kommt auf sie zurück. Entscheide pro Attribut, ob die Historie zählt: Die Korrektur eines Tippfehlers überschreibt, ein Wechsel der Region behält die Historie. Nutze Surrogatschlüssel, damit die Dimension mehrere Versionen halten kann. Konforme Dimensionen, etwa eine Datums- und eine Produkttabelle für alle Fakten, machen Berichte aus verschiedenen Bereichen vergleichbar.

Schwache Antwort: „Eine große Tabelle, in der alles steht.“ Nachfrage: „Die Finanzabteilung will die Umsätze nach der Region, in der der Kunde heute ist.“ Erkläre, wie du beide Sichten aus derselben Dimension anbietest.

Wann würdest du ein Data Vault einem Sternschema vorziehen?

Worauf sie achten: dass du die Muster als Werkzeuge für verschiedene Aufgaben kennst, nicht als Lager.

Kurze Antwort: „Ein Data Vault teilt Daten in Hubs für fachliche Schlüssel, Links für Beziehungen und Satelliten für sich ändernde Details, sodass neue Quellen und Änderungen ohne Umbau dazukommen und jede Änderung mit Quelle und Zeitpunkt erhalten bleibt. Ich nutze es für die Integrationsschicht, wenn es viele sich ändernde Quellen und Anforderungen aus Audits gibt. Die Nutzer lesen trotzdem Sternschemata, die darauf aufbauen.“

Die ausführliche Antwort: Das Vault ist gut darin, Daten zu laden und Historie zu bewahren, und schlecht darin, von Menschen gelesen zu werden, deshalb steht es selten allein. Es bringt auch viele Tabellen mit und braucht Automatisierung, um beherrschbar zu bleiben. Für eine Firma mit fünf stabilen Quellen reicht vielleicht ein gut gebautes Warehouse mit Sternschemata. Sag, welches Problem die zusätzliche Schicht löst, bevor du sie einführst.

Schwache Antwort: „Data Vault ist der moderne Weg, Sternschemata sind veraltet.“ Nachfrage: „Das Team hat zwei Engineers.“ Sprich darüber, ob sie ein Vault am Laufen halten können und was du stattdessen tun würdest.

Warehouses, Data Lakes, Streams und die Wahl der Plattform

Data Warehouse, Data Lake oder Lakehouse: Wie wählst du für eine Firma?

Worauf sie achten: eine Wahl, die von den Daten und den Nutzern ausgeht, mit ihren Kosten.

Kurze Antwort: „Ein Data Warehouse hält bereinigte, modellierte Daten fürs Reporting und ist für Analysten leicht zu nutzen. Ein Data Lake bewahrt Rohdateien jeder Art günstig auf, was zu Data Science und großen Mengen passt, wird ohne Regeln aber zum Sumpf. Ein Lakehouse setzt Tabellenformate und Governance auf den Data Lake, damit eine Kopie beidem dient. Ich wähle nach den Nutzern, den Arten von Daten, den Fähigkeiten des Teams und der Cloud, die schon da ist.“

Die ausführliche Antwort: Die meisten Firmen landen bei Schichten: Rohdaten so abgelegt, wie sie kamen, bereinigte Daten und Tabellen, die fürs Geschäft bereit sind, wie auch immer das Produkt sie nennt. Die Frage ist weniger, welches Wort, als wo jede Schicht liegt, wer sie lesen darf und wie sie bezahlt wird. Ein späterer Wechsel zwischen den Modellen ist teuer, also schreib auf, warum du gewählt hast.

Schwache Antwort: „Alles in den Data Lake und später sortieren.“ Nachfrage: „Die Analysten beschweren sich, dass sie nichts finden.“ Sprich über einen Katalog, Verantwortliche und kuratierte Tabellen.

Batch oder Streaming: Wie entscheidest du, wie frisch die Daten sein müssen?

Worauf sie achten: dass Aktualität eine fachliche Anforderung mit einem Preis ist, keine Mode.

Kurze Antwort: „Ich frage, welche Entscheidung die Daten nutzt und wie spät sie sein dürfen: Ein monatlicher Finanzbericht kann nachts laden, Betrugsprüfungen brauchen Sekunden. Batch ist einfacher und günstiger zu betreiben und zu reparieren; Streaming, mit Ereignissen in KafkaEvent-Streams, Topics und ihre Verträge; wann ein Stream dem Fachbereich besser dient als eine nächtliche Ladung. oder einem Cloud-Dienst, lohnt sich nur, wo die Verzögerung Geld oder Risiko kostet.“

Die ausführliche Antwort: Viele Fälle liegen dazwischen: Ladungen alle fünfzehn Minuten oder Change Data Capture aus der Quelldatenbank liefern fast Echtzeit ohne vollen Streaming-Entwurf. Streams brauchen Verträge für jedes Ereignis, einen Plan für späte und doppelte Ereignisse und Menschen in Rufbereitschaft. Vereinbare das Ziel für die Aktualität mit dem Verantwortlichen und schreib es neben den Datenbestand.

Schwache Antwort: „Echtzeit für alles, das mögen die Nutzer.“ Nachfrage: „Der Stream hat dieselbe Bestellung zweimal geliefert.“ Erkläre, wie der Entwurf mit Duplikaten umgeht.

Wie vergleichst du Datenplattformen wie Snowflake, Databricks, BigQuery und Microsoft Fabric nach Passung und Kosten, ohne eine zu bevorzugen?

Worauf sie achten: ein fairer, schriftlicher Vergleich mit den eigenen Bedürfnissen der Firma.

Kurze Antwort: „Ich schreibe zuerst die Bedürfnisse auf: Arten von Daten und Nutzern, die Cloud, auf der die Firma läuft, Sicherheit und Datenresidenz, Fähigkeiten und die erwartete Last. Dann teste ich jede Plattform an ein paar echten Fällen, messe Tempo und Kosten und vergleiche, wie jede abrechnet: nach Rechenzeit, nach gelesenen Daten oder nach Kapazität. Die Antwort ist die, die passt, mit den Risiken schriftlich festgehalten.“

Die ausführliche Antwort: Snowflake, Databricks, BigQuery auf Google Cloud und Microsoft Fabric auf Azure, dazu die Dienste von AWS als weitere Option, speichern alle große Datenmengen und führen SQL aus; sie unterscheiden sich darin, wie sie Speicher und Rechenleistung trennen, wie sie mit Data Science umgehen und wie ihre Rechnungen wachsen. Offene Tabellenformate machen einen späteren Ausstieg weniger schmerzhaft. Hol die Finanzabteilung früh dazu, denn auch ein Entwurf, der gut läuft, kann sie überraschen.

Schwache Antwort: „Ich nehme die, die ich kenne.“ Nachfrage: „Die Rechnung hat sich in drei Monaten verdoppelt.“ Erkläre, wie du die Abfragen und Jobs dahinter finden würdest.

Passt Data Mesh zu dieser Firma, und wie würdest du es einführen?

Worauf sie achten: dass du weißt, was Data Mesh von einer Organisation verlangt, nicht nur von der Technik.

Kurze Antwort: „Data Mesh gibt die Verantwortung für Daten an die fachlichen Domänen, die Datenprodukte mit einem Verantwortlichen, einer Beschreibung und Zusagen zur Qualität veröffentlichen, auf einer gemeinsamen Self-Service-Plattform und nach gemeinsam gesetzten Regeln. Es passt zu einer großen Firma, in der ein zentrales Team zum Engpass geworden ist. Eine kleine Firma mit einem Datenteam gewinnt meist wenig dadurch.“

Die ausführliche Antwort: Die schwierigen Teile sind Menschen und Geld: Domänen brauchen Datenkompetenz und Budget, und jemand muss die gemeinsamen Regeln pflegen. Fang mit einer oder zwei willigen Domänen an, leg fest, was ein Datenprodukt bieten muss, und miss, ob die Nutzer es finden und ihm vertrauen. Ohne Plattform und Governance wird ein Mesh zu vielen Silos.

Schwache Antwort: „Jedes Team baut seine eigenen Pipelines, das ist ein Mesh.“ Nachfrage: „Zwei Domänen veröffentlichen verschiedene Zahlen von Kunden.“ Erkläre, wo die gemeinsame Definition liegt.

Governance, Qualität, Stammdaten, Lineage und Datenschutz

Wie richtest du Data Governance ein, an die sich Menschen halten, mit Verantwortlichen und Data Stewards?

Worauf sie achten: Governance, die der Arbeit hilft, statt sie zu bremsen.

Kurze Antwort: „Ich benenne für jede Datendomäne einen Verantwortlichen im Fachbereich, der entscheidet, was die Daten bedeuten und wer sie nutzen darf, und Data Stewards, die sie im Alltag in Ordnung halten. Wir einigen uns in einem gemeinsamen Glossar auf die wichtigsten Definitionen, bauen die Zugriffsregeln in die Plattform ein und halten eine kurze Liste von Standards. Entscheidungen werden aufgeschrieben und sind leicht zu finden.“

Die ausführliche Antwort: Governance scheitert, wenn sie ein Gremium ist, das tagt und nichts entscheidet. Fang mit den Daten an, die am meisten wehtun, etwa Kunden oder Umsatz, zeig einen schnellen Erfolg und wachse von dort aus. Tools für Kataloge und Richtlinien helfen, aber erst, wenn es Verantwortliche gibt.

Schwache Antwort: „Der IT gehören alle Daten.“ Nachfrage: „Keine Abteilung will die Produktdaten verantworten.“ Erkläre, wie du einen Verantwortlichen finden würdest und was du ihm anbieten würdest.

Wie misst und verbesserst du die Datenqualität?

Worauf sie achten: Qualität als gemessene Regeln mit Verantwortlichen, behoben an der Quelle.

Kurze Antwort: „Ich vereinbare Qualitätsregeln mit den Verantwortlichen: Vollständigkeit, Gültigkeit, Eindeutigkeit, Aktualität und Konsistenz zwischen Systemen. Die Pipelines prüfen sie bei jeder Ladung und stoppen oder markieren schlechte Daten, und ein Dashboard zeigt den Trend. Fehler werden dort behoben, wo sie entstehen, im Quellsystem, und nicht für immer im Warehouse geflickt.“

Die ausführliche Antwort: Nicht jedes Feld ist gleich wichtig; fang mit denen an, die in Geld, Meldungen an Aufsichtsbehörden oder Kunden einfließen. Gib jeder Regel einen Schwellenwert und einen Verantwortlichen und entscheide, was bei einem Verstoß passiert. Berichte die Qualität dem Geschäft in seinen eigenen Worten, etwa Bestellungen ohne gültigen Kunden.

Schwache Antwort: „Wir bereinigen die Daten im Bericht.“ Nachfrage: „Das Team der Quelle sagt, es hat keine Zeit.“ Zeig die Kosten der Fehler und vereinbare einen Plan.

Wie gehst du mit Stammdaten um, etwa einem Kundendatensatz über viele Systeme hinweg?

Worauf sie achten: Abgleich, Golden Records und wer was ändern darf.

Kurze Antwort: „Stammdaten sind die gemeinsamen Kerndaten, etwa Kunden, Produkte und Lieferanten. Ich lege fest, welches System für jedes Attribut führend ist, wie Duplikate erkannt und zu einem Golden Record zusammengeführt werden und wie Änderungen zurück in die anderen Systeme fließen. Bei Konflikten entscheidet ein Verantwortlicher.“

Die ausführliche Antwort: Die Muster reichen von einem zentralen Hub, aus dem alle Systeme lesen, bis zu einem Register, das die Datensätze nur verknüpft. Die Wahl hängt davon ab, wie viele Systeme Kundendaten schreiben und wie sauber sie sind. Der Abgleich ist nie perfekt, also plane Warteschlangen für die Prüfung von Hand und einen Weg, eine falsche Zusammenführung rückgängig zu machen.

Schwache Antwort: „Wir erklären das CRM für alles zur Wahrheit.“ Nachfrage: „Die Abrechnung und das CRM haben verschiedene Adressen.“ Erkläre, wie jedes Attribut sein führendes System bekommt.

Wie pflegst du Metadaten und Data Lineage, damit Menschen einer Zahl vertrauen können?

Worauf sie achten: dass sich eine Zahl vom Bericht bis zur Quelle zurückverfolgen lässt.

Kurze Antwort: „Metadaten beschreiben die Daten: was eine Tabelle enthält, wem sie gehört, wie aktuell sie ist. Data Lineage zeigt, woher jede Zahl kommt und was auf dem Weg mit ihr gemacht wurde. Beides halte ich in einem Katalog, wo möglich automatisch aus den Pipelines gesammelt, damit ein Analyst die Quelle einer Umsatzzahl sehen kann und ein Engineer, was kaputtgeht, wenn sich eine Spalte ändert.“

Die ausführliche Antwort: Lineage zahlt sich in Audits aus, bei der Analyse von Störungen und vor jeder Änderung. Von Hand geschriebene Lineage veraltet innerhalb von Monaten, also nimm lieber Tools, die sie aus dem Code und der Plattform lesen. Zeig sie dort, wo Menschen arbeiten, neben dem Bericht oder der Tabelle.

Schwache Antwort: „Es steht alles im Code, falls jemand es braucht.“ Nachfrage: „Ein Prüfer fragt, wie diese Zahl im Jahresabschluss zustande kam.“ Geh durch, wie du es zeigen würdest.

Wie entwirfst du für Sicherheit und Datenschutz, auch für personenbezogene Daten nach der DSGVO der EU?

Worauf sie achten: Datenschutz und Zugriffe, die von Anfang an in den Entwurf eingebaut sind.

Kurze Antwort: „Ich klassifiziere die Daten, markiere personenbezogene und sensible Felder und vergebe Zugriffe nach Rollen, mit Maskierung für alle, die die echten Werte nicht brauchen. Personenbezogene Daten werden nur für einen festgelegten Zweck und eine festgelegte Zeit aufbewahrt, und der Entwurf muss die Daten einer Person in jeder Kopie finden und löschen können. Verschlüsselung und Zugriffsprotokolle sind der Standard.“

Die ausführliche Antwort: Nach der DSGVO der EU ist das Löschen der schwierige Teil, denn Daten werden in viele Schichten und Backups kopiert; entwirf früh dafür. Andere Orte haben eigene Gesetze, etwa den CCPA Kaliforniens in den USA oder Indiens DPDP Act, und Regeln zur Datenresidenz können begrenzen, welche Cloud-Region du nutzen darfst. Arbeite mit dem Datenschutzbeauftragten zusammen; der Architekt entwirft, die Juristen entscheiden, was das Gesetz verlangt.

Schwache Antwort: „Sicherheit ist Sache des Security-Teams.“ Nachfrage: „Ein Kunde verlangt alle Daten, die ihr über ihn habt.“ Erkläre, wie die Plattform sie findet.

Migration, Stakeholder und die Senior-Stufen

Plane die Migration eines alten On-Premises-Warehouse in die Cloud.

Worauf sie achten: ein Plan in Etappen, mit wenig Risiko und einem ehrlichen Blick darauf, was sich ändern soll.

Kurze Antwort: „Zuerst erfasse ich, was es gibt: Quellen, Ladungen, Berichte, Nutzer und die versteckten Regeln im alten Code. Dann entscheiden wir, was so umzieht, wie es ist, was neu gebaut und was abgeschaltet wird. Wir ziehen nach Themenbereichen um, lassen Alt und Neu nebeneinander laufen, vergleichen die Zahlen und stellen die Nutzer erst um, wenn sie übereinstimmen.“

Die ausführliche Antwort: Der Vergleich der Zahlen ist der Teil, den die meisten Pläne unterschätzen; plane Zeit dafür ein. Alte Warehouses tragen Geschäftsregeln, die niemand aufgeschrieben hat, also hol die Menschen dazu, die die Berichte nutzen. Leg ein Datum fest, an dem das alte System abgeschaltet wird, sonst zahlt die Firma für zwei. Die Integration mit Systemen, die vor Ort bleiben, braucht einen eigenen Plan für Netz und Sicherheit.

Schwache Antwort: „Wir kopieren alle Tabellen an einem Wochenende hinüber.“ Nachfrage: „Die neue Umsatzzahl weicht ein wenig ab.“ Erkläre, wie du den Unterschied zurückverfolgen würdest.

Zwei Abteilungen wollen verschiedene Definitionen von Umsatz. Wie klärst du das als Senior Data Architect mit den Stakeholdern?

Worauf sie achten: dass du Menschen zu einer Entscheidung führen kannst, ohne dass dir die fachliche Frage gehört.

Kurze Antwort: „Ich mache beide Definitionen sichtbar, mit ihrer Wirkung auf echte Zahlen, und bringe die Verantwortlichen zusammen. Oft gelten beide für verschiedene Fragen, dann bekommen sie zwei Namen. Braucht es eine Definition, entscheidet der Verantwortliche der Daten oder die Finanzabteilung, und die Entscheidung wird ins Glossar geschrieben und ins Modell gebaut.“

Die ausführliche Antwort: Auf der Stufe von Principal Data Architect und Head of Data Architecture weiten sich die Fragen auf Standards für viele Teams, eine Roadmap, das Budget der Plattform und die Frage, wer im Architekturgremium sitzt. Rechne mit einem Fall wie drei Warehouses nach zwei Übernahmen und erkläre, wie du sie zusammenführen würdest, während das Geschäft weiterläuft.

Schwache Antwort: „Ich wähle die richtige und sage es ihnen.“ Nachfrage: „Die beiden Leitungen sind sich weiter uneinig.“ Erkläre, wer entscheidet und wie du eskalierst.

Dein Lebenslauf für diese Fragen

Jeder Entwurf in deinem Lebenslauf lädt zu den Fragen oben ein: welches Modell, welche Plattform, warum, für wie viele Teams und was er verändert hat. Gib jedem Entwurf eine Zeile unter dem Job, in dem du ihn gemacht hast, und der Interviewer wird dich bitten, davon zu erzählen:

Bewerte deinen Lebenslauf vor dem Interview an einem Job als Datenarchitekt, den du willst; die Skills, die dabei als fehlend markiert werden, zeigen auf die Entwürfe, über die du sprechen können solltest.