Microsoft AZ-104: Bazy danych Azure i usługi danych — Przewodnik do nauki

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Część Microsoft Azure Administrator Associate AZ-104 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Usługi bazodanowe i analityczne Azure obejmują zarządzane silniki relacyjne, globalnie rozproszone bazy NoSQL, buforowanie w pamięci, analitykę na dużą skalę oraz integrację/orkiestrację. Jako administrator musisz rozumieć modele zakupowe, warstwy usług, topologię sieci i zabezpieczeń, semantykę kopii zapasowych i odzyskiwania po awarii (DR) oraz sposoby łączenia usług w celu uzyskania wydajności, optymalizacji kosztów i odporności. Ta sekcja koncentruje się na wyborach operacyjnych i funkcjach platformy, które konfigurujesz na co dzień: modelach aprowizacji (DTU vs vCore), pulach elastycznych, kopiach zapasowych i przechowywaniu długoterminowym, georeplikacji i trybie failover, wystąpieniach zarządzanych wstrzykiwanych do VNet, dystrybucji i spójności Cosmos DB, replikach HA/do odczytu dla relacyjnych baz open-source, silnikach Synapse oraz środowiskach uruchomieniowych Data Factory.

Relacyjne bazy danych Azure (SQL Database, Managed Instance, MySQL/PostgreSQL)

Azure SQL Database oferuje dwa modele zakupowe. Model DTU łączy CPU, pamięć i IOPS w jednostki transakcji bazy danych (Database Transaction Units) z warstwami Basic, Standard i Premium; jest prosty, ale nieprzejrzysty, dobry dla stabilnych, przewidywalnych obciążeń i tradycyjnego doboru rozmiaru. Model vCore udostępnia generację/liczbę procesorów CPU i pamięć, w połączeniu z kontrolą nad pamięcią masową i IOPS. vCore umożliwia przejrzystość w doborze rozmiaru, korzyści z Azure Hybrid Benefit oraz zniżki na pojemność zarezerwowaną (Reserved Capacity). W ramach vCore warstwy usług odpowiadają różnym typom obciążeń i wzorcom dostępności: General Purpose wykorzystuje zdalną pamięć masową Premium SSD lub Azure Premium ze standardową architekturą dostępności; Business Critical umieszcza zasoby obliczeniowe i pamięć masową na lokalnym dysku SSD z wieloma replikami, zapewniając niskie opóźnienia i zintegrowane skalowanie odczytu w poziomie; Hyperscale oddziela zasoby obliczeniowe od pamięci masowej za pomocą serwerów stron (page servers), co pozwala na niemal natychmiastowe skalowanie i obsługę bardzo dużych baz danych. Dla pojedynczych baz danych warstwa obliczeniowa serverless (vCore) elastycznie skaluje CPU i może być automatycznie wstrzymywana, aby obniżyć koszty w stanie bezczynności.

Pule elastyczne (Elastic pools) współdzielą zasoby obliczeniowe między wieloma bazami danych, aby absorbować szczytowe, rozłożone w czasie obciążenia przy niższym łącznym koszcie. Pule są dostępne w wariantach DTU (eDTU) i vCore. Ustawiasz minimalne/maksymalne limity dla każdej bazy danych, aby ograniczyć wpływ “hałaśliwych sąsiadów”, oraz maksymalny limit dla puli, aby kontrolować wydatki. Nadsubskrypcja jest akceptowalna, gdy skoki obciążenia są krótkie i nieskorelowane. Dobór rozmiaru puli zależy od zsumowanego średniego zużycia plus marginesu na współbieżność; monitorowanie metryk poszczególnych baz danych i całej puli jest kluczowe dla utrzymania wskaźników SLO.

Kopie zapasowe są tworzone automatycznie. Azure SQL utrzymuje pełne, różnicowe i transakcyjne kopie zapasowe dziennika z możliwością przywracania do punktu w czasie (PITR) do dowolnej sekundy w oknie retencji (zazwyczaj 7–35 dni, w zależności od warstwy i konfiguracji pamięci masowej). Przechowywanie długoterminowe (LTR) utrwala cotygodniowe pełne kopie zapasowe na lata w pamięci masowej RA-GRS; można przywrócić kopię zapasową LTR jako nową bazę danych na dowolnym serwerze w tej samej subskrypcji i zestawie regionów, a przywracanie międzyregionalne jest dostępne, jeśli włączono geograficznie nadmiarową pamięć masową dla kopii zapasowych. Operacje przywracania tworzą nową bazę danych; nie nadpisują istniejącej.

