Funkcje Zerobus Ingest

Ta strona przedstawia przegląd tego, co oferuje Zerobus Ingest w Lakeflow Connect. Każda funkcja łączy się z pełną dokumentacją.

• Endpoint zawsze włączony: bezserwerowy, domyślnie włączony, skaluje się automatycznie.
• Metody uwierzytelniania: sposób uwierzytelniania klientów, w tym OAuth jednostki usługi oraz federacja zewnętrznych dostawców tożsamości.
• Blokowanie komunikatów: metody odbioru i sposoby potwierdzania trwałości zapisu.
• Funkcje zwrotne potwierdzeń: umożliwiają asynchroniczne reagowanie na potwierdzenia i błędy.
• Funkcje tabeli delta: partycjonowanie, grupowanie płynne oraz VARIANT dane.
• Kolumna ratunkowa: przejmuj pola, które nie pasują do schematu tabeli, zamiast je odrzucać.
• Trwała lokalizacja zapasowa: miejsce, do którego trafiają dane, jeśli nie można ich opublikować.
• Monitorowanie zużycia: tabele systemowe dotyczące zużycia i wydatków.

Zawsze aktywny punkt końcowy

Zerobus Ingest to bezserwerowy punkt końcowy, który jest domyślnie włączony dla przestrzeni roboczych w obsługiwanych regionach. Nie ma nic do uruchamiania, konfigurowania ani skalowania. Gdy już masz tabelę docelową i autoryzowaną tożsamość, możesz zacząć przesyłać dane, a przepustowość skaluje się automatycznie. Aby zacząć, zobacz Użyj Zerobus Ingest.

Metody uwierzytelniania

Każdy klient Zerobus uwierzytelnia się za pomocą krótkotrwałego tokena Azure Databricks OAuth. Gdy używasz SDK, token jest dla ciebie pobierany i odświeżany. Na innych interfejsach, takich jak REST API, sam pobierasz token i dostarczasz go do swoich żądań. Kroki konfiguracji i kod znajdziesz w sekcji Konfiguruj uwierzytelnianie.

OAuth z nazwą główną usługi (domyślnie)

Uwierzytelnij się za pomocą identyfikatora klienta i klucza tajnego jednostki usługi Azure Databricks. To jest metoda domyślna. Nadaje się do obciążeń, które mogą zawierać sekret zarządzany przez Azure Databricks.

Federacja z zewnętrznym dostawcą tożsamości

Uwierzytelniaj się za pomocą tokena od własnego dostawcy tożsamości, takiego jak Microsoft Entra ID, zamiast sekretu Azure Databricks. Token dostawcy tożsamości jest wymieniany na token Azure Databricks w skali Zerobus, korzystając z wymiany tokenów RFC 8693, więc na kliencie nie jest przechowywany długoterminowy sekret Azure Databricks.

Federacja wspiera dwa modele tożsamości:

• Federacja na poziomie konta: Nie istnieje jednostka usługi Azure Databricks. Twoja tożsamość od dostawcy tożsamości jest synchronizowana z kontem Azure Databricks poprzez automatyczne zarządzanie tożsamością, a klient uwierzytelnia się przy użyciu tej tożsamości. Wymaga to zasad federacji kont, które rejestrują Twojego dostawcę jako zaufanego emitenta.
• Federacja tożsamości obciążenia: Użyj service principal Azure Databricks, który ma identyfikator klienta i brak sekretu, z dołączoną polityką federacji.

Microsoft Entra ID jest przykładem na tych stronach, ale ten sam federowany przepływ działa z innymi dostawcami tożsamości kompatybilnymi z OpenID Connect (OIDC).

Porównaj metody uwierzytelniania

Metoda	Azure Databricks service principal	Azure Databricks client secret	Kiedy stosować
Jednostka usługi OAuth	Yes	Yes	Twój klient może przechowywać sekret zarządzany przez Azure Databricks.
Federacja na poziomie konta użytkownika	No	No	Twoja tożsamość jest zarządzana wyłącznie u twojego dostawcy, bez jednostki usługi ani wpisu tajnego Azure Databricks.
Federacja tożsamości obciążeń	Tak, bez użycia wpisu tajnego	No	Chcesz używać tożsamości jednostki usługi Azure Databricks bez przechowywania wpisu tajnego.

Uwaga / Notatka

Automatyczna wymiana tokenów w SDK jest dostępna w Python SDK 1.10.0 i nowszych oraz w Rust SDK 2.11.0 i nowszych. Kroki konfiguracji i kod znajdziesz w sekcji Konfiguruj uwierzytelnianie.

Funkcje tabeli Delta

Zerobus Ingest zapisuje dane w standardowych zarządzanych tabelach Delta w Unity Catalog, dzięki czemu zaimportowane dane mogą korzystać z funkcji tabel Delta. Aby uzyskać wymagania, które musi spełnić tabela docelowa, zobacz Wymagania tabeli.

• Tabele partycjonowane: obsługiwane, z zastrzeżeniem ograniczenia dotyczącego liczby partycji. Azure Databricks zaleca klastrowanie płynne dla kluczy o wysokiej krotności. Zobacz Tabele partycjonowane.
• Płynnie klastrowane tabele: zalecany układ danych, organizujący dane pod kątem wydajności zapytań bez limitu rozproszenia na partycje. Zobacz Używaj płynnego grupowania dla tabel.
• Dane wariantowe: ładowanie danych półstrukturalnych do kolumn VARIANT. Zobacz Obsługiwane typy danych.

Trwała lokalizacja zapasowa

Jeśli po tym, jak Zerobus Ingest trwale zapisze dane, ale zanim zdąży opublikować je w tabeli, zostanie wprowadzona niekompatybilna zmiana schematu tabeli, Zerobus Ingest zapisze te dane jako pliki Parquet w katalogu awaryjnym w lokalizacji magazynu tabeli, zamiast je odrzucać. Aby znaleźć i przetworzyć te dane po naprawieniu schematu, zobacz Odzyskiwanie danych z trwałej lokalizacji awaryjnej.

Monitorowanie użycia

Monitoruj zużycie i wydatki Zerobus Ingest przez tabele systemowe. Zobacz informacje referencyjne o tabeli systemowej Zerobus Ingest, a informacje o wydatkach znajdziesz w tabeli systemu rozliczeniowego w sekcji Koszt.