Kwarcianka i separacja przechowywania od obliczeń

Rozdzielanie przechowywania od obliczeń

Klasyczne magazyny danych — myślimy o maszynie Teradata lub Netezza w miejscu — połączały przechowywanie i obliczenia na tym samym fizycznym sprzęcie, ponieważ to była jedyna architektura dostępna podczas projektowania tych systemów. Konsekwencją było to, że skalowanie dla większego przechowywania oznaczało zakup dodatkowych obliczeń, nawet jeśli ich nie potrzebowano, a odwrotnie — skalowanie obliczeń wymagało zakupu dodatkowego przechowywania. Każda zapytanie, wykonane przez jednego analistę czy setku, konkurencjała za ustaloną pulę CPU. Centralnym decyzją architektoniczną Snowflaki była rozdzielanie tego połączenia na trzy oddzielne warstwy, które skalują i są facturowane niezależnie: warstwę przechowywania opartą na obiektowym przechowywaniu w chmurze (podstawieniem S3, Azure Blob lub GCS), warstwę obliczeniową z oddzielnie określonymi 'wirtualnymi magazynami obliczeń', oraz warstwę usług w chmurze zajmującą się metadanych, analizowaniem i przetwarzaniem zapytań, a także kontrolą dostępu.

Ta separacja brzmi jak mała decyzja inżynieryjna, ale zmienia ekonomię działania magazynu podstawowymi sposobami. Spółka może przechowywać dziesięć lat historii kliknięć w warstwie przechowywania, prawie za ceny obiektowych, a płaci tylko za obliczenia w chwilach każdego dnia, gdy ktoś rzeczywiście wykonuje zapytanie — i różne zespoły mogą tworzyć własne oddzielnie określone cluster obliczeniowe na exact tym samym podstawowym zestawie danych bez konkurowania między sobą za CPU.

Micro-partycje: jednostka przechowywania

Kiedy dane są załadowane do Snowflake, są automatycznie podzielone na micro-partycje — ciągłe, niezmienne kawałki zazwyczaj zawierające między 50 a 500 MB danych niewyrenderowanych, przechowywanych w formacie kolumnarnym. Dla każdej micro-partycji warstwa metadanych Snowflake rejestruje najmniejszą i największą wartość każdego kolumny bez konieczności zdefiniowania indeksu. Jest to forma automatycznej, szerszej klasteringi: gdy zapytanie filtuje na podstawie kolumny — `gdzie data_zamówienia > '2026-01-01'` — planer zapytań może pomijać całe micro-partycje, których zakres minimalnej i maksymalnej wartości nie nadmiarowo pokrywa się z filtrem, technika nazywana przycinaniem. Bez konieczności dotyku rzeczywistych danych w tych partycjach.

Dzięki temu, że micro-partycje są niezmienne, aktualizacja lub usunięcie nie pisze nowych wierszy na miejscu; zapisuje nowe micro-partycje ze zmienionymi wierszami i oznacza stare jako nie widoczne dla nowych zapytań. Jest to również mechanizm za pomocą którego Snowflake oferuje funkcję podróży w czasie — możesz zapytać o tabelę jak wyglądała w pewnym momencie niedawnego przeszłości, ponieważ stare micro-partycje nie zostały na prawdę usunięte, tylko nadpisane. Ta niezmienna, orientowana do dodawania deklaracja jest to co pozwala dzieleniu warstwy przechowywania Snowflake między wiele równocześnie uruchomionych klastrów obliczeniowych: nikt nigdy nie modyfikuje bloku, który inna warstwa może czytać podczas zapytania.

Wirtualne magazyny i niezależna skalizacja

Wirtualny magazyn to klaster węzłów obliczeniowych, określony w jednostkach nazywanych rozmiarami koszul (X-Mini do 6-X Duży, każdy podwójnie większy niż poprzedni), który odczytuje z warstwy współdzielonej magazynu, ale nie ma własnego trwałościowego stanu poza lokalnym buforowaniem SSD cache najbliższych mikro-partycji. Ponieważ magazyn ten nie przechowuje żadnych unikalnych danych, włączanie lub wyłączanie go jest niemalże natychmiastowe, a — to ważne — można uruchomić dowolną liczbę magazynów jednocześnie dla tych samych tabel bez tego, że by się nawzajem przeszkadzały, ponieważ nie dzielą one CPU ani pamięci, tylko czytają tę samą niewymienioną warstwę magazynu podstawowego.

To dlatego Snowflake stała się popularna w rozwiązywaniu klasycznego problemu „noisy neighbour” w współdzielonych magazynach: zapytania finansowe dotyczące raportów na koniec miesiąca i ad hoc eksploracyjne zapytania z dziedziny danych mogą działać na całkowicie oddzielnych wirtualnych magazynach, odpowiednio rozmiarowych dla każdego obciążenia, naliczanych osobno, a żaden z nich nie może utrudnić działania drugiego, przechwytując CPU. Naliczanie jest oparte na tej samej logice: Snowflake nalicza za sekundy czas, podczas gdy wirtualny magazyn rzeczywiście działa (z funkcją automatycznego wyłączania magazynów puste przez określony czas, zwykle kilka minut), więc magazyn wykonujący regularne zbiory danych trwałe 5 minut dziennie kosztuje tylko małą część magazynu działającego ciągle — kontrast przeciwko modelowi urządzenia o ustalonej pojemności, w którym płacisz za maksymalną pojemność w ciągu dnia.

Warstwa usług w chmurze i miejsce, gdzie znajduje się inteligencja

Na powierzchni obu przechowywania i obliczeń leży warstwa usług w chmurze, zestaw udostępnionych usług zawsze dostępnych, które zarządzają analizą zapytań, ich optymalizacją, autoryzacją i kontrolą dostępu, zarządzaniem transakcjami oraz katalogiem metadanych, który śledzi, do których mikro-partycji należy każda wersja tabeli. Ta warstwa jest to, co pozwala na realizację klonowania bez kopii: klonowanie wieloterabajowej tabeli trwa sekundy, ponieważ Snowflake kopiuje tylko wskaźniki metadanych do tych samych podstawowych mikro-partycji, nie fizycznie duplikując żadnych danych — klon zaczyna korzystać z nowego przechowywania dopiero w momencie pisania zmian przez jedno z obu stron, które się różnią od oryginału.

Przykładowa oferta tej architektury polega na tym, że przestajesz dyspozycyjnie kontrolować fizyczne struktury indeksów, schematy podziału i układ przechowywania — Snowflake decyduje o większości tych spraw automatycznie. W przypadku większości obciążen analizowych ta wymiana jest rozsądna: automatyczne grupowanie i przycinanie działają dobrze bez dostosowywania, a operacyjna prostej nie zarządzanie przechowywaniem fizycznym całkowicie odbija się na utraconej kontroli. Tylko w przypadku obciążeń, które wymagają bardzo precyzyjnego układu danych fizycznego z powodów dotyczących opóźnień, ta oferta staje się rzeczywistą ograniczeniem — co jest jednym z powodów, dla których Snowflake jest skierowany do obciążeń analizowych (OLAP) a nie transakcyjnych (OLTP).

Często zadawane pytania

Wypróbuj na żywo

Wszystko powyżej działa bezpośrednio w Twojej przeglądarce — otwórz Snowflake and the Separation of Storage from Compute i zmieniaj parametry podczas działania. Nic nie jest instalowane ani przesyłane na serwer, cały model działa w jednej karcie.