Protokoły interfejsu API

Zerobus Ingest udostępnia jeden punkt końcowy obsługujący kilka protokołów API: gRPC (za pośrednictwem pakietów SDK), REST, OpenTelemetry (OTLP), MQTT oraz interfejsy API zgodne z Kafką. Wszystkie zapisują się bezpośrednio do tabel Unity Catalog Delta, więc wybierasz protokół najlepiej dopasowany do każdego producenta.

Poniższy diagram pokazuje, jak rekordy ze strumieni źródłowych i API przepływają przez automatyczne skalowanie i równoważenie obciążenia do poziomo skalowalnej puli bezstanowych węzłów Zerobus. Każdy węzeł ma dziennik zapisu z wyprzedzeniem oraz zapis Lakehouse, który składa zapisy do tabeli Delta zarządzanej przez Unity Catalog. Etykiety źródłowe na diagramie są reprezentatywne. MQTT podąża tą samą ścieżką przez równoważenie obciążenia, trwałe przechowywanie i materializację stołów.

Diagram architektury zerobus Ingest pokazujący API źródłowe przepływające przez load balancing i stanowe węzły do tabeli Delta.

Jakiego protokołu powinieneś użyć?

Protokół Najlepsze dla Dlaczego
gRPC (SDK) Wysokowolumenowe źródła danych strumieniowych: przechwytywanie zmian danych, strumienie kliknięć oraz mechanizmy przekazywania logów i zdarzeń. Trwałe połączenia zapewniają najwyższą stałą przepustowość i zachowują kolejność w obrębie każdego strumienia. Dostępne w Python, Java, Rust, Go, TypeScript oraz (w wersji beta) C++ i C# / .NET. Zobacz Tworzenie klienta.
REST Duże floty lekkich lub "rozmownych" klientów, takich jak urządzenia edge i IoT, które raportują rzadko. Bezstanowość: każde żądanie jest niezależne, więc klienci nie utrzymują otwartego połączenia. Prostsze dla urządzeń, które od czasu do czasu wysyłają dane. Zobacz przykład REST.
OpenTelemetry (OTLP) Potoki obserwowalności już emitują ślady, logi i metryki. Skieruj swoje istniejące pakiety SDK OpenTelemetry lub kolektory do punktu końcowego bez konieczności tworzenia niestandardowej integracji. Zobacz Pozyskiwanie danych OpenTelemetry za pomocą Zerobus Ingest.
MQTT Aplikacje IoT, edge i telemetry, które już publikują wiadomości MQTT v5. Ponownie użyj klienta MQTT v5 do publikowania rekordów JSON do tematu nazwanego od docelowej tabeli. Zobacz Użyj MQTT z Zerobus Ingest.
API kompatybilne z Kafką Producenci, którzy już obsługują protokół Kafka, lub narzędzia wysyłające dane do Kafki — gdy chcesz przenieść te dane do Delty przy minimalnych zmianach w kodzie. Użyj ponownie istniejącego producenta Kafka bez zestawu SDK platformy Azure Databricks. Skieruj go do punktu końcowego i publikuj do tematu o nazwie takiej jak Twoja tabela docelowa. Zobacz Używaj API kompatybilnych z Kafką z Zerobus Ingest.

gRPC z zestawami SDK

SDK Zerobus owijają trwałe, dwukierunkowe połączenie gRPC zwane strumieniem. Ponieważ połączenie pozostaje otwarte, gRPC osiąga najwyższą stałą przepustowość i jest zalecanym rozwiązaniem do ciągłego przyjmowania dużych wolumenów danych. Każdy otwarty strumień to długowieczne połączenie, więc przepustowość klienta rośnie wraz z liczbą otwieranych strumieni.

Zestawy SDK obsługują zarządzanie połączeniami, śledzenie offsetów i mechanizmy odzyskiwania oraz są dostępne w Pythonie, Javie, Ruście, Go, TypeScripcie, a także (w wersji beta) w C++ i C# / .NET. Zapewniają równoważne zachowanie w różnych językach, więc wybierz ten, który pasuje do Twojej aplikacji. Przez gRPC pakiety SDK obsługują formaty rekordów JSON, protobuf i Apache Arrow, a niektóre pakiety SDK obsługują także Avro (Beta). Zobacz Typy wiadomości.

Aby napisać klienta z użyciem SDK, w tym przykłady dla każdego języka, zobacz Write a client.

REST

Interfejs REST jest bezstanowy: każde żądanie kończy się samodzielnie, bez konieczności utrzymywania otwartego połączenia. To sprawia, że jest to idealne rozwiązanie dla dużych flot lekkich lub przerywanych producentów, na przykład urządzeń edge i IoT, które rzadko raportują status, gdzie utrzymanie stałego połączenia na każde urządzenie byłoby niepraktyczne.

Pozyskiwanie danych przez interfejs REST podlega limitowi liczby żądań (zobacz Limity pozyskiwania Zerobus). Dla producenta o dużej skali pakiety SDK korzystające z gRPC zapewnią większą przepustowość niż wysyłanie wielu pojedynczych żądań REST. Zarezerwuj REST dla producentów, którzy wysyłają rzadko lub nie mogą utrzymać stałego połączenia.

OpenTelemetry (OTLP)

Zerobus Ingest zawiera natywny punkt końcowy protokołu OpenTelemetry. Jeśli twoje systemy już generują ślady, logi i metryki OpenTelemetry, możesz skierować istniejące eksportery lub kolektory OTLP do Zerobus Ingest i zapisywać tę telemetrię bezpośrednio w tabelach Delta, których jesteś właścicielem, zwykle wystarczy tylko zmiana konfiguracji. Zobacz Pozyskiwanie danych OpenTelemetry za pomocą Zerobus Ingest.

MQTT

Ważna

Ta funkcja jest dostępna w wersji beta.

Interfejs MQTT akceptuje połączenia MQTT v5 przez TLS na porcie 8883. Jedno połączenie celuje w jedną tabelę, a każda wiadomość zawiera jeden obiekt JSON UTF-8. Stosuj jakość usługi (QoS) na poziomie 1, gdy producent wymaga trwałego potwierdzenia. Aby uzyskać informacje o konfiguracji, uwierzytelnianiu, ograniczeniach i przykładzie Python, zobacz Użyj MQTT z Zerobus Ingest.

API kompatybilne z Kafką

Ważna

API kompatybilne z Kafką są w fazie beta.

Zerobus Ingest oferuje zgodne z Apache Kafka interfejsy API producenta, dzięki czemu możesz pozyskiwać dane za pomocą dowolnego klienta producenta Apache Kafka bez pakietu SDK platformy Azure Databricks. Wskazujesz istniejącego producenta Kafka na punkt końcowy i wysyłasz dane do tematu o nazwie odpowiadającej tabeli docelowej, a rekordy trafiają do tabeli Delta w Unity Catalog. To najlepszy wybór, jeśli masz już uruchomionego producenta Kafka albo kolektor czy agenta, który wysyła dane do Kafka, i chcesz kierować te dane do Delta przy minimalnych zmianach w kodzie.

Interfejsy API zgodne z Kafką implementują podzbiór protokołu Kafka po stronie producenta i obsługują wyłącznie zapis: interfejsy API konsumenckie, administracyjne i transakcyjne nie są dostępne. Akceptują tylko rekordy JSON. Przepustowość jest regulowana przez kwotę żądań na przestrzeń roboczą, a nie przez pojedyncze połączenia. Dla konkretnej kwoty zobacz Zerobus Ingest quotas. Aby uzyskać najwyższą przepustowość, potwierdzenia na rekord i automatyczne odzyskiwanie, zamiast tego użyj SDK Zerobus zamiast gRPC.

Informacje o konfiguracji, uwierzytelnianiu oraz przykład producenta znajdziesz w artykule Korzystanie z interfejsów API zgodnych z Kafka w usłudze Zerobus Ingest.