Daten abfragen

Das Abfragen von Daten ist der grundlegende Schritt zum Ausführen nahezu aller datengesteuerten Aufgaben in Azure Databricks. Unabhängig von der verwendeten Sprache oder dem verwendeten Tool definieren Workloads zunächst eine Abfrage für eine Tabelle oder eine andere Datenquelle und führen dann Aktionen aus, um Erkenntnisse aus den Daten zu gewinnen. In diesem Artikel werden die Kernkonzepte und Verfahren für die Ausführung von Abfragen in verschiedenen Azure Databricks-Produktangeboten beschrieben und Codebeispiele aufgeführt, die Sie für Ihren Anwendungsfall anpassen können.

Sie können Daten interaktiv mithilfe folgender Komponenten abfragen:

• Notebooks
• SQL-Editor
• Datei-Editor
• Dashboards

Sie können Abfragen auch als Teil von Delta Live Tables-Pipelines oder Aufträgen ausführen.

Eine Übersicht über Streamingabfragen für Azure Databricks finden Sie unter Abfragen von Streamingdaten.

Welche Daten können Sie mit Azure Databricks abfragen?

Azure Databricks unterstützt das Abfragen von Daten in mehreren Formaten und Unternehmenssystemen. Die Daten, die Sie mithilfe von Azure Databricks abfragen, fallen in eine von zwei allgemeinen Kategorien: Daten in einem Databricks Lakehouse und externe Daten.

Welche Daten befinden sich in einem Databricks Lakehouse?

Databricks Data Intelligence Platform speichert standardmäßig alle Ihre Daten in einem Databricks Lakehouse.

Das bedeutet, dass Sie beim Ausführen einer einfachen CREATE TABLE-Anweisung zum Erstellen einer neuen Tabelle eine Lakehouse-Tabelle erstellt haben. Lakehouse-Daten weisen die folgenden Eigenschaften auf:

• Sie werden im Delta Lake-Format gespeichert.
• Sie werden im Cloudobjektspeicher gespeichert.
• Sie werden über Unity Catalog gesteuert.

Die meisten Lakehouse-Daten in Azure Databricks werden in Unity Catalog als verwaltete Tabellen registriert. Verwaltete Tabellen stellen die einfachste Syntax bereit und verhalten sich wie andere Tabellen in den meisten Managementsystemen für relationale Datenbanken. Verwaltete Tabellen werden für die meisten Anwendungsfälle empfohlen und eignen sich für alle Benutzer*innen, die sich keine Gedanken über die Implementierungsdetails der Datenspeicherung machen möchten.

Eine nicht verwalteten Tabelle oder externe Tabelle ist eine Tabelle, die mit einem angegebenen LOCATION-Element registriert ist. Der Begriff extern kann irreführend sein, da externe Delta-Tabellen dennoch Lakehouse-Daten sind. Nicht verwaltete Tabellen werden möglicherweise von Benutzer*innen bevorzugt, die direkt von anderen Delta-Reader-Clients auf Tabellen zugreifen. Eine Übersicht über Unterschiede in der Tabellensemantik finden Sie unter Was sind Tabellen und Ansichten?.

Einige Legacyworkloads interagieren möglicherweise ausschließlich mit Delta Lake-Daten über Dateipfade und registrieren überhaupt keine Tabellen. Diese Daten sind immer noch Lakehouse-Daten, können aber schwieriger zu erkennen sein, da sie nicht in Unity Catalog registriert sind.

Welche Daten werden als extern betrachtet?

Alle Daten, die nicht in einem Databricks Lakehouse enthalten sind, können als externe Daten betrachtet werden. Einige Beispiele für externe Daten:

• Fremdtabellen, die bei Lakehouse Federation registriert sind
• Tabellen im Hive-Metastore, der von Parquet unterstützt wird
• Externe Tabellen in Unity Catalog, die von JSON unterstützt werden
• Im Cloudobjektspeicher gespeicherte CSV-Daten
• Aus Kafka gelesene Streamingdaten

Azure Databricks unterstützt das Konfigurieren von Verbindungen mit vielen Datenquellen. Weitere Informationen finden Sie unter Herstellen von Verbindungen mit Datenquellen.

Sie können Unity Catalog verwenden, um den Zugriff auf und die Definition von Tabellen anhand von Daten zu steuern, die in mehreren Formaten und externen Systemen gespeichert sind. Delta Lake ist jedoch eine Voraussetzung dafür, dass Daten im Lakehouse berücksichtigt werden.

Delta Lake bietet alle Transaktionsgarantien in Azure Databricks, die für die Aufrechterhaltung der Datenintegrität und Konsistenz von entscheidender Bedeutung sind. Wenn Sie mehr über Transaktionsgarantien für Azure Databricks-Daten und ihre Bedeutung erfahren möchten, lesen Sie Was sind ACID-Garantien in Azure Databricks?.

Die meisten Azure Databricks-Benutzer*innen fragen eine Kombination aus Lakehouse-Daten und externen Daten ab. Die Verbindung mit externen Daten ist immer der erste Schritt für Datenerfassung und ETL-Pipelines, die Daten in das Lakehouse zu übertragen. Informationen zum Erfassen von Daten finden Sie unter Erfassen von Daten in einem Databricks-Lakehouse.

Abfragen von Tabellen nach Name

Für alle Daten, die als Tabelle registriert sind, empfiehlt Databricks die Abfrage mithilfe des Tabellennamens.

Wenn Sie Unity Catalog nutzen, verwenden Tabellen einen dreistufigen Namespace mit dem folgenden Format: <catalog-name>.<schema-name>.<table-name>.

Ohne Unity Catalog verwenden Tabellenbezeichner das Format <schema-name>.<table-name>.

Die Abfrage nach Tabellenname wird in allen Azure Databricks-Ausführungskontexten und unterstützten Sprachen unterstützt.

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

spark.read.table("catalog_name.schema_name.table_name")

Abfragen von Daten nach Pfad

Sie können strukturierte, teilweise strukturierte und unstrukturierte Daten mithilfe von Dateipfaden abfragen. Die meisten Dateien in Azure Databricks werden vom Cloudobjektspeicher unterstützt. Siehe auch unter Arbeiten mit Dateien in Azure Databricks.

Databricks empfiehlt, den gesamten Zugriff auf Cloudobjektspeicher mithilfe von Unity Catalog zu konfigurieren und Volumes für Objektspeicherorte zu definieren, die direkt abgefragt werden. Volumes bieten mithilfe von Katalog- und Schemanamen für den Dateipfad lesbare Aliase für Speicherorte und Dateien im Cloudobjektspeicher. Siehe Verbinden mit Cloudobjektspeicher und -diensten mithilfe des Unity-Katalogs.

Die folgenden Beispiele veranschaulichen die Verwendung von Unity Catalog-Volumepfaden zum Lesen von JSON-Daten:

SQL

SELECT * FROM json.`/Volumes/catalog_name/schema_name/volume_name/path/to/data`

Python

spark.read.format("json").load("/Volumes/catalog_name/schema_name/volume_name/path/to/data")

Für Cloudspeicherorte, die nicht als Unity Catalog-Volumes konfiguriert sind, können Sie Daten direkt mithilfe von URIs abfragen. Sie müssen den Zugriff auf den Cloudobjektspeicher konfigurieren, um Daten mit URIs abzufragen. Weitere Informationen finden Sie unter Konfigurieren des Zugriffs auf Cloudobjektspeicher für Azure Databricks.

Die folgenden Beispiele veranschaulichen die Verwendung von URIs zum Abfragen von JSON-Daten in Azure Data Lake Storage Gen2, GCS und S3:

SQL

SELECT * FROM json.`abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data`;

SELECT * FROM json.`gs://bucket_name/path/to/data`;

SELECT * FROM json.`s3://bucket_name/path/to/data`;

Python

spark.read.format("json").load("abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data")

spark.read.format("json").load("gs://bucket_name/path/to/data")

spark.read.format("json").load("s3://bucket_name/path/to/data")

Abfragen von Daten mithilfe von SQL-Warehouses

Azure Databricks verwendet SQL-Warehouses für Compute in den folgenden Schnittstellen:

• SQL-Editor
• Databricks-SQL-Abfragen
• Dashboards
• Legacy-Dashboards
• SQL-Warnungen

Sie können optional SQL-Warehouses mit den folgenden Produkten verwenden:

• Databricks-Notebooks
• Databricks-Datei-Editor
• Databricks-Aufträge

Wenn Sie Daten mit SQL-Warehouses abfragen, können Sie nur SQL-Syntax verwenden. Andere Programmiersprachen und APIs werden nicht unterstützt.

Bei Arbeitsbereichen, die für Unity Catalog aktiviert sind, verwenden SQL-Warehouses immer Unity Catalog, um den Zugriff auf Datenquellen zu verwalten.

Die meisten Abfragen, die in SQL-Warehouses ausgeführt werden, haben Tabellen zum Ziel. Abfragen für Datendateien sollten Unity Catalog-Volumes nutzen, um den Zugriff auf Speicherorte zu verwalten.

Die direkte Verwendung von URIs in Abfragen, die in SQL-Warehouses ausgeführt werden, kann zu unerwarteten Fehlern führen.

Abfragen von Daten mithilfe von „All Purpose Compute“ und „Jobs Compute“

Die meisten Abfragen, die Sie über Databricks-Notebooks, -Workflows und den Databricks-Datei-Editor ausführen, werden für Computecluster ausgeführt, die mit Databricks Runtime konfiguriert sind. Sie können diese Cluster so konfigurieren, dass sie interaktiv ausgeführt werden, oder sie als Jobs Compute-Workloads bereitstellen, die Workflows unterstützen. Databricks empfiehlt, immer Jobs Compute-Workloads für nicht interaktive Workloads zu verwenden.

Interaktive und nicht interaktive Workloads

Viele Benutzer*innen finden es hilfreich, Abfrageergebnisse anzuzeigen, während Transformationen während der Entwicklung verarbeitet werden. Durch das Verschieben einer interaktiven Workload von „All Purpose Compute“ in „Jobs Compute“ können Sie Zeit und Verarbeitungskosten sparen, indem Sie Abfragen entfernen, die Ergebnisse anzeigen.

Apache Spark verwendet verzögerte Codeausführung. Das bedeutet, dass Ergebnisse nur nach Bedarf berechnet werden, und mehrere Transformationen oder Abfragen für eine Datenquelle können als einzelne Abfrage optimiert werden, wenn Sie keine Ergebnisse erzwingen. Dies unterscheidet sich vom beschleunigten Ausführungsmodus, der in Pandas verwendet wird und erfordert, dass Berechnungen in der entsprechenden Reihenfolge verarbeitet werden, bevor Ergebnisse an die nächste Methode übergeben werden.

Wenn Ihr Ziel darin besteht, bereinigte, transformierte, aggregierte Daten als neues Dataset zu speichern, sollten Sie Abfragen, die Ergebnisse anzeigen, aus Ihrem Code entfernen, bevor sie seine Ausführung planen.

Bei kurzen Vorgängen und kleinen Datasets ist die Zeit- und Kostenersparnis möglicherweise marginal. Bei umfangreichen Vorgängen kann jedoch viel Zeit beim Berechnen und Ausgeben von Ergebnissen in einem Notebook verloren werden, das möglicherweise nicht manuell überprüft wird. Die gleichen Ergebnisse könnten wahrscheinlich nach der Speicherung fast ohne Kosten aus der gespeicherten Ausgabe abgefragt werden.