Automatizált nagyvállalati BI

Microsoft Entra ID
Azure Analysis Services
Azure Blob Storage
Azure Data Factory
Azure Synapse Analytics

Megoldási ötletek

Ez a cikk egy megoldási ötlet. Ha azt szeretné, hogy további információkkal bővítsük a tartalmat, például a lehetséges használati eseteket, alternatív szolgáltatásokat, megvalósítási szempontokat vagy díjszabási útmutatást, a GitHub visszajelzésével tudassa velünk.

Ez a példa azt mutatja be, hogyan végezhet növekményes betöltést egy kinyerési, betöltési és átalakítási (ELT) folyamatban. Az Azure Data Factory használatával automatizálja az ELT-folyamatot. A folyamat növekményesen helyezi át a legújabb OLTP-adatokat egy helyszíni SQL Server-adatbázisból az Azure Synapse-be. A tranzakciós adatok táblázatos elemzési modellté alakulnak.

Felépítés

Architecture diagram for automated enterprise BI with Azure Synapse Analytics and Azure Data Factory.

Töltse le az architektúra Visio-fájlját.

Ez az architektúra az Enterprise BI-ban és az Azure Synapse-ben láthatóra épül, de hozzáad néhány olyan funkciót, amely fontos a vállalati adattárházak esetében.

  • A folyamat automatizálása a Data Factory használatával.
  • Növekményes betöltés.
  • Több adatforrás integrálása.
  • Bináris adatok, például térinformatikai adatok és képek betöltése.

Munkafolyamat

Az architektúra a következő szolgáltatásokból és összetevőkből áll.

Adatforrások

Helyszíni SQL Server. A forrásadatok egy helyszíni SQL Server-adatbázisban találhatók. A helyszíni környezet szimulálása. Forrásadatbázisként a Wide World Importers OLTP mintaadatbázist használjuk.

Külső adatok. Az adattárházak gyakori forgatókönyve több adatforrás integrálása. Ez a referenciaarchitektúra egy külső adatkészletet tölt be, amely évről évre tartalmazza a város lakosságát, és integrálja azokat az OLTP-adatbázis adataival. Ezeket az adatokat olyan elemzésekhez használhatja, mint például: "Az egyes régiókban az értékesítések növekedése egyezik vagy meghaladja a népesség növekedését?"

Betöltés és adattárolás

Blob Storage. A Blob Storage előkészítési területként szolgál a forrásadatokhoz, mielőtt betöltené őket az Azure Synapse-ba.

Azure Synapse. Az Azure Synapse egy elosztott rendszer, amely nagy méretű adatok elemzésére szolgál. Támogatja a nagy teljesítményű párhuzamos feldolgozást (MPP), ami alkalmassá teszi a nagy teljesítményű elemzések futtatására.

Azure Data Factory. A Data Factory egy felügyelt szolgáltatás, amely koordinálja és automatizálja az adatáthelyezést és az adatátalakítást. Ebben az architektúrában az ELT-folyamat különböző szakaszait koordinálja.

Elemzés és jelentéskészítés

Azure Analysis Services. Az Analysis Services egy teljes mértékben felügyelt szolgáltatás, amely adatmodellezési képességeket biztosít. A szemantikai modell betöltődik az Analysis Servicesbe.

Power BI. A Power BI üzleti elemzési eszközökből álló csomagja az üzleti elemzésekhez szükséges adatok elemzéséhez. Ebben az architektúrában lekérdezi az Analysis Servicesben tárolt szemantikai modellt.

Hitelesítés

A Microsoft Entra ID (Microsoft Entra ID) hitelesíti az Analysis Services-kiszolgálóhoz a Power BI-on keresztül csatlakozó felhasználókat.

A Data Factory a Microsoft Entra ID-t is használhatja az Azure Synapse-beli hitelesítéshez egy egyszerű szolgáltatásnév vagy egy felügyeltszolgáltatás-identitás (MSI) használatával.

Összetevők

Forgatókönyv részletei

Adat prognózis

Az Azure Data Factoryben a folyamatok a tevékenységek logikai csoportosítását használják a tevékenységek koordinálásához – ebben az esetben az adatok betöltése és átalakítása az Azure Synapse-ba.

Ez a referenciaarchitektúra egy szülőfolyamatot határoz meg, amely gyermekfolyamatok sorozatát futtatja. Minden gyermekfolyamat egy vagy több adattárháztáblába tölti be az adatokat.

