Power Query of Power BI-gegevensstromen
Power bi biedt vele voordelen. Zo kunnen meerlaagse en geavanceerde selfservice-oplossingen worden ontworpen door de transformatiequery’s te scheiden van het gegevensmodel met behulp van Power BI-gegevensstromen. Dit zijn door de server gehoste Power Query/M-query’s die zowel zijn ontworpen als beheerd in de Power BI-service.
Gegevensstromen leggen verschillende integraties met de Microsoft Azure-cloudservices bloot, zoals de Common Data Service en Azure Data Lake Gen2 Storage. Gegevensstromen hebben ook integraties met AutoML-modellen voor machine learning.
Voor-en nadelen
De voor- en nadelen van gegevensstromen moeten zorgvuldig worden overwogen voordat je begint. Power Query in Power BI dashbord is een snelle, juiste ontwikkelomgeving voor query’s die vrijwel onmiddellijke feedback biedt. Daarentegen is de browsergebaseerde ontwerpfunctie voor gegevensstromen vergelijkbaar in functie, maar langzamer en heeft een minder robuuste reeks functies voor het ontwerpen van query’s.
Sommige ontwikkelaars kiezen ervoor om Power Query in Desktop te ontwikkelen en vervolgens hun M-querycode naar gegevensstromen over te dragen.
Parameters
Als grote tabellen te lang duren om te laden of ervoor zorgen dat het PBIX-bestand een redelijke grootte voor ontwikkeling overschrijdt (niet meer dan 500 MB), gebruik dan parameters om het bereik van records te beperken. Voer één van de volgende handelingen uit om de tabelgrootte te beheren nadat deze is geïmplementeerd voor de service.
Gebruik parameters voor begin- en einddatumbereik om een kolom van het type Datum of Datum/tijd in de tabel te filteren. Gebruik dit om de werkset op de ontwikkeldesktop te beperken en vervolgens om het bereik van records in de service uit te breiden.
Gebruik, net als bij stap één, een paar datum/tijd-parameters met een bereikfilter in een kolom van het type Datum/Tijd en volg de productdocumentatie om incrementele vernieuwing te implementeren. Hierdoor worden de tabelrecords automatisch gepartitioneerd op gespecificeerde kalenderdatumdelen (bijv. weken, maanden, jaren) en worden dan alleen wijzigingen geladen.
Bedenk een strategie voor het partitioneren van tabellen en implementeer partities met de Tabular Editor. Gebruik PowerShell of het XMLA lees-/schrijfeindpunt om het TMSL- of XMLA-script te plannen en uit te voeren om partitieverwerking te beheren.
Gegevensmodellering
Veel modelleringstechnieken die goed presteren wanneer ze worden getest op kleine datasets, zullen vertragen met grote tabellen. Deze omvatten relaties op overbruggingstabellen, veel-op-veel-relaties, bidirectionele relatiefilters en gelaagde berekeningen met meerdere metingen.
Vermijd het gebruik van SWITCH-instructies over reeds complexe DAX-expressies of meetwaarden waarnaar wordt verwezen. Vermijd het gebruik van iteratorfuncties (zoals SUMX) met complexe rij-voor-rij predikaatlogica. Het scheiden van berekeningslogica in afzonderlijke metingen is een handig ontwerppatroon om bedrijfslogica te scheiden, maar het kan prestatieknelpunten creëren. Identificeer langzame maatregelen en overweeg om gestroomlijnde maatregelen te bouwen met behulp van alternatieve patronen wanneer knelpunten worden ontdekt.
Direct Query
Tabellen in de importmodus zijn over het algemeen sneller en flexibeler dan tabellen in de DirectQuery-modus. DirectQuery is echter een goede optie voor zeer lange transactietabellen waarin eenvoudige aggregaties worden gebruikt in plaats van complexe DAX-metingen.
Als tabellen in de Import- en DirectQuery-modus beide worden gebruikt in een samengesteld gegevensmodel, kun je overwegen een overzichtstabel te maken met behulp van het importmodel en een detailtabel met behulp van DQ en vervolgens aggregaten te definiëren om bepaalde queryresultaten in het geheugen te cachen (om te compenseren voor de normale prestatievermindering die resulteert uit de vertaling van de zoekopdracht in DirectQuery.)
Er is nog zoveel meer te bespreken, want de mogelijkheden van Power BI rapportage zijn nog omvattender dan wat is besproken.