Przekształcanie asertywne w przepływie danych mapowania

  • Artykuł

DOTYCZY: Azure Data Factory Azure Synapse Analytics

Napiwek

Wypróbuj usługę Data Factory w usłudze Microsoft Fabric — rozwiązanie analityczne typu all-in-one dla przedsiębiorstw. Usługa Microsoft Fabric obejmuje wszystko, od przenoszenia danych do nauki o danych, analizy w czasie rzeczywistym, analizy biznesowej i raportowania. Dowiedz się, jak bezpłatnie rozpocząć nową wersję próbną !

Przepływy danych są dostępne zarówno w usłudze Azure Data Factory, jak i w potokach usługi Azure Synapse. Ten artykuł dotyczy przepływów danych mapowania. Jeśli dopiero zaczynasz transformacje, zapoznaj się z artykułem wprowadzającym Przekształcanie danych przy użyciu przepływu danych mapowania.

Transformacja asercyjna umożliwia tworzenie niestandardowych reguł wewnątrz przepływów danych mapowania na potrzeby jakości danych i walidacji danych. Można tworzyć reguły, które określają, czy wartości spełniają oczekiwaną domenę wartości. Ponadto można tworzyć reguły sprawdzające unikatowość wierszy. Przekształcenie asertywne pomoże określić, czy każdy wiersz w danych spełnia zestaw kryteriów. Przekształcenie asertywne umożliwia również ustawianie niestandardowych komunikatów o błędach, gdy reguły sprawdzania poprawności danych nie są spełnione.

Assert type

Konfigurowanie

W panelu konfiguracji przekształcania asercji wybierzesz typ asercji, podaj unikatową nazwę asercji, opcjonalny opis oraz zdefiniuj wyrażenie i opcjonalny filtr. Okienko podglądu danych wskaże, które wiersze zakończyły się niepowodzeniem asercji. Ponadto można przetestować każdy tag wiersza podrzędny przy użyciu poleceń isError() i hasError() dla wierszy, które zakończyły się niepowodzeniem.

Assert settings

Typ asertywnej

  1. Oczekiwano wartości true: wynik wyrażenia musi zostać obliczony na wynik true wartości logicznej. Służy do sprawdzania poprawności zakresów wartości domeny w danych.
  2. Oczekiwano unikatowości: ustaw kolumnę lub wyrażenie jako regułę unikatowości w danych. Służy do tagowania zduplikowanych wierszy.
  3. Oczekiwano: ta opcja jest dostępna tylko po wybraniu drugiego strumienia przychodzącego. Istnieje, przyjrzyj się strumieniom i określi, czy wiersze istnieją w obu strumieniach na podstawie kolumn lub wyrażeń, które zostały określone. Aby dodać drugi strumień dla elementu istnieje, wybierz pozycję Additional streams.

Assert configuration

Przepływ danych, który kończy się niepowodzeniem

Wybierz fail data flow , jeśli chcesz, aby działanie przepływu danych nie powiodło się natychmiast po awarii reguły asercji.

Identyfikator potwierdzenia

Identyfikator asercji to właściwość, w której należy wprowadzić nazwę (ciąg) dla asercji. Będzie można użyć identyfikatora później podrzędnego w przepływie danych przy użyciu hasError() polecenia lub w celu wyprowadzenia kodu błędu asercji. Identyfikatory asertów muszą być unikatowe w każdym przepływie danych.

Opis potwierdzenia

Wprowadź tutaj opis ciągu potwierdzenia. W tym miejscu możesz również użyć wyrażeń i wartości kolumn kontekstu wiersza.

Filtr

Filter to opcjonalna właściwość, w której można filtrować asercji tylko do podzbioru wierszy na podstawie wartości wyrażenia.

Expression

Wprowadź wyrażenie do oceny dla każdej asercji. Dla każdej transformacji asercji można mieć wiele asercji. Każdy typ asercji wymaga wyrażenia, które usługa ADF będzie musiała ocenić, aby sprawdzić, czy aseracja została przekazana.

Ignoruj listy NUL

Domyślnie przekształcenie asercji będzie zawierać listy NUL w ocenie asercji wierszy. Możesz zignorować listy NUL z tą właściwością.

Niepowodzenia wierszy asercyjności bezpośredniej

W przypadku niepowodzenia asercji można opcjonalnie skierować te wiersze błędów do pliku na platformie Azure przy użyciu karty "Błędy" na transformacji ujścia. Istnieje również opcja przekształcenia ujścia, aby nie zwracać wierszy z błędami asercji w ogóle, ignorując wiersze błędów.

Przykłady

source(output(
		AddressID as integer,
		AddressLine1 as string,
		AddressLine2 as string,
		City as string,
		StateProvince as string,
		CountryRegion as string,
		PostalCode as string,
		rowguid as string,
		ModifiedDate as timestamp
	),
	allowSchemaDrift: true,
	validateSchema: false,
	isolationLevel: 'READ_UNCOMMITTED',
	format: 'table') ~> source1
source(output(
		CustomerID as integer,
		AddressID as integer,
		AddressType as string,
		rowguid as string,
		ModifiedDate as timestamp
	),
	allowSchemaDrift: true,
	validateSchema: false,
	isolationLevel: 'READ_UNCOMMITTED',
	format: 'table') ~> source2
source1, source2 assert(expectExists(AddressLine1 == AddressLine1, false, 'nonUS', true(), 'only valid for U.S. addresses')) ~> Assert1

Skrypt przepływu danych

Przykłady

source1, source2 assert(expectTrue(CountryRegion == 'United States', false, 'nonUS', null, 'only valid for U.S. addresses'),
	expectExists(source1@AddressID == source2@AddressID, false, 'assertExist', StateProvince == 'Washington', toString(source1@AddressID) + ' already exists in Washington'),
	expectUnique(source1@AddressID, false, 'uniqueness', null, toString(source1@AddressID) + ' is not unqiue')) ~> Assert1

Powiązana zawartość