Screenshot of the pipeline in Azure Data Factory.

Javaslatok

Növekményes betöltés

Automatizált ETL- vagy ELT-folyamat futtatásakor a leghatékonyabb, ha csak az előző futtatás óta megváltozott adatokat tölti be. Ezt növekményes terhelésnek nevezzük, szemben az összes adatot betöltő teljes terheléssel. Növekményes terhelés végrehajtásához meg kell határoznia, hogy mely adatok módosultak. A leggyakoribb módszer a magas vízjelérték használata, ami azt jelenti, hogy nyomon kell követni a forrástábla egyes oszlopainak legújabb értékét, akár datetime oszlopot, akár egyedi egész szám oszlopot.

Az SQL Server 2016-tól kezdve használhat időbeli táblákat. Ezek rendszerverziós táblák, amelyek az adatváltozások teljes előzményeit őrzik meg. Az adatbázismotor automatikusan rögzíti a változások előzményeit egy külön előzménytáblában. Az előzményadatok lekérdezéséhez hozzáadhat egy FOR SYSTEM_TIME záradékot egy lekérdezéshez. Az adatbázismotor belsőleg lekérdezi az előzménytáblát, de ez átlátható az alkalmazás számára.

Megjegyzés:

Az SQL Server korábbi verzióihoz használhatja az Adatrögzítés (CDC) módosítását. Ez a módszer kevésbé kényelmes, mint az időbeli táblák, mivel külön változástáblát kell lekérdeznie, és a változásokat egy naplóütemezési szám követi nyomon időbélyeg helyett.

Az időbeli táblák hasznosak a dimenzióadatokhoz, amelyek idővel változhatnak. A ténytáblák általában nem módosítható tranzakciót, például eladást jelölnek, ebben az esetben a rendszer verzióelőzményeinek megtartása nem logikus. Ehelyett a tranzakciók általában egy olyan oszlopmal rendelkeznek, amely a tranzakció dátumát jelöli, amely vízjelértékként használható. A Wide World Importers OLTP-adatbázisban például a Sales.Invoices és a Sales.InvoiceLines tábla egy olyan mezővel rendelkezik LastEditedWhen , amely alapértelmezés szerint a sysdatetime()következő.

Az ELT-folyamat általános folyamata a következő:

  1. A forrásadatbázis minden táblájában kövesse nyomon az utolsó ELT-feladat futásának kivágási idejét. Ezeket az adatokat az adattárházban tárolhatja. (A kezdeti beállításkor minden alkalommal "1-1-1900" értékre van állítva.)

  2. Az adatexportálási lépés során a kivágás ideje paraméterként a forrásadatbázisban tárolt eljárások egy halmazának lesz átadva. Ezek a tárolt eljárások lekérdezik azokat a rekordokat, amelyeket a kivágás után módosítottak vagy hoztak létre. A Sales fact tábla esetében a rendszer az LastEditedWhen oszlopot használja. A dimenzióadatokhoz rendszerverziójú időtáblákat használ a rendszer.

  3. Ha az adatmigrálás befejeződött, frissítse a kivágási időket tároló táblát.

Az is hasznos, ha minden ELT-futtatáshoz rögzít egy-egy sort . Egy adott rekord esetében a leágazás az adatokat előállító ELT-futtatással társítja a rekordot. Az egyes ETL-futtatásokhoz minden táblához létrejön egy új életútrekord, amely megjeleníti a kezdő és záró betöltési időket. Az egyes rekordokhoz tartozó életútkulcsok a dimenzió- és ténytáblákban vannak tárolva.

Screenshot of the city dimension table

Miután betöltött egy új adatköteget a raktárba, frissítse az Analysis Services táblázatos modelljét. Lásd: Aszinkron frissítés a REST API-val.

Adattisztítás

Az adattisztításnak az ELT folyamat részét kell képeznie. Ebben a referenciaarchitektúrában a rossz adatok egyik forrása a város népességtáblája, ahol egyes városokban nulla a népesség, talán azért, mert nem volt elérhető adat. A feldolgozás során az ELT-folyamat eltávolítja ezeket a városokat a város népességtáblájából. Külső táblák helyett adattisztítást végezhet az előkészítési táblákon.

Külső adatforrások

Az adattárházak gyakran összevonják az adatokat több forrásból. Például egy demográfiai adatokat tartalmazó külső adatforrás. Ez az adatkészlet az Azure Blob Storage-ban érhető el a WorldWideImportersDW-minta részeként.