Opcje georeplikacji obejmują aktywną georeplikację dla pojedynczych baz danych i pul (do czterech czytelnych replik pomocniczych z replikacją asynchroniczną) oraz grupy automatycznego przełączania awaryjnego (auto-failover groups) na poziomie serwera logicznego. Grupy przełączania awaryjnego łączą wiele baz danych (lub cały serwer) z geograficznym odzyskiwaniem po awarii (geo-DR), punktem końcowym nasłuchu do zapisu i odczytu, punktem końcowym tylko do odczytu do odciążania operacji odczytu, automatycznym przełączaniem awaryjnym opartym na stanie kondycji oraz przekierowaniem opartym na DNS. Warstwa Business Critical zapewnia również skalowanie odczytu w poziomie za pomocą lokalnej, czytelnej repliki, umożliwiając natychmiastowe odciążenie obciążeń odczytu bez złożoności związanej z komunikacją międzyregionalną.

Azure SQL Managed Instance (MI) zapewnia niemal 100% zgodność z silnikiem SQL Server, w tym SQL Agent, zapytania międzybazodanowe, CLR, serwery połączone (linked servers), Service Broker oraz natywne tworzenie i przywracanie kopii zapasowych plików .bak z Azure Blob Storage. MI jest wstrzykiwane do VNet: wdrażasz je w dedykowanej, delegowanej podsieci z prywatnymi adresami IP i kontrolą za pomocą NSG/UDR; zaplanuj rozmiar podsieci i przestrzeń adresową z góry, ponieważ późniejsza zmiana rozmiaru podsieci jest skomplikowana. Ścieżki migracji obejmują Azure Database Migration Service (przełączenia online/offline), natywne przywracanie kopii zapasowej z adresu URL do MI oraz replikację transakcyjną z lokalnego SQL Server do MI. Wybierz MI, gdy wymagasz pełnej zgodności funkcjonalnej lub funkcji o zakresie instancji, których nie oferują pojedyncze bazy danych.

Azure Database for MySQL i Azure Database for PostgreSQL (w wariancie Flexible Server) dostarczają zarządzane silniki OSS z kontrolą nad oknami konserwacji, opcją zatrzymywania/uruchamiania w celu oszczędności kosztów, zasobami obliczeniowymi typu burstable i ogólnego przeznaczenia, automatycznym powiększaniem pamięci masowej oraz integracją z VNet. Flexible Server oferuje wysoką dostępność z replikacją synchroniczną; można wybrać HA z nadmiarowością strefową (zone-redundant) obejmującą wiele Stref Dostępności (Availability Zones) dla lepszej izolacji błędów lub HA w tej samej strefie (same-zone) dla niższych opóźnień zapisu. Repliki do odczytu (read replicas) są dostępne do skalowania operacji odczytu w poziomie i mogą być aprowizowane w tym samym regionie lub w różnych regionach; używają replikacji asynchronicznej i są idealne do analityki, raportowania lub mikrousług o dużej intensywności odczytów. W razie potrzeby można promować replikę w celu przełączenia awaryjnego lub ekspansji regionalnej, pamiętając o potencjalnym opóźnieniu replikacji.

Rozproszone dane i buforowanie (Cosmos DB i Azure Cache for Redis)

Azure Cosmos DB to globalnie dystrybuowana, wielomodelowa baza danych oferująca interfejsy API dla Core (SQL), MongoDB, Cassandra, Gremlin (grafy) i Table. Wybór API determinuje kompatybilność sterowników klienckich i semantykę modelu danych; operacyjnie, niezależnie od API, zarządzasz przepustowością (alokowane jednostki RU lub autoskalowanie) i partycjami. Dane są partycjonowane horyzontalnie za pomocą klucza partycji, który musi charakteryzować się wysoką kardynalnością i równomiernym rozkładem dostępu, aby unikać gorących partycji (hot partitions); unikaj kluczy monotonicznie rosnących i rozważ hierarchiczne klucze partycji w przypadku istnienia złożonych wzorców dostępu. Zapytania międzypartycyjne są obsługiwane, ale zużywają więcej jednostek RU; w miarę możliwości współlokuj powiązane dane według tego samego klucza partycji.

Poziomy spójności są konfigurowalne na poziomie konta, bazy danych lub żądania: Strong (silna) gwarantuje linearyzowalność; Bounded Staleness (ograniczona nieaktualność) ogranicza nieaktualność danych o czas lub wersję; Session (sesyjna), domyślna, zapewnia odczyt własnych zapisów w ramach sesji; Consistent Prefix (spójny prefiks) gwarantuje kolejność bez pełnej spójności; Eventual (ewentualna) maksymalizuje dostępność i wydajność. Dla zapisów wieloregionowych wybierz odpowiednią politykę rozwiązywania konfliktów (LastWriterWins lub niestandardowa za pomocą procedur składowanych) i zdefiniuj priorytety przełączania awaryjnego (failover). Globalna dystrybucja umożliwia dodawanie regionów jednym kliknięciem; usługa obsługuje replikację, przełączanie awaryjne i zoptymalizowane pod kątem opóźnień trasowanie z umowami SLA dotyczącymi przepustowości, opóźnień, dostępności i spójności.

Azure Cache for Redis zapewnia opóźnienia poniżej milisekundy, opierając się na technologii Redis. Poziomy (tiers) różnią się możliwościami: Basic (pojedynczy węzeł, dla środowisk deweloperskich/testowych), Standard (replikowany dwuwęzłowy klaster primary/replica z umową SLA), Premium (większe rozmiary, klastrowanie, trwałość zapisu (persistence), integracja z VNet, georeplikacja i moduły Redis, takie jak Bloom), Enterprise i Enterprise Flash (oparte na Redis Enterprise z zaawansowanym klastrowaniem, aktywną georeplikacją dla zapisów wielo-primary i większymi pamięciami podręcznymi opartymi na pamięci Flash). Polityki usuwania (eviction policies) definiują zachowanie w sytuacji braku pamięci: noeviction (błędy przy zapisie), allkeys-lru/lfu/random (dotyczy wszystkich kluczy) oraz volatile-lru/lfu/ttl/random (dotyczy tylko kluczy z ustawionym TTL). Do buforowania sesji użyj warstwy Premium lub wyższej w celu zapewnienia trwałości, jeśli nie możesz pozwolić sobie na utratę sesji, włącz TTL dla kluczy, aby ograniczyć rozrost danych, i rozważ klastrowanie w celu zwiększenia przepustowości i skalowalności. Umieść pamięć podręczną w tym samym regionie i sieci wirtualnej co serwery aplikacji, aby zminimalizować opóźnienia; użyj tożsamości zarządzanej (Managed Identity) lub kluczy dostępu i wymuś izolację sieciową za pomocą Private Link lub integracji z VNet.

Analityka i integracja (Synapse Analytics i Data Factory)

Azure Synapse Analytics unifikuje hurtownie danych, big data i integrację danych. Dedykowana pula SQL (dedicated SQL pool, dawniej SQL DW) to silnik MPP z dystrybucją danych typu hash/round-robin, replikowanymi tabelami i buforowaniem wyników zapytań (result-set caching). Możesz skalować moc obliczeniową w górę lub w dół, aby sprostać oknom czasowym SLA, a także wstrzymać ją, płacąc tylko za magazyn. Izolację obciążeń (workload isolation) można osiągnąć za pomocą grup obciążeń (workload groups) i ustawień ważności (importance), aby chronić krytyczne zapytania. Bezserwerowa pula SQL (serverless SQL pool) zapewnia dostęp na żądanie do danych w Azure Data Lake Storage Gen2 za pomocą T-SQL bez konieczności alokowania zasobów; płacisz za terabajty przeskanowanych danych i możesz eksternalizować schematy za pomocą widoków w celu tworzenia warstw semantycznych. Pule Spark (Spark pools) wprowadzają Apache Spark do Synapse z autoskalowaniem i klastrami na żądanie, umożliwiając pracę z notatnikami, Delta Lake i uczeniem maszynowym ze zintegrowanym bezpieczeństwem i śledzeniem pochodzenia danych (data lineage); możesz współdzielić dane lakehouse między silnikami Spark i SQL.

Azure Data Factory (ADF) służy do orkiestracji przesyłania i transformacji danych. Potoki (Pipelines) koordynują działania (activities), takie jak Kopiowanie (Copy), Przepływ danych (Data Flow, oparte na Sparku przepływy mapujące) i obliczenia zewnętrzne (Databricks, Synapse, Functions). Zestawy danych (Datasets) definiują strukturę i lokalizację danych, podczas gdy połączone usługi (linked services) hermetyzują szczegóły połączenia (uwierzytelnianie, punkty końcowe) do źródeł/celów. Środowiska Integration Runtimes (IR) zapewniają płaszczyznę obliczeniową i sieciową: Azure IR do natywnie chmurowego przesyłania i transformacji, Self-hosted IR dla źródeł lokalnych (on-premises) lub w sieciach prywatnych przez wychodzący ruch HTTPS, oraz Azure-SSIS IR do migracji typu „lift-and-shift” pakietów SSIS. Wyzwalacze (Triggers) – harmonogramowe, okna przesuwne (tumbling window), oparte na zdarzeniach – umożliwiają powtarzalną orkiestrację; zarządzana sieć wirtualna i prywatne punkty końcowe mogą być włączone w celu ochrony przed eksfiltracją danych i zapewnienia zgodnej z wymogami łączności. Parametryzacja i integracja z Key Vault wspierają tworzenie reużywalnych, bezpiecznych wzorców do promowania zmian między środowiskami (deweloperskie/testowe/produkcyjne).

