Chwilę mnie nie było, ale wracam z niespodzianką. Zanim o BigQuery to trochę informacji organizacyjnych Podczas ostatnich rozmów z Marcinem Siudzińskim, u którego wystąpiłem w podcaście (więcej tutaj), doszliśmy do wniosku, iż warto połączyć nasze formy wymiany wiedzy. Jak to będzie wyglądało?
Otóż Marcin dzieli się wiedzą głównie poprzez podcast. Ja z kolei — głównie artykułami na blogu. Wiem, iż są zwolennicy jednej i drugiej formy. Aby jak najwięcej osób skorzystało z wiedzy, to u mnie na blogu znajdziesz informacje o nowym odcinku u Marcina. A w artykule:
- Link do nagrania
- Krótki opis
- Ciekawe linki do tematów wymienionych w podcaście.
- Transkrypt odcinka
A teraz już przechodzimy do meritum
Dlaczego warto pomyśleć o BigQuery?
Czy wiesz, iż dzięki BigQuery można zbudować małą hurtownię danych zupełnie za darmo? Czy wyobrażasz sobie wykorzystanie BigQuery w małej rodzinnej firmie, która produkuje dania obiadowe i kanapki?
Ten odcinek się trochę różni się od pozostałych, ponieważ Marcin opowiada w nim o BigQuery, ale z nieco innej perspektywy niż możesz się spodziewać.
BigQuery na pewno kojarzy się z przetwarzaniem ogromnych ilości danych, w petabajtowej skali, czyli klasyczne Big Data. I to wszystko się zgadza, jednak nie jest to cała prawda o BigQuery.
Spojrzymy na to trochę od strony biznesowej, trochę z perspektywy architekta rozwiązań, który może zbudować całkiem potężny system zarządzający procesami w przedsiębiorstwie, którego model działania nie może wykorzystać istniejących rozwiązań. A wszystko to w błyskawicznym tempie i niskim kosztem, wykorzystując w większości gotowe narzędzia.
W odcinku dowiesz się, czym różni się BigQuery od innych narzędzi Big Data, takich jak np. Hadoop oraz o tym, kiedy można czerpać największe korzyści z usług typu serverless, bo nie do końca prawdą jest, iż serverless sprawdza się najlepiej w dużej skali.
A wszystko to będzie poparte realnym przykładem z życia wziętym, w którym koszty infrastruktury systemów informatycznych dla małego przedsiębiorstwa mieściły się w kwocie 5 zł miesięcznie. Tak, nie ma tu pomyłki, słownie pięć złotych miesięcznie, a konkretnie około 1$.
No i na koniec Marcin dzieli się prywatną opinią na temat źródła sukcesu wielu fajnych projektów i produktów z rynku IT.
Zapraszam do odsłuchania odcinka, a na dole artykułu znajdziesz transkrypt odcinka:
Ciekawe linki:
- Strona FB firmy Grzybekfood
- Strony BigQuery
- Książka Radka Kotarskiego: Inaczej
- Odcinek serii Polimaty 2 o rodzajach motywacji.
Czy już nadszedł odpowiedni moment, żeby pomyśleć o BigQuery — transkrypt
Cześć! Witam cię w kolejnym odcinku mojego podcastu: Od danych do danych, za pomocą którego oczywiście do danych będzie ci coraz bliżej. Dzisiaj spotykamy się po dość długiej przerwie. A w dodatku dotkniemy tematów troszeczkę innych niż zwykle. Dziś nie będziemy mówić o kwestiach technicznych, ale o tym kiedy na przykład warto zacząć myśleć o BigQuery.
Od początku istnienia Google tak naprawdę, inżynierowie myśleli o składowaniu i przetwarzaniu ogromnych ilości zbiorów informacji, ogromnych danych, które można było porównać do dobrze znanego żartu sprzed 20 lat: skopiujmy internet na dyskietkę Dlatego wcale nie dziwi mnie podejście większości osób, które na słowo BigQuery myślą o sobie: przecież ja jeszcze nie mam tak dużych zbiorów danych, żeby w ogóle myśleć o tym, żeby zacząć korzystać z BigQuery.
Czym tak naprawdę BigQuery nie jest?
Jeszcze kilka lat temu myślałem podobnie. Myślałem, iż pomysł wrzucania wszystkiego do BigQuery musi zakończyć się kompletną klapą. W końcu o ile coś jest do wszystkiego, to jest do niczego. A co myślę o BigQuery dzisiaj? I dlaczego uważam, iż nadaje się dobrze nie tylko do zastosowań w wielkich korporacji w ogromnych przedsiębiorstwach? Sprawdźmy!
Jak pewnie już wiesz, od dłuższego czasu zajmuje się przetwarzaniem danych. Długo pracowałem z tak zwanym BigData, więc lwią część tego czasu w pracę z Hadoopem i jego ekosystemem. Między innymi praca z Hadoopem, ale nie tylko (ponieważ jest też wiele przykładów z życia codziennego), nauczyły mnie, iż jeżeli coś jest do wszystkiego, to jest do niczego. Czyli raczej korzystamy z narzędzi, które są specjalizowane do wykonywania konkretnej czynności. Kiedy pierwszy raz usłyszałem o BigQuery, a usłyszałem coś w stylu definicji a z Wikipedii, czyli:
BigQuery to w pełni zarządzana bezserwerowa hurtownia danych, która umożliwia nam składowanie i analizę danych w petabajtach.
Drugie zdanie, które opisywało tę hurtownię, to rozwiązanie, było zdanie, które brzmiało mniej więcej tak:
Do BigQuery wrzucamy wszystko i radzimy sobie tam ze wszystkim dzięki SQL-a.
No i to były dwie rzeczy, które z początku zbudziły moje wątpliwości. Ale choćby całkiem spore wątpliwości.
Po pierwsze — w tamtym czasie nie zależało mi na analizowaniu petabajtów danych, ponieważ zbiory, na których pracowałem to były gigabajty, adekwatnie dziesiątki gigabajtów, może setki, czasem terabajty. No i w porywach można powiedzieć, iż pracowałem z dziesiątkami terabajtów, więc petabajtowa skala to nie było to, czego szukałem.
Drugi problem polegał na tym, iż nie za chciałem wierzyć w to, iż BigQuery nadaje się do wszystkiego. No i tutaj byłem rzeczywiście trochę bliżej prawdy, bo oczywiście mowa była o danych w postaci strukturalnej lub semistrukturalnej. Na przykład dane z baz danych relacyjnych, pliki CSV, JSON, XML itd.
O Big Data słów kilka…
Ale żeby trochę lepiej zrozumieć co mam na myśli, chciałbym opowiedzieć Ci jeszcze kilka zdań o Hadoopie. Hadoop ma bogaty system i bardzo wiele wyspecjalizowanych narzędzi. Dane przechowujemy w systemie plików HDFS, czyli mamy tam coś w stylu naszego dysku twardego, tylko iż mieści się na nim zdecydowanie więcej plików. Pliki te mogą mieć ogromne rozmiary. Do tych danych możemy uzyskać dostęp dzięki wielu różnych technologii takich jak na przykład MapReduce, Hive, Impala, Pig, Spark itd. I każde z tych narzędzi służy do czegoś. A adekwatnie każde służy do czegoś innego.
Na przykład MapReduce jest takim środowiskiem programistycznym. Czyli o ile mamy programistę Javowego, ewentualnie i w innych językach programowania, korzystamy z MapReduce. To jest taki paradygmat programowania. To jest taki framework, który dostarcza nam narzędzie umożliwiające pracę z tym rozproszonym systemem plików bez dodatkowego narzutu. Oczywiście to wszystko jest trudne i skomplikowane, bo są to narzędzia dla programistów. I to dość zaawansowanych programistów, ale dlatego powstało też wiele innych narzędzi.
Doskonałym przykładem może być tutaj, np. Hive, który powstał w Facebooku. Facebook nie miał tak wielu programistów Javy. Za to miał bardzo duże grono osób pracujących z MySQL-em i doskonale znających język SQL. Pliki, które składowane są w systemie HDFS, są mapowane do struktury podobnej do tabelarycznej. jeżeli mamy jakiś plik CSV, JSON albo w innym formacie, takim jak np. Parquet, ORC itd, możemy stworzyć strukturę danych, która pozwoli zamapować poszczególne pola do kolumn. Takich jak w relacyjnych bazach danych. I Hive pozwala na odpytywanie tego dzięki języka SQL.
Natomiast w Yahoo wymyślono takie narzędzie, którym jest Pig. Pig służy do tego, żeby przetworzyć te dane. Czyli żeby je jakoś przetransformować, napisać skrypty, które przeczytają coś z plików wejściowych, wykonają proste transformacje i załadują te dane do tabeli docelowej. Można powiedzieć, iż jest to takie narzędzie służące do pisania przepływów ETL. Również do otworzenia przepływowe ETL powstał projekt Apache Spark, który operuje nie korzystając z MapReduce, ale uzyskując bezpośrednio dostęp do plików w systemie HDFS przez Yarn. I operuje wykonuje operację w pamięci operacyjnej workerów.
Jeśli chcielibyśmy załadować dane z lub do bazy relacyjnej, możemy skorzystać z takiego narzędzia, które nazywa się Sqoop. jeżeli chcielibyśmy skorzystać z jakiejś bazy transakcyjnej, która miałaby służyć do obsługi bardzo dużych ilości operacji wejściowych i wejściowych, dobrym rozwiązaniem może być HBase czy Cassandra. Chociaż trzeba pamiętać o tym, iż są to bazy key-value, a nie relacyjne. No i pozostało mnóstwo innych narzędzi. Można zintegrować to na przykład z Flumem, Kafką, Stormem i całą rzeszą innych aplikacji, których pewnie nie jesteśmy w stanie wymienić w tym odcinku.
Ale chyba największym problemem, który wiąże się z wykorzystywaniem takich narzędzi jak na przykład Hadoop, czy w ogóle BigData jest to, iż tworzenie tych klastrów obliczeniowych ma sens dopiero wtedy, kiedy danych jest naprawdę dużo. To znaczy, żeby miało to sens i żeby było to chociażby porównywalnie wydajne, czy miało porównywalną prędkość odczytu tych danych do klasycznych rozwiązań, potrzebujemy minimum kilkanaście, kilkadziesiąt węzłów. Narzut na operacje jest dość spory. jeżeli chcielibyśmy uruchomić na przykład proste zapytaniem w Hivie, to potrzebujemy kilkunastu sekund na to, żeby zwróciło ono podstawowe wyniki. No i to właśnie wynika z faktu, iż jest rozproszony system plików. Operacje najpierw muszą zostać delegowane na zdalne węzły. Następnie te poszczególne części operacji muszą zostać wykonane. A na koniec musimy wykonać jeszcze agregacje tych wyników, które zostały zwrócone przez poszczególne węzły.
Instalacja takiego klastra jest bardzo skomplikowana. Oczywiście instalacji towarzyszy konfiguracja, utrzymywanie, monitorowanie, problemy z bezpieczeństwem danych. Tak naprawdę zarządzanie bezpiecznie danymi w Hadoopie, o ile jest możliwe, to wymaga dużo wysiłku. No i można powiedzieć, iż Hadoop, czy jakiekolwiek inne rozwiązanie Big Data, tak naprawdę będzie miało bardzo duży próg wejścia. Trochę lepiej będzie wyglądało to w przypadku narzędzi takich jak narzędzia chmurowe. Tam przynajmniej nie musimy zawracać sobie głowy infrastrukturą czy bezpieczeństwem. przez cały czas jednak nie jest to tak szybkie, proste i przyjemne jak skorzystanie z np. klasycznej relacyjnej bazy danych.
Zawsze mówiłem, iż BigData zaczyna się tam, gdzie kończą się możliwości naszych tradycyjnych rozwiązań i tradycyjnych systemów. Takich jak chociażby relacyjne bazy danych. Ze względu na wydajność albo zbyt duże koszty takich środowisk rozproszonych, jeżeli można coś zrobić tradycyjnie, to nie strzelajmy z armaty do muchy i nie róbmy tego dzięki Big Data.
A gdzie tutaj jest BigQuery?
Od kilku minut dążę do tego, żeby podsumować mniej więcej czym nie jest BigQuery. BigQuery tak naprawdę nie jest takim typowym rozwiązaniem Big Data. Pomimo tego, iż ma w sobie pewne podobieństwa, a choćby całkiem sporo podobieństw do rozwiązań takich jak na przykład Hadoop, Hive czy Presto, to tak naprawdę różnicy jest również bardzo wiele.
Po pierwsze — nie jest otwartym systemem. Nie posiada tak bogatego ekosystemu Open Sourcowego. No ale za to doskonale integruje się z innymi narzędziami – zarówno GCP, firm trzecich, a choćby całkiem sporą ilością rozwiązań Open Source. Generalnie podejście Google jest takie, iż bardzo mocno opiera się na usługach Open Sourcowych i wiele narzędzi, z których korzysta się w ramach chmury GCP, jest oparte o Open Source.
Po drugie — BigQuery nie jest takim typowym narzędziem do budowania Data Lake, w takim tradycyjnym ujęciu. Czyli ono nie działa tak jak Hadoop + np. Hive, Impala czy Presto. Tutaj nie będziemy mapować plików, chociaż to jest możliwe. Wszystkie dane są ładowane, albo przynajmniej powinny być ładowane do natywnych tabel. Dzięki czemu odczyt jest szybszy i bardziej wydajny. No niekoniecznie zawsze tańszy. BigQuery tak naprawdę trochę bliżej jest chyba do hurtowni danych niż do takiego typowego Data Lake’a. Ale łączy w sobie na zalety jednego i drugiego.
Po trzecie — BigQuery nie jest taką tradycyjną bazą danych, a przynajmniej nie transakcyjną bazą danych. To jest rozwiązanie typowo analityczne. Działa typowo w modelu OLAP, nie OLTP. W związku z tym update’y inserty i delete’y są oczywiście możliwe, ale trzeba pamiętać, iż są ograniczone. Mamy na przykład limit takich operacji ustawiony na poziomie 1500 operacji update dla każdej tabeli, w ramach naszego projektu dziennie. No i właśnie BigQuery nie służy do odczytu danych z systemów plików. To nie jest tak, iż tak jak w Hadoopie: ładujemy tam pliki CSV, JSON, Parquet, a następnie nakładamy na nie pewną strukturę i odpytujemy te pliki. Oczywiście to też jest możliwe. Możemy utworzyć tabelę external, ale to nie jest to natywne podejście, które jest wykorzystane w BigQuery.
BigQuery samo w sobie nie posiada narzędzi do tworzenia przepływów ETL, ale za to może być wykorzystywane jako narzędzie ELT. Czyli najpierw ładujemy dane do BigQuery, a następnie dzięki np. schedulera oraz kilku zapytań, możemy te dane przetransformować i załadować do innej tabeli. Istnieje też taka możliwość, żeby załadować dane z tablic zewnętrznych. Przykładowo możemy podłączyć sobie jakieś pliki CSV czy JSON. Albo możemy podłączyć np. arkusz kalkulacyjny Google Sheet i te dane wykorzystać w procesie ładowania danych. Możemy napisać takie procedury, które załadują dane z tych źródeł do BigQuery.
Następny punkt to to, iż BigQuery w ogóle nie wymaga skomplikowanej infrastruktury. A przynajmniej nie musimy się nie martwić, bo to Google nią zarządza. BigQuery jest narzędziem całkowicie serverless. Tutaj płacimy tylko i wyłącznie za ilość miejsca, którą wykorzystamy oraz za ilość danych, którą przeczytamy. Nie ma tam żadnych dodatkowych opłat za infrastrukturę. Nie trzeba stawiać żadnych klastrów, żadnych serwerów i tym podobnych. Może go obsłużyć praktycznie każdy, bo BigQuery jest gotowe do użycia w zasadzie zaraz po utworzeniu projektu w GCP. I każdy, kto ogarnia SQL, od razu w sposób bezpieczny może zacząć pisać zapytania, uzyskiwać bezpieczny dostęp do danych.
W zasadzie nie ma żadnego większego progu wejścia dla kogoś, kto zna SQL. Poza tym taka operacja odczytu, w przeciwieństwie do Hadoopa, będzie trwała znacznie krócej. To znaczy, o ile chcemy napisać jakiegoś prostego SQLa, to czas, w którym rezultaty zostaną nam zwrócone, to będzie około jednej sekundy. Nie kilkanaście tak jak w przypadku Hive. Więc zdecydowanie lepiej będzie się nadawało do jakiś takich narzędzi raportowych. Czy do tego, żeby zasilać nasz front-end czy jakieś systemy dashboardów. No i podsumowując ten punkt, można powiedzieć, iż BigQuery zdecydowanie jest narzędziem służącym do analizy Big Data, ale nadaje się doskonale również do dużo mniejszych zadań.
Rozwiązanie, które kosztowało 5 zł miesięcznie! Historia z życia!
No i dzisiaj, zamiast opowiadać Wam, czym tak naprawdę jest BigQuery, chciałbym zobrazować na podstawie mojego doświadczenia. Opowiedzieć wam krótką historię, która miała miejsce w ostatnich latach. Tym razem nie będzie to opowiadanie o tym EpicFail, które próbowało przetwarzać 300 MB za pomoc narzędzi Big Data i osiągnął spektakularny sukces redukując kilkudniowy proces do kilku godzin. Tym razem opowiem o małej firmie, która zatrudniała około 10 osób. I dzięki BigQuery, Cloud Functions oraz pakietowi G Suite, udało się stworzyć dla niej rozwiązanie, które zarówno obsługiwało analitykę jak i back-end. Całkowity koszt tego rozwiązania, całkowity koszt infrastruktury zamykał się w kwocie poniżej 5 zł miesięcznie. jeżeli jesteście ciekawi, to posłuchajcie.
Kilka lat temu pewne małżeństwo postanowiło zmienić swój sposób na życie oraz sposób na życie kilku członków swojej rodziny i założyć firmę rodzinną, której model biznesowy można byłoby opisać prostymi słowami: Pan Kanapka. Misja była bardzo prosta. Klienci codziennie będą mogli zjeść w biurze posiłek tak dobry, jak w dobrej restauracji. Bez nudy, pysznie, niekoniecznie dietetycznie. Może to być kanapka, może to być danie obiadowe, może być sałatka. Co kto lubi. Z początku zaczęło się od tych rzeczy podstawowych. To znaczy, trzeba było najpierw znaleźć lokal, wyposażyć go, zacząć proces produkcji, sprzedaż, znaleźć klientów itd. Ale w dzisiejszym świecie tak naprawdę każda firma jest, choć odrobinę, firmą technologiczną. A jeżeli nie jest, to trudno jest się jej rozwijać.
No i w tej sytuacji kiedy ta mała rodzinna firma rozwinęła się do takiego poziomu, iż w ciągu dnia obsługiwała kilkuset klientów, pojawiło się kilka problemów, które na tak małą skalę były dość skomplikowane. Wyglądało to mniej więcej tak.
Każdego dnia zmienia się menu. Informacja o tym menu powinna pojawić się na stronie internetowej oraz w mediach społecznościowych we właściwym momencie, żeby klienci mogli zapoznać się z ofertą na dany dzień. Dodatkowo oferta musiała zawierać cennik. Trzeba było odpowiednio zaplanować pracę kuchni, np. zaopatrzenie. Trzeba było też analizować jakie produkty będą sprzedawane i w jakich ilościach. Tak, żeby przygotować się na odpowiedni dzień sprzedaży. Trzeba było też analizować, które kroki były dobre, które były złe. Jakich produktów sprzedawać więcej, jakich produkować mniej. Tak z biznesowego punktu widzenia, historia jest bardzo przydatna. Historia przydaje się również wtedy kiedy nie masz siły na to, żeby wymyślić nowe menu, zawsze możesz sięgnąć do tego co było rok temu.
No i te problemy, które opisałem, są mocno niestandardowe. One nie pasują do standardowych modeli biznesowych. I nie do końca można wykorzystać istniejące na rynku narzędzia, ponieważ one nie są dopasowane do potrzeb akurat tego biznesu. Dodatkowym poziomem skomplikowania jest to, iż te osoby, które pracują w kuchni, niekoniecznie są osobami technicznymi. A można powiedzieć, iż często wręcz bardzo nie są osobami technicznymi. Więc korzystanie z różnego rodzaju narzędzi internetowych, narzędzi typu: CRM, ERP itd. absolutnie twoje nie wchodzi w grę, ponieważ to jest zbyt skomplikowane.
Dodatkowo mała firma zatrudniająca kilku pracowników czy kilkunastu pracowników, nie zawsze ma ogromne środki na inwestycje w sprzęt, dedykowane oprogramowanie klasy Enterprise. A duża zmienność i to, iż nie możemy sobie pozwolić, aby wdrażać jakieś rozwiązanie miesiącami, wymaga takiej sporej elastyczności. I zapewnienia, iż wszystko da się zrobić w sposób prosty przyjazny i szybki.
Dobrą informacją jest to, iż choćby użytkownicy, którzy nie znają się na technologii, są w stanie skorzystać z prostych narzędzi takich jak, chociażby arkusze kalkulacyjne. Na przykład Google Sheets, które obsługują w telefonie, czy na tablecie. Arkusz kalkulacyjny jest prosty, ale nie rozwiązuje wszystkich problemów. W przypadku tej małej firmy, o której mówię, rozwiązaniem okazało się wykorzystanie BigQuery, Cloud Functions oraz kilku innych narzędzi ze stajni GCP. Arkusze kalkulacyjne w BigQuery mogą zostać wykorzystane jako źródło danych. Jako tabela zewnętrzna, której zawartością można zarządzać z poziomu aplikacji w telefonie czy na tablecie albo przez internet. Nie wymaga żadnych inwestycji, ponieważ jest to darmowe narzędzie dostępne dla wszystkich. Kiedy wykorzystamy taki arkusz kalkulacyjny jako tabelę zewnętrzną w BigQuery, możemy te same dane, które zostały zmodyfikowane w aplikacji na telefonie przetwarzać dzięki języka SQL.
Zmiany oczywiście rejestrowane są w czasie rzeczywistym. Bardziej skomplikowane czynności i operacje można wykonać dzięki np. skryptów Pythonowych działających w sposób zautomatyzowany. o ile chcemy codziennie wygenerować menu z cennikiem na dany dzień, wygenerować listę zakupów, które trzeba zrobić czy np. listę specjalnych zamówień, to nadają się do tego świetnie takie usługi jak Cloud Functions czy Cloud Scheduler. Wszystkie te usługi są usługami serverless, działającymi w modelu pay-as-you-go. I uwaga! To nie zawsze znaczy tanio, ale właśnie sprawdza się szczególnie w przypadku małej firmy. o ile jesteśmy częścią dużego przedsiębiorstwa, to bardzo musimy uważać na wszystkie rozwiązania pay-as-you-go. Może się okazać, iż ich wykorzystanie będzie znacznie większe niż oczekiwano.
Natomiast w przypadku małej firmy, wykonujemy tylko dziesiątki, może setki operacji dziennie. W związku z tym nie jesteśmy w stanie często choćby przekroczyć tych limitów, które są przyznawane w ramach free tier. Można powiedzieć, iż te usługi są nam dostarczane zupełnie za darmo. Rozwiązania takie nie wykorzystują choćby jednego serwera, które trzeba byłoby monitorować, serwisować czy wykonywać jakieś operacje updatów, patchowania itp. No i można powiedzieć, iż w przypadku tego konkretnego przedsiębiorstwa, zaimplementowanie rozwiązań opartych o BigQuery, Cloud Functions, Cloud Scheduler i jeszcze kilka drobnych usług znaczy z GCP, pozwoliło zaoszczędzić praktycznie pełen etat osoby, która musiałaby wykonywać te czynności codziennie manualnie. Więc to całkiem spora oszczędność.
Jednak firma, o której mówię, z prawdziwym wyzwaniem spotkała się w momencie wybuchu pandemii. Wyobraźcie sobie, iż w dniu kiedy ogłoszono lockdown, z dnia na dzień tracicie 100% klientów i 100% przychodu. Tracicie płynność finansową. Nie jesteście przygotowani do tego, żeby sprzedawać online, bo model biznesowy nie pasuje do rozwiązania online’owych. Nie możecie nawiązać współpracę z agregatami takimi jak Pyszne, Uber, ponieważ ta firma nie działa jak restauracja, tylko raczej jak firma produkcyjna.
Zwróćcie uwagę też na to, iż klienci byli przyzwyczajeni do tego, iż firma dojeżdża do nich. Ze ten produkt jest łatwo dostępny i oni nigdy nie musieli go szukać. Nigdy nie zastanawiali się skąd wziąć ten produkt. On zawsze był na miejscu. Marka była stworzona ekskluzywnie na rynek korporacji i tylko tam była rozpoznawalna. Poza biurowcami nikt nie słyszał choćby o tych usługach. Nikomu nie przychodziło na myśl również, iż można zamówić jedzenie z tej konkretnej firmy. No nic tylko usiąść i płakać. To koniec! Hasta la vista!
Walka o Grzybek Food
Firma, o której mówię nazywała się Grzybek Food i była prowadzona przez moją żonę i przeze mnie. A w związku z tym, iż my nie lubimy poddawać się bez walki i lubimy starać się sprostywać trudnym wyzwaniom, postanowiliśmy podjąć próbę ratowania z tej sytuacji. I jak to zrobiliśmy?
Grzybek FoodPo pierwsze otworzyliśmy sklep internetowy online. Skorzystaliśmy oczywiście z gotowej platformy, czyli w tym przypadku była to platforma Shopper. Polecam — całkiem dobrze nam się z nią współpracowało. Zaczęliśmy sprzedaż online.
Proces aktualizacji asortymentu sklepu musiał być zautomatyzowany. manualne aktualizacje nie wchodziły w grę ze względu na to, iż mieliśmy rąk do pracy. Nie mieliśmy też środków na to, żeby zatrudnić kolejne osoby. Integracja odbywała się do przez API systemu Shopper. No i korzystaliśmy skryptów Pythonowych, wykonywanych przez Cloud Functions, dzięki harmonogramów zarządzanych przez Cloud Scheduler. Cały ten projekt obejmował jednego programistę oraz jedną osobę zarządzającą całą resztą tego bałaganu. Pracowaliśmy po godzinach, podczas lockdownu, z trójką dzieci w wieku od niemowlaka do przedszkolaka. System został w takich warunkach wdrożony w ciągu dwóch tygodni. No i przyznaję — nigdy więcej bym się czegoś takiego nie podjął, ale chciałbym zwrócić uwagę na to, iż rozwiązania te są proste i dostępne.
Jaki był efekt tej operacji? Przyznaję, iż ruszyliśmy ze sprzedażą pod koniec marca 2019. Początku ekstremalnie trudno. Udało się osiągnąć tak mniej więcej 10 do 20% normalnego obrotu. Poziom sprzedaży był też bardzo mocno skorelowany z działaniami marketingowy na Facebooku. W wynikach sprzedaży było widać każdy słabszy dzień Marty. Z początku byliśmy naprawdę pod kreską, ale nasze usługi spodobały się też korporacjom, z którymi współpracowaliśmy. Bardzo dużą część naszego nowego modelu biznesowego zamiast sprzedaży B2C, stała się właśnie sprzedaż B2B.
Staliśmy się dostawcą benefitów pracowniczych. Później sytuacja zaczęła się trochę poprawiać na plus. A w dodatku lockdown ulegał złagodzeniu, więc pracownicy zaczynali wracać masowo do biur. A to, w połączeniu z nowym modelem biznesowym, zaczęło odwracać naszą złą passę. W sierpniu odzyskaliśmy płynność finansową, a wrzesień był naszym najlepszym miesiącem w historii sprzedaży.
Jednak niestety w październiku nastąpił kolejny lockdown. A ponieważ obiecaliśmy sobie, iż ta firma będzie dla nas, a nie my dla firmy, postanowiliśmy pozostać wierni naszym wartością i jeszcze przez kilka miesięcy prowadziliśmy sprzedaż, natomiast dzisiaj firma przygotowana do likwidacji.
Czego uczy nas ta historia?
Co moim zdaniem jest najważniejsza w tej historii? Gdyby nie serverless i usługi takie jak BigQuery, Cloud Functions w połączeniu z Google Sheets oraz z kilkoma innymi usługami, nie bylibyśmy w stanie przetrwać pierwszej fali pandemii. Zastosowanie narzędzi, które powstały z myślą o przetwarzaniu petabajtów, w przypadku małego przedsiębiorstwa stają się praktycznie darmową alternatywą dla drogich hurtowni i dla drogich systemów przetwarzania danych, systemów baz danych. BigQuery nie jest typowym narzędziem Big Data i może być stosowany choćby tam, gdzie tych dużych danych nie ma.
Siła BigQuery tkwi nie tylko w gotowości i wydajności do przetwarzania tych ogromnych zasobów, liczonych w tera- i petabajtach, a również w łatwości integracji z wieloma usługami i narzędziami dostarczonymi przez inne firmy, niskim koszty składowania danych, łatwości implementacji no i latach doświadczenia, które spowodowały, iż Google dostarczyło tę usługę w takiej formie, w jakiej jest ona dostępna dzisiaj.
Moim skromnym zdaniem u źródła sukcesu tej usługi stoi to, iż Google tak naprawdę stworzyło ją do swoich wewnętrznych potrzeb, dla siebie. Jeszcze zanim podjęli decyzję o komercjalizacji tego pomysłu. Dlatego usługa została udostępniona w ramach GCP jako produkt gotowy i sprawdzony. Moim zdaniem działa to trochę tak jakbyśmy porównali motywację wewnętrzną i zewnętrzną. Według wielu badań motywacja wewnętrzna jest znacznie bardziej efektywna i osoby kierujące się motywacją wewnętrzną osiągają znacznie lepsze rezultaty. I chociaż często zdarza się, iż produkty budowane od razu w celu sprzedaży, komercjalizacji, również okazują się bardzo dobrym produktem i ogromnym sukcesem.
Jednak jak pokazuje historia, bardzo wiele z takich udanych projektów, takich jak np. Apache Hive, Pig, Airflow, Superset, jak BigQuery, czy choćby jak usługi AWS, czyli Amazon Web Services, zostały stworzone najpierw do zaspokojenia własnych potrzeb przedsiębiorstw, w których powstały. A dopiero potem zostały skomercjalizowane w jakiś sposób.
Jeśli ten temat motywacji wewnętrznej i zewnętrznej zainteresował Cię chociaż trochę, to bardzo polecam książkę Radka Kotarskiego: Inaczej. On tam wskazuje proste porównania, dowody naukowe, które pokazują różnice między tymi dwoma typami motywacji, załączając również szereg pozycji bibliograficznych.
Źródło: https://altenberg.pl/inaczej-radek-kotarski/A w oczekiwaniu na kolejny odcinek mojego podcastu, zachęcam też do obejrzenia odcinka Polimatów 2, w których właśnie Radek Kotarski opisuje zagadnienia motywacji wewnętrznej i zewnętrznej:
Chociaż na dzisiaj to już wszystko, to jeszcze nie koniec moich opowieści o BigQuery. W kolejnym odcinku opowiem Ci znacznie więcej na ten temat. I mam nadzieję, iż dzięki temu będziesz lepiej rozumieć, jak działa ta usługa i kiedy można z niej skorzystać. Szczególnie w twoim konkretnym przypadku. Wszystkich zapraszam do odwiedzenia i śledzenia mojej strony na LinkedIn oraz do subskrybowania mojego podcastu. A w nim już niedługo ukażą się kolejne odcinki. Do usłyszenia!
