Ich komme aus der SQL-Datawarehouse-Welt, wo ich aus einem flachen Feed Dimensions- und Faktentabellen erzeuge. In allgemeinen Data Warehouse-Projekten teilen wir Feeds in Fakten und Dimensionen ein. Ex:
Ich bin völlig neu in Hadoop und ich habe erfahren, dass ich Data Warehouse im Stock erstellen kann. Jetzt bin ich vertraut mit der Verwendung von GUID, die meiner Meinung nach als Primärschlüssel im Bienenstock anwendbar ist. Die folgende Strategie ist also die richtige Methode zum Laden von Fakten und Dimensionen in einer Struktur?
Generiere Dimension von sales_data_warehouse; zB:
SELECT New_Guid (), Customer_Name, Customer_Address von Sales_Data_Warehouse
Wenn alle Dimensionen fertig sind, laden Sie die Faktentabelle wie
SELECT New_Guid () AS 'Fact_Key', Customer.Customer_Key, Store.Store_Key ... FROM Sales_Data_Warehouse AS 'Quelle' JOIN Customer_Dimension Customer auf source.Customer_Name = Customer.Customer_Name UND source.Customer_Address = Customer.Customer_Address JOIN Store_Dimension AS 'Speichern' EIN Store.Store_Name = Name des Quell-Stores JOIN Product_Dimension AS 'Produkt' EIN .....
Ist das die Art und Weise, wie ich meine Fakt- und Dimensionstabelle im Bienenstock laden soll?
Außerdem müssen wir in allgemeinen Warehouse-Projekten Dimensionsattribute aktualisieren (z. B. Customer_Address wird auf etwas anderes geändert) oder müssen den Fremdschlüssel der Faktentabelle aktualisieren (selten, aber es passiert). Also, wie kann ich eine INSERT-UPDATE laden in Hive haben. (Wie wir in SSIS oder MERGE-Anweisung in TSQL suchen)?
Wir haben immer noch die Vorteile dimensionaler Modelle auf Hadoop und Hive. Einige Features von Hadoop erfordern jedoch, dass wir den Standardansatz für die Dimensionsmodellierung übernehmen.
Das Hadoop-Dateisystem ist unveränderlich. Wir können Daten nur hinzufügen, aber nicht aktualisieren. Als Ergebnis können wir Datensätze nur an Dimensionstabellen anhängen (Während Hive eine Update-Funktion und Transaktionen hinzugefügt hat, scheint dies ziemlich fehlerhaft zu sein). Langsam ändernde Dimensionen in Hadoop werden zum Standardverhalten. Um den neuesten und aktuellsten Datensatz in einer Dimensionstabelle zu erhalten, haben wir drei Möglichkeiten. Zunächst können wir eine View erstellen, die den neuesten Datensatz mithilfe von Fensterfunktionen abruft. Zweitens können wir im Hintergrund einen Kompaktierungsdienst ausführen, der den letzten Status neu erstellt. Drittens können wir unsere Dimensionstabellen in veränderbarem Speicher speichern, z. HBase und föderieren Abfragen über die beiden Arten von Speicher.
Die Art und Weise, wie Daten über HDFS verteilt werden, macht die Datenverbindung teuer. In einer verteilten relationalen Datenbank (MPP) können wir Datensätze mit denselben Primär- und Fremdschlüsseln auf demselben Knoten in einem Cluster gemeinsam lokalisieren. Dies macht es relativ billig, sehr große Tabellen zu verbinden. Zum Durchführen der Verknüpfung müssen keine Daten über das Netzwerk übertragen werden. Dies ist bei Hadoop und HDFS sehr unterschiedlich. In HDFS werden Tabellen in große Blöcke aufgeteilt und über die Knoten in unserem Cluster verteilt. Wir haben keine Kontrolle darüber, wie sich einzelne Datensätze und ihre Schlüssel im Cluster verteilen. Daher sind Joins auf Hadoop für zwei sehr große Tabellen ziemlich teuer, da Daten über das Netzwerk übertragen werden müssen. Wir sollten Verbindungen vermeiden, wo es möglich ist. Für eine große Fakt- und Dimensionstabelle können wir die Dimensionstabelle direkt in die Faktentabelle entnormalisieren. Für zwei sehr große Transaktionstabellen können wir die Datensätze der untergeordneten Tabelle in der übergeordneten Tabelle verschachteln und die Daten zur Laufzeit abflachen. Wir können SQL-Erweiterungen wie array_agg in BigQuery / Postgres usw. verwenden, um mehrere Körner in einer Faktentabelle zu verarbeiten
Ich würde auch die Nützlichkeit von Ersatzschlüsseln in Frage stellen. Warum nicht den natürlichen Schlüssel benutzen? Vielleicht ist die Leistung für komplexe zusammengesetzte Schlüssel ein Problem, aber Ersatzschlüssel sind nicht wirklich nützlich und ich benutze sie nie.
Tags und Links hadoop hive data-warehouse dimensional-modeling fact