Analitika360
Power BI suplanuotas atnaujinimas: limitai ir nustatymai
Taip, Power BI palaiko suplanuotus atnaujinimus, tačiau leidžiamas kiekis priklauso nuo licencijos: Pro planas leidžia iki 8 atnaujinimų per dieną, o Premium, PPU ar Fabric talpos leidžia gerokai daugiau suplanuotų atnaujinimų per dieną. Jungiantis prie vietinių duomenų šaltinių (Rivilė, Finvalda, lokalios SQL bazės) dažniausiai reikės ir on‑premises data gateway. Toliau rasite konkrečius UI ir API žingsnius, kaip nustatyti tvarkaraštį patiems.
Trumpai:
- Power BI Pro leidžia iki 8 suplanuotų atnaujinimų per dieną, o Premium, PPU ar Fabric talpos šį limitą padidina iki 48.
- Vietinių duomenų šaltinių jungimui dažniausiai reikalingas on-premises data gateway, o debesyje esančioms sistemoms jis nėra būtinas.
- Jei atnaujinimai vėluoja ar nepavyksta, dažniausiai kaltas pasenęs gateway, apkrovos padidėjimas arba dataset’o neaktyvumas daugiau nei du mėnesius.
- Programiškai tvarkaraštį galima keisti naudojant Power BI REST API, nurodant dienas, laikus ir pranešimų parinktis.
- Automatinio atnaujinimo diegimo ir valdymo paslaugas teikia įmonė Analitika360, siūlanti paruoštus sprendimus su iš anksto sukonfigūruotu gateway ir monitoringais.
Turinys
- Kaip sukonfigūruoti suplanuotą atnaujinimą Power BI portale
- Licencijos ir limitai: ką planuodami atnaujinimus turite žinoti
- Data gateway: kada jis reikalingas ir kurią konfigūraciją rinktis
- Gerosios praktikos suplanuotiems atnaujinimams
- Dažniausios klaidos ir greiti jų sprendimai
- API ir automatizacija: programinis refreshSchedule valdymas
- Analitika360 praktika: kaip įdiegiame patikimą atnaujinimų procesą
- Redakcijos perspektyva: kada automatizuoti atnaujinimus yra verslo pokytis
- Kaip Analitika360 gali padėti suplanuotus atnaujinimus paleisti be priežiūros
- Šaltiniai
- Dažniausiai užduodami klausimai
Kaip sukonfigūruoti suplanuotą atnaujinimą Power BI portale
Power BI atnaujinimo planavimas prasideda ne raporte, o dataset’o nustatymuose. Eikite į „Power BI Service“, atsidarykite darbo sritį, kurioje laikomas dataset’as, ir suraskite jį sąraše.
- Prie dataset’o pavadinimo spauskite tris taškelius ir pasirinkite Settings.
- Skiltyje Scheduled refresh įjunkite jungiklį ir pasirinkite dažnumą: kartą per dieną ar keliskart per dieną.
- Nustatykite laiko juostą (svarbu, jei serveris ir vartotojai skirtinguose regionuose) ir konkrečius laikus, kada turi vykti atnaujinimas.
- Pridėkite el. pašto adresą pranešimams apie klaidas (
notifyOptionreikšmė API lygmenyje) arba pasirinkite gauti pranešimą tik dataset’o savininkui. - Jei duomenų šaltinis yra didelė lentelė su nuolat augančia istorija, įjunkite incremental refresh politiką. Ji atnaujina tik naujus arba pasikeitusius duomenų segmentus, todėl atnaujinimo trukmė sutrumpėja net keliomis dešimtimis minučių palyginti su pilnu atnaujinimu.
Prieš patvirtinant tvarkaraštį, paspauskite Refresh now ir palaukite, kol procesas pasibaigs. Tada patikrinkite Refresh history, kur matomas trukmės laikas ir galimos klaidos. Šis vienas testas atskleidžia daugumą kredencialų ar gateway problemų anksčiau, nei jos pasikartoja automatiškai kiekvieną naktį.
Licencijos ir limitai: ką planuodami atnaujinimus turite žinoti
Pro licencijos limitas yra fiksuotas ir aiškus: 8 suplanuoti atnaujinimai per dieną vienam dataset’ui. Premium, Premium Per User (PPU) ir Fabric talpos šį skaičių pakelia iki 48 per dieną, praktiškai leidžiant atnaujinti duomenis kas 30 minučių visą darbo dieną.
Vykdymo trukmė taip pat skiriasi. Bendros (shared) talpos aplinkoje atnaujinimas turi laiko limitą, po kurio procesas nutrūksta, jei duomenų kiekis pernelyg didelis. Premium talpose šis limitas didesnis, nes resursai skiriami dedikuotai, o ne bendrinami su kitais nuomininkais.
Jei 48 atnaujinimų per dieną neužtenka, sprendimas dažniausiai nėra „daugiau suplanuotų atnaujinimų“, bet architektūros pokytis: DirectQuery, XMLA endpoint’ų naudojimas arba kelių talpų paskirstymas tarp padalinių. Verta atminti, kad ir rankiniu būdu paleisti atnaujinimai, ir per REST API iškviesti atnaujinimai skaičiuojami į tuos pačius dienos limitus, ne atskirai.
Data gateway: kada jis reikalingas ir kurią konfigūraciją rinktis
On‑premises data gateway reikalingas visada, kai Power BI jungiasi prie duomenų, kurie fiziškai nėra debesyje, arba prie šaltinių privačiame tinkle. Tipiniai atvejai Lietuvos verslui: lokaliai įdiegta Rivilė duomenų bazė, Finvalda SQL serveris biuro tinkle arba failų serveris su Excel ataskaitomis.
Rinkdamiesi konfigūraciją, turėkite šiuos skirtumus:
- Personal gateway tinka vienam autoriui ir tik import operacijoms, be galimybės dalintis su kolegomis.
- Standard gateway valdomas centralizuotai, palaiko kelis vartotojus ir yra tinkamas įmonės lygmens diegimui.
- VNet gateway naudojamas, kai duomenys yra Azure virtualiame tinkle, ir eliminuoja poreikį valdyti fizinę virtualią mašiną.
Profesionalus patarimas: Jei turite ir Import, ir DirectQuery modelius, laikykite juos ant atskirų gateway klasterių. Vienas perkrautas DirectQuery ryšys gali sulėtinti visos organizacijos importo atnaujinimus.
Didesnėms organizacijoms verta iš anksto planuoti gateway klasterizaciją, nes kelios virtualios maszinos vienam gateway sumažina vieno įrenginio gedimo riziką. Tai planuojama diegimo pradžioje, kartu su Power BI diegimo strategija, o ne pridedama vėliau kaip pataisa.
Gerosios praktikos suplanuotiems atnaujinimams
Atnaujinimų strategija, kuri veikia stabiliai metų metus, dažniausiai remiasi keturiais principais.
- Naudokite incremental refresh visoms lentelėms, kurios turi datos stulpelį ir auga kasdien, ne tik didžiausiems faktų lentelėms.
- Paskirstykite atnaujinimų laikus per dieną, o ne suplanuokite juos visus 8 val. ryto — tai sumažina talpos apkrovą tuo metu, kai vartotojai pradeda darbą.
- Įjunkite el. pašto pranešimus apie klaidas kiekvienam kritiniam dataset’ui, o ne pasitikėkite, kad kas nors pastebės tuščią ataskaitą.
- Periodiškai testuokite tvarkaraštį po kiekvieno duomenų šaltinio struktūros pakeitimo, nes tyliai sulūžęs ryšys dažnai pastebimas tik per savaitę.
Vienas dažnai nuvertinamas faktas: Power BI siekia pradėti suplanuotą atnaujinimą per 15 minučių nuo nustatyto laiko, tačiau esant resursų trūkumui vėlavimas gali siekti iki valandos. Jei dataset’as ilgiau nei du mėnesius nebuvo naudojamas, jo suplanuotas atnaujinimas gali būti automatiškai pristabdytas. Tokia „tyli“ pauzė yra viena dažniausių priežasčių, kodėl vadovas pamato pasenusius skaičius ir nesupranta, kodėl.
Dažniausios klaidos ir greiti jų sprendimai
Kai atnaujinimas nepavyksta, IT komanda turėtų tikrinti priežastis šia tvarka, nes ji atspindi realų klaidų dažnumą.
- Patikrinkite gateway būseną. Jei gateway offline arba kredencialai pasenę, atnaujinimas nutrūks iškart. Po kredencialų pakeitimo galimas kelių valandų uždelsimas dėl prisijungimų kešavimo, tad nelaukite, kad pataisa suveiktų per minutę.
- Atidarykite Refresh history. Detali klaidos žinutė dažnai nurodo konkretų stulpelį, ryšio timeout’ą ar teisių problemą, kurios generinis pranešimas neparodo.
- Įvertinkite talpos apkrovą. Jei keli dataset’ai atsinaujina tuo pačiu metu Premium talpoje, atnaujinimai patenka į eilę (queueing) ir vykdomi ilgiau nei paprastai.
- Laikinai išjunkite tvarkaraštį, jei šaltinis remontuojamas, o po pataisos paleiskite Refresh now, kad patikrintumėte prieš vėl įjungdami automatinį planą.
API ir automatizacija: programinis refreshSchedule valdymas
Power BI REST API leidžia keisti tvarkaraštį programiškai per PATCH užklausą į refreshSchedule endpoint’ą. Užklausoje galima nurodyti days, times, enabled, localTimeZoneId ir notifyOption reikšmes, todėl visą tvarkaraštį galima perrašyti be portalo sąsajos.
DirectQuery ir LiveConnection modeliams naudojamas atskiras endpoint, kuriame dažnumas nustatomas minutėmis: 15, 30, 60, 120 arba 180. Tai naudinga, kai dataset’ą reikia atnaujinti rečiau nei standartinis Import limitas leistų, pavyzdžiui, kartą per mėnesį per Power Automate scenarijų. API iškvietimui reikalinga dataset’o savininko teisė arba atitinkama darbo srities rolė, todėl automatizacijos scenarijų kūrimą verta patikėti asmeniui, turinčiam administravimo prieigą.
Analitika360 praktika: kaip įdiegiame patikimą atnaujinimų procesą
Diegiant Power BI sprendimus klientams, kurių duomenys laikomi Rivilė arba Finvalda sistemose, procesas dažniausiai vyksta pagal vieną schemą: pirmiausia įdiegiamas standard mode gateway biuro tinkle, tada modeliuose įjungiamas incremental refresh didžiausioms lentelėms, po to tvarkaraštis testuojamas kelias dienas prieš paleidžiant automatinį monitoringą su pranešimais apie klaidas.
Restoranų tinklams ir logistikos įmonėms, kur pardavimų duomenys keičiasi kelis kartus per dieną, dažnai renkamės tankesnį atnaujinimo grafiką darbo valandomis ir retesnį naktį. Buhalterinių paslaugų įmonėms, dirbančioms su Finvalda integracija, pakanka vieno atnaujinimo ryte, nes duomenys apskaitos sistemoje keičiasi rečiau. Kiekvienu atveju tikslas tas pats: kad ataskaita atsinaujintų savaime, o ne po rankinio paspaudimo.
Redakcijos perspektyva: kada automatizuoti atnaujinimus yra verslo pokytis
Automatizuotas atnaujinimo tvarkaraštis nustoja būti tik techniniu patogumu tada, kai sprendimų priėmimas pradeda remtis pasenusiais skaičiais. Jei įmonė artėja prie Pro licencijos 8 atnaujinimų limito arba turi kelis padalinius, kuriems reikia skirtingo dažnumo, tai signalas peržiūrėti talpos strategiją ir centralizuotą gateway valdymą, o ne kantriai laukti kitos ribos.
— Analitika360
Kaip Analitika360 gali padėti suplanuotus atnaujinimus paleisti be priežiūros
Yra tiek bendro Power BI diegimo, tiek paruoštų ataskaitų paketų su automatiniu atnaujinimu, integruotu tiesiai su Rivilė ar Finvalda duomenų baze.
Tai reiškia, kad jums nereikia patiems derinti gateway režimo, incremental refresh politikos ar klaidų pranešimų. Diegimo metu komanda sukonfigūruoja tvarkaraštį, patikrina duomenų šaltinius ir įjungia monitoringą, kad ataskaita realiu laiku rodytų pajamas, sąnaudas ir pelną be jokio papildomo paspaudimo. Tam tikroms įmonėms tai reiškia mažiau laiko, skiriamo failų tvarkymui, ir daugiau laiko strateginiams sprendimams. Peržiūrėkite verslo analitikos sprendimus pagal veiklos sritį arba susisiekite per Power BI diegimo puslapį, kad sužinotumėte, kokia konfigūracija tiktų jūsų duomenų šaltiniams.
Dažniausiai užduodami klausimai
Kiek suplanuotų atnaujinimų per dieną leidžia Power BI Pro?
Pro licencija leidžia iki 8 suplanuotų atnaujinimų per dieną vienam dataset’ui, o Premium, PPU ar Fabric talpos šį limitą padidina iki 48.
Ar suplanuotam atnaujinimui visada reikia data gateway?
Gateway reikalingas tik jungiantis prie vietinių ar privataus tinklo šaltinių, tokių kaip Rivilė ar Finvalda serveriai biure; debesyje esantiems šaltiniams jis nereikalingas.
Kodėl suplanuotas atnaujinimas vėluoja ar nepasileidžia?
Dažniausios priežastys yra pasenę gateway kredencialai, talpos apkrova tuo pačiu laiku arba dataset’o neaktyvumas ilgiau nei du mėnesius, kurio metu Power BI automatiškai sustabdo tvarkaraštį.
Kaip pakeisti atnaujinimo tvarkaraštį programiškai?
Naudokite REST API PATCH užklausą į refreshSchedule endpoint’ą, kur galima nustatyti dienas, laikus, dažnumą ir pranešimų parinktis.
Ar Analitika360 padeda sukonfigūruoti automatinius atnaujinimus?
Taip, Analitika360 diegia paruoštus Power BI ataskaitų paketus su iš anksto sukonfigūruotu gateway, incremental refresh ir klaidų monitoringu, integruotu su Rivilė ar Finvalda duomenimis.
