Kontrakty danych
Obowiązki są dystrybuowane między domenami w architekturze federacyjnej, co może utrudnić nadzorowanie zależności i uzyskiwanie szczegółowych informacji o użyciu danych. Kontrakty danych mogą pomóc w uzyskaniu szczegółowych informacji o użyciu danych, ponieważ udostępniają informacje o tym, kto jest właścicielem każdego produktu danych. Kontrakty danych ułatwiają ustawianie standardów i pewnie zarządzanie potokami danych. Są one niezbędne do niezawodnego zarządzania danymi, zapewniając informacje na temat:
Które produkty danych są używane.
Którzy użytkownicy korzystają z produktów danych.
Jakie cele prowadzą użytkowników do korzystania z określonych produktów danych.
Dystrybucja i użycie produktów danych mają dwa wymiary: problemy techniczne i problemy biznesowe. Kwestie techniczne obejmują obsługę potoków danych i wzajemne oczekiwania dotyczące stabilności danych. Problemy biznesowe obejmują umowy celowe udostępniania danych, które definiują cele użycia, prywatności i celu, w tym wszelkie ograniczenia.
Te dwa wymiary obejmują różne role. Ogólnie rzecz biorąc, należy polegać na właścicieli aplikacji lub inżynierów danych w przypadku problemów technicznych i polegać na właścicielach produktów lub przedstawicielach biznesowych w przypadku problemów biznesowych.
Kontrakty danych
Kontrakty danych są podobne do kontraktów usług lub kontraktów dostarczania danych.
W większej lub rozproszonej architekturze może być trudno nadzorować zmiany. Nadzór można uprościć, implementując przechowywanie wersji i zarządzanie zgodnością za każdym razem, gdy masz produkt danych, który jest popularny i powszechnie używany.
Jeśli aplikacje są połączone, oznacza to, że istnieje wysoki stopień współzależności między aplikacjami w połączeniu. Aplikacje, które uzyskują dostęp do danych lub korzystają z nich z innych aplikacji, zawsze cierpią w przypadku połączenia. Każda zmiana struktury danych, na przykład, może mieć bezpośredni wpływ na inne aplikacje, które uzyskują dostęp do tych danych lub korzystają z nich. W sytuacjach, w których istnieje wiele aplikacji połączonych ze sobą, często występuje kaskadowy efekt, w którym mała zmiana w jednej aplikacji wpływa na wiele innych aplikacji. Ze względu na zwiększone prawdopodobieństwo niezamierzonych efektów po nawet drobnych zmianach wielu architektów i inżynierów oprogramowania unika tworzenia architektur połączonych.
Umowa dotycząca danych gwarantuje zgodność interfejsu i obejmuje warunki świadczenia usług oraz umowę dotyczącą poziomu usług (SLA). Warunki użytkowania usługi określają, jak można używać danych, takich jak ograniczenie ich używania tylko do programowania, testowania lub produkcji. Umowy SLA opisują wymaganą jakość dostarczania danych i interfejsu. Szczegóły dotyczące jakości, które można określić w umowie SLA, obejmują:
- Czas pracy
- Stawki błędów
- Dostępność
- Przestarzałe
- Plan działania
- Numery wersji
Metadane przechwytujące te szczegóły można umieścić pod kontrolą źródła, co umożliwia automatyczne wyzwalanie walidacji i wdrożeń. Aby uzyskać więcej informacji na temat kontroli źródła, zobacz Kontrola źródła w Azure Data Factory.
Kontrakty danych zapewniają wgląd w sprzężenia i zależności między domenami i aplikacjami. Kontrakt umożliwia również testowanie kontraktu, co gwarantuje, że wszystkie zmiany aplikacji i interfejsu są weryfikowane pod kątem wymagań dotyczących danych użytkowników. Możesz określić, kiedy przepływy danych stają się podatne na zmiany nadrzędnego źródła danych, wykrywając dryf schematu. Aby uzyskać więcej informacji, zobacz Dryf schematu w przepływie danych mapowania.
Kontrakty danych są często częścią platform pozyskiwania metadanych. Kontrakty danych można przechowywać w rekordach metadanych w centralnie zarządzanym magazynie metadanych. Z tej centralnej lokalizacji kontrakty danych odgrywają ważną rolę w danych w wielu obszarach pozyskiwania danych, w tym:
Wykonywanie potoku
Tworzenie produktu danych
Walidacja typu danych
Schematy
Standardy współdziałania
Wersje protokołu
Domyślne reguły dotyczące brakujących danych
Kontrakty danych obejmują duże ilości metadanych technicznych. Aby udokumentować potoki danych i produkty danych, musisz mieć jasny opis źródeł danych, wszystkie przekształcenia danych zostały poddane i jak ostatecznie dostarczać dane.
W architekturze rozproszonej platforma potoku danych jest dystrybuowana w różnych domenach, a domeny są zgodne z typowym sposobem pracy. Ponieważ domeny przetwarzają same dane, kontrola i odpowiedzialność pozostają z nimi, podczas gdy struktura i metadane pozostają w ramach centralnego ładu.
Podczas implementowania metody federacyjnej zacznij od małej. Zacznij od podstaw, takich jak magazyn metadanych na potrzeby weryfikacji schematu, identyfikatorów przedsiębiorstwa i odwołań do innych zestawów danych w udostępnionym repozytorium metadanych. Dodaj obsługę pochodzenia danych, aby ułatwić wizualizowanie przenoszenia danych. Uruchamianie procesów i używanie bibliotek, takich jak Great Expectations , w celu zaimplementowania mechanizmów kontroli na potrzeby walidacji jakości danych technicznych.
Wszystkie kontrolki powinny być częścią procedur ciągłej integracji. Przechwyć wszystkie informacje o środowisku uruchomieniowym, w tym metryki i rejestrowanie, i wprowadź te informacje jako część podstaw metadanych w celu uzyskania szczegółowych informacji o stabilności potoku danych. Ta konfiguracja gwarantuje, że masz pętlę opinii między domenami a centralnym kokpitem zarządzania.
Podczas stabilizacji całego przenoszenia danych przechwytuje atrybuty danych (takie jak tabele i kolumny) używane przez użytkowników danych i używają tych informacji, aby kontynuować skalowanie. Te informacje można uwzględnić w centralnie zarządzanym magazynie metadanych. Informacje o użyciu danych umożliwiają wykrywanie zmian powodujących niezgodność i identyfikowanie ich wpływu na producentów danych i konsumentów. Jeśli zestaw danych produktu danych nie ma konsumentów, możesz zezwolić na to, aby mogły one doświadczyć zmian zakłócających działanie. Użyj kontroli źródła (takiej jak Git), aby umożliwić proces uzgadniania między dostawcami i użytkownikami danych.
Umowy dotyczące udostępniania danych
Umowy dotyczące udostępniania danych to rozszerzenie kontraktów danych. W umowach opisano użycie danych, prywatność i cel, w tym wszelkie ograniczenia. Umowy dotyczące udostępniania danych są niezależne od interfejsu i oferują wgląd w dane używane do określonego celu. Działają one również jako dane wejściowe dla mechanizmów kontroli zabezpieczeń danych. Możesz użyć umowy do udostępniania danych, aby określić, które filtry lub zabezpieczenia muszą być stosowane do danych.
Umowy dotyczące udostępniania danych pomagają również zapobiegać nieporozumianiu się z użyciem danych. Właściciele domeny powinni omówić udostępnianie danych i problemy z użyciem danych przed udostępnieniem jakichkolwiek danych. Posiadanie wspólnego zrozumienia ma kluczowe znaczenie dla możliwości regulowania danych i ich użycia oraz zapewnienia, że możesz dostarczać wartość organizacji. Gdy wszyscy właściciele domeny osiągną wspólne zrozumienie, upewnij się, że dokumentują je w umowie dotyczącej udostępniania danych. W tej umowie można również adresować obszary, takie jak:
Jakość danych funkcjonalnych
Historyzacja
Zarządzanie cyklem życia danych
Dalsza dystrybucja danych
Zastosuj klasyfikacje i warunki, takie jak etykiety poufności lub warunki filtrowania, aby zabezpieczyć dane.
Na diagramie poprzedniej sekcji przedstawiono niektóre elementy oznaczone przyczepą produktu danych. Przyczepka produktu danych jest składnikiem lub warstwą do wstrzykiwania wykonywania zasad, takich jak mechanizmy kontroli dostępu do danych lub metody wyjściowe użycia danych. Jest to abstrakcja zabezpieczeń, która używa kontraktów danych do obsługi wymuszania zabezpieczeń na danych domeny. Możesz utworzyć przyczepkę produktu danych z repozytorium kontraktów danych jako listę kontroli dostępu (ACL) lub widok bezserwerowy albo utworzyć go przy użyciu zduplikowanego zestawu danych, który wybierasz i filtrujesz dla określonego konsumenta. Tak czy inaczej, celem jest uzyskanie widoków zabezpieczeń z kontraktów danych w pełni zautomatyzowany.
Połącz atrybuty kontraktu danych i dokumentację. Upewnij się, że udostępniasz kontekst semantyczny i relację z słownikiem, aby użytkownicy mogli zrozumieć, jak wymagania biznesowe przekładają się na rzeczywistą implementację. Jeśli relacja z terminami biznesowymi jest ważna dla organizacji, rozważ wdrożenie zasad, takich jak zezwolenie na ustanowienie kontraktów danych tylko po połączeniu wszystkich atrybutów produktu danych z jednostkami terminów biznesowych. Ten typ zasad można również zastosować do zmian kontekstowych, takich jak korekty relacji lub definicji.
Używanie kontraktów danych
Rozpocznij wolno, gdy zaczniesz używać kontraktów danych. Nie wprowadzaj zbyt wielu zmian jednocześnie; kontrakty danych wymagają zmiany kulturowej, a użytkownicy potrzebują czasu, aby się z nimi zapoznać i zrozumieć znaczenie własności danych. Należy również znaleźć słodkie miejsce między zbyt niewielką i zbyt liczbą atrybutów metadanych w kontraktach danych.
W poniższych krokach opisano proces implementowania kontraktów danych dla organizacji.
Upewnij się, że potoki danych technicznych są stabilne. Przypadki użycia nie mogą dotrzeć do środowiska produkcyjnego, jeśli potoki przechodzą przez nieoczekiwane zakłócenia.
Umieść proste i pragmatyczne procesy w miarę rozpoczynania korzystania z umów dotyczących udostępniania. Możesz zacząć od zaprojektowania prostego formularza lub szablonu w Microsoft Forms. Napisz w jasnym, zwięzłym języku, który czytelnicy mogą łatwo zrozumieć. Celem tej pierwszej fazy jest zmiana kulturowa i zbieranie wymagań. Upewnij się, że nie komplikujesz elementów; zaakceptuj procesy ręczne, ogranicz wymagania dotyczące początkowych metadanych i iteruj, dopóki te wymagania nie będą stabilne.
Po uzyskaniu pierwszych procesów należy rozpocząć zastępowanie formularzy ręcznych aplikacją internetową, bazą danych i/lub kolejką komunikatów. Centralny zespół ds. nadzoru nad danymi powinien być nadal odpowiedzialny za nadzór w tej fazie. Stopień szczegółowości dostępu do danych jest zwykle oparty na kursie, koncentrując się na folderach lub plikach. Jeśli to możliwe, użyj interfejsów API REST, aby automatycznie aprowizować zasady dostępu do danych lub listy ACL.
Umieść właścicieli danych lub stewardów danych odpowiedzialnych za silny przepływ pracy na potrzeby zarządzania zatwierdzeniami. Centralna rola nadzoru nad danymi powinna teraz nadzorować zatwierdzenia tylko z roli zaplecza i regularnie przeglądać wszystkie kontrakty danych. Na tym etapie powinien istnieć wykaz danych, taki jak usługa Azure Purview , który pokazuje wszystkie gotowe do użycia produkty danych. Zwiększ możliwości wymuszania danych i zabezpieczeń, umożliwiając precyzyjne wybieranie i filtrowanie, i rozważ użycie technik, takich jak dynamiczne maskowanie danych, aby zapobiec duplikowaniu danych.
W ostatnim etapie procesu wdrażania kontraktu danych wszystko powinno być samoobsługowe i w pełni zautomatyzowane. Zautomatyzowane uczenie maszynowe powinno przewidywać zatwierdzenia danych. Zabezpieczenia
Po zakończeniu podróży wszystko będzie samoobsługowe i w pełni zautomatyzowane. Obejmuje to automatyczne wymuszanie zabezpieczeń i uczenie maszynowe do przewidywania zatwierdzeń danych. Bezpieczne widoki są na przykład automatycznie wdrażane po zatwierdzeniu.
Kontrakty danych są stosunkowo nowym, ale ważnym dodatkiem do architektury siatki danych, zapewniając przejrzystość użycia danych i zależności. Skoncentruj się na stabilności technicznej i standaryzacji, gdy najpierw zaczniesz korzystać z kontraktów danych, a następnie korzystaj z procesu nauczonego lekcji podczas iteracji. Powoli twórz i automatyzuj ład danych, aby nie zwiększać nakładu pracy organizacji.
Aby uzyskać więcej informacji na temat możliwości obserwacji i umów dotyczących udostępniania danych, zobacz Przewodnik monitorowania chmury: Obserwacja.
W ramach dokumentacji kontraktu danych potrzebne są również warunki umowy dotyczącej usług i poziomu usług (SLA). Użyj umów SLA, aby przedstawić wymagania dotyczące jakości dostarczania danych i interfejsów, w tym czasu pracy, współczynników błędów i dostępności. Umowy SLA mogą również obejmować wszelkie wymagania dotyczące wycofania, planu działania i numeru wersji, które należy zdefiniować.