POIT #110: Wykorzystanie danych dzięki chmurze

Witam w sto dziesiątym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest wykorzystanie danych dzięki chmurze.

Dziś moim gościem jest Marek Glijer – Cloud Architect w Chmurze Krajowej. Osoba z wieloletnim doświadczeniem w wytwarzaniu oprogramowania, przetwarzaniu danych Big Data, inżynierii danych, rozproszonych środowisk obliczeniowych, R&D.

W tym odcinku o wykorzystaniu danych dzięki chmurze rozmawiamy w następujących kontekstach:

  • jaką rolę w zbieraniu i obróbce danych sprawuje obecnie chmura obliczeniowa?
  • co Google Cloud Platform może zaoferować firmom, które już są „data-driven”?
  • jaka jest rola Operatora Chmury Krajowej w tworzeniu nowego regionu GCP Warszawa?
  • co statystycznej polskiej firmie daje fakt, że lada chwila udostępniony zostanie nowy region Google Cloud – Warszawa?
  • czy ma sens by firmy migrowały się z innych regionów GCP do Warszawy?
  • jakie kluczowe usługi Google Cloud Platform będą obsługiwane?
  • jakie największe bolączki z przetwarzaniem danych można spotkać w firmach?
  • jakie komponenty Google Cloud w obszarze danych są obecnie dostępne?
  • jakie możliwości stwarza polski region dla programistów, inżynierów, architektów?
  • jak działa BigQuery?
  • czym jest Data Pipeline?
  • jak chmura może wspomóc tworzenie podejścia bazującego na ETL?
  • czym są i jak działają data lakes?
  • czy chmura publiczna jest miejscem, gdzie możemy czuć się bezpiecznie ze swoimi poufnymi danymi?
  • jakie trendy związane z danymi i chmurą obliczeniową będą się rozwijały?

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óre 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 110. odcinek podcastu Porozmawiajmy o IT, w którym to wraz z moim gościem rozmawiam o wykorzystaniu danych dzięki chmurze.

Przypominam, że w poprzednim odcinku rozmawiałem o tym, kim jest senior developer. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/110

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. 

Nazywam się Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest m.in. ten podcast. Zostając patronem na platformie Patronite, możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły! 

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

Teraz życzę Ci miłego słuchania. Odpalam! 

 

Cześć! Mój dzisiejszy gość to cloud architect w Chmurze Krajowej, osoba z wieloletnim doświadczeniem w wytwarzaniu oprogramowania, przetwarzaniu danych big data, inżynier danych rozproszonych środowisk obliczeniowych R&D.

Moim i Waszym gościem jest dzisiaj Marek Glijer. Cześć, Marku! Bardzo miło mi gościć cię w podcaście.

 

Cześć! Bardzo mi miło, dziękuję za zaproszenie.

 

Ostatnio bardzo dużo mówi i dzieje się w obszarze chmury obliczeniowej, dzisiaj z Markiem będę chciał porozmawiać o tym, jak wykorzystać dane, które bardzo często firmy już posiadają, dzięki właśnie chmurze obliczeniowej, jakie mechanizmy, jakie narzędzia mamy dostępne.

Zawsze na początku pytam mojego gościa i Marku, do Ciebie też kieruję takie pytanie. Czy słuchasz podcastów i jeśli tak, to może masz jakieś swoje ulubione audycje?

 

Tak, czasami słucham. Nie będę specjalnie odkrywczy, jeśli chodzi o polską scenę podcasterów. Jeśli wymienię Imponderabilia czy Dwóch typów, natomiast z takich zagranicznych to bardzo lubię sobie uruchamiać The Science Hour produkcji BBC. Lekki podcast o nauce, o odkryciach. Z takich bardziej chmurowych mógłbym jeszcze wyróżnić The Cloudcast, czyli takie niezbyt techniczne, ale całkiem miłe pogawędki na temat środowisk chmurowych.

 

Super! Dziękuję za te rekomendacje. Pewnie zgodzisz się ze mną, że obecnie jak mówimy o chmurze, to mamy na myśli bardzo wiele różnych pojęć, usług, zjawisk technologii. Mam wrażenie, że to pojęcie jest bardzo pojemne. Być może każdy z nas ma trochę inne patrzenie na to, czym naprawdę chmura jest. Natomiast chciałbym cię zapytać, z twojego punktu widzenia co jest najważniejsze w chmurze? Jakie obszary chmury są najważniejsze, kiedy mówimy właśnie o danych? O przetwarzaniu, zbieraniu, składowanie, czyli całym tym procesie, który bardzo często ma właśnie miejsce z wykorzystaniem usług chmurowych.

 

Na pewno można tu powiedzieć, że autoskalowanie jest dla nas bardzo kluczowe, jeśli chodzi o dane, bo danych mamy coraz więcej z różnych systemów i mówi się, że im więcej, tym lepiej, ale co za tym idzie, to naturalnie rodzi to szereg wyzwań pod spodem.

Kolejnym ważnym czynnikiem, którym można byłoby podnieść przy tej okazji, jest niemal w wykładniczym tempie rosnąca liczba usług mocno, wysoko poziomowych, wyspecjalizowanych, które służą do analityki danych. To już nie tylko zwykłe bazy danych czy kolejki as a service, ale też zaawansowane kombajny odpowiadające na konkretne rodzaje problemów. Jest też cała sekcja związanych z tym środowisk, które często są w on premise już nieopłacalnym wyzwaniem, ponieważ odpowiadają na zbyt wąską potrzebę i nikomu nie chciałoby się utrzymywać bardzo dużego systemu tylko po to, żeby o 5% czy 15% zwiększyć jakiś wskaźnik w swoich biznesowych celach.

 

Kolejnym ważnym czynnikiem, którym można byłoby podnieść przy tej okazji, jest niemal w wykładniczym tempie rosnąca liczba usług mocno, wysoko poziomowych, wyspecjalizowanych, które służą do analityki danych. To już nie tylko zwykłe bazy danych czy kolejki as a service, ale też zaawansowane kombajny odpowiadające na konkretne rodzaje problemów.

 

Oczywiście nie może byłoby tutaj nie wspomnieć o sztucznej inteligencji, gdzie w Google Cloud, chociażby mamy szereg serwisów na różnym poziomie abstrakcji odpowiadających na te potrzeby i podniósłbym jeszcze security, które jest domyślnie na dość wysokim poziomie w chmurach publicznych, więc myślę, że na tym pewnie możemy zakończyć, natomiast o security warto byłoby kiedyś porozmawiać, bo to bardzo ciekawy i szeroki, jeśli chodzi o chmury publiczne, czasami kontrowersyjny w niektórych środowiskach, także na pewno jest to wdzięczny temat do dyskusji!

 

Tak! I coraz więcej się o nim słyszy.

Poruszamy się tutaj w obszarze danych. Jeśli mówimy o danych, to jest to oczywiście proces zbierania, proces obróbki, składowania. Jaką rolę w tym procesie odgrywa chmura publiczna? Interesuje mnie to, na ile takie rozwiązania chmurowe są w stanie przyspieszyć, uprościć cały ten proces? W efekcie ciągnąć tę transformację cyfrową i wykorzystanie danych, które firmy bardzo często mają, a z których nie do końca potrafią skorzystać.

 

Głównie tutaj moglibyśmy podnieść time to market, jako taka główna rola w procesie przyspieszania czy główna rola odgrywana przez środowiska chmurowe w dzisiejszym świecie, bo nagle budzimy się w takim „candy landzie” i możemy sobie zacząć zastanawiać się, z czego sobie skorzystamy po prostu.

Wiele tych rozwiązań też można prototypować w ciągu dosłownie minut, -nastu minut czy kilku godzin, można zbudować jakiś kawałek rozwiązania, który popiera lub obala pewną ukutą wcześniej sobie hipotezę.

Warto to pewnie podnieść, jako taki główny wyznacznik jak to wygląda w tym procesie.

 

Poruszyłeś temat przyspieszenia, bardzo istotny w dzisiejszym biznesie, żeby jak najszybciej dostarczyć tę produkt, tę usługę, być może wyprzedzić konkurencję, być po prostu szybszym w tym bardzo konkurencyjnym rynku. Natomiast interesuje mnie też uproszczenie, które wprowadza chmura, jeśli chodzi o dane. Czy tutaj możesz porównać na przykład takie standardowe środowiska w on premie, w stosunku do chmury i czy te rozwiązania chmurowe upraszczają proces obróbki zbierania danych według Ciebie?

 

