Kiedy Adam Kawa dołącza do Spotify w 2012 roku firma jest dynamicznie rosnącym, perspektywicznym startupem, jednym z pierwszych które budują i wykorzystują architekturę Big Data w oparciu o Hadoop na wielką skalę. Adam jest pierwszym członkiem a następnie liderem zespołu rozwijającego klaster Hadoop.
Biorąc pod uwagę późniejszy rozwój tej technologii i zapotrzebowanie na kompetencje w tym zakresie naturalnym wyborem było założenie własnej firmy – GetInData. Po drodze współtworzył największą w Polsce techniczną konferencję poświęconą Big Data i powiązanym obszarom – Big Data Tech Warsaw.
Adam, już rok temu prezentowaliście swój projekt realizowany dla telekomu z Kazachstanu obejmujący budowę infrastruktury big data dla przetwarzania strumieni danych z różnych źródeł. Ponieważ branża telekomunikacyjna jest mi szczególnie bliska zainteresował mnie fakt, że tak kluczowy projekt zrealizowaliście w dużej mierze na odległość i w oparciu o podejście zwinne. To nie jest często spotykane podejście i trudne do wypracowania. Czy mógłbyś krótko podzielić się opinią, co Twoim zdaniem zadecydowało o sukcesie takiego podejścia?
Tak, to prawda. Może w kilku zdaniach opowiem o tym projekcie, bo na pewno większość czytelników o nim nie słyszała. W ciągu pół roku udało nam się od zera zbudować nowoczesną platformę big data do analizowania danych telekomu w czasie rzeczywistym, a także wdrożyć kilkanaście biznesowych scenariuszy związanych z kampaniami marketingowymi, wykrywaniem nadużyć, czy automatyczną konfiguracją wybranych usług dla abonentów telekomu. Wszystkie te scenariusze działają dziś w środowisku produkcyjnym i przynoszą klientowi korzyści finansowe. Wolumen przetwarzanych danych przez system obejmuje zdarzenia płynące od ok. 10 milionów abonentów, czyli mówimy o podobnej skali jak w polskich telekomach w np. Play, Polkomtel czy Orange.
Jak się nam to wszystko udało? Były trzy klucze do sukcesu: podejście zwinne, odpowiedni skład zespołów eksperckich po obu stronach oraz dobrze określony cel biznesowy całego przedsięwzięcia. Oprócz typowych stand-up’ów i tygodniowych sprintów, nasze podejście zwinne zakładało, że co miesiąc wspólnie z klientem będziemy definiować zakres prac na dany miesiąc (tzw. work packages), który uwzględni bieżące priorytety, zaktualizowane wymagania, pojawiające się trudności oraz całą dotychczas nabytą wiedzę o projekcie. Dzięki temu, każdy miesiąc skutkował dobrze zaplanowanym krokiem prowadzącym w kierunku docelowego rozwiązania. Choć kontrakt miał ustalony z góry budżet, to był również zwinny, bo zakładał że zakres naszych prac będzie ewoluował, a klient wypłacał nam wynagrodzenie w formie miesięcznych transz, ale w dowolnym momencie miał prawo przerwania współpracy, w przypadku niezadowolenia z jakości czy szybkości naszych wspólnych prac lub innego, dowolnego powodu. Bardzo zależało nam na takiej formie kontraktu, bo natura innowacyjnych projektów Big Data jest taka, że priorytety i potrzeby odkrywane są i zmieniają się non stop. Byliśmy pewni,że pozwoli ona zrealizować projekt nie dość, że z sukcesem, ale do tego taniej i lepiej.
Drugim kluczem do sukcesu był odpowiedni skład zespołów eksperckich. Po naszej stronie był prawdziwy dream team, który nawet koledzy z dataArtisans, czyli twórcy Apache Flink, nazwali zespołem klasy światowej. W jego skład wchodziły osoby o wieloletnim doświadczeniu w technologiach Big Data, a nawet committer do Flink. Po stronie klienta były również osoby z dużym doświadczeniem technicznym, które doskonale znały własne systemy używane w telekomie, co pozwalało nam łatwiej integrować się ze źródłami danych (a nawet je zmieniać, tak żeby otrzymać dane strumieniowo), łatwiej spełniać wymagania związane z bezpieczeństwem, wszelkimi dostępami, a także wymaganiami biznesowymi. Szybko też zaraziliśmy zespół klienta pasją do rozwiązań open-source i Big Data, co pozwoliło aktywnie zaangażować kolegów z Kazachstanu do wspólnej budowy całego rozwiązania. Dzisiaj, czyli rok po zakończonym projekcie, czujemy dumę, że są oni w stanie sami utrzymywać i rozwijać produkcyjny system real-time, który działa 24/7 i realizuje ważne biznesowe scenariusze.
Choć kwestie związane z odległością były ważne, to nie stanowiły one większego wyzwania, bo od lat mamy wypracowane transparentne metody pracy z klientami, które są inspirowane tym jak my sami pracowaliśmy w Spotify. Właściwie codziennie byliśmy “na linii” z kolegami z Kazachstanu, rozmawialiśmy non-stop na komunikatorach typu Skype/Slack, współdzieliliśmy kod źródłowy, tabelę zadań w JIRA.
Bardzo pomogło nam również to, że klient dobrze określił cel biznesowy całego projektu, czyli było dobrze wiadomo po co te dane gromadzimy i przetwarzamy. Klientowi zależało żeby zastąpić komercyjny pudełkowy system analityki zdarzeniowej i kilkanaście scenariuszy biznesowych na nim działających, rozwiązaniem dedykowanym dla nich, skalowalnym, w łatwy sposób rozszerzalnym o nowe scenariusze, oparte o nowoczesne technologie. Nie chcieli standardowego komercyjnego rozwiązania pudełkowego, które konkurencja mogłaby łatwo skopiować, gdyż to nie byłoby innowacyjne, nie umożliwiałoby zbudować przewagi konkurencyjnej i zachować pozycję lidera w branży. Klient nawet sam zorientował się że do tego celu doskonale nadają się projekty open-source typu Kafka czy Flink, i jak po nitce do kłębka, trafił do nas wiedząc, że jesteśmy ekspertami w tych obszarach.
Ostatecznie, klient ocenił nasze prace na cztery piątki na portalu Clutch. Prezentację na temat tego projektu wygłosiliśmy wspólnie z klientem m.in. na Big Data Tech Warsaw, czy na Flink Forward Berlin. Video można zobaczyć tutaj. Moim zdaniem, jest to wzorcowy przykład jak powinno wdrażać się tego typu projekty Big Data.
Czy to podejście udało się je powtórzyć w innym projekcie?
To podejście udało nam się powtórzyć również w innych przedsięwzięciach. Przykładowo w projekcie dla Spotify, gdzie byliśmy odpowiedzialni za wygaszanie jednego z największych w Europie klastrów Hadoop i jego migrację do chmury Google, czy w Truecaller z którym współpracujemy od pierwszego dnia istnienia naszej firmy i po dzień dzisiejszy, a gdzie od zera zbudowaliśmy platformę big data i wdrożyliśmy procesy analityczne przetwarzające dane prawie pół miliarda użytkowników ich aplikacji mobilnej. Właściwie zawsze kiedy mamy szansę zastosować tenże model w praktyce, to udaje się go nam powtórzyć z dobrym skutkiem. Mamy wypracowane dobre praktyki i know-how w tym zakresie.
Na co stawia obecnie GetInData jeśli chodzi o usługi, lub odwracając pytanie – o co pytają klienci? Infrastruktura big data, przetwarzanie strumieni w czasie rzeczywistym, analityka w czasie rzeczywistym?
Chcąc nieustannie utrzymywać pozycję lidera wdrożeń Big Data w Polsce, GetInData musi stawiać zarówno na usługi, które przynoszą wartość naszym klientom tu i teraz, ale także na takie które są przyszłościowe i uwzględniają kierunek rozwoju świata Big Data. Trzema najważniejszymi filarami naszej działalności są: nowoczesne platformy Big Data (zarówno on-premise, hybrid jak i cloud), podejście strumieniowe (nie tylko do gromadzenia danych, ale też przetwarzania), a także analityka dają klientowi rzeczywistą wartość biznesową (więc nie tylko AI/ML, ale też BI).
Klienci pytają nas o wszystkie z tych rzeczy, a nawet więcej 🙂 Z wielką przyjemnością prowadziliśmy projekty które łączą te wszystkie filary naraz np. segmentacja użytkowników aplikacji mobilnych w czasie rzeczywistym działająca przy wykorzystaniu szeregu technologii z chmury Google.
Czy może obserwujecie gorączkę związaną z zastosowaniami sztucznej inteligencji i rosnące zainteresowania ze strony klientów?
Podobnie jak wszyscy widzimy gorączkę związaną z zastosowaniami sztucznej inteligencji. Zainteresowanie jest duże i projektów tego typu powoli przybywa m.in. analiza obrazów i wideo, chatboty, inteligentne roboty. Na pewno jest dobra koniunktura na te projekty i duży hype, podgrzewany przez media, konferencje i propagatorów AI w Polsce. Niemniej my jako GetInData nie forsujemy takich rozwiązań, kiedy widzimy że inne rozwiązania spełnią cele biznesowe tak samo dobrze, a wdrożone zostaną dużo szybciej. Przykładem jest system rekomendacji produktów, który nie zawsze musi wykorzystywać deep learning 🙂 Bardzo skuteczny system można zrobić i bez tego np. bazując na modelach statystycznych. Docelowo liczy się dla nas, żeby klient miał realną wartość dodaną z nowych wdrożeń za rozsądną cenę. Niekoniecznie każde rozwiązanie musi być sexy, fancy i naszpikowane modułami AI. Wolimy pragmatyzm. To powiedziawszy, chcę podkreślić, że nie ignorujemy technologii AI i obecnie realizujemy kilka projektów w tym obszarze.
Jaką przyszłość widzisz przed ekosystemem Hadoop? Można spotkać dwie sprzeczne opinie, jedną że nie ma przyszłości – i drugą, że pogłoski o śmierci są stanowczo przesadzone.
Najbliższy rok czy dwa wydają się być przełomowym momentem, który na nowo zdefiniuje świat Big Data i rolę jaką będzie w nim pełnił Hadoop. Wszystko przez takie megatrendy jak konteneryzacja, chmura publiczna, podejście serverless oraz wejście do gry takich graczy jak np. Google.
To jaka przyszłość czeka ekosystem Hadoop w dużej mierze zależy od tego jak walczyć o niego będzie społeczność open-source oraz Cloudera po fuzji z Hortonworks. Na pewno ekosystem ten się unowocześni zgodnie z wymienionymi megatrendami. Strategiczny cel Cloudera na najbliższe lata to tak dostosować swoją nową dystrybucję Big Data, żeby dało się ją łatwo zainstalować nie tylko w serwerowniach klientów, ale też u największych dostawców publicznej chmury (m.in. GCP, AWS, Azure). Ten cel można osiągnąć dzięki konteneryzacji. Niemniej jednak dużo większy nacisk będzie się także kładło na narzędzia, które można łatwiej migrować do chmury np. Spark, Airflow, Jupyter, Nifi, zapewne też Flink i Kafka. Z kolei technologie takie jak HDFS, YARN, ZooKeeper, czyli serca ekosystemu Hadoop, z czasem stracą na znaczeniu na rzecz rozwiązań, które łatwiej się uruchamia zarówno on-premise, jak i w chmurze, czyli Ceph lub Ozone czy Docker i Kubernetes.
Pojawia się również termin open-source cloud, czyli koncepcja zmierzająca do tego, żeby móc uruchamiać popularne narzędzia open-source w chmurze. Oznacza to, że każdy obecny lub nowy projekt open-source (w tym Hadoop) będziemy musiał spełnić dodatkowe wymaganie, czyli możliwość uruchamiania na Kubernetes oraz docelowo w chmurze. Uważam, że takie rozwiązania będą miały większy poziom adopcji, a co za tym idzie, zgromadzą większe społeczności i zwiększą środki na inwestycje, nawet jeśli koniec końców wielu użytkowników będzie uruchamiać je on-premise. Zmienia się model – nie uruchamiamy bezpośrednio na serwerach, tylko w kontenerach, co umożliwia migrację między różnymi środowiskami. Klienci będą mieć możliwość wyboru tego w jakim środowisku chcą zainstalować swoje platformy Big Data, i będą chcieli żeby taka instalacja była bezbolesna
Innymi słowy, w tym momencie jesteśmy w bardzo interesującym punkcie, gdy po ponad dekadzie świat open-source Big Data i Hadoop musi określić się na nowo. Oprócz tego, że technologie open-source będą się konteneryzowały, to wiele z nich czeka na pewno zażarta walka z ich typowo chmurowymi komercyjnymi odpowiednikami closed-source tworzonymi przez dostawców chmurowych (np. Kafka vs. Pub/Sub, Flink vs. Dataflow, Hive vs. BigQuery). Dzisiaj wynik wielu z tych bitew jest nierozstrzygnięty.
O planach Cloudera na najbliższe lata będzie można usłyszeć na konferencji Big Data Tech Warsaw, którą organizujemy w Warszawie już 27 lutego. Z kolei ING opowie o tym jak już teraz od zera buduje swoją nową platformę Big Data opartą o open-source (m.in. Ceph, Kubernetes), tak żeby była ona ewentualnie gotowa na migrację do jednej z chmur publicznych, jeśli będzie taka potrzeba w przyszłości. Z kolei GetInData opowie o tym jak już teraz, krokowo, drogą ewolucji, można rozbudowywać swoją obecną infrastrukturę big data opartą o Hadoop, w kierunku nowoczesnej i przyszłościowej platformy big data zgodnej z obecnymi megatrendami takimi jak kontenery czy cloud. Serdecznie zapraszam!
Pracując dla klientów międzynarodowych i dla polskich czy widzisz różnicę w kulturze wykorzystania danych (data-driven)? Ostatnio opublikowany został raport wg którego polscy przedsiębiorcy gromadzą duże zbiory danych ale.. nie wiedzą po co. Czy przedsiębiorstwa międzynarodowe są bardziej świadome jaką wartość chcą uzyskać z inwestycji w rozwiązania big data?
Dostrzegam delikatną, choć niekoniecznie dużą różnicę. Łatwo znaleźć międzynarodowe przedsiębiorstwa, które wydają ogromne pieniądze na Big Data bez zwrotu z inwestycji.
My natomiast u swoich obecnych klientów widzimy dużą świadomość związaną z produkowanymi przez nich danymi. Z każdym z naszych klientów prowadzimy rozmowy i realizujemy projekty dotyczące monetyzacji danych, wspierania procesów biznesowych, czy ulepszania ich produktów zaawansowaną analityką. Wielu z nich to polscy klienci, zarówno startupy jak i korporacje. Nigdy nam nie zależy żeby budować platformę Big Data, tylko po to żeby gromadzić tam dane i żeby hulał tam wiatr. Przed laty mieliśmy jeden czy dwa takie projekty, ale nauczyliśmy się, żeby tego typu kwestie adresować już na samym początku prac.
Co ciekawe, pierwsze zastosowanie technologii Big Data w firmie nie musi być jakieś szczególnie fantazyjne – przykładowo dla Allegro było to zastąpienie komercyjnej wersji Google Analytics własnymi raportami zasilanymi przez analizy uruchamiane na klastrze Hadoop, dla Spotify było to generowanie niezwykle drobiazgowych cyklicznych raportów na temat odsłuchań piosenek tak aby rozliczyć się z wytwórniami płytowymi i właścicielami praw autorskich, dla Truecaller była to analiza i zrozumienie podróży użytkownika (tzw. user journey), a dla Kcell odpowiednie reagowanie na konkretne aktywności abonentów i interakcje z ich produktami w czasie rzeczywistym. A za tymi zastosowaniami poszły kolejne m.in. systemy rekomendacji, segmentacje, ML/AI, czy zaawansowane analizy pozwalające na podejmowanie decyzji w oparciu nie o intuicje i autorytet, ale i dane.
Założenie, że wystarczy zbudować Data Lake i zacząć gromadzić dane, a potem pomysły przyjdą same jest oczywiście błędne. O tym trzeba pomyśleć w odwrotnej kolejności, i gromadzić tylko te dane które są faktycznie potrzebne biznesowi oraz zbudować tylko taki wycinek Data Lake, który pozwoli na realizację pierwszych projektów. A potem podążać drogą ewolucji zgodnie z potrzebami biznesu.
Adam, dziękuję za rozmowę.
