Power BI duomenų šliuzas: kaip veikia ir kaip jį įdiegti

Power BI duomenų šliuzas yra saugus tiltas tarp vietinių duomenų šaltinių ir Power BI debesies, leidžiantis ataskaitoms atsinaujinti be duomenų perkėlimo į debesį. Jis naudoja tik išeinančius (outbound) ryšius, todėl įmonės ugniasienė nereikalauja papildomų atidarytų prievadų. Praktikoje egzistuoja trys šliuzo režimai:

• Standartinis – daugelio vartotojų, daugelio šaltinių sprendimas įmonėms.
• Asmeninis – skirtas vienam vartotojui, nedalinamas su komanda.
• VNet (virtualaus tinklo) šliuzas – be atskiro serverio, tinka aplinkoms su padidintais privatumo reikalavimais.

Kiekvienas iš jų sprendžia skirtingą problemą, o teisingo pasirinkimas priklauso nuo to, kiek vartotojų naudosis duomenimis ir kiek griežta jūsų organizacijos duomenų valdymo politika.

Pagrindinės išvados

Power BI duomenų šliuzas veikia patikimai tik tada, kai jo tipas, konfigūracija ir sizing atitinka realų vartotojų skaičių ir DirectQuery apkrovą, ne bendrą šabloną.

Turinys

• Kaip power bi duomenų šliuzas techniškai užtikrina duomenų srautus ir saugumą
• Šliuzų tipai: standartinis, asmeninis ir VNet šliuzas
• Kada rinktis standartinį šliuzą, o kada – asmeninį
• Techniniai reikalavimai ir sizing sprendimams
• Kaip pagerinti šliuzo našumą praktiškai
• Diegimo kontrolinis sąrašas žingsnis po žingsnio
• Kaip Analitika360 diegia ir optimizuoja duomenų šliuzus klientams
• Ką dažniausiai pameta iš akių Power BI naudotojai
• Kodėl rinktis Analitika360 Power BI šliuzo diegimui
• Šaltiniai

Kaip power bi duomenų šliuzas techniškai užtikrina duomenų srautus ir saugumą

Šliuzas neatidaro jokio įeinančio ryšio – jis pats inicijuoja ryšį su Microsoft debesimi per Azure Service Bus/Relay infrastruktūrą. Tai reiškia, kad jūsų IT skyrius nebeturi kurti sudėtingų VPN tunelių ar atidaryti pavojingų prievadų vien tam, kad Power BI galėtų pasiekti Rivilės ar Finvaldos duomenų bazę.

Prisijungimo kredencialai šifruojami ir laikomi taip, kad dešifravimas įvyksta tik pačiame šliuzo kompiuteryje – Microsoft debesis jų niekada nemato atviru tekstu.

Statistika: Microsoft dokumentacija patvirtina, kad šliuzas naudoja tik išeinančius ryšius į debesį, o kredencialai dešifruojami vien vietinėje maszinoje.

Praktinės implikacijos ugniasienei ir VPN yra paprastos:

• Nereikia atidaryti inbound prievadų.
• Užtenka leisti išeinantį ryšį per 443 prievadą.
• Kai duomenų šaltiniai jau yra debesyje, šliuzas dažniausiai nereikalingas – jo prasmė atsiranda tik tada, kai duomenys glaudžiasi už ugniasienės.

Šliuzų tipai: standartinis, asmeninis ir VNet šliuzas

Prieš diegdami, apsibrėžkite, kokį darbo modelį šliuzas turės aptarnauti. Trys galimybės skiriasi ne kosmetiškai, o funkciškai:

1. Standartinis šliuzas palaiko kelis vartotojus, kelis duomenų šaltinius vienu metu ir yra suderinamas su platesniu Power Platform ekosistemos rinkiniu – Power Automate, Power Apps ir panašiai. Microsoft rekomenduoja šį režimą įmonėms, kur duomenimis naudojasi daugiau nei vienas žmogus.
2. Asmeninis šliuzas dirba tik su vieno vartotojo autentifikacija, negali būti dalinamas su komanda ir dažniausiai naudojamas testavimui ar labai mažoms individualioms ataskaitoms.
3. VNet šliuzas yra be atskiro fizinio serverio – tinklo integracija vyksta Azure virtualaus tinklo lygmenyje, todėl jis tinka organizacijoms, kur duomenų srautai turi likti izoliuoti nuo viešojo interneto beveik visą kelią.

Restoranų tinklui su vienu buhalteriu asmeninis režimas gali pakakti pradžiai, tačiau jei prie tų pačių duomenų prisijungia keli vadovai skirtingais laikais, standartinis šliuzas tampa būtinybe, ne prabanga.

Kada rinktis standartinį šliuzą, o kada – asmeninį

Sprendimą lemia trys konkretūs kriterijai, ne intuicija.

Pirma, vartotojų skaičius ir bendri šaltiniai. Jei prie tos pačios duomenų bazės jungiasi keli žmonės arba keliose ataskaitose naudojamas tas pats šaltinis, asmeninis šliuzas tiesiog neveiks – jis neleidžia dalintis prisijungimu.

Antra, DirectQuery apkrova. Kiekvienas ataskaitos atidarymas DirectQuery režimu siunčia tiesioginę užklausą į šaltinio duomenų bazę per šliuzą. Kai vartotojų daug, apkrova auga tiesiogiai proporcingai, ir asmeninis šliuzas su ribotais resursais tampa kliūtimi.

Trečia, duomenų valdymo (governance) reikalavimai. Standartinis šliuzas leidžia centralizuotai valdyti prieigą, matyti naudojimo žurnalus ir priskirti administratorius – tai kritinė funkcija įmonėms, kurios turi atsiskaityti audito metu.

• Vienas vartotojas, testinė ataskaita → asmeninis šliuzas.
• Kelios komandos, bendri šaltiniai, DirectQuery → standartinis šliuzas.
• Reikalingas prieigos auditas → standartinis šliuzas su administratoriaus paskyra.

Profesionalus patarimas: jei nesate tikri, kiek vartotojų per metus prisijungs prie ataskaitos, rinkitės standartinį šliuzą iš karto – persikėlimas iš asmeninio režimo į standartinį reikalauja pakartotinės konfigūracijos ir dažnai trumpo ataskaitų neveikimo laiko.

Techniniai reikalavimai ir sizing sprendimams

Prieš diegimą patikrinkite du dalykus: operacinę sistemą ir .NET Framework versiją. Microsoft nurodo, kad būtina turėti bent .NET Framework 4.8 ir palaikomą Windows serverio ar darbastalio versiją. Šliuzo negalima diegti domeno valdiklyje (domain controller) – tai dažna klaida, kuri sukelia diegimo klaidas arba saugumo riziką.

Rekomenduojama konfigūracija, kuri tinka daugumai vidutinio dydžio įmonių:

• Bent 8 branduolių procesorius (8 core CPU)
• 8 GB RAM arba daugiau
• SSD diskas, ne standartinis HDD

Statistika: Microsoft sizing gairės rekomenduoja pradėti nuo šios konfigūracijos ir koreguoti pagal realią apkrovą, o ne investuoti į itin galingą serverį iš karto.

Skirtumas tarp cached (importuotų) ir DirectQuery darbo krūvių tiesiogiai lemia, kiek hardware jums reikia. Importuoti duomenys apkrauna serverį tik atnaujinimo metu – dažniausiai naktį ar kelis kartus per dieną. DirectQuery, priešingai, siunčia užklausą kiekvienu ataskaitos atidarymu, todėl procesoriaus ir RAM poreikis auga su vartotojų skaičiumi realiu laiku, ne pagal grafiką.

Prižiūrint šliuzą, verta stebėti šiuos rodiklius: procesoriaus apkrovą, atminties naudojimą, atnaujinimų sėkmės procentą ir eilės (queue) ilgį. Šliuzo diagnostikos žurnalai (Gateway diagnostic logs) rodo, kada užklausos laukia eilėje – tai pirmas signalas, kad reikia daugiau resursų arba klasterio.

Kaip pagerinti šliuzo našumą praktiškai

Fizinis atstumas tarp šliuzo ir duomenų šaltinio turi realią įtaką – jei šliuzo kompiuteris yra toje pačioje lokalioje tinklo aplinkoje kaip duomenų bazė, tinklo latencija sumažėja ženkliai, o DirectQuery atsakymo laikas pagerėja. Šis principas dažnai ignoruojamas, kai šliuzas diegiamas „kur yra vietos serverinėje“, ne kur yra duomenys.

Keli praktiniai žingsniai, kurie iš tiesų veikia:

• Diekite šliuzą kuo arčiau duomenų šaltinio, mažindami tinklo šuolius (hop) tarp jų.
• Atskirkite suplanuotus atnaujinimus (scheduled refresh) nuo DirectQuery užklausų per skirtingus laiko langus, kad jie nesikonkuruotų dėl resursų.
• Kur galima, naudokite agregacijas (aggregations), kad DirectQuery užklausos grąžintų suvestinius duomenis, ne pilną detalizaciją.
• Didelio pasiekiamumo reikalavimams pridėkite papildomus mazgus į klasterį – kiekvienas mazgas turi būti atskirame kompiuteryje ir vienodos šliuzo versijos, kitaip prisijungę seni mazgai gali sulėtinti visą sistemą.
• Konfigūracijos pakeitimas StreamBeforeRequestCompletes leidžia šliuzui pradėti siųsti duomenis anksčiau, nelaukiant, kol visa užklausa bus paruošta – tai gali reikšmingai paspartinti didelių duomenų rinkinių perdavimą.

Profesionalus patarimas: jei transformacijos Power Query žingsniuose negali būti „query folding“ (t. y. neperkeliamos atgal į duomenų bazę), jos vykdomos ant paties šliuzo kompiuterio ir smarkiai padidina RAM naudojimą – tai viena dažniausiai nepastebimų priežasčių, kodėl šliuzas „lėtai dirba“, nors CPU rodikliai atrodo normalūs.

Diegimo kontrolinis sąrašas žingsnis po žingsnio

Sistemingas diegimas sutaupo valandas derinimo darbo vėliau. Sekite šiuos žingsnius nuosekliai:

1. Paruoškite serverį – patikrinkite Windows versiją, .NET Framework 4.8 buvimą ir įsitikinkite, kad tai NE domeno valdiklis.
2. Registruokite šliuzą su organizacijos paskyra (ne asmenine), priskirkite bent du administratorius ir sukurkite atsarginį atkūrimo raktą (recovery key) saugioje vietoje.
3. Pridėkite prie klasterio, jei planuojate aukštą pasiekiamumą – kiekvienas naujas mazgas turi turėti tą pačią šliuzo versiją.
4. Testuokite ryšį su kiekvienu duomenų šaltiniu atskirai, patikrindami autorizaciją ir realią atnaujinimo sėkmę.
5. Įvertinkite latenciją stebėdami pirmuosius suplanuotus atnaujinimus – jei jie trunka ženkliai ilgiau nei tikėtasi, patikrinkite tinklo maršrutą tarp šliuzo ir šaltinio.

Kaip Analitika360 diegia ir optimizuoja duomenų šliuzus klientams

Analitika360 integruoja duomenis iš Rivilė, Finvalda, SharePoint ir Excel, o kiekvienam klientui šliuzo konfigūracija pritaikoma pagal realų duomenų kiekį ir vartotojų skaičių, ne pagal bendrą šabloną.

Restoranų tinklams ir buhalterinėms įmonėms dažniausiai svarbiausia ne pati technologija, o tai, kad ataskaitos atsinaujintų automatiškai, be rankinio įsikišimo – tai ir yra sizing sprendimo tikslas, ne tik techninė detalė.

Praktikoje tai reiškia:

• Sizing sprendimai priimami stebėjus realią apkrovą pirmas kelias savaites po diegimo, ne teoriškai iš anksto.
• Aukšto pasiekiamumo (HA) klasteriai diegiami tik tada, kai klientas realiai turi kelis vartotojus tuo pačiu metu naudojančius ataskaitas.
• Automatizuotos ataskaitos sukonfigūruojamos taip, kad atsinaujintų be papildomo vartotojo įsikišimo, o Rivilės integracija sujungia apskaitos duomenis su pardavimų ir sandėlio rodikliais vienoje ataskaitoje.

Ką dažniausiai pameta iš akių Power BI naudotojai

Dauguma vadovų apie šliuzą sužino tik tada, kai kažkas sugenda – ataskaita nustoja atsinaujinti, ir tik tada paaiškėja, kad visą laiką veikė vienas asmeninis šliuzas ant kažkieno darbastalio kompiuterio. Tai yra tikroji problema, ne technologija savaime.

Įprasta manyti, kad šliuzo diegimas yra vienkartinis IT darbas, po kurio galima pamiršti. Realybėje tai infrastruktūros dalis, kuriai reikia periodinės priežiūros – programinės įrangos atnaujinimų, prieigos teisių peržiūros ir klasterio mazgų būklės tikrinimo. Įmonės, kurios ignoruoja šį aspektą, dažniausiai susiduria su tyliai sugriuvusiais atnaujinimais, ne dramatiškomis klaidomis.

Kita nuostata, kurią verta peržiūrėti: sizing nereikia spėti iš anksto su kaupu. Geriau pradėti nuo vidutinės konfigūracijos ir koreguoti pagal realų naudojimą, nei investuoti į pernelyg galingą serverį, kuris niekada nebus pilnai išnaudotas. DirectQuery rizikos taip pat dažnai nuvertinamos – vadovai mato greitą ataskaitos atidarymą testavimo metu su vienu vartotoju ir nesuvokia, kad su dešimčia vienalaikių vartotojų vaizdas pasikeis radikaliai.

Skaitytojui, kuris planuoja diegimą pirmą kartą, verta pirmiausia nusistatyti realų vartotojų skaičių ir tik tada rinktis tarp standartinio ir asmeninio režimo.

— Analitika360

Kodėl rinktis Analitika360 Power BI šliuzo diegimui

Power BI duomenų šliuzo diegimas savarankiškai reikalauja laiko, kurio dauguma finansų vadovų ir buhalterių tiesiog neturi – nuo OS suderinamumo tikrinimo iki sizing sprendimų ir klasterio konfigūravimo.

Analitika360 sprendžia šią problemą praktiškai: diegiame ir konfiguruojame šliuzą kartu su visa Power BI ataskaitų sistema, integruota su Rivilė ar Finvalda apskaitos duomenimis, SharePoint ir Excel failais. Klientas gauna ne tuščią techninę infrastruktūrą, o veikiančią ataskaitų sistemą, kuri automatiškai atsinaujina ir rodo pajamų, sąnaudų ir pelno rodiklius realiu laiku.

Skirtingai nei bendras IT konsultantas, kuris diegia šliuzą kaip vienkartinę užduotį, Analitika360 lieka atsakinga už veikimą ilgainiui – sizing koregavimą, klasterio priežiūrą ir atnaujinimų stebėjimą. Jei norite pradėti nuo aiškaus Power BI diegimo ir konsultacijų plano, arba peržiūrėti, kaip atrodo tokie sprendimai praktikoje su Finvalda duomenimis, susisiekite ir gaukite individualų pasiūlymą pagal savo įmonės dydį ir duomenų šaltinius.

Rekomendacija

• Power BI diegimas ir konsultacijos | analitika360.lt
• Kas yra Power BI ir kam jis naudojamas? | analitika360.lt
• Power BI ar Qlik: palyginimas | analitika360.lt
• Kaip veikia Power BI: Power Query ir DAX | analitika360.lt