Tak! Myślę, że zdecydowanie tak. Na kilku, co najmniej kilku płaszczyznach. Po pierwsze, na płaszczyźnie uruchamiania tych usług i konfiguracji, ponieważ ten proces w chmurach publicznych jest okrojony do niezbędnego minimum i niektóre produkty są po prostu uruchomione i skonfigurowane, więc wystarczy tylko sobie wejść i z nich skorzystać, z gotowych, dobrze zoptymalizowanych pod konkretne rozwiązania komponentów, a kolejnym zagadnieniem, jakie warto podnieść, to ta integracja mocno wbudowana w chmury publiczne, która jest podstawą działania tych komponentów. To znaczy – ich siła nie tkwi w tym, że one są stand alone gdzieś tam powołane i można z nich przyjść i skorzystać, tylko że tych komponentów jest nagle dosłownie setki, więc możemy z nich układać różne, ciekawe rzeczy.

Jeśli chcemy powołać klaster Hadoopowy w chmurze publicznej, konkretnie w Google Cloud, chociażby, no to główną pracą, jaką będziemy musieli wykonać, to poczekanie na powołanie klastra i oczywiście mamy dostęp do zaawansowanej konfiguracji tego klastra, natomiast jeśli chcemy sobie powołać klaster do zabawy na chwilę, to możemy to robić. I to jest taka główna filozofia tworzenia środowisk cloudowych – te środowiska tworzone są kodem, a nie klikaniem, dzięki temu developerzy mogą uruchamiać całe stacki technologiczne, na które nikogo nie byłoby w on premie stać, albo które byłoby bardzo ciężkie do skonfigurowania właśnie.

 

Powiedzieliśmy chwilkę o transformacji cyfrowej. Wyobrażam sobie, że dla tych firm, które dopiero rozpoczęły tę transformację, takie rozwiązania chmurowe, chociażby udostępnione przez Google Cloud to jest jak gdyby oczywista droga Łatwo jest uargumentować, że chmura może być dobrą drogą do wykonania właśnie kroków w stronę transformacji cyfrowej. Ale wyobraźmy sobie taką sytuację, że jest już firma, która opiera się na danych – jest data driven, korzysta z nowoczesnych rozwiązań technologicznych.

Czy Google Cloud Platform za waszym pośrednictwem czy Chmury Krajowej może zaoferować coś atrakcyjnego takiemu klientowi? Czy ten klient również może wykorzystać chmurę, rozważyć to, jeśli już jest jakoś zaawansowany technologicznie?

 

Mamy klientów o bardzo zróżnicowanym poziomie technologicznym i to bardzo zależy od tego, jakie problemy chcesz rozwiązać, ale co do zasady – chmura publiczna jest tak naprawdę rozwiązaniem dla każdego. Jeśli nawet nie masz wszystkich swoich systemów w cloudzie, to możesz mieć ich jakiś subset, jakąś część, jakiś podzbiór tych systemów. Możesz czy nawet w wielu przypadkach jest to uzasadnione, jak pokazują badania, więc myślę, że tak. Jeśli chodzi o organizację data driven, która jest zaawansowana technologicznie, bo takich klientów również Chmura Krajowa ma, no to naturalnie jest to bardzo wygodna współpraca, ponieważ klient jest super doedukowany, wie dokładnie, czego chce, ma bardzo kompetentny zespół technologiczny po swojej stronie i nasza rola to zaczęcie od środka, a nie od początku, takiego całego procesu, ponieważ nie musimy edukować tego klienta jakoś specjalnie, jeśli chodzi o to, że jego aplikacja w modelu skategoryzowanym będzie bardziej cloud-native, będzie bardziej przystępna dla środowisk chmurowych i odwrotnie.

Tylko ten klient już to wie – wie, po co ma w swoim stacku technologicznym pewne rozwiązania i szuka konkretnych rozwiązań konkretnych problemów. Możemy mu bardzo precyzyjnie zaproponować architekturę, która spełnia jego oczekiwania w stu procentach i będzie gotowa na jego plan rozwoju na najbliższe lata.

W przypadku klientów, którzy mają bardziej archaiczne systemy, to droga jest troszeczkę dłuższa, bardziej kręta, przede wszystkim wymaga więcej zaangażowania od strony samego klienta, ponieważ jego zespół też powinien przejść tę drogę, tę transformację też w głowie, bo nie jest sztuką przenieść tych wszystkich ludzi z tymi systemami do chmury, zoptymalizować to i zostawić, tylko my zajmujemy się tym, żeby ten klient był naprawdę zadowolony, naprawdę przekonany do tego wszystkiego, widział w tym sens i żebyśmy wspólnie wypracowali optymalną ścieżkę od chmury. 

 

Dotknąłeś bardzo ważnego tematu, bo firmy, które dostarczają rozwiązania technologiczne związane z chmurą mają jedną, dodatkową, bardzo ważną rolę, pt. edukowanie rynku czy też uświadamianie firm, przedsiębiorstw, że wiemy, że adopcja chmury w Polsce czy jej zastosowanie odstaje od Zachodu, Stanów – ciężko to porównać i stąd taka ewangelizacja, która przez te nasze polskie firmy związane technologicznie z chmurą jest prowadzona, jest bardzo potrzebna w tym temacie. 

I z tego co słyszę w ramach Chmury Krajowej taką misję też realizujecie! 

 

Tak, to było nasze główne pryncypium powstania, kiedy uruchamiano spółkę. Operator Chmury Krajowej to było główne założenie, że będziemy tutaj motorem w tym zakresie, ponieważ nie jest tajemnicą, że istnieje bardzo silna korelacja między innowacyjnością technologiczną a poziomem rozwoju gospodarczego i rozwiązania chmurowe bardzo silnie korelują z tymi parametrami. 

Jak zaczynaliśmy, to Polska była na absolutnie szarym końcu, jeśli chodzi o adopcję rozwiązań chmurowych w naszej części świata. 

 

Powiedzieliśmy kilka razy o Chmurze Krajowej, o Google Cloud Platform. Te dwa podmioty w jakiś sposób się łączą. 

W postaci nowego regionu – regionu Warszawa, który powstał przy współpracy Chmury Krajowej i firmy Google. 

Jaka była rola operatora Chmury Krajowej, jak ta współpraca wyglądała, jeśli możesz zdradzić jakieś rzeczy?

 

Przede wszystkim nasza pozycja to pozycja edukatora klientów. Zajmujemy się sprzedażą, konsultingiem, planujemy całe procesy migracyjne, optymalizujemy kosztowo różne rzeczy, które są albo u istniejących klientów chmurowych albo u nowych klientów, u których migrujemy lub zmigrowali oni niedawno, a teraz chcieliby przyjść do nas po taki przegląd, może trochę audyt, trochę takiego doradztwa, bo my świadczymy również usługi tego typu. 

Co jest istotne –  nie patrzymy tylko na to wszystko przez szybę, tylko bardzo często mamy takie projekty, które od zera do bohatera przeprowadzamy przez cały proces naszego klienta i na różnym poziomie zaawansowania również nasi inżynierowie, hands on, czy ja czy to szereg moich koleżanek i kolegów, codziennie programujemy z klientem, czy tam dla klienta, także – pomagamy w tym procesie na każdym praktycznie poziomie, na którym jesteśmy w stanie. Staramy się znormalizować, wypłaszczyć tę krzywą, próg wejścia, który jest dla środowisk chmurowych, bo też warto wspomnieć o tym, że kiedy rozmawiamy sobie o chmurze, to musimy mieć na uwadze, że to jest bardzo dynamiczne środowisko, które warto znać w stopniu co najmniej średniozaawansowanym, jeśli nie więcej, jeśli do niego przychodzimy. Co za tym idzie – pewnie warto dobrać sobie partnera, który będzie mógł taką migrację, chociażby dojrzeć. 

 

Staramy się znormalizować, wypłaszczyć tę krzywą, próg wejścia, który jest dla środowisk chmurowych, bo też warto wspomnieć o tym, że kiedy rozmawiamy sobie o chmurze, to musimy mieć na uwadze, że to jest bardzo dynamiczne środowisko, które warto znać w stopniu co najmniej średniozaawansowanym, jeśli nie więcej, jeśli do niego przychodzimy. Co za tym idzie – pewnie warto dobrać sobie partnera, który będzie taką migrację, chociażby dojrzeć. 

 

Właśnie! Jestem też bardzo ciekawy, myślę, że słuchaczy również to zaciekawi – jak się współpracuje z taką dużą firmą technologiczną? Czy to jest partnerski układ czy może trzeba się dostosować do tych wymogów? 

 

