Optymalne ustawienia przepływu danych SSIS do załadowania do stołu montażowego w usłudze Azure SQL DW

Question

Mam 350 MB tabeli, która jest dość szeroka, z dwoma kolumnami varchar (2000). Poprzez przepływ danych SSIS ładowanie trwa 60 minut przez docelowe "szybkie ładowanie" OLEDB do Azure SQL DW. Zmieniłem miejsce docelowe tego przepływu danych na Azure Blob Destination (z SSIS Azure feature pack) i ten sam przepływ danych zakończył się w ciągu 1,5 minuty (a Polybase z tego nowego płaskiego pliku zajmuje około 2 minut).

Dla innego źródła mam istniejący płaski plik 1GB. Przepływ danych SSIS do miejsca docelowego OLEDB w systemie Azure SQL DW zajmuje 90 minut. Skopiuj plik do magazynu BLOB, a ładowanie w Polybase zajmuje 5 minut.

SSIS to SSIS 2014 i działa na maszynie wirtualnej Azure w tym samym regionie co Azure SQL DW. Wiem, że ładowanie zbiorcze jest znacznie wolniejsze niż w przypadku Polybase, ponieważ ładowanie zbiorcze prowadzi przez węzeł sterujący, ale Polybase jest zrównoleglone we wszystkich węzłach obliczeniowych. Ale te obciążenia są bardzo powolne.

Jakie są optymalne ustawienia dla przepływu danych SSIS i miejsca docelowego w celu załadowania do tabeli etapów DW programu Azure SQL tak szybko, jak to możliwe, poprzez ładowanie zbiorcze? Szczególnie jestem zainteresowany w optymalnej wartości dla następujących ustawień w uzupełnieniu wszelkich innych ustawień nie jestem rozważa:

• Stage stół geometria = HEAP (to najszybszy wierzę)
• ustawień przepływu danych:
  • DefaultBufferMaxRows =?
  • DefaultBufferSize =?
• ustawienia OLEDB przeznaczenia
  • Data Access mode = Tabela lub widok - szybkie obciążenia
  • zachować tożsamość = niesprawdzone
  • Przechowywać null =
  • Blokada stołu =?
  • Sprawdź więzy =?
  • Wiersze na wsad =?
  • Maksymalny rozmiar zatwierdzenia wkładu =?

Answer 1

Polybase pewnością jest to najszybszy sposób, aby załadować do SQL DW. HEAP, jak sugerujesz, jest także najszybszym typem docelowym. Spójrz na ten artykuł z zespołu SQL CAT pod numerem best practices for loading to Clustered Columnstore using SSIS. Zaleceniem zespołu inżynierów jest tutaj dostosowanie DefaultBufferMaxRows (domyślnie 10K), DefaultBufferSize (domyślnie 10 MB), Rows per batch i Maximum commit commit size.

Wiele lat temu przeprowadziłem obszerne testy wydajności SSIS dla naszej lokalnej wersji bazy danych SQL Azure, PDW znanej również jako Parallel Data Warehouse lub APS, Appliance Platform System. Podczas tych testów często stwierdzałem, że lokalny procesor był wąskim gardłem, a konkretnie jednym rdzeniem. Można to wyraźnie zobaczyć za pomocą Perfmon, jeśli monitorujesz wykorzystanie procesora przez rdzeń.

Było kilka rzeczy, które mogłem zrobić, aby poprawić przepustowość. Jeśli procesor jest powiązany z jednym rdzeniem, uruchomienie wielu współbieżnych pakietów SSIS umożliwi wykorzystanie większej liczby rdzeni i będzie działał szybciej. Aby to zrobić, musisz podzielić pliki źródłowe na wiele plików, a miejscem docelowym powinno być wiele tabel.Jeśli podzielisz tabelę docelową, a każde obciążenie zawiera inną partycję, możesz użyć przełączania partycji po wczytaniu danych, aby skonsolidować je do pojedynczej tabeli.

Można również spróbować utworzyć wiele przepływów danych w pakiecie, które osiągną taką samą wydajność, jak równoległe uruchamianie wielu ładowarek SSIS, ale uważam, że nadal trzeba będzie podzielić plik źródłowy na wiele plików, jak również miejsce docelowe, wiele tabel, aby zmaksymalizować przepustowość.

Innym podejściem, które próbowałem, było ładowanie równoległe wewnątrz jednego przepływu danych. Chociaż był szybszy niż jeden program ładujący, był wolniejszy niż poprzednie dwa podejścia, o których wspomniałem powyżej.

Stwierdziłem również, że jeśli mam SSIS zrobić char do konwersji binarnych znaków, że to przyspieszyło ładuje. Ponadto użycie źródła SQL było szybsze niż użycie pliku tekstowego jako źródła.

Kolejną rzeczą, którą możesz wypróbować, jest SSIS Balanced Data Distributor. BDD to inny sposób wykorzystania wielu rdzeni w systemie źródłowym bez konieczności uruchamiania wielu równoległych pakietów SSIS.

Po uruchomieniu pakietów SSIS, monitoruj procesor za pomocą programu perfmon, aby sprawdzić, czy działasz na jednym rdzeniu, czy na wielu rdzeniach. Jeśli przypisujesz jeden rdzeń, to najprawdopodobniej jest to wąskie gardło.

Również w odniesieniu do kolumn VARCHAR (2000). Jeśli naprawdę nie oczekujesz, że Twoje przychodzące dane mają taki rozmiar, zmniejsz rozmiar kolumn VARCHAR. Wprawdzie poprawimy to zachowanie w przyszłości, jednak obecnie nasza usługa przenoszenia danych rozszerzy dane VARCHAR na określoną długość. To oczywiście oznacza, że ​​więcej danych jest przenoszonych niż potrzeba, jeśli najszersza wartość jest znacznie mniejsza niż 2000 znaków.

Mam nadzieję, że to pomoże.