Koncepcje pozyskiwania danych w Zerobus

Ta strona opisuje podstawowe koncepcje Zerobus Ingest w Lakeflow Connect: jak działa usługa, jej strumienie, serwer i klienci oraz obsługiwane przez nią typy danych.

Przejdźmy do konkretnej koncepcji:

• Jak działa Zerobus Ingest: cały przepływ, od producenta do tabeli, którą można odpytywać.
• Serwer: za co odpowiada usługa Zerobus Ingest.
• Klient: za co odpowiada Twój producent.
• Strumienie: połączenie, które klient otwiera do pobierania danych.
• Jak skaluje się Zerobus Ingest: dlaczego skaluje się bez planowania przepustowości.
• Wymagania dotyczące stołu: co musi spełniać Twój docelowy stół i przestrzeń pracy.
• Ograniczenia: nieobsługiwane typy tabel, operacje tabelowe oraz kolejność między strumieniami.
• Obsługiwane typy danych: mapowanie typu Delta-do-Protobuf.

Jak działa Zerobus Ingest

Producent danych najpierw łączy się z API Zerobus Ingest i określa docelową tabelę Delta, konstruuje komunikat odpowiadający jego schematowi, a następnie wysyła tę wiadomość. Usługa sprawia, że dane są trwałe i w interfejsach zapewniających potwierdzenia trwałości potwierdzają komunikat klienta. Następnie materializuje dane w tabeli Delta, w zoptymalizowany sposób, jako osobny krok. Potwierdzenie trwałości potwierdza trwałość, a nie możliwość zapytania. Zobacz komunikację asynchroniczną , aby dowiedzieć się, jak to działa i co oznacza dla Twojego klienta.

Zerobus Ingest to usługa bezserwerowa, która skaluje się elastycznie wraz z Twoim obciążeniem. Informacje o skalowaniu znajdują się poniżej: Jak skaluje się Zerobus Ingest.

Ta sekcja obejmuje także sposoby łączenia się z Zerobus Ingest oraz kształty, jakie mogą przybierać Twoje dane:

• Protokoły API: protokoły API, gRPC wraz z pakietami SDK, REST, OpenTelemetry, MQTT oraz interfejsy API zgodne z Kafka, a także kiedy stosować każdy z nich.
• Typy komunikatów: formaty rekordów, JSON, bufory protokołu (protobuf) oraz Apache Arrow oraz kiedy używać każdego z nich.

Server

Usługa pozyskiwania Zerobus nie tworzy tabel ani nie manipuluje nimi. Użytkownicy muszą utworzyć tabelę samodzielnie. Tabele i ich schematy są autorytatywnymi źródłami oczekiwań dotyczących danych przychodzących.

Serwer Zerobus Ingest akceptuje dane przesyłane przez klientów i sprawdza, czy pasują one do schematu docelowej tabeli. Jeśli rekord pasuje, serwer czyni go trwałym i gdy interfejs zapewnia potwierdzenie trwałości, potwierdza je klientowi. Materializacja rekordu do tabeli Delta, aby stał się zapytanialny, następuje jako osobny krok niedługo potem.

Obowiązki związane z usługą obejmują:

• Weryfikacja schematu wiadomości względem tabeli.
• Uczynienie pliku trwałym, a gdy interfejs zapewnia potwierdzenie trwałości, potwierdzanie go klientowi. Potwierdzenie potwierdza trwałość, choć nie jest jeszcze przedmiotem weryfikacji.
• Materializacja danych w docelowej tabeli w odpowiednim czasie, wtedy staje się ona podatna na zapytania. Wartości opóźnień znajdują się w sekcji Opóźnienia.

Client

Klient łączy się z Zerobus Ingest, wysyła rekordy i, gdy interfejs to obsługuje, potwierdza, że są one trwałe. Gdy używasz Zerobus Ingest SDK, SDK obsługuje większość tego za Ciebie, więc pomaga oddzielić konfigurację od tego, co robi SDK automatycznie.

Konfigurujesz lub implementujesz:

• Wybieranie tabeli docelowej.
• Otwieram strumień do usługi Zerobus Ingest.
• Skonstruowanie wiadomości zgodnej ze schematem i jej wysłanie.

SDK automatycznie obsługuje:

• Potwierdzenia odbioru wiadomości. Pakiet SDK uruchamia za Ciebie pętlę potwierdzeń i udostępnia potwierdzenia trwałości za pośrednictwem offsetów lub funkcji zwrotnej potwierdzenia. Blokujesz konkretny rekord tylko wtedy, gdy wymaga tego aplikacja. Zobacz komunikację asynchroniczną.
• Powrót do zdrowia. Domyślnie SDK ponownie łączy się i odtwarza niepotwierdzone rekordy w przypadku przejściowych awarii.
  • Możesz wyłączyć wbudowane systemy odzyskiwania i wdrożyć własny mechanizm odzyskiwania. Aby dowiedzieć się, co wywołuje odzyskiwanie, opcje konfiguracji oraz wzorce niestandardowego odzyskiwania, zobacz wzorce odzyskiwania i próby ponownej.

Nie musisz ręcznie zapisywać potwierdzenia ani logiki odzyskiwania, gdy używasz SDK. Dla niestandardowych integracji, które nie wykorzystują SDK, repozytorium SDK Zerobus jest źródłem informacji o strukturze integracji i obsłudze procesu odzyskiwania.

Strumienie

Strumień to bezpośrednie połączenie między Twoim klientem a serwerem Zerobus Ingest, ustanowione przez trwałe, dwukierunkowe połączenie gRPC. Zestawy SDK używają strumieni do obsługi długotrwałych połączeń o wysokiej przepływności.

• Strumienie są używane tylko w interfejsie API gRPC z bibliotekami SDK.
• Strumień pozyskuje dane do jednej tabeli docelowej.
• Otwórz dodatkowe strumienie, aby zapisywać dane w różnych tabelach lub zwiększyć przepustowość pojedynczego klienta do poziomu wymaganego przez obciążenie.

Strumienie są także jednostką określającą kolejność (zobacz Gwarancje kolejności) oraz jednostką, według której skaluje się Zerobus Ingest (zobacz Jak skaluje się Zerobus Ingest).

Gwarancje porządkowania

Zamawianie jest gwarantowane na każdy stream. Rekordy są zatwierdzane w docelowej tabeli w kolejności, w jakiej są kolejkowane w jednym strumieniu. Nie ma globalnego porządku między strumieniami. Z tego wynika kilka punktów konstrukcyjnych:

• Jeśli rozłożysz rekordy na wiele strumieni (na przykład w systemie round-robin), nie ma gwarancji kolejności między tymi strumieniami.
• Jeśli Twój przypadek użycia wymaga jednej globalnej kolejności dla wielu producentów lub strumieni, wymuś tę kolejność w aplikacji (na przykład za pomocą znacznika czasu lub numeru sekwencyjnego, na podstawie którego wykonujesz zapytania), zamiast polegać na kolejności przyjmowania danych.

Dlaczego gRPC streaming

Ponieważ połączenie gRPC dla strumienia pozostaje otwarte, klient unika kosztu konfiguracji wymaganego dla każdego żądania w protokole bezstanowym i może przesyłać ciągły strumień rekordów o dużym wolumenie jednym kanałem. To właśnie sprawia, że SDK są najwydajniejszym sposobem pobierania. Informacje o pozostałych interfejsach (REST, OpenTelemetry, MQTT i interfejsach API zgodnych z Kafka) oraz o tym, kiedy wybrać każdy z nich, znajdziesz w artykule Protokoły API.

Jak skaluje się Zerobus Ingest

Zerobus Ingest jest zaprojektowany z myślą o wysokiej skalowalności i osiąga tę skalę bez konieczności planowania pojemności. Dwa wybory projektowe to umożliwiają:

• Jest bezserwerowy. Usługa automatycznie dodaje i usuwa pojemność wraz ze zmianą obciążenia, więc nie zmieniasz rozmiaru brokerów ani nie przydzielasz partycji. Możesz otworzyć tyle równoległych strumieni i zapisywać do tylu tabel, ile wymaga obciążenie.
• Strumienie są jednostkami dynamicznego podziału. Zamiast stałego zestawu partycji, które muszą być ponownie partycjonowane i zbalansowane, aby skalować dalej, strumienie można otwierać, zamykać i obracać. Rotacja strumieni pozwala usłudze na bieżąco równoważyć przepustowość i zasoby, gdy zmienia się zapotrzebowanie, dzięki czemu możesz skalować system, otwierając więcej strumieni i uruchamiając większą liczbę producentów, a usługa bierze na siebie całą resztę.

Praktycznym efektem jest to, że klient "hello world" i obciążenie w skali petabajtów działają zasadniczo na tym samym kodzie. Różnica polega na liczbie producentów i streamów, których prowadzisz. Ten projekt pozwala na pobieranie ponad 1 biliona rekordów do jednej tabeli Delta. Techniczne tło można znaleźć w wpisie na blogu Ingesting the Milky Way: Petabyte-Scale with Zerobus Ingest .

Wymagania dotyczące tabel

Zerobus Ingest zapisuje dane w tabeli Delta, którą sam tworzysz i jesteś jej właścicielem. Stół docelowy i przestrzeń pracy muszą spełniać następujące wymagania:

• Docelowa tabela musi być zarządzaną tabelą Delta lub tabelą streamingową.
• Nazwy tabel mogą zawierać wyłącznie litery ASCII, cyfry i podkreślenia.
• Przestrzeń robocza i tabela docelowa muszą znajdować się w jednym z obsługiwanych regionów.

Aby dowiedzieć się, jak rekordy są weryfikowane względem schematu tabeli, zobacz zarządzanie schematem. Aby poznać cechy tabel, takie jak podział i klastrowanie cieczy, zobacz cechy tabeli Delty. Informacje o nieobsługiwanych typach tabel i operacjach można znaleźć w sekcji Ograniczenia.

Limitations

Zerobus Ingest ma następujące ograniczenia:

• Zerobus Ingest nie zapisuje do zewnętrznych tabel ani widoków.
• Zerobus Ingest nie zapisuje do magazynu zabezpieczonego za pomocą prywatnego punktu końcowego.
• Zerobus Ingest nie tworzy tabel docelowych ani nie zmienia ich schematu. Tworzysz tabelę i zmieniasz schemat tabeli. Zobacz ewolucję schematu.
• Zerobus Ingest nie obsługuje ponownego utworzenia tabeli docelowej.
• Zerobus Ingest nie obsługuje zmiany nazwy ani wymiany tabeli docelowej podczas aktywnego pozyskiwania danych. Zobacz temat Zmień nazwę lub zamień tabelę docelową.
• Zerobus Ingest nie obsługuje nazw tabel zawierających znaki inne niż litery ASCII, cyfry i podkreślenia.
• Zerobus Ingest nie gwarantuje kolejności między strumieniami. Kolejność jest gwarantowana tylko w obrębie jednego strumienia. Zobacz Gwarancje kolejności.

Aby poznać limity numeryczne, takie jak przepustowość, rozmiar rekordu i rozgałęzienie partycji, zobacz Zerobus Ingest quotas.

Zmień nazwę lub zamień tabelę docelową

Nie zmieniaj nazwy, nie usuwaj i nie twórz ponownie ani nie zastępuj tabeli docelowej innym obiektem, na przykład widokiem, gdy strumienie do niej zapisują. Zerobus Ingest nie może zapisać danych z bufora do tabeli, której nazwę zmieniono lub którą zastąpiono, więc dotknięte strumienie przestają robić postępy, a rekordy, które jeszcze nie zostały potwierdzone, nie mogą zostać zapisane. Dane, które pozostają niezapisane, są usuwane po upływie okresu przechowywania danych buforowanych.

Obsługiwane są zmiany schematu, takie jak dodanie kolumny za pomocą ALTER TABLE. Zobacz ewolucję schematu.

Aby bezpiecznie zmienić nazwę lub przenieść tabelę docelową:

1. Zatrzymaj producentów, a potem opróżnij i zamknij każdy strumień zapisujący do tabeli. Zobacz opróżnianie i łagodne zamknięcie.
2. Potwierdź, że najnowsze zapisy pojawiają się w tabeli.
3. Zmienij nazwę lub przenieś tabelę.
4. Nadaj jednostce usługi, która pobiera dane USE CATALOG, USE SCHEMA, SELECT i MODIFY, uprawnienia do nowej tabeli. Zobacz Jak utworzyć jednostkę usługi i nadać uprawnienia.
5. Zaktualizuj producentów, aby używali nowej nazwy tabeli, a potem otwórz nowe streamy. Jeśli twoi producenci proszą o tokeny OAuth przypisane do tabeli, poproś o nie dla nowej tabeli.

Obsługiwane typy danych

W poniższej tabeli przedstawiono obsługiwane typy delty i odpowiadające im typy Protobuf na potrzeby ingestii.

Typy Avro

Gdy przetwarzasz rekordy w formacie Avro, Zerobus Ingest dekoduje każdy rekord względem dostarczonego schematu zapisu Avro i konwertuje go do typów docelowej tabeli Delta. Poniższa tabela pokazuje, jak typy Avro odwzorowują się na typy Delta.

To mapowanie opiera się na konwencjach źródła danych Spark Avro. O samym systemie typów Avro zobacz specyfikację Apache Avro.

TIMESTAMP kolumny zapisywane są jako chwile UTC. Avro nie posiada 8-bitowego ani 16-bitowego typu całkowitoliczbowego, więc kolumn TINYINT i SMALLINT nie można wskazać w Avro jako docelowych. Avro nie może też zapisywać do kolumn VARIANT, VOID, INTERVAL, GEOMETRY ani GEOGRAPHY. Schemat celujący w jeden z tych elementów jest odrzucany podczas tworzenia strumienia.

Schematy zapisujące Avro muszą również deklarować każdy typ w linii; nie są obsługiwane odwołania do typów nazwanych. Zobacz Avro.