This blog post was authored by: Sahaj Saini, PM a Microsoft Analytics Platform System (APS) csapatában.

Ezzel a blogbejegyzéssel egy gyors áttekintést nyújtunk a szimmetrikus többprocesszoros feldolgozás (SMP) és az MPP között. Massively Parallel Processing (MPP) rendszerekről, az SMP-ről MPP-re való áttérés kiváltó okainak azonosításáról, a Microsoft Analytics Platform System (APS) rendszerre való áttérés legfontosabb szempontjairól, valamint arról, hogyan lehet kihasználni egy olyan MPP-megoldás, mint az APS teljesítményét.

Kezdjük egy forgatókönyvvel. Emma az Adventure Works Cycles, egy kerékpárgyártó vállalat adatbázis-adminisztrátora. Az Adventure Worksnél Emma és csapata hagyományos SQL Server SMP-t használ adattárházi megoldásként. A vállalat gyorsan növekszik, és mivel a kerékpáriparban egyre nagyobb a verseny, az Adventure Works Cycles üzleti elemzői gyorsabb betekintést szeretnének az adataikba. Emma most a következő kihívásokkal szembesül az SMP telepítésével: –

• Nagy adatmennyiség és adatnövekedés: A növekvő eladások és a növekvő ügyfélkör miatt az adatmennyiség gyorsan nőtt, és meghaladta a 10 TB-ot.
• Hosszabb adatbetöltési/ETL-idők: Mivel naponta jelentéseket kell készíteni a vezetőség számára, az Emma úgy találja, hogy a jelenlegi ETL sebessége nem megfelelő a más OLTP és nem relációs rendszerekből érkező növekvő adatmennyiség beviteléhez és feldolgozásához.
• Lassú lekérdezésvégrehajtás:
• Hosszú kockafeldolgozási idő: A jelenlegi kockafeldolgozási idővel nehéz megfelelni a vállalat valós idejű jelentési igényeinek.

E kihívások leküzdése érdekében Emma és csapata értékeli egy nagyobb, drágább és erősebb szerver- és tárolóhardver beszerzését az adatközpontjukba. Ez a megközelítés megoldaná a problémájukat, de csak rövid távon, mivel az adatok növekedése a következő 12 hónapban várhatóan robbanásszerűen megnő. Az Adventure Works által várt adatnövekedés mellett még a nagyobb és erősebb SMP-megoldások is nagyon gyorsan falba ütköznének. Az Emma olyan megoldást szeretne, amely az adatigényeik növekedésével együtt skálázódik.

Mielőtt belevágnánk az Emma problémáinak megoldásába, gyorsan definiáljuk, hogy mi is az SMP és az MPP. A szimmetrikus többprocesszoros feldolgozás (SMP) egy szorosan összekapcsolt többprocesszoros rendszer, ahol a processzorok megosztják az erőforrásokat – az operációs rendszer (OS) egyes példányait, a memóriát, az I/O eszközöket, és egy közös busz segítségével csatlakoznak egymáshoz. Az SMP a szerverekben alkalmazott elsődleges párhuzamos architektúra, amelyet a következő képen ábrázolunk.

A masszívan párhuzamos feldolgozás (MPP) egyetlen feladat összehangolt feldolgozása több processzor által, ahol minden processzor saját operációs rendszert és memóriát használ, és valamilyen üzenetküldő interfész segítségével kommunikál egymással. Az MPP felállítható megosztott semmi vagy megosztott lemez architektúrával.

A megosztott semmi architektúrában nincs egyetlen vitapont a rendszerben, és a csomópontok nem osztoznak a memórián vagy a lemeztárolón. Az adatok horizontálisan vannak felosztva a csomópontok között, úgy, hogy minden csomópont az adatbázis minden táblájából a sorok egy részhalmazával rendelkezik. Ezután minden csomópont csak a saját lemezein lévő sorokat dolgozza fel. Az ilyen architektúrán alapuló rendszerek hatalmas méreteket érhetnek el, mivel nincs egyetlen szűk keresztmetszet sem, amely lelassítaná a rendszert. Ezt keresi az Emma.

