Jak stworzyć rozszerzalną platformę Big Data do zaawansowanej analityki? Jak ją skalować z kilku terabajtów do ponad 100 petabajtów danych, zmniejszając jednocześnie opóźnienie w dostępie do danych z ponad 24 godzin do minut. Reza Shiftehfar, lider zespołu odpowiedzialnego za platformę Hadoop w firmie Uber, podczas „Big Data Tech Warsaw Summit 2020” opowiadał o budowie oraz rozwoju niezawodnej i skalowalnej platformy Big Data. W Uber obsługuje ona petabajty danych w czasie rzeczywistym, wykorzystując technologie, takie jak: Apache Hadoop, Apache Hive, Apache Kafka, Apache Spark i Presto.

Na czym polega Pana praca w Uberze?

Zarządzam zespołem odpowiedzialnym za nowe platformy Big Data. To zespół, który dostarcza analizy Big Data jako usługę dla pozostałych jednostek organizacyjnych firmy. Pracuję w Uber od 2014 roku. Wtedy byliśmy małym start-upem – nasze dane były wystarczająco małe, aby zmieścić się w tradycyjnej bazie danych Postgres na jednym urządzeniu. Przez ostatnie siedem lat nasze dane urosły z kilku terabajtów do ponad setek petabajtów. Musieliśmy zbudować skalowalną horyzontalnie infrastrukturę.

Jak wyglądał rozwój firmy w tym czasie i jak wpłynęło to na infrastrukturę danych?

Osiągnięcie jednego miliarda podróży na platformie zajęło nam prawie sześć lat. Dojście do drugiego miliarda zajęło nam już tylko sześć miesięcy. Na kolejny miliard potrzebowaliśmy pięciu miesięcy, a na następny tylko czterech. Jeśli spojrzymy na to z perspektywy infrastruktury, oznacza to, że ciągle musimy planować następną architekturę, ponieważ wzrost jest wykładniczy, a skalowanie infrastruktury nie jest takie łatwe.

Spójrzmy też na zakres oferowanych przez nas produktów. Zaczęliśmy w 2010 roku, proponując tylko przejazdy. To względnie prosty produkt. Masz jednego kierowcę, jednego pasażera, a podróż odbywa się w tym samym czasie. Następnie uruchomiliśmy UberPool. Ten produkt oferuje znacznie lepsze doświadczenie dla użytkownika. Jest tańszy, ale o wiele bardziej skomplikowany: masz jednego kierowcę, dwóch pasażerów i dwa przejazdy, które się pokrywają.

Potem wystartowaliśmy z Uber Eats. To jeszcze bardziej skomplikowany produkt. Mamy zaangażowane trzy strony: osobę, która złożyła zamówienie, partnera w restauracji, a także kogoś, kto odbierze i dostarczy zamówione jedzenie. Potrzebne do tego są dwa przejazdy: jeden, aby dostać się do restauracji, odebrać jedzenie, i drugi, żeby dostarczyć zamówienie. Następnie uruchomiliśmy Uber Freight, gdzie mamy jeszcze więcej zaangażowanych stron. Zatem dojrzałość i złożoność produktów rośnie. Rośnie także ilość generowanych danych. Musimy mieć dość niezawodną infrastrukturę danych, aby móc zapewnić użytkownikom jeszcze lepsze doświadczenia. 

Dojrzałość i złożoność produktów rośnie. Rośnie także ilość generowanych danych. Musimy mieć niezawodną infrastrukturę danych, aby zapewnić użytkownikom jak najlepsze doświadczenia.

Jak dane są wykorzystywane w Uberze?

Dane stanowią fundament działalności naszej firmy. Korzystamy z historycznych danych, doświadczeń poprzednich użytkowników, aby stworzyć znacznie lepsze i płynniejsze doświadczenia dla pasażerów w przyszłości. Patrząc na wewnętrznych użytkowników danych w firmie, z perspektywy infrastruktury, mamy trzy główne kategorie użytkowników.

Mamy tysiące operatorów w miastach. Są to zespoły zlokalizowane na miejscu, w każdym mieście, w którym działamy. Zarządzają one naszą siecią transportową i skalują ją na danym rynku. Są jak małe start-upy działające w ramach Ubera. Ich celem jest zwiększenie liczby podróży w danym mieście. Są to zespoły operacyjne. Nie mają umiejętności technicznych i nie piszą kodu, co najwyżej proste zapytania SQL. Ich umiejętności techniczne są niskie, ale zależność od danych jest wysoka.

Mamy również setki data scientist i analityków danych. Badają oni historyczne dane i sprawdzają na nich nowe pomysły, testują różne produkty. Posiadają umiejętności techniczne. Potrafią pisać zapytania, kodować, a przy tym rozumieją, czego dane dotyczą. Pracują na dużej ilości danych historycznych.

Zatrudniamy w firmie setki inżynierów, których praca skupia się na danych. Budują usługi, które podają na przykład szacowany czas dostawy zamówionego jedzenia. Posiadają wysokie umiejętności w zakresie kodowania, a zależność ich pracy od danych jest dość wysoka.

Jaka wygląda skala korzystania z danych przez Ubera wyrażona w konkretnych liczbach?

Każdego dnia generujemy ponad 2 biliony unikalnych zdarzeń, mamy ponad 20 tysięcy fizycznych hostów w każdym z naszych centrów danych i setki petabajtów danych w klastrach HDFS. Generujiemy ponad 200 terabajtów nowych danych dziennie i mamy kilkaset tysięcy zapytań, które dotyczą tych danych każdego dnia. Mamy ponad 2 tysiące unikalnych pulpitów menedżerskich, z których korzystają różne jednostki w organizacji, żeby widzieć, jak na bieżąco działa firma. 

Generujemy ponad 200 terabajtów nowych danych dziennie i mamy kilkaset tysięcy zapytań, które dotyczą tych danych każdego dnia. Mamy ponad 2 tysiące unikalnych pulpitów menedżerskich. 

Jaka była Wasza filozofia budowania platformy infrastrukturalnej na skalę petabajtową?

Wiedzieliśmy, że żadna firma nie jest w stanie zbudować wszystkiego od zera. Na świecie jest bardzo mało firm, które działają na taką skalę, mają do czynienia z taką ilością danych. Najlepszym sposobem na zbudowanie niezawodnej platformy jest współpraca z nimi i społecznością open source. Intensywnie użytkujemy popularne platformy Big Data w modelu open source. Jesteśmy wieloletnimi użytkownikami Spark, Hive, Presto, HDFS czy Parquet.

Jednocześnie wiele z tych produktów nie sprawdza się w dużej skali od razu, „po wyjęciu z pudełka”. Kiedy zaczynamy ich używać, dostrzegamy wszystkie te ograniczenia dotyczące ilości danych. Dlatego staramy się przebudować ich architekturę, przeprojektować te komponenty, aby zwiększyć możliwości skalowania. Staramy się jak najlepiej wspierać społeczność open source i dostarczać wyniki naszych prac. Dobrymi przykładami takich działań są węzły Observer w HDFS czy wsparcie geoprzestrzenne w Presto.

Czasem widzimy, że istnieje luka w przestrzeni open source – nie ma jednego produktu, który byłby w stanie zaspokoić nasze potrzeby, lub jest wiele produktów, ale nie na naszą skalę. Wtedy zaczynamy od zera własny projekt. W takich przypadkach również staramy się otwierać tworzony kod. Przykładami takich projektów, które pochodzą z mojego zespołu, są Apache Hudi i Marmaray.

Reza Shiftehfar był prelegentem na konferencji „Big Data Tech Warsaw Summit 2020”. Relacja z tego wydarzenia znajduje się na stronie https://e-s-r.pl/2020/03/05/wielkie-zbiory-danych-jeszcze-wieksze-wyzwania/.