Az Azure Data Factory közvetlenül a blobtárolóból másolhat a blobtároló-összekötő használatával. Az összekötőnek azonban kapcsolati sztring vagy közös hozzáférésű jogosultságkódra van szüksége, így nem használható nyilvános olvasási hozzáféréssel rendelkező blob másolására. Áthidaló megoldásként a PolyBase használatával létrehozhat egy külső táblát a Blob Storage-on keresztül, majd a külső táblákat az Azure Synapse-be másolhatja.

Nagy bináris adatok kezelése

A forrásadatbázisban például a Város tábla hely oszlopa földrajzi térbeli adattípust tartalmaz. Az Azure Synapse nem támogatja natív módon a földrajzi típust, ezért ez a mező a betöltés során varbináris típussá alakul. (Lásd: Megkerülő megoldások a nem támogatott adattípusokhoz.)

A PolyBase azonban támogatja a maximális oszlopméretet varbinary(8000), ami azt jelenti, hogy egyes adatok csonkoltak lehetnek. A probléma kerülő megoldása az adatok adattömbökre bontása az exportálás során, majd az adattömbök újra összeállítása az alábbiak szerint:

  1. Hozzon létre egy ideiglenes átmeneti táblát a Hely oszlophoz.

  2. Minden város esetében ossza fel a helyadatokat 8000 bájtos adattömbökre, ami 1 – N sort eredményez az egyes városokhoz.

  3. Az adattömbök újra összeállításához használja a T-SQL PIVOT operátort a sorok oszlopokká alakításához, majd az egyes városok oszlopértékeinek összefűzéséhez.

A feladat az, hogy minden város különböző számú sorra legyen felosztva a földrajzi adatok méretétől függően. Ahhoz, hogy a PIVOT operátor működjön, minden városnak azonos számú sornak kell lennie. Ennek érdekében a T-SQL-lekérdezés néhány trükköt alkalmaz a sorok üres értékekkel való kitöltésére, hogy minden városnak ugyanannyi oszlopa legyen a kimutatás után. Az eredményül kapott lekérdezés sokkal gyorsabb, mint a sorok egyesével történő hurkolása.

Ugyanezt a megközelítést használják a rendszerképadatokhoz is.

Lassan változó dimenziók

A dimenzióadatok viszonylag statikusak, de változhatnak. Előfordulhat például, hogy egy termék egy másik termékkategóriához lesz hozzárendelve. A lassan változó dimenziók kezelésére számos módszer létezik. A 2. típusnak nevezett gyakori módszer egy új rekord hozzáadása, amikor egy dimenzió megváltozik.

A 2. típusú megközelítés implementálásához a dimenziótábláknak további oszlopokra van szükségük, amelyek meghatározzák az adott rekord érvényes dátumtartományát. A forrásadatbázisból származó elsődleges kulcsok is duplikálva lesznek, így a dimenziótáblának mesterséges elsődleges kulccsal kell rendelkeznie.

Az alábbi képen például a Dimension.City tábla látható. Az WWI City ID oszlop a forrásadatbázis elsődleges kulcsa. Az City Key oszlop egy mesterséges kulcs, amely az ETL-folyamat során jön létre. Azt is megfigyelheti, hogy a tábla rendelkezik és Valid To oszlopokkal rendelkezikValid From, amelyek meghatározzák az egyes sorok érvényességének tartományát. Az aktuális értékek Valid To értéke "9999-12-31".

Screenshot of the city dimension table

Ennek a megközelítésnek az az előnye, hogy megőrzi az előzményadatokat, ami értékes lehet az elemzéshez. Ez azonban azt is jelenti, hogy ugyanahhoz az entitáshoz több sor is tartozik. Az alábbi rekordok például megegyeznek WWI City ID a = 28561 értékével:

Second screenshot of the city dimension table

Minden Értékesítési tény esetében ezt a tényt a Város dimenzió tábla egyetlen sorához szeretné társítani, amely megfelel a számla dátumának.

Considerations

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek halmaza. További információ: Microsoft Azure Well-Architected Framework.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információ: A biztonsági pillér áttekintése.