A megosztás nélküli architektúrájú MPP az alábbi képen látható.

A Microsoft Analytics Platform System alkalmazáson futó Microsoft Parallel Data Warehouse (PDW) MPP megosztás nélküli architektúraként van megvalósítva. Egy vezérlő csomópontból és tárolóhoz csatolt számítási csomópontokból áll, amelyek Ethernet és Infiniband segítségével vannak összekapcsolva. A vezérlő csomóponton található a PDW motor – az MPP rendszer agya -, amely párhuzamos lekérdezési terveket készít, koordinálja a lekérdezések végrehajtását a számítási csomópontokon és az adatok aggregálását az egész berendezésen. Minden csomópont, beleértve a vezérlő- és a számítási csomópontokat is, egy adatmozgatási szolgáltatást (Data Movement Service, DMS) fogad a csomópontok közötti adatátvitelhez.

A PDW architektúrájáról további részleteket a Microsoft Analytics Platform System architektúrája című bejegyzésben olvashat.

Áttérés az MPP-re

Az MPP által kínált értékek kihasználásához Emma és csapata megvásárol egy Microsoft APS-berendezést, és megkezdi az MPP-re való áttérést. Nézzük meg, hogyan alakítják át a megoldásukat, hogy teljes mértékben kihasználják az APS megosztott semmi MPP-architektúrájának előnyeit.

Táblázat kialakítása

Amint korábban említettük, az APS a megosztott semmi MPP-architektúrán alapul, ami azt jelenti, hogy a csomópontok önellátóak, és nem osztoznak memórián vagy lemezeken. Az architektúra ezért megköveteli, hogy a nagy táblákat elosztja a csomópontok között, hogy kihasználhassa a tömegesen párhuzamos feldolgozás előnyeit. Az APS lehetővé teszi, hogy egy táblát elosztottként vagy replikáltként definiáljunk. Az egyik és a másik közötti választás eldöntése az adatmennyiségtől és attól függ, hogy az összes adathoz egyetlen csomóponton keresztül kell-e hozzáférni.

elosztott táblák

Az elosztott tábla olyan tábla, ahol a táblán belüli soradatok az alkalmazáson belüli csomópontok között vannak elosztva a masszív méretezés lehetővé tétele érdekében. Minden sor egy elosztásban, egy számítási csomópontban végzi, ahogy az alábbi képen látható.

Az APS elosztott jellegének kihasználása érdekében az Emma a nagy táblákat, jellemzően a Fact és a nagy dimenziós táblákat az alábbiak szerint módosítja az APS-ben történő elosztás érdekében:

CREATE TABLE .( NOT NULL, NOT NULL, . . NULL) WITH( DISTRIBUTION = HASH(ProductKey),CLUSTERED COLUMNSTORE INDEX);

Amint látható, ez egy tipikus DDL utasítás a táblák létrehozásához, egy kisebb kiegészítéssel az elosztott táblákhoz. A táblák elosztása egy determinisztikus hash-függvény segítségével történik, amelyet az adott táblához kiválasztott elosztási oszlopra alkalmaznak. Emma a FactInternetSales tábla elosztási oszlopának a Product Key-t választja a nagy kardinalitás és a ferdeség hiánya miatt, így a tábla egyenletesen oszlik el a csomópontok között.

Replikált táblák

Ha azonban minden tábla elosztásra kerülne, akkor az összes műveletnél a join műveletek végrehajtása előtt nagyon sok adatmozgatásra lenne szükség a csomópontok között. Ezért a kisebb dimenziós táblák, például a nyelv, országok stb. esetében érdemes a teljes táblát minden egyes számítási csomóponton replikálni. Ez azt jelenti, hogy az ilyen táblák esetében a helyi összekapcsolási műveletek lehetővé tételének előnyei meghaladják a felhasznált extra tárolási költséget. A replikált tábla olyan tábla, amely az összes számítási csomóponton replikálva van az alábbi ábrán látható módon.

Emma a kis táblákat, jellemzően dimenziós táblákat a következőképpen tervezi replikálni:

 CREATE TABLE .( NOT NULL, . . (10) NOT NULL,)WITH(CLUSTERED COLUMNSTORE INDEX);

Az elosztott és replikált táblák megfelelő tervezésével Emma összehangolja megoldását az általános MPP-tervezési legjobb gyakorlatokkal, és lehetővé teszi a nagy mennyiségű adat hatékony feldolgozását. Például egy SQL Server SMP-környezetben egy 100 milliárd sorra irányuló lekérdezés az összes adat feldolgozását egyetlen végrehajtási térben igényelné. Az MPP-vel a munka több csomópontra oszlik szét, hogy a problémát könnyebben kezelhető és könnyebben végrehajtható feladatokra bontsa. Egy négy csomópontos berendezésben (lásd a fenti képet) minden egyes csomópontnak csak nagyjából 25 milliárd sort kell feldolgoznia – ez sokkal gyorsabb feladat. Ennek eredményeképpen Emma jelentős javulást tapasztal a lekérdezések végrehajtási idejében, és vállalkozása mostantól gyorsabban, jobb döntéseket tud hozni. Emellett Emma az APS “skálaegységek” hozzáadásával az adattárházat néhány terabájttól akár 6 petabájt feletti adatmennyiségre is növelheti.

Adatbetöltés

Az SQL Server SMP-vel Emma és csapata egy sor SSIS csomagon keresztül ETL-folyamatokat használt az adatoknak az adattárházba való betöltésére – (1) adatok kinyerése az OLTP- és más rendszerekből; (2) az adatok dimenziós formátumba történő átalakítása; és (3) az adatok betöltése az adattárház céldimenzió- vagy ténytábláiba. Az adatmennyiség növekedésével a középen lévő SSIS sever szűk keresztmetszetté válik az átalakítások végrehajtása során, ami lassú adatbetöltést eredményez.

Az APS segítségével Emma és csapata ehelyett az ELT-t használhatja az adatoknak az OLTP- és más rendszerekből történő kivonására és az APS-en lévő átmeneti helyre történő betöltésére. Ezután az adatokat nem az SSIS-szel, hanem az APS Engine segítségével lehet dimenziós formátumba transzformálni, kihasználva a készülék elosztott jellegét és a párhuzamos feldolgozás erejét. Egy 4 csomópontos alkalmazásban négy szerver végzi az adatok részhalmazainak átalakítását, szemben az egy csomópontos SSIS-kiszolgálóval.

Ez a párhuzamos feldolgozás az adatbetöltési teljesítmény jelentős növekedését eredményezi. Emma ezután a Create Table As Select (CTAS) utasítással létrehozhatja a táblát a staging táblából az alábbiak szerint.

CREATE TABLE . WITH( CLUSTERED COLUMN INDEX, DISTRIBUTION = HASH (CustomerKey))ASSELECT * FROM .;

Az ELT-folyamatra való áttéréssel Emma az APS párhuzamos feldolgozási teljesítményét kihasználva teljesítménynövekedést tapasztal az adatbetöltésben.

Végeredményben Emma és csapata az MPP-vel választ talált az SMP-bajokra. Most már magabiztosan kezelhetik az Adventure Works adatmennyiségét és növekedését, és képesek az adattárház szükség szerinti skálázására. Az ELT-vel és az APS párhuzamos feldolgozásának erejével gyorsabban és az elvárt időablakon belül tölthetnek be adatokat az APS-be. Az APS MPP kialakításával összehangolva pedig áttörő lekérdezési teljesítményt érhetnek el, ami lehetővé teszi a valós idejű jelentéstételt és az adatokba való betekintést.