POIT #085: DataOps

Witam w osiemdziesiątym piątym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest DataOps.

Dziś moim gościem jest Tomasz Gintowt – w smoim życiu był już Architekt’em, DevOps’em, SysOps’em oraz DBA. Skupiony na dostarczaniu rozwiązań składowania i przetwarzania danych. Nie są mu obce wszelkiej maści bazy danych, systemy real time data i streamingu. Doradza, wdraża, projektuje jak efektywnie wykorzystywać technologie.

W tym odcinku o DataOps rozmawiamy w następujących kontekstach:

  • czym jest to pojęcie i kto je zdefiniował?
  • na czym polegają różnice w buzzwordach związanych z danymi?
  • jak obecnie wygląda sytuacja firm związana z przetwarzaniem danych?
  • czym jest DataOps Manifesto?
  • dla kogo podejście DataOps ma sens?
  • jakie są wady i zalety tego podejścia?
  • czym DataOps różni się od DevOps?
  • od czego należy zacząć wdrożenie podejścia DataOps?
  • jak wygląda spektrum narzędzi używanych w tym zakresie?
  • kim jest inżynier DataOps?
  • jak wygląda rynek pracy dla specjalistów z tego obszaru?
  • od czego powinna zacząć edukację osoba chcąca pracować w tym temacie?
  • czym jest i jakie tematy porusza meetup DataOps Polska?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, która wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner  (posłuchaj)

Transkrypcja podcastu

To jest 85. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o DataOps.

Przypominam, że w poprzednim odcinku rozmawiałem o Disaster Recovery Center.

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/85.

Jeśli jeszcze tego nie zrobiłeś, to wystaw ocenę lub recenzję podcastowi w aplikacji, w której tego słuchasz.

Chcę poszerzać horyzonty ludzi z branży IT i wierzę, że wywiady takie jak te, publikowane jako podcasty, będę to robił z sukcesem.

Już dzisiaj możesz mnie wesprzeć w tej misji zostając patronem na platformie Patronite. Wejdź na porozmawiajamyoit.pl/wspieram i sprawdź szczegóły. 

Jednocześnie bardzo dziękuję moim obecnym Patronom. 

Nazywam się Krzysztof Kempiński i życzę Ci miłego słuchania. 

Odpalamy!

 

Cześć! Mój dzisiejszy gość w swoim życiu był już architektem, DevOpsem, SysOpsem oraz administratorem baz danych. Skupiony na dostarczaniu rozwiązań składowania i przetwarzania danych. Nie są mu obce wszelkiej maści bazy danych, systemy Real Time Data, czy streamingu. Doradza, wdraża, projektuje jak efektywnie wykorzystać technologie. Jest jednym ze współzałożycieli spotkań Data Ops Polska. Mój dzisiejszy gość to Tomasz Gintowt. 

 

Cześć Tomku, miło mi gościć Cię w podcaście. 

 

Cześć Krzysztofie! Witam słuchaczy! Dziękuję za zaproszenie.

 

Przyjemność po mojej stronie!

Z Tomkiem będę dziś rozmawiał o zjawisku całkiem świeżym, które rośnie na popularności, ale jeszcze nie do końca jest może w pełni znane, mianowicie o podejściu DataOps. 

Tomku, na początku standardowe pytanie wprowadzające, czy słuchasz podcastów, jeśli tak to, jakich najczęściej?

 

Nie, niestety nie słucham podcastów. Przyznaję się szczerze do tego. Przyznaję się też do tego, że jest to dla mnie ogromne wyzwanie, ponieważ ja jestem wielkim fanem wystąpień na żywo i całkowicie nie onieśmiela mnie dwieście parę oczu – czy więcej, patrzących na mnie. Natomiast jestem bardzo onieśmielony w momencie, kiedy mówię do mikrofonu.

 

No tak, wiem, jak to jest. W tych czasach raczej ciężko jest właśnie móc występować gdzieś tam publicznie do tak licznego grona, ale potrafię też zrozumieć, że mikrofon potrafi przynajmniej tak samo onieśmielać, jak pełna sala. 

 

Przyznaje się też, że porównałem też Twoje podcasty, pierwszy i jeden z ostatnich. Kiedyś wrzuciłeś fajnego posta, w którym pisałeś właśnie o tym, że umiejętności rosną razem z praktyką i porównałem te dwa odcinki i wierzę, że mi też kiedyś się uda dojść do takiego poziomu. 

 

Dzięki, miło, że to zauważyłeś. To znaczy, że faktycznie jakiś progres jest. Dzięki wielkie!

Chciałbym Cię na początku zapytać o to, czym właściwie jest DataOps? Kto to pojęcie zdefiniował, kiedy takie pojęcie w ogóle powstało? Od kiedy możemy mówić, że DataOps jest sformalizowane i określone?

 

Tak naprawdę DataOps jest w miarę świeżym pojęciem. Pojawiła się ona w momencie, w którym następuje naturalna ewolucja w procesie inżynierii danych i w procesie obróbki danych. Pierwszy raz pojawia się takie określenie na bloku firmy IBM kilka lat temu, właśnie jako określenie przyszłościowej dziedziny, która będzie całościowo obejmować inżynierie danych i rozwiązywać problemy, albo starać się pomóc firmom, które pracują z danymi. Tak naprawdę takim wielkim prekursorem jest firma DataKitchen, które stworzyła zarówno manifest, pierwsze narzędzie, jak i też promuje to. Natomiast w ciągu kilku ostatnich lat, jest to kierunek szczególnie rozwijający się na zachodzie. W Polsce jeszcze może mało znany, chociaż dociera głównie ze względu na duże, międzynarodowe korporacje. U nas też już powoli zaczynamy iść w tym kierunku.

 

Od kilkunastu lat mamy do czynienia z różnymi passwordami związanymi z danymi w IT. Od ITL, Big Data, niedawno Data Science i po DataOps, jako świeżynka w tym gronie. Czy to jest według Ciebie kolejna ewolucja, czy inkarnacje dziedziny inżynierii związanej z obróbką danych? Na czym tutaj polegają różnice w tych różnych pojęciach? 

 

To jest coś, co bardzo mi się podoba w samym podejściu DataOps, ponieważ jest to naturalna ewolucja w podejściu. Na pewno większość z nas pamięta proces, kiedy jeszcze nie było DevOpsów i były zwykłe systemy, działy administratorów i operations, a później był ten krok w stronę DevOpsów. Mniej więcej to samo w tej chwili dzieje się w dziedzinie danych. Mieliśmy deweloperów, Big Data, ETLe i wszystko to, co związane z danymi. A teraz przechodzimy do takiego momentu, gdzie firmy bazujące na modelach DataDriven czy obrabiające duże ilości danych, chcą spiąć to w całość i ten proces usprawnić. Dzisiaj, nie ukrywajmy, panuje slogan, że dane są naszym nowym olejem –  Data is new oil – który napędza firmę. W związku z tym te dane będą wykorzystywane coraz głębiej, coraz więcej będziemy chcieli z nich wycisnąć, no i pytanie brzmi, już nie jak je gromadzić, tylko ile z nich można wyłuskać, co znaleźć, co można z tego sprzedać. Na tym dzisiaj bazuje model, w związku z tym DataOps jest taką naturalną ewolucją, kolejnym krokiem w inżynierii danych, w obróbce i będziemy się obracać w jak najlepszym wykorzystaniu i spójności, żeby ubrać ten cały proces w jeden przepływ danych i zapewnić mu ciągłość, wydajność i jak najwięcej wartości dla biznesu.

 

Dzisiaj, nie ukrywajmy, panuje slogan, że dane są naszym nowym olejem –  Data is new oil – który napędza firmę.

 

Rozumiem. Powiedziałeś, że firmy prowadzą dane, to jest nowe złoto, bogactwo, które sobie składują. Gdybyśmy spojrzeli na przeciętną firmę, to jak tam wygląda sytuacja z danymi? Jak daleko jesteśmy od ideału? Czego w przeciętnej firmie według Ciebie brakuje, z jakimi bolączkami się mierzy, jeśli chodzi o dane?

 

Tak naprawdę możemy odróżnić tutaj dwie sytuacje. DataOps nigdy nie mówi, samo w sobie, co powinniśmy zrobić. Wyznacza kierunek rozwoju i to, co powinniśmy robić, natomiast nie mówi dokładnie „To jest jedyna, słuszna droga”. Ze swojego doświadczenia widywałem dwa kierunki. Pierwszy jest taki, że firmy idą we własny dział, czyli firmy idą we własny dział, czyli budują narzędzia DataOps od podstaw sami. Jest to połączenie automatyzacji, testowania, CI/CD , wszystkich tych narzędzi, co spowoduje, że w firmie stworzymy sobie serwis, który będzie pomagał w obróbce danych. Drugi kierunek to są produkty Enterprise i platformy, gdzie możemy kupić gotową taką platformę. My wrzucając tam dane, dostaniemy dostęp do wszystkich narzędzi i czy będą przechowywane w chmurze, czy będą to prywatne serwerownie, to ciągle są to Enterprise’owe rozwiązania i kupujemy produkt, który ułatwi pracę naszej firmy. Tym samym pozwoli nam się skupić na tych najbardziej biznesowych aspektach, natomiast ta techniczna część zostanie pozostawiona komuś innemu, oczywiście za to będziemy musieli zapłacić. Jak daleko jesteśmy, to jest pytanie do każdej z firm. Trudno jest na nie odpowiedzieć jednoznacznie, natomiast jest bardzo dużo do poprawy i bardzo dużo miejsc, w których można to zoptymalizować i wycisnąć jeszcze więcej z tych danych, jeszcze szybciej, a to zmniejszy też swoje koszty. Nie ukrywajmy, że w chmurach głównie płacimy za przesył danych i za to ile ich wyślemy, ile odbierzemy. Tutaj przychodzi DataOps z takim rozwiązaniem i podpowiada gdzie szukać tych rozwiązań i na co zwrócić uwagę, żeby móc jeszcze więcej z tych danych wyciągnąć i zapłacić mniejszą cenę.

 

DataOps, to oczywiście określone technologie, narzędzia, które wykorzystujemy. O tym jeszcze będę chciał później porozmawiać, natomiast najpierw spójrzmy na DataOps, jako pewne przedłużenia, albo wykorzystanie założeń Agile, czyli od filozoficznego punktu widzenia. Przejawia się to między innymi w DataOps poprzez DataOps Manifesto, o którym powiedziałeś. Jest tam takich pięć podstawowych wartości dla DataSense, Zarządzania Danymi, Business Intelligence, czy Big Data. Powiesz, proszę, jakie to wartości są zawarte w tym Manifeście?

 

Tak naprawdę Data składa się z trzech głównych filarów. Jeden z nich jest właśnie podejście Agile. Kolejne, drugi z filarów to jest DevOps. Ostatni to Lean Manufacturing. To jest składowa wszystkich tych trzech. One są bardzo dobrze znane większości z nas. Z podejściem agile’owym spotyka się każdy z nas. Jakiś czas temu porównywałem sobie DataOps, manifest i agile’owy manifest. Tam tak naprawdę tych kilka punktów, czy kilkanaście, które zakładają, że skupiają się na rozwiązaniach, a nie na dokumentacji, dostarczaniu wartości, współpracy z klientem, one są tak naprawdę te same, mają nawet użyte te same słowa i zwroty. Natomiast w DataOps dokładamy jeszcze te dwa filary, DevOpsowy i Lean Manufacturing. Dlaczego Lean Manufacturing i dlaczego to jest takie ważne? Bo tak naprawdę każda firma zajmująca się danymi, jest bardzo podobna do fabryki. Tutaj twórcy też oparli ten pomysł o statystykę i badanie tego, testowanie, jak często, gdzie, ciągła kontrola jakości. Tutaj, te trzy najważniejsze filary, kiedy zbierzemy do siebie, otrzymamy taki zbiorowy proces DataOps. 

 

Ten Manifest można sobie przeczytać na stronie dataopsmanifesto.org. Tam też odsyłamy. 

Chciałbym Cię jeszcze zapytać, jak jesteśmy przy temacie Manifestu, tam jest wspomniane o zasadach, którymi się powinniśmy posługiwać przy obróbce danych. Czy jakieś najważniejsze zasady z tej listy mógłbyś przywołać?

 

Pierwszą, z takich najważniejszych przy obróbce danych, jest właśnie to badanie statystyczne. Badanie, kontrola jakości, tak to nazwijmy. Dlaczego kontrola jakości? Taki prosty przykład. Jeśli mamy aplikację, na której wypełniamy nasz formularz i wpisujemy adres, to my w DataOps powinniśmy sprawdzać, czy kod pocztowy jest poprawny, czy numer telefonu się zgadza. 

Z takich prostych przykładów, miałem ostatnio prywatną rozmowę z jednym z Data Scientist, który w aplikacji zajmującej się obróbka dużej ilości danych znalazł 38 tysięcy kobiet, które nie mają albo pierwszego imienia, albo ostatniego, albo adresów, a tak naprawdę wymogiem tej aplikacji jest, żeby wszystkie dane zostały podane. 

To jest prosty przykład, dlaczego warto i powinniśmy kierować się kontrolą jakości tych danych. Kolejną rzeczą jest ubranie całości procesu. Chcę przez to powiedzieć, że DataOps skupia się na przypływie danych. Chodzi o to, żeby minimalizować bariery pomiędzy różnymi elementami. W DataOps mamy różnych ludzi obok siebie, którzy pracują nad jednym przesyłem danych. 

Kogo tutaj widzimy? To jest współpraca pomiędzy ludźmi, których nazywamy Data Inżynierami, Data Scientist, Analitykami, DevOpsami. Tak naprawdę trzeba zebrać pracę tych ludzi i żeby ona działała jak dobrze naoliwiona sprawna maszyna. Fajnym kolejnym przykładem, odnoszącym się do metodyki Agile. W DataOps mówi się, że powinny być różne długości sprintów. 

Ludzie skupieni bardziej na DevOps, czyli dostarczający tę infrastrukturę, powinni mieć około dwutygodniowe sprinty. Data Scientist powinni już mieć krótsze sprinty, około dwóch tygodni do tygodnia. Najkrótsze powinny być dla ludzi, którzy są najbliżej biznesu, czyli Data Intelligence, ewentualnie analityków, tam sprinty powinny być nawet dzienne, żeby dostarczać tę wartość dla firmy w krótkich i szybkich odstępach czasu. 

Łatwo sobie wyobrazić sytuację, że przychodzi do nas Chief Officer, czy Data Officer i prosi nas o analizy, a my mówimy, że będą za dwa tygodnie. Za dwa tygodnie rynek będzie już dużo przed nami, dlatego, jeżeli mamy te dane, to sprinty na przykład dla analityków i Business Intelligence powinny być nawet jednodniowe, żeby na podstawie danych, które już mamy, szybko dostarczyć wartość, na której biznes może skorzystać, przygotować lepsze raporty, lepsze wyniki a tym samym podejmować lepsze decyzje na podstawie danych. 

 

Rozumiem. Schodząc na taki pragmatyczny punkt widzenia, dla kogo podejście DataOps ma sens? Jakie podmioty, w jakich sytuacjach mogą skorzystać z takiego podejścia?

 

Tak naprawdę każdy z nas. Każdy, kto pracuje z danymi. To jest to, co ja najbardziej lubię w podejściu DataOps, to, że każdy tak naprawdę może czerpać z tego tyle, ile potrzebuje. Nie ma tak podejścia „Wszystko albo nic”. Możemy wyjąć sobie mały kawałek i zaimplementować go w naszej firmie, a możemy wziąć, albo kupić nawet gotową platformę DataOps i po prostu z niej skorzystać. 

To jest moim zdaniem najfajniejsze w tej części, to co ja lubię, ta elastyczność. Ona pozwoli dostosować się do każdej organizacji, w której znajdziemy się i nie ukrywajmy, inaczej jest w firmie, w której jest dwóch, trzech inżynierów, którzy pracują nad całym procesem, a inaczej jest w korporacjach, w dużych firmach, gdzie tych osób jest kilkanaście, zespoły są duże i każdy z nich obsługuje inny kawałek przepływu danych. W każdym miejscu znajdziemy coś dla siebie. Osobiście zachęcam do przeczytania tego Manifestu i zapoznaniu się, bo jest naprawdę mnóstwo rzeczy, które możemy wykorzystać, które się sprawdzają. Jest mnóstwo przykładów, szczególnie dużych firm, które widzą w tym potencjał i opierają na tym swój biznes, na szybkości podejmowania tych decyzji.

 

Możemy wyjąć sobie mały kawałek i zaimplementować go w naszej firmie, a możemy wziąć, albo kupić nawet gotową platformę DataOps i po prostu z niej skorzystać.

 

Powiedziałeś, że praktycznie wszędzie, gdzie dane są jakąś wartością, podejście DataOps może dostarczać jakieś benefity. Chciałbym zadać Ci kilka pytań, związanych z tym, jak wdrożyć właśnie takie podejście. Rozpocznę może od pytania: Jakie są zalety i wady podejścia DevOps? Czy organizacja, która decyduje się na taki krok, czymś ryzykuje, czy to jest raczej kolejny zdroworozsądkowy krok w rozwoju? Czy musi być to strategiczna decyzja, ponieważ ciężko jest gdzieś tam wrócić do stanu poprzedniego?

 

DataOps musi wrócić do dwóch organizacji. Do małych i dużych. Na czym polega problem? DataOps jest tak obszernym tematem, że ciężko jest go zebrać i umieścić w głowie jednej osoby. Potrzebujemy ludzi z różnych zakresów. W samym DataOps i Manifeście są zawarte wskazówki, równie dla DevOpsów, Data Scientist, analityków, Business Intelligence, Data Management. Te obszary są tak rozbudowane, że ciężko byłoby je zmieścić w jednej głowie. Największym zagrożeniem i trudnością, są małe firmy, gdzie tych osób jest mało. Tutaj bym raczej zalecał wybranie pojedynczych aspektów i wdrażanie ich krok po kroku, żeby uzyskać efekt końcowy. Nie rzucanie się i jak to bardzo często bywa, na „Hurra” robienie czegoś, bo jest nowa metodologia, która rozwiąże wszystkie problemy. 

Nie, ona nie rozwiąże naszych problemów, ona może nam pomóc je rozwiązać, natomiast nie da się tego zrobić w jednym, szybkim kroku. Dużo łatwiej DataOps się wdraża w dużych organizacjach. Tutaj duży nacisk się kładzie na współpracę między działami. Są gotowe nawet całe skrypty albo przykładowe rozmowy, które bardzo mi się podobały i pomagały w uzmysłowieniu sobie, czym jest DataOps, czyli właśnie przykładowe rozmowy pomiędzy działami, wymiana informacji, oczywiście mówimy o działach DevOps, Data Inżynierów, którzy pozyskują te dane, a z drugiej mówimy Data Scientist, Analitykach i Business Intelligence, którzy te dane obrabiają i bazują na nich. Jestem człowiekiem, który jest blisko DevOpsów i tych danych, często mi się zdarza, że nie rozumiem, co jest w środku. 

Nie znamy tych danych i nie potrafię ich zwalidować i powiedzieć, czy one są dobre, czy złe. W takiej dużej organizacji DataOps pomoże usprawnić całość, zbudować zespoły, zresztą jednym z punktów DataOps Manifest mówi, że DataOps to jest gra zespołowa. Wszyscy gramy w jednej drużynie, pomagamy sobie, szukamy rozwiązań, zamiast prowadzić politykę obwiniania i bardziej, więcej koordynacji, wspólnych pomysłów, mniej obwiniania i spędzania czasu na roztrząsanie problemów. Interesuje nas szybki przepływ danych i zapewnienie wysokiej jakości.

 

Kiedy mówi się „DataOps”, to brzmi to niemal jak „DevOps”. Zresztą tutaj wiele razy, z Twoich ust, też padło słowo „DevOps”. Jakie są różnice w obydwu tych podejściach, czy też może jedno jest składową drugiego? Czy w DataOps również korzysta się z procesu dobrze znanego w DevOps jak CI/CD?

 

Dokładnie. Tak naprawdę one nie różnią się od siebie zarówno w wymowie, jak i słownictwie. Różnica jest taka, że DataOps jest dużo szerszym pojęciem. DevOps zawiera się w środku, jest jednym z filarów składowych, jednym z trzech. Najłatwiej to sobie uzmysłowić, jak zapytamy siebie, kto jest odbiorcą tych danych. 

W przypadku metodologii DevOps będą to inżynierowie, Software Engineerowie. My się skupiamy na produkcie, którym jest kod czy deployment w jakiejś aplikacji. To jest proces, który wspiera DevOps. Natomiast w DataOps wspieramy się na danych i dostarczamy efektu końcowego opartego na tych danych. My nie produkujemy aplikacji, którą będziemy w stanie sprzedać albo wykorzystać. W tym podejściu, gdy produkujemy dane, wytwarzamy je, obrabiamy, pozyskujemy, analizujemy i na końcu powstają z tego raportu albo ktoś z nich korzysta. Gdybyśmy najłatwiej mogli to wytłumaczyć, to z jednej strony przy DevOps mamy Software Engineerów i produkujemy aplikację, przy DataOps mamy Data Scientist, Business Intelligence i analityków, którzy potrzebują danych i my te dane im dostarczamy.

 

Rozumiem. Wdrożenie DevOps to proces, wymaga świadomej decyzji i zaplanowanych działań praktycznie od większej części organizacji. Czy podobnie jest w DataOps? Od czego trzeba zacząć, co uwzględnić podchodząc do założenia DataOps w takiej większej organizacji? Chodzi mi tutaj zarówno o analizę bieżącej sytuacji, jak i procesy, narzędzi, które należy wziąć pod uwagę.

 

Tak naprawdę trzeba zacząć od ludzi, bo to oni są największą wartością każdej firmy. Tak jak wspomniałem, jest to karkołomne wyzwanie dla jednej osoby, która podejmie się wdrożenia całości takiego procesu. Dzisiaj ceni się ludzi, którzy mają ogromny przekrój wiedzy. Zachęcam też do sprawdzenia, jest bardzo znany, albo coraz częściej ceniony amerykański, a właściwie angielskie słownictwo, które określa takich ludzi. Ich się określa jako „T-shaped people”. 

To jest od litery „T”, w której mamy kreskę pionową i poziomą. Pozioma kreska to zakres wiedzy. Od prawej strony do lewej jest ogromna. W przypadku człowieka z DataOps jest to przez deployment, przez Ansible, Puppeta, Chiefa, przez CI/CD gdzie będzie dron, gdzie będą Trello, gdzie będziemy mieli GitHuba i wszystkie inne rzeczy, które pomagają – Jenkinsa, później będziemy mieli Re-Streaming, gdzie jest Kafka, RabbitMQ, później będą bazy danych, z których będziemy pozyskiwać te dane. Badanie jakościowe i na koniec trzeba gdzieś to umieścić, żeby analitycy mogli odczytać treść. 

To ogromny przekrój. W związku z tym to jest karkołomne zadanie, natomiast osiągalne w przypadku dużych zespołów, albo kogoś, kto ma ogromną wiedzę. Wracając do naszej literki „T”, o której rozmawialiśmy, to ta kreska pionowa to jest ekspercka wiedza w jednej dziedzinie. 

Na przykład w moim przypadku są to najczęściej albo bazy danych, albo streaming, Kafka, RabbitMQ, Postgres, Elasticsearch. To są dziedziny, w których ja się specjalizuję. Tego też często oczekuję od ludzi, którzy zostają DevOpsami. Ogromnej, szerokie wiedzy, natomiast konkretnych kierunków, w których są ekspertami. 

 

 Tak naprawdę trzeba zacząć od ludzi, bo to oni są największą wartością każdej firmy.

 

Poruszmy temat od strony technologicznej, czyli narzędzi, jakie mamy dostępne. Wiem, że kilka przed chwilą wymieniłeś. Chcę Cię zapytać, jak obecnie wygląda to spektrum narzędzi, które DataOps ma w swoim arsenale do wykorzystania, jeśli chodzi o przetwarzanie danych?

 

Jest ich naprawdę całe mnóstwo. Mam nadzieję, że nikt się nie obrazi, jak wymienię tylko kilka. Są to raczej przedstawiciele konkretnej grupy. Na przykład na deploymencie, czy obróbce danych, możemy wykorzystywać Sparka, Pythona, Databricks. 

Jeżeli chodzi o deploymenta, to Kubernetes, Jenkinsa, wszystkiego rodzaju chmury, Gita. Jeżeli chodzi o rejestrację danych i konfigurację, to mamy Puppeta, Ansible, możemy też używać Aflow, czy znowu odpowiedników z chmur, chociażby z AWS, Chiefa . Później mamy testowanie i monitoring, gdzie mamy Slacka, Datadoga. Streaming, kolejna dziedzina, tutaj możemy używać Kafki, RabbitMQ, Pulsara. 

Przechowywanie danych, czy to będzie S3, czy Data lake, czy Google BigQuery. Integracja danych, tutaj znowu możemy użyć Aflow, Data Government, Calibre, Informatica. 

Na koniec analitykę, czyli Power BI, Tableau i jeszcze kilkanaście różnych innych. Jest tego naprawdę cały przekrój i ciężko to zmieścić w jednej głowie.

 

Wow! Zapytam Cię o tę głowę. Kim jest inżynier DataOps – jakbyś mógł powiedzieć ze swojego doświadczenia? Jakie wcześniejsze doświadczenia zawodowe ma na swoim koncie, bo to wiadomo, jeśli chodzi o takie dopiero powstające specjalizacje w IT, to zazwyczaj na początku po prostu przechodzą do tych specjalizacji ludzie, którzy mają wcześniejsze inne doświadczenia, inne specjalizacje. Jakie umiejętności trzeba mieć, żeby pracować na takim stanowisku? 

 

DataOps Inżynier, DataOps, to taki ktoś, kto zbiera już doświadczenie najlepiej w dziedzinie Big Data, baz danych, ETL, Hadoopa, Streamingu, Kafki. Powiedzmy, że to jest taki DevOps z zacięciem do danych. Ci ludzie lubią się najlepiej sprawdzać w takim środowisku. 

Co jest ważne, ale może być też przytłaczające, o czym trzeba pamiętać, jeżeli zdecydujemy się na taką ścieżkę, że będziemy znali bardzo dużo narzędzi, natomiast tylko z wybranych będziemy specjalistami. Bardzo chwali się tutaj podejście, w którym jesteśmy specjalistą w wybranej dziedzinie, natomiast ten zakres jest ogromny. Jeżeli szybko umiemy się uczyć i nie przeszkadza nam to, że będziemy zmieniać technologię, będziemy skakać albo szybko rozwiązywać problemy. To sławne podejście „I can do it”  tak naprawdę jest tutaj niesamowicie cenione.  

Tak jak wspomniałem, ciężko jest być specjalistą z każdej dziedziny. Trzeba zbudować całego Pulp Linea, który będzie analizował te dane, pobierał, przetwarzał i na końcu analizował. Jesteśmy skupieni na celu, którym są te dane, natomiast technologia jest tylko narzędziem. Odnajdą się ludzie, którzy stawiają cel ponad technologie i nie są skupieni na jednej, szybko się uczą, przyswajają. Może to być też niesamowita przygoda, bo nie można się tu nudzić. Nawet nie ma na to czasu, bo co chwile są nowe narzędzia, często w wersji 1.0, albo wersja 0, coś tam na produkcji są już używane, więc jest tego bardzo dużo, szybko się trzeba uczyć i szybko zdobywać wiedzę, natomiast potrafi dawać satysfakcję i przegląd przez rynek, przez całą infrastrukturą, zaczynając od chmur, kończąc na obróbce danych i składowaniu danych. Tacy ludzie na pewno się sprawdza. 

Ciężko będzie ludziom, którzy chciałaby mieć konkretną, jedną dziedzinę, w której czują się najlepiej i nie chcą znać innych, takich ewidentnych specjalistów, dla takich ludzi będzie to ciężkie. Trudno jest się przyznać do tego, że jesteśmy specjalistami we wszystkim. Zawsze się znajdzie lepszy od nas w danej dziedzinie. Jeżeli ktoś umie to zaakceptować, to może być to dla niego bardzo fajną przygodą i ciekawym doświadczeniem życiowym. 

 

Zachęcasz. Wiemy już wobec tego, kim jest Inżynier DataOps. Teraz może jak wygląda rynek pracy dla specjalistów z tego obszaru. Chodzi mi zarówno o ilość ofert, zwłaszcza w taki relatywnie świeżej specjalizacji, jak i o wynagrodzenie średnie, jakie występuje w ofertach.

 

Jakiś czas temu robiłem rozeznanie, szukałem, jak to wygląda w Polsce. Na LinkedInie jest około 20 ofert. To jest taka średnia w Polsce, w których występuje słowo „DataOps”. Tych ofert jest coraz więcej. 

Tak jak wspominałem na początku, najczęściej są to duże, zagraniczne firmy. W Polskich firmach, z polskim kapitałem jeszcze się to dopiero rodzi, musi to dotrzeć, natomiast już takie oferty się pojawiają. Na samym LinkedInie jest to w granicach 400-500 ofert w ciągu tygodnia, właśnie dla Inżynierów DataOps. Warto sprawdzić technologie, które są używane i one się w większości pokrywają z tym, co wspomniałem. Wymaga się dużego zakresu wiedzy, natomiast nie wymaga się bycia ekspertem we wszystkim. 

 

A średnie wynagrodzenie, to jest coś zbliżone do DevOpsów, programistów, mniej więcej ten pułap?

 

Tak, to jest mniej więcej ten sam pułap. Powiedziałbym nawet z lekkim plusem, ze względu na to, że tych ludzi jest mało na rynku. Jest to ciągle dziedzina rozwijająca się i mam też wrażenie, że bardzo duże wsparcie dla Data Scientist powoduje, że jest to jedna z lepiej wynagradzanych pozycji, ponieważ jesteśmy bardzo blisko danych, biznesu, i tych ludzi, których jeszcze jest nie dużo. Mówię o Data Scientist. Trzeba rozmawiać z nimi specyficznym językiem, ponieważ są to ludzie jednak skupieni na matematyce i bardzo naukowi ludzi, którzy wyszukują w danych i my musimy im te dane dostarczyć. 

 

Co poradziłbyś słuchaczowi, który powiedzmy, jakoś ma wrażenie, że odnajduje się w tej roli, że to jest coś, w czym mógłby się specjalizować, to od czego powinien zacząć swoją drogę zdobywania umiejętności? Jakie rzeczy poznać na początku, żeby mimo wszystko, z tego przesytu różnych technologii, umiejętności, dobrać te, które są kluczowe, zwłaszcza na początku?

 

Tak naprawdę to bym chyba doradził komuś, żeby skupił się na konkretnych filarach. Jeżeli ktoś zajmuje się Kubernetesem, to gdzieś musiał dotykać Dockera, musi też trochę znać ze strony DevOpsowej, natomiast czy będzie to Puppet, czy Ansible, czy Chief Top, nie ma już większego znaczenia. 

Bardziej chodzi o to, żeby potrafił zrozumieć, jak to działa, potrafił odkryć zalety i wady takiego konkretnego produktu i potrafił szybko się do niego wdrożyć, ponieważ one są wszystkie na pewnym poziomie podobne, rozwiązują te same problemy, tylko w trochę inny sposób. 

Tak samo z bazami danych, jest ogromny przekrój, natomiast kiedy zrozumiemy, jak działają relacyjne bazy danych, czym się różnią od NoSQL-owych i jak twórcy próbują rozwiązać matematyczne problemy, to rozwiązywanie jest bardzo proste. 

Jako przykład podam, jeżeli porównujemy bazy danych Postgresa, MySQL i Oracle’a, to tak naprawdę, kiedy zejdziemy bardzo nisko, na poziom czystej matematyki, to oni wszyscy próbują rozwiązać te same problemy. 

To samo dzieje się, jeżeli chodzi o streaming, czy jest to Kafka, czy jest to RabbitMQ, czy jest to na przykład Pulsar, to tutaj tez są trzy najważniejsze problemy, z którymi twórcy próbują sobie poradzić. Każdy to robi w inny sposób, jak dotrzemy do tych źródeł, najważniejszych podstaw, to tak naprawdę wszystko staje się prostsze i rozwiązania są inne. Natomiast sama technologia próbuje rozwiązać konkretny problem. Ma też ograniczenia w związku z tym.

 

Czy w tych czasach, kiedy obserwujemy taki znaczący wzrost ilości danych i rosnący apetyt firm EA na dane, to czy podejście DataOps ma szansę zrewolucjonizować IT? Ma szanse w istotny sposób przełożyć się na to, w jaki sposób będziemy zajmować się danymi w przyszłości?

 

Mam takie odczucie, że to już się dzieje. Może jeszcze tego tak nie widzimy, aczkolwiek bardzo często rozmawiając na forach, czy konferencjach, jeszcze przed koronawirusem, pytanie brzmi, nie jak składowali dane, tylko co z nich można uzyskać i jak można je obrobić i zrobić to szybko. 

Tak naprawdę DataOps mam wrażenie, że jest odpowiedzią na to pytanie. Jak to zrobić zapewniając odpowiednią jakość, jak to zrobić szybko i jak dostarczyć z tego największą wartość? Z tych danych gromadzimy już tera, więc jeżeli wyobrazimy sobie proces, gdzie ktoś ma terową bazę i nagle próbuje zrobić terową bazę na Stagingu, czy do testowania, mija się to z celem. 

W DataOps rozróżnia się Pulp Liney, gdzie mamy produkcyjny, ale korzystamy z tych samych danych do testowania. Troszkę idziemy w kierunku, że wiemy, że tych danych jest dużo, teraz starajmy się coś z tym zrobić, żebyśmy wyciągnęli z tego jak najwięcej i nie wysyłali ich co chwilę i nie obrabiali, tylko wyciągali w konkretnych krokach dokładne dane i sprawdzali, weryfikowali za każdym razem, czy jest to poprawne, czy cały link został zaczerpnięty z Toyoty, więc wzór do naśladowania, jeśli chodzi o jakość wykonania. Taki jest właśnie cel.

 

Ok. Na początku powiedziałem, że jesteś jednym ze współorganizatorów meetupu DataOps Polska. Powiedz, proszę, parę słów o tym wydarzeniu, jakie tematy poruszacie, do kogo jest to wydarzenie adresowane? Przede wszystkim też, czy teraz się odbywa, w czasie pandemii?

 

Tak, odbywa się. Sam DataOps powstał właśnie w czasie pandemii. Wspólnie z Konradem Szatan, pewnego dnia rozmawialiśmy o tym i żaden z nas nie potrafił się odnaleźć w tym, co robimy. Wcześniej prowadziłem meetupy, były to kafkowe, ewentualnie elasticsearchowe. Natomiast ciągle to były konkretne technologie. Jestem bardziej DevOpsem, Konrad jest bardziej Developerem, obracamy się w podobnych kręgach i pracujemy razem, więc szukaliśmy pomysłu na to, co możemy zrobić, jak nazwać to, co robimy. Tak naprawdę przebyliśmy drogę, w której jak nazwiemy siebie, tym co robimy i jak to określimy i w pewnym momencie znaleźliśmy właśnie DataOps. Jak zaczęliśmy się w to wgłębiać, to okazało się, że każdy z nas gdzieś do tego pasuje i to, co robimy, jest częścią naszej pracy i chcielibyśmy się w tym kierunku rozwijać. Postanowiliśmy, że stworzymy spotkania. To są spotkania wirtualne. Generalnie przez ostatnie pół roku co dwa tygodnie spotykamy się, zapraszamy. W założeniu nasz meetup miał być meetupem polskim, natomiast z kilkunastu prezentacji, które mieliśmy, tylko dwa, czy trzy były polskie. Okazało się, że w Polsce jest ciężko znaleźć takich ludzi, natomiast jest bardzo dużo chętnych ludzi zza granicy, którzy chcą się dowiedzieć. Mało tego, że chcą z jednej strony prezentować, z drugiej strony jest bardzo dużo słuchaczy. W tej chwili jest nas tam pięćset trzydzieści pare osób i to bardzo szybko rośnie z każdym meetupem. Na ostatnie trzy, czy cztery, zapisało się miedzy sto a sto trzydzieści osób, więc naprawdę ta społeczność rośnie.

 

W założeniu nasz meetup miał być meetupem polskim, natomiast z kilkunastu prezentacji, które mieliśmy, tylko dwa, czy trzy były polskie. Okazało się, że w Polsce jest ciężko znaleźć takich ludzi, natomiast jest bardzo dużo chętnych ludzi zza granicy, którzy chcą się dowiedzieć.

 

Super!

 

Mamy dużo pytań. Tematy, o których rozmawiamy, są bezpośrednio związane właśnie z DataOps. Mieliśmy kilka prezentacji o bazach danych, na przykład grafowych bazach danych, o Kafce, o Streamingu, były o Elasticsearchu, o platformie DPSowej, która dostarcza jako DataOps. Mieliśmy meetup o bezpieczeństwie danych, jak o nie dbać w naszych Pulp Lineach. Tak naprawdę każdy z nich jest gdzieś tam w tej okolicy danych, czy to na przykład był Pulsar, czy ostatnio rozmawialiśmy o analizach danych. Naprawdę tematów jest dużo, jest dużo chętnych. To, co ja najbardziej lubię i na czym byłem najbardziej zaskoczony, to są dyskusje po. Ponieważ zazwyczaj prezentacja trwa około godziny, a później pół godziny jest mnóstwo pytań, ludzie chcą się dowiedzieć, chcą wymienić swoje doświadczenia, my też to umożliwiamy. Przyjęliśmy taki schemat, gdzie, jeżeli ktoś może, to wypowiada się i słyszymy go, rozmawiamy z nim, jest bardziej interaktywny. Jeżeli ktoś nie może, to pisze. 

Mam wrażenie, że koronawirus nam trochę w tym pomógł, ponieważ był taki moment, gdzie ludzie chcieli jednak tego kontaktu, wymiany wiedzy, a też, gdybyśmy próbowali go organizować w Warszawie, byłoby nam to ciężko zrobić, to się okazało, że prawie 30% naszych uczestników jest spoza Polski. Jest to naprawdę przegląd z całego świata. Ludzie z Londynu, Indii, San Paolo, Seulu. Według mnie są to właśnie rejony, w których trwa dzień, albo wczesny poranek i Ci ludzie dołączają do nas. W Polsce jest to wieczór, bo zazwyczaj spotykamy się po godzinie osiemnastej i ludzie na koniec pracy, albo będąc w domu, nas słuchają i dyskutują. 

 

Fajnie. Wobec tego zapraszam na meetup DataOps Polska. Link oczywiście będzie w notatce do odcinka. Tomku, ja Ci bardzo dziękuję. Bardzo fajna rozmowa. Dzięki, że pokazałeś, czym jest to podejście DataOps i myślę, że coraz częściej będziemy o nim słyszeć. Cieszę się, że mieliśmy okazję o tym porozmawiać. Na koniec proszę, powiedz, gdzie Cię można znaleźć w internecie? Jak się z Tobą skontaktować?

 

Takim głównym źródłem kontaktu dla mnie jest LinkedIn. Zapraszam też na swojego bloga na stronie medium.com. Z tego, co pamiętam, będzie to w linkach. Można mnie spotkać również na różnego rodzaju meetupach. Przede wszystkim odpowiadam za DataOps Polskę, w której wspólnie z Konradem wymyślamy nowe tematy, natomiast często też sam prowadzę prezentacje. 

Najczęściej jest to Elasticsearch, ewentualnie Kafka i to są dwa miejsca, w których najczęściej można mnie spotkać, odpowiadam na pytania, albo biorę udział w organizacji takich eventów, promując te technologie skierowane zarówno do ludzi, którzy dopiero zaczynają, jak i tych zaawansowanych użytkowników.

 

Świetnie. Zatem odsyłamy do linków w notatce do odcinka. Z mojej strony jeszcze raz bardzo dziękuję Tomku! 

Do usłyszenia, cześć!

 

Dzięki wielkie!

To na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. DataOps to podejście do danych, które z pewnością będzie coraz popularniejsze, więc warto się z nim zaznajomić, nawet jeśli nie będziesz pracował na stanowisku Data Inżyniera.

Jeśli doceniasz to, co robię, wesprzyj mnie na Patronite. To taka platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Mój profil znajdziesz pod adresem porozmawiajmyoit.pl/wspieram

Link również w notatce do tego odcinka. 

Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. 

Jeśli spodobał Ci się ten odcinek i nie chcesz przegapić kolejnych epizodów podcastu, zasubskrybuj go w swojej aplikacji podcastowej. 

Jeśli nie wiesz jak to zrobić, wejdź na stronę porozmawiajmyoit.pl/subskrybuj

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o DataOps.

Zapraszam do kolejnego odcinka już za tydzień.

Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
Tags:
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.