DataOps

Krzysztof Kempiński
Oct 6 · 11 min read
Image for post
Image for post

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Tomaszem Gintowt o DataOps.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

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.

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.

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.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-085-dataops/

kkempin’s dev blog

Dev and life blog.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store