Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Magazyny danych w chmurze i magazyny danych data lake wzbogacają dane, centralizują informacje i umożliwiają zaawansowaną analizę. Jednak prawdziwa wartość danych polega na przekształcaniu szczegółowych informacji w rzeczywistych decyzjach i doświadczeniach klientów. Aby osiągnąć ten cel, czyste, niezawodne dane muszą przenieść się z magazynowania danych i jezior danych do systemów operacyjnych. Funkcja Reverse ETL przenosi dane z warstwy magazynu danych, takiej jak usługa Delta Lake w usłudze Azure Databricks lub Microsoft Fabric, z powrotem do systemów operacyjnych. Ten krok migracji umożliwia aplikacjom podrzędnym korzystanie z najnowszych, wzbogaconych danych na potrzeby analizy operacyjnej w czasie rzeczywistym. Odwrotna funkcja ETL odgrywa kluczową rolę w odblokowywaniu pełnego potencjału zasobów danych przez pomost między analizą a operacjami, umożliwiając lepsze podejmowanie decyzji.
Usługa Azure Cosmos DB for NoSQL została zaprojektowana pod kątem bardzo małych opóźnień, dystrybucji globalnej i skalowalności NoSQL, dzięki czemu jest idealna dla aplikacji w czasie rzeczywistym. Dzięki technologii Reverse ETL można zsynchronizować dane wzbogacone przez procesy delta do usługi Azure Cosmos DB, co umożliwia analizę operacyjną w czasie rzeczywistym. Ten wzorzec umożliwia wypychanie danych, takich jak wykazy produktów, spersonalizowane informacje o kliencie, aktualizacje cen, dane spisu i rekomendacje dotyczące funkcji. Możesz wypchnąć te dane do operacyjnego magazynu danych, umożliwiając aplikacjom podrzędnym natychmiastowe podejmowanie decyzji opartych na danych.
Architektura rozwiązania
Usprawniona architektura implementowania odwrotnego procesu ETL składa się z platform Apache Spark i Azure Databricks. Ta architektura wyodrębnia oczyszczone i wzbogacone dane ze źródeł, takich jak tabele delty, i zapisuje dane z powrotem do magazynu operacyjnego w usłudze Azure Cosmos DB for NoSQL.
Ten diagram zawiera następujące składniki:
Źródła danych , które obejmują dane, takie jak; dane produktu, dane CRM, informacje o zamówieniu i informacje o reklamie.
Przepływ pracy ETL przenoszący dane z oryginalnych źródeł danych do magazynu danych lub magazynu danych typu data lake w celu przechowywania i wzbogacania danych przy użyciu rozwiązań, takich jak Azure Databricks lub Microsoft Fabric.
Odwrotny przepływ pracy ETL umożliwiający migrację wzbogaconych danych do operacyjnego magazynu danych przy użyciu tabel apache Spark i delta
Operacyjny magazyn danych, taki jak Azure Cosmos DB dla NoSQL, umożliwia używanie wzbogaconych danych w aplikacjach działających w czasie rzeczywistym.
Odwrotny proces ETL umożliwia takie scenariusze jak:
Real-Time Decyzje: Aplikacje uzyskują dostęp do najświeższych danych bez polegania na analitykach lub SQL.
Aktywacja danych: Szczegółowe informacje są wypychane tam, gdzie są potrzebne — nie tylko na pulpitach nawigacyjnych.
Ujednolicone źródło prawdy: Usługa Delta Lake działa jako warstwa kanoniczna, zapewniając spójność między systemami.
Etapy pozyskiwania danych
W przypadku scenariuszy, takich jak magazyn funkcji, aparaty rekomendacji, wykrywanie oszustw lub wykazy produktów w czasie rzeczywistym, ważne jest oddzielenie przepływu danych na dwa etapy. Na tych etapach założono, że masz odwrotny potok ETL z usługi Delta Lake do usługi Azure Cosmos DB for NoSQL.
Etapy na tym diagramie składają się z następujących elementów:
Początkowe ładowanie: Początkowe ładowanie to jednorazowy krok procesu wsadowego w celu załadowania wszystkich danych historycznych z tabel Delta do usługi Azure Cosmos DB for NoSQL. Tworzy podstawy dla potoku ETL rewersyjnego, zapewniając, że operacyjny magazyn danych zawiera pełne dane historyczne. To obciążenie jest podstawowym krokiem przed rozpoczęciem przyrostowej synchronizacji danych.
Synchronizacja przechwytywania zmian danych (CDC): ten krok implementuje przyrostową, ciągłą synchronizację zmian z tabel delty do usługi Azure Cosmos DB for NoSQL. Zmiany w tabeli Delta można przechwycić po włączeniu Delta Change Data Feed (CDF), który umożliwia śledzenie zmian. Można zaimplementować synchronizację przechwytywania zmian na podstawie partii lub przesyłania strumieniowego (CDC).
Dostępne są dwie opcje synchronizacji usługi CDC z usługą Azure Cosmos DB for NoSQL:
Synchronizacja usługi Batch CDC: ta opcja jest uruchamiana zgodnie z harmonogramem (np. codziennie lub co godzinę) i ładuje przyrostową migawkę danych na podstawie zmian przechwyconych od ostatniej wersji lub znacznika czasu.
Wskazówka
Przełącz na nowszą migawkę usługi Azure Cosmos DB, aby uniknąć niespójności danych, gdy przyrostowe duże woluminy są ładowane z tabeli delta do usługi Azure Cosmos DB dla NoSQL. Na przykład podczas zapisywania w nowym kontenerze lub przy użyciu flagi wersji przerzuć wskaźnik na nowszy zrzut ekranu po pełnym załadowaniu nowych danych.
Synchronizacja usługi Stream CDC: ta opcja stale synchronizuje przyrostowe zmiany niemal w czasie rzeczywistym, zapewniając aktualność systemu docelowego z minimalnym opóźnieniem. Ta opcja używa strukturalnego przesyłania strumieniowego Apache Spark do ciągłego przechwytywania i zapisywania zmian. Tabela delty działa jako źródło przesyłania strumieniowego z usługą
readChangeData = true, a łącznik usługi Azure Cosmos DB for NoSQL działa jako ujście przesyłania strumieniowego.Wskazówka
Określ lokalizację punktu kontrolnego, aby upewnić się, że postęp jest śledzony i unika się zduplikowanych zapisów.
Najlepsze rozwiązania
Użyj zadań wsadowych Apache Spark z konektorem Azure Cosmos DB dla NoSQL, aby wykonać początkowy etap ładowania.
Zoptymalizuj przepustowość przyjmowania, przełączając się na standardową zaprovisionowaną przepustowość, jeśli początkowe obciążenie będzie zużywać dużą ilość RU/s względem przydzielonej przepustowości. W szczególności używaj standardowej przepływności zabezpieczonej, jeśli maksymalna liczba jednostek żądań na sekundę (RU/s) jest używana spójnie przez większość czasu trwania początkowego procesu ładowania. W tym scenariuszu nie używaj autoskalowania przepustowości dla początkowego etapu ładowania.
Wskazówka
Jeśli znormalizowane użycie jednostek RU jest stale 100%, metryka wskazuje, że początkowe obciążenie stale zużywa maksymalną liczbę jednostek żądania automatycznego skalowania (RU). Ten próg jest wyraźnym wskaźnikiem, że ten scenariusz dotyczy Twojego obciążenia roboczego i należy użyć standardowej wydajności aprowizowanej.
Wybierz skuteczny klucz partycji, który maksymalizuje równoległość. Aby uzyskać więcej informacji, zobacz partycjonowanie i zalecenia dotyczące klucza partycji.
Zaplanuj łączną liczbę partycji i łączną liczbę jednostek RU/s we wszystkich partycjach w przypadku dużego importu danych. Aby uzyskać więcej informacji i wskazówek, zobacz zalecenia dotyczące partycjonowania i przepływności.
Użyj kontroli przepustowości Apache Spark, aby ograniczyć zużycie jednostek żądania (RU) dla zadań. Kontrola przepływności pomaga zapobiegać przeciążeniu docelowego kontenera operacyjnego.
Użyj autoskalowania przepływności, jeśli to możliwe, w Azure Cosmos DB do NoSQL na potrzeby synchronizacji CDC, ponieważ autoskalowanie dynamicznie dostosowuje RU/s, wzrastając lub obniżając w zależności od użycia. Przepływność skalowania automatycznego jest idealna w przypadku okresowych i kolczasowych obciążeń, takich jak zaplanowane zadania synchronizacji CDC. Aby uzyskać więcej informacji, zobacz zalecenia dotyczące przepływności.
Oszacuj czas trwania wczytywania danych dla pierwszego kroku ładowania danych. Aby uzyskać więcej informacji i przykład, zobacz Szacowanie przepływności.