Több-bérlős konfiguráció kezelése Power BI Embedded-analitikávalManage multi-tenancy with Power BI embedded analytics

Több-bérlős SaaS-alkalmazás tervezése során körültekintően kell kiválasztani az SaaS-alkalmazás igényeinek leginkább megfelelő bérlői modellt.When designing a multi-tenant SaaS application, you must carefully choose the tenancy model that best fits the needs of your SaaS application. Ez az eljárás az SaaS-alkalmazás részeként, beágyazott analitikaként használt Power BI-ra is vonatkozik.This process is also valid for Power BI as an embedded analytics part of your SaaS application. A bérlői modell határozza meg, hogy az egyes bérlők adatai hogyan vannak leképezve és kezelve a Power BI-ban és a tárfiókban.A tenancy model determines how each tenant’s data is mapped and managed within Power BI and the storage account. A bérlői modell az alkalmazás tervezését és kezelését is érinti.Your tenancy model impacts application design and management. Más modellre később áttérni költséges lehet, és megzavarhatja a folyamatos használatot.Switching to a different model later may become costly and disruptive.

A Power BI Embedded használatával a bérlők elkülönítése két alapvető módszerrel tartható fenn.With Power BI Embedded, there are two main fundamental approaches to maintaining separation between tenants.

  1. Munkaterület-alapú elkülönítés – bérlőnként külön Power BI-munkaterület létrehozása.Workspace-based isolation - creating a separate Power BI Workspace per tenant.
  2. Elkülönítés sorszintű biztonság alapján – az adatokhoz való hozzáférés felhasználónkénti vagy csoportonkénti szabályozása és felügyelete a mögöttes adatok használatával.Row-level security-based isolation - where the underlying data is used to control and manage access to data per user or group.

Ez a cikk ismerteti és többféle kiértékelési szempont alapján elemzi a különböző módszereket.This article describes the different approaches and analyzes them according to several evaluation criteria.

Fogalmak és szakkifejezésekConcepts and terminology

AAD – Azure Active Directory.AAD - Azure Active Directory.

AAD-alkalmazás – Alkalmazás-identitás az AAD-ben.AAD application - An application identity in AAD. A hitelesítéshez AAD-alkalmazás szükséges.An AAD application is required for authentication.

SaaS-alkalmazás (szoftverszolgáltatás) – Nagyvállalat vagy független szoftverszállító által megvalósított rendszer, többnyire online szolgáltatás.SaaS application (software-as-a-service) - A system implemented by an enterprise or ISV that is usually an online service. Összefüggő szoftverek rendszere is lehet, amely több ügyfél-bérlőt (vállalatot) is kiszolgál.Its also related software systems for serving multiple customer tenants (organizations). Ebben a cikkben az SaaS-alkalmazás a Power BI Embedded használatával nyújt elemzéseket különböző bérlőinek.For this article, the SaaS application uses Power BI Embedded to serve analytics to its different tenants. A Power BI Embedded bármilyen típusú alkalmazáshoz használható, ha az rendelkezik online kapcsolattal.Power BI Embedded can also work for all types of applications when they have an online connection.

Bérlő – Egyetlen ügyfél (vállalat), amely az SaaS-alkalmazást használja, valamint minden olyan erőforrás és adat, amelyet az ügyfél beemel az SaaS-alkalmazásba.Tenant – A single customer (organization) that uses the SaaS application and any resources or data that the customer brings to the SaaS application.

Power BI – A Power BI a Power BI Embedded platformjaként szolgáló felhőszolgáltatás.Power BI - The Power BI cloud service that serves as a platform for Power BI Embedded.

Power BI-bérlő – Egyetlen AAD-bérlőhöz társított Power BI-erőforrások halmaza.Power BI tenant - Is a set of Power BI resources associated with a single AAD tenant.

Power BI-munkaterület – Tároló Power BI-beli tartalomhoz.Power BI workspace - A container for content in Power BI.

Power BI-összetevők – A Power BI-munkaterületeken több Power BI-összetevő, például irányítópult, jelentés, adathalmaz és adatfolyam is lehet.Power BI artifacts – There are several Power BI artifacts in Power BI workspaces such as dashboards, reports, datasets, and dataflows.

Power BI Embedded – Nyilvános API-k készlete, melyekkel a fejlesztők a Power BI-tartalmat kezelő és Power BI-elemeket beágyazó alkalmazásokat készíthetnek.Power BI Embedded - A set of public APIs that allow developers to build applications that manage Power BI content and embed Power BI elements.

Sorszintű biztonság (RLS) – Lehetővé teszi a felhasználók adatokhoz való hozzáférésének a tábla egyes soraira vonatkozó szabályozását.Row-level security (RLS) - Gives the ability to control user access to the data for individual rows in a table. Sorszintű biztonság megvalósítható az adatforrás szintjén, vagy a Power BI szemantikai modelljében.You can implement row-level security at the data source level or in the Power BI semantic model.

Fő felhasználó – Az SaaS-alkalmazást a Power BI-ban képviselő identitás, amelyet az SaaS-alkalmazás a Power BI API-k hívása során használ.Master user - The identity that represents the SaaS application in Power BI and that the SaaS application uses when calling Power BI APIs. Power BI Pro-licenccel rendelkező AAD-felhasználónak kell lennie.Needs to be an AAD user with a Power BI Pro license.

AAD-alkalmazás felhasználó (szolgáltatásnév) – Az SaaS-alkalmazást a Power BI-ban képviselő identitás, amelyet az SaaS-alkalmazás a Power BI API-k hívása során használ.AAD Application user (service principal) - The identity that represents the SaaS application in Power BI and that the SaaS application uses when calling Power BI APIs. AAD-webalkalmazásnak kell lennie.Needs to be an AAD web application. Helyettesítheti a felhasználót a Power BI-jal való hitelesítésnél.Can replace the use of a master user to authenticate with Power BI.

Kapacitás – A Power BI szolgáltatás futtatásához dedikált erőforrások halmaza.Capacity - A set of resources dedicated to running the Power BI service. A Power BI Premium-kapacitások a Power BI-t belsőleg használó nagyvállalatoknak, a Power BI Embedded-kapacitások pedig SaaS-alkalmazásokat külső felek számára készítő alkalmazásfejlesztőknek ajánlottak.Power BI Premium capacities Intended for enterprise companies using Power BI internally, while Power BI Embedded capacities intend for application developers to develop SaaS applications for third parties.

Power BI Pro-licenc – Felhasználói szintű licenc, amely jogot biztosít tartalom alkalmazás-munkaterületeken való közzétételére, prémium szintű kapacitás nélküli alkalmazások felhasználására, irányítópultok megosztására, valamint irányítópultokra és jelentésekre való feliratkozásra.Power BI Pro license - A user-based license, which grants rights to publish content to app workspaces, consume apps without Premium capacity, share dashboards, and subscribe to dashboards and reports.

Adatkapcsolati módok – Csatlakozás Power BI-beli adatforrásokhoz, amely többféle módon valósítható meg:Data connectivity modes - Connecting data sources to Power BI that can be done in different modes:

  • Importálás – az adatok elérésének leggyakoribb módja.Import - which is the most common way to get data.
  • DirectQuery – csatlakozás közvetlenül az adatokhoz azok forrás-adattárában.DirectQuery - connect directly to the data in its source repository.
  • Élő kapcsolat – egy másik mód, amely közvetlenül csatlakozik (Azure-beli és helyszíni) Analysis Services-adatokhoz.Live connection - another mode that connects directly to Analysis Services data (both Azure and on-premises).

Kiértékelési szempontokEvaluation criteria

Az SaaS-alkalmazásához leginkább megfelelő bérlői modell egyebek mellett függhet az adott üzleti és technikai követelményektől, és az adatok architektúrájától.The optimal choice for the right tenancy model for your SaaS application varies according to specific business and technical requirements, data architecture and more. Ezeknek a követelményeknek, valamint a bérlői modell rendelkezésre álló beállításinak és azok hasznosságának alapos megértése segíthet erőteljes, nagy teljesítményű, költséghatékony és méretezhető architektúrát kialakítani SaaS-alkalmazásához.Deep understanding of these requirements along with available tenancy model options and trade-offs can help define robust, performant, cost-effective, and scalable architecture for your SaaS application.

Az alábbiak olyan területek, amelyeket érdemes mérlegelni a különböző bérlői modellek közötti választás során.The following are a set of areas to consider when choosing between the different tenancy models.

AdatarchitektúraData architecture

A Power BI Embedded használatával alkalmazásokat készítő fejlesztők többnyire már rendelkeznek egy- vagy több-bérlős adatbázissal.Usually, developers building applications with Power BI Embedded already have a single or multi-tenant database. Egyszerűbb a Power BI Embedded egy olyan bérlői modelljét használni, amely hasonlít az adatbázis bérlői modelljéhez.It's easier to use a tenancy model for Power BI Embedded which is similar to the tenancy model of the database. Ha az adatbázis bérlői modellje még nincs definiálva, akkor az architektúráról meghozandó döntés során további szempontokat is érdemes figyelembe venni.If the database tenancy model hasn’t been defined yet, you may want to consider other aspects before deciding on your data architecture.

AdatelkülönítésData Isolation

Mennyire bizalmasak a tárolt adatok?How sensitive is the data being stored? Milyen szinten kell elkülöníteni a különböző ügyfelek bérlőit?What level of isolation do you need separating different customer tenants? A válasz más üzletágak és bizonyos követelményeket támasztó ügyfelek esetén eltérő lehet.The answer might vary across different industries or specific customers that have certain requirements.

MéretezhetőségScalability

A legjobb megoldás megkeresése érdekében meg kell határozni az előrelátható jövőben elérhető méretet.To find the best solution, define the scale you reach in the foreseeable future. Lényeges, hogy egy jelenleg megfelelő megoldás a használat és az adattömeg növekedése esetén már nem lesz elégséges.Remember that a solution that might be suitable now might not suffice when usage and data scale up. A méretezhetőség elemzése során az alábbi szempontokat érdemes figyelembe venni:When analyzing scalability, consider the following list:

  • A bérlők (ügyfelek) száma.Number of tenants (customers).
  • Az egyes bérlők jelentéseinek, irányítópultjainak és adathalmazainak mennyisége.Number of reports, dashboards, and datasets for each tenant.
  • Az egyes adathalmazokban lévő adatok mennyisége és a frissítések gyakorisága.Size of data on each dataset and frequency of refreshes.
  • A felhasználók száma.Number of users.
  • Az egyidejű felhasználók száma csúcsidőszakban.Number of concurrent users in peak times.

Egyes kevés felhasználós, keveset használt SaaS-alkalmazások nagy adattömegeket kezelhetnek.Some SaaS applications might have a low number of customers and low usage, but large amounts of data. Másokat sokan és gyakran használnak, de ügyfelenként csak kevés adattal és jelentéssel.Others might have many customers and high usage, but a small amount of data and reports for each customer. A magas értékek minden ilyen helyzetben kihatnak a jövőbeli költségekre és az üzemeltetés bonyolultságára.High numbers in any of these situations can impact future costs and operational complexity.

Automatizálás és az üzemeltetés bonyolultságaAutomation & operational complexity

Azonosítsa a rendszeresen ismétlődő folyamatokat, amelyek automatizálást igényelnek.Identify frequently occurring processes that need automation.

  • Milyen gyakran kerül sor új bérlők bevezetésére?What is the frequency of onboarding new tenants? Milyen műveletek szükségesek a teljes bevezetésükhöz?What actions are needed to fully onboard each one?
  • Milyen az üzembe helyezendő új vagy frissített Power BI-tartalom kiadási üteme?What is the release cadence for new or updated Power BI content, that needs to be deployed?
  • Hány sorszintű biztonsági szerepkör van definiálva az egyes bérlőkhöz?How many row-level security roles are defined for each tenant?

