Rozmowa i opinie po prezentacji “Data Driven Production Apps”



Dima Boyko (Software Engineer, inFakt.pl): Sebastian, opowiedz o czym była ostatnia prezentacja. Jak ci się podobała?

Sebastian Bobrowski (CTO inFakt.pl): Bardzo mi się podobała. Był człowiek z Shopify’a. Dla mnie Shopify to jest taka pierwsza poważna aplikacja Railsowa. Jak ja się zacząłem interesować Rubim i Railsami to Shopify już działał tak produkcyjnie na dużą skalę. To jest tam firma z Kanady dostarczająca oprogramowanie dla sklepów internetowych. To był dla mnie taki, przy podejmowaniu decyzji technologicznej, pierwszy duży punkt, że da radę na Ruby od Rails i Rubim zbudować działającą produkcyjną aplikację. Na tej prezentacji zrozumiałem taką historię trochę Shopify’a, jak to się zaczęło. No zaczęło się od tego, że budowali po prostu aplikację dla sklepów internetowych i ona działała dobrze, ale w pewnym momencie wyszedł temat danych i dlaczego warto je zbierać. Na początku wiedzieli, że są biblioteki machine learningowe, że sztuczną inteligencją można je analizować, natomiast na podstawie danych, które mieli, było dosyć trudno było to robić. Na początku próbowali to robić jakby wewnątrz aplikacji, dobudowywać modele, ale okazało się, że to jest bardzo trudne, jeżeli mamy aplikację, która robi jedną rzecz, czyli dostarcza coś dla sklepów internetowych, to bardzo trudno jest tam dobudować jakiś moduł, który coś tam analizuje. No i ważnym wtedy elementem było to, że zrozumieli, że potrzebują taki magazyn danych, taki data warehouse, po to, żeby tam trzymać te informacje. To jest dla mnie taka pierwsza, najważniejsza rzecz z tej prezentacji.

Dima: Myślisz, że chciałbyś wprowadzić w swoim produkcie, taki data warehause? Czy ma to sens dla takiej skali?

Sebastian: Wydaje mi się… Na pierwszy rzut oka, to jest takie powtarzanie danych, jak gdyby że trzymamy nagle te same dane w dwóch miejscach i na pierwszy rzut oka wydaje się to niezbyt dobrym pomysłem, ale jak się nad tym dobrze zastanowić, co można przy okazji zrobić i jakby jak ta logika mocno jest oddzielona, to wydaje mi się, że ma to duży sens. Wyciągnięcie tych informacji poza, oczyszczenie ich, on opowiadał o tym, że na pewno warto w tym momencie, gdy wyciągamy je z produkcyjnej bazy do tego magazynu, na pewno warto je wtedy oczyścić, tak, żeby mieć je mocno przygotowane i je wręcz włożyć do płaskiej tabeli, czyli żebyśmy nie mieli zależności, które są pomiędzy różnymi tabelami. Mamy kilkadziesiąt tabeli np. w Postgresie i po to, żeby wyciągnąć jedną informację, musimy zjoinować kilkadziesiąt tabeli, to wtedy przy tym takim preprocesingu danych w momencie ich wyciągania możemy je od razu umieścić w jednej tabeli i wtedy dla takiej osoby, która później pracuje z tym magazynem danych, dużo łatwiej jest to zrozumieć i wyciągać. Także jak najbardziej, ale na pewno nie jest to takie super proste zadanie.

Adrian Zięba (Software Engineer, inFakt.pl): Zwróć też uwagę, że on opowiadał o tym, że mieli problemy z główną aplikacją i nie mogli zapewnić użytkownikom podstawowych funkcjonalności, jeśli to wszystko się działo, to analizowanie danych, w tej głównej aplikacji, bo obciążyło to serwer głównej aplikacji i jednym słowem zabrakło mocy obliczeniowej dla podstawowych funkcjonalności. Więc pod tym względem też jest to dobrze dzielić, żeby dywersyfikować obciążenie głównych serwerów.

Sebastian: Jakby się nad tym zastanowić, to można spróbować zrobić tak, że wiesz, ż wydzielasz jakąś tam aplikację bazy danych pod to, żeby z niej tylko czytać te dane, natomiast pytanie, czy to wtedy już nie robisz tego magazynu tak powoli.

Adrian: No właśnie.

Dima: Osobna instancja aplikacji z bazą to jest taki trochę data warehause. Adriano wspominał, że bardzo lubi MongoDB. Uważasz, że na taki data warehouse nadaje się bardziej tradycyjna baza danych czy coś w stylu MongoDB?

Sebastian: Wydaje mi się, że tutaj taka NoSQL’owa baza ma duży sens, właśnie z tego powodu, że wyciągamy dużą ilość danych z takiej produkcyjnej aplikacji, możemy je wcześniej oczyścić, możemy je wcześniej przygotować i możemy je właśnie użytkując zapakować w takie gotowe rekordy, dzięki czemu mamy już je gotowe, możemy coś na nich działać, a nie musimy zawsze trzymać tego schematu. Jeżeli mamy jakieś obiekty, które mają dzisiaj składają się z pięciu wartości, a jutro dochodzi szósta, no to nie musimy jakby całości przebudowywać, plus dostęp do jednego obiektu jest bardzo szybki.

Dima: Ten spiker z Shopify też wspominał, że dzielenie takich danych pozwala użyć zupełnie innych technologii do obróbki tych danych. Uważasz, że warto na tym data warehause używać takiej samej technologii czy można pójść w zupełnie innym kierunku i w innej technologii inne paradygmaty stosować?

Sebastian: Wydaje mi się, że można tutaj… jakby jest bardzo wtedy łatwo użyć innej technologii, ponieważ dużo technologii szczególnie maszyn learningowych ma duże wsparcie dla tego, że mamy dane bezpośrednio w JSON-ie, a dużo mniejsze wsparcie np. dane, które są w SQL-u. Też się da, ale jeżeli mamy dane w JSON-ie, to mamy od razu wsparcie, możemy je bezpośrednio załadować np. do Scikit-Learn’a Pytonowego i „z pudełka” mamy od razu te dane dostępne, możemy je analizować, wyciągać z nich jakieś informacje, budować na nich widoki itd.

Adrian: Zwróć też uwagę, że oni też dokonali na końcu czegoś takiego jak komunikacji zwrotnej. Dlatego że z tego magazynu danych potrzebowali danych na temat, aktualnych danych i danych przewidywanych dla użytkowników odnośnie sprzedaży i później z powrotem, te dane wrzucili do aplikacji łącząc, komunikując je przez API. Więc to też jest tak, że niby te dane są osobno, ale masz też do nich dostęp, do tych rezultatów.

Sebastian: No, bo dzięki temu, że one są w stanie jakby wrócić. Bo tak naprawdę robimy to dla tego użytkownika końcowego. No i ten użytkownik końcowy później ma z tego wartość, bo jesteśmy w stanie te dane wstrzyknąć.