Konfigurace clusterů
Tento článek vysvětluje možnosti konfigurace, které jsou k dispozici při vytváření a úpravách Azure Databricksch clusterů. Zaměřuje se na vytváření a úpravu clusterů pomocí uživatelského rozhraní. Další metody najdete v tématu clustery CLI a clustery rozhraní API 2,0.
Pro usnadnění rozhodování, jakou kombinaci možností konfigurace vyhovuje vašim potřebám, se podívejte na téma osvědčené postupy konfigurace clusteru.

Načtení konfigurační vlastnosti Sparku z tajného kódu
Datacihly doporučuje ukládat citlivé informace, jako jsou hesla, v tajnosti místo prostého textu. Pokud chcete odkazovat na tajný klíč v konfiguraci Sparku, použijte tuto syntaxi:
spark.<secret-prop-name> <path-value>
Například chcete-li nastavit vlastnost konfigurace Sparku nazvanou password na hodnotu tajného kódu uloženou v secrets/apps/acme-app/password :
spark.password {{secrets/apps/acme-app/password}}
Další informace najdete v tématu tajné cesty ve vlastnosti konfigurace Sparku nebo v proměnné prostředí.
Zásady clusteru
Zásady clusteru omezují schopnost konfigurovat clustery na základě sady pravidel. Pravidla zásad omezují atributy nebo hodnoty atributů, které jsou k dispozici pro vytvoření clusteru. Zásady clusteru mají seznamy řízení přístupu (ACL), které omezují jejich použití na konkrétní uživatele a skupiny, a tak omezují, které zásady můžete vybrat při vytváření clusteru.
Pokud chcete nakonfigurovat zásady clusteru, vyberte v rozevíracím seznamu zásady zásadu clusteru.

Poznámka
Pokud se v pracovním prostoru nevytvořilyžádné zásady, rozevírací seznam zásady se nezobrazí.
Pokud máte:
- Oprávnění vytvořit cluster, můžete vybrat zásadu bez omezení a vytvořit plně konfigurovatelné clustery. Zásady bez omezení neomezují žádné atributy clusteru ani hodnoty atributů.
- Jak cluster vytváří oprávnění a přístup k zásadám clusteru, můžete vybrat zásadu bez omezení a zásady, ke kterým máte přístup.
- Přístup jenom k zásadám clusteru můžete vybrat zásady, ke kterým máte přístup.
Režim clusteru
Azure Databricks podporuje tři režimy clusteru: Standard, High Concurrency a Single Node. Výchozí režim clusteru je standard.
Poznámka
Konfigurace clusteru zahrnuje nastavení automatického ukončení , jehož Výchozí hodnota závisí na režimu clusteru:
- Clustery Standard a Single Node se ve výchozím nastavení ukončí automaticky po 120 minutách.
- Vysoce souběžné clustery se ve výchozím nastavení neukončí automaticky.
Důležité
Po vytvoření clusteru nemůžete režim clusteru změnit. Pokud chcete jiný režim clusteru, musíte vytvořit nový cluster.
Standardní clustery
Pro jednoho uživatele se doporučuje standardní cluster. standardní clustery můžou spouštět úlohy vyvinuté v libovolném jazyce: Python, SQL, R a Scala.
Clustery s vysokou úrovní souběžnosti
Vysoký cluster souběžnosti je spravovaný cloudový prostředek. Klíčové výhody vysoké souběžnosti clusterů jsou tím, že poskytují jemně odstupňované sdílení pro maximální využití prostředků a minimální latenci dotazů.
clustery s vysokou úrovní souběžnosti můžou spouštět úlohy vyvinuté v SQL, pythonu a R. Výkon a zabezpečení vysoce souběžných clusterů je zajištěno spouštěním kódu uživatele v samostatných procesech, což v Scala není možné.
Kromě toho pouze vysoce souběžné clustery podporují řízení přístupu k tabulce.
Chcete-li vytvořit vysoký cluster souběžnosti, nastavte režim clusteru na vysokou souběžnost.

Příklad vytvoření clusteru s vysokou úrovní Concurrency pomocí rozhraní API clusterů naleznete v tématu High Concurrency cluster example.
Clustery s jedním uzlem
Cluster s jedním uzlem nemá žádné pracovní procesy a na uzlu ovladače spouští úlohy Spark.
Na rozdíl od je standardní cluster kromě uzlu ovladače nutný k provádění úloh Spark aspoň jeden uzel Spark Worker.
Pokud chcete vytvořit cluster s jedním uzlem, nastavte režim clusteru na jeden uzel.

Další informace o práci s clustery s jedním uzlem najdete v tématu clustery s jedním uzlem.
Licencí
Chcete-li zkrátit čas spuštění clusteru, můžete připojit cluster k předdefinovanému fondu nečinných instancí pro ovladače a uzly pracovního procesu. Cluster se vytvoří pomocí instancí ve fondech. Pokud fond nemá dostatek nečinných prostředků pro vytvoření požadovaného ovladače nebo pracovních uzlů, fond se rozšíří přidělením nových instancí od zprostředkovatele instance. Po ukončení připojeného clusteru se instance, které použily, vrátí do fondů a můžou je znovu použít v jiném clusteru.
Pokud vyberete fond pro pracovní uzly, ale ne pro uzel ovladače, uzel ovladače zdědí fond z konfigurace uzlu pracovního procesu.
Důležité
Pokud se pokusíte vybrat fond pro uzel ovladače, ale ne pro pracovní uzly, dojde k chybě a váš cluster se nevytvoří. Tento požadavek zabrání situaci, kdy uzel ovladače musí čekat, až budou vytvořeny pracovní uzly, nebo naopak.
Další informace o práci s fondy v Azure Databricks najdete v tématu fondy .
Databricks Runtime
Moduly runtime datacihly představují sadu základních komponent, které se spouštějí v clusterech. Všechny moduly runtime datacihly zahrnují Apache Spark a přidávají součásti a aktualizace, které zlepšují použitelnost, výkon a zabezpečení. Podrobnosti najdete v tématu moduly runtime datacihly.
Azure Databricks v rozevíracím seznamu Databricks runtime verze při vytváření nebo úpravě clusteru nabízí několik typů modulů runtime a několik verzí těchto typů modulu runtime.

Photon image
Důležité
Tato funkce je ve verzi Public Preview.
Poznámka
K dispozici v Databricks Runtime 8,3 a novějších.
Výběr image Photon:
Zobrazí pouze moduly runtime obsahující typy imagí Photon . Zaškrtněte políčko Photon :

Vyberte modul runtime Photon.
Volitelně můžete vybrat typ instance v rozevíracím seznamu Typ pracovního procesu a typ ovladače.
Datacihly doporučuje následující typy instancí pro zajištění optimální ceny a výkonu:
- Standard_E4ds_v4
- Standard_E8ds_v4
- Standard_E16ds_v4
Aktivitu Photon můžete zobrazit v uživatelském rozhraní Spark. Na následujícím snímku obrazovky vidíte podrobnosti dotazu DAG. V DAG jsou dvě indikace Photon. Nejprve Photon operátory začínají řetězcem "Photon", například PhotonGroupingAgg . Druhý, v DAG jsou operátory a fáze Photon barevné broskve, zatímco jiné než Photon jsou modré.

Image Docker
Pro některé verze Databricks Runtime můžete při vytváření clusteru zadat image Docker. Příklady případů použití zahrnují přizpůsobení knihovny, zlatý prostředí kontejneru, které se nemění a integraci CI/CD pro Docker.
K vytváření vlastních prostředí hloubkového učení v clusterech se zařízeními GPU taky můžete použít Docker images.
Pokyny najdete v tématu přizpůsobení kontejnerů pomocí datacihlů a kontejnerových služeb datacihly v clusterech GPU.
Python version (Verze Pythonu)
Důležité
Python 2 dosáhl konce životnosti 1. ledna 2020. Python 2 není podporován v Databricks Runtime 6,0 a vyšších. Databricks Runtime 5,5 a níže i nadále podporují Python 2.
Clustery Pythonu se systémem Databricks Runtime 6,0 a vyšším
Databricks Runtime 6,0 (nepodporované) a vyšší podporuje pouze Python 3. Významné změny týkající se prostředí Pythonu, které zavádí Databricks Runtime 6,0, najdete v tématu prostředí Pythonu v poznámkách k verzi.
Clustery Pythonu se spuštěným Databricks Runtime 5,5 LTS
Pro Databricks Runtime 5,5 LTS, úlohy Sparku, buňky s poznámkovým blokem Pythonu a instalace knihovny podporují i Python 2 a 3.
Výchozí verze Pythonu pro clustery vytvořené pomocí uživatelského rozhraní je Python 3. V Databricks Runtime 5,5 LTS výchozí verze pro clustery vytvořené pomocí REST API je Python 2.
Zadat verzi Pythonu
Pokud chcete při vytváření clusteru pomocí uživatelského rozhraní zadat verzi Pythonu, vyberte ji v rozevíracím seznamu verze Pythonu .

Pokud chcete zadat verzi Pythonu při vytváření clusteru pomocí rozhraní API, nastavte proměnnou prostředí PYSPARK_PYTHON na /databricks/python/bin/python nebo /databricks/python3/bin/python3 . příklad najdete v příkladu REST API Upload velkých souborů do DBFS.
Pokud chcete ověřit, že se PYSPARK_PYTHON Konfigurace projevila, spusťte v poznámkovém bloku (nebo %python buňce) Pythonu:
import sys
print(sys.version)
Pokud jste určili /databricks/python3/bin/python3 , měl by se vytisknout něco jako:
3.5.2 (default, Sep 10 2016, 08:21:44)
[GCC 5.4.0 20160609]
Důležité
U Databricks Runtime 5,5 LTS se při spuštění %sh python --version v poznámkovém bloku python odkazuje na verzi Pythonu systému Ubuntu, což je Python 2. Použijte /databricks/python/bin/python k odkazování na verzi Pythonu, kterou používají notebooky datacihly a Spark: Tato cesta je automaticky nakonfigurovaná tak, aby odkazovala na správný spustitelný soubor Pythonu.
Nejčastější dotazy
Můžu ve stejném clusteru používat notebooky Python 2 a Python 3?
No. Verze Pythonu je nastavení pro jednotlivé clustery a nedá se konfigurovat na základě poznámkového bloku.
Jaké knihovny jsou nainstalovány v clusterech Pythonu?
Podrobnosti o konkrétních nainstalovaných knihovnách najdete v poznámkách k verzi modulu runtime datacihly.
Budou moje stávající knihovny PyPI fungovat s Pythonem 3?
Závisí na tom, zda verze knihovny podporuje verzi Databricks Runtime verze Python 3.
Databricks Runtime 5,5 LTS používá Python 3,5. Databricks Runtime 6,0 a vyšší a Databricks Runtime pomocí conda používat Python 3,7. Je možné, že konkrétní stará verze knihovny Pythonu není dopředně kompatibilní s Python 3,7. V takovém případě budete muset použít novější verzi knihovny.
Budou mé stávající .egg knihovny fungovat s Pythonem 3?
Záleží na tom, jestli je vaše existující knihovna pro vejce vzájemně kompatibilní s Pythonem 2 a 3. Pokud knihovna nepodporuje Python 3, žádná z nich selže nebo dojde k chybám za běhu.
Komplexní vodítko pro přenos kódu na Python 3 a psaní kódu kompatibilního s Pythonem 2 a 3 najdete v tématu Podpora Pythonu 3.
Můžu pořád instalovat knihovny Pythonu pomocí skriptů init?
Běžným případem použití inicializačních skriptů uzlu clusteru je instalace balíčků.
Pro Databricks Runtime 5,5 LTS použijte /databricks/python/bin/pip k zajištění toho, aby se balíčky python nainstalovaly do virtuálního prostředí Pythonu datacihly, nikoli do prostředí Pythonu systému.
Pro Databricks Runtime 6,0 a novější a Databricks Runtime s conda se pip příkaz odkazuje na pip ve správném virtuálním prostředí Pythonu. Pokud však používáte inicializační skript k vytvoření virtuálního prostředí Python, vždy používejte absolutní cestu k přístupu python a pip .
Typ uzlu clusteru
Cluster se skládá z jednoho uzlu ovladače a žádného nebo více pracovních uzlů.
Pro ovladače a pracovní uzly můžete vybrat samostatné typy instancí poskytovatele cloudu, i když ve výchozím nastavení uzel ovladače používá stejný typ instance jako pracovní uzel. Různé rodiny typů instancí vyhovují různým případům použití, například úlohám náročným na paměť nebo výpočetní výkon.
Poznámka
Pokud vaše požadavky na zabezpečení zahrnují izolaci výpočtů, vyberte jako typ pracovního procesu Standard_F72s_V2 instanci. Tyto typy instancí představují izolované virtuální počítače, které využívají celého fyzického hostitele, a poskytují potřebnou úroveň izolace, která je nutná k podpoře, například oddělení služeb USA s ochranou vlivu obrany 5 (IL5).
Uzel ovladače
Uzel ovladače uchovává informace o stavu všech poznámkových bloků připojených ke clusteru. Uzel ovladače také udržuje SparkContext a interpretuje všechny příkazy, které spouštíte z poznámkového bloku nebo knihovny v clusteru, a spustí hlavní Apache Spark, který koordinuje prováděcí moduly Spark.
Výchozí hodnota typu uzlu ovladače je stejná jako typ uzlu pracovního procesu. Pokud plánujete collect() spoustu dat od pracovníků Spark a analyzujete je v poznámkovém bloku, můžete zvolit větší typ uzlu ovladače s větší pamětí.
Tip
Vzhledem k tomu, že uzel ovladače udržuje všechny informace o stavu připojených poznámkových bloků, nezapomeňte odpojit nepoužívané poznámkové bloky z uzlu ovladače.
Pracovní uzel
Azure Databricks pracovních uzlů spouští moduly Spark a další služby, které jsou potřebné pro správné fungování clusterů. Při distribuci úlohy pomocí Sparku dojde k veškerému distribuovanému zpracování na pracovních uzlech. Azure Databricks spustí jeden prováděcí modul na jeden pracovní uzel. Proto jsou výrazy vykonavatel a Worker v kontextu architektury Azure Databricks používány v zaměnitelné.
Tip
Chcete-li spustit úlohu Spark, potřebujete alespoň jeden pracovní uzel. Pokud má cluster žádné pracovní procesy, můžete spustit jiné příkazy než Spark v uzlu ovladače, ale příkazy Spark selžou.
Typy instancí GPU
U výpočetně náročných úloh, které vyžadují vysoký výkon, jako jsou ty, které jsou spojené s hloubkovým učením, Azure Databricks podporuje clustery s akcelerovanými grafickými procesory (GPU). Tato podpora je ve verzi beta. Další informace najdete v tématu clustery s podporou GPU.
Instance přímých instancí
Pokud chcete ušetřit náklady, můžete vybrat, jestli chcete použít instance bodového volání, označované taky jako virtuální počítače Azure, a to tak, že zkontrolujete zaškrtávací políčko instance .

První instance bude vždycky na vyžádání (uzel ovladače je vždycky na vyžádání) a další instance budou obsahovat instance. Pokud jsou instance přímých instancí vyřazeny z důvodu nedostupnosti, nasadí se instance na vyžádání, aby se nahradily vyřazení instancí.
Velikost clusteru a automatické škálování
Když vytvoříte cluster Azure Databricks, můžete buď zadat pevný počet pracovních procesů pro cluster, nebo zadat minimální a maximální počet pracovních procesů pro cluster.
Když zadáte cluster s pevnou velikostí, Azure Databricks zajistí, že má váš cluster zadaný počet pracovních procesů. Když zadáte rozsah počtu pracovních procesů, datacihly zvolí příslušný počet pracovních procesů potřebných ke spuštění vaší úlohy. Tento postup se označuje jako automatické škálování.
Díky automatickému škálování Azure Databricks dynamicky předěluje pracovní procesy na účet pro charakteristiky vaší úlohy. Některé části vašeho kanálu můžou být náročnější na výpočetní výkon než jiné a datacihly automaticky přidávají další pracovní procesy v těchto fázích úlohy (a odstraní je, když už je nepotřebují).
Automatické škálování usnadňuje zajištění vysokého využití clusteru, protože nemusíte cluster zřizovat, aby se shodoval s úlohami. To platí zejména pro úlohy, jejichž požadavky se v průběhu času mění (například prozkoumat datovou sadu v průběhu dne), ale můžou se také vztahovat na jednorázovou kratší úlohu, jejíž požadavky na zřizování nejsou známy. Automatické škálování proto nabízí dvě výhody:
- Úlohy můžou běžet rychleji v porovnání s konstantním clusterem, který je v rámci zřízené velikosti.
- Clustery automatického škálování můžou snížit celkové náklady ve srovnání se staticky škálovatelným clusterem.
V závislosti na konstantní velikosti clusteru a zatížení vám automatické škálování poskytuje jednu nebo obě tyto výhody současně. Velikost clusteru může přecházet pod minimálním počtem pracovníků vybraných, když poskytovatel cloudu ukončí instance. V tomto případě se Azure Databricks nepřetržitě pokusí znovu zřídit instance, aby bylo možné zachovat minimální počet pracovních procesů.
Poznámka
Automatické škálování není pro úlohy k dispozici spark-submit .
Typy automatického škálování
Azure Databricks nabízí dva typy automatického škálování uzlu clusteru: Standard a optimalizováno. Diskuzi o výhodách optimalizovaného automatického škálování najdete v blogovém příspěvku o optimalizovanémautomatickém škálování.
Automatizované (úlohy) clustery vždy používají optimalizované automatické škálování. Typ automatického škálování provedený u všech clusterů účelu závisí na konfiguraci pracovního prostoru.
Standardní automatické škálování se používají u všech clusterů v pracovních prostorech v cenové úrovni Standard. optimalizované automatické škálování se používají u všech clusterů pro všechny účely v plánu Azure Databricks Premium.
Jak se chová automatické škálování
Automatické škálování se chová odlišně v závislosti na tom, jestli je optimalizované nebo standardní a jestli se používá pro všechny účely nebo clustery úloh.
Optimalizované automatické škálování
- Škáluje se v 2 krocích až z minimálního počtu na maximum.
- Může horizontální navýšení kapacity i v případě, že je cluster nečinný, když se podíváte do stavu souboru náhodně
- Škáluje dolů na základě procenta aktuálních uzlů.
- V případě clusterů úloh Škálujte, jestli je cluster během posledních 40 sekund nevyužitý.
- V případě clusterů pro všechny účely Škálujte, jestli je cluster během posledních 150 sekund nevyužitý.
spark.databricks.aggressiveWindowDownSVlastnost konfigurace Spark určuje dobu v sekundách, po kterou cluster provádí rozhodování o škálování. Zvýšení hodnoty způsobí pomalejší škálování clusteru. Maximální hodnota je 600.
Standardní automatické škálování
- Začíná přidáváním osmi uzlů. Následně se škáluje exponenciálně, ale může provést mnoho kroků, abyste dosáhli maximálního počtu. První krok můžete přizpůsobit nastavením
spark.databricks.autoscaling.standardFirstStepUpVlastnosti konfigurace Sparku. - Škáluje se dolů pouze v případě, že je cluster zcela nečinný a byl za posledních 10 minut již nevyužit.
- Škáluje exponenciálně dolů, počínaje 1 uzlem.
Povolení a konfigurace automatického škálování
Pokud chcete Azure Databricks povolit automatické změny velikosti clusteru, povolte pro cluster automatické škálování a zadejte minimální a maximální rozsah pracovních procesů.
Povolte automatické škálování.
All-Purpose cluster – na stránce vytvořit cluster zaškrtněte políčko Povolit automatické škálování v poli Možnosti automatického pilotu :

Cluster úloh – na stránce konfigurovat cluster zaškrtněte políčko Povolit automatické škálování v poli Možnosti automatického pilotu :

Nakonfigurujte pracovní procesy min a max.

Když je cluster spuštěný, zobrazí se na stránce Podrobnosti o clusteru počet přidělených pracovních procesů. Můžete porovnat počet přidělených pracovníků s konfigurací pracovního procesu a podle potřeby provádět úpravy.
Důležité
Pokud používáte fond instancí:
- Ujistěte se, že požadovaná velikost clusteru je menší nebo rovna minimálnímu počtu nečinných instancí ve fondu. Pokud je větší, doba potřebná ke spuštění clusteru bude stejná jako u clusteru, který nevyužívá fond.
- Ujistěte se, že maximální velikost clusteru je menší nebo rovna maximální kapacitě fondu. Pokud je větší, vytváření clusteru selže.
Příklad automatického škálování
Pokud překonfigurujete statický cluster tak, aby byl cluster s automatickým škálováním, Azure Databricks hned změní velikost clusteru v rámci minimální a maximální meze a potom spustí automatické škálování. V následující tabulce najdete příklad toho, co se stane s clustery s určitou počáteční velikostí, pokud překonfigurujete cluster pro automatické škálování mezi 5 a 10 uzly.
| Počáteční velikost | Velikost po změně konfigurace |
|---|---|
| 6 | 6 |
| 12 | 10 |
| 3 | 5 |
Automatické škálování místního úložiště
Může být často obtížné odhadnout, kolik místa na disku bude konkrétní úloha trvat. Pokud si chcete ušetřit, kolik GB spravovaného disku se má během vytváření připojit ke clusteru, Azure Databricks automaticky povolí automatické škálování místního úložiště ve všech clusterech Azure Databricks.
Díky automatickému škálování místního úložiště Azure Databricks monitoruje množství volného místa na disku, které je dostupné pro pracovní procesy Sparku v clusteru. Pokud pracovník na disku začne používat příliš nízký počet, datacihly automaticky připojí k pracovnímu procesu nový spravovaný disk, než dojde k vyzkoušení místa na disku. Disky jsou připojeny až do limitu 5 TB z celkového místa na disku na virtuální počítač (včetně počátečního místního úložiště virtuálního počítače).
Spravované disky připojené k virtuálnímu počítači se odpojí jenom v případě, že se virtuální počítač vrátí do Azure. To znamená, že se spravované disky nikdy neodpojily od virtuálního počítače, pokud je součástí běžícího clusteru. Pokud chcete škálovat využívání spravovaného disku, Azure Databricks doporučuje použít tuto funkci v clusteru nakonfigurovaném pomocí typů instancí GPU nebo automatického ukončení.
Šifrování místního disku
Důležité
Tato funkce je ve verzi Public Preview.
Některé typy instancí, které používáte ke spouštění clusterů, můžou mít místně připojené disky. Azure Databricks může na těchto místně připojených discích ukládat náhodně uložená data nebo data v dočasném prostředí. Aby se zajistilo, že všechna uložená data jsou zašifrovaná pro všechny typy úložišť, včetně náhodného ukládání dat, která jsou dočasně uložená na místních discích clusteru, můžete povolit šifrování na místním disku.
Důležité
Vaše úlohy můžou být pomaleji kvůli dopadu na výkon čtení a zápisu šifrovaných dat do a z místních svazků.
Pokud je povolené šifrování na místním disku, Azure Databricks vygeneruje místně šifrovací klíč, který je jedinečný pro každý uzel clusteru a používá se k šifrování všech dat uložených na místních discích. Rozsah klíče je místní pro každý uzel clusteru a je zničen spolu s samotným uzlem clusteru. Během své životnosti se klíč nachází v paměti pro šifrování a dešifrování a je uložen na disku zašifrovaný.
Pokud chcete povolit šifrování na místním disku, musíte použít rozhraní API clusterů 2,0. Během vytváření nebo úprav clusteru nastavte:
{
"enable_local_disk_encryption": true
}
Příklady volání těchto rozhraní API najdete v tématu Vytvoření a Úprava v referenčních informacích k rozhraní API clusterů.
Tady je příklad volání vytvoření clusteru, které umožňuje šifrování místního disku:
{
"cluster_name": "my-cluster",
"spark_version": "7.3.x-scala2.12",
"node_type_id": "Standard_D3_v2",
"enable_local_disk_encryption": true,
"spark_conf": {
"spark.speculation": true
},
"num_workers": 25
}
Konfigurace Sparku
Aby bylo možné doladit úlohy Sparku, můžete v konfiguraci clusteru zadat vlastní Vlastnosti konfigurace Sparku .
Na stránce konfigurace clusteru klikněte na přepínač Rozšířené možnosti .
Klikněte na kartu Spark .

V konfiguraci Sparkuzadejte vlastnosti konfigurace jako jednu dvojici klíč-hodnota na řádek.
Při konfiguraci clusteru pomocí rozhraní API clusterů 2,0nastavte vlastnosti Sparku v poli v poli vytvořit žádost o cluster nebo upravit požadavek clusteru.
Chcete-li nastavit vlastnosti Spark pro všechny clustery, vytvořte globální skript init:
dbutils.fs.put("dbfs:/databricks/init/set_spark_params.sh","""
|#!/bin/bash
|
|cat << 'EOF' > /databricks/driver/conf/00-custom-spark-driver-defaults.conf
|[driver] {
| "spark.sql.sources.partitionOverwriteMode" = "DYNAMIC"
|}
|EOF
""".stripMargin, true)
Proměnné prostředí
Můžete nastavit proměnné prostředí, ke kterým máte přístup ze skriptů spuštěných v clusteru.
Na stránce konfigurace clusteru klikněte na přepínač Rozšířené možnosti .
Klikněte na kartu Spark .
Nastavte proměnné prostředí v poli proměnné prostředí .

Můžete také nastavit proměnné prostředí pomocí spark_env_vars pole v koncových bodech rozhraní API pro spark_env_vars nebo pro úpravy v clusterech žádostí o cluster.
Poznámka
Proměnné prostředí, které jste nastavili v tomto poli, nejsou k dispozici v inicializačních skriptech uzlů clusteru. Skripty init podporují pouze omezené sady předdefinovaného pořadí spouštění skriptu init.
Značky clusteru
Značky clusteru umožňují snadno sledovat náklady na cloudové prostředky, které používají různé skupiny ve vaší organizaci. Značky můžete zadat jako páry klíč-hodnota při vytváření clusteru a Azure Databricks tyto značky použít pro cloudové prostředky, jako jsou virtuální počítače a diskový svazek, a také sestavy o využití DBU.
Pro clustery spouštěné z fondů se vlastní značky clusteru aplikují jenom na sestavy využití DBU a nešíří se do cloudových prostředků. Podrobné informace o tom, jak typy značek fondů a clusterů vzájemně spolupracují, najdete v tématu monitorování využití pomocí značek cluster, pool a Workspace.
Pro usnadnění práce používá Azure Databricks pro každý cluster čtyři výchozí značky: Vendor , Creator , ClusterName a ClusterId .
Kromě toho Azure Databricks v clusterech úloh použít dvě výchozí značky: RunName a JobId . u prostředků používaných datacihly SQL Azure Databricks používá také výchozí značku SqlEndpointId .
Upozornění
Nepřiřazujte ke clusteru vlastní značku Name . Každý cluster má značku, Name jejíž hodnota je nastavena pomocí Azure Databricks. Pokud změníte hodnotu přidruženou ke klíči Name , cluster už nebude možné sledovat pomocí Azure Databricks. V důsledku toho se může stát, že se cluster neukončí po nečinnosti a bude dál účtovat náklady na využití.
Vlastní značky můžete přidat při vytváření clusteru. Konfigurace značek clusteru:
Na stránce konfigurace clusteru klikněte na přepínač Rozšířené možnosti .
V dolní části stránky klikněte na kartu značky .

Přidejte pár klíč-hodnota pro každou vlastní značku. Můžete přidat až 43 vlastních značek.
Přístup ke clusterům přes SSH
Z bezpečnostních důvodů je v Azure Databricks port SSH ve výchozím nastavení uzavřený. Pokud chcete povolit přístup SSH k vašim clusterům Spark, obraťte se na podporu Azure Databricks.
Poznámka
SSH se dá povolit jenom v případě, že je váš pracovní prostor nasazený ve vaší vlastní službě Azure Virtual Network.
Doručení protokolu clusteru
Při vytváření clusteru můžete zadat umístění pro doručování protokolů pro uzel ovladače Spark, pracovní uzly a události. Protokoly se dodávají do vybraného cíle každých pět minut. Po ukončení clusteru Azure Databricks garantuje doručení všech protokolů vygenerovaných až do chvíle, kdy byl cluster ukončen.
Cíl protokolů závisí na ID clusteru. Pokud je zadaný cíl dbfs:/cluster-log-delivery , 0630-191345-leap375 do nástroje se doručí protokol clusteru pro dbfs:/cluster-log-delivery/0630-191345-leap375 .
Konfigurace umístění pro doručování protokolu:
Na stránce konfigurace clusteru klikněte na přepínač Rozšířené možnosti .
Klikněte na kartu protokolování .

Vyberte typ cíle.
Zadejte cestu k protokolu clusteru.
Poznámka
Tato funkce je také k dispozici v REST API. Viz příklady clusterů rozhraní API 2,0 a doručování protokolů clusteru.
Inicializační skripty
Inicializace uzlu clusteru – nebo init – skript je skript prostředí, který se spouští během spouštění pro každý uzel clusteru před spuštěním ovladače Spark nebo JVM pracovního procesu. Skripty init můžete použít k instalaci balíčků a knihoven, které nejsou zahrnuté v modulu runtime datacihly, úpravě třídy classpath systému JVM, nastavení vlastností systému a proměnných prostředí používaných JVM, nebo úpravě konfiguračních parametrů Sparku mezi další úlohy konfigurace.
Skripty init můžete připojit ke clusteru tak, že rozbalíte část Upřesnit možnosti a kliknete na kartu inicializační skripty .
Podrobné pokyny najdete v tématu inicializační skripty uzlu clusteru.