5

mam fabrykę danych z działalności kopiowania rurociąg jak ten:Azure dane fabryczne aktywność kopia z magazynu do SQL: wisi na 70000 wierszy

{ 
    "type": "Copy", 
    "name": "Copy from storage to SQL", 
    "inputs": [ 
    { 
     "name": "storageDatasetName" 
    } 
    ], 
    "outputs": [ 
    { 
     "name": "sqlOutputDatasetName" 
    } 
    ], 
    "typeProperties": { 
    "source": { 
     "type": "BlobSource" 
    }, 
    "sink": { 
     "type": "SqlSink" 
    } 
    }, 
    "policy": { 
    "concurrency": 1, 
    "retry": 3 
    }, 
    "scheduler": { 
    "frequency": "Month", 
    "interval": 1 
    } 
} 

dane wejściowe są ok 90MB w wielkości około 1,5 miliona wierszy , w podziale na ok. Pliki blokowe o wielkości 20 x 4,5 MB w usłudze Azure Storage. Oto przykład danych (CSV):

A81001,1,1,1,2,600,3.0,0.47236654,141.70996,0.70854986 A81001,4,11,0,25,588,243.0,5.904582,138.87576,57.392536 A81001,7,4,1,32,1342,278.0,7.5578647,316.95795,65.65895

zlew jest Azure SQL serwera typu S2, ustalona jest na 50 DTUs. Stworzyłem prostą tabelę z sensownych typów danych, a nie ma klucze, indeksy ani nic nadzwyczajnego, po prostu kolumny:

CREATE TABLE [dbo].[Prescriptions](
    [Practice] [char](6) NOT NULL, 
    [BnfChapter] [tinyint] NOT NULL, 
    [BnfSection] [tinyint] NOT NULL, 
    [BnfParagraph] [tinyint] NOT NULL, 
    [TotalItems] [int] NOT NULL, 
    [TotalQty] [int] NOT NULL, 
    [TotalActCost] [float] NOT NULL, 
    [TotalItemsPerThousand] [float] NOT NULL, 
    [TotalQtyPerThousand] [float] NOT NULL, 
    [TotalActCostPerThousand] [float] NOT NULL 
) 

Źródłem, zlewozmywak i fabryka dane znajdujące się w tym samym regionie (Europa Północna).

Według Microsoft's 'Copy activity performance and tuning guide', dla źródła Azure Storage Source i Azure SQL S2 powinienem uzyskać około 0,4 MBps. Według moich obliczeń oznacza to, że 90 MB powinno przenieść się za około pół godziny (czy to prawda?).

enter image description here

z jakiegoś powodu to kopiuje 70.000 wierszy bardzo szybko, a następnie wydaje się powiesić. Używając SQL Management Studio widzę, że liczba wierszy w tabeli bazy danych wynosi dokładnie 70 000 i nie zwiększyła się wcale w 7 godzin. Jednak zadanie kopia jest nadal działa bez żadnych błędów:

enter image description here

pomysłów, dlaczego ta wisi na 70.000 wierszy? Nie widzę nic niezwykłego w wierszu danych 70,001, co mogłoby spowodować problem. Próbowałem już całkowicie zniszczyć fabrykę danych i zacząć od nowa, i zawsze mam takie samo zachowanie. Mam inną aktywność kopiowania z mniejszą tabelą (8000 wierszy), która kończy się za 1 minutę.

Odpowiedz

9

Wystarczy odpowiedzieć na moje własne pytanie w przypadku Pomaga nikogo innego:

Problem był z wartościami null. Powodem, dla którego mój wiersz był zawieszony na 70 000 wierszy, było to, że w wierszu 76560 pliku źródłowego mojego obiektu blob w jednej z kolumn była wartość pusta. Skrypt HIVE, którego użyłem do wygenerowania tego pliku blob, zapisał wartość pustą jako "\ N". Ponadto, moja tabela SQL sink określała "NOT NULL" jako część kolumny, a kolumna była wartością FLOAT.

Więc zrobiłem dwie zmiany: dodano następującą właściwość do mojego blob definicji zestawu danych:

"nullValue": "\\N" 

i udałem SQL kolumny tabeli pustych. Działa teraz całkowicie i nie zawiesza się! :)

Problem polega na tym, że Fabryka Danych nie popełniła błędu, po prostu utknęła - byłoby miło, gdyby zadanie nie powiodło się z użytecznym komunikatem o błędzie, i powiedział mi, w którym rzędzie danych wystąpił problem. Myślę, że ponieważ rozmiar partii zapisu wynosi domyślnie 10 000, dlatego utknął na 70 000, a nie na 76560.

+0

to jest świetne, ale jak doszło do tego ?! – m1nkeh

+2

Musiałem ręcznie skanować moje pliki danych z linii 70 000 w poszukiwaniu jakichkolwiek problemów! Na szczęście pusta/pusta wartość się wyróżniała: p Wyliczyłem później, że możesz zmienić rozmiar partii, np. do 100, co będzie oznaczać, że zawiesi się przy numerze wiersza oddalonym najwyżej o 100 wierszy od problemu –