Aanbevolen procedures voor Unity Catalog

Dit document bevat aanbevelingen voor het gebruik van Unity Catalog en Delta Sharing om te voldoen aan uw behoeften voor gegevensbeheer.

Unity Catalog is een verfijnde governanceoplossing voor gegevens en AI op het Databricks-platform. Het helpt de beveiliging en governance van uw gegevens te vereenvoudigen door een centrale plaats te bieden voor het beheren en controleren van gegevenstoegang. Delta Sharing is een beveiligd platform voor het delen van gegevens waarmee u gegevens kunt delen in Azure Databricks met gebruikers buiten uw organisatie. Er wordt gebruikgemaakt van Unity Catalog om gedrag voor delen te beheren en te controleren.

Bouwstenen voor gegevensbeheer en gegevensisolatie

Als u een gegevensbeheermodel en een gegevensisolatieplan wilt ontwikkelen dat geschikt is voor uw organisatie, is het handig om inzicht te krijgen in de primaire bouwstenen die voor u beschikbaar zijn wanneer u uw oplossing voor gegevensbeheer maakt in Azure Databricks.

In het volgende diagram ziet u de primaire gegevenshiërarchie in Unity Catalog (sommige beveiligbare objecten worden grijs weergegeven om de hiërarchie van objecten die worden beheerd onder catalogi te benadrukken).

De objecten in die hiërarchie bevatten het volgende:

• Metastore: Een metastore is de container op het hoogste niveau van objecten in Unity Catalog. Metastores leven op accountniveau en functioneren als de bovenkant van de piramide in het Azure Databricks-gegevensbeheermodel.

  Metastores beheren gegevensassets (tabellen, weergaven en volumes) en de machtigingen die toegang tot deze assets beheren. Azure Databricks-accountbeheerders kunnen één metastore maken voor elke regio waarin ze werken en deze toewijzen aan meerdere Azure Databricks-werkruimten in dezelfde regio. Metastore-beheerders kunnen alle objecten in de metastore beheren. Ze hebben geen directe toegang tot tabellen die zijn geregistreerd in de metastore, maar ze hebben wel indirecte toegang via hun mogelijkheid om het eigendom van gegevensobjecten over te dragen.

  Fysieke opslag voor een bepaalde metastore wordt standaard geïsoleerd van opslag voor andere metastores in uw account.

  Metastores bieden regionale isolatie, maar zijn niet bedoeld als eenheden van gegevensisolatie. Gegevensisolatie moet beginnen op catalogusniveau.

• Catalogus: Catalogi zijn het hoogste niveau in de gegevenshiërarchie (catalogusschematabel >>/weergave/volume) die wordt beheerd door de Unity Catalog-metastore. Ze zijn bedoeld als de primaire eenheid van gegevensisolatie in een typisch Azure Databricks-gegevensbeheermodel.

  Catalogi vertegenwoordigen een logische groepering van schema's, meestal gebonden aan vereisten voor gegevenstoegang. Catalogi spiegelen vaak organisatie-eenheden of levenscyclusbereiken voor softwareontwikkeling. U kunt er bijvoorbeeld voor kiezen om een catalogus te hebben voor productiegegevens en een catalogus voor ontwikkelingsgegevens, of een catalogus voor niet-klantgegevens en een catalogus voor gevoelige klantgegevens.

  Catalogi kunnen worden opgeslagen op metastoreniveau of u kunt een catalogus configureren die afzonderlijk van de rest van de bovenliggende metastore moet worden opgeslagen. Als uw werkruimte automatisch is ingeschakeld voor Unity Catalog, is er geen opslag op metastoreniveau en moet u een opslaglocatie opgeven wanneer u een catalogus maakt.

  Als de catalogus de primaire eenheid van gegevensisolatie is in het Azure Databricks-gegevensbeheermodel, is de werkruimte de primaire omgeving voor het werken met gegevensassets. Metastore-beheerders en cataloguseigenaren kunnen de toegang tot catalogi onafhankelijk van werkruimten beheren, of ze kunnen catalogi binden aan specifieke werkruimten om ervoor te zorgen dat bepaalde soorten gegevens alleen in die werkruimten worden verwerkt. Mogelijk wilt u afzonderlijke productie- en ontwikkelingswerkruimten, bijvoorbeeld een afzonderlijke werkruimte voor het verwerken van persoonlijke gegevens.

  Toegangsmachtigingen voor een beveiligbaar object worden standaard overgenomen door de onderliggende elementen van dat object, met catalogi boven aan de hiërarchie. Hierdoor kunt u eenvoudiger standaardtoegangsregels instellen voor uw gegevens en verschillende regels opgeven op elk niveau van de hiërarchie waar u ze nodig hebt.

• Schema (Database): Schema's, ook wel databases genoemd, zijn logische groeperingen van tabelgegevens (tabellen en weergaven), niet-tabellaire gegevens (volumes), functies en machine learning-modellen. Ze bieden u een manier om de toegang tot gegevens te organiseren en te beheren die gedetailleerder zijn dan catalogi. Meestal vertegenwoordigen ze één use-case, project of team-sandbox.

  Schema's kunnen worden opgeslagen in dezelfde fysieke opslag als de bovenliggende catalogus, of u kunt een schema configureren dat afzonderlijk van de rest van de bovenliggende catalogus moet worden opgeslagen.

  Metastore-beheerders, bovenliggende cataloguseigenaren en schema-eigenaren kunnen de toegang tot schema's beheren.

• Tabellen: Tabellen bevinden zich in de derde laag van de naamruimte op drie niveaus van Unity Catalog. Ze bevatten rijen met gegevens.

  Met Unity Catalog kunt u beheerde tabellen en externe tabellen maken.

  Voor beheerde tabellen beheert Unity Catalog de levenscyclus en de bestandsindeling volledig. Beheerde tabellen worden standaard opgeslagen in de hoofdopslaglocatie die u configureert wanneer u een metastore maakt. U kunt in plaats daarvan kiezen voor het isoleren van opslag voor beheerde tabellen op de catalogus- of schemaniveaus.

  Externe tabellen zijn tabellen waarvan de levenscyclus van gegevens en de bestandsindeling worden beheerd met behulp van uw cloudprovider en andere gegevensplatformen, niet Unity Catalog. Normaal gesproken gebruikt u externe tabellen om grote hoeveelheden bestaande gegevens te registreren, of als u ook schrijftoegang tot de gegevens nodig hebt met behulp van hulpprogramma's buiten Azure Databricks-clusters en Databricks SQL-warehouses. Zodra een externe tabel is geregistreerd in een Unity Catalog-metastore, kunt u Azure Databricks-toegang beheren en controleren, net zoals bij beheerde tabellen.

  Eigenaren van bovenliggende catalogi en schema-eigenaren kunnen de toegang tot tabellen beheren, net zoals metastore-beheerders (indirect).

• Weergaven: Een weergave is een alleen-lezenobject dat is afgeleid van een of meer tabellen en weergaven in een metastore.

• Rijen en kolommen: toegang op rij- en kolomniveau, samen met gegevensmaskering, wordt verleend met dynamische weergaven of rijfilters en kolommaskers. Dynamische weergaven zijn alleen-lezen.

• Volumes: Volumes bevinden zich in de derde laag van de naamruimte op drie niveaus van Unity Catalog. Ze beheren niet-tabellaire gegevens. U kunt volumes gebruiken voor het opslaan, ordenen en openen van bestanden in elke indeling, waaronder gestructureerde, semi-gestructureerde en ongestructureerde gegevens. Bestanden in volumes kunnen niet worden geregistreerd als tabellen.

• Modellen en functies: Hoewel ze niet, strikt genomen, gegevensassets, geregistreerde modellen en door de gebruiker gedefinieerde functies ook kunnen worden beheerd in Unity Catalog en zich op het laagste niveau in de objecthiërarchie bevinden. Zie Levenscyclus van modellen beheren in Unity Catalog en door de gebruiker gedefinieerde functies (UDF's) in Unity Catalog.

Uw gegevensisolatiemodel plannen

Wanneer een organisatie een gegevensplatform zoals Azure Databricks gebruikt, is er vaak behoefte aan gegevensisolatiegrenzen tussen omgevingen (zoals ontwikkeling en productie) of tussen operationele eenheden van de organisatie.

Isolatiestandaarden kunnen variëren voor uw organisatie, maar bevatten doorgaans de volgende verwachtingen:

• Gebruikers kunnen alleen toegang krijgen tot gegevens op basis van opgegeven toegangsregels.
• Gegevens kunnen alleen worden beheerd door aangewezen personen of teams.
• Gegevens worden fysiek gescheiden in de opslag.
• Gegevens kunnen alleen worden geopend in aangewezen omgevingen.

De noodzaak van gegevensisolatie kan leiden tot siloomgevingen die zowel gegevensbeheer als samenwerking onnodig moeilijk kunnen maken. Azure Databricks lost dit probleem op met behulp van Unity Catalog, dat een aantal opties voor gegevensisolatie biedt en tegelijkertijd een geïntegreerd platform voor gegevensbeheer onderhoudt. In deze sectie worden de opties voor gegevensisolatie besproken die beschikbaar zijn in Azure Databricks en hoe u deze kunt gebruiken, ongeacht of u liever een gecentraliseerd gegevensbeheermodel of een gedistribueerd model gebruikt.

Gebruikers kunnen alleen toegang krijgen tot gegevens op basis van opgegeven toegangsregels

De meeste organisaties hebben strikte vereisten voor gegevenstoegang op basis van interne of wettelijke vereisten. Typische voorbeelden van gegevens die veilig moeten worden gehouden, zijn salarisgegevens van werknemers of creditcardbetalingsgegevens. Toegang tot dit type informatie wordt doorgaans nauw gecontroleerd en periodiek gecontroleerd. Unity Catalog biedt u gedetailleerde controle over gegevensassets in de catalogus om te voldoen aan deze industriestandaarden. Met de besturingselementen die Unity Catalog biedt, kunnen gebruikers alleen de gegevens bekijken en er query's op uitvoeren die ze recht hebben om ze te bekijken en er query's op uit te voeren.

Gegevens kunnen alleen worden beheerd door aangewezen personen of teams

Unity Catalog biedt u de mogelijkheid om te kiezen tussen gecentraliseerde en gedistribueerde governancemodellen.

In het gecentraliseerde governancemodel zijn uw governancebeheerders eigenaars van de metastore en kunnen ze eigenaar worden van elk object en machtigingen verlenen en intrekken.

In een gedistribueerd governancemodel is de catalogus of een set catalogi het gegevensdomein. De eigenaar van die catalogus kan alle assets maken en bezitten en governance binnen dat domein beheren. De eigenaren van een bepaald domein kunnen onafhankelijk van de eigenaren van andere domeinen werken.

Ongeacht of u de metastore of catalogi als uw gegevensdomein kiest, raadt Databricks u ten zeerste aan om een groep in te stellen als de metastore-beheerder of cataloguseigenaar.

Gegevens worden fysiek gescheiden in de opslag

Een organisatie kan vereisen dat gegevens van bepaalde typen worden opgeslagen in specifieke accounts of buckets in hun cloudtenant.

Unity Catalog biedt de mogelijkheid om opslaglocaties op metastore-, catalogus- of schemaniveau te configureren om aan dergelijke vereisten te voldoen.

Stel dat uw organisatie een nalevingsbeleid voor bedrijven heeft waarvoor productiegegevens met betrekking tot human resources moeten worden opgeslagen in de container abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net. In Unity Catalog kunt u deze vereiste bereiken door een locatie op catalogusniveau in te stellen, een catalogus te maken die bijvoorbeeld hr_prodwordt aangeroepen en de locatie toe te wijzen abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog. Dit betekent dat beheerde tabellen of volumes die zijn gemaakt in de hr_prod catalogus (bijvoorbeeld met behulp van CREATE TABLE hr_prod.default.table …) hun gegevens opslaan in abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog. U kunt er desgewenst voor kiezen om locaties op schemaniveau op te geven om gegevens op hr_prod catalog een gedetailleerder niveau te ordenen.

Als een dergelijke opslagisolatie niet vereist is, kunt u een opslaglocatie instellen op metastore-niveau. Het resultaat is dat deze locatie fungeert als een standaardlocatie voor het opslaan van beheerde tabellen en volumes in catalogi en schema's in de metastore.

Het systeem evalueert de hiërarchie van opslaglocaties van schema naar catalogus naar metastore.

Als er bijvoorbeeld een tabel wordt gemaakt, my-region-metastorewordt de opslaglocatie van de tabel myCatalog.mySchema.myTable bepaald volgens de volgende regel:

1. Als er een locatie is opgegeven mySchema, wordt deze daar opgeslagen.
2. Als dat niet het probleem is en er een locatie is opgegeven myCatalog, wordt deze daar opgeslagen.
3. Als er ten slotte geen locatie is opgegeven myCatalog, wordt deze opgeslagen op de locatie die is gekoppeld aan de my-region-metastore.

Gegevens kunnen alleen worden geopend in aangewezen omgevingen

Organisatie- en nalevingsvereisten geven vaak aan dat u bepaalde gegevens, zoals persoonlijke gegevens, alleen toegankelijk houdt in bepaalde omgevingen. U kunt ook productiegegevens geïsoleerd houden van ontwikkelomgevingen of ervoor zorgen dat bepaalde gegevenssets en domeinen nooit aan elkaar worden gekoppeld.

In Databricks is de werkruimte de primaire omgeving voor gegevensverwerking en zijn catalogi het primaire gegevensdomein. Met Unity Catalog kunnen metastore-beheerders en cataloguseigenaren catalogi toewijzen of 'binden', aan werkruimten. Deze omgevingsbewuste bindingen bieden u de mogelijkheid om ervoor te zorgen dat alleen bepaalde catalogi beschikbaar zijn in een werkruimte, ongeacht de specifieke bevoegdheden voor gegevensobjecten die aan een gebruiker zijn verleend.

Laten we nu eens kijken naar het proces van het instellen van Unity Catalog om aan uw behoeften te voldoen.

Een Unity Catalog-metastore configureren

Een metastore is de container op het hoogste niveau van objecten in Unity Catalog. Metastores beheren gegevensassets (tabellen, weergaven en volumes) en andere beveiligbare objecten die worden beheerd door Unity Catalog. Zie Beveiligbare objecten in Unity Catalog voor de volledige lijst met beveiligbare objecten.

Deze sectie bevat tips voor het maken en configureren van metastores. Als uw werkruimte automatisch is ingeschakeld voor Unity Catalog, hoeft u geen metastore te maken, maar de informatie die in deze sectie wordt weergegeven, is mogelijk nog steeds nuttig. Zie Automatische activering van Unity Catalog.

Tips voor het configureren van metastores:

• U moet één metastore instellen voor elke regio waarin u Azure Databricks-werkruimten hebt.

  Elke werkruimte die is gekoppeld aan één regionale metastore heeft toegang tot de gegevens die worden beheerd door de metastore. Als u gegevens tussen metastores wilt delen, gebruikt u Delta Sharing.

• Elke metastore kan worden geconfigureerd met een beheerde opslaglocatie (ook wel hoofdopslag genoemd) in uw cloudtenant die kan worden gebruikt voor het opslaan van beheerde tabellen en beheerde volumes.

  Als u ervoor kiest om een beheerde locatie op metastore-niveau te maken, moet u ervoor zorgen dat er geen gebruikers rechtstreeks toegang toe hebben (dat wil gezegd via het cloudaccount dat deze bevat). Door toegang te verlenen tot deze opslaglocatie kan een gebruiker toegangsbeheer omzeilen in een Unity Catalog-metastore en de controlebaarheid verstoren. Om deze redenen moet uw beheerde metastore-opslag een toegewezen container zijn. U moet een container die ook uw DBFS-hoofdbestandssysteem is of eerder een DBFS-hoofdbestandssysteem is geweest, niet opnieuw gebruiken.

  U hebt ook de mogelijkheid om beheerde opslag te definiëren op de catalogus- en schemaniveaus, waarbij de hoofdopslaglocatie van de metastore wordt overschreven. In de meeste scenario's raadt Databricks aan beheerde gegevens op catalogusniveau op te slaan.

• U moet inzicht krijgen in de bevoegdheden van werkruimtebeheerders in werkruimten die zijn ingeschakeld voor Unity Catalog en uw bestaande toewijzingen van werkruimtebeheerders controleren.

  Werkruimtebeheerders kunnen bewerkingen voor hun werkruimte beheren, waaronder het toevoegen van gebruikers en service-principals, het maken van clusters en het delegeren van andere gebruikers als werkruimtebeheerders. Als uw werkruimte automatisch is ingeschakeld voor Unity Catalog, hebben werkruimtebeheerders de mogelijkheid om catalogi en veel andere Unity Catalog-objecten standaard te maken. Beheerdersbevoegdheden voor werkruimten weergeven wanneer werkruimten automatisch zijn ingeschakeld voor Unity Catalog

  Werkruimtebeheerders hebben ook de mogelijkheid om werkruimtebeheertaken uit te voeren, zoals het beheren van het eigendom van taken en het weergeven van notebooks, die indirecte toegang kunnen geven tot gegevens die zijn geregistreerd in Unity Catalog. Werkruimtebeheerder is een bevoorrechte rol die u zorgvuldig moet distribueren.

• Als u werkruimten gebruikt om de toegang tot gebruikersgegevens te isoleren, kunt u bindingen voor werkruimtecatalogus gebruiken. Met bindingen voor werkruimtecatalogus kunt u catalogustoegang beperken op basis van werkruimtegrenzen. U kunt er bijvoorbeeld voor zorgen dat werkruimtebeheerders en gebruikers alleen toegang hebben tot productiegegevens vanuit prod_catalog een productiewerkruimteomgeving. prod_workspace De standaardinstelling is om de catalogus te delen met alle werkruimten die zijn gekoppeld aan de huidige metastore. Zie (Optioneel) Een catalogus toewijzen aan specifieke werkruimten.

  Als uw werkruimte automatisch is ingeschakeld voor Unity Catalog, is de vooraf ingerichte werkruimtecatalogus standaard gebonden aan uw werkruimte.

Zie Een Unity Catalog-metastore maken.

Externe locaties en opslagreferenties configureren

Met externe locaties kan Unity Catalog namens gebruikers gegevens lezen en schrijven in uw cloudtenant. Externe locaties worden gedefinieerd als een pad naar cloudopslag, gecombineerd met een opslagreferentie die kan worden gebruikt voor toegang tot die locatie.

U kunt externe locaties gebruiken om externe tabellen en externe volumes te registreren in Unity Catalog. De inhoud van deze entiteiten bevindt zich fysiek op een subpad op een externe locatie waarnaar wordt verwezen wanneer een gebruiker het volume of de tabel maakt.

Een opslagreferentie bevat een langetermijncloudreferentie die toegang biedt tot cloudopslag. Het kan een door Azure beheerde identiteit (sterk aanbevolen) of een service-principal zijn. Het gebruik van een door Azure beheerde identiteit heeft de volgende voordelen ten opzichte van het gebruik van een service-principal:

• Voor beheerde identiteiten hoeft u geen referenties te onderhouden of geheimen te roteren.
• Als uw Azure Databricks-werkruimte is geïmplementeerd in uw eigen VNet (ook wel VNet-injectie genoemd), kunt u verbinding maken met een Azure Data Lake Storage Gen2-account dat wordt beveiligd door een opslagfirewall.

Tip

Externe locaties, door opslagreferenties en opslagpaden te combineren, bieden een sterke controle en controlebaarheid van opslagtoegang. Als u wilt voorkomen dat gebruikers het toegangsbeheer van Unity Catalog omzeilen, moet u ervoor zorgen dat u het aantal gebruikers met directe toegang beperkt tot elke container die wordt gebruikt als een externe locatie. Om dezelfde reden moet u opslagaccounts niet koppelen aan DBFS als ze ook worden gebruikt als externe locaties. Databricks raadt u aan om koppelingen op cloudopslaglocaties te migreren naar externe locaties in Unity Catalog met behulp van Catalog Explorer.

Zie Externe locaties, externe tabellen en externe volumes beheren voor een lijst met aanbevolen procedures voor het beheren van externe locaties. Zie ook Een externe locatie maken om cloudopslag te verbinden met Azure Databricks.

Uw gegevens ordenen

Databricks raadt aan catalogi te gebruiken om scheiding te bieden in de informatiearchitectuur van uw organisatie. Dit betekent vaak dat catalogi overeenkomen met het bereik van een softwareontwikkelingsomgeving, -team of -bedrijfseenheid. Als u werkruimten gebruikt als hulpprogramma voor gegevensisolatie, zoals het gebruik van verschillende werkruimten voor productie- en ontwikkelomgevingen of een specifieke werkruimte voor het werken met zeer gevoelige gegevens, kunt u ook een catalogus binden aan specifieke werkruimten. Dit zorgt ervoor dat alle verwerking van opgegeven gegevens wordt verwerkt in de juiste werkruimte. Zie (Optioneel) Een catalogus toewijzen aan specifieke werkruimten.

Een schema (ook wel een database genoemd) is de tweede laag van de naamruimte op drie niveaus van Unity Catalog en organiseert tabellen, weergaven en volumes. U kunt schema's gebruiken om machtigingen voor uw assets te organiseren en te definiëren.

Objecten die worden beheerd door Unity Catalog, kunnen worden beheerd of extern:

• Beheerde objecten zijn de standaard manier om gegevensobjecten te maken in Unity Catalog.

  Unity Catalog beheert de levenscyclus en de bestandsindeling voor deze beveiligbare apparaten. Gebruik geen hulpprogramma's buiten Azure Databricks om bestanden in beheerde tabellen of volumes rechtstreeks te bewerken.

  Beheerde tabellen en volumes worden opgeslagen in beheerde opslag, die kunnen bestaan op metastore-, catalogus- of schemaniveau voor een bepaalde tabel of elk bepaald volume. Gegevens worden fysiek gescheiden in de opslag.

  Beheerde tabellen en volumes zijn een handige oplossing wanneer u een beheerde locatie voor uw inhoud wilt inrichten zonder dat u hiervoor externe locaties en opslagreferenties hoeft te maken en te beheren.

  Beheerde tabellen maken altijd gebruik van de Delta-tabelindeling .

• Externe objecten zijn beveiligbare objecten waarvan de levenscyclus van gegevens en de bestandsindeling niet worden beheerd door Unity Catalog.

  Externe volumes en tabellen worden geregistreerd op een externe locatie om toegang te bieden tot grote aantallen bestanden die al bestaan in de cloudopslag zonder dat gegevenskopieeractiviteit is vereist. Gebruik externe objecten wanneer u bestanden hebt die door andere systemen worden geproduceerd en ze gefaseerd wilt uitvoeren vanuit Azure Databricks of wanneer hulpprogramma's buiten Azure Databricks directe toegang tot deze bestanden vereisen.

  Externe tabellen ondersteunen Delta Lake en vele andere gegevensindelingen, waaronder Parquet, JSON en CSV. Zowel beheerde als externe volumes kunnen worden gebruikt om bestanden van willekeurige indelingen te openen en op te slaan: gegevens kunnen gestructureerd, semi-gestructureerd of ongestructureerd zijn.

Zie Tabellen maken in Unity Catalog en Maken en werken met volumes voor meer informatie over het maken van tabellen en volumes.

Externe locaties, externe tabellen en externe volumes beheren

Het onderstaande diagram vertegenwoordigt de bestandssysteemhiërarchie van één cloudopslagcontainer, met vier externe locaties die één opslagreferentie delen.

Zodra u externe locaties hebt geconfigureerd in Unity Catalog, kunt u externe tabellen en volumes maken in mappen binnen de externe locaties. Vervolgens kunt u Unity Catalog gebruiken om gebruikers- en groepstoegang tot deze tabellen en volumes te beheren. Hiermee kunt u specifieke gebruikers of groepen toegang bieden tot specifieke mappen en bestanden in de cloudopslagcontainer.

Notitie

Wanneer u een volume definieert, wordt cloud-URI-toegang tot gegevens onder het volumepad beheerd door de machtigingen van het volume.

Aanbevelingen voor het gebruik van externe locaties

Aanbevelingen voor het verlenen van machtigingen op externe locaties:

• Verdeel de mogelijkheid om alleen externe locaties te maken aan een beheerder die is belast met het instellen van verbindingen tussen Unity Catalog en cloudopslag, of aan vertrouwde gegevenstechnici.

  Externe locaties bieden toegang vanuit Unity Catalog tot een breed omvattende locatie in cloudopslag, bijvoorbeeld een hele bucket of container (abfss://my-container@storage-account.dfs.core.windows.net) of een breed subpad (abfss://my-container@storage-account.dfs.core.windows.net/pad/naar/submap). Het is de bedoeling dat een cloudbeheerder betrokken kan zijn bij het instellen van een paar externe locaties en vervolgens de verantwoordelijkheid voor het beheren van deze locaties delegeert aan een Azure Databricks-beheerder in uw organisatie. De Azure Databricks-beheerder kan de externe locatie vervolgens verder indelen in gebieden met gedetailleerdere machtigingen door externe volumes of externe tabellen te registreren bij specifieke voorvoegsels onder de externe locatie.

  Omdat externe locaties zo omvatten, raadt Databricks aan om alleen de CREATE EXTERNAL LOCATION machtiging te verlenen aan een beheerder die is belast met het instellen van verbindingen tussen Unity Catalog en cloudopslag, of aan vertrouwde gegevenstechnici. Om andere gebruikers gedetailleerdere toegang te bieden, raadt Databricks aan externe tabellen of volumes te registreren op externe locaties en gebruikers toegang te geven tot gegevens met behulp van volumes of tabellen. Omdat tabellen en volumes onderliggende elementen van een catalogus en schema zijn, hebben catalogus- of schemabeheerders de ultieme controle over toegangsmachtigingen.

• Wijs geen algemene READ FILES of WRITE FILES machtigingen toe aan externe locaties aan eindgebruikers.

  Met de beschikbaarheid van volumes mogen gebruikers geen externe locaties gebruiken voor iets anders dan het maken van tabellen, volumes of beheerde locaties. Ze mogen geen externe locaties gebruiken voor padgebaseerde toegang voor data science of andere niet-tabellaire gegevensgebruiksscenario's.

  Volumes bieden ondersteuning voor het werken met bestanden met behulp van SQL-opdrachten, dbutils, Spark-API's, REST API's, Terraform en een gebruikersinterface voor bladeren, uploaden en downloaden van bestanden. Bovendien bieden volumes een FUSE-koppeling die toegankelijk is op het lokale bestandssysteem onder /Volumes/<catalog_name>/<schema_name>/<volume_name>/. Met de FUSE-koppeling kunnen gegevenswetenschappers en ML-technici toegang krijgen tot bestanden alsof ze zich in een lokaal bestandssysteem bevinden, zoals vereist door veel machine learning- of besturingssysteembibliotheken.

  Als u rechtstreeks toegang moet verlenen tot bestanden op een externe locatie (voor het verkennen van bestanden in cloudopslag voordat een gebruiker bijvoorbeeld een externe tabel of volume maakt), kunt u deze verlenen READ FILES. Use cases for granting WRITE FILES zijn zeldzaam.

U moet externe locaties gebruiken om het volgende te doen:

• Registreer externe tabellen en volumes met behulp van de CREATE EXTERNAL VOLUME of CREATE TABLE opdrachten.
• Verken bestaande bestanden in cloudopslag voordat u een externe tabel of volume maakt op een specifiek voorvoegsel. Het READ FILES voorrecht is een voorwaarde.
• Registreer een locatie als beheerde opslag voor catalogi en schema's in plaats van de metastore-hoofdbucket. Het CREATE MANAGED STORAGE voorrecht is een voorwaarde.

Meer aanbevelingen voor het gebruik van externe locaties:

• Vermijd conflicterende paden: maak nooit externe volumes of tabellen in de hoofdmap van een externe locatie.

  Als u externe volumes of tabellen maakt in de hoofdmap van de externe locatie, kunt u geen extra externe volumes of tabellen maken op de externe locatie. Maak in plaats daarvan externe volumes of tabellen in een submap binnen de externe locatie.

Aanbevelingen voor het gebruik van externe volumes

U moet externe volumes gebruiken om het volgende te doen:

• Registreer landingsgebieden voor onbewerkte gegevens die door externe systemen worden geproduceerd om de verwerking ervan in de vroege fasen van ETL-pijplijnen en andere data engineering-activiteiten te ondersteunen.
• Registreer faseringslocaties voor opname, bijvoorbeeld met behulp van AutoLoader- COPY INTOof CTAS-instructies (CREATE TABLE AS).
• Geef bestandsopslaglocaties op voor gegevenswetenschappers, gegevensanalisten en machine learning-technici die kunnen worden gebruikt als onderdelen van hun verkennende gegevensanalyse en andere gegevenswetenschapstaken wanneer beheerde volumes geen optie zijn.
• Geef Azure Databricks-gebruikers toegang tot willekeurige bestanden die door andere systemen in de cloud worden geproduceerd en opgeslagen, bijvoorbeeld grote verzamelingen ongestructureerde gegevens (zoals afbeeldings-, audio-, video- en PDF-bestanden) die zijn vastgelegd door bewakingssystemen of IoT-apparaten, of bibliotheekbestanden (JAR's en Python-wielbestanden) die zijn geëxporteerd vanuit lokale afhankelijkheidsbeheersystemen of CI/CD-pijplijnen.
• Sla operationele gegevens, zoals logboekregistratie of controlepuntenbestanden, op wanneer beheerde volumes geen optie zijn.

Meer aanbevelingen voor het gebruik van externe volumes:

• Databricks raadt u aan externe volumes te maken vanaf één externe locatie binnen één schema.

Tip

Voor gebruiksvoorbeelden waarin de gegevens naar een andere locatie worden gekopieerd, bijvoorbeeld met behulp van automatisch laden of COPY INTO, gebruiken we externe volumes. Gebruik externe tabellen als u gegevens wilt opvragen als een tabel, zonder dat er een kopie is betrokken.

Aanbevelingen voor het gebruik van externe tabellen

U moet externe tabellen gebruiken ter ondersteuning van normale querypatronen boven op gegevens die zijn opgeslagen in cloudopslag, wanneer het maken van beheerde tabellen geen optie is.

Meer aanbevelingen voor het gebruik van externe tabellen:

• Databricks raadt u aan externe tabellen te maken met één externe locatie per schema.
• Databricks raadt ten zeerste aan om een tabel als een externe tabel in meer dan één metastore te registreren vanwege het risico op consistentieproblemen. Een wijziging in het schema in één metastore wordt bijvoorbeeld niet geregistreerd in de tweede metastore. Delta Delen gebruiken voor het delen van gegevens tussen metastores. Zie Gegevens veilig delen met Delta Sharing.

Toegangsbeheer configureren

Elk beveiligbaar object in Unity Catalog heeft een eigenaar. De principal waarmee een object wordt gemaakt, wordt de oorspronkelijke eigenaar. De eigenaar van een object heeft alle bevoegdheden voor het object, zoals SELECT en MODIFY in een tabel, evenals de machtiging voor het verlenen van bevoegdheden voor het beveiligbare object aan andere principals. Alleen eigenaren van een beveiligbaar object hebben de machtiging om bevoegdheden voor dat object toe te kennen aan andere principals. Daarom is het raadzaam om het eigendom van alle objecten te configureren voor de groep die verantwoordelijk is voor het beheer van subsidies voor het object. Zowel de eigenaar als de metastore-beheerders kunnen het eigendom van een beveiligbaar object overdragen aan een groep. Als het object zich in een catalogus bevindt (zoals een tabel of weergave), kan de eigenaar van de catalogus en het schema het eigendom van het object wijzigen.

Beveiligbare objecten in Unity Catalog zijn hiërarchisch en bevoegdheden worden naar beneden overgenomen. Dit betekent dat het verlenen van een bevoegdheid voor een catalogus of schema automatisch de bevoegdheid verleent aan alle huidige en toekomstige objecten in de catalogus of het schema. Zie Overnamemodel voor meer informatie.

Als u gegevens uit een tabel wilt lezen of een gebruiker wilt weergeven, moet deze de volgende bevoegdheden hebben:

• SELECT in de tabel of weergave
• USE SCHEMA in het schema dat eigenaar is van de tabel
• USE CATALOG in de catalogus die eigenaar is van het schema

USE CATALOG stelt de toekenning in staat om de catalogus te doorlopen om toegang te krijgen tot de onderliggende objecten en USE SCHEMA stelt de grantee in staat om het schema te doorlopen om toegang te krijgen tot de onderliggende objecten. Als u bijvoorbeeld gegevens uit een tabel wilt selecteren, moeten gebruikers beschikken over de SELECT bevoegdheid voor die tabel en over de bevoegdheid voor de USE CATALOG bovenliggende catalogus, samen met de USE SCHEMA bevoegdheid voor het bovenliggende schema. Daarom kunt u deze bevoegdheid gebruiken om de toegang tot secties van uw gegevensnaamruimte te beperken tot specifieke groepen. Een veelvoorkomend scenario is het instellen van een schema per team, waarbij alleen dat team het schema heeftUSE SCHEMA.CREATE Dit betekent dat alle tabellen die door teamleden worden geproduceerd, alleen binnen het team kunnen worden gedeeld.

U kunt de toegang tot een tabel beveiligen met behulp van de volgende SQL-syntaxis:

GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

U kunt de toegang tot kolommen beveiligen met behulp van een dynamische weergave in een secundair schema, zoals wordt weergegeven in de volgende SQL-syntaxis:

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  id,
  CASE WHEN is_account_group_member(< group_name >) THEN email ELSE 'REDACTED' END AS email,
  country,
  product,
  total
FROM
  < catalog_name >.< schema_name >.< table_name >;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;

U kunt de toegang tot rijen beveiligen met behulp van een dynamische weergave in een secundair schema, zoals wordt weergegeven in de volgende SQL-syntaxis:

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  *
FROM
  < catalog_name >.< schema_name >.< table_name >
WHERE
  CASE WHEN is_account_group_member(managers) THEN TRUE ELSE total <= 1000000 END;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

U kunt gebruikers ook beveiligde toegang verlenen tot tabellen met behulp van rijfilters en kolommaskers. Zie Gevoelige tabelgegevens filteren met rijfilters en kolommaskers voor meer informatie.

Zie Bevoegdheden beheren in Unity Catalog voor meer informatie over alle bevoegdheden in Unity Catalog.

Clusterconfiguraties beheren

Databricks raadt aan clusterbeleid te gebruiken om de mogelijkheid om clusters te configureren op basis van een set regels te beperken. Met clusterbeleid kunt u de toegang beperken tot alleen clusters maken waarvoor Unity Catalog is ingeschakeld. Het gebruik van clusterbeleid vermindert beschikbare opties, waardoor het proces voor het maken van clusters voor gebruikers aanzienlijk wordt vereenvoudigd en ervoor zorgt dat ze naadloos toegang hebben tot gegevens. Met clusterbeleid kunt u ook de kosten beheren door de maximale kosten per cluster te beperken.

Om de integriteit van toegangsbeheer te waarborgen en sterke isolatiegaranties af te dwingen, legt Unity Catalog beveiligingsvereisten op voor rekenresources. Daarom introduceert Unity Catalog het concept van de toegangsmodus van een cluster. Unity Catalog is standaard beveiligd; als een cluster niet is geconfigureerd met de juiste toegangsmodus, heeft het cluster geen toegang tot gegevens in Unity Catalog. Zie Ondersteunde reken- en clustertoegangsmodi voor Unity Catalog.

Databricks raadt aan de modus voor gedeelde toegang te gebruiken bij het delen van een cluster en de toegangsmodus voor één gebruiker voor geautomatiseerde taken en machine learning-workloads.

De onderstaande JSON biedt een beleidsdefinitie voor een cluster met de modus voor gedeelde toegang:

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9]*\\.x-scala.*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "USER_ISOLATION",
    "hidden": true
}
}

De onderstaande JSON biedt een beleidsdefinitie voor een geautomatiseerd taakcluster met de toegangsmodus voor één gebruiker:

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9].*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "SINGLE_USER",
    "hidden": true
},
"single_user_name": {
    "type": "regex",
    "pattern": ".*",
    "hidden": true
}
}

Toegang controleren

Een volledige oplossing voor gegevensbeheer vereist controletoegang tot gegevens en biedt waarschuwingen en bewakingsmogelijkheden. Unity Catalog legt een auditlogboek vast van acties die worden uitgevoerd op de metastore en deze logboeken worden geleverd als onderdeel van Azure Databricks-auditlogboeken.

U hebt toegang tot de auditlogboeken van uw account met behulp van systeemtabellen. Zie Referentie voor systeemtabel auditlogboeken voor meer informatie over de tabel auditlogboeksysteem.

Zie Uw Databricks Data Intelligence-platform bewaken met auditlogboeken voor meer informatie over hoe u volledige inzicht krijgt in kritieke gebeurtenissen met betrekking tot uw Databricks Data Intelligence Platform.

Gegevens veilig delen met Delta Sharing

Delta Sharing is een open protocol dat door Databricks is ontwikkeld voor het veilig delen van gegevens met andere organisaties of andere afdelingen binnen uw organisatie, ongeacht de computerplatforms die ze gebruiken. Wanneer Delta Sharing is ingeschakeld in een metastore, voert Unity Catalog een Delta Sharing-server uit.

Als u gegevens tussen metastores wilt delen, kunt u Gebruikmaken van Databricks-to-Databricks Delta Sharing. Hiermee kunt u tabellen registreren bij metastores in verschillende regio's. Deze tabellen worden weergegeven als alleen-lezen objecten in de verbruikende metastore. Deze tabellen kunnen toegang krijgen zoals elk ander object in Unity Catalog.

Wanneer u Databricks-to-Databricks Delta Sharing gebruikt om te delen tussen metastores, moet u er rekening mee houden dat toegangsbeheer beperkt is tot één metastore. Als een beveiligbaar object, zoals een tabel, verleent en die resource wordt gedeeld met een metastore binnen het account, zijn de subsidies van de bron niet van toepassing op de doelshare. De doelshare moet zijn eigen subsidies instellen.

Meer informatie

• Unity Catalog instellen en beheren
• Gegevens en AI-assets veilig delen met Delta Sharing
• Tabellen en weergaven upgraden naar Unity Catalog