A további biztonság érdekében a virtuális hálózati szolgáltatásvégpontok használatával csak a virtuális hálózat számára biztosíthatja az Azure-szolgáltatás erőforrásait. Ez teljes mértékben eltávolítja a nyilvános internet-hozzáférést ezekhez az erőforrásokhoz, így csak a virtuális hálózatról engedélyezi a forgalmat.

Ezzel a módszerrel létrehoz egy virtuális hálózatot az Azure-ban, majd privát szolgáltatásvégpontokat hoz létre az Azure-szolgáltatásokhoz. Ezek a szolgáltatások ezután az adott virtuális hálózatról érkező forgalomra korlátozódnak. A helyszíni hálózatról is elérheti őket egy átjárón keresztül.

Vegye figyelembe a következő korlátozásokat:

  • Ha a szolgáltatásvégpontok engedélyezve vannak az Azure Storage-ban, a PolyBase nem tud adatokat másolni a Storage-ból az Azure Synapse-ba. A probléma megoldására van lehetőség. További információ: A VNet-szolgáltatásvégpontok Azure Storage-beli használatának hatása.

  • A helyszíni adatok Azure Storage-ba való áthelyezéséhez engedélyeznie kell a nyilvános IP-címeket a helyszíni vagy az ExpressRoute-ból. További információ: Azure-szolgáltatások biztonságossá tétele virtuális hálózatokon.

  • Ha engedélyezni szeretné, hogy az Analysis Services adatokat olvashasson az Azure Synapse-ből, helyezzen üzembe egy Windows rendszerű virtuális gépet az Azure Synapse szolgáltatásvégpontot tartalmazó virtuális hálózaton. Telepítse az Azure Helyszíni Adatátjárót erre a virtuális gépre. Ezután csatlakoztassa az Azure Analysis szolgáltatást az adatátjáróhoz.

DevOps

  • Külön erőforráscsoportokat hozhat létre éles, fejlesztési és tesztelési környezetekhez. A külön erőforráscsoportok használata megkönnyíti az üzemelő példányok felügyeletét, a tesztkörnyezetek törlését és a hozzáférési jogok kiosztását.

  • Helyezze az egyes számítási feladatokat egy külön üzembehelyezési sablonba, és tárolja az erőforrásokat a forrásvezérlő rendszerekben. A sablonokat egy CI/CD-folyamat részeként együtt vagy egyenként is üzembe helyezheti, így egyszerűbbé teheti az automatizálási folyamatot.

    Ebben az architektúrában három fő számítási feladat van:

    • Az adattárház-kiszolgáló, az Analysis Services és a kapcsolódó erőforrások.
    • Azure Data Factory.
    • Helyszíni és felhőalapú szimulált forgatókönyv.

    Minden számítási feladat saját üzembehelyezési sablonnal rendelkezik.

    Az adattárház-kiszolgáló az IaC-gyakorlat imperatív megközelítését követő Azure CLI-parancsokkal van beállítva és konfigurálva. Fontolja meg az üzembehelyezési szkriptek használatát, és integrálja őket az automatizálási folyamatba.

  • Fontolja meg a számítási feladatok átmeneti előkészítését. Helyezze üzembe a különböző szakaszokban, és futtassa az érvényesítési ellenőrzéseket minden egyes szakaszban, mielőtt továbblépne a következő fázisra. Így szigorúan ellenőrzött módon küldheti le a frissítéseket az éles környezetekbe, és minimalizálhatja a nem várt üzembe helyezési problémákat. Kék-zöld üzembe helyezési és Canary-kiadási stratégiák használata az élő éles környezetek frissítéséhez.

    Jó visszaállítási stratégiával rendelkezik a sikertelen üzemelő példányok kezeléséhez. Például automatikusan újra üzembe helyezhet egy korábbi, sikeres üzembe helyezést az üzembe helyezési előzményekből. Tekintse meg a --rollback-on-error flag paramétert az Azure CLI-ben.

  • Az Azure Monitor az adattárház teljesítményének és a teljes Azure Analytics-platformnak az integrált monitorozási élmény érdekében történő elemzéséhez ajánlott. Az Azure Synapse Analytics monitorozási felületet biztosít az Azure Portalon az adattárház számítási feladatainak elemzéséhez. Az Azure Portal az adattárház monitorozásához ajánlott eszköz, mivel konfigurálható megőrzési időszakokat, riasztásokat, javaslatokat és testre szabható diagramokat és irányítópultokat biztosít metrikákhoz és naplókhoz.

További információt a Microsoft Azure Well-Architected Framework DevOps szakaszában talál.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információ: A költségoptimalizálási pillér áttekintése.

Az Azure díjkalkulátorával megbecsülheti költségeit. Íme néhány szempont a referenciaarchitektúrában használt szolgáltatásokra vonatkozóan.

Azure Data Factory

Az Azure Data Factory automatizálja az ELT-folyamatot. A folyamat áthelyezi az adatokat egy helyszíni SQL Server-adatbázisból az Azure Synapse-be. Az adatok ezután táblázatos modellté alakulnak elemzés céljából. Ebben a forgatókönyvben a díjszabás havi 0,001 dollár értékű tevékenységfuttatástól indul, amely tevékenység-, eseményindító- és hibakeresési futtatásokat is tartalmaz. Ez az ár csak a vezénylés alapdíja. A végrehajtási tevékenységekért, például az adatok másolásáért, a keresésekért és a külső tevékenységekért is díjat számítunk fel. Minden tevékenység külön-külön díjas. A hónap során társított eseményindítók nélküli vagy futtatott folyamatokért is díjat számítunk fel. Minden tevékenység percről percre van produkálva és felfelé kerekítve.

Példa költségelemzésre

Fontolja meg azt a használati esetet, amikor két keresési tevékenység két különböző forrásból származik. Az egyik 1 percet és 2 másodpercet vesz igénybe (2 percre kerekítve), a másik 1 percet vesz igénybe, ami összesen 3 percet eredményez. Egy adatmásolási tevékenység 10 percet vesz igénybe. Egy tárolt eljárástevékenység 2 percet vesz igénybe. A teljes tevékenység 4 percig fut. A költség kiszámítása a következőképpen történik:

Tevékenységfuttatások: 4 * $ 0,001 = $0,004

Keresések: 3 * ($ 0,005 / 60) = $0,00025

Tárolt eljárás: 2 * ($ 0,00025 / 60) = $0,000008

Adatmásolás: 10 * ($ 0,25 / 60) * 4 adatintegrációs egység (DIU) = $0,167

  • Folyamatfuttatásonkénti teljes költség: 0,17 USD.
  • Futtassa naponta egyszer 30 napig: 5,1 usd.
  • Futtasson naponta egyszer 100 táblánként 30 napig: 510 USD

Minden tevékenységhez tartozik költség. Ismerje meg a tarifamodellt, és használja az ADF-díjkalkulátort egy olyan megoldás beszerzéséhez, amely nem csak teljesítményre, hanem költségre is optimalizált. A költségek kezelése a szolgáltatások elindításával, leállításával, szüneteltetésével és skálázásával.

Azure Synapse

Az Azure Synapse ideális a nagyobb lekérdezési teljesítménnyel és számítási skálázhatósági igényekkel rendelkező intenzív számítási feladatokhoz. Kiválaszthatja a használatalapú fizetéses modellt, vagy használhat egy év (37%-os megtakarítás) vagy 3 év (65%-os megtakarítás) fenntartott csomagjait.

Az adattárolás külön díjköteles. Az egyéb szolgáltatások, például a vészhelyreállítás és a fenyegetésészlelés szintén külön díjkötelesek.

További információkért lásd az Azure Synapse díjszabását.

Analysis Services

Az Azure Analysis Services díjszabása a szinttől függ. Az architektúra referencia-implementációja a fejlesztői szintet használja, amely kiértékelési, fejlesztési és tesztelési forgatókönyvekhez ajánlott. Más szintek közé tartozik az Alapszintű szint, amely kis üzemi környezetekhez ajánlott; a kritikus fontosságú éles alkalmazások standard szintje. További információ: A megfelelő szint, amikor szüksége van rá.

No charges apply when you pause your instance.

További információkért tekintse meg az Azure Analysis Services díjszabását.

Blob Storage

Fontolja meg a fenntartott Azure Storage-kapacitás funkció használatát a tárterület költségeinek csökkentéséhez. Ezzel a modellel kedvezményt kap, ha egy vagy három évre lefoglalhatja a rögzített tárkapacitást. További információ: A Blob Storage költségeinek optimalizálása fenntartott kapacitással.

További információt a Microsoft Azure Well-Architected Framework Költség szakaszában talál.

További lépések

Érdemes lehet áttekinteni a következő Azure-példaforgatókönyveket , amelyek ugyanazon technológiák némelyikét használó konkrét megoldásokat mutatnak be: