SQL Server PolyBase Engine

PolyBase Engine umożliwia wykonywanie zapytań łączących dane relacyjne z zewnętrznymi źródłami, np. Hadoop.

Rola PolyBase Engine w SQL Server

SQL Server PolyBase Engine jest komponentem SQL Server odpowiedzialnym za obsługę zapytań do danych znajdujących się poza lokalną bazą relacyjną. Dzięki niemu zapytanie napisane w języku Transact-SQL może odczytywać dane z określonych zewnętrznych źródeł i łączyć je z tabelami przechowywanymi w SQL Server. Użytkownik korzysta z obiektów takich jak zewnętrzne źródło danych, format pliku oraz tabela zewnętrzna, natomiast silnik PolyBase tłumaczy operacje na sposób zrozumiały dla podłączonego dostawcy danych.

W SQL Server 2016 PolyBase wprowadzono między innymi do pracy z Hadoop i usługą Azure Blob Storage. W kolejnych wersjach dodano obsługę połączeń z innymi instancjami SQL Server, Oracle, Teradata, MongoDB, ogólnymi sterownikami ODBC oraz magazynami obiektowymi zgodnymi z S3. Zakres zależy od wersji SQL Server i konkretnego konektora. Istotne jest także rozróżnienie między dawną obsługą Hadoop a współczesnymi instalacjami: SQL Server 2022 i nowsze wersje nie obsługują zewnętrznych źródeł Hadoop.

Obiekty T-SQL opisujące dane zewnętrzne

Konfiguracja PolyBase rozpoczyna się od utworzenia obiektu CREATE EXTERNAL DATA SOURCE. Definiuje on lokalizację oraz rodzaj źródła, na przykład adres magazynu obiektowego albo połączenie z inną bazą SQL Server. Dostęp do niepublicznych zasobów może wymagać poświadczenia przypisanego do bazy za pomocą obiektu database scoped credential. Dzięki temu dane uwierzytelniające nie muszą być wpisywane bezpośrednio w każdym zapytaniu.

Następnie można utworzyć tabelę zewnętrzną poleceniem CREATE EXTERNAL TABLE. Tabela przechowuje w katalogu SQL Server opis kolumn, typów danych, formatu plików i powiązanego źródła, ale nie musi zawierać samych rekordów. Zapytanie SELECT wykonane na takiej tabeli uruchamia odczyt w źródle zewnętrznym. W SQL Server 2022 PolyBase obsługuje między innymi pliki CSV, Parquet i Delta przechowywane w Azure Storage, Azure Data Lake Storage Gen2 lub zgodnym magazynie S3. Do jednorazowego odczytu plików może służyć także OPENROWSET, a do zapisania wyników zapytania w zewnętrznym zbiorze danych służy między innymi CREATE EXTERNAL TABLE AS SELECT, znane jako CETAS.

Przebieg zapytania i ograniczenia wydajnościowe

Zapytanie do tabeli zewnętrznej jest najpierw analizowane przez SQL Server. Część dotycząca zewnętrznych danych trafia do PolyBase Engine, który tworzy plan odczytu i przekazuje zadania do usług odpowiedzialnych za przemieszczanie danych. Wyniki są zwracane do instancji SQL Server, gdzie mogą zostać połączone z lokalnymi tabelami, przefiltrowane albo poddane dalszym operacjom T-SQL. W niektórych scenariuszach predykaty mogą zostać przesłane do źródła zewnętrznego, co ogranicza ilość danych przesyłanych do SQL Server. Nie każda operacja i nie każdy konektor obsługuje jednak takie przesunięcie obliczeń.

PolyBase nie gwarantuje stałego czasu odpowiedzi. Wydajność zależy od ilości danych, liczby plików, formatu, organizacji katalogów, przepustowości sieci, możliwości źródła oraz złożoności filtrów i złączeń. Odczyt dużych plików kolumnowych, takich jak Parquet, może zachowywać się inaczej niż odczyt wielu małych plików CSV. Tabela zewnętrzna nie jest automatycznie kopią danych ani indeksem lokalnym. Jeżeli źródło jest niedostępne, poświadczenie wygasło, definicja kolumn nie odpowiada rzeczywistym plikom albo brakuje wymaganego konektora, zapytanie może zakończyć się błędem mimo poprawnej składni T-SQL.

Diagnostyka instalacji i połączenia PolyBase

Diagnostykę należy rozpocząć od ustalenia wersji SQL Server, systemu operacyjnego i faktycznie dostępnego konektora. W SQL Server 2019 funkcję PolyBase trzeba w razie potrzeby włączyć w konfiguracji instancji za pomocą opcji polybase enabled, a następnie wykonać RECONFIGURE. Sama obecność tabeli zewnętrznej nie potwierdza poprawności całej konfiguracji. Należy jeszcze sprawdzić istnienie zewnętrznego źródła danych, formatu pliku, poświadczenia zakresu bazy oraz uprawnień użytkownika wykonującego zapytanie.

Podczas analizy błędu warto oddzielić problem SQL Server od problemu sieciowego i problemu po stronie źródła. Sprawdza się adres lokalizacji, dostępność portów, certyfikaty lub sposób uwierzytelniania, zgodność typów danych oraz strukturę plików. Przy migracji do SQL Server 2022 trzeba zweryfikować stare definicje używające typu HADOOP lub dawnych schematów Azure Storage, ponieważ część z nich wymaga usunięcia i ponownego utworzenia z użyciem aktualnych konektorów. W przypadku awarii należy zachować komunikat błędu, plan zapytania, definicję obiektów PolyBase i informacje o wersji, ponieważ dopiero ich zestawienie pozwala rozstrzygnąć, czy przyczyną jest konfiguracja, niezgodność wersji, dostęp do źródła czy rzeczywista usterka komponentu.