Sytuacja kobiet w IT w 2024 roku
20.07.20216 min
Benjamin Rogojan

Benjamin RogojanData Engineer / Strategy Development ConsultantThe Seattle Data Guy

Rozmowa kwalifikacyjna na stanowisko Inżyniera danych

Nie daj się zaskoczyć na następnej rozmowie kwalifikacyjnej. Oto pytania, na które każdy szanujący się inżynier danych potrafi znaleźć odpowiedź.

Rozmowa kwalifikacyjna na stanowisko Inżyniera danych

Data Science to tylko jedna z nowoczesnych dziedzin opartych na danych. Z kolei inżynieria danych jest jeszcze bardziej rozpowszechniona niż praca naukowca. Dziś, bycie inżynierem danych nie ma nic wspólnego z byciem naukowcem. Jednak firmy takie jak Google, Facebook, Amazon i Netflix zawsze potrzebują takich inżynierów!

Inżynieria danych wymaga połączenia wiedzy, od hurtu danych po programowanie, w celu zapewnienia, że systemy danych są dobrze zaprojektowane i maksymalnie zautomatyzowane.

Tak więc przejdźmy do sedna sprawy: Jak przygotować się do rozmowy kwalifikacyjnej na stanowisko inżyniera danych?

Wiele z pytań będzie wymagało wiedzy z zakresu hurtowni danych, skryptów, ETL i ewentualnie jakichś NoSQL, jeśli firma korzysta z innego rodzaju systemu do przechowywania danych, jak na przykład CouchDB.

Jeżeli przygotowujesz się do rozmowy o pracę jako inżynier danych, oto kilka pytań, które mogą Ci się przydać. Skupimy się na pytaniach koncepcyjnych. Jednakże trzeba również popracować nad pewnymi technicznymi umiejętnościami, takimi jak SQL, Python i inne.

Jak opracować nowy produkt analityczny jako inżynier danych?

Jako inżynier danych masz kontrolę nad możliwościami produktu końcowego. Naukowiec nie jest w stanie zbudować algorytmów lub metryk bez posiadania danych o odpowiedniej granulacji.

A to oznacza, że inżynier danych musi zrozumieć cały produkt. Nie upiecze mu się budowanie systemów tylko na podstawie wymagań. Inżynier danych musi pytać, dlaczego buduje pewne tabele i obiekty.

Jest to pomocne, w przypadku gdy interesariusze mają już ogólny zarys tego, czego oczekują od produktu. Jeśli go nie mają, trzeba z nimi współpracować w celu wypracowania ogólnej koncepcji metryk i algorytmów. To będzie miało wpływ na wszystkie ważne decyzje: jakie dane powinny być pobierane, jak długo powinny być przechowywane, czy powinny być archiwizowane itd.

Kiedy już powstanie ogólny zarys, następnym krokiem byłoby wnikanie w istotę każdej metryki. To ważne, zważając, że budując tabele o różnej granulacji danych, możemy trafić na problemy. Czy unikalny klucz powinien znajdować się w kolumnach A i B, czy A, B i C? To zależy. Ale od czego? Co oznacza ten wiersz? Czy jest to poziom klienta, sklepu, czy może marki?

Kiedy Twój zespół przejdzie przez proces pracy nad zarysem z interesariuszami i zrozumie, o co chodzi, następnym krokiem jest przemyślenie jak największej liczby scenariuszy działania.

Czy kiedykolwiek będzie trzeba przeładować dane? Czy twoje ETL pozwolą na to? Czy będzie to skuteczne? Co się stanie, gdy wydarzy się X? Jak poradzimy sobie z sytuacją Y?

Nie powinno się spędzać na tym całego dnia, ale próba przewidzenia wszystkich problemów, które mogą się pojawić, pomoże Ci stworzyć solidniejszy system. Pomaga również stworzyć system, który rzeczywiście spełnia wymagania.

A z tego punktu pozostaje jedynie opracowanie projektu, tworzenie przypadków testowych, testowanie tabel, przechowywanych procedur i skryptów, a następnie przeniesienie ich na produkcję. Jak to wygląda, zazwyczaj zależy od zespołu.

Jaka jest różnica między operacyjną bazą danych a hurtownią danych?

Jeśli na studiach uczyli Cię o bazach danych, to prawdopodobnie wiesz jak stworzyć takową, a przynajmniej standardową i znormalizowaną. Taki rodzaj bazy danych jest zoptymalizowany dla transakcji obejmujących polecenia SQL-a jak insert, update czy delete. Są to standardowe operacyjne bazy danych.

Muszą się skupić na szybkim dokonywaniu transakcji, nie pogrążając się w obliczeniach i manipulacji danymi. W związku z tym ich projekt jest nieco bardziej uciążliwy do analizy. Ogólnie rzecz biorąc, będzie trzeba złączyć kilka tabel, tylko po to, by uzyskać sensowne dane.

Hurtownia danych nie zajmuje się tak bardzo obsługą milionów szybkich transakcji co sekundę. Zamiast tego, hurtownia jest zazwyczaj budowana w celu wsparcia produktu analitycznego i analizy danych. Oznacza to, że wydajność nie jest ukierunkowana na transakcje, lecz na agregację, obliczenia i uzyskiwanie danych.

Hurtownia danych będzie miała nieco zdenormalizowaną strukturę w porównaniu z operacyjną bazą danych. Zazwyczaj w hurtowni danych większość tabel przyjmuje dwa różne atrybuty: tabelę transakcji historycznych i tabele zawierające dane w stylu kategorycznym. Odnosimy się do nich jako do tabel faktów i wymiarów.

Tabela faktów znajduje się zasadniczo w centrum, w przeciwieństwie do znormalizowanej bazy danych, gdzie być może trzeba będzie połączyć kilka tabel, aby uzyskać jeden punkt danych. Standardowy magazyn danych zazwyczaj skupia się na tabelach faktów, a wszystkie tabele wymiarowe są łączone w celu dostarczenia informacji kategorycznych do tabeli faktów.

Jest to również typowa zła praktyka łączenia tabeli faktów z tabelą faktów, ale czasami może się zdarzyć, jeśli dane są tworzone prawidłowo. Oto przykład struktury hurtowni danych:

Nie są to jedyne tabele istniejące w hurtowni danych. Dostępne są również tabele agregacyjne, snapshoty, partycje i wiele innych. Celem jest zazwyczaj raport lub a, który może być szybko automatycznie aktualizowany.

Hurtownie danych mają również wiele innych niuansów, takich jak wolno zmieniające się wymiary. Jest to jednak zupełnie inny cyrk z zupełnie innymi małpami.

Opowiedz nam o problemach z wydajnością ETL oraz jak to naprawić?

Jako inżynier danych, napotkasz problemy z wydajnością. Albo ETL był opracowany przez Ciebie, gdy dane były mniejsze, a teraz się nie skalują, albo utrzymujesz starszą architekturę, która nigdy się nie skalowała. ETL posiadają wiele komponentów, wiele wstawień danych do tabel, połączeń i aktualizacji. Utrudnia to dokładne zlokalizowanie problemu z ETL. Pierwszym krokiem jest identyfikacja problemu, więc musisz dowiedzieć się, gdzie występuje zator.

Miejmy nadzieję, że ktokolwiek ustawił twoje ETL, ma gdzieś jego logi, w których śledzone jest wykonanie poszczególnych komponentów. Dzięki temu łatwo będzie dostrzec wąskie gardła i najbardziej czasochłonne operacje. Jeśli ten sposób nie pomoże, znalezienie źródła problemu będzie znacznie trudniejsze.

W zależności od pilności sprawy, zalecamy utworzenie tabeli logów ETL, a następnie ponowne uruchomienie w celu zidentyfikowania problemu. Jeśli naprawa będzie wymagana od razu, prawdopodobnie będzie trzeba po prostu przejść krok po kroku przez całe ETL, aby spróbować wytropić problematyczny komponent. Zależy to również od czasu uruchamiania ETL. Istnieją osobne sposoby podejścia do tego zagadnienia w zależności od działania komponentu.

Problemy mogą się bardzo różnić i obejmować blokady na tabelach, powolne transakcje, zablokowanie wykonania pętli itp. Po zidentyfikowaniu problemu należy oczywiście znaleźć rozwiązanie. W zależności od problemu rozwiązania mogą wymagać dodania indeksu, usunięcia indeksu, podziału tabel i dozowania danych w mniejszych dawkach (a czasem nawet większych - wydaje się to sprzeczne, ale polegałoby na skanowaniu tabel i indeksów). W zależności od używanego rodzaju pamięci masowej, dobrze jest zajrzeć do monitora aktywności, aby zobaczyć, co dzieje się na poziomie I/O. To da Ci lepsze pojęcie o problemie.

Kiedy spojrzysz na monitor aktywności, możesz sprawdzić, czy w ogóle przetwarzane są jakiekolwiek dane. Czy przetwarzane są zbyt duże ilości danych, brak danych lub blokady na tabelach? Każda z tych kwestii może zdławić ETL i należy się nią zająć.

Jeśli wygooglujesz niektóre problemy z wydajnością, to znajdziesz ludzi obwiniających architekturę za wiele problemów. Często mają rację. Jednak to nie znaczy, że możesz się po prostu poddać. Istnieje wiele różnych sposobów zarządzania wydajnością, nawet jeśli nie można tknąć rzeczywistej struktury. Nawet poza indeksami, istnieją pewne metody przetwarzania równoległego, które mogą być wykorzystane do przyspieszenia ETL. Można również dodać tymczasowe tabele wsparcia w celu zmniejszenia obciążenia.

Pytanie numer cztery: Masz doświadczenie w Pythonie, PowerShellu, Bashu i Javie?

To pytanie służy zwróceniu uwagi na to, że jako inżynier danych ważne jest posiadanie języków skryptowych po swojej stronie. Zazwyczaj większość firm, w których będziemy pracować, nie polega tylko na narzędziach ETL, takich jak SSIS. Zamiast tego, często używają niestandardowych skryptów i bibliotek do ładowania danych.

To może wydawać się przesadne, ale często jest łatwiejsze. Używanie narzędzi takich jak SSIS jest świetne, jeśli potrzebujesz wszystkich fantazyjnych funkcji, jak maile i inne dodatki. Nawet te można oskryptować, zamiast wywoływać je ręcznie.

Dlatego warto posiadać jakieś umiejętności z zakresu pisania skryptów. Umożliwia to łatwe zautomatyzowanie przepływu danych i zadań analitycznych.

To tylko kilka ogólnych pytań, które pomogą Ci przygotować się do rozmowy o pracę na stanowisko inżyniera danych. Oprócz tych pytań, możesz również przyjrzeć się koncepcji wolno zmieniających się wymiarów, automatyzacji za pomocą Pythona lub PowerShella, kilku podstawowych poleceń Linuksa i koncepcji projektowych. A jeśli czytasz to faktycznie przygotowując się do rozmowy, to powodzenia! Trzymamy kciuki!


Oryginalny artykuł w języku angielskim można przeczytać tutaj.

<p>Loading...</p>