Co Data Engineer powinien umieć w 2021 roku

Kiedyś zdano sobie sprawę, że jedna osoba może nauczyć się używać wielu technologii z wielu obszarów naraz. To właśnie wtedy wymyślono Full Stack Developera, czyli kogoś, kto modeluje dane, pisze kod na backendzie i pracuje na frontendzie. Coś podobnego wydarzyło się na obszarze danych - prawie pół dekady temu powstał Data Engineer.

Dla wielu Full Stack Developer to nadal mityczne stworzenie, ze względu na to, że zna nieskończoną ilość technologii, które odnoszą się do frontendu, backendu oraz pracy z danymi. Data Engineer nie jawi się jednak jako ktoś niewiarygodny. Jednym z powodów może tutaj być fakt, że wizualizacja (analityka biznesowa) sama w sobie stała się bardzo dużym obszarem. 

Data Engineer ma tworzyć systemy, aby udostępniały one dane i aby sprawiały, że będą one możliwe do wykorzystania i przemieszczania się z jednego miejsca do drugiego. Pomimo że wiele firm chce, aby ich inżynierowie danych zajmowali się wizualizacją, to tak się jednak nie zawsze dzieje. Niemniej jednak, jako Data Engineer, warto jest posiadać zakres umiejętności, związanych z analityką biznesową.

Pomówimy tutaj o technologiach, które są zbyt ważne, aby je ignorować. Nie musisz jednak być mistrzem każdej z nich. 

Nie jest to i tak w żaden sposób możliwe. Ważne jest jednak, aby mieć rozeznanie i trochę pojęcia o każdej z nich, aby dobrze sobie poradzić w obszarze pracy z danymi. Nie zapominaj, że nowsze technologie cały czas będą się pojawiać, a starsze, zaczną tracić na aktualności. 

Moim celem jest pokazanie, w którą stronę to wszystko zmierza.

Bazy danych

Nawet wraz z pojawieniem się wielu niekonwencjonalnych baz danych, pierwsza rzecz, jaka przychodzi mi do głowy w tym kontekście to relacyjne bazy danych oraz SQL. 

Relacyjne bazy danych (OLTP)

Wszystkie relacyjne bazy danych działają w mniej więcej taki sam sposób. Wewnętrzne implementacje się między sobą oczywiście różnią. Znajomość jednej lub dwóch relacyjnych baz danych z poniższej listy absolutnie Ci wystarczy: Oracle, MySQL, Microsoft SQL Server oraz PostgreSQL.  

Nie słyszałem o firmie, która działałby bez relacyjnej bazy danych, niezależnie od tego, jak zaawansowane i złożone byłyby ich systemy. 

Wielka czwórka - Oracle, MySQL, MS SQL Server, PostgreSQL.

Oto strona, która pokazuje ranking popularności dla wszelkiego rodzaju baz danych. Zajrzycie, aby sprawdzić, z czego najczęściej obecnie korzystają firmy. 

Magazyny danych (OLAP)

Relacyjne bazy danych (OLTP) są z definicji stworzone z myślą o transakcjach. Do analityki, data lake, magazynów danych, hurtowni danych przydają się bazy danych innego rodzaju. W teorii możesz tworzyć magazyn danych korzystając z bazy OLTP, ale to nie skończy się dobrze, zwłaszcza gdy zwiększa się skala. 

Magazyny danych mają inne systemy do zarządzania bazami danych. Najbardziej popularne to Google BigQuery, Amazon Redshift, Snowflake, Azure Data Warehouse i tak dalej. Wybór magazynu danych zwykle zależy od tego, co jest domyślne w danej usłudze chmurowej, z której korzysta jakaś firma. Jeśli infrastruktura firmy jest na AWS, to z pewnością użyją oni Amazon Redshift, aby zredukować tarcie. 

Wielka czwórka - BigQuery, Redshift, Snowflake, Azure DW

Mając na uwadze powyższe, istnieje spora szansa, że przyszłość chmury nie będzie pojedynczą chmurą, a wieloma chmurami, co z kolei oznacza, że firmy będą sobie mogły dobierać własne magazyny danych bez patrzenia na to, gdzie jest ich obecna infrastruktura i martwienia się, czy nie wywoła to zbyt wielkiego tarcia.  

Inne

Różne przypadki użycia wymagają różnych rozwiązań. Dane geoprzestrzenne wymagają takich baz danych jak PostGIS, a dane szeregu czasowego czasem wymagają wyspecjalizowanych baz danych, takich jak InfluxDB, czy TimescaleDB. 

Bazy danych zorientowane na dokumenty, magazyn klucz-wartość, znalazły się w ekosystemie baz danych, oferując coś, co zawsze było problemem dla relacyjnych baz danych, tj. możliwość wydajnego przechowywania, wyszukiwania i analizowania częściowo ustrukturyzowanych i nieustrukturyzowanych danych.

Wielka ósemka - MongoDB, InfluxDB, neo4j, Redis, Elasticsearch, CosmosDB, DynamoDB, Cloud Datastore.

Potem mamy bazy danych oparte na grafach, bazy danych in-memory oraz wyszukiwarki pełnotekstowe, które rozwiązują bardzo specyficzne problemy. 

Ciężko jest coś wybrać, mając do wyboru setkę baz danych, ale powyższe można zaliczyć do najważniejszych. Te, o których nie wspomniałem, są prawdopodobnie bardzo blisko.

Chmura

Razem z popularyzacją chmury obliczeniowej, którą dostarczają takie firmy jak AWS, Azure i Google Cloud, infrastruktura w dużym stopniu przeszła demokratyzację. Mniejsze firmy nie muszą się już martwić nakładami inwestycyjnymi na infrastrukturę. 

Nie ma większego błogosławieństwa dla inżyniera danych, niż szereg świetnych serwisów, które są dostępne na zasadzie “zapłać za tyle, ile używasz’.

Firmy przeszły na model serverless, gdzie infrastruktura działa tylko, gdy potrzeba obliczeń. Pamięć trwała to już inna usługa.

Wielka trójka - Google Cloud, Azure oraz AWS

To ważne, aby inżynier danych znał wszystkie główne serwisy chmurowe, które dostarcza jedna z powyższych firm. 

Weźmy na przykład AWS - jeśli jesteś inżynierem danych, który pracuje w chmurze AWS, to powinieneś wiedzieć o S3 oraz EBS (jeśli chodzi o przechowywanie danych), EC2 oraz EMR (dla obliczeń i pamięci), Glue oraz Step Functions i Lambda (orkiestracja) itd.

To samo się tyczy innych dostawców chmury.

Orkiestracja

Dla zespołów, które są bardziej skupione na inżynierii, Airflow to ostatnio oczywisty wybór, jeśli chodzi o orkiestratory. Platformy chmurowe mają swoje własne orkiestratory. Na przykład, w przypadku AWS można korzystać z połączenia Glue, Step Functions oraz Lambdy.

Google Cloud oferuje w pełni zarządzaną wersją Airflow o nazwie Cloud Composer. Azure też ma podobne serwisy. 

Król tej kategorii jest jeden - Airflow

Niektóre ze starszych orkiestratorów, silników przepływu pracy oraz narzędzi ETL dobrze się dopasowały i nadal mają znaczenie. Na przykład, Talned to nadal szeroko używany orkiestrator. A to sprawia, że niestety musimy zająć się ETL.

ETL

Tak naprawdę to SQL jest do dzisiaj najlepszą opcją dla ETL. Niedawno jednak pojawiły się inne technologie, takie jak Spark. Więcej pamięci i obliczeń daje tam szybsze rezultaty dzięki eksploatacji zasad masywnego przetwarzania równoległego. Dni, kiedy ETL był pozyskiwany głównie przy pomocy oprogramowania zamkniętego, już dawno minęły.

Na rynku dostępnych jest więcej narzędzi typu open source. Istnieje również wiele w pełni zarządzanych rozwiązań ETL dostarczanych przez firmy zajmujące się integracją danych i ETL. Niektóre z nich to Fivetran, Panoply i Stitch. Większość z tych narzędzi to zaplanowane lub wyzwalane instrukcje SQL pobierające dane z jednej bazy danych i wstawiające do innej. 

Można to łatwo osiągnąć, korzystając z Airflow (lub czegoś podobnego).

Wielka dwójka - SQL i Spark

dbt firmy Fishtown Analytics jest jednym z nielicznych narzędzi, które koncentrują się na rozwiązywaniu problemów związanych z warstwą transformacji w ETL.

Atrakcyjność dbt wynika z tego, że jest on całkowicie oparty na SQL. Z niecierpliwością czekam na chmurową usługę dbt od jednego z kluczowych dostawców. Właściwie to coś takiego może już być w przygotowaniu.

Infrastruktura

DevOpsi podzielili się ostatnio na 3 kategorie - core DevOps, DataOps i DevSecOps. Od inżynierów danych oczekuje się obecnie znajomości infrastruktury. Oznacza to, że powinni być w stanie rozwiązywać problemy operacyjne dotyczące infrastruktury, niezależnie od stosu, z którego korzystają - baz danych, potoków danych, magazynów danych, orkiestratorów, pamięci i tak dalej.

Do tworzenia i utrzymania infrastruktury na rynku mamy kilka niezależnych od platformy chmurowych narzędzi, takich jak Pulumi i Terraform. Takie narzędzia, jak CloudFormation (dla AWS), również spotkały się z szerokim uznaniem.

Wielka dwójka - Terraform, Pulumi

Dobrze jest znać co najmniej jedno z dwóch wyżej wymienionych narzędzi Infrastructure-as-Code. IaC ma swoje zalety, takie jak łatwość wdrażania niezmiennej infrastruktury oraz zwiększona szybkość wdrażania i tak dalej.

CI/CD

Niezależnie od tego, czy wykonujesz deployment infrastruktury, skryptów SQL czy kodu Spark, ciągła integracja i ciągły deployment są tutaj standardem. Czasy, kiedy inżynierowie mieli dostęp do maszyn, logowali się do bazy danych i wykonywali DDL dla procedury składowanej na serwerze bazy danych, już dawno minęły.

Wielu zdało sobie sprawę z ryzyka takiego postępowania, ale niestety z powodu popełnionych błędów.

Wielka czwórka - Jenkins, AWS CodePipeline, Google Cloud Build, Azure DevOps.

Testowanie

Celem inżynierii danych jest udostępnienie danych naukowcom, analitykom danych i ludziom biznesu. Bez odpowiednich testów każdy projekt jest narażony na porażkę. Ręczne testowanie danych jest wysoce nieefektywne i, szczerze mówiąc, nie jest możliwe na dużą skalę.

Wielka dwójka - Pytest, JUnit

Najlepszym rozwiązaniem jest automatyzacja testów. Każdy z frameworków automatyzacji testów dostępnych do testowania kodu backendowego działa również w przypadku testowania komponentów inżynierii danych.

Takie narzędzia jak dbt również mogą być używane do automatyzacji. Mamy też Cucumber i Gherkin z kategorii BDD. Można również użyć Pytest, JUnit i innych.

Kontrola źródła

Pisałem już o kontroli źródła dla SQL. Nie chcę powtarzać wszystkich informacji, które udostępniłem w innym artykule, więc oto link. Używaj kontroli wersji na wszystkim, co możesz: na potokach danych, DDLach baz danych, kodzie orkiestratora i na przypadkach testowych. 

Języki 

Pomimo że Python powinien być oczywistą odpowiedzią na pytanie, jakiego języka używają inżynierowie danych, to istnieje też jednak wiele technologii zbudowanych w Javie i Scali. Cały ekosystem Hadoop oparty jest na Javie. Talend, orkiestrator i narzędzie ETL, jest również napisany w Javie.

Nie wszyscy muszą jednak znać oba języki. Większość powszechnie używanych technologii ma wrapper zarówno dla Pythona jak i Javy, aby produktu mogło użyć więcej osób. Najbardziej powszechnym tego przykładem jest PySpark, który umożliwia inżynierom danych korzystanie z Pythona do interakcji ze Sparkiem.

Wielka trójka - SQL, Python, Java.

To samo można powiedzieć o SQL. Jeśli istnieje jeden język, który inżynierowie danych powinni znać, to jest nim SQL. Bo tak naprawdę to dane mówią w tym języku.

Podsumowanie

Inżynier danych to nie tylko osoba zajmująca się ETL. Nie zajmują się oni też tylko bazami danych. Inżynier danych to połączenie wszystkich rzeczy, o których mówiliśmy w tym artykule, a może i nawet wielu więcej.

Pamiętaj, że perfekcyjne opanowanie wszystkich tych technologii nie jest możliwe, ale każdą z nich można w jakimś stopniu poznać. To jest właśnie teraz najbardziej potrzebne. I tak prawdopodobnie będzie przez kilka następnych lat.