DE202011110890U1

DE202011110890U1 - System für die Bereitstellung eines Datenspeicherungs- und Datenverarbeitungsservices

Info

Publication number: DE202011110890U1
Application number: DE202011110890.6U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2010-05-18
Filing date: 2011-05-17
Publication date: 2017-02-15
Anticipated expiration: 2021-05-18
Also published as: US20120016901A1; EP2572289B1; EP2572289A4; EP2572289A1; WO2011146452A1

Abstract

System, worin das System Folgendes umfasst:
ein Repository der Objektspeicherung in einem Serversystem, so konfiguriert, dass es Daten, die von einem entfernten Computergerät übertragen werden, als Objekt speichert;
ein Tabellenmanagementsystem, das so konfiguriert ist, dass es in Reaktion auf eine Anforderung von einem entfernten Computergerät für die Erstellung einer Tabelle eine Tabelle erstellt;
einen Importjobmanager im Serversystem, der so konfiguriert ist, dass er in Reaktion auf eine Anforderung von einem entfernten Computergerät für den Import der in dem Objekt befindlichen Daten in die Tabelle die in dem Objekt befindlichen Daten in die Tabelle importiert, worin der Import der in dem Objekt befindlichen Daten das Folgende beinhaltet: (i) die Konversion der in dem Objekt befindlichen Daten in spaltenorientierte Streifen, (ii) die Speicherung der spaltenorientierten Streifen in Assoziation mit der Tabelle; und
ein spaltenorientiertes Datenverarbeitungssystem im Serversystem, das solcherart konfiguriert ist, dass es in Reaktion auf eine Anforderung, von einem entfernten Computergerät, für die Durchführung einer Abfrage die Abfrage für die Tabelle vornimmt, während die Durchführung der Abfrage eine Abfrage von einem oder mehreren spaltenorientierten Streifen beinhaltet.

Description

TECHNISCHES GEBIET
Dieses Dokument beschreibt generell Techniken, Verfahren, Systeme und Mechanismen für die Bereitstellung eines Datenspeicherungs- und Datenverarbeitungsservice.
Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
HINTERGRUND
Die vorliegende Offenbarung betrifft im Allgemeinen analytische Datenverarbeitung großer Datenvolumen. Solch eine Datenverarbeitung wird mittlerweile weit verbreitet in Webunternehmen und in vielen verschiedenen Wirtschaftssektoren, nicht zuletzt aufgrund der kostengünstigen Speichermöglichkeit angewendet, mit der das Erfassen großer Mengen von geschäftskritischen Daten machbar ist. Die unmittelbare Bereitstellung dieser Daten für Analysten und technische Entwickler ist von zunehmender Bedeutung; interaktive Antwortzeiten geben häufig den Ausschlag über Qualität bei der Datenuntersuchung, Datenüberwachung, dem Online-Kunden-Support, einem schnellen Prototyping, der Fehlerbehebung von Daten-Pipelines und bei anderen Aufgaben. Das Durchführen einer interaktiven Datenanalyse in großem Umfang erfordert ein hohes Maß an Parallelität. Das Lesen eines Terabyte komprimierter Daten innerhalb von einer Sekunde kann unter Einsatz der heute verfügbaren Disketten zehntausende von Disketten erforderlich machen. Auf ähnliche Weise müssen CPU-intensive Abfragen möglicherweise auf Tausenden von Kernen ausgeführt werden, um die Verarbeitung innerhalb von Sekunden abzuschließen.
ZUSAMMENFASSUNG
Ein Datenspeicherungs- und Datenverarbeitungsservice wird hierin offengelegt. Der beschriebene Service liefert ein skalierbares interaktives Ad-hoc-Abfragesystem für die Analyse verschachtelter Daten. Durch Kombinieren von Multilevel-Ausführungsbäumen mit einem spaltenartigen Datenlayout kann das Verfahren schnelle und effiziente Abfragen wie beispielsweise Aggregationsabfragen durchführen. Es wird eine Spaltenspeicherdarstellung für verschachtelte Datensätze, ein verbreitetes Datenmodell beschrieben, das in vielen Web-Skalierungs- und wissenschaftlichen Datensätzen angewendet werden kann. Gemäß einer Ausführungsform wird ein Datensatz in Spaltenstreifen zerlegt, wobei jede Spalte als eine Reihe von Blöcken codiert ist, wobei jeder Block Feldwerte und Informationen zu Repetitions- und Definitionsebenen beinhaltet. Ebeneninformationen werden unter Verwendung eines Baumes aus Feld-Schreibelementen erzeugt, deren Aufbau mit der Feldhierarchie in dem Datensatzschema übereinstimmt. Der Datensatz kann unter Verwendung einer finiten Zustandsmaschine assembliert werden, die die Feldwerte und Ebeneninformationen für jedes Feld liest und die Werte sequenziell an die ausgegebenen Datensätze anhängt. Im Vergleich zu herkömmlichen Lösungen, die alle Datenfelder aus jeder Aufzeichnung extrahieren, kann eine endliche Zustandsmaschine konstruiert werden, die auf eine begrenzte Menge von Datenfeldern in allen oder einem Teil der Aufzeichnungen zugreift (z. B. ein einziges Datenfeld innerhalb aller Aufzeichnungen). Ferner können durch Speichern zusätzlicher Metadaten wie etwa Zwangsbedingungsinformationen mittels der spaltenförmigen Speicherdarstellung zusätzliche Typen von Abfragen unterstützt werden.
Es wird ein Multilevel(über mehrere Ebenen)-Bereitstellungsbaum zum Ausführen von Abfragen verwendet. Bei einer Ausführungsform empfängt ein Root-Server eine eingehende Abfrage, liest Metadaten aus den Tabellen und leitet die Abfragen an eine nächste Ebene in dem Bereitstellungsbaum weiter. Leaf(Endknoten)-Server kommunizieren mit einer Speicherschicht oder greifen auf die Daten auf dem lokalen Speicher zu, wo die gespeicherten Daten repliziert werden können, und liest Streifen von verschachtelten Daten in der spaltenartigen Darstellung. Jeder Server kann einen internen Ausführungsbaum umfassen, der einem physischen Abfrageausführungsplan entspricht, der eine Reihe an Iteratoren aufweist, die eingegebene Spalten scannen und Ergebnisse von Aggregaten (Zusammenfassungen) und skalaren Funktionen emittieren, die mit Ebeneninformationen versehen sind. In einer weiteren Ausführungsform wird ein Abfrage-Dispatcher bereitgestellt, der Abfragen auf der Grundlage ihrer Prioritäten terminiert und die Last ausgleicht. Der Abfrage-Dispatcher stellt zudem eine Fehlertoleranz bereit, wenn ein Server viel langsamer als andere oder wenn ein Replikat unerreichbar wird. Der Abfrage-Dispatcher kann ein Histogramm an Bearbeitungszeiten für Ausführungs-Threads auf den Leaf-Servern berechnen und die Zeitplanung für einen anderen Server vorsehen, wenn die Bearbeitungszeit eine unverhältnismäßige Menge an Zeit in Anspruch nimmt.
Ein Web-Service kann Benutzern Fernzugriff auf das Abfragesystem und ein unterstützendes Datenspeichersystem bieten. Benutzer des Web-Service können Daten in das Datenspeichersystem für gehostete Speicherung hochladen. Ein Teil der hochgeladenen Daten kann Sammlungen geschachtelter Aufzeichnungen umfassen und als Objekt gespeichert werden. Der Web-Service kann für multiple Benutzer entferntes Datenhosting bieten und ihnen erlauben, Daten per Streaming an den Web-Service zu übertragen und diese Daten an einem einzigen Standort zu aggregieren. Benutzer können Tabellen erstellen und für diese Abfragen vornehmen sowie die Daten in einem oder mehreren der im Datenspeichersystem gespeicherten Objekte in die Tabellen importieren. Der Importvorgang kann die Konversion geschachtelter Daten in einem Objekt in spaltenorientierte Daten und deren Speicherung in einer anderen Datenschicht als den Objekten beinhalten. So kann eine Tabelle aus der Sicht des Benutzers mit Daten aus Objekten gefüllt sein, doch in Wirklichkeit zugrunde liegende Sätze von spaltenorientierten Daten referenzieren. In diesem Fall können Abfragen der Tabellen durch Benutzer des Webservice das Abfragesystem veranlassen, bestimmte Datenspalten abzufragen, die den Tabellen zugrunde liegen.
Die spaltenorientierten Daten können in situ abgefragt werden. Durch das Halten der Spaltendaten auf einer gemeinsamen Speicherschicht und das Bereitstellen von Mechanismen zum Assemblieren von Datensätzen anhand der Spaltendaten wird eine Betriebsbereitschaft mit Datenverwaltungs-Tools ermöglicht, die Daten in einer Datensatzstruktur analysieren. Das System kann eine Vielzahl von CPUs skalieren und zu schnellem Lesen von großen Datenmengen in der Lage sein. Es können bestimmte Ausführungsformen in bestimmten Fällen implementiert werden, um einen oder mehrere der folgenden Vorteile umzusetzen. Verschachtelte Daten können in situ bearbeitet werden, so dass auf sie zugegriffen werden kann, ohne die Daten mit einem Datenbank-Managementsystem zu laden. Abfragen an verschachtelten Daten können in einer verringerten Ausführungszeit als bei anderen Analyseprogrammen erforderlich durchgeführt werden. Mit einer Spaltenspeicher-Datenstruktur, die auf einer gewöhnlichen Speicherschicht implementiert ist, können mehrere verschiedene Analyseprogramme auf die Spaltenspeicher-Datenstruktur zugreifen.
Als Alternative zu den beigefügten Ansprüchen und den in der nachstehend aufgeführten Beschreibung dargestellten Ausführungsformen könnte die gegenwärtige Erfindung auch durch eine der folgenden Ausführungsformen beschrieben werden:
Ausführungsform 1 bezieht sich auf ein computerimplementiertes Verfahren. Das Verfahren umfasst den Empfang einer Anforderung in einem Serversystem und aus einem entfernten Computergerät für die Speicherung von eine Daten in dem Serversystem. Das Verfahren umfasst die Speicherung der in der Anforderung identifizierten Daten durch das Serversystem als ein Objekt in einem Repository innerhalb des Serversystems. Das Verfahren umfasst den Empfang einer Anforderung in dem Serversystem und aus einem entfernten Computergerät für die Erstellung einer Tabelle, worin die Anforderung einen Namen für die Tabelle identifiziert. Das Verfahren umfasst die Erstellung der Tabelle mit dem in der Anforderung identifizierten Namen durch das Serversystem und in dem Serversystem. Das Verfahren umfasst den Empfang einer Anforderung in dem Serversystem für den Import der in dem Objekt befindlichen Daten in die Tabelle. Das Verfahren umfasst den Import der in dem Objekt befindlichen Daten in die Tabelle durch das Serversystem, worin der Import der in dem Objekt befindlichen Daten in die Tabelle das Folgende beinhaltet: (i) die Konversion der in dem Objekt befindlichen Daten in spaltenorientierte Streifen und (ii) die Speicherung der spaltenorientierten Streifen in Assoziation mit der Tabelle. Das Verfahren umfasst den Empfang einer Anforderung in dem Serversystem und aus einem entfernten Computergerät für die Durchführung einer Abfrage für die Tabelle, worin die Anforderung die Abfrage enthält und die Tabelle identifiziert. Das Verfahren umfasst die Durchführung der Abfrage für die Tabelle, worin die Durchführung der Abfrage eine Abfrage für eine oder mehrere der spaltenorientierten Streifen enthält.
Ausführungsform 2 ist mit dem Verfahren von Ausführungsform 1 verwendet, worin das Repository eine Sammlung von Raster umfasst und die Anforderung für die Speicherung der Daten ein Raster aus der Sammlung identifiziert, während jedes Raster einen Namen trägt, der unter den Raster in dem Repository einzigartig ist und jedes Raster einen Namenraum für Objekte bereitstellt, die in jedem Raster gespeichert sind, und worin die Speicherung der Daten die Speicherung des Objektes in dem in der Anforderung der Datenspeicherung identifizierten Raster umfasst.
Ausführungsform 3 bezieht sich auf das Verfahren von Ausführungsform 2, worin das Repository Raster in einem flachen Namensraum solcherart speichert, dass Raster nicht verschachtelt sind.
Ausführungsform 4 bezieht sich auf das Verfahren von Ausführungsform 2, worin ein Raster in der Sammlung multiple verschiedene entfernte Computergeräte bereitstellt, die mit den verschiedenen authentifizierten Benutzerkonten korrespondieren mit der Fähigkeit, Daten aus den verschiedenen entfernten Computergeräten in das Raster hochzuladen.
Ausführungsform 5 bezieht sich auf das Verfahren einer jeglichen der Ausführungsformen 1–4, worin die Anforderung für die Datenspeicherung, für die Erstellung der Tabelle und für die Durchführung der Abfrage in dem Serversystem über Anwendungsprogrammieroberflächen und von einem oder mehreren entfernten Computergeräten empfangen werden, welche die Anforderungen über das Internet einreichen.
Ausführungsform 6 bezieht sich auf das Verfahren einer jeglichen der Ausführungsformen 1–5, worin das Verfahren weiterhin den Empfang einer Anforderung in dem Serversystem und aus einem entfernten Computergerät für die Einrichtung eines kontinuierlichen Importservice umfasst, wobei die Anforderung ein Raster zur Überwachung von neu gespeicherten Objekten sowie eine Tabelle identifiziert, in die in dem neu gespeicherten Objekt befindliche Daten importiert werden sollen, und worin die Anforderung für den Import der in dem Objekt befindlichen Daten in die Tabellen von dem in dem Serversystem operierenden kontinuierlichen Importservice in Reaktion auf die Feststellung durch den kontinuierlichen Importservice empfangen wird, dass das Objekt neu in dem Raster gespeichert wurde.
Ausführungsform 7 bezieht sich auf das Verfahren der Ausführungsform 6, worin das Verfahren weiterhin die Löschung des Objektes aus dem Repository in Reaktion auf den Import der in dem Objekt befindlichen Daten in die Tabelle umfasst.
Ausführungsform 8 bezieht sich auf das Verfahren einer jeglichen der Ausführungsformen 1–7, worin die Daten eine Sammlung strukturierter Aufzeichnungen beinhaltet und diese Sammlung strukturierter Aufzeichnungen in dem Objekt gespeichert ist, und worin der Import der in dem Objekt befindlichen Daten in die Tabelle die Konversion der in dem Objekt befindlichen strukturierten Aufzeichnungen in spaltenorientierte Streifen beinhaltet, von denen jede Werte für ein Feld der strukturierten Aufzeichnungen beinhaltet.
Ausführungsform 9 bezieht sich auf das Verfahren der Ausführungsform 8, worin eine bestimmte der strukturierten Aufzeichnungen multiple Werte für ein bestimmtes Feld umfasst, während die multiplen Werte für das bestimmte Feld in einem bestimmten spaltenorientierten Streifens gespeichert werden.
Ausführungsform 10 bezieht sich auf das Verfahren der Ausführungsform 9, worin die bestimmte Aufzeichnung multiple Werte für ein anderes Feld beinhaltet, und worin die multiplen Werte für das andere Feld in einem anderen spaltenorientierten Streifen gespeichert sind.
Ausführungsform 11 bezieht sich auf das Verfahren der Ausführungsform 10, worin der bestimmte spaltenorientierte Streifen in einer benachbarten Beziehung Werte für das bestimmte Feld aus multiplen der Aufzeichnungen speichert.
Ausführungsform 12 bezieht sich auf das Verfahren der Ausführungsform 11, worin die bestimmte Aufzeichnung verschachtelte Sätze von Werten für Felder beinhaltet.
Ausführungsform 13 bezieht sich auf das Verfahren der Ausführungsform 8, worin ein Schema eine Struktur der strukturierten Aufzeichnungen in der Sammlung spezifiziert, und worin das Verfahren weiterhin das Folgende umfasst: den Empfang einer Anforderung in dem Serversystem und aus einem entfernten Computergerät für die Erweiterung des Schemas zwecks Einbeziehung eines neuen Feldes und Generierung eines neuen spaltenorientierten Streifens durch den Server für das neue Feld, ohne die spaltenorientierten Streifen zu modifizieren.
Ausführungsform 14 bezieht sich auf das Verfahren der Ausführungsform 8, worin ein Schema eine Struktur der strukturierten Aufzeichnungen in der Sammlung spezifiziert, und worin das Verfahren weiterhin das Folgende umfasst: den Empfang einer Anforderung in dem Serversystem und aus einem entfernten Computergerät für die Änderung des Namens eines in dem Schema existierenden Feldes in einen neuen Namen für das Feld und die Zuordnung des neuen Namens durch den Server als Pseudonym des existierenden Namens, so dass mit einem Feld des existierenden Namens identifizierte Daten und mit einem Feld des neuen Namens identifizierte Daten in demselben spaltenorientierten Streifen gespeichert werden.
Ausführungsform 15 bezieht sich auf das Verfahren einer jeglichen der Ausführungsformen 1–14, worin die Erstellung der Tabelle die Generierung eines Delegat-Objektes in dem Repository mit dem Namen der Tabelle beinhaltet.
Ausführungsform 16 bezieht sich auf das Verfahren einer jeglichen der Ausführungsform 15, worin die Erstellung der Tabelle die Generierung von Metadaten für die Tabelle in einer Datenbank enthält, das Delegat-Objekt die Daten für die Tabelle referenziert, so dass auf die Metadaten zugegriffen wird, wenn das Serversystem mit dem Delegat-Objekt eine Operation vornimmt.
Ausführungsform 17 bezieht sich auf das Verfahren einer jeglichen der Ausführungsformen 1–16, worin die Tabelle ein strukturierter Datensatz ist, der für die Abfrage durch das Serversystem konfiguriert ist.
Ausführungsform 18 bezieht sich auf das Verfahren einer jeglichen der Ausführungsformen 1–17, worin das Objekt und die eine oder mehreren spaltenorientierten Streifen unter geographisch verteilten Computergeräten, die das Serversystem bilden, reproduziert werden.
Ausführungsform 19 bezieht sich auf ein computerimplementiertes Verfahren. Das Verfahren umfasst die Übertragung einer Anforderung durch ein Computergerät und an einen entfernten Server für die Speicherung von Daten in dem Serversystem solcherart, dass in Reaktion auf den Empfang der Anforderung das System die in der Anforderung identifizierten Daten als Objekt in einem Repository im Serversystem speichert. Das Verfahren umfasst die Übertragung einer Anforderung durch das Computergerät und an einen entfernten Server für die Erstellung einer Tabelle, worin die Anforderung einen Namen für die Tabelle solcherart identifiziert, dass in Reaktion auf den Empfang der Anforderung das Serversystem die Tabelle mit dem in der Anforderung identifizierten Namen erstellt. Das Verfahren umfasst die Übertragung einer Anforderung durch ein Computergerät und an einen entfernten Server für den Import der in dem Objekt befindlichen Daten solcherart, dass in Reaktion auf den Empfang der Anforderung das Serversystem die in dem Objekt befindlichen Daten in die Tabelle importiert, worin der Import der in dem Objekt befindlichen Daten in die Tabelle Folgendes beinhaltet: (i) die Konversion der in dem Objekt befindlichen Daten in spaltenorientierte Streifen und (ii) die Speicherung der spaltenorientierten Streifen in Assoziation mit der Tabelle. Das Verfahren umfasst die die Übertragung einer Anforderung durch das Computergerät und an das Serversystem für die Durchführung einer Abfrage für die Tabelle, wobei die Anforderung die Abfrage beinhaltet und die Tabelle identifiziert, solcherart, dass in Reaktion auf den Empfang der Anforderung das Serversystem die Abfrage für die Tabelle vornimmt, worin das Durchführen der Abfrage das Abfragen einer oder mehrerer spaltenorientierter Streifen beinhaltet.
Weitere Ausführungsformen der beschriebenen Aspekte umfassen korrespondierende computerlesbare Speichergeräte, die Anweisungen speichern, die, wenn sie durch ein oder mehrere Datenverarbeitungsgeräte ausgeführt werden, Operationen gemäß der vorstehend beschriebenen Verfahren ausführen. Weitere Ausführungsformen können Geräte und Apparate umfassen, welche die beschriebenen computerlesbaren Speichergeräte beinhalten und für die Ausführung der Operation unter Einsatz von einem oder mehreren Datenverarbeitungsgeräten konfiguriert sind.
Ausführungsform 20 beinhaltet ein System, das Folgendes umfasst: ein Repository für die Speicherung von Objekten in einem Serversystem, das als Objekt für die Speicherung von Daten konfiguriert ist, die von einem entfernten Computergerät übertragen werden; ein System für das Tabellenmanagement, das in Reaktion auf eine Anforderung von einem entfernten Computergerät für die Erstellung einer Tabelle konfiguriert ist; einen Import-Jobmanager in dem Serversystem, der in Reaktion auf eine Anforderung aus einem entfernten Computergerät für den Import der in dem Objekt befindlichen Daten in die Tabelle, konfiguriert ist, worin der Import der in dem Objekt befindlichen Daten das Folgende beinhaltet: (i) die Konversion der in dem Objekt befindlichen Daten in spaltenorientierte Streifen und (ii) die Speicherung der spaltenorientierten Streifen in Assoziation mit der Tabelle; und ein Datenverarbeitungssystem für spaltenorientierte Daten in dem Serversystem, das in Reaktion auf eine Anforderung für die Durchführung einer Abfrage aus einem entfernten Computergerät für die Durchführung der Abfrage für die Tabelle konfiguriert ist, worin die Durchführung der Abfrage die Abfrage für eine oder mehrere der spaltenorientierten Streifen umfasst.
Die Einzelheiten von einer oder mehreren Ausführungsformen sind in den begleitenden Zeichnungen und der nachstehenden Beschreibung dargestellt. Andere Merkmale, Objekte und Vorteile sind anhand der Beschreibung und den Zeichnungen sowie anhand der Patentansprüche ersichtlich.
BESCHREIBUNG DER ZEICHNUNGEN
1 illustriert die aufzeichnungsmäßige gegenüber der spaltenorientierten Darstellung geschachtelter Daten.
2 illustriert zwei musterhafte geschachtelte Aufzeichnungen und ihr Schema.
3 illustriert Darstellungen mit spaltenorientierten Streifen der musterhaften geschachtelten Aufzeichnungen.
4 ist ein Algorithmus für die Zerlegung einer Aufzeichnung in Spalten.
5 illustriert einen Automaten zur Durchführung einer vollständigen Aufzeichnungsassemblierung.
6 illustriert einen Automaten zur Assemblierung von Aufzeichnungen aus zwei Feldern und die Aufzeichnungen, die der Automat produziert.
7 ist ein Algorithmus für die Konstruktion eines Automaten zur Aufzeichnungsassemblierung.
8 ist ein Algorithmus für die Assemblierung einer Aufzeichnung aus spaltenorientierten Daten.
9 stellt das Beispiel einer musterhaften Abfrage dar, die Projektion und Selektion sowie innerhalb der Aufzeichnung eine Aggregation vornimmt.
10 illustriert eine Systemarchitektur und Realisierung innerhalb eines Serverknotens.
11 ist eine Tabelle, die die in der experimentellen Studie benutzten Datensätze darstellt.
12 ist ein Graph, der den Leistungsabfall illustriert, der beim Ablesen einer lokalen Festplatte erfolgen kann.
13 ist ein Graph, der die Realisierung von sowohl MapReduce und des beschriebenen Systems für eine spaltenorientierte gegenüber einer aufzeichnungsorientierten Speicherung illustriert.
14 ist ein Graph, der die Realisierungszeit als eine Funktion der Bedienung von Baumstrukturen für zwei Aggregationsabfragen illustriert.
15 ist ein Graph, der Histogramme der Verarbeitungszeiten illustriert.
16 ist ein Graph, der die Realisierungszeit illustriert, wenn das System unter Einsatz einer Top-K-Abfrage von 1000 auf 4000 Knoten skaliert wird.
17 ist ein Graph, der einen Prozentsatz verarbeiteter Tabellen als eine Funktion der Realisierungszeit pro Tablet illustriert.
18 ist ein Graph, der die Verteilung der Responsezeit für die Abfrage eines monatlichen Arbeitspensums illustriert.
19 ist das Blockdiagramm eines Systems zur Generierung und Verarbeitung spaltenorientierter Speicherdarstellungen verschachtelter Aufzeichnungen.
20 ist das Flussdiagramm eines musterhaften Verfahrens zur Generierung spaltenorientierter Daten.
21 ist ein Blockdiagramm, welches das Beispiel eines Systems illustriert, das einen Webservice zur Datenspeicherung und -verarbeitung implementiert.
22 ist ein Flussdiagramm, welches das Beispiel eines Verfahrens zur Durchführung von Datenspeicherung und -verarbeitung zeigt.
23 ist ein Blockdiagramm von Computergeräten, die zur Implementierung der in diesem Dokument beschriebenen Systeme und Verfahren benutzt werden können, entweder als Client oder Server oder als eine Vielzahl von Servern.
Gleiche Verweissymbole in den verschiedenen Zeichnungen zeigen gleiche Elemente an.
AUSFÜHRLICHE BESCHREIBUNG
Dieses Dokument beschreibt Techniken, Verfahren, Systeme und Mechanismen für einen Datenspeicherungs- und Datenverarbeitungsservice. Das beschriebene System kann Darstellungen einer spaltenorientierten Speicherung von verschachtelten Aufzeichnungen generieren und verarbeiten. Als eine Veranschaulichung kann ein Unternehmen Daten von Webseiten in Datensätzen verschachtelter Daten speichern. Die verschachtelten Daten können in einem Spaltendatenspeicherformat gespeichert werden, das effiziente Abfragen der Daten unter Verwendung eines Multilevel-Ausführungsbaums ermöglicht. Der Spaltenspeicher kann in Datensätze zur Eingabe in Analyseprogramme erneut assembliert werden, die an nach Datensätzen gespeicherten Daten operieren.
Genauer gesagt kann jede Aufzeichnung die Instanz eines Schemas sein, das eine Formatierung von Aufzeichnungen definiert, worin die Aufzeichnungen im Einklang mit dem Schema erstellt werden. So kann ein Schema beispielsweise verschiedene Felder zum Speichern von Informationen über eine Webseite und eine Struktur zum Organisieren von Feldern in einem Datensatz und ihre entsprechenden Werte identifizieren. Wenn die Instanz einer Aufzeichnung für die Beschreibung der Charakteristika einer Website generiert wird, kann die Aufzeichnung für jedes Feld ein Datenelement und einen korrespondierenden Wert enthalten. Das Datenelement kann die Semantik des Wertes gemäß einer Definition in dem Schema definieren. Die Begriffe Datenelement und Feld können in diesem Dokument untereinander austauschbar verwendet werden. Feld kann sich auch auf eine Kombination eines Datenelementes und eines entsprechenden Wertes beziehen.
Es kann sein, dass eine bestimmte Aufzeichnung nicht alle der Felder enthalten muss, die durch ein Schema definiert werden. Solcherart kann das Schema als Vorlage dienen, aus der die Felder für die bestimmte Aufzeichnung gewählt werden. So kann das Schema beispielsweise ein Feld zum Definieren von Informationen über Videoinhalt in einer Webseite beinhalten. Enthält eine Webseite keinen Videoinhalt, dann beinhaltet der der Webseite entsprechende Datensatz möglicherweise nicht das Feld von dem Schema, das Informationen über Videos auf der Webseite beinhaltet. Daher können einige der Felder 'optional' sein.
Einige der Felder in einer Aufzeichnung können jedoch Erforderlich' sein.' So kann beispielsweise ein 'erforderlich'-Feld in dem Schema ein Einheitlicher Ressourcenzeiger (englisch: Uniform Resource Locator (URL) eines Quellenortes für das Dokument sein, der die Webseite bedient hat. Das Feld kann erforderlich sein, weil auf jedes Webseitendokument von einem Quellenort zugegriffen werden kann (d. h. es ist ein URL für jedes Dokument verfügbar) und weil das Feld zum weiteren Verarbeiten von Informationen auf der Webseite erforderlich ist (beispielsweise um zu bestimmen, ob sich der Inhalt geändert hat).
Ein Feld kann auch 'wiederholbar' sein. Ein Feld, das sich in dem Schema befindet und als wiederholbar definiert ist, kann an dem von dem Feld definierten Standort wiederholt in einer Instanz des Schemas (d. h. in einer Aufzeichnung) reproduziert werden. So kann ein Schema beispielsweise ein Feld beinhalten, das zum Definieren von Dokumenten dient, die einen Link zu der Webseite bilden. Das Schema kann dem Feld nur eine einzige Zeit spezifizieren, kann jedoch anzeigen, dass das Feld wiederholbar ist (beispielsweise weil mehrere Dokumente einen Link zu einer bestimmten Webseite bilden können). Demgemäß kann ein Datensatz für die Webseite mehrere Felder beinhalten, die einen Wert für eine verlinkende Webseite identifizieren. Die wiederholten Felder können auf einer gleichen Ebene und unter einem übergeordneten Feld in dem Datensatz (wie dies nachstehend ausführlicher beschrieben wird) angeordnet sein.
Die Felder des Schemas (und somit die Felder in den Aufzeichnungen) können verschachtelt sein. Mit anderen Worten bedeutet dies, dass einige Felder untergeordnete Felder von anderen Feldern sein können, die als übergeordnete Felder, in zweiter Ebene übergeordnete Felder usw. bezeichnet werden können. In einigen Beispielen sind untergeordnete Knoten jene Knoten in dem Schema, die innerhalb eines Paares von geöffneten und geschlossenen welligen Klammern unmittelbar nach dem übergeordneten Knoten angeordnet sind. Es können jedoch auch andere Implementierungen (beispielsweise die Verwendung eines Start-Tag für das Feld und eines End-Tag für das Feld) verwendet werden. Demgemäß kann, mit Ausnahme der Felder, die sich auf der höchsten Ebene befinden (beispielsweise die Felder, die keine untergeordnete Felder von irgendwelchen anderen Feldern sind), jedes Feld ein übergeordnetes Feld haben.
Verschachtelung kann bei der Organisation von Informationen in konzeptuell verbundene Informationsstücke hilfreich sein. Beim Rückgriff auf unser vorheriges Beispiel kann das Schema ein 'Videofeld' umfassen. Das 'Videofeld' kann eine Anzahl von Ablegerfeldern umfassen, welche die Charakteristika des Videos identifizieren (z. B. wie lang das Video ist, das Format des Videos und seine Resolution). Wird demgemäß ein Datensatz erstellt, dürfen untergeordnete Knoten nicht in den Datensatz platziert werden, wenn ihre übergeordneten Knoten nicht vorhanden sind. Mit anderen Worten kann es sein, dass die Aufzeichnung einer Website, die kein Video enthält, kein Feld der 'Videolänge' umfasst, weil die Aufzeichnung kein 'Videofeld' aufweist (d. h. den Elternteil des Feldes der 'Videolänge'.). Anwendungsprogramme, die Ansehen und Bearbeiten eines Datensatzes ermöglichen, können die abhängigen untergeordneten Felder visuell von den übergeordneten Feldern entfernt verschachteln (beispielsweise die untergeordneten Felder rechts von dem übergeordneten Feld eingerückt).
Die Analyse von Millionen von Aufzeichnungen kann zeitaufwendig sein. In einigen Beispielen interessiert sich ein Nutzer für Daten aus einem einzelnen Feld, muss jedoch auf jeden der Datensätze in ihrer Gesamtheit zugreifen. So kann ein Nutzer beispielsweise anfordern, dass ein Analyseprogramm Millionen von Datensätzen prüft, um jene Datensätze zu identifizieren, die den Webseiten zugewiesen sind, die Videos beinhalten, welche nicht länger als zehn Minuten sind und die eine hohe Auflösung ('High') haben. Da jeder Datensatz als eine separate Datenstruktur gespeichert werden kann, muss eventuell jeder Datensatz in seiner Gesamtheit in ein Datenbankverwaltungssystem geladen werden, um den Datensatz abzufragen, um zu bestimmen, ob der Datensatz die bestimmte Kombination aus Videolänge und Auflösung beinhaltet.
Solch eine Ladung einer jeden einzelnen Aufzeichnung kann unerhört teuer sein, sowohl im Hinblick auf die Anzahl der Server, die zur Durchführung der Aufgabe erforderlich sind, als auch auf die Zeit, die für den Abschluss der Abfrage gebraucht wird. Es können erhebliche Zeiteinsparungen durch Speichern aller der Werte für ein bestimmtes Feld, das aus den Millionen von Datensätzen ausgewählt wird, zusammen in einem zusammenhängenden Abschnitt des Speichers erzielt werden. Solch ein Speichern von Werten von mehreren Datensätzen jedoch für ein bestimmtes Feld wird als Spaltenspeicher bezeichnet. Im Gegensatz dazu wird das Beispiel, bei dem Informationen für einen bestimmten Datensatz zusammenhängend in einem Speicher gespeichert wird, als datensatzorientiertes Speichern bezeichnet.
Spaltenorientierte Speicherung für verschachtelte Aufzeichnungen weist jedoch einzigartige Schwierigkeiten auf. Ein Feld in einem Datensatz kann durch seinen Pfad identifiziert werden, der eine Aufstellung des Feldes und der übergeordneten Felder (beispielsweise GrandParent.Parent.Child) beinhalten kann. Da sich ein oder mehrere der Felder in dem Pfad wiederholen können, kann es mehrere Instanzen eines Feldes mit demselben Pfadnamen geben. Schaut man sich eine darauffolgende Auflistung von Spaltendaten für ein bestimmtes Feld an, wird ein Mechanismus benötigt, um zu identifizieren, welche Werte zu welchen Datensätzen gehören, und für jene Datensätze, die mehrere Werte für einen bestimmten Pfaden beinhalten, welches der jeweilige Ort des Wertes in dem Datensatz ist. Mit anderen Worten wird in Anbetracht einer Sequenz von Werten in einer Spaltenstruktur ein Mechanismus zum Rekonstruieren der Struktur des Datensatzes anhand der Werte benötigt.
Der Mechanismus für die Rekonstruktion der Struktur einer Aufzeichnung aus spaltenorientierten Daten umfasst die Speicherung für jeden Wert in den spaltenorientierten Daten, eine 'Wiederholungsebene' und eine 'Definitionsebene'. Jede 'Ebene' ist eine Sequenz von Bits, die eine Zahl repräsentiert. Eine 'Ebene' von 3 zum Beispiel kann durch zwei Bits repräsentiert werden (z. B. '11'). In einem anderen Beispiel kann eine 'Ebene' von 5 von drei Bits dargestellt sein (beispielsweise '101').
Die 'Wiederholungsebene', die für einen bestimmten Wert gespeichert wird, zeigt das Feld im Pfad des Wertes an, das zuletzt wiederholt wurde. Als Veranschaulichung kann eine Spalte an Werten für ein Feld mit dem Pfad 'Video.Resolution.Width.' gespeichert werden. Eine Wiederholungsebene von '1' kann anzeigen, dass das 'Videofeld' das zuletzt wiederholte ist, während eine Wiederholungsebene von '2' darauf hinweisen kann, dass das 'Auflösungsfeld' das zuletzt wiederholte ist. Ein kürzliches Wiederholen kann von der Position des Wertes in dem Datensatz anzeigen, von dem der Wert ausgewählt wurde und nach oben in Richtung des Anfangs des Dokumentes arbeitend, welches Feld in dem Pfad 'Video.Resolution.Width.' das erste sein wird, das einen Zählwert von zwei erreicht (beispielsweise welches Feld zuerst zum zweiten Mal vorkommt.
Wenn man zum Beispiel vom Standort des 'Breitenwertes' nach oben arbeitet, wird jedes Feld ein einziges Mal angetroffen. Für ein Auffinden einer zweiten Instanz eines jeden Feldes muss man quer zu den Tiefen des nächsten, angrenzenden verschachtelten Feldes (und möglicherweise zu weiteren Verschachtelungen) vorgehen. Solcherart kann ein 'Videofeld' angetroffen werden, das keine 'Auflösungsableger' umfasst (z. B. weil das Auflösungsfeld' optional oder ein Wiederholungsfeld ist). Daher wurde das 'Videofeld' zum zweiten Mal angetroffen und ist somit das zuletzt wiederholte Feld. Eine Wiederholungsebene von '1' wird dem Wert zugeordnet.
Eine Wiederholungsebene von '0' kann anzeigen, dass das Feld keinen zuletzt wiederholten Wert umfasst (z. B. wenn es zum ersten Mal in den Aufzeichnungen im Verlauf eines Top-Down-Scans angetroffen wurde). In verschiedenen Beispielen weist ein 'required' (erforderlich)-Feld in einem Pfad keine Repetitions-Ebene auf. Wenn das 'Auflösungsfeld' für den Pfad 'Video. Auflösung. Breite' erforderlich ist, kann das Spektrum der Auflösungsebenen entweder '0' oder '1' sein. Die 'Auflösung' kann auch keine Ebene haben, weil sie stets in der Aufzeichnung anwesend ist, wenn das 'Videofeld' vorhanden ist. Wenn daher der 'Auflösung' eine Ebene von '2' zugeordnet wurde, kann sie immer vor 'Video' angetroffen werden, und daher kann es sein, dass eine Ebene von '1' niemals zugeordnet wird. Demgemäß können durch das Nicht-Einfügen einer Repetition-Ebene für erforderliche Felder eine Anzahl von verschiedenen Auflösungsebenen und eine Anzahl von Bits zum Darstellen der Auflösungsebene reduziert werden.
Wenn das Feld der 'Breite' in dem obigen Beispiel ein 'optionales' oder 'sich wiederholendes' Feld ist, kann es sein, dass eine Aufzeichnung nicht immer einen Wert für das Feld der 'Breite' beinhaltet. Demgemäß kann eine Spalte an Werten für den 'Video.Resolution.Width'-Pfad einen Mechanismus verwenden, um anzugeben, wenn ein 'Video' oder ein 'Video.Resolution'-Pfad in dem Datensatz gefunden wird, das 'Width'-Feld jedoch in dem Datensatz nicht instantiiert wurde. Dieser Mechanismus kann Speichern, in der 'Video.Resolution.Width'-Datenspalte, einer 'Definition'-Ebene für jedes 'Video'- oder 'Video.Resolution'-Feld in dem Datensatz unabhängig davon umfassen, ob das 'Width'-Feld instantiiert ist. Die 'Definition'-Ebene kann anzeigen, wie viele der Felder in dem 'Video.Resolution.Width'-Pfad, die fehlen könnten (beispielsweise weil das erste Feld optional oder wiederholbar ist), tatsächlich vorhanden sind.
Wenn daher das Feld 'Video' in der Aufzeichnung vorhanden ist, sich jedoch kein korrespondierender 'Resolutionsableger' findet, kann eine Definitionsebene von '1' in der Spalte 'Video. Auflösung. Breite' aufgezeichnet sein. Wenn das Feld 'Video.Auflösung' in der Aufzeichnung vorhanden ist, sich jedoch kein korrespondierender 'Breitenableger' findet, kann eine Definitionsebene von '2' aufgezeichnet sein. Ist das Feld 'Video.Resolution.Width' in dem Datensatz vorhanden, kann eine Definitionsebene von '3' eingetragen werden.
Daher kann immer, wenn die 'Definitionsebene' (welche die Anzahl der Felder repräsentiert, die nicht definiert sein könnten, jedoch tatsächlich definiert sind) weniger beträgt als die Anzahl der Felder, die definiert sein könnten, ein fehlendes Vorkommen des Feldes 'Breite' identifiziert werden. Die Kombination der 'Wiederholungsebene' und der 'Definitionsebene' kann eine Rekonstruktion der Struktur der Aufzeichnung ermöglichen.
Eine Spalte mit Daten für ein bestimmtes Feld (z. B. das Feld, Video.Auflösung.Breite') kann die Werte für das Feld aus multiplen Aufzeichnungen, korrespondierende Wiederholungs- und Definitionsebenen (unter Anerkennung der Tatsache, dass einige 'fehlende' Werte eine Wiederholungs-, aber keine Definitionsebene haben), und Header-Informationen beinhalten. In einigen Beispielen werden die Werte aufeinanderfolgend und angrenzend gespeichert. Wenn mit anderen Worten der Wert für ein Feld der 'Video.Auflösung.Breite' ,700' betrug und der Wert für ein nächstes Feld der 'Video.Auflösung.Breite' sich auf '800' belief, kann ein Teil der Spalte wie im Speicher gespeichert sich als '700800' lesen. In diesem Beispiel kann ein Header in der Spalte identifizieren, dass jeder Wert eine feste Breite hat (z. B. eine feste binäre Repräsentation, um die Zahlen 700 und 800 zu umfassen).
In einigen Beispielen werden die gespeicherten Daten von Strings repräsentiert. So können zum Beispiel Instanzen des Feldes 'Breite' die Werte 'klein' und 'medium' enthalten. In einigen Beispielen können die verschiedenen Zeichenfolgewerte einer festgelegten Länge (beispielsweise kann dem Anfang oder dem Ende des 'Small'-Wertes ein Nullwert hinzugefügt werden, um der Zeichenfolge mit derselben Länge wie dem 'Medium'-Wert zu versehen) sein. In einigen Beispielen kann jedoch jede gespeicherte Zeichenfolge eine Kennung in einem Anfangsanschnitt der Zeichenfolge beinhalten, die eine Länge der Zeichenfolge identifiziert. Der Wert 'klein' kann zum Beispiel ein Identifizierungsmerkmal umfassen, das anzeigt, dass der String fünf Ziffern lang ist (oder eine korrespondierende Anzahl von binären Bits umfasst).
Da die Werte konsekutiv in dem spaltenorientierten Streifen gespeichert werden können, können die 'Wiederholungs-, und 'Definitionsebenen' zu Anfang des spaltenorientierten Streifens gespeichert werden. In einigen Beispielen werden die 'Repetition' und 'Definition'-Ebene in Paaren für einen bestimmten Wert (ungeachtet ob instantiiert oder fehlend) gespeichert. Als Veranschaulichung kann eine Repetitionsebene von 3 in den ersten vier Bits eines Byte und eine Definitionsebene von 1 in den letzten vier Bits des Byte gespeichert werden. Ein nächstes Byte in dem Header kann eine Repetitionsebene und eine Definitionsebene für die nächste Instanz des Feldes in dem Datensatz (oder der ersten Instanz in dem sich anschließenden Datensatz) beinhalten.
Die Anzahl der für die Repräsentation der Wiederholungs- und Definitionsebenen eingesetzten Bits kann sich auf einen maximalen Wert für die Ebene gründen. Wenn beispielsweise eine maximale Repetitionsebene 3 ist, kann die Repetitionsebene mit zwei Bits dargestellt werden. Wenn die maximale Repetitionsebene 4 ist, kann die Repetitionsebene mit drei Bits dargestellt werden. Der Header kann Informationen beinhalten, die die Länge der Repetitions- und Definitionsebene identifizieren.
In verschiedenen Beispielen können die Wiederholungsebenen konsekutiv im Speicher gespeichert und die Definitionsebenen konsekutiv im Speicher gespeichert werden (d. h., nicht in Paaren). In verschiedenen Beispielen können die Repetitions- und Definitionsebenen in einer Gruppe mit ihren entsprechenden Wert (wenn der Wert instantiiert ist) gespeichert werden. Mit anderen Worten kann eine Informationssequenz in dem spaltenorientierten Streifen sich wie folgt lesen:
Wert 1:

Wiederholungsebene 1: Definitionsebene 1: Wert 2: Wiederholungsebene 2: Definitionsebene 2, und so weiter.

Die spaltenorientierten Streifen können in Informationsblöcke komprimiert werden. So kann beispielsweise jeder Spaltenstreifen in eine Reihe an Blöcken aufgeteilt werden, wobei jeder Block seinen eigenen jeweiligen Header aufweist. Ein erster Block kann die ersten 800.000 Werte und ein zweiter Block kann die zweiten 800.000 Werte von einem Streifen aus 1,6 Millionen Werten umfassen. Ein Block-Header kann die Repetitions- und Definitionsebene zusammen mit zusätzlichen Informationen beinhalten, die verwendet werden können, um beim Analysieren des Abschnittes des Spaltenstreifens, der durch den Block dargestellt wird, und beim Rekonstruieren des Spaltenstreifens zu helfen.
In einigen Beispielen beinhaltet der Block-Header einen 'Assertionswert', der einen Typ von Daten definiert, der sich in den Werten des Blocks findet. So darf beispielsweise ein Block für das 'Video.Resolution.Width'-Feld keinerlei Werte beinhalten, die eine 'Large'-Breiteauflösung auflisten. Demgemäß kann der 'Assertion'-Wert anzeigen, dass die Werte nur 'Small'- und 'Medium'-Werte beinhalten. Wird eine Abfrage für Datensätze durchgeführt, die Videos mit 'High' (hoher) Breiteauflösung beinhalten, kann der beschriebene Block von dem Abfragesystem umgangen werden.
Das in diesem Dokument beschriebene System kann Abfragen für spaltenorientierte Streifen ausführen, ohne die Informationen in den spaltenorientierten Streifen in Aufzeichnungen zu rekonstruieren, und ohne Informationen aus den spaltenorientierten Streifen in eine Datenbank zu laden. (z. B. ohne Einsatz der 'Einfügeklausel'). Demgemäß kann auf die Daten in-situ zugegriffen werden, was Einsparungen hinsichtlich der Datenberechnungsanalyse in hochstelliger Größenordnung bereitstellt.
Das Abfragesystem kann zahlreiche der für die Abfrage relationaler Datenbanken eingesetzten Klauseln benutzen. Es können jedoch auch zusätzliche Klauseln verwendet werden die für nicht-verwandte Daten spezifisch sind. So können beispielsweise mit einer WITHIN(INNERHALB)-Klausel Operationen auf mehreren Instanzen eines Feldes innerhalb eines einzelnen Datensatzes oder eines Abschnittes eines Datensatzes durchgeführt werden. Eine verwandte Datenbank ist jedoch möglicherweise nicht zum Speichern von mehr als einer einzelnen Instanz eines Feldes in einer Zeile (beispielsweise eine Darstellung eines Datensatzes) in der Lage. Demzufolge ist eine Abfrage an einer verwandten Datenbank möglicherweise im Grunde genommen zum Durchführen von Abfragen 'innerhalb' eines Datensatzes nicht in der Lage.
Als Beispiel für die WITHIN-Klausel können Werte für ein bestimmtes Feld vervielfacht werden. Es sei angenommen, dass die Abfrageanweisungen anfordern dass alle Werte für 'MutualFund.InterestRate' (Gemeinsamer Fonds-Zinssatz) für einen bestimmten Datensatz zusammen multipliziert werden (wobei jeder Datensatz für einen bestimmten Kontoinhaber sein kann). Das Abfragesystem kann alle der 'MutualFund.InterestRate'-Werte innerhalb eines einzigen Datensatzes finden und diese zusammen multiplizieren.
Ein weiteres Beispiel für eine Klausel, die sich spezifisch auf nicht-relationale geschachtelte Daten bezieht, ist die OMIT IF-Klausel. Mit dieser Klausel kann ein Datensatz gefiltert werden, um Instanzen von Feldern zu entfernen, wenn eine bestimmte Bedingung erfüllt ist (beispielsweise kann ein neuer Spaltenstreifen oder Datensatz erstellt werden, wenn spezifizierte Felder entfernt werden). Zur Illustration kann ein Streifen mit Werten abgefragt werden, der eine Liste der Mitarbeitergehälter umfasst, und ein neuer Streifen, der Mitarbeiter mit Gehältern von mehr als $ 90.000 entfernt, kann unter Einsatz der OMIT-IF-Klausel generiert werden.
Das Abfragesystem kann von einem Serversystem gehostet und mit Hilfe von Anwendungsprogrammierungsoberflächen (Application Programming Interfaces, API) über das Internet an entfernte Computergeräte geliefert werden. Im Allgemeinen können die spaltenorientierten Daten gegenüber externen Benutzern der entfernten Computergeräte innerhalb von Informationstabellen angezeigt werden. Die Benutzer können die Tabellen mit Hilfe von API-Aufrufen generieren und die Tabellen mit Daten aus einem Repository von Objekten füllen.
Die Benutzer können separate API-Aufrufe einsetzen, um Objekte in das Repository zu laden. Der Server kann zum Beispiel auch ein über das Internet zugängliches Speichersystem implementieren, das Benutzer befähigt, Daten zum Serversystem für entferntes Hosting zu treiben. Auf diese Weise kann der Datenspeicherservice als ein Repository für aus zahlreichen geographisch verteilt angesiedelten Computergeräten aggregierte Daten dienen. Die Protokolle von Websites im Internet können dem Speichersystem zum Beispiel aus hunderten von Computern zugeführt und als individuelle Objekte in einem oder mehreren „Rastern” im Repository gespeichert werden. Ein beliebiges Raster kann eine Liste der Zugriffskontrolle aufweisen, die bestimmt, welche Computergeräte oder Benutzerkonten für das Hochladen von Objekten in das Raster oder den Zugriff auf Objekte in einem Raster autorisiert sind. Auf ähnliche Weise können einzelne Objekte assoziierte Listen der Zugriffskontrolle haben, die kontrollieren, welche Geräte oder Benutzerkonten in der Lage sind, auf das Objekt zuzugreifen oder es zu manipulieren.
Ein Benutzer kann ausdrücklich verlangen, dass die Daten in Objekten in einem Raster in eine Tabelle übertragen werden oder kann einen Service einrichten, der das Raster überwacht und die in neu platzierten Objekten befindlichen Daten in die Tabelle überträgt. Bei einigen Implementierungen kann die Übertragung der in den Objekten befindlichen Daten in die Tabelle die Konversion des Datenformats der Objekte in ein anderes Format beinhalten und spaltenorientierte Streifen für die Daten in den Aufzeichnungen generieren und die spaltenorientierten Streifen in einem anderen Repository platzieren. Metadaten für die Tabelle können aktualisiert werden, um die spaltenorientierten Streifen zu referenzieren, die die konvertierten Daten für die importierten Objekte beinhalten.
Somit werden bei einigen Implementierungen, wenn der Abfrageservice eine Anforderung für die Abfrage einer Tabelle empfängt, die Metadaten für die Tabelle geortet, und die Abfrage wird für die spaltenorientierten Daten vorgenommen, die der Tabelle zugrunde liegen. Die Ausgabe der Abfrage kann in eine andere Tabelle platziert, an ein die Abfrage anforderndes entferntes Gerät geliefert oder in dem Repository der Objekte als Objekt gespeichert werden (z. B. als Objekt, das eine Sammlung von Aufzeichnungen beinhaltet).
1. EINFÜHRUNG
Eine großformatige parallele Datenverarbeitung kann unter Einsatz von Cluster aus handelsüblichen Maschinen vorgenommen werden. Siehe L. A. Barroso und U. Holzle. Das Datenzentrum als ein Computer: Eine Einführung in das Design von Maschinen der Lagerhaus-Skala. Morgan & Claypool Publishers, 2009. Ein Cluster kann eine Vielzahl von verteilten Anwendungen hosten, die Ressourcen gemeinsam nutzen, die unterschiedlichste Workloads umfassen und auf Maschinen mit unterschiedlichen Hardware-Parametern laufen. Eine einzelne Datenverarbeitungsmaschine in einer verteilten Anwendung braucht möglicherweise viel länger zum Ausführen einer jeweiligen Aufgabe als andere oder kann möglicherweise aufgrund von Störungen oder einen vorrangigen Zugriff durch ein Cluster-Verwaltungssystem die Aufgabe gar nicht erst abschließen. Daher kann der Umgang mit Nachzüglern (z. B. Datenverarbeitungsaufgaben mit bedeutender Latenz) und Ausfällen eine schnelle Realisierung und Fehlertoleranz erreichen. Siehe G. Czajkowski. Sorting 1PB with MapReduce. Official Google Blog, Nov. 2008. Auf http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html.
Die in der Web-bezogenen und wissenschaftlichen Datenverarbeitung eingesetzten Daten sind oft nicht relational. Demzufolge kann in diesen Bereichen ein flexibles Datenmodell von Vorteil sein. Datenstrukturen, die in Programmiersprachen, Mitteilungen, die durch verteilte Systeme ausgetauscht werden, Webverkehrsprotokollen usw. verwendet werden, tendieren möglicherweise ganz natürlich zu einer verschachtelten Darstellung. So kann eine verschachtelte Darstellung von Daten beispielsweise mehrere Felder beinhalten, die jeweils mehrere Ebenen von untergeordneten Feldern beinhaltet. Einige der untergeordneten Felder können entsprechende Daten beinhalten. Das Normalisieren und erneute Kombinieren solcher Daten auf einer Webskalierung kann vom Rechenaufwand her sehr kostenintensiv sein. Ein verschachteltes Datenmodell liegt einigen Bestandteilen der strukturierten Datenverarbeitung bei wichtigen Webunternehmen zugrunde.
Dieses Dokument beschreibt ein System, das die interaktive Analyse von sehr großen Datensätzen über geteilte Cluster von handelsüblichen Maschinen unterstützt. Anders als herkömmliche Datenbanken ist es in der Lage, mit verschachtelten Daten in situ zu operieren. In situ bezieht sich auf die Fähigkeit, auf Daten an 'Ort und Stelle' zuzugreifen, zum Beispiel in einem verteilten Dateisystem wie etwa das Google File System (siehe S. Ghemawat, H. Gobioff, und S. -T. Leung. The Google File System. In SOSP, 2003) oder einer anderen Speicherebene wie etwa Bigtable {siehe F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes und R. Gruber. Bigtable: A Distributed Storage System for Structured Data (Bigtable: Ein verteiltes Speichersystem für strukturierte Daten). In OSDI 2006).
Das System kann zahlreiche Abfragen zu solchen Daten ausführen, die normalerweise eine Sequenz von MapReduce-Jobs erfordern würden, dies in einem Bruchteil der Realisierungszeit. Siehe J. Dean und S. Ghemawat. MapReduce: Simplified Data Processing an Large Clusters. In OSDI, 2004. Das beschriebene System kann zusammen mit MapReduce verwendet werden, um Ausgaben von MapReduce-Pipelines zu analysieren, oder schneller Prototypen von größeren Datenberechnungen zu erstellen. Zu Verwendungsbeispielen des Systems gehören:

• Analyse von Webprotokollen und gekraulten Webdokumenten;
• Installieren von Daten für Anwendungen, die von einem Online-Marktplatz bedient werden;
• Crash-Daten für Anwendungsprodukte;
• Multimedia-Playback-Statistiken;
• OCR-Ergebnisse von Bücherscannen;
• Spamanalyse;
• Fehlerbeseitigung von gekachelten Karten;
• Tablettentfernungen in verwalteten Bigtable-Instanzen;
• Ergebnisse von Testläufen auf einem verteilten Build-System;
• Platten-E/A-Statistiken für Hunderttausende von Platten;
• Ausführungsprotokolle von MapReduce-Aufgaben über mehrere Datenzentren hinweg; und
• Symbole und Abhängigkeiten in einer Code-Basis.

Das beschrieben System gründet sich auf Ideen aus der Web-Forschung und parallele Systeme des Datenbank-Managements. Zunächst baut seine Architektur auf dem Konzept eines Bereitstellungsbaums in verteilten Suchmaschinen auf. Siehe J. Dean. Challenges in Building Large-Scale Information Retrieval Systems: Invited Talk. In WSDM, 2009. Wie bei einer Websuche-Anfrage wird eine Abfrage einen Baum hinuntergeschoben und bei jedem Schritt neu geschrieben. Das Ergebnis der Abfrage wird durch Zusammenfassen der Antworten assembliert, die von den unteren Ebenen des Baums empfangen werden.
Zweitens bietet das beschriebene System eine SQL-ähnliche, qualitativ hochwertige Sprache, um Ad-hoc-Abfragen auszudrücken. Im Gegensatz zu Ebenen wie Pig (siehe C. Olston, B. Reed, U. Srivastava, R. Kumar und A. Tomkins. Pig Latin: a Not-so-Foreign Language for Data Processing (Pig Latin: Eine nicht so fremde Sprache für die Datenverarbeitung). In SIGMOD, 2008.) und Hive (Hive. http://wiki.apache.org/hadoop/Hive, 2009), realisiert das Abfragesystem Abfragen nativ aus, ohne sie in MapReduce-Jobs zu übersetzen.
Zuletzt benutzt das beschriebene System eine Speicherdarstellung mit spaltenorientierten Streifen, die es befähigt, weniger Daten aus sekundärer Speicherung zu lesen und CPU-Kosten aufgrund einer billigeren Kompression zu reduzieren. Es wird nicht angenommen, dass Speicher für Spalten für die Analyse relationaler Daten (D. J. Abadi, P. A. Boncz und S. Harizopoulos. Column-Oriented Database Systems (Tabellenorientierte Datenbanksysteme). VLDB, 2(2), 2009) sich auf geschachtelte Datenmodelle ausgedehnt haben. Das Spaltenspeicherformat, das beschrieben wird, kann von MapReduce, Sawzall unterstützt werden (siehe R. Pike, S. Dorward, R. Griesemer, and S. Quinlan). Interpreting the Data: Parallel Analysis with Sawzall. Scientific Programming, 13(4), 2005), and FlumeJava (Wissenschaftliches Programmieren und FlumeJava) (siehe C. Chambers, A. Raniwala, F. Perry, S. Adams, R. Henry, R. Bradshaw und N. Weizenbaum. FlumeJava: Easy, Efficient Data-Parallel Pipelines (FlumeJava: Einfache, effiziente datenparallele Pipelines. In PLDI, 2010).
In Abschnitt 4 beschreibt dieses Dokument ein spaltenorientiertes Speicherformat für verschachtelte Daten. Es werden Algorithmen zum Zerlegen von verschachtelten Datensätzen in Spalten und ihr erneutes Zusammenstellen (Reassemblieren) dargestellt.
In Abschnitt 5 wird eine Abfragesprache zur Verarbeitung von Daten beschrieben, die im spaltenorientierten Speicherformat gespeichert werden. Die Abfragesprache und die Ausführung der Sprache für ein effizientes Operieren verschachtelten Daten als Spaltenstreifen ausgelegt und erfordern kein Umstrukturieren der verschachtelten Datensätze.
In Abschnitt 6 wird eine Illustration der Anwendung von Ausführungsbäumen beschrieben, die bei der Websuche zur Bedienung von Systemen zur Datenbankverarbeitung eingesetzt werden. Es werden die Vorteile für ein effizientes Beantworten von Zusammenfassungsabfragen erläutert.
In Abschnitt 7 werden Experimente präsentiert, die mit Systeminstanzen durchgeführt wurden.
ABSCHNITT 2: BEISPIELHAFTES SZENARIO
Angenommen, dass Alice, eine Ingenieurin bei einem Websuche-Unternehmen, sich eine Idee für die Extraktion neuer Arten von Signalen aus Webseiten einfallen lässt. Sie führt eine MapReduce-Aufgabe aus, die sich durch die Eingabedaten zieht, die Inhalt von den Webseiten beinhalten und produziert einen Datensatz, der neue Signale beinhaltet, die in Milliarden von Datensätzen in einem verteilten Dateisystem gespeichert werden. Um die Ergebnisse ihres Experimentes zu analysieren, startet sie das in diesem Dokument beschriebene System und führt mehrere interaktive Befehle aus:
DEFINE TABLE t AS /path/to/data/*
SELECT TOP (signal1, 100), COUNT(*) FROM t
Die Befehle von Alice werden in Sekundenschnelle realisiert. Sie führt einige andere Abfragen durch, um sich selbst zu überzeugen, dass ihr Algorithmus funktioniert. Sie findet eine Unregelmäßigkeit in Signal 1 und forscht nach, indem sie ein FlumeJava-Programm schreibt, das eine komplexere analytische Berechnung für ihren Ausgabedatensatz vornimmt. Sobald das Problem behoben ist, richtet sie eine Pipeline ein, die die eingehenden Daten fortlaufend bearbeitet. Sie formuliert einige gekapselte SQL-Abfragen, die die Ergebnisse ihrer Pipeline über verschiedene Dimensionen zusammenfasst und fügt diese einem interaktiven Dashbord (beispielsweise einer Webseite über einen Dienst, der den Dienst erklärt und Einzelheiten zu Statistiken zu dem Dienst anführt) hinzu. Schließlich registriert sie ihren neuen Datensatz in einem Katalog, so dass andere Techniker den Datensatz schnell finden und auf ihn zugreifen können.
Das obige Szenarium kann eine Interoperation zwischen dem Abfrageprozessor und anderen Instrumenten des Datenmanagements erfordern. Der erste bildende Bestandteil einer solchen Interoperation ist eine gemeinsame Speicherschicht. Das Google File System ist eine solche verteilte Speicherschicht, die verwendet werden kann. Das Google File System verwaltet große replizierte Datensätze über Tausende von Maschinen und Zehntausende von Platten.
Reproduktion hilft bei der Erhaltung der Daten trotz fehlerhafter Hardware und bei der Erzielung schneller Reaktionszeiten beim Vorhandensein von Nachzüglern. Eine hochleistungsfähige geteilte Speicherebene ist ein zentraler Befähigungsfaktor für das Datenmanagement in situ. Es ermöglicht das Zugreifen auf Daten ohne eine zeitaufwändige Phase des Ladens, das ein großes Hindernis für die Verwendung von Datenbanken für die analytische Datenverarbeitung ist (wo oftmals möglicherweise Dutzende von MapReduce-Analysen ausgeführt werden, bevor ein Datenbankverwaltungssystem die Daten laden und (auch nur) eine einzige Abfrage ausführen kann). Wenn zum Beispiel ein Datenmanagementsystem zur Analyse von Daten eingesetzt wird, kann es sein, dass die Datenbank unter Einsatz von 'Einfügebefehlen' geladen werden muss. Solch ein Laden wird möglicherweise von dem beschriebenen System nicht benötigt. Als weiterer Vorteil können Daten in einem Dateisystem praktischerweise unter Verwendung von Standardtools, beispielsweise zum Übertragen an ein anderes Cluster, Ändern von Zugriffsprivilegien oder Identifizieren einer Teilmenge von Daten zur Analyse auf der Grundlage von Dateinamen manipuliert werden.
Ein zweites Element für die Schaffung interoperabler Datenmanagementkomponenten ist ein geteiltes Speicherformat. Es wird ein Spaltenspeicher für flache verwandte Daten verwendet, durch ein Anpassen des Spaltenspeichers an ein verschachteltes Datenmodell, kann das Verfahren jedoch auf Webdaten angewendet werden. 1 veranschaulicht die Idee, dass alle Werte eines verschachtelten Feldes in einer Datenstruktur zusammenhängend gespeichert werden. So werden beispielsweise bei der an Spalten ausgerichteten Darstellung verschachtelter Daten alle Werte für ein bestimmtes verschachteltes Feld innerhalb einer Datenstruktur (beispielsweise das Feld A.B.-C) aneinander angrenzend und im Speicher zusammenhängend gespeichert. Demzufolge können Werte für das Feld A.B.C aus dem Speicher abgerufen werden, ohne dass die Werte von dem Feld A.E und Werte von dem Feld A.B.D gelesen werden.
Darüber hinaus können Werte für dasselbe spezifische Feld in verschiedenen Instanzen einer Datenstruktur (z. B. einer 'Aufzeichnung') zusammenhängend gespeichert werden. So werden beispielsweise die Werte für das Feld A.B.C für den Datensatz 'r1' angrenzend an die Werte für dasselbe Feld für den Datensatz 'r2' gespeichert. Im Gegensatz dazu werden in der 'datensatzorientierten' Darstellung verschachtelter Daten Werte für alle Felder innerhalb eines bestimmten Datensatzes zusammenhängend gespeichert. Mit anderen Worten werden Datenwerte für ein bestimmtes Feld nicht zusammengelegt.
Die Herausforderung, der das beschriebene spaltenorientierte Speicherformat begegnet, besteht in der Bewahrung aller strukturellen Informationen und der Fähigkeit, Aufzeichnungen aus einem arbiträren Teilsatz von Feldern zu rekonstruieren. Dieses Dokument beschreibt das Datenmodell, anhand dem die Felder in dem Spaltenspeicherformat gefüllt werden können und sich dann Algorithmen zum Bearbeiten der Spaltenspeicher und zur Abfragebearbeitung an Daten in dem Spaltenspeicher zugewendet werden kann.
ABSCHNITT 3: DATENMODELL
Dieser Abschnitt beschreibt das von dem beschriebenen System eingesetzte Datenmodell und stellt einen Teil der später benutzten Terminologie vor. Das beschriebene Protocol-Buffer-Datenmodell hat seinen Ursprung im Kontext von verteilten Systemen und ist als eine Open-Source-Implementierung verfügbar. Siehe (Protocol Buffers: Developer Guide. Available at http://code.google.com/apis/protocolbuffers/docs/overview.html). Das Datenmodell basiert auf stark typisierten verschachtelten Datensätzen. Seine abstrakte Syntax wird bereitgestellt durch:
τ = dom | < A₁ : τ[*|?], ..., A_n : τ[*|?] >
wo x ein atomarer Typ oder ein Aufzeichnungstyp ist. Atomare Typen in DOM umfassen Integerzahlen, Gleitkommazahlen, Strings, etc. Der Datensatz besteht aus einem oder mehreren Feldern. Ein Feld i in einer Aufzeichnung hat einen Namen A_i und eine optionale Vielfältigkeitskennzeichnung. Wiederholte Felder (*) können mehrere Male in einem Datensatz vorkommen. Sie werden als Listen von Werten interpretiert, das heißt, die Reihenfolge des Vorkommens von Feldern in einem Datensatz ist von wichtiger Bedeutung. Optionale Felder (?) können in dem Datensatz fehlen. Anderenfalls ist ein Feld erforderlich (muss beispielsweise genau ein Mal vorkommen).
Als Illustration zeigt 2 ein Schema, das ein aufzeichnungstypisches Dokument' definiert, welches ein Web-Dokument darstellt. Die Schemadefinition verwendet die Protocol-Buffer-Syntax. Ein 'Dokument' hat eine erforderliche Ganzzahl 'Docld' und optionale 'Links,' die eine Liste an 'Forward'(Vorwärts)- und 'Backward'(Rückwärts)-Einträgen beinhalten, die 'Doclds' anderer Webseiten halten. Ein 'Document' kann mehrere 'Names' haben, bei denen es sich um verschiedene URLs handelt, über die das Dokument referenziert werden kann. Ein 'Name' beinhaltet eine Folge aus 'Code'- und (optionalen) 'Country'-Paaren. 2 zeigt ferner zwei musterhafte Datensätze r1 und r2, die dem Schema entsprechen. Die Datensatzstruktur wird unter Verwendung von Einrückung umrissen. Die musterhaften Datensätze r1 und r2 in 2 werden zum Beschreiben der Algorithmen im Verlauf dieses Dokumentes verwendet. Die in dem Schema definierten Felder bilden eine Baumhierarchie. Der vollständige Pfad eines verschachtelten Datenfeldes wird unter Verwendung einer gestrichelte Anmerkung bezeichnet. So ist beispielsweise Name.Language.Code der vollständige Pfadname für das in 2 dargestellte 'Code'-Feld.
Das Modell der verschachtelten Daten stützt einen plattformneutralen, erweiterungsfähigen Mechanismus zur Serialisierung von strukturierten Daten. Tools zum Erstellen von Codes erzeugen Bindungen für unterschiedliche Programmiersprachen wie etwa C++ oder Java. Eine sprachübergreifende Interoperabilität wird unter Einsatz einer standardmäßigen binären On-the-Wire-Darstellung von Aufzeichnungen erreicht, worin Feldwerte sequentiell so dargelegt werden, wie sie in der Aufzeichnung erscheinen. Auf diese Weise kann ein MapReduce-Programm, das in Java geschrieben ist, Datensätze von einer Datenquelle konsumieren, die über eine C++-Bibliothek zugänglich ist. Demzufolge kann, wenn Datensätze in einer Spaltendarstellung gespeichert werden, ihr schnelles Zusammenstellen die Interoperation mit MapReduce und anderen Datenverarbeitungs-Tools unterstützen.
ABSCHNITT 4: VERSCHACHTELTE SPALTENSPEICHER
Wie in 1 illustriert, besteht ein Ziel in der konsekutiven Speicherung aller Werte eines beliebigen Feldes in der Verbesserung der Abrufwirksamkeit. Dieser Abschnitt widmet sich den Herausforderungen hinsichtlich einer verlustfreien Darstellung von Datensatzstruktur in einem Spaltenformat (Abschnitt 4.1), Fast Encoding (schnelles Codieren) (Abschnitt 4.2) und effizientem Assemblieren von Datensätzen (Abschnitt 4.3).
ABSCHNITT 4.1: REPETITIONS- UND DEFINITIONSEBENEN
Eine konsekutive Liste von Werten allein vermittelt die Struktur einer Aufzeichnung nicht. Bei zwei beliebigen Werten eines in einer Aufzeichnung wiederholten Feldes kann es sein, dass ein System nicht fähig ist festzustellen, auf welcher Ebene der Wert wiederholt wird (z. B. ob die beiden Werte aus verschiedenen Aufzeichnungen oder aus derselben Aufzeichnung stammen). Auf gleiche Weise geben, wenn ein optionales Feld aus einem Datensatz fehlt, Werte allein nicht bekannt, welche einschließenden Datensätze explizit definiert wurden und welche nicht. Demgemäß werden die Konzepte von Repetitions- und Definitionsebenen vorgestellt. 3 umfasst Tabellen, die die Repetitions- und Definitionsebenen für atomische Felder in denselben Datensätzen zusammenfassen, die in 1 dargestellt sind.
Wiederholungsebenen. Betrachtet werden soll das Feld 'Code' in 2. Es kommt im Datensatz 'r1' dreimal vor. Vorkommen von 'en-us' und 'en' liegen innerhalb des ersten 'Name'-Feldes während 'en-gb' im dritten 'Name'-Feld vorhanden ist. Um diese Vorkommen in der Spaltenstruktur zu disambiguieren, wird jedem Wert eine Repetitionsebene angehängt, die in der Spaltenstruktur gespeichert werden soll. Die Wiederholungsebene zeigt an, bei welchem wiederholten Feld im Pfad des Feldes der Wert wiederholt wurde. Der Pfad des Feldes Name.Sprache.Code umfasst zum Beispiel zwei Felder, die wiederholt werden, 'Name' und 'Sprache'. Daher reicht die Wiederholungsebene des Code von 0 bis 2. Ebene 0 bezeichnet den Beginn einer neuen Aufzeichnung, Ebene 1 bezeichnet eine kürzliche Wiederholung im Feld 'Name', und Ebene 2 bezeichnet eine kürzliche Wiederholung im Feld 'Sprache'.
Als Illustration für die Bestimmung der Eben für ein Feld kann Aufzeichnung 'r1' von oben nach unten gescannt werden. Der Wert 'en-us' kommt zuerst vor, und es kann eine Prüfung durchgeführt werden, um das Feld in dem Pfad Name.Language.Code zu identifizieren, das am aktuellsten in dem Datensatz wiederholt wurde. In diesem Beispiel wurde keines der Felder wiederholt, und demzufolge ist die Repetitionsebene 0. Der Wert 'en' wird als nächstes für den Pfad Name.Sprache.Code angetroffen, und das Feld 'Sprache' wird als das Feld identifiziert, das kürzlich wiederholt wurde. Beim Aufwärtsscannen ab dem Wert 'en' zum Beispiel ist das erste sich im Pfad von Name.Sprache.Code wiederholende Feld 'Sprache'. Somit ist die Wiederholungsebene 2 (z. B. weil '2' mit dem Feld 'Sprache' korrespondiert, da 'Sprache' das zweite Feld in dem sich wiederholenden Pfad Name.Sprache.Code ist). Zuletzt, wenn der Wert 'en-gb' angetroffen wird, hat sich das Feld 'Name' kürzlich als letztes wiederholt (das Feld 'Sprache'' trat nur einmal nach dem Namen auf), so dass die Wiederholungsebene 1 ist. Mit anderen Worten kann die Repetitionsebene für einen Wert eine Zahl sein, die ein am aktuellsten wiederholtes Feld darstellt. Demzufolge sind die Repetitionsebenen von Codewerten in dem Datensatz 'r1' 0, 2, 1.
Man beachte, dass das zweite Feld 'Name' in Aufzeichnung '1' keine Werte für das Feld 'Code' enthält. Um festzustellen, dass 'en-gb' als Wert für ein Feld auftritt, das in der dritten Instanz des Feldes 'Name' verschachtelt ist und nicht in der zweiten Instanz, wird ein NULL-Wert zwischen den Werten 'en' und 'en-gb' hinzugefügt, während sie in der spaltenorientierten Struktur gespeichert werden (siehe 3). 'Code' ist ein erforderliches Ablegerfeld des Feldes 'Sprache', so dass die Tatsache, dass ein Wert für das Feld 'Code' fehlt, impliziert, dass das Feld 'Sprache' ebenfalls nicht auch nicht definiert ist. Im Allgemeinen kann das Bestimmen der Ebene, bis auf die, auf der verschachtelte Datensätze vorhanden sind, zusätzliche Informationen erfordern.
Definitionsebenen. Jeder Wert eines Feldes mit Pfad 'p', und vor allem jeder NULL-Wert, hat eine 'Definitionsebene', die spezifiziert, wie viele Felder in dem Pfad 'p', die nicht definiert sein könnten (z. B. weil die Felder optional oder wiederholt sind), tatsächlich in der Aufzeichnung vorhanden sind. Um dies zu veranschaulichen, sei zu beachten, dass der Datensatz 'r1' keine Felder 'Backward' für das Feld 'Links' aufweist. Dennoch ist das Feld 'Links' definiert (auf einer Ebene von 1). Um diese Informationen zu bewahren, wird ein NULL-Wert mit der Definitionsebene 1 der Spalte 'Links.Zurück' hinzugefügt.
Mit anderen Worten zeigt die Spezifizierung einer Ebene von 1 für den Pfad 'Links.Zurück', dass Feld '1', das optional oder wiederholt war (d. h. das Feld 'Links') in einem Pfad definiert war, der zwei Felder umfasst, die optional oder wiederholt sind (d. h. das Feld 'Links' und das Feld 'Zurück'). Demzufolge zeigt eine Definition von '1' an, dass das Feld 'Backward' nicht instantiiert war. Auf ähnliche Weise trägt das fehlende Auftreten von 'Name.Sprache.Land' in Aufzeichnung 'r2' eine Definitionsebene 1, während seine fehlenden Vorkommen in Aufzeichnung Y1' jeweils Definitionsebenen von 2 (innerhalb von 'Name.Sprache') und 1 (innerhalb von 'Name') haben. Das vorstehend umrissene Codierverfahren kann die Datensatzstruktur verlustfrei bewahren.
Codierung. Eine Spalte entspricht in ihrer in dem Speicher gespeicherten Form, einem bestimmten Feld, das mit einem Header gespeichert werden kann, der eine zusammenhängende Auflistung von Repetition- und Definitionswerten, gefolgt von einer zusammenhängenden Auflistung der substantiellen Werte beinhaltet. Jeder Sättigungs- und Definitionswert kann als eine Bitfolge (beispielsweise in einem einzelnen Byte) gespeichert sein. So können beispielsweise die ersten vier Bits eines Bytes zum Darstellen der Repetitionsebene für einen bestimmten und die letzten vier Bits zum Darstellen der Definitionsebene verwendet werden. Bei einigen Beispielen kann der Header Definitionen von Längen der Zahl an Bits beinhalten, so dass Begrenzer verwendet werden können. Auf diese Weise können Bits, nur wenn sie notwendig sind, verwendet werden. Beträgt die maximale Definitionsebene beispielsweise 3, können zwei Bits pro Definitionsebene verwendet werden.
Daher kann eine Darstellung von spaltenorientierten Daten für ein einzelnes Feld (z. B. das Feld 'Name.Sprache.Code') im Speicher mit einer Sequenz von Bytes gespeichert sein, welche die Wiederholungs- und Definitionsebenen für eine korrespondierende Sequenz von Werten repräsentieren, gefolgt von einer Sequenz von Werten. NULL-Werte können jedoch nicht explizit gespeichert werden, da sie durch Analysieren der Definitionsebenen bestimmt werden können. Jede Definitionsebene zum Beispiel, die niedriger als die Anzahl der wiederholten und optionalen Felder im Pfad eines Feldes ist, kann eine NULL anzeigen. Demzufolge kann ein System in der Lage sein zu bestimmen, wo in einer Auflistung aufeinanderfolgender Werte ein NULL-Wert eingefügt oder inferiert werden sollte. In einigen Beispielen werden Definitionsebenen nicht für Werte gespeichert, die immer und stets definiert sind. Auf ähnliche Weise können Repetitionsebenen nur gespeichert werden, wenn sie erforderlich sind. So impliziert etwa eine Definitionsebene von 0 eine Repetitionsebene von 0, dementsprechend kann die Letztgenannte weggelassen werden. In der Tat können durch Verweisen auf die in 3 veranschaulichten Strukturen keine Ebenen für das Feld 'Docld' gespeichert werden.
Eine Darstellung von spaltenorientierten Daten im Speicher kann in einen Satz von Blöcken zerlegt werden. Jeder Block kann einen Header beinhalten, der die Informationen zu den Repetitions- und Definitionsebenen und eine sich anschließende Auflistung der Werte für das Feld beinhaltet. Jeder Header kann einen 'constraint'-(Zwangsbedingungs-)Wert beinhalten, der einen zulässigen Wertebereich in dem Block anzeigt. Auf diese Weise kann das beschriebene System Identifizieren, welche Blöcke Daten beinhalten, an denen das System interessiert ist. Die Zwangsbedingung kann auch andere Eigenschaften der Werte, so etwa, ob die Werte sortiert worden sind, anzeigen. Im Allgemeinen kann man sich das 'constraint' als eine 'assertion' (Zurechnung) darüber, welche Art von Werten in dem Block gefunden werden, vorstellen. Jeder Block kann komprimiert werden.
ABSCHNITT 4.2 ZERLEGEN VON DATENSATZEN IN SPALTEN
Die obige Beschreibung präsentierte die Codierung der Aufzeichnungsstruktur in einem spaltenorientierten Format. Eine Herausforderung besteht nun darin, Spaltenstreifen mit Repetitions- und Definitionsebenen effizient zu produzieren. Der grundlegende Algorithmus zum Berechnen von Repetitions- und Definitionsebenen wird nachstehend bereitgestellt. Der Algorithmus kehrt in die Datenstruktur wieder und berechnet die Ebenen für jeden Feldwert. Wie weiter oben veranschaulicht, müssen die Repetitions- und Definitionsebenen möglicherweise selbst, wenn die Feldwerte fehlen, berechnet werden. Viele Datensätze sind dünn besetzt, und es ist möglicherweise nicht unüblich, ein Schema mit Tausenden von Feldern zu haben, von denen nur Einhundert in einem jeweiligen Datensatz verwendet werden. Demzufolge ist es möglicherweise von Vorteil, fehlende Felder so kostengünstig wie möglich zu bearbeiten. Um Spaltenstreifen zu erzeugen, wird ein Baum aus Feld-Schreibelementen erstellt, dessen Struktur mit der Feldhierarchie in dem Schema übereinstimmt. Die grundlegende Idee besteht darin, Feld-Schreibelemente nur dann zu aktualisieren, wenn sie ihre eigenen Daten umfassen, und nicht zu versuchen, den übergeordneten Zustand nach unten im Baum weiterzugeben, es sei denn, dies ist absolut erforderlich. Um dies zu tun, bekommen untergeordnete Schreibelemente die Ebenen von ihren übergeordneten Elementen übertragen. Ein Ableger-Autor synchronisiert sich mit seinen Elternteilen, warm immer ein neuer Wert hinzugefügt wird.
Ein musterhafter Algorithmus für die Zerlegung einer Aufzeichnung in Spalten wird in 4 gezeigt. Das Verfahren 'DissectRecord' leitet die Instanz eines 'RecordDecoder' weiter, eingesetzt zur Überquerung binär codierter Aufzeichnungen. 'FieldWriters' bilden eine Baumhierarchie, die gegenüber dem Eingabeschema isomorph ist. Die Wurzel 'FieldWriter' wird für jede neue Aufzeichnung an den Algorithmus geleitet, wobei 'repetitionLevel' auf 0 eingestellt ist. Die vorrangige Aufgabe der Vorgehensweise 'DissectRecord' besteht im Beibehalten der aktuellen 'Repetitionsebene'. Die gegenwärtige 'repetitionLevel' wird durch die Baumposition des gegenwärtigen Autors eindeutig bestimmt als die Summe der Anzahl optionaler und wiederholter Felder im Pfad des Feldes.
Die While-Schleife des Algorithmus (Zeile 5) iteriert über alle atomaren und aufzeichnungsbewerteten Felder, die in einer beliebigen Aufzeichnung enthalten sind. Der Satz 'seenFields' verfolgt mit, ob ein Feld in der Aufzeichnung gesehen wurde oder nicht. Es wird verwendet, um zu bestimmen, welches Feld am aktuellsten wiederholt wurde. Die Ableger-Wiederholungsebene 'chRepetitionLevel' ist auf diejenige des kürzlich zuletzt wiederholten Feldes eingestellt oder kehrt ansonsten zu der voreingestellten Ebene der betreffenden Elternteile zurück (Zeilen 9–13). Die Vorgehensweise wird rekursiv an verschachtelten Datensätzen aufgerufen (Linie 18).
Das obige, als 'FieldWriters' referenzierte Dokument kumuliert Ebenen und verbreitet sie gemächlich an Autoren niedriger Ebenen. Dies kann von jedem Nicht-Leaf-Schreibelement durchgeführt werden, das eine Folge von (Repetitions-, Definitions-)Ebenen) hält. Jeder Autor hat zudem eine mit ihm assoziierte 'Versionsnummer'. Einfach ausgedrückt wird eine Schreibelement-Version immer dann um Eins erhöht, wenn eine Ebene hinzugefügt wird. Es reicht für Ableger, sich an die letzte Elternteil-Version zu erinnern, die sie synchronisiert haben. Wenn ein untergeordnetes Schreibelement seinen eigenen (Nicht-Null) Wert erhält, synchronisiert es seinen Zustand mit dem übergeordneten Element, indem es neue Ebenen abruft und fügt anschließend nur die neuen Daten hinzu.
Weil Eingabedaten tausende von Feldern und Millionen von Aufzeichnungen haben können, kann es sein, dass es nicht machbar ist, alle Ebenen im Speicher zu speichern. Einige Ebenen können vorrübergehend in einer Datei oder auf einer Platte gespeichert werden. Für ein verlustfreies Codieren von leeren (Teil-)Datensätzen, benötigen nicht-atomische Felder (wie etwa Name.Sprache in 2) möglicherweise selbst Spaltenstreifen, die nur Ebenen jedoch keine Nicht-NULL-Werte umfassen.
ABSCHNITT 4.3: ASSEMBLIERUNG DES DATENSATZES
Die effiziente Zusammenstellung von Aufzeichnungen (z. B. Aufzeichnungen 'r1' und 'r2') aus spaltenorientierten Daten ist für aufzeichnungsorientierte Datenverarbeitungsinstrumente von kritischer Bedeutung (z. B. MapReduce). Für einen beliebigen Teilsatz von Feldern besteht ein Ziel darin, die ursprünglichen Aufzeichnungen zu rekonstruieren, als ob sie nur die ausgewählten Felder enthielten und alle anderen Felder weggenommen wären. Die Schlüsselidee besteht darin, eine finite Zustandsmaschine (FSM) zu erstellen, die die Feldwerte und Ebenen für jedes Feld liest und die Werte sequenziell an die ausgegebenen Datensätze anhängt. Eine FSM entspricht einen Feld-Leseelement für jedes ausgewählte Feld. Zustandsübergänge werden mit Repetitionsebenen gekennzeichnet. Sobald ein Leseelement einen Wert abruft, wird die nächste Repetitionsebene betrachtet, um zu entscheiden, welches nächste Leseelement zu verwenden ist. Die FSM wird für jeden Datensatz vom Anfang- bis zum Endzustand durchlaufen.
5 zeigt eine endliche Zustandsmaschine (finite state machine, FSM), welche die gesamten Aufzeichnungen in unserem laufenden Beispiel rekonstruiert und die in Abschnitt 4.1 beschriebenen Blocks als Eingabe benutzt. In diesem Beispiel werden die Knoten mit Feldern gekennzeichnet und die Kanten werden mit Repetitionsebenen gekennzeichnet. Der Ausgangszustand ist 'Docld'. Sobald ein 'Docld'-Wert gelesen wird, geht die FSM auf den Status 'Links.Zurück' über. Nachdem alle wiederholten Zurück'-Werte abgezogen wurden, springt die FSM zu 'Links.Vorwärts' über etc.
Um zu umreißen, wie FSM-Übergänge konstruiert werden, nehmen wir an, dass '1' die nächste Wiederholungsebene ist, die durch den gegenwärtigen Field Reader für das Feld 'f' wiederhergestellt wird. Beginnend bei 'f' im Schemabaum (z. B. dem Schema in 2) wird sein Vorgänger gefunden, der sich auf Ebene '1' wiederholt und das erste Blatt-Feld 'n' innerhalb dieses Vorgängers wählt. Das liefert einen FSM-Übergang ('f'; '1') → n. Nehmen wir z. B. an, dass '1' = 1 die nächste, von 'f' = 'Name.Sprache.Land' gelesene Wiederholungsebene ist. Der Vorgänger auf Wiederholungsebene '1' ist Name, und dessen erstes Blatt-Feld ist 'n' = 'Name.Url.'
Wenn nur ein Teilsatz von Feldern wiederhergestellt werden muss, kann eine einfachere FSM konstruiert werden, die kostengünstiger umzusetzen ist. 6 zeigt eine FSM zum Ablesen der Felder (Docld and 'Name.Language.Country'. Die Figur zeigt die Ausgabeaufzeichnungen 's1' und 's2', die von dem Automaten produziert wurden. Es ist zu beachten, dass die Codierung und der Sammelalgorithmus die umschließende Struktur des Feldes 'Land' bewahren. Dies kann für Anwendungen wichtig sein, die beispielsweise auf ”Country” zugreifen müssen, das im ersten ”Language” des zweiten ”Name” erscheint. Im Xpath kann diese mit der Fähigkeit korrespondieren, Expressionen zu bewerten wie etwa /Name[2]/Sprache[1]/Land.
Konstruktion FSM-Verfahren. 7 zeigt einen Algorithmus zum Konstruieren einer endlichen Zustandsmaschine, die eine Datensatzzusammenstellung durchführt. Der Algorithmus nimmt als Eingabe die Felder, die in den Datensätzen belegt werden sollen, in der Reihenfolge, in der sie in dem Schema erscheinen. Der Algorithmus benutzt das Konzept einer 'gemeinsamen Wiederholungsebene' von zwei Feldern, welche die Wiederholungsebene ihres niedrigsten gemeinsame Vorgängers ist. So entspricht beispielsweise die gemeinsame Repetitionsebene von 'Links.Backward' und 'Links.Forward' 1. Das zweite Konzept ist das einer 'Barriere', welche das nächste Feld in der Sequenz nach dem gegenwärtigen ist. Es wird angenommen, dass versucht wird, jedes Feld nacheinander so lange zu bearbeiten, bis die Grenze erreicht ist, und ein Sprung auf ein vorher gesehenes Feld erforderlich wird.
Der Algorithmus besteht aus drei Schritten. In Schritt 1 (Zeilen 6–10) werden die gemeinsamen Repetitionsebenen rückwärts bearbeitet. Diese sind garantiert nicht-ansteigend. Für jede angetroffene Wiederholungsebene wird das am weitesten links befindliche Feld in der Sequenz gewählt – das ist das Feld, auf das übergegangen wird, wenn diese Wiederholungsebene von einem 'FieldReader' wiederhergestellt wird. In Schritt 2 werden die Lücken gefüllt (Zeilen 11–14). Die Lücken entstehen, weil nicht alle Repetitionsebenen in den gemeinsamen Repetitionsebenen vorhanden sind, die in Zeile 8 berechnet wurden. In Schritt 3 (Zeilen 15–17) werden Übergänge für alle Ebenen eingestellt, die der Grenzebene entsprechen oder darunter liegen, an der zu dem Grenzfeld zu springen ist. Wenn ein 'FieldReader' eine solche Ebene produziert, kann die verschachtelte Aufzeichnung weiter konstruiert werden, und es kann unnötig sein, von der Barriere abzuprallen.
Assemblierung Aufzeichnungsverfahren. Eine Vorgehensweise zum Assemblieren eines Datensatzes (veranschaulicht in 8) nimmt als Eingabe eine Reihe von 'FieldReaders', und die FSM schafft (implizit) Zustandsübergänge zwischen den Leseelementen. Mit anderen Worten arbeitet der Algorithmus an der FSM und den Spaltendaten und gibt konstruierte Datensätze aus. Der Variable Reader hält den gegenwärtigen 'FieldReader' in der hauptsächlichen Routine (Zeile 4). Das Variable Leseelement hält die letzten zwei Leseelemente, deren Wert an den Datensatz angehängt ist und allen drei in 7 dargestellten Vorgehensweisen verfügbar ist. Die Haupt-”Obgleich-Schleife” ist in Zeile 5 dargestellt. Der nächste Wert wird von dem aktuellen Leseelement abgerufen. Wenn der Wert nicht NULL ist, was durch Betrachtung seiner Definitionsebene bestimmt wird, wird der Datensatz, der assembliert wird, auf die Datensatzstruktur des aktuellen Leseelementes in dem Verfahren 'MoveToLevel' (Gehe zu Ebene) synchronisiert, und der Feldwert wird an den Datensatz angehängt. Anderenfalls kann die Datensatzstruktur ohne Anhängen irgendeines Wertes angepasst werden, was bei Vorhandensein von leeren Datensätzen durchgeführt werden kann. In Zeile 12 wird eine 'vollständige Definitionsebene' eingesetzt. Es sei zu erinnern, dass die Definitionsebene erforderliche Felder ausklammert (nur wiederholte und optionales Felder werden gezählt). ”Full definition level” berücksichtigt alle Felder.
Das Verfahren 'MoveToLevel' überführt die Aufzeichnung vom Status 'lastReader' zu dem von 'nextReader' (siehe Zeile 22). So sei beispielsweise angenommen, dass der 'lastReader' den 'Links' entspricht. Zurück' in 2 und 'nextReader' ist 'Name.Sprache.Code'. Das Verfahren beendet den verschachtelten Datensatz Links und beginnt neue Datensätze ”Name” und ”Language”, in dieser Reihenfolge. Das Verfahren 'ReturnsToLevel' (Zeile 30) ist ein Gegenstück von 'MoveToLevel', das nur die gegenwärtigen Aufzeichnungen beendet, ohne neue zu beginnen.
In ihrer On-the-Wire-Darstellung sind die Aufzeichnungen als Paare eines Feldidentifikators dargelegt, gefolgt von einem Feldwert. Verschachtelte Aufzeichnungen können so betrachtet werden, als hätten sie einen 'öffnenden Tag' und einen 'schließenden Tag', ähnlich wie XML (die eigentliche binäre Codierung kann anders aussehen).
Eine Beschreibung für den Start' einer Aufzeichnung bezieht sich auf das Schreiben von öffnenden Tags, während eine Aufzeichnung 'beenden' sich auf das Schreiben von schließenden Tags bezieht.
ABSCHNITT 5: ABFRAGESPRACHE
Das beschriebene System kann eine Abfragesprache einsetzen, die sich auf SQL gründet und darauf ausgerichtet ist, effizient für spaltenorientiert verschachtelte Speicherung implementierbar zu sein. Hierin werden Aspekte der Abfragesprache beschrieben. Jede SQL-ähnliche Aussage (und algebraische Operators, in die sie übersetzbar ist) nimmt als Eingabe eine oder mehrere verschachtelte Tabellen (beispielsweise eine Reihe von komprimierten Blöcken an Spaltendaten, die eine Tabelle darstellen, wie in Abschnitt 4.1 beschrieben) und ihre Schemata, und erzeugt eine verschachtelte Tabelle (beispielsweise eine modifizierte Instanz der Spaltendaten) und ihr ausgegebenes Schema. 9 stellt eine musterhafte Abfrage dar, die Projektion, Auswahl und Aggregation (Zusammenfassung) innerhalb des Datensatzes durchführt. Die Abfrage wird über der Tabelle t = {r1, r2} aus 2 evaluiert. Die Felder werden unter Verwendung von Pfadausdrücken referenziert. Die Abfrage erzeugt ein verschachteltes Ergebnis, obgleich keine Datensatzkonstruktoren in der Abfrage vorhanden sind.
Zur Erklärung dessen, was die Abfrage tut, betrachtet man die Auswahloperation (die WHERE-Klausel). Ein verschachtelter Datensatz sollte sich als ein gekennzeichneter Baum vorgestellt werden, bei dem jede Kennzeichnung einem Feldnamen entspricht. Der Auswahl-Operator schneidet die Äste des Baumes weg, die die spezifizierten Bedingungen nicht erfüllen. Auf diese Weise werden nur jene verschachtelten Datensätze erhalten, bei denen 'Name.Url' definiert ist und mit 'http' beginnt. Als Nächstes sei die Projektion betrachtet. Jeder skalare Ausdruck in der SELECT-(AUSWAHL)Klausel emittiert einen Wert auf derselben Verschachtelungsebene wie das am aktuellsten wiederholte Eingabefeld, das in diesem Ausdruck verwendet wird. Somit emittiert die String-Konzentration 'Str'-Werte auf der Ebene von 'Name.Sprache.Code' im Eingabeschema.
Die COUNT-Expression illustriert die Aggregation innerhalb der Aufzeichnung. Die Aggregation erfolgt WITHIN (innerhalb) jeder 'Name'-Subaufzeichnung und emittiert die Anzahl der Vorkommen von 'Name.Sprache.Code' für jedes Vorkommen von 'Name' als eine nicht-negative 64-Bit-Integerzahl (Einheit 64). Demgemäß ermöglicht die INNERHALB-Aussage eine Aggregation innerhalb der Zeilen. Mit anderen Worten können Datensätze desselben Namens in einem gleichen Datensatz oder unter einem gleichen untergeordneten Datensatz aggregiert werden. Im Gegensatz dazu ist SQL, das möglicherweise nicht zum Arbeiten an verschachtelten Daten in der Lage ist, nicht in der Lage, an Datensätzen innerhalb der Zeilen zu arbeiten.
Die Sprache unterstützt verschachtelte Unterabfragen, Aggregation zwischen und innerhalb von Aufzeichnungen, Top-k, Verknüpfungen, benutzerdefinierte Funktionen etc. Einige dieser Merkmale werden im Abschnitt der experimentellen Daten besprochen. Als zusätzliches Beispiel beinhaltet die beschriebene Abfragesprache eine OMIT IF-(WEGLASSEN, WENN)Aussage, mit der eine Gruppe von Werten innerhalb einer Zeile gefiltert werden kann. Jedes Tausend von Aufzeichnungen kann zum Beispiel mehrere wiederholte Felder für 'Kosten' beinhalten, von denen jedes einen numerischen Wert enthält. Der Benutzer der Abfragesprache kann wünschen, alle Aufzeichnungen zu entfernen, in denen die Summe der Werte in den Feldern die Zahl '20' übersteigt. Somit kann der Benutzer eine OMIT IF-Aussage zur Generierung einer Liste der Aufzeichnungen einsetzen, wo die summierten 'Kosten' in jeder Aufzeichnung zwanzig oder weniger betragen.
ABSCHNITT 6: ABFRAGEAUSFÜHRUNG
Baumarchitektur. Das beschriebene System verwendet einen Multilevel-Bereitstellungsbaum zum Ausführen von Abfragen (siehe 10). Ein Root-Server empfangt eingehende Abfragen, liest Metadaten aus Tabellen und leitet die Abfragen an die nächste Ebene in dem Bereitstellungsbaum weiter. Die Leaf-Server kommunizieren mit der Speicherschicht oder greifen auf einer lokalen Platte auf die Daten zu. Viele der Abfragen, die in dem beschriebenen System operieren, sind ”Single-Scan”-Aggregationen; demzufolge konzentriert sich dieses Dokument auf das Beschreiben solcher Abfragen und verwendet sie für Experimente in dem Textabschnitt. Im Folgenden sei eine einfache Aggregationsabfrage betrachtet:
SELECT A, COUNT(B) FROM T GROUP BY A (WÄHLE A AUS, ZÄHLE (B) VON T GRUPPE DURCH A)
Wenn der Root-Server die obige Anfrage empfängt, bestimmt er alle Tablets, d. h. horizontale Partitionen der Tabelle, welche die Tabelle T' umfassen, und schreibt die Abfrage wie folgt neu:
SELECT A, SUM(c) FROM (R¹ _,1; UNION ALL ... R¹ _,n GROUP BY A
Tables R¹ _,1 UNION ALL ... R¹ _,n sind die Ergebnisse der Abfragen, die an die Knoten gesendet werden 1, ..., n auf Ebene 1 des Bereitstellungsbaums:
R¹ _,i = SELECT A, COUNT(B) AS c FROM T¹ _,i; GROUP BY A
T¹ _,i ist eine disjunkte Partition von Tablets in 'T', verarbeitet von Server 'i' auf Ebene Jede Serverebene nimmt eine ähnliche Neuschreibung vor. Letztlich erreichen die Abfragen die Blätter, welche die Tablets parallel in 'T' scannen. Auf dem Weg nach oben führen zwischengeschaltete Server eine parallele Aggregation von Teilergebnissen durch. Das vorstehend dargestellte Ausführungsmodell ist gut für Aggregationsabfragen geeignet, die kleine und mittelgroße Ergebnisse liefern, bei denen es sich um eine sehr weit verbreitete Klasse interaktiver Abfragen handelt.
Abfragen-Dispatcher. Bei dem beschriebenen System handelt es sich um ein Multi-User-System, so können beispielsweise mehrere Abfragen gleichzeitig ausgeführt werden. Ein Abfrage-Dispatcher terminiert Abfragen auf der Grundlage ihrer Prioritäten und führt einen Lastausgleich durch. Eine weitere Rolle besteht in der Fehlertoleranz wenn ein Server viel langsamer als andere oder ein Tablettreplikat unerreichbar wird.
Die Menge der in jeder Abfrage verarbeiteten Daten ist oft größer als die Anzahl der für die Realisierung verfügbaren Verarbeitungseinheiten, die als Slots bezeichnet werden. Ein Slot entspricht einem Ausführungspfad auf einem Leaf-Server. Ein System von 3.000 Blattservern zum Beispiel, von denen jeder 8 Threads einsetzt, hat 24.000 Slots. Eine Tabelle, die 100.000 Tablets umspannt, kann somit verarbeitet werden, indem jedem Slot etwa 5 Tablets zugeordnet werden. Während der Abfrageausführung berechnet der Abfrage-Dispatcher ein Histogramm von Tablett-Bearbeitungszeiten. Nimmt ein Tablett unverhältnismäßig viel Zeit zum Verarbeiten in Anspruch, führt das System eine neue Terminierung des Tabletts auf einem anderen Server durch. Einige Tabletts müssen mehrere Male neu zugeteilt werden.
Die Blatt-Server lesen Streifen verschachtelter Daten in spaltenorientierter Darstellung. Die Blöcke in jedem Streifen werden vorab asynchron abgerufen; der Vorauslese-Cachespeicher erreicht normalerweise Trefferquoten von 95%. Tablets werden normalerweise in drei Richtungen reproduziert. Kann ein Leaf-Server nicht auf ein Tablett-Replikat zugreifen, greift es auf ein anderes Replikat zurück.
Der Abfragen-Dispatcher beachtet einen Parameter, der den Mindestprozentsatz von Tablets spezifiziert, die vor der Rückgabe eines Ergebnisses gescannt werden müssen. Wie nachstehend beschrieben, kann durch das Einstellen eines solchen Parameters (beispielsweise 98% anstatt 100%) die Ausführung oftmals signifikant beschleunigt werden, insbesondere wenn kleinere Replikationsfaktoren verwendet werden.
Jeder Server kann einen internen Ausführungsbaum haben, wie auf der rechten Seite in 7 dargestellt wird. Der Baum entspricht einem physischen Abfrage-Ausführungsplan und umfasst die Evaluierung von skalaren Ausdrücken. In optimierter Form wird ein typspezifischer Code für die meisten skalaren Funktionen erzeugt. Ein grundlegender Ausführungsplan besteht aus einer Reihe von Iteratoren, die eingegebene Spalten in Lockstep scannt und Ergebnisse von Aggregaten (Zusammenfassungen) und skalaren Funktionen, die mit den korrekten Repetitions- und Definitionsebenen versehen sind, und umgeht die Assemblierung von Datensätzen während der Ausführung völlig.
Einige Abfragen des beschriebenen Systems, wie etwa Top-k und Count-Distinct, geben unter Einsatz gut bekannter Einzelscan-Algorithmen annähernde Ergebnisse zurück. Siehe Hailing Yu, Hua-gang Li, Ping Wu, Divyakant Agrawal, Amr El Abbadi, "Efficient processing of distributed top-k queries" (Effiziente Verarbeitung verteilter Top-k-Anfragen), DEXA2005, S. 65–74.
ABSCHNITT 7: EXPERIMENTELLE DATEN
Dieser Abschnitt präsentiert eine experimentelle Einschätzung des beschriebenen Systems für mehrere Datensätze und prüft die Wirksamkeit der spaltenförmigen Speicherung für verschachtelte Daten. Die Eigenschaften der in der Studie verwendeten Datensätze sind in 11 zusammengefasst. In nicht-komprimierter, nicht-replizierter Form belegen die Datensätze ungefähr einen Speicherbereich von einem Petabyte. Alle Tabellen sind, mit Ausnahme einer zweifach replizierten Tabelle, dreifach repliziert und beinhalten zwischen 100.000 und 800.000 Tabletts verschiedener Größe. Dieser Abschnitt beginnt mit Überprüfen der grundlegenden Datenzugriffseigenschaften auf einer einzelnen Maschine, zeigt anschließend, welche Vorteile die Spaltenspeicherung der MapReduce-Ausführung bringt und konzentriert sich abschließend auf die Leistung des beschriebenen Systems. Die Experimente wurden während des normalen Geschäftsbetriebs auf Systeminstanzen durchgeführt, die in zwei Datenzentren neben vielen anderen Anwendungen laufen. Nachstehend verwendete Tabellen- und Feldnamen sind anonymisiert.
Lokale Festplatte. In dem ersten Experiment wurden Leistungs-Tradeoffs von spaltenorientierter gegenüber aufzeichnungsorientierter Speicherung durch das Scannen eines Fragmentes von 1 GB von Tabelle T1 untersucht, etwa 300 K Zeilen beinhaltend (siehe 12). Die Daten sind auf einer lokalen Platte gespeichert und nehmen ungefähr 375 MB in komprimierter Spaltendarstellung in Anspruch. Das datensatzorientierte Format verwendet eine schwerere Komprimierung, ergibt jedoch ungefähr dieselbe Größe auf der Platte. Das Experiment wurde auf einer Dual-Core-Intel-Maschine mit einer Platte durchgeführt, die eine Lesebandbreite von 70 MB/s bereitstellt. Alle berichteten Zeiten sind kalt; der OS-Cachespeicher wurde vor jedem Scan geleert.
12 zeigt fünf Graphen, welche die Zeit illustrieren, die für das Lesen und die Dekompression der Daten sowie die Assemblierung und das Parsing der Aufzeichnungen für einen Teilsatz von Feldern erforderlich ist. Die Graphen (a)–(c) stellen einen Überblick der Ergebnisse für die Spaltenspeicherung dar. Jeder Datenpunkt in diesen Graphen wurde mittels Durchschnittsbildung der Messungen über 30 Durchläufe erhalten, bei denen in jedem eine Reihe von Spalten einer jeweiligen Kardinalität (Beziehungsfolge) stichprobenartig ausgewählt wurde. Graph (a) zeigt die Lese- und Dekompressionszeit. Graph (b) fügt die Zeit hinzu, die zum Assemblieren von verschachtelten Datensätzen von den Spalten benötigt wird. Graph (c) zeigt, wie lange es dauert, um die Datensätze in stark typisierte C++-Datenstrukturen zu parsen.
Graphen (d)–(e) zeigen die Zeit für den Zugriff auf die Daten in aufzeichnungsorientierter Speicherung. Graph (d) zeigt die Lese- und Dekompressionszeit. Ein Großteil der Zeit wird für die Dekomprimierung aufgewandt; tatsächlich können die komprimierten Daten in ungefähr der Hälfte der Zeit von der Platte gelesen werden. Wie Graph (e) anzeigt, fügt das Parsen weitere 50% zu der Zeit für Lesen und Dekomprimieren hinzu. Diese Kosten werden für alle Felder einschließlich der Felder bezahlt, die gar nicht benötigt werden.
Wenn eine geringe Zahl von Spalten gelesen wird, können die Gewinne der spaltenförmigen Darstellung etwa eine Größenordnung sein. Die Abrufzeit für spaltenförmige verschachtelte Daten kann linear mit der Anzahl der Felder zunehmen. Die Zusammenstellung und das Parsen von Datensätzen kann kostenintensiv sein, wobei jedes Mal die Ausführungszeit möglicherweise verdoppelt wird. Ähnliche Trends wurden an anderen Datensätzen beobachtet. Es stellt sich ganz selbstverständlich die Frage, wo sich die oberen und unteren Graphen treffen, das heißt, wo die datensatzorientierte Speicherung anfangt, die Spaltenspeicherung hinsichtlich der Leistung zu übertreffen. Im Experiment kann der Schnittpunkt bei Dutzenden von Feldern liegen, variiert jedoch zwischen den Datensätzen und hängt davon ab, ob eine Datensatzassemblierung benötigt wird.
MapReduce und das beschriebene System. Als Nächstes werden eine Ausführung von MapReduce und das Beschriebene System hinsichtlich spalten- vs. datensatzortentierten Daten veranschaulicht. In diesem Fall wird auf ein einzelnes Feld zugegriffen, und die Leistungsgewinne treten sehr deutlich hervor. Die Ausführungsformen für mehrere Spalten können unter Verwendung der Ergebnisse von 12 extrapoliert werden. In diesem Experiment wird die durchschnittliche Anzahl von Begriffen in einem Feld 'txtField' von Tabelle T1' gezählt. Die MapReduce-Ausführung wird unter Verwendung des folgenden Sawzall-Programms durchgeführt:
numRecs: table sum of int;
numWords: table sum of int;
emit numRecs <- 1;
emit numWords <- CountWords(input.txtField);
Die Anzahl der Aufzeichnungen wird in der Variablen 'numRecs' gespeichert. Für jeden Datensatz wird 'numWords' um die Anzahl von Begriffen in 'input.txtField' erhöht, die von der 'CountWords'-Funktion zurückgegeben wird. Nachdem das Programm läuft, kann die durchschnittliche Begriffshäufigkeit als numWords=numRecs berechnet werden. In SQL wird die Berechnung wie folgt ausgedrückt:
Q₁: SELECT SUM(CountWords(textile))/COUNT(*) FROM T1
13 zeigt die Ausführungszeiten von zwei MapReduce-Jobs und das beschriebene System auf einer logarithmischen Skala. Beide MapReduce-Aufgaben werden an 3000 Bearbeitern (beispielsweise Servern) ausgeführt. Auf ähnliche Weise wird eine 3000-Knoten-Instanz des vorliegenden Systems zum Ausführen von Abfrage Q1 verwendet. Das beschriebene System und MapReduce für Spalten lesen etwa 0,5 TB komprimierter spaltenförmiger Daten gegenüber 87 TB, die beim MapReduce für Aufzeichnungen gelesen werden. Wie 12 veranschaulicht, gewinnt MapReduce durch das Wechseln von datensatzorientierter auf spaltenorientierter Speicherung eine Größenordnung an Effizienz (von Stunden auf Minuten). Eine weitere Größenordnung wird durch das Verwenden des beschriebenen Systems erreicht (von Minuten auf Sekunden).
Servina Baumtopologie. Im nächsten Experiment wird die Auswirkung der Tiefe des Bereitstellungsbaumes auf die Ausführungszeit veranschaulicht. Zwei Abfragen GROUP BY (GRUPPIEREN NACH) werden an Tabelle T2 durchgeführt, die jeweils unter Verwendung eines einzelnen Scans über die Daten ausgeführt werden. Tabelle T2 beinhaltet 24 Milliarden verschachtelte Datensätze. Jeder Datensatz hat ein wiederholtes Feldelement, das eine Zahlenmenge beinhaltet. Das Feld item.amount wiederholt sich etwa 40 Billiarden Mal im Datensatz. Die erste Abfrage summiert die Elementmenge nach ”country” (Land):
Q₂: SELECT country, SUM(item.amount) FROM T2
GROUP BY country
Es bringt einige hundert Aufzeichnungen zurück und liest etwa 60 GB komprimierter Daten von der Platte. Die nächste Abfrage führt ein GRUPPIEREN NACH an einem Textfeldbereich mit einer ausgewählten Bedingung durch. Sie liest ungefähr 180 GB und erzeugt ungefähr 1,1 Millionen unterschiedliche Bereiche:
Q₃: SELECT domain, SUM(item.amount) FROM T2
WHERE domain CONTAINS'.net'
GROUP BY domain
14 zeigt die Ausführungszeiten für jede Abfrage als eine Funktion der Servertopologie. In jeder Topologie wird die Anzahl von Leaf-Servern konstant bei 2900 gehalten, so dass von der gleichen kumulativen Scangeschwindigkeit ausgegangen werden kann. In der 2-Ebenen-Topologie (1:2900) kommuniziert ein Single-Root-Server direkt mit den Leaf-Servern. Für 3 Ebenen wird eine Einstellung von 1:100:2900 verwendet, das heißt eine zusätzliche Ebene von 100 zwischengeschalteten Servern. Die Topologie mit 4 Ebenen lautet: 1:10:100:2900.
Abfrage Q₂ läuft in drei Sekunden, wenn bei der Bedienung des Baums drei Ebenen eingesetzt werden und profitiert nicht viel von einer zusätzlichen Ebene. Im Gegensatz dazu wird die Ausführungszeit von Q₃ aufgrund der erhöhten Parallelität halbiert. Bei 2 Ebenen liegt Q₃ außerhalb des Diagramms, da der Root-Server, der zum Aggregieren der Ergebnisse nahe sequenziell erforderlich war, Ergebnisse von Tausenden von Knoten empfangen hat. Dieses Experiment veranschaulicht wie Aggregationen, die viele Gruppen zurückgeben, von Multilevel-Bereitstellungsbäumen profitieren können.
Per-Tablet Histogramme. 15 zeigt, wie schnell Tabletts von Leaf-Servern für einen spezifischen Durchlauf von Q₂ and Q₃ verarbeitet werden. Die Zeit wird beginnend an dem Punkt gemessen, an dem ein Tablett zur Ausführung in einem verfügbaren Slot terminiert wird, das heißt es wird die Zeit herausgerechnet, die mit Warten in der Aufgabenwarteschlange verbracht wird. Diese Messtechnologie lagert die Effekte anderer Abfragen, die gleichzeitig ausgeführt werden, aus. Der Bereich unter jedem Histogramm entspricht 100%. Wie 15 anzeigt, werden 99% von Q₂ (oder Q₃) Tabletts in weniger als einer (oder zwei) Sekunden bearbeitet.
Aggregation innerhalb der Aufzeichnung. Als ein weiteres Experiment wird die Leistung von Abfrage Q₄ untersucht, wenn sie für Tabelle T3 erfolgt. Die Abfrage veranschaulicht die Aggregation innerhalb des Datensatzes: sie zählt alle Datensätze, bei denen die Summe von a.b.c.d-Werten die in dem Datensatz vorkommen, größer als die Summe aus a.b.q.r-Werten ist. Die Felder wiederholen sich auf verschiedenen Ebenen von Verschachtelung. Aufgrund der Spaltenstreifenanordnung werden nur 13 GB (von 70 TB) von der Platte gelesen, und die Abfrage ist in 15 Sekunden abgeschlossen. Wäre Verschachtelung nicht unterstützt, würde diese Abfrage an T3 kostenintensiv sein.
Q₄: SELECT COUNT(c1 > c2) FROM
(SELECT SUM(a.b.c.d) WITHIN RECORD AS c1, SUM(a.b.p.q.r)
WITHIN RECORD AS c2 FROM T3)
Skalierbarkeit. Das folgende Experiment veranschaulicht die Skalierbarkeit des Systems an einer Tabelle mit Trillionen von Datensätzen. Die nachstehend gezeigte Abfrage Q₅ wählt die obersten 20 Unterstützungsfunktionen und ihre Anzahl des Vorkommens in Tabelle T4 aus. Die Abfrage scannt 4,2 TB an komprimierten Daten.
Q₅: SELECT TOP(aid, 20), COUNT(*) FROM T4
WHERE bid = {valuel} AND cid = {value2}
Die Abfrage wurde unter Einsatz von vier Konfigurationen des Systems ausgeführt, in einer Reichweite von 1.000 bis 4.000 Knoten. Die Ausführungszeiten sind in 16 dargestellt. Die insgesamt aufgewendete CPU-Zeit ist bei jedem Durchlauf nahezu gleich und liegt bei ungefähr 300.000 Sekunden, während sich die vom Nutzer wahrgenommene Zeit nahezu linear mit der zunehmenden Größe des Systems verringert. Dieses Ergebnis legt den Schluss nahe, dass ein größeres System genauso effektiv hinsichtlich der Ressourcennutzung wie ein kleineres sein kann, jedoch eine schnellere Ausführung ermöglicht.
Nachzügler. Bei Stragglern (”Nachzüglern”) kann es sich um Aufgaben (beispielsweise das Verarbeiten eines Tabletts) handeln, die beispielsweise deshalb nicht durchgeführt werden, weil die Maschine, die die Aufgabe durchführt, ein funktionelles Problem aufweist, oder die Maschine bei der Abwicklung der Aufgabe aufgrund Aufgaben höherer Priorität nicht aggressiv genug ist. Nachstehende Abfrage Q₆ wird an einer Tabelle T5 mit einer Trillionen Zeilen ausgeführt. Im Gegensatz zu den anderen Datensätzen wird T5 zweifach repliziert. Dementsprechend ist die Wahrscheinlichkeit, dass Straggler die Ausführung verlangsamen, höher, da weniger Möglichkeiten für eine Neuterminierung der Arbeitsaufgaben vorliegen.
Q₆: SELECT COUNT(DISTINCT a) FROM T5
Abfrage Q₆ liest mehr als 1 TB komprimierter Daten. Das Komprimierungsverhältnis für das abgerufene Feld liegt bei ungefähr 10. Wie dies in 17 angezeigt ist, liegt die Verarbeitungszeit für 99% der Tabletts unter 5 Sekunden pro Tablett pro Slot. Ein kleiner Bruchteil der Tabletts brauch jedoch weitaus länger, wodurch die Abfrage-Reaktionszeit von weniger als eine Minute auf mehrere Minuten ansteigt, wenn sie auf einem System mit 2500 Knoten ausgeführt wird. Der folgende Abschnitt fasst die Ergebnisse der Experimente zusammen.
ABSCHNITT 8: FESTSTELLUNGEN
18 zeigt die Reaktionszeitverteilung der Abfrage in einem typischen monatlichen Arbeitspensum auf einer logarithmischen Skala. Wie von 18 angezeigt, werden die meisten Abfragen in weniger als 10 Sekunden, bequem innerhalb des interaktiven Bereiches verarbeitet. Einige Abfragen haben eine Scan-Durchsatzleistung von nahezu 100 Milliarden Datensätzen pro Sekunde in einem ausgelasteten Cluster und sogar noch mehr auf dedizierten Maschinen erzielt. Die vorstehend dargelegten Experimentdaten legen die folgenden Feststellungen nahe:

• Scanbasierte Abfragen können bei interaktiven Geschwindigkeiten an auf Platten befindlichen Datensätzen einer Vielzahl von Datensätzen ausgeführt werden;
• Für Systeme, die Tausende von Knoten beinhalten, kann eine nahezu lineare Skalierbarkeit hinsichtlich der Anzahl von Spalten und Servern erzielt werden;
• MapReduce kann ebenso von einer Spaltenspeicherung wie ein DBMS profitieren;
• Die Assemblierung und das Parsen von Datensätzen ist kostenintensiv. Software-Schichten (über die Abfrageverarbeitungsschicht hinaus) können so optimiert werden, dass sie direkt spaltenorientierte Daten konsumieren;
• MapReduce und Abfragenverarbeitung können in ergänzender Form eingesetzt werden, die Ausgabe einer Schicht kann die Eingabe einer anderen speisen;
• In einer Multi-User-Umgebung kann ein größeres System von Skalierungseinsparungen profitieren, während ein qualitativ besseres Nutzererlebnis bereitgestellt wird;
• Wenn für Genauigkeit ein Abstriche hinsichtlich der Geschwindigkeit annehmbar sind, kann eine Abfrage viel früher abgeschlossen werden und es können immer noch die meisten Daten sichtbar sein; und
• Der Großteil eines webskalierten Datensatzes kann schnell gescannt werden, obgleich das Erreichen der letzten wenigen Prozent die Menge an Verarbeitungszeit erhöhen kann.

19 ist das Blockdiagramm eines Systems zur Generierung und Verarbeitung spaltenorientierter Speicherungsdarstellungen von verschachtelten Aufzeichnungen. Der Datensatzgenerator 1904 erzeugt Datensätze verschachtelter Daten anhand von Datenquellen 1920 und einem Schema 1902. Der Spaltengenerator 1908 empfängt als Eingabe die Datensätze 1906 und das Schema 1902 und gibt Spaltenstreifen aus, die die Daten in den Datensätzen 1906 darstellen, jedoch in einem Spaltenformat. Die Spaltendaten 1910 können in-situ durch das Abfragesystem 1912 abgefragt werden, um verschiedene Reihen an ausgegebenen Spalten 1914 zu erzeugen. Die Spaltendaten 1910 können auch von dem Datensatz-Assembler 1916 zurück in Datensatzform assembliert werden. Die Datensätze 1918, die von dem Datensatz-Assembler ausgegeben werden, können jeweils eine Teilmenge an Feldern von den ursprünglichen Datensätzen in der Sammlung 1906 beinhalten. An den ausgegebenen Datensätzen 1918 kann durch ein datensatzbasiertes Datenanalyseprogramm (beispielsweise MapReduce) operiert werden.
Genauer gesagt können die Datenquellen 1920 erheblich unstruktierte Daten beinhalten. Im ”Wesentlichen unstrukturiert” bedeutet, dass die Daten Elemente beinhalten können, die Struktur bezeichnen, das gesamte Spektrum von Informationen jedoch möglicherweise nicht ähnlich strukturiert ist. Als Veranschaulichung können zu den Datenquellen 1920 der Quellencode für jede der Millionen von Webseiten gehören. Obgleich jede Webseite ein gewisses Maß an Struktur beinhaltet, wird der Inhalt jeder Webseite nicht auf der Grundlage eines gemeinsamen Schemas erzeugt. Im Allgemeinen können Standards ein Format der Seite vorgeben, Inhalt und Platzierung von Feldern wird jedoch nicht durch ein einzelnes Schema zwischen den einzelnen Webseiten spezifiziert. Bei einigen Beispielen werden die Informationen in den Datenquellen 1920 nicht auf der gemeinsamen Speicherschicht 1922 gespeichert, sondern direkt von externen Quellen im Internet abgerufen.
Das Schema 1902 definiert eine gemeinsame Strukturierung für Informationen, die in den Datenquellen enthalten sein könnten. Wie dies bereits in diesem Dokument beschrieben wurde, kann das Schema 1902 bestimmte Felder an Informationen erfordern und zulassen, dass andere Felder an Informationen als optional gespeichert werden.
Der Aufzeichnungsgenerator 1904 empfängt als Eingabe das Schema 1902 und Informationen aus den Datenquellen 1920. Der Datensatz-Generator 1904 nimmt die Informationen von den Datenquellen 1920 und strukturiert alle oder Abschnitte der Informationen in den einzelnen Instanzen der Datensätze, die mit dem Schema 1902 übereinstimmen. Während die Datenquellen 1920 im Wesentlichen unstrukturierte Daten von Webseiten beinhalten können, kann der Datensatz-Generator 1904 einzelne Informationen von jeder Webseite auswählen, um sie in bestimmte Datensätze 1906 einzufügen.
Somit kann jede der Aufzeichnungen 1906 Daten enthalten, die im Einklang mit dem Schema 1902 strukturiert sind. Die strukturierten Daten können Felder beinhalten, die eine Semantik von Datenwerten und eine strukturbezogene Beziehung der Datenwerte bezeichnen kann. Dementsprechend kann das Schema referenziert werden, um zusätzliche Informationen für den Datenwert (beispielsweise was der digital gespeicherte Datenwert in der realen Welt oder auf einer Webseite darstellt und Beziehungen zu anderen Werten) zu beziehen.
Jede Aufzeichnung 1906 kann verschachtelte Felder und Datenwerte enthalten. Ein verschachtelter Datensatz kann mehr als ein Feld desselben Namen oder Pfades beinhalten. Die Felder mit demselben Namen oder Pfad können sich jedoch strukturell an verschiedenen Orten in einem bestimmten Datensatz befinden. So kann sich beispielsweise ein einzelnes Feld, das durch das Schema definiert wird, mehrere Male wiederholen. Ferner können Felder untergeordnete Felder (das heißt verschachtelte Felder) umfassen. Auf diese Weise kann sich ein bestimmtes Feld auf einer oberen Ebene eines Datensatzes wiederholen, und jede Wiederholung des Feldes kann in einem bestimmten untergeordneten Feld beinhalten sein oder nicht. Mit anderen Worten kann der Datensatz Instanzen des untergeordneten Feldes in einigen Abschnitten des Datensatzes aber nicht in anderen Abschnitten des Datensatzes beinhalten.
Die Sammlung von Aufzeichnungen 1906 kann in spaltenorientierte Daten 1910 übersetzt werden, um die Verarbeitung der Information in den Aufzeichnungen zu beschleunigen. Wenn die Aufzeichnungsmenge in Sammlung 1906 zum Beispiel in die Billiarden reicht und jede Aufzeichnung hunderte verschiedener Felder enthalten könnte, kann eine Analyse der Aufzeichnungen dort zeitaufwendig sein, wo eine geringe Anzahl von Feldern gewünscht wird. Dies rührt daher, dass jeder Datensatz in der Sammlung 1906 zusammen mit anderen Informationen von dem Datensatz gespeichert wird. Das heißt, jeder Datensatz wird zusammen in einem darauffolgenden Abschnitt des Speichers gruppiert (wie dies beispielsweise in der 'datensatzorientierten' Darstellung verschachtelter Daten in 1 dargestellt ist).
Im Gegensatz dazu umfassen die spaltenorientierten Daten 1910 Spalten, von denen jede Informationen für ein einzelnes Feld im Schema 1902 speichert (z. B. wie in der 'spalten-orientierten' Darstellung verschachtelter Daten in 1 dargestellt wird). Wenn demgemäß das Feld ein Byte lang ist, kann die Spalte für das Feld in der Größenordnung von Milliarden von Bytes (beispielsweise ein Byte für jeden Datensatz) im Gegensatz zu Milliarden von Datensätzen liegen (wo beispielsweise jeder Datensatz ein Megabyte groß sein kann). Die Operationen des Spalten-Generators 1908 werden ausführlicher im Abschnitt 4.2 ”Zerlegen von Datensätzen in Spalten” beschrieben. Das Speicherformat für die Spaltendaten 1910 wird ausführlicher im Abschnitt 4.1 ”Repetitions- und Definitionsebene” beschrieben.
Die spaltenorientierten Daten 1910 können unter Einsatz des Abfragesystems 1912 direkt abgefragt werden. Mit anderen Worten können die Spaltendaten 1910 ohne Laden von Daten in eine Datenbank abgefragt werden. Das Abfragesystem kann, wenn es eine Abfrage ausführt, eine Tabelle mit Spaltendaten als Eingabe empfangen. Bei einigen Beispielen empfängt das Abfragesystem auch das Schema 1902 als Eingabe. Die Spaltenstreifen können zusammen mit dem Schema gespeichert werden, um die Daten selbstbeschreibend zu gestalten. Mit dem Abfragesystem können Operationen an den Spaltendaten durchgeführt werden, um Spalten mit ausgegebenen Informationen 1914 zu erzeugen. Die ausgegebenen Spalten 1914 können eine Teilmenge der Werte beinhalten, die in den Spaltendaten 1910 dargestellt sind, je nachdem wie dies von einer bestimmten Abfrage bestimmt wird. Bei einigen Beispielen gibt das Abfragesystem Datensätze 1918 anstelle oder zusätzlich von den Spalten 1914 aus.
Das Abfragesystem 1912 kann zum Beispiel eine ersten Abfrage empfangen, in Reaktion dazu über ausgewählte Datenspalten parsen und einen Satz von Ausgabespalten generieren, der einen Titel von allen Webseiten liefert, die ein oder mehrere Videos enthalten, sowie eine Nummer für jede Webseite. Das Abfragesystem kann eine zweite Abfrage empfangen und in Reaktion eine zweite Reihe an ausgegebenen Spalten ausgeben, die einen URL jeder Webseite bereitstellt, die innerhalb der letzten fünfzehn Minuten erzeugt wurde. Andere Informationen von den Spalten 1910 sind möglicherweise nicht in einer Reihe an ausgegebenen Spalten beinhalten, die einer bestimmten Abfrage 1914 entsprechen.
Es kann sein, dass auf Daten, die als spaltenorientierte Daten 1910 gespeichert sind, über einen analytischen Service zugegriffen werden muss, der nicht mit spaltenorientierten Daten, sondern mit Aufzeichnungen operiert. Demgemäß kann ein Datensatz-Assembler 1916 die Spaltendaten als Eingabe empfangen und Datensätze anhand der Spaltendaten assemblieren. Das Verfahren der Assemblierung von Aufzeichnungen wird in größerem Detail in Abschnitt 4.3, „Assemblierung von Aufzeichnungen” beschrieben.
Auch wenn die Aufzeichnungen bereits in der Sammlung 1906 verfügbar sind, ermöglicht der Aufzeichnungsassembler 1916 die Generierung eines Aufzeichnungssatzes, der einen Teilsatz der Felder der Aufzeichnungen in der Sammlung 1906 umfasst. So können die Datensätze in der Sammlung beispielsweise Tausende unterschiedlicher Felder beinhalten. Ein Nutzer möchte möglicherweise ein datensatzorientiertes Analyseprogramm ausführen, das lediglich Kenntnis von zweien der Felder jedoch für alle der Datensätze erfordert. Demgemäß kann der Datensatz-Assembler 1916 eine Reihe von Datensätzen erzeugen, die lediglich Informationen zu den erforderlichen Feldern beinhaltet. Auf diese Weise können mehrere Reihen an ausgegebenen Datensätzen 1918 für unterschiedliche Analysen oder für verschiedene Analyseprogramme entwickelt werden. Eine Analyse an kleineren Datensätzen kann schneller als eine Analyse sein, die die größeren Datensätze durchlaufen muss, die in der Sammlung 1906 vorkommen können.
Die obige Beschreibung der Operation von System 1900 illustriert ein Beispiel, in dem die Sammlung von Aufzeichnungen 1906 Aufzeichnungen umfasst, die im Einklang mit Schema 1902 formatiert sind, worin die spaltenorientierten Daten 1910 aus diesem einzelnen Satz ähnlich strukturierter Daten generiert werden. Bei verschiedenen Beispielen können mehrere Schemata 1902 zum Erzeugen einer Sammlung von Datensätzen verwendet werden, die viele Reihen an unterschiedlich strukturierten Datensätzen 1906 beinhaltet. Dennoch kann jede Aufzeichnung in einem Header den Typ des Schemas identifizieren, das bei der Generierung der Aufzeichnung eingesetzt wurde. Auf ähnliche Weise kann ein Spaltenstreifen für jedes Feld in jedem vieler Reihen an ähnlich strukturierten Datensätzen erzeugt werden. Jeder Spaltenstreifen kann nicht nur den Namen des Feldes sondern auch das Schema anzeigen, dem die Spaltendaten zugewiesen sind (das heißt das Schema, das zum Formatieren der Datensätze verwendet wird, anhand derer die Spaltendaten erzeugt wurden).
20 ist das Flussdiagramm eines musterhaften Verfahrens zur Generierung spaltenorientierter Daten. Das Verfahren kann von Komponenten des Systems 1900 durchgeführt werden.
In Box 2002 wird ein Satz Aufzeichnungen generiert. Die Erzeugung der Datensätze kann von dem Datensatz-Generator 1904 durchgeführt werden. Unstrukturierte Daten (beispielsweise von Datenquellen 1920) können zu einem standardisierten Datensatzformat kompiliert werden, das durch Schema 1902 definiert ist. Die Datensätze können in der Sammlung 1906 gespeichert werden.
In Box 2004 wird auf die Aufzeichnungen in der Sammlung 1906 zugegriffen. So empfangt der Spalten-Generator 1908 beispielsweise die Daten von der Sammlung an Datensätzen 1906 als Eingabe.
In Box 2006 wird festgestellt, ob ein spaltenorientierter Streifen für ein zusätzliches Feld generiert werden soll. So muss beispielsweise ein Streifen für jedes Feld in der Reihe an Datensätzen erzeugt werden, die in der Sammlung 1906 gespeichert sind (und demzufolge jeder Datensatz in dem Schema 1902 oder einer Teilmenge davon). In dieser Veranschaulichung wurden bisher keine Streifen erzeugt, und demzufolge gibt es Felder, für die ein Streifen erzeugt werden muss. Dementsprechend geht das Verfahren in Kästchen 2008 über, um Operationen für ein bestimmtes Feld durchzuführen. Wenn alle Streifen erzeugt worden sind (beispielsweise wurde ein Streifen für jedes Feld in der Sammlung an Datensätzen 1906 erzeugt) kann das Verfahren enden.
In Box 2008 wird eine Liste von Werten für das bestimmte Feld generiert. So kann beispielsweise jeder der Datensätze durchlaufen und eine Liste mit Werten für das bestimmte Feld erzeugt werden.
In Box 2010 werden Wiederholungsebenen für das bestimmte Feld generiert. So kann der Spalten-Generator 1908 beispielsweise eine Repetitionsebene für jeden der Werte in der Liste durch Bestimmen eines am aktuellsten wiederholten Feldes in dem Pfad für das Feld bestimmen.
In Box 2012 werden Definitionsebenen für das bestimmte Feld generiert. So kann der Spalten-Generator 1908 beispielsweise eine Definitionsebene für jeden Wert (einschließlich von Werten, die 'missing' (fehlen), wie weiter oben ausführlicher beschrieben ist) erzeugen.
In Box 2014 erfolgt die Assemblierung eines spaltenorientierten Streifens für das bestimmte Feld. In verschiedenen Beispielen sind die Wiederholungs- und Definitionsebenen in gepaarten Gruppierungen im Header des Streifens platziert. Die Liste mit Werten kann in den Hauptteil des Streifens platziert werden.
In Box 2016 wird der spaltenorientierte Streifen in Blöcke zerlegt, die komprimiert werden können. Jeder Block kann eine Reihe von Werten und ihre entsprechenden Repetitions- und Definitionsebenen beinhalten. Anschließend wird in Kästchen 2006 eine Bestimmung dahingehend, ob Spaltenstreifen für zusätzliche Felder erzeugt werden müssen, durchgeführt. Wenn keine zusätzlichen Spaltenstreifen erzeugt werden sollen, endet der Prozess.
Das in 20 dargestellte Verfahren ist ein musterhaftes Verfahren zur Generierung spaltenorienterter Streifen. Es sind Varianten an dem Prozess vorgesehen. So können beispielsweise die Operationen der Kästchen nicht sequenziell wie in dem Ablaufplan dargestellt durchgeführt werden. Streifen können für mehrere Felder in einem einzigen Anlauf erzeugt werden. Die Repetitions- und Definitionsebenen können dann erzeugt werden, wenn jeder Wert von einem Datensatz bezogen wird. Der Spaltenstreifen muss nicht als Ganzes erzeugt werden. Stattdessen kann jeder Block anhand des Streifens erzeugt und unabhängig komprimiert werden. Auf diese Weise kann der Ablaufplan einen konzeptuellen Mechanismus zum Verständnis der Streifen darstellen, ist jedoch nicht im beschränkenden Sinne zu erachten. In dem Algorithmus von 4 wird ein Prozess zum Erzeugen von Spaltendaten dargestellt, der möglicherweise nicht den in Bezug auf 20 beschriebenen Operationen entspricht.
21 ist ein Blockdiagramm, das ein Beispiel für ein System 2100 illustriert, welches einen Web-Service für die Speicherung und Verarbeitung von Daten implementiert. Um Allgemeinen repräsentiert das Verarbeitungssystem für spaltenorientierte Daten 2130 auf der untere rechten Seite der 21 Komponenten des in 19 illustrierten Systems (die das Blockdiagramm eines Systems für die Generierung und Verarbeitung von spaltenorientierten Speicherrepräsentationen verschachtelter Aufzeichnungen illustriert). Wie in größerem Detail überall in diesem Dokument beschrieben wird, kann das Verarbeitungssystem für spaltenorientierte Daten 2130 wirksame Abfragen für spaltenorientierte Daten ausführen, die in Repository 2132 gespeichert sind. Die verbleibenden Komponenten des Datenspeicherungs- und Datenverarbeitungsservice 2102 unterstützen einen Web-Service, der Daten speichert, externen Benutzern (z. B. Personen, die auf den Service 2102 über das Internet zugreifen) den Import dieser Daten in Tabellen und, aus der Perspektive des Benutzers, die Durchführung von Abfragen für diese Tabellen gestattet. Die diesen Tabellen zugrunde liegenden Daten können als spaltenorientierte Daten gespeichert werden, und die Abfragen für die Tabellen können durch die Abfragekapazitäten des Verarbeitungssystems der speicherorientierten Daten 2130 implementiert werden. Die externen Benutzer setzen Anwendungsprogrammierungsoberflächen (Application Programming Interfaces, API) 2104, 2134 und 2124 ein, um Daten in den Datenspeicherungs- und Verarbeitungsservice 2102 hochzuladen und Abfragen für die Tabellen durchzuführen.
Externe Benutzer können die Objekte-API 2104 einsetzen, um Daten in die Objektspeicherung 2106 hochzuladen, die potentiell in den Daten eines einzigen Service aggregiert werden, die regelmäßig von zahlreichen Computergeräten strömen. Externe Benutzer können Tabellen definieren und die in der Objektspeicherung 2106 befindlichen Daten in die Tabellen übertragen. Die Übertragung kann auf Anforderung des Benutzers oder automatisch durch den Service 2102 erfolgen, wenn neue Daten in die Objektspeicherung 2106 hochgeladen werden. Die Massendaten, die in Tabellen referenziert werden, können als spaltenorientierte Daten in Speicherung 2132 gespeichert werden, während die Metadaten für die Tabellen separat in der Tabellenspeicherung für Metadaten 2120 gespeichert werden können. Die externen Benutzer können wirksame Abfragen für die Tabellen mit Hilfe der Abfragen-API 2124 durchführen. Die Abfragen für die Tabellen können als Abfragen für die zugrunde liegenden spaltenorientierten Daten in Speicherung 2132 implementiert werden, und die Verarbeitung der Abfragen für die spaltenorientierten Daten in Speicherung 2132 kann von dem Verarbeitungssystem für spaltenorientierte Daten 2130 vorgenommen werden, wie überall in diesem Dokument beschrieben.
Die Objektspeicherung 2106, die externen Benutzern über die Objekte-API 2104 zur Verfügung gestellt wird, wird zuerst im Einzelnen beschrieben. Die Objektspeicherung 2106 hostet Daten, auf die über die Objekte-API 2104 zugegriffen werden kann. Zur Illustration werden immer mehr Protokolldaten, die von Websites generiert werden, in der Cloud von entfernten Services gehostet, die sich auf Datenhosting spezialisieren, im Gegensatz zu den Websites selbst, die die Protokolldateien in ihren eigenen Netzwerken speichern. Eine solche Cloud-basierte Speicherung kann besonders von Vorteil sein, wenn Daten, die kontinuierlich von geographisch verstreuten Computer generiert werden, an einem Ort aggregiert werden und für multiple verschiedenen Benutzer zur Verfügung stehen sowie von Zeit zu Zeit analysiert werden müssen.
Die Objektspeicherung 2106 kann Objekte von verschiedenen Benutzern umfassen, die in Raster gruppiert sind. Jedes Raster kann ein flacher Behälter sein, der Objekte gruppiert und einen einzigartigen Namenraum für die Gruppe der Objekte bereitstellt. Ein externer Benutzer kann eine Sammlung von Raster besitzen und jedem Raster Zugriffseinstellungen zuordnen. Solcherart können Objekte in einem Raster für einige wenige Benutzer privater Natur sein, während Objekte in einem anderen Raster öffentlich im Internet zugänglich sein können. Die Raster können einen universal einzigartigen Namen unter allen von externen Benutzern besessenen Rastern haben. In einigen Beispielen existieren die Raster in einem flachen Namenraum, so dass sich die Raster nicht verschachteln lassen.
Jedes Objekt kann als eine opake Sammlung von Bytes gespeichert werden. Mit anderen Worten kann die Objektspeicherung 2106 über die Objekte-API 2104 verschiedene Arten von Daten empfangen, kann die empfangenen Daten jedoch als einen Datenbrocken ohne Rücksicht auf das Format der Daten behandeln. Jedes Objekt kann korrespondierende Metadaten haben, die in einer separaten Tabelle oder Datenbank gespeichert werden. Jedes Objekt kann einem Raster zugeordnet sein, und jedes Objekt in einem Raster kann einen Namen haben, der für das Raster einzigartig ist. Somit kann jedes Objekt einen global einzigartigen Namen haben, wenn es mit Referenz auf das Elternraster des Objektes angesprochen wird. Wie Raster kann jedes Objekt seine eigene Liste der Zugriffskontrolle haben, was das Teilen von Daten über ein Netzwerk (z. B. das Internet) zwischen einer Vielzahl von Benutzern mit verschiedenen Berechtigungen ermöglicht.
Die von der Objekt-API 2104 für den Datenaustausch bereitgestellte Benutzeroberfläche kann eine HTTP-Oberfläche des Typs RESTful (REpresentational State Transfer) sein, die standardmäßige Protokolle der Industrie oder urheberrechtlich geschützte Protokolle einsetzt. Externe Benutzer können zum Beispiel Aktionen des Typs GET, PUT, POST, HERD und DELETE zur Interaktion mit Objekten einsetzen, die in der Objektspeicherung 2106 gespeichert sind. Die Objekt-API 2104 bietet eine sequentielle Oberfläche für das Schreiben und Lesen von Daten für Objekte in der Objektspeicherung 2106. In einigen Beispielen bietet die Objekt-API 2104 Nur-Lese-Zugriff auf einige der Objekte. Somit kann ein Benutzer Objekte löschen oder ersetzen, diese jedoch nicht inkrementell modifizieren. In einigen Beispielen kann der Datenspeicherungs- und Verarbeitungsservice 2102 nicht für externe Kunden konfiguriert sein, um SQL-ähnliche Abfragen direkt für die Objekte auszuführen. Die Daten in den Objekten können zunächst in strukturierten Tabellen platziert werden, bevor solche Abfragen durchgeführt werden.
Zur Illustration können HTTP API-Abfragen am Front-End-Server 2126 von einem entfernten Computergerät empfangen werden, das mit einem externen Benutzer assoziiert ist. Der Front-End-Server 2126 leitet die Abfrage an einen API-Sammelimplementor 2126 weiter. Der API-Sammelimplementor speichert API-Bibliotheken, verarbeitet die Abfrage auf der Grundlage der gespeicherten Bibliotheken und generiert korrespondierende Abfragen zu den entsprechenden Komponenten des Datenspeicherungs- und Verarbeitungsservice 2102. Weil API-Abfragen für die Objekte-API 2104 zur Objektspeicherung 2106 gehören, leitet der API-Sammelimplementor 2116 eine Abfrage an die Objektspeicherung 2106 weiter.
Der Datenspeicherungs- und Verarbeitungsservice 2102 bietet die Fähigkeit, in den Objekten gespeicherte Daten in Tabellen zu übertragen und mit Hilfe des Verarbeitungssystems für spaltenorientierte Daten 2130 wirksame Abfragen durchzuführen.
Benutzer können zum Beispiel Daten an Tabellen anhängen, neue Tabellen erstellen und das Teilen von Berechtigungen handhaben. Die Daten in den Tabellen können als spaltenorientierte Daten in der Speicherung für spaltenorientierte Daten 2132 gespeichert werden. Dementsprechend überträgt der Datenspeicherungs- und Verarbeitungsservice 2102 Daten aus der Objektspeicherung 2106 an die Speicherung für spaltenorientierte Daten 2132, wenn Daten in der Tabelle platziert werden. Der Importjobmanager 2108 handhabt das Verfahren der Datenübertragung und führt Konversionsoperationen für die Daten durch.
Jede Tabelle repräsentiert einen strukturierten Datensatz, den ein Benutzer über die Abfrage-API 2124 abfragen kann. Benutzer können Tabellen erstellen, Daten in Tabellen importieren, Abfragen zu Tabellen durchführen und die Tabellen in Pipelines der Datenanalyse einsetzen. Der Kontakt externer Benutzer zu einer Tabelle kann in Form eines Objektes erfolgen, das in der Objektspeicherung 2106 als Delegat-Objekt gespeichert ist. Ein Delegat-Objekt kann ein Objekt sein, das eine Benutzeroberfläche für einen Satz von Daten und Operationen bietet, die nicht in der Objektspeicherung 2106 gespeichert sind. Mit anderen Worten können Delegat-Objekte die Abbildung von Tabellen in den globalen Namensraum für die Objektspeicherung 2106 erlauben. Somit kann der Name jeder Tabelle im globalen Objekt-Namenraum residieren und einzigartig sein. Ein Delegat-Objekt für eine Tabelle kann Metadaten enthalten, die den Besitzer der Tabelle, die Liste der Zugangskontrolle für die Tabelle und den Tabellen-Identifikator identifizieren (der das Delegat-Objekt mit weiteren Metadaten der Tabelle verlinkt und nachstehend beschrieben wird).
Somit sieht ein externer Benutzer in einer Implementierung Tabellen als Objekte, die in Raster residieren. Der Benutzer kann eine Liste aller Tabellen in einem Raster sehen und eine Tabelle löschen, indem er das korrespondierende Delegat-Objekt löscht, fast genauso, wie der Benutzer eine Liste von Objekten einsehen und Objekte löschen kann. Wenn ein externer Benutzer eine Anforderung stellt, die eine Tabelle über ihren Objektnamen referenziert, wird eine Referenz zu den zugrunde liegenden Tabellendaten aus dem Delegat-Objekt extrahiert und zur Bedienung der Anforderung eingesetzt. Eine Löschoperation für eine Tabelle kann zum Beispiel Säuberungsoperationen für die korrespondierenden Metadaten in der Tabellen-Metadatenspeicherung 2120 und den zugrunde liegenden spaltenorientierten Daten in der Speicherung der spaltenorientierten Daten 2132 auslösen.
Eine Tabelle wird in Reaktion auf eine Anforderung durch die Tabellen-API 2134 erstellt. Das Tabellen-Managementsystem 2118 kann eine Tabelle bei einem Schlüssel einer Datenbank in der Tabellen-Metadatenspeicherung 2120 erstellen und dann ein Delegat-Objekt in der Objektspeicherung 2106 als Referenz für den Schlüssel einrichten. Die Tabellen-Metadatenspeicherung 2120 kann Metadaten für die Tabellen enthalten, die durch Delegat-Objekte referenziert werden. Ein Tabellen-Identifikator in einem Delegat-Objekt referenziert zum Beispiel einen Schlüssel in einer Zeile der Tabellen-Metadatenspeicherung 2120. Die Tabellen-Metadatenspeicherung 2120 speichert für die Tabelle und unter dem Schlüssel eine jegliche Kombination von: (1) dem Tabellen-Identifikator, (2) einer Tabellen-Revisionszahl, (3) einem Tabellennamen, (4) einem Datenreferenzsatz, (5) einer Schemabeschreibung und (6) Datenstatistiken.
Der Tabellenname kann ein auf ein oder mehrere Raster und Objekte zurückdeuten, mit denen die Tabelle assoziiert ist. Die Speicherung des Tabellennamens kann die Abfalleinsammlung erleichtern und bei der Vermeidung von Konflikten helfen, wenn die Tabelle gelöscht und später eine neue Tabelle gleichen Namens mit demselben externen (Objekt) Namen erstellt wird. Der Datenreferenzsatz kann Pfadreferenzen zu den spaltenorientieren Daten 2132 beinhalten, welche die Tabelle stützen (die z. B. die Massendaten für die Tabellen speichern). Die Beschreibung des Schemas kann die wirksame Schemenvalidierung im Verlauf von Operationen des Datenmanagements erlauben. Die Datenstatistiken können Informationen über die Tabelle identifizieren, wie zum Beispiel etwa die Zahl von Zeilen, den Umfang von durch die Tabelle referenzierten Daten und einen letzten aktualisierter Zeitstempel.
In einigen Beispielen wird eine Tabelle in Reaktion auf eine Anforderung durch einen Benutzer mit Daten aus Objekten in der Objektspeicherung 2106 gefüllt (z. B. einen Tabellen-API-Aufruf). Der Importjobmanager 2108 zum Beispiel kann eine Ad-hoc-Anforderung von einem Datenbesitzer empfangen, die Daten aus einem Satz von Objekten in der Datenspeicherung 2106 in eine Tabelle zu importieren. In anderen Beispielen kann ein Datenbesitzer einen Job generieren, der durch den Importjobmanager 2108 ausgeführt wird, und der einen kontinuierlichen Importservice einrichtet, der Objekte, die neu in einem Raster platziert werden, nimmt und die Daten in den Objekten in eine Tabelle „automatisch importiert”. Nachdem die Daten aus den Objekten in die Tabelle importiert sind, können die Objekte automatisch ohne Zutun des Benutzers gelöscht werden.
Der Importjobmanager 2108 empfängt Anforderungen für den Import von Daten aus einem Objekt in eine Tabelle und führt in Reaktion mehrere Operationen aus, um Daten in die Speicherung für spaltenorientierte Daten 2132 zu übertragen. Der Jobmanager 2108 erstellt Metadaten für den Job, um den Import mitzuverfolgen und startet einen Koordinator 2110. Die Metadaten für den Job werden in der Speicherung der Metadaten für den Job 2122 gespeichert.
Im Besonderen kann der Importjobmanager 2118 den Inhalt von Objekten aggregieren, Datenformattransformationen durchführen, die Daten in Bruchstücke angemessener Größe zerlegen, die Daten in eine andere Speicherschicht bewegen und die Datenbrocken in der Speicherung für spaltenorientierte Daten 2132 für den Zugriff durch das Verarbeitungssystem für spaltenorientierte Daten 2130 platzieren. In einigen Beispielen transformiert der Importjobmanager 2108 die Objektdaten in spaltenorientierte Daten. In anderen Beispielen platziert der Importjobmanager 2108 nicht spaltenorientierte Datenbrocken in der Speicherung für spaltenorientierte Daten 2132, und das Verarbeitungssystem für spaltenorientierte Daten 2130 konvertiert die nicht spaltenorientierte Datenbrocken in ein spaltenorientiertes Format.
Der Koordinator 2110 wird durch den Importjobmanager 2108 aufgerufen, einen Importjob zu analysieren und eine angemessene Anzahl von Arbeitern für die Verarbeitung der Daten innerhalb einer angemessenen Zeit zu starten. Der Koordinator 2110 analysiert die Objekte der Dateneingabe und entscheidet, wie er die Datenobjekte unter den einzelnen Arbeitern 2112 zuordnet, welche die Datenobjekte der Eingabe verarbeiten. Der Koordinator 2110 produziert einzelne Arbeiterinstanzen und beobachtet den Fortschritt der Arbeiter. Der Koordinator 2110 stellt sicher, dass die von jedem Arbeiter gehandhabte Datenmenge nicht zu klein oder zu groß ist.
In einigen Umständen kann der Einsatz eines einzelnen Koordinators und zahlreicher Arbeiter den Importjobmanager 2110 befähigen, den Datenumfang und eine Anzahl von Objekten der Dateneingabe zu skalieren. Wenn ein Ausfall entdeckt wird oder ein Arbeiter ineffizient ist, kann der Arbeiter erneut gestartet werden, oder die Aufgabe des Arbeiters kann neu zugeordnet werden. Jede Arbeiterinstanz 2112 kann sequentiell die Objekte der Dateneingabe lesen, angemessene Formatkonversionen durchführen und die Daten in fragmentierten Paketen von spaltenorientierten Daten 2132 speichern. In einigen Beispielen werden Arbeiterinstanzen zugeordnet, um in denselben Cluster zu laufen, in denen die Eingabedaten angesiedelt sind (weil der Verkehr über Datenzentren hinweg ineffizient und teuer sein kann).
Die Arbeiter konvertieren Daten aus einem beliebigen Satz von Eingaben in einen fragmentierten Satz von spaltenorientierten Datenpaketen und hängen die Pakete an die entsprechenden Tabellen an. Eingabedaten können jegliches schematisierte Datenformat haben, welches das System versteht. Eingabedaten können Text- oder Binärformat haben, und das Schema kann in das Datenformat inkorporiert oder gemeinsam mit den Daten spezifiziert werden. Musterhafte Dateneingaben können die folgenden sein: (1) eine Art Aufzeichnungsdaten (eine eigenständige und selbstbeschreibende Struktur für aufzeichnungsorientiert gespeicherte Daten), (2) eine Art spaltenorientierter Daten (eine eigenständige und selbstbeschreibende Struktur für spaltenorientiert gespeicherte Daten), (3) Formate auf Textbasis, für welche der Datenspeicherungs- und Verarbeitungsservice 2102 das Schema kennt (Formate mit getrennten Feldern oder mit fester Feldlänge wie etwa Apache, AppEngine oder W3CProtokolle), oder (4) textbasierte Formate, die mit Wertepaaren für Namen/Typ beschrieben werden können (Formate mit separaten Feldern oder mit fester Feldlänge, und der Benutzer spezifiziert die Paare für Namen/Typ und Separatoren oder Feldgrößen).
Der Koaleszer und Abfallsammler 2114 kann Tabellen periodisch auf Probleme abtasten, die es zu lösen gilt. Der Koaleszer kann die Inhalte der spaltenorientierten Datenspeicherung 2132 überwachen und spaltenorientierte Datenpakete entdecken, die zu klein sind und in größere Pakete koalesziert werden können. Der Abfallsammler entdeckt spaltenorientierte Datenpakete, die durch keine Tabelle referenziert sind und gelöscht werden können. Auf ähnliche Weise können hängende Metadaten von Tabellen entsorgt werden, wenn zum Beispiel eine Tabelle erstellt wird, der Erstellungsprozess der Tabelle jedoch fehlschlägt, bevor ein korrespondierendes Delegat-Objekt in der Objektspeicherung 2106 generiert wird.
Sobald eine Tabelle erstellt ist und Daten in die Tabelle importiert wurden (z. B. durch die Generierung von Tabellen-Metadaten, die Generierung des Delegat-Objektes in der Datenspeicherung 2106 und die Generierung korrespondierender spaltenorientierter Daten 2132), können für die Tabellen Benutzerabfragen durchgeführt werden. Die Abfragen können SQL-ähnlich sein und von externen Benutzern über die Abfragen-API 2124 empfangen werden. Der Front-End-Server 2126 empfängt die Anforderungen der Abfragen-API und leitet die Anforderungen an den API-Sammelimplementor 2116 weiter, der die Abfragen an den Abfragenmanager 2128 weiterleitet.
Der Abfragenmanager 2128 übernimmt die SQL-ähnlichen Abfragen sowie ein authentifiziertes Token für den externen Benutzer, vergewissert sich, dass der externe Benutzer auf die in der Abfrage referenzierten Tabellen zugreifen kann und leitet die Anforderung an das Verarbeitungssystem für spaltenorientierte Daten 2130 und das Tabellenmanagementsystem 2118 zwecks Durchführung der Abfrage weiter. Wie bereits zuvor in dem Dokument beschrieben, kann das Verarbeitungssystem für spaltenorientierte Daten 2130 spaltenorientierte Daten 2132 und Ergebnisdaten der Ausgabe (z. B. Spalten mit Ergebnisdaten) abfragen. Die Ergebnisdaten können in einer durch die Abfrage definierten Tabelle platziert, an den externen Benutzer in einem durch Datenformatvorlagen definierten Format zurückgegeben oder in einem in dem API-Aufruf definierten Objekt platziert werden.
Der API-Sammelimplementor 2116 handhabt API-Aufrufe über die Objekte-API 2104, Tabellen- API 2134 und die Abfragen-API 2124. Musterhafte API-Funktionen werden nachstehend im Einzelnen dargestellt.
Objekte-API
ObjectStorage.DeleteObject(string object): Ein Objekt oder eine Tabelle löschen (z. B. durch die Veranlassung des Delegat-Objektes, Operationen zur Entfernung der Tabelle aufzurufen).
ObjectStorage.ListObjects(string bucket): Listet die Objekte und Tabellen in einem Raster. Objekte können ein Tag enthalten, der die Kennzeichnung der Objekte als Tabellen oder andere Datentypen zulässt. Somit kann die beschriebene API-Funktion ListObjects einen optionalen Parameter enthalten, der die innerhalb eines Rasters aufzulistenden Objekttypen identifiziert.
ObjectStorage.PutObject(string object): Treibt Daten aus dem Computergerät eines externen Benutzers in die Objektspeicherung 2106.
ObjectStorage.GetObject(string object): Sendet ein Objekt an das Computergerät eines externen Benutzers aus der Objektspeicherung 2106 zurück. Wenn für einen tableName eingesetzt, kann der API-Aufruf GetObject das Folgende zurückbringen: (1) das Äquivalent einer Erklärung für ”select * from tableName”, (2) eine Beschreibung des Inhalts der Tabelle, die Tabellenreferenzen und die der Tabelle hinzugefügten Aufzeichnungen oder (3) Metadaten über die Tabelle.
Tabellen-API
CreateTable(string bucket, string tableName, ACLs): Erstellt Tabellen in der Objektspeicherung 2106 mit dem spezifizierten Namen tableName, mit auf die Tabelle angewandten optionalen Listen der Zugriffskontrolle.
ImportRecords (string sourceBucket, string sourceObject, string dataFormat, string destBucket, string destTableName, ImportToken importToken, Boolean extendSchema = true): Initiiert unter Einsatz von dataFormat einen asynchronen Import von Daten nach destTableName, um festzustellen, wie der Inhalt im sourceObject zu lesen ist. Wenn extendSchema zutrifft, dann wird das Schema von destTableName erweitert, um alle importierten Daten zu unterstützen. Wenn extendSchema nicht zutrifft, dann werden Objekte ignoriert, die Datenaufzeichnungen umfassen, welche dem bestehenden Schema von destTableName oder den Datenaufzeichnungen nicht entsprechen. ImportToken speichert einen Pointer für den durch einen Aufruf initiierten Importjob unter Einsatz der Funktion ImportRecords.
GetImportStatus(ImportToken importToken): Stellt den Status des mit importToken assoziierten Import-Aufrufs wieder her. Der wiederhergestellte Status kann angeben, ob der Import abgeschlossen oder noch im Gange ist, die Anzahl der importierten Aufzeichnungen und die Anzahl der Aufzeichnungen mit Fehlern anzeigen.
CreateContinuousImportService(Bucket sourceBucket, FormatDescription sourceFormat, Object destinationTable, Object importServiceName): Startet eine Importaufgabe, die sourceBucket für neue Objekte beobachtet. Wenn die neuen Objekte nach sourceBucket geladen werden (z. B. von externen Benutzern), importiert die Aufgabe die Daten in den Objekten zur Zieltabelle. Das Serviceattribut sourceFormat identifiziert das Format der Objekte in sourceBucket. Der Importservice hat einen Namen im Namenraum der Objekte und bietet externen Benutzern die Fähigkeit, Autorisierungsoperationen für Importservices aufzulisten, zu löschen und durchzuführen.
GetContinuouslmportServiceStatus(Object importServiceName): Bringt Informationen zurück, die beschreiben, ob der importServiceName vollständig oder noch im Gange ist. Kann auch beliebige kürzliche Fehler zurücksenden.
Abfragen-API
Query(String sqlQuery, ExportEnum exportAs): Führt eine Abfrage des Typs sqlQuery durch und sendet Daten in dem durch exportAs spezifizierten Format zurück. Das Format der zurückgesandten Daten kann csv, xml, json und viz sein. In einigen Beispielen können GViz SQL und Pig Latin anstatt von SQL eingesetzt werden. Das Feld exportAs kann optional sein, wenn die Abfrage sqlQuery eine Tabelle für den Erhalt der Datenausgabe definiert.
Query(String sqlQuery, ExportEnum exportAs, Object exportToObject): Speichert die Ergebnisse der Abfrage sqlQuery im Objekt exportToObject.
Die Sammlung von APIs kann die Erstellung SQL-ähnlicher Zusammenfassungen für große Datenmengen ermöglichen, die aus der Objektspeicherung 2106 in Tabellen importiert werden. Die Quellenobjekte in Objektspeicherung 2106 können aus zahlreichen Web-Quellen aggregiert werden, worin jede Quelle die Berechtigung hat, Daten in demselben Raster der Objektspeicherung 2106 zu platzieren. Somit kann der illustrierte Datenspeicherungs- und Verarbeitungsservice 2102 eine Aggregation und eine Pipeline des Datenimports für das zuvor in diesem Dokument beschriebene Verarbeitungssystem für spaltenorientierte Daten 2130 bieten. Das Verarbeitungssystem für spaltenorientierte Daten 2130 kann schnelle Abfragen und Aggregationen von großen Datensätzen bereitstellen.
Zusätzlich zu den zuvor in diesem Dokument beschriebenen SQL-ähnlichen Operationen kann ein externer Benutzer Daten in Tabellen einer JOIN-Funktion (Verknüpfung) unterziehen. Weil das beschriebene Verarbeitungssystem für spaltenorientierte Daten 2130 als ein Baum von Ausgabebruchstücken organisiert werden kann, in dem jedes Bruchstück mit seinen Ablegern und Elternteilen kommuniziert, kann die Einführung einer allgemeinen JOIN-Funktion die Hinzufügung einer Kommunikationskapazität zwischen allen Paaren von Blatt-Bruchstücken erforderlich machen. Die (lokale) JOIN-Funktion, die an Eingabetabellen arbeiten kann, die für ein Blatt spezifisch sein kann, kann zunächst durch die Ausgabe eines SHUFFLE-Befehls (Aufmischen) global arbeiten.
Der SHUFFLE-Befehl stellt sicher, dass Tupel, die verknüpft werden sollen, sich auf demselben Bruchstück befinden. Eine JOIN-Operation R JOIN S ON R.f1 = S.f2 kann zum Beispiel ausgedrückt werden, indem zunächst R durch f1 und S durch f2 aufgemischt wird. Die Semantik des Aufmischens gewährleistet, dass alle Tupel von R mit einem gegebenen Wert für f1 dann auf einem Tablet sein und alle Tupel von S, die denselben Wert für f2 haben, sich auf einem korrespondierenden Tablet befinden werden. Daher kann nach Abschluss des Aufmischens eine (lokale) JOIN-Funktion denselben Effekt haben wie eine globale Verknüpfung.
In verschiedenen Beispielen werden die durch den Datenspeicherungs- und Verarbeitungsservice 2102 gespeicherten Daten unter geographisch verteilten Servergeräten reproduziert. Ein Objekt zum Beispiel, das in der Objektspeicherung 2106 gespeichert ist, kann unter Servergeräten in Datenzentren reproduziert werden, die hunderte von Kilometern voneinander entfernt sind. Daher kann es sein, dass ein Serverversagen, ein Stromausfall oder eine Naturkatastrophe auf lokaler Ebene die Verfügbarkeit des Objektes nicht beeinflussen. Auf ähnliche Weise können die spaltenorientierten Streifen, die der Tabelle zugrunde liegen und in der spaltenorientierten Datenspeicherung 2132 residieren, unter geographisch verteilten Servergeräten reproduziert werden, nachdem die Daten in dem Objekt in eine Tabelle importiert wurden. Die Metadaten der Tabelle, die in der Metadatenspeicherung der Tabelle 2120 gespeichert sind, können ebenfalls unter geographisch verteilten Servergeräten reproduziert werden.
22 ist ein Flussdiagramm, welches das Beispiel eines Verfahrens 2200 zur Durchführung von Datenspeicherung und -verarbeitung zeigt. Das Verfahren 2200 kann von dem in 21 illustrierten System, und vor allem dem Datenspeicherungs- und Verarbeitungsservice 2102 durchgeführt werden.
In Box 2202 wird eine Anforderung zur Speicherung von Daten in einem Serversystem empfangen. Ein Serversystem zum Beispiel, das den Datenspeicherungs- und Verarbeitungsservice 2102 bietet, kann eine API implementieren, die entfernte Computergeräte befähigt, Daten in das Serversystem zum Beispiel über das Internet hochzuladen. Das Serversystem kann einen Funktionsaufruf für das Hochladen von Daten über die API und von einem entfernten Computergerät empfangen. Der Funktionsaufruf kann Daten für das Hochladen und einen Namen für die Daten identifizieren. Der Name für die Daten kann einen Speicherstandort für Daten identifizieren (z. B. ein Raster).
In einigen Beispielen kann die Anforderung von einem Computergerät empfangen werden, das nicht auf den Datenspeicherungs- und Verarbeitungsservice 2102 zugreift. Eine dritte Partei kann zum Beispiel ein oder mehrere physische Speichergeräte (z. B. CDs, DVDs, Festplatten oder RAID-Gehäuse) physisch an eine Geschäftseinheit versenden, die den Datenspeicherungs- und Verarbeitungsservice 2102 betreibt. Angestellte der Geschäftseinheit können die Daten, die sich in dem physischen Speichergerät befinden, mit Hilfe eines Computergerätes, das an den Datenspeicherungs- und Verarbeitungsservice 2102 angeschlossen ist, mit Hilfe eines lokalen Netzwerks in die Objektspeicherung 2106 laden. Es kann sein, dass die lokale Übertragung von Daten in die Objektspeicherung 2106 die API nicht benutzt.
In Box 2204 werden die identifizierten Daten als Objekt in einem Repository im Serversystem gespeichert. Das Repository kann eine Sammlung von „Buckets” (Raster) enthalten, von denen jedes für die Aufnahme von einem oder mehreren Objekten konfiguriert ist. Jedes Raster kann einen Namen haben, der in der Rastersammlung einzigartig ist, und die Objekte in jedem Raster können Namen haben, für das Raster einzigartig ist. Somit kann jedes Objekt durch einen einzigartigen Namenpfad ansprechbar sein (z. B. bucketName.objectName). Jedes Raster kann im Besitz eines oder mehrerer externer Kunden sein.
Die Speicherung der Daten (z. B. eine Aufzeichnung, eine Sammlung von Aufzeichnungen, Datei oder Dateisammlung) als Objekt kann die Feststellung umfassen, dass das die Daten hochladende entfernte Gerät berechtigt ist, Objekte in dem identifizierten Raster zu platzieren. Ein externer Kunde kann zum Beispiel ein Raster erstellen und spezifische Benutzerkonten mit der Berechtigung für die Platzierung von Daten in dem Raster und Einsicht in die Inhalte des Rasters zuordnen. Wenn ein entferntes Gerät, das sich mit einem der spezifischen Konten angemeldet hat, die Platzierung von Daten in dem Raster anfordert, kann der Anforderung stattgegeben werden. Ähnliche Anforderungen von nicht berechtigten Benutzerkonten können zurückgewiesen werden.
In Box 2206 wird die Anforderung zur Erstellung einer Tabelle empfangen. Der Datenspeicherungs- und Verarbeitungsservice 2102 kann einen API-Funktionsaufruf von einem entfernten Computergerät empfangen, der die Erstellung einer Tabelle verlangt. Eine Tabelle kann ein strukturierter Datensatz sein, den ein Benutzer abfragt. Die Anforderung kann einen Namen für die Tabelle und Felder für die Tabelle definieren. Die Anforderung kann zum Beispiel ein Schema beinhalten, das eine Struktur für eine Art Aufzeichnung definiert, und die Tabelle kann generiert werden, um Daten für Aufzeichnungen dieser Art zu speichern.
In Box 2208 wird die Tabelle erstellt. Metadaten für die Tabelle können zum Beispiel unter eine Zeile in einer Datenbank hinzugefügt werden. Ein Delegat-Objekt, das die Tabellenzeile referenziert, kann im Repository des Objektes platziert werden. Wenn der API-Aufruf zum Beispiel die Generierung einer Tabelle namens bucketName.TableName verlangt, kann ein Objekt namens TableName in dem Raster bucketName platziert werden. Das Delegat Objekt namens TableName kann eine Liste der Zugriffskontrolle für die Tabelle und einen Tabellenidentifikator beinhalten (z. B. einen Identifikator der Datenbankzeile, die Metadaten für die Tabelle speichert).
In Box 2210 wird eine Anforderung für den Import von im Objekt befindlichen Daten in die Tabelle empfangen. Der Datenspeicherungs- und Verarbeitungsservice 2102 kann von einem entfernten Computergerät einen ABI-Funktionsaufruf empfangen, der die Ladung der in dem Objekt befindlichen Daten in die Tabelle oder deren Anhängen an das Ende einer Tabelle verlangt, die bereits Daten enthält. In einigen Beispielen wird die Anforderung von einem kontinuierlichen Importservice empfangen. Der kontinuierliche Importservice kann periodische ein Raster überwachen, und wenn das Raster neue Objekte enthält (z. B. wenn externe Kunden neue Objekte in dem Raster platzieren), verlangt der kontinuierliche Importservice, dass Daten in den neuen Objekten an die Tabelle angehängt werden. In einigen Beispielen wurde ein API-Aufruf, der den kontinuierlichen Importservice einrichtet, früher empfangen. Die kundenseitige Ansicht des kontinuierlichen Importservices kann ein Delegat-Objekt sein.
In Box 2212 werden die Daten in dem Objekt in ein spaltenorientiertes Format konvertiert. Das Objekt kann zum Beispiel einen Satz von Aufzeichnungen enthalten, und die Aufzeichnungen können in einen Satz spaltenorientierter Streifen konvertiert werden, worin jeder Streifen (oder jeder Satz von Blöcken eines Streifens) ein einziges Attributfeld der Aufzeichnungen beschreibt. Die spaltenorientierten Streifen können die überall in diesem Dokument beschriebenen Wiederholungs- und Definitionsebenen beinhalten.
In Box 2214 werden die spaltenorientierten Daten in einem Repository gespeichert. In einigen Beispielen ist das Repository für die spaltenorientierten Daten anders, als das Repository für die Objekte. Ein Repository zum Beispiel kann eine andere Speicherschicht sein, die in einem Serversystem implementiert ist, die den Datenspeicherungs- und Verarbeitungsservice 2102 implementiert. Metadaten, die die spaltenorientierten Daten referenzieren, können in der Tabellendatenbank gespeichert werden. Somit kann eine Abfrage für die Tabelle eine Referenzierung der Metadaten in der Tabellendatenbank beinhalten, um spaltenorientierte Daten zu identifizieren, die mit bestimmten Attributfeldern für die Daten in der Tabelle korrespondieren.
In einigen Beispielen identifiziert die Anforderung mehrere Objekte, für die Daten in die Tabelle zu laden sind. Der Dateninhalt der Objekte kann aggregiert sein, es können Datenformattransformationen durchgeführt werden, die Daten können in angemessen große Brocken spaltenorientierter Daten fragmentiert werden, und die Brocken spaltenorientierter Daten können in dem Repositorium für spaltenorientierte Daten platziert werden.
In Box 2216 wird eine Anforderung für die Durchführung einer Abfrage für die Tabelle empfangen. Der Datenspeicherungs- und Verarbeitungsservice 2102 zum Beispiel kann einen API-Funktionsaufruf von einem entfernten Computergerät mit der Anforderung der Durchführung einer SQL-ähnlichen Abfrage für die Tabelle empfangen. In einigen Beispielen operiert die Abfrage mit der Tabelle und einer oder mehreren weiteren Tabellen. Die Abfrage kann zum Beispiel aus jeder von zwei Tabellen Daten sammeln, die bestimmte Charakteristika aufweisen und die aggregierten Daten in einer dritten Tabelle platzieren.
In Box 2218 wird festgestellt, ob das entfernte Computergerät, das die Abfrage anfordert, für den Zugriff auf die eine oder mehrere in der Abfrage spezifizierte/n Tabelle/n berechtigt ist. Das Delegat-Objekt für jede Tabelle kann zum Beispiel eine Liste der Zugriffskontrolle haben, die Benutzerkonten identifiziert, und die Abfragen für die mit dem Delegat-Objekt korrespondierende Tabelle durchführen, die Tabelle löschen und der Tabelle Daten hinzufügen kann. Wenn ein entferntes, mit einem Benutzerkonto assoziiertes Computergerät versucht, eine Abfrage für mehrere Tabellen durchzuführen, bestimmt der Datenspeicherungs- und Verarbeitungsservice 2102, ob das Benutzerkonto für Abfrage jeder dieser Tabellen berechtigt ist.
In Box 2220 wird eine Abfrage für spaltenorientierte Daten vorgenommen. Abfragen werden zum Beispiel für die spaltenorientierten Daten vorgenommen, die den in der Abfragenanforderung spezifizierten Tabellen zugrunde liegen. Ein Abfragenmanager 2128 kann auf der Grundlage der von dem entfernten Computergerät empfangenen Abfrage Komponentenabfragen vornehmen, die für bestimmte Spalten von Daten für die durch die Abfrage spezifizierten Tabellen durchgeführt werden. Die Abfrage kann zum Beispiel Daten innerhalb einer bestimmten Bandbreite für ein einziges Attribut in einer Tabelle anfordern. Der Abfragenmanager 2128 kann eine Komponentenabfrage für eine Sammlung von Blöcken eines spaltenorientierten Streifens generieren, der mit dem einzelnen Attribut assoziiert ist und kann andere Komponentenabfragen für spaltenorientierte Streifen für andere der Attribute in der Abfrage vornehmen.
In Box 2222 werden Daten auf der Grundlage der Abfrage ausgegeben. Die Abfrage kann eine Tabelle identifizieren, in die die Ergebnisse der Abfrage platziert werden sollen. Dementsprechend können der Abfragenmanager 2128, das Tabellenmanagementsystem 2118 und das Verarbeitungssystem für spaltenorientierte Daten 2130 die Ergebnisdaten in einer Tabelle platzieren. Die Abfrage kann auch ein oder mehrere Objekte identifizieren, in das/die die Ergebnisse der Abfrage zu platzieren sind. Somit können die Ergebnisse der Abfrage in ein oder mehrere Objekte in der Objektspeicherung 2106 platziert werden. Der API-Abruf, der die Platzierung der Daten in dem Objekt anfordert, kann ein Datenformat für die Speicherung der Daten in dem Objekt spezifizieren. Dementsprechend kann die Ausgabe der Daten als ein oder mehrere Objekte die Konversion der Ausgabespalten von in der Speicherung für spaltenorientierte Daten 2132 gespeicherten spaltenorientierten Daten in einer anderen Art des Datenformats für die Speicherung in der Objektspeicherung 2106 beinhalten (z. B. in einer aufzeichnungsorientierten Art des Datenformats).
In einigen Beispielen kann das Schema erweiterungsfähig sein. Mit anderen Worten kann eine dritte Partei geringfügige Änderungen des Schemas anfordern (z. B. durch die Bearbeitung des Schemas über eine API oder das Hochladen eines neuen Schemas, das geringfügige Änderungen umfasst). Die geringfügigen Änderungen können die Hinzufügung neuer optionaler Felder zu dem Schema beinhalten. In einigen Beispielen jedoch kann es sein, dass der Benutzer nicht fähig ist, dem Schema neue erforderliche Felder hinzuzufügen oder bestehende erforderliche Felder aus dem Schema zu entfernen. Das Schema kann aktualisiert werden, ohne den gesamten Datensatz neu aufzubauen oder zu regenerieren. Solcherart kann ein neuer spaltenorientierter Streifen für ein neu hinzugefügtes optionales Feld ohne die Modifizierung der bestehenden spaltenorientierten Streifen hinzugefügt werden.
In einigen Beispielen kann ein Drittparteibenutzer in der Lage sein, Feldnamen zu ändern und Pseudonyme für Feldnamen hinzuzufügen. Ein Schema kann zum Beispiel ein Feld namens „Zeit” umfassen. Ein Drittparteibenutzer kann beschließen, den Namen des Feldes in „Lokalzeit” zu ändern. Solcherart können neu eingereichte Datenaufzeichnungen Felder für die „Lokalzeit” umfassen, während bereits durch den Datenspeicherungs- und Verarbeitungsservice 2102 gespeicherte Datenaufzeichnungen Felder der „Zeit” enthalten können. Der Datenspeicherungs- und Verarbeitungsservice 2102 kann die Felder „Zeit” und „Lokale Zeit” als Pseudonyme für einander erkennen. Als Beispiel kann der Datenspeicherungs- und Verarbeitungsservice 2102 einen Index speichern, der Feldnamen mit einem einzigartigen Identifikator für ein Datenelement abstimmt. Der Index kann die Pseudonyme sowohl für die „Zeit” als auch die „Lokale Zeit” mit einem einzigartigen Identifikator für ein Feld assoziieren (z. B. mit dem Identifikator „1A452BC”). Solcherart kann der einzigartige Identifikator mit einem einzelnen spaltenorientierten Streifen assoziiert werden und ihn für alle Datenwerte der Felder „Zeit” und „Lokale Zeit benennen. In einigen Beispielen identifizieren die in der Objektspeicherung 2106 gespeicherten Datenaufzeichnungen auch Felder mit einzigartigen Identifikatoren und identifizieren keine Felder mit Namen, die sich ändern können.
Die Daten können auch direkt an das entfernte Computergerät ausgegeben werden, zusätzlich zu oder anstelle von der Platzierung der Daten in einer Tabelle oder einem Objekt. Ein die Abfrage anforderndes entferntes Computergerät zum Beispiel kann in Reaktion die Ergebnisse der Abfrage empfangen. Die Ergebnisse der Abfrage können in verschiedenen Formaten sein (z. B. CSV oder Daten für die Rekonstruktion einer Anzeige der Ausgabetabelle).
23 ist ein Blockdiagramm der Computergeräte 2300, 2350, die zur Implementierung der in diesem Dokument beschriebenen Systeme und Verfahren benutzt werden können, entweder als Client oder als Server oder als eine Vielzahl von Servern. Computergerät 2300 soll verschiedene Formen von Digitalcomputern darstellen, wie etwa Laptops, Desktops, Workstations, Personal Digital Assistants, Server, Blade Server, Mainframes und andere geeignete Computer. Computergerät 2350 soll verschiedene Formen mobiler Geräte, wie etwa Personal Digital Assistants, Mobiltelefone, Smartphones und andere ähnliche Computergeräte darstellen. Zusätzlich kann das Computergerät 2300 oder 2350 Flash-Laufwerke von USB-Speichermedien (Universal Serial Bus) beinhalten. Die USB-Speichermedien können Betriebssysteme und andere Anwendungen speichern. Die USB-Flashlaufwerke können Eingabe-/Ausgabekomponenten, wie z. B. einen kabellosen Transmitter oder USB-Anschluss enthalten, der in eine USB-Schnittstelle eines anderen Computers eingesteckt werden kann. Die hier gezeigten Komponenten, ihre Verbindungen und Beziehungen sowie ihre Funktionen sind im rein beispielhaften Sinne zu erachten und stellen keine Einschränkung der in diesem Dokument beschriebenen und/oder beanspruchten Implementierungen dar.
Computergerät 2300 beinhaltet einen Prozessor 2302, Speicher 2304, ein Speichergerät 2306, eine High-Speed-Oberfläche 2308, die mit Speicher 2304 und High-Speed-Erweiterungsanschlüssen 2310 verbunden ist sowie eine Low-Speed-Schnittstelle 2312, die an Low-Speed-Bus 2314 und Speichergerät 2306 angeschlossen ist. Alle der Komponenten 2302, 2304, 2306, 2308, 2310 und 2312 sind unter Einsatz verschiedener Busse miteinander verbunden und können an einer gemeinsamen Hauptplatine oder auf andere Weise, wie geeignet, angebracht sein. Der Prozessor 2302 kann Anweisungen für die Ausführung im Computergerät 2300 verarbeiten, darunter auch Anweisungen, die im Speicher 2304 oder Speichergerät 2306 gespeichert sind, um graphische Informationen für eine graphische Benutzeroberfläche (graphic unser interface, GUI) auf einem externen Eingabe-/Ausgabegerät anzuzeigen, zum Beispiel Anzeige 2316, gekoppelt mit der High-Speed-Oberfläche 2308. In anderen Implementierungen können mehrere Prozessoren und/oder mehrere Busse verwendet sein, wie angemessen, zusammen mit mehreren Speichern und Speichertypen. Außerdem können multiple Computergeräte 2300 angeschlossen sein, worin jedes Gerät Teile der nötigen Operationen liefert (z. B. als Serverbank, eine Gruppe von Blade-Servern oder ein Multiprozessor-System).
Der Speicher 2304 speichert Informationen im Computergerät 2300. In einer Implementierung stellt der Speicher 2304 eine flüchtige Speichereinheit oder flüchtige Speichereinheiten dar. In einer anderen Implementierung stellt der Speicher 2304 eine nicht-flüchtige Speichereinheit oder nicht-flüchtige Speichereinheiten dar. Der Speicher 2304 kann auch eine andere Form von computerlesbarem Medium sein, zum Beispiel ein magnetischer oder optischer Datenträger.
Das Speichergerät 2306 ist geeignet, Massenspeicherung für das Computergerät 2300 bereitzustellen. In einer Ausführungsform kann das Speichergerät 2306 ein computerlesbares Medium sein oder enthalten, zum Beispiel ein Diskettenlaufwerk, ein Festplattenlaufwerk, ein optisches Datenträgergerät oder ein Bandgerät, einen Flash-Speicher oder ein anderes ähnliches Solid-State-Speichergerät oder eine Reihe von Geräten, zum Beispiel Geräte in einem Storage Area Network oder anderen Konfigurationen. Ein Computerprogrammprodukt kann konkret in einem Informationsträger ausgeführt sein. Das Computerprogrammprodukt kann auch Anweisungen enthalten, die, wenn sie ausgeführt werden, ein oder mehrere Verfahren durchführen, wie die oben beschriebenen. Der Informationsträger ist ein computer- oder maschinenlesbares Medium, wie der Speicher 2304, das Speichergerät 2306 oder der Prozessorspeicher 2302.
Der High-Speed-Controller 2308 verwaltet bandbreitenintensive Operationen für das Computergerät 2300, während der Low-Speed-Controller 2312 Operationen einer geringeren Brandbreitenintensität verwaltet. Eine solche Zuordnung von Funktionen ist nur exemplarisch. In einer Ausführungsform ist der High-Speed-Controller 2308 mit einem Speicher 2304, einer Anzeige 2316 (z. B. über einen Graphikprozessor oder -beschleuniger) und mit High-Speed-Erweiterungsanschlüssen 2310 gekoppelt, die verschiedene Erweiterungskarten aufnehmen können (nicht dargestellt). In der Implementierung ist der Low-Speed-Controller 2312 mit Speichergerät 2306 und Low-Speed-Erweiterungsanschluss 2314 gekoppelt. Der Low-Speed-Erweiterungsanschluss, der verschiedene Datenübertragungsanschlüsse (z. B. USB, Bluetooth, Ethernet, Funkethernet) beinhalten kann, kann mit einem oder mehreren Eingabe-/Ausgabe-Geräten, wie eine Tastatur, ein Zeigegerät, ein Scanner oder ein Netzwerkgerät, wie etwa einen Switch oder Router, z. B. über einen Netzwerkadapter verbunden sein.
Das Computergerät 2300 kann in einer Reihe verschiedener Formen implementiert werden, wie in der Figur gezeigt. Es kann zum Beispiel als Standardserver 2320 oder mehrmals in einer Gruppe solcher Server implementiert sein. Es kann auch als Teil eines Rackserversystems 2324 implementiert sein. Außerdem kann es in einem Personalcomputer wie ein Laptop-Computer 2322 implementiert sein. Alternativ können Komponenten von Computergerät 2300 mit anderen Komponenten in einem mobilen Gerät kombiniert sein (nicht dargestellt), wie etwa Gerät 2350. Jedes solcher Geräte kann eines oder mehrere Computergeräte 2300, 2350 enthalten, und ein gesamtes System kann aus mehreren Computergeräten 2300, 2350 bestehen, die miteinander kommunizieren.
Computergerät 2350 beinhaltet neben anderen Komponenten einen Prozessor 2352, Speicher 2364, ein Eingabe-/Ausgabegerät, wie Anzeige 2354, eine Kommunikationsoberfläche 2366 und einen Sender 2368. Das Gerät 2350 kann auch mit einem Speichergerät ausgestattet sein, zum Beispiel einem Microdrive oder anderem Gerät, um zusätzliche Speicherung bereitzustellen. Alle der Komponenten 2350, 2352, 2364, 2354, 2366 und 2368 sind unter Einsatz verschiedener Busse miteinander verbunden, und mehrere der Komponenten können an einer gemeinsamen Hauptplatine oder auf andere Weise, wie geeignet, angebracht sein.
Der Prozessor 2352 kann Anweisungen im Computergerät 2350 ausführen, darunter auch Anweisungen, die im Speicher 2364 gespeichert sind. Der Prozessor kann als ein Chipsatz von Chips implementiert werden, die separate und mehrere analoge und digitale Prozessoren beinhalten. Zusätzlich dazu kann der Prozessor mit einer beliebigen Anzahl von Architekturen implementiert werden. So kann der Prozessor 410 beispielsweise ein CISC-Prozessor (Complex Instruction Set Computers), ein RISC-Prozessor (Reduced Instruction Set Computer) oder ein MISC-Prozessor (Minimal Instruction Set Computer) sein. Der Prozessor kann zum Beispiel für die Koordination der anderen Komponenten des Geräts 2350 sorgen, zum Beispiel die Kontrolle von Benutzeroberflächen, Anwendungen, die vom Gerät 2350 ausgeführt werden, und die drahtlose Kommunikation durch Gerät 2350.
Prozessor 2352 kann mit einem Benutzer über Steueroberfläche 2358 und Anzeigenoberfläche 2356 kommunizieren, die mit einer Anzeige 2354 gekoppelt ist. Die Anzeige 2354 kann zum Beispiel eine TFT Anzeige (Thin-Film-Transistor Liquid Crystal Display) oder eine OLED-Anzeige (Organic Light Emitting Diode) oder eine andere geeignete Anzeigentechnologie sein. Die Anzeigenoberfläche 2356 kann eine geeignete Schaltung enthalten, die die Anzeige 2354 veranlasst, einem Benutzer graphische und andere Informationen zu präsentieren. Die Steueroberfläche 2358 kann Befehle von einem Benutzer empfangen und sie für die Übertragung an Prozessor 2352 konvertieren. Außerdem kann eine externe Oberfläche 2362 in Kommunikation mit Prozessor 2352 bereitgestellt werden, um die Nahbereichskommunikation von Gerät 2350 mit anderen Geräten zu ermöglichen. Die externe Oberfläche 2362 kann zum Beispiel in einigen Implementierungen eine kabelgebundene Kommunikation oder in anderen Implementierungen eine drahtlose Kommunikation bereitstellen, und es können auch mehrere Oberflächen verwendet werden.
Der Speicher 2364 speichert Informationen im Computergerät 2350. Der Speicher 2364 kann als ein oder mehrere computerlesbare Medien, eine oder mehrere flüchtige Speichereinheiten oder eine oder mehrere nicht-flüchtige Speichereinheiten implementiert werden. Erweiterungsspeicher 2374 kann ebenfalls bereitgestellt und mit dem Gerät 2350 über Erweiterungsoberfläche 2372 verbunden werden, die zum Beispiel eine SIMM-Kartenoberfläche (Single In Line Memory Module) beinhalten kann. Ein solcher Erweiterungsspeicher 2374 kann zusätzlichen Speicherplatz für Gerät 2350 bieten oder auch Anwendungen oder andere Informationen für Gerät 2350 speichern. Insbesondere kann Erweiterungsspeicher 2374 Anweisungen für die Ausführung oder Ergänzung der oben beschriebenen Prozesse enthalten und außerdem sichere Informationen enthalten. Somit kann Erweiterungsspeicher 2374 zum Beispiel als Sicherheitsmodul für Gerät 2350 bereitgestellt werden und mit Anweisungen programmiert sein, die die sichere Verwendung von Gerät 2350 erlauben. Zusätzlich dazu können über die SIMM-Cards sichere Anwendungen bereitgestellt werden, zusammen mit zusätzlichen Informationen, wie dem Ablegen von Identifizierungsinformationen auf der SIMM-Card auf eine Weise, die nicht gehackt werden kann.
Der Speicher kann beispielsweise Flash- und/oder NVRAM-Speicher beinhalten, wie nachstehend erörtert. In einer Implementierung ist ein Computerprogrammprodukt greifbar in einem Informationsträger ausgeführt. Das Computerprogrammprodukt enthält Anweisungen, die, wenn sie ausgeführt werden, ein oder mehrere Verfahren durchführen, wie die oben beschriebenen. Der Informationsträger ist ein computer- oder maschinenlesbares Medium, wie der Speicher 2364, die Speichererweiterung 2374 oder der Prozessorspeicher 2352, das zum Beispiel über den Sender-Empfänger 2368 oder die externe Oberfläche 2362 empfangen werden kann.
Das Gerät 2350 kann drahtlos über Kommunikationsoberfläche 2366 kommunizieren, die, wo erforderlich, digitale Signalverarbeitungsschaltkreise beinhalten kann. Die Kommunikationsoberfläche 2366 kann mittels verschiedener Modi oder Protokolle für Kommunikation sorgen, wie unter anderem etwa GSM-Sprachaufrufe, SMS, EMS oder MMS-Nachrichten, Messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000 oder GPRS. Eine solche Kommunikation kann zum Beispiel über Funkfrequenzsender und -empfänger 2368 erfolgen. Zusätzlich kann eine Kurzstreckenkommunikation stattfinden, wie unter Verwendung eines Bluetooth-, WLAN- oder anderen solchen Sende-Empfängers (nicht gezeigt). Außerdem kann das GPS-Empfängermodul (Global Positioning System) 2370 zusätzliche mit Navigation und Standort verbundene drahtlose Daten für Gerät 2350 bereitstellen, die von Anwendungen genutzt werden können, die auf Gerät 2350 umgesetzt werden.
Das Gerät 2350 kann unter Einsatz des Audio-Codec 2360, das gesprochene Informationen von einem Benutzer empfangen und diese in nutzbare digitale Informationen konvertieren kann, auch akustisch kommunizieren. Audio-Codec 2360 kann ebenfalls hörbare Töne für einen Benutzer erzeugen, wie etwa durch einen Lautsprecher, der sich z. B. in einem Handgerät von Gerät 2350 befindet. Solche Töne können Töne von telefonischen Sprachverbindungen, aufgezeichnete Töne (z. B. Sprachnachrichten, Musikdateien usw.) und ebenso Töne beinhalten, die von Anwendungen generiert werden, die auf Gerät 2350 betrieben werden.
Das Computergerät 2350 kann in einer Reihe verschiedener Formen implementiert werden, wie in der Figur gezeigt. Es kann zum Beispiel als Mobiltelefon 2380 implementiert werden. Es kann außerdem als Teil eines Smartphones 2382, eines Personal Digital Assistant oder eines anderen ähnlichen mobilen Geräts implementiert werden.
Verschiedene Implementierungen der hier beschriebenen Systeme und Techniken können in digitalen elektronischen Schaltkreisen, integrierten Schaltkreisen, speziell konzipierten ASICs (application specific integrated circuits, anwendungsorientierten integrierten Schaltkreisen), Computerhardware, Firmware, Software und/oder Kombinationen davon realisiert werden. Diese verschiedenen Implementierungen können eine Implementierung in einem oder mehreren Computerprogrammen beinhalten, die auf einem programmierbaren System ausführbar und/oder interpretierbar sind, das mindestens einen programmierbaren Prozessor beinhaltet, der ein spezieller Prozessor oder ein Prozessor für allgemeine Zwecke sein kann, und der zum Empfangen von Daten und Anweisungen von und zum Übertragen von Daten und Anweisungen an ein Speichersystem, mindestens eine Eingabevorrichtung und mindestens eine Ausgabevorrichtung gekoppelt ist.
Diese Computerprogramme (auch bekannt als Programme, Software, Softwareanwendungen oder Code) beinhalten Maschinenanweisungen für einen programmierbaren Prozessor und können in einer höheren prozeduralen und/oder objektorientierten Programmiersprache und/oder in Assembler-/Maschinensprache implementiert werden. Wie hier verwendet, beziehen sich die Begriffe „maschinenlesbares Medium”, „computerlesbares Medium” auf jegliche Computerprogrammprodukte, Apparate und/oder Geräte (z. B. magnetische und optische Platten, Speicher, [Programmable Logic Devices, PLD]), die zur Bereitstellung von Maschinenanweisungen und/oder -daten für einen programmierbaren Prozessor verwendet werden, einschließlich eines maschinenlesbaren Mediums, das Maschinenanweisungen als maschinenlesbares Signal empfängt. Der Begriff „maschinenlesbares Signal” bezeichnet ein beliebiges Signal, das verwendet wird, um einem programmierbaren Prozessor Maschinenanweisungen und/oder Daten bereitzustellen.
Zur Interaktion mit einem Benutzer können die hier beschriebenen Systeme und Techniken auf einem Computer mit einem Anzeigegerät (z. B. einem CRT Monitor (Cathode Ray Tube, Kathodenstrahlröhre) oder einem LCD-Monitor (Liquid Crystal Display, Flüssigkristallanzeige) implementiert werden, um Informationen für den Benutzer anzuzeigen, und mit Tastatur und Zeigegerät (z. B. Maus oder Trackball), mit denen der Benutzer Eingaben in den Computer vornehmen kann. Andere Arten von Geräten können auch verwendet werden, um eine Interaktion mit einem Benutzer bereitzustellen; zum Beispiel kann eine dem Benutzer bereitgestellte Rückmeldung irgendeine Form von Sinnesrückmeldung sein (z. B. visuelle Rückmeldung, auditive Rückmeldung oder Tastrückmeldung); und eine Eingabe vom Benutzer kann in einer beliebigen Form empfangen werden, einschließlich akustischer, Sprach- oder Tasteingaben.
Die hier beschriebenen Systeme und Techniken können in einem Computersystem implementiert werden, das eine Back-End-Komponente (z. B. als Datenserver) oder eine Middleware-Komponente (z. B. einen Anwendungsserver) oder eine Front-End-Komponente beinhaltet (z. B. ein Client-Computer mit einer graphischen Benutzeroberfläche oder einem Webbrowser, über welche ein Benutzer mit einer Implementierung der hier beschriebenen Systeme und Techniken interagieren kann) oder Kombination derartiger Back-End-, Middleware- und Front-End-Komponenten. Die Komponenten des Systems können durch eine beliebige Form oder ein beliebiges Medium von digitaler Datenkommunikation (z. B. ein Kommunikationsnetzwerk) miteinander verbunden sein. Beispiele von Kommunikationsnetzwerken beinhalten ein lokales Netzwerk (Local Area Network, „LAN”), ein Weitverkehrsnetzwerk (Wide Area Network, „WAN”), Peer-to-Peer-Netze (mit Ad-hoc-Mitgliedern und ständigen Mitgliedern), Netzrechnerinfrastrukturen und das Internet.
Das Computersystem kann Clients und Server beinhalten. Ein Client und Server befinden sich im Allgemeinen ortsfern voneinander und interagieren typischerweise über ein Kommunikationsnetz. Die Beziehung von Client und Server ergibt sich durch Computerprogramme, die auf den jeweiligen Computer laufen und eine Client-Server-Beziehung zueinander umfassen.
Obgleich hier einige Implementierungen zuvor im Detail beschrieben wurden, sind andere Modifikationen möglich. Ferner können andere Mechanismen zum Erzeugen und Verarbeiten von Spaltenspeicherdarstellungen verschachtelter Datensätze verwendet werden. Darüber hinaus erfordern die logischen Abläufe in den Abbildungen nicht unbedingt die abgebildete Reihenfolge oder die sequenzielle Reihenfolge, um die gewünschten Ergebnisse zu erzielen. Es können weitere Schritte zu den beschriebenen Abläufen hinzugefügt oder aus diesen weggelassen werden, und andere Komponenten zu den beschriebenen Systemen hinzugefügt oder von diesen weggelassen werden. Dementsprechend liegen andere Implementierungen im Geltungsbereich der folgenden Ansprüche.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

L. A. Barroso und U. Holzle. Das Datenzentrum als ein Computer: Eine Einführung in das Design von Maschinen der Lagerhaus-Skala. Morgan & Claypool Publishers, 2009 [0086]
G. Czajkowski. Sorting 1PB with MapReduce. Official Google Blog, Nov. 2008. Auf http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html [0086]
S. Ghemawat, H. Gobioff, und S. -T. Leung. The Google File System. In SOSP, 2003 [0088]
F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes und R. Gruber. Bigtable: A Distributed Storage System for Structured Data (Bigtable: Ein verteiltes Speichersystem für strukturierte Daten). In OSDI 2006 [0088]
J. Dean und S. Ghemawat. MapReduce: Simplified Data Processing an Large Clusters. In OSDI, 2004 [0089]
J. Dean. Challenges in Building Large-Scale Information Retrieval Systems: Invited Talk. In WSDM, 2009 [0090]
C. Olston, B. Reed, U. Srivastava, R. Kumar und A. Tomkins. Pig Latin: a Not-so-Foreign Language for Data Processing (Pig Latin: Eine nicht so fremde Sprache für die Datenverarbeitung). In SIGMOD, 2008 [0091]
Hive. http://wiki.apache.org/hadoop/Hive, 2009 [0091]
D. J. Abadi, P. A. Boncz und S. Harizopoulos. Column-Oriented Database Systems (Tabellenorientierte Datenbanksysteme). VLDB, 2(2), 2009 [0092]
R. Pike, S. Dorward, R. Griesemer, and S. Quinlan). Interpreting the Data: Parallel Analysis with Sawzall. Scientific Programming, 13(4), 2005 [0092]
C. Chambers, A. Raniwala, F. Perry, S. Adams, R. Henry, R. Bradshaw und N. Weizenbaum. FlumeJava: Easy, Efficient Data-Parallel Pipelines (FlumeJava: Einfache, effiziente datenparallele Pipelines. In PLDI, 2010 [0092]
http://code.google.com/apis/protocolbuffers/docs/overview.html [0104]
Hailing Yu, Hua-gang Li, Ping Wu, Divyakant Agrawal, Amr El Abbadi, ”Efficient processing of distributed top-k queries” (Effiziente Verarbeitung verteilter Top-k-Anfragen), DEXA2005, S. 65–74 [0145]