Self Service BI jest obecnie bardzo popularnym podejściem do demokratyzacji danych organizacyjnych. Jako inżynierowie chcemy umożliwić pracę z danymi mniej zaawansowanym użytkownikom – powinni oni być w stanie w sposób naprawdę prosty eksplorować zbiory czy tworzyć proste kokpity menedżerskie. Takie możliwości daje platforma Databricks SQL, o której więcej w tym poście.
Przecież SQL w Databricks to nie nowość
Jeśli pracowałeś już z Databricks wiesz, że można tam uruchamiać zapytania z wykorzystaniem SQL, a konkretniej Spark SQL. Takie zapytania oczywiście wykorzystujemy w notatnikach. W pracy inżyniera danych takie rozwiązanie spełnia swoje zadanie, a w notatnikach możemy nie tylko tworzyć nowe struktury bazodanowe, wykonywać transformacje ale także prezentować dane na prostych wykresach. Warto tutaj dodać, że polecenia pisane w Spark SQL powinny być tak samo wydajne, jak te pisane w PySpark czy Scali. Wydaje się więc, że niczego więcej nam do szczęścia nie potrzeba – możemy pisać zapytania SQL w zwykłych notatnikach databricksowych.
Z punktu widzenia użytkownika biznesowego takie rozwiązanie nie do końca może spełniać oczekiwania, a praca na notatnikach może być zbyt skomplikowana. Oczywiście to bardzo subiektywne stwierdzenie, ale prościej byłoby nie tłumaczyć czym jest klaster, notatnik i jak z niego korzystać, a jedynie pokazać miejsce, gdzie można uruchamiać zapytania i tworzyć dashboardy. I tu przychodzi Databricks SQL, czyli platforma skierowana bardziej do użytkowników nie będących inżynierami, a chcących analizować dane z wykorzystaniem SQL.
Jak korzystać z Databricks SQL?
Potrzebne będzie Databricks w warstwie Premium, niestety funkcjonalność nie jest dostępna w warstwie standard czy na darmowym community. Jeśli mamy otwarty workspace, to w lewym rogu, pod logo Databricks widoczne będzie rozwijanie menu z opcją Databricks SQL. Po kliknięciu, zostaniemy przeniesieni do platformy.
Inicjalna konfiguracja
Oczywiście aby móc wykonywać operacje potrzebny będzie klaster, tutaj nazywany jako SQL Endpoint. Domyślnie jest utworzony Starter Endpoint, zwróćmy uwagę jak małe mamy możliwości konfiguracji (w przeciwieństwie do klasycznych klastrów). Właściwie możemy wybrać tylko rozmiar, który jest wyrażony w jednostkach DBU, określić zakres skalowania oraz czas, po jakim klaster ma się wyłączyć przy braku aktywności. Nie ma tutaj różnych specyfikacji pod konkretne wykorzystanie, nie możemy nawet wybrać, z której wersji Databricks Runtime chcemy skorzystać, można by powiedzieć – serverless. Przy konfiguracji warto zaznaczyć opcję photon, wykorzystamy wtedy nowy silnik o wyższej wydajności. To tyle, możemy uruchomić klaster i zacząć pracę na testowym zbiorze danych. Jeśli jednak interesuje Cię co kryje się pod nazwami rozmiarów SQL Endpointów, to tutaj jest dostępna specyfikacja.
Odpytujemy bazę testową
Nie mając załadowanych danych możemy skorzystać z przykładów udostępnionych przez Databricks. Wybieramy opcję SQL Editor, następnie metastore samples i bazę tpch. Piszemy proste zapytanie, po jego wykonaniu mamy wyniki w formie tabeli, natomiast tę formę możemy łatwo zmienić klikając na opcję edit visualisation. Wyniki można także eksportować do różnych formatów, należy jednak pamiętać o limicie 65 000 wierszy, który istnieje w momencie pisania tego posta.
Analiza danych z pliku CSV
Oczywiście z poziomu SQL Databricks będziemy mieli dostęp również do innych tabel w naszym workspace, w tym tych z delta lake’a. Do celów testowych pobrałem plik z dane.gov.pl, następnie załadowałem bezpośrednio do DBFS (w tym celu wykorzystałem obszar data science and engineering) i utworzyłem tabelę (już na Databricks SQL) za pomocą kodu.
CREATE TABLE rezydenci
USING CSV
OPTIONS (
path = "dbfs:/FileStore/Rezydenci.csv",
header = "true",
delimiter = ";",
inferSchema = "false"
)
Co ważne ta tabela będzie dostępna zarówno z poziomu Databricks SQL jak i klasycznych notebooków. Możliwe jest także nadanie uprawnień, dla użytkowników czy grup. Oczywiście dane możemy analizować za pomocą narzędzi takich jak power BI czy Tableau. W tym wystarczy, że przejdziemy do zakładki Partner Connect i wybierzemy odpowiednie narzędzie, następnie zostanie pobrany plik, który umożliwi połączenie bezpośrednio z SQL Enpointem. Istotne jest to, że jeśli endpoint jest wyłączony, to uruchomi się automatycznie. Korzystając z tableau, po pobraniu pliku możemy się zalogować z użyciem tokena, możemy go wygenerować w zakładce users setting. Po zalogowaniu wystarczy dodać tabele, które nas interesują i możemy tworzyć raporty.
Monitoring
Aby mieć pewność, że rozmiar SQL Enpointa jest dobrany optymalnie, powinniśmy monitorować bieżące zużycie zasobów. Oczywiście mamy taką możliwość, wystarczy otworzyć zakładkę SQL Endpoint, a następnie przejść do karty monitoring, gdzie możliwa jest weryfikacja, jak wiele zapytań jest uruchomionych i czy klaster radzi sobie z obciążeniem. Co również istotne, możemy śledzić wszystkie zapytania, jakie były uruchomione na Endpoincie, łącznie z informacją o czasie trwania i autorze zapytania. To na wypadek, gdybyśmy otrzymywali skargi o wolnych zapytaniach.
W czym Databricks SQL pomoże organizacji?
Przede wszystkim umożliwi demokratyzację danych w środowisku mniej zaawansowanych użytkowników. Mam tu na myśli głównie analityków, którzy bardzo dobrze znają SQLa i chcieliby w prosty sposób korzystać z mocy klastrów sparkowych. Uproszczona platforma przyczyni się do większej adopcji platformy danych w naszej organizacji. Co więcej, być może w niektórych sytuacjach będziemy mogli zrezygnować elementów platformy danych, takich jak klasyczne serwery bazodanowe, a wystarczy nam Databricks i data lake. Oczywiście, znaczne uproszczenia w Databricks SQL niosą ze sobą limity – na przykład brak możliwości wyboru wersji Databricks runtime’u działającym na klastrze. Co więcej, nie jest możliwe instalowanie dodatkowych bibliotek i korzystanie z zewnętrznego metastore’a. Znajdzie się pewnie jeszcze kilka limitów, ale pamiętać należy, że nie zawsze będą one istotne dla naszego projektu. Być może w kolejnych wydaniach te limity zostaną wyeliminowane.