Tak, jest to bardzo partnerska współpraca, absolutnie. Zakładamy, że sukces drugiej strony, jeśli mówimy o nas i o Google, sukces tego drugiego wpływa na sukces tego pierwszego, więc nie ma czegoś takiego, że my sobie jakoś pod spodem czy tam się nie lubimy, czy jakkolwiek trzymamy tylko swoje interesy w garści i absolutnie nie myślimy sobie tutaj o wspólnym dobru. 

Myślę, że jest absolutnie odwrotnie, z personelem googlowym współpracuje się bardzo dobrze. Kuchnia takiej współpracy wygląda w ten sposób, że jeśli jest jakiś kłopot, jest jakiś problem i musimy sobie porozmawiać z Google na pewien temat techniczny, to organizujemy sobie albo tekstowy, albo głosowo-wizyjny kanał komunikacji z odpowiednimi, bardzo kompetentnymi osobami, niekiedy inżynierami produkującymi dane rozwiązanie, którzy są na pierwszej linii, jeśli chodzi o taką merytorykę. Jak działa coś pod spodem, jak coś zostało zoptymalizowane albo mamy tutaj taki edge case, który nigdy wcześniej nie powstał, bo nigdy wcześniej nie mieliśmy na przykład takiego specyficznego rodzaju ruchu na tym silniku bazodanowych czy innym i chcielibyśmy się spytać, czy to, co robimy, czy oni mają jakąś lepszą rekomendację albo czasami też bywa, że zgłaszamy sobie jakieś support case’y, więc – bardzo partnersko!

A jeśli chodzi o taką sprzedażową i frontem do klienta stronę naszej współpracy, no to bardzo często występujemy razem z pracownikami Google na spotkaniach z klientami, po prostu. Czy to spotkań sprzedażowych, w których ja akurat nie uczestniczę zbyt często ze względu na to, że mam zupełnie inne kompetencje, albo tych bardziej technicznych, warsztatowych to tak też bywa. 

 

Nagrywamy tę rozmowę pod koniec marca 2021, za chwilę zostanie udostępniony ten nowy region Google Cloud, o którym rozmawiamy, region Warszawa. I o ile jest to bardzo duże docenienie Polski jako kraju, o tyle zastanawiam się, co takiej statystycznej, polskiej firmie daje właśnie fakt, że za chwilę taki region będzie u nas dostępny. 

 

Mamy tutaj kilka aspektów tej sytuacji, w której będziemy się zaraz znajdować. 

Po pierwsze, jest to rezydencja danych w Polsce, która jest dość oczywista, bo wiadomo, że nie każda organizacja jest gotowa na to i powinna wysyłać dane poza kraj, w którym działa, więc ta rezydencja danych w Polsce – te gwarancje są bardzo ważne dla wszystkich, dla większości przedsiębiorstw. 

Następnie możemy powiedzieć o niskich latencjach do infrastruktury googlowej, bo nie jest tajemnicą, że im bliżej będziemy mieć Data Center Google’a, tym będziemy mogli uruchamiać usługi, które są bardziej wymagające. Oczywiście – jeśli mamy sobie, nie umniejszając skomplikowaniu technologicznemu, jakiś tam projekt aplikacji webowej, to ona nie do końca wymaga, aby działać z 15-20 milisekundową prędkością odpowiedzi na ICMP, tylko to mogą być i 40-60 milisekund i to nikogo nie będzie specjalnie obchodziło, no to wówczas taka aplikacja – nie jest to dla niej jakieś niesamowite osiągnięcie. Natomiast jest szereg usług, możemy sobie wyobrazić systemy IoT, systemy analizujące dane z jakichś bardzo zaawansowanych sensorów odpowiadających za bezpieczeństwo czy inne i wówczas te niskie latencję, czy systemy finansowe, które muszą spełniać jakieś kryteria niskich latencji, które to wówczas można będzie uruchamiać sobie właśnie w warszawskim regionie. 

Chciałem podnieść tutaj temat, bo pomyślałem sobie o tym, że to nie tylko polskie firmy są beneficjentami tego, ponieważ inne również – w całym naszym regionie, bo pamiętajmy, że to jest 9 region w Europie, ale pierwszy w Europie Środkowo-Wschodniej. Otwierają się szerokie pola dla naszych najbliższych sąsiadów, którzy również na pewno z wypiekami na twarzy czekają na moment 14 kwietnia 2021.

 

Rozmawiając z osobą, która zna to przedsięwzięcie od kuchni, nie mogę nie zapytać o to, czy ten region w twojej opinii będzie takim pełnoprawnym regionem? Czy możemy poznać jakąś lokalizację Data Center, może jakieś szczegóły, które jesteś w stanie powiedzieć?

 

Co do zasady to Google nie buduje regionów drugiej kategorii, tylko kiedy jest jakiś region ogłoszony na mapie globalnej, jest globalnie dostępny, to również jest on pełnoprawnym regionem, który może normalnie – w którym można uruchamiać te same lub podobne usługi jak w innych regionach na całym świecie. Oczywiście nie jest tak, że te regiony między sobą się zupełnie niczym nie różnią, ale tak samo różnią się w Europie Zachodniej, tak samo na terenie obu Ameryk i tak samo będzie się różnił nasz od tamtych regionów. To znaczy – to nie będzie różnica jakościowa, tylko ewentualnie będziemy mogli mieć o jedną usługę więcej czy o jedną usługę mniej, ponieważ nie wszystkie usługi są dostępne po prostu we wszystkich regionach. Ale to będą jedyne różnice, więc absolutnie nie mamy tutaj mowy o jakimś regionie, który jest ubogi. Powiedziałbym nawet, że przeciwnie. Będzie on złożony z trzech zon – zazwyczaj zona to Data center, ale nie zawsze tak jest. Lokalizacje tych Data Center nie są podane do publicznej wiadomości ze względów bezpieczeństwa, ale mogę powiedzieć, że nie były to inwestycje w budowę Data Center od fundamentów i tyle! Więcej nie mogę powiedzieć. 

 

Dobrze, to już cię więcej nie ciągnę za język! Powiedziałeś, że za chwilę polskie firmy będą miały dostęp do Data Center, które jest w naszym kraju, co może mieć duże znaczenie, jeśli chodzi o przechowywanie, przetwarzanie danych, ale też tę niską latencję. 

Może powstać takie pytanie – czy jeśli już jakaś organizacja, jakaś firma posiada swoją infrastrukturę Google Cloud, chociażby we Frankfurcie, który stosunkowo często jest przez polskie firmy wybierany, to czy w Twojej opinii ma sens to, żeby taka firma dokonywała migracji na region Warszawa?

 

To jest dobre pytanie, dość kontrowersyjne, bo tak naprawdę nie ma jednej odpowiedzi i to zależy od tego, czy ta rezydencja lub latencje są dla ciebie ważniejsze, dla twojego biznesu i będą w skali najbliższego roku czy dwóch ważniejsze od czasu, który poświęcisz na migrację. Migracja między regionami jest dość prosta i w większości usług nie powinna zająć niesamowitych ilości godzin roboczych, bo będziemy ten czas raczej liczyć w godzinach, nie uważałbym tutaj, że będzie inaczej. 

Dla absolutnej większości, tak jak wspomniałem, architektur, bo wyobrażam sobie jakieś tam super edge case’y, gdzie to może troszeczkę potrwać, ale również nie jakoś specjalnie długo. 

Odpowiedziałbym krótko: jeśli te zalety, które wymieniliśmy sobie wcześniej są dla jakiejś organizacji kluczowe albo wpłyną na jej wizerunek być może, wpłyną na działanie jej systemów albo pozwolą na rozbudowę tych systemów o kolejne klocki, które wymagałyby rezydencji czy latencji kilku-milisekundowej, jeśli mówimy o połowie obszaru naszego kraju, to pewnie będzie ok. 10 milisekund na PING-u, to wówczas tak. Wówczas warto. Jeśli nie – to zaryzykowałbym stwierdzenie, że to nieopłacalne tak naprawdę, bo to sztuka dla sztuki. 

 

Bardzo inżynierskiej odpowiedzi udzieliłeś! Że po prostu trzeba dobierać rozwiązania do problemu, tam, gdzie ma sens dokonywanie takiej migracji, tam ma sens, ale dla samego faktu dokonania pewnie nie ma to zawsze uzasadnienia. 

Pytanie związane z Google Cloud Platform, z naszym przyszłym już niedługo regionem. Jakie kluczowe w twojej opinii usługi będą obsługiwane?

 

Tego przed 14 kwietnia oficjalnie nie można udostępniać, ale z tego, co mogę powiedzieć, to nie będzie – już to wcześniej zdaje się padło – będzie to dość nieubogi region w usługi i należy się spodziewać takiego wachlarza serwisów, który satysfakcjonuje większość odbiorców Google Cloud!

 

Dyplomatyczna odpowiedź! 

 

Mówiąc krótko: tych usług będzie więcej, niż mniej, jeśli wyobrażamy sobie jakiś region, który ma ich sporo, to możemy przyjąć, że warszawski będzie miał bardzo podobną liczbę. 

 

Świetnie! Myślę, że to dają namiastkę tego, czego możemy się za chwileczkę spodziewać. 

Teraz może pytania w oderwaniu do Google Cloud, tylko raczej ogólne, związane z przetwarzaniem danych. Jakie największe bolączki, problemy spotkacie we współpracy z klientami, jeśli chodzi o przetwarzanie danych. 

Czy są to jakieś powtarzające się błędy architektoniczne, na które napotykacie co najczęściej leży u źródła tych problemów z przetwarzaniem danych?

 

Wydaje mi się, że będzie kilka takich rzeczy. Na pewno czasem zdarza się, że w jakimś ekosystemie wykorzystywane są komponenty nie do końca zgodne z ich takim tradycyjnym przeznaczeniem, na przykład ktoś używa sobie relacyjnej bazy danych do takich analiz typowo hurtownianych albo trzymania danych sensorów IoT. Następnie mógłbym powiedzieć o monolitach, które absolutnie nie zawsze, nie do końca nigdy nie jest to odpowiedź jednoznaczna, ale monolity się nie lubią trochę z cloudami. Im bardziej rozproszony serwis na mikrousługi, tym bardziej jesteśmy w stanie sobie tutaj tę architekturę software’ową rozsmarować po komponentach i ona się będzie dużo lepiej skalować, dużo precyzyjniej, bo wyobrażamy sobie na przykład sytuację, w której przychodzi do nas jakiś gigantyczny ruch, ale tylko na jedną funkcję naszego systemu. Wówczas w monolicie musimy podnieść zasoby dla wszystkich, to znaczy dla tego konkretnego monolitu, natomiast w przypadku mikroserwisów tam będziemy w dużo bardziej komfortowej sytuacji, bo rozłożymy sobie ten ruch na poziomie jednego mikro serwisu. 

To na pewno wpływa i jeśli mamy takich klientów, to oni sami zazwyczaj też planują równolegle być może albo być może jeszcze przed tym, jak przystąpią do migracji do środowisk chmurowych, aby swoje aplikacje bardziej skonteneryzować, rozbić na mikroserwisy niektóre procesy, które się da, bo wtedy robi się to dużo przyjemniej. Egzotyczne technologie konteneryzacji lub ich całkowity brak to kolejna taka rzecz, z którą się czasami spotykamy, ale to zazwyczaj szybko jesteśmy w stanie skorygować z klientem i przejść na rozwiązania, które reprezentują potentatów w tej dziedzinie niż jakieś wyszukane, czasami pisane bardzo customowo, wewnątrz firmy, rozwiązania. 

 

Zacząłeś mówić o tym, że takie rozbicie monolitu na mniejsze części może dobrze współgrać z chmurą, wtedy jesteśmy w stanie więcej usług, więcej możliwości z tej chmury wydobyć. W chmurze publicznej, w tym w Google Cloud mamy dostępne konfigurowalne narzędzia, komponenty, które mogą realizować poszczególne wycinki danego procesu. Weźmy to przetwarzanie czy w ogóle dane, o których mówimy.

Mamy jakieś komponenty, jakieś możliwości, narzędzia do zbierania, do przechowywania, do analizy, do wyciągania jakichś wniosków.

Czy według ciebie takie komponentowe podejście to jest odpowiednia droga do uzyskania dużej elastyczności? Czy jesteśmy w stanie przełożyć każdą specyfikę czy też każde zaplecze technologiczne, takie zróżnicowanie i technologiczne, i biznesowe, jakie można spotkać w firmach na komponenty, które już w Cloudzie są i zawsze skończy się to odpowiednim przełożeniem, odpowiednim zmapowaniem elementów infrastruktury, procesu biznesowego właśnie na odpowiednie komponenty w chmurze?

 

Jest to niewątpliwie duże wyzwanie, żeby to mapowanie powstało i było zgodne z najlepszymi praktykami oraz też najnowszymi doniesieniami z konkretnego vendora chmurowego, bo te usługi często się zmieniają, często powstają nowe, które bardziej odpowiadają naszym oczekiwaniom i zdarza się, że architektura zaplanowana pół roku temu za pół roku może wymagać przesunięcia jednego komponentu, wymienienia go na inny, ponieważ ten inny już w tej chwili realizuje proces, który chcieliśmy ograć jakimś innym komponentem i zrobić jakiegoś work-arounda.

 

Jest to niewątpliwie duże wyzwanie, żeby to mapowanie powstało i było zgodne z najlepszymi praktykami oraz też najnowszymi doniesieniami z konkretnego vendora chmurowego, bo te usługi często się zmieniają, często powstają nowe, które bardziej odpowiadają naszym oczekiwaniom i zdarza się, że architektura zaplanowana pół roku temu za pół roku może wymagać przesunięcia jednego komponentu, wymienienia go na inny, ponieważ ten inny już w tej chwili realizuje proces, który chcieliśmy ograć jakimś innym komponentem i zrobić jakiegoś work-arounda. 

 

Co do zasady, to w twoim pytaniu padła stwierdzenie, które prowokuje do odpowiedzi, że oczywiście, że nie, zawsze komponenty chmurowe odpowiadają wszystkim funkcjom, bo bywają systemy, które są bardzo specyficzne, mają specyficzne potrzeby, są zbudowane w specyficzny sposób, ale też wymagają specyficznego środowiska wokół siebie.

I wówczas taki zestaw nawet setek komponentów, które są wykorzystywane zazwyczaj w chmurze publicznej przez większość klientów może nie wystarczyć, wówczas korzystając z komponentu o niższym poziomie abstrakcji, czyli maszyn wirtualnych GKE, klastra gubernetusowego, możemy sobie taki komponent zdeployować czy wydać, wdrożyć na produkcję zgodnie z pryncypiami cloud native i dobudować sobie usługę, której nie było, albo doinstalować taką, więc często tak bywa, że przy bardzo skomplikowanych systemach 30-40% komponentów może być customowych i nadal cały ekosystem spełnia te definicje i czerpie garściami z chmury publicznej.

 

Skupiamy się tutaj na przetwarzaniu, zbieraniu i obróbce danych, więc w tym wąskim – chociaż może niekoniecznie – obszarze chmury. Jakie mamy komponenty? Konkretnie już w Google Cloud, które dają jakieś możliwości właśnie związane z obszarem danych.

Co byś tutaj wymienił, jeśli chodzi o takie podstawowe komponenty Google Cloud w obszarze danych?

 

Och tak! Mamy tych komponentów całkiem dużo i nie wiem, od czego moglibyśmy zacząć, bo jest to szereg komponentów, które są osadzone na różnym poziomie abstrakcji i służą oczywiście do rozwiązywania różnych problemów. Czasami grupy problemów, czasami bardzo wąskiego, wybranego wycinka i tak możemy sobie powiedzieć o hurtowni danych, która jest as a service, bazach danych różnego przeznaczenia, czy to relacyjne, czy to nierelacyjne silniki kolejek, Pub/Sub, narzędzia do budowania ETL i ELT, stosy narzędzi służących do budowy rozwiązań opartych o AI, to zupełnie osobny temat na osobny podcast prawdopodobnie, ale oczywiście trzeba o tym wspomnieć.

Serwisy AI do ubogacania czy anonimizacji danych, to taki przykład na wysokopoziomowe narzędzie, które zapinasz pod strumień nieustrukturyzowanych danych serwis, które wyszukuje danych o kartach kredytowych, peseli, adresach korespondencyjnych i zrobi z nimi rzeczy, które ci się podobają. Wygwiazdkuje wszystko i zostawi ostatnie cztery cyfry numeru karty. Tego rodzaju rzeczy są gotowe i na półce, nie trzeba ich implementować w żaden sposób. Czasami nie trzeba ich nawet konfigurować, tylko sprawdzić, czy się wszystko zgadza z naszymi oczekiwaniami, bo mamy podobne problemy do setek innych firm, które też przyszły do Google’a szukając rozwiązania „Hej, mamy nieustrukturyzowane dane, jak ktoś poda kartę kredytową, to proszę mi wyciąć”. W taki sposób, w jaki właśnie powiedziałem. I takie rzeczy też istnieją.

Są też narzędzia audytujące dostęp do danych, lobbujące wszystkie aktywności z jakiego IP, przeglądarki, który user wszedł do której bazy, co wyciągnął, mniej więcej to wszystko ładnie widać, jest tam dużo dobrego i narzędzia na start z data governance’em, również istnieją w chmurach publicznych, czy to konkretnie w Google Cloudzie mamy Data Catalogue, który w sposób bardzo przejrzysty pozwala nam na to, żebyśmy zapanowali nad wieloma strumieniami danych w naszej organizacji. Kto z tych danych korzysta, kto jest właścicielem biznesowym, właścicielem technologicznym. Takie poukładanie. Czasem duże organizacje mają spory problem, chociażby z onboardingiem pracownika, który przychodzi, jest analitykiem danych jakiegoś rodzaju i się ciężko, w pocie czoła onboarduje.

Natomiast gdyby dane były poukładane i skatalogowane – nie muszę kończyć tego zdania!

 

Tak jest. Chciałbym przejść do pytań bardziej technicznych, bo zaczęliśmy od tego, jakie możliwości daje nam czy też będzie nam dawał ten polski region dla firm z naszego kraju i regionu. Teraz chciałbym cię zapytać, jakie możliwości stwarza ten regon dla osób zajmujących się IT? Dla programistów, inżynierów, architektów?

 

Oprócz tego, że można robić ciekawe projekty, ciekawsze niż wcześniej, bo posiadając system, który wymaga niskich latencji należało porzucić Google Cloud ze swojej mapy, tak samo, jeśli byliśmy podmiotem regulowanym, to były z tym większe problemy niż teraz będą. Nie chcę wchodzić w szczegóły, bo to bardzo szeroki temat podmiotów regulowanych. Dla samego takiego inżynieryjnego punktu widzenia nie będzie różnicy, jakiegoś skoku technologicznego, no bo te technologie będą bardzo tożsame z tymi, które obserwowaliśmy w regionach europejskich czy amerykańskich już dzisiaj, będą one w Warszawie, więc będzie szybciej i mógłbym tylko podnieść, jeśli taki egoistyczny światopogląd jest również dobrą odpowiedzią na to, czy tam jedną z nich, to egoistyczne ze względu na branżę i jakąś grupę zawodową, no to mamy poszerzający się bardzo rynek pracy dla tego typu specjalistów, ponieważ o tym otwarciu jest głośno, oddaje szereg dodatkowych możliwości i w kolejnych latach nie ma badania, które nie pokazywałoby spadek czy stagnację. 

W naszej dzisiejszej sytuacji, pandemicznej, obserwujemy bardzo wysokie zainteresowanie środowiskami chmurowymi, również dlatego, żeby te koszty obniżyć. Infrastruktury, bo nie tylko mówimy o chmurze w kontekście tego, jakie stwarza sobie możliwości dla organizacji i jakie organizacja ma przed sobą dodatkowe klocki do poukładania w swojej architekturze i jakie wyzwania technologiczne czy też jaki ruch może przyjąć bez najmniejszego zająknięcia, jakie dane może przetwarzać, ale również mamy w drugą stronę – temat składania się infrastruktury, jeśli twój biznes nie potrzebuje nagle takiego ruchu, no bo jesteś w branży, która został lekko czy bardzo dotknięta.

 

W tym obszarze danych, o którym rozmawiamy i w kontekście Google Cloud, jedno z takich podstawowych, sztandarowych narzędzi to BigQuery.

Jak to narzędzie działa? Jak wygląda model rozliczeń, bo „big” świadczy o tym, że możemy dużo danych przetwarzać, w związku z tym ta warstwa rozliczeń też może być istotna i wreszcie też jakie umiejętności musimy mieć, by w ogóle w tym obszarze BigQuery się poruszać?

 

Tak, to jest falowy produkt do analityki dużej ilości danych. Ono się trochę infantylnie nazywa, jak zauważyłeś, ale tak. Na pewno jest to hurtownia danych, ma interfejsy komunikacyjne na różnym poziomie abstrakcji, ale takim sztandarowym interfejsem jest SQL 2011, który pozwala na to, abyśmy się w tej hurtowni poruszali, eksplorowali dane.

Ma ona taki model rozliczeniowy, że w klasycznym ujęciu pay as you go, to jest to tylko opłata za storage, za dane, które tam przechowujemy i za każdy kolejny, po drugim włącznie, terabajt przetwarzanych danych. Chodzi o to, że mamy tutaj free tier, mamy darmowy jeden terabajt danych do przetworzenia i dzięki temu możemy w tym jednym terabajcie w okresie rozliczeniowym się poruszać i nie zapłacić nic, a każdy kolejny terabajt rozpoczęty to kilka dolarów amerykańskich, w zależności od regionu i cóż można dalej powiedzieć – są operacje, które są zawsze darmowe, jeśli chodzi o pricing jeszcze tak jak ładowanie danych, bo chmury lubią, jak się w nie ładuje duże dane i żadna nie powie ci, że coś jest nie tak. Bardzo nas to wszystkich cieszy. 

Kopiowanie, eksport tych danych. Oprócz oczywiście IGRS-u sieciowego, bo za ten trzeba zapłacić, ale takie operacje eksportu wewnątrz Google Clouda, one są darmowe z BigQuery. Usuwanie, praca z metadanymi, na przykład COUNT(*) from: tabela, tabela jest zawsze opcją darmową, bo dotyka tylko metadanej, a nie faktycznych danych, które sobie tam przechowujesz. Można byłoby o tym opowiadać sporo, chociażby o tym, że jest to storage kolumnowy, który jest zoptymalizowany pod kolumny, więc jeśli mamy takie myślenie z baz wierszowych, to oczywiście powinniśmy lekko je zmodyfikować i dostosować je do nowej rzeczywistości, jeśli chcemy korzystać z tej hurtowni akurat, ma sporo zaawansowanych funkcji takich w stylu machine learning, wbudowany bardzo prosty, ale skuteczny mechanizm do uruchamiania machine learningowych analiz. Głównie sprawdza się to przy predykcjach danych ustrukturyzowanych, gdzie nie musimy sięgać po narzędzia spółki od AI, tylko możemy sobie wewnątrz BigQuery ewaluować, trenować modele bezpośrednio za pomocą właśnie języka SQL. 

Pytałeś jeszcze na koniec o to, jakie umiejętności należy mieć, aby skorzystać z BigQuery. 

Jest takim przykładem narzędzia, którego konfiguracji nie trzeba nawet sprawdzać. Jest to uruchomiona hurtownia danych, która jest zawsze dostępna i nic za nią nie płacisz. Nagle tam wchodzisz i ona tam jest, więc to jest koniec całego set-upu, jeśli chodzi o administrację. Oczywiście jest kwestia integracji, kwestia bezpieczeństwa, te wszystkie rzeczy są bardzo istotne, ale mówimy z punktu widzenia człowieka, który prototypuje rozwiązanie i chciałby się pobawić, chociażby data governance. 

Natomiast jeśli chcesz się pobawić i masz ochotę skorzystać z tej hurtowni to ona tam jest, potrzebujesz podstawowej znajomości języka SQL, żeby zacząć z GUI, żeby zacząć się bawić danymi. Możesz zaimportować sobie jakiś otwarty data set, który w ramach BigQuery jest ich całe mnóstwo różnego rodzaju. Na przykład cała Wikipedia, GitHub nie mówiąc o bardziej zaawansowanych genetycznych, medycznych data setach pogodowych, także dużo zabawy i praktycznie zero kompetencji. Bardzo niski próg wejścia, moim zdaniem. 

 

Okazuje się, że nawet tak duże i złożone rozwiązanie może być częścią składową jeszcze większej, szerszej konstrukcji, jaką jest data pipeline. W jakim celu się tworzy takie przepływy i co tutaj może być na wejściu, co jesteśmy w stanie uzyskać na wyjściu?

 

Główny cel jest taki, żeby zarządzać swoimi danymi tak, aby mogły stanowić dla nas jak najwyższa wartość, bo nie jest sztuka pozbieranie wszystkich danych ze świata albo przynajmniej połowy, ale sztuką jest potem nimi zarządzać tak, żeby stanowiły wartość dla naszego biznesu. 

Na wejściu, na wyjściu może być oczywiście cokolwiek technicznie, im więcej danych wejściowych na całym ekosystemie analitycznym tym łatwiej będzie nam spotęgować ich wartość poprzez tworzenie przecięć, korelacji, ubogacania ich serwisami zewnętrznymi czy to właśnie przez łączenie i dostosowywanie niektórych wniosków do tego, co znajduje się w zupełnie innym, pozornie niezwiązanym data secie. 

 

Na wejściu, na wyjściu może być oczywiście cokolwiek technicznie, im więcej danych wejściowych na całym ekosystemie analitycznym tym łatwiej będzie nam spotęgować ich wartość poprzez tworzenie przecięć, korelacji, ubogacania ich serwisami zewnętrznymi czy to właśnie przez łączenie i dostosowywanie niektórych wniosków do tego, co znajduje się w zupełnie innym, pozornie niezwiązanym data secie. 

 

Przykładem może być tutaj jakiś e-commerce, duży e-commerce, który ma jeszcze dane dotyczące magazynów, IoT związanego z magazynami. Można tutaj sobie rysować cały przykład, data pipeline’y co do zasady mają sprawić, żeby nasze dane były w miejscach, które są odpowiednie do dalszej analizy, albo wręcz dokonywać tych analiz już preagregacji, usuwania jakichś niezbyt pasujących nam danych, takich jak jakieś anomalie, które nas nie obchodzą, jakieś zaszumienie, więc takie pipeline’y oczywiście się również tworzy. 

 

Nie bez powodu zacząłem cię pytać o BigQuery, ponieważ to jest taki flagowy produkt, który nam się kojarzy z analityką danych, w ogóle z danymi. Okazuje się, że w ramach Google Cloud to nie jest jedyny produkt z tej kategorii. Są nawet bardziej skomplikowane, bardziej złożone usługi dostępne, ale jednak ta popularność z czegoś wynika. Zastanawiam się, z czego i skąd według ciebie jest takie jednoznaczne skojarzenie, że analiza danych w Google Cloud to jest właśnie BigQuery?

 

Tak. Jest to pewnego rodzaju problem marketingowy, chociaż zupełnie się na tym nie znam. Cóż można powiedzieć na obronę tego stwierdzenia, bo ono jest częścią otaczającego nas świata – jest to produkt, który jest na pewno bardzo wygrzany. Ma 11 lat w tym roku historii produkcyjnego wykorzystywania w Google Cloudzie, jest to miejsce, w które wystarczy kliknąć i masz gotową konsolę analityczną do zarządzania dowolnym wolumenem danych, który przyjmie od ciebie BigQuery za zero złotych. To robi już jakieś wrażenie i pewnie przysparza dodatkowych wdzięków wśród ludzi, którzy nie zajmowali się dotychczas takimi systemami lub zajmowali się nimi w on premise, gdzie musieli przechodzić troszeczkę dłuższą ścieżkę. 

Każdy zna SQL-a na takim czy innym poziomie, więc poradzi sobie w BigQuery bez najmniejszego problemu. Oczywiście można się łączyć przez API, przez CLI, SDK itd., natomiast SQL jest podstawowym interfejsem, tak jak wspomnieliśmy wcześniej, więc bardzo popularny interfejs też przysparza popularności samemu narzędziu na pewno. 

Jest to potężne narzędzie posiadające cały ekosystem pod narzędzi. Mówiliśmy sobie o machine learningu, ale moim jednym z ulubionych połączeń jest Scheduler zapytań, czyli miejsce, w którym możesz powiedzieć BigQuery, żeby wykonywał jakieś zapytanie co jakiś czas, ustalane odpowiednio, z gwarancją, że się wykona. 

Możliwość sięgnięcia po dane spoza własnego storage’u, czyli możesz sobie za jego pośrednictwem zrobić tzw. federated query do, chociażby Google Cloud Storage, czyli storage’u obiektowego na Google Cloudzie, albo do Google Drive’a możesz sobie pójść i te wszystkie wyniki, które sobie tam wykonasz w zapytaniach schedulowanych zapisać do tabeli obok w formie albo nadpisania, albo dopisania na końcu. 

Możesz stworzyć takiego małego ETL-a, czy ELT, w zależności od tego, co będziesz dalej robił i jaka jest główna, gdzie jest główny ciężar tych operacji. 

Niewiele osób powie „big table” myśląc o danych sensorycznych pochodzących z IoT, bo to stawianie klastra to jest to krótki, ale jednak proces, a nie kliknięcie tak jak w BigQuery. W Big Table poniżej 300 gigabajtów zaleca się, żeby takiego Big Table nie powoływać, że to nie ma sensu, bo nie będzie to miało realnej wartości, ale kiedy przychodzą dziesiątki miliardów requestów na dobę z takimi sensorami, chcesz mieć te dane na Big Table, po prostu. Ten silnik bazodanowy wspiera całą gamę standardowych operacji, które chcesz sobie zrobić na time serious’owych, sensorycznych danych z IoT i niekoniecznie BigQuery tutaj będzie doskonałym wyborem. Choć do części, wybranej części zastosowań to będzie na pewno jakaś dobra alternatywa, więc część tych informacji nie jest też tak w tym naszym świecie data, jak wiemy, że wszystkie dane z konkretnego źródła muszą być w jednym, docelowym miejscu. Bywa tak, że są w dwóch, a jeszcze jakiś mały subset jest w trzecim. Potem jest coś jeszcze koszowanego, preagregaty są trzymane gdzieś tam i tak to wygląda!

 

Rozmawiając o danych, o obróbce danych nie można wspomnieć o ETL-u, którego już przywoływałeś kilka razy. Taki zestaw narzędzi, które wspomagają nam pozyskiwanie danych do baz danych, do hurtowni. Bardzo popularne narzędzie w obszarze business intelligence. 

Jak chmura, w szczególności takie narzędzia jak data fusion czy komponenty wranglera mogą nam pomóc stworzyć odpowiednie podejście bazujące na ETL-u?

 

Data fusion jest przykładem narzędzia, które jest opensourcowe, tylko zaadaptowane przez Google Cloud. Tylko albo aż, bo ta cała sekcja integracji, ta współpraca to nie są super łatwe tematy, żebyśmy mieli jasność absolutną. Natomiast jest to takie narzędzie, które pozwala na budowanie ETL-a z klocków lego. Jakby one były inaczej w UI-u wyświetlone, a nie prostokątnymi blokami o prostych bokach, tylko jako klocki, to bym się wcale nie zdziwił, bo wygląda to faktycznie tak, że budujesz diagram przeciągając i upuszczając pewne komponenty i na każdym z nich możesz kliknąć sobie „konfiguruj mnie”, gdzie brakuje tam jeszcze czarodzieja z Office’a, które to komponenty udostępniają bardzo ładny interfejs konfiguracji. 

I teraz jak mamy sobie przeczytać dane z GCS-a, to możemy sobie kliknąć, że moim źródłem będzie GCS – i w konfiguracji podajemy gdzie, jaki, z jakimi uprawnieniami i kropka, testujemy sobie tylko te konfiguracje i zamykamy. I mamy blok, który wykonuje nam pracę: „czytam dane z GCS-a”. I na wyjściu będą te dane. 

Jeśli chcesz na wyjściu wrzucić je w kolejkę, to klikasz sobie, że chciałbyś to zrobić i ta kolejka na wejściu, bo połączysz to strzałką, dosłownie tak to wygląda, przyjmuje te wartości. Oczywiście formaty i tak dalej, to wszystko jest do skonfigurowania no i nagle zrobiłeś proces, który wrzuca dane z GCS-a na kolejkę, z kolejki wrzuca to do data flow, robi cokolwiek. Mówiliśmy sobie o wranglerze, więc wrzucasz jego komponent, wchodzisz do niego i widzisz dane w formie tabelki, powiedzmy, bo miałaś dane tabelaryczne na wejściu. 

Nie podoba ci się format, nazwy kolumn, nie podobają ci się różne rzeczy – chcesz obrócić tę macierz, więc wykonujesz to na podstawie tego, co jest w interfejsie wranglera, robisz wszystkie transpozycje, transformacje, jakie ci się podobają, klikasz „save” i masz komponent, który zrobił właśnie te transpozycje. Następnie układasz BigQuery albo dowolny inny, kontynuując poprzedni wątek, sink tak zwany do tych danych i one mogą się znaleźć w drugim miejscu, w kompletnie innej części twojej infrastruktury chmurowej bez ingerencji programisty, dosłownie w ciągu kilkudziesięciu minut, jak jest bardziej skomplikowany proces. 

Rekordem takiego podobnego pipeline’u było faktycznie ok. 5-6 minut konfiguracji i dane z CSV-ek, które były rozrzucone, to były dane sensoryczne z farm fotowoltaicznych. Potrafiłem te dane złożyć w jedną tabelkę, znormalizować ją, trochę pozmieniać typy danych, powyrzucać kolumny, które mnie nie interesowały, zobaczyć przy okazji, czy mam jakieś anomalie na sensorach, które mnie interesowały najbardziej, bo we wranglerze są insighty, które pozwalają ci wyświetlić tego typu informacje od razu po prostu i załadowałem to wszystko do miejsca, gdzie dalej mogłem przetwarzać te dane w inny sposób, więc takie rzeczy – to robi na pewno wrażenie na osobach, które nie miały z tym wcześniej styczności. 

 

Bardzo przystępna, przyjazna forma i co jest tutaj bardzo istotne – powiedziałeś, że niekoniecznie trzeba mieć bardzo szeroki background technologiczny, żeby sobie z tym poradzić, bo ten interfejs jest na tyle prosty, te strzałki, o których powiedziałeś, to robi wrażenie. 

 

A jednocześnie to wszystko można eksportować i importować później, więc te wszystkie rzeczy, o których niektórzy nasi słuchacze sobie myślą, o utrzymaniu, o tym, jak wersjonować te pipeline’y, to wszystko, wszystko jest „robialne”!

 

Powiedziałeś wcześniej, że wiele firm najczęściej posiada dane z różnych źródeł, w różnych formatach, w różny sposób spływające. Weźmy jakieś dane związane z ecomeercem, z systemem księgowym, IoT itd. 

Mówi się wówczas o czymś takim jak data lake. Czy mógłbyś proszę wyjaśnić, na czym to podejście polega? Jak za pomocą chmury możemy zrealizować takie podejście data lake?

 

Data lake bywa określane buzzwordem, ale co to tak naprawdę oznacza? Podajmy sobie przykład danych, które przychodzą właśnie z IoT, bo wokół tego przykładu się poruszamy. Przychodzą do nas te dane co sekundę z różnych miejsc dostajemy informacje o odczytach. Jest tych danych sporo, dostajemy je na jakichś bramkach komunikacyjnych i teraz możemy z nimi robić różne rzeczy. Analizujemy je, w sposób, który jest nam dziś znany i co możemy zrobić z data lake?

 

Data lake bywa określane buzzwordem, ale co to tak naprawdę oznacza? Podajmy sobie przykład danych, które przychodzą właśnie z IoT, bo wokół tego przykładu się poruszamy. Przychodzą do nas te dane co sekundę z różnych miejsc dostajemy informacje o odczytach. Jest tych danych sporo, dostajemy je na jakichś bramkach komunikacyjnych i teraz możemy z nimi robić różne rzeczy. Analizujemy je, w sposób, który jest nam dziś znany i co możemy zrobić z data lake? 

 

Po pierwsze, możemy zapisać te dane, które przychodzą w wersji surowej. Jest to istotne z punktu widzenia, chociażby bezpieczeństwa czy też kultury pracy z danymi, żeby przetwarzane dane z systemów zewnętrznych zawsze store’ować sobie na boku w takiej wersji surowej, jakiej dostałeś, bo jest to uzasadnione z wielu względów. 

Co możemy powiedzieć dalej? Po pół roku czy po roku, mamy nowy pomysł na to, jak możemy te dane analizować i wyciągać z nich więcej pieniędzy, bo do tego się to sprowadza na koniec całej zabawy. Możemy te dane odtworzyć jak byśmy się cofali w czasie i kliknęli play, tylko w historii na przyspieszeniu czasami, czasami nie, jak nam się podoba i odtworzyć je z data lake’a, tak jakby nam przychodziły z takiego zewnętrznego systemu, który już nie da nam tych informacji wstecz, bo taka jest jego charakterystyka. Te sensory w oczywisty sposób nie zaczną pisać z powrotem tego, co pisały rok temu, te bufory są, ale nie oszukujmy się. I szereg innych. 

Masz jakieś API zewnętrzne, to API odpowiada w jakiś sposób, więc warto sobie przytrzymać „surówkę”, zwłaszcza że w GCS-ie, na który będziemy pisać w przypadku Google Clouda, mamy kilka polityk tak jak zresztą u wszystkich dużych vendorów. Mamy kilka polityk na object storage’u i możemy sobie efektywnie kosztowo zapisać duże ilości danych na nigdy nie odtworzenie, żeby nadal było rozsądnie kosztowo. A jakby raz czy dwa się okazało, że chcemy przeczytać połowę czy 10%, to nie zapłacimy jakichś horrendalnych pieniędzy. 

 

Potrafię sobie wyobrazić, że sytuacja jest nieco prostsza, jeśli całość tej naszej infrastruktury związanej z danymi mamy już w chmurze, np. w Google Cloud, ale to oczywiście jakaś część przypadków. 

Mogę sobie wyobrazić sytuację, kiedy mamy potrzebę, żeby nasze Data Center połączyć z Google cloud, żeby za pomocą tych danych, które są wymieniane, realizować dane usługi. 

Tu się pojawia pytanie, jak takie połączenie zestawić, jak je zoptymalizować i zabezpieczyć?

 

Na pewno mamy szereg możliwości, zarówno software’owych, jak i nie do końca. Pierwszą, klasyczną możliwością jest postawienie sobie VPN-a, czy to HA czy bez HA i tunel IPsec będzie zostawiał nam to połączenie – zostawimy sobie to połączenie za jego pośrednictwem i będzie to działać. Przy okazji mówienia o dużych danych i o transferze, warto wspomnieć o tym, że przez takiego VPN-a i tak przesłalibyśmy sobie sporo informacji poza infrastrukturę sieciową Google’a, co jest odbijane na cenniku. Bo wszystkie informacje wychodzące z chmury kosztują. 

Można tutaj rozważyć tzw. partner albo dedicated interconnecty, za których pośrednictwem można się połączyć bezpośrednio z punktem dostępowym, bo to nie do końca musi być data center. 

To dość oczywiste, ale być może niektórzy nie są tego świadomi. Wówczas taki interconnect działa w ten sposób, że Google charge’uje nas za ten IGRS do naszego on prema, ale nadal jest to zdecydowanie korzystniejsze. I też szereg takich bardziej zaawansowanych wymagań, jeśli chodzi o transfer. Warto jednak wspomnieć, że interconnecty nie oferują same z siebie żadnego zabezpieczenia i trzeba to zabezpieczenie, o te warstwy bezpieczeństwa dbać we własnym zakresie. 

 

Właśnie. Przejdźmy do bezpieczeństwa, bo to jest temat, który trafia do świadomości osób nie tylko zajmujących się IT. Do tej pory mówiliśmy sporo o takiej inżynierii danych, a teraz może warto byłoby powiedzieć o aspekcie bezpieczeństwa. 

Czy według ciebie, jeśli mówimy o chmurze publicznej, po danych, które w tej chmurze chcemy sobie składować czy obrabiać, to czy możemy czuć się bezpiecznie z poufnymi danymi, za które jesteśmy odpowiedzialni, aby były w odpowiedni sposób składowane i przetwarzane?

 

Tak, myślę, że zdecydowanie tak i na to składa się wiele czynników. Po pierwsze mamy taką macierz odpowiedzialności za bezpieczeństwo. To jest taka publicznie dostępna macierz, która plasuje środowiska chmurowe w takim miejscu, w którym klient tego środowiska ma stosunkowo mało kłopotów. Za mało rzeczy musi odpowiadać. Na przykład nie musi odpowiadać za to, że nieuprawniony pracownik serwerowni dostanie się do maszyny fizycznie, w jej okolice. Do pomieszczenia, w którym trzymane jest jego serwer czy też jego szafy. 

Dane domyślnie są szyfrowane zarówno in transit, jak i addressed, czyli zarówno przy przesyle  jak i dane w spoczynku, dane zapisane, w Google Cloud. Tego nie da się wyłączyć, domyślnie kluczami szyfrującymi są klucze od Google, natomiast można sobie skonfigurować pewną paletę usług Google Cloud tak, aby dane przechowywane tam były przechowywane za pośrednictwem klucza zarządzanego przez nas samych. 

 

Dane domyślnie są szyfrowane zarówno in transit, jak i addressed, czyli zarówno przy przesyle  jak i dane w spoczynku, dane zapisane, w Google Cloud. Tego nie da się wyłączyć, domyślnie kluczami szyfrującymi są klucze od Google, natomiast można sobie skonfigurować pewną paletę usług Google Cloud tak, aby dane przechowywane tam były przechowywane za pośrednictwem klucza zarządzanego przez nas samych. 

 

Możemy jeszcze, chociaż byłaby to zbyt szeroka odpowiedź, nakreślę: możemy skonfigurować Google Cloud tak, aby jego KMS korzystał zewnętrznego HSM-a, bo takie rzeczy też są możliwe, nie jest to trywialne, ale dostępne. Myślenie o bezpieczeństwie to myślenie również o compliance, więc o tym, jak w Google Cloud mamy zaadresowaną potrzebę bycia zgodnym ze standardami GDPR czy też RODO, jak kto woli, czy jakimiś regulacjami dotyczącymi danych medycznych. 

Te wszystkie i wiele innych regulacji czy też norm są pokryte audytami, certyfikatami, które można sobie przeglądać i takie twarde raporty SOC-owe, nie są dostępne w większości dla publicznego audytorium, Google udostępnia je po podpisaniu odpowiedniej umowy NDA, ale można przeczytać jak to było realizowane no i te audyty to są firmy trzecie, jest ich więcej niż jedna, oczywiscie, więc to wszystko jest tak zrobione, żebyśmy czuli się bezpiecznie i byli bezpieczni. 

Zazwyczaj te wszystkie data leaki, data bleache wynikały tylko z tego, jeśli dotykały środowisk chmurowych, że to był właśnie misconfiguration, czyli ktoś po prostu czy to udostępniła jakąś bazę publicznie, po kliknął, że „tak, naprawdę mam ochotę udostępnić ją publicznie” i potwierdził to na dwóch niezależnych ekranach, jeśli mówimy, chociażby o relacyjnej bazie, natomiast jeśli mówimy o becketcie na GCS-ie, to również tak samo. Można go udostępnić i przechowywać swoje dane osobowe i będzie wyciek, nie będzie to niebezpieczne, tylko że domyślnie wszystko jest powyłączane, wszystko w sieci wewnętrznej i nie ma takich przypadków, żeby ktoś obudził się w chmurze i dostał na dzień dobry niebezpieczną infrastrukturę, która robi mu jakieś brzydkie rzeczy. 

Oczywiście same kwestie związane z sieciową infrastrukturą również są konfigurowalne, można separować te narzędzia według naszych potrzeb, także jest tam sporo dobrego. 

 

Na końcu chcę cię zapytać, w którym kierunku ta branża będzie się rozwijać? Jakie trendy obecnie związane z danymi i z chmurą widzisz co może nas czekać w najbliższej przyszłości? 

 

To ciężkie pytanie, bo przypomnijmy się, że compute, maszyny wirtualne AWS-a mają kilkanaście lat. Usługi googlowe mają kilkanaście lat, mniej, ale już powoli robią się z tego takie wartości, więc cóż będzie za dwukrotność tego czasu? 

Bardzo dobre pytanie. Myślę, że po pierwsze będziemy obserwować znaczący wzrost zainteresowania środowiskami chmurowymi, bo pokazują to badania rok do roku, wszystkich vendorów – oni rosną o co najmniej kilkadziesiąt procent, jeśli mamy sobie spojrzeć na historię ostatnich lat. Kilkadziesiąt procent rok do roku. To po pierwsze. 

Po drugie: ekspansja regionów też wpływa. Myślę, że można byłoby porównać to do ekspansji metra w jakimś mieście, gdy jest pół nitki to jest jakość, ale jak są trzy, to już wszystkie dzielnice, które wcześniej tymi stacjami metra nie dysponowały, nie mogły się nimi cieszyć, dzisiaj wyglądają troszeczkę inaczej i historycy miejscy w miastach, w których budowano metro w ostatnich 50 latach, mogliby coś więcej na ten temat powiedzieć. 

Wracając do naszego podwórka, rozwój tych regionów na pewno będzie na to wpływał, będzie coraz więcej kompetencji, danych będzie coraz więcej, więc coraz trudniej będzie robić sobie te wszystkie operacje, które chcieliśmy robić dzisiaj na danych. Bardzo trudno będzie je robić jutro nadal w on premie. 

Oczywiście nie zakładam, że wszyscy nagle przeniesiemy się jak jeden mąż do chmury obliczeniowej, bo to nie jest możliwe, czasem niewskazane, natomiast w bardzo wybranych przypadkach i jak pokazują badania, to absolutna większość firm przechodzi do chmur, ale też większość z tej większości przechodzi do niejednej chmury. Nadąża się taki moment w historii rozwoju organizacji technologicznej, że te wybierają sobie komponenty najbardziej odpowiednie do swoich potrzeb spoza wachlarza jednego vendora i ma to oczywiście taki sens, że nie tylko zyskujemy bezpieczeństwo czy brak vendor-lockingu, ale również te komponenty dopasowane bezpośrednio do naszych potrzeb, moglibyśmy przywołać tutaj AWS Ground Station, jako taki przykład usługi. 

 

Oczywiście nie zakładam, że wszyscy nagle przeniesiemy się jak jeden mąż do chmury obliczeniowej, bo to nie jest możliwe, czasem niewskazane, natomiast w bardzo wybranych przypadkach i jak pokazują badania, to absolutna większość firm przechodzi do chmur, ale też większość z tej większości przechodzi do niejednej chmury. 

 

To na pewno będzie się działo – myślę, że będziemy korzystać z coraz bardziej wyspecjalizowanych, zawężonych komponentów, których będzie coraz więcej. Najpierw była infrastruktura, maszyny wirtualne, czyli najszerzej jak się da w chmurze, a dzisiejszą historię możemy zakończyć na takich usługach, które są dedykowane do analizy obrazu w pewnym konkretnym przypadku. Albo tak jak wspomniałem już o anonimizacji danych nieustrukturyzowanych, no to są bardzo wąskie serwisy, które nie mają dużego zastosowania, są na wysokim poziomie abstrakcji. Myślę, że takich serwisów będzie powstawać coraz więcej i vendorzy cloudowi będą chcieli pokryć potrzeby swoich klientów nie tylko maszynami wirtualnymi i tyle, nie tylko bazami danych w managed i dodatkowymi zabawkami, jak to było faktycznie 10 lat temu, tylko tak jak dzisiaj i tak jak mam nadzieję za parę, paręnaście lat również, będziemy mieć tych usług wąskich i wyspecjalizowanych coraz więcej. 

 

Albo tak jak wspomniałem już o anonimizacji danych nieustrukturyzowanych, no to są bardzo wąskie serwisy, które nie mają dużego zastosowania, są na wysokim poziomie abstrakcji. 

 

Myślę, że jedyne co tutaj jest oczywiste, to zmiana i ciągły rozwój. Marku, dziękuję ci za rozmowę, za pokazanie świata chmury właśnie w kontekście wykorzystania danych i też za opowiedzenie trochę o tym nowym regionie, który za chwilę będzie dostępny, którym będziemy mogli się cieszyć i z którego będziemy mogli korzystać. 

 

Gdzie cię można znaleźć w internecie? Jak się z tobą skontaktować?

 

Jestem niezbyt szeroko dostępny w internecie, nie epatuję swoją obecnością, ale jeśli ktoś miałby powód, ochotę się skontaktować, to myślę, że LinkedIn będzie bardzo dobrym źródłem! 

 

Świetnie! Oczywiście ten link będzie też w notatce do odcinka. Z moje strony Marku jeszcze raz bardzo dziękuję z poświęcony czas. I do usłyszenia! Cześć!

 

Dziękuję bardzo za zaproszenie, bardzo mi było miło porozmawiać z tobą! Cześć!  

 

I to na tyle z tego, co przygotowałem dla ciebie na dzisiaj. Chmura obliczeniowa daje wiele potężnych narzędzi do wykorzystania danych, które firmy gromadzą. Dzięki uruchomieniu nowego regionu Google Cloud Warszawa będzie to jeszcze łatwiejsze i dostępniejsze.

Jeśli ten odcinek był dla Ciebie interesujący i przydatny, odwdzięcz się proszę recenzją, oceną lub komentarzem w social mediach.  

Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o wykorzystaniu danych dzięki chmurze.

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.