İçeri Aktarma modellemesi için veri azaltma teknikleriData reduction techniques for Import modeling

Bu makale İçeri Aktarma modelleri geliştiren Power BI Desktop veri modelleyicilerine yöneliktir.This article targets Power BI Desktop data modelers developing Import models. İçeri Aktarma modellerine yüklenen verileri azaltmaya yardımcı olacak farklı teknikler açıklanır.It describes different techniques to help reduce the data loaded into Import models.

İçeri Aktarma modelleri sıkıştırılmış ve iyileştirilmiş verilerle yüklenir, sonra da VertiPaq depolama motoru tarafından diskte depolanır.Import models are loaded with data that is compressed and optimized and then stored to disk by the VertiPaq storage engine. Kaynak veriler belleğe yüklendiğinde 10 kat sıkıştırma görmek mümkündür ve bundan dolayı 10 GB kaynak verinin boyutunun yaklaşık 1 GB'a kadar sıkıştırılması beklenebilir.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. Ayrıca diskte kalıcı hale getirildiğinde fazladan %20 daha azaltma elde edilebilir.Further, when persisted to disk an additional 20% reduction can be achieved.

VertiPaq depolama motoruyla elde edilen verimliliklere karşın, modellerinize yüklenecek olan verileri en aza indirmek için çaba harcamanız önemlidir.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. Bu durum özellikle büyük modeller veya zamanla çok büyümesini beklediğiniz modeller için geçerlidir.It is especially true for large models, or models that you anticipate will grow to become large over time. Dört dikkat çekici nedeni vardır:Four compelling reasons include:

  • Büyük model boyutları kapasiteniz tarafından desteklenmiyor olabilir.Larger model sizes may not be supported by your capacity. Paylaşılan kapasite boyutu en çok 1 GB olan modelleri barındırabilirken, Premium kapasiteler boyutu 13 GB'a kadar olan modelleri barındırabilir.Shared capacity can host models up to 1 GB in size, while Premium capacities can host models up to 13 GB in size. Daha fazla bilgi için Büyük veri kümeleri için Power BI Premium desteği makalesini okuyun.For further information, read the Power BI Premium support for large datasets article.
  • Daha küçük model boyutları kapasite kaynakları, özellikle de bellek için çekişmeyi azaltır.Smaller model sizes reduce contention for capacity resources, in particular memory. Bu sayede daha fazla model daha uzun süreler için eşzamanlı olarak yüklenebildiğinden sonuçta daha düşük çıkarma ücretleri elde edilir.It allows more models to be concurrently loaded for longer periods of time, resulting in lower eviction rates. Daha fazla bilgi için bkz. Premium kapasiteleri yönetme.For more information, see Managing Premium capacities.
  • Daha küçük modeller daha hızlı veri yinelemesi sağladığından düşük gecikme süreli raporlama, daha yüksek veri kümesi yenileme işleme hızı ve kaynak sistemle kapasite kaynakları üzerinde daha az baskı sonucu verir.Smaller models achieve faster data refresh, resulting in lower latency reporting, higher dataset refresh throughput, and less pressure on source system and capacity resources.
  • Tablo satır sayısının daha az olması daha hızlı hesaplama değerlendirmeleri sonucu verebildiğinden bir bütün olarak sorgu performansını artırabilir.Smaller table row counts can result in faster calculation evaluations, which can deliver better overall query performance.

Bu makalede sekiz farklı veri azaltma tekniği ele alınmıştır.There are eight different data reduction techniques covered in this article. Bu teknikler şunları içerir:These techniques include:

Gereksiz sütunları kaldırmaRemove unnecessary columns

Model tablosu sütunları iki ana amaca hizmet eder:Model table columns serve two main purposes:

  • Raporlama, model verilerini uygun şekilde filtreleyen, gruplandıran ve özetleyen rapor tasarımları elde etmek içinReporting, to achieve report designs that appropriate filter, group, and summarize model data
  • Model yapısı, model ilişkilerini, model hesaplamalarını, güvenlik rollerini, hatta veri rengi biçimlendirmesini destekleyerekModel structure, by supporting model relationships, model calculations, security roles, and even data color formatting

Bu amaçlara hizmet etmeyen sütunlar büyük olasılıkla kaldırılabilir.Columns that don't serve these purposes can probably be removed. Raporların kaldırılması dikey filtreleme olarak adlandırılır.Removing columns is referred to as vertical filtering.

Modelleri, bilinen raporlama gereksinimleri temelinde tam olarak doğru sayıda sütunla tasarlamanızı öneririz.We recommend that you design models with exactly the right number of columns based on the known reporting requirements. Gereksinimleriniz zaman içinde değişebilir ama daha sonra sütun eklemenin kaldırmaktan daha kolay olduğunu aklınızda bulundurun.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. Sütunların kaldırılması raporları veya veri modelini bozabilir.Removing columns can break reports or the model structure.

Gereksiz satırları kaldırmaRemove unnecessary rows

Model tabloları mümkün olan en az sayıda satırla yüklenmelidir.Model tables should be loaded with as few rows as possible. İki farklı nedenle model tablolarına filtrelenmiş satır kümeleri yüklenerek bu başarılabilir: varlığa veya zamana göre filtreleme.It can be achieved by loading filtered rowsets into model tables for two different reasons: to filter by entity or by time. Satırların kaldırılması yatay filtreleme olarak adlandırılır.Removing rows is referred to as horizontal filtering.

Varlığa göre filtreleme, kaynak verilerin bir alt kümesini modele yüklemeyi içerir.Filtering by entity involves loading a subset of source data into the model. Örneğin tüm satış bölgelerinin satış olgularını yüklemek yerine tek bir bölgenin olgularını yükleyin.For example, instead of loading sales facts for all sales regions, only load facts for a single region. Bu tasarım yaklaşımının sonucunda birçok küçük model elde edilir ve bu yaklaşım satır düzeyi güvenlik tanımlama gereğini de ortadan kaldırabilir (ama Power BI hizmetinde belirli veri kümesi izinleri verilmesini ve her veri kümesine bağlanan "yinelenen" raporlar oluşturulmasını gerektirecektir).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). Yönetimi ve yayını basitleştirmek için Power Query parametrelerinin ve Power BI Şablon dosyalarının kullanımından yararlanabilirsiniz.You can leverage the use of Power Query parameters and Power BI Template files to simplify management and publication. Daha fazla bilgi için Sorgu Parametrelerine ve Power BI Şablonlarına Derinlemesine Bakış blog girdisini okuyun.For further information, read the Deep Dive into Query Parameters and Power BI Templates blog entry.

Zamana göre filtreleme, olgu türündeki tablolara yüklenen veri geçmişi miktarını sınırlamayı (ve model tarih tablolarına yüklenen tarih satırlarını sınırlamayı) içerir.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). Bilinen bir raporlama gereksinimi olmadıkça tüm kullanılabilir geçmişi otomatik olarak yüklememenizi öneririz.We suggest you don't automatically load all available history, unless it is a known reporting requirement. Zamana dayalı Power Query filtrelerini parametreleştirmenin, hatta göreli dönemleri kullanacak şekilde ayarlamanın (yenileme tarihine göre, örneğin son beş yıl) mümkün olduğunu anlamanız yararlı olabilir.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). Ayrıca zaman filtrelerinde yapılan geçmişe dönük değişikliklerin raporları bozmayacağını; yalnızca raporlarda daha az (veya daha çok) veri geçmişi bulunmasıyla sonuçlanacağını da aklınızda bulundurun.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.

Gruplandırma ve özetlemeGroup by and summarize

Model boyutunu küçültmek için belki de en etkili teknik önceden özetlenmiş verileri yüklemektir.Perhaps the most effective technique to reduce a model size is to load pre-summarized data. Bu teknik olgu türündeki tabloların dilimini yükseltmek için kullanılabilir.This technique can be used to raise the grain of fact-type tables. Öte yandan bunun da ayrıntı kaybı gibi bir bedeli vardır.There is a distinct trade-off, however, resulting in loss of detail.

Örneğin kaynak satışlar olgu tablosunda sipariş satırı başına bir satır depolanır.For example, a source sales fact table stores one row per order line. Tüm satış ölçümlerini özetleyerek, tarihe, müşteriye ve ürüne göre gruplandırarak önemli bir veri azaltması elde edilebilir.Significant data reduction could be achieved by summarizing all sales metrics, grouping by date, customer, and product. Ardından da tarihe göre, ay düzeyinde gruplandırarak daha da önemli bir veri azaltması elde edilebileceğini göz önünde bulundurun.Consider, then, that an even more significant data reduction could be achieved by grouping by date at month level. Bu şekilde modelde %99 azaltma elde etmek mümkün olabilir ancak gün düzeyinde raporlama veya tek tek sipariş düzeyinde raporlama artık mümkün olmayacaktır.It could achieve a possible 99% reduction in model size, but reporting at day level—or individual order level—is no longer possible. Olgu türündeki verilerin özetlenmesiyle ilgili kararların her zaman bir bedeli vardır.Deciding to summarize fact-type data always involves tradeoffs. Karma model tasarımı kullanılarak bu bedel hafifletilebilir ve bu seçenek Karma moda geçiş tekniği altında açıklanır.Tradeoff could be mitigated by a Mixed model design, and this option is described in the Switch to Mixed mode technique.

Sütun veri türlerini iyileştirmeOptimize column data types

VertiPaq depolama motoru her sütun için ayrı veri yapıları kullanır.The VertiPaq storage engine uses separate data structures for each column. Tasarımı gereği bu veri yapıları değer kodlaması kullanan sayısal sütun verilerinde en yüksek iyileştirmeleri getirir.By design, these data structures achieve the highest optimizations for numeric column data, which use value encoding. Öte yandan metin verileri ve diğer sayısal olmayan veriler karma kodlama kullanır.Text and other non-numeric data, however, uses hash encoding. Bunun için depolama motorunun sütunda yer alan her benzersiz metin değerine bir sayısal tanımlayıcı ataması gerekir.It requires the storage engine to assign a numeric identifier to each unique text value contained in the column. Ardından veri yapısında depolanan işte bu sayısal tanımlayıcıdır; depolama ve sorgulama sırasında karma arama gerektirir.It is the numeric identifier, then, that is then stored in the data structure, requiring a hash lookup during storage and querying.

Bazı belirli durumlarda kaynak metin verilerini sayısal değerlere dönüştürebilirsiniz.In some specific instances, you can convert source text data into numeric values. Örneğin satış siparişi numarasında tutarlı olarak bir metin değeri ön eki bulunabilir (örneğin "SO123456").For example, a sales order number may be consistently prefixed by a text value (e.g. "SO123456"). Ön ek kaldırılabilir ve sipariş numarası değeri tam sayıya dönüştürülebilir.The prefix could be removed, and the order number value converted to whole number. Büyük tablolarla, özellikle de sütun benzersiz veya yüksek kardinaliteye sahip değerler içerdiğinde bu uygulama önemli bir veri azaltması sonucu verebilir.For large tables, it can result in significant data reduction, especially when the column contains unique or high cardinality values.

Bu örnekte sütunun Varsayılan Özetleme özelliğini "Özetleme" olarak ayarlamanızı öneririz.In this example, we recommend that you set the column Default Summarization property to "Do Not Summarize". Bu ayar sipariş numarası değerlerinin uygun olmayan şekilde özetlenmesini en aza indirmeye yardımcı olacaktır.It will help to minimize the inappropriate summarization of the order number values.

Özel sütunlar tercihiPreference for custom columns

VertiPaq depolama motoru model hesaplanmış sütunlarını (DAX dilinde tanımlanır) aynı normal Power Query kaynaklı sütunlar gibi depolar.The VertiPaq storage engine stores model calculated columns (defined in DAX) just like regular Power Query-sourced columns. Öte yandan veri yapıları biraz farklı depolanır ve genellikle daha az verimli sıkıştırma yapılabilir.However, the data structures are stored slightly differently, and typically achieve less efficient compression. Ayrıca tüm Power Query tabloları yüklendikten sonra oluşturulur ve bunun sonucunda daha uzun veri yenileme sürelerine neden olabilir.Also, they are built once all Power Query tables are loaded, which can result in extended data refresh times. Dolayısıyla tablo sütunlarını Power Query hesaplanan sütunları (M dilinde tanımlanan) yerine hesaplanan sütunlar olarak eklemek daha az verimlidir.It is therefore less efficient to add table columns as calculated columns than Power Query computed columns (defined in M).

Power Query'de özel sütunlar oluşturmanın tercih edilmesi gerekir.Preference should be creating custom columns in Power Query. Kaynak bir veritabanı olduğunda iki yönden daha fazla yük verimliliği elde edebilirsiniz.When the source is a database, you can achieve greater load efficiency in two ways. Hesaplama SQL deyiminde tanımlanabilir (sağlayıcının yerel sorgu dili kullanılarak) veya veri kaynağında bir sütun olarak gerçekleştirilebilir.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.

Öte yandan bazı durumlarda model hesaplanmış sütunları daha iyi bir seçenek olabilir.However, in some instances, model calculated columns may be the better choice. Formül ölçülerin değerlendirilmesini içerdiğinde veya yalnızca DAX işlevlerinde desteklenen özel modelleme işlevselliği gerektirdiğinde bu durum geçerli olabilir.It can be the case when the formula involves evaluating measures, or it requires specific modeling functionality only supported in DAX functions. Bu tür bir örnekle ilgili bilgi için DAX'ta üst-alt hiyerarşileri için işlevleri anlama makalesine bakın.For information on one such example, refer to the Understanding functions for parent-child hierarchies in DAX article.

Power Query sorgu yükünü devre dışı bırakmaDisable Power Query query load

Diğer sorgularla veri tümleştirmesini desteklemesi hedeflenen Power Query sorguları modele yüklenmemelidir.Power Query queries that are intended support data integration with other queries should not be loaded to the model. Sorgunun modele yüklenmesini önlemek için bu örneklerde sorgu yüklemesinin devre dışı bırakıldığından emin olun.To avoid loading the query to the model, take care to ensure that you disable query load in these instances.

“Yüklemeyi etkinleştir” seçeneğini gösteren, Power Query’nin ekran görüntüsü.

Otomatik tarih/saati devre dışı bırakmaDisable auto date/time

Power BI Desktop'ta Otomatik tarih/saat olarak adlandırılan bir seçenek mevcuttur.Power BI Desktop includes an option called Auto date/time. Bu seçenek etkinleştirildiğinde takvim süreleri için filtreleme, gruplama ve detaylandırma yapılandırma aşamalarında rapor yazarlarına destek olma amacıyla tarih sütunları için gizli bir otomatik tarih/saat tablosu oluşturur.When enabled, it creates a hidden auto date/time table for date columns to support report authors when configuring filters, grouping, and drill down for calendar time periods. Gizli tablolar gerçekte hesaplanmış tablolardır ve modelin boyutunu artıracaktır.The hidden tables are in fact calculated tables that will increase the size of the model. Bu seçeneği kullanma hakkında bilgi edinmek için Power BI Desktop'ta otomatik tarih/saat kılavuzu makalesine bakın.For guidance about using this option, refer to the Auto date/time guidance in Power BI Desktop article.

Karma moda geçişSwitch to Mixed mode

Power BI Desktop'ta Karma mod tasarımı bir Bileşik bir model oluşturur.In Power BI Desktop, a Mixed mode design produces a Composite model. Temelde her tablo için depolama modunu saptamanıza olanak tanır.Essentially, it allows you to determine storage mode for each table. Dolayısıyla her tablonun Import veya DirectQuery olarak ayarlanmış kendi Depolama Modu özelliği olabilir (bir diğer seçenek de Dual'dır).Therefore, each table can have its Storage Mode property set as Import or DirectQuery (Dual is another option).

Model boyutunu küçültmeye yönelik etkili bir teknik daha büyük olgu türündeki tabloların Depolama Modu özelliğini DirectQuery olarak ayarlamaktır.An effective technique to reduce the model size is to set the Storage Mode property for larger fact-type tables to DirectQuery. Bu tasarım yaklaşımının daha önce açıklanan Gruplandırma ve özetleme tekniğiyle birlikte iyi çalışacağını göz önünde bulundurun.Consider that this design approach could work well in conjunction with the Group by and summarize technique introduced earlier. Örneğin, özetlenmiş satış verileri yüksek performanslı "özet" raporu elde etmek için kullanılabilir.For example, summarized sales data could be used to achieve high performance "summary" reporting. Bir detaylandırma sayfasında belirli (ve dar) bir filtre bağlamı için ayrıntılı satışlar ve bağlam içi tüm satış siparişleri görüntülenebilir.A drill through page could display granular sales for specific (and narrow) filter context, displaying all in-context sales orders. Bu örnekte detaylandırma sayfasında satış siparişi verilerini almaya yönelik bir DirectQuery tablosuna dayalı görseller bulunabilir.In this example, the drill through page would include visuals based on a DirectQuery table to retrieve the sales order data.

Bununla birlikte Bileşik modellerle ilgili birçok güvenlik ve performans etkisi söz konusudur.There are, however, many security and performance implications related to Composite models. Daha fazla bilgi için Power BI Desktop'ta bileşik modelleri kullanma makalesini okuyun.For further information, read the Use composite models in Power BI Desktop article.

Sonraki adımlarNext steps

Power BI İçeri Aktarma modeli tasarımı hakkında daha fazla bilgi için aşağıdaki makalelere bakın:For more information about Power BI Import model design, see the following articles: