Udostępnij przez

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 łączy 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żyj odpornego rozproszonego silnika 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 awarii niezwiązanych z kodem, takich jak krótki problem z siecią lub anulowana maszyna wirtualna Spot. Pracując zarówno z interfejsem SQL, jak i ramką danych Platformy Spark, ta odporność jest wbudowana w silnik.

W lakehouse usługi Databricks, Photon, natywny aparat wektoryzowany w całości napisany w języku C++, jest silnikiem obliczeniowym o wysokiej wydajności zgodnym z interfejsami API 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ć odporność całego procesu od końca do końca, najlepszym rozwiązaniem jest odfiltrowanie nieprawidłowych i niezgodnych danych w trakcie pobierania. Wsparcie dla uratowanych danych gwarantuje, że nigdy nie utracisz ani nie przegapisz danych podczas importu lub przetwarzania 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.

  • Automatyczne ładowanie usługi Databricks:Auto Loader to idealne narzędzie do strumieniowego wczytywania plików. Obsługuje ono odzyskane dane dla JSON i CSV. Na przykład w przypadku formatu JSON kolumna z uratowanymi danymi zawiera wszystkie dane, które nie zostały poprawnie przeanalizowane, prawdopodobnie z powodu ich nieobecności w danym schemacie, niezgodności typów lub niespójności wielkości liter w nazwach kolumn. Uratowana kolumna danych jest częścią schematu zwracanego przez moduł automatycznego ładowania jako _rescued_data domyślnie, gdy schemat jest wywnioskowany.

  • Potoki: Inną opcją tworzenia przepływów pracy w celu zwiększenia odporności jest użycie Deklaratywnych Potoków Lakeflow Spark z ograniczeniami jakości. Zobacz Zarządzanie jakością danych przy użyciu oczekiwań potoku. Potoki deklaratywne platformy Lakeflow domyślnie 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. Przejrzyj nieprawidłowe rekordy w kwarantannie .

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.

Z drugiej strony zawieszające się zadanie może uniemożliwić ukończenie całego zadania, co powoduje wysokie koszty. Procesy Lakeflow obsługują konfigurację limitu czasu, aby zatrzymać procesy, które trwają dłużej niż przewidywano.

Użyj skalowalnej i przeznaczonej do produkcji infrastruktury do obsługi modelu

W przypadku wnioskowania wsadowego i przesyłania strumieniowego użyj Lakeflow Jobs i MLflow do wdrażania modeli jako funkcji UDF (funkcji zdefiniowanych przez użytkownika) w Apache Spark, aby korzystać z planowania zadań, ponawiania prób, automatycznego skalowania itd. Zobacz Wdrażanie modeli na potrzeby wnioskowania i przewidywania wsadowego.

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:

Te usługi są obsługiwane przez usługę Databricks w niezawodny i skalowalny sposób, dzięki czemu obciążenia są bardziej niezawodne.

2. Zarządzanie jakością danych

Zastosuj architekturę pamięci warstwowej

Kuratorowanie danych poprzez tworzenie architektury warstwowej i zapewniając, że jakość danych wzrasta w miarę przechodzenia przez kolejne warstwy. Typowym podejściem do warstw jest:

  • Warstwa surowa (brąz): Dane źródłowe są importowane do lakehouse w warstwie pierwszej 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 przechowywanie oczyszczonych, uściślonych, 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 oparta na potrzebach biznesowych lub projektowych. Zapewnia odmienny widok danych jako produktów dla innych jednostek biznesowych lub projektów, przygotowując dane pod kątem potrzeb związanych z bezpieczeństwem (takich jak zanonimizowane dane) lub optymalizując pod kątem wydajności (np. za pomocą wstępnie zagregowanych widoków). Produkty danych w tej warstwie są uważane za źródło prawdy dla biznesu.

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'ie.

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:

  • Delta Lake obsługuje walidację schematu i wymuszanie schematu, automatycznie obsługując zmiany schematu, aby zapobiec wstawieniu nieprawidłowych rekordów podczas procesu ładowania danych. Zobacz Wymuszanie schematu.
  • Moduł automatycznego ładowania wykrywa dodanie nowych kolumn podczas przetwarzania danych. Domyślnie dodanie nowej kolumny powoduje zatrzymanie strumieni z kodem UnknownFieldException. Moduł automatycznego ładowania obsługuje kilka trybów ewolucji schematu .

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

Tabele Delta obsługują standardowe klauzule zarządzania ograniczeniami 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ę, Lakeflow Spark Declarative Pipelines obsługują 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 przy użyciu oczekiwań potoku.

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 skoncentrowane na danych MLOps i 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ść.

Databricks zaleca używanie Lakeflow Spark Deklaratywnych Potoków ze skalowaniem automatycznym w przypadku obciążeń przesyłania strumieniowego. 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 po awarii zapytania w ramach Structured Streaming

Przesyłanie strumieniowe ze strukturą zapewnia odporność na uszkodzenia i spójność danych na potrzeby zapytań przesyłanych strumieniowo. Za pomocą Lakeflow Jobs można łatwo skonfigurować zapytania Structured Streaming do automatycznego ponownego uruchamiania w przypadku wystąpienia awarii. Włączając punkt kontrolny dla zapytania strumieniowego, można ponownie uruchomić zapytanie po niepowodzeniu. Ponownie uruchomione zapytanie jest kontynuowane od miejsca, w którym przerwano zapytanie, które zakończyło się niepowodzeniem. Zobacz Ustrukturyzowane punkty kontrolne przesyłania strumieniowego i zagadnienia dotyczące produkcji dla ustrukturyzowanego przesyłania strumieniowego.

Odzyskiwanie zadań ETL za pomocą funkcjonalności 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 naprawieniu potoku, który spowodował problem na początku. Jednak często nie jest to proste i zadanie, o którym mowa, powinno zostać cofnięte. Korzystając z Delta Time, użytkownicy mogą łatwo wycofać zmiany do starszej wersji lub znacznika czasu, naprawić potok i ponownie uruchomić naprawiony potok.

Wygodnym sposobem na to jest RESTORE polecenie .

Korzystanie z platformy automatyzacji zadań z wbudowanym odzyskiwaniem

Zadania Lakeflow są przeznaczone do odzyskiwania. Gdy zadanie w pracy wielozadaniowej kończy się niepowodzeniem (a więc i wszystkie zadania zależne), praca ta zapewnia widok macierzy przebiegów, co pozwala zbadać problem, który spowodował awarię; zobacz Wyświetlanie przebiegów pojedynczego zadania. Niezależnie od tego, czy był to krótki problem z siecią, czy prawdziwy problem z danymi, możesz go rozwiązać i rozpocząć naprawę w zadaniach Lakeflow. Spowoduje to uruchomienie tylko zadań zakończonych niepowodzeniem i zależnych oraz zachowanie pomyślnych wyników z wcześniejszego uruchomienia, oszczędność czasu i pieniędzy, 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, 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 w przypadku regionalnej awarii usługi.

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 zespół budynków zasilanych z różnych źródeł energii, aby zapewnić, że pojedynczy przestój zasilania nie unieruchomi 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.

  • Last updated on