Používanie agregácií v aplikácii Power BI DesktopUse aggregations in Power BI Desktop

Agregácie v službe Power BI vám umožnia zmenšiť veľkosť tabuľky tak, aby ste sa mohli sústrediť na dôležité údaje a zlepšiť výkon dotazov.Aggregations in Power BI let you reduce table sizes so you can focus on important data and improve query performance. Agregácie umožňujú interaktívnu analýzu veľkého množstva údajov spôsobom, ktorý nie je možné vykonať inak. Môžu tak výrazne znížiť náklady na sprístupnenie veľkých množín údajov pri prijímaní rozhodnutí.Aggregations enable interactive analysis over big data in ways that aren't possible otherwise, and can dramatically reduce the cost of unlocking large datasets for decision making.

Medzi niektoré výhody používania agregácií patria:Some advantages of using aggregations include:

  • Lepší výkon dotazov pri veľkom objeme údajov.Better query performance over big data. Pri každej interakcii s vizuálmi služby Power BI sa do množiny údajov odošlú dotazy jazyka DAX.Every interaction with Power BI visuals submits DAX queries to the dataset. Agregované údaje vo vyrovnávacej pamäti používajú zlomok zdrojov, ktoré sú potrebné pre podrobné údaje, takže môžete sprístupniť veľký objem údajov, ktorý by bol inak nedostupný.Cached aggregated data uses a fraction of the resources required for detail data, so you can unlock big data that would otherwise be inaccessible.
  • Optimalizované obnovenie údajov.Optimized data refresh. Menšie veľkosti vyrovnávacej pamäte skracujú čas obnovenia, takže údaje sa k používateľom dostanú rýchlejšie.Smaller cache sizes reduce refresh times, so data gets to users faster.
  • Vyvážená architektúra.Balanced architectures. Vyrovnávacia pamäť v pamäti služby Power BI dokáže spracovať agregované dotazy, čím obmedzuje počet dotazov odoslaných v režime DirectQuery a pomáha dodržiavať limity súbežnosti.The Power BI in-memory cache can handle aggregated queries, limiting queries sent in DirectQuery mode and helping you meet concurrency limits. Zostávajúce dotazy na úrovni podrobností sú zvyčajne filtrované dotazy na úrovni transakcií, ktoré sklady údajov a systémy na veľké objemy údajov zvyčajne zvládajú dobre.The remaining detail-level queries tend to be filtered, transactional-level queries, which data warehouses and big-data systems normally handle well.

Agregácie v aplikácii Microsoft Power BI Desktop

Dimenzionálne zdroje údajov, ako napríklad sklady údajov a trhy údajov, môžu využívať agregácie založené na vzťahoch.Dimensional data sources, like data warehouses and data marts, can use relationship-based aggregations. Zdroje veľkých objemov údajov založené na serveri Hadoop majú často založené agregácie na stĺpcoch GroupBy.Hadoop-based big-data sources often base aggregations on GroupBy columns. V tomto článku sa popisujú typické rozdiely v modelovaní v službe Power BI pre jednotlivé typy zdrojov údajov.This article describes typical Power BI modeling differences for each type of data source.

Vytvorenie agregovanej tabuľkyCreate an aggregated table

Vytvorenie agregovanej tabuľky:To create an aggregated table:

  1. Nastavte novú tabuľku s požadovanými poľami v závislosti od zdroja údajov a modelu.Set up a new table with the fields you want, depending on your data source and model.
  2. Definujte agregácie pomocou dialógového okna Spravovať agregácie.Define the aggregations by using the Manage aggregations dialog.
  3. Ak je to potrebné, zmeňte režim úložiska agregovanej tabuľky.If applicable, change the storage mode for the aggregated table.

Spravovať agregácieManage aggregations

Keď vytvoríte novú tabuľku s požadovanými poľami, na table Polia v ľubovoľnom zobrazení aplikácie Power BI Desktop kliknite pravým tlačidlom myši na tabuľku a vyberte položku Spravovať agregácie.After you create the new table that has the fields you want, in the Fields pane of any Power BI Desktop view, right-click the table, and select Manage aggregations.

Výber položky Spravovať agregácie

V dialógovom okne Spravovať agregácie sa pre jednotlivé stĺpce v tabuľke zobrazí riadok, kde môžete zadať správanie agregácie.The Manage aggregations dialog shows a row for each column in the table, where you can specify the aggregation behavior. V nasledujúcom príklade sa dotazy na tabuľku podrobností Sales (Predaj) interne presmerujú na tabuľku agregácie Sales Agg (Agregácia predaja).In the following example, queries to the Sales detail table are internally redirected to the Sales Agg aggregation table.

Rozbaľovací zoznam súhrnu v dialógovom okne Spravovať agregácie ponúka nasledujúce hodnoty:The Summarization drop-down in the Manage aggregations dialog offers the following values:

  • CountCount
  • GroupByGroupBy
  • MaxMax
  • MinMin
  • SumSum
  • Spočítať riadky tabuľkyCount table rows

Dialógové okno Spravovať agregácie

V tomto príklade agregácie založenej na vzťahoch sú položky GroupBy voliteľné.In this relationship-based aggregation example, the GroupBy entries are optional. Okrem funkcie DISTINCTCOUNT nemajú vplyv na správanie agregácie a sú primárne určené na účely čitateľnosti.Except for DISTINCTCOUNT, they don't affect aggregation behavior, and are primarily for readability. Bez položiek GroupBy by sa agregácie aj tak zasiahli, a to v závislosti od vzťahov.Without the GroupBy entries, the aggregations would still get hit, based on the relationships. Táto situácia sa líši od príkladu veľkého objemu údajov ďalej v tomto článku, kde sa položky GroupBy vyžadujú.This is different from the big data example later in this article, where the GroupBy entries are required.

Po definovaní požadovaných agregácií vyberte tlačidlo Použiť všetko.After defining the aggregations you want, select Apply All.

OvereniaValidations

Dialógové okno Spravovať agregácie vyžaduje nasledujúce dôležité overenia:The Manage aggregations dialog enforces the following notable validations:

  • Typ údajov stĺpca podrobností musí byť rovnaký ako agregačný stĺpec s výnimkou funkcií súhrnu Počet a Počet riadkov v tabuľke.The Detail Column must have the same datatype as the Aggregation Column, except for the Count and Count table rows Summarization functions. Funkcie Počet a Počet riadkov v tabuľke sú dostupné iba pre celočíselné agregačné stĺpce a nevyžadujú zodpovedajúci typ údajov.Count and Count table rows are only available for integer aggregation columns, and don't require a matching datatype.
  • Zreťazené agregácie týkajúce sa troch alebo viacerých tabuliek nie sú povolené.Chained aggregations covering three or more tables aren't allowed. Agregácie v Tabuľke A napríklad nemôžu odkazovať na Tabuľku B, ktorej agregácie odkazujú na Tabuľku C.For example, aggregations on Table A can't refer to a Table B that has aggregations referring to a Table C.
  • Duplicitné agregácie, kde dve položky používajú rovnakú funkciu súhrnu a odkazujú na rovnakú tabuľku podrobností a stĺpec podrobností, nie sú povolené.Duplicate aggregations, where two entries use the same Summarization function and refer to the same Detail Table and Detail Column, aren't allowed.
  • Tabuľka podrobností musí využívať režim úložiska režimu DirectQuery, nie Import.The Detail Table must use DirectQuery storage mode, not Import.
  • Zoskupovanie podľa stĺpca cudzieho kľúča používaného neaktívnym vzťahom a spoliehanie sa na funkciu USERELATIONSHIP pre výsledky agregácie sa nepodporuje.Grouping by a foreign key column used by an inactive relationship, and relying on the USERELATIONSHIP function for aggregation hits, isn't supported.

Väčšina overení sa vynúti zakázaním hodnôt rozbaľovacieho zoznamu a zobrazením vysvetľujúceho textu v popise, ako je znázornené na nasledujúcom obrázku.Most of the validations are enforced by disabling dropdown values and showing explanatory text in the tooltip, as shown in the following image.

Overenia zobrazené podľa popisu

Tabuľky agregácie sú skrytéAggregation tables are hidden

Používatelia s prístupom iba na čítanie do množiny údajov nemôžu vytvoriť dotaz na agregačné tabuľky.Users with read-only access to the dataset can't query aggregation tables. Slúži to na vyhnutie sa bezpečnostným rizikám pri použití so zabezpečením na úrovni riadkov (RLS) .This avoids security concerns when used with row-level security (RLS). Používatelia a dotazy odkazujú na tabuľku podrobností, nie na tabuľku agregácie, a nemusia vedieť, že tabuľka agregácie existuje.Consumers and queries refer to the detail table, not the aggregation table, and don't need to know about the aggregation table.

Z tohto dôvodu sú tabuľky agregácie v zobrazení Zostava skryté.For this reason, aggregation tables are hidden from Report view. Ak tabuľka ešte nie je skrytá, dialógové okno Spravovať agregácie ju nastaví ako skrytú po výbere tlačidla Použiť všetko.If the table isn't already hidden, the Manage aggregations dialog will set it to hidden when you select Apply all.

Režimy úložiskaStorage modes

Agregačná funkcia pracuje s režimami úložiska na úrovni tabuľky.The aggregation feature interacts with table-level storage modes. Tabuľky služby Power BI môžu používať režimy úložiska DirectQuery, Import alebo Dual.Power BI tables can use DirectQuery, Import, or Dual storage modes. Režim DirectQuery odosiela dotazy priamo na koncový server, zatiaľ čo režim Import ukladá údaje vo vyrovnávacej pamäti a odosiela dotazy do údajov vo vyrovnávacej pamäti.DirectQuery queries the backend directly, while Import caches data in memory and sends queries to the cached data. Všetky zdroje údajov Import a nemultidimenzionálne zdroje DirectQuery služby Power BI pracujú s agregáciami.All Power BI Import and non-multidimensional DirectQuery data sources can work with aggregations.

Ak chcete nastaviť režim úložiska agregovanej tabuľky na Import a tak urýchliť dotazy, vyberte agregovanú tabuľku v zobrazení Model aplikácie Power BI Desktop.To set the storage mode of an aggregated table to Import to speed up queries, select the aggregated table in Power BI Desktop Model view. Na table Vlastnosti otvorte položku Rozšírené, rozbaľte ponuku v časti Režim úložiska a vyberte položku Import.In the Properties pane, expand Advanced, drop down the selection under Storage mode, and select Import. Táto akcia je nevratná.Note that this action is irreversible.

Nastavenie režimu úložiska

Ďalšie informácie o režimoch úložiska tabuliek nájdete v téme Spravovanie režimu úložiska v aplikácii Power BI Desktop.For more information about table storage modes, see Manage storage mode in Power BI Desktop.

Zabezpečenie na úrovni riadkov (RLS) pre agregácieRLS for aggregations

Ak chcete, aby výrazy zabezpečenia na úrovni riadkov (RLS) fungovali pre agregácie správne, mali by filtrovať tabuľku agregácie aj tabuľku podrobností.To work correctly for aggregations, RLS expressions should filter both the aggregation table and the detail table.

V nasledujúcom príklade výraz zabezpečenia na úrovni riadkov v tabuľke Geography (Geografia) funguje pre agregácie, pretože tabuľka Geography (Geografia) sa nachádza na strane filtrovania vzťahov s tabuľkou Sales (Predaj) aj s tabuľkou Sales Agg (Agregácia predaja).In the following example, the RLS expression on the Geography table works for aggregations, because Geography is on the filtering side of relationships to both the Sales table and the Sales Agg table. V dotazoch, ktoré zasiahnu tabuľku agregácie, aj v tých, ktoré ju nezasiahnu, je úspešne použité zabezpečenia na úrovni riadkov.Queries that hit the aggregation table and those that don't will both have RLS successfully applied.

Úspešné zabezpečenie na úrovni riadkov (RLS) pre agregácie

Výraz zabezpečenia na úrovni riadkov v tabuľke Product (Produkt) filtruje iba tabuľku podrobností Sales (Predaj), nie agregovanú tabuľku Sales Agg (Agregácia predaja).An RLS expression on the Product table filters only the detail Sales table, not the aggregated Sales Agg table. Keďže tabuľka agregácie je iným zobrazením údajov v tabuľke podrobností, bolo by neisté odpovedať na dotazy z tabuľky agregácie, ak by sa nedal použiť filter zabezpečenia na úrovni riadkov.Since the aggregation table is another representation of the data in the detail table, it would be insecure to answer queries from the aggregation table if the RLS filter can't be applied. Neodporúča sa filtrovať len tabuľku podrobností, pretože dotazy používateľov z tejto roly nebudú mať prospech z výsledkov agregácie.Filtering only the detail table isn't recommended, because user queries from this role won't benefit from aggregation hits.

Výraz zabezpečenia na úrovni riadkov, ktorý filtruje len tabuľku agregácie Sales Agg (Agregácia predaja) a nie tabuľku podrobností Sales (Predaj), nie je povolený.An RLS expression that filters only the Sales Agg aggregation table and not the Sales detail table isn't allowed.

Výraz zabezpečenia na úrovni riadkov len pre tabuľku agregácie nie je povolený

V prípade agregácií založených na stĺpcoch GroupBy je možné výraz zabezpečenia na úrovni riadkov použitý v tabuľke podrobností použiť na filtrovanie tabuľky agregácie, pretože všetky stĺpce GroupBy v tabuľke agregácie sú obsiahnuté v tabuľke podrobností.For aggregations based on GroupBy columns, an RLS expression applied to the detail table can be used to filter the aggregation table, because all the GroupBy columns in the aggregation table are covered by the detail table. Na druhej strane, filter zabezpečenia na úrovni riadkov použitý na tabuľku agregácie nie je možné použiť na tabuľku podrobností, takže je zakázaný.On the other hand, an RLS filter on the aggregation table can't be applied to the detail table, so is disallowed.

Agregácia na základe vzťahovAggregation based on relationships

Dimenzionálne modely zvyčajne používajú agregácie na základe vzťahov.Dimensional models typically use aggregations based on relationships. Množiny údajov služby Power BI zo skladov údajov a trhov údajov pripomínajú schému hviezdy/vločky so vzťahmi medzi tabuľkami dimenzií a tabuľkami faktov.Power BI datasets from data warehouses and data marts resemble star/snowflake schemas, with relationships between dimension tables and fact tables.

V nasledujúcom modeli tvorenom jedným zdrojom údajov tabuľky používajú režim úložiska DirectQuery.In the following model from a single data source, the tables are using DirectQuery storage mode. Tabuľka faktov Sales obsahuje miliardy riadkov.The Sales fact table contains billions of rows. Nastavenie úložiska tabuľky Sales (Predaj) na režim Import na používanie vyrovnávacej pamäte by spotrebovávalo značný objem pamäte a prostriedkov.Setting the storage mode of Sales to Import for caching would consume considerable memory and management overhead.

Tabuľky podrobností v modeli

Namiesto toho vytvorte tabuľku agregácie Sales Agg (Agregácia predaja).Instead, create the Sales Agg aggregation table. Počet riadkov v tabuľke Sales Agg (Agregácia predaja) sa rovná súčtu stĺpca SalesAmount (SumaPredaja) zoskupenému podľa kľúčov CustomerKey (KľúčZákazníka), DateKey (KľúčDátumu) a ProductSubcategoryKey (KľúčPodkategórieProduktu).In the Sales Agg table, the number of rows equals the sum of SalesAmount grouped by CustomerKey, DateKey, and ProductSubcategoryKey. Tabuľka Sales Agg (Agregácia predaja) má vyššiu granularitu než tabuľka Sales (Predaj), takže namiesto miliárd riadkov by mala obsahovať milióny riadkov, ktorých spravovanie je oveľa jednoduchšie.The Sales Agg table is at a higher granularity than Sales, so instead of billions, it might contain millions of rows, which are much easier to manage.

Ak sa nasledujúce tabuľky dimenzií používajú najčastejšie pre dotazy s vysokou obchodnou hodnotou, môžu filtrovať tabuľku Sales Agg (Agregácia predaja) pomocou vzťahov One-to-many alebo Many-to-one.If the following dimension tables are the most commonly used for the queries with high business value, they can filter Sales Agg, using one-to-many or many-to-one relationships.

  • GeografiaGeography
  • ZákazníkCustomer
  • DátumDate
  • Podkategória produktovProduct Subcategory
  • Kategória produktuProduct Category

Tento model je zobrazený na nasledujúcom obrázku.The following image shows this model.

Tabuľka agregácie v modeli

V nasledujúcej tabuľke sú zobrazené agregácie pre tabuľku Sales Agg.The following table shows the aggregations for the Sales Agg table.

Agregácie pre tabuľku Sales Agg (Agregácia predaja)

Poznámka

Tabuľka Sales Agg (Agregácia predaja), podobne ako iné tabuľky, má flexibilitu načítania rôznymi spôsobmi.The Sales Agg table, like any table, has the flexibility of being loaded in a variety of ways. Agregácia sa môže vykonávať v zdrojovej databáze pomocou procesov ETL/ELT alebo pomocou výrazu M pre tabuľku.The aggregation can be performed in the source database using ETL/ELT processes, or by the M expression for the table. Tabuľka agregácie môže používať režim úložiska Import buď s prírastkovým obnovením v službe Power BI Premium, alebo bez neho, alebo môže používať režim DirectQuery a optimalizovať sa tak pre rýchle dotazy pomocou indexov columnstore.The aggregated table can use Import storage mode, with or without incremental refresh in Power BI Premium, or it can use DirectQuery and be optimized for fast queries using columnstore indexes. Táto flexibilita umožňuje vyvážené architektúry, ktoré môžu rozložiť zaťaženie dotazu, aby sa zabránilo kritickým miestam.This flexibility enables balanced architectures that can spread query load to avoid bottlenecks.

Zmenou režimu úložiska tabuľky agregácie Sales Agg (Agregácia predaja) na režim Import sa otvorí dialógové okno s informáciou, že súvisiace tabuľky dimenzií je možné nastaviť na režim úložiska Dual.Changing the storage mode of the aggregated Sales Agg table to Import opens a dialog box saying that the related dimension tables can be set to storage mode Dual.

Dialógové okno režimu úložiska

Nastavenie súvisiacich tabuliek dimenzií na režim Dual im umožňuje správať sa ako v režime Import alebo DirectQuery v závislosti od poddotazu.Setting the related dimension tables to Dual lets them act as either Import or DirectQuery, depending on the subquery. V tomto príklade:In the example:

  • Dotazy, ktoré agregujú metriky z tabuľky Sales Agg v režime Import, a zoskupujú podľa atribútov zo súvisiacich tabuliek Dual, je možné vrátiť z vyrovnávacej pamäte v pamäti.Queries that aggregate metrics from the Import-mode Sales Agg table, and group by attribute(s) from the related Dual tables, can be returned from the in-memory cache.
  • Dotazy, ktoré agregujú metriky z tabuľky Sales v režime DirectQuery, a zoskupujú podľa atribútov zo súvisiacich tabuliek Dual, je možné vrátiť v režime DirectQuery.Queries that aggregate metrics from the DirectQuery Sales table, and group by attribute(s) from the related Dual tables, can be returned in DirectQuery mode. Logika dotazu vrátane operácie GroupBy sa odovzdáva ďalej do zdrojovej databázy.The query logic, including the GroupBy operation, is passed down to the source database.

Ďalšie informácie o režime úložiska Dual nájdete v téme Spravovanie režimu úložiska v aplikácii Power BI Desktop.For more information about Dual storage mode, see Manage storage mode in Power BI Desktop.

Silné versus slabé vzťahyStrong vs. weak relationships

Prístupy agregácie na základe vzťahov vyžadujú silné vzťahy.Aggregation hits based on relationships require strong relationships.

Silné vzťahy zahŕňajú nasledujúce kombinácie režimov úložiska, pričom obe tabuľky pochádzajú z jedného zdroja:Strong relationships include the following storage mode combinations, where both tables are from a single source:

Tabuľka na stranách manyTable on the many sides Tabuľka na strane 1Table on the 1 side
DualDual DualDual
ImportovaťImport Import alebo DualImport or Dual
DirectQueryDirectQuery DirectQuery alebo DualDirectQuery or Dual

Vzťah zo zmiešaných zdrojov sa považuje za silný len v tom prípade, ak sú obe tabuľky nastavené na typ Import.The only case where a cross-source relationship is considered strong is if both tables are set to Import. Vzťahy typu many-to-many sa vždy považujú za slabé.Many-to-many relationships are always considered weak.

Informácie o prístupoch agregácie zo zmiešaných zdrojov, ktoré nie sú závislé od vzťahov, nájdete v časti Agregácie založené na stĺpcoch GroupBy.For cross-source aggregation hits that don't depend on relationships, see Aggregations based on GroupBy columns.

Príklady dotazov agregácie založených na vzťahochRelationship-based aggregation query examples

Nasledujúci dotaz zachytáva agregáciu, pretože stĺpce v tabuľke Dátum majú granularitu, ktorá dokážete agregáciu zachytiť.The following query hits the aggregation, because columns in the Date table are at the granularity that can hit the aggregation. Stĺpec SalesAmount (SumaPredaja) využíva agregáciu SUM.The SalesAmount column uses the Sum aggregation.

Úspešný dotaz agregácie založený na vzťahoch

Nasledujúci dotaz agregáciu nezachytí.The following query doesn't hit the aggregation. Napriek vyžiadaniu súčtu stĺpca SalesAmount (SumaPredaja) dotaz vykonáva operáciu GroupBy na stĺpci v tabuľke Product (Produkt), ktorá nemá granularitu umožňujúcu zasiahnuť agregáciu.Despite requesting the sum of SalesAmount, the query is performing a GroupBy operation on a column in the Product table, which isn't at the granularity that can hit the aggregation. Ak dodržíte vzťahy uvedené v modeli, podkategória produktu môže mať viacero riadkov Product (Produkt).If you observe the relationships in the model, a product subcategory can have multiple Product rows. Dotaz by nebol schopný určiť, ktorý produkt sa má agregovať.The query wouldn't be able to determine which product to aggregate to. Dotaz sa v tomto prípade vráti do režimu DirectQuery a odošle dotaz SQL do zdroja údajov.In this case, the query reverts to DirectQuery and submits a SQL query to the data source.

Dotaz, ktorý nemôže využiť agregáciu

Agregácie nie sú len pre jednoduché výpočty, ktoré vykonávajú jednoduchý súčet.Aggregations aren't just for simple calculations that perform a straightforward sum. Môžu sa využiť aj pri zložitých výpočtoch.Complex calculations can also benefit. Koncepčne sa zložitý výpočet rozdeľuje do poddotazov pre každú funkciu SUM, MIN, MAX a COUNT a každý poddotaz sa vyhodnotí s cieľom určiť, či dokáže agregáciu zasiahnuť.Conceptually, a complex calculation is broken down into subqueries for each SUM, MIN, MAX, and COUNT, and each subquery is evaluated to determine if it can hit the aggregation. Táto logika nie je vo všetkých prípadoch pravdivá z dôvodu optimalizácie plánu dotazu, ale vo všeobecnosti by mala platiť.This logic doesn't hold true in all cases due to query-plan optimization, but in general it should apply. Tento príklad agregáciu zachytí:The following example hits the aggregation:

Komplexný dotaz agregácie

Funkcia COUNTROWS môže využívať agregácie.The COUNTROWS function can benefit from aggregations. Nasledujúci dotaz agregáciu zasiahne, pretože pre tabuľku Sales (Predaj) je určená agregácia Počet riadkov v tabuľke.The following query hits the aggregation because there is a Count table rows aggregation defined for the Sales table.

Dotaz agregácie COUNTROWS

Funkcia AVERAGE môže využívať agregácie.The AVERAGE function can benefit from aggregations. Nasledujúci dotaz zachytí agregáciu, pretože funkcia AVERAGE sa interne včlení do funkcie SUM vydelenej funkciou COUNT.The following query hits the aggregation because AVERAGE internally gets folded to a SUM divided by a COUNT. Keďže stĺpec UnitPrice má agregácie definované pre funkcie SUM aj COUNT, agregácia sa zachytí.Since the UnitPrice column has aggregations defined for both SUM and COUNT, the aggregation is hit.

Dotaz agregácie AVERAGE

V niektorých prípadoch funkcia DISTINCTCOUNT môže využívať agregácie.In some cases, the DISTINCTCOUNT function can benefit from aggregations. Nasledujúci dotaz zachytí agregáciu, pretože pre CustomerKey existuje položka Zoskupiť_podľa, ktorá zachová odlišnosti CustomerKey v tabuľke agregácie.The following query hits the aggregation because there is a GroupBy entry for CustomerKey, which maintains the distinctness of CustomerKey in the aggregation table. Tento postup by mohol predsa zasiahnuť limit výkonu, pričom viac ako dva až päť miliónov jedinečných hodnôt môže ovplyvniť výkon dotazu.This technique might still hit the performance threshold where more than two to five million distinct values can affect query performance. Môže to však byť užitočné v prípadoch, kde existujú miliardy riadkov v tabuľke podrobností, no dva až päť miliónov jedinečných hodnôt v stĺpci.However, it can be useful in scenarios where there are billions of rows in the detail table, but two to five million distinct values in the column. V tomto prípade sa funkcia DISTINCTCOUNT môže vykonávať rýchlejšie než prehľadávanie tabuľky s miliardami riadkov, dokonca aj vtedy, ak boli uložené vo vyrovnávacej pamäti.In this case, the DISTINCTCOUNT can perform faster than scanning the table with billions of rows, even if it were cached into memory.

Dotaz agregácie DISTINCTCOUNT

Funkcie časovej inteligencie jazyka DAX podporujú agregácie.DAX time-intelligence functions are aggregation aware. Nasledujúci dotaz zaznamená agregáciu, pretože funkcia DATESYTD vygeneruje hodnoty tabuľky CalendarDay a agregačná tabuľka má granularitu, ktorá je pokrytá pre stĺpce zoskupenia v tabuľke Date.The following query hits the aggregation because the DATESYTD function generates a table of CalendarDay values, and the aggregation table is at a granularity that is covered for group-by columns in the Date table. Toto je príklad filtra s hodnotami z tabuliek na funkciu CALCULATE, ktorá dokáže pracovať s agregáciami.This is an example of a table-valued filter to the CALCULATE function, which can work with aggregations.

Dotaz agregácie SUMMARIZECOLUMNS

Agregácie založené na stĺpcoch GroupByAggregation based on GroupBy columns

Modely založené na spracovaní veľkého objemu údajov Hadoop majú odlišné vlastnosti ako rozmerové modely.Hadoop-based big data models have different characteristics than dimensional models. Ak sa chcete vyhnúť spojeniam medzi tabuľkami s veľkým objemom údajov, dátové modely s veľkým objemom zvyčajne nepoužívajú vzťahy, ale denormalizujú atribúty dimenzií na tabuľky faktov.To avoid joins between large tables, big data models often don't use relationships, but denormalize dimension attributes to fact tables. Takéto veľké dátové modely môžete odblokovať na interaktívnu analýzu pomocou agregácií založených na stĺpcoch GroupBy.You can unlock such big data models for interactive analysis by using aggregations based on GroupBy columns.

Nasledujúca tabuľka obsahuje číselný stĺpec Movement, ktorý sa má agregovať.The following table contains the Movement numeric column to be aggregated. Všetky ostatné stĺpce sú atribúty, podľa ktorých sa má zoskupiť.All the other columns are attributes to group by. Daný tabuľka obsahuje údaje IoT a obrovský počet riadkov.The table contains IoT data and a massive number of rows. Režim ukladacieho priestoru je DirectQuery.The storage mode is DirectQuery. Dotazy na zdroj údajov, ktoré sa agregujú v rámci celej množiny údajov, sú pomalé z dôvodu obrovského objemu.Queries on the data source that aggregate across the whole dataset are slow because of the sheer volume.

Tabuľka IoT

Ak chcete povoliť interaktívnu analýzu tejto množiny údajov, môžete pridať tabuľku agregácie, ktorá zoskupuje väčšinu atribútov, ale vylučuje atribúty s vysokou kardinalitou ako zemepisnú šírku a dĺžku.To enable interactive analysis on this dataset, you can add an aggregation table that groups by most of the attributes, but excludes the high-cardinality attributes like longitude and latitude. Týmto sa výrazne zníži počet riadkov a tento počet je dostatočne malý na to, aby sa pohodlne zmestili do vyrovnávacej pamäte v pamäti.This dramatically reduces the number of rows, and is small enough to comfortably fit into an in-memory cache.

Tabuľka Driver Activity Agg

Mapovanie agregácie definujete pre tabuľku Driver Activity Agg (Agregácia aktivít vodiča) v dialógovom okne Spravovať agregácie.You define the aggregation mappings for the Driver Activity Agg table in the Manage aggregations dialog.

Dialógové okno Spravovať agregácie pre Driver Activity Agg

V agregáciách založených na stĺpcoch GroupBy nie sú položky GroupBy voliteľné.In aggregations based on GroupBy columns, the GroupBy entries aren't optional. Bez nich by sa agregácia nezasiahla.Without them, the aggregations won't get hit. V tomto sa líši od používania agregácií na základe vzťahov, v ktorých sú položky GroupBy voliteľné.This is different from using aggregations based on relationships, where the GroupBy entries are optional.

V nasledujúcej tabuľke sú zobrazené agregácie pre tabuľku Driver Activity Agg.The following table shows the aggregations for the Driver Activity Agg table.

Tabuľka agregácií Driver Activity Agg

Režim úložiska tabuľky agregácie Driver Activity Agg (Agregácia aktivít vodiča) môžete nastaviť na Import.You can set the storage mode of the aggregated Driver Activity Agg table to Import.

Príklad dotazu agregácie GroupByGroupBy aggregation query example

Tento dotaz zasiahne agregáciu, pretože tabuľka agregácie zahŕňa stĺpec Activity Date.The following query hits the aggregation, because the Activity Date column is covered by the aggregation table. Funkcia COUNTROWS používa agregáciu Počet riadkov v tabuľke.The COUNTROWS function uses the Count table rows aggregation.

Úspešný dotaz agregácie GroupBy

Najmä pre modely, ktoré obsahujú atribúty filtrov v tabuľkách faktov, je vhodné použiť agregácie Počet riadkov v tabuľke.Especially for models that contain filter attributes in fact tables, it's a good idea to use Count table rows aggregations. Power BI môže odoslať dotazy do množiny údajov pomocou funkcie COUNTROWS v prípadoch, keď o to používateľ výslovne nežiada.Power BI may submit queries to the dataset using COUNTROWS in cases where it is not explicitly requested by the user. Napríklad dialógové okno filtrov zobrazuje počet riadkov pre každú hodnotu.For example, the filter dialog shows the count of rows for each value.

Dialógové okno filtrov

Techniky kombinovania agregácieCombined aggregation techniques

V prípade agregácií môžete kombinovať techniky vzťahov a stĺpcov GroupBy.You can combine the relationships and GroupBy columns techniques for aggregations. Agregácie založené na vzťahoch môžu vyžadovať, aby sa denormalizované tabuľky dimenzií rozdelili do viacerých tabuliek.Aggregations based on relationships may require the denormalized dimension tables to be split into multiple tables. Ak je to pre určité tabuľky dimenzií nákladné alebo nepraktické, potrebné atribúty môžete pre dané dimenzie replikovať v tabuľke agregácie a v prípade ostatných použiť vzťahy.If this is costly or impractical for certain dimension tables, you can replicate the necessary attributes in the aggregation table for those dimensions, and use relationships for others.

Nasledujúci model napríklad replikuje stĺpce Month (Mesiac), Quarter (Štvrťrok), Semester (Polrok) a Year (Rok) v tabuľke Sales Agg (Agregácia predaja).For example, the following model replicates Month, Quarter, Semester, and Year in the Sales Agg table. Medzi tabuľkou Sales Agg (Agregácia predaja) a Date (Dátum) neexistuje žiaden vzťah, ale medzi tabuľkou Customer (Zákazník) a Product Subcategory (Podkategória produktu) vzťahy existujú.There is no relationship between Sales Agg and the Date table, but there are relationships to Customer and Product Subcategory. Režim ukladacieho priestoru tabuľky Sales Agg je Import.The storage mode of Sales Agg is Import.

Techniky kombinovania agregácie

Nasledujúca tabuľka uvádza položky nastavené v dialógovom okne Spravovať agregácie pre tabuľku Sales Agg.The following table shows the entries set in the Manage aggregations dialog for the Sales Agg table. Položky GroupBy, pri ktorých je Date (Dátum) tabuľka podrobností, musia zasiahnuť agregácie pre dotazy, ktoré sa zoskupujú podľa atribútov Date.The GroupBy entries where Date is the detail table are mandatory, to hit aggregations for queries that group by the Date attributes. Rovnako ako v predchádzajúcom príklade položky GroupBy pre stĺpce CustomerKey (KľúčZákazníka) a ProductSubcategoryKey (KľúčPodkategórieProduktu) nemajú vplyv na zasiahnutie agregácie, s výnimkou funkcie DISTINCTCOUNT, z dôvodu výskytu vzťahov.As in the previous example, the GroupBy entries for CustomerKey and ProductSubcategoryKey don't affect aggregation hits, except for DISTINCTCOUNT, because of the presence of relationships.

Položky pre tabuľku agregácií Sales Agg (Agregácia predaja)

Príklady dotazov kombinovanej agregácieCombined aggregation query examples

Nasledujúci dotaz zasiahne agregáciu, pretože tabuľka agregácie zahŕňa položku CalendarMonth (KalendárnyMesiac), pričom položka CategoryName (NázovKategórie) je prístupná prostredníctvom vzťahov One-to-many.The following query hits the aggregation, because the aggregation table covers CalendarMonth, and CategoryName is accessible via one-to-many relationships. Stĺpec SalesAmount (SumaPredaja) využíva agregáciu SUM.SalesAmount uses the SUM aggregation.

Príklad dotazu, ktorý zasiahne agregáciu

Tento dotaz agregáciu nezasiahne, pretože tabuľka agregácie nezahŕňa položku CalendarDay (KalendárnyDeň).The following query doesn't hit the aggregation, because the aggregation table doesn't cover CalendarDay.

Príklad dotazu, ktorý nezasiahne agregáciu

Nasledujúci dotaz časovej inteligencie agregáciu nezasiahne, pretože funkcia DATESYTD vygeneruje tabuľku hodnôt CalendarDay (KalendárnyDeň) a tabuľka agregácie nezahŕňa položku CalendarDay (KalendárnyDeň).The following time-intelligence query doesn't hit the aggregation, because the DATESYTD function generates a table of CalendarDay values, and the aggregation table doesn't cover CalendarDay.

Príklad dotazu, ktorý nezasiahne agregáciu

Priorita agregácieAggregation precedence

Priorita agregácie umožňuje, aby jediný poddotaz bral do úvahy viaceré tabuľky agregácie.Aggregation precedence allows multiple aggregation tables to be considered by a single subquery.

Nasledujúci príklad zobrazuje zložený model, ktorý obsahuje viacero zdrojov:The following example is a composite model containing multiple sources:

  • Tabuľka Driver Activity (Aktivita vodiča) v režime DirectQuery obsahuje viac ako jeden bilión riadkov s údajmi IoT, ktoré pochádzajú zo systému spracovania veľkého objemu údajov.The Driver Activity DirectQuery table contains over a trillion rows of IoT data sourced from a big-data system. Slúži súhrnným dotazom na zobrazenie jednotlivých údajov IoT v súvislostiach riadeného filtra.It serves drillthrough queries to view individual IoT readings in controlled filter contexts.
  • Tabuľka Driver Activity Agg je sprostredkujúca tabuľka agregácie v režime DirectQuery.The Driver Activity Agg table is an intermediate aggregation table in DirectQuery mode. Obsahuje viac ako miliardu riadkov v Azure SQL Data Warehouse a je optimalizovaná na zdroji pomocou indexov columnstore.It contains over a billion rows in Azure SQL Data Warehouse and is optimized at the source using columnstore indexes.
  • Tabuľka Driver Activity Agg2 (Agregácia aktivít vodiča2) v režime Import má vysokú granularitu, pretože atribútov zoskupenia je málo a majú nízku kardinalitu.The Driver Activity Agg2 Import table is at a high granularity, because the group-by attributes are few and low cardinality. Počet riadkov môže byť nízky, teda v tisícoch, takže sa môžete jednoducho zmestiť do vyrovnávacej pamäte v pamäti.The number of rows could be as low as thousands, so it can easily fit into an in-memory cache. Tieto atribúty používajú výkonné tabule s vysokým profilom, takže dotazy, ktoré na ne odkazujú, by mali byť čo najrýchlejšie.These attributes happen to be used by a high-profile executive dashboard, so queries referring to them should be as fast as possible.

Poznámka

Agregačné tabuľky DirectQuery, ktoré používajú iný zdroj údajov než tabuľka podrobností, sa podporujú iba v prípade, že agregačná tabuľka je zo zdroja servera SQL Server, Azure SQL alebo Azure SQL Data Warehouse.DirectQuery aggregation tables that use a different data source from the detail table are only supported if the aggregation table is from a SQL Server, Azure SQL, or Azure SQL Data Warehouse source.

Nároky na pamäť tohto modelu sú relatívne malé, odhaľuje však veľkú množinu údajov.The memory footprint of this model is relatively small, but it unlocks a huge dataset. Predstavuje vyváženú architektúru, pretože rozkladá zaťaženie dotazu v rámci komponentov architektúry s ich využitím na základe ich silných stránok.It represents a balanced architecture because it spreads the query load across components of the architecture, utilizing them based on their strengths.

Tabuľky pre model s malými nárokmi, ktorý poskytuje prístup k veľkej množine údajov

Dialógové okno Spravovať agregácie pre tabuľku Driver Activity Agg2 (Agregácia aktivít vodiča2) nastaví pole Priorita na hodnotu 10, čo je vyššia hodnota než pre tabuľku Driver Activity Agg (Agregácia aktivít vodiča).The Manage aggregations dialog for Driver Activity Agg2 sets the Precedence field to 10, which is higher than for Driver Activity Agg. Nastavenie vyššej priority znamená, že dotazy, ktoré používajú agregácie, najskôr zvážia tabuľku Driver Activity Agg2 (Agregácia aktivít vodiča2).The higher precedence setting means queries that use aggregations will consider Driver Activity Agg2 first. Poddotazy, ktoré nemajú granularitu, ktorú môže zodpovedať Driver Activity Agg2 (Agregácia aktivít vodiča2), namiesto toho zvážia tabuľku Driver Activity Agg (Agregácia aktivít vodiča).Subqueries that aren't at the granularity that can be answered by Driver Activity Agg2 will consider Driver Activity Agg instead. Podrobné dotazy, ktoré sa nedajú zodpovedať v žiadnej tabuľke agregácie, budú presmerované na Driver Activity.Detail queries that cannot be answered by either aggregation table will be directed to Driver Activity.

Tabuľka určená v stĺpci Detail Table (Tabuľka podrobností) je Driver Activity (Aktivita vodiča)a nie Driver Activity Agg (Agregácia aktivít vodiča), pretože zreťazené agregácie nie sú povolené.The table specified in the Detail Table column is Driver Activity, not Driver Activity Agg, because chained aggregations are not allowed.

Dialógové okno Spravovať agregácie

V nasledujúcej tabuľke sú zobrazené agregácie pre tabuľku Driver Activity Agg2.The following table shows the aggregations for the Driver Activity Agg2 table.

Tabuľka agregácií Driver Activity Agg2

Určenie, či dotazy zasiahnu alebo nezasiahnu agregácieDetect whether queries hit or miss aggregations

Nástroj SQL Profiler dokáže zistiť, či sa dotazy vracajú z nástroja úložiska vyrovnávacej pamäte v pamäti alebo sa presunú do zdroja údajov pomocou režimu DirectQuery.SQL Profiler can detect whether queries are returned from the in-memory cache storage engine, or pushed to the data source by DirectQuery. Ten istý proces môžete použiť aj na zistenie toho, či sa agregácie práve zasahujú.You can use the same process to detect whether aggregations are being hit. Ďalšie informácie nájdete v téme Dotazy, ktoré majú alebo nemajú prístup do vyrovnávacej pamäte.For more information, see Queries that hit or miss the cache.

Nástroj SQL Profiler taktiež poskytuje rozšírenú udalosť Query Processing\Aggregate Table Rewrite Query.SQL Profiler also provides the Query Processing\Aggregate Table Rewrite Query extended event.

Nasledujúci zlomok JSON ukazuje príklad výstupu udalosti, keď sa používa agregácia.The following JSON snippet shows an example of the output of the event when an aggregation is used.

  • matchingResult ukazuje, že poddotaz použil agregáciu,matchingResult shows that the subquery used an aggregation.
  • dataRequest zobrazuje stĺpce GroupBy a agregované stĺpce, ktoré poddotaz použil,dataRequest shows the GroupBy column(s) and aggregated column(s) the subquery used.
  • mapovanie zobrazuje stĺpce v tabuľke agregácie, ktoré boli namapované.mapping shows the columns in the aggregation table that were mapped to.

Výstup udalosti pri použití agregácie

Zabezpečenie synchronizácie vyrovnávacej pamäteKeep caches in sync

Agregácie, ktoré kombinujú režimy úložiska DirectQuery, Import alebo Dual, môžu vrátiť rôzne údaje, pokiaľ je zabezpečená synchronizácia vyrovnávacej pamäte so zdrojom údajov.Aggregations that combine DirectQuery, Import, and/or Dual storage modes may return different data unless the in-memory cache is kept in sync with the source data. Spustenie dotazu sa napríklad nepokúsi prekryť problémy údajov filtrovaním výsledkov režimu DirectQuery tak, aby sa rovnali hodnotám vyrovnávacej pamäte.For example, query execution won't attempt to mask data issues by filtering DirectQuery results to match cached values. Existujú zavedené techniky na riešenie takýchto problémov už od základov, ak je to potrebné.There are established techniques to handle such issues at the source, if necessary. Optimalizácie výkonu by sa mali používať iba takým spôsobom, ktorý neohrozuje vašu schopnosť plniť obchodné požiadavky.Performance optimizations should be used only in ways that don't compromise your ability to meet business requirements. Vašou zodpovednosťou je poznať svoje toky údajov a podľa toho ich navrhovať.It's your responsibility to know your data flows and design accordingly.

Ďalšie krokyNext steps

Ďalšie informácie o zložených modeloch nájdete v témach:For more information about composite models, see:

Ďalšie informácie o režime DirectQuery nájdete v témach:For more information about DirectQuery, see: