SQL vs Data Analyst 💻 Jak to wygląda w praktyce? Na co zwrócić uwagę? | KajoData Podcast

Cześć, ja się nazywam Kajo Rudziński, to jest KajoData i dzisiaj odcinek taki trochę bardziej techniczny, mimo iż będę gadał do kamery. Mianowicie chciałbym opowiedzieć o tym, jak analityk pracuje z SQL-em. Powody są dwa. Po pierwsze, często dostaję od was takie pytanie, jak to tak naprawdę wygląda w pracy. KajoData Podcast. Names mentioned. KajoData Podcast. I są one w dużej mierze niedokładne, bo tak po prostu w biznesie jest. Przejdziemy sobie przez takie cztery punkty, które chciałbym bardzo mocno podkreślić, które są dosyć nieoczywiste i których świadomość bardzo ci pomoże także na rozmowach kwalifikacyjnych, bo będziesz wiedział też w jaki sposób eksponować swoje umiejętności w SQLu, jeżeli będziesz o to pytany.

Punkt pierwszy. Analityk głównie czyta SQL innych. Często jest tak, że wydaje nam się, że my jakby pracujemy sami i sami sobie wszystko piszemy. Niestety, czy też stety, tak po prostu jest. Jesteś częścią większego zespołu, jesteś częścią firmy i najczęściej w tej firmie będą inni analitycy. No chyba, że mamy do czynienia z taką jakąś bardzo małą firmką albo małym startupem, gdzie rzeczywiście jest tylko jeden taki analityk, ale trochę trudno mi sobie to wyobrazić. W większości firm tych analityków jest więcej, więcej jest osób, które posługują się SQL-em, a to oznacza, że o wiele częściej niż ci się wydaje, będziesz czytał SQL-e innych osób. Jakie są tego konsekwencje? Konsekwencje są dwie. Po pierwsze, bardzo ważne jest, żebyś sam ułatwiał to innym ludziom, z którymi pracujesz, czyli żebyś skupiał się na tym, że twój SQL, twój kod SQL-owy jest napisany w taki sposób,

KajoData. A druga rzecz, która z tego płynie, jest taka, że musisz umieć te SQL-e czytać. To znaczy, jeżeli na przykład widzisz jakiegoś SQL-a gdzieś tam w internecie czyjegoś, to nie miej takiego, że o nie, to jest trudne, ja się teraz zastanowię, jak ja bym to sam napisał, tylko rzeczywiście wejdź sobie i popatrz na takie dłuższe zapytania, bo to po prostu pomaga, to jest część pracy.

Powinno iść rzeczywiście na uczenie się selectów i wszystkiego, co jest z tym związane, czyli join-off, subquery, tego, jak można mieć skomplikowane warunki w aware, tego, jak działają window functions, bardzo różnych połączeń, tabel ze sobą. To jest dla ciebie istotne. Nie jest dla ciebie aż tak istotne np. normalizowanie tabel, bo oczywiście ktoś może powiedzieć, ale normalizacja też jest istotna. Tak, jest istotna dla administratorów bazy danych. To jest ich zadanie. Nie za bardzo to jest twoje zadanie. Oczywiście dobrze, jeżeli wiesz, na czym normalizacja polega, ale to nie jest główna rzecz, którą masz robić, bo tym sposobem to wszystko jest ważne. Jak wszystko jest ważne, to nic nie jest ważne. Więc jeżeli chodzi o pracę z SQL-em, analityka i rzeczy, których powinieneś się nauczyć, to to są przede wszystkim rzeczy, które możesz zrobić w poleceniu SELECT.

Tutaj z tą optymalizacją jest często taki problem, że jak np. piszemy CTE, to bardzo często to, co się dzieje, to za bardzo idziemy w ten punkt nr 1, czyli chcemy, żeby ten nasz SQL się super dobrze czytało, więc rozbijamy naszego SQL-a, nasz kod na tam 10 takich okienek, czyli tych Common Table Expressions. I to jest spoko i na początku to jest tak, że są takie etapy, że próbujesz pisać po prostu na coś, co działa, później próbujesz jak najbardziej zagęścić ten kod, później odkrywasz CTE i to jest dla ciebie takie super, bo teraz wszystko jest czytelne, można sobie to porozbijać na osobne fragmenty kodu. No ale jest jeszcze jedna rzecz, że odpytywanie na przykład tej samej tabeli, bez powodów CTE, jest no...

Dlatego z tą optymalizacją jest ten problem, że ona rywalizuje z czytelnością. To znaczy często jest tak, że im bardziej coś jest optymalne, tym mniej jest czytelne i odwrotnie. Im bardziej coś jest czytelne, tym mniej jest optymalne. Oczywiście zazwyczaj udaje się znaleźć jakiś tam złoty środek i to nie jest tak, że to się kompletnie wyklucza. Ale trzeba o tym balansie pamiętać i to jest fajna rzecz, jak będziesz na przykład rozmawiał o SQLu na rozmowie kwalifikacyjnej, żeby na tej rozmowie poruszyć ten temat, że masz tego świadomość. I znowu, jeżeli Zastanawiasz się o tym, jak popracować sobie nad tą optymalizacją, to warto pomyśleć o takich elementach jak indeks, partycja, explainitan.

I znowu, czy ta sekwencja Wydarzeń pokrywa się sekwencją timestampów. Czy jest jednak coś, że coś tam się zaktualizowało i de facto zaktualizowało coś wstecz w naszej bazie danych i trochę wykrzacza nam dane. To też jest ważna rzecz jeśli chodzi o jakość danych. Czyli znowu takie trzy elementy. Duplikaty, nule, timestampy. Tym samym, jeżeli miałbym podsumować, to analityk pracując z bazą danych będzie się skupiał na czterech elementach. Będzie czytał SQL innych, będzie pisał głównie polecenia select, będzie optymalizował te selecty korzystając z indeksów czy partycji oraz będzie często sprawdzał jakość danych. Daj mi koniecznie znać w komentarzu, Czego ci tutaj brakuje?

Co jeszcze ty robisz, jeżeli pracujesz już z SQL-em w swojej firmie? Albo jeżeli nie pracujesz, to który z tych elementów sprawia ci największą trudność? Przy okazji pozwolę sobie przypomnieć, że mam kurs Analiza danych z SQL i znajdziesz link pod tym odcinkiem, który pomoże ci opanować SQL-a właśnie z takim fokusem dla analityka przede wszystkim. To tyle z mojej strony. Widzimy się w kolejnym odcinku.