Speciális növekményes frissítés és valós idejű adatok az XMLA-végponttal
Az olvasási/írási műveletekhez engedélyezett XMLA-végponttal rendelkező prémium szintű kapacitás szemantikai modelljei speciálisabb frissítést, partíciókezelést és metaadat-telepítést tesznek lehetővé az eszközök, szkriptek és API-támogatás révén. Emellett az XMLA-végponton keresztüli frissítési műveletek nem korlátozódnak napi 48 frissítésre, és az ütemezett frissítési időkorlát nincs érvényben.
Partíciók
A szemantikai modell táblapartíciói nem láthatók, és nem kezelhetők a Power BI Desktop vagy a Power BI szolgáltatás használatával. Prémium szintű kapacitáshoz rendelt munkaterületen lévő modellek esetén a partíciók az XMLA-végponton keresztül kezelhetők olyan eszközökkel, mint az SQL Server Management Studio (SSMS), a nyílt forráskódú táblázatos szerkesztő, a táblázatos modell szkriptelési nyelvével (TMSL), és programozott módon a táblázatos objektummodellel (TOM).
Amikor először tesz közzé egy modellt a Power BI szolgáltatás, az új modell minden táblája egy partícióval rendelkezik. Növekményes frissítési szabályzatot nem tartalmazó táblák esetén az egyik partíció az adott tábla összes adatsorát tartalmazza, kivéve, ha szűrőket alkalmaztak. Növekményes frissítési szabályzattal rendelkező táblák esetében az egyik kezdeti partíció csak azért létezik, mert a Power BI még nem alkalmazta a szabályzatot. A kezdeti partíciót a Power BI Desktopban konfigurálhatja, amikor a tábla dátum-/időtartomány-szűrőit a paraméterek és RangeEnd a RangeStart Power Query-szerkesztő alkalmazott egyéb szűrők alapján határozza meg. Ez a kezdeti partíció csak azokat az adatsorokat tartalmazza, amelyek megfelelnek a szűrési feltételeknek.
Az első frissítési művelet végrehajtásakor a növekményes frissítési szabályzattal nem rendelkező táblák frissítik a tábla alapértelmezett egyetlen partíciójában található összes sort. Növekményes frissítési szabályzattal rendelkező táblák esetén a rendszer automatikusan létrehozza a frissítési és előzménypartíciókat, és sorokat tölt be az egyes sorok dátumának/időpontjának megfelelően. Ha a növekményes frissítési szabályzat tartalmazza az adatok valós idejű lekérését, a Power BI egy DirectQuery-partíciót is hozzáad a táblához.
Ez az első frissítési művelet az adatforrásból betöltendő adatok mennyiségétől függően sok időt vehet igénybe. A modell összetettsége is jelentős tényező lehet, mivel a frissítési műveleteknek több feldolgozást és újraszámítást kell végeznie. Ez a művelet elindítható. További információ: Időtúllépések megakadályozása a kezdeti teljes frissítésnél.
A partíciók pontrészletesség szerint vannak létrehozva és elnevezve: Évek, negyedévek, hónapok és napok. A legutóbbi partíciók, a frissítési partíciók a szabályzatban megadott frissítési időszakban tartalmaznak sorokat. Az előzménypartíciók a frissítési időszakig tartó teljes időszak szerint tartalmaznak sorokat. Ha a valós idő engedélyezve van, a DirectQuery-partíciók felveszik a frissítési időszak vége után bekövetkezett adatmódosításokat. A frissítési és előzménypartíciók részletessége a szabályzat meghatározásakor választott frissítési és előzményi (tárolási) időszakoktól függ.
Ha például a mai dátum 2021. február 2., és az adatforrás FactInternetSales táblája a mai napig tartalmaz sorokat, ha a szabályzat valós idejű módosításokat, az utolsó egy napos frissítési időszak sorainak frissítését és az elmúlt három év korábbi időszak sorainak tárolását határozza meg. Ezután az első frissítési művelettel létrejön egy DirectQuery-partíció a jövőbeni változásokhoz, új importálási partíció jön létre a mai sorokhoz, egy előzménypartíció jön létre tegnapra, egy egész napos időszakra, 2021. február 1-ére. A rendszer létrehoz egy előzménypartíciót az előző teljes hónapra (2021. január), egy előzménypartíciót az előző teljes évre (2020), és a 2019- és 2018-ra vonatkozó előzménypartíciókat. Nem jön létre teljes negyedéves partíció, mert még nem fejeztük be 2021 első teljes negyedévét.
Minden frissítési műveletnél csak a frissítési időszak partíciói frissülnek, a DirectQuery-partíció dátumszűrője pedig csak azokat a módosításokat tartalmazza, amelyek az aktuális frissítési időszak után következnek be. Új frissítési partíció jön létre az új sorokhoz, amelyek a frissített frissítési időszakon belül új dátumot/időpontot kapnak, és a frissítési időszakban már meglévő partíciókon belüli dátum/idő sorokat frissíti a rendszer. A frissítési időszaknál régebbi dátumot/időt tartalmazó sorok már nem frissülnek.
A teljes időszakok bezárásakor a partíciók egyesülnek. Ha például egy egynapos frissítési időszak és hároméves előzménytárolási időszak van megadva a szabályzatban, a hónap első napján az előző hónap egész napos partíciói egy hónap partícióba egyesülnek. Az új negyedév első napján a rendszer mind a három előző havi partíciót egyesíti egy negyedéves partícióval. Az új év első napján a rendszer mind a négy előző negyedévi partíciót egy év partícióba egyesíti.
A modell mindig megtartja a partíciókat a teljes előzménytár-időszakhoz, valamint az aktuális frissítési időszakon keresztüli teljes időszak partícióit. A példában a rendszer a 2018-ra, 2019-re és 2020-ra vonatkozó partíciókban, valamint a 2021Q101 hónap, a 2021Q10201 nap és az aktuális napi frissítési időszak partícióiban egy teljes hároméves előzményadatot őriz meg. Mivel a példa három évig őrzi meg az előzményadatokat, a 2018-ra vonatkozó partíció az első frissítésig, 2022. január 1-jén lesz megtartva.
A Power BI növekményes frissítésével és valós idejű adataival a szolgáltatás kezeli a partíciókezelést a szabályzat alapján. Bár a szolgáltatás képes kezelni az összes partíciókezelést, az XMLA-végponton keresztüli eszközökkel külön-külön, egymás után vagy párhuzamosan is frissítheti a partíciókat.
Frissítéskezelés az SQL Server Management Studióval
Az SQL Server Management Studio (SSMS) a növekményes frissítési szabályzatok alkalmazásával létrehozott partíciók megtekintésére és kezelésére használható. Az SSMS használatával például frissíthet egy adott előzménypartíciót, amely nem a növekményes frissítési időszakban történik, így anélkül hajthat végre visszamenőleges frissítést, hogy az összes előzményadatot frissítenie kellene. Az SSMS a nagy modellek előzményadatainak betöltésekor is használható a kötegek előzménypartícióinak növekményes hozzáadásával/frissítésével.
Növekményes frissítési viselkedés felülbírálása
Az SSMS-ben a táblázatos modellszkriptnyelv és a táblázatos objektummodell használatával jobban szabályozhatja a frissítések meghívását. Az SSMS-ben például az Object Explorerben kattintson a jobb gombbal egy táblára, majd válassza a Folyamattábla menüt, majd a Szkript gombra kattintva hozzon létre egy TMSL-frissítési parancsot.
Ezek a paraméterek használhatók a TMSL frissítési parancsával az alapértelmezett növekményes frissítési viselkedés felülbírálásához:
applyRefreshPolicy. Ha egy tábla növekményes frissítési szabályzattal rendelkezik, meghatározza,
applyRefreshPolicyhogy a szabályzat alkalmazva van-e. Ha a szabályzat nincs alkalmazva, a folyamat teljes művelete változatlanul hagyja a partíciódefiníciókat, és a tábla összes partíciója teljesen frissül. Az alapértelmezett érték igaz.effectiveDate. Növekményes frissítési szabályzat alkalmazása esetén ismernie kell az aktuális dátumot a növekményes frissítési és előzményidőszakok gördülőablak-tartományainak meghatározásához. A
effectiveDateparaméter lehetővé teszi az aktuális dátum felülbírálását. Ez a paraméter olyan tesztelési, bemutatók és üzleti forgatókönyvek esetén hasznos, ahol az adatok növekményesen frissülnek a múltban vagy a jövőben, például a jövőbeli költségvetésekben. Az alapértelmezett érték az aktuális dátum.
{
"refresh": {
"type": "full",
"applyRefreshPolicy": true,
"effectiveDate": "12/31/2013",
"objects": [
{
"database": "IR_AdventureWorks",
"table": "FactInternetSales"
}
]
}
}
A TMSL alapértelmezett növekményes frissítési viselkedésének felülbírálásáról további információt a Frissítés parancsban talál.
Optimális teljesítmény biztosítása
Az egyes frissítési műveletek esetén a Power BI szolgáltatás inicializálási lekérdezéseket küldhet az adatforrásnak minden növekményes frissítési partícióhoz. Az inicializálási lekérdezések számának csökkentésével javíthatja a növekményes frissítési teljesítményt az alábbi konfiguráció biztosításával:
- A növekményes frissítést konfiguráló táblázatnak egyetlen adatforrásból kell adatokat lekérnie. Ha a tábla több adatforrásból szerez be adatokat, a szolgáltatás által az egyes frissítési műveletekhez küldött lekérdezések számát megszorozza az adatforrások számával, ami csökkentheti a frissítési teljesítményt. Győződjön meg arról, hogy a növekményes frissítési tábla lekérdezése egyetlen adatforráshoz tartozik.
- Az importálási partíciók növekményes frissítésével és a Direct Query használatával valós idejű adatokkal rendelkező megoldások esetében minden partíciónak egyetlen adatforrásból kell adatokat lekérdeznie.
- Ha a biztonsági követelmények megengedik, állítsa az adatforrás adatvédelmi szintjét szervezeti vagy nyilvános értékre. Alapértelmezés szerint az adatvédelmi szint privát, de ez a szint megakadályozhatja az adatok más felhőforrásokkal való cseréjét. Az adatvédelmi szint beállításához válassza a További beállítások menüt, majd válassza a Gépház> Adatforrás hitelesítő adatainak>>szerkesztése az adatforrás adatvédelmi szintjének beállítását. Ha az adatvédelmi szint a Power BI Desktop-modellben van beállítva a szolgáltatásban való közzététel előtt, az nem lesz átadva a szolgáltatásnak a közzétételkor. A szolgáltatás szemantikai modellbeállításaiban továbbra is meg kell adnia. További információ: Adatvédelmi szintek.
- Helyszíni adatátjáró használata esetén győződjön meg arról, hogy a 3000.77.3-s vagy újabb verziót használja.
Időtúllépések megakadályozása a kezdeti teljes frissítés során
Miután közzétette a Power BI szolgáltatás, a modell kezdeti teljes frissítési művelete partíciókat hoz létre a növekményes frissítési táblához, betölti és feldolgozza az előzményadatokat a növekményes frissítési szabályzatban meghatározott teljes időszakra vonatkozóan. A nagy mennyiségű adatot betöltő és feldolgozó modellek esetében a kezdeti frissítési művelet időtartama meghaladhatja a szolgáltatás által előírt frissítési időt, vagy az adatforrás által előírt lekérdezési időkorlátot.
A kezdeti frissítési művelet indítása lehetővé teszi, hogy a szolgáltatás partícióobjektumokat hozzon létre a növekményes frissítési táblához, de az előzményadatokat nem töltheti be és dolgozza fel egyik partícióba sem. Az SSMS ezután a partíciók szelektív feldolgozására szolgál. Az egyes partíciókhoz betöltendő adatok mennyiségétől függően az egyes partíciókat egymás után vagy kis kötegekben is feldolgozhatja, hogy csökkentse az időtúllépés lehetőségét egy vagy több partíció esetében. Az alábbi módszerek bármilyen adatforrás esetében működnek.
Frissítési szabályzat alkalmazása
A nyílt forráskódú Táblázatszerkesztő 2 eszköz egyszerű módot kínál a kezdeti frissítési művelet elindítására. Miután közzétett egy olyan modellt, amelynek növekményes frissítési szabályzata van meghatározva a Power BI Desktopból a szolgáltatásba, csatlakozzon a modellhez az XMLA-végponttal olvasási/írási módban. Futtassa a Frissítési szabályzat alkalmazása parancsot a növekményes frissítési táblán. Csak a szabályzat alkalmazása esetén a rendszer partíciókat hoz létre, de nem tölt be adatokat. Ezután csatlakozzon az SSMS-hez a partíciók egymás utáni vagy kötegekben történő frissítéséhez az adatok betöltéséhez és feldolgozásához. További információ: Növekményes frissítés a Táblázatszerkesztő dokumentációjában.
Üres partíciók Power Query-szűrője
A modell szolgáltatásban való közzététele előtt Power Query-szerkesztő adjon hozzá egy másik szűrőt az ProductKey oszlophoz, amely a 0-tól eltérő értékeket szűri, hatékonyan vagy szűrve az összes adatot a FactInternetSales táblából.
Miután kiválasztotta a Bezárás &alkalmazás lehetőséget Power Query-szerkesztő, meghatározta a növekményes frissítési szabályzatot, és mentette a modellt, a modell közzé lesz téve a szolgáltatásban. A szolgáltatásból a kezdeti frissítési művelet a modellen fut. A FactInternetSales tábla partíciói a szabályzatnak megfelelően jönnek létre, de a rendszer nem tölt be és dolgoz fel adatokat, mert az összes adat ki van szűrve.
A kezdeti frissítési művelet befejeződése után a rendszer eltávolítja az oszlop másik szűrőjének ProductKey Power Query-szerkesztő. Miután kiválasztotta a Bezárás &alkalmazás lehetőséget Power Query-szerkesztő, és mentette a modellt, a modell nem lesz újból közzétéve. Ha a modell ismét közzé van téve, felülírja a növekményes frissítési szabályzat beállításait, és teljes frissítést kényszerít a modellre, amikor egy későbbi frissítési műveletet hajt végre a szolgáltatásból. Ehelyett csak metaadat-üzembe helyezést hajtson végre az alkalmazás életciklus-kezelési (ALM) eszközkészletével, amely eltávolítja a szűrőt az ProductKey oszlopból a modellből. Az SSMS ezután a partíciók szelektív feldolgozására használható. Ha az összes partíció teljesen fel lett dolgozva, amelynek tartalmaznia kell egy folyamat újraszámítását az összes partíción az SSMS-ből, a modell későbbi frissítési műveletei csak a növekményes frissítési partíciókat frissítik.
Tipp.
Mindenképpen tekintse meg a Power BI szakértőinek közössége által biztosított videókat, blogokat és egyebeket.
Ha többet szeretne megtudni a táblák és partíciók SSMS-ből történő feldolgozásáról, olvassa el az adatbázis, a tábla vagy a partíciók (Analysis Services) feldolgozását ismertető témakört. A modellek, táblák és partíciók TMSL használatával történő feldolgozásáról további információt a Frissítés parancs (TMSL) című témakörben talál.
Egyéni lekérdezések az adatváltozások észleléséhez
A TMSL és a TOM az észlelt adatváltozások viselkedésének felülbírálására használható. Ez a módszer nem csak az utolsó frissítési oszlop memóriabeli gyorsítótárban való megőrzésének elkerülésére használható, hanem olyan forgatókönyveket is lehetővé tehet, amelyekben egy konfigurációs vagy utasítástáblát kinyerési, átalakítási és betöltési (ETL) folyamatok készítenek, hogy csak a frissíteni kívánt partíciókat jelöljék meg. Ez a módszer hatékonyabb növekményes frissítési folyamatot hozhat létre, ahol csak a szükséges időszakok frissülnek, függetlenül attól, hogy mennyi ideig történtek adatfrissítések.
Ez pollingExpression egy egyszerű M-kifejezés vagy egy másik M-lekérdezés neve. Skaláris értéket kell visszaadnia, és minden partícióhoz végre kell hajtania. Ha a visszaadott érték eltér az utolsó növekményes frissítés időpontjától, a partíciót a rendszer a teljes feldolgozáshoz megjelöli.
Az alábbi példa a háttérrendszerbeli változások előzményidőszakában eltelt 120 hónapot ismerteti. Ha 10 év helyett 120 hónapot ad meg, az azt jelenti, hogy az adattömörítés nem feltétlenül olyan hatékony, de elkerüli, hogy egy teljes előzményévet frissítsen, ami drágább lenne, ha egy hónap elegendő lenne egy háttérbeli változáshoz.
"refreshPolicy": {
"policyType": "basic",
"rollingWindowGranularity": "month",
"rollingWindowPeriods": 120,
"incrementalGranularity": "month",
"incrementalPeriods": 120,
"pollingExpression": "<M expression or name of custom polling query>",
"sourceExpression": [
"let ..."
]
}
Tipp.
Mindenképpen tekintse meg a Power BI szakértőinek közössége által biztosított videókat, blogokat és egyebeket.
Csak metaadatok üzembe helyezése
Amikor egy .pbix-fájl új verzióját teszi közzé a Power BI Desktopból egy munkaterületre, ha már létezik azonos nevű modell, a rendszer kérni fogja a meglévő modell cseréjét.
Bizonyos esetekben előfordulhat, hogy nem szeretné lecserélni a modellt, különösen növekményes frissítésre. A Power BI Desktopban a modell sokkal kisebb lehet, mint a Power BI szolgáltatás. Ha a modell a Power BI szolgáltatás növekményes frissítési szabályzatot alkalmaz, előfordulhat, hogy több évnyi előzményadattal rendelkezik, amelyek elvesznek a modell lecserélése esetén. Az összes előzményadat frissítése órákat is igénybe vehet, és a rendszer leállását eredményezheti a felhasználók számára.
Ehelyett jobb, ha csak metaadat-telepítést hajt végre, amely lehetővé teszi az új objektumok üzembe helyezését az előzményadatok elvesztése nélkül. Ha például hozzáadott néhány mértéket, csak az új mértékeket helyezheti üzembe anélkül, hogy frissítenie kellene az adatokat, így időt takaríthat meg.
Az XMLA-végpont olvasásához/írásához konfigurált Premium-kapacitáshoz rendelt munkaterületek esetében a kompatibilis eszközök csak a metaadatok üzembe helyezését teszik lehetővé. Az ALM-eszközkészlet például a Power BI-modellek sémadiffiáló eszköze, és csak a metaadatok üzembe helyezésére használható.
Töltse le és telepítse az ALM-eszközkészlet legújabb verzióját az Analysis Services Git-adattárból. Az ALM Toolkit használatáról a Microsoft dokumentációja nem tartalmaz részletes útmutatást. Az ALM-eszközkészlet dokumentációjának hivatkozásai és a támogatással kapcsolatos információk a súgó menüszalagján érhetők el. Ha csak metaadat-telepítést szeretne végrehajtani, végezzen összehasonlítást, és válassza ki a futó Power BI Desktop-példányt forrásként, a meglévő modellt pedig a Power BI szolgáltatás célként. Vegye figyelembe a megjelenített különbségeket, és hagyja ki a tábla frissítését növekményes frissítési partíciókkal, vagy használja a Beállítások párbeszédpanelt a táblafrissítések partícióinak megőrzéséhez. Ellenőrizze a kijelölést a célmodell integritásának biztosításához, majd frissítsen.
Növekményes frissítési szabályzat és valós idejű adatok hozzáadása programozott módon
A TMSL és a TOM használatával növekményes frissítési szabályzatot is hozzáadhat egy meglévő modellhez az XMLA-végponton keresztül.
Feljegyzés
A kompatibilitási problémák elkerülése érdekében győződjön meg arról, hogy az Analysis Services ügyfélkódtárainak legújabb verzióját használja. A hibrid szabályzatok használatához például a verziónak 19.27.1.8-nak vagy újabbnak kell lennie.
A folyamat a következő lépéseket tartalmazza:
Győződjön meg arról, hogy a célmodell rendelkezik a minimális kompatibilitási szinttel. Az SSMS-ben kattintson a jobb gombbal a [modell neve]>Tulajdonságok>kompatibilitási szintje elemre. A kompatibilitási szint növeléséhez használjon createOrReplace TMSL-szkriptet, vagy ellenőrizze a következő TOM-mintakódot egy példához.
a. Import policy - 1550 b. Hybrid policy - 1565Adja hozzá a
RangeStartmodellkifejezésekhez a paramétereket ésRangeEnda paramétereket. Ha szükséges, adjon hozzá egy függvényt is a dátum/idő értékek dátumkulcsokká alakításához.Definiáljon egy
RefreshPolicyobjektumot a kívánt archiválási (gördülő) és növekményes frissítési időszakokkal, valamint egy forráskifejezéssel, amely a céltáblát szűri a paraméterek ésRangeEndaRangeStartparaméterek alapján. Állítsa a frissítési szabályzat módját importálásra vagy hibridre a valós idejű adatkövetelményektől függően. A hibrid funkció miatt a Power BI directQuery-partíciót ad hozzá a táblához, hogy lekérje az adatforrás legutóbbi módosításait, amelyek az utolsó frissítési időpont után történtek.Adja hozzá a frissítési szabályzatot a táblához, és végezzen teljes frissítést, hogy a Power BI a követelményeknek megfelelően particionálja a táblát.
Az alábbi kódminta bemutatja, hogyan hajthatja végre az előző lépéseket a TOM használatával. Ha ezt a mintát a következőképpen szeretné használni, rendelkeznie kell egy másolattal az AdventureWorksDW-adatbázishoz, és importálnia kell a FactInternetSales táblát egy modellbe. A kódminta feltételezi, hogy a RangeStart paraméterek és RangeEnd a DateKey függvény nem léteznek a modellben. Csak importálja a FactInternetSales táblát, és tegye közzé a modellt egy munkaterületen a Power BI Premiumban. Ezután frissítse a workspaceUrl kódot, hogy a kódminta kapcsolódni tud a modellhez. Szükség szerint frissítse a további kódsorokat.
using System;
using TOM = Microsoft.AnalysisServices.Tabular;
namespace Hybrid_Tables
{
class Program
{
static string workspaceUrl = "<Enter your Workspace URL here>";
static string databaseName = "AdventureWorks";
static string tableName = "FactInternetSales";
static void Main(string[] args)
{
using (var server = new TOM.Server())
{
// Connect to the dataset.
server.Connect(workspaceUrl);
TOM.Database database = server.Databases.FindByName(databaseName);
if (database == null)
{
throw new ApplicationException("Database cannot be found!");
}
if(database.CompatibilityLevel < 1565)
{
database.CompatibilityLevel = 1565;
database.Update();
}
TOM.Model model = database.Model;
// Add RangeStart, RangeEnd, and DateKey function.
model.Expressions.Add(new TOM.NamedExpression {
Name = "RangeStart",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 30, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "RangeEnd",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 31, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "DateKey",
Kind = TOM.ExpressionKind.M,
Expression =
"let\n" +
" Source = (x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)\n" +
"in\n" +
" Source"
});
// Apply a RefreshPolicy with Real-Time to the target table.
TOM.Table salesTable = model.Tables[tableName];
TOM.RefreshPolicy hybridPolicy = new TOM.BasicRefreshPolicy
{
Mode = TOM.RefreshPolicyMode.Hybrid,
IncrementalPeriodsOffset = -1,
RollingWindowPeriods = 1,
RollingWindowGranularity = TOM.RefreshGranularityType.Year,
IncrementalPeriods = 1,
IncrementalGranularity = TOM.RefreshGranularityType.Day,
SourceExpression =
"let\n" +
" Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW\"),\n" +
" dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],\n" +
" #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= DateKey(RangeStart) and [OrderDateKey] < DateKey(RangeEnd))\n" +
"in\n" +
" #\"Filtered Rows\""
};
salesTable.RefreshPolicy = hybridPolicy;
model.RequestRefresh(TOM.RefreshType.Full);
model.SaveChanges();
}
Console.WriteLine("{0}{1}", Environment.NewLine, "Press [Enter] to exit...");
Console.ReadLine();
}
}
}