Adatmennyiség-csökkentési technikák importálási modellek készítéséhezData reduction techniques for Import modeling

Ez a cikk a Power BI Desktopot használó, importálási modelleket fejlesztő adatmodellezőknek szól.This article targets Power BI Desktop data modelers developing Import models. Az importálási modellekbe betöltött adatmennyiség csökkentését elősegítő különböző technikákat ismerteti.It describes different techniques to help reduce the data loaded into Import models.

Az importálási modellekbe töltött tömörített és optimalizált adatok, a VertiPaq tárolási összetevő használatával vannak lemezen tárolva.Import models are loaded with data that is compressed and optimized and then stored to disk by the VertiPaq storage engine. A forrásadatok memóriába töltésekor akár tízszeres tömörítés is tapasztalható, ezért reális elvárás, hogy 10 GB forrásadat körülbelül 1 GB méretre tömöríthető.When source data is loaded into memory, it is possible to see 10x compression, and so it is reasonable to expect that 10 GB of source data can compress to about 1 GB in size. A lemezen való megőrzéskor további 20% méretcsökkenés érhető el.Further, when persisted to disk an additional 20% reduction can be achieved.

A VertiPaq tárolási összetevő által elért hatékonyság mellett is fontos a modellbe betöltött adatmennyiség minimalizálására törekedni.Despite the efficiencies achieved by the VertiPaq storage engine, it is important that you strive to minimize the data that is to be loaded into your models. Ez különösen így van a nagy modellek vagy olyan modellek esetén, amelyek idővel várhatóan nagyra növekednek.It is especially true for large models, or models that you anticipate will grow to become large over time. Emellett szól egyebek mellett as következő négy meggyőző érv:Four compelling reasons include:

  • A kapacitás esetleg nem támogatja a nagyobb méretű modelleket.Larger model sizes may not be supported by your capacity. A megosztott kapacitások legfeljebb 1 GB, a prémium szintű kapacitások legfeljebb 13 GB méretű modellt képesek üzemeltetni.Shared capacity can host models up to 1 GB in size, while Premium capacities can host models up to 13 GB in size. További információt a Nagyméretű adathalmazok Power BI Premium-támogatása című cikk kínál.For further information, read the Power BI Premium support for large datasets article.
  • A kisebb modellek csökkentik a kapacitás erőforrásai, elsősorban a memória iránti igényt.Smaller model sizes reduce contention for capacity resources, in particular memory. Így több modell hosszabb időtartam alatt tölthető be egyidejűleg, csökkentve a kiürítések számát.It allows more models to be concurrently loaded for longer periods of time, resulting in lower eviction rates. További információ: Prémium szintű kapacitások kezelése.For more information, see Managing Premium capacities.
  • Kisebb modellekkel gyorsabb adatfrissítés érhető el, ez pedig a jelentéskészítés kisebb késését és az adathalmaz gyorsabb frissítését eredményezi, valamint kevésbé terheli a forrásrendszer és a kapacitás erőforrásait.Smaller models achieve faster data refresh, resulting in lower latency reporting, higher dataset refresh throughput, and less pressure on source system and capacity resources.
  • A táblák sorainak alacsonyabb száma a számítások gyorsabb kiértékelését eredményezi, ez pedig a teljesítmény általános javulásában mutatkozhat meg.Smaller table row counts can result in faster calculation evaluations, which can deliver better overall query performance.

Ez a cikk nyolc különböző adatmennyiség-csökkentési technikát mutat be.There are eight different data reduction techniques covered in this article. Ezek a technikák a következők:These techniques include:

A szükségtelen oszlopok eltávolításaRemove unnecessary columns

A modelltáblák oszlopai két fő célt szolgálnak:Model table columns serve two main purposes:

  • Jelentéskészítést olyan jelentések kialakításához, amelyek megfelelően szűrik, csoportosítják és összesítik a modell adataitReporting, to achieve report designs that appropriate filter, group, and summarize model data
  • A modellstruktúrát a modellbeli kapcsolatok, számítások, biztonsági szerepkörök és akár az adatszínek formázása támogatásávalModel structure, by supporting model relationships, model calculations, security roles, and even data color formatting

Az ezeket a célokat nem szolgáló oszlopok valószínűleg eltávolíthatók.Columns that don't serve these purposes can probably be removed. Az oszlopok eltávolítása az úgynevezett vertikális szűrés.Removing columns is referred to as vertical filtering.

A modelleket ajánlott pontosan az ismert jelentéskészítési követelmények alapján meghatározott oszlopszámmal megtervezni.We recommend that you design models with exactly the right number of columns based on the known reporting requirements. A követelmények idővel megváltozhatnak, de érdemes szem előtt tartani, hogy később könnyebb oszlopokat hozzáadni, mint eltávolítani.Your requirements may change over time, but bear in mind that it's easier to add columns later than it is to remove them later. Az oszlopok eltávolítása tönkreteheti a jelentéseket vagy a modell struktúráját.Removing columns can break reports or the model structure.

A szükségtelen sorok eltávolításaRemove unnecessary rows

A modelltáblákat a lehető legkevesebb sorral kell betölteni.Model tables should be loaded with as few rows as possible. Ez úgy érhető el, ha a modelltáblákba két különböző okból (entitás vagy idő szerinti szűrés miatt) szűrt sorhalmazokat tölt be.It can be achieved by loading filtered rowsets into model tables for two different reasons: to filter by entity or by time. A sorok eltávolítása az úgynevezett horizontális szűrés.Removing rows is referred to as horizontal filtering.

Az entitás szerinti szűrés azzal jár, hogy csak a forrásadatok egy részhalmaza lesz betöltve a modellbe.Filtering by entity involves loading a subset of source data into the model. Az összes értékesítési régió értékesítési tényeinek betöltése helyett például csak egy régió tényei lesznek betöltve.For example, instead of loading sales facts for all sales regions, only load facts for a single region. Ez a tervezési mód sok kisebb modellt eredményez, és sorszintű biztonság definiálását is szükségtelenné teszi (megköveteli viszont célzott adathalmaz-engedélyek megadását a Power BI szolgáltatásban, és az egyes adathalmazokhoz csatlakozó „duplikált” jelentések létrehozását).This design approach will result in many smaller models, and it can also eliminate the need to define row-level security (but will require granting specific dataset permissions in the Power BI service, and creating "duplicate" reports that connect to each dataset). A felügyelet és a közzététel egyszerűbbé tétele érdekében kihasználhatja a Power Query-paraméterek és a Power BI-sablonfájlok használatával járó előnyöket.You can leverage the use of Power Query parameters and Power BI Template files to simplify management and publication. További információt A lekérdezési paraméterek és a Power BI-sablonok részletes bemutatása című blogbejegyzésben találhat.For further information, read the Deep Dive into Query Parameters and Power BI Templates blog entry.

Az idő szerinti szűrés lényege a tény típusú táblákba betöltött adatelőzmények mennyiségének (és a modell adattábláiba betöltött adatsorok számának) korlátozása.Filtering by time involves limiting the amount of data history loaded into fact-type tables (and limiting the date rows loaded into the model date tables). Az összes rendelkezésre álló előzményt csak akkor érdemes automatikusan betölteni, ha ez ismert jelentéskészítési követelmény.We suggest you don't automatically load all available history, unless it is a known reporting requirement. Hasznos lehet tudni, hogy a Power Query-szűrők paraméterezhetők, és akár relatív időszakok használatára is beállíthatók (a frissítés időpontjához viszonyítva, például az elmúlt öt évre).It is helpful to understand that time-based Power Query filters can be parameterized, and even set to use relative time periods (relative to the refresh date, for example, the past five years). Azzal is érdemes tisztában lenni, hogy az időalapú szűrők utólagos módosítása nem teszi tönkre a jelentéseket, csak azt eredményezi, hogy a jelentésekben kevesebb (vagy több) adatelőzmény fog rendelkezésre állni.Also, bear in mind that retrospective changes to time filters will not break reports; it will just result in less (or more) data history available in reports.

Csoportosítás és összesítésGroup by and summarize

A modell méretét csökkentő leghatékonyabb technika talán az előre összesített adatok betöltése.Perhaps the most effective technique to reduce a model size is to load pre-summarized data. Ezzel a technikával módosítható a tény típusú táblák részletessége.This technique can be used to raise the grain of fact-type tables. Ennek egyértelmű velejárója, hogy egyes részletek viszont elvesznek.There is a distinct trade-off, however, resulting in loss of detail.