Ciągłość działania, funkcje geograficzne i pule elastyczne

Strategie tworzenia kopii zapasowych i odzyskiwania różnią się w zależności od usługi, ale mają wspólne kluczowe motywy: automatyzuj, regularnie testuj przywracanie i oddzielaj PITR (błędy operacyjne) od LTR (zgodność z przepisami). W Azure SQL używaj PITR w przypadku przypadkowego usunięcia danych lub nieudanych wdrożeń; przechowuj cotygodniowe pełne kopie LTR w RA-GRS na potrzeby przechowywania wymaganego przez regulacje oraz odzyskiwania po awarii w innym regionie. W przypadku MySQL/PostgreSQL Flexible Server włącz automatyczne kopie zapasowe z magazynem geograficznie nadmiarowym (tam, gdzie jest to obsługiwane), ustaw okres przechowywania zgodnie z polityką i weryfikuj przywracanie do punktu w czasie na alternatywnych serwerach. Konta Cosmos DB z wieloma regionami umożliwiają automatyczne przełączanie awaryjne; połącz je z zapisami wieloregionowymi, gdy RPO musi wynosić zero, a aplikacja potrafi deterministycznie rozwiązywać konflikty.

Georeplikacja i grupy automatycznego przełączania awaryjnego w Azure SQL zapewniają odzyskiwanie po awarii (DR) i odciążenie odczytów. Używaj aktywnej georeplikacji dla pojedynczej bazy danych/puli, gdy chcesz jawnie zarządzać replikami pomocniczymi; używaj grup automatycznego przełączania awaryjnego, aby grupować wiele baz danych i uzyskać odbiorniki oparte na DNS oraz automatyczne przełączanie awaryjne. Tam, gdzie liczą się odczyty o niskim opóźnieniu, ale DR nie jest celem, użyj skalowania odczytu w poziomie w warstwie Business Critical lub nazwanych replik w warstwie Hyperscale, aby przenieść analitykę i raportowanie poza replikę podstawową. Monitoruj opóźnienie replikacji i sygnały o stanie przełączania awaryjnego oraz przeprowadzaj testowe ćwiczenia przełączania awaryjnego, aby zweryfikować RTO/RPO.

Pule elastyczne to narzędzia optymalizacji kosztów dla wielodostępnych aplikacji SaaS i flot małych baz danych. W pulach opartych na DTU alokuj eDTU z limitami dla poszczególnych baz danych; w pulach opartych na vCore alokuj vCore, pamięć i przepustowość IO z maksymalną liczbą vCore na bazę danych i zarządzaniem IO. Dopasuj rozmiar, mierząc wykorzystanie na poziomie 95. percentyla dla każdej bazy danych i dostosowując pojemność puli do wzorców współbieżności; podnieś limity dla poszczególnych baz danych dla najemców z wyższymi SLO i rozważ podział pul według klasy obciążenia (np. najemcy z dużym vs. małym obciążeniem). Używaj alertów dotyczących limitów puli i poszczególnych baz danych, aby wcześnie wykrywać nasycenie. Gdy kilka baz danych konsekwentnie osiąga maksymalne limity, przenieś je do dedykowanych zasobów obliczeniowych lub oddzielnej puli, aby zachować przewidywalność.

Praktyczny scenariusz problemu

Firma Starbucks musi zmodernizować swoją globalną platformę lojalnościową, aby sprostać szczytowemu ruchowi podczas promocji, zmniejszyć obciążenie operacyjne i wspierać analitykę bez zakłócania działalności sklepów na całym świecie.

Podziel operacyjną składnicę danych na partycje:

Wybierz Azure Cosmos DB (Core SQL API) dla interakcji z klientami i zdarzeń związanych z nagrodami, aby osiągnąć globalną dystrybucję z niskim opóźnieniem. Skonfiguruj zapisy wieloregionowe w regionach bliskich głównym populacjom klientów i ustaw spójność na poziomie Session, aby zrównoważyć odczyt własnych zapisów z wydajnością. Wybierz klucz partycji o wysokiej kardynalności, taki jak customerId, lub złożony klucz hierarchiczny (customerId, eventMonth), aby rozłożyć przepustowość i wspierać typowe wzorce zapytań.

Zaimplementuj transakcyjne dane kont i katalogów:

Wdróż Azure SQL Managed Instance dla sald kont, realizacji nagród i katalogu SKU, ponieważ wymagana jest niemal 100% zgodność z SQL Server dla istniejących procedur składowanych i logiki międz bazodanowej. Umieść MI w dedykowanej, delegowanej podsieci z grupami NSG i tabelami routingu, zgodnie z wymogami wstrzykiwania do VNet, umożliwiając prywatny dostęp z podsieci aplikacji i ExpressRoute.

Zapewnij globalne skalowanie odczytu i DR dla relacyjnych obciążeń roboczych:

Dla nowych mikrousług korzystających z Azure SQL Database użyj warstwy vCore Business Critical dla niskiego opóźnienia i skalowania odczytu w poziomie. Utwórz grupę automatycznego przełączania awaryjnego do sparowanego regionu z punktami końcowymi odbiornika tylko do odczytu dla zlokalizowanych odczytów i automatycznego przełączania awaryjnego, aby osiągnąć cele DR.

Dodaj zarządzanie sesjami o niskim opóźnieniu:

Wdróż Azure Cache for Redis w warstwie Premium z klastrowaniem i trwałością danych dla tokenów sesji internetowych i mobilnych. Ustaw zasadę usuwania allkeys-lfu, aby najczęściej używane sesje pozostawały w pamięci. Zintegruj pamięć podręczną w tej samej sieci VNet i regionie co warstwa aplikacji, aby zminimalizować opóźnienia.

Orkiestruj przepływ danych i buduj analitykę:

Użyj Azure Data Factory do kopiowania danych operacyjnych (z Cosmos DB change feed i SQL MI) do Azure Data Lake Storage Gen2. Wykorzystaj Managed VNet IR z prywatnymi punktami końcowymi, aby zapobiec eksfiltracji danych. Parametryzuj potoki i używaj wyzwalaczy okna kroczącego (tumbling window), aby zagwarantować przetwarzanie w ustalonej kolejności.

Włącz analitykę korporacyjną z elastyczną kontrolą kosztów:

W Azure Synapse Analytics użyj bezserwerowej puli SQL do eksploracji ad hoc danych w formacie parquet oraz dedykowanej puli SQL dla wyselekcjonowanych modeli BI o wysokiej współbieżności i przewidywalnej wydajności. Utwórz pule Spark do inżynierii cech na podstawie zachowań lojalnościowych i zapisuj tabele Delta w data lake, aby zapewnić interoperacyjność między Spark i SQL.

Zarządzanie, kopie zapasowe i przechowywanie:

Skonfiguruj priorytety automatycznego przełączania awaryjnego w Cosmos DB i monitoruj konflikty, używając zasady LastWriterWins z polem znacznika czasu. Dla Azure SQL Database i MI zweryfikuj okna PITR i włącz LTR, aby spełnić wymogi przechowywania na potrzeby zgodności z przepisami. Dla instancji Flexible Server obsługujących pomocnicze usługi OSS (np. telemetrię regionalnych sklepów w PostgreSQL), włącz strefowo nadmiarową wysoką dostępność (HA) i skonfiguruj repliki do odczytu na potrzeby raportowania.

Dlaczego te usługi: Globalna dystrybucja i strojalna spójność Cosmos DB odpowiadają na potrzeby globalnych interakcji wrażliwych na opóźnienia; MI zachowuje złożone funkcje SQL Server, zapewniając jednocześnie zarządzane operacje; bazy danych w warstwie Business Critical dostarczają lokalne skalowanie odczytu bez opóźnień międzyregionalnych; Redis zapewnia dostęp do sesji w czasie poniżej milisekundy podczas skoków ruchu; ADF zapewnia bezpieczny, zarządzany przepływ danych z sieci prywatnych; Synapse łączy analitykę na żądanie i aprowizowaną, oferując efektywne kosztowo i skalowalne analizy. Taka kompozycja spełnia wydajnościowe SLO podczas promocji, redukuje wysiłek administracyjny dzięki zarządzanym usługom PaaS i wymusza jasne granice RTO/RPO oraz zgodności z przepisami.

← Azure App Service i usługi obliczeniowe PaaS · Wszystkie domeny · Azure Monitor →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →