DE202020005703U1 - Auf verteilten Metadaten basierendes Cluster-Computing - Google Patents

Auf verteilten Metadaten basierendes Cluster-Computing Download PDF

Info

Publication number
DE202020005703U1
DE202020005703U1 DE202020005703.7U DE202020005703U DE202020005703U1 DE 202020005703 U1 DE202020005703 U1 DE 202020005703U1 DE 202020005703 U DE202020005703 U DE 202020005703U DE 202020005703 U1 DE202020005703 U1 DE 202020005703U1
Authority
DE
Germany
Prior art keywords
result files
database
data
serialized
metadata record
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE202020005703.7U
Other languages
English (en)
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Snowflake Inc
Original Assignee
Snowflake Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Snowflake Inc filed Critical Snowflake Inc
Publication of DE202020005703U1 publication Critical patent/DE202020005703U1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24553—Query execution of query operations
    • G06F16/24561—Intermediate data storage techniques for performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Computerprogramm, das Anweisungen umfasst, die dann, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, veranlassen, dass der eine oder die mehreren Prozessoren Operationen durchführt oder durchführen, wobei die Operationen folgendes umfassen:
Empfangen, durch eine Datenbank-Konnektorschnittstelle, unter Verwendung von einem oder mehreren Prozessoren einer Maschine, einer Abfrage gegenüber einer verteilten Datenbank, wobei die Abfrage von einem externen Computercluster empfangen wird, das einen Masterknoten und eine Vielzahl von Workerknoten umfasst, wobei die verteilte Datenbank serialisierte Ergebnisdateien für die Abfrage erzeugt und die serialisierten Ergebnisdateien in einer Staging-Datenbank speichert;
Übertragen, durch die Datenbank-Konnektorschnittstelle, eines Objektmetadatensatzes zum Masterknoten des externen Computerclusters, wobei der Objektmetadatensatz eine Vielzahl von Objektmetadatensatzelementen umfasst, wobei jedes der Vielzahl von Objektmetadatensatzelementen Zugriffs- bzw. Zugangsdaten von einer der serialisierten Ergebnisdateien in der Staging-Datenbank beschreibt;
Empfangen, durch die Datenbank-Konnektorschnittstelle, von der Vielzahl von Workerknoten, von Anforderungen für die in der Staging-Datenbank gespeicherten serialisierten Ergebnisdateien, wobei jede der Anforderungen unter Verwendung von einem der Vielzahl von Objektmetadatensatzelemente erzeugt ist; und
Übertragen, durch die Datenbank-Konnektorschnittstelle, der serialisierten Ergebnisdateien von der Staging-Datenbank zur Vielzahl von Workerknoten des externen Computerclusters.

Description

  • QUERVERWEIS AUF PRIORITÄTSANMELDUNG
  • Diese Anmeldung beansprucht den Vorteil der Priorität der US-Patentanmeldung mit der seriellen Nr. 16/719,218 , eingereicht am 18. Dezember 2019, deren Inhalte hierdurch in ihrer Gesamtheit hierin durch Bezugnahme enthalten sind.
  • TECHNISCHES GEBIET
  • Die vorliegende Offenbarung beziehen sich allgemein auf spezielle Maschinen, die Datenbanken managen, und Verbesserungen an solchen Varianten, und auf die Technologien, durch welche solche speziellen Maschinen im Vergleich mit anderen speziellen Maschinen zum Durchführen von verteiltem Computing unter Verwendung von Datenbankdaten verbessert werden.
    Um als Gebrauchsmuster geschützt und Gegenstand davon zu sein, gibt es gemäß den Erfordernissen des Gebrauchsmustergesetzes nur Vorrichtungen, wie sie in den beigefügten Ansprüchen definiert sind, aber keine Verfahren. In einem Fall, in welchem in der Beschreibung Bezug auf Verfahren genommen wird, dienen diese Bezugnahmen lediglich dazu, die Vorrichtung oder die Vorrichtungen darzustellen, für welche mit den enthaltenen Ansprüchen Schutz gesucht wird.
  • HINTERGRUND
  • Eine verteilte Verarbeitung kann verwendet werden, um analytische Rechen- bzw. Computerquellen zu erstellen, um Daten zu analysieren. Einige dieser verteilten Computersysteme enthalten ein Cluster von Knoten, einschließlich eines Masterknotens und mehrerer Workerknoten, die gemäß den Anweisungen des Masterknotens zusammenarbeiten, um Datenverarbeitungsaufgaben abzuschließen. Während diese verteilten Systeme ein leistungsfähiges Computing ermöglichen, können dennoch Ineffizienzen wie Engpässe auftreten.
  • Figurenliste
  • Verschiedene der beigefügten Zeichnungen stellen lediglich beispielhafte Ausführungsformen der vorliegenden Offenbarung dar und sollten nicht als ihren Geltungsbereich beschränkend angesehen werden.
    • 1 stellt eine beispielhafte Rechen- bzw. Computing-Umgebung, in welcher ein netzwerkbasiertes Data-Warehouse-System Cluster-Computing unter Verwendung eines Metadaten-Konnektors implementieren kann, gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar.
    • 2 ist ein Blockdiagramm, das Komponenten eines Computing-Service-Managers gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt.
    • 3 ist ein Blockdiagramm, das Komponenten einer Ausführungsplattform gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt.
    • 4 zeigt eine beispielhafte Datenarchitektur für Cluster-Computing unter Verwendung eines Metadaten-Konnektors gemäß einigen Ausführungsformen der vorliegenden Offenbarung.
    • 5 und 6 zeigen beispielhafte Ablaufdiagramme zum Implementieren von Cluster-Computing unter Verwendung eines Metadaten-Konnektors gemäß einigen Ausführungsformen der vorliegenden Offenbarung.
    • 7 zeigt ein beispielhaftes Netzwerkpfaddiagramm zum Implementieren von Cluster-Computing unter Verwendung eines Metadaten-Konnektors gemäß einigen Ausführungsformen der vorliegenden Offenbarung.
    • 8 stellt eine schematische Darstellung einer Maschine in der Form eines Computersystems, innerhalb von welchem ein Satz von Anweisungen ausgeführt werden kann, um zu veranlassen, dass die Maschine irgendeine oder mehrere der hierin diskutierten Methoden durchführt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar.
  • DETAILLIERTE BESCHREIBUNG
  • Die Beschreibung, die folgt, enthält Systeme, Verfahren, Techniken, Anweisungssequenzen und Computing-Maschinen-Programmprodukte, die illustrative Ausführungsformen der Offenbarung verkörpern. In der folgenden Beschreibung werden zu Erklärungszwecken zahlreiche spezifische Details dargelegt, um ein Verstehen verschiedener Ausführungsformen des erfinderischen Gegenstands bereitzustellen. Es wird jedoch für Fachleute offensichtlich sein, dass Ausführungsformen des erfinderischen Gegenstands ohne diese spezifischen Details ausgeführt werden können. Im Allgemeinen werden wohlbekannte Anweisungsinstanzen, Protokolle, Strukturen und Techniken nicht unbedingt im Detail gezeigt.
  • Wie es diskutiert ist, können Ineffizienzen in verteilten Computing-Systemen bzw. Computersystemen auftreten. Ein Typ von Ineffizienz enthält einen Masterknotenengpass beim Zugreifen auf und Verteilen von Daten zur Berechnung. Wenn zum Beispiel die Datenquelle des Cluster-Computing-Systems einen sehr großen Satz von Ergebnisdaten zur Verarbeitung (z.B. Abfrageergebnisdaten) erzeugt, kann der Masterknoten einer starken Belastung ausgesetzt sein, wenn er versucht, auf den sehr großen Satz von Ergebnissen zuzugreifen und ihn zu den Workerknoten zur Verarbeitung zu verteilen.
  • Zu diesem Zweck kann ein Metadatenkonnektorsystem implementiert werden, um ein gemeinsam genutztes bzw. geteiltes Datenbanksystem mit einem Cluster-Computing-System zu verbinden, wo eine Abfrage gegen das gemeinsam genutzte Datenbankverarbeitungssystem direkt ausgeführt wird und die Knoten des Clusters direkt auf die Abfrageergebnisdaten im Cloud-Speicher zugreifen, ohne eine Verbindung zum gemeinsam genutzten Datenbanksystem herstellen zu müssen. Bei einigen beispielhaften Ausführungsformen verwendet eine Abfrage vom Cluster-Computing-System (z.B. Apache Spark®) ein gemeinsam genutztes mehrmandantenfähiges Datenbankverarbeitungssystem (z.B. Snowflake®) als Datenquelle, wobei die Verbindung zwischen den beiden unter Verwendung eines für einen Datenbankzugriff konfigurierten Anwendungsprogrammierungsschnittstellen (API(= Application Programming Interface)) - Konnektors implementiert wird (z.B. Java Database Connectivity (JDBC®)). Bei einigen beispielhaften Ausführungsformen gibt das Cluster-Computing-System eine Abfrage durch den API-Konnektor zum gemeinsam genutzten Datenbanksystem aus, der Abfrageergebnisdaten erzeugt, die als Dateien zu einem Stagingbereich geschrieben werden. Zum Beispiel kann das gemeinsam genutzte Datenbanksystem die Abfrageergebnisdaten unter Verwendung von COPY UNLOAD SQL-Anweisungen zu einem externen Stagingbereich wie Amazon S3 Buckets speichern, wobei COPY Abfrageergebnisdaten aus dem Datenbanksystem kopiert und UNLOAD die Daten als Dateien zum Stagingbereich transferiert. Gemäß einigen beispielhaften Ausführungsformen greift der Masterknoten dann auf den Stagingbereich zu (greift z.B. auf die S3 Buckets zu), um zu bestimmen, was sich in den Ergebnisdateien befindet zur Verteilung der Dateien zu den Workerknoten zur weiteren Verarbeitung.
  • Wenn die zum Stagingbereich geschriebenen Ergebnisdateien sehr groß sind (z.B. in der Größe von Terabytes), können die Operationen des Masterknotens, der auf die Ergebnisdateien zugreift und/oder sie zu den Workerknoten transferiert, zu signifikanten Verzögerungen führen. Um eine Überlastung des Masterknotens des Cluster-Computing-Systems abzuschwächen, führt der API-Konnektor (z.B. JDBC) die Abfrage direkt gegen das gemeinsam genutzte Datenbanksystem aus, ohne die COPY UNLOAD-Anweisungen (z.B. SELECT-Anweisung gegen das gemeinsam genutzte Datenbanksystem) zu verwenden, und speichert die Ergebnisdateien in der Staging-Plattform. Das gemeinsam genutzte Datenbanksystem sendet dann einige der Ergebnisdateidaten zum API-Konnektor, um einen Objektmetadatensatz zu erzeugen, der eine Vielzahl von seriellen Objekten eines Clusters umfasst, die den verbleibenden Großteil der Ergebnisdateien im Stagingbereich beschreiben. Wenn zum Beispiel die Ergebnisdateien als Chunks bzw. Datenblöcke zu S3 geschrieben werden, sendet das gemeinsam genutzte Datenbanksystem den ersten Chunk der Ergebnisdateien (z.B., wenn der erste Chunk bezüglich der Größe allgemein klein ist) und Metadaten der anderen Chunks (z.B. Metadaten, einschließlich Ergebnis-Chunk-Dateien-URLs auf S3, Chunk-Größen, Berechtigungsnachweis- bzw. Anmeldeinformationsdaten, um auf die Ergebnisdateien auf S3 zuzugreifen) zum API-Konnektor zum API-Konnektor. Der API-Konnektor sendet dann eine Liste der Cluster-Speicherobjekte zum Masterknoten des Cluster-Computing-Systems, der dann die Liste von Clusterspeicherobjekten zu den Workerknoten verteilen kann.
  • Workerknoten empfangen die Cluster-Speicherobjekte und führen einen Funktionsaufruf zum API-Konnektor aus, um die Ergebnisdateidaten direkt aus dem Stagingbereich (über den API-Konnektor) abzurufen bzw. wiederzugewinnen. Auf diese Weise liest der API-Konnektor nicht die tatsächlichen Ergebnisdateidaten (der API-Konnektor behandelt sie nur als verpackte Metadaten oder als Umhüllung/Liste von Objekten) und muss der Masterknoten nicht auf die tatsächlichen Ergebnisdateidaten zugreifen und diese verteilen, sondern verteilt nur Speicherobjekt-Metadaten, die die Ergebnisdateien beschreiben, wobei die Speicherobjekt-Metadaten als Umhüllung fungieren und die Objekte serialisiert werden und dadurch zu Workerknoten verteilt und gleichzeitig durch irgendeinen der Workerknoten ausgeführt und verarbeitet werden können, wie es in weiterem Detail nachstehend diskutiert wird. Auf diese Weise sind, selbst wenn der durch die gemeinsam genutzte Datenbank erzeugte Abfrageergebnisdatensatz riesig ist, die Metadaten klein und serialisiert als Objekte, so dass die Arbeitslastverteilung und die Reaktionsfähigkeit einer Anwendung signifikant verbessert werden.
  • Ein Vorteil des Konnektor-Ansatzes enthält, zusätzlich zu einem signifikanten Erleichtern der Last des Masterknotens und dadurch einem Vermeiden eines signifikanten Engpasses, ein Reduzieren des Netzwerkverkehrs der über das Netzwerk transferierten Ergebnisdateien um die Hälfte oder mehr. Bei anderen Ansätzen empfängt der Masterknoten die Ergebnisdaten und transferiert dann die Ergebnisdaten zu den Workerknoten. Beim Metadaten-Konnektor-Ansatz werden die Daten nur vom gemeinsam genutzten Datenbanksystem zum Stagingbereich übertragen und transferieren der Masterknoten und der API-Konnektor nur verteilbare Metadaten, die signifikant kleiner als die Größen der Ergebnisdateien sind. Zusätzlich ermöglicht der Metadaten-Konnektor-Ansatz, dass die handzuhabende Datenmenge in Reaktion auf erhöhte Lasten erheblich skaliert wird, indem die Anzahl an Knoten im Stagingbereich erhöht wird. Wo zum Beispiel die Staging-Plattform ein elastisches, skalierbares System wie Amazon S3 ist, kann die Menge an Knoten in der Staging-Plattform erhöht werden, um Anforderungen von den Workerknoten besser bedienen zu können (z.B. erhöht sich dann, wenn die Anzahl der Workerknoten zunimmt und/oder eine Größe der Ergebnisdatei zunimmt, die Anzahl der Knoten der Staging-Plattform entsprechend, um auf die Workerknoten zu reagieren), was eine Entstehung von Engpässen für die Daten durch den Masterknoten vermeidet und eine Überlastung einer statischen Anzahl von Knoten im Stagingbereich vermeidet.
  • 1 stellt eine beispielhafte gemeinsam genutzte bzw. geteilte Datenverarbeitungsplattform 100, in der ein netzwerkbasiertes Data-Warehouse-System 102 als Datenquelle für eine Cluster-Computing-Plattform 150 fungiert, die mittels einer Datenbank-Konnektor-Schnittstelle, wie z.B. eines API-Konnektors 145, verbunden ist, gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar. Um zu vermeiden, dass der erfinderische Gegenstand mit unnötigem Detail verdeckt wird, wurden verschiedene funktionelle Komponenten, die nicht passend dafür sind, ein Verstehen des erfinderischen Gegenstands zu vermitteln, aus den Figuren weggelassen worden. Ein Fachmann wird jedoch ohne weiteres erkennen, dass verschiedene zusätzliche funktionelle Komponenten als Teil der gemeinsam genutzten bzw. geteilten Datenverarbeitungsplattform 100 enthalten sein können, um zusätzliche Funktionalität zu ermöglichen, die hierin nicht spezifisch beschrieben ist.
  • Wie es gezeigt ist, umfasst die gemeinsam genutzte Datenverarbeitungsplattform 100 das netzwerkbasierte Data-Warehouse-System 102, eine Cloud-Computing-Speicherplattform 104 (z.B. eine Speicherplattform, einen AWS®-Dienst wie S3, Microsoft Azure® oder Google Cloud Services®) und eine Benutzervorrichtung 106. Das netzwerkbasierte Data-Warehouse-System 102 ist ein netzwerkbasiertes System, das zum Speichern von und Zugreifen auf Daten (z.B. internes Speichern von Daten, Zugreifen auf externe entfernt angeordnete Daten) auf eine mehrmandantenfähige integrierte Weise verwendet wird, und für ein Berichten und eine Analyse der integrierten Daten aus der einen oder den mehreren ungleichartigen Quellen (z.B. der Cloud-Computing-Speicherplattform 104), wobei zusätzliches analytisches Computing durch die Cluster-Computing-Plattform 150 durchgeführt werden kann. Die Cloud-Computing-Speicherplattform 104 umfasst eine Vielzahl von Computing-Maschinen und stellt dem netzwerkbasierten Data-Warehouse-System 102 On-Demand-Computersystemressourcen wie Datenspeicherung und Computing- bzw. Rechenleistung zur Verfügung.
  • Die Benutzervorrichtung 106 (z.B. eine Benutzervorrichtung wie ein Laptop-Computer) umfasst eine oder mehrere Computing-Maschinen (z.B. eine Clientvorrichtung wie einen Laptop-Computer), die eine Softwarekomponente 108 (z.B. einen vom Browser aufgerufenen Cloud-Dienst, eine native App wie eine mobile App für ein mobiles Betriebssystem) ausführen, um Benutzern des netzwerkbasierten Data-Warehouse-Systems 102 zusätzliche Funktionalität bereitzustellen.
  • Die Softwarekomponente 108 umfasst einen Satz maschinenlesbarer Anweisungen (z.B. einen Code), die dann, wenn sie durch die Benutzervorrichtung 106 ausgeführt werden, veranlassen, dass die Benutzervorrichtung 106 ein bestimmte Funktionalität bereitstellt. Die Softwarekomponente 108 kann an Eingabedaten arbeiten und erzeugt Ergebnisdaten basierend auf einem Verarbeiten, einem Analysieren oder einem anderweitigen Transformieren der Eingabedaten. Als Beispiel kann die Softwarekomponente 108 ein Browser sein, der auf eine Cloud-betriebene Kundenanwendung auf der Cluster-Computing-Plattform 150 zur Berechnung durch den Masterknoten 152 und die Workerknoten 154-160 zugreift, wie es nachstehend in weiterem Detail diskutiert ist.
  • Das netzwerkbasierte Data-Warehouse-System 102 umfasst ein Zugriffsmanagementsystem 110, einen Computing-Service-Manager 112, eine Ausführungsplattform 114 und eine Datenbank 116. Das Zugriffsmanagementsystem 110 ermöglicht administrativen Benutzern, einen Zugriff auf Ressourcen und Dienste zu managen, die durch das netzwerkbasierte Data-Warehouse-System 102 bereitgestellt werden. Administrative Benutzer können Benutzer, Rollen und Gruppen erstellen und managen und Berechtigungen verwenden, um einen Zugriff auf Ressourcen und Dienste zuzulassen oder zu verweigern. Das Zugriffsmanagementsystem 110 kann Teilungsdaten speichern, die einen geteilten Zugriff auf die Speicherressourcen der Cloud-Computing-Speicherplattform 104 für verschiedene Benutzer des netzwerkbasierten Data-Warehouse-Systems 102 sicher managen, wie es nachstehend in weiterem Detail diskutiert wird.
  • Der Computing-Service-Manager 112 koordiniert und managt Operationen des netzwerkbasierten Data-Warehouse-Systems 102. Der Computing-Service-Manager 112 führt auch eine Abfrageoptimierung und -kompilierung durch und ein Managen von Clustern von Computing-Diensten, die Computerressourcen (z.B. virtuelle Lager, virtuelle Maschinen, EC2-Cluster) in der Ausführungsplattform 114 bereitstellen. Der Computing-Service-Manager 112 kann irgendeine Anzahl von Clientkonten unterstützen, wie beispielsweise Endbenutzer, die Datenspeicherungs- und -wiedergewinnungsanforderungen bereitstellen, Systemadministratoren, die die hierin beschriebenen Systeme und Verfahren managen, und andere Komponenten/Vorrichtungen, die mit Computing-Service-Manager 112 interagieren.
  • Der Computing-Service-Manager 112 ist auch mit der Datenbank 116 gekoppelt, die mit der Gesamtheit der durch die gemeinsam genutzte Datenverarbeitungsplattform 100 gemanagten Daten assoziiert ist. Die Datenbank 116 speichert Daten, die zu verschiedenen Funktionen und Aspekten gehören, die mit dem netzwerkbasierten Data-Warehouse-System 102 und seinen Benutzern assoziiert sind. Zum Beispiel können Daten, gegen die Abfragen durch eine auf der Cluster-Computing-Plattform 150 laufende Kundenanwendung ausgeführt werden können, in der Datenbank 116 als interne Daten oder in der Speicherplattform 122 als externe Daten gespeichert werden.
  • Bei einigen Ausführungsformen enthält die Datenbank 116 eine Zusammenfassung von in entfernten Datenspeichersystemen gespeicherten Daten sowie aus einem oder mehreren lokalen Caches verfügbaren Daten. Zusätzlich kann die Datenbank 116 Information diesbezüglich enthalten, wie Daten in den entfernten Datenspeichersystemen und den lokalen Caches organisiert sind. Die Datenbank 116 lässt zu, dass Systeme und Dienste bestimmen, ob auf ein Stück von Daten zugegriffen werden muss, ohne die tatsächlichen Daten aus einer Speichervorrichtung zu laden oder auf diese zuzugreifen. Der Computing-Service-Manager 112 ist weiterhin mit einer Ausführungsplattform 114 gekoppelt, die mehrere Computerressourcen (z.B. virtuelle Lager) bereitstellt, die verschiedene Datenspeicherungs- und Datenabruf- bzw. Datenwiedergewinnungsaufgaben ausführen, wie es nachstehend detaillierter diskutiert wird.
  • Die Ausführungsplattform 114 ist mit mehreren Datenspeichervorrichtungen 124-1 bis 124-n gekoppelt, die Teil einer Cloud-Computing-Speicherplattform 104 sind. Obwohl in 1 zwei Datenspeichervorrichtungen 124-1 und 124-n gezeigt sind, ist die Ausführungsplattform 114 in der Lage, mit irgendeiner Anzahl von Datenspeichervorrichtungen als Teil eines elastischen Speichersystems zu kommunizieren. Bei einigen Ausführungsformen sind die Datenspeichervorrichtungen 124-1 bis 124-n cloudbasierte Speichervorrichtungen, die an einem oder mehreren geografischen Standorten angeordnet sind. Zum Beispiel können die Datenspeichervorrichtungen 124-1 bis 124-n Teil einer Infrastruktur einer öffentlichen Cloud oder einer Infrastruktur einer privaten Cloud sein. Die Datenspeichervorrichtungen 124-1 bis 124-N können Festplattenlaufwerke (HDDs), Festkörperspeicher (SSDs), Speichercluster, Amazon S3-Speichersysteme oder irgendeine andere Datenspeichertechnologie sein. Zusätzlich kann die Cloud-Computing-Speicherplattform 104 verteilte Dateisysteme (wie beispielsweise Hadoop Distributed File Systems (HDFS)), Objektspeichersysteme und dergleichen enthalten.
  • Die Ausführungsplattform 114 umfasst eine Vielzahl von Computing- bzw. Rechenknoten (z.B. virtuelle Lager). Eine Gruppe von Prozessen auf einem Rechenknoten führt einen durch den Computing-Service-Manager 112 kompilierten Abfrageplan aus. Die Gruppe von Prozessen kann folgendes enthalten: einen ersten Prozess, um den Abfrageplan auszuführen; einen zweiten Prozess, um Mikropartitionsdateien unter Verwendung einer LRU(Least Recently Used (= am längsten nicht verwendet))-Strategie zu überwachen und zu löschen und um einen OOM(Out of Memory (= kein Speicher mehr))-Fehlerminderungsprozess zu implementieren; einen dritten Prozess, der Gesundheitsinformation aus Prozessprotokollen und -status extrahiert, um sie zum Computing-Service-Manager 112 zurückzusenden; einen vierten Prozess, um eine Kommunikation mit dem Computing-Service-Manager 112 nach einem Systemstart herzustellen; und einen fünften Prozess, um die gesamte Kommunikation mit einem Computercluster für einen gegebenen Job zu handhaben, der vom Computing-Service-Manager 112 bereitgestellt ist, und um Information zu dem Computing-Service-Manager 112 und anderen Computerknoten der Ausführungsplattform 114 zurück zu kommunizieren.
  • Die Cloud-Computing-Speicherplattform 104 umfasst auch ein Zugriffsmanagementsystem 118 und eine Cloud-Schnittstelle 120 (z.B. API-Gateway für die Cloud-Computing-Speicherplattform 104). Wie beim Zugriffsmanagementsystem 110 lässt das Zugriffsmanagementsystem 118 zu, dass Benutzer Benutzer, Rollen und Gruppen erstellen und managen und Berechtigungen verwenden, um einen Zugriff auf Cloud-Dienste und -Ressourcen zuzulassen und zu verweigern. Das Zugriffsmanagementsystem 110 des netzwerkbasierten Data-Warehouse-Systems 102 und das Zugriffsmanagementsystem 118 der Cloud-Computing-Speicherplattform 104 können Information kommunizieren und gemeinsam nutzen bzw. teilen, um ein Zugreifen und ein Management von Ressourcen und Diensten zu ermöglichen, die von Benutzern von sowohl dem netzwerkbasierten Data-Warehouse-System 102 als auch der Cloud-Computing-Speicherplattform 104 gemeinsam genutzt werden. Die Cloud-Schnittstelle 120 handhabt Aufgaben, die an einem Annehmen und einem Verarbeiten gleichzeitiger API-Aufrufe beteiligt sind, einschließlich eines Datenverkehrsmanagements, einer Autorisierung und einer Zugriffssteuerung bzw. -kontrolle, einer Überwachung und eines API-Versionsmanagements. Die Cloud-Schnittstelle 120 stellt einen HTTP-Proxy-Dienst zum Erstellen, Veröffentlichen, Beibehalten, Sichern und Überwachen von APIs (z.B. REST-APIs) bereit.
  • Bei einigen Ausführungsformen sind Kommunikationsverbindungen zwischen Elementen der gemeinsam genutzten Datenverarbeitungsplattform 100 über ein oder mehrere Datenkommunikationsnetzwerke implementiert. Diese Datenkommunikationsnetzwerke können irgendein Kommunikationsprotokoll und irgendeinen Typ von Kommunikationsmedium verwenden. Bei einigen Ausführungsformen sind die Datenkommunikationsnetzwerke eine Kombination von zwei oder mehr Datenkommunikationsnetzwerken (oder Teilnetzwerken), die miteinander gekoppelt sind. Bei alternativen Ausführungsformen sind diese Kommunikationsverbindungen unter Verwendung von irgendeinem Typ von Kommunikationsmedium und irgendeinem Kommunikationsprotokoll implementiert.
  • Wie es in 1 gezeigt ist, sind die Datenspeichervorrichtungen 124-1 bis 124-N von den mit der Ausführungsplattform 114 assoziierten Computerressourcen entkoppelt. Das bedeutet, dass neue virtuelle Lager in der Ausführungsplattform 114 erstellt und beendet werden können und zusätzliche Datenspeichervorrichtungen auf eine unabhängige Weise auf der Cloud-Computing-Speicherplattform 104 erstellt und beendet werden können (z.B. ist die Cloud-Computing-Speicherplattform 104 eine externe Netzwerkplattform, wie beispielsweise Amazon AWS, die separat gemanagt wird, aber mit dem netzwerkbasierten Data-Warehouse-System 102 verbunden ist). Diese Architektur unterstützt dynamische Änderungen am netzwerkbasierten Data-Warehouse-System 102 basierend auf den sich ändernden Datenspeicherungs-/-abrufanforderungen sowie den sich ändernden Anforderungen der Benutzer und Systeme, die auf die gemeinsam genutzte Datenverarbeitungsplattform 100 zugreifen. Die Unterstützung dynamischer Änderungen lässt zu, dass das netzwerkbasierte Data-Warehouse-System 102 in Reaktion auf sich ändernde Anforderungen an die Systeme und Komponenten innerhalb des netzwerkbasierten Data-Warehouse-Systems 102 schnell skaliert. Die Entkopplung der Computerressourcen von den Datenspeichervorrichtungen unterstützt die Speicherung großer Datenmengen, ohne eine entsprechend große Menge an Computerressourcen zu erfordern. Gleichermaßen unterstützt diese Entkopplung von Ressourcen eine signifikante Erhöhung von zu einem bestimmten Zeitpunkt verwendeten Computerressourcen, ohne eine entsprechende Erhöhung von verfügbaren Datenspeicherressourcen zu erfordern. Zusätzlich ermöglicht die Entkopplung von Ressourcen unterschiedlichen Konten, ein Erstellen zusätzlicher Computerressourcen zu handhaben, um durch andere Benutzer gemeinsam genutzte Daten zu verarbeiten, ohne die Systeme der anderen Benutzer zu beeinflussen bzw. zu beeinträchtigen. Zum Beispiel kann ein Datenanbieter drei Computerressourcen haben und Daten mit einem Datenverbraucher teilen und kann der Datenverbraucher neue Computerressourcen erzeugen, um Abfragen gegen die geteilten bzw. gemeinsam genutzten Daten auszuführen, wobei die neuen Computerressourcen durch den Datenverbraucher gemanagt werden und sich nicht auf die Computerressourcen des Datenanbieters auswirken oder mit ihnen interagieren.
  • Die Cluster-Computing-Plattform 150 ist eine Cluster-Computing-Umgebung, die die Computing- bzw. Rechenanalyse des netzwerkbasierten Data-Warehouse-Systems 102 erweitern kann. Während zum Beispiel das netzwerkbasierte Data-Warehouse-System 102 konfiguriert sein kann, um mit der Cloud-Computing-Speicherplattform 104 zu funktionieren bzw. zu arbeiten, um ein entkoppeltes Data-Warehouse bzw. Datenlager freizugeben, das skalieren kann, kann die Cluster-Computing-Plattform 150 eine Massendaten- bzw. Big-Data- oder Nicht-nur-SQL- bzw. NoSQL-Plattform (z.B. Apache Spark, Hadoop, Cassandra) sein, die einen Masterknoten 152 und eine Vielzahl von Workerknoten 154 implementiert, um verteilte Rechenaufgaben (z.B. eine Datenanalyse) auszuführen. Bei einigen beispielhaften Ausführungsformen funktionieren bzw. arbeiten das netzwerkbasierte Data-Warehouse-System 102 und die Cloud-Computing-Speicherplattform 104 als eine einzige Einheit und ist die Cluster-Computing-Plattform 150 unabhängig von der Entkopplung und den Funktionen der einzelnen Einheit. Zum Beispiel können das netzwerkbasierte Data-Warehouse-System 102 und die Cloud-Computing-Speicherplattform 104 als Snowflake-Datenquelle zu einem Apache-Spark-Cluster implementiert sein (z.B. eine beispielhafte Ausführungsform der Cluster-Computing-Plattform 150), wobei die zwei Plattformen über einen API-Konnektor 145, wie beispielsweise JDBC, verbunden sind. Obwohl der API-Konnektor 145 zwischen dem netzwerkbasierten Data-Warehouse-System 102 und der Cluster-Computing-Plattform 150 gezeigt ist, wird es eingesehen, dass der API-Konnektor 145 innerhalb des netzwerkbasierten Data-Warehouse-Systems 102 integriert sein kann, wie nachstehend unter Bezugnahme auf 2 detaillierter diskutiert wird.
  • Weiterhin sind der Computing-Service-Manager 112, die Datenbank 116, die Ausführungsplattform 114, die Cloud-Computing-Speicherplattform 104, die Cluster-Computing-Plattform 150 und die Benutzervorrichtung 106 in 1 als einzelne Komponenten gezeigt. Der Computing-Service-Manager 112, die Datenbank 116, die Ausführungsplattform 114, die Cloud-Computing-Speicherplattform 104 und die Cluster-Computing-Plattform 150 kann jedoch jeweils als verteiltes System implementiert sein (z.B. verteilt über mehrere Systeme/Plattformen an mehreren geografischen Standorten), verbunden durch APIs und Zugriffsinformation (z.B. Token, Anmeldedaten). Zusätzlich können der Computing-Service-Manager 112, die Datenbank 116, die Ausführungsplattform 114 und die Cloud Computing-Speicherplattform 104 jeweils in Abhängigkeit von Änderungen an den empfangenen Anforderungen und den sich ändernden Anforderungen der gemeinsam genutzten Datenverarbeitungsplattform 100 (unabhängig voneinander) nach oben oder nach unten skaliert werden. Somit ist bei den beschriebenen Ausführungsformen das netzwerkbasierte Data-Warehouse-System 102 dynamisch und unterstützt regelmäßige Änderungen, um den aktuellen Datenverarbeitungsanforderungen gerecht zu werden.
  • Während einer typischen Operation verarbeitet das netzwerkbasierte Data-Warehouse-System 102 mehrere durch den Computing-Service-Manager 112 bestimmte Jobs (z.B. Abfragen von der Cluster-Computing-Plattform 150). Diese Jobs werden durch den Computing-Service-Manager 112 geplant und gemanagt, um zu bestimmen, wann und wie der Job auszuführen ist. Zum Beispiel kann der Computing-Service-Manager 112 den Job in mehrere diskrete Aufgaben bzw. Aufträge aufteilen und bestimmen, welche Daten zum Ausführen von jeder der mehreren Aufgaben erforderlich sind. Der Computing-Service-Manager 112 kann jede der mehreren diskreten Aufgaben einem oder mehreren Knoten der Ausführungsplattform 114 zuordnen, um die Aufgabe zu verarbeiten. Der Computing-Service-Manager 112 kann bestimmen, welche Daten zum Verarbeiten einer Aufgabe nötig sind, und kann weiterhin bestimmen, welche Knoten innerhalb der Ausführungsplattform 114 für eine Verarbeitung der Aufgabe am besten geeignet sind. Es kann sein, dass einige Knoten bereits die für die Verarbeitung der Aufgabe erforderlichen Daten in einem Cache gespeichert bzw. zwischengespeichert haben (da die Knoten kürzlich die Daten von der Cloud-Computing-Speicherplattform 104 für einen früheren Job heruntergeladen haben) und daher ein guter Kandidat für die Verarbeitung der Aufgabe sein können. In der Datenbank 116 gespeicherte Metadaten unterstützen den Computing-Service-Manager 112 bei einem Bestimmen, welche Knoten in der Ausführungsplattform 114 bereits wenigstens einen Teilbereich der für die Verarbeitung der Aufgabe erforderlichen Daten zwischengespeichert haben. Ein oder mehrere Knoten in der Ausführungsplattform 114 verarbeiten die Aufgabe unter Verwendung von Daten, die durch die Knoten zwischengespeichert sind und, wenn es nötig ist, von Daten, die durch die Cloud-Computing-Speicherplattform 104 abgerufen bzw. wiedergewonnen sind. Es ist wünschenswert, so viele Daten wie möglich aus Caches innerhalb der Ausführungsplattform 114 abzurufen, da die Wiedergewinnungs- bzw. Abrufgeschwindigkeit typischerweise viel schneller als ein Wiedergewinnen bzw. Abrufen von Daten aus der Cloud-Computing-Speicherplattform 104 ist.
  • Wie es in 1 gezeigt ist, trennt die gemeinsam genutzte Datenverarbeitungsplattform 100 die Ausführungsplattform 114 von der Cloud-Computing-Speicherplattform 104. Bei dieser Anordnung arbeiten die Verarbeitungsressourcen und Cacheressourcen in der Ausführungsplattform 114 unabhängig von den Datenspeichervorrichtungen 124-1 bis 124-n in der Cloud-Computing-Speicherplattform 104. Somit sind die Computerressourcen und Cacheressourcen nicht auf spezifische Datenspeichervorrichtungen 124-1 bis 124-n beschränkt. Stattdessen können alle Computerressourcen und alle Cacheressourcen Daten von irgendeiner der Datenspeicherressourcen in der Cloud-Computing-Speicherplattform 104 abrufen und Daten dorthin speichern.
  • 2 ist ein Blockdiagramm, das Komponenten des Computing-Service-Managers 112 gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt. Wie es in 2 gezeigt ist, managt ein Anforderungsverarbeitungsdienst 202 empfangene Datenspeicheranforderungen und Datenwiedergewinnungs- bzw. Datenabrufanforderungen (z.B. an Datenbankdaten durchzuführende Jobs). Zum Beispiel kann der Anforderungsverarbeitungsdienst 202 die Daten bestimmen, die zur Verarbeitung einer empfangenen Abfrage (z.B. einer Datenspeicheranforderung oder einer Datenabrufanforderung) nötig sind. Die Daten können in einem Cache innerhalb der Ausführungsplattform 114 oder in einer Datenspeichervorrichtung in der Cloud-Computing-Speicherplattform 104 gespeichert werden. Ein Managementkonsolendienst 204 unterstützt einen Zugriff auf verschiedene Systeme und Prozesse durch Administratoren und andere Systemmanager. Zusätzlich kann der Managementkonsolendienst 204 eine Anforderung empfangen, um einen Job auszuführen und um die Arbeitsauslastung auf dem System zu überwachen.
  • Der Ergebnisobjekt-Manager 207 ist so konfiguriert, dass serialisierte Ergebnisdateien zur Speicherung auf einer Staging-Plattform erzeugt werden und der Objektmetadatensatz erzeugt wird, bei dem es sich um eine Metadatenliste handelt, die die in der Staging-Plattform gespeicherten Ergebnisdateien beschreibt. Der Ergebnisobjekt-Manager 207 enthält den API-Konnektor 145 als Verbindungsschnittstelle für eine relationale Datenbank zur Erleichterung von Datenübertragungen (z.B.
  • Empfangen von Abfragen und Senden bzw. Übertragen von Ergebnisdaten) zwischen dem netzwerkbasierten Data-Warehouse-System 102 und der Cluster-Computing-Plattform 150. Zum Beispiel kann eine auf der Cluster-Computing-Plattform 150 laufende Kundenanwendung eine Abfrage zum netzwerkbasierten Data-Warehouse-System 102 ausgeben, die zum API-Konnektor 145 gerichtet ist, zum Analysieren bzw. Parsen und Weiterleiten als Jobanforderung zum Anforderungsverarbeitungsdienst. Obwohl der API-Konnektor 145 derart dargestellt ist, dass er zwischen der Cluster-Computing-Plattform 150 und dem netzwerkbasierten Data-Warehouse-System 102 ist, ist der API-Konnektor 145 bei einigen beispielhaften Ausführungsformen im netzwerkbasierten Data-Warehouse-System 102 installiert, um Daten zur Cluster-Computing-Plattform 150 zu senden und zu empfangen, die eine extern ausgeführte Cluster-Computing-Plattform 150 sein kann, die durch ein anderes Unternehmen gemanagt wird (z.B. kann die Cluster-Computing-Plattform 150 ein Apache-Spark-Cluster sein, das durch die Databricks-Plattform oder andere Spark-Plattformen gehostet wird).
  • Der Computing-Service-Manager 112 enthält auch einen Job-Compiler 206, einen Job-Optimierer 208 und einen Job-Ausführer 210. Der Job-Compiler 206 parst bzw. zerlegt bzw. analysiert einen Job in mehrere diskrete Aufgaben und erzeugt den Ausführungscode für jede der mehreren diskreten Aufgaben. Der Job-Optimierer 208 bestimmt das beste Verfahren zum Ausführen der mehreren diskreten Aufgaben basierend auf den Daten, die verarbeitet werden müssen. Der Job-Optimierer 208 handhabt auch verschiedene Datenbereinigungsoperationen und andere Datenoptimierungstechniken, um die Geschwindigkeit und Effizienz eines Ausführens des Jobs zu verbessern. Der Job-Ausführer 210 führt den Ausführungscode für aus einer Warteschlange empfangene oder durch den Computing-Service-Manager 112 bestimmte Jobs aus.
  • Ein Job-Planer und -Koordinator 212 sendet empfangene Jobs zu den geeigneten Diensten oder Systemen zur Kompilierung, Optimierung und Entsendung zur Ausführungsplattform 114. Zum Beispiel können Jobs priorisiert und in dieser priorisierten Reihenfolge verarbeitet werden. Bei einer Ausführungsform bestimmt der Job-Planer und -Koordinator 212 eine Priorität für interne Jobs, die vom Computing-Service-Manager 112 geplant sind, mit anderen Jobs „von außen“, wie beispielsweise Benutzerabfragen, die von anderen Systemen in der Datenbank geplant sein können, aber dieselben Verarbeitungsressourcen in der Ausführungsplattform 114 verwenden können. Bei einigen Ausführungsformen identifiziert der Job-Planer und -Koordinator 212 bestimmte Knoten in der Ausführungsplattform 114 oder ordnet sie zu, um bestimmte Aufgaben zu verarbeiten. Ein Manger eines virtuellen Lagers 214 managt die Operation bzw. den Betrieb mehrerer virtueller Lager, die in der Ausführungsplattform 114 implementiert sind. Wie es nachstehend diskutiert wird, enthält jedes virtuelle Lager mehrere Ausführungsknoten, die jeweils einen Cache und einen Prozessor enthalten (z.B. eine virtuelle Maschine, eine Containerausführungsumgebung auf Betriebssystemebene).
  • Zusätzlich enthält der Computing-Service-Manager 112 einen Konfigurations- und Metadaten-Manager 216, der die Information in Bezug auf die in den entfernten Datenspeichervorrichtungen und in den lokalen Caches (d.h. den Caches in der Ausführungsplattform 114) gespeicherten Daten managt. Der Konfigurations- und Metadaten-Manager 216 verwendet die Metadaten, um zu bestimmen, auf welche Datenmikropartitionen zugegriffen werden muss, um Daten für die Verarbeitung einer bestimmten Aufgabe oder eines bestimmten Jobs wiederzugewinnen bzw. abzurufen. Überwachungs- und Arbeitslast-Analysierer 618 beaufsichtigt durch den Computing-Service-Manager 112 durchgeführte Prozesse und managt die Verteilung von Aufgaben (z.B. Arbeitslast) quer über die virtuellen Lager und Ausführungsknoten in der Ausführungsplattform 114. Der Überwachungs- und Arbeitslast-Analysierer 218 verteilt auch Aufgaben neu, wie es nötig ist, basierend auf sich ändernden Arbeitslasten über dem gesamten Data Warehouse 102 und kann weiterhin Aufgaben basierend auf einer Abfragearbeitslast eines Benutzers (d.h. „von extern“) neu verteilen, die auch durch die Ausführungsplattform 114 verarbeitet werden kann. Der Konfigurations- und Metadaten-Manager 216 und der Überwachungs- und Arbeitslast-Analysierer 218 sind mit einer Datenspeichervorrichtung 220 gekoppelt. Die Datenspeichervorrichtung 220 in 2 stellt irgendeine Datenspeichervorrichtung innerhalb des Data Warehouses bzw. Datenlagers 102 dar. Zum Beispiel kann die Datenspeichervorrichtung 220 Caches in der Ausführungsplattform 114, Speichervorrichtungen in der Cloud-Computing-Speicherplattform 104 oder irgendeine andere Speichervorrichtung darstellen.
  • 3 ist ein Blockdiagramm, das Komponenten der Ausführungsplattform 114 gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt. Wie es in 3 gezeigt ist, enthält die Ausführungsplattform 114 mehrere virtuelle Lager, die elastische Cluster von Computing-Instanzen sind, wie beispielsweise virtuelle Maschinen. Beim dargestellten Beispiel enthalten die virtuellen Lager ein virtuelles Lager 1, ein virtuelles Lager 2 und ein virtuelles Lager n. Jedes virtuelle Lager (z.B. ein EC2-Cluster) enthält mehrere Ausführungsknoten (z.B. virtuelle Maschinen), die jeweils einen Datencache und einen Prozessor enthalten. Die virtuellen Lager können mehrere Aufgaben parallel ausführen, indem sie die mehreren Ausführungsknoten verwenden. Wie es hierin diskutiert ist, kann die Ausführungsplattform 114 neue virtuelle Lager hinzufügen und vorhandene virtuelle Lager fallenlassen, und zwar in Echtzeit basierend auf den aktuellen Verarbeitungsanforderungen der Systeme und Benutzer. Diese Flexibilität lässt zu, dass die Ausführungsplattform 114 schnell große Mengen an Computerressourcen nutzt, wenn es nötig, ohne dazu gezwungen zu sein, fortgesetzt für diese Computerressourcen zu bezahlen, wenn sie nicht mehr benötigt werden. Alle virtuellen Lager können auf Daten von irgendeiner Datenspeichervorrichtung (z.B. irgendeiner Speichervorrichtung in der Cloud-Computing-Speicherplattform 104) zugreifen.
  • Obwohl jedes in 3 gezeigte virtuelle Lager drei Ausführungsknoten enthält, kann ein bestimmtes virtuelles Lager irgendeine Anzahl von Ausführungsknoten enthalten. Weiterhin ist die Anzahl von Ausführungsknoten in einem virtuellen Lager dynamisch, so dass neue Ausführungsknoten erstellt werden, wenn zusätzlicher Bedarf vorhanden ist, und vorhandene bzw. existierende Ausführungsknoten gelöscht werden, wenn sie nicht mehr benötigt werden (z.B. auf eine Abfrage oder einen Jobabschluss hin).
  • Jedes virtuelle Lager ist in der Lage, auf irgendeine der in 1 gezeigten Datenspeichervorrichtungen 124-1 bis 124-n zuzugreifen. Somit sind die virtuellen Lager nicht notwendigerweise einer spezifischen Datenspeichervorrichtung 124-1 bis 124-n zugeordnet und können stattdessen auf Daten von irgendeiner der Datenspeichervorrichtungen 124-1 bis 124-n innerhalb der Cloud-Computing-Speicherplattform 104 zugreifen. Gleichermaßen kann jeder der in 3 gezeigten Ausführungsknoten auf Daten von irgendeiner der Datenspeichervorrichtungen 124-1 bis 124-n zugreifen. Zum Beispiel kann die Speichervorrichtung 124-1 eines ersten Benutzers (z.B. eines Anbieterkontobenutzers) mit einem Workerknoten in einem virtuellen Lager eines anderen Benutzers (z.B. eines Verbraucherkontobenutzers) geteilt werden, so dass der andere Benutzer eine Datenbank (z.B. eine Nurlese-Datenbank) erstellen und die Daten in der Speichervorrichtung 124-1 direkt verwenden kann, ohne die Daten kopieren zu müssen (z.B. sie zu einer neuen Diskette bzw. Platte kopieren, die durch den Verbraucherkontobenutzer gemanagt wird). Bei einigen Ausführungsformen kann ein bestimmtes virtuelles Warehouse oder ein bestimmter Ausführungsknoten vorübergehend einer spezifischen Datenspeichervorrichtung zugeordnet sein, aber das virtuelle Warehouse oder der Ausführungsknoten kann später auf Daten von irgendeiner anderen Datenspeichervorrichtung zugreifen.
  • Beim Beispiel von 3 enthält das virtuelle Lager 1 drei Ausführungsknoten 302-1, 302-2 und 302-n. Der Ausführungsknoten 302-1 enthält einen Cache 304-1 und einen Prozessor 306-1. Der Ausführungsknoten 302-2 enthält einen Cache 304-2 und einen Prozessor 306-2. Der Ausführungsknoten 302-n enthält einen Cache 304-n und einen Prozessor 306-n. Jeder Ausführungsknoten 302-1, 302-2 und 302-n ist mit einer Verarbeitung von einer oder mehreren Datenspeicherungs- und/oder Datenabrufaufgaben assoziiert. Zum Beispiel kann ein virtuelles Lager Datenspeicherungs- und Datenabrufaufgaben handhaben, die mit einem internen Dienst assoziiert sind, wie beispielsweise einem Clusterbildungsdienst, einem Auffrischungsdienst für eine materialisierte Ansicht, einem Dateikompaktierungsdienst, einem Speicherprozedurdienst oder einem Datei-Upgradedienst. Bei anderen Implementierungen kann ein bestimmtes virtuelles Lager Datenspeicherungs- und Datenabrufaufgaben handhaben, die mit einem bestimmten Datenspeichersystem oder einer bestimmten Datenkategorie assoziiert sind.
  • Ähnlich wie bei dem oben diskutierten virtuellen Lager 1 enthält das virtuelle Lager 2 drei Ausführungsknoten 312-1, 312-2 und 312-n. Der Ausführungsknoten 312-1 enthält einen Cache 314-1 und einen Prozessor 316-1. Der Ausführungsknoten 312-2 enthält einen Cache 314-2 und einen Prozessor 316-2. Der Ausführungsknoten 312-n enthält einen Cache 314-n und einen Prozessor 316-n. Zusätzlich enthält das virtuelle Lager 3 drei Ausführungsknoten 322-1, 322-2 und 322-n. Der Ausführungsknoten 322-1 enthält einen Cache 324-1 und einen Prozessor 326-1. Der Ausführungsknoten 322-2 enthält einen Cache 324-2 und einen Prozessor 326-2. Der Ausführungsknoten 322-n enthält einen Cache 324-n und einen Prozessor 326-n.
  • Bei einigen Ausführungsformen sind die in 3 gezeigten Ausführungsknoten zustandslos in Bezug auf die Daten, die die Ausführungsknoten im Cache speichern bzw. zwischenspeichern. Zum Beispiel speichern diese Ausführungsknoten Zustandsinformation über den Ausführungsknoten oder die Daten, die von einem bestimmten Ausführungsknoten zwischengespeichert werden, nicht oder halten sie nicht auf andere Weise. Somit kann im Fall eines Fehlers bzw. Ausfalls eines Ausführungsknotens der fehlerhafte bzw. ausgefallene Knoten transparent durch einen anderen Knoten ersetzt werden. Da es keine Zustandsinformation gibt, die mit dem fehlerhaften Ausführungsknoten assoziiert ist, kann der neue (Ersatz-) Ausführungsknoten den ausgefallenen Knoten auf einfache Weise ersetzen, ohne sich Gedanken über eine Neuerstellung eines bestimmten Zustands machen zu müssen.
  • Obwohl die in 3 gezeigten Ausführungsknoten jeweils einen Datencache und einen Prozessor enthalten, können alternative Ausführungsformen Ausführungsknoten umfassen, die irgendeine Anzahl von Prozessoren und irgendeine Anzahl von Caches enthalten. Zusätzlich können die Caches bezüglich der Größe zwischen den unterschiedlichen Ausführungsknoten variieren. Die in 3 gezeigten Caches speichern im lokalen Ausführungsknoten (z.B. in einer lokalen Platte) Daten, die von einer oder mehreren Datenspeichervorrichtungen in der Cloud-Computing-Speicherplattform 104 wiedergewonnen bzw. abgerufen wurden (z.B. S3-Objekte, auf die durch den gegebenen Knoten kürzlich zugegriffen ist). Bei einigen beispielhaften Ausführungsformen speichert der Cache Dateivorsätze bzw. Datei-Header und einzelne Spalten von Dateien, da eine Abfrage nur Spalten herunterlädt, die für diese Abfrage nötig sind.
  • Um Cache-Treffer zu verbessern und sich überlappende redundante Daten zu vermeiden, die in den Knoten-Caches gespeichert sind, ordnet der Job-Optimierer 208 den Knoten Eingabedateisätze unter Verwendung eines konsistenten Hashing-Schemas zu, um über Tabellendateinamen der Daten, auf die zugegriffen wird (z.B. Daten in der Datenbank 116 oder der Speicherplattform 122), zu hashen bzw. klein zu schneiden. Nachfolgende oder gleichzeitige Abfragen, die auf dieselbe Tabellendatei zugreifen, werden daher gemäß einigen beispielhaften Ausführungsformen auf demselben Knoten ausgeführt.
  • Wie es diskutiert ist, können sich die Knoten und virtuellen Lager in Reaktion auf Umgebungsbedingungen (z.B. Katastrophenszenarien), Hardware-/Softwareprobleme (z.B. Fehlfunktionen) oder administrative Änderungen (z.B. ein Ändern von einem großen Cluster zu einem kleineren Cluster zur Kostensenkung) dynamisch ändern. Bei einigen beispielhaften Ausführungsformen werden, wenn sich der Satz bzw. die Gruppe von Knoten ändert, keine Daten sofort umstrukturiert. Stattdessen wird die Ersatzpolitik für am wenigsten kürzlich verwendet implementiert, um die verlorenen Cacheinhalte über mehrere Jobs hinweg möglicherweise zu ersetzen. Somit reduzieren oder eliminieren die Caches die Engpassprobleme, die bei Plattformen auftreten, die konsistent Daten aus entfernten Speichersystemen abrufen. Anstatt wiederholt auf Daten aus den entfernten Speichervorrichtungen zuzugreifen, greifen die hierin beschriebenen Systeme und Verfahren auf Daten aus den Caches in den Ausführungsknoten zu, was signifikant schneller ist und das oben diskutierte Engpassproblem vermeidet. Bei einigen Ausführungsformen sind die Caches unter Verwendung von Hochgeschwindigkeits-Speichervorrichtungen implementiert, die einen schnellen Zugriff auf die zwischengespeicherten Daten bereitstellen. Jeder Cache kann Daten von irgendeiner der Speichervorrichtungen in der Cloud-Computing-Speicherplattform 104 speichern.
  • Weiterhin können die Cacheressourcen und Computerressourcen zwischen unterschiedlichen Ausführungsknoten variieren. Zum Beispiel kann ein Ausführungsknoten signifikante Computerressourcen und minimale Cacheressourcen enthalten, was den Ausführungsknoten für Aufgaben nützlich macht, die signifikante Computerressourcen erfordern. Ein anderer Ausführungsknoten kann signifikante Cacheressourcen und minimale Computerressourcen enthalten, was diesen Ausführungsknoten für Aufgaben nützlich macht, die das Zwischenspeichern großer Datenmengen erfordern. Ein noch weiterer Ausführungsknoten kann Cacheressourcen enthalten, die schnellere Eingabe-Ausgabe-Operationen bereitstellen, die für Aufgaben nützlich sind, die ein schnelles Scannen großer Datenmengen erfordern. Bei einigen Ausführungsformen implementiert die Ausführungsplattform 114 eine Versatz-Handhabung, um die Arbeit unter den Cacheressourcen und Computerressourcen zu verteilen, die mit einer bestimmten Ausführung assoziiert sind, wobei die Verteilung weiterhin auf den erwarteten Aufgaben basieren kann, die durch die Ausführungsknoten ausgeführt werden sollen. Zum Beispiel kann ein Ausführungsknoten mehreren Verarbeitungsressourcen zugeordnet werden, wenn die durch den Ausführungsknoten durchgeführten Aufgaben prozessorintensiver werden. Gleichermaßen kann ein Ausführungsknoten mehreren Cacheressourcen zugeordnet werden, wenn die durch den Ausführungsknoten durchgeführten Aufgaben eine größere Cachekapazität erfordern. Weiterhin können einige Knoten aufgrund verschiedener Probleme (z.B. Virtualisierungsprobleme, Netzwerk-Overhead) viel langsamer ausführend sein als andere. Bei einigen beispielhaften Ausführungsformen werden die Ungleichgewichte auf der Abtast- bzw. Scan-Ebene unter Verwendung eines Dateidiebstahlschemas behoben. Insbesondere fordert, wann immer ein Knotenprozess ein Scannen seiner Eingabedateien abschließt, er zusätzliche Dateien von anderen Knoten an. Wenn der eine der anderen Knoten eine solche Anforderung empfängt, analysiert der Knoten seinen eigenen Satz (z.B. wie viele Dateien beim Empfang der Anforderung im Eingabedateisatz gelassen sind) und überträgt dann das Eigentumsrecht bzw. den Besitz von einer oder mehreren der verbleibenden Dateien für die Dauer des aktuellen Jobs (z.B. der Abfrage). Der anfordernde Knoten (z.B. der Dateidiebstahlknoten) empfängt dann die Daten (z.B. Header-Daten) und lädt die Dateien von der Cloud-Computing-Speicherplattform 104 (z. B. von der Datenspeichervorrichtung 124-1) herunter und lädt die Dateien nicht vom übertragenden Knoten herunter. Auf diese Weise können zurückbleibende bzw. nacheilende Knoten Dateien über einen Dateidiebstahl auf eine Weise übertragen, die die Belastung an den zurückbleibenden Knoten nicht verschlechtert.
  • Obwohl die virtuellen Lager 1, 2 und n mit derselben Ausführungsplattform 114 assoziiert sind, können die virtuellen Lager unter Verwendung von mehreren Computersystemen an mehreren geografischen Standorten implementiert werden. Zum Beispiel kann das virtuelle Lager 1 durch ein Computersystem an einem ersten geografischen Standort implementiert werden, während die virtuellen Lager 2 und n durch ein anderes Computersystem an einem zweiten geografischen Standort implementiert werden. Bei einigen Ausführungsformen sind diese unterschiedlichen Computersysteme cloudbasierte Computersysteme, die durch ein oder mehrere unterschiedliche Unternehmen unterhalten werden.
  • Zusätzlich ist jedes virtuelle Lager in 3 derart gezeigt, dass es mehrere Ausführungsknoten hat. Die mit jedem virtuellen Lager assoziierten mehreren Ausführungsknoten können unter Verwendung mehrerer Computersysteme an mehreren geografischen Standorten implementiert werden. Zum Beispiel implementiert eine Instanz des virtuellen Lagers 1 die Ausführungsknoten 302-1 und 302-2 auf einer Computerplattform an einem geografischen Standort und implementiert den Ausführungsknoten 302-n auf einer anderen Computerplattform an einem anderen geografischen Standort. Ein Auswählen bestimmter Computersysteme, um einen Ausführungsknoten zu implementieren, kann von verschiedenen Faktoren abhängen, wie beispielsweise dem Ausmaß von Ressourcen, die für einen bestimmten Ausführungsknoten nötig sind (z.B. Verarbeitungsressourcenanforderungen und Cacheanforderungen), den Ressourcen, die bei bestimmten Computersystemen verfügbar sind, Kommunikationsfähigkeiten von Netzwerken innerhalb eines geografischen Standorts oder zwischen geografischen Standorten und welche Computersysteme bereits andere Ausführungsknoten im virtuellen Lager implementieren.
  • Die Ausführungsplattform 114 ist auch fehlertolerant. Wenn zum Beispiel ein virtuelles Lager ausfällt, wird dieses virtuelle Lager schnell durch ein anderes virtuelles Lager an einem anderen geografischen Standort ersetzt.
  • Eine bestimmte Ausführungsplattform 114 kann irgendeine Anzahl von virtuellen Lagern enthalten. Zusätzlich ist die Anzahl von virtuellen Lagern in einer bestimmten Ausführungsplattform dynamisch, so dass neue virtuelle Lager erstellt werden, wenn zusätzliche Verarbeitungs- und/oder Cachespeicherungs- bzw. Zwischenspeicherungs-Ressourcen nötig sind. Gleichermaßen können existierende virtuelle Lager gelöscht werden, wenn die mit dem virtuellen Lager assoziierten Ressourcen nicht mehr nötig sind.
  • Bei einigen Ausführungsformen können die virtuellen Lager an denselben Daten in der Cloud-Computing-Speicherplattform 104 arbeiten, aber jedes virtuelle Lager hat seine eigenen Ausführungsknoten mit unabhängigen Verarbeitungs- und Cachespeicherungs- bzw. Zwischenspeicherungs-Ressourcen. Diese Konfiguration lässt zu, dass Anforderungen an unterschiedlichen virtuellen Lagern unabhängig und ohne Interferenz zwischen den Anforderungen verarbeitet werden. Diese unabhängige Verarbeitung, kombiniert mit der Fähigkeit, virtuelle Lager dynamisch hinzuzufügen und zu entfernen, unterstützt das Hinzufügen neuer Verarbeitungskapazität für neue Benutzer, ohne die von den existierenden Benutzern beobachtete Leistungsfähigkeit zu beeinflussen bzw. zu beeinträchtigen.
  • 4 zeigt eine beispielhafte Metadaten-Konnektorarchitektur 400 für verteiltes Cluster-Computing gemäß einigen beispielhaften Ausführungsformen. Beim in 4 dargestellten Beispiel umfasst die Cluster-Computing-Plattform 150 einen Benutzercode 420 (z.B. Endbenutzercode, Abfragen, eine Spark-Anwendung etc.), der Daten bei einem Cluster-Ansatz unter Verwendung eines Masterknotens 425 (z.B. eines Treiberknotens) und einer Vielzahl von Workerknoten 430 verarbeitet. Die Cluster-Computing-Plattform 150 ist so konfiguriert, dass sie das netzwerkbasierte Data-Warehouse-System 102 als relationale Datenquelle über den API-Konnektor 145 (z.B. einen JDBC-Konnektor) verwendet. Beim Beispiel enthält der Benutzercode 420 eine Abfrage im Format für den API-Konnektor 145 (z.B. „ExecuteQuery (= Abfrage ausführen)“, die dann die Abfrage gegen das netzwerkbasierte Data-Warehouse-System 102 im Abfrageformat für das netzwerkbasierte Data-Warehouse-System 102 ausführt (z.B. „execute (= ausführen)“). Das netzwerkbasierte Data-Warehouse-System 102 implementiert ein oder mehrere virtuelle Lager und Speichervorrichtungen bei einem entkoppelten skalierbaren Ansatz, wie es oben in Bezug auf die 1-3 diskutiert ist, um Abfragedaten 407 (z.B. Abfrageergebnisse) zu erzeugen, die zur Erzeugung von Ergebnisdateien 410 verwendet werden.
  • Bei einigen Ausführungsformen sind die Ergebnisdateien 410 serialisierte Objekte, die eine Serialisierungsschnittstelle verwenden (z.B. Java-Serialisierung, Ergebnisdateien 1, 2, 3, ..., n, eine serialisierte Datei in JSON, die an Arbeitern bzw. Workern dekomprimiert werden kann). Zum Beispiel implementiert das netzwerkbasierte Data-Warehouse-System 102 eine Java-Serialisierungsschnittstelle beim Aufbau bzw. Bilden der Objekte (z.B. import.java.io.serializable zur Serialisierung unter Verwendung von einer ObjectOutputStream-Klasse unter Verwendung der write-Object()-Methode). Die Serialisierung der Objekte speichert den Objektzustand in einer Sequenz bzw. Folge von Bytes und speichert den Prozess eines erneuten Bildens zu Bytes in ein verarbeitbares Objekt, das zu einer späteren Zeit verarbeitet werden kann (z.B. erneutes Bilden und Verarbeiten auf einem gegebenen Workerknoten). Bei einigen beispielhaften Ausführungsformen werden die Abfragedaten 407 als JSON-Daten zurückgegeben bzw. zurückgebracht, die dann zum Erstellen eines serialisierten Objekts verwendet werden, wobei die Schema- und Variablenwerte in der Serialisierungsschnittstelle beibehalten werden, damit die Ergebnisdateien als serialisierte Objekte zur Speicherung auf S3 komprimiert, dann durch Workerknoten-Anforderungen zu den Arbeitsknoten verteilt, und dann für jeden Workerknoten dekomprimiert (z.B. deserialisiert, wiederhergestellt) werden können. Bei einigen beispielhaften Ausführungsformen enthalten die Serialisierungsvariablen, für die ein Zustand gespeichert ist, folgendes: Spaltennamen aus Tabellen, die abgefragt werden, Indizes, bei denen sich basierend auf den Daten, die abgefragt werden, ändern kann, welche Daten serialisiert oder persistent sind (z.B. Daten im netzwerkbasierten Data-Warehouse-System 102, Schema, Tabellenmenge, Datentyp etc., die durch die Cluster-Computing-Plattform 150 abgefragt werden). Die Größe der serialisierten und zu einer Staging-Plattform 405 gespeicherten Objekte kann gemäß einer Implementierung variieren (z.B. Einrichten einer großen Dateiengröße, um eine Menge von Ergebnisdateien zu reduzieren, oder Einrichten einer kleinen Dateiengröße, um eine Dateienmenge zu erhöhen, sich aber auf zusätzlichen Workerknoten zu verlassen, um die verteilte Leistungsfähigkeit zu erhöhen). Obwohl bei den Beispielen hier JSON diskutiert ist, wird es eingesehen, dass die Objekte im Arrow-Format und in zusätzlichen Binärformaten konstruiert bzw. ausgebildet und serialisiert werden können.
  • Das netzwerkbasierte Data-Warehouse-System 102 speichert dann die Ergebnisdateien 410 zu einer Staging-Plattform 405. Die Staging-Plattform 405 kann eine Cloud-Speicherdatenbank (z.B. S3) sein, die elastisch ist und skalieren kann, um große Mengen von Ergebnisdateien und Verbindungen von der Cluster-Computing-Plattform 150 (z.B. Workerknoten-Anforderungen) zu handhaben.
  • Wie es diskutiert ist, kann dann, wenn der Masterknoten 425 auf die Ergebnisdateien 410 in der Staging-Plattform 405 zugreift (z.B. um sie abzurufen und einen Plan für eine Verteilung der Daten zu Workern zu bestimmen), ein Engpass auftreten, wenn die Größe der Ergebnisdateien zunimmt. Um Engpässe zu vermeiden und eine Skalierbarkeit zu ermöglichen, bildet die Snowflake-Plattform einen Objektmetadatensatz (z.B. Wrapper bzw. Umhüllung, Umschlag) aus, der die Daten in der Plattform 405 beschreibt und den Objektmetadatensatz zum API-Konnektor 145 überträgt, um ihn zur Cluster-Computing-Plattform 150 zu senden. Zum Beispiel und gemäß einigen beispielhaften Ausführungsformen enthält das netzwerkbasierte Data-Warehouse-System 102 im Objektmetadatensatz folgendes: den ersten Chunk bzw. Block (das aktuelle Ergebnisdateiobjekt) und Datei-URLs, Zeilenanzahlen, komprimierte/unkomprimierte Größen und Anmeldeinformations- bzw. Berechtigungsnachweisdaten für die anderen Blöcke der Ergebnisdateien 410, die sich noch in der Staging-Plattform 405 befinden.
  • Der API-Konnektor 145 empfängt den Objektmetadatensatz, liest ihn nicht oder muss ihn nicht modifizieren und sendet ihn zur Cluster-Computing-Plattform 150, z.B. zum Masterknoten 425. Auf diese Weise ist, selbst wenn die Menge an Ergebnisdateien extrem groß ist, der die Ergebnisdateien beschreibende Objektmetadatensatz noch klein und einfach zu verarbeiten und zu senden. Anschließend verteilt der Masterknoten 425 dann die einzelnen Objekte im Objektmetadatensatz zu den Workerknoten unter Verwendung einer Verteilung und von Optimierungen, die für die Cluster-Computing-Plattform 150 natürlich sind. Wenn zum Beispiel die Cluster-Computing-Plattform 150 Apache Spark ist, dann verteilt der Masterknoten 425 die Objekte als RDDs zu den Workerknoten 430, wo eine Verteilung von RDDs und ein Reihenfolgenbildung durch die natürlichen bzw. nativen Optimierungen intern von Apache Spark gehandhabt werden. Es wird eingesehen, dass, obwohl Apache Spark hier als Beispiel verwendet wird, die Cluster-Computing-Plattform 150 andere Cluster-Modus-Plattformen, wie beispielsweise Cassandra oder Hadoop, sein kann. Bei diesen beispielhaften Implementierungen können die Clustersysteme die Objekte zur Berechnung noch auf einfache Weise empfangen und verteilen. Zum Beispiel kann die Cluster-Computing-Plattform 150 Hadoop sein und die serialisierbaren Speicherobjekte effizient zu Knoten verteilen, die dann schnell auf die Daten auf der Staging-Plattform 405 zugreifen, sie dekomprimieren und weitere Aktionen über die Hadoop-Anwendung (z.B. MapReduce-Operationen) auf ähnliche Weise ausführen können.
  • Fährt man fort, empfangen die Workerknoten 430 die Objekte und verwenden dann den Konnektorfunktionsaufruf 415, um die Ergebnisdateien abzurufen, die jeweiligen Workern von der Staging-Plattform 405 zugeordnet sind. Zum Beispiel ruft, wie es dargestellt ist, ein Worker 2 die Funktion „getResultSet()“ zum Konnektor JDBC_2 auf, um ein Standard-JDBC-ResultSet-Objekt mit einer Ergebnisdatei 2 auf der Staging-Plattform 405 zu bekommen, wo die zurückgebrachten Daten dekomprimiert werden (z.B. JSON-Deserialisierer). Gemäß einigen beispielhaften Ausführungsformen wird die getResultSet()-Funktion auf den Standard-getResult()-Aufruf abgebildet, der für JDBC im API-Konnektor 145 nativ ist (z.B. wird der Konnektorcode erweitert oder modifiziert, um das Abbilden zu speichern). Gleichermaßen ruft ein Worker 3 die Funktion „getResuItSet()“ zum Konnektor JDBC_3 auf, um ein Standard-JDBC-ResultSet-Objekt mit einer Ergebnisdatei 3 auf der Staging-Plattform 405 zu bekommen, und können zusätzliche Workerknoten gleichermaßen auf Ergebnissatzdaten von zusätzlichen Ergebnisdateien zugreifen (z.B. Workerknoten n unter Verwendung von JDBC_n, um ResultSet n zu empfangen). Beim dargestellten Beispiel greift der erste Workerknoten nicht auf den ersten Block (z.B. Ergebnisdatei 1) zu, da diese Datei im Objektmetadatensatz enthalten war (z.B. ist dort, wo die Ergebnisdatei 1 oder der erste Block eines Ergebnissatzes typischerweise klein ist, sie in den über den API-Konnektor 145 gesendeten Metadatenobjekten enthalten). Weiterhin sind gemäß einigen beispielhaften Ausführungsformen der Konnektorfunktionsaufruf 415 Aufrufe zum API-Konnektor 145, während bei anderen beispielhaften Ausführungsformen jedes von JDBC_1, JDBC_2, JDBC_3, JDBC_n etc. separate Instanzen eines einzelnen API-Konnektors sind, die für jeden Arbeitsknoten installiert sind. Fährt man fort, kann dann, wenn die Workerknoten 430 einmal ihre zugeordneten jeweiligen Teilbereiche der Ergebnisdaten über HTTP URL herunterladen und sie dekomprimieren, jeder Workerknoten eine Analyse durchführen und weitermachen gemäß dem Benutzercode 420 (z.B. weitere Verarbeitung, Abfragen, Filtererzeugung von Visualisierungen und andere Aktionen, die durch einen Endbenutzer angewiesen werden).
  • Bei einigen beispielhaften Ausführungsformen werden die Ergebnisdateien 410 als Objekte in der Staging-Plattform 405 für eine vorkonfigurierte Zeitperiode gespeichert, um eine schnelle Wiederverarbeitung der abgefragten Daten durch die Workerknoten zu einer späteren Zeit zu ermöglichen. Zum Beispiel werden die Ergebnisdateien 410 für eine gegebene Abfrage 36 Stunden lang (z.B. eine Sitzung bzw. Session) auf der Staging-Plattform 405 gespeichert, um zu ermöglichen, dass die Worker die abgefragten Daten schnell erneut verarbeiten und deserialisieren, ohne neue Ergebnisdateien zu erstellen und neue Serialisierungen zu definieren. Weiterhin laufen gemäß einigen beispielhaften Ausführungsformen die durch die Worker verwendeten Anmeldeinformationen bzw. Berechtigungsnachweise (z.B. aus dem Umschlag empfangen) ab, um eine Sicherheit zu erhöhen (z.B. laufen die Anmeldeinformationen des Workers 2 für einen Zugriff auf Die Ergebnisdatei 2 auf der Staging-Plattform 405 innerhalb von 6 Stunden ab).
  • 5 zeigt ein Ablaufdiagramm eines Verfahrens 500 zum Erzeugen von Ergebnisdateien und Objektmetadatensatzelementen zur Cluster-Computing-Verarbeitung gemäß einigen beispielhaften Ausführungsformen. Bei einer Operation 505 verbindet das Computercluster mit einer Datenquelle, gegenüber welcher das Computercluster Abfragen ausführen kann. Zum Beispiel wird bei der Operation 505 der Masterknoten der Cluster-Computing-Plattform 150 über einen API-Konnektor, wie beispielsweise den API-Konnektor 145, mit dem netzwerkbasierten Data-Warehouse-System 102 verbunden.
  • Bei einer Operation 510 empfängt das netzwerkbasierte Data-Warehouse-System 102 eine Abfrage vom Cluster. Zum Beispiel führt bei der Operation 510 eine Kundenanwendung auf der Cluster-Computing-Plattform 150 eine Abfrage aus, die über den API-Konnektor 145 zum netzwerkbasierten Data-Warehouse-System 102 zum Verarbeiten gegenüber Datenbanken übertragen wird, die durch das netzwerkbasierte Data-Warehouse-System 102 gemanagt werden. Bei einer Operation 515 führt das netzwerkbasierte Data-Warehouse-System 102 die Abfrage aus. Zum Beispiel führt das netzwerkbasierte Data-Warehouse-System 102 die Abfrage gegenüber Daten aus, die durch die gemeinsam genutzte Datenverarbeitungsplattform 100 gemanagt werden, indem es die virtuellen Lager verwendet, die oben unter Bezugnahme auf die 1-3 diskutiert sind.
  • Bei einer Operation 520 erzeugt das netzwerkbasierte Data-Warehouse-System 102 aus den Abfragedaten Ergebnisdateien. Wie es diskutiert ist, sind die Ergebnisdateien über den API-Konnektor 145 serialisierbar (z.B. java.io.serializable) und können zur entfernten Verarbeitung zu unterschiedlichen Systemen übertragen werden, wie beispielsweise zu den Cluster-Computing-Plattform-Workerknoten. Bei einer Operation 525 speichert das netzwerkbasierte Data-Warehouse-System 102 die erzeugten Ergebnisdateien. Zum Beispiel speichert das netzwerkbasierte Data-Warehouse-System 102 bei der Operation 525 die Ergebnisdateien in der cloudbasierten Staging-Plattform wie beispielsweise Amazon S3 oder Microsoft Azure.
  • Bei einer Operation 530 erzeugt das netzwerkbasierte Data-Warehouse-System 102 einen Objektmetadatensatz, der die auf der Staging-Plattform gespeicherten serialisierten Daten beschreibt. Wie es oben diskutiert ist, kann der Objektmetadatensatz eine erste Ergebnisdatei oder Chunk- bzw. Blockdaten enthalten, und Metadaten, die die Ergebnisdateien beschreiben, die in der Staging-Plattform gespeichert sind, einschließlich Ergebnisdateigrößen, Dateiformaten, Anmeldeinformationen oder Zugriffsinformationen, Dateipfaden (z.B. Netzwerkadressen, URLs) für jede der Ergebnisdateien auf der Staging-Plattform.
  • Bei einer Operation 535 überträgt das netzwerkbasierte Warehouse-System den Objektmetadatensatz. Zum Beispiel überträgt das netzwerkbasierte Data-Warehouse-System 102 bei der Operation 535 den Objektmetadatensatz über den API-Konnektor 145 zur Cluster-Computing-Plattform 150 zur Verteilung zum Workerknoten und zur weiteren Verarbeitung.
  • 6 zeigt das Ablaufdiagramm eines Verfahrens 600 zum Verarbeiten von Ergebnisdateien, die vom API-Konnektor empfangen sind, gemäß einigen beispielhaften Ausführungsformen. Bei einer Operation 605 empfängt die Cluster-Computing-Plattform 150 den Objektmetadatensatz. Zum Beispiel empfängt der Masterknoten der Cluster-Computing-Plattform 150 bei der Operation 605 den Objektmetadatensatz vom API-Konnektor 145. Bei einer Operation 610 verteilt die Cluster-Computing-Plattform 150 Objektmetadatensatzelemente. Zum Beispiel verteilt der Masterknoten der Cluster-Computing-Plattform 150 bei der Operation 610 den Objektmetadatensatz unter seinen Workerknoten, wie z.B. ein Metadatenelement pro Workerknoten, wobei es jedes der Metadatenobjekte dem Empfänger-Workerknoten ermöglicht, eine der Ergebnisdateien auf der Staging-Plattform zur Verarbeitung abzurufen.
  • Bei einer Operation 615 ruft die Cluster-Computing-Plattform 150 Ergebnisdateien von der Staging-Plattform ab. Zum Beispiel führen die Workerknoten der Cluster-Computing-Plattform 150 bei der Operation 615 einen Funktionsaufruf zum API-Konnektor 145 (z.B. GetResult()) aus, um direkt auf Ergebnisdateien von der Staging-Plattform zuzugreifen und diese herunterzuladen. Der API-Konnektor 145 empfängt den Funktionsaufruf von einem gegebenen Workerknoten und bringt Ergebnisdaten, wie z.B. ResultSet in JDBC, zurück, die die Ergebnisdateien in der Staging-Plattform enthalten, die dem gegebenen Knoten zugeordnet ist.
  • Bei einer Operation 620 parst die Cluster-Computing-Plattform 150 die abgerufenen Ergebnisdateien. Zum Beispiel lädt jeder der Worker bei der Operation 620 die Speicherobjekt-Ergebnisdatei von der Staging-Plattform herunter, dekomprimiert sie (z.B. deserialisiert sie unter Verwendung eines JSON-Serialisierers) und speichert die Ergebnisdaten in unkomprimierter Form zur Verarbeitung.
  • Bei einer Operation 625 führt die Cluster-Computing-Plattform 150 Anwendungsoperationen an den abgerufenen Ergebnisdateien durch. Zum Beispiel führt jeder der Workerknoten in der Cluster-Computing-Plattform 150 bei der Operation 625 zusätzliche analytische Operationen (z.B. Datenwissenschafts- bzw. Data-Science-Operationen, Visualisierungserzeugungsoperationen, interne Abfrage- und Datenanordnungsoperationen) unter Verwendung der nativen Funktionalität oder von Anweisungen der Cluster-Computing-Plattform 150 (z.B. Standardfunktionen von Apache Spark, Spark-Maschinenlernbibliotheken) durch.
  • Bei einer Operation 630 zeigt die Cluster-Computing-Plattform 150 verarbeitete Ergebnisdaten auf einer Benutzeroberfläche an. Zum Beispiel zeigt die Kundenanwendung auf der Cluster-Computing-Plattform 150 bei der Operation 630 die Datenvisualisierung oder Abfrageergebnisse auf einer Benutzeroberfläche einer Benutzervorrichtung, wie beispielsweise der Benutzervorrichtung 106, an. Bei einer Operation 635 werden die Daten, die Ergebnisdaten sind, erneut abgefragt. Wie es oben diskutiert ist, kann die Staging-Plattform zum Beispiel die Ergebnisdateiobjekte für eine begrenzte Zeit (z.B. 36 Stunden) aufbewahren, während welcher Zeit die Objekte und ein Serialisierungsprozess für einen gegebenen Datensatz nicht erneut verarbeitet werden müssen. Vielmehr verbleiben die Daten auf der Staging-Plattform und kann die Cluster-Computing-Plattform 150 Daten unter Verwendung des verteilten Serialisierungsansatzes abfragen. Gemäß einigen beispielhaften Ausführungsformen werden die serialisierten Ergebnisobjekte nach Ablauf der Aufbewahrungsperiode gelöscht oder auf andere Weise von der Staging-Plattform entfernt.
  • 7 zeigt ein Netzwerkbahndiagramm 700 zum Implementieren von Cluster-Computing unter Verwendung eines Metadaten-Konnektors gemäß einigen beispielhaften Ausführungsformen. Im Netzwerkbahndiagramm 700 entspricht jede der Spalten oder Bahnen durch die unterschiedlichen Einheiten bzw. Entitäten ihrer jeweiligen Bahnen durchgeführten Aktionen. In der ersten Spalte werden zum Beispiel die Operationen 715, 720 und 730 durch das netzwerkbasierte Data-Warehouse-System 102 durchgeführt. Gleichermaßen führt der API-Konnektor 145 die Operationen 710, 735 und 755 durch; führt die Cluster-Computing-Plattform 150 die Operationen 705, 740, 745, 750 und 765 durch; und führt die Staging-Plattform 405 die Operationen 725 und 760 durch, und zwar gemäß einigen beispielhaften Umgebungen. Es wird eingesehen, dass, obwohl die Entitäten beim Beispiel der 7 als separate Einheiten diskutiert und gezeigt sind, die Entitäten kombiniert oder integriert sein können, wie es von denjenigen eingesehen wird, die über durchschnittliche Fachkenntnisse auf dem Gebiet verfügen. Zum Beispiel kann der API-Konnektor 145 als Komponente des netzwerkbasierten Data-Warehouse-Systems 102 installiert sein.
  • Bei der Operation 705 erzeugt die Cluster-Computing-Plattform 150 eine Abfrage. Zum Beispiel erstellt oder entwickelt ein Spark-Benutzer einen Apache-Spark-Job (z.B. eine Kundenanwendung), wo der Job durch die Cluster-Computing-Plattform 150 gemanagt wird, z.B. empfängt der Masterknoten den Job und erzeugt die Abfrage für Daten, wobei die Daten durch das netzwerkbasierte Data-Warehouse-System 102 gemanagt werden. Bei der Operation 710 wandelt der API-Konnektor 145 die Abfrage zur Ausführung gegenüber dem netzwerkbasierten Data-Warehouse-System 102 um. Bei der Operation 715 führt das netzwerkbasierte Data-Warehouse-System 102 die empfangene Abfrage gegenüber einem oder mehreren relationalen Datenspeichern aus, um Abfrageergebnisdaten zu erzeugen. Bei der Operation 720 überträgt das netzwerkbasierte Data-Warehouse-System 102 die Ergebnisdateien zur Staging-Plattform 405, die die Ergebnisdateien dann bei der Operation 725 speichert. Gemäß einigen beispielhaften Ausführungsformen serialisiert das netzwerkbasierte Data-Warehouse-System 102 die Ergebnisdatenergebnisse als serialisierbare Objekte über eine Konnektor-API (Java-serialisierbare Schnittstelle). Bei der Operation 730 erzeugt das netzwerkbasierte Data-Warehouse-System 102 Metadaten (z.B. den Objektmetadatensatz), die die Dateien beschreiben, die in der Staging-Plattform 405 gespeichert sind (z.B. Adresse, Format, Ort, Größe), und Zugriffsdaten (z.B. Netzwerkanmeldeinformationen), die die Cluster-Computing-Plattform 150 implementieren kann, um auf die gespeicherten Ergebnisdaten zuzugreifen. Bei der Operation 735 empfängt der API-Konnektor 145 den Objektmetadatensatz. Bei der Operation 745 verteilt der Masterknoten der Cluster-Computing-Plattform 150 die Metadatenobjekte zu jedem der Workerknoten. Bei der Operation 750 empfängt jeder der Workerknoten ein Objektmetadatenelement aus der Liste und führt einen Funktionsaufruf zum API-Konnektor 145 durch. Bei der Operation 755 fungiert der API-Konnektor 145 als Versorgungseinrichtung für die Workerknoten und führt die Aufrufe (z.B. GetResult(), um ResultSet für einen gegebenen Knoten zurückzubringen) aus, um auf die Ergebnisdateien auf der Staging-Plattform 405zuzugreifen. Die Staging-Plattform 405 sendet dann bei der Operation 760 die Ergebnisse zum Workerknoten. Bei der Operation 765 verarbeiten die Workerknoten der Cluster-Computing-Plattform 150 die heruntergeladenen Ergebnisdateien. Zum Beispiel lädt jeder der Workerknoten eine Ergebnisdatei in serialisierter Form herunter und dekomprimiert sie und führt eine weitere Verarbeitung an den Daten gemäß der Kundenanwendung durch (wie z.B. eine Analyseverarbeitung, Maschinenlernverfahren etc.).
  • 8 stellt eine schematische Darstellung einer Maschine 800 in der Form eines Computersystems dar, innerhalb von welchem eine Gruppe von Anweisungen ausgeführt werden kann, zum Veranlassen, dass die Maschine 800 irgendeine oder mehrere der hierin diskutieren Methoden durchführt, gemäß einer beispielhaften Ausführungsform. Spezifisch zeigt 8 eine schematische Darstellung der Maschine 800 in der beispielhaften Form eines Computersystems, innerhalb von welchem Anweisungen 816 (z.B. Software, ein Programm, eine Anwendung, ein Applet, eine App oder ein anderer ausführbarer Code) zum Veranlassen, dass die Maschine 800 irgendeine oder mehrere der hierin diskutierten Methoden durchführt, ausgeführt werden können. Die Anweisungen 816 können zum Beispiel veranlassen, dass die Maschine 800 irgendeine oder mehrere Operationen von irgendeinem oder mehreren der Verfahren 500, 600 und 700 ausführt. Auf diese Weise transformieren die Anweisungen 816 eine allgemeine, nicht programmierte Maschine in eine bestimmte Maschine 800 (z.B. die Benutzervorrichtung 106, das Zugriffsmanagementsystem 110, den Computing-Service-Manager 112, die Ausführungsplattform 114, das Zugriffsmanagementsystem 118, die Cloud-Schnittstelle 120), die speziell konfiguriert ist, um irgendeine der beschriebenen und dargestellten Funktionen auf die hierin beschriebene Weise auszuführen.
  • Bei alternativen Ausführungsformen arbeitet die Maschine 800 als alleinstehende Vorrichtung oder sie kann mit anderen Maschinen gekoppelt (z.B. vernetzt) sein. Bei einer vernetzten Verwendung kann die Maschine 800 in der Funktion einer Server-Maschine oder einer Client-Maschine in einer Server-Client-Netzwerkumgebung oder als Peer-Maschine in einer Peer-zu-Peer-(oder verteilten)Netzwerkumgebung arbeiten. Die Maschine 800 kann, ist aber nicht beschränkt darauf, einen Servercomputer, einen Client-Computer, einen Personalcomputer (PC), einen Tablet-Computer, einen Laptop-Computer, ein Netbook, ein Smartphone, ein mobiles Gerät, einen Netzwerkrouter, einen Netzwerkschalter, eine Netzwerkbrücke oder irgendeine Maschine, die die Anweisungen 816 sequentiell oder auf andere Weise ausführen kann, die von der Maschine 800 vorzunehmende Aktionen spezifizieren, umfassen. Weiterhin soll, während nur eine einzige Maschine 800 dargestellt ist, der Ausdruck „Maschine“ auch derart genommen werden, dass er eine Sammlung von Maschinen 800 enthält, die einzeln oder gemeinsam die Anweisungen 816 ausführen, um irgendeine oder mehrere der hierin diskutierten Methoden durchzuführen.
  • Die Maschine 800 enthält Prozessoren 810, einen Speicher 830 und Eingabe-/Ausgabe-(I/O-)Komponenten 850, die konfiguriert sind, um miteinander zu kommunizieren, wie beispielsweise über einen Bus 802. Bei einer beispielhaften Ausführungsform können die Prozessoren 810 (z.B. eine zentrale Verarbeitungseinheit (CPU), ein Prozessor mit reduziertem Befehlssatz (RISC), ein Prozessor mit komplexem Befehlssatz (CISC), eine Grafikverarbeitungseinheit (GPU), ein digitaler Signalprozessor (DSP), eine anwendungsspezifische integrierte Schaltung (ASIC), eine integrierte Funkfrequenz-Schaltung (RFIC), ein anderer Prozessor oder irgendeine geeignete Kombination davon) zum Beispiel einen Prozessor 812 und einen Prozessor 814 umfassen, die die Anweisungen 816 ausführen können. Es ist beabsichtigt, dass der Ausdruck „Prozessor“ Mehrkernprozessoren 810 enthält, die zwei oder mehr unabhängige Prozessoren (auf die manchmal auch als „Kerne“ Bezug genommen wird) umfassen können, die Anweisungen 816 gleichzeitig ausführen können. Obwohl 8 mehrere Prozessoren 810 zeigt, kann die Maschine 800 einen einzelnen Prozessor mit einem einzigen Kern, einen einzelnen Prozessor mit mehreren Kernen (z.B. einen Mehrkernprozessor), mehrere Prozessoren mit einem einzigen Kern, mehrere Prozessoren mit mehreren Kernen oder eine beliebige Kombination davon enthalten.
  • Der Speicher 830 kann einen Hauptspeicher 832, einen statischen Speicher 834 und eine Speichereinheit 836 enthalten, die alle für die Prozessoren 810 zugreifbar bzw. zugänglich sind, wie beispielsweise über den Bus 802. Der Hauptspeicher 832, der statische Speicher 834 und die Speichereinheit 836 speichern die Anweisungen 816, die irgendeine oder mehrere der hierin beschriebenen Methoden oder Funktionen verkörpern. Die Anweisungen 816 können sich während ihrer Ausführung durch die Maschine 800 auch ganz oder teilweise innerhalb des Hauptspeichers 832, innerhalb des statischen Speichers 834, innerhalb der Speichereinheit 836, innerhalb von wenigstens einem der Prozessoren 810 (z.B. innerhalb des Cachespeichers des Prozessors) oder irgendeiner geeigneten Kombination davon befinden.
  • Die I/O-Komponenten 850 enthalten Komponenten, um eine Eingabe zu empfangen, eine Ausgabe zur Verfügung zu stellen, eine Ausgabe zu erzeugen, Information zu übertragen, Information auszutauschen, Messungen zu erfassen, und so weiter. Die spezifischen I/O-Komponenten 850, die in einer bestimmten Maschine 800 enthalten sind, werden vom Typ einer Maschine abhängen. Zum Beispiel werden portierbare bzw. tragbare Maschinen, wie beispielsweise Mobiltelefone, wahrscheinlich eine Berührungseingabevorrichtung oder andere solche Eingabemechanismen enthalten, während eine monitorlose Servermaschine wahrscheinlich keine solche Berührungseingabevorrichtung enthalten wird. Es wird eingesehen werden, dass die I/O-Komponenten 850 viele andere Komponenten enthalten können, die nicht in 8 gezeigt sind. Die I/O-Komponenten 850 sind lediglich zum Vereinfachen der folgenden Diskussion nach Funktionalität gruppiert und die Gruppierung ist in keiner Weise beschränkend. Bei verschiedenen beispielhaften Ausführungsformen können die I/O-Komponenten 850 Ausgabekomponenten 852 und Eingabekomponenten 854 enthalten. Die Ausgabekomponenten 852 können visuelle Komponenten (z.B. eine Anzeige wie einen Plasmabildschirm (PDP), eine Leuchtdioden-(LED-)Anzeige, eine Flüssigkristallanzeige (LCD), einen Projektor oder eine Kathodenstrahlröhre (CRT)), akustische Komponenten (z.B. Lautsprecher), andere Signalgeneratoren und so weiter enthalten. Die Eingabekomponenten 854 können alphanumerische Eingabekomponenten (z.B. eine Tastatur, einen Berührungsbildschirm, der konfiguriert ist, um eine alphanumerische Eingabe zu empfangen, eine fotooptische Tastatur oder andere alphanumerische Eingabekomponenten), punktbasierte Eingabekomponenten (z.B. eine Maus, eine Rollkugel, ein Joystick, ein Bewegungssensor oder ein anderes Zeigeinstrument), taktile Eingabekomponenten (z.B. eine physikalische Taste, einen Berührungsbildschirm, der eine Stelle und eine Kraft von Berührungen oder Berührungsgesten zur Verfügung stellt, oder andere taktile Eingabekomponenten), Audio-Eingabekomponenten (z.B. ein Mikrofon) und ähnliches enthalten.
  • Kommunikation kann unter Verwendung einer weiten Vielzahl von Technologien implementiert werden. Die I/O-Komponenten 850 können Kommunikationskomponenten 864 enthalten, die betreibbar sind, um die Maschine 800 mit einem Netzwerk 880 oder Vorrichtungen bzw. Geräten 870 über eine Kopplung 882 bzw. eine Kopplung 872 zu koppeln. Zum Beispiel können die Kommunikationskomponenten 864 eine Netzwerkschnittstellenkomponente oder eine andere geeignete Vorrichtung enthalten, um eine Schnittstelle mit dem Netzwerk 880 zu bilden. Bei weiteren Beispielen können die Kommunikationskomponenten 864 kabelgebundene bzw. verdrahtete Kommunikationskomponenten, drahtlose Kommunikationskomponenten, zellulare Kommunikationskomponenten und andere Kommunikationskomponenten enthalten, um Kommunikation über andere Modalitäten zur Verfügung zu stellen. Die Vorrichtungen bzw. Geräte 870 können eine andere Maschine oder irgendeine einer Vielzahl von peripheren Vorrichtungen bzw. Peripheriegeräten (z.B. ein Peripheriegerät, das über einen universellen seriellen Bus (USB) gekoppelt ist) sein. Zum Beispiel kann, wie es oben angemerkt ist, die Maschine 800 irgendetwas von der Benutzervorrichtung 106, dem Zugriffsmanagementsystem 110, dem Computing-Service-Manager 112, der Ausführungsplattform 114, dem Zugriffsmanagementsystem 118, der Cloud-Schnittstelle 120 entsprechen.
  • Die verschiedenen Speicher (z.B. 830, 832, 834 und/oder Speicher des Prozessors (der Prozessoren) 810 und/oder die Speichereinheit 836) können einen oder mehrere Sätze von Anweisungen 816 und Datenstrukturen (z.B. Software) speichern, die irgendeine oder mehrere der hierin beschriebenen Methoden oder Funktionen verkörpert oder durch diese genutzt werden. Diese Anweisungen 816 veranlassen dann, wenn sie von dem (den) Prozessor(en) 810 ausgeführt werden, verschiedene Operationen, um die offenbarten Ausführungsformen zu implementieren.
  • Wie sie hierin verwendet sind, bedeuten die Ausdrücke „Maschinenspeichermedium“, „Vorrichtungsspeichermedium“ und „Computerspeichermedium“ dasselbe und können in dieser Offenbarung austauschbar verwendet sein. Die Ausdrücke beziehen sich auf eine einzelne oder mehrere Speichervorrichtungen und/oder Medien (z.B. eine zentrale oder verteilte Datenbank und/oder assoziierte Caches und Server), die ausführbare Anweisungen und/oder Daten speichern. Die Ausdrücke sollen demgemäß genommen werden, um Festkörperspeicher und optische und magnetische Medien, einschließlich eines Speichers intern oder extern von Prozessoren, zu enthalten, aber nicht um darauf beschränkt zu sein. Spezifische Beispiele für Maschinenspeichermedien, Computerspeichermedien und/oder Vorrichtungsspeichermedien enthalten einen nichtflüchtigen Speicher, einschließlich, anhand eines Beispiels, Halbleiterspeichervorrichtungen, wie z.B. eines löschbaren programmierbaren Nurlesespeichers (EPROM), eines elektrisch löschbaren programmierbaren Nurlesespeichers (EEPROM), von feldprogrammierbaren Gate-Arrays (FPGAs) und Flashspeichervorrichtungen; Magnetplatten wie beispielsweise interne Festplatten und entfernbare Scheiben bzw. Wechseldatenträger; magneto-optische Scheiben; und CD-ROM- und DVD-ROM-Scheiben. Die Ausdrücke „Maschinenspeichermedien“, „Computerspeichermedien“ und „Vorrichtungsspeichermedien“ schließen spezifisch Trägerwellen, modulierte Datensignale und andere solche Medien aus, von welchen wenigstens einige unter dem nachstehend diskutierten Ausdruck „Signalmedium“ abgedeckt sind.
  • Bei verschiedenen beispielhaften Ausführungsformen kann ein oder können mehrere Teilbereiche des Netzwerks 980 ein Ad-hoc-Netzwerk, ein Intranet, ein Extranet, ein virtuelles privates Netzwerk (VPN), ein lokales Netz (LAN), ein drahtloses LAN (WLAN), ein Weitverkehrsnetz (WAN), ein drahtloses WAN (WWAN), ein Stadtgebietsnetz (MAN), das Internet, ein Teilbereich des Internets, ein Teilbereich des öffentlichen geschalteten Telefonnetzes (PSTN), ein altes analoges Telefondienst-(POTS-)Netz, ein zellulares Telefonnetz, ein drahtloses Netz, ein Wi-Fi®-Netz, ein anderer Typ von Netzwerk oder eine Kombination von zwei oder mehreren solchen Netzwerken sein. Zum Beispiel kann das Netzwerk 880 oder ein Teilbereich des Netzwerks 880 ein drahtloses oder zellulares Netzwerk enthalten und die Kopplung 882 kann eine Verbindung mit einem Codemultiplexverfahren (CDMA), eine Verbindung mit globalem System für mobile Kommunikationen (GSM) oder andere Typen einer zellularen oder drahtlosen Kopplung sein. Bei diesem Beispiel kann die Kopplung 882 irgendeinen einer Vielfalt von Typen einer Datenübertragungstechnologie implementieren, wie beispielsweise eine Einzelträgerfunk-Übertragungstechnologie (1xRTT), eine Technologie mit optimierten Entwicklungsdaten (EVDO (Evolution Data Optimized)), eine Technologie eines allgemeinen Paketfunkdienstes (GPRS (General Packet Radio Service)), eine Technologie mit erhöhten Datenraten für GSM-Entwicklung (EDGE (Enhanced Data Rates for GSM Evolution)), Partnerschaftsprojekt der dritten Generation (3GPP) einschließlich 3G, drahtlose Netzwerke der vierten Generation (4G), universelle mobile Telekommunikationssysteme (UMTS), Hochgeschwindigkeits-Paketzugang (HSPA), weltweite Interoperabilität für Mikrowellenzugang (WiMAX), Langzeitentwicklungs-(LTE-)Standard, andere, die durch verschiedene Standardeinstellungsorganisationen definiert sind, andere Weitbereichs- bzw. Langstreckenprotokolle oder andere Datenübertragungstechnologie.
  • Die Anweisungen 816 können über das Netzwerk 880 unter Verwendung eines Übertragungsmedium über eine Netzwerkschnittstellenvorrichtung (z.B. eine in den Kommunikationskomponenten 864 enthaltene Netzwerkschnittstellenkomponente) übertragen bzw. gesendet oder empfangen werden und unter Nutzung von irgendeinem einer Anzahl von wohlbekannten Übertragungsprotokollen (z.B. Hypertext-Übertragungsprotokoll (HTTP)). Gleichermaßen können die Anweisungen 816 unter Verwendung eines Übertragungsmediums über die Kopplung 872 (z.B. Peer-zu-Peer-Kopplung) mit den Vorrichtungen bzw. Geräten 870 übertragen bzw. gesendet oder empfangen werden. Die Ausdrücke „Übertragungsmedium“ und „Signalmedium“ bedeuten dasselbe und können in dieser Offenbarung austauschbar verwendet sein. Die Ausdrücke „Übertragungsmedium“ und „Signalmedium“ sollen genommen werden, um irgendein immaterielles Medium zu enthalten, das die Anweisungen 816 zur Ausführung durch die Maschine 800 speichern, codieren oder tragen kann, und um digitale oder analoge Kommunikationssignale oder andere immaterielle Medien zu enthalten, um eine Kommunikation von solcher Software zu erleichtern bzw. zu ermöglichen. Somit sollen die Ausdrücke „Übertragungsmedium“ und „Signalmedium“ genommen werden, um irgendeine Form eines modulierten Datensignals, einer Trägerwelle und so weiter zu enthalten. Der Ausdruck „moduliertes Datensignal“ bedeutet ein Signal, das eine oder mehrere seiner Charakteristiken auf solche Weise eingestellt oder verändert hat, um Information im Signal zu codieren.
  • Die Ausdrücke „maschinenlesbares Medium“, „computerlesbares Medium“ und „vorrichtungslesbares Medium“ bedeuten dasselbe und können in dieser Offenbarung austauschbar verwendet sein. Die Ausdrücke sind definiert, um sowohl Maschinenspeichermedien als auch Übertragungsmedien zu enthalten. Somit enthalten die Ausdrücke sowohl Speichervorrichtungen/-medien als auch Trägerwellen/modulierte Datensignale.
  • Die verschiedenen Operationen der hierin beschriebenen beispielhaften Verfahren können wenigstens teilweise durch einen oder mehrere Prozessoren durchgeführt werden, die temporär (z.B. durch Software) oder dauerhaft konfiguriert sind, um die relevanten Operationen durchzuführen. Gleichermaßen können die hierin beschriebenen Verfahren wenigstens teilweise prozessorimplementiert sein. Zum Beispiel können wenigstens einige Operationen der Verfahren 500, 600 und 700 durch einen oder mehrere Prozessoren durchgeführt werden. Die Leistungsfähigkeit von bestimmten der Operationen kann auf den einen oder die mehreren Prozessoren verteilt werden, die sich nicht nur innerhalb einer einzelnen Maschine befinden, sondern auch quer über eine Anzahl von Maschinen genutzt werden. Bei einigen beispielhaften Ausführungsformen kann der Prozessor oder können die Prozessoren an einer einzigen Stelle angeordnet sein (z.B. in einer häuslichen Umgebung, einer Büroumgebung oder einer Serverfarm), während die Prozessoren bei anderen Ausführungsformen quer über eine Anzahl von Stellen bzw. Standorten verteilt sein können.
  • Obwohl die Ausführungsformen der vorliegenden Offenbarung unter Bezugnahme auf spezifische beispielhafte Ausführungsformen beschrieben worden sind, wird es offensichtlich werden, dass verschiedene Modifikationen und Änderungen an diesen Ausführungsformen vorgenommen werden können, ohne von dem breiteren Schutzumfang des erfinderischen Gegenstands abzuweichen. Demgemäß sind die Spezifikation und die Zeichnungen eher in einem illustrativen als in einem beschränkenden Sinn anzusehen. Die beigefügten Zeichnungen, die einen Teil hiervon bilden, zeigen, zur Veranschaulichung und nicht zur Beschränkung, spezifische Ausführungsformen, bei welchen der Gegenstand ausgeführt werden kann. Die dargestellten Ausführungsformen sind in ausreichendem Detail beschrieben, um Fachleuten auf dem Gebiet zu ermöglichen, die hierin offenbarten Lehren auszuführen. Andere Ausführungsformen können verwendet und daraus abgeleitet werden, so dass strukturelle und logische Substitutionen und Änderungen vorgenommen werden können, ohne vom Schutzbereich dieser Offenbarung abzuweichen. Diese detaillierte Beschreibung ist daher nicht in einem beschränkenden Sinn zu nehmen, und der Schutzumfang von verschiedenen Ausführungsformen wird nur durch die beigefügten Ansprüche definiert, zusammen mit dem gesamten Bereich von Äquivalenten, auf welche solche Ansprüche eine Anspruchsberechtigung haben.
  • Auf solche Ausführungsformen des erfinderischen Gegenstands kann hierin einzeln und/oder kollektiv lediglich der Annehmlichkeit halber und ohne die Absicht, den Schutzumfang dieser Anmeldung auf eine einzelne Erfindung oder ein erfinderisches Konzept gewollt zu beschränken, durch den Ausdruck „Erfindung“ Bezug genommen werden, wenn tatsächlich mehr als eine offenbart ist. Somit sollte, obwohl hierin spezifische Ausführungsformen dargestellt und beschrieben worden sind, eingesehen werden, dass irgendeine Anordnung, für die kalkuliert ist, dass sie den gleichen Zweck erreicht, für die gezeigten spezifischen Ausführungsformen substituiert werden kann. Diese Offenbarung soll irgendwelche und alle Anpassungen oder Variationen von verschiedenen Ausführungsformen abdecken. Kombinationen der obigen Ausführungsformen und andere Ausführungsformen, die hierin nicht spezifisch beschrieben sind, werden Fachleuten auf dem Gebiet beim Durchsehen bzw. Überprüfen der obigen Beschreibung offensichtlich werden.
  • In diesem Dokument werden die Ausdrücke „ein“ oder „eine“ verwendet, wie es in Patentdokumenten üblich ist, um einen (eine) oder mehr als einen (eine) zu enthalten, unabhängig von irgendwelchen anderen Fällen oder Verwendungen von „wenigstens einer“ oder „einer oder mehrere“. In diesem Dokument wird der Ausdruck „oder“ verwendet, um sich auf ein nicht ausschließliches oder zu beziehen, so dass „A oder B“ „A, aber nicht B“, „B, aber nicht A“ und „A und B“ enthält, solange nichts anderes angegeben ist. In den beigefügten Ansprüchen werden die Ausdrücke „einschließlich“ und „in welchen“ als Äquivalente in einfachem Englisch der jeweiligen Ausdrücke „umfassend“ und „wobei“ verwendet. Ebenso sind in den folgenden Ansprüchen die Ausdrücke „enthaltend“ und „umfassend“ mit offenem Ende; das bedeutet, dass ein System, eine Vorrichtung, ein Artikel oder ein Verfahren, das, die oder der Elemente zusätzlich zu denjenigen enthält, die nach einem solchen Ausdruck in einem Anspruch aufgelistet sind, derart angesehen wird, dass es, sie oder er in den Schutzbereich dieses Anspruchs fällt.
  • BEISPIELE
  • Beispiel 1 ist ein Verfahren, das folgendes umfasst: Empfangen, durch eine Datenbank-Konnektorschnittstelle, unter Verwendung von einem oder mehreren Prozessoren einer Maschine, einer Abfrage gegenüber einer verteilten Datenbank, wobei die Abfrage von einem externen Computercluster empfangen wird, das einen Masterknoten und eine Vielzahl von Workerknoten umfasst, wobei die verteilte Datenbank serialisierte Ergebnisdateien für die Abfrage erzeugt und die serialisierten Ergebnisdateien in einer Staging-Datenbank speichert; Übertragen, durch die Datenbank-Konnektorschnittstelle, eines Objektmetadatensatzes zum Masterknoten des externen Computerclusters, wobei der Objektmetadatensatz eine Vielzahl von Objektmetadatensatzelementen umfasst, wobei jedes der Vielzahl von Objektmetadatensatzelementen Zugriffs- bzw. Zugangsdaten von einer der serialisierten Ergebnisdateien in der Staging-Datenbank beschreibt; Empfangen, durch die Datenbank-Konnektorschnittstelle, von der Vielzahl von Workerknoten, von Anforderungen für die in der Staging-Datenbank gespeicherten serialisierten Ergebnisdateien, wobei jede der Anforderungen unter Verwendung von einem der Vielzahl von Objektmetadatensatzelemente erzeugt ist; und Übertragen, durch die Datenbank-Konnektorschnittstelle, der serialisierten Ergebnisdateien von der Staging-Datenbank zur Vielzahl von Workerknoten des externen Computerclusters, wobei die Vielzahl von Workerknoten die serialisierten Ergebnisdateien empfängt und eine weitere Verarbeitung an den serialisierten Ergebnisdateien durchführt.
  • Beispiel 2 ist der Gegenstand von 1, der weiterhin optional umfasst, dass jedes der Vielzahl von Objektmetadatensatzelementen Netzwerkadressendaten von einer der serialisierten Ergebnisdateien in der Staging-Datenbank umfasst.
  • Beispiel 3 ist der Gegenstand von einem der Beispiele 1 oder 2, der weiterhin optional umfasst, dass jedes der Vielzahl von Objektmetadatensatzelemente Berechtigungsnachweis- bzw. Anmeldeinformationsdaten umfasst, um auf die serialisierten Ergebnisdateien in der Staging-Datenbank zuzugreifen.
  • Beispiel 4 ist der Gegenstand von einem der Beispiele 1 bis 3, der weiterhin optional umfasst, dass die Vielzahl von Workerknoten die Vielzahl von Metadatensatzelementen vom Masterknoten empfängt und die Vielzahl von Workerknoten die Anforderungen für die serialisierten Ergebnisdateien unter Verwendung der Netzwerkadressdaten in der empfangenen Vielzahl von Metadatensatzelementen erzeugt.
  • Beispiel 5 ist der Gegenstand von einem der Beispiele 1 bis 4, der weiterhin optional ein Erzeugen, durch die verteilte Datenbank, von Abfrageergebnissen unter Verwendung der vom externen Computercluster empfangenen Abfrage umfasst.
  • Beispiel 6 ist der Gegenstand von einem der Beispiele 1 bis 5, der weiterhin optional ein Erzeugen der serialisierten Ergebnisdateien unter Verwendung der Abfrageergebnisse umfasst, wobei die serialisierten Ergebnisdateien unter Verwendung einer Serialisierungsschnittstelle der Datenbank-Konnektorschnittstelle erzeugt sind, wobei die unter Verwendung der Serialisierungsschnittstelle erzeugten serialisierten Ergebnisdateien über ein Netzwerk zur entfernten Verarbeitung verteilbar sind.
  • Beispiel 7 ist der Gegenstand von einem der Beispiele 1 bis 6, der weiterhin optional umfasst, dass die serialisierten Ergebnisdateien Zustandsdaten der Abfrageergebnisse unter Verwendung der Serialisierungsschnittstelle speichern.
  • Beispiel 8 ist der Gegenstand von einem der Beispiele 1 bis 7, der weiterhin optional umfasst, dass die Zustandsdaten ein Schema der für die Abfrage erzeugten Abfrageergebnisse umfassen.
  • Beispiel 9 ist der Gegenstand von einem der Beispiele 1 bis 8, der weiterhin optional umfasst, dass die durch die Vielzahl von Workerknoten durchgeführte weitere Verarbeitung eine Dekomprimieren der serialisierten Ergebnisdateien umfasst.
  • Beispiel 10 ist der Gegenstand von einem der Beispiele 1 bis 9, der weiterhin optional umfasst, dass die serialisierten Ergebnisdateien durch Deserialisieren der serialisierten Ergebnisdateien, die verwendet werden, um die Zustandsdaten wiederherzustellen, dekomprimiert werden.
  • Beispiel 11 ist der Gegenstand von einem der Beispiele 1 bis 10, der weiterhin optional umfasst, dass die durch die Vielzahl von Workerknoten durchgeführte weitere Verarbeitung von einer durch das externe Computercluster gehostete Cluster-Computing-Anwendung erzeugte Anweisungen umfasst.
  • Beispiel 12 ist der Gegenstand von einem der Beispiele 1 bis 11, der weiterhin optional umfasst, dass die verteilte Datenbank eine relationale Datenbank ist und die Datenbank-Konnektorschnittstelle ein Anwendungsprogrammierungsschnittstellen-(API (= Application Programming Interface)-Konnektor einer relationalen Datenbank ist.
  • Beispiel 13 ist ein System, das folgendes umfasst: einen oder mehrere Prozessoren einer Maschine; und einen Speicher, der Anweisungen speichert, die dann, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, veranlassen, dass die Maschine Operationen durchführt, die irgendeines der beispielhaften Verfahren 1 bis 12 implementieren.
  • Beispiel 14 ist eine maschinenlesbare Speichervorrichtung, die Anweisungen verkörpert bzw. enthält, die dann, wenn sie durch eine Maschine ausgeführt werden, veranlassen, dass die Maschine Operationen durchführt, die eines der Verfahren 1 bis 12 implementieren.
  • Ein weiteres Beispiel betrifft eine gemeinsam genutzte Datenbankplattform, die durch einen Konnektor über ein Netzwerk mit einer Cluster-Computing-Plattform eine Schnittstelle bilden kann, wobei die über das Netzwerk übertragenen Daten Metadaten-Ergebnispakete enthalten können, die zu Workerknoten der Cluster-Computing-Plattform verteilt werden können, die die Metadatenobjekte empfangen und auf die Ergebnisdaten zur weiteren Verarbeitung auf einer Staging-Plattform, wie beispielsweise einer skalierbaren Speicherplattform, zugreifen.
  • 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 Patentliteratur
    • US 16/719218 [0001]

Claims (30)

  1. Computerprogramm, das Anweisungen umfasst, die dann, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, veranlassen, dass der eine oder die mehreren Prozessoren Operationen durchführt oder durchführen, wobei die Operationen folgendes umfassen: Empfangen, durch eine Datenbank-Konnektorschnittstelle, unter Verwendung von einem oder mehreren Prozessoren einer Maschine, einer Abfrage gegenüber einer verteilten Datenbank, wobei die Abfrage von einem externen Computercluster empfangen wird, das einen Masterknoten und eine Vielzahl von Workerknoten umfasst, wobei die verteilte Datenbank serialisierte Ergebnisdateien für die Abfrage erzeugt und die serialisierten Ergebnisdateien in einer Staging-Datenbank speichert; Übertragen, durch die Datenbank-Konnektorschnittstelle, eines Objektmetadatensatzes zum Masterknoten des externen Computerclusters, wobei der Objektmetadatensatz eine Vielzahl von Objektmetadatensatzelementen umfasst, wobei jedes der Vielzahl von Objektmetadatensatzelementen Zugriffs- bzw. Zugangsdaten von einer der serialisierten Ergebnisdateien in der Staging-Datenbank beschreibt; Empfangen, durch die Datenbank-Konnektorschnittstelle, von der Vielzahl von Workerknoten, von Anforderungen für die in der Staging-Datenbank gespeicherten serialisierten Ergebnisdateien, wobei jede der Anforderungen unter Verwendung von einem der Vielzahl von Objektmetadatensatzelemente erzeugt ist; und Übertragen, durch die Datenbank-Konnektorschnittstelle, der serialisierten Ergebnisdateien von der Staging-Datenbank zur Vielzahl von Workerknoten des externen Computerclusters.
  2. Computerprogramm nach Anspruch 1, wobei die Anzahl von Workerknoten eine weitere Verarbeitung an den empfangenen serialisierten Ergebnisdateien durchführt.
  3. Computerprogramm nach Anspruch 1, wobei jedes der Vielzahl von Objektmetadatensatzelementen Netzwerkadressendaten von einer der serialisierten Ergebnisdateien in der Staging-Datenbank umfasst.
  4. Computerprogramm nach Anspruch 1, wobei jedes der Vielzahl von Objektmetadatensatzelementen Berechtigungsnachweis- bzw. Anmeldeinformationsdaten umfasst, um auf die serialisierten Ergebnisdateien in der Staging-Datenbank zuzugreifen.
  5. Computerprogramm nach Anspruch 2, wobei die Vielzahl von Workerknoten die Vielzahl von Metadatensatzelementen vom Masterknoten empfängt und die Vielzahl von Workerknoten die Anforderungen für die serialisierten Ergebnisdateien unter Verwendung der Netzwerkadressendaten in der empfangenen Vielzahl von Metadatensatzelementen erzeugt.
  6. Computerprogramm nach Anspruch 2, wobei die Datenbank-Konnektorschnittstelle in der verteilten Datenbank integriert ist und wobei das Verfahren weiterhin folgendes umfasst: Erzeugen, durch die verteilte Datenbank, von Abfrageergebnissen unter Verwendung der vom externen Computercluster empfangenen Abfrage.
  7. Computerprogramm nach Anspruch 5, wobei die Operationen weiterhin folgende umfassen: Erzeugen der serialisierten Ergebnisdateien unter Verwendung der Abfrageergebnisse, wobei die serialisierten Ergebnisdateien unter Verwendung einer Serialisierungsschnittstelle der Datenbank-Konnektorschnittstelle erzeugt werden, wobei die unter Verwendung der Serialisierungsschnittstelle erzeugten serialisierten Ergebnisdateien über ein Netzwerk zur entfernten Verarbeitung verteilbar sind.
  8. Computerprogramm nach Anspruch 6, wobei die serialisierten Ergebnisdateien Zustandsdaten der Abfrageergebnisse unter Verwendung der Serialisierungsschnittstelle speichern.
  9. Computerprogramm nach Anspruch 7, wobei die Zustandsdaten ein Schema der für die Abfrage erzeugten Abfrageergebnisse umfassen.
  10. Computerprogramm nach Anspruch 8, wobei die durch die Vielzahl von Workerknoten durchgeführte weitere Verarbeitung ein Dekomprimieren der serialisierten Ergebnisdateien umfasst.
  11. Computerprogramm nach Anspruch 9, wobei die serialisierten Ergebnisdateien durch Deserialisieren der serialisierten Ergebnisdateien dekomprimiert werden, die verwendet werden, um die Zustandsdaten wiederherzustellen.
  12. Computerprogramm nach Anspruch 2, wobei die durch die Vielzahl von Workerknoten durchgeführte weitere Verarbeitung Anwendungsoperationen umfasst, die aus einer durch den externen Computercluster gehosteten Cluster-Computing-Anwendung erzeugt sind.
  13. System, das folgendes umfasst: einen oder mehrere Prozessoren einer Maschine; und einen Speicher, der Anweisungen speichert, die dann, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, veranlassen, dass die Maschine Operationen durchführt, die folgendes umfassen: Empfangen, durch eine Datenbank-Konnektorschnittstelle, einer Abfrage gegenüber einer verteilten Datenbank, wobei die Abfrage von einem externen Computercluster empfangen wird, das einen Masterknoten und eine Vielzahl von Workerknoten umfasst, wobei die verteilte Datenbank serialisierte Ergebnisdateien für die Abfrage erzeugt und die serialisierten Ergebnisdateien in einer Staging-Datenbank speichert; Übertragen, durch die Datenbank-Konnektorschnittstelle, eines Objektmetadatensatzes zum Masterknoten des externen Computerclusters, wobei der Objektmetadatensatz eine Vielzahl von Objektmetadatensatzelementen umfasst, wobei jedes der Vielzahl von Objektmetadatensatzelementen Zugriffs- bzw. Zugangsdaten von einer der serialisierten Ergebnisdateien in der Staging-Datenbank beschreibt; Empfangen, durch die Datenbank-Konnektorschnittstelle, von der Vielzahl von Workerknoten, von Anforderungen für die in der Staging-Datenbank gespeicherten serialisierten Ergebnisdateien, wobei jede der Anforderungen unter Verwendung von einem der Vielzahl von Objektmetadatensatzelemente erzeugt ist; und Übertragen, durch die Datenbank-Konnektorschnittstelle, der serialisierten Ergebnisdateien von der Staging-Datenbank zur Vielzahl von Workerknoten des externen Computerclusters.
  14. System nach Anspruch 13, wobei die Anzahl von Workerknoten eine weitere Verarbeitung an den empfangenen serialisierten Ergebnisdateien durchführt.
  15. System nach Anspruch 13, wobei jedes der Vielzahl von Objektmetadatensatzelementen Netzwerkadressendaten von einer der serialisierten Ergebnisdateien in der Staging-Datenbank umfasst.
  16. System nach Anspruch 13, wobei jedes der Vielzahl von Objektmetadatensatzelementen Berechtigungsnachweis- bzw. Anmeldeinformationsdaten umfasst, um auf die serialisierten Ergebnisdateien in der Staging-Datenbank zuzugreifen.
  17. System nach Anspruch 14, wobei die Vielzahl von Workerknoten die Vielzahl von Metadatensatzelementen vom Masterknoten empfängt und die Vielzahl von Workerknoten die Anforderungen für die serialisierten Ergebnisdateien unter Verwendung der Netzwerkadressendaten in der empfangenen Vielzahl von Metadatensatzelementen erzeugt.
  18. System nach Anspruch 14, wobei die Operationen weiterhin folgendes umfassen: Erzeugen, durch die verteilte Datenbank, von Abfrageergebnissen unter Verwendung der vom externen Computercluster empfangenen Abfrage.
  19. System nach Anspruch 17, das weiterhin folgendes umfassend: Erzeugen der serialisierten Ergebnisdateien unter Verwendung der Abfrageergebnisse, wobei die serialisierten Ergebnisdateien unter Verwendung einer Serialisierungsschnittstelle der Datenbank-Konnektorschnittstelle erzeugt werden, wobei die unter Verwendung der Serialisierungsschnittstelle erzeugten serialisierten Ergebnisdateien über ein Netzwerk zur entfernten Verarbeitung verteilbar sind.
  20. System nach Anspruch 19, wobei die serialisierten Ergebnisdateien Zustandsdaten der Abfrageergebnisse unter Verwendung der Serialisierungsschnittstelle speichern.
  21. System nach Anspruch 18, wobei die Zustandsdaten ein Schema der für die Abfrage erzeugten Abfrageergebnisse umfassen.
  22. System nach Anspruch 21, wobei die durch die Vielzahl von Workerknoten durchgeführte weitere Verarbeitung ein Dekomprimieren der serialisierten Ergebnisdateien umfasst.
  23. System nach Anspruch 22, wobei die serialisierten Ergebnisdateien durch Deserialisieren der serialisierten Ergebnisdateien dekomprimiert werden, die verwendet werden, um die Zustandsdaten wiederherzustellen.
  24. System nach Anspruch 14, wobei die durch die Vielzahl von Workerknoten durchgeführte weitere Verarbeitung Anweisungen umfasst, die aus einer durch den externen Computercluster gehosteten Cluster-Computing-Anwendung erzeugt sind.
  25. Maschinenlesbare Speichervorrichtung, die Anweisungen verkörpert bzw. enthält, die dann, wenn sie durch eine Maschine ausgeführt werden, veranlassen, dass die Maschine Operationen durchführt, die folgendes umfassen: Empfangen, durch eine Datenbank-Konnektorschnittstelle, einer Abfrage gegenüber einer verteilten Datenbank, wobei die Abfrage von einem externen Computercluster empfangen wird, das einen Masterknoten und eine Vielzahl von Workerknoten umfasst, wobei die verteilte Datenbank serialisierte Ergebnisdateien für die Abfrage erzeugt und die serialisierten Ergebnisdateien in einer Staging-Datenbank speichert; Übertragen, durch die Datenbank-Konnektorschnittstelle, eines Objektmetadatensatzes zum Masterknoten des externen Computerclusters, wobei der Objektmetadatensatz eine Vielzahl von Objektmetadatensatzelementen umfasst, wobei jedes der Vielzahl von Objektmetadatensatzelementen Zugriffs- bzw. Zugangsdaten von einer der serialisierten Ergebnisdateien in der Staging-Datenbank beschreibt; Empfangen, durch die Datenbank-Konnektorschnittstelle, von der Vielzahl von Workerknoten, von Anforderungen für die in der Staging-Datenbank gespeicherten serialisierten Ergebnisdateien, wobei jede der Anforderungen unter Verwendung von einem der Vielzahl von Objektmetadatensatzelemente erzeugt ist; und Übertragen, durch die Datenbank-Konnektorschnittstelle, der serialisierten Ergebnisdateien von der Staging-Datenbank zur Vielzahl von Workerknoten des externen Computerclusters.
  26. Maschinenlesbare Speichervorrichtung nach Anspruch 25, wobei jedes der Vielzahl von Objektmetadatensatzelementen Netzwerkadressendaten von einer der serialisierten Ergebnisdateien in der Staging-Datenbank umfasst.
  27. Maschinenlesbare Speichervorrichtung nach Anspruch 25, wobei jedes der Vielzahl von Objektmetadatensatzelemente Berechtigungsnachweis- bzw. Anmeldeinformationsdaten umfasst, um auf die serialisierten Ergebnisdateien in der Staging-Datenbank zuzugreifen.
  28. Maschinenlesbare Speichervorrichtung nach Anspruch 26, wobei die Vielzahl von Workerknoten die Vielzahl von Metadatensatzelementen vom Masterknoten empfängt und die Vielzahl von Workerknoten die Anforderungen für die serialisierten Ergebnisdateien unter Verwendung der Netzwerkadressendaten in der empfangenen Vielzahl von Metadatensatzelementen erzeugt.
  29. Maschinenlesbare Speichervorrichtung nach Anspruch 25, wobei die Operationen weiterhin folgendes umfassen: Erzeugen, durch die verteilte Datenbank, von Abfrageergebnissen unter Verwendung der vom externen Computercluster empfangenen Abfrage; und Erzeugen der serialisierten Ergebnisdateien unter Verwendung der Abfrageergebnisse, wobei die serialisierten Ergebnisdateien unter Verwendung einer Serialisierungsschnittstelle der Datenbank-Konnektorschnittstelle erzeugt werden, wobei die unter Verwendung der Serialisierungsschnittstelle erzeugten serialisierten Ergebnisdateien über ein Netzwerk zur entfernten Verarbeitung verteilbar sind.
  30. Maschinenlesbare Speichervorrichtung nach Anspruch 25, wobei die Vielzahl von Workerknoten eine weitere Verarbeitung an den empfangenen serialisierten Ergebnisdateien durchführt, wobei die weitere Verarbeitung Anweisungen umfasst, die aus einer durch den externen Computercluster gehosteten Cluster-Computing-Anwendung erzeugt sind.
DE202020005703.7U 2019-12-18 2020-12-08 Auf verteilten Metadaten basierendes Cluster-Computing Active DE202020005703U1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/719,218 US10719517B1 (en) 2019-12-18 2019-12-18 Distributed metadata-based cluster computing
US16/719,218 2019-12-18

Publications (1)

Publication Number Publication Date
DE202020005703U1 true DE202020005703U1 (de) 2022-02-09

Family

ID=71611973

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202020005703.7U Active DE202020005703U1 (de) 2019-12-18 2020-12-08 Auf verteilten Metadaten basierendes Cluster-Computing

Country Status (6)

Country Link
US (3) US10719517B1 (de)
EP (1) EP3938926A4 (de)
KR (2) KR102377084B1 (de)
CN (1) CN113508373A (de)
DE (1) DE202020005703U1 (de)
WO (1) WO2021126599A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11790008B2 (en) * 2019-09-12 2023-10-17 Business Objects Software Ltd. Persisted queries and batch streaming
US20210089553A1 (en) * 2019-09-19 2021-03-25 Okera, Inc. Data retrieval using distributed workers in a large-scale data access system
US10719517B1 (en) 2019-12-18 2020-07-21 Snowflake Inc. Distributed metadata-based cluster computing
US11057491B1 (en) 2020-07-17 2021-07-06 Snowflake Inc. Remote execution using a global identity
US11258846B1 (en) * 2021-05-26 2022-02-22 Capital One Services, Llc Real-time serverless streaming in a multi-cloud environment
US11916998B2 (en) 2021-11-12 2024-02-27 Electronics And Telecommunications Research Institute Multi-cloud edge system
CN116521744B (zh) * 2023-06-30 2023-09-12 杭州拓数派科技发展有限公司 全双工元数据传输方法、装置、系统和计算机设备

Family Cites Families (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7007024B2 (en) * 2002-03-29 2006-02-28 Panasas, Inc. Hashing objects into multiple directories for better concurrency and manageability
US7873684B2 (en) * 2003-08-14 2011-01-18 Oracle International Corporation Automatic and dynamic provisioning of databases
WO2005043323A2 (en) * 2003-10-27 2005-05-12 Archivas, Inc. Policy-based management of a redundant array of independent nodes
US20050289175A1 (en) * 2004-06-23 2005-12-29 Oracle International Corporation Providing XML node identity based operations in a value based SQL system
US7657581B2 (en) * 2004-07-29 2010-02-02 Archivas, Inc. Metadata management for fixed content distributed data storage
US7680855B2 (en) * 2005-03-11 2010-03-16 Yahoo! Inc. System and method for managing listings
US20070239661A1 (en) * 2006-03-28 2007-10-11 Sun Microsystems, Inc. Systems and methods for a distributed in-memory database and distributed cache
WO2008017044A1 (en) * 2006-08-02 2008-02-07 Watt Systems Technologies, Inc. Object oriented system and method of graphically displaying and analyzing complex systems
US7917469B2 (en) * 2006-11-08 2011-03-29 Hitachi Data Systems Corporation Fast primary cluster recovery
US20090012965A1 (en) * 2007-07-01 2009-01-08 Decisionmark Corp. Network Content Objection Handling System and Method
US20090112796A1 (en) * 2007-10-24 2009-04-30 Marvin Elder Natural language conceptual joins
US8484259B1 (en) * 2009-12-08 2013-07-09 Netapp, Inc. Metadata subsystem for a distributed object store in a network storage system
US9245058B2 (en) * 2010-12-03 2016-01-26 Titus Inc. Method and system of hierarchical metadata management and application
US9396242B2 (en) * 2011-04-11 2016-07-19 Salesforce.Com, Inc. Multi-master data replication in a distributed multi-tenant system
US20130067024A1 (en) * 2011-09-12 2013-03-14 Microsoft Corporation Distributing multi-source push notifications to multiple targets
US9753999B2 (en) * 2012-01-06 2017-09-05 Citus Data Bilgi Islemieri Ticaret A.S. Distributed database with mappings between append-only files and repartitioned files
US8815752B2 (en) 2012-11-28 2014-08-26 Micron Technology, Inc. Methods of forming features in semiconductor device structures
WO2014074957A1 (en) * 2012-11-08 2014-05-15 Sparkledb As Systems and methods involving resource description framework distributed data base managenent systems and/or related aspects
US9588822B1 (en) * 2012-12-18 2017-03-07 Amazon Technologies, Inc. Scheduler for data pipeline
US9116970B2 (en) * 2013-03-14 2015-08-25 Pivotal Software, Inc. In-database connectivity components analysis of data
US20140304525A1 (en) * 2013-04-01 2014-10-09 Nexenta Systems, Inc. Key/value storage device and method
US10303702B2 (en) * 2014-02-07 2019-05-28 Ignite Scalarc Solutions, Inc. System and method for analysis and management of data distribution in a distributed database environment
US9792129B2 (en) * 2014-02-28 2017-10-17 Tyco Fire & Security Gmbh Network range extender with multi-RF radio support for plurality of network interfaces
CN104391913B (zh) * 2014-11-18 2018-02-16 北京锐安科技有限公司 一种数据库管理方法及装置
US10437797B1 (en) * 2014-12-12 2019-10-08 Amazon Technologies, Inc. In-memory distributed database with a remote data store
US10545915B2 (en) * 2015-02-02 2020-01-28 Quantum Corporation Recursive multi-threaded file system scanner for serializing file system metadata exoskeleton
US10318491B1 (en) * 2015-03-31 2019-06-11 EMC IP Holding Company LLC Object metadata query with distributed processing systems
CN105468720A (zh) * 2015-11-20 2016-04-06 北京锐安科技有限公司 集成分布式数据处理系统的方法、相应系统及其数据处理方法
US10572510B2 (en) * 2015-12-21 2020-02-25 Sap Se Distributed database transaction protocol
EP3449363A4 (de) * 2016-04-28 2019-10-02 Snowflake Inc. Multicluster-warehouse
US9753744B1 (en) * 2016-05-27 2017-09-05 Intuit Inc. Defining application programming interfaces (APIS) using object schemas
US10628424B2 (en) * 2016-09-15 2020-04-21 Oracle International Corporation Graph generation for a distributed event processing system
US11604795B2 (en) * 2016-09-26 2023-03-14 Splunk Inc. Distributing partial results from an external data system between worker nodes
US10956415B2 (en) * 2016-09-26 2021-03-23 Splunk Inc. Generating a subquery for an external data system using a configuration file
US11243963B2 (en) * 2016-09-26 2022-02-08 Splunk Inc. Distributing partial results to worker nodes from an external data system
KR20180044696A (ko) * 2016-10-24 2018-05-03 삼성에스디에스 주식회사 쿼리 결과 분산 저장 방법 및 그 시스템
CN106570145B (zh) * 2016-10-28 2020-07-10 中国科学院软件研究所 一种基于分层映射的分布式数据库结果缓存方法
CN108228654A (zh) * 2016-12-21 2018-06-29 青岛祥智电子技术有限公司 一种大数据分布式存储方法和系统
US10237346B2 (en) * 2017-02-08 2019-03-19 Vmware, Inc. Maintaining partition-tolerant distributed metadata
US10552269B2 (en) * 2017-08-31 2020-02-04 International Business Machines Corporation Backup optimization in hybrid storage environment
US10719484B2 (en) * 2017-09-07 2020-07-21 Cohesity, Inc. Remotely mounted file system with stubs
US9967238B1 (en) * 2017-11-09 2018-05-08 Broadridge Financial Solutions, Inc. Database-centered computer network systems and computer-implemented methods for cryptographically-secured distributed data management
US10936585B1 (en) * 2018-10-31 2021-03-02 Splunk Inc. Unified data processing across streaming and indexed data sets
US10719517B1 (en) 2019-12-18 2020-07-21 Snowflake Inc. Distributed metadata-based cluster computing

Also Published As

Publication number Publication date
US11494386B2 (en) 2022-11-08
CN113508373A (zh) 2021-10-15
US11250005B2 (en) 2022-02-15
EP3938926A4 (de) 2022-11-30
KR20220039836A (ko) 2022-03-29
KR102377084B1 (ko) 2022-03-22
US20210191945A1 (en) 2021-06-24
EP3938926A1 (de) 2022-01-19
US20220129467A1 (en) 2022-04-28
US10719517B1 (en) 2020-07-21
KR20210141531A (ko) 2021-11-23
WO2021126599A1 (en) 2021-06-24

Similar Documents

Publication Publication Date Title
DE202020005703U1 (de) Auf verteilten Metadaten basierendes Cluster-Computing
DE202020005715U1 (de) Dynamische Maskierung geteilter Datenobjekte
DE202020005700U1 (de) Aufrufen externer Funktionen aus einem Datenlager
US10581957B2 (en) Multi-level data staging for low latency data access
DE202020005734U1 (de) Beschneiden von Indizes zur Verbesserung einer Verarbeitung von Datenbankabfragen
DE202021004036U1 (de) Data Clean Room
DE202020005693U1 (de) Externe berechtigungsnachweisfreie Stufen für Datenbankintegrationen
DE202015009859U1 (de) Ressourcenmanagementsysteme
DE202011110890U1 (de) System für die Bereitstellung eines Datenspeicherungs- und Datenverarbeitungsservices
DE202012013432U1 (de) Speichern von Daten auf Speicherknoten
DE202023101653U1 (de) Organisations- und cloudübergreifende automatisierte Datenpipelines
CN113474764A (zh) 共享数据库对象上的流
DE112018004247T5 (de) Datenverarbeitungsauslagerung unter verwendung einer speicherinternen codeausführung
CN116069811B (zh) 使用用户定义的函数扩展数据库外部函数
EP3848815B1 (de) Effizientes geteiltes massenladen in optimierten speicher
DE202021004295U1 (de) Gleichzeitige Transaktionsverarbeitung in einem Datenbanksystem
DE202021004340U1 (de) Beschränkte Sichten zum Steuern des Zugriffs auf Informationen in einem Datenbanksystem
US11232000B1 (en) Moving database partitions from replica nodes
US20230237043A1 (en) Accelerating change data capture determination using row bitsets
DE202021004327U1 (de) Autoskalierung externer Funktionsanforderungen
DE202023102700U1 (de) Datenaufnahmereplizierung und Notfallwiederherstellung
EP2765517B1 (de) Datenstromspaltung für Datenzugriff mit niedriger Latenzzeit
DE202021102315U1 (de) Flexibles Computing
US20230367757A1 (en) Streams using persistent tables
DE202023103214U1 (de) Web-Anwendung als Datenbankobjekt erster Klasse

Legal Events

Date Code Title Description
R207 Utility model specification
R150 Utility model maintained after payment of first maintenance fee after three years