Dotaz na data
Dotazování na data je základním krokem pro provádění téměř všech úloh řízených daty v Azure Databricks. Bez ohledu na použitý jazyk nebo nástroj začínají úlohy definováním dotazu na tabulku nebo jiný zdroj dat a následným prováděním akcí pro získání přehledů z dat. Tento článek popisuje základní koncepty a postupy pro spouštění dotazů napříč různými nabídkami produktů Azure Databricks a obsahuje příklady kódu, které můžete přizpůsobit pro váš případ použití.
Data můžete interaktivně dotazovat pomocí:
- Poznámkové bloky
- SQL editor
- Editor souborů
- Řídicí panely
Dotazy můžete také spouštět jako součást kanálů nebo úloh DLT.
Přehled streamovaných dotazů v Azure Databricks najdete v tématu Dotazování streamovaných dat.
Jaká data můžete dotazovat pomocí Azure Databricks?
Azure Databricks podporuje dotazování dat ve více formátech a podnikových systémech. Data, která dotazujete pomocí Azure Databricks, spadají do jedné ze dvou širokých kategorií: dat v Datovém jezeře Databricks a externích datech.
Jaká data jsou v Databricks lakehouse?
Platforma Databricks Data Intelligence ve výchozím nastavení ukládá všechna data do Databricks Lakehouse.
To znamená, že když spustíte základní příkaz CREATE TABLE pro vytvoření nové tabulky, vytvořili jste tabulku lakehouse. Data Lakehouse mají následující vlastnosti:
- Uložené ve formátu Delta Lake.
- Uložené v cloudovém úložišti objektů.
- Řízeno katalogem Unity.
V Unity Catalogu jsou většina dat lakehouse na Azure Databricks zaregistrována jako spravované tabulky. Spravované tabulky poskytují nejsnadnější syntaxi a chovají se jako ostatní tabulky ve většině systémů pro správu relačních databází. Spravované tabulky se doporučují pro většinu případů použití a jsou vhodné pro všechny uživatele, kteří se nechtějí starat o podrobnosti implementace úložiště dat.
nespravovaná tabulkanebo externí tabulkaje tabulka zaregistrovaná se zadanou LOCATION. Termín externí může být zavádějící, protože externí tabulky Delta jsou stále součástí "lakehouse" dat. Nespravované tabulky můžou upřednostňovat uživatelé, kteří přímo přistupují k tabulkám z jiných klientů Delta Reader. Přehled rozdílů v sémantice tabulky najdete v tématu Co je tabulka?.
Některé starší úlohy můžou pracovat výhradně s daty Delta Lake prostřednictvím cest k souborům a neregistrovat tabulky vůbec. Tato data jsou stále data lakehouse, ale může být obtížnější je objevit, protože nejsou zaregistrovaná ve službě Unity Catalog.
Poznámka:
Správce pracovního prostoru možná neupgradoval zásady správného řízení dat tak, aby používal katalog Unity. Stále můžete získat řadu výhod Databricks Lakehouse bez Unity Catalog, ale ne všechny funkce uvedené v tomto článku nebo v dokumentaci k Azure Databricks jsou podporovány.
Jaká data jsou považována za externí?
Všechna data, která nejsou v Databricks Lakehouse, se dají považovat za externí data. Mezi příklady externích dat patří:
- Cizí tabulky zaregistrované ve službě Lakehouse Federation
- Tabulky v metastore Hive podporované Parquetem.
- Externí tabulky v Unity Catalogu s podporou JSON.
- Data CSV uložená v cloudovém úložišti objektů
- Streamování dat načtených ze systému Kafka
Azure Databricks podporuje konfiguraci připojení k mnoha zdrojům dat. Viz Připojení ke zdrojům dat.
Ačkoli katalog Unity můžete použít k řízení přístupu a definování tabulek pro data uložená ve více formátech a v externích systémech, je Delta Lake nezbytným předpokladem pro to, aby byla data považována za součást lakehouse.
Delta Lake poskytuje všechny transakční záruky v Azure Databricks, které jsou zásadní pro zachování integrity a konzistence dat. Pokud se chcete dozvědět více o transakčních zárukách v datech Azure Databricks a o tom, proč jsou důležité, přečtěte si téma Co jsou záruky ACID v Azure Databricks?
Většina uživatelů Azure Databricks provádí dotazy na kombinaci dat z "lakehouse" a externích dat. Připojování s externími daty je vždy prvním krokem pro příjem dat a kanály ETL, které přenesou data do jezera. Informace o ingestování dat najdete v tématu Ingestování dat do Azure Databricks Lakehouse.
Tabulky dotazů podle názvu
Pro všechna data zaregistrovaná jako tabulka doporučuje Databricks dotazování pomocí názvu tabulky.
Pokud používáte Katalog Unity, tabulky používají tříúrovňový obor názvů s následujícím formátem: <catalog-name>.<schema-name>.<table-name>.
Bez katalogu Unity používají identifikátory tabulek formát <schema-name>.<table-name>.
Poznámka:
Azure Databricks dědí většinu své syntaxe SQL z Apache Sparku, který nerozlišuje mezi SCHEMA a DATABASE.
Dotazování podle názvu tabulky se podporuje ve všech kontextech spuštění Azure Databricks a podporovaných jazycích.
SQL
SELECT * FROM catalog_name.schema_name.table_name
Python
spark.read.table("catalog_name.schema_name.table_name")
Řešení identifikátoru katalogu Unity
Databricks doporučuje používat plně kvalifikované identifikátory, když dotazy nebo úlohy pracují s databázovými objekty uloženými napříč několika schématy nebo katalogy.
Následující tabulka popisuje chování částečně kvalifikovaných a nekvalifikovaných identifikátorů:
| Vzor identifikátoru | Chování |
|---|---|
catalog_name.schema_name.object_name |
Odkazuje na databázový objekt určený identifikátorem. |
schema_name.object_name |
Odkazuje na databázový objekt přidružený k zadanému schema_name a object_name v aktuálním katalogu. |
object_name |
Odkazuje na databázový objekt přidružený k zadanému object_name v aktuálním katalogu a schématu. |
Co je aktuální katalog a schéma?
V interaktivních výpočetních prostředích pomocí current_catalog() a current_schema() potvrďte aktuální katalog a schéma.
Všechny pracovní prostory nakonfigurované pomocí katalogu Unity mají výchozí katalog nastavený na úrovni pracovního prostoru. Viz Správa výchozíhokatalogu .
Následující tabulka popisuje konfigurace produktů Databricks, které můžou přepsat výchozí katalog pracovního prostoru:
| Výrobek | Konfigurace |
|---|---|
| Univerzální výpočetní výkon pro všechny účely nebo úlohy | Při konfiguraci výpočetních prostředků nastavte konfiguraci Sparku spark.databricks.sql.initial.catalog.namespace. |
| technologie distribuované účetní knihy (DLT) | Katalog a schéma zadané během konfigurace kanálu přepíší výchozí hodnoty pracovního prostoru pro všechny logiky kanálu. |
Poznámka:
JDBC konfigurace mohou při připojování k externím systémům nebo metastorům také nastavit výchozí katalog nebo schéma. Pokud narazíte na neočekávané výchozí chování, obraťte se na správce zodpovědného za konfiguraci výpočetních a integrovaných systémů Databricks.
Pomocí syntaxe USE CATALOG nebo USE SCHEMA zadejte aktuálně používaný katalog nebo schéma pro aktuální relaci. Aktuální katalog nebo schéma se použije, když dotaz nebo příkaz používá částečně kvalifikovaný nebo nekvalifikovaný identifikátor.
| Výrok | Výsledek |
|---|---|
USE CATALOG catalog_name |
Nastaví aktuální katalog pomocí poskytnutého catalog_name. Nastaví aktuální schéma na default. |
USE SCHEMA schema_name |
Nastaví aktuální schéma pomocí poskytnutého schema_name v aktuálním katalogu. |
USE SCHEMA catalog_name.schema_name |
Nastavte aktuální katalog pomocí poskytnutého catalog_name a aktuálního schématu pomocí poskytnutého schema_name. |
Poznámka:
Dotazy a příkazy, které používají plně kvalifikované identifikátory pro interakci s objekty, jako jsou tabulky, zobrazení, funkce nebo modely, nemění aktuální katalog nebo schéma a vždy odkazují na zadaný objekt.
Dotazování dat podle cesty
Pomocí cest k souborům můžete dotazovat strukturovaná, částečně strukturovaná a nestrukturovaná data. Většina souborů v Azure Databricks je založená na cloudovém úložišti objektů. Viz Práce se soubory v Azure Databricks.
Databricks doporučuje nakonfigurovat veškerý přístup ke cloudovému úložišti objektů pomocí katalogu Unity a definovat svazky pro umístění úložiště objektů, která jsou přímo dotazována. Svazky poskytují lidem čitelné aliasy pro umístění a soubory v cloudovém úložišti objektů pomocí názvů katalogů a schémat pro cestu k souborům. Viz Připojte se ke cloudovým úložištím objektů a službám pomocí katalogu Unity.
Následující příklady ukazují, jak pomocí cest ke svazkům katalogu Unity číst data JSON:
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")
U cloudových umístění, která nejsou nakonfigurovaná jako svazky katalogu Unity, můžete dotazovat data přímo pomocí identifikátorů URI. Musíte nakonfigurovat přístup ke cloudovému úložišti objektů a dotazovat se na data pomocí identifikátorů URI. Viz Konfigurace přístupu ke cloudovému úložišti objektů pro Azure Databricks.
Následující příklady ukazují, jak pomocí identifikátorů URI dotazovat data JSON ve službě Azure Data Lake Storage Gen2, GCS a 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")
Dotazování dat pomocí SQL Warehouses
Azure Databricks používá SQL sklady pro výpočetní výkon v následujících rozhraních:
- SQL Editor
- Dotazy SQL služby Databricks
- Řídicí panely
- Starší řídicí panely
- Upozornění SQL
Volitelně můžete použít SQL Warehouse s následujícími produkty:
- Poznámkové bloky Databricks
- Editor souborů Databricks
- Úlohy Databricks
Při dotazování dat pomocí SQL Warehouse můžete použít pouze syntaxi SQL. Jiné programovací jazyky a rozhraní API nejsou podporovány.
Pro pracovní prostory, které mají povolený Unity Catalog, využívají SQL sklady vždy Unity Catalog k řízení přístupu ke zdrojům dat.
Většina dotazů spuštěných v cílových tabulkách SQL Warehouse Dotazy, které cílí na datové soubory, by měly využívat svazky katalogu Unity ke správě přístupu k umístěním úložiště.
Použití identifikátorů URI přímo v dotazech spuštěných ve skladech SQL může vést k neočekávaným chybám.
Dotazování na data pomocí univerzálních výpočetních prostředků nebo výpočetních prostředků pro úlohy
Většina dotazů, které spouštíte z poznámkových bloků, pracovních postupů a editoru souborů Databricks, běží na výpočetních clusterech nakonfigurovaných pomocí databricks Runtime. Tyto clustery můžete nakonfigurovat tak, aby běžely interaktivně, nebo je nasadit jako výpočetní úlohy, které pohánějí pracovní postupy. Databricks doporučuje vždy používat výpočetní prostředky úloh pro neinteraktivní úlohy.
Interaktivní a neinteraktivní úlohy
Mnoho uživatelů může při zpracování transformací během vývoje zobrazit výsledky dotazů. Přesunem interaktivní úlohy z univerzálních výpočetních prostředků na výpočetní prostředky pro úlohy můžete ušetřit čas a náklady na zpracování tím, že odstraníte dotazy, které zobrazují výsledky.
Apache Spark používá opožděné spouštění kódu, což znamená, že výsledky se počítají pouze podle potřeby a pokud nevynutíte výsledky, můžete optimalizovat více transformací nebo dotazů na zdroj dat jako jeden dotaz. To kontrastuje s režimem okamžitého vykonávání používaným v knihovně pandas, který vyžaduje, aby se výpočty zpracovávaly postupně před předáním výsledků do další metody.
Pokud vaším cílem je uložit vyčištěná, transformovaná a agregovaná data jako novou datovou sadu, měli byste před plánováním spuštění odebrat dotazy, které zobrazují výsledky z kódu.
U malých operací a malých datových sad může být čas a úspora nákladů mezní. Při velkých operacích může být značné množství času ztraceno při výpočtu a tisknutí výsledků do poznámkového bloku, který možná nebude ručně zkontrolován. Stejné výsledky by mohly být pravděpodobně dotazovány z uloženého výstupu za téměř žádné náklady po jejich uložení.