Tegyük fel például, hogy a forrásban egy értékesítési ténytábla megrendelésenként egy sort tartalmaz.For example, a source sales fact table stores one row per order line. Az adatmennyiség jelentősen csökkenthető az összes értékesítési metrika összesítésével, valamint a dátum, az ügyfél és a termék szerinti csoportosítással.Significant data reduction could be achieved by summarizing all sales metrics, grouping by date, customer, and product. Felvetődhet, hogy az adatmennyiség még tovább csökkenthető az adatok havi csoportosításával.Consider, then, that an even more significant data reduction could be achieved by grouping by date at month level. Ez akár 99%-kal is csökkentheti a modell méretét, de többé nem lesz lehetséges jelentést készíteni napi szinten, vagy az egyes megrendelések szintjén.It could achieve a possible 99% reduction in model size, but reporting at day level—or individual order level—is no longer possible. A tény típusú adatok összesítése melletti döntés mindig hátrányokkal is jár.Deciding to summarize fact-type data always involves tradeoffs. A hátrányok vegyes modell kialakításával enyhíthetők, ezt a lehetőséget a Váltás Vegyes módra technika ismerteti.Tradeoff could be mitigated by a Mixed model design, and this option is described in the Switch to Mixed mode technique.

Oszlopok adattípusainak optimalizálásaOptimize column data types

A VertiPaq tárolási összetevő minden oszlophoz külön adatstruktúrát használ.The VertiPaq storage engine uses separate data structures for each column. Ezek az adatstruktúrák az értékkódolást használó numerikus oszlopadatok esetén érik el a legjobb optimalizálást.By design, these data structures achieve the highest optimizations for numeric column data, which use value encoding. A szöveges és más nem numerikus adatok viszont kivonatoló kódolást használnak.Text and other non-numeric data, however, uses hash encoding. Ehhez a tárolómotornak numerikus azonosítót kell rendelnie az oszlopban szereplő minden egyedi szöveges értékhez.It requires the storage engine to assign a numeric identifier to each unique text value contained in the column. Ez a numerikus azonosító lesz aztán az adatstruktúrában tárolva, ezért a tároláshoz és a lekérdezéshez a kivonat keresése szükséges.It is the numeric identifier, then, that is then stored in the data structure, requiring a hash lookup during storage and querying.

Bizonyos esetekben a szöveges forrásadatok numerikus értékekké konvertálhatók.In some specific instances, you can convert source text data into numeric values. lehetséges például, hogy a rendelésszámok előtagja mindig ugyanaz a szöveges érték (például „SO123456”).For example, a sales order number may be consistently prefixed by a text value (e.g. "SO123456"). Az előtag eltávolításával a rendelésszám értéke egész számmá konvertálható.The prefix could be removed, and the order number value converted to whole number. Nagy táblák esetén ez az adatmennyiség jelentős csökkenését eredményezheti, főleg akkor, ha az oszlop egyedi vagy nagy számosságú értékeket tartalmaz.For large tables, it can result in significant data reduction, especially when the column contains unique or high cardinality values.

Ebben a példában az oszlop Alapértelmezett összesítés tulajdonságát érdemes a „Nincs összesítés” értékre beállítani.In this example, we recommend that you set the column Default Summarization property to "Do Not Summarize". Így könnyebb kizárni a rendelésszámértékek nem megfelelő összesítését.It will help to minimize the inappropriate summarization of the order number values.

Egyéni oszlopok előnyben részesítésePreference for custom columns

A VertiPaq tárolási összetevő a modell számított (DAX-ban definiált) oszlopait ugyanúgy tárolja, mint a hagyományos, Power Queryből származó oszlopokat.The VertiPaq storage engine stores model calculated columns (defined in DAX) just like regular Power Query-sourced columns. Az adatstruktúrák azonban kissé eltérően vannak tárolva, és általában kevésbé hatékony tömörítést érnek el.However, the data structures are stored slightly differently, and typically achieve less efficient compression. Ráadásul az összes Power Query-tábla betöltése után vannak elkészítve, ez pedig hosszabb adatfrissítési időt eredményez.Also, they are built once all Power Query tables are loaded, which can result in extended data refresh times. Ez az oka, hogy a tábla oszlopait kevésbé hatékony számított oszlopokként felvenni, mint Power Queryben számított (M-ben definiált) oszlopokként.It is therefore less efficient to add table columns as calculated columns than Power Query computed columns (defined in M).

Az egyéni oszlopok létrehozását érdemesebb a Power Queryben végezni.Preference should be creating custom columns in Power Query. Ha a forrás egy adatbázis, két módon is elérhető nagyobb betöltési hatékonyság.When the source is a database, you can achieve greater load efficiency in two ways. A számítás definiálható az SQL-utasításban (a szolgáltató natív lekérdezési nyelvének használatával), vagy megvalósítható oszlopként az adatforrásban.The calculation can be defined in the SQL statement (using the native query language of the provider), or it can be materialized as a column in the data source.

Egyes esetekben mégis érdemesebb a modellbeli számított oszlopok mellett dönteni.However, in some instances, model calculated columns may be the better choice. Ilyen eset lehet az, amikor a képlet egy része mértékeket értékel ki, vagy ha adott, csak a DAX-függvényekben támogatott modellezési funkciókat igényel.It can be the case when the formula involves evaluating measures, or it requires specific modeling functionality only supported in DAX functions. Ilyen példával mutat be a Szülő-gyermek hierarchiákat kiszolgáló DAX-függvények ismertetése című cikk.For information on one such example, refer to the Understanding functions for parent-child hierarchies in DAX article.

Power Query-lekérdezések betöltésének letiltásaDisable Power Query query load

A más lekérdezésekkel való adatintegráció támogatására szánt Power Query-lekérdezéseket nem érdemes betölteni a modellbe.Power Query queries that are intended support data integration with other queries should not be loaded to the model. A lekérdezés modellbe való betöltésének elkerüléséhez ilyen esetekben gondoskodni kell a lekérdezésbetöltés letiltásáról.To avoid loading the query to the model, take care to ensure that you disable query load in these instances.

A Power Query képernyőképe, amelyen a „Betöltés engedélyezése” lehetőség látható.

Automatikus dátum/idő letiltásaDisable auto date/time

A Power BI Desktop tartalmaz egy Automatikus dátum/idő beállítást.Power BI Desktop includes an option called Auto date/time. Ha engedélyezve van, egy rejtett automatikus dátum/idő táblát hoz létre a dátumoszlopok számára, hogy támogassa a jelentés szerzőit a naptári időszakokra vonatkozó szűrők, csoportosítás és részletezés műveletek konfigurálásakor.When enabled, it creates a hidden auto date/time table for date columns to support report authors when configuring filters, grouping, and drill-down actions for calendar time periods. A rejtett táblák valójában számított táblák, amelyek megnövelik a modell méretét.The hidden tables are in fact calculated tables that will increase the size of the model. Ha útmutatásra van szüksége a beállítás használatával kapcsolatban, tekintse meg az automatikus dátum/idő a Power BI Desktopban történő használatának útmutatócikkét.For guidance about using this option, refer to the Auto date/time guidance in Power BI Desktop article.

Váltás Vegyes módraSwitch to Mixed mode

A Power BI Desktopban a Vegyes módú tervezés összetett modellt állít elő.In Power BI Desktop, a Mixed mode design produces a Composite model. Ez lényegében minden egyes tábla tárolási módjának meghatározását teszi lehetővé.Essentially, it allows you to determine storage mode for each table. Ennek köszönhetően minden tábla Tárolási mód tulajdonsága beállítható Importálás vagy DirectQuery értékre (egy további lehetőség a Kettős).Therefore, each table can have its Storage Mode property set as Import or DirectQuery (Dual is another option).

A modell méretét hatékonyan csökkentő technika a nagyobb tény típusú táblák Tárolási módjának DirectQuery értékre állítása.An effective technique to reduce the model size is to set the Storage Mode property for larger fact-type tables to DirectQuery. Megfontolandó, hogy ez a tervezési elv jól használható a korábban bemutatott Csoportosítás és összesítés technikával együtt.Consider that this design approach could work well in conjunction with the Group by and summarize technique introduced earlier. Az összesített értékesítési adatok például felhasználhatók „összegző” jelentések nagy teljesítményű készítéséhez.For example, summarized sales data could be used to achieve high performance "summary" reporting. Egy részletező oldal úgy mutathatja be részletesen a megadott (szűk) szűrőkörnyezethez tartozó értékesítéseket, hogy a környezeten belüli összes értékesítési megrendelést megjeleníti.A drill through page could display granular sales for specific (and narrow) filter context, displaying all in-context sales orders. Ebben a példában a részletező oldal egy DirectQuery-tábla alapján tartalmaz vizualizációkat az értékesítési megrendelés adatainak lekéréséhez.In this example, the drillthrough page would include visuals based on a DirectQuery table to retrieve the sales order data.

Az összetett modellek használatának azonban számos biztonsági és a teljesítményt érintő velejárója van.There are, however, many security and performance implications related to Composite models. Erről az Összetett modellek használata a Power BI Desktopban című cikkben talál további tájékoztatást.For further information, read the Use composite models in Power BI Desktop article.

Következő lépésekNext steps

Power BI-beli importálási modell tervezéséről a következő cikkekből tájékozódhat bővebben:For more information about Power BI Import model design, see the following articles: