Najlepsze rozwiązania dotyczące niezawodności

W tym artykule opisano najlepsze rozwiązania dotyczące niezawodności uporządkowane według zasad architektury wymienionych w poniższych sekcjach.

1. Projektowanie pod kątem awarii

Używanie formatu danych obsługującego transakcje ACID

Transakcje ACID są krytyczną funkcją do utrzymania integralności i spójności danych. Wybór formatu danych, który obsługuje transakcje ACID, ułatwia tworzenie potoków, które są prostsze i znacznie bardziej niezawodne.

Delta Lake to platforma magazynu typu open source, która zapewnia transakcje ACID, a także wymuszanie schematów, skalowalną obsługę metadanych oraz unifies przesyłanie strumieniowe i przetwarzanie danych wsadowych. Usługa Delta Lake jest w pełni zgodna z interfejsami API platformy Apache Spark i została zaprojektowana pod kątem ścisłej integracji ze strukturą przesyłania strumieniowego, umożliwiając łatwe używanie pojedynczej kopii danych zarówno dla operacji wsadowych, jak i przesyłania strumieniowego oraz zapewnianie przyrostowego przetwarzania na dużą skalę.

Używanie odpornego rozproszonego aparatu danych dla wszystkich obciążeń

Platforma Apache Spark, jako aparat obliczeniowy usługi Azure Databricks Lakehouse, jest oparta na odpornym rozproszonym przetwarzaniu danych. Jeśli wewnętrzne zadanie platformy Spark nie zwraca wyniku zgodnie z oczekiwaniami, platforma Apache Spark automatycznie ponownie wykonuje brakujące zadania i kontynuuje wykonywanie całego zadania. Jest to przydatne w przypadku błędów braku kodu, takich jak krótki problem z siecią lub odwołana maszyna wirtualna typu spot. Praca zarówno z interfejsem API SQL, jak i interfejsem API ramki danych Platformy Spark, ta odporność jest wbudowana w aparat.

W lakehouse usługi Databricks Photon, natywny aparat wektoryzowany w całości napisany w języku C++, jest obliczeniami o wysokiej wydajności zgodnym z interfejsami API platformy Apache Spark.

Automatyczne ratowanie nieprawidłowych lub niezgodnych danych

Nieprawidłowe lub niekonformujące dane mogą powodować awarie obciążeń korzystających z ustalonego formatu danych. Aby zwiększyć kompleksową odporność całego procesu, najlepszym rozwiązaniem jest odfiltrowanie nieprawidłowych i niezgodnych danych podczas pozyskiwania. Obsługa uratowanych danych gwarantuje, że nigdy nie utracisz lub nie przegapisz danych podczas pozyskiwania lub ETL. Uratowana kolumna danych zawiera wszystkie dane, które nie zostały przeanalizowane, albo dlatego, że brakuje go w danym schemacie, ponieważ wystąpiła niezgodność typów lub ponieważ treść kolumny w rekordzie lub pliku nie była zgodna z tym w schemacie.

• Narzędzie do automatycznego ładowania usługi Databricks: narzędzie do automatycznego ładowania to idealne narzędzie do przesyłania strumieniowego pozyskiwania plików. Obsługuje ono uratowane dane dla plików JSON i CSV. Na przykład w przypadku formatu JSON uratowana kolumna danych zawiera wszystkie dane, które nie zostały przeanalizowane, prawdopodobnie dlatego, że brakuje go w danym schemacie, ponieważ wystąpiła niezgodność typów lub ponieważ wielkość liter kolumny nie jest zgodna. Uratowana kolumna danych jest częścią schematu zwracanego przez moduł automatycznego ładowania jako _rescued_data domyślny, gdy schemat jest wnioskowany.
• Delta Live Tables: Inną opcją tworzenia przepływów pracy w celu uzyskania odporności jest użycie tabel delta live tables z ograniczeniami jakości. Zobacz Zarządzanie jakością danych za pomocą tabel delta live. Gotowe do użycia tabele Delta Live Tables obsługują trzy tryby: Zachowywanie, upuszczanie i niepowodzenie w nieprawidłowych rekordach. Aby określić nieprawidłowe rekordy w kwarantannie, można zdefiniować reguły oczekiwania w określony sposób, tak aby nieprawidłowe rekordy zostały zapisane ("poddane kwarantannie") w innej tabeli. Zobacz Kwarantanna nieprawidłowych danych.

Konfigurowanie zadań na potrzeby automatycznych ponownych prób i kończenia

Systemy rozproszone są złożone i błąd w jednym miejscu może potencjalnie spowodować kaskadę błędów w całym systemie.

• Zadania usługi Azure Databricks obsługują zasady automatycznego ponawiania, które określają, kiedy i ile razy ponowienie prób przebiegów zakończyło się niepowodzeniem.
• Można skonfigurować opcjonalne progi czasu trwania zadania, w tym oczekiwany czas ukończenia zadania i maksymalny czas ukończenia zadania.
• Delta Live Tables automatyzuje również odzyskiwanie po awarii przy użyciu eskalacji ponownych prób w celu zrównoważenia szybkości i niezawodności. Zobacz Tryby programowania i produkcji.

Z drugiej strony zawieszające się zadanie może uniemożliwić ukończenie całego zadania, co powoduje wysokie koszty. Zadania usługi Databricks obsługują konfigurację limitu czasu w celu zabicia zadań, które zajmują więcej niż oczekiwano.

Korzystanie ze skalowalnej i klasy produkcyjnej infrastruktury obsługującej model

W przypadku wnioskowania wsadowego i przesyłania strumieniowego użyj zadań usługi Azure Databricks i platformy MLflow, aby wdrożyć modele jako funkcje zdefiniowane przez użytkownika platformy Apache Spark, aby korzystać z planowania zadań, ponawiania prób, skalowania automatycznego itd. Zobacz Use MLflow for model inference (Używanie platformy MLflow do wnioskowania modelu).

Obsługa modelu zapewnia skalowalną i klasy produkcyjnej infrastrukturę do obsługi modeli w czasie rzeczywistym. Przetwarza ona modele uczenia maszynowego przy użyciu biblioteki MLflow i udostępnia je jako punkty końcowe interfejsu API REST. Ta funkcja korzysta z bezserwerowych zasobów obliczeniowych, co oznacza, że punkty końcowe i skojarzone zasoby obliczeniowe są zarządzane i uruchamiane na koncie usługi Azure Databricks w chmurze.

Korzystanie z usług zarządzanych, jeśli jest to możliwe

Skorzystaj z usług zarządzanych (bezserwerowych zasobów obliczeniowych) z platformy analizy danych usługi Databricks, na przykład:

• bezserwerowe magazyny SQL
• obsługa modelu
• zadania bezserwerowe
• bezserwerowe obliczenia dla notesów
• Tabele na żywo delty

w miarę możliwości. Te usługi są obsługiwane przez usługę Databricks w niezawodny i skalowalny sposób bez dodatkowych kosztów dla klienta, dzięki czemu obciążenia będą bardziej niezawodne.

2. Zarządzanie jakością danych

Korzystanie z architektury magazynu warstwowego

Curate data by creating a layered architecture and zapewnianie, że jakość danych wzrasta w miarę przechodzenia danych przez warstwy. Typowym podejściem do warstw jest:

• Warstwa nieprzetworzona (brąz): dane źródłowe są pozyskiwane do jeziora w pierwszej warstwie i powinny być tam utrwalane. Gdy wszystkie dane podrzędne są tworzone na podstawie warstwy pierwotnej, można ponownie skompilować kolejne warstwy z tej warstwy zgodnie z potrzebami.
• Wyselekcjonowana warstwa (srebro): celem drugiej warstwy jest utrzymywanie oczyszczonych, uściślionych, przefiltrowanych i zagregowanych danych. Celem tej warstwy jest zapewnienie solidnej, niezawodnej podstawy do analizy i raportowania we wszystkich rolach i funkcjach.
• Warstwa końcowa (złoto): trzecia warstwa jest zbudowana wokół potrzeb biznesowych lub projektowych. Zapewnia inny widok jako produkty danych do innych jednostek biznesowych lub projektów, przygotowywanie danych dotyczących potrzeb związanych z zabezpieczeniami (takich jak anonimowe dane) lub optymalizowanie pod kątem wydajności (np. przy użyciu wstępnie zagregowanych widoków). Produkty danych w tej warstwie są uważane za prawdę dla firmy.

Końcowa warstwa powinna zawierać tylko dane wysokiej jakości i być w pełni zaufana z perspektywy biznesowej.

Zwiększanie integralności danych dzięki zmniejszeniu nadmiarowości danych

Kopiowanie lub duplikowanie danych powoduje nadmiarowość danych i prowadzi do utraty integralności, utraty pochodzenia danych i często różnych uprawnień dostępu. Zmniejsza to jakość danych w lakehouse.

Tymczasowa lub jednorazowa kopia danych nie jest sama w sobie szkodliwa — czasami konieczne jest zwiększenie elastyczności, eksperymentowania i innowacji. Jednak gdy kopie te stają się operacyjne i są regularnie używane do podejmowania decyzji biznesowych, stają się silosami danych. Gdy te silosy danych nie są zsynchronizowane, ma to znaczący negatywny wpływ na integralność i jakość danych, co powoduje pytania, takie jak "Który zestaw danych jest wzorcem?" lub "Czy zestaw danych jest aktualny?

Aktywne zarządzanie schematami

Niekontrolowane zmiany schematu mogą prowadzić do nieprawidłowych danych i zadań zakończonych niepowodzeniem korzystających z tych zestawów danych. Usługa Azure Databricks ma kilka metod sprawdzania poprawności i wymuszania schematu:

• Usługa Delta Lake obsługuje walidację schematu i wymuszanie schematu, automatycznie obsługując odmiany schematu, aby zapobiec wstawieniu nieprawidłowych rekordów podczas pozyskiwania. Zobacz Wymuszanie schematu.
• Moduł automatycznego ładowania wykrywa dodanie nowych kolumn podczas przetwarzania danych. Domyślnie dodanie nowej kolumny powoduje zatrzymanie strumieni przy użyciu elementu UnknownFieldException. Automatyczne ładowanie obsługuje kilka trybów ewolucji schematu.

Używanie ograniczeń i oczekiwań dotyczących danych

Tabele różnicowe obsługują standardowe klauzule zarządzania ograniczeniem SQL, które zapewniają automatyczne sprawdzanie jakości i integralności danych dodanych do tabeli. Gdy ograniczenie zostanie naruszone, usługa Delta Lake zgłasza błąd sygnalizujący InvariantViolationException , że nie można dodać nowych danych. Zobacz Ograniczenia dotyczące usługi Azure Databricks.

Aby jeszcze bardziej ulepszyć tę obsługę, funkcja Delta Live Tables obsługuje oczekiwania: Oczekiwania definiują ograniczenia jakości danych dotyczące zawartości zestawu danych. Oczekiwanie składa się z opisu, niezmienności i akcji, która ma zostać podjęta, jeśli rekord narusza niezmienność. Oczekiwania dotyczące zapytań używają dekoratorów języka Python lub klauzul ograniczeń SQL. Zobacz Zarządzanie jakością danych za pomocą tabel delta live.

Podejście skoncentrowane na danych do uczenia maszynowego

Wiodącą zasadą, która pozostaje podstawą wizji sztucznej inteligencji dla platformy analizy danych usługi Databricks, jest podejście skoncentrowane na danych do uczenia maszynowego. Ponieważ generowanie sztucznej inteligencji staje się bardziej powszechne, ta perspektywa pozostaje równie ważna.

Podstawowe składniki dowolnego projektu uczenia maszynowego można po prostu traktować jako potoki danych: inżynieria funkcji, szkolenie, wdrażanie modelu, wnioskowanie i potoki monitorowania to wszystkie potoki danych. W związku z tym operacjonalizacja rozwiązania ML wymaga scalenia danych z tabel przewidywania, monitorowania i funkcji z innymi odpowiednimi danymi. Zasadniczo najprostszym sposobem osiągnięcia tego celu jest opracowanie rozwiązań opartych na sztucznej inteligencji na tej samej platformie używanej do zarządzania danymi produkcyjnymi. Zobacz Metodyki MLOps skoncentrowane na danych i metodyce LLMOps

3. Projektowanie pod kątem skalowania automatycznego

Włączanie skalowania automatycznego dla obciążeń ETL

Skalowanie automatyczne umożliwia klastrom automatyczne zmienianie rozmiaru na podstawie obciążeń. Skalowanie automatyczne może przynieść wiele przypadków użycia i scenariuszy zarówno z perspektywy kosztów, jak i wydajności. Dokumentacja zawiera zagadnienia dotyczące określania, czy używać skalowania automatycznego i jak uzyskać największą korzyść.

W przypadku obciążeń przesyłania strumieniowego usługa Databricks zaleca używanie tabel delta Live Tables z skalowaniem automatycznym. Rozszerzone skalowanie automatyczne usługi Databricks optymalizuje wykorzystanie klastra przez automatyczne przydzielanie zasobów klastra na podstawie woluminu obciążenia, przy minimalnym wpływie na opóźnienie przetwarzania danych potoków.

Włączanie skalowania automatycznego dla usługi SQL Warehouse

Parametr skalowania usługi SQL Warehouse określa minimalną i maksymalną liczbę klastrów, w których zapytania wysyłane do magazynu są dystrybuowane. Wartość domyślna to jeden klaster bez skalowania automatycznego.

Aby obsługiwać więcej współbieżnych użytkowników dla danego magazynu, zwiększ liczbę klastrów. Aby dowiedzieć się, w jaki sposób usługa Azure Databricks dodaje klastry do magazynu i usuwa je z magazynu, zobacz Artykuł Dotyczący określania rozmiaru, skalowania i zachowania kolejkowania w usłudze SQL Warehouse.

4. Testowanie procedur odzyskiwania

Odzyskiwanie sprawności po niepowodzeniu zapytania strukturalnego przesyłania strumieniowego

Przesyłanie strumieniowe ze strukturą zapewnia odporność na uszkodzenia i spójność danych dla zapytań przesyłanych strumieniowo. Przy użyciu zadań usługi Databricks można łatwo skonfigurować zapytania przesyłania strumieniowego ze strukturą w celu automatycznego ponownego uruchomienia po awarii. Włączenie punktów kontrolnych dla zapytania przesyłania strumieniowego umożliwia ponowne uruchomienie zapytania po niepowodzeniu. Ponownie uruchomione zapytanie będzie kontynuowane od miejsca, w którym zostało przerwane zapytanie, które zakończyło się niepowodzeniem.

Odzyskiwanie zadań ETL przy użyciu funkcji podróży w czasie danych

Pomimo dokładnego testowania zadanie może zakończyć się niepowodzeniem w środowisku produkcyjnym lub spowodować nieoczekiwane, nawet nieprawidłowe dane. Czasami można to naprawić za pomocą dodatkowego zadania po zrozumieniu źródła problemu i rozwiązaniu potoku, który spowodował problem w pierwszej kolejności. Jednak często nie jest to proste i zadanie, o których mowa, powinno zostać wycofane. Korzystając z czasu różnicowego , użytkownicy mogą łatwo wycofać zmiany do starszej wersji lub znacznika czasu, naprawić potok i ponownie uruchomić stały potok.

Wygodnym sposobem na to jest RESTORE polecenie .

Korzystanie z platformy automatyzacji zadań z wbudowanym odzyskiwaniem

Zadania usługi Databricks są przeznaczone do odzyskiwania. Gdy zadanie w zadaniu wielozadaniowym kończy się niepowodzeniem (i, w związku z tym ze wszystkimi zadaniami zależnymi), zadania usługi Azure Databricks zapewniają widok macierzy przebiegów, które umożliwiają zbadanie problemu, który spowodował awarię, zobacz Wyświetlanie przebiegów zadania. Niezależnie od tego, czy był to krótki problem z siecią, czy prawdziwy problem z danymi, możesz go rozwiązać i uruchomić uruchomienie naprawy w zadaniach usługi Azure Databricks. Będzie działać tylko zadania zakończone niepowodzeniem i zależne oraz zachować pomyślne wyniki z wcześniejszego uruchomienia, zaoszczędzić czas i pieniądze, zobacz Rozwiązywanie problemów i naprawianie błędów zadań

Konfigurowanie wzorca odzyskiwania po awarii

W przypadku natywnej dla chmury platformy analizy danych, takiej jak Azure Databricks, jasny wzorzec odzyskiwania po awarii ma kluczowe znaczenie. Ważne jest, aby zespoły danych mogły korzystać z platformy Azure Databricks nawet w rzadkich przypadkach regionalnej awarii dostawcy usług w chmurze, niezależnie od tego, czy jest to spowodowane katastrofą regionalną, taką jak huragan, trzęsienie ziemi, czy inne źródło.

Usługa Azure Databricks jest często główną częścią ogólnego ekosystemu danych, który obejmuje wiele usług, w tym nadrzędne usługi pozyskiwania danych (batch/streaming), magazyn natywny dla chmury, taki jak Azure Data Lake Storage Gen2, narzędzia podrzędne i usługi, takie jak aplikacje analizy biznesowej i narzędzia do aranżacji. Niektóre przypadki użycia mogą być szczególnie wrażliwe na awarię w całej usłudze regionalnej.

Odzyskiwanie po awarii obejmuje zestaw zasad, narzędzi i procedur, które umożliwiają odzyskiwanie lub kontynuację istotnej infrastruktury technologicznej i systemów po klęskach żywiołowych lub wywołanych przez człowieka. Duża usługa w chmurze, taka jak platforma Azure, obsługuje wielu klientów i ma wbudowane zabezpieczenia przed pojedynczym niepowodzeniem. Na przykład region to grupa budynków połączonych z różnymi źródłami zasilania, aby zapewnić, że jedna awaria zasilania nie obniży regionu. Mogą jednak wystąpić błędy w regionie chmury, a ważność awarii i jej wpływ na twoją firmę może się różnić.

5. Automatyzowanie wdrożeń i obciążeń

Zobacz Doskonałość operacyjna — automatyzowanie wdrożeń i obciążeń.

6. Monitorowanie systemów i obciążeń

Zobacz Doskonałość operacyjna — konfigurowanie monitorowania, zgłaszania alertów i rejestrowania.