Ten wpis na blogu został napisany przez: Sahaj Saini, PM w zespole Microsoft Analytics Platform System (APS).

W tym wpisie na blogu przedstawimy szybki przegląd Symmetric Multi-Processing (SMP) vs. Massively Parallel Processing (MPP), jak zidentyfikować czynniki wyzwalające migrację z SMP do MPP, kluczowe kwestie związane z przejściem na Microsoft Analytics Platform System (APS) oraz omówienie sposobów wykorzystania możliwości rozwiązania MPP, takiego jak APS.

Zacznijmy od scenariusza. Emma jest administratorem bazy danych w Adventure Works Cycles, firmie zajmującej się produkcją rowerów. W Adventure Works, Emma i jej zespół używają tradycyjnego SQL Server SMP jako rozwiązania do magazynowania danych. Firma szybko się rozwija, a wraz z rosnącą konkurencją w branży rowerowej, analitycy biznesowi Adventure Works Cycles chcieliby mieć szybszy wgląd w swoje dane. Emma stoi obecnie przed następującymi wyzwaniami związanymi z wdrożeniem SMP –

• Duża ilość danych i ich przyrost: Wraz ze wzrostem sprzedaży i rosnącą bazą klientów objętość danych gwałtownie wzrosła, przekraczając 10 TB.
• Dłuższe czasy ładowania danych/ETL: W związku z koniecznością tworzenia codziennych raportów dla kierownictwa Emma stwierdza, że obecna szybkość ETL jest nieodpowiednia do przyjmowania i przetwarzania rosnącej ilości danych płynących z innych systemów OLTP i nierelacyjnych.
• Wolne wykonywanie zapytań: Czasy wykonywania zapytań są spowolnione ze względu na wzrost ilości danych i coraz trudniej jest generować wgląd w codzienne raportowanie w odpowiednim czasie.
• Długi czas przetwarzania kostki: Przy obecnym czasie przetwarzania kostki trudno jest spełnić potrzeby firmy w zakresie raportowania w czasie rzeczywistym.

W celu przezwyciężenia tych wyzwań, Emma i jej zespół oceniają zakup większego, drogiego i bardziej wydajnego zestawu serwerów i sprzętu do przechowywania danych do ich centrum danych. Takie podejście rozwiązałoby ich problem, ale tylko na krótką metę, ponieważ wzrost danych ma eksplodować w ciągu najbliższych 12 miesięcy. Przy takim przyroście danych, jakiego spodziewa się Adventure Works, nawet większe i bardziej wydajne rozwiązania SMP bardzo szybko natrafiłyby na mur. Emma chciałaby zobaczyć rozwiązanie, które skaluje się wraz z rosnącymi potrzebami danych.

Zanim przejdziemy do rozwiązywania problemów Emmy, szybko zdefiniujmy, czym są SMP i MPP. Symmetric Multi-Processing (SMP) to ściśle sprzężony system wieloprocesorowy, w którym procesory współdzielą zasoby – pojedyncze instancje systemu operacyjnego (OS), pamięć, urządzenia I/O i są połączone wspólną magistralą. SMP jest podstawową architekturą równoległą stosowaną w serwerach i przedstawioną na poniższym rysunku.

Przetwarzanie masywnie równoległe (MPP) to skoordynowane przetwarzanie pojedynczego zadania przez wiele procesorów, z których każdy korzysta z własnego systemu operacyjnego i pamięci oraz komunikuje się między sobą za pomocą jakiejś formy interfejsu przesyłania komunikatów. MPP może być skonfigurowane z architekturą współdzielonego niczego lub współdzielonego dysku.

W architekturze współdzielonego niczego nie ma pojedynczego punktu rywalizacji w całym systemie, a węzły nie współdzielą pamięci ani pamięci dyskowej. Dane są poziomo dzielone na węzły, tak że każdy węzeł ma podzbiór wierszy z każdej tabeli w bazie danych. Każdy węzeł przetwarza wtedy tylko wiersze znajdujące się na jego własnych dyskach. Systemy oparte na tej architekturze mogą osiągnąć ogromną skalę, ponieważ nie ma jednego wąskiego gardła, które spowalniałoby system. Tego właśnie szuka Emma.

MPP z architekturą shared-nothing przedstawiono na poniższym obrazku.

Microsoft Parallel Data Warehouse (PDW) działający na urządzeniu Microsoft Analytics Platform System jest zaimplementowany jako architektura MPP shared-nothing. Składa się z jednego węzła kontrolnego i węzłów obliczeniowych podłączonych do pamięci masowej, połączonych ze sobą przez Ethernet i Infiniband. W węźle kontrolnym znajduje się silnik PDW – mózg systemu MPP – który tworzy równoległe plany zapytań, koordynuje wykonywanie zapytań na węzłach obliczeniowych i agregację danych w całym urządzeniu. Wszystkie węzły, w tym kontrolne i obliczeniowe, hostują usługę Data Movement Service (DMS) do przesyłania danych między węzłami.

Więcej szczegółów na temat architektury PDW można znaleźć w poście Architecture of the Microsoft Analytics Platform System.

Przejście na MPP

Aby wykorzystać wartość oferowaną przez MPP, Emma i jej zespół kupują urządzenie Microsoft APS i rozpoczynają przejście na MPP. Przyjrzyjmy się, jak dostosowują swoje rozwiązanie, aby w pełni wykorzystać współdzieloną nic architekturę MPP APS.

Projekt tabeli

Jak już wspomniano, APS jest oparty na współdzielonej nic architekturze MPP, co oznacza, że węzły są samowystarczalne i nie współdzielą pamięci ani dysków. Architektura ta wymaga zatem rozłożenia dużych tabel na węzły, aby uzyskać korzyści z masowo równoległego przetwarzania. APS pozwala na zdefiniowanie tabeli jako rozproszonej lub replikowanej. Decyzja o wyborze jednego z nich zależy od ilości danych i potrzeby dostępu do wszystkich danych na jednym węźle.

Tabele rozproszone

Tabela rozproszona to taka, w której dane wierszy w tabeli są rozproszone po węzłach w urządzeniu, aby umożliwić masową skalę. Każdy wiersz kończy się w jednej dystrybucji w jednym węźle obliczeniowym, jak pokazano na poniższym obrazku.

Aby wykorzystać rozproszoną naturę APS, Emma modyfikuje duże tabele, zwykle Fact i duże tabele wymiarowe, aby były rozproszone w APS w następujący sposób:

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

Jak widać, jest to typowa instrukcja DDL do tworzenia tabel z niewielkim dodatkiem dla tabel rozproszonych. Tabele są dystrybuowane przez deterministyczną funkcję haszującą zastosowaną do kolumny dystrybucyjnej wybranej dla danej tabeli. Emma wybiera Klucz produktu jako kolumnę dystrybucyjną w tabeli FactInternetSales ze względu na wysoką kardynalność i brak skośności, co powoduje równomierne rozmieszczenie tabeli w węzłach.

Tabele replikowane

Jeśli jednak wszystkie tabele byłyby rozproszone, wymagałoby to dużej ilości ruchu danych między węzłami przed wykonaniem operacji łączenia dla wszystkich operacji. Dlatego dla mniejszych tabel wymiarowych, takich jak język, kraje itp. sensowne jest replikowanie całej tabeli na każdym węźle obliczeniowym. Oznacza to, że korzyści płynące z umożliwienia lokalnych operacji łączenia z tymi tabelami przewyższają koszt dodatkowego zużycia pamięci masowej. Tabela replikowana to taka, która jest replikowana na wszystkich węzłach obliczeniowych, jak pokazano poniżej.

Emma projektuje małe tabele, zwykle tabele wymiarów, do replikacji w następujący sposób:

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

Poprzez odpowiednie zaprojektowanie tabel rozproszonych i replikowanych Emma dostosowuje swoje rozwiązanie do wspólnych najlepszych praktyk projektowania MPP i umożliwia wydajne przetwarzanie dużych ilości danych. Na przykład, zapytanie dotyczące 100 miliardów wierszy w środowisku SQL Server SMP wymagałoby przetworzenia wszystkich danych w pojedynczej przestrzeni wykonawczej. Z MPP, praca jest rozłożona na wiele węzłów, aby rozbić problem na bardziej zarządzalne i łatwiejsze do wykonania zadania. W urządzeniu z czterema węzłami (patrz rysunek powyżej), każdy węzeł jest proszony o przetworzenie tylko około 25 miliardów wierszy – co jest znacznie szybszym zadaniem. W rezultacie Emma obserwuje znaczącą poprawę w czasie wykonywania zapytań, a jej firma może teraz podejmować lepsze decyzje, szybciej. Dodatkowo, Emma może rozbudować hurtownię danych do rozmiarów od kilku terabajtów do ponad 6 petabajtów danych poprzez dodanie „jednostek skalujących” do APS.

Ładowanie danych

W przypadku SQL Server SMP Emma i jej zespół używali procesów ETL za pomocą zestawu pakietów SSIS do ładowania danych do hurtowni danych – (1) Ekstrakcja danych z OLTP i innych systemów; (2) Przekształcanie danych do formatu wymiarowego; i (3) Ładowanie danych do docelowych tabel wymiarów lub tabel faktów w hurtowni danych. Wraz ze wzrostem ilości danych, SSIS sever w środku staje się wąskim gardłem podczas wykonywania transformacji, co skutkuje powolnym ładowaniem danych.

Dzięki APS, Emma i jej zespół mogą zamiast tego użyć ELT, aby wyodrębnić dane z OLTP i innych systemów i załadować je do miejsca przechowywania w APS. Następnie dane mogą zostać przekształcone w format wymiarowy nie za pomocą SSIS, ale za pomocą silnika APS, wykorzystującego rozproszoną naturę urządzenia i moc przetwarzania równoległego. W przypadku urządzenia 4-węzłowego, cztery serwery wykonują transformacje na podzbiorach danych w porównaniu do pojedynczego serwera SSIS.

Takie równoległe przetwarzanie skutkuje znacznym wzrostem wydajności ładowania danych. Emma może następnie użyć polecenia Create Table As Select (CTAS), aby utworzyć tabelę z tabeli staging w następujący sposób.

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

Przechodząc na proces ELT, Emma wykorzystuje moc przetwarzania równoległego APS, aby zobaczyć wzrost wydajności ładowania danych.

Podsumowując, Emma i jej zespół znaleźli odpowiedź na swoje problemy z SMP dzięki MPP. Teraz mogą czuć się pewnie, obsługując ilość i wzrost danych w Adventure Works, mając możliwość skalowania hurtowni danych zgodnie z potrzebami. Dzięki ELT i mocy przetwarzania równoległego w APS, mogą ładować dane do APS szybciej i w oczekiwanym przedziale czasowym. A dzięki dostosowaniu do projektu MPP w APS, mogą osiągnąć przełomową wydajność zapytań, co pozwala na raportowanie w czasie rzeczywistym i wgląd w ich dane.