Ezeknek a folyamatoknak és azok kezelési módjának azonosítása hozzájárulhat az egyes modellek fenntartásával járó üzemeltetési bonyolultság megértéséhez.Identifying these processes and how you address them can help you understand the operational complexity involved in maintaining each model.

Az adatok tárolási helyére vonatkozó követelmények és több földrajzi hely támogatásának igényeData Residency Requirements and the need to support multiple geographies

A Power BI Embedded támogatja a több földrajzi helyen történő üzembe helyezést (előzetes funkció).Power BI Embedded supports multi-geo deployment (preview feature). Több földrajzi hely használatával a Power BI Embedded-erőforrások különböző régiókban helyezhetők üzembe úgy, hogy a meghatározott tartalmak meghatározott régiókban legyenek elhelyezve.Multi-Geo enables Power BI Embedded resources to be deployed in different regions with specific content assigned to reside in specific regions. Ez a funkció minden modellhez használható, de befolyásolhatja a kezelendő tartalom mennyiségét és a költséget.This feature can be used across all models, but can have an impact on the amount of content to manage and cost. A több földrajzi hely használata jelenleg az adatok elhelyezésére vonatkozó követelmények kielégítését szolgálja, és nem a teljesítménynek az adatok ügyfelekhez közelebbi elhelyezésével való javítását.Currently multi-geo is designed for meeting data residency requirements and doesn't improve performance by moving data closer to consumers.

CostCost

A Power BI Embedded erőforrás-alapú vásárlási modelje a Power BI Premiuméhoz hasonló.Power BI Embedded has a resource-based purchase model, like Power BI Premium. Egy vagy több, rögzített számítási teljesítménnyel és memóriával rendelkező kapacitás vásárolható meg.You purchase one or more capacities with fixed computing power and memory. A Power BI Embeddeddel végzett munka során ez a kapacitás a költség fő tétele.This capacity is the main cost item when working with Power BI Embedded. A kapacitást használó felhasználók száma nincs korlátozva.There's no limit on the number of users using the capacity. Az egyetlen korlát a kapacitás teljesítménye.The only limit is the performance of the capacity. Minden felhasználónak vagy olyan megadott felhasználónak, akinek el kell érnie a Power BI portált, Power BI Pro-licenccel kell rendelkeznie.A Power BI Pro license is required for each master user, or specific users that need to access the Power BI portal.

A kapacitás várható terhelését ajánlott élő környezet és használat szimulálásával, és a kapacitáson futtatott terheléstesztekkel tesztelni és mérni.We recommend testing and measuring the expected load on your capacity by simulating live environment and usage and run load testing on the capacity. A terhelés és a teljesítmény az Azure-kapacitás vagy a prémium szintű kapacitás metrika-alkalmazásában elérhető különböző metrikákkal mérhető.You can measure the load and performance with the various Metrics available in the Azure capacity or Premium capacity metrics app.

Tartalom testreszabása és szerzői műveletekContent customization and authoring

Az SaaS-alkalmazások két módon kínálnak lehetőséget a felhasználóknak jelentések szerkesztésére és létrehozására, valamint adatoknak a folyamat részeként a szolgáltatásba való feltöltésére:There are two approaches to SaaS applications that give users the ability to edit and create reports or upload data into the service as part of the flow:

  • Szerkesztés/Létrehozás mód beágyazott iFrame-ben – A felhasználó az SaaS-alkalmazáson belül tekintheti meg a jelentést, vagy egy üres vásznat.Edit/Create mode in an embedded iFrame - The user gets a view of the report or a new blank canvas inside the SaaS application. Így a Power BI-eszköztár használatával hozhat létre tartalmat egy a munkaterületen lévő adathalmaz alapján.This way they can use the Power BI toolbar to create content based on a dataset in the workspace. Ez az ajánlott megoldás, hiszen ez a felhasználó számára ismerős környezet.We recommend this option since it’s in the user’s context in a familiar environment. Könnyebb megkezdeni a munkát és a szerkesztést, a felhasználó pedig egy meglévő adathalmazhoz társított jelentést hoz létre.It’s easier to get started working and editing, and the user creates a report attached to an existing dataset.

  • Tartalom létrehozása a Power BI Desktop használatával, majd feltöltése a munkaterületre az SaaS-alkalmazás felhasználói felületén keresztül.Use Power BI Desktop to create content and upload it through the SaaS application UI to the workspace. Ezen a módon a Power BI Desktopot használó felhasználók több eszközzel dolgozhatnak.In this approach, users have more tools to work with using the Power BI Desktop. Ez a módszer mégsem ajánlott, ugyanis a felhasználóknak az SaaS-alkalmazáson kívüli, újabb eszközzel is meg kell ismerkedniük.However, we do not recommend this approach since users need to be familiar with an additional tool outside of the SaaS application context. PBIX-fájl feltöltésével a felhasználó újabb adathalmazt ad a munkaterülethez, amely egy már meglévő duplikálása is lehet.Uploading a PBIX file means the user is adding an additional dataset, that might be a duplicate of datasets already in the workspace.

Elkülönítés Power BI-munkaterületek alapjánPower BI workspace-based isolation

A Power BI-munkaterületeken alapuló elkülönítéssel az SaaS-alkalmazás több bérlőt támogat egyetlen Power BI-bérlőből.With Power BI workspace-based isolation, the SaaS application supports multiple tenants from a single Power BI tenant. A munkaterület-alapú elkülönítés a különböző bérlők által használt összes Power BI-tartalmat magában foglalja.Workspace-based isolation contains all the Power BI content that different tenants use. A bérlők elkülönítése a Power BI-munkaterületek szintjén, külön munkaterületek létrehozásával valósul meg.The separation of tenants is done at the Power BI workspace level, by creating multiple workspaces. Minden munkaterület tartalmazza az adott bérlőhöz tartozó adathalmazokat, jelentéseket és irányítópultokat.Each workspace contains the relevant datasets, reports, and dashboards for that tenant. Az egyes munkaterületek csak az adott bérlő adataihoz csatlakoznak.Also, each workspace is connected only to that tenant’s data. További elkülönítés igénye esetén minden munkaterülethez és annak tartalmához létrehozhat egy felhasználót vagy szolgáltatásnevet.If you need additional isolation, you can create a master user or a service principal for each workspace and its content.

Munkaterület

AdatarchitektúraData architecture

A bérlők adatainak felügyeletére két fő módszer használatos.There are two main approaches to manage tenant’s data.

  • Bérlőnként külön adatbázisA separate database per tenant
  • Egyetlen több-bérlős adatbázisA single multi-tenant database

Ha az SaaS-alkalmazás tárolója bérlőnként külön adatbázist tart fenn, akkor magától értetődő választás a Power BI-ban egybérlős adathalmazokat használni, ahol az egyes adathalmazok kapcsolati sztringje mutat a megfelelő adatbázisra.If the SaaS application storage is keeping a separate database per tenant, then the natural choice is to use single-tenant datasets in Power BI with the connection string for each dataset pointing to the matching database.

Amennyiben az SaaS-alkalmazás tárolója minden bérlőhöz egy több-bérlős adatbázist használ, akkor a bérlők könnyen elkülöníthetők munkaterületek szerint.If the SaaS application storage is using a multi-tenancy database for all tenants, it’s easy to separate tenants by workspace. A Power BI-adathalmaz adatbázis-kapcsolata paraméteres adatbázis-lekérdezéssel konfigurálható, amely csak a megfelelő bérlő adatait adja vissza.You can configure the database connection for the Power BI dataset with a parameterized database query that only retrieves the relevant tenant’s data. A kapcsolati sztring a Power BI Desktoppal, vagy az API-val frissíthető, a lekérdezés paramétereivel.You can update the connection using the Power BI Desktop or using the API with parameters on the query.

AdatelkülönítésData isolation

Ebben a bérlői modellben az adatok a munkaterületek szintjén vannak elkülönítve.Data in this tenancy model is separated at the workspace level. A munkaterületek és bérlők közötti egyszerű leképezés akadályozza meg, hogy a felhasználók egy másik bérlőtől származó tartalmat lássanak.A simple mapping between a workspace and a tenant prevents users from one tenant seeing content from another tenant. Egyetlen felhasználó használatakor követelmény, hogy az összes munkaterülethez hozzáférjen.Using a single master user demands you to have access to all the different workspaces. A végfelhasználók számára megjelenítendő adatok köre a beágyazási token generálása során van meghatározva. A felhasználók ezt a háttérbeli folyamatot nem látják, és nem módosíthatják.The configuration of which data to show an end user is defined during the generation of the embed token, a backend-only process which end users can’t see, or change.

További elkülönítés érhető el, ha az alkalmazásfejlesztő több munkaterülethez hozzáférő egyetlen felhasználó vagy alkalmazás helyett munkaterületenként ad meg felhasználót vagy alkalmazást.To add additional isolation, an application developer can define a master user or an application per workspace rather than a single master user or application with access to multiple workspaces. Így biztosítható, hogy egy emberi mulasztás vagy a hitelesítő adatok nyilvánosságra kerülése ne tegye sebezhetővé egyszerre több ügyfél adatait.This way, you can ensure that any human error or credential leak does not cause multiple customers' data to be exposed.

MéretezhetőségScalability

Ennek a modellnek az egyik előnye az, hogy az adatok bérlőnkénti adathalmazokra való felosztása enyhíti az egy adathalmaz méretére vonatkozó korlátozást (jelenleg 10 GB egy kapacitásban).One advantage of this model is that separating the data into multiple datasets for each tenant overcomes the size limits of a single dataset (currently 10 GB in a capacity). Ha a kapacitás betelik, kizárhatja a nem használt adathalmazokat, hogy memóriát szabadítson fel az aktív adathalmazok számára.When the capacity is overloaded, it can evict unused datasets to free memory for active datasets. Ez egyetlen nagy adathalmazzal nem oldható meg.This task isn't possible with a single large dataset. Több adathalmaz használata mellett a bérlők szükség esetén több Power BI-kapacitásba is elkülöníthetők.Using multiple datasets, it is also possible to separate tenants into multiple Power BI capacities if needed.

Mindezen előnyök ellenére érdemes átgondolni, hogy milyen méretet érhet el az SaaS-alkalmazás a jövőben.Despite these advantages, one must consider the scale that the SaaS application can reach in the future. Megtörténhet például, hogy a kezelhető összetevők száma ér el egy korlátot.For example, one might reach limitations around the number of artifacts one can manage. Erről a cikk üzembe helyezési korlátozásokról szóló szakaszában talál további részleteket.See deployment limitations later in this article for more details. A használt kapacitás-SKU korlátozza be az egyes adathalmazok számára elérhető memória mennyiségét, az egyidejűleg futtatható frissítések számát, és az adatfrissítések gyakoriságát.The capacity SKU used introduces a limit on the size of memory that datasets need to fit in, how many refreshes can run at the same time and the maximum frequency of data refreshes. Több száz, vagy több ezer adathalmaz felügyelete estén ezt ajánlatos tesztelni.It's recommended to test when managing hundreds or thousands of datasets. Ajánlott még figyelembe venni a használat átlagos mértékét és csúcsértékét, valamint a nagy adathalmazokat vagy eltérő használati mintákat használó, a többi bérlőtől eltérő módon kezelt bérlőket is.It is also recommended to consider the average and peak volume of usage, as well as any specific tenants with large datasets, or different usage patterns, that are managed differently than other tenants.

Automatizálás és az üzemeltetés bonyolultságaAutomation & operational complexity

Power BI-munkaterület alapján történő elkülönítés esetén az alkalmazásfejlesztőnek esetleg összetevők százait vagy ezreit kell kezelnie.With Power BI workspace-based isolation, an application developer might need to manage hundreds or thousands of artifacts. Az alkalmazás-életciklus kezelésben fontos meghatározni a rendszeresen lezajló folyamatokat, és gondoskodni a megfelelő eszközökről, amelyekkel ezek a műveletek tömegesen elvégezhetők a bérlői modellben.It’s essential to define the processes that frequently happen in your application lifecycle management, and ensure you have the right set of tools to perform these operations at scale in this tenancy model. Néhány példa ilyen műveletekre:Some example operations include:

  • Új bérlő (ügyfél) felvételeAdding a new tenant (customer)
  • Jelentés vagy irányítópult frissítése egy bérlő, vagy az összes számáraUpdating a report or dashboard for some or all the tenants
  • Az adathalmaz-séma frissítése egy bérlő, vagy az összes számáraUpdating the dataset schema for some or all the tenants
  • Előre nem tervezett testreszabások adott bérlők számáraUnplanned customizations for specific tenants
  • Az adathalmaz-frissítések gyakoriságaFrequency of dataset refreshes

Munkaterület létrehozása új bérlő számára például gyakori feladat, amelyet automatizálni kell.For example, creating a workspace for a new tenant is a common task, which needs automation. A Power BI REST API-val elérhető a munkaterületek létrehozásának teljes automatizálása.With the Power BI REST API, you can achieve full automation when creating workspaces.

Több földrajzi helyre vonatkozó igényekMulti-Geo needs

Több földrajzi hely használatához sok egyéb mellett gondoskodni kell kapacitás vásárlásáról a kívánt régiókban, valamint egy munkaterület hozzárendeléséről ehhez a kapacitáshoz.Multi-geo involves purchasing capacity in the desired regions and assigning a workspace to that capacity. Ha különböző régiókban kell különböző bérlőket támogatni, akkor a bérlők munkaterületét a kívánt régióban lévő kapacitáshoz kell rendelni.If you need to support different tenants in different regions, you need to assign the tenant’s workspace to a capacity in the desired region. Ez egy egyszerű művelet, amely nem jár magasabb költséggel, mint ha minden munkaterület ugyanabban a kapacitásban volna.This task is a simple operation and one where the cost is not more than having all workspaces in the same capacity. Olyan bérlők esetén azonban, akiknek több régióban elhelyezkedő adatokra van szükségük, a munkaterület valamennyi összetevőjét duplikálni kell minden regionális kapacitásban, ezáltal pedig a költség magasabbá, a felügyelet pedig bonyolultabbá válik.However, if you have tenants that need data resident in multiple regions, all artifacts in the workspace need to be duplicated in each regional capacity, increasing both cost and management complexity.

CostCost

A Power BI Embeddedet használó alkalmazásfejlesztőknek az éles üzemeltetéshez Power BI Embedded-kapacitást kell vásárolniuk.Application developers using Power BI Embedded need to purchase Power BI Embedded capacity to go to production. Fontos tisztában lenni a munkaterületen alapuló elkülönítési modell következményeivel és a kapacitásokra gyakorolt hatásával.It’s important to understand the impact of workspace-based isolation model and their effect on capacities.

A munkaterület-alapú elkülönítési modell az alábbi okokból felel meg a kapacitásoknak:The workspace-based isolation model sits well with capacities for the following reasons:

  • A munkaterület a kapacitáshoz függetlenül hozzárendelhető legkisebb objektum (jelentést például nem lehet hozzárendelni), így a bérlők munkaterületek alapján történő elkülönítésével az egyes bérlők, és azok teljesítménnyel kapcsolatos igényei teljesen rugalmasan kezelhetők, a kapacitás kihasználtsága pedig fel- és leméretezéssel optimalizálható.The smallest object you can independently assign to a capacity is a workspace that is, you can’t assign a report, for example), so by separating tenants by workspaces, you get full flexibility in managing each tenant and its performance needs, and optimizing capacity utilization by scaling up/down. Így például a kiemelt fontosságú bérlők, ameyek nagy és változó teljesítményt kívánnak, a szolgáltatás állandó színvonala érdekében külön kapacitásban kezelhetők, míg a kisebb bérlők költségkímélés céljából egy másik kapacitásban csoportosíthatók.For example, large and essential tenants with high volume and volatility can be managed in a separate capacity to ensure a consistent service level, while grouping smaller tenants in another capacity to optimize costs.

  • A munkaterületek elkülönítésével együtt jár az adathalmazok bérlők közötti elkülönítése is, így az adatmodellek kisebb darabok lehetnek egyetlen nagy adathalmaz helyett.Separating workspaces also means separating datasets between tenants so that data models can be in smaller chunks, rather than in a single large dataset. Ezen a módon a kapacitás jobban kezeli a memóriahasználatot, kizárva a kicsi, nem használt adathalmazokat, ha azokra nincs szükség, ugyanakkor kielégítő teljesítményt nyújtva az ügyfeleknek.This task allows the capacity to manage memory usage better, evicting small, and unused datasets when not needed, while keeping users satisfied with the performance.

Az alkalmazásfejlesztőknek számolniuk kell a párhuzamos frissítések számára vonatkozó korlátozással, a frissítési folyamatok ugyanis több adathalmaz esetén külön kapacitást igényelhetnek.Application developers need to consider the limit on the number of parallel refreshes, as refresh processes might need extra capacity when you have multiple datasets.

Tartalom testreszabása és szerzői műveletekContent customization and authoring

A tartalomkészítés fő használati eseteiben az alkalmazásfejlesztőnek gondosan kell mérlegelnie, hogy mely bérlők rendelkezhetnek szerkesztési lehetőséggel, és hogy az egyes bérlőkben hány felhasználó végezhet szerkesztést.For the primary use cases of content creation, the application developer needs to carefully consider which tenants can have editing capabilities, and how many users in each tenant can edit. Egy bérlőn belül több felhasználó feljogosítása sok tartalom létrehozását, ezáltal pedig olyan adathalmaz-korlátok túllépését eredményezheti, mint az adathalmazonkénti jelentések, vagy a munkaterületenkénti adathalmazok számára vonatkozók.Permitting multiple users in each tenant to edit can result in many contents being generated, that can reach a dataset limitation such as the number of reports per dataset, or the number of datasets in a workspace. Amennyiben a felhasználók erre lehetőséget kapnak, ajánlott figyelemmel kísérni a tartalom keletkezését, és szükség esetén felméretezést végrehajtani.If you give users this capability, we recommend monitoring the content generation closely and scale up as needed. Ugyanezen okból nem ajánlott ezt a képességet tartalom személyre szabására használni, ilyenkor ugyanis minden felhasználó kisebb módosításokat végezhet egy jelentésen, amelyet aztán menthet magának.For the same reasons, we don’t recommend using this capability for content personalization, where each user can make small changes to a report and save it for themselves. Ha az SaaS-alkalmazás engedélyezi a tartalom személyre szabását, megfontolandó a munkaterület felhasználóspecifikus tartalmakra vonatkozó adatmegőrzési szabályzatának bevezetése és kihirdetése, amely végrehajtja a tartalom törlését, ha a végfelhasználók új beosztást kapnak, távoznak a vállalattól, vagy már nem használják a platformot.If the SaaS application allows content personalization, consider introducing and communicating workspace retention policies for user-specific content to facilitate the flow of content deletion when end users move to a new position, leaving the company or not using the platform anymore.

Elkülönítés sorszintű biztonság alapjánRow-level security-based isolation

Sorszintű biztonság alapján történő elkülönítés esetén az SaaS-alkalmazás egyetlen munkaterületet használ több bérlő kiszolgálására.With row-level security-based isolation, the SaaS application uses a single workspace to host multiple tenants. Ez azt jelenti, hogy minden Power BI-összetevő (jelentés, irányítópult és adathalmaz) egyszer van létrehozva, és minden bérlő azt használja.It means each Power BI artifact report, dashboard, & dataset, is created once all tenants use it. A bérlők közötti adatelkülönítés sorszintű biztonság használatával valósul meg a több-bérlős adathalmazban.Data separation between tenants is accomplished using row-level security on the multi-tenant dataset. Amikor egy végfelhasználó bejelentkezik az SaaS-alkalmazásba és megnyit egy tartalmat, létrejön egy beágyazási token a felhasználói munkamenethez olyan szerepkörökkel és szűrőkkel, amelyek biztosítják, hogy a felhasználó csak olyan adatokat lásson, amelyekhez jogosultsággal rendelkezik.When end users log into the SaaS application and open content, an Embed token is generated for that user’s session, with the roles and filters that ensure the user only sees the data they are permitted to see. Ha egy bérlőn belül a felhasználók nem ugyanazoknak az adatoknak a megtekintésére jogosultak, akkor az alkalmazásfejlesztőnek hierarchikus szerepköröket kell kialakítania a bérlők között, és egy bérlőn belül is.If users from the same tenant are not permitted to view the same data, the application developer needs to implement hierarchical roles both between tenants and within the same tenant.

Sorszintű biztonság

AdatarchitektúraData architecture

A sorszintű biztonságon alapuló elkülönítés a legegyszerűbben akkor valósítható meg, ha minden bérlő adatai egyetlen adattárházban vannak tárolva.Implementing row-level security-based isolation is most comfortable when all tenants’ data is stored in a single data warehouse. Ilyen esetben az alkalmazásfejlesztő csak a megfelelő adatokat adja át a Power BI-adathalmazba, akár DirectQuery, akár adatimportálás használatával.In this case, the application developer can pass only the relevant data from the data warehouse into the Power BI dataset, either via Direct Query or data import. Ha az adatbázisban az adatok bérlőnként el vannak különítve, akkor egyetlen adathalmazzá kell kombinálni őket, ez pedig alacsonyabb szintű elkülönítést eredményez a bérlők között, mint az adatbázisban meglévő.If data in the database is separated per tenant, it needs to be combined into a single dataset, which results in a lower degree of separation between tenants that existed in the database.

AdatelkülönítésData isolation

Sorszintű biztonságon alapuló elkülönítés esetén az adatelkülönítés sorszintű biztonsági definíciók használatával valósul meg az adathalmazban, tehát minden adat egyszerre lehet jelen.With row-level security-based isolation, data separation is accomplished using row-level security definitions on the dataset, which means all the data coexist. Az adatelkülönítésnek ennél a formájánál nagyobb a fejlesztői hibából következő adatszivárgás kockázata.This form of data separation is more susceptible to data leakage through developer error. Bár a sorszintű biztonság a háttérben, a végfelhasználótól elzárva működik, szigorúan bizalmas adatok esetén, vagy ha az ügyfelek kérik az adatok elkülönítését, érdemesebb lehet munkaterület-alapú elkülönítést használni.Even though row-level security is done on the backend and secured from an end user, if the data is highly sensitive or customers are asking for data separation, it might be better to use workspace-based isolation.

MéretezhetőségScalability

Sorszintű biztonságon alapuló elkülönítés használatakor az adatoknak el kell férniük az adathalmaz méretkorlátján belül, amely jelenleg 10 GB.With row-level security-based isolation, the data needs to fit within the dataset size limit, which is currently 10 GB. A növekményes frissítés bevezetésével, és egy Power BI-adathalmazokhoz készülő XMLA-végpont közeljövőbeli megjelenésével várható, hogy az adathalmaz méretkorlátja jelentősen emelkedni fog.With the introduction of incremental refresh and the upcoming release of an XMLA endpoint for Power BI datasets, the dataset size limit is expected to increase significantly. Az adatoknak azonban továbbra is el kell férniük a kapacitás memóriájában úgy, hogy elég memória maradjon az adatfrissítések futásához.However, the data still needs to fit into the capacity’s memory, with enough remaining memory for data refreshes to run. A nagyméretű üzembe helyezett példányok nagy kapacitást igényelnek, hogy a felhasználók ne tapasztaljanak problémákat a jelenlegi kapacitás korlátait túllépő memóriahasználat miatt.Large-scale deployments need a large capacity to avoid users experiencing issues due to memory exceeding the limits of the current capacity. A méretezés kezelésének további módja az összesítések használata, vagy az adatforráshoz való közvetlen csatlakozás DirectQuery vagy élő kapcsolat használatával ahelyett, hogy minden adat a Power BI-kapacitásban van gyorsítótárazva.Alternative ways to handle scale include using aggregations or connecting to the data source directly using DirectQuery or Live connection, rather than caching all the data in the Power BI capacity.

Automatizálás és az üzemeltetés bonyolultságaAutomation & operational complexity

Az összetevők sokkal kényelmesebben kezelhetők sorszintű biztonságon alapuló, mint munkaterület-alapú elkülönítéssel, hiszen ilyenkor minden környezetben (fejlesztői/teszt/éles) csak az összetevők egy változata van jelen, nem pedig bérlőnként egy változat.Managing artifacts is far more comfortable using row-level security-based isolation than with workspace-based isolation as there is only one version of an artifact for each environment (dev/test/production), instead of a version per tenant. Nagy méreteknél az összetevőkezelés néhányszor tíz összetevő frissítését és kezelését jelenti több ezer vagy több tízezer helyett.At a large scale, managing artifacts means managing and updating tens of artifacts, rather than thousands to ten-thousands.

A Power BI egyelőre nem rendelkezik sorszintű biztonsági szerepkörök és szabályok kezelésére szolgáló API-val.Power BI doesn’t yet have an API to modify or create RLS roles and rules. Szerepkörök csak manuálisan vehetők fel és módosíthatók a Power BI Desktopban.Adding or changing roles can only be done manually in the Power BI Desktop. Ha sorszintű biztonsági hierarchiát kell alkalmazni, annak kezelése nem kellően gondos tervezés esetén bonyolult lehet, és sok hibalehetőséggel jár.If an RLS hierarchy needs to be applied, it can be complicated and error-prone to manage if you don't plan it carefully.

Ha az alkalmazásfejlesztőnek sok olyan szerepkört és szerepkör-definíciót kell kezelnie, amelyeket gyakran kell létrehozni vagy frissíteni, a sorszintű biztonságon alapuló elkülönítés a kezelhetőség szempontjából nem lesz méretezhető.If the application developer needs to manage many roles and role definitions that need to be created or updated frequently, row-level security-based isolation isn't scalable, from a manageability perspective.

Az üzemeltetést tovább bonyolítja az a követelmény, hogy a memóriahasználatot gondosan figyelni kell, és erőteljes riasztási és méretezési rendszer kiépítésével kell biztosítani az akadálytalan működést.Another operational complexity is the need to closely monitor memory utilization and build a robust mechanism of alerts and scaling to ensure users get a smooth experience.

Több földrajzi helyre vonatkozó igényekMulti-Geo needs

Mivel minden adat egyetlen adathalmazban van tárolva, nehéz lehet eleget tenni az adatok elhelyezésére vonatkozó olyan követelményeknek, amelyek bizonyos adatok adott helyen való tárolását írják elő.Since all the data is stored in a single dataset, it is challenging to meet data residency requirements that require certain data to be bound to specific locations. Jelentősen megemelkedhet a több régió használatával járó költség is, hiszen minden adat minden régióban replikálva és tárolva lesz.It can also significantly increase the cost of using multiple regions as all the data is replicated and stored in each region. Ha csak néhány bérlő igényel más földrajzi helyet, akkor elég ezek adatait külön régióban tárolni, a fent ismertetett munkaterület-alapú elkülönítési modell használatával.If only a limited number of tenants need different geographies, you can keep only those tenants’ data in a different region, using the workspace-based isolation model described above.

CostCost

A sorszintű biztonságon alapuló elkülönítéssel járó költség fő tényezője az adathalmaz memóriaigénye.The primary cost driver with row-level security-based isolation is the memory footprint of the dataset. A kapacitásnak elégnek kell lennie az adathalmaz befogadására és némi tartalék fenntartására az esetleg hirtelen megnövekedő memóriaigény ellátására.You need enough capacity to store the dataset and keep some additional memory buffer for any peaks in memory demand. Ez a helyzet enyhíthető például azzal, hogy az adatok SQL Server-adatbázisban, vagy SQL Server Analysis Services-kockában vannak tárolva, az adatok pedig valós időben, DirectQuery vagy élő kapcsolat használatával vannak lekérve az adatforrásból.One way to mitigate this situation is to store the data in a SQL Server database or SQL Server Analysis Services cube and using Direct Query or a Live connection to retrieve the data from the data source in real time. Ez a módszer növeli az adatforrások költségét, de a memóriaigény miatt nem igényel olyan nagy kapacitást, ezáltal csökkenti a Power BI-kapacitás költségét.This approach increases the cost of the data sources, but reduces the need for large capacity because of memory needs, hence reducing the cost of Power BI capacity.

Tartalom testreszabása és szerzői műveletekContent customization and authoring

A jelentéseket szerkesztő vagy létrehozó végfelhasználók az éles, több-bérlős adathalmazt használhatják.As end users edit or create reports, they can use the production multi-tenant dataset. Emiatt a jelentések létrehozásához vagy szerkesztéséhez ajánlott csak a beágyazott iFrame-et használni, az ugyanis ugyanazt az adathalmazt használja sorszintű biztonság alkalmazásával.For that reason, we advise only using the embedded iFrame option to edit or create reports, as it relies on the same dataset, with row-level security applied. Ha a felhasználóknak PBIX-fájlokat kell feltölteniük újabb adathalmazokkal, az a sorszintű biztonságra alapuló elkülönítés mellett költséges és nehezen kezelhető lehet.Having users uploading PBIX files with additional datasets can be costly and difficult to manage with row-level security-based isolation. Ha pedig a felhasználók egyazon munkaterületen generálnak új tartalmat, gondoskodni kell arról, hogy az éles munkaterület ne érje el a korlátokat, és hatékony rendszert kell kiépíteni, amely megállapítja, hogy melyik tartalom melyik bérlőhöz kapcsolódik.Also, when users generate new content that is in the same workspace, you need to make sure the production workspace doesn't hit its limits and build a robust mechanism to distinguish which content is connected to which tenant.

A különböző módszerek összefoglaló összehasonlításaSummary comparison of the different approaches

Fontos

Az alábbi elemzés alapja a termék jelenlegi állapota.The following analysis is based on the current state of the product. Miközben havonta bocsátunk ki újabb frissítéseket, folyamatosan kínálunk a meglévő kötöttségeket és gyengeségeket orvosló új képességeket és funkciókat.As we are releasing new features on a monthly cadence, we continue to provide new capabilities and features that answer existing limitations and weak spots. Érdemes elolvasni havi blogbejegyzésünket, megismerni az újdonságokat, majd ehhez a cikkhez visszatérve megtudni, hogyan módosítják az új funkciók a bérlői modellre vonatkozó ajánlásokat.Make sure to check our monthly blog posts to see what’s new and come back to this article to see how new features affect the tenancy model recommendation.

Kiértékelési szempontokEvaluation Criteria Munkaterület-alapúWorkspace-based Sorszintű biztonság-alapúRow-level security-based
AdatarchitektúraData architecture Akkor a legegyszerűbb, ha minden bérlőhöz külön adatbázis tartozikEasiest when there's a separate database per tenant Akkor a legegyszerűbb, ha minden bérlő összes adata egyetlen adattárházban van elhelyezveEasiest when all the data for all tenants are in a single data warehouse
AdatelkülönítésData isolation Jó.Good. Minden bérlő dedikált adathalmazzal rendelkezik.Each tenant has a dedicated dataset. Közepes.Moderate. Minden adat ugyanabban a megosztott adathalmazban helyezkedik el, fe hozzáférés-vezérlésen keresztül van kezelve.All data is in the same shared dataset but managed through access-control.
MéretezhetőségScalability Közepes.Medium. Az adattömeg több adathalmazra bontása lehetővé teszi az optimalizálást.Breaking the data into multiple datasets enables optimization. A legrosszabb.Lowest. Behatárolják az adathalmazra vonatkozó korlátozások.Constrained by dataset limits.
Több földrajzi helyre vonatkozó igényekMulti-Geo needs Jó választás, ha a bérlők többsége egy régión belül található.Good fit when most tenants are only in one region. Nem ajánlott.Not recommended. Az egész adathalmazt több régióban is tárolni kell hozzá.Needs to keep the entire dataset stored in multiple regions.
Automatizálás és az üzemeltetés bonyolultságaAutomation & operational complexity Jól automatizálható az egyes bérlők számára.Good automation for the individual tenant. Sok összetevő nagybani kezelése bonyolult feladat.Complex to manage many artifacts at scale. Egyszerűen kezelhető Power BI-összetevők, de nagy méretekben nehezen kezelhető sorszintű biztonság.Easy to manage Power BI artifacts but complex to manage RLS at scale.
CostCost Gyenge közepes.Low-medium. A kihasználtság a bérlőnkénti költség csökkentésére optimalizálható.Can optimize utilization to reduce cost-per-tenant. Növekedhet, ha rendszeres frissítésekre van szükség.Might increase when frequent refreshes are needed. Erős közepes Importálás mód használata esetén.Medium- high if using Import mode. Gyenge közepes DirectQuery mód használata esetén.Low- medium if using Direct Query mode.
Tartalom testreszabása és szerzői műveletekContent customization and authoring Jól megfelel.Good fit. Nagy méretek esetén korlátokba ütközhet.Might hit limitations at large scale. Tartalomgenerálás csak beágyazott iFrame-kerettelContent generation in embedded iFrame only

Üzembe helyezési szempontok és korlátozásokDeployment considerations and limitations

Power BI-összetevőkre vonatkozó korlátozások:Power BI Artifact limits:

  • A V1 munkaterületek (csoportok) száma, amelynek egy felhasználó/alkalmazás tagja/rendszergazdája lehet 250.The number of workspaces V1 (groups) that a single user/application can be a member/admin of is 250.
  • A V2 munkaterületek (mappák) száma, amelynek egy felhasználó/alkalmazás tagja/rendszergazdája lehet 1000.The number of workspaces V2 (folders) that a single user/application can be a member/admin of is 1000.
  • Az adathalmazok száma egy munkaterületen 1000.The number of datasets in a single workspace is 1000.
  • Az egy adathalmazhoz csatlakozó jelentések/irányítópultok száma 1000.The number of reports/dashboards connected to a single dataset is 1000.
  • Az adathalmaz .pbix fájl feltöltésére vonatkozó memória-korlátja 10 GB.The dataset memory size limit to upload a .pbix file is 10 GB.

Power BI-kapacitásokra vonatkozó szempontok és korlátozások:Power BI Capacity considerations and limitations:

  • Minden kapacitás csak az ahhoz lefoglalt memóriát és virtuális magokat használhatja, a megvásárolt SKU-nak megfelelően.Each capacity can only use its allocated memory and V-cores, according to the SKU purchased.
  • Az egyes SKU-khoz javasolt adatbázismérettel kapcsolatban a prémium szintű nagy adathalmazokról szóló cikk nyújt útmutatást.For the recommended dataset size for each SKU, reference Premium large datasets.
  • Dedikált kapacitásban a maximális adathalmaz-méret 10 GB.The max dataset size in a dedicated capacity is 10 GB.
  • Importálás módú adathalmaz ütemezett frissítéseinek számra naponta 48.The number of scheduled refreshes for an import mode dataset in a day is 48.
  • Importálás módú adathalmaz ütemezett frissítéseinek időköze 30 perc.The time between scheduled refreshes for an import mode dataset is 30 minutes.
  • Az egy kapacitásban egyidejűleg futtatható frissítések számáról az erőforrás-kezelést és optimalizálást ismertető cikk nyújt tájékoztatást.For the number of refreshes that can run concurrently on a capacity, reference resource management and optimization.
  • Egy kapacitás méretezésének átlagos időtartama 1-2 perc.The average time of scaling a capacity is between 1-2 minutes. Ezalatt a kapacitás nem érhető el.During that time, the capacity isn't available. A kimaradás elkerülése érdekében ajánlott horizontális felméretezést alkalmazni.We recommend using a scale-out approach to avoid downtime.

Következő lépésekNext steps