Sie sind ein professioneller \u00dcbersetzer ins Deutsche. Barry Devlin und Paul Murphy, zwei IBM-Europe-Ingenieure, versuchten 1986 ein Problem zu l\u00f6sen, das die gro\u00dfen Konzerne jener Zeit besch\u00e4ftigte: Betriebsdaten waren vorhanden, aber daraus Management-Analytik zu gewinnen war praktisch unm\u00f6glich. Transaktionssysteme speicherten den aktuellen Gesch\u00e4ftszustand, konnten aber keine Fragen nach dem \u201eWarum\u201c oder \u201eWas als N\u00e4chstes kommt\u201c beantworten. Devlin und Murphy entwickelten eine interne Architektur f\u00fcr IBM EMEA und ver\u00f6ffentlichten 1988 einen Artikel, der erstmals das Konzept des \u201eBusiness Data Warehouse\u201c beschrieb.<\/p>\r\n
Der Begriff, der zuvor nicht existierte, wurde innerhalb weniger Jahre zum Industriestandard.<\/p>\r\n
Fast vierzig Jahre sp\u00e4ter ist das Problem immer noch nicht verschwunden \u2013 es hat lediglich seinen Ma\u00dfstab ge\u00e4ndert. Anstelle isolierter Mainframes haben Unternehmen heute CRMs, ERPs, Marketingplattformen, Produktionssysteme und Dutzende von Excel-Dateien, die \u201evor\u00fcbergehend\u201c zum Hauptwerkzeug der Analytik geworden sind. Daten sind \u00fcberall vorhanden, aber die Antwort auf eine einfache analytische Frage erfordert manchmal drei Tage Arbeit in der Finanzabteilung.<\/p>\r\n
Im Folgenden analysieren wir, wie ein modernes Data Warehouse in der Ukraine aufgebaut ist: Wann wird es f\u00fcr ein Unternehmen zur Notwendigkeit und wie sieht dieser Weg in der Praxis aus?<\/p>\r\n
Was ist ein Data Warehouse und wie unterscheidet es sich von einer Datenbank?<\/strong><\/p>\r\n Jedes Unternehmen hat irgendwo seine Daten, aber die Hauptfrage ist, wozu diese Daten \u00fcberhaupt ben\u00f6tigt werden. CRMs oder ERPs sind auf eine sehr einfache Aufgabe ausgelegt: schnell etwas zu erfassen und es genauso schnell wiederzufinden. Zum Beispiel \u00f6ffnet ein Manager einen Kunden und erh\u00e4lt in Sekundenschnelle Informationen. Ein Gesch\u00e4ft wird abgeschlossen und das System zeichnet es auf.<\/p>\r\n Und das scheint perfekt zu sein \u2026 bis zu dem Moment, in dem eine Frage einer anderen Ebene auftaucht:<\/p>\r\n \u201eWas passiert mit der Marge nach Kategorien in den letzten zwei Jahren, wenn man sie nach Regionen und Vertriebskan\u00e4len aufschl\u00fcsselt?\u201c<\/p>\r\n Eine operative Datenbank ist auf eine solche Frage nicht ausgelegt. Sie entweder denkt zu lange nach, blockiert die Arbeit anderer Benutzer oder liefert Daten, die dennoch manuell zusammengef\u00fchrt werden m\u00fcssen.<\/p>\r\n Ein Data Warehouse ist eine separate analytische Umgebung innerhalb der Datenarchitektur, in die Daten aus verschiedenen Systemen gelangen, bereinigt und in eine einheitliche Struktur f\u00fcr die weitere Analyse \u00fcberf\u00fchrt werden.<\/p>\r\n DWH vs. OLTP vs. Data Lake<\/strong><\/p>\r\n Drei Konzepte, die h\u00e4ufig verwechselt werden:<\/p>\r\n\r\n Kurz gesagt: OLTP beantwortet die Frage \u201eWas passiert gerade?\u201c, DWH beantwortet \u201eWarum passiert es und was kommt als N\u00e4chstes?\u201c, und im Data Lake werden gro\u00dfe Mengen an Rohdaten in verschiedenen Formaten f\u00fcr die sp\u00e4tere Verarbeitung gespeichert. Data Lake und analytisches Data Warehouse konkurrieren nicht miteinander: In ausgereiften Architekturen koexistieren sie \u2013 der Lake als Schicht f\u00fcr Rohdaten, das DWH als strukturierte Analytik dar\u00fcber.<\/p>\r\n Wann ben\u00f6tigt ein Unternehmen ein Data Warehouse?<\/strong><\/p>\r\n Es gibt keine universelle Umsatzschwelle oder eine bestimmte Anzahl von Systemen, nach der ein DWH erforderlich ist. Aber es gibt konkrete Symptome:<\/p>"},{"acf_fc_layout":"list_block","list_title":"","list_type":"ul","list_items":[{"item_text":"Die Erstellung des Finanzberichts dauert mehr als zwei Tage und erfordert die manuelle Zusammenf\u00fchrung von Daten aus mehreren Systemen."},{"item_text":"Die verschiedenen Abteilungen kommen mit unterschiedlichen Zahlen zu einem bestimmten Indikator zur Besprechung."},{"item_text":"Einen Gro\u00dfteil seiner Zeit (oft mehr als die H\u00e4lfte) verbringt der Analyst mit der Datenerhebung."},{"item_text":"Jede ungew\u00f6hnliche Anfrage der Gesch\u00e4ftsleitung wird zu einem eigenst\u00e4ndigen Projekt, das mehrere Tage in Anspruch nimmt."},{"item_text":"Das Unternehmen w\u00e4chst, und die Komplexit\u00e4t der Daten nimmt schneller zu als die Infrastruktur."}]},{"acf_fc_layout":"text_block","text_content":" Ebenen: Staging \u2192 Core \u2192 Data Mart<\/strong><\/p>\r\n Ein modernes analytisches Data Warehouse wird schichtweise aufgebaut, wobei jede Schicht eine klare Rolle und klare Verantwortungsgrenzen hat.<\/p>\r\n Staging (Bronze-Ebene)<\/strong> \u2013 die erste Ebene, auf der die Daten so landen, wie sie aus den Quellsystemen kommen: ohne Transformationen, ohne Bereinigung, ohne Gesch\u00e4ftslogik. Dies ist die Absicherung: Falls in den n\u00e4chsten Phasen etwas schiefgeht, besteht die M\u00f6glichkeit, zum Original zur\u00fcckzukehren und den Prozess neu zu starten.<\/p>\r\n Core (Silber-Ebene)<\/strong> \u2013 hier findet die eigentliche Hauptarbeit statt. Die Daten werden von Duplikaten und technischen Artefakten bereinigt, auf einheitliche Formate gebracht, mit Stammdaten angereichert und untereinander verkn\u00fcpft. Der Kunde aus dem CRM und der Kunde aus dem ERP werden zu einem einzigen Datensatz mit einer eindeutigen Kennung. Die Produktposition aus verschiedenen Systemen erh\u00e4lt eine vereinheitlichte Bezeichnung. Dies ist die eigentliche Single Source of Truth.<\/p>\r\n Data Mart (Gold-Ebene)<\/strong> \u2013 fachbereichsspezifische Datenm\u00e4rkte, die auf konkrete analytische Aufgaben optimiert sind: Finanz-Data-Mart f\u00fcr den CFO, Marketing-Data-Mart f\u00fcr den CMO, operativer Data-Mart f\u00fcr die Produktion. Abfragen werden hier schnell ausgef\u00fchrt, da die Daten bereits f\u00fcr bestimmte Fragestellungen aggregiert sind.<\/p>\r\n Die dreistufige Architektur bietet zwei Dinge gleichzeitig: Stabilit\u00e4t<\/strong> \u2013 Ver\u00e4nderungen in den Quellsystemen zerst\u00f6ren nicht die Analytik, und Flexibilit\u00e4t<\/strong> \u2013 neue Data Marts k\u00f6nnen hinzugef\u00fcgt werden, ohne das Fundament umbauen zu m\u00fcssen.<\/p>"},{"acf_fc_layout":"text_block","text_content":" ETL (Extract \u2192 Transform \u2192 Load):<\/strong> Der klassische Ansatz, bei dem Daten zuerst aus den Quellen extrahiert, auf einem separaten Server transformiert und erst dann in das Data Warehouse geladen werden. Dieser Ansatz funktionierte gut in der \u00c4ra teurer Cloud-Ressourcen und geringer Datenmengen.<\/p>\r\n ELT (Extract \u2192 Load \u2192 Transform):<\/strong> Der moderne Ansatz, bei dem Daten zuerst im Rohzustand in das Data Warehouse geladen werden und die Transformationen dann innerhalb des Data Warehouse stattfinden. Dies wurde durch Cloud-Plattformen mit ausreichender Rechenleistung f\u00fcr Transformationen direkt auf Warehouse-Ebene erm\u00f6glicht.<\/p>\r\n\r\n F\u00fcr die meisten neuen Projekte wird heute ELT gew\u00e4hlt. Cloud-Plattformen machen es oft einfacher zu implementieren und zu skalieren, aber die Kosten h\u00e4ngen von der Effizienz der Abfragen und dem Verarbeitungsvolumen ab. Klassische ETL-Prozesse bleiben dort relevant, wo eine Legacy-Infrastruktur besteht oder strenge Anforderungen gelten, welche Daten die Unternehmensnetzgrenzen verlassen d\u00fcrfen.<\/p>\r\n Top Cloud-DWH-Plattformen<\/strong><\/p>\r\n Die Wahl der Plattform ist eine der Schl\u00fcsselentscheidungen, die sp\u00e4ter nur schwer r\u00fcckg\u00e4ngig zu machen ist. Auf dem Markt f\u00fcr Cloud-DWH hat sich ein klarer Kreis von Marktf\u00fchrern gebildet: BigQuery und Snowflake werden in der Ukraine am h\u00e4ufigsten als grundlegende Optionen betrachtet, neben Redshift und Azure Synapse.<\/p>\r\n Google BigQuery<\/strong><\/p>\r\n BigQuery ist eine serverlose Plattform von Google, bei der kein Cluster-Management oder eine Kapazit\u00e4tsplanung erforderlich ist: Ressourcen werden automatisch f\u00fcr jede einzelne Abfrage zugewiesen. Sie basiert auf der eigenen Dremel-Engine, die parallele Spaltenabfragen \u00fcber Tausende von Knoten gleichzeitig ausf\u00fchrt.<\/p>\r\n Vorteile: minimaler operativer Overhead, native Integration in das Google-\u00d6kosystem (Looker Studio, Vertex AI, Google Analytics), Zahlungsmodell nach tats\u00e4chlich verarbeiteten Daten. Praktisch f\u00fcr ungleichm\u00e4\u00dfige Lasten.<\/p>\r\n Einschr\u00e4nkungen: Das On-Demand-Modell kann bei nicht optimierten Abfragen zu unvorhersehbaren Kosten f\u00fchren. Erfordert Disziplin beim Schreiben von SQL. Bindung an Google Cloud.<\/p>\r\n Geeignet f\u00fcr: Unternehmen mit ungleichm\u00e4\u00dfiger Last, Projekte in Google Cloud, Teams ohne dedizierten Infrastrukturadministrator.<\/p>\r\n Snowflake<\/strong><\/p>\r\n Snowflake basiert auf der Idee der vollst\u00e4ndigen Trennung von Speicher und Rechenleistung, die unabh\u00e4ngig voneinander skaliert werden k\u00f6nnen. Die Plattform wird auf AWS, Azure oder Google Cloud betrieben und ist somit eine multi-cloudf\u00e4hige L\u00f6sung ohne Bindung an einen bestimmten Anbieter.<\/p>\r\n Vorteile: Multi-Cloud-F\u00e4higkeit, bequemer Datenaustausch zwischen Organisationen \u00fcber den Snowflake Marketplace, verwaltetes Kostenmodell durch Virtual Warehouses mit flexibler Skalierung.<\/p>\r\n Einschr\u00e4nkungen: H\u00f6here Grundkosten im Vergleich zu BigQuery bei geringen Volumina. Erfordert eine Planung der Gr\u00f6\u00dfe der Virtual Warehouses entsprechend der Last.<\/p>\r\n Geeignet f\u00fcr: gro\u00dfe Konzerne, Multi-Cloud-Umgebungen, Unternehmen mit Bedarf an Datenaustausch zwischen Gesch\u00e4ftsbereichen.<\/p>\r\n Amazon Redshift<\/strong><\/p>\r\n Redshift ist die L\u00f6sung von AWS, tief integriert in das Amazon-\u00d6kosystem: S3, Glue, SageMaker, QuickSight. Es existiert in zwei Varianten: klassisch provisioned und neuer serverless mit automatischer Skalierung.<\/p>\r\n Vorteile: Ausgereifte Werkzeuge f\u00fcr ETL-Prozesse \u00fcber AWS Glue, breite Community, zahlreiche Integrationen innerhalb des AWS-\u00d6kosystems.<\/p>\r\n Einschr\u00e4nkungen: Die klassische Variante erfordert eine Cluster-Planung und manuelles Management bei Last\u00e4nderungen. Serverless adressiert einen Teil dieser Einschr\u00e4nkungen.<\/p>\r\n Geeignet f\u00fcr: Unternehmen, deren Infrastruktur bereits auf AWS l\u00e4uft, Projekte mit stabiler und vorhersehbarer Last.<\/p>\r\n Microsoft Azure Synapse Analytics<\/strong><\/p>\r\n Azure Synapse vereint auf einer Plattform DWH, Datenintegration und Big-Data-Analytik. F\u00fcr Unternehmen in einer Microsoft-Umgebung bedeutet dies eine native Zusammenarbeit mit Power BI, Azure Active Directory und Microsoft Fabric ohne zus\u00e4tzliche Integrationsschichten.<\/p>\r\n Vorteile: Einheitliche Umgebung f\u00fcr SQL-Abfragen und Spark-Berechnungen, tiefe Integration mit Power BI, vertraute Oberfl\u00e4che f\u00fcr Teams im Azure-\u00d6kosystem.<\/p>\r\n Einschr\u00e4nkungen: Der gr\u00f6\u00dfere Funktionsumfang bedeutet gleichzeitig eine h\u00f6here Konfigurationskomplexit\u00e4t. F\u00fcr kleinere Projekte kann es eine \u00fcberdimensionierte L\u00f6sung sein.<\/p>\r\n Geeignet f\u00fcr: Unternehmen in einer Microsoft-Konzernumgebung, Projekte bei denen Power BI das Hauptvisualisierungswerkzeug ist.<\/p>\r\n\r\n British American Tobacco \u2013 ein multinationales Unternehmen mit Pr\u00e4senz in \u00fcber 180 L\u00e4ndern und mehr als 50.000 Mitarbeitern. Der Ma\u00dfstab des Gesch\u00e4fts bedeutet einen Ma\u00dfstab der Daten: Dutzende Quellen, Tausende von Kennzahlen, mehrere analytische Teams mit unterschiedlichen Anforderungen.<\/p>\r\n Aufgabenstellung<\/strong><\/p>\r\n In der ersten Phase f\u00fchrte das Team ein Audit der bestehenden Power-BI-Berichte durch und identifizierte Probleme bei Berechnungen und der Nutzung der Plattformtools. Vor der Zusammenarbeit mit IWIS funktionierte die analytische Berichterstattung von BAT instabil: Berichte waren zeitweise nicht verf\u00fcgbar, Kennzahlen wurden mit Verz\u00f6gerungen neu berechnet, und die Systemgeschwindigkeit f\u00fchrte zu Beschwerden. Die Diagnose ergab ein systemisches Problem: Die Daten wurden ohne Zwischenspeicherung transportiert und transformiert. Tats\u00e4chlich startete jede Abfrage an Power BI einen vollst\u00e4ndigen Zyklus der Extraktion und Transformation von Daten aus den Quellen in Echtzeit. Jeder Fehler in einem beliebigen Schritt f\u00fchrte dazu, dass der Bericht einfach nicht ge\u00f6ffnet werden konnte.<\/p>\r\n Ein separates Problem war das Fehlen einer Orchestrierungsschicht f\u00fcr ETL-Prozesse: Niemand kontrollierte weder die Verbindung zu den Quellen, noch die tats\u00e4chliche Ausf\u00fchrung der Ladeprozesse, noch die Ausgabedatenqualit\u00e4t. Das System funktionierte wie eine Black Box.<\/p>\r\n Architekturl\u00f6sung<\/strong><\/p>\r\n Das IWIS-Team entwickelte mehrere Architekturvarianten, die jeweils den Aufbau eines Business-Data-Warehouse vorsahen, jedoch mit unterschiedlichen Tools. Der Kunde w\u00e4hlte die optimale Plattform unter Ber\u00fccksichtigung der Unternehmensinfrastruktur.<\/p>\r\n Die Umsetzung umfasste zwei Ebenen:<\/p>\r\n Bronze-Layer (Rohdaten)<\/strong> \u2013 F\u00fcr jede Quelle wurden Extraktionsmechanismen mit automatischer Speicherung der Rohdaten eingerichtet. Die Daten werden nicht mehr live transformiert, sondern zun\u00e4chst unver\u00e4ndert abgelegt.<\/p>\r\n Silver-Layer (bereinigte Daten)<\/strong> \u2013 Ein separater Transformationsprozess bereinigt und strukturiert die Daten aus der Bronze-Ebene. Power BI greift nicht mehr direkt auf die Quellen zu, sondern arbeitet mit der bereits aufbereiteten Ebene.<\/p>\r\n Zus\u00e4tzlich wurde ein infologisches Datenmodell erstellt: eine Beschreibung aller wichtigen Entit\u00e4ten, ihrer Beziehungen und der Datenfl\u00fcsse zwischen den Systemen. Dies vereinfachte die sp\u00e4tere Wartung und wurde zur Grundlage f\u00fcr die Skalierung.<\/p>\r\n Die wichtigste Komponente der Architektur ist der Orchestrierungsmechanismus. Das System kontrolliert die Ausf\u00fchrung jeder ETL-Aufgabe nach Zeitplan, vergleicht die Dateninkremente zwischen der Bronze-Ebene und der Quelle auf parallele Weise (unabh\u00e4ngig vom Extraktionsprozess selbst) und sendet bei Abweichungen oder Fehlern automatisch Benachrichtigungen per E-Mail und Telegram.<\/p>\r\n Ergebnisse<\/strong><\/p>\r\n Das Team von IWIS und BAT durchlief den Weg von instabiler Berichterstattung zu einer vollwertigen zweistufigen Data-Warehouse-Architektur innerhalb von 12 Monaten. Konkrete Ergebnisse:<\/p>"},{"acf_fc_layout":"list_block","list_title":"","list_type":"ul","list_items":[{"item_text":"Power BI ist nicht mehr direkt von den Quellsystemen abh\u00e4ngig."},{"item_text":"Dank des inkrementellen Ansatzes sind Datenaktualisierungen nun besser vorhersehbar."},{"item_text":"Jeder Fehler im ETL-Prozess wird nun automatisch protokolliert."},{"item_text":"Das infologische Modell bot dem BAT-Team eine dokumentierte Grundlage f\u00fcr die eigenst\u00e4ndige Weiterentwicklung des Systems."}]},{"acf_fc_layout":"text_block","text_content":"Die Gold-Ebene (Data Mart) wurde zum Zeitpunkt des Projektabschlusses nicht implementiert, da die bestehenden Anforderungen durch die Silver-Ebene abgedeckt waren. Die Architektur ist jedoch so konzipiert, dass die Hinzuf\u00fcgung der Gold-Ebene keine Umgestaltung der vorherigen Schichten erfordert."},{"acf_fc_layout":"text_block","text_content":" Wenn es um die Entwicklung eines Data Warehouses geht, ist die Frage nach den Kosten eine der ersten. Und die Antwort ist immer dieselbe: Es kommt darauf an. Aber es gibt Orientierungspunkte, die helfen, ein realistisches Budget zu erstellen.<\/p>\r\n Die Entwicklungskosten setzen sich aus mehreren Komponenten zusammen:<\/p>\r\n\r\n Analyse und Architektur-Design:<\/strong> Die Discovery-Phase, in der das Team die Datenquellen, deren Qualit\u00e4t, Struktur und Beziehungen untersucht, das infologische Modell erstellt und die technische L\u00f6sung ausarbeitet. Diese Phase zu \u00fcberspringen und sofort mit dem Coden zu beginnen, ist der h\u00e4ufigste Fehler, der bei Nacharbeiten teuer zu stehen kommt.<\/p>\r\n<\/li>\r\n \t Entwicklung und Konfiguration:<\/strong> Aufbau der Warehouse-Ebenen, Einrichtung der ETL\/ELT-Prozesse, Orchestrierung, Datenqualit\u00e4tskontrolle. Der gr\u00f6\u00dfte Teil des Budgets.<\/p>\r\n<\/li>\r\n \t Plattformlizenzen:<\/strong> Abh\u00e4ngig von der gew\u00e4hlten L\u00f6sung. Cloud-Plattformen (BigQuery, Snowflake, Redshift, Azure Synapse) arbeiten nach dem Pay-as-you-go-Modell, daher sind die Anfangskosten gering, steigen aber mit dem Datenvolumen und der Anzahl der Abfragen.<\/p>\r\n<\/li>\r\n \t Wartung und Weiterentwicklung:<\/strong> Nach dem Start ben\u00f6tigt das System Monitoring, Updates und das Hinzuf\u00fcgen neuer Quellen oder Data Marts.<\/p>\r\n<\/li>\r\n<\/ul>\r\n Die Sch\u00e4tzungen basieren auf der Praxis des ukrainischen Marktes und globalen Benchmarks, da die meisten DWH-Projekte mit internationalen Cloud-Plattformen realisiert werden. Hier sind ungef\u00e4hre Budgetorientierungen:<\/p>\r\n\r\n Diese Zahlen sind ein Ausgangspunkt. Die tats\u00e4chlichen Kosten werden nach der Discovery-Phase bestimmt, wenn die Qualit\u00e4t und Struktur der Quelldaten bekannt sind. Genau das kann das Budget entweder verringern oder um ein Vielfaches erh\u00f6hen. Hier treten die h\u00e4ufigsten \u00dcberraschungen auf: Ein Legacy-ERP-System mit einer zehn Jahre alten Dokumentation oder Daten in Formaten, von denen niemand zuvor gesprochen hat.<\/p>\r\n H\u00e4ufige Fehler beim Aufbau eines Data Warehouse<\/strong><\/p>\r\n Die meisten Probleme in DWH-Projekten sind organisatorischer oder architektonischer Natur. Hier sind die h\u00e4ufigsten:<\/p>\r\n\r\n Ausgelassene Discovery-Phase:<\/strong> Das Team beginnt mit der Entwicklung, ohne die Datenquellen, deren Qualit\u00e4t und die Gesch\u00e4ftslogik vollst\u00e4ndig zu verstehen. Die Folge sind Nacharbeiten in sp\u00e4teren Phasen, die ein Vielfaches der urspr\u00fcnglichen Analyse kosten.<\/p>\r\n<\/li>\r\n \t Fehlender Datenverantwortlicher (Data Owner):<\/strong> Ein DWH ist eine Infrastruktur, die st\u00e4ndige Aufmerksamkeit erfordert. Wenn das Unternehmen keine Person hat, die f\u00fcr die Qualit\u00e4t und Aktualit\u00e4t der Daten verantwortlich ist, degradiert das System allm\u00e4hlich.<\/p>\r\n<\/li>\r\n \t Der Versuch, alles auf einmal zu bauen:<\/strong> Der Wunsch, ein \u201eperfektes Warehouse\u201c auf Anhieb zu schaffen, f\u00fchrt zu langen Projekten ohne Zwischenergebnisse. Der richtige Ansatz ist iterativ: Eine Basisarchitektur starten, einen Mehrwert schaffen, dann weiterentwickeln.<\/p>\r\n<\/li>\r\n \t Ignorieren der Qualit\u00e4t der Eingangsdaten:<\/strong> \u201eGarbage in, garbage out\u201c ist eine w\u00f6rtliche Beschreibung dessen, was passiert, wenn die Quelldaten nicht validiert werden. Analytik mit schmutzigen Daten ist sch\u00e4dlich, weil sie ein falsches Vertrauen in die Zahlen erzeugt.<\/p>\r\n<\/li>\r\n \t Plattformwahl vor dem Verst\u00e4ndnis der Anforderungen:<\/strong> Die Plattform sollte sich nach der Architektur und den Anforderungen richten, nicht umgekehrt.<\/p>\r\n<\/li>\r\n<\/ul>\r\n\r\n\r\n
\r\n \r\nMerkmal<\/th>\r\n OLTP<\/th>\r\n Data Warehouse<\/th>\r\n Data Lake<\/th>\r\n<\/tr>\r\n<\/thead>\r\n \r\n Zweck<\/td>\r\n Operative Transaktionen<\/td>\r\n Analytische Abfragen<\/td>\r\n Speicherung von Rohdaten in beliebigen Formaten<\/td>\r\n<\/tr>\r\n \r\n Datenstruktur<\/td>\r\n Normalisiert<\/td>\r\n Denormalisiert, f\u00fcr Lesezugriffe optimiert<\/td>\r\n Beliebig (strukturiert, halbstrukturiert, unstrukturiert)<\/td>\r\n<\/tr>\r\n \r\n Typische Benutzer<\/td>\r\n Manager, Sachbearbeiter<\/td>\r\n Analysten, F\u00fchrungskr\u00e4fte<\/td>\r\n Data Scientists, Data Engineers<\/td>\r\n<\/tr>\r\n \r\n Datenhorizont<\/td>\r\n Aktueller Zustand<\/td>\r\n Jahre an Historie<\/td>\r\n Unbegrenzt<\/td>\r\n<\/tr>\r\n \r\n Systembeispiele<\/td>\r\n SAP, Salesforce<\/td>\r\n BigQuery, Snowflake, Redshift<\/td>\r\n AWS S3, Azure Data Lake<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\r\n Architektur des modernen Data Warehouse<\/strong><\/h2>\r\n
ETL vs. ELT-Ans\u00e4tze<\/strong><\/h2>\r\n
\r\n\r\n
\r\n \r\nMerkmal<\/th>\r\n ETL<\/th>\r\n ELT<\/th>\r\n<\/tr>\r\n<\/thead>\r\n \r\n Ort der Transformation<\/td>\r\n Externer Server<\/td>\r\n Innerhalb des DWH<\/td>\r\n<\/tr>\r\n \r\n Geeignet f\u00fcr<\/td>\r\n Legacy-Systeme, strenge Datensicherheitsanforderungen<\/td>\r\n Cloud-Plattformen, gro\u00dfe Datenmengen<\/td>\r\n<\/tr>\r\n \r\n Entwicklungsgeschwindigkeit<\/td>\r\n Langsamer<\/td>\r\n Schneller<\/td>\r\n<\/tr>\r\n \r\n Kosten<\/td>\r\n Separater ETL-Server<\/td>\r\n Abh\u00e4ngig vom Rechenvolumen in der Cloud<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\r\n Case Study IWIS: Data Warehouse f\u00fcr BAT<\/strong><\/h2>\r\n
Was kostet die Entwicklung eines DWH in der Ukraine?<\/strong><\/h2>\r\n
\r\n \t
\r\n\r\n
\r\n \r\nSzenario<\/th>\r\n Umfang<\/th>\r\n Budgetrahmen<\/th>\r\n<\/tr>\r\n<\/thead>\r\n \r\n Basis-Start<\/td>\r\n 2\u20135 Quellen, Basisdatenmodell, ELT, einfache Berichterstattung<\/td>\r\n 15.000\u201330.000 $<\/td>\r\n<\/tr>\r\n \r\n Mittel<\/td>\r\n 5\u201315 Quellen, Datenbereinigung, mehrere Data Marts, stabile ETL-Prozesse<\/td>\r\n 30.000\u201380.000 $<\/td>\r\n<\/tr>\r\n \r\n Gro\u00df<\/td>\r\n 15+ Quellen, komplexe Logik, Data Governance, Integrationen, Skalierung<\/td>\r\n 80.000\u2013200.000 $+<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\r\n \r\n \t
Wo anfangen: Eine Checkliste zur Gesch\u00e4ftsbereitschaft<\/strong><\/h2>"},{"acf_fc_layout":"list_block","list_title":"Bevor man mit der Entwicklung eines Data Warehouse beginnt, sollte man sich ehrlich einige Fragen beantworten:","list_type":"ul","list_items":[{"item_text":"Ist klar, welche gesch\u00e4ftlichen Anforderungen das Repository erf\u00fcllen muss?"},{"item_text":"Gibt es eine Bestandsaufnahme der Datenquellen: eine Liste der Systeme, Formate und Verantwortlichen?"},{"item_text":"Gibt es jemanden aus der Wirtschaft, der bereit ist, an Discovery teilzunehmen und die Logik der Kennzahlen zu validieren?"},{"item_text":"Gibt es einen \u00dcberblick \u00fcber die Qualit\u00e4t der aktuellen Daten? Ist bekannt, wo es Duplikate, L\u00fccken oder Unstimmigkeiten gibt?"},{"item_text":"Ist das Budget nicht nur f\u00fcr die Entwicklung, sondern auch f\u00fcr den weiteren Support vorgesehen?"},{"item_text":"Gibt es ein technisches Team oder einen Auftragnehmer, der nach der Inbetriebnahme f\u00fcr das System verantwortlich sein wird?"}]},{"acf_fc_layout":"text_block","text_content":"Wenn die Antwort auf die meisten Fragen \u201eNein\u201c lautet, sollte man mit einer Datenpr\u00fcfung und der Festlegung der Anforderungen beginnen. Genau das ist der erste Schritt in einem gut durchdachten DWH-Projekt."},{"acf_fc_layout":"text_block","text_content":"
Kostenlose Beratung zur Datenarchitektur<\/h2>\r\nIWIS ist auf den Aufbau von Analyseinfrastrukturen f\u00fcr Unternehmen spezialisiert: von der Pr\u00fcfung der Datenquellen bis hin zu einem vollwertigen Analysedatenlager mit ETL-Prozessen und BI-Berichten. Zu unseren Kunden z\u00e4hlen zahlreiche Unternehmen unterschiedlicher Gr\u00f6\u00dfe, die den Weg von verstreuten Daten zu einer einzigen Quelle der Wahrheit zur\u00fcckgelegt haben.\r\n\r\nWenn Sie sich in diesem Artikel wiedererkennen, wenden Sie sich an uns f\u00fcr eine kostenlose Beratung zur Datenarchitektur. Wir analysieren Ihre Infrastruktur und schlagen konkrete n\u00e4chste Schritte vor."}]},"yoast_head":"\n