Video: HDInsight: Fast Interactive Queries with Hive on LLAP | Azure Friday 2025
genannt) eine Vielzahl von Studien zeigen, dass die meisten Daten in einem Enterprise Data Warehouse selten abgefragt werden. Datenbankanbieter haben auf solche Beobachtungen geantwortet, indem sie ihre eigenen Methoden implementierten, um zu sortieren, welche Daten wo platziert werden.
Eine Methode ordnet das Datenuniversum in Bezeichnungen von warm, warm oder kalt, wobei heiß Daten (manchmal aktiv Daten genannt wird häufig verwendet, warm Daten werden von Zeit zu Zeit verwendet und kalt Daten wird selten verwendet. Die vorgeschlagene Lösung für viele Anbieter ist die kalten Daten auf langsameren Festplatten in den Data Warehouse-Gehäusen zu speichern oder clevere Caching-Strategien zu erstellen, um die heißen Daten im Speicher zu halten, unter anderem.
Das Problem bei diesem Ansatz ist, dass, obwohl langsamer Speicher verwendet wird, es immer noch teuer ist, kalte, selten benutzte Daten in einem Lagerhaus zu speichern. Lizenzierung von Hardware und Software. Gleichzeitig werden kalte und ruhende Daten oft auf Band archiviert.
Dieses traditionelle Archivierungsmodell bricht zusammen, wenn Sie alle kalte Daten kosteneffizient und relativ effizient abfragen wollen - ohne alte Bänder anzufordern.
Wenn Sie sich die Kosten und die Betriebseigenschaften von Hadoop ansehen, scheint es tatsächlich das neue Backup-Band zu werden. Hadoop ist vor allem deshalb preiswert, weil Hadoop-Systeme so konzipiert sind, dass sie einen geringeren Hardware-Grad verwenden als normalerweise in Data-Warehouse-Systemen. Eine weitere signifikante Kosteneinsparung ist die Softwarelizenzierung.
Kommerzielle Hadoop-Distributionslizenzen erfordern einen Bruchteil der Kosten von relationalen Data-Warehouse-Softwarelizenzen, die dafür berüchtigt sind, teuer zu sein. Aus betrieblicher Sicht ist Hadoop so konzipiert, dass es einfach skaliert werden kann, indem einem vorhandenen Cluster zusätzliche Slave-Knoten hinzugefügt werden. Und da Slave-Knoten hinzugefügt werden und Datensätze immer umfangreicher werden, ermöglichen die Datenverarbeitungs-Frameworks von Hadoop Ihren Anwendungen, die erhöhte Arbeitslast nahtlos zu bewältigen.
Hadoop stellt eine einfache, flexible und kostengünstige Möglichkeit dar, die Verarbeitung über buchstäblich Tausende von Servern zu beschleunigen.
Mit seiner skalierbaren und kostengünstigen Architektur scheint Hadoop die perfekte Wahl für die Archivierung von Warehouse-Daten zu sein … abgesehen von einer kleinen Sache: Der größte Teil der IT-Welt läuft auf SQL, und SQL allein ist nicht gut mit Hadoop kompatibel…
Sicherlich ist die Hadoop-freundliche NoSQL-Bewegung am Leben und gut, aber die meisten Power-User verwenden jetzt SQL mit üblichen, standardmäßigen Toolsets, die SQL-Abfragen unter der Haube erzeugen - Produkte wie Tableau, Microsoft Excel und IBM Cognos BI.
Es stimmt, dass das Hadoop-Ökosystem Hive enthält, aber Hive unterstützt nur eine Untermenge von SQL, und obwohl sich die Leistung verbessert (zusammen mit der SQL-Unterstützung), ist es bei der Beantwortung kleinerer Anfragen nicht annähernd so schnell wie bei relationalen Systemen. In letzter Zeit gab es große Fortschritte beim SQL-Zugriff auf Hadoop, wodurch Hadoop zum neuen Ziel für Online-Data-Warehouse-Archive wurde.
Je nach Hadoop-Anbieter werden SQL- (oder SQL-ähnliche) APIs verfügbar, sodass die gängigen Reporting- und Analysetools SQL-Standards für die Ausführung von Daten ausgeben können. Hadoop. Zum Beispiel hat IBM seine Big SQL API, Cloudera Impala und Hive selbst, über die Hortonworks Stinger Initiative, wird zunehmend SQL-konform.
Obwohl es verschiedene Sichtweisen gibt (einige zielen darauf ab, Hive zu erweitern, einige, Hive zu erweitern und andere, eine Alternative zu bieten), versuchen all diese Lösungen, zwei Probleme anzugehen: MapReduce ist eine schlechte Lösung für die Ausführung kleinerer Abfragen. Der SQL-Zugriff ist vorerst der Schlüssel dafür, dass IT-Mitarbeiter ihre vorhandenen SQL-Kenntnisse nutzen können, um die in Hadoop gespeicherten Daten zu optimieren.
