Inżynierowie danych: mity a rzeczywistość

Od autonomicznych samochodów po automatyczne tagowanie na obrazach, analiza danych przeszła długą drogę. Analitycy i analitycy danych stali się integralną częścią każdej organizacji ze względu na wartość dodaną. Ale szczerze mówiąc, analityk danych jest tak dobry, jak dane, z którymi pracuje. Większość dzisiejszych organizacji przechowuje swoje dane w różnych formatach i na wielu platformach. Nadchodzi zapotrzebowanie na inżynierów danych!

Inżynierowie danych to ludzie, którzy sprawiają, że te dane są przydatne dla naukowców zajmujących się danymi i analityków. Inżynierowie danych są odpowiedzialni za tworzenie potoków, które przekształcają stosy danych do formatu, który jest użyteczny dla analityków danych. Przeważnie pracują za kulisami, a zatem są pozbawione uroków analityka danych/badacza danych – ale pamiętaj, że są równie (jeśli nie bardziej) niezbędne do funkcjonowania każdej organizacji.
Jeśli analitycy danych są kierowcami wyścigowymi, inżynierowie danych są konstruktorami samochodów wyścigowych. Ten pierwszy czerpie radość z pędzenia po torze i dreszczyk zwycięstwa przed oklaskami. Ten z kolei czerpie radość z tuningu silników i tworzenia potężnej, solidnej maszyny. Konstruktor samochodów wyścigowych znacznie ułatwia pracę kierowcy (lub trudniejszą, w zależności od jakości konstruktora).
Jak przejść do analizy danych?

Pod tym względem inżynierowie danych są właściwie niedocenianymi bohaterami każdego zespołu analityki danych. Bez inżyniera danych dźwiękowych, analityk danych będzie po prostu drapał się po głowie, szukając wskazówek w niesformatowanych danych.
Zobaczmy, na czym polega praca inżyniera danych.
Aby lepiej zrozumieć, załóżmy, że jesteś inżynierem danych u konkurenta Swiggy (nazwijmy go Twiggy). Masz aplikację, z której użytkownicy mogą korzystać na dowolnym urządzeniu i uzyskiwać dostęp do Twoich usług. Zamawiają jedzenie, zamówienie zostaje przekierowane do odpowiedniej restauracji, jedzenie jest stamtąd odbierane i dociera do Ciebie.
Aby ta usługa była zsynchronizowana, potrzebujesz:

• Aplikacja mobilna dla użytkowników
• Aplikacja mobilna dla restauratorów
• Solidny serwer do obsługi wielu żądań jednocześnie.

Jak już zapewne zrozumiałeś, ta aplikacja wygeneruje OGROMNE ilości danych. Ponadto będziesz potrzebować kilku magazynów danych:

• Baza danych zawierająca dane użytkowników i restauracji.
• Dzienniki dostępu do serwera. Obejmują one wszelkie żądania skierowane do serwera z aplikacji.
• Dzienniki błędów serwera zawierające wszystkie błędy po stronie serwera.
• Dzienniki zdarzeń aplikacji. Będą one zawierać informacje o tym, jakie działania w aplikacji podjęli użytkownicy lub właściciele restauracji.
• Dzienniki błędów aplikacji, które zawierają błędy aplikacji.
• Baza obsługi klienta. Zawiera dane o Twojej interakcji z klientami.

Załóżmy teraz, że analityk danych z Twojego zespołu chce przeanalizować zachowanie użytkowników w Twoich usługach i zobaczyć, jakie działania są skorelowane z użytkownikami o wysokich wydatkach. Aby pomóc im to stworzyć, musisz połączyć wszystkie informacje z dzienników dostępu do serwera i dzienników zdarzeń aplikacji.
Musisz:

• Regularnie gromadź dzienniki analizy aplikacji.
• Połącz dzienniki analizy aplikacji z wpisami dziennika serwera dla odpowiednich użytkowników.
• Opracuj interfejs API, który zwraca historię zdarzeń dowolnego użytkownika.

To dużo pracy!
Aby to wszystko zrobić, musisz utworzyć potok, który będzie mógł wydajnie pozyskiwać dzienniki aplikacji mobilnych i dzienniki serwera w czasie rzeczywistym, analizować je i łączyć z odpowiednim użytkownikiem. Co więcej, będziesz musiał przechowywać przeanalizowane dzienniki w bazie danych, aby interfejs API mógł łatwo wysyłać do nich zapytania. Będzie wiele serwerów, które będziesz musiał uruchomić za systemem równoważenia obciążenia, aby analizować przychodzące logi.
Większość problemów, które napotkasz, dotyczy systemów rozproszonych i niezawodności. Jeśli masz miliony urządzeń, z których możesz gromadzić logi i dynamiczne żądania (po południu dostajesz wiele wpisów w dzienniku, ale nie tak dużo w nocy), będziesz musiał opracować system, który może automatycznie skalować liczbę serwerów w górę i w dół w zależności od natężenia ruchu.
Najważniejsze kroki do opanowania nauki o danych

Ogólnie rzecz biorąc, operacje w ogólnym potoku inżynierii danych przechodzą następujące etapy:

• Spożycie: zbieranie potrzebnych danych.
• Przetwarzanie: przetwarzanie danych w celu uzyskania pożądanego rezultatu.
• Przechowywanie: przechowywanie wyniku w celu szybszego wyszukiwania.
• Dostęp: umożliwienie narzędziu dostępu do wyników potoku danych.

Od inżyniera danych oczekuje się posiadania wiedzy w następujących dziedzinach.

• Magazyn danych:
  • RDBMS, takie jak MySQL, MS SQL Server itp.
  • Bazy danych NoSQL, takie jak HBase, MongoDB, CouchDB, Cassandra itp.
• Zbieranie danych:
  • RESTful API
  • Znajomość modelowania danych i ekspertyza SQL.
• Transformacja danych:
  • Narzędzia ETL, takie jak Informatica, Datastage, Redpoint itp.
  • Dowolny język skryptowy, taki jak Python, Ruby, Perl itp.

Przyjrzyjmy się niektórym mitom i błędnym wyobrażeniom dotyczącym życia i pracy tych inżynierów danych.

Mit 1: Inżynierowie danych wydobywają wartość z zebranych danych.

Pomiędzy zbieraniem danych a wydobywaniem wiedzy jest wiele rzeczy. Inżynierowie danych są przede wszystkim odpowiedzialni za konwertowanie danych do postaci odpowiedniej do analizy i pracy przez naukowców. Pod tym względem nie wyciągają żadnej wartości z danych, w rzeczywistości przedstawiają dane na tabliczce naukowcom zajmującym się danymi, którzy następnie odkrywają z nich wartość.

Mit 2: Inżynierowie danych muszą zadbać o to, by wszystkie dane były nieskazitelne.

Zrozumiesz niedorzeczność tego, jeśli będziesz czytać powyższe zdanie powoli. Inżynier danych zajmuje się przychodzącymi strumieniami danych przez cały dzień. Te dane muszą zostać natychmiast wyczyszczone i podjęte działania, aby nie stały się nieaktualne. Przez nieświeży rozumiemy niewidzący i stary. Dlatego inżynierowie danych nie dbają o to, aby wszystkie dane były nieskazitelnie czyste. Pracują na dostępnych danych w połączeniu z innymi danymi, które są niezbędne do rozwiązania problemu. Czyszczenie kompletnych zbiorów danych zajmie miesiące i do tego czasu nie będzie już przydatne.
Podstawowe podstawy statystyki dla nauki o danych

Mit 3: Inżynierowie danych zrzucają dane na gotowe narzędzia i cieszą się czystymi/praktycznymi danymi jako danymi wyjściowymi.

Proszę, nie mów tego głośno w obecności żadnego inżyniera danych. Kiedykolwiek. Żaden szanujący się inżynier danych nie będzie tolerował tak rażącej zniewagi. Jak każdy inny inżynier (oprogramowania, mechaniki, chemii itp.), inżynierowie danych wymagają ciągłego myślenia. W inżynierii danych nie ma jednego uniwersalnego podejścia, a inżynierowie danych muszą stale kształtować algorytmy, aby pasowały do ​​ich przypadku użycia. Muszą być świadomi najnowszych technik i metod związanych z ich pracą, aby zapewnić doskonałą wydajność.

Mit 4: Inżynierowie danych to tylko inżynierowie oprogramowania, którzy pracują nad Big Data.

Inżynierowie oprogramowania pracują nad tworzeniem aplikacji mobilnych/sieciowych. Ich praca wiąże się z wieloma różnymi problemami, a trudność polega na zarządzaniu zadaniami – myśl, komunikuj się i porządkuj kod. Z drugiej strony inżynierowie danych mają na ogół mniej problemów, ale poszczególne problemy są znacznie trudniejsze technicznie. Od perspektyw po umiejętności, inżynier danych jest zupełnie inny niż inżynier oprogramowania.
Kim jest analityk danych, analityk danych i inżynier danych?

Uzyskaj certyfikat nauk o danych od najlepszych uniwersytetów na świecie. Naucz się programów Executive PG, Advanced Certificate Programs lub Masters Programs, aby przyspieszyć swoją karierę.